Evaluaciones de agentes en producción: el framework que funciona

Actualizado: 2026-05-03

La narrativa de 2024 era optimista: bastaba con un modelo capaz y un prompt bien pensado para construir un agente útil. La realidad de 2026, con cientos de equipos habiendo desplegado agentes a usuarios reales, es que la diferencia entre un agente que funciona y uno que va a la deriva está casi siempre en la parte menos glamorosa de la pila: las evaluaciones. No los modelos, no los prompts, no las herramientas — la medición.

Este artículo recoge el patrón que más ha convergido entre equipos que sostienen agentes en producción con fiabilidad razonable. No es teoría académica; es el conjunto de decisiones que se ven repetir cuando se comparan notas con ingenieros que llevan año y medio al frente del mismo sistema.

Puntos clave

• El golden dataset es la piedra angular: entre 30 y 200 casos, con el 60% de uso normal, 30% de casos fronterizos y 10% adversariales.
• El juez LLM no debe ser el mismo modelo que el evaluado; el prompt del juez debe pedir evaluación por rúbrica, no nota global.
• Las métricas deterministas (validación de JSON, verificación de URLs, conteo de fallos duros) deben filtrarse antes de invocar el juez.
• El umbral de regresión que bloquea el merge: 2% es ruido, 5% es señal, 10% es incidente.
• El mínimo viable se construye en una semana y empieza a pagar desde el primer incidente evitado.

Por qué “funciona en mi máquina” ya no basta

Durante la primera ola de adopción, muchos equipos se apoyaban en pruebas manuales: el producto leía respuestas, aprobaba visualmente si “sonaban bien” y empujaba a producción. Ese proceso funciona mientras el espacio de estados es pequeño. Deja de funcionar cuando aparecen tres cosas simultáneamente:

• El modelo se actualiza.
• La distribución de consultas cambia.
• El equipo crece lo suficiente como para que nadie tenga el contexto completo en la cabeza.

Los síntomas son siempre los mismos: regresiones silenciosas tras un cambio de modelo, prompts que parecían equivalentes que degradan calidad en casos concretos, un nuevo tipo de entrada que dispara fallos que nadie previó. Este es el punto donde la falta de evaluaciones deja de ser una deuda manejable y pasa a ser el cuello de botella principal. Para contexto más amplio sobre modos de fallo, ver lecciones de agentes en producción.

El golden dataset como piedra angular

El componente imprescindible es un conjunto de pruebas representativo, pequeño y curado con cuidado. La tentación inicial es capturar miles de entradas reales y lanzarlas al modelo, pero los equipos que triunfan convergen hacia datasets deliberadamente reducidos:

• Entre 30 y 200 ejemplos, cada uno con su respuesta esperada y la justificación de por qué está ahí.
• Distribución típica:
  • 60% de casos felices que representan el uso normal.
  • 30% de casos fronterizos donde el agente tiende a confundirse.
  • 10% de casos adversariales donde la entrada intenta romperlo a propósito.

La curaduría importa porque el dataset debe cubrir los modos de fallo que tu sistema ha demostrado históricamente. Cuando alguien reporta un bug, la respuesta correcta no es solo arreglarlo sino añadir el caso al golden dataset con una anotación clara: “este caso falló en la versión X porque el modelo ignoró la restricción Y”. A los seis meses, el dataset es un testigo vivo de todos los errores que el equipo ha aprendido a evitar.

Un error frecuente es incluir solo ejemplos donde la respuesta correcta es única y clara. Los agentes raramente operan en ese régimen. La mayoría de las tareas reales admiten varias respuestas válidas, y el dataset debe reflejarlo: ya sea expresando la evaluación como un rango aceptable, listando varias respuestas correctas, o delegando el juicio a un criterio cualitativo. Los datasets excesivamente deterministas sobreajustan a un único estilo y no detectan degradaciones sutiles de calidad.

LLM-as-judge para lo cualitativo

Para las métricas que no se pueden verificar programáticamente — coherencia, utilidad, cumplimiento de un estilo, ausencia de información inventada — el patrón que ha madurado es usar un modelo como juez. Dos reglas no negociables:

1. El juez NO debe ser el mismo modelo que el evaluado.
2. El prompt del juez debe ser extremadamente específico sobre los criterios.

El formato que genera menos falsos positivos es pedir al juez no una puntuación global, sino una evaluación por rúbrica: “evalúa estas seis dimensiones, cada una con una nota de 1 a 5, y justifica cada nota con una frase”. Pedir al juez una nota holística produce resultados inconsistentes entre ejecuciones; pedirle que puntúe dimensiones independientes produce resultados que correlacionan razonablemente con el juicio humano.

Un refinamiento que vale la pena: calibrar el juez contra un subconjunto de casos evaluados por humanos. Si el juez da 4,5 donde los humanos dan 3, el juez está inflando y hay que recalibrar el prompt. Esta verificación solo hay que hacerla de vez en cuando — cada trimestre, o cuando cambia el modelo del juez — pero es el único mecanismo que garantiza que el número que lees refleja algo real.

Métricas deterministas para lo verificable

Todo lo que sí se puede medir sin un modelo, hay que medirlo sin modelo:

• Si el agente produce JSON → valida el schema y cuenta los fallos de parseo como error grave.
• Si llama a herramientas → mide si las llamadas se ejecutan sin excepción.
• Si el output contiene URLs → comprueba que resuelven con HTTP 200.
• Si hay restricciones de longitud → mídelas.

Estas métricas son baratas, rápidas, deterministas y atrapan regresiones que un LLM-as-judge pasaría por alto porque enfocaría en la narrativa.

La combinación que funciona es una pirámide:

1. Filtrar primero con métricas deterministas (cualquier caso que falle aquí es un fallo duro que bloquea la integración).
2. Correr el juez sobre los casos que pasaron los filtros duros.
3. Solo entonces agregar a un número de calidad por rúbrica.

Regresión en integración continua

Las evaluaciones sin mecanismo automático de regresión son un ejercicio nostálgico. El patrón consolidado es correr la batería en cada cambio que toque el prompt, el modelo, las herramientas o la cadena del agente, y bloquear el merge si la métrica agregada cae por encima de un umbral:

• 2% de caída → ruido típico entre ejecuciones.
• 5% de caída → señal de regresión que merece investigación.
• 10% de caída → incidente.

Para equipos con volumen alto de cambios, la batería se divide en tres niveles:

1. Smoke test (~10 casos críticos): corre en cada push, feedback en menos de un minuto.
2. Batería nocturna completa: tarda 10 a 20 minutos sobre todo el golden dataset.
3. Comparación entre modelos: se ejecuta cuando se considera un cambio de modelo y compara el candidato nuevo contra el actual en todas las dimensiones.

Observabilidad en producción

El golden dataset cubre los casos que conoces. Los usuarios reales producen casos que no conoces. La parte final del sistema es capturar trazas de producción y alimentarlas al dataset cuando detectas comportamientos inesperados.

Herramientas como LangSmith, Braintrust, HoneyHive o Promptfoo ofrecen flujos específicos para este bucle. La parte delicada es qué se captura. Idealmente:

• La entrada del usuario.
• La respuesta del agente.
• Cada llamada a herramienta con su resultado.
• El estado final del agente.

Menos que eso y no reproduces el fallo. Con ese nivel de traza, cualquier incidente se puede replicar offline, debugear con calma y añadir al golden dataset para que no vuelva a suceder. Este nivel de trazabilidad es el mismo que exige la gobernanza de agentes en empresa desde el plano de auditoría.

Qué evitar

Algunos antipatrones ya son folklore entre equipos experimentados:

• Evaluar solo con el modelo como juez sin ningún ancla determinista, porque amplifica errores del juez sin posibilidad de detección.
• Usar una métrica agregada única como único indicador, porque oculta dónde está el problema.
• Correr evals solo en el golden dataset sin observabilidad en producción, porque los fallos reales ocurren fuera del dataset.
• Aceptar puntuaciones del juez sin calibrar contra humanos, porque pueden medir algo distinto a lo que crees.
• Bloquear el merge con umbrales rígidos que son ruido estadístico, porque acabas ignorándolos y pierdes el beneficio.

La forma práctica de empezar

Si no tienes nada, el camino mínimo es:

1. 30 casos curados con respuestas esperadas.
2. Un prompt de juez con rúbrica de cinco dimensiones.
3. Tres o cuatro validaciones deterministas específicas de tu dominio.
4. Un script que corre todo en minuto y medio y escupe un número y un desglose.
5. Integrado en CI para que se ejecute en cada PR que toque el agente.

Esa base se puede construir en una semana y empieza a pagar desde el primer incidente evitado.

A partir de ahí, la expansión es oportunista: cada bug nuevo añade un caso al dataset, cada dimensión relevante añade una métrica, cada cambio de modelo desencadena una comparación completa. El sistema crece con el producto.

Conclusión

Las evaluaciones son el motor silencioso de los agentes que funcionan en producción. No son glamurosas, no se demuestran bien, no se viralizan. Son la infraestructura que permite que todo lo demás — modelos, prompts, herramientas, arquitecturas — se pueda comparar, mejorar y defender.

Los equipos que invierten en evaluaciones seis meses antes de necesitarlas agradecen haberlo hecho; los que las construyen después de un incidente aprenden por la vía cara. La decisión es cuándo, no si.