Progettare i dati di training per i carichi di lavoro di intelligenza artificiale in Azure
Quando si progettano dati per la funzionalità di intelligenza artificiale nelle applicazioni, considerare sia i requisiti non funzionali, ad esempio l'operabilità, i costi e la sicurezza, sia i requisiti funzionali correlati all'inserimento, alla preparazione e alla convalida dei dati.
La progettazione dei dati e la progettazione di applicazioni non possono essere disaccoppiate. La progettazione dell'applicazione richiede la comprensione dei casi d'uso, dei modelli di query e dei requisiti di aggiornamento. Per soddisfare i requisiti aziendali che determinano la necessità di usare l'intelligenza artificiale, l'applicazione potrebbe richiedere output da modelli discriminanti, modelli generativi o una combinazione di tipi di modello.
Per ottenere risultati significativi, è necessario eseguire il training dei modelli di intelligenza artificiale. Il training del modello prevede l'insegnamento di un modello per classificare o prevedere situazioni nuove o non visibile. I dati di training devono essere personalizzati in base al contesto specifico del problema e del carico di lavoro.
Il training supervisionato implica la fornitura del modello con esempi etichettati. Questo tipo di training è utile quando il risultato desiderato è chiaro. Al contrario, l'apprendimento non supervisionato consente al modello di identificare modelli e relazioni all'interno dei dati senza indicazioni sull'output previsto. Durante il training, il tipo di algoritmo e i relativi parametri vengono modificati per controllare le modalità di apprendimento del modello. L'approccio varia a seconda del tipo di modello, che può includere reti neurali, alberi delle decisioni e altri.
Ad esempio, i modelli di rilevamento delle immagini vengono in genere sottoposti a training su attività come il rilevamento degli oggetti, il riconoscimento facciale o la comprensione della scena. Imparano da immagini annotate per identificare oggetti o funzionalità specifici. Altri esempi comuni includono algoritmi di rilevamento delle frodi e modelli di stima dei punti di prezzo. Questi modelli imparano dai dati finanziari cronologici per prendere decisioni informate.
Questo articolo è incentrato principalmente sul caso d'uso precedente, in cui viene eseguito il training dei modelli prima di poter fornire input significativo all'applicazione. L'articolo include indicazioni sulla raccolta, l'elaborazione, l'archiviazione, il test e la manutenzione dei dati. La progettazione dei dati per data science esplorativo o business intelligence tramite intelligenza artificiale non è coperta. L'obiettivo è supportare le esigenze di training tramite strategie allineate ai requisiti del carico di lavoro fornendo raccomandazioni sulla pipeline di dati di training di un carico di lavoro di intelligenza artificiale.
Per informazioni sulla progettazione dei dati per i modelli di intelligenza artificiale che richiedono contesto durante l'inferenza , vedere Progettazione dei dati di base.
Importante
Si prevede che la progettazione dei dati sia un processo iterativo basato sulla sperimentazione statistica. Per raggiungere un livello di qualità accettabile, regolare i dati di training, l'elaborazione, lo sviluppo delle funzionalità del modello e gli iperparametri del modello (quando possibile). Questo ciclo di sperimentazione si verifica in genere sia durante il training del modello iniziale che durante gli sforzi di perfezionamento continui per risolvere la deriva dei dati e del modello nel corso della durata della funzionalità nel carico di lavoro.
Consigli
Ecco il riepilogo delle raccomandazioni fornite in questo articolo.
| Suggerimento | Descrizione |
|---|---|
| Selezionare le origini dati in base ai requisiti del carico di lavoro. | Considerare le risorse disponibili e se l'origine dati può aiutare a raggiungere la qualità dei dati accettabile per il training del modello. Vengono illustrati sia esempi positivi che negativi. Combinare tipi di dati diversi per ottenere un livello di completezza adeguato per l'analisi e la modellazione. Si considerino tecniche come la tecnica di sovracampionamento delle minoranze sintetiche (SMOTE) per la scarsità o lo squilibrio dei dati. ▪ Inserimento e analisi dei dati |
| Eseguire l'analisi dei dati sui dati raccolti in anticipo. | Eseguire processi di analisi, ad esempio Exploratory Data Analysis (EDA), offline. Prendere in considerazione i costi e le implicazioni per la sicurezza. Per i set di dati di piccole dimensioni senza vincoli di risorse, è possibile prendere in considerazione l'esecuzione di analisi nell'origine. ▪ Archivio raccolta dati |
| Mantenere la segmentazione dei dati, se i requisiti aziendali e tecnici lo richiedono. | Se si usano origini dati con requisiti di sicurezza distinti, creare pipeline separate per ogni modello. Stabilire controlli di accesso per limitare l'interazione con subset di dati specifici. ▪ Segmentazione dei dati |
| Pre-elaborare i dati per renderli significativi rispetto agli obiettivi di training. | Perfezionare la qualità dei dati inseriti filtrando il rumore, ripristinando i dati, indirizzando i duplicati e standardizzando formati diversi. ▪ Pre-elaborazione dei dati |
| Evitare il training sui dati non aggiornati. | Monitorare la deriva dei dati e la deriva dei concetti come parte dei cicli operativi interni ed esterni per mantenere l'accuratezza e l'affidabilità dei modelli nel tempo. Aggiornare regolarmente i dati di training con nuove osservazioni. Definire le condizioni che attivano il training del modello e determinano la frequenza di aggiornamento. ▪ Manutenzione dei dati |
Tipi di dati
Per creare potenza predittiva nei modelli, è necessario raccogliere dati, elaborarli e generarli nel modello. Questo processo viene in genere concettualizzato come una pipeline suddivisa in fasi. Ogni fase della pipeline potrebbe gestire lo stesso set di dati, ma potrebbe servire a scopi diversi. In genere, si gestiscono i dati di questi tipi:
I dati di origine sono dati di osservazione temporizzato. Può anche trattarsi di dati che possono essere etichettati per fungere da potenziale input per la pipeline di dati.
Questi dati vengono in genere ottenuti dall'ambiente di produzione o da un'origine esterna. Queste origini dati possono trovarsi in account di archiviazione, database, API o altre origini. I dati possono essere in diversi formati di dati, ad esempio database OLTP, documenti non strutturati o file di log. Questi dati fungono da potenziale input per la pipeline di dati.
I dati di training sono un subset di dati di origine usati per fornire campioni al modello. Gli esempi sono dati descrittivi precalcolati che consentono al modello di apprendere modelli e relazioni. Senza questi dati, il modello non può generare output pertinente.
I dati di valutazione sono un subset dei dati di origine usati per monitorare e convalidare le prestazioni di un modello di Machine Learning durante il training. È diverso dai dati di training e test e viene usato per valutare periodicamente le prestazioni del modello durante la fase di training e guidare l'ottimizzazione degli iperparametri. Per altre informazioni, vedere Valutazione del modello.
I dati di test vengono usati per convalidare la potenza predittiva di un modello sottoposto a training. Questi dati vengono campionati dai dati di origine non usati per il training. Contiene osservazioni dalla produzione in modo che il processo di test sia conclusivo. Dal punto di vista della progettazione dei dati, è necessario archiviare questi dati. Per informazioni sui modelli di test, vedere l'area Progettazione test .
In alcuni casi, le informazioni fornite dagli utenti durante le interazioni con l'applicazione possono diventare dati di origine. In generale, è consigliabile che l'input dell'utente usato in questo modo sia di alta qualità. In caso contrario, la necessità di gestire continuamente i problemi di qualità downstream può diventare problematica. Le indicazioni sulla gestione dei dati utente non sono illustrate in questo articolo.
Inserimento e analisi dei dati
I dati di training vengono raccolti all'interno di una finestra predeterminata con rappresentazioni sufficienti per il training del tipo di modello selezionato. Ad esempio, quando si esegue il training di un modello di classificazione binaria, i dati di training devono includere rappresentazioni di ciò che è il caso (esempi positivi) e ciò che non è il caso (esempi negativi). Affinché i dati di training siano significativi, eseguire edA in anticipo durante la progettazione delle funzionalità.
EDA consente di analizzare i dati di origine per identificare caratteristiche, relazioni, modelli e problemi di qualità. È possibile eseguire EDA direttamente nell'archivio dati di origine o replicare i dati in archivi centralizzati, ad esempio un data lake o un data warehouse. Il risultato del processo consiste nell'informare la raccolta e l'elaborazione dei dati per un training efficace del modello.
Nota
Anche se EDA è un processo di pre-produzione, usa i dati originati dall'ambiente di produzione. Applicare lo stesso livello di controllo a questo processo come si farebbe per l'ambiente di produzione.
Di seguito sono riportate alcune considerazioni per la raccolta dei dati in preparazione per il training del modello.
Origini dati
I dati possono essere raccolti da queste origini:
I dati proprietari sono creati o di proprietà dell'organizzazione. Non è destinato al consumo pubblico. Serve a scopi interni.
Le fonti pubbliche sono accessibili a chiunque. Queste fonti includono siti Web, documenti di ricerca e database condivisi pubblicamente. Potrebbe essere specifico di un'area di nicchia. Ad esempio, i contenuti di Wikipedia e PubMed sono considerati accessibili pubblicamente.
La scelta delle origini dati dipende dai requisiti del carico di lavoro, dalle risorse disponibili e dalla qualità dei dati accettabili per il training del modello. I set di dati sbilanciati possono causare modelli distorti, quindi è necessario progettare la raccolta dati per ottenere esempi sufficienti di dati rappresentativi. Potrebbe essere necessario sovrastare i dati di minoranza o i dati di maggioranza sottosample. Se i dati sono scarsi o sbilanciati, prendere in considerazione tecniche come la generazione di dati SMOTE e sintetici.
Archivio raccolta dati
Sono disponibili due opzioni principali per la raccolta dei dati di origine:
- Esecuzione di query sui dati nell'origine dati
- Copiare i dati in un archivio dati localizzato e quindi eseguire query su tale archivio
La scelta dipende dai requisiti del carico di lavoro e dal volume di dati. Se si dispone di una quantità relativamente piccola di dati, il sistema di origine potrebbe gestire direttamente le query non elaborate. Tuttavia, la procedura comune consiste nell'eseguire query e analizzare dall'archivio localizzato.
Cambio. Anche se gli archivi dati localizzati possono facilitare l'analisi e il processo di training, è necessario bilanciare anche i costi, la sicurezza e i requisiti del modello.
La duplicazione dei dati comporta costi di archiviazione e calcolo. La gestione di una copia separata richiede risorse aggiuntive. Le copie locali possono contenere informazioni riservate. In caso affermativo, è necessario proteggere i dati usando misure di sicurezza regolari.
Se si usano i dati di produzione per i dati di training, è necessario che siano soggetti a tutti i vincoli di classificazione dei dati originali di tali dati.
I dati possono essere forniti al processo di training (modalità push) o il processo stesso può eseguire query sull'origine dati (modalità pull). La scelta dipende dai vincoli di proprietà, efficienza e risorse.
Quando i dati vengono inseriti nel carico di lavoro, è responsabilità del proprietario dell'origine dati fornire dati aggiornati. Il proprietario del carico di lavoro fornisce una posizione appropriata nell'archivio dati localizzato per archiviare i dati. Questo approccio si applica ai dati proprietari di proprietà dell'organizzazione, non alle origini pubbliche.
Esistono due approcci che è possibile usare per il pull dei dati. In un unico approccio, il carico di lavoro esegue query sull'archivio dati, recupera i dati necessari e lo inserisce nell'archivio localizzato. Un altro modo consiste nell'eseguire query in tempo reale in memoria. La decisione dipende dal volume di dati e dalle risorse di calcolo disponibili. Per i set di dati più piccoli, il recupero in memoria potrebbe essere sufficiente per il training del modello.
Indipendentemente dal fatto che si usi la modalità push o pull, evitare modelli di training su dati non aggiornati. La frequenza degli aggiornamenti dei dati deve essere allineata ai requisiti del carico di lavoro.
Segmentazione dei dati
I requisiti specifici del carico di lavoro potrebbero richiedere la segmentazione dei dati. Ecco alcuni casi d'uso potenziali:
I requisiti di sicurezza spesso determinano decisioni di segmentazione. Ad esempio, i vincoli normativi potrebbero impedire l'esportazione dei dati tra aree geopolitiche. Se la progettazione dell'applicazione consente l'uso di modelli separati, la progettazione dei dati incorpora pipeline di dati separate per ogni modello.
Tuttavia, se viene usato un singolo modello, le origini dati segmentate vengono inserite in tale modello. È necessario eseguire il training del modello sui dati di entrambe le aree geografiche, che potenzialmente aggiungono complessità.
Indipendentemente dal fatto che l'applicazione usi un singolo modello o più modelli, mantiene le misure di sicurezza su ogni segmento di dati in modo che sia protetto con lo stesso livello di rigore dei dati all'origine.
La frequenza di aggiornamento dei dati può essere un fattore per separare i dati. I dati provenienti da origini diverse potrebbero essere aggiornati a intervalli di tempo diversi. Se i dati cambiano, la ripetizione del training diventa necessaria. La segmentazione consente un controllo granulare del ciclo di vita dei dati. È consigliabile usare tabelle o pipeline separate per segmenti di dati diversi.
Indipendentemente dal caso d'uso, quando i dati vengono segmentati, i controlli di accesso sono chiave. Professionisti dei dati, come data engineer e data scientist, esplorano i dati di origine disponibili per comprendere modelli e relazioni. Le informazioni dettagliate contribuiscono ai modelli di training che stimano i risultati. Stabilire i controlli di accesso per garantire che solo gli utenti autorizzati possano interagire con subset di dati specifici. Applicare privilegi minimi ai dati considerati rilevanti. Collaborare con i proprietari dei dati per configurare le autorizzazioni appropriate.
Pre-elaborazione dei dati
In uno scenario reale, i dati di origine non vengono semplicemente archiviati per gli scenari di intelligenza artificiale. Esiste un processo intermedio che prepara i dati per il training. Durante questa fase, i dati vengono rimossi dal rumore, rendendoli utili per l'utilizzo. Quando si gestiscono i dati di origine, i data scientist interagiscono in un processo di esplorazione, sperimentazione e processo decisionale. Il loro obiettivo principale è identificare ed estrarre parti dei dati di origine che mantengono la potenza predittiva.
La logica di pre-elaborazione dipende dal problema, dal tipo di dati e dai risultati desiderati. Di seguito sono riportate alcune tecniche comuni per la pre-elaborazione. Questo elenco non è esaustivo. I criteri effettivi per il carico di lavoro saranno determinati dai requisiti aziendali.
Qualità. La pre-elaborazione consente di garantire che i dati di training vengano rimossi dal rumore. L'obiettivo è garantire che ogni riga nei dati di training rappresenti un'osservazione chiara o un buon esempio rilevante per il caso d'uso e per eliminare le osservazioni che non hanno qualità o potenza predittiva. Ad esempio, se si confrontano le recensioni dei prodotti, è possibile scegliere di eliminare i dati troppo brevi. È necessario individuare la qualità dei dati che produce risultati predittivi significativi.
Riaspingere. I campi dati di origine troppo specifici possono limitare i poteri predittivi. Si consideri ad esempio un campo indirizzo. Ampliare l'ambito dall'indirizzo completo (numero di casa e nome della strada) a un livello superiore, ad esempio città, stato o paese/area geografica, potrebbe essere più rilevante.
Deduplicazione. L'eliminazione della ridondanza può garantire che i dati di training rimangano accurati e rappresentativi. In alcuni casi, la frequenza con cui viene effettuata un'osservazione non è rilevante. Ad esempio, quando si analizzano i log, se viene visualizzata una voce di log 1.000 volte, che ne indica la frequenza. Non implica necessariamente che si tratti di un errore più grave di un log che si è verificato una sola volta. Questo tipo di ridondanza può introdurre rumore.
Gestione dei dati sensibili. Eliminare i dati personali a meno che non sia assolutamente essenziale per il potere predittivo del modello in modo che non possa essere ottenuto tramite l'anonimizzazione. I dati di training devono essere efficaci senza compromettere la privacy. Se i dati forniscono valore, è necessario essere consapevoli delle considerazioni etiche relative alla gestione dei dati sensibili. Per altre informazioni, vedere Intelligenza artificiale responsabile.
Trasformazione standardizzata. Gli esperti di dominio considerano le tecniche precedenti come parte fondamentale dell'ingegneria delle funzionalità. L'ambito generale e i dati di origine diversificati devono infine essere uniti in archivi di funzionalità in cui le funzionalità sono organizzate ,ad esempio nelle tabelle delle funzionalità, allo scopo esplicito dei modelli di training. Dopo aver selezionato i dati predittivi per il training, trasformare i dati in un formato standardizzato. La standardizzazione garantisce anche la compatibilità con il modello di training.
La conversione di immagini in rappresentazioni di testo è una forma di trasformazione. Ad esempio, è possibile convertire documenti o immagini digitalizzati in testo leggibile dal computer.
Per garantire la compatibilità con i modelli, potrebbe essere necessario modificare gli orientamenti o le proporzioni delle immagini in base alle aspettative del modello.
Nota
La combinazione di grandi quantità di dati strutturati e non strutturati può aumentare il tempo di elaborazione. I team del carico di lavoro devono misurare l'impatto dell'elaborazione di formati diversi. Man mano che la finestra tra gli sforzi di ripetizione del training diventa più breve, la quantità di tempo impiegato per la pre-elaborazione diventa più critica.
Conservazione dei dati
Dopo aver eseguito il training di un modello, valutare se eliminare i dati usati per il training e ricompilare il modello per la finestra di training successiva.
Se i dati rimangono relativamente invariati, la ripetizione del training potrebbe non essere necessaria, a meno che non si verifichi la deriva del modello. Se l'accuratezza della stima diminuisce, è necessario ripetere il training del modello. È possibile scegliere di inserire nuovamente i dati, pre-elaborare e compilare il modello. Questo corso di azione è migliore se è presente un delta significativo nei dati dall'ultima finestra di training. Se è presente un volume elevato di dati e non è cambiato molto, potrebbe non essere necessario pre-elaborare e ricompilare il modello. In tal caso, conservare i dati, eseguire aggiornamenti sul posto e ripetere il training del modello. Decidere per quanto tempo conservare i dati di training.
In generale, eliminare i dati dagli archivi funzionalità per ridurre i costi di archiviazione e disordine per le funzionalità con prestazioni scarse e che non sono più rilevanti per i modelli correnti o futuri. Se si conservano i dati, aspettarsi di gestire i costi e risolvere i problemi di sicurezza, che sono problemi tipici della duplicazione dei dati.
Rilevamento della derivazione
La derivazione dei dati si riferisce al rilevamento del percorso dei dati dall'origine al relativo uso nel training del modello. Tenere traccia della derivazione dei dati è essenziale per la spiegazione. Anche se gli utenti potrebbero non avere bisogno di informazioni dettagliate sulle origini dei dati, queste informazioni sono fondamentali per i team di governance dei dati interni. I metadati di derivazione garantiscono trasparenza e responsabilità, anche se non vengono usati direttamente dal modello. Ciò è utile a scopo di debug. Consente inoltre di determinare se le distorsioni vengono introdotte durante la pre-elaborazione dei dati.
Usare le funzionalità della piattaforma per il rilevamento della derivazione quando è possibile. Ad esempio, Azure Machine Learning è integrato in Microsoft Purview. Questa integrazione consente di accedere alle funzionalità per l'individuazione dei dati, il rilevamento della derivazione e la governance come parte del ciclo di vita di MLOps.
Manutenzione dei dati
Tutti i modelli possono diventare obsoleti nel tempo, causando il decadimento della potenza predittiva o della pertinenza di un modello. Diverse modifiche esterne possono causare il decadimento, tra cui il cambiamento nel comportamento degli utenti, le dinamiche di mercato o altri fattori. I modelli di cui è stato eseguito il training potrebbero risultare meno rilevanti a causa di circostanze mutevoli. Per eseguire stime con maggiore fedeltà, sono necessari dati recenti.
Adozione di modelli più recenti. Per garantire la pertinenza, è necessario un ciclo operativo che valuta continuamente le prestazioni del modello e considera i modelli più recenti, che mantiene la pipeline di dati con un impatto minimo. In alternativa, è possibile prepararsi per una modifica più grande che comporta la riprogettazione del ciclo di vita e della pipeline dei dati.
Quando si sceglie un nuovo modello, non è necessario iniziare necessariamente con un nuovo set di dati. Le osservazioni esistenti usate per il training potrebbero rimanere preziose anche durante un cambio di modello. Anche se i nuovi modelli potrebbero rivelare scenari più stretti, il processo fondamentale rimane simile. Gli approcci di gestione dei dati, ad esempio archivi funzionalità e mesh di dati, possono semplificare l'adozione di nuovi modelli di Machine Learning.
Operazioni basate su trigger e routine. Valutare se la ripetizione del training del modello deve essere attivata da eventi o condizioni specifici. Ad esempio, la disponibilità di nuovi dati più rilevanti o un calo della pertinenza al di sotto di una baseline stabilita potrebbe attivare la ripetizione del training. I vantaggi di questo approccio sono la velocità di risposta e gli aggiornamenti tempestivi.
La manutenzione può anche essere pianificata a intervalli fissi regolari, ad esempio giornaliera o settimanale. Per le operazioni di verifica degli errori, prendere in considerazione entrambi gli approcci.
Rimozione dei dati. Rimuovere i dati che non vengono più usati per il training per ottimizzare l'uso delle risorse e ridurre al minimo il rischio di usare dati obsoleti o irrilevanti per il training del modello.
Il diritto di dimenticare si riferisce al diritto di un individuo di rimuovere i propri dati personali dalle piattaforme online o dai database. Assicurarsi di disporre di criteri per rimuovere i dati personali usati per il training.
Conservazione dei dati. In alcune situazioni, è necessario ricompilare un modello esistente. Ad esempio, per il ripristino di emergenza, un modello deve essere rigenerato esattamente come prima dell'evento irreversibile. È consigliabile disporre di una pipeline di dati secondaria che segue i requisiti del carico di lavoro della pipeline primaria, ad esempio l'indirizzamento del decadimento del modello, gli aggiornamenti regolari tramite operazioni basate su trigger o routine e altre attività di manutenzione.
Assicurarsi che la manutenzione dei dati venga eseguita come parte delle operazioni del modello. È consigliabile stabilire processi per gestire le modifiche tramite l'automazione il più possibile e usare il set corretto di strumenti. Per altre informazioni, vedere MLOps e GenAIOps per carichi di lavoro di intelligenza artificiale in Azure.