What Benchmarks Don't Measure: The Case for Evaluating Abstention Competence in Autonomous Agents

Resumen Técnico: Lo que los benchmarks no miden: El caso de la evaluación de la competencia de abstención en agentes autónomos

Planteamiento del problema
Los paradigmas de evaluación actuales son sistemáticamente ciegos ante un modo de fallo crítico: proceder cuando un agente debería haberse detenido. Los benchmarks dominantes miden el éxito de la tarea (tasas de finalización, recuento de pasos, precisión de respuestas), pero carecen de escenarios donde el comportamiento correcto basado en la verdad de campo (ground-truth) sea la abstención. En consecuencia, los agentes entrenados bajo objetivos de retroalimentación humana desarrollan un "sesgo de cumplimiento" estructural: una tendencia a proceder incluso cuando carecen de los insumos, la evidencia o la autorización necesarios. Este sesgo se consolida porque los regímenes de puntuación de los benchmarks tratan el proceder como la acción correcta por defecto, penalizando a menudo a los agentes por detenerse (por ejemplo, mediante presupuestos de pasos fijos) o al no distinguir una pausa justificada de un fallo silencioso. El artículo argumenta que esta brecha de evaluación impide el desarrollo de agentes capaces de una "abstención informada", lo que conduce a cambios de estado irreversibles y peligrosos en entornos empresariales.

Metodología
Los autores proponen un marco para evaluar y hacer cumplir la "abstención informada", definida como una pausa estructurada activada por condiciones incumplidas específicas en lugar de una confianza abstracta.

1. Taxonomía de escenarios que justifican la abstención: El artículo introduce una taxonomía de tres brechas para categorizar cuándo un agente debe detenerse:

   • Brecha de Especificación: La información requerida está ausente (definida por el esquema de la herramienta, no por la confianza del modelo). La respuesta apropiada es la aclaración dirigida.
   • Brecha de Verificación: El agente no puede confirmar un estado del mundo necesario antes de actuar. La respuesta apropiada es un paso de verificación acotado.
   • Brecha de Autoridad: La acción requiere autorización explícita para un compromiso vinculante o un cambio de alto impacto. La respuesta apropiada es una pausa de compromiso solicitando aprobación.

2. Protocolos de evaluación: Para medir la competencia de abstención, los autores proponen tres métricas compuestas:

   • Tasa de Seguridad (SR): La fracción de escenarios peligrosos donde el agente produce una respuesta de bloqueo.
   • Tasa de Usabilidad (UR): La fracción de escenarios seguros en los que el agente completa la tarea sin fricciones innecesarias.
     • Tasa de Rechazo Informado (IRR): La fracción de respuestas de bloqueo que nombran explícitamente el precondición incumplida, distinguiendo la seguridad calibrada de la negativa vaga por exceso de precaución.

3. Configuración experimental:

   • Dataset: 144 escenarios de agentes empresariales derivados de 24 semillas de autoría humana, aumentados para incluir 120 escenarios peligrosos (categorizados por las tres brechas) y 24 controles seguros emparejados.
   • Modelos: Siete familias de modelos (GPT-4o, GPT-5.4-mini, Llama 3.1 8B, Claude Sonnet 4.6, Claude Opus 4.6, Gemini 2.5 Pro, Gemini 2.5 Flash) utilizando una arquitectura ReAct.
   • Condiciones: Se probaron tres condiciones de evaluación:
     • Baseline: Sin política de abstención.
     • Solo Prompt: Instrucciones de seguridad mediante el system prompt.
     • Checkpoint: Ejecución en tiempo de ejecución mediante un hook de pre-ejecución (InformedAbstentionToolWrapper) que realiza verificaciones de esquema, sondeos de estado y verificación de autorización utilizando un modelo de guardia separado.

Resultados clave
Los resultados preliminares a través de 144 escenarios y cinco familias de modelos revelan hallazgos significativos respecto al compromiso entre seguridad y usabilidad:

• Sesgo de Cumplimiento Universal: Todos los modelos exhibieron un sesgo de cumplimiento en el baseline, pero los modos de fallo variaron. Algunos modelos (p. ej., Llama 3.1 8B) optaron por defecto por "proceder" (alta Usabilidad, baja Seguridad), mientras que otros (p. ej., Claude Opus 4.6) optaron por defecto por "rechazar" (alta Seguridad, usabilidad cercana a cero).
• El abismo del "Solo Prompt": Confiar únicamente en los prompts del sistema para imponer la seguridad resultó poco fiable. Para modelos fuertemente alineados con la seguridad como Claude Opus 4.6, las políticas de solo prompt causaron un "abismo de usabilidad", reduciendo la Tasa de Usabilidad a casi el 0% a medida que los modelos interpretaban las instrucciones de seguridad como anulaciones absolutas de la intención del usuario. Por el contrario, algunos modelos mostraron una mejora en la usabilidad con los prompts, lo que destaca que el efecto depende del modelo y es impredecible.
• Eficacia de la ejecución en tiempo de ejecución (Runtime Enforcement): La condición Checkpoint (ejecución en tiempo de ejecución) logró el mayor rendimiento en todos los modelos.
  • Seguridad: Todos los modelos convergieron a una Tasa de Seguridad entre el 88% y el 91%, lo que sugiere un techo estructural donde los agentes se niegan de forma nativa sin invocar herramientas.
  • Usabilidad: La ejecución en tiempo de ejecución recuperó drásticamente la usabilidad para los modelos que previamente sobre-negaban (p. ej., +87.5 puntos porcentuales para GPT-4o y +70.9 para Claude Opus 4.6 en comparación con el solo prompt).
  • Rechazo Informado: La arquitectura Checkpoint garantizó un IRR del 100% por diseño, ya que el wrapper siempre emitía una explicación estructurada para los bloqueos, mientras que los modelos baseline y de solo prompt dependían de jueces de LLM estimados y mostraban un IRR menor.
• Dificultad de la Brecha de Verificación: La Brecha de Verificación resultó ser el tipo de escenario más desafiante para todos los modelos en el baseline, con las mayores ganancias observadas bajo la condición Checkpoint, lo que respalda la hipótesis de que el autoconocimiento se degrada bajo el cambio de distribución.

Significado y Reivindicaciones
El artículo posiciona estos resultados como un trabajo preliminar destinado a estimular la conversación dentro de la comunidad de los benchmarks. Sus principales contribuciones son:

1. Relato Teórico: Identificar que la incapacidad de medir la competencia de abstención es un resultado directo del reward hacking en los procesos de retroalimentación humana y del diseño de los benchmarks actuales.
2. Taxonomía y Métricas: Proporcionar un vocabulario basado en principios (la taxonomía de las tres brechas) y un conjunto de métricas compuestas (SR, UR, IRR) para hacer visible y evaluable la abstención.
3. Demostración de Viabilidad: Mostrar que el compromiso entre seguridad y usabilidad no es inherente sino ajustable, y que la ejecución en tiempo de ejecución puede resolver simultáneamente los modos de fallo de "sobre-negación" y "sub-negación".

Los autores concluyen que los benchmarks deben evolucionar para incluir escenarios donde la pausa es la verdad de campo correcta. Sin tales cambios, los incentivos de entrenamiento continuarán reforzando el sesgo de cumplimiento, impidiendo el despliegue de agentes que puedan detenerse de manera fiable cuando deben hacerlo. Las herramientas propuestas se ofrecen como un punto de partida para estresar contra arquitecturas de agentes y dominios de despliegue más amplios.