Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Notebook di Microsoft Fabric per il training IA: modelli direttamente sui dati del Lakehouse, senza caos di CSV (Doppiaggio IA)

Transcript

Notebook di Microsoft Fabric per il training IA: modelli direttamente sui dati del Lakehouse, senza caos di CSV (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Speaker 2: Pronto per 10 giorni di Microsoft 365, Copilot EA, Azure
0:04
Speaker 2: e le persone che stanno plasmando il futuro del lavoro?
0:07
Speaker 2: Questo gennaio, M365 con ritorno e puntiamo ancora più in alto?
0:13
Speaker 2: Unisciti a noi per sessioni live, demo concrete e conoscenze
0:15
Speaker 2: pratiche da MVP ed esperti del settore da tutto il mondo.
0:18
Speaker 2: Niente slide generiche, niente inutili tecnicismi. Affrontiamo le sfide reali.
0:23
Speaker 2: Copilot Studio, agenti IA, Fabric, Sicurezza, Governance e Automazione. Che
0:29
Speaker 2: tu sia un professionista IT, uno sviluppatore o un leader aziendale,
0:33
Speaker 2: ci sono sessioni pensate per te. Con 10 giorni interi
0:36
Speaker 2: potrai esplorare molteplici tecnologie e connetterti con una community globale.
0:40
Speaker 2: Segui dal vivo e porta intuizioni pratiche nella tua organizzazione.
0:45
Speaker 2: Dal 20 al 27 gennaio. 10 giorni. Un'unica community Microsoft.
0:49
Speaker 2: Le iscrizioni sono aperte. Vai su m365com. net e assicurati un
0:54
Speaker 2: posto oggi stesso. Il sito è m365com. net. Iscriviti ora su m365con. net,
1:02
Speaker 2: ci vediamo live. A gennaio...
1:05
Speaker 3: Hai mai provato ad addestrare un modello di IA sul
1:07
Speaker 3: tuo portatile per poi vederlo procedere a rilento per ore
1:09
Speaker 3: o bloccarsi del tutto? Non sei solo. La maggior parte
1:12
Speaker 3: dei dataset aziendali ha superato le capacità del nostro locale.
1:16
Speaker 3: Ma se il tuo intero dataset da svariati terabyte fosse
1:18
Speaker 3: istantaneamente accessibile nel tuo notebook di addestramento? Nessun estratto, niente
1:21
Speaker 3: caos di file CSV. Oggi entriamo nei notebook integrati di
1:24
Speaker 3: Microsoft Fabric, dove l'addestramento del modello avviene direttamente accanto ai
1:28
Speaker 3: dati del tuo lake house analizzeremo esattamente come questa configurazione
1:32
Speaker 3: può far risparmiare giorni di elaborazione permettendoti di lavorare in
1:35
Speaker 3: Python o R senza compromessi quando i big data superano
1:40
Speaker 3: le capacità del tuo portatile immagina la ventola che gira
1:42
Speaker 3: così forte da coprire la tua riunione mentre lavori su
1:45
Speaker 3: un foglio di calcolo ora sostituisci quel foglio di calcolo
1:48
Speaker 3: con 12 terabyte di transazioni clienti grezze spalmate su anni
1:51
Speaker 3: di attività con decine di campi per record ancora prima
1:55
Speaker 3: di premere invio sai già che sarà un disastro è
1:58
Speaker 3: esattamente la situazione in cui si trovano molti team di
2:00
Speaker 3: marketing Hanno un database transazionale che potrebbe facilmente essere la
2:03
Speaker 3: base di un progetto di avanzato. Prevedere l'abbandono, segmentare il pubblico,
2:09
Speaker 3: personalizzare le campagne quasi in tempo reale, ma i loro
2:12
Speaker 3: strumenti sono ancora bloccati sui desktop. Aprono file in Excel
2:18
Speaker 3: o in un notebook Jupyter locale, segmentando e filtrando in
2:21
Speaker 3: piccoli pezzi solo per evitare che la macchina si congeli,
2:24
Speaker 3: sperando che tutto regga abbastanza a lungo da ottenere risultati utilizzabili.
2:29
Speaker 3: Quando i team provano a farlo localmente, i limiti emergono rapidamente.
2:32
Speaker 3: L'elaborazione rallenta drasticamente, l'interfaccia utente risponde con secondi di ritardo
2:36
Speaker 3: e gli script di esportazione che richiedevano minuti ora impiegano ore.
2:39
Speaker 3: Peggio ancora, i carichi di lavoro più grandi non rallentano soltanto,
2:41
Speaker 3: si fermano. Errori di memoria, sovraccarico del disco, riavvi del
2:44
Speaker 3: camera fanno sì che i processi di addestramento non solo
2:46
Speaker 3: richiedano più tempo, ma spessano più tempo, ma spesso non
2:48
Speaker 3: finiscano mai. E quando parliamo di addestrare un modello di
2:50
Speaker 3: IA si tratta di calcolo sprecato, tempo perso e opportunità mancate.
2:55
Speaker 3: Un tentativo di previsione del tasso di abbandono che ho
2:57
Speaker 3: visto era stato pianificato come un'esecuzione notturna in un ambiente
3:00
Speaker 3: Python locale. 20 ore dopo il processo è fallito perché
3:03
Speaker 3: l'ultima parte del set di dati ha superato il limite
3:06
Speaker 3: di utilizzo della RAM. Il team ha perso un'intera giornata
3:09
Speaker 3: senza nemmeno ottenere una serie di metriche di addestramento. Se
3:12
Speaker 3: sembra estremo sappiate che sta diventando sempre più comune. I
3:15
Speaker 3: set di dati di marketing aziendali crescono di anno in
3:17
Speaker 3: anno guidati da tracciamento avanzato, esperienza omnicanale e log basati
3:23
Speaker 3: sugli eventi Anche in una configurazione standard, log delle campagne,
3:27
Speaker 3: analisi web e dati CRM possono facilmente raggiungere centinaia di gigabyte.
3:32
Speaker 3: I grandi account con linee di prodotti multiple arrivano spesso
3:34
Speaker 3: nell'ordine dei multiterabyte. Il problema non è solo la capacità
3:37
Speaker 3: di archiviazione. Metodo di modelli di grandi dimensioni mette una
3:39
Speaker 3: dura prova nei limiti di una macchina locale. Le CPU
3:42
Speaker 3: rimangono al 100% per periodi prolungati e persino le GPU
3:45
Speaker 3: di fascia alta restano inattive, mentre i dati arrivano troppo lentamente.
3:50
Speaker 3: L'input output del disco diventa un collo di bottiglia costante,
3:53
Speaker 3: specialmente se i dati risiedono su un drive esterno o
3:56
Speaker 3: di rete. E poi c'è il livello software, quando i
3:59
Speaker 3: file diventano abbastanza grandi. Anche uno strumento versatile come un
4:02
Speaker 3: notebook Jupiter inizia a mostrare i suoi limiti. Non puoi
4:05
Speaker 3: semplicemente caricare un file CSV in memoria se quel file
4:07
Speaker 3: è più grande del tuo SSD. Ecco perché molti team
4:10
Speaker 3: hanno provato a dividere i file, campionare i dati o
4:12
Speaker 3: creare surrogati leggeri per i veri set di dati di produzione.
4:16
Speaker 3: È un compromesso che salva il tuo laptop ma costa
4:18
Speaker 3: di perdere informazioni preziose? campionamento può far perdere pattern sottili
4:22
Speaker 3: che avrebbero migliorato le prestazioni del modello. Dividere i file
4:25
Speaker 3: introduce ogni sorta di incoerenza e rende il riaddestramento più
4:28
Speaker 3: complicato del necessario. Esiste un modo più intelligente per saltare
4:32
Speaker 3: l'intero ciclo di download e importazione. Microsoft Fabrics posta completamente
4:36
Speaker 3: il lavoro pesante fuori dal tuo ambiente locale. L'addestramento si
4:39
Speaker 3: sposta nel cloud dove le risorse di calcolo risiedono accanto
4:42
Speaker 3: ai dati nelle house. Non sposti terabyte avanti e indietro,
4:46
Speaker 3: porti il tuo codice dove i dati risiedono già Invece
4:51
Speaker 3: di preoccuparti di quale porzione dello storico cliente entrerà nella RAM,
4:54
Speaker 3: puoi concentrarti sulla struttura e la logica del training. Ed
4:58
Speaker 3: ecco la parte che la maggior parte dei team trascura.
5:01
Speaker 3: Il vero vantaggio non è solo la maggiore potenza di
5:03
Speaker 3: calcolo del cloud. È il fatto che non devi più
5:06
Speaker 3: spostare affatto i dati. Accesso diretto alle chaos, niente più
5:10
Speaker 3: chaos di file csu. E se il tuo notebook potesse
5:13
Speaker 3: acquisire terabyte di dati istantaneamente, senza mai mostrare una barra
5:16
Speaker 3: di caricamento... Niente esportazioni in CSV, niente più attese che
5:20
Speaker 3: l'icona di caricamento giri sullo schermo. Basta digitare la query,
5:24
Speaker 3: eseguirla e iniziare a lavorare con i risultati direttamente lì.
5:27
Speaker 3: Questa è la differenza quando il data layer non è
5:29
Speaker 3: un passaggio esterno ma è integrato nell'ambiente in cui stai
5:32
Speaker 3: già programmando. In Fabric il lakehouse non è solo un
5:36
Speaker 3: bucket di archiviazione separato a cui ci si connette ogni tanto.
5:40
Speaker 3: È il data layer nativo per i notebook. Ciò significa
5:43
Speaker 3: che il tuo codice viene eseguito nello stesso ambiente in
5:45
Speaker 3: cui risiedono fisicamente i dati. non stai trasferendo milioni di
5:49
Speaker 3: righe attraverso la rete nella tua sessione stai inviando istruzioni
5:52
Speaker 3: e dati nella loro posizione originale la pipeline di input
5:55
Speaker 3: del modello non è un gioco di prestigio trasportazione importazione
5:57
Speaker 3: importazione è la linea diretta dallo storage a Spark fino
6:00
Speaker 3: a qualsiasi logica Python o R tu stia scrivendo se
6:02
Speaker 3: hai lavorato con un flusso di lavoro tradizionale conosci già
6:04
Speaker 3: i soliti punti critici qualcuno crea un estratto dal data
6:07
Speaker 3: warehouse lo scrive in un CSV e lo consegna al
6:10
Speaker 3: team di data science ora lo schema è cristallizzato nel
6:13
Speaker 3: tempo la settimana successiva i dati sorgente cambiano e l'estratto
6:17
Speaker 3: è già obsoleto In alcuni casi ottieni persino due team
6:19
Speaker 3: diversi che creano esportazioni leggermente differenti tra loro. E ora
6:23
Speaker 3: archivi duplicati con definizioni non corrispondenti. Nel migliore dei casi
6:27
Speaker 3: è solo inefficienza. Nel peggiore dei casi è il motivo
6:29
Speaker 3: per cui due modelli avvestrati sugli stessi dati forniscono previsioni contraddittorie.
6:33
Speaker 3: Un team con cui ho lavorato necessitava di un set
6:35
Speaker 3: filtrato di record di attività dei clienti per un nuovo
6:37
Speaker 3: modello di churn. Hanno estratto tutto dal warehouse in un
6:40
Speaker 3: database SQL locale, lo hanno filtrato, poi hanno esportato il
6:43
Speaker 3: risultato in un CSV per l'ambiente di training. Solo questo
6:46
Speaker 3: ha richiesto quasi un'intera giornata sulla loro rete. Quando la
6:49
Speaker 3: settimana successiva sono stati caricati i nuovi record di attività
6:52
Speaker 3: hanno dovuto rifare l'intero processo da zero. Quando hanno potuto
6:55
Speaker 3: iniziare l'addestramento effettivo, avevano passato più tempo a gestire file
6:58
Speaker 3: che a scrivere codice. Il calo di prestazioni non riguarda
7:00
Speaker 3: solo il tempo necessario per i trasferimenti. La ricerca su
7:04
Speaker 3: più aziende mostra guadagni costanti quando le trasformazioni vengono eseguite
7:07
Speaker 3: dove i dati sono archiviati. Quando puoi eseguire join, filtri
7:11
Speaker 3: e aggregazioni in locale invece che a valle, elimini overhead,
7:14
Speaker 3: salti di rete e letture ridondanti e letture ridondanti. I
7:17
Speaker 3: notebook di Fabric sfruttano Spark sotto il cofano per rendere
7:20
Speaker 3: possibile tutto ciò. Quindi, invece di estrarre 400 milioni di
7:23
Speaker 3: righe nella sessione del notebook, Spark esegue quell'aggregazione all'interno dell'ambiente
7:27
Speaker 3: Lakehouse e restituisce solo i risultati necessari al tuo modello.
7:32
Speaker 3: Se lavori in Python, R inoltre non parti da una
7:34
Speaker 3: shell vuota. Fabric viene fornito con una serie di librerie
7:39
Speaker 3: già integrate per il lavoro su larga scala, PySpark, Pandason Spark,
7:42
Speaker 3: Sparkler e altre. Quindi lavorazioni distribuite hanno opzioni disponibili dal
7:47
Speaker 3: momento in cui apri un nuovo notebook. Questo è importante
7:51
Speaker 3: quando si uniscono tabelle di fatti e dimensioni nell'ordine delle
7:53
Speaker 3: centinaia di gigabyte o quando occorre calcolare finestre mobili su
7:56
Speaker 3: diversi anni di cronologia clienti. Non appena la query viene completata,
8:01
Speaker 3: il set di dati aggregati e puliti è pronto per
8:03
Speaker 3: passare direttamente al processo di feature engineering. Non c'è alcuna
8:07
Speaker 3: fase intermedia di salvataggio su disco, verifica dello schema e
8:09
Speaker 3: reimportazione in un notebook di training locale. È saltata un'intera
8:13
Speaker 3: fase di preparazione. Team passavano giorni solo ad allineare colonne
8:16
Speaker 3: ed eseguire nuovamente i filtri quando i dati sorgenti cambiavano.
8:19
Speaker 3: Con questa configurazione possono esplorare combinazioni di feature per il
8:22
Speaker 3: modello entro la stessa ora in cui i dati grezzi
8:24
Speaker 3: sono stati aggiornati. Ed è qui che la cosa si
8:26
Speaker 3: fa interessante perché una volta che set di dati massivi
8:29
Speaker 3: e puliti fluiscono direttamente nella sessione del notebook il modo
8:32
Speaker 3: di pensare alla creazione delle feature inizia a cambiare. feature
8:37
Speaker 3: engineering e selezione del modello su larga scala il tuo
8:39
Speaker 3: set di dati potrebbe essere abbastanza grande da prevedere quasi
8:42
Speaker 3: tutto ma ciò non significa che ogni colonna debba essere
8:44
Speaker 3: inclusa nel tuo modello la differenza tra un modello che
8:47
Speaker 3: produce previsioni significative e uno che genera rumore dipende spesso
8:50
Speaker 3: da come selezioni e definisci le tue feature la scala
8:54
Speaker 3: offre possibilità ma amplifica anche gli errori con set di
8:58
Speaker 3: dati massivi fornire tutti i campi grezzi all'algoritmo non è
9:01
Speaker 3: solo disordinato può compromettere attivamente le prestazioni Più colonne significano
9:06
Speaker 3: più parametri da stimare e maggiore opportunità per il modello
9:10
Speaker 3: di adattarsi a peculiarità dei dati di training che non
9:13
Speaker 3: si generalizzano. L'overfitting diventa più facile e non più difficile
9:17
Speaker 3: quando il set di feature è sovradimensionato. Oltretutto ogni variabile
9:20
Speaker 3: aggiuntiva significa più calcoli. Anche in un ambiente cloud ben
9:24
Speaker 3: equipaggiato 500 feature grezze rallenteranno il training, aumenteranno l'uso di
9:28
Speaker 3: memoria e complicheranno ogni passaggio successivo rispetto a un set
9:31
Speaker 3: snello di 50 feature ben progettate. Il costo nascosto non
9:35
Speaker 3: è sempre evidente dal tempo di esecuzione. Quell'esecuzione con 500
9:37
Speaker 3: feature potrebbe terminare senza errori, ma lasciarti con un modello
9:41
Speaker 3: marginalmente più accurato sui dati di training è notevolmente peggiore
9:44
Speaker 3: sui nuovi dati e... Quando restringi e rifinisci quelle feature,
9:50
Speaker 3: unendo variabili correlate e codificando le categorie in modo più
9:53
Speaker 3: efficiente o creando aggregati che catturano pattern anziché valori grezzi,
9:57
Speaker 3: riduci il tempo di calcolo, migliorando al contrario la capacità
10:01
Speaker 3: predittiva del modello. Alcune strutture di dati rendono tutto ciò
10:05
Speaker 3: più difficile. Le feature ad alta cardinalità, come scaudi, prodotti
10:09
Speaker 3: univoci o ID cliente, possono esplodere in migliaia di colonne
10:13
Speaker 3: codificate se gestite in modo ingenuo. I dati sparsi, dove
10:17
Speaker 3: la maggior parte dei campi è vuota per gran parte
10:19
Speaker 3: dei record, possono nascondere segnali utili ma consumare risorse archiviando
10:23
Speaker 3: ed elaborando valori per lo più mancanti. In ambiti come
10:27
Speaker 3: la previsione dell'abbandono dei clienti potreste avere anche pattern temporali,
10:30
Speaker 3: cicli di acquisto, attività stagionali e fasi di onboarding che
10:34
Speaker 3: non appaiono nei comuni campi statici. L'ingegneria delle feature su
10:39
Speaker 3: questa scala significa progettare trasformazioni che condensano i pattern senza
10:43
Speaker 3: non dare il set di dati con rumore. È qui
10:46
Speaker 3: che gli strumenti di automazione distribuite iniziano a dare i
10:48
Speaker 3: loro frutti. Liberlie come Feature Tools possono automatizzare la generazione
10:52
Speaker 3: di aggregati e feature mobili su grandi set di dati relazionali.
10:56
Speaker 3: In Fabric tali trasformazioni possono essere eseguite su Spark permettendoti
10:59
Speaker 3: di scalare la creazione di centinaia di feature candidate senza
11:02
Speaker 3: caricare tutto nella memoria di una singola macchina. Raggruppamenti basati
11:06
Speaker 3: sul tempo, aggregati a livello di client, rapporti tra metriche correlate,
11:10
Speaker 3: tutto ciò può essere creato e testato iterativamente senza interrompere
11:13
Speaker 3: il flusso di lavoro operativo. Una volta accurato il tuo
11:16
Speaker 3: set di feature, la selezione del modello diventa un esercizio
11:18
Speaker 3: di equilibrio a sé stante. Algoritmi diversi interagiscono con dati
11:21
Speaker 3: su larga scala in modi differenti. I framework di gradient
11:24
Speaker 3: boosting come XGBoost o LightGBM gestiscono i grandi set di
11:27
Speaker 3: dati tabulari in modo efficiente, ma pagano comunque il costo
11:29
Speaker 3: per feature in termini di memoria e tempo di iterazione.
11:33
Speaker 3: La regressione logistica scala bene e si addestra rapidamente, ma
11:36
Speaker 3: non cattura relazioni non lineari complesse a meno che tu
11:39
Speaker 3: non le integri personalmente nelle feature. I modelli di Deep
11:43
Speaker 3: Learning possono in teoria scoprire pattern più ricchi, ma richiedono
11:45
Speaker 3: anche maggiore messa a punto e maggiore potenza di calcolo.
11:48
Speaker 3: Nell'ambiente di Fabric puoi predisporre tutto questo, ma dovrai valutare
11:51
Speaker 3: se i guadagni giustificano il costo dell'addestramento. La buona notizia
11:54
Speaker 3: è che, con i notebook di Fabric direttamente collegati alla
11:56
Speaker 3: tua Lake House, puoi testare queste strategie senza i coli
11:59
Speaker 3: di bottiglia tradizionali. Puoi avviare molteplici sessioni di addestramento con
12:03
Speaker 3: set di feature e algoritmi diversi, usando gli stessi dati
12:06
Speaker 3: sottostanti senza doverli ricaricare o rimodellare per ogni tentativo. Questa
12:11
Speaker 3: capacità di iterare rapidamente significa che non sei vincolato a
12:13
Speaker 3: ipotesi su quale approccio funzioni meglio. Puoi misurare e decidere.
12:17
Speaker 3: Feature ben progettate e abbinate alla giusta architettura di modello
12:20
Speaker 3: possono ridurre significativamente i tempi di esecuzione, diminuire l'uso della
12:23
Speaker 3: memoria e migliorare l'accuratezza su dati non visti. Ottieni cicli
12:27
Speaker 3: di sperimentazione più veloci e risultati più affidabili spendendo il
12:31
Speaker 3: tuo budget di calcolo sull'addestramento che conta davvero invece di
12:34
Speaker 3: elaborare pesi inutili. Segue il passaggio che mantiene produttive queste
12:38
Speaker 3: esecuzioni su larga scala. monitorarle e valutarle in tempo reale
12:42
Speaker 3: per sapere esattamente cosa accade mentre il modello si addestra
12:45
Speaker 3: nel cloud. Addestramento, monitoraggio e valutazione su scala cloud. Addestrare
12:50
Speaker 3: su gigabyte di dati sembra un sogno finché non ti
12:52
Speaker 3: ritrovi a chiederti se il job stia ancora girando o
12:54
Speaker 3: se sia morto silenziosamente un'ora fa. Quando tutto avviene nel
12:59
Speaker 3: cloud perdi il feedback immediato che ottieni osservando i log
13:01
Speaker 3: scorrere in un terminale locale. Va bene se il job
13:04
Speaker 3: termina in pochi minuti. Diventa un problema quando il tempo
13:07
Speaker 3: si dilunga in ore e non hai idea se stai
13:09
Speaker 3: facendo progressi. Eseguire l'addestramento in un ambiente remoto cambia il
13:13
Speaker 3: modo in cui pensi alla visibilità. In una sessione locale
13:16
Speaker 3: identifichi i problemi immediatamente. Valori mancanti in un campo ha
13:19
Speaker 3: mancata corrispondenza del tipo di dati o blocco dell'importazione. Su
13:23
Speaker 3: un cluster cloud lo stesso errore potrebbe essere sepolto in
13:26
Speaker 3: un file di log che non controlli fino a molto
13:28
Speaker 3: tempo dopo. E poiché le risorse vengono approvisionate e create
13:32
Speaker 3: mentre il processo è tecnicamente in esecuzione, ogni minuto di
13:34
Speaker 3: un'esecuzione fallita è comunque denaro speso. Il costo di scoprire
13:38
Speaker 3: un problema troppo tardi aumenta rapidamente. Ho visto un lavoro
13:41
Speaker 3: di previsione del tasso di abbandono, avviato un venerdì sera
13:43
Speaker 3: con una stima di otto ore. Lunedì mattina il team
13:47
Speaker 3: si è reso conto che era fallito prima ancora, che
13:49
Speaker 3: iniziasse la prima epoca perché una colonna che avrebbe dovuto
13:51
Speaker 3: essere numerica è stata caricata come testo. Il tempo di
13:54
Speaker 3: seguizione è effettivo. Dieci minuti sprecati all'inizio, otto ore fatturate
13:57
Speaker 3: sul contatore. È il tipo di errore che erode la
14:00
Speaker 3: fiducia nel processo e rallenta i cicli di iterazione fino
14:02
Speaker 3: a fermarli. Fabric affronta questo problema con il monitoraggio dei
14:06
Speaker 3: lavori in tempo reale che puoi aprire accanto al tuo notebook.
14:10
Speaker 3: Ottieni metriche in tempo reale sul consumo di memoria, sull'utilizzo
14:13
Speaker 3: della CPU e sull'avanzamento delle epoche di addestramento. I log
14:18
Speaker 3: vengono trasmessi man mano che il lavoro viene eseguito, così
14:20
Speaker 3: puoi individuare avvisi o errori prima che si trasformino in
14:23
Speaker 3: guasti totali. Se qualcosa sembra non andare, puoi interrompere l'esecuzione
14:27
Speaker 3: subito invece di scoprire il problema a tue spese in seguito.
14:29
Speaker 3: Non si tratta solo di guardare, però. Puoi impostare dei
14:32
Speaker 3: checkpoint durante l'addestramento in modo che lo stato del modello
14:33
Speaker 3: venga salvato periodicamente. Se il lavoro si interrompe a causa
14:37
Speaker 3: di un errore, di un limite di risorse o di
14:39
Speaker 3: un'interruzione intenzionale, puoi ripartire dall'ultimo checkpoint invece di ricominciare da zero.
14:44
Speaker 3: Anche il versionamento gioca un ruolo qui. Salvando le versioni
14:47
Speaker 3: dei modelli addestrati con i loro parametri e le relative
14:49
Speaker 3: suddivisioni dei dati, puoi rivedere una configurazione passata senza dover
14:53
Speaker 3: ricreare l'intero ambiente che l'ha prodotta. I salvataggi intermedi non
14:57
Speaker 3: sono solo una buona salvaguardia, sono ciò che rende fattibile
15:00
Speaker 3: la sperimentazione su larga scala. Puoi diramarti da un checkpoint
15:04
Speaker 3: promettente e provare diversi iperparametri senza pagare il costo in
15:07
Speaker 3: termini di tempo del ricaricamento e del riaddestramento del modello base.
15:11
Speaker 3: Con set di dati di diversi gigabyte, questo può fare
15:13
Speaker 3: la differenza tra eseguire tre esperimenti in un giorno o
15:15
Speaker 3: uno solo. Una volta che il modello ha terminato, la
15:17
Speaker 3: valutazione su questa scala comporta le sue sfide specifiche. Non
15:21
Speaker 3: sempre è possibile effettuare lo scoring rispetto all'intero test set
15:23
Speaker 3: in un unico passaggio senza rallentare tutto drasticamente. Il campionamento
15:27
Speaker 3: bilanciato aiuta in questo, mantenendo le proporzioni delle classi riducendo
15:30
Speaker 3: al contempo il set di dati a una dimensione che
15:31
Speaker 3: si valuta più velocemente. Per una maggiore precisione, la valutazione
15:34
Speaker 3: distribuita ti permette di dividere il compito di scoring tra
15:36
Speaker 3: i cluster con i risultati aggregati automaticamente. Fabric supporta librerie
15:42
Speaker 3: Python come MLib e flussi di lavoro Shekit Learn distribuiti
15:45
Speaker 3: per renderlo possibile. Invece di aspettare che una singola macchina
15:49
Speaker 3: elabori le metriche su centinaia di milioni di record, puoi
15:52
Speaker 3: distribuire il compito e recuperare i punteggi consolidati di accuratezza, precisione,
15:55
Speaker 3: recollo o F1 in una frazione del tempo. Dati non
15:59
Speaker 3: lasciano mai le cause, quindi non devi occuparti di esportazioni
16:01
Speaker 3: di set di testo, unitesto o unioni manuali.