In breve: la preelaborazione per l'IA è un insieme di passaggi ripetibili che trasformano dati grezzi e ad alta varianza in input coerenti per il modello, tra cui pulizia, codifica, ridimensionamento, tokenizzazione e trasformazioni delle immagini. È importante perché se gli input di addestramento e gli input di produzione differiscono, i modelli possono fallire silenziosamente. Se un passaggio "apprende" parametri, è consigliabile utilizzarlo solo sui dati di addestramento per evitare fughe di informazioni.
La pre-elaborazione dell'intelligenza artificiale è tutto ciò che si fa sui dati grezzi prima (e talvolta durante) l'addestramento o l'inferenza, in modo che un modello possa effettivamente imparare da essi. Non si tratta solo di "pulizia". Si tratta di pulire, modellare, ridimensionare, codificare, aumentare e confezionare i dati in una rappresentazione coerente che non comprometterà silenziosamente il modello in seguito. [1]
Punti chiave:
Definizione: la pre-elaborazione converte tabelle, testo, immagini e registri non elaborati in funzionalità pronte per il modello.
Coerenza: applicare le stesse trasformazioni durante l'addestramento e l'inferenza per evitare errori di mancata corrispondenza.
Perdita: adattare scaler, encoder e tokenizzatori solo ai dati di addestramento.
Riproducibilità: creare pipeline con statistiche ispezionabili, non sequenze cellulari di notebook ad hoc.
Monitoraggio della produzione: tenere traccia delle deviazioni e delle derive in modo che gli input non compromettano gradualmente le prestazioni.
Articoli che potrebbero interessarti dopo questo:
🔗 Come testare i modelli di intelligenza artificiale per le prestazioni nel mondo reale
Metodi pratici per valutare rapidamente accuratezza, robustezza e distorsione.
🔗 L'intelligenza artificiale text-to-speech è e come funziona?
Spiega i principi fondamentali della sintesi vocale, i suoi utilizzi principali e le limitazioni più comuni oggi.
🔗 L'intelligenza artificiale può leggere la scrittura corsiva in modo accurato oggi?
Tratta le sfide del riconoscimento, gli strumenti migliori e i suggerimenti sulla precisione.
🔗 Quanto è accurata l'intelligenza artificiale nelle attività comuni?
Analizza i fattori di accuratezza, i parametri di riferimento e l'affidabilità nel mondo reale.
Pre-elaborazione dell'IA in linguaggio semplice (e cosa non è) 🤝
La pre-elaborazione dell'IA è la trasformazione di input grezzi (tabelle, testo, immagini, log) in funzionalità pronte per il modello. Se i dati grezzi sono un garage disordinato, la pre-elaborazione è etichettare le scatole, buttare via i rottami e impilare gli oggetti in modo da poterli effettivamente attraversare senza farsi male.
Non è il modello in sé, ma ciò che lo rende possibile:
-
trasformare le categorie in numeri (one-hot, ordinali, ecc.) [1]
-
ridimensionamento di grandi intervalli numerici in intervalli sani (standardizzazione, min-max, ecc.) [1]
-
tokenizzazione del testo in ID di input (e solitamente una maschera di attenzione) [3]
-
ridimensionamento/ritaglio delle immagini e applicazione appropriata di trasformazioni deterministiche rispetto a quelle casuali [4]
-
costruire pipeline ripetibili in modo che la formazione e gli input della “vita reale” non divergano in modi sottili [2]
Una piccola nota pratica: la "pre-elaborazione" comprende tutto ciò che avviene sistematicamente prima che il modello veda l'input. Alcuni team distinguono questa fase in "ingegneria delle caratteristiche" e "pulizia dei dati", ma nella pratica questi confini si confondono.
Perché la pre-elaborazione dell'intelligenza artificiale è più importante di quanto la gente ammetta 😬
Un modello è un comparatore di schemi, non un lettore del pensiero. Se i tuoi input sono incoerenti, il modello apprende regole incoerenti. Non è filosofico, è dolorosamente letterale.
La pre-elaborazione ti aiuta a:
-
Migliorare la stabilità dell'apprendimento inserendo le caratteristiche in rappresentazioni che gli stimatori possono utilizzare in modo affidabile (soprattutto quando è coinvolto il ridimensionamento/la codifica). [1]
-
Ridurre il rumore facendo sembrare la realtà disordinata qualcosa da cui un modello può generalizzare (invece di memorizzare strani artefatti).
-
Prevenire le modalità di errore silenziose come perdite e discrepanze tra training e servizio (quelle che sembrano "fantastiche" in fase di validazione e poi falliscono miseramente in produzione). [2]
-
Accelera l'iterazione perché le trasformazioni ripetibili sono più efficaci degli spaghetti del notebook ogni giorno della settimana.
Inoltre, è da lì che deriva gran parte delle "prestazioni modello". Tipo... sorprendentemente tante. A volte sembra ingiusto, ma è la realtà 🙃
Cosa rende una buona pipeline di pre-elaborazione dell'IA ✅
Una “buona versione” di pre-elaborazione solitamente presenta queste qualità:
-
Riproducibile: stesso input → stesso output (nessuna casualità misteriosa a meno che non si tratti di un'aggiunta intenzionale).
-
Coerenza del servizio di formazione: tutto ciò che fai al momento della formazione viene applicato allo stesso modo al momento dell'inferenza (stessi parametri adattati, stesse mappe di categoria, stessa configurazione del tokenizzatore, ecc.). [2]
-
A prova di perdite: nulla nella valutazione/test influenza alcuna
di adattamento. (Maggiori informazioni su questa trappola tra poco.) [2] -
Osservabile: è possibile ispezionare cosa è cambiato (statistiche delle funzionalità, elementi mancanti, conteggi delle categorie), quindi il debug non si basa su sensazioni.
Se la tua preelaborazione è un ammasso di celle di notebook chiamato final_v7_really_final_ok... sai com'è. Funziona finché non smette di funzionare 😬
Elementi fondamentali della pre-elaborazione dell'IA 🧱
Pensa alla pre-elaborazione come a un insieme di elementi costitutivi che si combinano in una pipeline.
1) Pulizia e convalida 🧼
Attività tipiche:
-
rimuovere i duplicati
-
gestire i valori mancanti (eliminare, imputare o rappresentare esplicitamente i valori mancanti)
-
applicare tipi, unità e intervalli
-
rilevare input malformati
-
standardizzare i formati di testo (spazi vuoti, regole di maiuscole e minuscole, stranezze Unicode)
Questa parte non è glamour, ma previene errori estremamente stupidi. Lo dico con affetto.
2) Codifica dei dati categoriali 🔤
La maggior parte dei modelli non può utilizzare direttamente stringhe non elaborate come "red" o "premium_user".
Approcci comuni:
-
Codifica one-hot (categoria → colonne binarie) [1]
-
Codifica ordinale (categoria → ID intero) [1]
La cosa fondamentale non è quale codificatore si sceglie, ma che la mappatura rimanga coerente e non "cambi forma" tra l'addestramento e l'inferenza. È così che si ottiene un modello che sembra a posto offline e si comporta in modo strano online. [2]
3) Ridimensionamento e normalizzazione delle funzionalità 📏
La scalabilità è importante quando le caratteristiche si trovano su intervalli molto diversi.
Due classici:
-
Standardizzazione: rimuovere la media e ridimensionare la varianza alla varianza unitaria [1]
-
Scala min-max: ridimensiona ogni caratteristica in un intervallo specificato [1]
Anche quando si utilizzano modelli che "per lo più riescono a farcela", la scalabilità spesso rende le pipeline più facili da gestire e più difficili da interrompere accidentalmente.
4) Feature engineering (ovvero imbrogli utili) 🧪
È qui che si semplifica il lavoro del modello creando segnali migliori:
-
rapporti (clic/impressioni)
-
finestrini scorrevoli (ultimi N giorni)
-
conteggi (eventi per utente)
-
trasformazioni logaritmiche per distribuzioni a coda pesante
C'è un'arte in questo. A volte crei una funzionalità, ne sei orgoglioso... e non succede nulla. O peggio, ti fa male. È normale. Non affezionarti emotivamente alle funzionalità: non ti ricambiano 😅
5) Dividere i dati nel modo giusto ✂️
Sembra ovvio, finché non lo è più:
-
suddivisioni casuali per dati IID
-
suddivisioni basate sul tempo per serie temporali
-
suddivisioni raggruppate quando le entità si ripetono (utenti, dispositivi, pazienti)
E soprattutto: dividi prima di adattare la preelaborazione che impara dai dati. Se la tua fase di preelaborazione "apprende" parametri (come medie, vocabolari, mappe di categorie), deve apprenderli solo dall'addestramento. [2]
Pre-elaborazione AI per tipo di dati: tabellare, testo, immagini 🎛️
La pre-elaborazione cambia forma a seconda di ciò che si fornisce al modello.
Dati tabulari (fogli di calcolo, registri, database) 📊
Passaggi comuni:
-
strategia del valore mancante
-
codifica categoriale [1]
-
scalatura delle colonne numeriche [1]
-
gestione dei valori anomali (le regole di dominio battono il "clipping casuale" la maggior parte delle volte)
-
caratteristiche derivate (aggregazioni, ritardi, statistiche mobili)
Consiglio pratico: definisci esplicitamente i gruppi di colonne (numerici, categorici, identificatori). Il tuo io futuro ti ringrazierà.
Dati di testo (NLP) 📝
La preelaborazione del testo spesso include:
-
tokenizzazione in token/sottoparole
-
conversione in ID di input
-
riempimento/troncamento
-
creazione di maschere di attenzione per il batching [3]
Piccola regola che evita problemi: per le configurazioni basate su transformer, segui le impostazioni previste del tokenizer del modello e non fare freestyle a meno che tu non abbia un motivo valido. Il freestyle è il modo in cui ti ritrovi con "si allena ma è strano"
Immagini (visione artificiale) 🖼️
Pre-elaborazione tipica:
-
ridimensionare/ritagliare in forme coerenti
-
trasformazioni deterministiche per la valutazione
-
trasformazioni casuali per l'aumento dell'addestramento (ad esempio, ritaglio casuale) [4]
Un dettaglio che la gente trascura: le "trasformazioni casuali" non sono solo un'atmosfera: campionano letteralmente i parametri ogni volta che vengono chiamate. Ottime per addestrare la diversità, pessime per la valutazione se ci si dimentica di disattivare la casualità. [4]
La trappola in cui cadono tutti: la fuga di dati 🕳️🐍
La perdita di informazioni si verifica quando le informazioni provenienti dai dati di valutazione si insinuano nel training, spesso tramite la pre-elaborazione. Può far sembrare il modello magico durante la convalida, per poi deludere nel mondo reale.
Modelli di perdite comuni:
-
ridimensionamento utilizzando statistiche di set di dati completi (invece della sola formazione) [2]
-
mappe di categoria di costruzione utilizzando insieme train+test [2]
-
qualsiasi
fit()ofit_transform()che “vede” il set di test [2]
Regola pratica (semplice, brutale, efficace):
-
Tutto ciò che ha un adatto dovrebbe essere adatto solo all'allenamento.
-
Quindi trasformi la convalida/il test utilizzando quel trasformatore montato. [2]
E se volete una prova di "quanto può essere grave?", la documentazione stessa di scikit-learn mostra un esempio di leak in cui un ordine di preelaborazione errato produce un'accuratezza intorno allo 0,76 su target casuali, per poi scendere a circa lo0,5 una volta corretto il leak. Ecco quanto può sembrare convincentemente errato un leak. [2]
Come portare la pre-elaborazione in produzione senza caos 🏗️
Molti modelli falliscono in produzione non perché il modello sia "cattivo", ma perché la realtà dei dati di input cambia, oppure cambia la pipeline.
La pre-elaborazione orientata alla produzione solitamente include:
-
Artefatti salvati (mappature dell'encoder, parametri dello scaler, configurazione del tokenizer) in modo che l'inferenza utilizzi esattamente le stesse trasformazioni apprese [2]
-
Contratti di input rigorosi (colonne/tipi/intervalli previsti)
-
Monitoraggio per skew e drift, perché i dati di produzione potrebbero variare [5]
Se vuoi definizioni concrete: Vertex AI Model Monitoring di Google distingue tra training-serving skew (la distribuzione della produzione si discosta da quella di training) e inference drift (la distribuzione della produzione cambia nel tempo) e supporta il monitoraggio sia per le caratteristiche categoriche che numeriche. [5]
Perché le sorprese costano. E non sono divertenti.
Tabella comparativa: strumenti comuni di pre-elaborazione e monitoraggio (e a chi sono destinati) 🧰
| Strumento / libreria | Ideale per | Prezzo | Perché funziona (e un pizzico di onestà) |
|---|---|---|---|
| pre-elaborazione scikit-learn | Pipeline ML tabulari | Gratuito | Codificatori + scaler solidi (OneHotEncoder, StandardScaler, ecc.) e comportamento prevedibile [1] |
| Tokenizzatori Hugging Face | Preparazione all'input NLP | Gratuito | Produce ID di input + maschere di attenzione in modo coerente tra esecuzioni/modelli [3] |
| Torchvision trasforma | La visione si trasforma + aumenta | Gratuito | Un modo pulito per combinare trasformazioni deterministiche e casuali in un'unica pipeline [4] |
| Monitoraggio del modello Vertex AI | Rilevamento di deriva/inclinazione in produzione | A pagamento (cloud) | I monitor sono dotati di skew/drift e di avvisi quando vengono superate le soglie [5] |
(Sì, la tabella contiene ancora delle opinioni. Ma almeno sono opinioni oneste 😅)
Una pratica checklist di pre-elaborazione che puoi effettivamente utilizzare 📌
Prima dell'allenamento
-
Definire uno schema di input (tipi, unità, intervalli consentiti)
-
Controlla i valori mancanti e i duplicati
-
Suddividere i dati nel modo giusto (casuale / in base al tempo / raggruppati)
-
Adatta la preelaborazione solo all'addestramento (
fit/fit_transformrimane sull'addestramento) [2] -
Salvare gli artefatti di pre-elaborazione in modo che l'inferenza possa riutilizzarli [2]
Durante l'allenamento
-
Applicare l'aumento casuale solo dove appropriato (solitamente solo suddivisione dell'allenamento) [4]
-
Mantenere la pre-elaborazione della valutazione deterministica [4]
-
Tieni traccia delle modifiche di pre-elaborazione come le modifiche al modello (perché lo sono)
Prima della distribuzione
-
Assicurarsi che l'inferenza utilizzi lo stesso percorso di pre-elaborazione e gli stessi artefatti [2]
-
Impostare il monitoraggio della deriva/distorsione (anche i controlli di distribuzione delle caratteristiche di base sono molto utili) [5]
Approfondimento: errori comuni di pre-elaborazione (e come evitarli) 🧯
Errore 1: "Normalizzerò tutto velocemente" 😵
Se calcoli i parametri di ridimensionamento sull'intero set di dati, stai perdendo informazioni di valutazione. Adatta il training, trasforma il resto. [2]
Errore 2: le categorie scivolano nel caos 🧩
Se la mappatura delle categorie si sposta tra addestramento e inferenza, il modello può interpretare male il mondo in modo silenzioso. Mantieni le mappature fisse tramite artefatti salvati. [2]
Errore 3: aumento casuale che si insinua nella valutazione 🎲
Le trasformazioni casuali sono fantastiche durante l'allenamento, ma non dovrebbero essere "segretamente attive" quando si cerca di misurare le prestazioni. (Casuale significa casuale.) [4]
Osservazioni finali 🧠✨
La pre-elaborazione dell'IA è l'arte disciplinata di trasformare la realtà caotica in input di modelli coerenti. Comprende la pulizia, la codifica, il ridimensionamento, la tokenizzazione, la trasformazione delle immagini e, soprattutto, pipeline e artefatti ripetibili.
-
Eseguire la pre-elaborazione deliberatamente, non casualmente. [2]
-
Dividi prima, adatta le trasformazioni solo durante l'allenamento, evita le perdite. [2]
-
Utilizzare una pre-elaborazione appropriata alla modalità (tokenizzatori per il testo, trasformazioni per le immagini). [3][4]
-
Monitora la distorsione/deriva della produzione in modo che il tuo modello non si trasformi lentamente in un nonsenso. [5]
E se mai doveste trovarvi in difficoltà, chiedetevi:
"Questo passaggio di pre-elaborazione avrebbe ancora senso se lo eseguissi domani su dati completamente nuovi?"
Se la risposta è "uhm... forse?", ecco il vostro indizio 😬
Esempio pratico: creazione di una pipeline di pre-elaborazione a prova di perdite per la previsione dell'abbandono dei clienti
Scenario
Immaginate un piccolo team SaaS che cerca di prevedere quali clienti probabilmente disdiranno l'abbonamento nei prossimi 30 giorni. I loro dati grezzi si trovano in tre fonti: esportazioni di fatturazione, registri di utilizzo del prodotto e ticket di assistenza.
La prima versione del modello appare eccellente in fase di validazione, ma ha prestazioni scadenti quando viene testata su un nuovo mese di clienti. Il problema non risiede nell'architettura del modello, bensì nella fase di pre-elaborazione.
Il team ha accidentalmente scalato le caratteristiche numeriche utilizzando l'intero set di dati, ha creato mappature di categorie dai dati di training e di test insieme e ha incluso tag di ticket di supporto che sono stati aggiunti solo dopo la cancellazione. Una classica perdita di informazioni. Dolorosa, ma risolvibile. [2]
Di cosa ha bisogno l'oleodotto
Una configurazione pratica includerebbe:
-
Schema di input fisso: customer_id, plan_type, account_age_days, logins_30d, tickets_30d, last_payment_status, region
-
Una suddivisione temporale, come ad esempio l'allenamento da gennaio a settembre e i test a ottobre
-
La scalatura numerica è stata applicata solo al gruppo di addestramento
-
Codificatori categoriali installati solo sul set di addestramento
-
Una pipeline di preelaborazione salvata in modo che la produzione utilizzi le stesse mappature e gli stessi valori di scala
-
Monitoraggio di base per colonne mancanti, categorie non visualizzate e modifiche alla distribuzione dopo l'implementazione
La regola fondamentale è semplice: prima si divide, poi si adatta la preelaborazione. Tutto ciò che apprende dai dati dovrebbe apprendere solo dal periodo di addestramento. [2]
Esempio di istruzione
Utilizzate questo documento come brief di lavoro per la fase di preelaborazione:
Crea una pipeline di pre-elaborazione per un modello di previsione dell'abbandono utilizzando i dati di fatturazione, utilizzo e assistenza clienti. Suddividi i dati in base al tempo prima di applicare qualsiasi trasformatore. Applica gli scaler numerici e gli encoder categoriali solo ai dati di training, quindi applica le trasformazioni così ottenute ai dati di validazione e di test. Salva tutti gli artefatti di pre-elaborazione in modo che il modello di produzione utilizzi lo stesso schema, le stesse mappature delle categorie e gli stessi parametri di scalatura. Segnala colonne mancanti, tipi di dati imprevisti, categorie non viste e significative variazioni nella distribuzione prima della previsione.
Come testarlo
Prima di fidarti del modello, testa la pipeline di preelaborazione con alcuni record volutamente complessi:
-
Un cliente con un piano tariffario non previsto nella formazione
-
Una riga con regione o stato dell'ultimo pagamento mancanti
-
Un cliente con un utilizzo insolitamente elevato, ad esempio 10.000 accessi in 30 giorni
-
Un file di produzione con le colonne nell'ordine sbagliato
-
Un set di prova per il mese futuro che non è mai stato utilizzato durante l'adattamento
Quindi controlla tre cose:
-
La pipeline viene eseguita senza modificare l'ordine delle funzionalità?
-
Le categorie sconosciute vengono gestite in modo coerente?
-
Le prestazioni di validazione si riducono a un livello più credibile dopo l'eliminazione delle fughe di dati?
Quest'ultimo punto è importante. Un punteggio di validazione sospettosamente alto è spesso indice di un problema di pre-elaborazione, non di un miracolo.
Risultato
Risultato illustrativo, basato sulla misurazione dei tempi di cinque esecuzioni di preelaborazione di esempio prima e dopo la conversione dei passaggi del notebook in una pipeline salvata:
-
Il tempo di preelaborazione manuale è stato ridotto da 55 minuti per ogni aggiornamento del set di dati a 8 minuti.
-
Gli errori di ordine delle funzionalità sono diminuiti da 3 errori in 5 aggiornamenti del test a 0 errori in 5 aggiornamenti.
-
L'accuratezza della validazione è diminuita dal 91% al 74% dopo l'eliminazione delle perdite, ma l'accuratezza del test del mese successivo è migliorata dal 62% al 71%.
-
Il team ha aggiunto 6 controlli automatici: colonne mancanti, tipi non validi, categorie non viste, variazione del tasso di valori nulli, variazione dell'intervallo numerico e mancata corrispondenza dello schema di erogazione dei dati di addestramento.
Questi numeri non rappresentano un parametro di riferimento universale. Si tratta di semplici misurazioni "prima e dopo" che un team può riprodurre cronometrando gli aggiornamenti, contando le esecuzioni fallite e confrontando i risultati della convalida con quelli di un mese futuro non utilizzato per i test.
Cosa può andare storto?
Il rischio maggiore è quello di dare un'apparenza di pulizia al processo, preservando al contempo, in modo subdolo, le informazioni riservate. Ad esempio, il dato relativo al numero di giorni trascorsi dall'ultima email di avviso di cancellazione potrebbe sembrare utile, ma se tale email viene inviata solo dopo un'analisi interna del tasso di abbandono, potrebbe rivelare informazioni preziose per il futuro.
Altre trappole comuni:
-
Riconfigurare gli encoder in produzione anziché caricare le mappature salvate
-
Lasciare che le nuove categorie spostino silenziosamente le posizioni delle funzionalità
-
Eseguire test su una suddivisione casuale quando il compito reale è basato sul tempo
-
Eliminare le righe con valori mancanti durante l'addestramento, ma non gestirle durante l'inferenza
-
Monitoraggio dell'accuratezza del modello ignorando la deriva dell'input
Da portare via in modo pratico
Una buona pipeline di pre-elaborazione fa molto di più che semplicemente sistemare i dati grezzi. Protegge il modello da valutazioni errate, input di produzione corrotti e derive lente e silenziose. Per un modello di previsione del tasso di abbandono dei clienti, la differenza tra una pre-elaborazione intelligente e una pre-elaborazione affidabile spesso si riduce al riutilizzo delle stesse trasformazioni applicate, soprattutto quando i dati provengono da un mese che il modello non ha mai visto prima.
Domande frequenti
Cos'è la pre-elaborazione dell'IA, in parole semplici?
La pre-elaborazione dell'IA è un insieme ripetibile di passaggi che trasforma dati grezzi rumorosi e ad alta varianza in input coerenti da cui un modello può apprendere. Può includere la pulizia, la convalida, la codifica di categorie, il ridimensionamento di valori numerici, la tokenizzazione del testo e l'applicazione di trasformazioni di immagini. L'obiettivo è garantire che l'inferenza di addestramento e produzione veda lo "stesso tipo" di input, in modo che il modello non si sposti in un comportamento imprevedibile in seguito.
Perché la pre-elaborazione dell'intelligenza artificiale è così importante nella produzione?
La pre-elaborazione è importante perché i modelli sono sensibili alla rappresentazione dell'input. Se i dati di training vengono ridimensionati, codificati, tokenizzati o trasformati in modo diverso rispetto ai dati di produzione, si possono verificare errori di mancata corrispondenza tra training e servizio che sembrano corretti offline, ma che online falliscono silenziosamente. Pipeline di pre-elaborazione efficaci riducono anche il rumore, migliorano la stabilità dell'apprendimento e accelerano l'iterazione, perché non si districa il caos generato dai notebook.
Come posso evitare la perdita di dati durante la pre-elaborazione?
Una regola semplice funziona: qualsiasi processo che preveda una di addestramento deve essere eseguito esclusivamente sui dati di training. Questo include scaler, encoder e tokenizer che apprendono parametri come medie, mappe di categorie o vocabolari. Prima si effettua la suddivisione, si esegue l'addestramento sui dati di training e poi si trasforma la validazione/il test utilizzando il trasformatore addestrato. La perdita di informazioni può far sembrare la validazione "magicamente" buona, per poi fallire miseramente in produzione.
Quali sono i passaggi di pre-elaborazione più comuni per i dati tabulari?
Per i dati tabulari, la pipeline standard include pulizia e convalida (tipi, intervalli, valori mancanti), codifica categoriale (one-hot o ordinale) e ridimensionamento numerico (standardizzazione o min-max). Molte pipeline aggiungono funzionalità di feature engineering basate sul dominio, come rapporti, finestre mobili o conteggi. Un'abitudine pratica è quella di definire esplicitamente i gruppi di colonne (numerici, categorici o identificatori) in modo che le trasformazioni rimangano coerenti.
Come funziona la pre-elaborazione per i modelli di testo?
La pre-elaborazione del testo in genere implica la tokenizzazione in token/sottoparole, la loro conversione in ID di input e la gestione del padding/troncamento per l'elaborazione in batch. Molti flussi di lavoro dei trasformatori creano anche una maschera di attenzione insieme agli ID. Un approccio comune consiste nell'utilizzare la configurazione prevista del tokenizzatore del modello anziché improvvisare, poiché piccole differenze nelle impostazioni del tokenizzatore possono portare a risultati del tipo "si addestra ma si comporta in modo imprevedibile".
Cosa c'è di diverso nella pre-elaborazione delle immagini per l'apprendimento automatico?
La pre-elaborazione delle immagini solitamente garantisce forme e gestione dei pixel coerenti: ridimensionamento/ritaglio, normalizzazione e una netta separazione tra trasformazioni deterministiche e casuali. Per la valutazione, le trasformazioni dovrebbero essere deterministiche in modo che le metriche siano confrontabili. Per l'addestramento, l'aumento casuale (come i ritagli casuali) può migliorare la robustezza, ma la casualità deve essere intenzionalmente limitata alla suddivisione dell'addestramento, non lasciata accidentalmente attiva durante la valutazione.
Cosa rende una pipeline di pre-elaborazione "buona" anziché fragile?
Una buona pipeline di pre-elaborazione AI è riproducibile, a prova di perdite e osservabile. Riproducibile significa che lo stesso input produce lo stesso output, a meno che la casualità non sia un aumento intenzionale. A prova di perdite significa che le fasi di adattamento non interferiscono mai con la convalida/il test. Osservabile significa che è possibile ispezionare statistiche come elementi mancanti, conteggi di categorie e distribuzioni di feature, in modo che il debug sia basato sull'evidenza, non sull'istinto. Le pipeline superano sempre le sequenze di notebook ad hoc.
Come posso mantenere coerenti la pre-elaborazione dell'addestramento e dell'inferenza?
La chiave è riutilizzare esattamente gli stessi artefatti appresi al momento dell'inferenza: parametri dello scaler, mappature dell'encoder e configurazioni del tokenizzatore. È inoltre necessario un contratto di input (colonne, tipi e intervalli previsti) in modo che i dati di produzione non possano assumere silenziosamente forme non valide. La coerenza non significa semplicemente "eseguire gli stessi passaggi", ma "eseguire gli stessi passaggi con gli stessi parametri e mappature adattati"
Come posso monitorare i problemi di pre-elaborazione, come deriva e inclinazione, nel tempo?
Anche con una pipeline solida, i dati di produzione cambiano. Un approccio comune consiste nel monitorare le variazioni nella distribuzione delle feature e nell'emettere avvisi in caso di skew tra training e serving (la produzione si discosta dal training) e drift di inferenza (le variazioni della produzione nel tempo). Il monitoraggio può essere leggero (controlli di distribuzione di base) o gestito (come Vertex AI Model Monitoring). L'obiettivo è individuare tempestivamente le variazioni di input, prima che compromettano lentamente le prestazioni del modello.
Riferimenti
[1] API di scikit-learn: sklearn.preprocessing (encoder, scaler, normalizzazione)
[2] scikit-learn: Insidie comuni - Perdita di dati e come evitarla
[3] Documentazione di Hugging Face Transformers: Tokenizer (ID di input, maschere di attenzione)
[4] Documentazione di PyTorch Torchvision: Trasformazioni (Ridimensionamento/Normalizzazione + trasformazioni casuali)
[5] Documentazione di Google Cloud Vertex AI: Panoramica del monitoraggio del modello (skew e drift delle caratteristiche)