CI/CD per progetti AI non è come CI/CD per software tradizionale. L’ho imparato a mie spese quando il mio pipeline di GitHub Actions perfettamente configurato ha distribuito un aggiornamento del modello AI che funzionava senza problemi nei test ma produceva risultati scadenti in produzione.
Il problema: il mio 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 un cambiamento del prompt che aveva superato tutti i test del codice ma aveva alterato fondamentalmente il comportamento dell’agente in modi che i miei test non potevano catturare.
Il CI/CD tradizionale presume uscite deterministiche: dato l’input X, ci si aspetta l’uscita Y. I sistemi AI hanno uscite probabilistiche: dato l’input X, ci si aspetta un’uscita che è approssimativamente Y, nella maggior parte dei casi, a seconda dell’umore attuale del modello.
Come appare un Pipeline CI/CD per AI
Il mio pipeline ha cinque fasi, rispetto alle tipiche tre (build, test, deploy):
Fase 1: Build. Standard. Installa dipendenze, compila se necessario, impacchetta l’applicazione. Niente di specifico per l’AI qui.
Fase 2: Test del codice. Test unitari e di integrazione standard. Il codice fa ciò che deve? Le funzioni sono corrette? Le API rispondono? Questo cattura bug nella logica dell’applicazione ma non testa il comportamento dell’AI.
Fase 3: Test comportamentali. Questa è la fase specifica per l’AI. Invia prompt di prova all’agente e valuta le risposte. Non per corrispondenze esatte — per criteri comportamentali: “La risposta menziona i fatti chiave? Il tono è appropriato? Rimane nei suoi limiti? Hallucina?”
Ho 15 casi di test comportamentali che coprono i comportamenti critici dell’agente. Ogni test invia un prompt e valuta la risposta contro un elenco di controllo. Un umano ha impostato i comportamenti attesi iniziali; il pipeline CI verifica che l’agente soddisfi ancora tali criteri.
Fase 4: Distribuzione canary. Distribuisci in un ambiente di staging e instrada una piccola percentuale di traffico reale verso di esso. Monitora per 30 minuti. Se i tassi di errore sono normali e la qualità comportamentale si mantiene, procedi. In caso contrario, rollback automatico.
Fase 5: Distribuzione completa. Rilascia in produzione. Monitora per 2 ore con allerta migliorata.
La sfida dei test comportamentali
I test comportamentali sono la parte più difficile del CI/CD per AI perché le risposte dell’AI variano. Lo stesso prompt può produrre risposte diverse ogni volta. Come scrivi un test per qualcosa di non deterministico?
Il mio approccio: testare per vincoli piuttosto che per uscite specifiche.
Invece di: “La risposta deve essere esattamente ‘Il tempo a Londra è di 18°C.’”
Testa per: “La risposta deve menzionare Londra. La risposta deve includere una temperatura. La risposta non deve pretendere di conoscere il meteo in tempo reale (l’agente non ha accesso al meteo in questo test).”
Questo testing basato su vincoli è più solido del testing per corrispondenza esatta. Cattura le regressioni comportamentali (l’agente smette di menzionare Londra) senza rompersi a causa di variazioni innocue (la formulazione cambia tra i run).
I cambiamenti nei prompt sono distribuzioni
Questo è il maggiore cambiamento di mentalità per il CI/CD per AI: un cambiamento nel prompt è una distribuzione, non una modifica di testo.
Cambiare il prompt del tuo sistema può alterare ogni risposta prodotta dall’agente. È equivalente a rifattorizzare ogni funzione nel tuo codice simultaneamente. Eppure, la maggior parte delle persone modifica i prompt in modo informale, senza test, versioning o piani di rollback.
La mia regola: i cambiamenti nei prompt devono passare attraverso lo stesso pipeline CI/CD delle modifiche al codice. Modifica il prompt in un branch, esegui test comportamentali, rivedi le differenze, unisci al main, distribuisci attraverso il pipeline. Se i test comportamentali falliscono, il cambiamento del prompt viene rifiutato.
Monitoraggio post-distribuzione
Le distribuzioni AI necessitano di un monitoraggio diverso rispetto alle distribuzioni tradizionali:
Punteggio di qualità della risposta. Un valutatore leggero che assegna un punteggio a ciascuna risposta su una scala da 1 a 5 per rilevanza, accuratezza e utilità. Il punteggio è approssimativo (è anche valutato dall’AI, il che è meta), ma cattura drastici cali di qualità.
Percentuale di allucinazioni. Tieni traccia di quanto spesso l’agente fa affermazioni che non sono supportate dai suoi dati disponibili. Un picco della percentuale di allucinazioni dopo una distribuzione indica che il cambiamento del prompt o del modello ha introdotto confabulazione.
Feedback degli utenti. Pollice su/giù sulle risposte dell’agente. Il segnale di qualità più affidabile, ma con il volume più basso. Utile per l’analisi delle tendenze nel corso dei giorni, non per catturare problemi in minuti.
Costi per interazione. Una distribuzione che rende l’agente più verboso (risposte più lunghe, più chiamate a strumenti) aumenterà i costi. Tieni traccia di questo per catturare aumenti di costo non intenzionali.
Il ROI del CI/CD per AI
Impostare questo pipeline mi ha preso circa una settimana. Mantenere richiede circa 2 ore al mese (aggiornamento dei test comportamentali, revisione delle distribuzioni canary).
Dalla sua implementazione, ho catturato: 3 cambiamenti di prompt che avrebbero degradato la qualità, 2 aggiornamenti di dipendenze che hanno rotto le integrazioni degli strumenti, e 1 cambiamento di fornitore di modello che ha alterato il comportamento delle risposte. Ognuno di questi avrebbe comportato un incidente di produzione senza il pipeline.
Il pipeline non rende le distribuzioni più lente — le fasi automatizzate richiedono circa 5 minuti. Rende le distribuzioni più sicure. E le distribuzioni sicure sono quelle che effettivamente fai regolarmente, il che significa che il tuo agente resta attuale invece di eseguire una versione vecchia di mesi perché hai paura di aggiornare.
🕒 Published: