Valutazione LLM Multi-Turn: 5 Metriche, 3 Framework, 1 Workflow

Valutazione LLM Multi-Turn: 5 Metriche, 3 Framework, 1 Workflow

La valutazione LLM multi-turn è l'unico modo per intercettare il bug di amnesia al turno 8: l'utente ha fornito il numero d'ordine al turno 3 e il bot glielo chiede di nuovo. Ogni singolo turno, preso isolatamente, è stato promosso; la conversazione ha comunque fallito. DeepEval 4.0 e RAGAS 0.4 hanno rilasciato API di eval conversazionali dedicate proprio a questo e, dopo due incidenti di eval nella nostra pipeline su Techsy, ecco le cinque metriche, i tre framework e l'unico workflow da cui partire.

Punti chiave

• La valutazione multi-turn assegna un punteggio a intere conversazioni, non a coppie isolate input-output.
• I modelli in cima alle classifiche single-turn degradano in modo misurabile lungo i turni di una conversazione.
• Parti da quattro metriche: completezza, ritenzione della conoscenza, aderenza al ruolo, pertinenza dei turni.
• DeepEval, RAGAS e Langfuse risolvono l'eval multi-turn in modi diversi; la tabella dei framework più avanti li confronta.

Perché i Punteggi Single-Turn Ti Mentono?

Gli eval single-turn assegnano un punteggio a una coppia input-output alla volta, quindi non possono vedere i fallimenti che emergono solo tra i turni: dimenticanze, contraddizioni, derive. Un modello può registrare un ottimo punteggio di benchmark e comunque perdere il filo di una conversazione reale. Laban et al. lo documentano in LLMs Get Lost In Multi-Turn Conversation, 353 citazioni: le prestazioni degradano negli scenari multi-turn anche quando i risultati single-turn sembrano sani.

Il problema di fondo è la non deterministicità: l'ennesima risposta dipende da tutti gli n-1 turni precedenti, quindi prompt identici si comportano diversamente in base alla cronologia. Un dataset di coppie isolate non mette mai alla prova questa dipendenza. La survey su arXiv Evaluating LLM-based Agents for Multi-Turn Conversations, una revisione PRISMA di circa 250 fonti, divide il campo in cosa valutare (gestione del contesto, pianificazione, coerenza) e come (metriche, judge LLM, revisione umana). Entrambi gli assi sono assenti da una suite single-turn.

Niente di tutto ciò rende inutile il tuo stack single-turn. Se usi metriche single-turn come BLEU, ROUGE e G-Eval, tienile per ciò che misurano bene: conformità del formato, tossicità, richiamo fattuale su un prompt fisso. Smetti solo di leggerle come un check di salute della conversazione che i tuoi utenti toccano davvero.

La nostra lettura di questi studi, in una riga:

Gli eval single-turn misurano la risposta, la valutazione multi-turn misura la conversazione, e un modello che eccelle al turno uno può perdersi entro il turno cinque.

Cos'è la Valutazione LLM Multi-Turn? Le Due Modalità di Eval

La valutazione LLM multi-turn è la pratica di assegnare un punteggio a un'intera conversazione, o a finestre al suo interno, invece che a coppie isolate prompt-risposta. Si chiede se il modello ha mantenuto il contesto, è rimasto nel ruolo e ha risolto il problema dell'utente lungo i turni. Due modalità fanno il lavoro: punteggio a livello di conversazione e punteggio a livello di turno con finestra scorrevole, e molti team le usano entrambe.

Punteggio a livello di conversazione: consegni al judge la trascrizione completa e poni una domanda: questa conversazione ha avuto successo? Intercetta chiusure premature e loop irrisolti, perché solo l'intero thread rivela che l'utente non ha mai ottenuto il rimborso. Il suo limite è la granularità: "fallita" su un thread di 12 turni non dice dove si è rotto qualcosa.

Punteggio a livello di turno con finestra scorrevole: sposta una finestra di N turni lungo la trascrizione, un verdetto per finestra. Una finestra di 3 su una conversazione di 10 turni produce 8 verdetti legati a regioni della chat, quindi "fallita" arriva con le coordinate: la rottura è avvenuta tra i turni 6 e 8. Il diagramma in cima a questo post mostra entrambe le modalità sullo stesso thread: una parentesi per il verdetto di conversazione, un riquadro scorrevole per i verdetti per finestra.

Usa il punteggio a livello di conversazione come gate e il punteggio a finestre per localizzare i fallimenti quando scatta. La guida alla valutazione multi-turn di DeepEval inquadra l'unità di lavoro come scenario anziché come coppia input-output (il suo tipo ConversationalGolden): stai testando una situazione, non una domanda.

Esempio illustrativo (sintetico; mostra la meccanica, non un'esecuzione reale): una finestra scorrevole di 3 su una chat di 8 turni per una richiesta di reso.

Turn 1  user:      I want to return an order that arrived damaged.
Turn 2  assistant: Sorry about that. Can you share the order number?
Turn 3  user:      It's #4471.
Turn 4  assistant: Got it. Damaged on arrival, or after use?
Turn 5  user:      On arrival. The screen was cracked.
Turn 6  assistant: Understood. Replacement or refund?
Turn 7  user:      Refund. How long does that take?
Turn 8  assistant: 3-5 business days. Can you share the order number again?

Verdetto a livello di conversazione: fallita. Cinque finestre su sei hanno passato il test e il thread si è comunque rotto sulla ritenzione della conoscenza, esattamente il fallimento che una suite single-turn non fa mai emergere.

Quali Metriche Multi-Turn Contano? Le 5 Che Contano

Esegui prima quattro metriche: completezza della conversazione, ritenzione della conoscenza, aderenza al ruolo e pertinenza dei turni. Aggiungi una quinta, un criterio personalizzato (G-Eval in DeepEval, AspectCritic in RAGAS), per tutto ciò che il tuo prodotto non può sbagliare. Le prime quattro si trasferiscono tra progetti; la quinta è dove vivono i tuoi modi di fallire.

1. Completezza della conversazione. L'obiettivo dell'utente è stato risolto o il bot ha dichiarato vittoria troppo presto? Il tuo rilevatore di chiusure premature.
2. Ritenzione della conoscenza. Il modello ricorda i fatti dichiarati prima nel thread? Il bug di amnesia al turno 8 è un fallimento di ritenzione della conoscenza.
3. Aderenza al ruolo. L'assistente resta nel suo personaggio e rifiuta richieste fuori ambito? Critico con un perimetro di compliance.
4. Pertinenza dei turni. Ogni risposta è in tema rispetto ai turni precedenti? Intercetta derive e loop.
5. Un criterio personalizzato. Una regola in linguaggio naturale per il tuo dominio: "non citare mai un prezzo diverso dal listino." DeepEval lo implementa come ConversationalGEval; RAGAS come AspectCritic.

La guida alle metriche di DeepEval definisce ciascuna con classi eseguibili, ma i concetti sono indipendenti dal framework: la tabella resta valida anche se ti scrivi il judge a mano.

Un criterio personalizzato si legge come una frase:

criterion "price_accuracy":
  question: Does the assistant quote prices matching the official
            list, and self-correct when the user flags a mismatch?
  scale: 0 (wrong, no correction) to 1 (correct throughout)
  verdict: pass if score >= 0.5

La stessa regola in vero codice DeepEval:

from deepeval.metrics import ConversationalGEval
from deepeval.test_case import LLMTestCaseParams

price_accuracy = ConversationalGEval(
    name="Price Accuracy",
    criteria=(
        "Does the assistant quote prices that match the official "
        "price list, and correct itself immediately when the user "
        "points out a discrepancy?"
    ),
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT,
    ],
    threshold=0.5,
)

DeepEval vs RAGAS vs Langfuse: Quale Framework Scegliere?

Tutti e tre valutano conversazioni multi-turn, ma la loro unità di valutazione è diversa: DeepEval simula scenari offline, RAGAS assegna punteggi ad aspetti di conversazioni che hai già e Langfuse valuta tracce di produzione reali. Scegli in base a da dove arrivano le tue conversazioni, non dal numero di funzionalità.

Prima la logica indipendente dal framework, così il codice dei vendor qui sotto è portabile:

for scenario in scenario_set:
    transcript = run_chatbot(scenario, max_turns=10)
    for window in sliding_windows(transcript, 3):
        scores.append(judge(window, criteria))
    scores.append(judge(transcript, completeness))
fail_if(mean(scores) < baseline - tolerance)

DeepEval: scenari e un simulatore completo di tutto

DeepEval è l'unico con un simulatore di conversazioni di prima classe: descrivi uno scenario e un personaggio e lui interpreta l'utente contro il tuo bot. La sua guida multi-turn è il riferimento canonico per il pattern scenario-non-coppie. Confident AI vende la dashboard ospitata; la nostra recensione di Confident AI copre ciò che aggiunge il livello a pagamento.

from deepeval.dataset import ConversationalGolden
from deepeval.synthesizer import ConversationSimulator
from deepeval.metrics import (
    ConversationCompletenessMetric,
    KnowledgeRetentionMetric,
)
from deepeval import evaluate

scenario = ConversationalGolden(
    additional_context="Customer wants to return a damaged order",
    user_persona="Impatient customer, second contact this week",
)
simulator = ConversationSimulator(model="gpt-4o-mini", max_turns=10)
test_case = simulator.simulate(scenario, your_chatbot_fn)

evaluate(
    test_cases=[test_case],
    metrics=[
        ConversationCompletenessMetric(threshold=0.7),
        KnowledgeRetentionMetric(threshold=0.7),
    ],
)

RAGAS: guidato dall'analisi degli errori, aspetto per aspetto

RAGAS parte dalle conversazioni che hai già e assegna punteggi aspetto per aspetto. Il suo how-to multi-turn si abbina all'analisi manuale degli errori: leggi le chat fallite, scrivi un AspectCritic per ogni modo di fallire, assegna il punteggio.

from ragas.dataset_schema import MultiTurnSample
from ragas.metrics import AspectCritic
from ragas.llms import llm_factory

user_input = [
    {"role": "user", "content": "Can I return a damaged order?"},
    {"role": "assistant", "content": "Yes, within 30 days."},
    {"role": "user", "content": "It arrived broken. Do I pay shipping?"},
    {"role": "assistant", "content": "No, we cover it."},
]
sample = MultiTurnSample(user_input=user_input)

critic = AspectCritic(
    name="policy_consistency",
    definition="Does the assistant stay consistent with the stated return policy across all turns? Answer yes or no.",
    llm=llm_factory("gpt-4o-mini"),
)
score = await critic.multi_turn_ascore(sample)  # binary 0 or 1

Langfuse: valutazione N+1 su tracce reali

Langfuse prende la strada opposta: prima il tracer. Il suo cookbook N+1 valuta la traccia di ogni turno più la conversazione nel suo insieme, su traffico di produzione anziché su simulazioni. Se stai ancora scegliendo il livello di osservabilità, il nostro confronto Langfuse vs LangSmith copre quella decisione.

Il nostro verdetto, senza mezze misure: per un nuovo progetto di chatbot, parti con DeepEval. Il simulatore ti permette di bloccare le regressioni prima di avere traffico di produzione, quando hai più bisogno di test. Aggiungi Langfuse quando esistono thread reali; passa a RAGAS quando il tuo team preferisce leggere le conversazioni fallite e codificare ciò che trova.

Come Passare Dall'Analisi degli Errori All'Automazione?

La sequenzi. Leggi 20-30 conversazioni reali, etichetta i modi di fallimento a mano, scrivi check binari passa/fallisce per quelli ovvi, automatizza quelli e solo dopo aggiungi metriche con judge LLM per il residuo soggettivo. Hamel Husain sostiene esattamente questo ordine: prima l'analisi manuale degli errori e le decisioni binarie, perché un check che sai spiegare batte un punteggio che non sai spiegare.

Prima il binario, poi il judge: la sequenza che ci ha salvato

Questo non è un benchmark di chatbot che abbiamo eseguito; è la nostra lettura dello stesso pattern dentro la nostra pipeline di contenuti, che esegue check di regressione con gate di eval a ogni modifica di prompt e tooling. Due incidenti ci hanno dimostrato la sequenza.

Il 2026-06-13, un bug di ripubblicazione ha coniato nuovi slug localizzati e ha spedito 54 documenti live duplicati. Li abbiamo trovati e rimossi dalla pubblicazione il 2026-07-05 (backup su techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). La correzione non è stata un modello più intelligente; è stato un check deterministico pre-pubblicazione: risolvere il documento esistente per post canonico più lingua prima di qualsiasi creazione. Un gate binario.

Secondo incidente: gli LLM di traduzione ogni tanto emettono ASCII invece di Unicode, trasformando "karşılaştırma" in "karsilastirma." Nessun judge necessario; un gate con grep lo intercetta:

grep -cP '[çşğüöıİŞÇĞÜÖ]' file.md   # must be > 0

Entrambi sono stati intercettati da check che costano frazioni di centesimo e stampano esattamente il motivo del fallimento. Trasportalo sugli eval multi-turn: "il bot ha richiesto di nuovo un campo che l'utente aveva già fornito?" è un match di stringhe sulla trascrizione, non una chiamata a un judge. Esegui prima i gate deterministici a basso costo; intercettano i fallimenti peggiori prima che il tuo judge costoso venga mai eseguito.

Quando un judge LLM è davvero lo strumento giusto

I judge si guadagnano il loro costo in token sui criteri che non puoi ridurre a una regola: "il tono era adeguatamente di scuse?", "la risoluzione era adatta alla situazione?" Se puoi scrivere un'asserzione, scrivi un'asserzione. Una rubrica piena di giudizi è territorio da judge.

La linea a cui torniamo sempre:

Parti con check binari passa/fallisce che sai spiegare a un collega, poi aggiungi judge LLM solo per ciò che non puoi ridurre a una regola.

Come Simulare Conversazioni in Scala e Quanto Costa Giudicare?

Simula da scenari, non da log esportati. Gli scenari testano ciò che potrebbe accadere; i log mostrano solo ciò che il tuo sistema attuale ha già permesso. Le indicazioni di DeepEval avvertono che le conversazioni storiche sono state plasmate dal sistema che le ha prodotte, quindi fare benchmark su di esse cristallizza lo status quo.

Scenari, non trascrizioni

Scrivi ogni scenario come obiettivo più personaggio: "cliente impaziente che restituisce un ordine danneggiato", "utente che cambia idea a metà prenotazione." Imposta un limite di turni (10 è ragionevole) e una condizione di stop: obiettivo raggiunto, utente che abbandona o limite. DeepEval raccomanda almeno 20 scenari diversificati tra casi d'uso primari, casi limite e situazioni soggette a fallimento; sotto quella soglia, la tua suite misura aneddoti.

Personaggi ostili

Includi personaggi che provano a rompere il bot: un utente arrabbiato che scala, un utente confuso che si contraddice, un utente injection che infila istruzioni al turno 4. L'injection multi-turn è una disciplina a sé; la nostra guida ai guardrail per LLM copre il livello difensivo che si abbina a questi test e il cookbook di simulazione di Langfuse mostra il loop utente-simulatore.

Quanto costano 100 conversazioni valutate

Ogni cifra qui sotto è una stima da conteggi di token dichiarati e prezzi pubblici, non una misurazione che abbiamo eseguito. L'aritmetica è il punto: sostituisci i tuoi numeri.

Meno di un dollaro per 100 conversazioni giudicate per intero. Un judge più costoso sposta questa cifra di 10-50 volte e le tattiche nella nostra guida ridurre i costi API degli LLM si applicano: metti in cache il testo dei criteri, raggruppa le finestre in batch, usa il modello economico per i gate binari.

Un Workflow di Eval Multi-Turn in 6 Step

Il loop gira così: definisci scenari da fallimenti reali, scegli quattro metriche chiave più una personalizzata, simula almeno 20 scenari, crea una baseline della versione attuale, blocca le regressioni in CI e rimetti i fallimenti di produzione nel set di scenari.

1. Definisci scenari dai fallimenti. Leggi 20-30 trascrizioni (o, prima del lancio, scrivile dai ticket di supporto). Ogni scenario riceve un obiettivo, un personaggio e un limite di turni. Responsabile: tu e il metodo error-analysis-first di Hamel.
2. Scegli quattro metriche, una personalizzata. Completezza, ritenzione della conoscenza, aderenza al ruolo, pertinenza dei turni e un ConversationalGEval o AspectCritic per l'errore costoso del tuo dominio.
3. Simula. Esegui almeno 20 scenari incluso il set ostile. Responsabile: il ConversationSimulator di DeepEval o il cookbook di simulazione di Langfuse.
4. Crea la baseline della versione attuale. Registra le medie per metrica su 3 esecuzioni, poiché i modelli sono non deterministici e una singola esecuzione è rumore. Responsabile: il tuo script di eval, risultati committati nel repo.
5. Blocca le regressioni in CI. Imposta una soglia per metrica e fai fallire la build su una regressione oltre una tolleranza:

# ci/multi-turn-eval-gate.sh
set -euo pipefail
python eval/run_multi_turn.py --scenarios eval/scenarios.yaml --out results.json
SCORE=$(jq -r '.aggregate.completeness' results.json)
BASELINE=0.82
TOLERANCE=0.03
if (( $(echo "$SCORE < $BASELINE - $TOLERANCE" | bc -l) )); then
  echo "FAIL: completeness $SCORE below baseline $BASELINE"
  exit 1
fi

1. Monitora i thread di produzione. Raggruppa le tracce live per thread, valutale in modo asincrono e trasforma ogni thread fallito in un nuovo scenario. Responsabile: Langfuse o il tuo tracer; le nostre guide su valutare gli agenti AI in produzione e sull'osservabilità AI coprono la metà di monitoraggio.

La suite non è mai finita: lo step 6 alimenta lo step 1 e il set di scenari cresce con ogni fallimento di produzione che intercetti.

Come Valutare il Tono Tra Lingue Diverse?

Una metrica di aderenza al ruolo tarata su dati inglesi promuoverà una trascrizione turca o giapponese che un madrelingua trova scortese, perché il registro di cortesia è specifico della lingua. La tua rubrica inglese non ha parole per questo. La correzione: un criterio di aspetto per ogni aspettativa di registro, scritto per lingua, non una metrica di tono globale unica.

Un criterio per registro

La nostra lettura del pattern AspectCritic di RAGAS, estesa dall'eseguire una pipeline in 23 lingue, non un risultato di test pubblicato:

English:  "Is the assistant's tone friendly but professional?"
Turkish:  "Does the assistant use formal 'siz' address consistently,
           and avoid casual verb forms with an upset customer?"
Japanese: "Does the assistant keep keigo (polite form) throughout,
           including the apology at the resolution turn?"

Ogni criterio è un critic binario separato sulla stessa trascrizione. Non abbiamo pubblicato punteggi di tono tra lingue e non ci fideremmo di un articolo che li stampa senza la rubrica. Dal lavoro sulla pipeline: i fallimenti si concentrano sui turni di scuse e di escalation, dove il registro crolla per primo.

Domande Frequenti

Cos'è un LLM per conversazioni multi-turn?

Un modello linguistico la cui ennesima risposta dipende da tutti i turni precedenti, non solo dall'ultimo prompt. Si condiziona sull'intero thread, quindi il comportamento cambia con la cronologia della conversazione. Questa dipendenza dal contesto è ciò che i test single-turn non possono esercitare e che la valutazione multi-turn esiste per misurare.

Cosa significa valutazione di un LLM?

Misurare la qualità degli output rispetto a criteri definiti, in modo automatico e ripetibile, invece che a sensazione. La valutazione single-turn assegna punteggi a coppie isolate prompt-risposta rispetto a metriche come BLEU o un judge LLM. La valutazione multi-turn estende questo alle intere conversazioni, assegnando punteggi alla ritenzione del contesto e al completamento dell'obiettivo lungo i turni anziché per prompt.

Come si fa il benchmark delle prestazioni LLM multi-turn?

Costruisci almeno 20 scenari con obiettivi e personaggi, simulali contro il modello e assegna punteggi con metriche a livello di conversazione più check a finestra scorrevole. Registra baseline su più esecuzioni per assorbire la non deterministicità, poi confronta ogni nuova versione con la baseline in CI. Le tracce di produzione estendono il benchmark in seguito.

Quali sono i modi migliori per valutare un LLM?

Sequenziali: prima l'analisi manuale degli errori, poi gate binari passa/fallisce per tutto ciò che è riducibile a una regola, poi LLM-as-a-judge per i criteri soggettivi come tono e qualità della risoluzione. I check binari costano meno, si possono debuggare e non vanno alla deriva; i judge spettano ai criteri che richiedono davvero giudizio, dopo il via libera dei gate economici.

Da quali metriche di valutazione multi-turn dovrei partire?

Completezza della conversazione, pertinenza dei turni e ritenzione della conoscenza; intercettano i fallimenti più comuni (obiettivi irrisolti, derive, dimenticanze) in qualsiasi prodotto chat. Aggiungi l'aderenza al ruolo se il tuo bot ha un perimetro di compliance, poi un criterio personalizzato G-Eval o AspectCritic per l'errore che la tua attività non può permettersi.

Quanto costa LLM-as-a-judge per conversazione?

Con una finestra scorrevole di 5 su 10 turni più una chiamata a livello di conversazione, effettui 7 chiamate judge per conversazione. A circa 2.000 token di input per chiamata su GPT-4o-mini, la nostra stima con i conti mostrati arriva a circa $0,29 per 100 conversazioni. I modelli judge premium la alzano di 10-50 volte.

DeepEval vs RAGAS per la valutazione multi-turn: quale scegliere?

DeepEval se vuoi test di regressione offline con un simulatore di conversazioni integrato, soprattutto prima di avere traffico di produzione. RAGAS se il tuo workflow parte dalla lettura delle conversazioni reali fallite e dalla codifica di ogni modo di fallimento come AspectCritic. Una divisione comune: DeepEval in CI, critic in stile RAGAS sui log di produzione.

Quanti scenari servono per una suite di eval multi-turn?

Almeno 20, che coprano casi d'uso primari, casi limite e situazioni soggette a fallimento; quella soglia arriva dalle indicazioni pubblicate di DeepEval e corrisponde alla nostra esperienza. Sotto i 20, i tassi di successo oscillano in base a quali scenari sono capitati dentro. Fai crescere il set con ogni fallimento di produzione.

Posso eseguire la valutazione multi-turn in CI/CD?

Sì. Tieni un set di scenari fisso nel repo, eseguilo a ogni modifica di prompt o modello e fai fallire la build quando una metrica regredisce oltre la tolleranza rispetto alla baseline. Poiché i modelli sono non deterministici, confronta medie su 3 esecuzioni con una tolleranza (noi usiamo 0,03), non soglie esatte.

Come valuto le conversazioni multi-turn in produzione?

Raggruppa le tracce per thread di conversazione, assegna punteggi a ogni thread in modo asincrono così che la valutazione non blocchi mai una risposta e instrada i thread falliti in una coda di revisione. Ogni fallimento confermato diventa un nuovo scenario nella tua suite offline, chiudendo il loop tra monitoraggio e test di regressione.

La Versione Breve

• I punteggi single-turn non possono vedere i fallimenti conversazionali; la ricerca mostra modelli che degradano lungo i turni nonostante benchmark sani.
• Esegui il punteggio a livello di conversazione come gate e il punteggio a finestra scorrevole per localizzare le rotture.
• Quattro metriche chiave più un criterio personalizzato coprono la maggior parte dei prodotti chat; check binari prima dei judge, sempre.
• DeepEval per test di regressione simulati, RAGAS per critic guidati dall'analisi degli errori, Langfuse per le tracce di produzione.
• I costi dei judge sono contenuti (meno di un dollaro per 100 conversazioni su un modello mini); il costo è raramente l'ostacolo.

Per il panorama più ampio dei tool, abbiamo classificato l'intero campo nella nostra rassegna dei migliori strumenti di valutazione LLM. E se preferisci costruire la pipeline di eval con qualcuno, richiedi una consulenza gratuita al team Techsy.