Un error, al menos, avisa. Sentry manda una alerta, la gráfica se pone roja y te sientas a arreglarlo.
Con un modelo de lenguaje, el fallo más común no hace ruido.
Lo aprendí por mi cuenta, con un proyecto personal que hago para aprender: un entrenador de ciclismo donde un LLM escribe el plan de entrenamiento de cada semana. Después, unas reglas en código lo ajustan: que no se pase del tiempo disponible, que no haya demasiadas sesiones duras, cosas así.
#.La semana que salió más fácil
En agosto apareció un plan real con una semana pico rara.
La semana pico se supone que es la más exigente del bloque. Esta traía 217 minutos. La semana de construcción anterior tenía 327, y también más carga.
Menos tiempo y menos carga que la semana anterior. El bloque cerraba con una semana de descanso que nadie planificó.
Y ninguna regla protestó.
Se le habían pedido al modelo 4 horas y 12 minutos, y devolvió 3 horas y 37, un 13.9% menos. La tolerancia era de 15%. Quedó dentro del margen por menos de tres minutos.
Ningún error, ninguna alerta. Alguien lo encontró leyendo el plan.
Cuando revisé el porqué, apareció algo más incómodo. Todas las reglas eran techos: limitar el volumen, limitar el trabajo duro. Ninguna le ponía un piso a la intensidad.
El sistema estaba bien protegido contra un tipo de error y ciego ante el contrario.
#.Una prueba para respuestas que cambian
Anthropic lo dice simple: un eval es una prueba para un sistema de IA. Le das una entrada, calificas la salida y mides si salió bien.
Suena a una prueba unitaria. La diferencia es que un modelo te puede dar una respuesta distinta para la misma entrada, y muchas preguntas tienen más de una buena respuesta. Un expect(result).toEqual(...) no te dice si la respuesta es buena.
Mis reglas eran guardrails: revisan o corrigen cada respuesta en el momento. Cada una cuidaba su parte. Nada miraba el plan desde afuera para preguntarse si tenía sentido como plan.
Para eso sirve un eval: el sistema completo, sobre muchos casos y a lo largo del tiempo. De estos cien planes, ¿cuántas semanas pico salieron más suaves que la anterior? ¿Y con el prompt nuevo?
¿Un eval habría atrapado esa semana antes? Siendo honesto, probablemente no. No me había imaginado ese fallo, así que no habría escrito una prueba para él.
Lo que sí puede hacer un eval es que no vuelva a pasar.
#.Primero leer, después medir
Hamel Husain y Shreya Shankar insisten en algo en su FAQ sobre evals que es fácil saltarse: antes de escribir métricas, lee respuestas reales a mano. Anota qué está mal, agrupa los fallos y después mide.
Así fue exactamente como apareció. No en un tablero. Leyendo.
Y aplica a cualquier producto. Un bot de soporte que a todo responde, muy amable, “contacta a nuestro equipo” nunca rompe una regla. Solo lo ves cuando lees las conversaciones.
Una vez que viste un fallo, revisarlo es barato. El mío fueron unas pocas líneas de código: la semana pico no puede tener menos carga por minuto que la anterior. Sin otra IA.
Para lo que el código no ve, como si una respuesta fue clara, puedes usar otro modelo como juez. Pero antes compara sus notas con las tuyas. Un juez que no has revisado es solo una opinión más.
#.Empieza por tus fallos reales
No necesitas miles de casos. Anthropic dice que de 20 a 50 tareas simples sacadas de fallos reales son un gran comienzo. Si ya estás en producción, te manda a tu gestor de bugs y a la cola de soporte.
Cada fallo que lees se vuelve un caso. Cada caso protege el siguiente cambio.
#.Por qué “casi siempre” no alcanza
Un plan son muchas respuestas seguidas, y la tarea de un agente de IA también.
Si cada paso tuviera, de forma independiente, un 95% de probabilidad de salir bien, doce seguidos saldrían limpios solo un 54% de las veces.
Es una ilustración, no una medición. Pero la idea se sostiene: quien usa tu producto no vive tu tasa promedio de éxito. Vive cada respuesta.
#.Un cambio que no toca tu código
El proveedor actualiza el modelo. Alguien ajusta el prompt. Se activa un respaldo que manda el tráfico a otro modelo cuando el principal se cae.
No cambia ni una línea de tu código, y tus pruebas siguen en verde. Pero tu producto puede amanecer comportándose distinto.
Los evals no eliminan esa incertidumbre. La convierten en algo que puedes revisar un martes, antes de que lo encuentre otra persona.