Resumen Técnico: IH-BENCHMARK

Planteamiento del Problema

A medida que los Modelos de Lenguaje Extensos (LLMs) evolucionan hacia agentes que orquestan herramientas y gestionan conversaciones de múltiples turnos, la fiabilidad de la robustez de la jerarquía de instrucciones se ha vuelto central tanto para la seguridad como para la utilidad. El problema central abordado es la capacidad del modelo para priorizar correctamente las instrucciones basándose en su origen: los mensajes del sistema deben tener precedencia sobre las entradas del usuario, las cuales, a su vez, deben tener precedencia sobre el historial de chat y las salidas de las herramientas.

Cuando los modelos fallan al respetar este orden, las entradas adversarias del usuario pueden invalidar las restricciones del sistema, y las salidas maliciosas de las herramientas pueden secuestrar el comportamiento del modelo en medio de una tarea. Aunque trabajos previos han formalizado esta jerarquía, las evaluaciones existentes sufren de dos limitaciones primarias:

1. Enfoque en un solo borde: Muchos benchmarks se centran únicamente en conflictos sistema-usuario ($S \succ U$), descuidando los conflictos derivados de las salidas de las herramientas.
2. Datasets adaptados: Otros adaptan conjuntos de datos públicos en lugar de construir escenarios de conflicto de jerarquía diseñados específicamente, lo que resulta en una cobertura limitada de entornos agénticos y restricciones específicas como listas de permitidos/denegados de herramientas o restricciones de parámetros.

Consecuentemente, existe una falta de benchmarks que prueben conjuntamente los conflictos a través de los niveles de la jerarquía en un entorno agéntico.

Metodología: IH-BENCHMARK

Los autores introducen IH-BENCHMARK (IH-B), un benchmark diseñado a propósito para evaluar la robustez de la jerarquía de instrucciones a través de dos pistas distintas:

1. Sistema $\succ$ Usuario ($S \succ U$): Evalúa si un modelo preserva una restricción de mayor prioridad del sistema cuando un usuario emite una solicitud conflictiva.
2. Usuario $\succ$ Herramienta ($U \succ T$): Evalúa si un modelo preserva la tarea del usuario cuando aparece una instrucción conflictiva en una salida de herramienta de menor prioridad.

Construcción y Alcance

• Familias de Restricciones: El benchmark se construye a partir de una taxonomía de autoría humana de 44 familias de restricciones que abarcan cinco dominios: genérico, salud, finanzas, comercio minorista (retail) y codificación.
  • Pista $S \succ U$: 19 familias que cubren restricciones de salida (léxicas, de formato), restricciones de tema (temas prohibidos, desviación hacia competidores) y restricciones de herramientas (prohibiciones absolutas, restricciones de parámetros).
  • Pista $U \succ T$: 25 familias que cubren manipulación del formato de respuesta, manipulación de contenido (alteración fáctica), manipulación de herramientas (bloqueo/redirección de llamadas) y acciones agénticas de alta severidad (ejecución de comandos, exfiltración de datos, compras no autorizadas).
• Generación de Escenarios: IH-B genera procedimentalmente 2,336 escenarios ejecutables (734 en $S \succ U$, 1,602 en $U \succ T$). Los escenarios se generan vinculando parámetros de restricción y variando:
  • Rigurosidad de la Restricción ($L$): Desde declaraciones simples ($L_1$) hasta cláusulas fortalecidas y directivas de rechazo ($L_3$).
  • Fraseo del Prompt ($P$): Solicitudes de usuario explícitas ($P_1$) frente a implícitas ($P_2$).
  • Variante de Entrega ($D$): Para $U \succ T$, variando cómo las instrucciones conflictivas se integran en las salidas de las herramientas (planas, con ruptura de contexto/breakout, de reconocimiento, de cambio de flujo).
• Simuladores de Agentes: Para los escenarios agénticos de $U \succ T$, el benchmark emplea tres simuladores basados en Python con estado (codificación, soporte de retail, soporte de salud) para modelar efectos secundarios persistentes e interacciones de herramientas de múltiples pasos.
• Protocolo de Evaluación: Se utiliza un protocolo uniforme de paso/fallo binario.
  • DSL de Predicado: Un lenguaje de dominio específico ligero evalúa la coincidencia de cadenas, comprobaciones estructurales e inspección de llamadas a herramientas.
    la LLM-as-a-Judge (LLM como Juez): Se utiliza selectivamente para categorías donde la verificación mecánica es difícil (por ejemplo, desprestigio de marca, compromiso de tema), utilizando una rúbrica de 4 niveles mapeada a decisiones binarias.
  • Escenarios sin Conflicto: Incluidos para medir el sobre-rechazo (over-refusal) y asegurar que los modelos no fallen en solicitudes ordinarias debido a la sensibilidad de las restricciones.

Contribuciones Clave

1. Benchmark Procedimental: La propuesta de IH-B, que cubre las pistas $S \succ U$ y $U \succ T$ con 2,336 escenarios derivados de 44 familias de restricciones.
2. Marco de Evaluación Unificado: Un sistema que combina escenarios controlados a nivel de prompt con simuladores de agentes con estado, permitiendo la evaluación en entornos estáticos, mediados por herramientas y agénticos.
3. Análisis Empírico Exhaustivo: Evaluación de 37 variantes de modelos (22 de código cerrado, 15 de pesos abiertos) revelando que la robustez de la jerarquía de instrucciones no es una única capacidad, sino un conjunto de comportamientos que varían según las superficies de conflicto y los tipos de restricción.

Resultados

La evaluación de 37 modelos revela una varianza significativa en el rendimiento, con tasas de cumplimiento general que oscilan entre el 98.2% y el 20.5%.

• Disociación de Pistas: Un alto rendimiento en la pista $S \succ U$ no es un indicador fiable de la robustez en $U \succ T$. Por ejemplo, Grok 4.20 (R) logró un 96.9% de cumplimiento en $S \succ U$ pero solo un 65.6% en $U \succ T$. Esto sugiere que resistir las anulaciones directas del usuario no garantiza la resistencia a la inyección de salidas de herramientas.
• Disparidades entre Modelos: Los modelos de código cerrado generalmente superaron a los modelos de pesos abiertos. El cumplimiento promedio para los modelos de código cerrado fue del 88.6% ($S \succ U$) y 75.1% ($U \succ T$), comparado con el 80.5% y 59.1% para los modelos de pesos abiertos.
• Efectos de la Rigurosidad de la Restricción:
  • En $S \succ U$, las restricciones más estrictas ($L_2, L_3$) mejoraron consistentemente el cumplimiento, particularmente para los modelos más débiles (por ejemplo, Qwen 3 235B-A22B mejoró del 23.5% al 88.2% en entornos específicos de dominio).
  • En $U \succ T$, el efecto del endurecimiento fue menos uniforme. Mientras que algunos modelos (por ejemplo, Grok 4.20 (R)) mostraron ganancias masivas (del 18.8% al 89.6%), otros (por ejemplo, Qwen 3 235B-A22B) permanecieron cerca del 10% en todos los niveles de rigurosidad, indicando una incapacidad fundamental para mantener los límites en lugar de solo una sensibilidad a la instrucción.
• Análisis de Familias de Restricciones:
  • $S \succ U$: La familia más difícil fue forbid-tools-all (52.4%), donde los modelos luchan por rechazar todas las llamadas a herramientas a pesar de las solicitudes del usuario. Las restricciones de tema fueron las más fáciles (por ejemplo, forbid-disparagement en 98.6%).
  • $U \succ T$: Las familias más difíciles involucraron acciones de bajo riesgo y no sospechosas como content-lie (50.1%) y format-disclaimer (50.4%). Por el contrario, las acciones de alta severidad como compras no autorizadas o cierres masivos de tickets fueron resistidas con mayor fiabilidad (por ejemplo, purchase en 88.1%), probablemente debido al entrenamiento de alineación de seguridad existente.
• Subtileza de los Fallos: Los fallos más reveladores fueron a menudo sutiles (por ejemplo, avisos legales inyectados, pequeñas distorsiones fácticas) en lugar de acciones abiertamente peligrosas. Los modelos fueron más fiables resistiendo acciones masivas no autorizadas que detectando derivaciones fácticas sutiles.

Significado y Limitaciones

El artículo argumenta que la robustez de la jerarquía de instrucciones no es una capacidad uniforme única, sino una colección de comportamientos que deben evaluarse a través de múltiples superficies de conflicto, tipos de restricción y presentaciones de ataque. La publicación de IH-B, incluyendo el corpus, los simuladores y el marco de evaluación, tiene como objetivo apoyar la evaluación y el despliegue responsables al ayudar a los desarrolladores a identificar debilidades específicas del modelo o del escenario antes del despliegue.

Limitaciones:

• El benchmark se centra en escenarios de tarea única acotados y no cubre entornos de múltiples turnos más largos donde el contexto se acumula con el tiempo.
• La cobertura de dominios es seleccionada y asimétrica basada en dónde cada dominio encaja naturalmente en la pista (por ejemplo, finanzas solo está en $S \succ U$, codificación solo en $U \succ T$).
• Aunque 35 de las 44 familias de restricciones fueron redactadas por humanos, el resto fueron sugeridas por un LLM y revisadas manualmente, lo que significa que la cobertura es amplia pero no exhaustiva.

Los autores reconocen que revelar debilidades específicas de los modelos conlleva riesgos de ayudar a los adversarios, pero postulan que el beneficio de una evaluación de seguridad sistemática y reproducible supera estos riesgos.