Corso / builder / capitolo 6

Quando l'agente sbaglia

durata: 22 minprerequisiti: builder cap. 1–5percorso: builder
ALLA FINE SAPRAI
· individuare dove degrada davvero un sistema con più agenti
· progettare i passaggi di consegne, non solo i singoli passi
· decidere esplicitamente cosa deve sapere il passo successivo
Cinque corridori in sequenza si passano un testimone blu durante una staffetta, disegnati in bianco e nero.

Hai costruito un sistema in cui più agenti si passano il lavoro: uno cerca, uno riassume, uno scrive il testo finale. Funziona sulla demo, poi in produzione comincia a produrre risultati plausibili ma sbagliati, e passi ore a controllare i prompt di ogni singolo agente convinto che il problema sia lì. Quasi sempre non lo è.

Dove si rompe davvero la catena

La tentazione, quando un sistema di più agenti sbaglia, è ottimizzare ogni singolo passo: un prompt migliore per l’agente che cerca, uno più preciso per quello che riassume. Ma la maggior parte dei fallimenti non nasce dentro un passo, nasce fra un passo e il successivo, nel momento in cui un agente passa il proprio output a quello dopo. È il gioco del telefono senza fili, quello dove una frase sussurrata all’orecchio arriva all’ultimo giocatore completamente diversa: nessuno ha sbagliato clamorosamente, ognuno ha solo perso un pezzetto, e i pezzetti persi si sommano.

Nel tuo sistema succede la stessa cosa in versione automatica. L’agente che cerca trova dieci fonti buone, ma ne passa un riassunto di tre righe a quello successivo. L’agente che riassume lavora bene con quello che ha ricevuto, ma quello che ha ricevuto è già monco: mancano le citazioni, manca il contesto su quale fonte è più affidabile, manca la data di pubblicazione che avrebbe cambiato la rilevanza di un dato. L’agente che scrive il testo finale produce qualcosa di fluente e sicuro di sé, partendo da basi che nessuno ha controllato lungo la strada.

Perché un modello più potente non lo risolve

Il primo istinto è cambiare modello: prendere quello più recente, più grande, più costoso, sperando che l’intelligenza in più compensi il problema. Non lo fa, perché il problema non è nell’intelligenza di nessuno dei singoli agenti. Anche l’agente più capace del mondo, se riceve un riassunto di tre righe a cui mancano le citazioni, non può inventarsi le citazioni mancanti: può solo produrre qualcosa di plausibile che le sostituisce, ed è esattamente questo il momento in cui il sistema comincia a sbagliare in modo silenzioso. Il problema è nell’architettura del passaggio, non nella capacità del modello, e per questo va risolto lì.

Progetta i passaggi di consegne, non solo i passi

La domanda giusta da farti per ogni singolo passaggio del tuo sistema non è «come rendo più bravo questo agente», è: cosa deve sapere il passo successivo per non lavorare al buio? È una domanda diversa da quelle che probabilmente ti sei fatto finora, perché sposta l’attenzione dal singolo agente all’interfaccia fra due agenti. Progettare bene questa interfaccia vale più che ottimizzare i singoli passi, perché anche il passo più intelligente produce spazzatura se lavora su materiale già degradato.

In pratica, questo significa decidere esplicitamente cosa attraversa ogni confine: non «un riassunto», ma un riassunto con citazioni verificabili, la data delle fonti, e un’indicazione di quanto ciascuna fonte sia affidabile. Non «i punti principali», ma i punti principali più un segnale su quali sono incerti e andrebbero controllati da un umano prima di procedere. Più il passaggio è esplicito su cosa deve contenere, meno l’agente successivo deve indovinare, e meno indovina, meno il sistema degrada lungo la catena.

Un esempio vero

Nello scaffolding agente di ricerca bibliografica, il passaggio critico è esattamente questo: fra l’agente che cerca le fonti e quello che le riassume. La versione che degrada passa un testo libero, senza struttura: «ecco cosa ho trovato». La versione che regge passa un oggetto strutturato, con ogni fonte, la sua citazione verificabile, e un campo che segnala l’affidabilità. Con questa seconda versione, l’agente che riassume non deve indovinare quali affermazioni può fare con sicurezza e quali no: la struttura del passaggio glielo dice già.

Una cosa da fare, adesso

Prendi un sistema di più agenti che hai costruito o che stai progettando. Per ogni passaggio fra un agente e il successivo, scrivi in una riga cosa attraversa quel confine oggi, in forma libera o strutturata. Poi chiediti, per ognuno: se questo passaggio perdesse metà del dettaglio, il passo successivo se ne accorgerebbe, o produrrebbe comunque qualcosa di plausibile? Dove la risposta è «produrrebbe comunque qualcosa di plausibile», hai trovato il punto dove il tuo sistema può degradare senza che nessuno se ne accorga.

Un prompt da cui partire

Sto passando questo output da un agente al successivo: [incolla l'output].
Elenca cosa manca in questo output che il passo successivo potrebbe dover indovinare invece di sapere con certezza.
Per ogni elemento mancante, dimmi se la sua assenza cambierebbe una decisione presa più avanti nella catena.

Fallo davvero

Il degrado si studia meglio provocandolo in un ambiente dove non costa niente, e il corso te ne dà due già pronti.

Il primo è l’agente di ricerca dello scaffolding: quando ha la chiave API, dagli una domanda vera con tre fonti, di cui una con un indirizzo inesistente in mezzo alle due buone. Un sistema che degrada bene fa quello che vedrai: dichiara la fonte saltata nell’output, prosegue con le altre, e la sezione «cosa non si può concludere» si allarga di conseguenza. Poi immagina, o prova a costruire, la versione che degrada male: quella che davanti alla fonte mancante riassume lo stesso, riempiendo il buco con quello che il modello sa già, con l’aria di averla letta.

Il secondo è il passaggio di consegne, il punto dove il telefono senza fili si gioca la partita. Prendi il template di handoff e rifai l’esercizio della catena analista e redattore visto nel capitolo sull’orchestrazione, ma stavolta sabotalo: togli dall’handoff la sezione delle decisioni prese e quella dei confini, e passa al secondo agente solo il resto. Confronta i due risultati finali. La differenza che vedi, un commento che riapre decisioni già prese o inventa esiti mai decisi, è il degrado da passaggio di consegne descritto in questa lezione, prodotto in laboratorio invece che scoperto in produzione.

Dove andare adesso

Questa lettura è l’applicazione pratica del paper «Perché gli agenti sbagliano», che approfondisce i tre punti in cui un sistema di più agenti degrada. Per vederlo dal vivo, scarica lo scaffolding corrispondente, rompi di proposito un passaggio di consegne, e osserva dove e come il risultato finale peggiora.

Scrivi per cercare fra corso, playbook, skill, paper…