Instruction fragility under hidden operational requirements

Resumen Técnico: Fragilidad de la Instrucción bajo Requerimientos Operativos Ocultos

Definición del Problema
El artículo aborda el problema de la fragilidad de la instrucción derivada de requerimientos operativos ocultos. En las interacciones de lenguaje natural con Modelos de Lenguaje Extensos (LLM), los usuarios suelen omitir restricciones que son conocidas por ellos o por los evaluadores pero que están ausentes en el prompt (por ejemplo, formatos de salida específicos, límites de palabras, etiquetas de riesgo o limitaciones de fuentes). Los autores formalizan esto no como un único resultado pretendido, sino como una semántica de valores de conjunto: una instrucción denota un conjunto de ejecuciones factibles. La seguridad bajo tal subespecificación requiere que cada ejecución factible dentro de ese conjunto se encuentre dentro del conjunto aceptable del usuario. Si la instrucción permite incluso una sola ejecución inaceptable (por ejemplo, un método fraudulento para "hacerme rico"), la instrucción no es robusta. El problema central es que las instrucciones finitas no pueden identificar de manera única una única ejecución pretendida sin transmitir todas las restricciones latentes.

Metodología
El estudio combina un marco teórico formal con un banco de pruebas empírico controlado.

1. Marco Formal:

   • Los autores definen una instrucción $s$ como poseedora de una denotación $J_sK_B \subseteq H$ (un conjunto de historias factibles) bajo una teoría de fondo $B$.
   • La seguridad se define mediante el criterio de seguridad adversarial: $J_sK_B \subseteq A_{\tau, \eta}$, donde $A_{\tau, \eta}$ es el conjunto de historias aceptables (que satisfacen umbrales de utilidad y presupuestos de efectos secundarios).
   • Los análisis teóricos derivan límites inferiores de información-teórica (requiriendo $\Omega(\log N)$ símbolos para distinguir $N$ intenciones), restricciones de cardinalidad (las instrucciones finitas no pueden denotar subconjuntos arbitrarios de espacios de ejecución infinitos) y dureza computacional (la síntesis segura se mapea al problema de Cobertura de Conjuntos, que es NP-completo).

2. Construcción del Banco de Pruebas (Benchmark):

   • Se creó un banco de pruebas de 100 tareas, cubriendo 20 dominios temáticos (por ejemplo, memorandos de política, respuesta a incidentes, notas financieras).
   • Cada tarea consiste en un prompt de usuario visible y un conjunto de requerimientos ocultos (de 2 a 5 por tarea) conocidos por el evaluador pero omitidos en el prompt.
   • Los requerimientos se categorizan en tres tipos:
     • Implícitos convencionales: Suposiciones, incertidumbre, compensaciones (trade-offs), niveles de riesgo.
     • Operativos: Límites de palabras, límites de fuentes.
     • Formato privado: JSON válido, conteos exactos de viñetas.
   • Un "pase estricto" se define como la satisfacción de cada requerimiento oculto en una tarea.

3. Protocolos Experimentales:
   El estudio evaluó tres modelos (GPT-5.4, Claude Opus 4.7, Gemini 3.1 Pro) a través de nueve condiciones:

   • Baja Información: Prompting de un solo paso (one-shot), plantillas genéricas y aclaración de control negativo (preguntas forzadas con respuestas de "sin restricciones ocultas").
   • Elicitación: Aclaración forzada (respuestas veraces a preguntas basadas en menús) y verificación (listas de verificación visibles o internas).
   • Condiciones de Oráculo: Oráculo con presupuesto (revelación de hasta 4 requerimientos ocultos) y Oráculo Total (revelación de todos los requerimientos ocultos).

Resultados Clave
Los resultados empíricos, basados en 2,700 observaciones de tarea–modelo–condición, revelan un contraste marcado entre la interacción genérica y la revelación de las restricciones reales:

• Fallo de la Interacción Genérica: El prompting de un solo paso logró una tasa de pase estricto de solo el 2.7% (8/300 ensayos). Las plantillas genéricas (7.3%) y la aclaración de control negativo (1.7%) ofrecieron una mejora insignificante. Esto indica que la interacción sin información relevante para la tarea no recupera las restricciones omitidas.
• Valor de la Elicitación Correcta: Revelar los requerimientos ocultos correctos produjo un salto cualitativo en el rendimiento. La condición de Oráculo Total alcanzó una tasa de pase estricto del 64.7%. El Oráculo con Presupuesto (revelación parcial) alcanzó el 54.0%.
• Fallo de la Elicitación: Incluso cuando se obligó a los modelos a hacer preguntas (Forced Clarify), solo alcanzaron una tasa de pase del 8.0%. La brecha entre Forced Clarify y el Oráculo con Presupuesto (46. puntos porcentuales) demuestra que los modelos fallan frecuentemente al identificar qué restricciones latentes son relevantes, haciendo las preguntas equivocadas o pasando por alto las críticas (por ejemplo, los límites de fuentes se recuperaron solo el 1.0% de las veces).
• Fallo de Ejecución: Incluso bajo condiciones de Oráculo Total, donde todos los requerimientos eran conocidos, la tasa de pase no alcanzó el 100% (64.7%). Esto indica un segundo modo de fallo: cumplimiento de restricción conocida, donde los modelos fallan al ejecutar la especificación completa incluso cuando se proporciona explícitamente.
• Fallo Compuesto: Las tasas de pase estricto colapsaron de forma multiplicativa a medida que aumentaba el número de requerimientos ocultos. Para los protocolos de baja información, las tasas de pase cayeron a casi cero para tareas con 3 a 5 requerimientos.
• Especificidad de los Requerimientos: Los requerimientos de formato privado (JSON, conteos de viñetas) fueron casi imposibles de recuperar sin divulgación (0% en un solo paso), mientras que los requerimientos convencionales (incertidumbre, evitar absolutos) fueron parcialmente inferidos pero siguieron siendo poco fiables.

Significancia y Reivindicaciones
El artículo afirma identificar un modo de fallo controlado para el cumplimiento operativo estricto en sistemas de IA. Sus contribuciones principales son:

1. Formalización de la Fragilidad de la Instrucción: Proporciona un marco de denotación de valores de conjunto que muestra que la robustez requiere la exclusión de todas las ejecuciones inaceptables, no solo la inclusión de una buena ejecución.
2. Diagnóstico del Fallo de Comunicación: Los resultados demuestran que el cuello de botella en el seguimiento de instrucciones no es simplemente la falta de turnos de diálogo, sino la calidad de la información elicitada. La aclaración genérica es insuficiente; la elicitación de requerimientos dirigida es necesaria.
3. Reencuadre de Plantillas y Verificación: El estudio sugiere que las plantillas de prompt y las listas de verificación de verificación genéricas proporcionan solo ganancias marginales. No pueden sustituir la comunicación explícita de las restricciones privadas específicas de la tarea.
4. Implicaciones de Seguridad: Los hallazgos apoyan el diseño de principios de que los asistentes de IA robustos requieren la elicitación del estado de los requerimientos, la integración fiel de esas restricciones y la verificación contra dicho estado, en lugar de depender de prompts más largos o interacciones genéricas.

Los autores mantienen un alcance modesto, señalando que el banco de pruebas es sintético y solo de texto, centrándose en restricciones verificables superficialmente. No pretenden medir el comportamiento de agentes de largo alcance o la calidad subjetiva, sino aislar el modo de fallo específico de los requerimientos operativos omitidos. Los resultados sugieren que los modelos frontera actuales, aunque capaces, no son clarividentes y no pueden recuperar de manera confiable los requerimientos omitidos sin comunicación explícita.