Testare e valutare i carichi di lavoro di intelligenza artificiale in Azure
Lo scopo dei test nei carichi di lavoro di intelligenza artificiale è garantire la qualità quando viene introdotta una modifica al sistema. I test possono verificare se il carico di lavoro soddisfa le destinazioni identificate e soddisfa le aspettative degli utenti. Impedisce anche regressioni di qualità. Questo processo include l'esecuzione di test in varie aree funzionali e la valutazione della qualità delle funzionalità, della gestione del carico, della prevedibilità e di altri criteri in base ai requisiti del carico di lavoro.
I risultati dei test forniscono punti dati critici per decisioni come se i componenti di intelligenza artificiale sono pronti per il rilascio e quali SKU o funzionalità sono appropriati. Inoltre, i test possono fungere da sistema di notifica per gli errori e aiutare a rilevare i problemi nell'ambiente di produzione tramite test di routine o sintetici.
Azure Well-Architected Framework descrive una metodologia di test completa. È consigliabile usare vari tipi di test in diverse fasi del ciclo di vita di sviluppo e in diversi componenti e flussi di sistema. Senza questi test, le modifiche implementate possono compromettere la qualità del sistema. Ad esempio, errori di codice secondari potrebbero diventare errori di sistema di grandi dimensioni. Il comportamento del sistema potrebbe diventare imprevedibile o produrre risultati distorti a causa della natura non deterministica dei sistemi di intelligenza artificiale. Inoltre, l'allocazione delle risorse potrebbe essere inefficiente e i dati utente reali o le risorse di sistema possono essere sfruttati perché questi sistemi sono vulnerabili ad abusi.
È necessario progettare e sviluppare asset del carico di lavoro tenendo presente i test. Ad esempio, quando si eseguono la manipolazione dei dati e si modificano i dati di origine per la progettazione delle funzionalità, attenersi alle procedure di codifica consigliate e assicurarsi di strutturare il codice per supportare i test. Questa strategia include la progettazione del codice per facilitare unit test efficaci e isolare i test dalle funzionalità del codice e dalle relative dipendenze. In questo esempio è necessario progettare un sistema che possa essere eseguito in un ambiente di test con dati di test sufficientemente rappresentativi in termini di volume e somiglianza.
È necessario distribuire i componenti del carico di lavoro nell'ambiente di produzione in modo sicuro. Parte delle procedure di distribuzione sicura di qualsiasi carico di lavoro è il test strategico per garantire un comportamento corretto prima che gli utenti o i dati consumino il sistema. I test strategici sono essenziali durante la distribuzione iniziale e, man mano che il sistema evolve e subisce modifiche al codice o all'infrastruttura. Testare tutte le modifiche proposte al codice e all'infrastruttura correlati all'intelligenza artificiale prima di distribuire le modifiche nell'ambiente di produzione.
Questo articolo è incentrato sull'applicazione di tale metodologia agli aspetti di intelligenza artificiale dell'architettura. Come eseguire questi test non rientra nell'ambito.
Consigli
Ecco il riepilogo delle raccomandazioni fornite in questo articolo.
| Suggerimento | Descrizione |
|---|---|
| Definire le metriche di successo per la strategia di test. | Come qualsiasi altro tipo di test del carico di lavoro, è necessario acquisire e analizzare le metriche appropriate per un determinato test per assicurarsi che il test fornisca informazioni utili sul carico di lavoro di intelligenza artificiale. ▪ Definire le metriche di successo |
| Eseguire test end-to-end delle pipeline di inserimento ed elaborazione dei dati durante il ciclo di vita dello sviluppo. | I test possono convalidare i dati e garantire che il processo di manipolazione dei dati funzioni come previsto. Incorporare i test nelle fasi di progettazione per garantire la qualità dei dati e le scelte appropriate per la tecnologia e il dimensionamento. Sviluppare unit test per codice personalizzato durante lo sviluppo ed eseguire test di produzione in tempo reale per rilevare i problemi e convalidare le funzionalità. ▪ Testare l'inserimento dati |
| Eseguire test per i processi di training per assicurarsi che gli script vengano richiamati e funzionino come previsto. | I test di carico e prestazioni possono fornire informazioni dettagliate sulla scelta e sul dimensionamento delle risorse di calcolo adatte per l'esecuzione dei processi. Gli unit test possono convalidare l'utilità del codice e rilevare le regressioni quando le dipendenze vengono aggiornate. ▪ Testare il flusso di lavoro di training |
| Valutare e testare il modello per evitare la duplicazione nei dati di training, valutazione e test. | Per assicurarsi che i dati di origine non vengano interamente usati per il training, è necessario riservare dati univoci per la valutazione del modello e i test finali. Questi subset non sono inclusi nel processo di training effettivo. ▪ Valutare e testare il modello |
| Testare l'endpoint di inferenza. | Eseguire test di carico sull'endpoint ospitato dal server di inferenza e scegliere SKU GPU in base a tali risultati del test. Per gli endpoint ospitati dalla piattaforma distribuita come servizio (PaaS), testare la velocità effettiva e i potenziali errori. Questi endpoint sono raggiungibili, quindi eseguire test di sicurezza appropriati per evitare situazioni di jailbreak. ▪ Testare l'endpoint di inferenza |
| Testare la correttezza della progettazione dell'indice in modo che le query restituisca risultati pertinenti. | Il test funzionale e di integrazione consente di garantire che i dati siano accurati e che i controlli dei test dello schema dell'indice siano compatibili con le versioni precedenti. È necessario testare i passaggi di pre-elaborazione per la qualità. I test di carico determinano SKU adatti per le risorse e i controlli di sicurezza proteggono la riservatezza dei dati. ▪ Testare i dati di base |
| Testare l'agente di orchestrazione per convalidarne le funzionalità e la sicurezza. | Eseguire unit test, funzionali, di integrazione e di runtime, inclusi i test in modalità di carico e di errore, per garantire prestazioni e affidabilità. Anche i test di sicurezza e sicurezza dei contenuti sono fondamentali per proteggere il sistema e i dati. ▪ Testare l'agente di orchestrazione |
| Testare il decadimento del modello. | Il decadimento del modello è un problema inevitabile che interessa la maggior parte dei carichi di lavoro di intelligenza artificiale. I test per la deriva dei dati e dei concetti consentono di intercettare il decadimento del modello in anticipo e attenuare il problema prima che influisca negativamente sul carico di lavoro. ▪ Impedire il decadimento del modello |
Definire le metriche di successo
È consigliabile avere una baseline e misurare la potenza predittiva del modello usando metriche ben definite. Ecco alcune metriche comuni.
L'accuratezza rappresenta il rapporto tra le istanze stimate correttamente e le istanze totali nel set di dati di test. Si tratta di una misura comune delle prestazioni complessive del modello.
La precisione è il rapporto tra stime positive vere e la somma dei veri positivi e dei falsi positivi. È utile quando si riducono al minimo i falsi positivi è importante, ad esempio nelle diagnosi mediche.
La sensibilità misura il rapporto dei veri positivi alla somma dei veri positivi e dei falsi negativi. È utile quando si evitano falsi negativi o casi rilevanti mancanti è fondamentale.
La specificità calcola il rapporto dei veri negativi alla somma di veri negativi e falsi positivi. È rilevante quando si ottimizzano per stime negative accurate.
Nota
Quando si definiscono le metriche di successo per i modelli di regressione, è consigliabile aggiungere le metriche seguenti:
L'errore assoluto medio (MAE) misura la differenza assoluta media tra i valori stimati e i valori effettivi. Calcolarlo prendendo la media delle differenze assolute tra ogni valore effettivo e il valore stimato corrispondente. MAE è meno sensibile agli outlier rispetto a MSE e RMSE.
L'errore quadratico medio misura la differenza media quadrata tra i valori effettivi e i valori stimati. Calcolarlo prendendo la media delle differenze quadratiche tra ogni valore effettivo e il valore stimato corrispondente. Mse penalizza gli errori più grandi rispetto a MAE perché gli errori sono quadrati.
Radice errore quadratico medio (RMSE) è la radice quadrata dell'ambiente del servizio gestito. Fornisce una misura dell'errore assoluto medio tra i valori effettivi e stimati, ma nelle stesse unità dei dati originali. RMSE è più sensibile agli outlier rispetto a MAE perché piazza gli errori prima della media.
Testare l'inserimento dati
Pipeline di dati, ad esempio processi di estrazione, trasformazione e caricamento (ETL), spostamento e modifica dei dati. Testare la parte ETL del carico di lavoro per assicurarsi che inserisca i dati in modo affidabile e che i dati siano di alta qualità e accettabili per l'analisi e la progettazione delle funzionalità. Assicurarsi che la pulizia e l'elaborazione dei dati includano test per verificare che la manipolazione dei dati funzioni come previsto.
I test devono essere integrati in tutto il ciclo di vita, incluse le fasi di progettazione, sviluppo e produzione.
Test per facilitare le scelte di progettazione
Quando si raccolgono i requisiti per il carico di lavoro, un passaggio chiave per il processo decisionale consiste nel scegliere un'opzione tecnologica specifica valida per la progettazione.
In base ai requisiti ETL e ai criteri di accettazione, eseguire test funzionali esplorativi per selezionare il prodotto più adatto, gli SKU e le funzionalità che eseguono le attività previste. Il modello di verifica, la prova della tecnologia e i test di prova delle funzionalità sono essenziali per valutare se si sceglie la tecnologia giusta e se è appropriata.
Per gli scenari in cui si incorpora l'intelligenza artificiale in un'architettura esistente, testare il livello di integrazione della nuova tecnologia con il sistema corrente.
I requisiti iniziali del carico di lavoro possono cambiare. Si supponga che l'azienda prevede una crescita e che il sistema debba gestire le normali query utente. Questa previsione richiede una corretta pianificazione della capacità. È consigliabile eseguire test proattivi per comprendere in che modo il sistema risponde ai dati aggiuntivi e per apportare modifiche basate sui dati al ridimensionamento esistente o effettuare nuove scelte di prodotto. Per i test della capacità, è consigliabile combinare test funzionali con test di carico e prestazioni e usare sintetici per simulare condizioni realistiche.
Testare per garantire la qualità del codice
Quando viene incluso il codice, assicurarsi che venga sottoposto a unit test e che non venga rilasciato in caso di errore. Ad esempio, è comune avere codice personalizzato eseguito come parte dell'inserimento. È disponibile anche il codice usato per la pulizia e l'elaborazione dei dati. Eseguire unit test per assicurarsi che il codice si comporti in base alla progettazione e che la manipolazione dei dati funzioni come previsto.
Eseguire test come parte della pipeline di integrazione continua e recapito continuo.
Testare nel sistema live
I test funzionali devono estendersi al sistema attivo. Se questi test hanno esito negativo, valutare la possibilità di attivare avvisi per avviare indagini immediate, se necessario. Di seguito sono riportati alcuni esempi.
Eseguire test pianificati per verificare che il volume di dati corretto sia stato raccolto se i dati vengono inseriti in base a una pianificazione impostata con una quantità prevista.
Eseguire test che rilevano problemi di dati, ad esempio valori mancanti o dati duplicati, ed eseguire controlli di integrità dei dati di base. Se i dati contengono informazioni temporali che ne indicano l'aggiornamento, questi test possono controllare tali informazioni e potenzialmente impedire ai processi downstream di usare dati non aggiornati.
Controllare la disponibilità delle dipendenze esterne. Ad esempio, un processo di pulizia dei dati potrebbe chiamare un altro servizio per estrarre tabelle o pre-elaborazione. Eseguire test per assicurarsi che siano disponibili perché la mancata disponibilità potrebbe influire sul processo ETL.
Un altro modo per testare la correttezza del sistema ETL nell'ambiente di produzione consiste nell'eseguire test sintetici. La disponibilità di dati di test noti nell'ambiente di produzione è estremamente efficace. È possibile usarlo per convalidare l'elaborazione end-to-end confrontando lo stato iniziale noto con lo stato finale previsto per tali dati. Ad esempio, è necessario un documento per esaminare l'intelligence dei documenti e contenere dati personali. L'inserimento di un documento sintetico può verificare che il carico di lavoro esegua il processo di manipolazione dei dati come previsto.
Inoltre, sperimentare rilasciando esperienze diverse, note anche come test A/B, per apprendere dalle interazioni dell'utente prima di eseguire completamente il commit. I test A/B consentono di evitare regressioni di qualità.
Testare i dati raccolti durante l'inserimento
Nell'ambito del processo di inserimento da varie origini dati, includere test per verificare che i dati di training corrispondano alle aspettative.
Il training di un modello di Machine Learning con dati incompleti o danneggiati può essere controproducente. Potrebbe comportare uno spreco di sforzi e comportare un modello che non riesce a eseguire stime significative. Le pipeline di inserimento e pre-elaborazione dei dati includono test di qualità come checkpoint. Questi test consentono di verificare che i dati siano allineati alle aspettative impostate durante l'analisi dei dati e la progettazione delle funzionalità.
L'elenco seguente include alcuni test case di esempio:
Verificare la completezza. Testare la quantità prevista di dati di training per verificare la completezza del set di dati. Questo test garantisce di fornire dati sufficienti per eseguire il training del modello.
Testare la ricerca di informazioni critiche. Se il training è basato su entità note, ad esempio record o identificatori specifici, testare il set di dati per assicurarsi che tali entità siano presenti. Questa convalida garantisce che le informazioni critiche non siano mancanti.
Testare i dati irrilevanti. I dati inseriti non devono contenere voci irrilevanti o errate. Il processo di inserimento dati deve filtrare i dati.
Verificare la freschezza. L'aggiornamento dei dati inseriti non deve influire sulla potenza predittiva del modello. Verificare che i dati riflettano informazioni ragionevolmente correnti e non siano obsolete rispetto alle esecuzioni precedenti. Ad esempio, se si prevede che i dati includano record della settimana precedente, ma non sono presenti record di questo tipo dopo l'importazione dei dati, che potrebbero indicare un problema di importazione non riuscita o di aggiornamento dei dati nel sistema di origine.
Eseguire test di routine
Un problema significativo per l'inserimento dati è il volume di dati e velocità effettiva. La valutazione continua durante le operazioni è necessaria per evitare colli di bottiglia delle prestazioni. Questa valutazione in corso deve far parte dei processi operativi anziché solo un test monouso. L'obiettivo è garantire che il team del carico di lavoro non manchi gli obiettivi a livello di servizio.
Si consideri una situazione in cui il monitoraggio indica una riduzione delle prestazioni. Per attenuare tali condizioni, rivalutare e ottimizzare i processi ETL. Dopo aver apportato modifiche, i test delle prestazioni consentono di assicurarsi che le modifiche soddisfino la velocità effettiva richiesta.
Nota
I test e il monitoraggio servono a scopi diversi. Eseguire test per valutare le potenziali modifiche apportate al sistema, in genere prima di implementare le modifiche. Eseguire il monitoraggio continuamente per valutare l'integrità complessiva del sistema.
Testare il flusso di lavoro di training
Eseguire il training di un modello usando codice personalizzato, ad esempio script PyTorch, che eseguono il lavoro di training effettivo. Questi script vengono eseguiti in ambiente di calcolo, ad esempio nei notebook o nei processi di Azure Machine Learning, che richiedono anche risorse di memoria e rete. È consigliabile eseguire test di carico durante la fase di progettazione per valutare le esigenze di calcolo e assicurarsi che gli SKU proposti siano adatti. Spesso è necessario eseguire test manuali per determinare la configurazione migliore per eseguire in modo efficiente il carico di lavoro entro il limite di tempo.
Scrivere gli script usando SDK specializzati, che gestiscono la maggior parte delle attività. Tuttavia, poiché gli script sono ancora codice, è consigliabile integrare unit test come parte dello sviluppo. Questi test consentono di assicurarsi che non si verifichino regressioni quando si aggiornano le dipendenze. Se non è possibile eseguire unit test, è necessario eseguire test manuali prima di distribuire nuovo codice per evitare regressioni di qualità.
Questi script vengono eseguiti come parte di un flusso di lavoro, ad esempio studio di Azure Machine Learning, che possono fornire informazioni dettagliate su quando e se lo script è stato eseguito. È tuttavia consigliabile eseguire test di integrazione per assicurarsi che questi script vengano richiamati in modo affidabile.
Valutare e testare il modello
Nota
La valutazione e i test del modello vengono spesso usati in modo intercambiabile, ma devono essere considerati processi separati che usano set di dati distinti. La valutazione è un'attività iterativa eseguita durante la fase di sviluppo. Si concentra sulla sperimentazione per trovare il modello migliore con il giusto livello di ottimizzazione. Include la regolazione di iperparametri, configurazioni o funzionalità e quindi la valutazione del modello in base a varie metriche. Dopo aver identificato il modello migliore, eseguire test durante la distribuzione.
I test includono la verifica dell'intero sistema, inclusi il modello ottimizzato e i componenti non di intelligenza artificiale, per verificare che funzionino correttamente, integrano bene e offrono i risultati previsti in conformità agli standard di qualità. Valutare un modello in situ insieme ad altri componenti del carico di lavoro. Il processo include l'invio di richieste al modello, la valutazione delle risposte e l'esecuzione di una decisione go o no-go in base ai dati di test. Anche se i test non sono negoziabili prima della produzione, è consigliabile eseguire anche test nell'ambiente di produzione usando dati reali e dati sintetici.
Usare i dati per valutare e testare
In genere sono presenti tre set di dati chiave partizionati dai dati di origine: training, valutazione e test.
Usare il set di dati di training, che è in genere il subset più grande, per eseguire il training del modello. Usare un altro set di dati per la valutazione per perfezionare il modello tramite un processo iterativo valutando diverse permutazioni. Dopo aver trovato una permutazione soddisfacente, testarla sul set di dati di test.
Tutti i set di dati devono contenere dati di alta qualità per ridurre al minimo il rumore. I test case per l'inserimento dati e la pre-elaborazione delle pipeline possono fungere da checkpoint di qualità. Una mancanza di campioni può anche attribuire a dati di bassa qualità. Usare i dati sintetici per bilanciare e ottenere uniformità nel set di dati. Questo approccio è utile per i modelli di training come i modelli di rilevamento delle frodi, in cui le istanze di frode reali sono rare, rendendo difficile ottenere una potenza statistica sufficiente per stime affidabili.
Per evitare distorsioni nelle stime, mantenere distinti tutti i set di dati. Non è consigliabile usare i dati di training per la valutazione e non usare i dati di valutazione per i test. Riservare dati univoci per la valutazione del modello e il test finale.
Usare le metriche di valutazione
Eseguire il training di un modello e selezionare quello giusto per la produzione sono processi interdipendenti. È necessario scegliere inizialmente un modello, ma potrebbe cambiare dopo la sperimentazione e la valutazione.
La valutazione del modello segue come ciclo di sperimentazione che valuta numerose permutazioni di modelli, parametri e funzionalità usando le metriche. Queste metriche forniscono valutazioni scientifiche, che è necessario confrontare in modo iterativo tra versioni e configurazioni diverse per determinare il modello migliore. Per altre informazioni, vedere Metriche di valutazione.
Un approccio simile si applica ai modelli di intelligenza artificiale generativi. Disporre di processi che valutano e quantificano i risultati dell'esperienza utente in base alle prestazioni del modello. Ad esempio, la base è una delle metriche chiave che quantifica il modo in cui il modello è allineato ai dati di origine. La pertinenza è un'altra metrica importante che indica come è pertinente la risposta alla query. Per le metriche di esempio, vedere Valutazione e monitoraggio delle metriche per l'intelligenza artificiale generativa.
Valutare diversi tipi di modelli usando varie metriche. L'importanza di ogni metrica può variare a seconda dello scenario. Classificare le metriche in ordine di priorità in base al caso d'uso. Ad esempio, l'equità è fondamentale nell'IA responsabile. Nonostante test validi, i modelli possono comunque presentare distorsioni ingiuste a causa di dati di origine distorti. I risultati potrebbero segnare un punteggio elevato di pertinenza, ma bassa equità. Integrare valutazioni di equità nel processo per garantire risultati non distorti.
L'intelligenza artificiale generativa si integra con il codice di orchestrazione, la logica di routing e un indice per la generazione avanzata del recupero (RAG), che complica la valutazione. Anche se è consigliabile valutare i modelli singolarmente usando le metriche, è anche importante valutare altri componenti di sistema.
Test del modello
L'ottimizzazione consiste essenzialmente nel test perché modifica un modello con training preliminare per modificarne il comportamento. È necessario iniziare con una baseline per comprendere le prestazioni iniziali del modello. Dopo l'ottimizzazione, rivalutare le prestazioni del modello per garantire che soddisfi gli standard di qualità. Considerare le metriche di valutazione comuni seguenti:
Il livello di base si riferisce all'allineamento del modello con i dati di origine. Un modello a terra genera risposte coerenti con la realtà.
La pertinenza indica quanto sia pertinente la risposta a una determinata domanda. Una risposta altamente basata potrebbe non avere pertinenza se non risolve direttamente la domanda.
La somiglianza misura la somiglianza tra un testo dei dati di origine e la risposta generata. Il modello ha usato parole precise? Una mancanza di governance editoriale può ridurre il punteggio di somiglianza.
Il recupero indica l'efficacia delle query sugli indici. Valutare l'allineamento dei dati dell'indice recuperati alla domanda. I dati irrilevanti della ricerca nell'indice abbassano questo punteggio. I punteggi di recupero più elevati indicano una variabilità inferiore perché si basano esclusivamente sulle query sugli indici.
La fluency si riferisce all'utilizzo del vocabolario. Se il modello è conforme a una guida di stile e presenta il contenuto nel formato appropriato, può essere fluente anche se non dispone di elementi di base o di pertinenza.
La coerenza valuta se il parlato del modello scorre in modo naturale e coerente. Valuta se la conversazione si sente come uno scambio autentico.
Testare gli iperparametri
I parametri del modello dipendono dalle decisioni di progettazione specifiche dell'applicazione. Come parte della progettazione dell'applicazione, scegliere il modello e i parametri in base ai casi d'uso del carico di lavoro. Il processo di test ha un ciclo interno iterativo in cui i dati di training sono confrontati con i dati di test per verificare che il modello sia sottoposto a training nel set di dati previsto. Inoltre, i parametri vengono ottimizzati in modo che il modello possa eseguire stime con un livello di accuratezza accettabile.
Compromesso. Il ciclo interno include i costi di calcolo del training del modello e il costo della valutazione tramite test. È necessario tenere conto del tempo necessario per il training e il test del modello in questo ciclo. Si prevede che il processo di test richiede più tempo del processo di training. È possibile eseguire test iniziali su un subset di dati di training per valutare se il modello produce risultati ragionevoli. È possibile aumentare gradualmente il numero di test impostato sul set di dati completo.
Testare l'endpoint di inferenza
Un endpoint di inferenza è l'API REST che consente l'accesso ai modelli per eseguire stime. Si tratta dell'interfaccia in cui si inviano dati come parte della richiesta e si ottiene una risposta che contiene i risultati del modello. L'endpoint è ospitato in ambiente di calcolo, che può essere PaaS come il servizio OpenAI di Azure o un server di inferenza non Microsoft, ad esempio il server di inferenza NVIDIA Xaml, TorchServe e BentoML. Negli scenari PaaS, il provider di servizi gestisce il test in una certa misura. Tuttavia, se si ospita l'endpoint, considerarlo come qualsiasi altra API e testarlo accuratamente.
Anche se si testa il modello durante il training e la valutazione, il test dell'endpoint di inferenza comporta la corretta esecuzione dei meccanismi relativi a tale modello, ad esempio l'elaborazione delle richieste, la creazione della risposta, il ridimensionamento e il coordinamento tra istanze. Creare un piano di test completo che copre i casi d'uso in base alle esigenze. In questa sezione vengono descritti alcuni test case di esempio e tipi di test da considerare.
Considerazioni sul test per i server di hosting dell'inferenza
È importante comprendere le caratteristiche di carico del calcolo e convalidare le prestazioni tramite test di carico. Queste azioni consentono di scegliere tecnologie quando si progetta o si ottimizza l'architettura. Ad esempio, server di inferenza diversi hanno caratteristiche di prestazioni variabili. Il codice utilizza cicli di CPU e memoria man mano che aumenta il numero di connessioni simultanee. Informazioni sulle prestazioni del codice e delle risorse di calcolo in condizioni di carico standard e di picco. Test di carico di Azure è un'opzione valida per i test di carico e può generare un carico di volume elevato. Altre opzioni open source, come Apache JMeter, sono anche popolari. Prendere in considerazione la possibilità di richiamare questi test direttamente dall'ambiente. Ad esempio, Machine Learning si integra bene con test di carico.
Un'altra decisione chiave è la scelta delle funzionalità GPU. Molti modelli richiedono GPU per un'inferenza efficace a causa della progettazione. I test di carico consentono di comprendere i limiti di prestazioni di uno SKU GPU e di evitare l'overprovisioning, che sono importanti considerazioni finanziarie.
Per le piattaforme di hosting non PaaS, la sicurezza è fondamentale perché l'API viene esposta pubblicamente. È importante assicurarsi che l'endpoint non venga sfruttato o compromesso, che può compromettere l'intero sistema. Includere questo endpoint come parte dei test di sicurezza di routine insieme ad altri endpoint pubblici. Prendere in considerazione l'esecuzione di test, ad esempio test di penetrazione, nel sistema live. Un altro aspetto della sicurezza è la sicurezza dei contenuti. Il codice può chiamare api specializzate che rilevano contenuto dannoso nel payload della richiesta e della risposta. La sicurezza dei contenuti di Azure per intelligenza artificiale può essere chiamata dai test per facilitare i test di sicurezza dei contenuti.
Per le strategie chiave, vedere Raccomandazioni per i test di sicurezza.
Considerazioni sul test per gli endpoint di inferenza PaaS
Il client deve prevedere errori quando invia richieste all'endpoint di inferenza nel servizio PaaS. Gli errori possono verificarsi a causa dell'overload del sistema, dei back-end non rispondenti e di altre condizioni di errore. Eseguire l'analisi della modalità di errore nel servizio e testare tali potenziali errori. L'analisi della modalità di errore è necessaria per progettare e implementare strategie di mitigazione nel codice client. Ad esempio, le API OpenAI di Azure limitano le richieste restituendo un codice di risposta di errore HTTP 429. Il client deve gestire tale errore usando meccanismi di ripetizione dei tentativi e interruttori di circuito. Per maggiori informazioni, consultare la sezione Raccomandazioni per l'esecuzione dell'analisi della modalità di errore.
Il test dei servizi PaaS consente di selezionare gli SKU del servizio perché si conoscono i costi associati, ad esempio il calcolo con pagamento in base al consumo o il provisioning preliminare. Usare i calcolatori dei prezzi di Azure per valutare i carichi di lavoro, la frequenza e l'utilizzo dei token per determinare le opzioni di fatturazione e calcolo migliori. Simulare carichi di lavoro con SKU a basso costo e giustificare opzioni di fascia alta, ad esempio unità elaborate con provisioning (PTU) per Azure OpenAI.
I test di carico non sono rilevanti per il calcolo con pagamento in base al consumo perché, con capacità infinita, non si verificano problemi. Il test convalida i limiti e le quote. Non è consigliabile testare il carico per il calcolo con pagamento in base al consumo perché è una spesa finanziaria significativa. Tuttavia, è necessario testare di carico per verificare la velocità effettiva, misurata in token al minuto o richieste al minuto. A differenza delle API standard che considerano metriche come le dimensioni delle richieste, questo approccio valuta i carichi di lavoro in base ai token per determinare l'utilizzo. La chiave consiste nel comprendere il numero di utenti attivi e misurare la velocità effettiva di conseguenza. Per altre informazioni, vedere Misurare la velocità effettiva.
Usare i controlli di sicurezza
Indipendentemente dal fatto che si usi un server di inferenza o un'opzione PaaS, la sicurezza è responsabilità dell'utente. Con gli endpoint API, è fondamentale testare i controlli di sicurezza per il jailbreak e il contenuto. Assicurarsi che questi controlli non possano essere ignorati e funzionino come previsto. Ad esempio, l'invio di un elemento bloccato noto consente di verificare se i controlli di sicurezza sono presenti e funzionano correttamente prima della distribuzione. Prendere in considerazione l'esecuzione di questi test in base alle esigenze o integrarli nel processo di rilascio.
È importante verificare se il sistema può esporre inavvertitamente informazioni che non dovrebbe. Ad esempio, il sistema non deve esporre informazioni personali nel payload della risposta. Testare anche per assicurarsi che un client non possa accedere agli endpoint destinati ad altre identità. Eseguire test di sicurezza per verificare che l'API, con i relativi meccanismi di autenticazione e autorizzazione, non trapeli informazioni riservate e gestisca una segmentazione utente corretta.
Testare i dati di base
La progettazione dei dati influenza l'efficienza di un modello generativo e i dati di base sono il componente critico. I dati di base forniscono più contesto per aumentare la pertinenza della risposta. Viene indicizzato prima di raggiungere il modello. Questo indice è accessibile in tempo reale quando l'utente attende una risposta.
Eseguire test end-to-end e incorporare tale processo come parte della progettazione dei dati. Implementare un processo di test che valuta e quantifica i risultati dell'esperienza del cliente in base alle prestazioni, all'orchestrazione, all'indice, alla pre-elaborazione e ai dati di origine del modello. Monitorare e misurare le metriche di qualità in modo iterativo. Ecco alcune considerazioni:
Testare accuratamente l'elaborazione dei dati usando test funzionali e di integrazione. Verificare che i dati vengano caricati come previsto e che tutti i dati siano presenti.
Testare lo schema dell'indice per garantire la compatibilità con le versioni precedenti. È consigliabile testare le modifiche apportate a un documento o a un campo per assicurarsi che la nuova versione possa comunque contenere versioni precedenti dei dati.
Prima che i dati vengano indicizzati, vengono sottoposti a preparazione per ridurre il rumore e la distorsione e abilitare query efficienti. Questo processo include la pre-elaborazione, la suddivisione in blocchi e il calcolo degli incorporamenti e ogni passaggio salva i dati nel contesto o nei file nell'indice. Una pipeline di orchestrazione, ad esempio i set di competenze forniti da Ricerca di intelligenza artificiale di Azure, esegue questi passaggi. È necessario testare il codice di orchestrazione per assicurarsi che non vengano superati passaggi e che i dati elaborati siano di alta qualità.
I test devono verificare la presenza di dati obsoleti, valori sintetici, tabelle vuote, aggiornamento dati ed elaborazione nella versione più recente. Se si verificano errori di test, potrebbe essere necessario modificare la query di ricerca e l'indice. Questo processo include la modifica dei filtri e altri elementi illustrati in precedenza. È consigliabile considerare il test come un'attività iterativa.
Gli indici sono complessi e le prestazioni delle query possono variare in base alla struttura dell'indice, che richiede una stima del carico. I test di carico appropriati consentono di determinare i diversi SKU per l'archiviazione, il calcolo e altre risorse disponibili per supportare i requisiti.
È necessario testare tutti i controlli di sicurezza. Ad esempio, i dati potrebbero essere partizionati in documenti separati. Ogni partizione ha controlli di accesso. È necessario testare correttamente tali controlli per proteggere la riservatezza.
Testare l'agente di orchestrazione
Un componente chiave di un'applicazione RAG è l'agente di orchestrazione centrale. Questo codice coordina varie attività correlate alla domanda iniziale dell'utente. Le attività dell'agente di orchestrazione richiedono in genere una comprensione della finalità dell'utente, una connessione all'indice per cercare i dati di base e chiamare l'endpoint di inferenza. Se gli agenti devono eseguire attività, ad esempio la chiamata alle API REST, questo codice gestisce tali attività all'interno del contesto.
È possibile sviluppare codice di orchestrazione in qualsiasi linguaggio o scriverlo da zero. È tuttavia consigliabile usare tecnologie come il "prompt flow" nel portale di Azure AI Foundry o i grafici aciclici diretti (DAG) di Apache Airflow per velocizzare e semplificare il processo di sviluppo. Il flusso prompt offre un'esperienza di progettazione. Usarlo per modularizzare le attività come unità e connettere input e output di ogni unità, formando infine il codice di orchestrazione, che rappresenta l'intero processo.
Isolare il codice di orchestrazione. Svilupparlo separatamente e distribuirlo come microservizio con un endpoint online e un'API REST per l'accesso. Questo approccio garantisce la modularità e la facilità di distribuzione.
Dal punto di vista dei test, trattare questo codice come qualsiasi altro codice ed eseguire unit test. Tuttavia, l'aspetto più importante è la funzionalità, ad esempio la logica di routing, che è possibile convalidare tramite test funzionali e di integrazione. Progettazione della richiesta di test per assicurarsi che il codice possa rilevare le finalità dell'utente e instradare le chiamate in modo appropriato. Sono disponibili diversi framework e librerie per i test, ad esempio Scikit-learn, il modulo torch.testing di PyTorch, FairML per i test di distorsione e equità e l'analisi del modello TensorFlow per la valutazione del modello.
Eseguire anche test di runtime, ad esempio test in modalità di errore. Ad esempio, testare potenziali errori correlati alle limitazioni dei token.
Alcuni test di runtime possono essere utili per prendere una decisione. Eseguire test di carico per comprendere il comportamento di questo codice sotto stress e usare i risultati per la pianificazione della capacità. Poiché questo codice è posizionato in un punto cruciale nell'architettura in cui deve raggiungere altri servizi, può aiutare a raccogliere i dati di telemetria da tutte queste chiamate. Questi dati possono fornire informazioni dettagliate sulla quantità di tempo impiegato per l'elaborazione locale rispetto alle chiamate di rete e determinare il comportamento di altri componenti, ad esempio la potenziale latenza. Tecnologie come il flusso di richiesta hanno funzionalità di telemetria predefinite per facilitare questo processo. In caso contrario, incorporare i dati di telemetria nel codice personalizzato.
Nota
Il test di questo codice ha implicazioni in termini di costi. Ad esempio, se si usa Azure OpenAI per ospitare l'endpoint di inferenza, i test di stress sono una pratica comune che consente di determinare i limiti del sistema. Tuttavia, Azure OpenAI addebita costi per ogni chiamata, che può rendere costosi test di stress estesi. Un modo per ottimizzare gli addebiti consiste nell'usare PTU inutilizzati di Azure OpenAI in un ambiente di test. In alternativa, è possibile simulare l'endpoint di inferenza.
I problemi di sicurezza si applicano sia al codice di orchestrazione che al modello. Includere test per il jailbreaking, dove l'obiettivo è interrompere la sicurezza del modello. Gli utenti malintenzionati non interagiscono direttamente con il modello. Interagiscono prima con il codice di orchestrazione. Il codice di orchestrazione riceve le richieste utente e le analizza. Se il codice di orchestrazione riceve una richiesta dannosa, può inoltrare tale richiesta al modello e potenzialmente compromettere il modello.
La sicurezza dei contenuti è un altro aspetto importante. In un'applicazione chatbot il codice di orchestrazione riceve il testo della chat. Nel codice prendere in considerazione la chiamata a un servizio di sicurezza del contenuto. Inviare sia il prompt dell'utente che il contesto di base per l'analisi e ricevere una valutazione del rischio. Prompt Shields è un'API unificata che analizza gli input del modello linguistico di grandi dimensioni e rileva attacchi di richiesta utente e attacchi documentali, che sono due tipi comuni di input antagonisti.
Il controllo di sicurezza e l'autenticazione sono fondamentali per un endpoint RESTful. È necessario gestire l'autenticazione e garantire test accurati.
Impedire il decadimento del modello
Un problema comune per tutti i modelli è un certo grado di riduzione nel tempo. Le modifiche interne ed esterne al carico di lavoro alla fine causano una riduzione della qualità del modello e dei relativi output. Il decadimento del modello si verifica in due modi:
La deriva dei dati si verifica quando i dati di input cambiano. Il nuovo input di dati rende il modello sottoposto a training non aggiornato. Ad esempio, si potrebbe avere un modello che stima i modelli di voto di una determinata area geografica, ad esempio un distretto. Se il distretto viene ridisegnato e i dati demografici della popolazione di tale distretto cambiano, il modello deve essere aggiornato per tenere conto delle modifiche.
La deriva del concetto si verifica quando le condizioni esterne al carico di lavoro e al modello cambiano in modo che l'output del modello non corrisponda più alla realtà. Ad esempio, potrebbe essere disponibile un modello di previsione delle vendite per un prodotto tecnologico. Se un concorrente introduce in modo imprevisto un prodotto concorrente più avanzato che attira un'attenzione significativa dal pubblico, è necessario aggiornare il modello in base al cambiamento delle tendenze dei consumatori.
Quando possibile, usare test automatizzati per rilevare e valutare il decadimento del modello nel ciclo di vita del modello. Se il modello stima valori discreti, è possibile creare test per valutare le stime rispetto a tali valori nel tempo e misurare la deviazione tra i risultati previsti e effettivi. Integrare questo test con il monitoraggio per rilevare la deriva nel tempo confrontando le statistiche di riepilogo e le metriche di distanza.
Un altro approccio comune per identificare il decadimento del modello è il feedback degli utenti. Un esempio di feedback degli utenti è un meccanismo di risposta thumbs up o thumbs down. Tenere traccia del feedback positivo o negativo nel tempo e creare un avviso quando si soddisfa una soglia di feedback negativo può aiutare a sapere quando analizzare la qualità del modello.
Indipendentemente dai segnali usati per identificare il decadimento del modello, il team operativo avvisato del potenziale decadimento deve coinvolgere un data scientist per cercare il segnale e determinare se il decadimento sta accadendo e la causa radice.
Implementare gli strumenti
Usare l'agente di raccolta dati di Azure Machine Learning per ottenere la registrazione in tempo reale dei dati di input e output dai modelli distribuiti agli endpoint online gestiti o agli endpoint online Kubernetes. Machine Learning archivia i dati di inferenza registrati nell'archivio BLOB di Azure. È quindi possibile usare questi dati per il monitoraggio del modello, il debug o il controllo, che offre l'osservabilità delle prestazioni dei modelli distribuiti. Se si distribuisce un modello all'esterno di Machine Learning o in un endpoint batch di Machine Learning, non è possibile sfruttare i vantaggi dell'agente di raccolta dati e dover rendere operativo un altro processo di raccolta dati.
Usare il monitoraggio del modello di Machine Learning per implementare il monitoraggio. Machine Learning acquisisce i segnali di monitoraggio eseguendo calcoli statistici su dati di inferenza di produzione trasmessi e dati di riferimento. I dati di riferimento possono essere dati di training cronologici, dati di convalida o dati di verità di base. D'altra parte, i dati di inferenza di produzione fanno riferimento ai dati di input e output dei modelli raccolti nell'ambiente di produzione.
- Vedere Monitoraggio dei modelli di Machine Learning per informazioni sulle funzionalità di monitoraggio di Machine Learning e sulle metriche acquisite e analizzate.
- Per altre raccomandazioni per il monitoraggio, vedere le procedure consigliate .