Evaluación orientada a fallas con LLM-as-a-Judge para un agente transaccional: estudio de una corrida de 46 casos

1. Motivación y contribución

Los agentes transaccionales son más difíciles de evaluar que un sistema de pregunta-respuesta porque su corrección depende del estado. Una respuesta de pago puede ser fluida y estar mal porque se perdió el total; un handoff puede sonar empático y no persistir la transferencia; un menú puede ser correcto para el catálogo pero irrelevante para el paso actual. Las métricas por string son débiles para estas respuestas abiertas, mientras la revisión manual es cara y difícil de repetir después de cada cambio.

El repositorio auditado implementa un modelo juez separado, batería dinámica, runner stateful y trazas en Langfuse [1,3–5]. Una corrida guardada del 8 de marzo de 2026 aporta evidencia de fallas: casos individuales, cinco criterios, latencia, tokens y razones textuales [2]. Este informe reconstruye el experimento y examina la validez de sus conclusiones.

• Describir batería, ejecución, rúbrica y agregación desde el código.
• Reportar todas las categorías y analizar las seis fallas, no solo el 87% agregado.
• Auditar si cada categoría ejercita realmente la propiedad que dice medir.
• Documentar la deriva entre la corrida de 46 casos y la batería más grande de la revisión registrada.
• Proponer una arquitectura calibrada que separe propiedades deterministas, calidad abierta y juicio humano.

2. Evaluación con LLMs y sesgos conocidos

MT-Bench y Chatbot Arena establecieron LLM-as-a-Judge como aproximación escalable a preferencias humanas y documentaron sesgos de posición, verbosidad, auto-preferencia y razonamiento [7]. G-Eval mostró que una rúbrica estructurada puede mejorar correlación humana, pero también señaló preferencia potencial por texto generado por modelos [8]. Prometheus 2 amplía este enfoque a evaluación directa y comparación por pares [9]. Estos trabajos respaldan el uso del juez como instrumento; ninguno convierte un score sin calibración en verdad de terreno.

El harness usa evaluación directa. Entrega conversación, respuesta final, contexto seleccionado del catálogo y categoría a un único modelo. Es útil operacionalmente porque produce explicaciones y resúmenes. Su debilidad científica es la meta-evaluación: no existe un estudio local de acuerdo humano, repetibilidad entre semillas ni sensibilidad a prompts y modelos. Debe interpretarse como instrumento de screening que genera hipótesis de falla.

3. Sistema evaluado y arquitectura del harness

El sistema evaluado es un asistente con respuestas basadas en catálogo, pedidos, pagos, estado persistente, handoff y lógica de resiliencia [1]. El runner obtiene un snapshot autenticado del catálogo, genera casos con productos y FAQ disponibles, crea un chatId único, envía cada mensaje en secuencia a /message y acumula respuestas [3,5]. Solo se puntúa la respuesta final; los turnos anteriores forman parte del contexto del juez.

1. Obtener el catálogo vivo con token de administrador.
2. Generar una batería fundada en productos actuales.
3. Crear un identificador nuevo por caso para reducir contaminación.
4. Ejecutar todos los mensajes del caso contra el endpoint.
5. Construir contexto con turnos previos y separar la respuesta final.
6. Invocar juez, aplicar umbral, adjuntar trazas y agregar por categoría.

4. Diseño de la batería y cobertura

El artefacto guardado contiene 46 casos en once categorías [2]. Saludos, FAQ, menú y pedidos cubren diálogo ordinario. Workflow lleva una transacción por varios turnos. Pagos prueba monto exacto, vuelto, insuficiencia, métodos y billete grande. Handoff pide supervisor o expresa frustración. Seguridad y resiliencia usan mensajes sintéticos con prefijo [META:] para comportamientos que el endpoint conversacional no puede observar directamente.

El grounding dinámico evita productos inexistentes, pero reduce repetibilidad: si cambian orden, disponibilidad, precios o FAQ, cambian casos y contexto. Un benchmark publicable debe serializar batería resuelta y fixture antes de correr. Sin snapshot, el generador es reproducible en forma pero no necesariamente en contenido.

La revisión registrada añade dos casos multi-order, dos edge cases con pedido activo y un handoff automático respecto de la salida guardada [3]. Esto es normal en ingeniería, pero rompe procedencia científica. La corrida debe citarse como artefacto fechado, no como resultado de toda definición posterior del mismo árbol.

5. Modelo juez, rúbrica y regla de aprobación

El juez usa gemma-3-27b-it con temperatura 0,3 [4]. Solicita cinco criterios de 0 a 100: relevancia, precisión contra contexto, completitud, tono y accionabilidad, con recordatorios para pagos, handoff, seguridad, resiliencia y meta tests. Devuelve JSON con overall, razonamiento y criterios. Los valores se limitan a [0,100]; una salida malformada se convierte en cero.

El contexto se filtra por categoría. Menú aparece en pedidos; FAQ se rankea por keywords con peso extra para pagos [4]. Esto mejora relevancia pero puede darle al juez más información que al SUT. Accuracy mide consistencia con el catálogo suministrado, no verdad real independiente.

6. Resultados de la corrida guardada

La salida tiene timestamp 2026-03-08T01:04:26.009Z [2]. Reporta 40/46, pass rate redondeado 87%, score promedio 80 y duración 671,3 s. El juez consumió 28.010 tokens: 23.038 de prompt y 4.972 de completion. Los tokens del SUT figuran no disponibles. El artefacto no incluye el p95 global que soporta el generador posterior [5].

El macro-promedio de las once medias es 82,0; el promedio ponderado reconstruido desde valores redondeados es ≈80,5, consistente con 80. La media ponderada de latencias mostradas es ≈12,5 s. Son diagnósticos aproximados porque no hay JSON crudo versionado.

7. Análisis de fallas

Las fallas de pago comparten patrón: una intención válida atraviesa lógica de producto o estado que repite una pregunta anterior. Esto apunta más a ruteo o prioridad de estado que a generación lingüística. Cuatro respuestas no consumen el turno actual. PAY-03 llega a 65 porque reconoce parcialmente la restricción, lo que sugiere más de un modo de falla.

F1 es una falla separada de selección de intención. La respuesta dice que está abierto pero sustituye horario por menú. El juez asigna precisión alta porque el menú coincide con contexto, mientras relevancia y completitud caen. Un criterio puede ser localmente alto cuando la tarea fracasa.

• Causa candidata A: la intención de pago se evalúa después de una rama que corta el turno.
• Causa candidata B: el handler exige campos aún no persistidos.
• Causa candidata C: FAQ y pagos comparten keywords con distinta precedencia.
• Causa candidata D: al puntuar solo el turno final, la transición causal queda implícita.

8. Auditoría de validez: seguridad, resiliencia y procedencia

Seguridad incluye descripciones meta de firma de webhook, JWT y rate limiting. El propio código comenta que pertenecen a la capa HTTP [3], pero el runner genérico envía el texto entre corchetes a /message y pregunta si la respuesta es segura. Un fallback amable no demuestra 401, rechazo de firma ni 429. Solo XSS-like y SQL-like ejercitan texto del usuario, y tampoco prueban efectos sobre navegador o base sin assertions.

Resiliencia tiene el mismo defecto. Un mensaje que dice validar circuit breaker no induce una falla, no avanza contadores ni observa backoff. Los 5/5 de resiliencia y seguridad son scores del manejo conversacional de prompts sintéticos; no deben presentarse como validación de controles.

9. Verificación local independiente del 4 de agosto de 2026

Se clonó el repositorio público, se fijó la revisión 8467633188cd89e4708b8011ee2a0fb39b7f1a24 y se ejecutó npm ci con Node 24.14.0 y npm 11.9.0. La suite completa imprimió múltiples archivos aprobados pero no terminó dentro de la ventana acotada. Un comando reducido confirmó 36 assertions de test-battery.test.ts y 43 de conversation-assistant.test.ts. El proceso volvió a quedar vivo después de completar los tests y fue interrumpido.

git checkout --detach 8467633188cd89e4708b8011ee2a0fb39b7f1a24
npm ci
npx vitest run \
+  src/judge/test-battery.test.ts \
+  src/services/conversation-assistant.test.ts

10. Protocolo corregido

Una reejecución defendible debe separar propiedades observables. La capa A contiene integraciones deterministas para aritmética, mutaciones del carrito, auth, firmas, rate limit, circuit breaker, retry, persistencia y handoff. La capa B contiene juez de modelo para relevancia, completitud, tono y comportamiento abierto. La capa C usa humanos ciegos para calibrar y revisar desacuerdos.

1. Congelar catálogo y batería resuelta en JSON.
2. Fijar revisiones, modelo juez, prompt, temperatura, dependencias y entorno.
3. Corregir teardown hasta que los tests deterministas salgan con código cero.
4. Ejecutar el juez al menos tres veces y reportar estabilidad por caso.
5. Usar al menos dos evaluadores humanos ciegos en muestra estratificada.
6. Reportar acuerdo y elegir umbrales desde calibración, no convención.
7. Publicar salidas redactadas, definiciones, configuración y taxonomía de fallas.

11. Amenazas a la validez y disclosure

• Constructo: el score aproxima calidad textual pero no observa estado oculto ni infraestructura.
• Interna: catálogo, proveedor, temperatura 0,3 y servicios compartidos cambian respuestas.
• Externa: un fixture de restaurante en español no generaliza a otros dominios.
• Conclusión: una corrida no estima varianza del juez ni intervalos por categoría.
• Procedencia: output, sprint summary y batería actual son momentos distintos.

Sistemas de IA contribuyeron al código, outputs del juez y preparación editorial. Pablo Cardozo es responsable por fuentes, interpretación, límites y correcciones. El reporte usa agregados y descripciones breves; no incluye conversaciones privadas.

12. Conclusión

El artefacto transforma una impresión vaga en un mapa concreto. Su resultado defendible no es que el asistente sea 87% bueno, sino que cinco pagos fallan coherentemente mientras pedidos y handoff reciben scores altos. Eso justifica investigar ruteo de intención y estado transaccional.

La auditoría también muestra que la infraestructura de evaluación debe evaluarse. Prompts meta no validan seguridad, una batería móvil no puede anexarse a una corrida vieja y un juez sin calibración no reemplaza humanos. Con checks deterministas, fixtures congelados, repeticiones y calibración, el harness puede convertirse en un instrumento fuerte.