Evals para agentes de IA: la infraestructura que separa una demo de un producto

Un eval (evaluación) es una prueba automatizada que mide si la salida de un modelo o de un agente es correcta, útil y segura para un caso concreto. Es al software con IA lo que el test unitario es al software tradicional: sin evals no sabes si tu último cambio de prompt, tu subida de versión de modelo o tu nueva herramienta MCP ha mejorado el producto o lo ha roto. La única diferencia es que aquí la salida no es determinista, y por eso la disciplina cambia.

Si estás construyendo un producto sobre LLMs y todavía validas los cambios "probando un par de prompts a mano y viendo si suena bien", este artículo es para ti. La tesis es simple: en 2026 el eval coverage está camino de ser una métrica tan normal como el test coverage, y los equipos que envían agentes fiables son los que tienen buena infraestructura de evaluación, no los que tienen el mejor prompt.

Por qué ahora

Durante un tiempo, evaluar a ojo fue suficiente porque los productos con IA eran finos: un prompt, una llamada, una respuesta. Eso ya no es la realidad de producción. Un agente en 2026 se conecta a decenas de herramientas vía MCP, y una sola tarea del usuario se abre en decenas o cientos de llamadas a APIs, bases de datos, navegadores y sandboxes de código. Cuando la ejecución es un árbol y no una línea, "probarlo a mano" deja de escalar: no puedes revisar cientos de trayectorias por cada cambio, y los fallos dejan de ser "la respuesta está mal" para convertirse en "llamó a la herramienta equivocada en el paso 7".

A esto se suma la fatiga de releases. Si cada pocas semanas sale un modelo nuevo —y este año han salido muchos—, la única forma honesta de decidir si migrar es medir. Sin un conjunto de evals, "el modelo nuevo es mejor" es una nota de prensa, no un dato tuyo.

Los tres niveles de evaluación

No todos los evals miden lo mismo. Conviene separarlos porque responden a preguntas distintas y se rompen por motivos distintos.

  1. End-to-end (tarea completa): ¿el agente resolvió lo que el usuario pidió, sin intervención humana? Es la métrica que le importa al negocio. La más citada es el task completion rate: el porcentaje de invocaciones que producen una salida usable. Integra precisión, fiabilidad y seguridad en un solo número, pero no te dice por qué falla.

  2. Trayectoria: ¿el camino que siguió el agente fue eficiente y correcto? Aquí se evalúa el enrutado, los argumentos con los que llamó a cada herramienta y el orden de los pasos. Un agente puede acertar la respuesta final por casualidad tras cinco llamadas innecesarias; a nivel de trayectoria eso es un fallo, aunque el resultado sea correcto.

  3. Componente: ¿qué eslabón concreto se rompió? Aísla un paso —una extracción, una clasificación, una llamada a una tool— para poder arreglarlo sin adivinar. Es el nivel que convierte un "a veces falla" en un ticket accionable.

Un equipo maduro mide los tres. El end-to-end te avisa de que algo va mal; la trayectoria y el componente te dicen dónde.

Las seis piezas de una infraestructura de evals

Montar evals no es escribir un test y ya. Es un problema de ingeniería con seis partes que tienen que encajar:

  • Dataset: los casos contra los que evalúas. La mejor fuente no es sintética: es tu tráfico de producción. Los casos límite que encuentran tus usuarios valen más que cualquier batería de ejemplos inventados. El dataset crece: cada nuevo modo de fallo que aparece en producción se convierte en un caso de regresión.
  • Métricas: qué mides en cada caso (exactitud, formato, latencia, coste, uso correcto de herramientas, ausencia de alucinación).
  • Judge: quién puntúa. Puede ser una comprobación determinista (¿el JSON valida?, ¿llamó a la tool correcta?), un modelo actuando de juez, o una persona.
  • CI gate: el eval corre en cada pull request, antes de mergear. Nada llega a producción sin pasar. El cambio de prompt viaja en la PR con sus métricas de calidad, igual que un cambio de código viaja con sus tests.
  • Observación en producción: online evals que puntúan tráfico real, muestreando trazas en vivo o enganchando jueces ligeros a los spans de producción. Es tu red de seguridad para lo que el dataset no anticipó.
  • El loop: el bucle que cierra todo lo anterior. Los fallos de producción alimentan el dataset, el dataset endurece el CI gate, y el ciclo se repite. Sin este bucle, las otras cinco piezas envejecen.

Si tuviéramos que señalar la pieza que más gente se salta, es el CI gate. Es fácil tener un notebook con evals que alguien corre "de vez en cuando". Es otra cosa que ninguna PR se mergee sin pasar por ellos. La segunda disciplina es la que cambia productos.

LLM-as-judge: útil, con letra pequeña

Usar un modelo para evaluar la salida de otro modelo (LLM-as-judge) es hoy el patrón por defecto para lo que no se puede comprobar de forma determinista: calidad de un RAG, tono de un chatbot, corrección de un resumen, solidez de un razonamiento. Es potente porque escala a cosas que ningún assert captura.

Pero no es gratis ni infalible, y aquí es donde toca ser honesto sobre cuándo NO fiarse solo del juez:

  • Un juez LLM tiene sesgos conocidos: tiende a preferir respuestas más largas, o la primera de dos opciones. Hay que calibrarlo contra puntuaciones humanas antes de creerle.
  • Para todo lo que sí se puede comprobar de forma determinista —¿valida el esquema?, ¿la cifra cuadra?, ¿llamó a la herramienta correcta?— usa una comprobación determinista. Es más barata, más rápida y no alucina. El juez LLM es para lo subjetivo, no para lo verificable.
  • Un juez añade coste y latencia. En online evals sobre producción, eso se paga en cada traza que muestreas.

La regla práctica: comprobación determinista siempre que se pueda, juez LLM cuando no quede otra, y calibración humana por encima de ambos para lo que de verdad importa.

Cuándo NO montar tu propia infraestructura de evals

Coherentes con nuestra forma de escribir, aquí va el matiz que casi nadie pone. No todo producto necesita el aparato completo:

  • Si tu caso es determinista de verdad —extraes un campo, clasificas en tres categorías cerradas, transformas un formato— no necesitas un juez LLM ni un pipeline de trazas. Necesitas tests normales. Meter evals con modelo encima es sobreingeniería cara.
  • Si estás en fase de discovery y aún no sabes si el producto tiene sentido, un dataset de 20 casos bien elegidos en una hoja de cálculo te da el 80% del valor. Construir infraestructura antes de tener señal de producto es optimizar lo que quizá tires.
  • Si tu volumen es bajo y el coste de un fallo es asumible, la revisión humana por muestreo puede ser más barata que mantener jueces y datasets. Los evals compensan cuando el volumen o el riesgo hacen que revisar a mano no escale.

La inversión en evals debe crecer con el volumen y con el coste de equivocarse, no por moda. Un equipo que factura sobre decisiones de un agente necesita eval coverage; un prototipo de fin de semana, no.

Cómo lo abordamos nosotros

En Dribba llevamos desde 2011 montando producto digital, y con la IA aplicada hemos trasladado la misma disciplina que ya aplicábamos al backend en Go o a las apps en Flutter: nada llega a producción sin una forma automatizada de saber si funciona. Con un equipo 100% senior in-house, cuando montamos un agente para un cliente el eval no es un extra opcional al final, sino parte del diseño desde el primer sprint —empezando por lo barato (comprobaciones deterministas, un dataset pequeño de tráfico real) y subiendo la inversión solo cuando el volumen lo justifica.

Es la misma idea que defendemos al elegir dónde ejecutar el runtime de un agente: decisiones medibles, sin hype, con la letra pequeña puesta encima de la mesa.

En resumen

Los evals son la infraestructura que convierte una demo impresionante en un producto que puedes mantener. Mídelos en tres niveles, monta las seis piezas cuando el caso lo pida —y solo cuando lo pida—, usa jueces LLM con calibración y no te saltes el CI gate. En 2026, "¿cuál es tu eval coverage?" empieza a ser una pregunta tan razonable en una revisión de sprint como "¿cuál es tu test coverage?".

Si estás llevando un agente de la demo a producción y quieres que la parte de evaluación esté bien puesta desde el principio, hablémoslo.