Cómo medir el rendimiento de agentes de IA con evals efectivos
DominicodeEvals para código generado por IA — cómo medir si tu agente está mejorando o empeorando con tu spec
Tiempo estimado de lectura: 6 min
- Combina validación determinista y semántica: ambas dimensiones son necesarias para señales accionables.
- Golden Dataset + rúbricas: versiona casos reales con criterios explícitos para comparar versiones del spec.
- Two-speed pipeline: validación determinista en cada PR; juez LLM y revisiones completas en merges/release.
- Métricas operativas clave: pass rate, semantic score, flakiness, coste por eval y regression rate.
Si cambias una línea en tu CLAUDE.md o ajustas las instrucciones del sistema y luego aceptas código “porque se ve bien”, estás apostando a que la intuición compense la probabilidad. No lo hace. Necesitas implementar evals para código generado por IA — cómo medir si tu agente está mejorando o empeorando con tu spec para convertir esa intuición en métricas reproducibles.
Este artículo explica qué medir, cómo construir un pipeline fiable, qué herramientas usar y las decisiones operativas que separan a los equipos que gestionan agentes con criterio de los que lo hacen por esperanza.
Resumen rápido (lectores con prisa)
Qué es: Un enfoque combinado de evals deterministas y semánticos para código generado por IA.
Cuándo usarlo: Siempre que tu agente genere código que afecte producción o el diseño arquitectónico.
Por qué importa: Transforma intuición en métricas reproducibles y reduce regresiones al cambiar el spec.
Cómo funciona: Golden Dataset versionado + pipeline: determinista rápido en PRs, juez LLM y/o humanos en merges y releases.
¿Qué miden los evals para código generado por IA — cómo saber si tu agente mejora o empeora?
Un eval profesional mide dos dimensiones complementarias:
- 1. Validación determinista — ¿el output cumple reglas objetivas?
- 2. Validación semántica — ¿el output cumple criterios arquitectónicos, de seguridad y estilo que sólo pueden evaluarse con criterio?
Si sólo ejecutas una, te quedas cojo. Combínalas y obtendrás señales accionables.
Validación determinista
Objetivos claros y automatizables:
- Síntaxis / AST: el código parsea sin errores.
- Linter/style: ESLint/Prettier pasan según la configuración del repo.
- Tests unitarios de integración en sandbox: el código generado se inyecta en un contenedor efímero y ejecuta Jest/Vitest/PyTest.
- Reglas binarias del spec: por ejemplo, “no usar fetch en cliente” → comprobación estática.
Resultado: métricas binarias y tasas de paso (pass rate) que puedes agregar y comparar entre versiones del spec.
Validación semántica — LLM-as-a-Judge y estrategias híbridas
Algunos criterios no son booleanos: diseño, seguridad implícita, uso idiomático. Aquí entra un juez LLM:
- El juez recibe: el spec original, el código generado, y una rúbrica estructurada.
- Produce: una puntuación y un reasoning structured (json) que explica fallos de arquitectura, riesgos de seguridad, o desviaciones de estilo.
Precaución: existe sesgo de auto-preferencia. Mitigaciones prácticas:
- Usar un modelo juez distinto y preferible más capaz (ej. GPT‑4o o Claude avanzado).
- Ensembles: combinar juicios de 2–3 modelos y una muestra humana para calibrar.
- Registrar justificaciones (no sólo la puntuación).
Cómo construir un pipeline de Evals paso a paso
1. Golden Dataset (20–50 casos reales)
- Casos representativos del código y dominios del producto.
- Cada caso: input, contexto (memory files relevantes), criterios de éxito explícitos.
- Versionado en Git junto al spec.
2. Frameworks y herramientas
- Promptfoo — orquestación de evals en CLI.
- LangSmith (observabilidad y tracing).
- Braintrust (plataformas de evals y datasets).
- Integrar linters, AST analyzers y runners de tests (Jest/Vitest/PyTest).
3. Sandbox seguro para deterministas
- Contenedores efímeros sin red ni credenciales, preferiblemente con políticas de seccomp/gVisor o Firecracker para microVMs.
- Tiempo límite por test y quotas de CPU/RAM.
4. LLM-as-a-Judge
- Definir rúbricas concretas (JSON schema) por caso del Golden Dataset.
- Ejecutar juez sólo en merges o nightly builds si el coste es alto; o en un flujo “two-speed” (ver abajo).
5. Métricas y alertas
- Pass rate determinista por caso y agregado.
- Puntuación semántica media y desviación estándar.
- Flakiness rate (casos con resultados inconsistentes entre corridas).
- Cost per eval (tokens, wall time).
- Guardrails: bloquear PRs si la adherencia agregada cae por debajo de un umbral (ej. 85–90%).
6. Integración CI/CD
- Disparar evals cuando cambie el spec (
CLAUDE.md,AGENTS.md, memory files). - Pipeline típico: generar → determinista (rápido) → reporte → si pasa, opcional: juez LLM → aprobar o bloquear PR.
Estrategia operativa: coste vs seguridad vs velocidad
- Two-speed pipeline: Validación determinista ligera en cada PR; validación semántica completa en merges a main o releases. Reduce coste y mantiene seguridad.
- Ensembles y muestreo: Si el coste de juez LLM es prohibitivo, ejecuta juez en una muestra estadística del Golden Dataset por cada cambio mayor.
- Human-in-the-loop: para nuevas rules o casos edge, requiere revisión humana antes de aceptar un cambio en el spec.
Métricas que realmente importan
- Regression rate por cambio de spec (número de casos del Golden Dataset que empeoran).
- Mean Semantic Score delta entre versiones del spec.
- Time-to-fix promedio cuando un eval falla.
- Token cost por ejecución y coste por PR.
- Porcentaje de automatización (qué % de PRs infractions se bloquean automáticamente vs requieren intervención humana).
Conclusión operativa
Trata tu spec como código crítico: versiona, prueba y monitoriza. Implementar evals para código generado por IA transforma la gestión de agentes de una caja de sorpresas a un proceso auditable. Si quieres que el agente mejore con cambios en tu spec, mide, automatiza y obliga a retroalimentación continua. Sin datos no hay control; sin control, el agente termina rompiendo más de lo que arregla.
Si trabajas con automatización, agentes o workflows y quieres ejemplos prácticos y experimentos reproducibles, revisa Dominicode Labs. Encontrarás recursos y prototipos alineados con pipelines de evals y prácticas de integración.
FAQ
- ¿Qué miden los evals para código generado por IA?
- ¿Qué es validación determinista?
- ¿Cómo se construye un Golden Dataset?
- ¿Cuándo debo ejecutar un juez LLM?
- ¿Qué métricas operativas debo vigilar?
- ¿Cómo integrar evals en CI/CD sin elevar demasiado el coste?
Respuesta: Miden dos dimensiones complementarias: validación determinista (sintaxis, linters, tests, reglas binarias) y validación semántica (diseño, seguridad, estilo evaluados por un juez LLM o humanos).
Respuesta: Es la comprobación automática y objetiva: el código parsea, pasa linters, ejecuta tests en sandbox y cumple reglas estáticas definidas en el spec.
Respuesta: Reúne 20–50 casos reales representativos. Cada caso debe incluir input, contexto relevante y criterios de éxito explícitos; versiona el dataset en Git junto al spec.
Respuesta: Ejecuta juez LLM en merges o nightly builds si el coste es alto, o en un flujo two-speed donde aplicas juez a cambios aprobados determinísticamente o a muestras estadísticamente relevantes.
Respuesta: Pass rate determinista, mean semantic score, regression rate por cambio de spec, flakiness rate, token cost por ejecución y time-to-fix promedio.
Respuesta: Usa una validación determinista ligera en cada PR y ejecuta validación semántica completa en merges/releases. Muestrea casos para reducir coste y aplica ensembles o revisión humana en casos críticos.