Las evals que se ejecutan manualmente detectan regresiones después de shippear. El desarrollo eval-driven necesita la eval en CI — para que cada cambio esté gateado, no solo los que te acuerdas de evaluar.
Una eval que ejecutas a mano es una eval que no se ejecuta en cada cambio. La disciplina que hace que las evals realmente gateen regresiones es ponerlas en CI, para que el cambio que rompe el agente no shippee — igual que un test roto no shippea.
Primero lo primero: la eval en CI
Empieza con el fin en mente: cada cambio al agente ejecuta el suite de evals, y una regresión falla el build. La eval en CI es el mecanismo que hace real el desarrollo eval-driven — sin ella, la eval es un ritual; con ella, la eval es un gate.
- El suite de evals se ejecuta en cada cambio.
- Una regresión falla el build.
- El cambio no shippea hasta que la eval pasa.
Medición del proceso: lo que atrapa CI
La eval en CI atrapa lo que las evals manuales se pierden:
- Un cambio de prompt que rompió la cola larga.
- Un upgrade de modelo que mejoró el promedio y rompió los bordes.
- Un cambio de retrieval que regresionó la precisión.
- Un cambio de dependencia que alteró el comportamiento del agente.
Cada una es una regresión que habría shippeado sin el gate de CI.
Qué construir
- Un suite de evals que corra headless, rápido y reproducible.
- Un job de CI que lo ejecute en cada cambio.
- Un fallo que bloquee el build.
- Una retención de resultados para que las regresiones sean visibles en el tiempo.
Qué vigilar
- Latencia de eval — un suite lento se vuelve un cuello de botella de CI; manténlo rápido.
- Flakiness — una eval flaky es peor que ninguna; arregla los flakes antes de confiar en el gate.
- El set de evals desfasándose del uso real — refresca el set a medida que el producto cambia.
Qué rechazar
- Un suite de evals demasiado lento para correr en cada cambio.
- Una eval flaky que falla al azar y entrena a la gente a ignorar los fallos.
- Un set de evals que no cubre los modos de fallo que importan.
- Un gate de CI que la gente bypassea porque hace ruido.
Conclusión
Las evals de agentes en CI son lo que hace real el desarrollo eval-driven. Ejecuta el suite en cada cambio, falla el build ante regresiones, y mantén la eval rápida, estable y actualizada. El gate que atrapa regresiones antes que los usuarios es el que shippea — y el que no, es el que shippea regresiones.
Sobre FACTA
FACTA ayuda a startups y equipos en etapa de crecimiento a convertir la IA en sistemas de producción que siguen funcionando — no demos que impresionan una vez.
Diseñamos la arquitectura alrededor de las partes que realmente fallan bajo uso real: herramientas que tú controlas, credenciales que tú gestionas, failover, controles de costo, observabilidad. La infraestructura aburrida que mantiene vivo un sistema después del lanzamiento.
Liderado por Matías Baglieri y Carolina Fogliato, nos enfocamos en una sola cosa:
Liderazgo de IA que construye. No solo asesora.
Las evals que se ejecutan manualmente detectan regresiones demasiado tarde.
Así es como poner las evals de agentes en CI para que cada cambio esté gateado. Ve RAG eval-driven para la base del lado de evals.
Explora la automatización de IA