Avaliação de LLM Multi-Turn: 5 Métricas, 3 Frameworks, 1 Workflow

Avaliação de LLM Multi-Turn: 5 Métricas, 3 Frameworks, 1 Workflow

A avaliação de LLM multi-turn é a única forma de capturar o bug de amnésia do turno 8: o usuário informou o número do pedido no turno 3, e o bot pede de novo. Cada turno individual passou isoladamente; a conversa ainda assim falhou. O DeepEval 4.0 e o RAGAS 0.4 lançaram APIs de avaliação conversacional dedicadas exatamente para isso, e depois de dois incidentes de avaliação no nosso próprio pipeline na Techsy, aqui estão as cinco métricas, três frameworks e um workflow para começar.

Principais conclusões

• A avaliação multi-turn pontua conversas inteiras, não pares isolados de entrada e saída.
• Modelos que lideram benchmarks single-turn degradam de forma mensurável ao longo dos turnos da conversa.
• Comece com quatro métricas: completude, retenção de conhecimento, adesão ao papel e relevância por turno.
• DeepEval, RAGAS e Langfuse resolvem a avaliação multi-turn de formas diferentes; a tabela de frameworks abaixo os compara.

Por que as pontuações single-turn mentem para você?

Avaliações single-turn pontuam um par de entrada e saída por vez, então não conseguem ver falhas que só aparecem entre turnos: esquecimento, contradição, desvio. Um modelo pode registrar uma pontuação forte em benchmark e ainda assim perder o fio de uma conversa ao vivo. Laban et al. documentam isso em LLMs Get Lost In Multi-Turn Conversation, com 353 citações: o desempenho cai em cenários multi-turn mesmo quando os resultados single-turn parecem saudáveis.

O problema central é o não determinismo: a enésima resposta depende de todos os n-1 turnos anteriores, então prompts idênticos se comportam de forma diferente conforme o histórico. Um dataset de pares isolados nunca exercita essa dependência. O survey da arXiv Evaluating LLM-based Agents for Multi-Turn Conversations, uma revisão PRISMA de cerca de 250 fontes, divide o campo entre o que avaliar (gestão de contexto, planejamento, coerência) e como (métricas, juízes LLM, revisão humana). Ambos os eixos estão ausentes de uma suíte single-turn.

Nada disso torna sua pilha single-turn inútil. Se você roda métricas single-turn como BLEU, ROUGE e G-Eval, mantenha-as para o que elas medem bem: conformidade de formato, toxicidade, recall factual em um prompt fixo. Apenas pare de lê-las como um teste de saúde da conversa que seus usuários tocam.

Nossa interpretação desses estudos, em uma linha:

Avaliações single-turn medem a resposta; a avaliação multi-turn mede a conversa; e um modelo que gabarita o turno um pode estar perdido no turno cinco.

O que é avaliação de LLM multi-turn? Os dois modos de avaliação

A avaliação de LLM multi-turn é a prática de pontuar uma conversa inteira, ou janelas dentro dela, em vez de pares isolados de prompt e resposta. Ela pergunta se o modelo manteve o contexto, permaneceu no papel e resolveu o problema do usuário ao longo dos turnos. Dois modos fazem o trabalho: pontuação em nível de conversa e pontuação em nível de turno com janela deslizante, e a maioria das equipes roda os dois.

Pontuação em nível de conversa entrega ao juiz a transcrição completa e faz uma pergunta: esta conversa teve sucesso? Ela captura encerramento prematuro e loops não resolvidos, já que só o thread inteiro revela que o usuário nunca recebeu o reembolso. Sua fraqueza é a granularidade: "falhou" em um thread de 12 turnos não diz onde as coisas quebraram.

Pontuação em nível de turno com janela deslizante move uma janela de N turnos pela transcrição, um veredito por janela. Uma janela de 3 sobre uma conversa de 10 turnos produz 8 vereditos ligados a regiões do chat, então "falhou" vem com coordenadas: a quebra aconteceu nos turnos 6 a 8. O diagrama no topo deste post mostra os dois modos em um mesmo thread: um colchete para o veredito da conversa, um quadro deslizante para os vereditos por janela.

Use a pontuação em nível de conversa como portão, e a pontuação em janela para localizar falhas quando ele disparar. O guia de avaliação multi-turn do DeepEval define a unidade de trabalho como um cenário, não como um par de entrada e saída (seu tipo ConversationalGolden): você está testando uma situação, não uma pergunta.

Exemplo ilustrativo (sintético; mostra a mecânica, não uma execução real): uma janela deslizante de 3 sobre um chat de solicitação de devolução com 8 turnos.

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?

Veredito em nível de conversa: falhou. Cinco de seis janelas passaram, e o thread ainda quebrou na retenção de conhecimento, exatamente a falha que uma suíte single-turn nunca revela.

Quais métricas multi-turn importam? As 5 que importam

Rode quatro métricas primeiro: completude da conversa, retenção de conhecimento, adesão ao papel e relevância por turno. Adicione uma quinta, um critério personalizado (G-Eval no DeepEval, AspectCritic no RAGAS), para aquilo que seu produto não pode errar. As quatro primeiras se transferem entre projetos; a quinta é onde vivem os seus modos de falha.

1. Completude da conversa. O objetivo do usuário foi resolvido, ou o bot declarou vitória cedo demais? Seu detector de encerramento prematuro.
2. Retenção de conhecimento. O modelo lembra fatos declarados antes no thread? O bug de amnésia do turno 8 é uma falha de retenção de conhecimento.
3. Adesão ao papel. O assistente permanece dentro da sua persona e recusa pedidos fora do escopo? Crítico com um limite de compliance.
4. Relevância por turno. Cada resposta está no tópico, dados os turnos anteriores? Captura desvios e loops.
5. Um critério personalizado. Uma regra em linguagem simples para o seu domínio: "nunca cite um preço diferente da tabela oficial." O DeepEval implementa isso como ConversationalGEval; o RAGAS como AspectCritic.

O guia de métricas do DeepEval define cada uma com classes executáveis, mas os conceitos são neutros em relação a framework: a tabela vale mesmo se você construir seu juiz à mão.

Um critério personalizado se lê como uma 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

A mesma regra como código real de 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: qual framework escolher?

Os três avaliam conversas multi-turn, mas a unidade de avaliação difere: o DeepEval simula cenários offline, o RAGAS pontua aspectos de conversas que você já tem, e o Langfuse avalia traces reais de produção. Escolha pela origem das suas conversas, não pela contagem de recursos.

Primeiro a lógica neutra em framework, para que o código de fornecedor abaixo seja portável:

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: cenários e um simulador completo

O DeepEval é o único com um simulador de conversão de primeira classe: descreva um cenário e uma persona, e ele faz o papel do usuário contra o seu bot. Seu guia multi-turn é a referência canônica para o padrão de cenário, não de pares. A Confident AI vende o dashboard hospedado; nosso review do Confident AI cobre o que a camada paga adiciona.

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: orientado a análise de erros, aspecto por aspecto

O RAGAS parte de conversas que você já tem e as pontua aspecto por aspecto. Seu how-to multi-turn se combina com análise manual de erros: leia os chats que falharam, escreva um AspectCritic por modo de falha, pontue.

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: avaliação N+1 em traces reais

O Langfuse segue o caminho oposto: tracer primeiro. Seu cookbook N+1 avalia o trace de cada turno mais a conversa como um todo, em tráfego de produção em vez de simulações. Se você ainda está escolhendo a camada de observabilidade, nossa comparação Langfuse vs LangSmith cobre essa decisão.

Nosso veredito, sem ficar em cima do muro: para um projeto novo de chatbot, comece com o DeepEval. O simulador permite barrar regressões antes de você ter tráfego de produção, quando mais precisa de testes. Adicione o Langfuse quando threads reais existirem; recorra ao RAGAS quando sua equipe preferir ler conversas que falharam e codificar o que encontrar.

Como passar da análise de erros para a automação?

Você sequencia. Leia 20 a 30 conversas reais, rotule os modos de falha à mão, escreva verificações binárias de aprovado/reprovado para os óbvios, automatize esses, e só então adicione métricas julgadas por LLM para o resíduo subjetivo. Hamel Husain defende exatamente essa ordem: análise manual de erros e decisões binárias primeiro, porque uma verificação que você consegue explicar supera uma pontuação que você não consegue.

Binário antes de juiz: a sequência que nos salvou

Isso não é um benchmark de chatbot que rodamos; é a nossa interpretação do mesmo padrão dentro do nosso próprio pipeline de conteúdo, que roda verificações de regressão com portão de avaliação a cada mudança de prompt e de tooling. Dois incidentes comprovaram a sequência para nós.

Em 2026-06-13, um bug de republicação cunhou novos slugs localizados e enviou 54 documentos duplicados ao vivo. Nós os encontramos e despublicamos em 2026-07-05 (backup em techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). A correção não foi um modelo mais esperto; foi uma verificação determinística de pré-publicação: resolver o documento existente pelo post canônico mais o idioma antes de qualquer criação. Um portão binário.

Segundo incidente: LLMs tradutores ocasionalmente emitem ASCII em vez de Unicode, transformando "karşılaştırma" em "karsilastirma." Nenhum juiz necessário; um portão de grep captura:

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

Ambos foram capturados por verificações que custam frações de centavo e imprimem exatamente por que falharam. Mapeie isso para evals multi-turn: "o bot pediu de novo um campo que o usuário já deu?" é uma correspondência de string contra a transcrição, não uma chamada de juiz. Rode primeiro portões determinísticos baratos; eles capturam as falhas feias antes que seu juiz caro sequer execute.

Quando um juiz LLM é realmente a ferramenta certa

Juízes justificam seu custo de tokens em critérios que você não consegue reduzir a uma regra: "o tom foi adequadamente apologético?", "a resolução coube na situação?" Se você consegue escrever uma asserção, escreva uma asserção. Um rubrica cheia de julgamentos é território de juiz.

A linha à qual sempre voltamos:

Comece com verificações binárias de aprovado/reprovado que você consegue explicar a um colega, e só então adicione juízes LLM para aquilo que não dá para reduzir a uma regra.

Como simular conversas em escala, e quanto custa julgar?

Simule a partir de cenários, não de logs exportados. Cenários testam o que poderia acontecer; logs só mostram o que seu sistema atual já permitiu. A orientação do DeepEval alerta que conversas históricas foram moldadas pelo sistema que as produziu, então fazer benchmark contra elas cristaliza o status quo.

Cenários, não transcrições

Escreva cada cenário como objetivo mais persona: "cliente impaciente devolvendo um pedido danificado", "usuário que muda de ideia no meio da reserva." Defina um limite de turnos (10 é sensato) e uma condição de parada: objetivo alcançado, usuário abandona, ou limite. O DeepEval recomenda pelo menos 20 cenários diversos entre casos de uso principais, casos extremos e situações propensas a falha; abaixo disso, sua suíte mede anedotas.

Personas adversariais

Inclua personas que tentam quebrar o bot: um usuário irritado que escala, um usuário confuso que se contradiz, um usuário de injeção que enfia instruções no turno 4. Injeção multi-turn é uma disciplina própria; nosso guia de guardrails de LLM cobre a camada defensiva que se combina com esses testes, e o cookbook de simulação do Langfuse mostra o loop de simulador de usuário.

Quanto custam 100 conversas avaliadas

Cada número abaixo é uma estimativa a partir de contagens de tokens declaradas e preços públicos, não uma medição que rodamos. A aritmética é o ponto: troque pelos seus próprios números.

Menos de um dólar por 100 conversas totalmente julgadas. Um juiz mais caro move isso 10 a 50 vezes, e as táticas do nosso guia de reduzir custos de API de LLM se aplicam: faça cache do texto dos critérios, agrupe janelas, use o modelo barato para portões binários.

Um workflow de avaliação multi-turn em 6 passos

O loop roda assim: defina cenários a partir de falhas reais, escolha quatro métricas centrais mais uma personalizada, simule pelo menos 20 cenários, estabeleça a linha de base da versão atual, barre regressões no CI e alimente o conjunto de cenários com as falhas de produção.

1. Defina cenários a partir de falhas. Leia 20 a 30 transcrições (ou, antes do lançamento, escreva-os a partir de tickets de suporte). Cada cenário recebe um objetivo, uma persona e um limite de turnos. Responsável: você e o método de análise de erros primeiro do Hamel.
2. Escolha quatro métricas, uma personalizada. Completude, retenção de conhecimento, adesão ao papel, relevância por turno, e um ConversationalGEval ou AspectCritic para o erro caro do seu domínio.
3. Simule. Rode pelo menos 20 cenários incluindo o conjunto adversarial. Responsável: o ConversationSimulator do DeepEval, ou o cookbook de simulação do Langfuse.
4. Estabeleça a linha de base da versão atual. Registre médias por métrica ao longo de 3 execuções, já que modelos são não determinísticos e uma execução única é ruído. Responsável: seu script de avaliação, resultados commitados no repositório.
5. Barre regressões no CI. Defina um limiar por métrica e falhe o build em regressão além de uma tolerância:

# 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. Monitore threads de produção. Agrupe traces ao vivo por thread, avalie de forma assíncrona e transforme cada thread que falha em um novo cenário. Responsável: Langfuse ou seu tracer; nossos guias sobre avaliar agentes de IA em produção e observabilidade de IA cobrem a metade do monitoramento.

A suíte nunca termina: o passo 6 alimenta o passo 1, e o conjunto de cenários cresce com cada falha de produção que você captura.

Como avaliar o tom em vários idiomas?

Uma métrica de adesão ao papel ajustada em dados em inglês vai aprovar uma transcrição em turco ou japonês que um falante nativo considera rude, porque o registro de polidez é específico do idioma. Sua rubrica em inglês não tem palavras para isso. A correção: um critério de aspecto por expectativa de registro, escrito por idioma, não uma métrica global de tom.

Um critério por registro

Nossa interpretação do padrão AspectCritic do RAGAS, estendida a partir da operação de um pipeline de 23 idiomas, não um resultado de teste publicado:

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?"

Cada critério é um crítico binário separado sobre a mesma transcrição. Não publicamos pontuações de tom entre idiomas, e não confiaríamos em um artigo que as imprime sem a rubrica. Do trabalho no pipeline: as falhas se concentram nos turnos de desculpa e escalonamento, onde o registro colapsa primeiro.

Sobre o autor

Mert Batur é cofundador da Techsy.io, onde a equipe entrega agentes de IA, sistemas de automação e pipelines de voz/SDR para clientes B2B. Ele escreve sobre a pilha de tooling de LLM que a equipe da Techsy realmente usa em produção. Credenciais: cofundador, Techsy.io. Conecte-se no LinkedIn.

Perguntas frequentes

O que é um LLM de conversa multi-turn?

Um modelo de linguagem cuja enésima resposta depende de todos os turnos anteriores, não apenas do último prompt. Ele se condiciona ao thread inteiro, então o comportamento muda com o histórico da conversa. Essa dependência de contexto é o que testes single-turn não conseguem exercitar e que a avaliação multi-turn existe para pontuar.

O que significa avaliação de LLM?

Medir a qualidade da saída contra critérios definidos, de forma automática e repetível, em vez de no feeling. A avaliação single-turn pontua pares isolados de prompt e resposta contra métricas como BLEU ou um juiz LLM. A avaliação multi-turn estende isso a conversas inteiras, pontuando retenção de contexto e conclusão de objetivo ao longo dos turnos, e não por prompt.

Como fazer benchmark de desempenho multi-turn de LLM?

Construa pelo menos 20 cenários com objetivos e personas, simule-os contra o modelo e pontue com métricas em nível de conversa mais verificações em janela deslizante. Registre linhas de base ao longo de múltiplas execuções para absorver o não determinismo, e então compare cada nova versão contra a linha de base no CI. Traces de produção estendem o benchmark depois.

Quais são as melhores formas de avaliar um LLM?

Sequencie: análise manual de erros primeiro, depois portões binários de aprovado/reprovado para tudo que é redutível a uma regra, e então LLM-as-a-judge para critérios subjetivos como tom e qualidade da resolução. Verificações binárias são mais baratas, depuráveis e não derivam; juízes pertencem a critérios que genuinamente exigem julgamento, depois que os portões baratos passam.

Com quais métricas de avaliação multi-turn devo começar?

Completude da conversa, relevância por turno e retenção de conhecimento; elas capturam as falhas mais comuns (objetivos não resolvidos, desvio, esquecimento) em qualquer produto de chat. Adicione adesão ao papel se seu bot tem um limite de compliance, e então um critério personalizado G-Eval ou AspectCritic para o erro que seu negócio não pode pagar.

Quanto custa o LLM-as-a-judge por conversa?

Com uma janela deslizante de 5 sobre 10 turnos mais uma chamada em nível de conversa, você faz 7 chamadas de juiz por conversa. Com cerca de 2.000 tokens de entrada por chamada no GPT-4o-mini, nossa estimativa com a conta mostrada resulta em cerca de $0,29 por 100 conversas. Modelos juiz premium elevam isso 10 a 50 vezes.

DeepEval vs RAGAS para avaliação multi-turn: qual escolher?

DeepEval se você quer testes de regressão offline com um simulador de conversação integrado, especialmente antes de ter tráfego de produção. RAGAS se o seu workflow começa lendo conversas reais que falharam e codificando cada modo de falha como um AspectCritic. Uma divisão comum: DeepEval no CI, críticos estilo RAGAS em logs de produção.

De quantos cenários preciso para uma suíte de avaliação multi-turn?

Pelo menos 20, cobrindo casos de uso principais, casos extremos e situações propensas a falha; esse limiar vem da orientação publicada do DeepEval e bate com a nossa experiência. Abaixo de 20, as taxas de aprovação oscilam conforme quais cenários por acaso foram incluídos. Aumente o conjunto com cada falha de produção.

Posso rodar avaliação multi-turn em CI/CD?

Sim. Mantenha um conjunto fixo de cenários no repositório, rode-o a cada mudança de prompt ou de modelo e falhe o build quando uma métrica regredir além da tolerância contra a linha de base. Como modelos são não determinísticos, compare médias ao longo de 3 execuções com uma tolerância (usamos 0,03), não limiares exatos.

Como avaliar conversas multi-turn em produção?

Agrupe traces por thread de conversa, pontue cada thread de forma assíncrona para que a avaliação nunca bloqueie uma resposta, e encaminhe threads que falham para uma fila de revisão. Cada falha confirmada vira um novo cenário na sua suíte offline, fechando o loop entre monitoramento e testes de regressão.

A versão curta

• Pontuações single-turn não conseguem ver falhas de conversação; pesquisas mostram modelos degradando ao longo dos turnos apesar de benchmarks saudáveis.
• Rode pontuação em nível de conversa como seu portão e pontuação em janela deslizante para localizar quebras.
• Quatro métricas centrais mais um critério personalizado cobrem a maioria dos produtos de chat; verificações binárias antes de juízes, sempre.
• DeepEval para testes de regressão simulados, RAGAS para críticos orientados a análise de erros, Langfuse para traces de produção.
• Custos de juiz são pequenos (menos de um dólar por 100 conversas em um modelo mini); o custo raramente é o bloqueio.

Para o panorama mais amplo de ferramentas, classificamos o campo completo no nosso roundup das melhores ferramentas de avaliação de LLM. E se você prefere construir o pipeline de avaliação com alguém, receba uma consultoria gratuita com a equipe da Techsy.