← andrea migliavacca progetti · τ²-benchEN

progetto · valutazione di agenti

Migliorare un agente AI cambiando solo il prompt.

Modello fisso, prompt diversi: confronto i risultati e analizzo le tracce per capire che cosa cambia.

sintesi

Su τ²-bench ho confrontato sei versioni del prompt di un agente di assistenza, mantenendo fisso il modello. Ho usato le tracce per distinguere errori di comunicazione, azioni sbagliate e limiti della misura finale.

La versione finale ha ottenuto l’80,5% di successi in media su quattro esecuzioni. Il confronto con l’agente di default e la variabilità fra le esecuzioni sono mostrati nei risultati.

1

Il banco di prova

Nel benchmark l’agente assiste un cliente simulato, usa strumenti che modificano prenotazioni e segue un regolamento. Un task riesce se comunica le informazioni richieste e lascia il database nello stato atteso.

Ho mantenuto fissi modello e strumenti per isolare l’effetto delle modifiche al prompt.

il banco di prova: cliente simulato, agente, strumenti e regolamento

2

Oltre il punteggio finale

L’agente di default risolve 34 task su 50. Il punteggio binario, però, non distingue una risposta corretta senza azione da un’azione eseguita male.

Ho quindi letto le tracce in Langfuse e separato comunicazione, stato finale del database e azioni degli strumenti. Ogni tipo di errore suggerisce una correzione diversa.

scomporre il voto binario in ciò che serve sapere

3

Tre tipi di errore

Le tracce mostrano tre famiglie: l’agente descrive un’azione senza eseguirla, esegue un’azione non autorizzata oppure sceglie la prima opzione valida senza confrontarla con le altre.

Queste distinzioni hanno guidato le modifiche al prompt. Le figure mostrano un esempio di traccia e come ho classificato gli errori.

Traccia Langfuse di una conversazione fallita, reward 0.00

una traccia reale: la conversazione, passo per passo, e perché ha preso zero · apri a schermo intero ↗

le tre famiglie di fallimento, lette dalle tracce

4

Quando le regole aggiunte peggiorano il risultato

In tre versioni ho aggiunto istruzioni per i casi osservati. Il punteggio non è migliorato: il grafico mostra perché ho cambiato approccio.

Nel prompt finale ho cercato istruzioni più selettive e rimosso un esempio che spingeva l’agente ad aggiungere un servizio non richiesto. Il risultato riguarda questo modello e questi task, non ogni agente.

Come leggere il grafico Le versioni intermedie hanno una sola esecuzione ciascuna; la versione finale è stata ripetuta quattro volte. Il confronto delle medie è nel risultato finale.

le sei versioni durante lo sviluppo; la versione finale è stata poi ripetuta

5

Correggere il prompt

Ho tolto un esempio che confondeva un diritto del cliente con una richiesta effettiva. Ho poi reso espliciti due passaggi: confrontare le opzioni quando il cliente chiede «la più economica» e comunicare che una modifica non è ancora stata eseguita prima di chiedere conferma.

le tre frasi nel prompt, come le legge l’agente

Il prompt finale è in inglese. In evidenza le frasi che hanno corretto le tre famiglie di fallimento.

Serve what they asked for, and ONLY that: something the <policy> permits, or that they are entitled to - a free checked bag, a compensation, an upgrade they qualify for - is not something they asked for. An entitlement is not an instruction. If they did not ask for it, do not add it and do not offer it.
When the customer DESCRIBES what they want instead of naming it - "the cheapest", "anywhere on the west coast", "either airport" - that description is a search, not an instruction to take the first thing that fits. Search every combination the description allows, list the candidates you found with the number that decides between them, and choose by comparing those numbers. Write the list out before you choose.
Open that message with exactly this line, on its own:
I have not made any of these changes yet - I need your go-ahead first.
It matters because this message reads like a receipt, and a customer who thinks the work is already done will end the call before you can do it. Nothing is done until you call the tools.

Estratti da patches/tau2-custom-agent.patch, sezioni PROCEDURE e CONFIRMATION_FORMAT.

Prima di ogni prova ho annotato quali task mi aspettavo cambiassero. Le esecuzioni successive hanno permesso di confrontare la previsione con il comportamento osservato.

1. UNDERSTAND. Name to yourself every distinct thing the customer asked for;
   one message often contains more than one. … Serve what they asked for,
   and ONLY that: … Before you go further, it can help to glance again
   at the parts of the <policy> that cover what you just named - keep them
   in mind for the steps below, rather than trying to recall them from earlier
   in this conversation.

…

3. CHECK ELIGIBILITY. The tools do not enforce the policy: a call can succeed
   and still be wrong. … Once you have an answer, it is worth checking it
   once more against the exact wording of the <policy> lines it rests on, in
   case the reasoning above drifted from what they actually say.

dal prompt finale: due righe scritte come consigli su come ragionare prima di decidere

6

Risultato e variabilità

La versione finale ha risolto in media l’80,5% dei task su quattro esecuzioni complete. L’agente di default ha ottenuto il 68% in una sola esecuzione: il numero è un riferimento, non una stima altrettanto stabile.

I quattro punteggi della versione finale vanno dal 74% all’86%. Ripetere la prova rende visibile una variabilità che una sola esecuzione nasconderebbe.

quattro giri identici, quattro punteggi diversi

Tabella Langfuse con le dieci esecuzioni a confronto

le dieci esecuzioni nel dataset di confronto su Langfuse · apri a schermo intero ↗

approfondimento

Il difetto nel benchmark

τ²-bench confronta lo stato finale del database con quello atteso. Ho trovato che l’impronta usata per il confronto ordina i campi, ma non gli elementi delle liste.

In due esecuzioni reali, le stesse carte regalo con gli stessi importi hanno prodotto esiti opposti solo perché erano elencate in ordine diverso. Ho segnalato il caso agli autori del benchmark.

Non è un errore del modello La prenotazione non cambia. È la misura del benchmark a distinguere due stati equivalenti e a introdurre variabilità nel verdetto.

stessi dati, ordine diverso, verdetto diverso

← torna ai progetti