Los evals son la única suite de regresión que un sistema de IA te va a dar

No puedes escribir assertEquals contra un sistema que no devuelve la misma respuesta dos veces. Todos los equipos que construyen sobre un LLM lo descubren la primera semana — y la mayoría reacciona dejando de escribir tests.

Llevo dos décadas en sistemas donde la suite de regresión era el contrato. Si el CI estaba en verde, desplegabas; si un cambio rompía comportamiento, la build roja lo cazaba antes que un cliente. Luego empecé a llevar a producción funcionalidades apoyadas en LLMs y ese contrato saltó por los aires. La temperatura cero no lo restaura: con inferencia por lotes y acumulación en coma flotante, el mismo prompt puede producir el martes tokens distintos de los del viernes. La caja de herramientas determinista — fixtures, snapshots, aserciones exactas — testea el 20% del sistema que nunca iba a romperse.

La conclusión habitual es que los sistemas de IA no se pueden testear, así que se lanza y se vigilan dashboards. Yo creo que es justo al revés. Los sistemas de IA sí se pueden testear — la disciplina existe, se llama evals, y los equipos que la tratan con el mismo rigor que el CI son los que tienen agentes que sobreviven al contacto con producción. En el último post de nuestra serie sobre loops agénticos defendí que el loop es el 20% fácil y los guardrails el 80% restante. Los evals son la mitad de ese 80% que casi todo el mundo se salta.

Una actualización de modelo es un bump de dependencia que nadie revisa

Empecemos por qué hay regresiones en un sistema que no has vuelto a desplegar. El comportamiento de tu funcionalidad de IA es función de al menos cuatro entradas que cambian cada una por su cuenta:

• El modelo. Los proveedores reentrenan y cambian el modelo que hay detrás de un alias estable. El modelo contra el que afinaste tu prompt en marzo no es el que sirve las respuestas en julio, y ningún changelog te dirá qué cambió.
• El prompt. Cada edición del prompt es un despliegue. Equipos que exigen revisión para tocar una línea de configuración dejan pasar un cambio de 40 líneas en el system prompt con un visto bueno en Slack.
• El contexto. Si haces retrieval, tu índice RAG muta a diario según entran documentos. Mismo prompt, mismo modelo, distinto grounding — distinta respuesta.
• Las herramientas. Renombra un parámetro en el esquema de una tool y el agente que llevaba meses llamándola bien empieza a adivinar.

Cada una de esas cosas es un despliegue que ningún test vigila. En software clásico lo llamaríamos entrega continua sin pipeline. Ese es el hueco que cubre la suite de evals: un conjunto fijo de casos, ejecutado en cada cambio, que te dice si el comportamiento ha cambiado.

El golden dataset es la spec que nunca escribiste

Una suite de evals empieza por un golden dataset: entradas reales con el comportamiento esperado etiquetado. La palabra clave es reales. El fallo que me sigo encontrando en auditorías es el golden set construido a partir del guion de la demo — veinte casos impecables que el equipo se inventó, todos en verde, mientras la funcionalidad se degrada con el tráfico que los usuarios envían de verdad.

Constrúyelo con trazas de producción. Captura todas las interacciones desde el primer día — entradas, contexto recuperado, llamadas a herramientas, salidas — y siéntate a etiquetar un centenar. Es trabajo de pico y pala, y es también donde se define el producto: en el momento en que alguien tiene que dejar por escrito cuál es el comportamiento correcto para un caso real y sucio, afloran todos los desacuerdos que el equipo llevaba meses aplazando. El golden dataset es la spec que nunca escribiste, extraída caso a caso.

Después, ordena las aserciones por coste. Primero las deterministas: la salida parsea como JSON, se llamó a la herramienta correcta, el importe del reembolso queda por debajo del tope de la política, no aparece ningún email en la respuesta. Cuestan milisegundos y no admiten discusión — y «comportarse bien» se reduce a eso más veces de las que parece. Después las semánticas, para los juicios que el código no puede hacer: si la respuesta estaba anclada en el contexto recuperado, si el tono era el adecuado, si declinó la petición fuera de alcance. Ahí entra el juez.

Un juez LLM es un revisor al que también hay que revisar

Usar un modelo frontera para puntuar las salidas de tu sistema es ya práctica estándar, y el resultado fundacional se sostiene: el paper de MT-Bench (Zheng et al., NeurIPS 2023) midió una concordancia de GPT-4 con evaluadores humanos superior al 80% — la misma que alcanzan los humanos entre sí. Un modelo juez es la única manera escalable de puntuar semántica.

También es un componente con sus propios modos de fallo, documentados en el mismo paper: sesgo de posición (preferir la respuesta que vio primero), sesgo de verbosidad (premiar respuestas largas al margen de la calidad), sesgo de autopromoción (favorecer texto que se parece a su propia salida). Un juez es un revisor que acierta casi siempre — y que, cuando se equivoca, lo hace con sistema y siempre hacia el mismo lado.

Así que revisas al revisor. Calibra el juez contra una muestra de etiquetas humanas — con veinte o treinta casos basta para medir concordancia — y trata cualquier caída de esa concordancia como una build roja. Fija la versión del modelo del juez igual que fijas cualquier dependencia, y recalibra cuando la actualices, porque un cambio de juez altera tus métricas sin que cambie nada en el sistema medido. He visto a un equipo celebrar una mejora de cinco puntos de calidad cuya única causa era un juez que se había vuelto más indulgente.

Cuatro maneras en que un eval te miente

Una ejecución en verde es un indicio, no una prueba. La objeción más seria a todo lo anterior es que las suites de evals acaban siendo teatro — un conjunto fijo de casos que aprueba siempre mientras el producto se degrada. Ese modo de fallo existe, y opera por cuatro mecanismos:

1. Sobreajuste al golden set. Afina tu prompt contra los mismos cien casos durante seis meses y habrás entrenado sobre tu test set — la ley de Goodhart de manual. Reserva una porción hold-out que los autores del prompt no vean nunca.
2. Deriva del juez. Lo que cambió fue el corrector, no el sistema. Versión fijada y calibración, como arriba.
3. Fugas. Casos dorados que acaban pegados en el prompt como ejemplos few-shot, y el eval pasa a medir memorización. Controla de dónde sale cada caso y dónde acaba usándose.
4. Obsolescencia. Tu tráfico cambió y el golden set no. El eval sigue certificando el rendimiento sobre el problema del trimestre pasado.

La contramedida para los cuatro es la misma: mantener vivo el dataset. Aliméntalo cada mes con trazas de producción, retira los casos que ya no representan el tráfico, y convierte los fallos que encuentres en producción en los casos de regresión del mes siguiente — la misma disciplina de añadir un test por cada bug.

Móntalo como un CI, no como un proyecto de investigación

La mecánica, en concreto:

• Bloquea los cambios. Ediciones de prompt, cambios de esquema de herramientas y configuración de retrieval entran por pull request y disparan la suite. Una caída material de puntuación bloquea el merge, igual que un test unitario en rojo.
• Ejecuta cada noche contra el alias vivo. Tu modelo fijado es lo que testeaste; el alias del proveedor es lo que sirves. Una ejecución nocturna contra ambos es la manera de enterarte de que algo ha cambiado por debajo antes de que se enteren tus usuarios.
• Muestrea producción. Pasa un 1–5% del tráfico real por el juez, en asíncrono, y alerta sobre la deriva semana contra semana. Es la comprobación que el golden set no puede hacer: caza la regresión en el tráfico que no predijiste.
• Presupuéstalo con honestidad. Puntuar 200 casos con un modelo frontera cuesta unos pocos dólares por ejecución. La retrospectiva de un solo incidente de producción cuesta más que un año de evals nocturnos.

Nada de esto exige herramientas exóticas — harnesses open source como promptfoo u OpenAI Evals cubren la mecánica — porque lo difícil nunca fue el runner. Es el dataset etiquetado y el hábito.

Qué haría este trimestre si fuera tu CTO

1. Activa hoy la captura de trazas. Entradas, contexto, llamadas a herramientas, salidas, versión del modelo. Todo lo demás depende de que estos datos existan.
2. Etiqueta 100 casos dorados a partir de trazas reales. Producto e ingeniería en la misma sala. Presupuesta dos días; las discusiones que provoca son el entregable.
3. Mete la suite en el CI. Los cambios de prompt quedan bloqueados por ella. Si tus prompts no están en control de versiones, ese es el paso cero.
4. Calibra el juez cada mes. Veinte casos etiquetados por humanos, mide la concordancia, fija la versión del juez.
5. Muestrea un 2% de producción a través del juez con una alarma de deriva. Cuando salte, las trazas que fallen se convierten en nuevos casos dorados.

Un sistema que nunca se comporta igual dos veces puede, aun así, rendir cuentas ante un estándar. Solo hay que escribir ese estándar y comprobarlo en cada cambio — que es, en el fondo, lo único que ha sido siempre una suite de regresión. Los equipos que tienen agentes fiables en producción no son los que tienen mejores modelos. Son los que reconstruyeron su disciplina de testing para un componente probabilístico en lugar de abandonarla.

---

Si estás montando esta disciplina y necesitas ingenieros que la hayan operado en producción — golden sets, calibración de jueces, CI bloqueado por evals — eso es lo que hacen nuestros ingenieros LLM.