Phase 14 - Lesson 30

Desarrollo de Agentes Orientado a la Evaluación

Orientación de Anthropic: "comience con prompts simples, optimícelos con una evaluación exhaustiva y añada sistemas agénticos de múltiples pasos solo cuando sea necesario". La evaluación no es el último paso. Es el bucle externo que impulsa cada una de las demás elecciones en la Fase 14.

Tipo: Aprender + Construir Lenguajes: Python (stdlib) Prerrequisitos: Toda la Fase 14. Tiempo: ~60 minutos

Objetivos de Aprendizaje

• Nombrar las tres capas de evaluación — benchmarks estáticos, evaluación offline personalizada, producción online — y para que sirve cada una.
• Explicar el bucle cerrado evaluador-optimizador.
• Describir la mejor práctica de 2026: las evaluaciones viven junto al código, se ejecutan en CI y sirven como control (gate) para las PR.
• Conectar cada lección de la Fase 14 con el caso de evaluación que genera.

El Problema

Los agentes superan las demostraciones. Fallan en producción de maneras que las demostraciones no pueden predecir. Los benchmarks responden a "¿es este modelo ampliamente capaz?" y no a "¿está este agente entregando las correcciones (patches) correctas para mi producto?". La respuesta: evaluación en tres capas, ejecutándose continuamente, con cada guardrail y regla aprendida mapeados a un caso de evaluación.

El Concepto

Tres capas de evaluación

1. Benchmarks estáticos — SWE-bench Verified para código (Lección 19), WebArena/OSWorld para navegación / escritorio (Lección 20), GAIA para generalista (Lección 19), BFCL V4 para uso de herramientas (Lección 06). Úselos para la comparación entre modelos y el control de regresiones (regression gating). La contaminación es real: SWE-bench+ encontró un 32,67% de filtración de soluciones. Reporte siempre puntuaciones Verified / auditadas con +.

2. Evaluaciones offline personalizadas — la forma de su producto:

   • LLM-as-judge (Langfuse, Phoenix, Opik — Lección 24).
   • Basadas en ejecución (ejecutar la corrección, verificar las pruebas).
   • Basadas en trayectoria (comparar secuencias de acciones con el gabarito [gold]; OSWorld-Human muestra que los mejores agentes realizan de 1,4 a 2,7 veces más pasos que el gabarito).

3. Evaluaciones online — producción:

   • Reproducción de sesiones (Langfuse).
   • Alertas activadas por guardrails (Lección 16, 21).
   • Seguimiento de costo / latencia por paso (spans de OTel en la Lección 23).

Evaluador-optimizador (Anthropic)

El bucle cerrado:

1. El proponente (proposer) genera la salida.
2. El evaluador (evaluator) juzga.
3. Se refina hasta que el evaluador apruebe.

Esto es Self-Refine (Lección 05) generalizado. Cualquier flujo de agente que le interese puede envolverse en un evaluador-optimizador para mayor confiabilidad.

Mejor práctica de 2026

• Las evaluaciones viven junto al código.
• Se ejecutan en CI en cada PR.
• Controlan la fusión (gate) según las puntuaciones de evaluación (por ejemplo, "ninguna regresión > 5% frente a main").
• Cada guardrail se mapea a un caso de evaluación.
• Cada regla aprendida (Reflexion, regla de aprendizaje de flujo de trabajo profesional) se mapea a un caso de fallo.

Conectando la Fase 14

Cada lección de la Fase 14 genera casos de evaluación:

Si su suite de evaluación tiene casos para cada uno, ha cubierto la Fase 14.

Dónde falla el desarrollo orientado a la evaluación

• Sin línea de base (baseline). Las evaluaciones sin una última referencia buena conocida no se pueden interpretar. Guarde las líneas de base.
• LLM-juez sin base empírica (grounding). Los jueces también alucinan. Patrón CRITIC (Lección 05): el juez se basa en herramientas externas.
• Sobreajuste (over-fitting) a las evaluaciones. Optimizar para la evaluación se desvía de la utilidad en producción. Rote los casos.
• Evaluaciones inestables (flaky). Los casos no deterministas causan falsas alarmas. Fije las semillas (seeds) y tome capturas de estado (snapshots).

Constrúyalo

code/main.py es un arnés de evaluación (eval harness) de la biblioteca estándar:

• Registro de casos con categorías (benchmark, personalizado, online).
• Un agente programado bajo prueba.
• Bucle evaluador-optimizador: proponer, juzgar, refinar hasta aprobar o alcanzar el límite de rondas.
• Control de CI (CI gate): tasa de aprobación agregada + regresión frente a la línea de base.

Ejecútelo:

python3 code/main.py

Salida: aprobado/fallido por caso, indicador de regresión, veredicto del control de CI.

Úselo

• Escriba los casos de evaluación en el mismo repositorio que el código de su agente.
• Ejecútelos en cada PR a través de CI.
• Falle la compilación en caso de regresión.
• Realice un seguimiento de la tasa de aprobación a lo largo del tiempo.
• Asocie cada fallo de producción a un nuevo caso.

Ship It

outputs/skill-eval-suite.md crea una suite de evaluación de tres capas para un producto de agente con controles de CI y seguimiento de regresión.

Ejercicios

1. Tome uno de sus fallos de producción. Escriba un caso de evaluación que lo reproduzca. ¿Lo aprueba su agente ahora?
2. Construya una rúbrica de LLM-juez para su dominio con tres dimensiones (factual, tono, alcance). Califique 50 sesiones.
3. Conecte la suite de evaluación a CI. Falle la compilación con un >=5% de regresión.
4. Añada una métrica de eficiencia de trayectoria: ¿cuántos pasos tomó el agente en comparación con una trayectoria de referencia (gold)?
5. Mapee cada lección de la Fase 14 a un caso de evaluación en su suite. ¿Falta alguno? Ese es un vacío que debe cerrar.

Términos Clave

Lectura Adicional

• Anthropic, Building Effective Agents — "comience simple, optimice con evaluaciones"
• OpenAI, SWE-bench Verified — el benchmark seleccionado
• Berkeley Function Calling Leaderboard — benchmark de uso de herramientas
• Langfuse docs — evaluaciones + reproducción de sesiones en la práctica