Evaluaciones de Agentes y Benchmarking SWE-bench

1. Visión general del concepto y problema sistémico

El mayor peligro en el desarrollo de sistemas de agentes en 2026 es la llamada «regresión de comportamiento» (Behavioral Regression):

• Cambias una frase en el prompt del sistema para que el agente formatee mejor Markdown, pero de repente deja de invocar la herramienta de lectura de archivos.
• Pasas de la versión del modelo v1.2 a v1.3, y el agente comienza a ejecutar el doble de comandos shell erróneos.
• Sin pruebas automatizadas, los proyectos de agentes se convierten en "chamanismo", donde los desarrolladores prueban la calidad del sistema con un par de consultas manuales en el chat.

Evaluaciones de Agentes es una disciplina de ingeniería que traslada los principios clásicos de TDD y CI/CD al mundo de los agentes de lenguaje no determinísticos. Permite medir cuantitativamente el éxito (Pass Rate), el costo en tokens (Cost per Task) y el tiempo de ejecución (Latency).

2. Taxonomía arquitectónica y modelo mental

┌─────────────────────────────────────────────────────────────┐
│                 TAXONOMÍA DE EVALUACIÓN DE AGENTES          │
├─────────────────────────────────────────────────────────────┤
│ 1. Evaluaciones Basadas en Estado (Estado final del entorno):│
│    • Pruebas Unitarias / de Integración Pasadas (pytest,     │
│      vitest == 0)                                           │
│    • Verificación de Diferencias en el Sistema de Archivos   │
│      (si se han creado los necesarios)                      │
├─────────────────────────────────────────────────────────────┤
│ 2. Evaluaciones Basadas en Trayectoria (Evaluación de la     │
│    trayectoria de pensamientos):                             │
│    • Precisión en la Llamada a Herramientas (si se ha       │
│      invocado la herramienta correcta)                       │
│    • Eficiencia de Pasos (en cuántos pasos se alcanzó el    │
│      objetivo)                                              │
│    • Penalización por Acción Redundante (penalizaciones por   │
│      repeticiones)                                         │
├─────────────────────────────────────────────────────────────┤
│ 3. Evaluaciones LLM-as-a-Judge (Verificación Semántica por   │
│    un Juez):                                               │
│    • Tono de Respuesta y Adherencia a Guías de Estilo      │
│    • Cumplimiento de Completitud y Seguridad               │
├─────────────────────────────────────────────────────────────┤
│ 4. Evaluaciones de Recursos y Económicas:                   │
│    • Tasa de Consumo de Tokens por Problema Resuelto        │
│    • Tiempo de Ejecución en Reloj de Pared                 │
└─────────────────────────────────────────────────────────────┘

3. Pipeline técnico y mecánica interna

Un marco típico de evaluación de agentes (por ejemplo, Inspect AI, Braintrust o un Docker Harness propio) opera bajo el siguiente ciclo:

1. Reinicio del Entorno de Pruebas: Lanzamiento de un contenedor Docker aislado con el commit inicial de la base de código, donde el problema aún está presente.
2. Provisionamiento de Tareas: Se envía al agente solo la descripción del error (issue.md).
3. Registro de Trayectoria del Agente: El agente ejecuta comandos, lee archivos y realiza modificaciones. Todos los pasos se registran en formato OpenTelemetry / JSONL (trayectoria de acciones).
4. Evaluación del Harness:
   • El orquestador recoge el git diff generado.
   • Se ejecutan pruebas de verificación ocultas (pruebas Fail-to-Pass).
   • Se registra el estado: RESOLVED, FAILED, TIMEOUT o OUT_OF_BUDGET.
5. Agregación de Métricas: Se calcula el porcentaje total de tareas resueltas (Resolve Rate) para la versión del agente.

4. Escenarios prácticos de ingeniería en producción

01. Gate CI/CD para actualización de prompts de agentes

Antes de fusionar cambios en el archivo .cursorrules o el prompt del sistema en el repositorio, se ejecuta una acción de GitHub con 30 pruebas sintéticas. Si el agente resuelve menos del 90% de las tareas, la solicitud de extracción se bloquea automáticamente.

02. Selección de proveedor de modelos según criterio ROI

El equipo evalúa: ¿vale la pena pagar $15 por millón de tokens por un modelo de primera, o es suficiente un nuevo modelo abierto por $0.50? La ejecución de evaluaciones en 100 tareas propias muestra cifras precisas: el modelo de primera resuelve el 78% de las tareas, el modelo barato el 74%, pero cuesta 20 veces menos.

5. Errores comunes, trampas y seguridad

• Contaminación de la Muestra de Entrenamiento: Los benchmarks públicos (por ejemplo, el básico HumanEval) se incorporan a los datos de entrenamiento de nuevos modelos, lo que hace que el modelo "recuerde" la respuesta correcta, pero no sepa razonar. Utiliza solo evaluaciones cerradas propias o SWE-bench Verified con tareas que se actualizan constantemente.
• Evaluaciones Inestables: La no determinación de la temperatura del modelo puede dar un 80% de éxito en una ejecución y un 65% en otra. Es necesario realizar al menos 3-5 ejecuciones por cada tarea (métrica Pass@k).
• Confianza Ciega en LLM-as-a-Judge: El uso de otro modelo para evaluar el código a menudo sufre de sesgo a favor de respuestas largas o estéticamente agradables. Prioriza compiladores determinísticos y pruebas.