[ PLAYBOOK · 08 ] · 11 DE MAYO DE 2026 · 7 min
Evals que detectan regresiones reales.
No necesitas una eval de 500 filas. Necesitas una de 50 que de verdad corras en cada cambio. Pequeña, versionada, binaria y crecida una falla de producción a la vez.
La tesis
La mayoría de los equipos envía sin evals o las trata como scripts de una vez. Ambas opciones fallan, de formas distintas. La forma que paga en producción es pequeña (alrededor de 50 filas), versionada (vive junto al prompt en git), automatizada (corre en CI en cada cambio) y binaria (pasa o falla por fila). Más grande es difícil de mantener. Más laxa pierde regresiones hasta que un cliente las reporta. Los equipos que más bugs reales atrapan no son los que corren las evals más grandes. Son los que corren las evals más pequeñas que duele ignorar.
Por qué fallan la mayoría de las evals
Tres modos de falla aparecen en casi cada engagement que auditamos.
El primero es testing por sensaciones. Un líder técnico revisa veinte salidas tras un cambio de prompt, decide "se ve bien" y envía. Funciona hasta que cambia la versión del modelo subyacente (Anthropic publica un Sonnet nuevo, OpenAI deprecia un snapshot, tu proveedor rota el routing) y los chequeos no son reproducibles. No hay baseline. No hay diff. El equipo se entera de la regresión por un ticket de soporte.
El segundo es el dump de 5,000 filas. Alguien exporta dos meses de trazas de producción, las puntúa una vez con un juez LLM, manda un PDF al equipo y nunca más toca el set. El conjunto es demasiado grande para mantener, demasiado ruidoso para leer y demasiado desconectado del prompt para actualizar. Seis semanas después representa un sistema que ya no existe.
El tercero es LLM-como-juez sin calibración humana. Los modelos de juicio modernos tienen un sesgo documentado hacia la indulgencia: marcan las salidas en el límite como "pasa" más seguido de lo que lo haría un humano. El umbral estándar de confiabilidad entre evaluadores (alfa de Krippendorff alrededor de 0.8) rara vez se alcanza con jueces sin calibrar entre corridas del mismo prompt. Si el juez es la única señal, el baseline se mueve bajo los pies del equipo.
La forma de una eval que se gana su lugar
La eval que sobrevive en producción está moldeada por cinco restricciones. Cada una rechaza una alternativa tentadora.
50 filas, no 500. Cincuenta es lo bastante grande para abarcar los modos de falla que ves en producción y lo bastante chico para que un ingeniero las lea todas en una tarde. A 500 nadie las lee; el set se degrada a territorio confiar-en-el-número y deja de atrapar fallas nuevas. Apuntamos a 5 o 10 filas por modo de falla, con 5 a 7 modos cubiertos.
Trazas reales de producción, no prompts sintéticos. Cada fila viene de una interacción real que ya pasó. Los casos sintéticos pierden la cola larga. La forma en que tus usuarios escriben de verdad, las entradas malformadas, los espacios al final, el unicode, las frases a medio terminar: ahí se esconden las regresiones. Una eval llena de inglés bien formateado es una eval que miente.
Rúbrica binaria, no puntaje 1 a 10. Pasa o falla por fila es más confiable que el puntaje fino. Las escalas puntuales derivan entre corridas y entre jueces. El hallazgo empírico es consistente: la puntuación binaria reduce la varianza del juez y produce comparaciones estables a través del tiempo. Si no puedes decidir pasa o falla, la rúbrica no es lo bastante específica.
Versionada junto al prompt. La eval vive en el mismo repo que el prompt, en el mismo commit, bajo la misma revisión de código. Cuando el prompt se mueve, la eval se mueve con él. Cualquier otro arreglo lleva a desfase entre lo que el prompt hace y lo que la eval mide. El costo es real: el repo carga con fixtures de eval y posibles trazas de producción que toca redactar. Presupuesta el tiempo de redacción.
Corre en CI en cada cambio. No semanal. No cuando alguien se acuerda. En cada pull request que toca el prompt, el cliente del modelo o las herramientas que el agente llama. La eval es una compuerta de release, no una revisión trimestral de salud.
Decisión de tooling
El panorama de tooling de evals en 2026 convergió en un conjunto chico de opciones serias. Elige por lo que de verdad necesitas medir.
Hecho a mano (pytest más un runner chico). Adecuado para equipos con menos de cinco evals, sin necesidad de dashboards de drift y sin ciclo de revisión por stakeholders. Un runner de 100 líneas que carga el dataset, llama al modelo, aplica la rúbrica e imprime un diff es suficiente. La mayoría de los equipos pasa de largo esta etapa y paga por SaaS que aún no necesita.
Promptfoo. Configurado por YAML, corre en CI, gratuito y open source, los resultados quedan locales. Fuerte en escenarios de seguridad y red-teaming. El segundo paso correcto cuando el runner hecho a mano se le queda chico al equipo.
Braintrust. Construido alrededor de la aplicación a nivel de release: gestión de datasets, scoring, tracking de regresiones, integración con CI. La elección correcta cuando la evaluación se vuelve preocupación cross-team del release, no la herramienta de un solo ingeniero.
LangSmith. Es agnóstica al framework, pero la integración es más estrecha si tu stack se centra en LangChain o LangGraph. El auto-tracing y la gestión de prompts funcionan de fábrica ahí. Fuera de ese ecosistema funciona vía SDK con más configuración.
Langfuse. Open source, autohospedable en menos de treinta minutos, compatible con OpenTelemetry. La elección correcta cuando la soberanía de datos o el self-hosting es la restricción que manda en la decisión.
El patrón que vemos en equipos maduros no es "elige uno." Son dos herramientas: un runner liviano que filtra el CI, junto con una plataforma para anotación humana, crecimiento del dataset y dashboards para stakeholders. Los ingenieros bloquean releases con el runner; los PMs y revisores hacen crecer el set en la plataforma. Esa división del trabajo es lo que mantiene la evaluación sostenible mientras el equipo escala.
Anti-patrones a evitar
Algunos patrones se ven como buena higiene de evaluación y no lo son.
LLM-como-juez en solitario. Calibra contra tres anotadores humanos antes de confiar en cualquier juez. Si el acuerdo juez-humano queda por debajo de un alfa de Krippendorff de 0.7, el juez no mide lo que crees.
Tasa de aprobación del 100%. Un puntaje perfecto no significa que el sistema sea bueno. Significa que la eval es muy fácil. Agrega el siguiente modo de falla que viste en producción. La tasa debería quedar entre 80% y 95%, con movimiento tras cada cambio significativo de prompt.
Puntuación puntual de 1 a 10. Se ve más matizada. Deriva más entre corridas. Usa binaria a menos que tengas una razón cross-team específica para reportar un número.
Set de eval que nunca cambia. Cada regresión que envías es una fila que deberías agregar. El set se mantiene afilado creciendo con el sistema, no quedándose quieto.
Eval desacoplada del cambio de prompt. Si el prompt se mueve y la eval no, las dos se pudren. Mismo repo, misma revisión, mismo release.
Rollout en 5 días
Si arrancas desde cero, esta es la secuencia que corremos con clientes nuevos.
Día 1. Saca 100 trazas de producción de la última semana. Si no tienes logging, ese es tu problema real del día 1; resuélvelo antes de que el resto importe. Clasifica las 100 trazas en "correcta," "incorrecta" e "incierta." Anota el conteo.
Día 2. Por cada traza "incorrecta," etiqueta el modo de falla en una oración. Agrupa las etiquetas en 5 a 7 categorías. Categorías comunes: hecho alucinado, restricción ignorada, formato equivocado, edge case perdido, rechazo de pedido legítimo, contexto no relacionado filtrado.
Día 3. Toma 5 a 10 trazas por categoría para el set de eval. Deberías quedar entre 30 y 60 filas. Escribe una rúbrica binaria por categoría, en español llano, lo bastante específica para que dos ingenieros leyendo la misma salida estén de acuerdo en pasa o falla.
Día 4. Conecta el set al CI. Elige una de las herramientas de arriba. La primera integración debe fallar en regresión y producir un diff contra la corrida anterior. Nada elegante.
Día 5. Corre el baseline. Documenta la tasa de aprobación por categoría. Ese es tu piso. Cada cambio de prompt de aquí en adelante o sostiene el piso o explica por qué se movió.
Qué medir después de la primera semana
Una vez que la eval corre, cuatro métricas te dicen si se está ganando su lugar.
Tasa de aprobación por categoría en el tiempo. Mira qué categorías derivan primero cuando cambian los prompts o se suben versiones de modelo. La deriva en una categoría es señal; la deriva en todas es ruido.
Drift entre versiones de modelo. Cuando Claude Sonnet 4.6 pasa a 4.8, cuando cambia el routing de GPT, la eval debería decirte qué se movió. Sin eso, vuelas a ciegas cada vez que un proveedor publica.
Costo por corrida de eval. Mantiene el set sostenible. Si una corrida completa cuesta más que un café, la correrás menos seguido y atrapará menos regresiones. Es la restricción que mantiene honesto el conteo de filas.
Tiempo desde regresión en producción hasta fila agregada. Cerrar este loop es el punto entero. Mientras más rápido las regresiones se vuelven filas, más rápido la próxima regresión del mismo tipo se atrapa antes de que un usuario la vea.
Las evals no son un workstream aparte. Son la parte de un sistema LLM que sabe si el sistema sigue funcionando. Construye la más pequeña que duele ignorar. Córrela en cada cambio. Hazla crecer desde fallas reales. Ese es el trabajo entero.