Il CI/CD per i progetti di IA non è identico al CI/CD per il software tradizionale. L’ho imparato a mie spese quando il mio pipeline GitHub Actions perfettamente configurato ha distribuito un aggiornamento del modello di IA che funzionava perfettamente in test ma produceva risultati mediocri in produzione.
Il problema: la mia suite di test validava la logica del codice, ma non il comportamento del modello. Il codice era corretto. Le uscite del modello erano cambiate a causa di una modifica del prompt che superava tutti i test di codice ma modificava fondamentalmente il comportamento dell’agente in modo che i miei test non potevano rilevare.
Il CI/CD tradizionale presuppone uscite deterministiche: data l’entrata X, ci si aspetta un’uscita Y. I sistemi di IA hanno uscite probabilistiche: data l’entrata X, ci si aspetta un’uscita che sia approssimativamente Y, la maggior parte delle volte, a seconda dell’umore attuale del modello.
Come appare un pipeline CI/CD per l’IA
Il mio pipeline ha cinque fasi, rispetto alle tre abituali (costruzione, test, distribuzione):
Fase 1: Costruzione. Standard. Installare le dipendenze, compilare se necessario, impacchettare l’applicazione. Nulla di specifico per l’IA qui.
Fase 2: Test di codice. Test unitari e di integrazione standard. Il codice fa ciò che deve fare? Le funzioni sono corrette? Le API rispondono? Questo rileva i bug nella logica dell’applicazione ma non testa il comportamento dell’IA.
Fase 3: Test di comportamento. Questa è la fase specifica per l’IA. Inviare prompt di test all’agente e valutare le risposte. Non per corrispondenze esatte — per criteri comportamentali: «La risposta menziona i fatti chiave? Il tono è appropriato? Resta nei propri limiti? Hallucina?»
Ho 15 casi di test comportamentali che coprono i comportamenti più critici dell’agente. Ogni test invia un prompt e valuta la risposta rispetto a una lista di controllo. Un umano ha definito i comportamenti attesi iniziali; il pipeline CI verifica che l’agente corrisponda ancora a queste aspettative.
Fase 4: Distribuzione canary. Distribuire in un ambiente di staging e instradare una piccola percentuale del traffico reale verso di esso. Monitorare per 30 minuti. Se i tassi di errore sono normali e la qualità del comportamento è mantenuta, continuare. Altrimenti, tornare indietro automaticamente.
Fase 5: Distribuzione completa. Distribuire in produzione. Monitorare per 2 ore con avvisi rinforzati.
La sfida dei test comportamentali
I test comportamentali sono la parte più difficile del CI/CD per l’IA perché le risposte dell’IA variano. Lo stesso prompt può produrre risposte diverse ogni volta. Come scrivi un test per qualcosa di non deterministico?
Il mio approccio: testare le restrizioni piuttosto che uscite specifiche.
Invece di: «La risposta deve essere esattamente ‘Il tempo a Londra è di 18°C.’»
Testare per: «La risposta deve menzionare Londra. La risposta deve includere una temperatura. La risposta non deve assumere di conoscere il tempo reale (l’agente non ha accesso al tempo in questo test).»
Questo test basato su restrizioni è più solido del test di corrispondenza esatta. Rileva le regressioni comportamentali (l’agente smette di menzionare Londra) senza fallire per variazioni innocue (la formulazione cambia da un test all’altro).
I cambiamenti di prompt sono distribuzioni
Questo è il cambiamento di mentalità più grande per il CI/CD di IA: un cambiamento di prompt è una distribuzione, non una semplice modifica di testo.
Modificare il tuo prompt di sistema può alterare ogni risposta prodotta dall’agente. È l’equivalente di rifattorizzare ogni funzione del tuo codice simultaneamente. Tuttavia, la maggior parte delle persone modifica i prompt in modo disinvolto, senza test, versioning o piani di rollback.
La mia regola: i cambiamenti di prompt devono seguire lo stesso pipeline CI/CD dei cambiamenti di codice. Modificare il prompt in un ramo, eseguire test comportamentali, esaminare la differenza, unire nel ramo principale, distribuire tramite il pipeline. Se i test comportamentali falliscono, il cambiamento di prompt viene respinto.
Monitoraggio post-distribuzione
Le distribuzioni di IA richiedono un monitoraggio diverso rispetto alle distribuzioni tradizionali:
Punteggio di qualità delle risposte. Un valutatore leggero che attribuisce un punteggio a ogni risposta su una scala da 1 a 5 per pertinenza, accuratezza e utilità. Il punteggio è approssimativo (è anche valutato dall’IA, il che è di per sé interessante), ma rileva i cali di qualità drammatici.
Tasso di allucinazione. Monitorare con quale frequenza l’agente fa affermazioni che non si basano sui suoi dati disponibili. Un aumento del tasso di allucinazione dopo una distribuzione significa che il cambiamento di prompt o di modello ha introdotto fabulazione.
Feedback degli utenti. Pollice in su/giù sulle risposte dell’agente. Il segnale di qualità più affidabile, ma con il volume più basso. Utile per l’analisi delle tendenze su più giorni, ma non per rilevare problemi in pochi minuti.
Costo per interazione. Una distribuzione che rende l’agente più verboso (risposte più lunghe, più chiamate agli strumenti) aumenterà i costi. Monitorare questo per rilevare aumenti di costi non desiderati.
Il ritorno sugli investimenti del CI/CD per l’IA
Impostare questo pipeline mi ha preso circa una settimana. Mantenere richiede circa 2 ore al mese (aggiornamento dei test comportamentali, revisione delle distribuzioni canary).
Da quando è stato implementato, ho rilevato: 3 cambiamenti di prompt che avrebbero degradato la qualità, 2 aggiornamenti delle dipendenze che hanno rotto integrazioni di strumenti, e 1 cambiamento di fornitore di modello che ha modificato il comportamento delle risposte. Ognuna di queste situazioni sarebbe stata un incidente di produzione senza il pipeline.
Il pipeline non rallenta le distribuzioni — le fasi automatizzate richiedono circa 5 minuti. Rende le distribuzioni più sicure. E distribuzioni sicure sono quelle che si eseguono realmente con regolarità, il che significa che il tuo agente rimane aggiornato invece di funzionare su una versione vecchia di mesi perché hai paura di aggiornare.
🕒 Published: