Instruction fragility under hidden operational requirements

Resumo Técnico: Fragilidade de Instrução sob Requisitos Operacionais Ocultos

Definição do Problema
O artigo aborda o problema da fragilidade de instrução decorrente de requisitos operacionais ocultos. Em interações de linguagem natural com Grandes Modelos de Linguagem (LLMs), os usuários frequentemente omitem restrições que são conhecidas por eles ou pelos avaliadores, mas que estão ausentes do prompt (ex: formatos de saída específicos, limites de palavras, rótulos de risco ou limitações de fontes). Os autores formalizam isso não como um único resultado pretendido, mas como uma semântica de valores de conjunto: uma instrução denota um conjunto de execuções viáveis. A segurança sob tal subespecificação exige que cada execução viável dentro desse conjunto esteja dentro do conjunto aceitável do usuário. Se a instrução permitir até mesmo uma execução inaceitável (ex: um método fraudulento para "tornar-me rico"), a instrução não é robusta. O problema central é que instruções finitas não podem identificar unicamente uma única execução pretendida sem transmitir todas as restrições latentes.

Metodologia
O estudo combina um arcabouço teórico formal com um benchmark empírico controlado.

1. Arcabouço Formal:

   • Os autores definem uma instrução $s$ como tendo uma denotação $J_sK_B \subseteq H$ (um conjunto de históricos viáveis) sob uma teoria de fundo $B$.
   • A segurança é definida pelo critério de segurança adversarial: $J_sK_B \subseteq A_{\tau, \eta}$, onde $A_{\tau, \eta}$ é o conjunto de históricos aceitáveis (que satisfazem limiares de utilidade e orçamentos de efeitos colaterais).
   • Análises teóricas derivam limites inferiores de informação-teórica (exigindo $\Omega(\log N)$ símbolos para distinguir $N$ intenções), restrições de cardinalidade (instruções finitas não podem denotar subconjuntos arbitrários de espaços de execução infinitos) e complexidade computacional (a síntese segura mapeia para o problema Set Cover, que é NP-completo).

2. Construção do Benchmark:

   • Foi criado um benchmark de 100 tarefas, cobrindo 20 domínios tópicos (ex: memorandos de política, resposta a incidentes, notas financeiras).
   • Cada tarefa consiste em um prompt de usuário visível e um conjunto de requisitos ocultos (2 a 5 por tarefa) conhecidos pelo avaliador, mas omitidos do prompt.
   • Os requisitos são categorizados em três tipos:
     • Convencionais implícitos: Suposições, incerteza, trade-offs, níveis de risco.
     • Operacionais: Limites de palavras, limites de fontes.
     • Formatação privada: JSON válido, contagens exatas de bullets.
   • Um "passagem estrita" é definida como o cumprimento de todos os requisitos ocultos de uma tarefa.

3. Protocolos Experimentais:
   O estudo avaliou três modelos (GPT-5.4, Claude Opus 4.7, Gemini 3.1 Pro) através de nove condições:

   • Baixa Informação: Prompt de disparo único (one-shot), templates genéricos e esclarecimento de controle negativo (perguntas forçadas com respostas de "sem restrições ocultas").
   • Elicitação: Esclarecimento forçado (respostas verdadeiras a perguntas baseadas em menus) e verificação (checklists visíveis ou internos).
   • Condições de Oráculo: Oráculo com orçamento (revelando até 4 requisitos ocultos) e Oráculo Total (revelando todos os requisitos ocultos).

Principais Resultados
Os resultados empíricos, baseados em 2.700 observações tarefa–modelo–condição, revelam um contraste gritante entre a interação genérica e a revelação das verdadeiras restrições:

• Falha da Interação Genérica: O prompting de disparo único alcançou uma taxa de passagem estrita de apenas 2,7% (8/300 tentativas). Templates genéricos (7,3%) e o esclarecimento de controle negativo (1,7%) ofereceram melhorias negligenciáveis. Isso indica que a interação sem informação relevante para a tarefa não recupera as restrições omitidas.
• Valor da Elicitação Correta: Revelar os requisitos ocultos corretos produziu um salto qualitativo no desempenho. A condição de Oráculo Total alcançou uma taxa de passagem estrita de 64,7%. O Oráculo com Orçamento (revelação parcial) atingiu 54,0%.
• Falha de Elicitação: Mesmo quando os modelos eram forçados a fazer perguntas (Esclarecimento Forçado), eles alcançaram apenas uma taxa de passagem de 8,0%. A lacuna entre o Esclarecimento Forçado e o Oráculo com Orçamento (46,0 pontos percentuais) demonstra que os modelos falham frequentemente em identificar quais restrições latentes são relevantes, fazendo as perguntas erradas ou omitindo as críticas (ex: limites de fontes foram recuperados apenas 1,0% das vezes).
• Falha de Execução: Mesmo sob condições de Oráculo Total, onde todos os requisitos eram conhecidos, a taxa de passagem não atingiu 100% (64,7%). Isso indica um segundo modo de falha: conformidade de restrição conhecida, onde os modelos falham em executar a especificação completa mesmo quando ela é explicitamente fornecida.
• Falha Composta: As taxas de passagem estrita colapsaram multiplicativamente à medida que o número de requisitos ocultos aumentava. Para protocolos de baixa informação, as taxas de passagem caíram para quase zero para tarefas com 3 a 5 requisitos.
• Especificidade de Requisito: Requisitos de formatação privada (JSON, contagem de bullets) foram quase impossíveis de recuperar sem divulgação (0% em disparo único), enquanto requisitos convencionais (incerteza, evitar absolutos) foram parcialmente inferidos, mas ainda assim pouco confiáveis.

Significância e Alegações
O artigo afirma identificar um modo de falha controlado para a conformidade operacional estrita em sistemas de IA. Suas principais contribuições são:

1. Formalização da Fragilidade de Instrução: Ele fornece um arcabouço denotacional de valores de conjunto mostrando que a robustez requer a exclusão de todas as execuções inaceitáveis, não apenas a inclusão de uma boa execução.
2. Diagnóstico de Falha de Comunicação: Os resultados demonstram que o gargalo no seguimento de instruções não é meramente o número de turnos de diálogo, mas a qualidade da informação elicitada. O esclarecimento genérico é insuficiente; a elicitação direcionada de requisitos é necessária.
3. Reenquadramento de Templates e Verificação: O estudo sugere que templates de prompt e checklists de verificação genéricos oferecem ganhos marginais. Eles não podem substituir a comunicação explícita de restrições privadas específicas da tarefa.
4. Implicações de Segurança: Os achados apoiam o princípio de design de que assistentes de IA robustos exigem elicitação de estado de requisito explícito, integração fiel dessas restrições e verificação contra esse estado, em vez de depender de prompts mais longos ou interação genérica.

Os autores mantêm um escopo modesto, observando que o benchmark é sintético e apenas de texto, focando em restrições verificáveis superficialmente. Eles não afirmam medir o comportamento de agentes de longo horizonte ou qualidade subjetiva, mas sim isolar o modo de falha específico de requisitos operacionais omitidos. Os resultados sugerem que os modelos de fronteira atuais, embora capazes, não são clarividentes e não conseguem recuperar confiavelmente restrições omitidas sem comunicação explícita.