Resumen Técnico: AEVAL – De la Evaluación Anecdótica a la Determinista para Flujos de Trabajo de Habilidades Agénticas

1. Planteamiento del Problema

Los sistemas agénticos modernos dependen cada vez más de las habilidades (skills): paquetes instalables que contienen especificaciones en lenguaje natural (p. ej., SKILL.md), scripts y configuraciones que enseñan a los agentes de Modelos de Lenguaje Extensos (LLM) cómo realizar tareas de dominio. A medida que los repositorios de habilidades se expanden, el paradigma de evaluación actual es anecdótico: los desarrolladores activan manualmente una habilidad, observan una ejecución de demostración y forman una impresión subjetiva de su éxito.

Este enfoque sufre tres deficiencias críticas:

1. Falta de Reproducibilidad: Dos ejecuciones consecutivas pueden ejercer diferentes rutas de código o producir diferentes salidas, lo que conduce a juicios inconsistentes por parte del desarrollador.
2. Falta de Comparabilidad: Las impresiones subjetivas no pueden compararse entre versiones o solicitudes de fusión (MR).
3. Problemas de Escalabilidad: En los mercados de múltiples habilidades, una sola regresión puede romper silenciosamente docenas de flujos de trabajo descendentes.

Además, un modo de fallo técnico específico afecta a la evaluación agéntica ingenua: el Sesgo de Autocorrección (Self-Correction Bias). Cuando el mismo agente tanto ejecuta como califica una habilidad, a menudo parchea silenciosamente la habilidad o su configuración durante la ejecución para recuperarse de los errores. El agente entonces califica su propia salida parcheada como un éxito. Esto resulta en una señal sistemáticamente optimista que mide la capacidad de depuración del agente en lugar de la calidad intrínseca del artefacto de la habilidad.

2. Metodología: El Marco AEVAL

AEVAL (Evaluación Agéntica) es un marco integrado en CI diseñado para reemplazar la prueba anecdótica con un pipeline de pruebas determinista y activado por cambios, que ejecuta un flujo de trabajo de cinco fases:

2.1. Contrato de Evaluación Definido por la Habilidad

Cada habilidad incluye un archivo eval.config ubicado junto a su especificación. Este contrato declara:

• Prompts en lenguaje natural para casos de prueba.
• Resultados esperados.
• Credenciales requeridas.
• Un mecanismo de fallback de tres niveles asegura la capacidad de prueba incluso sin una configuración explícita.

2.2. El Pipeline de Cinco Fases

1. Examinar (Examine): El sistema detecta las habilidades modificadas mediante git diff.
2. Instalar (Install): La habilidad modificada se instala en una sesión limpia.
3. Usar (Use/Ejecución): Un ejecutor automatizado corre la habilidad contra el contrato.
   • Restricción: Una regla estricta prohíbe las salidas simuladas. Si un comando falla o un servicio es inalcanzable, el fallo se registra como un resultado de prueba real. Los agentes no pueden fabricar logs o sintetizar resultados para pasar las aserciones.
4. Evaluar (Evaluate/Calificación): Se impone una separación estructural entre el ejecutor y el calificador.
   • Ejecutor: Ejecuta la habilidad y genera una transcripción ($\tau$) y salidas ($O$).
   • Calificador: Un subagente separado restringido a un conjunto de información de solo lectura: el prompt de la prueba ($x$), la transcripción de ejecución ($\tau$), las salidas ($O$) y las aserciones previas a la ejecución ($A$).
   • Regla de Calificación de Primer Intento: El calificador evalúa las aserciones contra la trayectoria del primer intento. Si el ejecutor aplicó cualquier edición de autocorrección ($\Delta(\tau) \neq \emptyset$) que fue causalmente necesaria para que una aserción tuviera éxito, esa aserción se marca como FALLO, independientemente del estado final.
5. Sugerir (Suggest): El sistema genera sugerencias de corrección basadas en los resultados de la calificación.

2.3. Sugerencias de Corrección Escalonadas y Fundamentadas

Para evitar el cambio especulativo de "deseable pero no necesario", las sugerencias están estrictamente fundamentadas en evidencia:

• Fundamentación: Cada sugerencia debe citar una aserción fallida específica o una entrada de autocorrección rastreada.
• Escalamiento (Tiering):
  • LV1 (Causal): Correcciones causalmente implicadas en el fallo del primer intento. Estas bloquean la solicitud de fusión (MR).
  • LV2 (Asesoría): Mejoras de calidad o robustez identificadas por el calificador que no causaron un fallo crítico.
• Entrega: Las sugerencias se publican como comentarios de línea de MR en GitLab con diffs de "Aplicar sugerencia", permitiendo a los desarrolladores aplicar parches empíricamente validados con un solo clic.

3. Contribuciones Clave

El artículo describe cuatro contribuciones primarias:

1. Protocolo de Prueba de Habilidades Determinista: Un sistema de evaluación activado por cambios con contratos por habilidad y esquemas de artefactos por ejecución, reemplazando la evaluación manual con un pipeline de CI reproducible.
2. Formalización del Sesgo de Autocorrección: La identificación y formalización del sesgo de autocorrección como un modo de fallo distinto que surge del acoplamiento estructural de la ejecución y la calificación, más allá de las elecciones específicas del modelo.
3. Separación Estructural y Calificación de Primer Intento: Un protocolo que aísla al calificador del bucle de ejecución y fuerza una regla de calificación de primer intento. Esto asegura que la señal de calidad refleje la habilidad tal como se distribuye, no la habilidad como fue parcheada por el agente.
4. Sugerencias Escalonadas y Fundamentadas: Un mecanismo para entregar sugerencias de corrección como commits de un solo clic en el MR, estrictamente ligados a evidencia causal (LV1) o retroalimentación de asesoría (LV2).

4. Resultados Empíricos

El marco fue validado contra un stack agéntico de producción y múltiples SDK de agentes populares (incluyendo agentes de la familia Claude y GPT).

• Eliminación del Sesgo: En un caso de estudio que involucró una habilidad de segmentación deliberadamente degradada, un evaluador ingenuo reportó una tasa de éxito del 100% después de que el agente parcheara silenciosamente los nombres de las acciones. AEVAL registró la autocorrección, marcó la aserción relevante como FALLO y reportó una tasa de éxito de primer intento estrictamente menor a CI.
• Estabilidad: Antes de la regla de "fundamentado en evidencia", las ejecuciones repetidas del mismo MR producían conjuntos de sugerencias disjuntos. Con la regla, las ejecuciones repetidas convergieron en el mismo conjunto de LV1 causalmente fundamentado.
• Prohibición de Simulación: Cuando un clúster de GPU descendente era inalcanzable, iteraciones anteriores producían logs sintéticos. Bajo AEVAL, el agente registró la falla de conectividad, permitiendo que el CI descendente distinguiera defectos de la habilidad de fallos ambientales.
• Calibración de Entornos de Ejecución (Cross-Runtime): El marco ejecutó con éxito la misma habilidad a través de diferentes backends de agentes. Aunque las tasas de éxito brutas variaron, la cuota causal (la fracción de sugerencias marcadas como bloqueo de fusión) proporcionó una métrica escalar reproducible para comparar la severidad del calificador. El Backend A (familia Claude) tuvo una cuota causal media de 0.41, mientras que el Backend B (familia GPT) tuvo 0.82, revelando diferencias sistemáticas en cómo diferentes agentes interpretan la severidad.
• Eficiencia de Costos: Con tasas de acierto en el caché de prompts de 95–97%, el costo marginal de tokens de repetir el protocolo en cada push es lo suficientemente bajo como para soportar la integración continua.

5. Significación y Reivindicaciones

El artículo afirma que AEVAL proporciona una garantía estructural de que la señal de evaluación es una función de la ejecución del primer intento y no del estado post-corrección.

• Bloque Fundamental: Los autores posicionan la prueba de habilidades determinista no como una garantía de cobertura probabilística (como la predicción conforme), sino como un componente ascendente necesario que produce etiquetas de verdad fundamental binarias y fiables. Estas etiquetas son prerrequisitos para que los métodos estadísticos descendentes (p. ej., predicción conforme, cuantificación de incertidumbre) funcionen correctamente.
• Cambio en la Práctica: El marco facilita un cambio de la "prueba manual anecdótica" a "pipelines de prueba deterministas activados por cambios", reflejando la evolución de la ingeniería de software tradicional.
• Bucle de Automatización: Al convertir las señales de éxito del 100% que se auto-cumplen en señales de fallo de primer intento auditables y proporcionar parches de un solo clic, AEVAL cierra el bucle de probar-fallar-corregir, permitiendo el enrutamiento y las decisiones de detención fiables en los flujos de trabajo agénticos descendentes.

Los autores mantienen la modestia respecto a las limitaciones, reconociendo que la prohibición de salidas simuladas se impone por instrucción (no por sandboxing) y que las autocorrecciones complejas de múltiples pasos aún pueden ser mal atribuidas por el calificador. Sin embargo, afirman que la separación estructural entre el ejecutor y el calificador es el ingrediente central de confiabilidad requerido para el monitoreo estadísticamente riguroso de los flujos de trabajo agénticos.