Condividi tramite

Piattaforma dati per carichi di lavoro di intelligenza artificiale in Azure

  • Articolo

Una piattaforma dati è un set integrato di tecnologie progettate per gestire i requisiti del carico di lavoro inserendo i dati di origine e quindi filtrando, aggregando e preparandolo per l'utilizzo.

I dati hanno caratteristiche distinte basate sull'uso previsto. Prima di esplorare le funzionalità tecnologiche descritte in questo articolo, è consigliabile comprendere i principi della progettazione di pipeline di dati validi. Per altre informazioni, vedere Progettazione dei dati di training e Progettazione dei dati a terra.

La piattaforma soddisfa anche le esigenze di archiviazione quando i dati vengono archiviati in determinati punti della pipeline. Se il carico di lavoro è complesso e gestisce dati su larga scala, è possibile distribuire le attività della pipeline tra vari componenti. Per casi d'uso più semplici, valutare se è possibile usare i dati di origine in un archivio che offre tali funzionalità combinate.

Porre le domande seguenti in modo da evitare di progettare un'architettura eccessivamente complessa per la piattaforma dati. È sempre meglio tenere le cose semplici quando si può.

  • L'applicazione può avere la potenza predittiva prevista inserendo i dati da una singola origine?
  • La scelta iniziale dell'archivio dati supporta le funzionalità di data warehousing?
  • I dati di origine sono già ottimizzati per le ricerche di intelligenza artificiale?

Se si risponde sì a queste domande, è possibile semplificare l'architettura consentendo all'applicazione di accedere direttamente all'origine dati. Questo approccio elimina la necessità di componenti dell'architettura di Big Data, ad esempio l'inserimento dei dati, l'integrazione dell'archivio analitico e l'elaborazione dei dati esterni. Se il database di origine può gestire le ricerche necessarie, l'integrazione della funzionalità di indice di ricerca direttamente nel database di origine può essere un approccio pratico. Assicurarsi che l'origine possa essere ridimensionata in modo conveniente per soddisfare nuove esigenze.

Ad esempio, Azure Cosmos DB supporta la ricerca vettoriale, quindi potrebbe non essere necessario un altro indice. Un altro caso d'uso consiste nell'usare le repliche in lettura come endpoint per le operazioni di ricerca. Per i database SQL con repliche in lettura, le ricerche dirette a queste repliche possono ottimizzare le prestazioni. Sfruttare al massimo le funzionalità predefinite del database per semplificare l'architettura.

Un'architettura della piattaforma dati per carichi di lavoro su larga scala è più complessa.

L'inserimento di dati da più origini dati e l'orchestrazione delle ricerche in varie piattaforme possono diventare complessi e inefficienti. Inoltre, sono ancora necessari alcuni estrazione, trasformazione e caricamento (ETL); estrazione, caricamento e trasformazione (ELT); o estrarre e caricare (EL) processi per modellare i dati all'interno dell'archivio dati. Lo scenario diventa più complesso perché i dati richiedono un'elaborazione maggiore. È necessario aggiungere molti componenti all'architettura per gestire la pipeline end-to-end dall'inserimento alla gestione delle query. Molte tecnologie di Big Data sono altamente specializzate e create per gestire in modo efficace tali attività di elaborazione.

Una di queste tecnologie è l'indice di ricerca. Il vantaggio principale dell'aggiunta di un indice separato è la possibilità di gestire in modo efficiente le query ed elaborare volumi elevati di dati con velocità effettiva elevata. Questa funzione esegue l'offload delle funzionalità di intelligenza artificiale dall'origine dati originale, in modo che l'indice possa concentrarsi sulla funzione principale e gestire le query.

Scegliere una piattaforma in base alle funzionalità e allo scopo specifiche e prendere in considerazione i requisiti funzionali e tecnici. Se l'architettura è in continua evoluzione per gestire casi d'uso complessi, concentrarsi sulle sezioni seguenti sugli archivi dati aggregati, sull'elaborazione delle pipeline e sugli indici di ricerca.

Consigli

Ecco il riepilogo delle raccomandazioni fornite in questo articolo.

Suggerimento Descrizione
Creare archivi dati sicuri, efficienti e convenienti. Una parte fondamentale della piattaforma dati è un archivio dati che aggrega i dati da più origini e consente l'integrazione con varie attività di integrazione. In questo modo il carico di lavoro viene eseguito su larga scala. Assicurarsi di esaminare i vari requisiti funzionali e non funzionali dell'archivio dati per garantire una distribuzione conveniente.

▪ Considerazioni per l'archiviazione di dati aggregati
Seguire le procedure consigliate per l'inserimento e l'elaborazione dei dati. I dati di alta qualità consentono di migliorare l'affidabilità del carico di lavoro e l'esperienza dell'utente finale. Prendere in considerazione i requisiti del carico di lavoro e le procedure consigliate principali per creare processi efficienti di inserimento e transizione dei dati che consentono di mantenere una barra di alta qualità.

▪ Considerazioni sull'elaborazione dei dati
Progettare indici di ricerca affidabili e pertinenti. Mirare a un archivio dati con prestazioni elevate, write-once e read-many che gestisce in modo efficiente query impromptu e fuzzy, offrendo risultati pertinenti alla base utente, anche quando le query non sono precise.

▪ Considerazioni per un indice di ricerca
Assicurarsi che gli archivi dati funzionali vengano eseguiti su larga scala. A seconda dei requisiti funzionali del carico di lavoro, potrebbe essere necessario creare archivi dati funzionali, ad esempio per l'inferenza offline. È importante creare archivi dati tenendo presente la funzione designata e applicare le procedure consigliate per la funzione.

▪ Considerazioni per un archivio funzionalità
▪ Considerazioni per un archivio dati di inferenza offline

Considerazioni per l'archiviazione di dati aggregati

Nei carichi di lavoro di intelligenza artificiale i dati passano attraverso varie fasi di archiviazione ed elaborazione con l'aiuto delle pipeline che orchestrano il flusso di lavoro tra queste fasi. Una fase chiave è un archivio dati che contiene dati inseriti e aggregati da più origini. Questo archivio è necessario per eseguire l'elaborazione fino a quando i dati non raggiungono uno stato appropriato per il training o l'indicizzazione. L'obiettivo principale è garantire che i dati riflettano accuratamente l'origine.

Nota

Un approccio alternativo consiste nell'accedere direttamente alle origini dati. Tuttavia, questo approccio può causare problemi di prestazioni perché potrebbe sovraccaricare i sistemi di origine con funzionalità di intelligenza artificiale. Possono verificarsi anche problemi di accesso ai dati. Per evitare questi problemi, è consigliabile copiare i dati in questo archivio.

La piattaforma dati per questo archivio deve soddisfare gli standard di sicurezza applicati alle origini dati, essere conveniente e supportare l'integrazione con le attività di elaborazione ETL, ELT e EL. Le opzioni variano dall'archiviazione di base alle tecnologie Big Data in base al volume di dati. Scegliere uno spazio di archiviazione economico che consente di ottenere un livello di affidabilità e prestazioni sufficiente.

La sezione seguente fornisce indicazioni sulle funzionalità da considerare quando si seleziona una tecnologia di archivio dati. Per altre informazioni, vedere Pipeline di elaborazione dati.

Requisiti funzionali

  • La piattaforma può gestire vari formati di dati?

    L'archivio dati deve essere in grado di archiviare vari formati di dati e trasformarli in altri formati, se necessario.

    Si supponga che la pipeline di inserimento origini dati da un database relazionale e un file Parquet, in modo che supporti dati strutturati e semistrutturati. Si desidera convertire i dati relazionali in formato Parquet in base alle relative definizioni di schema. La piattaforma dati deve avere funzionalità predefinite per eseguire questa trasformazione senza scrivere codice personalizzato.

  • Si prevede di archiviare più versioni dei dati?

    I valori e gli schemi dei dati possono cambiare nel tempo e la gestione di più versioni dei dati diventa importante.

    I sistemi di origine archiviano in genere solo i dati correnti, non i dati cronologici. Se è importante conservare i dati cronologici, potrebbe essere necessario duplicare set di dati di grandi dimensioni dai sistemi di origine. In questo caso, il controllo delle versioni può disambiguare i dati correnti dai dati cronologici.

    In alcuni casi, potrebbe essere necessario gestire copie dei dati per casi d'uso diversi. Per supportare questo scenario, potrebbe essere necessario creare una copia tramite fork dei dati. Ogni fork può mutare in modo indipendente per migliorarne la qualità e l'usabilità. La piattaforma dati deve essere in grado di mantenere il controllo delle versioni appropriato di tali fork.

    La piattaforma dati deve essere in grado di archiviare le versioni dei dati nel tempo per fornire contesto cronologico. Questo contetxt è utile per l'elaborazione e il training dei modelli di intelligenza artificiale perché offre più osservazioni anziché solo un singolo punto nel tempo.

  • La piattaforma dispone di funzionalità di gestione del ciclo di vita dei dati predefinite?

    La gestione del ciclo di vita dei dati (DLM) è un processo per la gestione dei dati dalla creazione all'eliminazione, con fasi quali raccolta dati, archiviazione, utilizzo, archiviazione e eliminazione.

    Senza DLM, i dati possono aumentare in modo noncontrollo, spesso comportando più copie mentre passano attraverso livelli di qualità. La piattaforma dati deve avere funzionalità DLM per impedire la crescita dei dati non associati.

    Si consideri questo scenario. Il passaggio di pre-elaborazione deve ripetere per perfezionare i dati fino a raggiungere una qualità accettabile a scopo di training. La piattaforma dati deve essere in grado di eliminare copie intermedie dei dati.

    In alcuni casi, potrebbe essere necessario conservare i dati per i controlli normativi. La piattaforma dati deve avere funzionalità di archiviazione ad accesso sporadico per i dati a cui si accede raramente in modo da poterla archiviare a un costo inferiore.

  • La piattaforma supporta le funzionalità di governance dei dati?

    La verificabilità è un aspetto importante per i carichi di lavoro di intelligenza artificiale. L'archivio dati deve gestire audit trail in grado di tenere traccia dell'accesso ai dati, garantire la privacy e comprendere le origini dei dati.

    Usare una funzionalità del dizionario dati per gestire metadati, tipi di dati, scopi e derivazione. Questa funzionalità è particolarmente importante quando i dati vengono inseriti da più origini.

  • Si prevede di eseguire il training con i dati di produzione?

    Esistono due approcci alle distribuzioni, alla distribuzione del modello e alla distribuzione del codice. Nella distribuzione del modello, i dati di produzione vengono usati nello sviluppo, che richiedono misure di sicurezza rigorose. Nella distribuzione del codice, il modello non visualizza i dati di produzione fino a quando non è in produzione. Anche se la distribuzione del codice semplifica i problemi di sicurezza nell'ambiente di sviluppo, può aumentare i costi di calcolo. Indipendentemente dall'approccio scelto, la piattaforma dati deve supportare ambienti separati per lo sviluppo e la produzione.

  • Si assegnano priorità alle funzionalità di praticità rispetto alle principali funzionalità funzionali?

    Quando si sceglie una piattaforma dati per intelligenza artificiale o Machine Learning, non basarsi solo sulle funzionalità del notebook. Anche se i notebook sono utili per l'analisi esplorativa dei dati, non devono essere il fattore determinante. Le risorse di calcolo per i notebook in genere non rientrano nell'ambito dell'archivio dati di aggregazione. In genere sono integrati con altre risorse, ad esempio Azure Machine Learning.

Requisiti non funzionali

  • Quanti dati si prevede di archiviare?

    I carichi di lavoro di intelligenza artificiale generano molti dati. Il volume può aumentare significativamente a causa di più versioni e metadati aggiuntivi.

    La scalabilità per l'archiviazione e la velocità effettiva è importante. La piattaforma dati deve utilizzare in modo efficiente i dati della pipeline di inserimento mentre gestisce il volume di dati, gestisce le scritture simultanee e garantisce prestazioni di scrittura singole senza riduzione delle prestazioni. Questi criteri si applicano anche alla pipeline di elaborazione che legge, elabora e persino scrive nuovamente nell'archivio.

    Quando si prende una decisione, prendere in considerazione l'intero processo perché l'inserimento e l'elaborazione spesso si verificano contemporaneamente. La progettazione deve essere in grado di gestire lo spostamento e l'elaborazione frequenti dei dati. La piattaforma dati deve offrire livelli elevati di parallelismo per elaborare i dati in modo efficace.

    La tecnologia della piattaforma deve generare dati di telemetria che forniscono informazioni significative sulla velocità effettiva e sulle prestazioni delle operazioni di lettura e scrittura.

  • Questo archivio dati è un componente critico che contribuisce alla destinazione di affidabilità del carico di lavoro?

    Scegliere un archivio dati che migliora sia l'affidabilità che la scalabilità usando più istanze. Gli archivi Big Data hanno spesso un controller predefinito che orchestra l'elaborazione dei dati tra istanze. Se una copia ha esito negativo, è possibile usare un'altra.

    Tenere presente che i dati non servono allo scopo se non sono corretti o accessibili. La piattaforma dati deve garantire la durabilità e assicurarsi che i dati rimangano intatti. Assicurarsi che le API che eseguono query sui dati siano accessibili. Prendere in considerazione anche gli archivi dati con funzionalità di backup.

    In generale, non è necessario eseguire il backup di questi dati. Tuttavia, se il costo di aggregazione dei dati ogni volta da zero è significativamente elevato, è possibile riattivare i dati da un backup.

  • Sono presenti vincoli di costo?

    Se l'affidabilità e le prestazioni dei dati sono sufficienti, prendere in considerazione l'impatto sui costi.

    Il sistema deve essere ottimizzato per la scrittura una sola volta, leggere molti per evitare sovraccariche nell'archiviazione dei dati. I dati di training o di messa a terra sono importanti ma non critici come un database di produzione, che richiede tempi di risposta immediata. L'obiettivo è quello di bilanciare i costi con un'efficienza sufficiente per massimizzare il ritorno sugli investimenti.

I requisiti precedenti possono naturalmente portare a prendere in considerazione l'uso di un data lake perché offre DLM, livelli di qualità, osservabilità e supporto per formati di file diversi. Se il carico di lavoro usa già un data lake, sfruttare tale risorsa per soddisfare le esigenze di intelligenza artificiale. In alternativa, è possibile scegliere altre opzioni di archiviazione, ad esempio Archiviazione BLOB di Azure, che offre un certo livello di DLM, funzionalità di monitoraggio e velocità elevate delle transazioni.

Considerazioni sull'elaborazione dei dati

È necessario elaborare i dati nell'archivio dati di aggregazione per aumentare l'utilità downstream. Le pipeline ETL eseguono questa attività, che è più importante nei punti seguenti:

  • Livello di inserimento

    La pipeline è responsabile della raccolta di dati da varie origini e dello spostamento nell'archivio dati di aggregazione. Durante questo processo, la pipeline esegue in genere la pre-elaborazione di base e potrebbe persino strutturare i dati in un formato querybile.

    Per ridurre al minimo la necessità di codice personalizzato, è consigliabile eseguire l'offload di gran parte di questa responsabilità in una piattaforma dati. Quando si seleziona una tecnologia, prendere in considerazione le caratteristiche ETL necessarie per supportare il training del modello e l'aumento.

  • Livello di elaborazione

    I dati dell'archivio dati aggregato vengono sottoposti a un'elaborazione estesa prima di poterli usare per l'indicizzazione o i casi d'uso del training del modello. La pipeline di elaborazione richiede livelli di affidabilità e scalabilità simili alla pipeline di inserimento. La differenza principale è il tipo di elaborazione eseguita sui dati.

    Il processo comporta un notevole ridimensionamento e ristrutturazione dei dati. Questo processo include attività come il riconoscimento delle entità, l'integrazione di dati aggiuntivi nel set di dati e l'esecuzione di ricerche. Questo processo può includere anche l'eliminazione di dati non necessari e l'applicazione della logica dei dati tramite una piattaforma di orchestrazione dei dati.

La fase di elaborazione dei dati può produrre vari output, che arrivano in destinazioni diverse per finalità diverse. L'obiettivo principale è preparare e trasferire i dati dall'archivio dati aggregato per l'utilizzo dalla destinazione finale. Il consumer può eseguire il pull dei dati quando necessario o il livello di elaborazione può eseguire il push dei dati quando è pronto.

Nota

Nel contesto di Machine Learning e intelligenza artificiale generativa, è importante distinguere tra processi ETL, ELT e EL. L'ETL tradizionale è fondamentale per il data warehousing e i mapping relazionali a oggetti, in cui, a causa delle restrizioni dello schema, i dati devono essere trasformati prima di caricarli nel sistema di destinazione. ELT implica l'estrazione dei dati, il caricamento in un data lake e la trasformazione tramite strumenti come Python o PySpark. Nell'intelligenza artificiale generativa, in particolare per la generazione avanzata del recupero ( RAG), il processo comporta spesso l'estrazione e il caricamento di documenti nella risorsa di archiviazione, seguita da trasformazioni come la suddivisione in blocchi o l'estrazione di immagini.

La sezione seguente fornisce indicazioni da considerare quando si seleziona una tecnologia di elaborazione dati con funzionalità ETL.

Requisiti funzionali

  • Qual è il supporto per la connessione alle origini dati?

    I dati che devono essere elaborati potrebbero essere archiviati in database relazionali, origini Big Data o varie soluzioni di archiviazione.

    La maggior parte delle tecnologie di elaborazione dati supporta le integrazioni predefinite che consentono di connettersi a varie origini dati senza scrivere codice. I connettori hanno funzionalità come la possibilità di copiare dati dall'origine al sink, eseguire ricerche e applicare una forma di governance dei dati. Sono disponibili strumenti che offrono funzionalità di trascinamento della selezione per evitare codice non necessario.

    Scegliere una piattaforma dati che semplifica l'integrazione con le origini dati previste.

  • La piattaforma può elaborare vari formati di dati?

    I dati possono venire in diversi formati, ad esempio dati strutturati, ad esempio database e JSON, dati non strutturati come immagini e documenti o dati in streaming come dati provenienti da dispositivi Internet delle cose. Le pipeline devono essere in grado di gestire i tipi di file previsti.

  • La piattaforma offre funzionalità per la preparazione e il ripristino dei dati?

    È necessario elaborare i dati che si intende usare per il training o l'aumento fino a quando non è adatto per il training, l'ottimizzazione o l'indicizzazione. Le strategie di progettazione dei dati devono delineare in modo esplicito i requisiti.

    Gli articoli seguenti descrivono considerazioni specifiche:

    Come parte della pulizia di base, la piattaforma rimuove i duplicati, riempie i valori mancanti ed elimina il rumore estraneo durante l'inserimento. Per alcuni casi d'uso, ad esempio l'implementazione di un modello RAG, è consigliabile usare blocchi minuscoli.

    Anche se questi passaggi di pre-elaborazione sono necessari, la piattaforma deve supportare anche la modifica avanzata dei dati specifica per le proprie esigenze. Questo processo comporta il caricamento, il ridimensionamento e la trasformazione dei dati. Per determinati modelli, la piattaforma deve essere in grado di eseguire query su origini esterne per l'analisi dei documenti, ad esempio l'intelligence sui documenti o altri strumenti di intelligenza artificiale. Questo lavoro è necessario per preparare i dati e per l'arricchimento dei dati.

    Se l'archivio dati supporta questo livello di elaborazione, è possibile localizzare questa fase nell'archivio senza spostarla altrove. In caso contrario, è necessaria una tecnologia esterna, ad esempio Azure Databricks o Azure Data Factory. Queste tecnologie sono adatte allo spostamento dei dati e all'esecuzione di manipolazioni, ad esempio il filtro, il riempimento di valori mancanti e la standardizzazione delle maiuscole e minuscole delle stringhe. Per le attività più complesse, in genere è necessaria una piattaforma di hosting di processi. È possibile usare i pool di Spark per l'orchestrazione di Big Data.

    In alcuni casi d'uso, potrebbe essere necessario esternalizzare questa responsabilità all'utente dei dati. Ad esempio, i modelli di intelligenza artificiale che usano Machine Learning offrono funzionalità di elaborazione dei processi per leggere, modificare e scrivere dati usando codice Python personalizzato.

    Un altro esempio è l'implementazione rag. Un passaggio di elaborazione comune è la suddivisione in blocchi di un documento in più blocchi e ogni blocco diventa una riga nell'indice. Archivia anche incorporamenti, che spesso genera un servizio OpenAI, per questi blocchi. Nelle ricerche di intelligenza artificiale questo processo viene orchestrato all'interno del flusso di lavoro di indicizzazione, indipendentemente dal fatto che si usi OpenAI o Ricerca di intelligenza artificiale di Azure.

  • Esiste un agente di orchestrazione predefinito per la gestione dei flussi di lavoro?

    Le attività di elaborazione sono modulari ed eseguite come processi. La piattaforma deve avere funzionalità di orchestrazione che suddivideno il flusso di lavoro in passaggi o processi. Ogni processo deve essere definito, eseguito e monitorato in modo indipendente.

    Nei flussi di lavoro complessi, alcuni passaggi dipendono dal completamento corretto di quelli precedenti. L'agente di orchestrazione deve gestire le dipendenze dei processi e assicurarsi che le attività vengano completate nell'ordine corretto.

    La progettazione dei dati è un processo iterativo, quindi lo strumento dell'agente di orchestrazione deve essere abbastanza flessibile per modificare facilmente i flussi di lavoro. Dovrebbe essere possibile inserire nuovi passaggi o regolare quelli esistenti senza riscrivere parti di codice di grandi dimensioni.

    Data Factory è una scelta comune perché offre un set di funzionalità avanzato per la gestione dei flussi di lavoro dei dati. Azure Databricks può anche gestire flussi di lavoro complessi e pianificare e monitorare i processi. È anche consigliabile considerare le implicazioni relative ai costi. Ad esempio, le funzionalità di Azure Databricks potrebbero essere estese, ma sono anche costose. Un'opzione alternativa open source, ad esempio Apache NiFi, potrebbe essere più conveniente.

    In definitiva, lo strumento scelto dipende da ciò che l'organizzazione consente e dalle competenze con cui il team del carico di lavoro è a proprio agio.

Requisiti non funzionali

Quando si sceglie una pipeline di elaborazione, è fondamentale bilanciare la velocità effettiva e l'osservabilità. La pipeline deve elaborare e trasferire in modo affidabile i dati necessari per i modelli o gli indici entro un intervallo di tempo sufficiente. Dovrebbe essere sufficientemente leggero per supportare le esigenze attuali e essere scalabile per la crescita futura. Teams deve decidere quanto è necessario per la piattaforma a prova di futuro per evitare il debito tecnico in un secondo momento. Le considerazioni chiave includono la frequenza e il volume di inserimento dei dati, l'affidabilità del processo e la necessità di osservare e risolvere tempestivamente i problemi.

  • Quanti dati ci si aspetta di inserire?

    Per le fasi di inserimento ed elaborazione, prendere in considerazione la scalabilità e la velocità della piattaforma per la gestione delle attività. Si prevede, ad esempio, di caricare 10 terabyte di dati ogni giorno in un indice o per il training del modello. La piattaforma di inserimento dati deve essere in grado di elaborare tale volume e con la velocità effettiva prevista. In questo caso, l'uso di App per la logica di Azure potrebbe non essere fattibile perché potrebbe non riuscire in un carico di questo tipo. Data Factory è invece più adatto per questa scala di elaborazione dei dati.

    Un modo per gestire volumi elevati consiste nel parallelismo perché consente una gestione e un'elaborazione dei dati più efficienti. Le piattaforme come Azure Databricks possono orchestrare le attività creando più istanze per lo stesso processo e distribuendo il carico in modo efficiente.

    Considerare anche la latenza tollerabile e la complessità dei processi. Ad esempio, la pulizia dei dati comporta la convalida e la sostituzione di campi non validi o mascheramento delle informazioni riservate. Queste attività, anche se di base, richiedono risorse significative perché ogni riga viene elaborata singolarmente, che aggiunge al tempo complessivo.

  • Quali funzionalità di monitoraggio sono necessarie?

    Le pipeline di elaborazione dati devono avere funzionalità di monitoraggio e fornire informazioni dettagliate sulle prestazioni e sullo stato dei processi della pipeline.

    È necessario essere in grado di tenere traccia dello stato di avanzamento dei processi. Si supponga che la pipeline esegua un processo di pulizia dei dati che non viene completato o completato parzialmente. Potrebbe verificarsi un impatto downstream sulla qualità dei dati con cui viene eseguito il training del modello, che potrebbe influire sulla potenza predittiva.

    Analogamente ad altri componenti del carico di lavoro, è necessario abilitare log, metriche e avvisi nella pipeline di dati per comprenderne il comportamento. Raccogliere e analizzare le metriche delle prestazioni per comprendere gli aspetti relativi all'efficienza e all'affidabilità.

    Identificare eventuali lacune nei dati di telemetria predefiniti e determinare quale monitoraggio aggiuntivo è necessario implementare. Questo monitoraggio potrebbe comportare l'aggiunta di metriche o registrazione personalizzate per acquisire dettagli specifici sui passaggi del processo.

  • Quanto affidabilità ci si aspetta dalla piattaforma di elaborazione dati?

    L'affidabilità di una pipeline di elaborazione dati varia in base alla scelta della piattaforma. Anche se App per la logica ha funzionalità di orchestrazione, potrebbe non essere affidabile come Data Factory. Data Factory, ospitato in un cluster del servizio Azure Kubernetes servizio Azure Kubernetes, potrebbe avere caratteristiche di affidabilità diverse.

    Le configurazioni a istanza singola sono considerate punti di errore. Scegliere una piattaforma che supporti le funzionalità di affidabilità, ad esempio più istanze, per soddisfare i requisiti.

    La piattaforma deve supportare anche le funzionalità di resilienza. Ad esempio, l'agente di orchestrazione deve ripetere automaticamente un'attività non riuscita, riducendo la necessità di riavvii manuali.

    L'elaborazione batch può essere meno affidabile rispetto all'inferenza, a seconda dei requisiti di aggiornamento e latenza dei dati. Se il training si verifica ogni settimana e l'elaborazione richiede un giorno, gli errori occasionali sono accettabili perché è sufficiente tempo per riprovare.

  • Esistono vincoli di costo?

    Quando si considera l'efficacia dei costi di una pipeline di elaborazione dati, è importante scegliere una soluzione che soddisfi le proprie esigenze senza spese non necessarie. Se i requisiti non giustificano le funzionalità avanzate di Azure Databricks, potrebbe essere sufficiente un'opzione più economica come Data Factory. Inoltre, strumenti open source come Apache Airflow o Apache NiFi possono offrire funzionalità affidabili a un costo inferiore. La chiave consiste nell'evitare overspending sulle funzionalità che non sono necessarie e selezionare una piattaforma che bilancia le funzionalità e l'efficienza dei costi.

  • Quali sono i requisiti di sicurezza per i flussi di lavoro e i dati elaborati?

    Essere chiari sui requisiti di sicurezza, privacy e residenza dei dati. Si considerino, ad esempio, eventuali requisiti normativi geografici. Rispettare i requisiti di residenza dei dati assicurandosi che i dati vengano archiviati ed elaborati all'interno di aree specifiche. Potrebbe essere necessario eseguire pipeline separate per aree diverse, ad esempio una per l'Europa e un'altra per l'America, per soddisfare le normative di conformità locali.

    La piattaforma della pipeline di dati deve supportare la gestione delle identità e degli accessi per garantire che solo le identità autorizzate abbiano accesso a processi o passaggi specifici all'interno dei flussi di lavoro. Ad esempio, se il processo ETL è costituito da diversi flussi di lavoro e uno di essi gestisce dati estremamente riservati, la piattaforma deve consentire di limitare l'accesso a tale flusso di lavoro mantenendo gli altri accessibili. Questa funzionalità consente di soddisfare i requisiti di sicurezza senza bisogno di piattaforme separate per diversi livelli di riservatezza dei dati. Idealmente, la piattaforma deve fornire supporto predefinito per tale isolamento che consente una gestione efficiente e sicura dei dati.

Le pipeline di elaborazione dati possono restituire i dati in un indice di ricerca o in una pipeline di training del modello. A seconda del caso d'uso, vedere le sezioni sugli indici di ricerca o sugli archivi di funzionalità.

Considerazioni per un indice di ricerca

L'indice di ricerca è progettato per archiviare i dati contestuali o di base da inviare all'endpoint di inferenza del modello, insieme alla richiesta. Entrambe le chiamate, la query di indice e la chiamata dell'endpoint di inferenza, vengono eseguite nel contesto della manutenzione delle stesse richieste HTTP client. A differenza dei processi ETL che gestiscono processi offline e batch, questo indice supporta l'inferenza in tempo reale, che richiede prestazioni elevate e affidabilità. È specializzata per le query di intelligenza artificiale e offre funzionalità come l'indicizzazione e il filtro delle parole chiave, che non sono tipici degli archivi Big Data. L'obiettivo è avere un archivio dati write-many ad alte prestazioni e con prestazioni elevate che supporta query impromptu e fuzzy. Questo archivio dati può fornire risultati pertinenti senza query precise.

Requisiti funzionali

  • Quali tipi di ricerca supportano l'indice di ricerca?

    Le query ricevute dal sistema sono essenzialmente ricerche e l'indice deve supportare funzionalità di ricerca avanzate. Per RAG, la ricerca vettoriale non è negoziabile perché i dati vengono archiviati come vettori calcolati o incorporamenti, che vengono usati per la ricerca.

    La ricerca vettoriale è potente e la combinazione con il filtro e la ricerca full-text migliora l'efficacia dell'indice di ricerca. La progettazione dei dati deve tenere conto della combinazione di questi tipi di ricerche, ad esempio vettore, ricerca full-text, filtro e tipi di dati speciali come la posizione geografica.

    La progettazione dei dati deve indicare in modo esplicito tali requisiti. Per altre informazioni, vedere Esecuzione efficiente di query nella progettazione dei dati.

  • L'indice supporta i dati multifunzionali?

    Scegliere le tecnologie di indice che supportano i dati multimodali. Ad esempio, le ricerche di intelligenza artificiale possono analizzare un messaggio di posta elettronica, convertire un'immagine in vettori e archiviare la descrizione nell'indice. Usare questa funzione per eseguire ricerche in varie modalità di contenuto, tra cui immagini, video e file audio.

  • L'indice supporta le funzionalità di aggiornamento automatico quando cambiano i dati nelle origini dati?

    Scegliere un indice con funzionalità di aggiornamento automatico. Se non è disponibile, è necessario rilevare ed eseguire il push manuale delle modifiche all'indice. Con queste funzionalità, l'indicizzatore può rilevare automaticamente le modifiche nelle origini dati e gli aggiornamenti pull. Eseguendo l'offload di questa responsabilità alla piattaforma, è possibile ridurre il sovraccarico operativo e semplificare il processo di manutenzione.

Requisiti non funzionali

  • L'indice può essere eseguito con grandi volumi di dati?

    L'indice deve essere in grado di gestire grandi quantità di dati, essere scalabile e prestazioni elevate per carichi di lavoro di ricerca elevati. L'indice archivia i dati non elaborati e tutti i metadati, gli arricchimenti e le entità associati. Nel contesto del modello RAG, un singolo documento suddiviso in più blocchi può comportare un aumento significativo del volume di dati.

  • L'indice dispone di funzionalità di affidabilità predefinite?

    Prendere in considerazione l'allineamento tra l'affidabilità dell'endpoint di inferenza o il modello e l'archivio dati perché dipendono l'uno dall'altro.

    Il processo di ricerca prevede due passaggi: l'esecuzione di query sull'archivio dati e quindi l'esecuzione di query sull'endpoint di inferenza. Entrambi i passaggi devono avere caratteristiche di affidabilità simili. Bilanciare gli obiettivi di affidabilità tra entrambi i componenti per garantire l'efficacia della ricerca.

    Per garantire la resilienza, il carico di lavoro deve supportare il numero previsto di utenti simultanei e avere una larghezza di banda sufficiente per gestire i picchi di traffico. Idealmente, la piattaforma dovrebbe sopravvivere a interruzioni di zona.

    La piattaforma dati deve essere progettata per impedire l'uso di un indice danneggiato per l'inferenza. In questi casi, dovrebbe essere possibile ricompilare facilmente l'indice. L'indice deve supportare anche lo scambio affidabile tra gli indici usando funzionalità come l'aliasing per ridurre al minimo i tempi di inattività durante gli scambi di indici. Senza questa funzionalità, potrebbe essere necessario basarsi su un backup dell'indice. La gestione di un backup presenta una maggiore complessità.

    Dal punto di vista del carico di lavoro, comprendere le potenziali modalità di errore o gli indicatori di stress, ad esempio la limitazione. Ad esempio, anche se il sistema potrebbe supportare normalmente 50 utenti simultanei, potrebbe supportare solo 30 utenti durante un processo di reindicizzazione eseguito come processo in background. In tal caso, la tempistica del processo in background diventa importante. Quando si valuta la velocità effettiva di un indice, includere sia le query front-end che i processi back-end.

  • Quali sono i principali fattori di costo di questa tecnologia?

    Quando si modellano i costi, stimare le spese associate al volume di dati, al numero di query e alla velocità effettiva prevista dell'indice. Tenere presente che gli indici sono principalmente piattaforma distribuita come servizio (PaaS), in cui i prezzi vengono astratti. Livelli di ricerca e le relative capacità per evitare il pagamento eccessivo della capacità o delle funzionalità inutilizzate.

    Ad esempio, ricerca di intelligenza artificiale fattura come unità, che può includere capacità, velocità effettiva e archiviazione. Funzionalità aggiuntive possono comportare più addebiti. Ad esempio, un uso esteso delle funzionalità di estrazione delle immagini può comportare una fattura elevata. Le dipendenze, ad esempio la funzionalità del set di competenze, che non rientrano nell'ambito dell'indice, ma fanno parte dell'elaborazione dati possono comportare costi aggiuntivi.

    Il pagamento per un livello senza l'uso della capacità completa può comportare il pagamento eccessivo. Analogamente, il numero di tabelle nell'indice e la possibilità di gestire il traffico simultaneo influiscono sui costi.

    Per comprendere i costi associati alla ricerca di intelligenza artificiale, vedere Pianificare e gestire i costi di un servizio di ricerca di intelligenza artificiale.

  • Le funzionalità di sicurezza dell'indice soddisfano la progettazione dei dati di sicurezza?

    La progettazione dei dati deve specificare chiaramente i requisiti di sicurezza e privacy. Negli ambienti di sviluppo e test in cui vengono usati dati di produzione reali, l'indice deve supportare funzionalità conformi a tutti i controlli di accesso e alle misure di tracciabilità. Esaminare le funzionalità di sicurezza, ad esempio maschera dati e la rimozione delle informazioni personali nell'indice.

    Scegliere un indice che abbia la possibilità di identificare in modo univoco i client tramite Microsoft Entra ID. L'indice di ricerca deve supportare anche i controlli di accesso a livello di documento per consentire la pertinenza delle query in base alle identità. Se l'indice non offre tali funzionalità, modificare la progettazione per ottenere funzionalità simili con i filtri di query. Per altre informazioni, vedere Filtri di sicurezza per la rimozione dei risultati in Ricerca di intelligenza artificiale.

    Idealmente, l'indice di ricerca deve essere allineato ai requisiti di sicurezza di rete. Ad esempio, se è necessario filtrare il traffico in uscita verso siti non Microsoft e mantenere l'osservabilità, l'indice deve offrire controlli in uscita. Deve anche supportare la segmentazione di rete. Se il calcolo back-end si trova in una rete virtuale, la connettività privata per i componenti chiave, incluso l'indice, è essenziale per evitare l'esposizione a Internet pubblico. L'indice deve essere facilmente integrato con le reti private e supportare le identità gestite per l'autenticazione tramite Microsoft Entra ID.

Considerazioni per un archivio funzionalità

Per i modelli discriminanti, la progettazione dei dati potrebbe includere un archivio dati intermedio che memorizza i dati nella cache per un perfezionamento aggiuntivo. Questo archivio, noto come archivio funzionalità, consente ai data scientist di archiviare le funzionalità come passaggio finale, all'esterno dell'archivio dati aggregato.

L'archivio funzionalità consente ai dati del catalogo per più usi aggiungendo metadati come il tempo di generazione e l'origine. Questo punto di destinazione intermedio è ideale per i dati di training golden.

Il archivio delle funzionalità gestite in Machine Learning è un'opzione di archiviazione dei dati che si integra con MLflow e altri strumenti. Recupera ed esegue il training dei dati dall'archivio dati aggregato, aggiungendo un livello riutilizzabile per migliorare la derivazione dei dati e l'identificazione formale all'interno di Machine Learning.

Quando si usa un archivio funzionalità, considerarlo come un archivio dati con considerazioni sulla sicurezza e sull'accesso.

Considerazioni per un archivio dati di inferenza offline

In alcuni scenari, l'uso di un archivio separato è appropriato per ricerche future più veloci perché l'inferenza viene eseguita in anticipo sui dati pre-raccolti e pre-calcolati. In questo processo, la richiesta dell'utente non raggiunge mai il modello di intelligenza artificiale. Esistono diversi vantaggi:

  • Miglioramento dell'efficienza e dell'esperienza utente riducendo la latenza. I risultati vengono serviti più velocemente per le query frequenti, ad esempio la generazione di domande frequenti come risultato.
  • Le chiamate di inferenza possono essere ridimensionate più facilmente come processo batch senza vincoli di elaborazione in tempo reale.
  • Consente la prevalidazione per garantire l'accuratezza prima dell'ambiente di produzione.
  • Poiché la richiesta non viene indirizzata all'endpoint di interferenza, riduce il carico, contribuendo all'affidabilità del carico di lavoro.
  • Potrebbe essere più conveniente perché riduce la necessità di hardware a prestazioni elevate necessarie per l'elaborazione in tempo reale.

Tuttavia, questo approccio è efficace solo se è possibile stimare le richieste possibili e si prevede che venga richiesta una parte significativa delle stime da parte degli utenti. Per gli scenari con meno richieste ripetute, un archivio di inferenza offline potrebbe essere meno efficace.

L'archivio dati per questo scenario deve essere ottimizzato per le operazioni di lettura, deve essere in grado di gestire grandi volumi di dati e fornire un recupero efficiente. Dovrebbe anche essere in grado di integrarsi nell'archivio dati aggregato. Qualsiasi archivio con queste funzionalità può essere considerato, ad esempio Azure Cosmos DB, o anche un archivio tabelle.

Risorse

Questi articoli forniscono altri dettagli sui prodotti Azure consigliati come opzioni tecnologiche per le considerazioni illustrate in questo articolo.

Passaggi successivi

Area di progettazione: MLOps e GenAIOps