Perché gli agenti di intelligenza artificiale superano i test di qualità e falliscono comunque in produzione

L’apprendimento continuo sta diventando la disciplina ingegneristica per migliorare gli agenti dopo il deploy, senza rompere ciò che già funzionava.

Un agente di intelligenza artificiale può superare ogni valutazione pre-lancio e fallire comunque in produzione una settimana dopo. Ciò non è una contraddizione. L’insieme di valutazione riflette ciò che il team sapeva testare prima del lancio. La produzione è dove appaiono i casi mancanti: strane formulazioni, contesto mancante, casi limite degli strumenti, utenti impazienti, politiche conflittuali e flussi di lavoro che nessun progettista di benchmark ha immaginato.

L’agente viene corretto dagli utenti tutto il tempo. Delude gli utenti. Quindi la sessione si conclude, il log viene archiviato e il prossimo utente incontra sostanzialmente lo stesso sistema.

Questo è il motivo per cui l’apprendimento continuo sta diventando centrale per l’ingegneria degli agenti. Non è una funzione di un prodotto. È una categoria di metodi per migliorare gli agenti dall’esperienza mentre si preserva ciò che già funziona. La ricerca classica sull’apprendimento continuo ha inquadrato il problema come apprendimento nel tempo senza dimenticanza catastrofica. Gli agenti rendono quel problema più ampio. La cosa che cambia può essere un modello, ma può anche essere un prompt, uno strumento, una competenza, un flusso di lavoro o una memoria.

Quella distinzione è importante, perché la maggior parte dei fallimenti degli agenti non vengono risolti raggiungendo per prima cosa la formazione del modello.

Il riflesso di fine-tuning è troppo limitato

Quando i team parlano di migliorare un sistema di intelligenza artificiale, il piano predefinito spesso suona così: raccogliere fallimenti, etichettare risposte migliori, fine-tuning del modello. Quell’istinto è comprensibile. Il fine-tuning supervisionato, l’ottimizzazione delle preferenze dirette, l’ottimizzazione della politica relativa di gruppo, e i metodi efficienti nei parametri come LoRA sono strumenti utili quando il modello stesso deve cambiare.

Ma molti fallimenti in produzione non sono fallimenti dei pesi del modello. Sono fallimenti del sistema.

L’agente può fare affidamento su una memoria obsoleta, saltare una conferma richiesta, chiamare uno strumento con l’argomento sbagliato o instradare un caso attraverso il flusso di lavoro sbagliato. Spesso, il problema non è la capacità del modello di base. È il contesto, la memoria, l’interfaccia dello strumento o il flusso di lavoro che lo avvolge.

Un agente moderno ha diversi strati. Il modello ragiona e genera. La bardatura intorno a esso definisce i prompt, gli strumenti, le competenze, il codice, l’instradamento e il flusso di lavoro. La memoria trasporta fatti e procedure apprese attraverso le sessioni. L’apprendimento continuo è la disciplina del decidere quale strato debba cambiare, quanto piccolo può essere il cambiamento e come verificare che il cambiamento abbia effettivamente aiutato.

A volte la correzione giusta è una scrittura in memoria. A volte è una modifica del prompt. A volte è un wrapper di strumento, una regola di instradamento o una patch del flusso di lavoro. Il fine-tuning dovrebbe rimanere disponibile, ma non dovrebbe essere la prima risposta a ogni fallimento.

I benchmark sono utili, ma la produzione raramente ti dà uno

C’è un lavoro emozionante sull’ottimizzazione della stessa bardatura dell’agente. Metodi come GEPA, Meta-Harness, e approcci correlati di ottimizzazione dei prompt o del flusso di lavoro trattano l’agente come un sistema che può essere mutato e testato. Possono proporre modifiche ai prompt o ad altri componenti della bardatura, eseguire i candidati e tenere le versioni che ottengono punteggi migliori.

Quella è la direzione giusta. Sposta il miglioramento fuori dal quadro ristretto di “aggiorna i pesi” e dentro il quadro più ampio di “migliora l’agente”.

Ma c’è un problema: questi metodi di solito presuppongono un benchmark. Hanno bisogno di un compito che possa essere eseguito ripetutamente e di un valutatore che dica se il candidato A è migliore del candidato B. Senza quello, l’ottimizzazione diventa lavoro di ipotesi con una strumentazione migliore.

Questo non è ciò che la maggior parte dei team ha in produzione.

Ciò che hanno sono log. Hanno tracce, correzioni degli utenti, biglietti di supporto, eventi di pollice verso, note di escalation e occasionali feedback di esperti. Quei segnali sono preziosi, ma non sono ancora un benchmark. Dicono loro che qualcosa è successo. Non dicono automaticamente come riprodurlo, cosa dovrebbe assomigliare al successo o come valutare una correzione proposta.

Quella lacuna è dove molti sforzi di apprendimento continuo si fermano. Il team ha esperienza, ma non ancora un ambiente di apprendimento.

I log non sono lezioni

Un log di produzione registra un percorso attraverso un’interazione. Un utente ha chiesto un volo. L’agente ha cercato. L’utente ha detto che la data era sbagliata. Quello è l’evidenza di un fallimento, ma non è abbastanza per imparare.

Il log non definisce il controfattuale. L’agente avrebbe dovuto chiedere conferma? Avrebbe dovuto dedurre la data dal contesto precedente? Avrebbe dovuto chiamare uno strumento diverso? Avrebbe dovuto rifiutare di procedere fino a quando l’ambiguità non fosse stata risolta? Un essere umano potrebbe sapere la risposta dopo aver letto la traccia, ma il sistema non ottiene quella struttura gratuitamente.

Perché l’apprendimento continuo funzioni, un fallimento grezzo deve essere trasformato in qualcosa di riproducibile. Ciò significa un compito che l’agente può affrontare di nuovo, un utente o un simulatore che ricrea il modello rilevante, strumenti che l’agente può chiamare e valutatori che definiscono il successo. Il valutatore potrebbe controllare la risposta finale, le chiamate degli strumenti, un limite di politica, latenza, costo o tutto ciò.

Questo è la parte meno visibile del lavoro, ma è la parte che rende il miglioramento reale. Una volta che un fallimento diventa un ambiente riproducibile, puoi porre una domanda concreta: il cambiamento proposto ha effettivamente risolto il comportamento?

Senza quel passaggio, i team stanno principalmente correggendo dalla memoria.

David Silver e Richard Sutton hanno descritto una prossima era dell’esperienza, in cui gli agenti imparano principalmente dall’interazione con il mondo piuttosto che da dati umani statici. Per gli agenti aziendali, quella visione dipende dal trasformare l’esperienza di produzione disordinata in ambienti che possono essere riprodotti, valutati e riutilizzati.

L’esperienza da sola non è sufficiente. Deve essere resa testabile.

La regressione è il costo nascosto

Anche quando un fallimento diventa testabile, la parte più difficile rimane: risolverlo senza rompere qualcos’altro.

Chiunque abbia mantenuto un agente complesso ha visto questo modello. Aggiungi un’istruzione in modo che l’agente escal i richiesti di rimborso aggressivi. Ora escal i rimborsi di routine che dovrebbero essere gestiti rapidamente. Riduci le chiamate degli strumenti in un flusso di lavoro. Ora un altro flusso di lavoro salta un controllo richiesto. Correggi una memoria obsoleta. Ora l’agente generalizza eccessivamente la correzione a una diversa linea di prodotti.

Ogni patch ha senso localmente. Il sistema continua a derivare globalmente.

Questo è la versione dell’agente della dimenticanza catastrofica. Nei network neurali, il termine si riferisce di solito alla formazione nuova che sovrascrive le vecchie capacità. Negli agenti, il fallimento è più ampio e spesso più difficile da vedere. La dimenticanza può verificarsi in prompt, strumenti, memoria, routing e flusso di lavoro. Si manifesta non come una metrica pulita su una curva di formazione, ma come un utente che dice: “Questo funzionava una volta”.

Quello è il motivo per cui il controllo della regressione non può essere un passaggio di revisione finale. Deve essere all’interno del ciclo di apprendimento stesso.

L’obiettivo non è semplicemente massimizzare le prestazioni sul nuovo fallimento. L’obiettivo è migliorare il nuovo caso mentre si preserva i vecchi. Ogni correzione che funziona dovrebbe diventare parte della memoria crescente dell’agente di ciò che deve continuare a funzionare. Nella pratica, significa che i vecchi fallimenti diventano test di regressione. La storia dell’agente diventa un vincolo, non solo un archivio.

Questo è dove l’apprendimento continuo diventa più come una seria ingegneria del software che una semplice ottimizzazione dei prompt. Un cambiamento non è buono perché suona meglio. È buono perché migliora un comportamento misurato e non fa regredire i comportamenti che il sistema aveva già guadagnato.

Cosa richiede l’apprendimento continuo pratico

Un ciclo di apprendimento continuo pronto per la produzione richiede quattro proprietà.

In primo luogo, i fallimenti devono essere riproducibili. Un fallimento una tantum è un aneddoto. Un ambiente riproducibile e valutato è un test. Fino a quando l’agente non può affrontare lo stesso modello di nuovo, nessuno può provare che la correzione ha funzionato.

In secondo luogo, la diagnosi deve essere olistica. La correzione potrebbe appartenere al modello, ma potrebbe anche appartenere alla memoria, al prompt, allo strato degli strumenti o al flusso di lavoro. La migliore correzione è di solito il più piccolo cambiamento duraturo che spiega il fallimento.

In terzo luogo, l’apprendimento deve essere per tutta la vita. L’agente non dovrebbe migliorare questa settimana annullando silenziosamente il comportamento difficile guadagnato la settimana scorsa. I successi precedenti dovrebbero diventare vincoli durante l’ottimizzazione, non sorprese dopo il deploy.

In quarto luogo, il ciclo deve essere efficiente. Se ogni miglioramento richiede un progetto di ri-formazione trimestrale, il sistema non terrà mai il passo con la produzione. Il ciclo deve provare a cercare correzioni a buon mercato per prima, escalare solo quando necessario e mantenere la verifica vicino al cambiamento.

Nessuno di questi significa che gli agenti dovrebbero aggiornarsi in modo cieco. Significa il contrario. Il miglioramento dovrebbe diventare misurabile. Ogni cambiamento dovrebbe avere un test, un punteggio prima e dopo, e un controllo di regressione.

Quello è ciò che trasforma l’apprendimento continuo da una vaga aspirazione in una disciplina ingegneristica.

Il futuro degli agenti non sarà definito solo da finestre di contesto più ampie, modelli di base più forti o più strumenti. Quelli saranno importanti. Ma la domanda più importante per le aziende è cosa succede dopo il deploy.

Quando l’agente fallisce domani, può il sistema trasformare quel fallimento in un test? Può instradare la correzione allo strato giusto? Può provare che la correzione ha aiutato? Può provare che nulla altro si è rotto?

Se la risposta è no, l’agente non sta imparando realmente dalla produzione. Sta accumulando rischi.

Gli agenti che contano dopo faranno qualcosa di meglio. Si accumuleranno.