HERA enseña a los agentes de IA a rechazar tareas imposibles: la precisión pasa del 61,7% al 83,3%

Un agente que hace con total seguridad algo que no se puede hacer es más peligroso que uno que simplemente se equivoca. Llama a herramientas, gasta presupuesto e informa de un éxito donde no existe solución. Los autores del artículo sobre HERA, incluido en Hugging Face Daily Papers, proponen una forma de corregirlo. En tareas reservadas para la evaluación, su arnés evolucionado elevó la precisión de rechazo del 61,7% al 83,3%. La proporción de tareas resolubles completadas pasó, al mismo tiempo, del 68,3% al 76,7%. Después, el mejor arnés se transfirió a otros 19 LLM y les añadió, de media, 15,3 puntos porcentuales de precisión de rechazo.

El problema: los agentes no saben decir «no puedo»

El trabajo lo denomina agentic abstention: la capacidad del agente para reconocer que una tarea es irrealizable en el entorno actual y detenerse. Hasta ahora, para mejorar la fiabilidad en estos casos se seguían dos vías: reentrenar el modelo o ajustar el arnés (harness), es decir, todo lo que rodea al modelo: instrucciones, reglas de uso de herramientas y comprobaciones. Ambos enfoques optimizaban para un conjunto fijo de tareas. El resultado es predecible: funciona con trampas conocidas de antemano y falla con tipos de error nuevos.

HERA ataca precisamente esa limitación. El framework consta de dos partes, y la segunda es más importante que la primera.

Cómo funciona HERA

La primera parte es un pipeline que construye automáticamente pares de tareas verificables: una realizable y otra irrealizable. La irrealizable se obtiene de la realizable mediante una mutación controlada del entorno. Por ejemplo, se retira del entorno aquello sin lo cual la solución es imposible. El par ofrece un contraste limpio: el agente debe resolver una versión y rechazar la otra. La verificabilidad es clave aquí: la respuesta correcta se conoce por construcción y no hace falta etiquetado manual.

La segunda parte es un procedimiento de coevolución. Los fallos en tareas anteriores impulsan la adaptación del arnés, y esos mismos puntos débiles se convierten en el encargo para generar nuevos entornos y tareas. El arnés mejora, el entorno se vuelve más duro justo donde el agente fallaba, y el ciclo se repite. En lugar de un benchmark estático, el resultado es un simulador de entrenamiento que se adapta a las debilidades del agente.

Las cifras

• Precisión de rechazo en tareas reservadas: 61,7% → 83,3% (+21,6 p. p.).
• Ejecución de tareas resolubles: 68,3% → 76,7% (+8,4 p. p.).
• En ambos indicadores, HERA lidera entre los métodos comparados.
• Transferencia a otros 19 LLM: +15,3 p. p. de media en precisión de rechazo, sin optimización para cada modelo concreto.
• Según la estimación de los autores, los modelos pequeños con este arnés alcanzan a los más potentes con un coste aproximadamente un 85% menor.

Conviene destacar aparte la mejora en las tareas resolubles. El precio habitual de la cautela es el exceso de prudencia: el agente empieza a rechazar tareas que sí tienen solución. Aquí no ocurrió: ambas métricas subieron a la vez. Nuestra aritmética: los saltos entre valores son múltiplos de 1,67 p. p., lo que apunta a un conjunto reservado de unas 60 tareas. La muestra es pequeña, así que las diferencias de unos pocos puntos entre métodos deben leerse con cautela. La transferencia a 19 modelos funciona, en cambio, como una comprobación independiente: un resultado promediado sobre tantos LLM depende menos de la suerte con un único conjunto de tareas.

La parte más práctica del resultado es la economía. Un arnés ajustado una sola vez se transfiere a otros modelos, y un modelo pequeño con un buen arnés cubre parte de los escenarios en lugar de un costoso modelo insignia. El ahorro del 85% es una estimación; los autores no lo presentan como un coste medido en producción, y en una carga de trabajo real la cifra dependerá de las tarifas y del perfil de las tareas.

Para los equipos que construyen agentes, el artículo deja tres conclusiones. Primera: las tareas irrealizables deben incluirse en el conjunto de pruebas como una clase aparte y contarse con una métrica propia. Segunda: la mutación del entorno es una forma barata de obtener esos casos: se toma un escenario que funciona y se rompe la condición de la que depende la solución. Tercera: antes de pagar por un modelo más potente, conviene comprobar si un arnés rediseñado resuelve el problema. Las limitaciones siguen ahí: los resultados proceden de los entornos concretos de los autores, y la robustez ante fallos que las mutaciones no cubren aún está por comprobar.