Cómo medir el rendimiento de agentes de IA con evals efectivos

Evals 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?