Evaluación LLM multiturno: 5 métricas, 3 frameworks, 1 flujo de trabajo

Evaluación LLM multiturno: 5 métricas, 3 frameworks, 1 flujo de trabajo

La evaluación LLM multiturno es la única forma de detectar el bug de amnesia del turno 8: el usuario dio su número de pedido en el turno 3 y el bot se lo vuelve a pedir. Cada turno pasó por separado; la conversación, igual falló. DeepEval 4.0 y RAGAS 0.4 lanzaron APIs de evaluación conversacional dedicadas justo para esto, y después de dos incidentes de evals en nuestro propio pipeline en Techsy, aquí van las cinco métricas, tres frameworks y un flujo de trabajo para empezar.

Puntos clave

• La evaluación multiturno puntúa conversaciones completas, no pares aislados de entrada-salida.
• Los modelos que lideran los benchmarks de un solo turno se degradan de forma medible entre turnos.
• Empieza con cuatro métricas: completitud, retención de conocimiento, adherencia al rol y relevancia por turno.
• DeepEval, RAGAS y Langfuse resuelven la eval multiturno de forma distinta; la tabla de frameworks de abajo los compara.

¿Por qué te mienten las puntuaciones de un solo turno?

Las evals de un solo turno puntúan un par entrada-salida a la vez, así que no pueden ver fallos que solo aparecen entre turnos: olvidos, contradicciones, deriva. Un modelo puede publicar un buen score de benchmark y aun así perder el hilo de una conversación real. Laban et al. lo documentan en Los LLM se pierden en las conversaciones multiturno, 353 citas: el rendimiento se degrada en entornos multiturno incluso cuando los resultados de un solo turno parecen sanos.

El problema de fondo es el no determinismo: la respuesta n-ésima depende de los n-1 turnos previos, así que prompts idénticos se comportan distinto según el historial. Un dataset de pares aislados nunca ejercita esa dependencia. El survey de arXiv Evaluación de agentes basados en LLM para conversaciones multiturno, una revisión PRISMA de unas 250 fuentes, divide el campo entre qué evaluar (gestión de contexto, planificación, coherencia) y cómo (métricas, jueces LLM, revisión humana). Ambos ejes están ausentes de una suite de un solo turno.

Nada de esto vuelve inútil tu stack de un solo turno. Si ya usas métricas de un solo turno como BLEU, ROUGE y G-Eval, quédate con ellas para lo que miden bien: cumplimiento de formato, toxicidad, recall factual sobre un prompt fijo. Solo deja de leerlas como un chequeo de salud de la conversación que tocan tus usuarios.

Nuestra interpretación de esos estudios, en una línea:

Las evals de un solo turno miden la respuesta; la evaluación multiturno mide la conversación, y un modelo que borda el turno uno puede estar perdido en el turno cinco.

¿Qué es la evaluación LLM multiturno? Los dos modos de evaluación

La evaluación LLM multiturno es la práctica de puntuar una conversación completa, o ventanas dentro de ella, en lugar de pares aislados de prompt-respuesta. Pregunta si el modelo mantuvo el contexto, se quedó en su rol y resolvió el problema del usuario a lo largo de los turnos. Dos modos hacen el trabajo: la puntuación a nivel de conversación y la puntuación por turnos con ventana deslizante, y la mayoría de los equipos ejecutan ambos.

La puntuación a nivel de conversación le pasa al juez la transcripción completa y hace una pregunta: ¿tuvo éxito esta conversación? Detecta cierres prematuros y bucles sin resolver, ya que solo el hilo completo revela que el usuario nunca consiguió su reembolso. Su debilidad es la granularidad: un "falló" en un hilo de 12 turnos no dice dónde se rompió todo.

La puntuación por turnos con ventana deslizante mueve una ventana de N turnos sobre la transcripción, un veredicto por ventana. Una ventana de 3 sobre una conversación de 10 turnos produce 8 veredictos atados a regiones del chat, así que el "falló" viene con coordenadas: la ruptura ocurrió entre los turnos 6 y 8. El diagrama al inicio de este post muestra ambos modos sobre un mismo hilo: un corchete para el veredicto de conversación y un marco deslizante para los veredictos por ventana.

Usa la puntuación a nivel de conversación como puerta y la puntuación por ventanas para localizar fallos cuando salte. La guía de evaluación multiturno de DeepEval plantea la unidad de trabajo como un escenario y no como un par entrada-salida (su tipo ConversationalGolden): estás probando una situación, no una pregunta.

Ejemplo ilustrativo (sintético; muestra la mecánica, no una ejecución real): una ventana deslizante de 3 sobre un chat de solicitud de devolución de 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?

Veredicto a nivel de conversación: falló. Cinco de seis ventanas pasaron y el hilo se rompió igual en retención de conocimiento, exactamente el fallo que una suite de un solo turno nunca saca a la luz.

¿Qué métricas multiturno importan? Las 5 que sí

Ejecuta primero cuatro métricas: completitud de la conversación, retención de conocimiento, adherencia al rol y relevancia por turno. Añade una quinta, un criterio personalizado (G-Eval en DeepEval, AspectCritic en RAGAS), para eso que tu producto no puede fallar. Las cuatro primeras se transfieren entre proyectos; la quinta es donde viven tus modos de fallo.

1. Completitud de la conversación. ¿Se resolvió el objetivo del usuario o el bot cantó victoria antes de tiempo? Tu detector de cierres prematuros.
2. Retención de conocimiento. ¿Recuerda el modelo los datos dichos antes en el hilo? El bug de amnesia del turno 8 es un fallo de retención de conocimiento.
3. Adherencia al rol. ¿El asistente se mantiene dentro de su persona y rechaza peticiones fuera de alcance? Crítico con un límite de cumplimiento normativo.
4. Relevancia por turno. ¿Cada respuesta está en tema dados los turnos previos? Detecta deriva y bucles.
5. Un criterio personalizado. Una regla en lenguaje llano para tu dominio: "nunca cites un precio distinto al de la lista oficial". DeepEval lo implementa como ConversationalGEval; RAGAS como AspectCritic.

La guía de métricas de DeepEval define cada una con clases ejecutables, pero los conceptos son independientes del framework: la tabla se sostiene aunque te fabriques el juez a mano.

Un criterio personalizado se lee como 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 misma regla 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: ¿qué framework encaja?

Los tres evalúan conversaciones multiturno, pero su unidad de evaluación difiere: DeepEval simula escenarios offline, RAGAS puntúa aspectos de conversaciones que ya tienes y Langfuse evalúa trazas reales de producción. Elige según de dónde vienen tus conversaciones, no por la cantidad de funciones.

Primero la lógica independiente del framework, para que el código de proveedores de abajo sea portable:

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: escenarios y un simulador con todo incluido

DeepEval es el único con un simulador de conversaciones de primera clase: describe un escenario y una persona, y él hace de usuario contra tu bot. Su guía multiturno es la referencia canónica del patrón escenarios-no-pares. Confident AI vende el dashboard alojado; nuestro análisis de Confident AI cubre lo que añade la capa de pago.

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: guiado por análisis de errores, aspecto a aspecto

RAGAS arranca de conversaciones que ya tienes y las puntúa aspecto a aspecto. Su how-to multiturno se combina con análisis manual de errores: lee los chats fallidos, escribe un AspectCritic por modo de fallo y puntúa.

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: evaluación N+1 sobre trazas reales

Langfuse toma el camino opuesto: tracer primero. Su cookbook N+1 evalúa la traza de cada turno más la conversación como un todo, sobre tráfico de producción y no sobre simulaciones. Si aún estás eligiendo la capa de observabilidad, nuestra comparativa de Langfuse vs LangSmith cubre esa decisión.

Nuestro veredicto, sin equidistancia: para un proyecto de chatbot nuevo, empieza con DeepEval. El simulador te permite bloquear regresiones antes de tener tráfico de producción, que es cuando más necesitas tests. Añade Langfuse cuando ya existan hilos reales; recurre a RAGAS cuando tu equipo prefiera leer conversaciones fallidas y codificar lo que encuentre.

¿Cómo pasas del análisis de errores a la automatización?

Lo secuencias. Lee 20-30 conversaciones reales, etiqueta los modos de fallo a mano, escribe checks binarios de pasa/falla para los obvios, automatiza esos y solo entonces añade métricas juzgadas por LLM para el residuo subjetivo. Hamel Husain defiende exactamente este orden: primero análisis manual de errores y decisiones binarias, porque un check que puedes explicar le gana a una puntuación que no puedes.

Binario antes que juez: la secuencia que nos salvó

Esto no es un benchmark de chatbots que ejecutamos; es nuestra interpretación del mismo patrón dentro de nuestro propio pipeline de contenido, que corre checks de regresión con puerta de evals en cada cambio de prompt y de herramientas. Dos incidentes nos demostraron la secuencia.

El 2026-06-13, un bug de republicación acuñó slugs localizados nuevos y despachó 54 documentos duplicados en vivo. Los encontramos y despublicamos el 2026-07-05 (copia de seguridad en techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). El arreglo no fue un modelo más listo; fue un check determinista pre-publicación: resolver el documento existente por post canónico más idioma antes de cualquier creación. Una puerta binaria.

Segundo incidente: los LLM de traducción a veces emiten ASCII en lugar de Unicode, convirtiendo "karşılaştırma" en "karsilastirma". No hace falta juez; una puerta de grep lo detecta:

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

Ambos los detectaron checks que cuestan fracciones de céntimo y dicen exactamente por qué fallaron. Llévalo a las evals multiturno: "¿el bot volvió a pedir un campo que el usuario ya dio?" es una coincidencia de cadenas contra la transcripción, no una llamada al juez. Ejecuta primero las puertas deterministas y baratas; detectan los fallos feos antes de que tu juez caro llegue a ejecutarse.

Cuando un juez LLM es de verdad la herramienta correcta

Los jueces se ganan su coste en tokens en criterios que no puedes reducir a una regla: "¿el tono fue adecuadamente disculpatorio?", "¿la resolución encajó con la situación?". Si puedes escribir una aserción, escribe una aserción. Una rúbrica llena de juicios es territorio de juez.

La línea a la que volvemos siempre:

Empieza con checks binarios de pasa/falla que puedas explicarle a un compañero, y añade jueces LLM solo para lo que no puedas reducir a una regla.

¿Cómo simulas conversaciones a escala y cuánto cuesta juzgar?

Simula desde escenarios, no desde logs exportados. Los escenarios prueban lo que podría pasar; los logs solo muestran lo que tu sistema actual ya permitió. La guía de DeepEval advierte que las conversaciones históricas las dio forma el sistema que las produjo, así que hacer benchmark contra ellas consolida el statu quo.

Escenarios, no transcripciones

Escribe cada escenario como objetivo más persona: "cliente impaciente que devuelve un pedido dañado", "usuario que cambia de opinión a mitad de una reserva". Fija un límite de turnos (10 es razonable) y una condición de parada: objetivo alcanzado, el usuario abandona o el tope. DeepEval recomienda al menos 20 escenarios diversos entre casos de uso principales, casos límite y situaciones propensas al fallo; por debajo de eso, tu suite mide anécdotas.

Personas adversarias

Incluye personas que intentan romper el bot: un usuario enfadado que escala, un usuario confundido que se contradice, un usuario de inyección que cuela instrucciones en el turno 4. La inyección multiturno es su propia disciplina; nuestra guía de guardrails para LLM cubre la capa defensiva que se combina con estos tests, y el cookbook de simulación de Langfuse muestra el bucle del simulador de usuario.

Cuánto cuestan 100 conversaciones evaluadas

Cada cifra de abajo es una estimación a partir de conteos de tokens declarados y precios públicos, no una medición que ejecutamos. La aritmética es el punto: sustituye tus propios números.

Menos de un dólar por 100 conversaciones totalmente juzgadas. Un juez más caro mueve esto 10-50x, y las tácticas de nuestra guía para reducir costes de API de LLM aplican: cachea el texto de los criterios, procesa ventanas en lote, usa el modelo barato para las puertas binarias.

Un flujo de evaluación multiturno en 6 pasos

El bucle funciona así: define escenarios desde fallos reales, elige cuatro métricas centrales más una personalizada, simula al menos 20 escenarios, establece una línea base de la versión actual, bloquea regresiones en CI y retroalimenta los fallos de producción al set de escenarios.

1. Define escenarios desde los fallos. Lee 20-30 transcripciones (o, antes del lanzamiento, escríbelas desde tickets de soporte). Cada escenario recibe un objetivo, una persona y un tope de turnos. Responsable: tú y el método de análisis de errores primero de Hamel.
2. Elige cuatro métricas, una personalizada. Completitud, retención de conocimiento, adherencia al rol, relevancia por turno y un ConversationalGEval o AspectCritic para el error caro de tu dominio.
3. Simula. Ejecuta al menos 20 escenarios, incluido el set adversario. Responsable: el ConversationSimulator de DeepEval o el cookbook de simulación de Langfuse.
4. Línea base de la versión actual. Registra las medias por métrica sobre 3 ejecuciones, ya que los modelos no son deterministas y una sola ejecución es ruido. Responsable: tu script de evals, con resultados commiteados al repo.
5. Bloquea regresiones en CI. Fija un umbral por métrica y falla el build ante una regresión más allá de una tolerancia:

# 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. Monitorea los hilos de producción. Agrupa las trazas en vivo por hilo, evalúa de forma asíncrona y convierte cada hilo fallido en un escenario nuevo. Responsable: Langfuse o tu tracer; nuestras guías sobre evaluar agentes de IA en producción y observabilidad de IA cubren la mitad del monitoreo.

La suite nunca está terminada: el paso 6 alimenta el paso 1 y el set de escenarios crece con cada fallo de producción que detectas.

¿Cómo evalúas el tono entre idiomas?

Una métrica de adherencia al rol afinada con datos en inglés aprobará una transcripción en turco o japonés que un nativo encuentra grosera, porque el registro de cortesía es específico de cada idioma. Tu rúbrica en inglés no tiene palabras para eso. El arreglo: un criterio de aspecto por expectativa de registro, escrito por idioma, no una métrica de tono global única.

Un criterio por registro

Nuestra interpretación del patrón AspectCritic de RAGAS, extendida desde la operación de un pipeline en 23 idiomas, no un resultado de prueba 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 criterio es un crítico binario separado sobre la misma transcripción. No hemos publicado puntuaciones de tono entre idiomas y no confiaríamos en un artículo que las imprima sin la rúbrica. Del trabajo de pipeline: los fallos se concentran en los turnos de disculpa y escalada, donde el registro colapsa primero.

Preguntas frecuentes

¿Qué es un LLM conversacional multiturno?

Un modelo de lenguaje cuya respuesta n-ésima depende de todos los turnos previos, no solo del último prompt. Se condiciona sobre el hilo completo, así que su comportamiento cambia con el historial de la conversación. Esa dependencia del contexto es lo que los tests de un solo turno no pueden ejercitar y la evaluación multiturno existe para puntuar.

¿Qué significa evaluación de LLM?

Medir la calidad de la salida contra criterios definidos, de forma automática y repetible, en lugar de a ojo. La evaluación de un solo turno puntúa pares aislados de prompt-respuesta contra métricas como BLEU o un juez LLM. La evaluación multiturno extiende eso a conversaciones completas y puntúa la retención de contexto y la consecución del objetivo entre turnos, no por prompt.

¿Cómo haces benchmark del rendimiento multiturno de un LLM?

Construye al menos 20 escenarios con objetivos y personas, simúlalos contra el modelo y puntúa con métricas a nivel de conversación más checks de ventana deslizante. Registra líneas base sobre varias ejecuciones para absorber el no determinismo y luego compara cada versión nueva contra la línea base en CI. Las trazas de producción extienden el benchmark después.

¿Cuáles son las mejores formas de evaluar un LLM?

Secuéncialo: primero análisis manual de errores, luego puertas binarias de pasa/falla para todo lo reducible a una regla y después LLM-as-a-judge para criterios subjetivos como el tono y la calidad de la resolución. Los checks binarios son más baratos, depurables y no derivan; los jueces pertenecen a criterios que de verdad exigen juicio, después de que las puertas baratas pasen.

¿Con qué métricas de evaluación multiturno debería empezar?

Completitud de la conversación, relevancia por turno y retención de conocimiento; detectan los fallos más comunes (objetivos sin resolver, deriva, olvidos) en cualquier producto de chat. Añade adherencia al rol si tu bot tiene un límite normativo y luego un criterio personalizado de G-Eval o AspectCritic para el error que tu negocio no puede permitirse.

¿Cuánto cuesta LLM-as-a-judge por conversación?

Con una ventana deslizante de 5 sobre 10 turnos más una llamada a nivel de conversación, haces 7 llamadas al juez por conversación. Con unos 2,000 tokens de entrada por llamada en GPT-4o-mini, nuestra estimación con las cuentas mostradas sale a unos $0.29 por 100 conversaciones. Los modelos juez premium suben eso 10-50x.

DeepEval vs RAGAS para evaluación multiturno: ¿cuál elijo?

DeepEval si quieres tests de regresión offline con un simulador de conversaciones integrado, sobre todo antes de tener tráfico de producción. RAGAS si tu flujo empieza leyendo conversaciones reales fallidas y codificando cada modo de fallo como un AspectCritic. Una división común: DeepEval en CI, críticos estilo RAGAS sobre logs de producción.

¿Cuántos escenarios necesito para una suite de evals multiturno?

Al menos 20, que cubran casos de uso principales, casos límite y situaciones propensas al fallo; ese umbral viene de la guía publicada de DeepEval y coincide con nuestra experiencia. Por debajo de 20, las tasas de aprobados oscilan según los escenarios que quedaron incluidos. Haz crecer el set con cada fallo de producción.

¿Puedo correr evaluación multiturno en CI/CD?

Sí. Mantén un set fijo de escenarios en el repo, ejecútalo en cada cambio de prompt o de modelo y falla el build cuando una métrica retroceda más que la tolerancia contra la línea base. Como los modelos no son deterministas, compara medias sobre 3 ejecuciones con una tolerancia (nosotros usamos 0.03), no umbrales exactos.

¿Cómo evalúo conversaciones multiturno en producción?

Agrupa las trazas por hilo de conversación, puntúa cada hilo de forma asíncrona para que la evaluación nunca bloquee una respuesta y manda los hilos fallidos a una cola de revisión. Cada fallo confirmado se convierte en un escenario nuevo de tu suite offline, cerrando el bucle entre monitoreo y tests de regresión.

La versión corta

• Las puntuaciones de un solo turno no pueden ver los fallos conversacionales; la investigación muestra modelos que se degradan entre turnos pese a benchmarks sanos.
• Corre la puntuación a nivel de conversación como puerta y la puntuación con ventana deslizante para localizar rupturas.
• Cuatro métricas centrales más un criterio personalizado cubren la mayoría de productos de chat; checks binarios antes que jueces, siempre.
• DeepEval para tests de regresión simulados, RAGAS para críticos guiados por análisis de errores, Langfuse para trazas de producción.
• Los costes de juez son pequeños (menos de un dólar por 100 conversaciones con un modelo mini); el coste rara vez es el bloqueo.

Para el resto del ecosistema de herramientas, ordenamos todas las opciones en nuestro roundup de las mejores herramientas de evaluación LLM. Y si prefieres construir el pipeline de evals con alguien, consigue una consulta gratuita con el equipo de Techsy.