Resumo Técnico: CONTRACTBENCH

Definição do Problema: Contratos de Observação

Agentes de Modelos de Linguagem (LLM) estão sendo cada vez mais implantados para executar fluxos de trabalho de múltiplas etapas envolvendo APIs externas. Embora benchmarks existentes avaliem se os agentes podem alcançar um estado final de objetivo, eles frequentemente ignoram um modo de falha crítico em produção: a violação de contratos de observação.

Um contrato de observação é definido como um artefato retornado por uma ferramenta (por exemplo, uma URL pré-assinada, um parâmetro de estado OAuth, um token de sessão ou um webhook protegido por HMAC) que carrega duas restrições ortogonais impostas pelo sistema externo:

1. Validade Temporal: O artefato deve ser utilizado dentro de uma janela de tempo específica (Time-to-Live, TTL) antes de expirar ou tornar-se obsoleto.
2. Integridade ao Nível de Byte: O artefato deve ser retransmitido byte por byte, sem alteração. Pilhas de agentes do mundo real frequentemente introduzem mutações por meio de recodificação de URL, reordenação de parâmetros, truncamento ou quebra de linha, o que invalida assinaturas ou checksums.

Os benchmarks atuais falham ao testar conjuntamente essas restrições. Eles tipicamente tratam as saídas das ferramentas como meras informações para a próxima decisão, permitindo que os agentes parafraseiem ou percam artefatos intermediários sem penalidade. Na realidade, uma única violação de validade (uso de um token expirado) ou integridade (corrupção de uma assinatura) invalida todo o fluxo de trabalho.

Metodologia: CONTRACTBENCH

Para abordar essa lacuna, os autores introduzem o CONTRACTBENCH, um benchmark determinístico projetado para medir a conformidade com contratos de observação.

Design do Benchmark

• Escopo: 33 tarefas de dois eixos derivadas de padrões reais de contratos de API, incluindo URLs pré-assinadas, fluxos OAuth, solicitações assinadas, webhooks HMAC e janelas de limite de taxa.
• Avaliação de Dois Eixos: As tarefas são categorizadas em quatro quadrantes com base na pressão que exercem:
  • Q1 (Controle): Baixa pressão de validade/integridade (verificações de sanidade).
  • Q2 (Validade): Isola o planejamento temporal (por exemplo, lidar com manutenção agendada ou limites de taxa).
  • Q3 (Integridade): Isola a preservação de bytes (por exemplo, lidar com tokens longos ou armadilhas de URL).
  • Q4 (Eixo Duplo): Estressa ambos os eixos simultaneamente, refletindo a prevalência de artefatos limitados no tempo e vinculados a assinaturas em produção.
• Ambiente de Execução: As tarefas são executadas sob um relógio virtual para garantir reprodutibilidade total. Um servidor FastAPI emite rótulos de falha determinísticos com base em especificações reais de API (por exemplo, AWS SigV4, OAuth 2.0, RFC 6585).
• Protocolo de Avaliação:
  • Validadores Determinísticos: Sem avaliadores humanos ou "LLM como juiz". Um validador programático consome registros de solicitações HTTP para verificar se cada observação satisfaz tanto a janela de validade quanto o predicado de integridade (verificação de hash SHA-256).
  • Taxonomia de Falhas: Uma taxonomia de 15 rótulos classifica as falhas em Validade (por exemplo, EXPIRED_BEFORE_USE, RATE_LIMITED), Integridade (por exemplo, MUTATED_TOKEN, SIGNATURE_MISMATCH) e categorias Meta.
  • Solvabilidade: Cada tarefa inclui uma solução oracular que passa no validador, provando que a tarefa é solucionável.

Configuração Experimental

Os autores avaliaram 38 variantes de modelos em 15 famílias, incluindo modelos proprietários de ponta (Claude, série GPT-5, Gemini) e modelos de código aberto ajustados por instrução (Qwen, Mistral, Gemma, Llama, DeepSeek). Cada modelo foi executado no conjunto completo de 33 tarefas com $k=3$ execuções por tarefa ($n=99$ episódios por modelo) na temperatura 0.

Principais Descobertas

1. Modelos de Ponta Falham em Contratos de Observação

Nenhum modelo avaliado atingiu 80% no conjunto completo. O melhor desempenho, Claude Opus 4.6, alcança 77,8%. Isso revela que até mesmo os modelos mais avançados lutam para preservar artefatos intermediários. Além disso, o ranking no CONTRACTBENCH não correlaciona com benchmarks de propósito geral; por exemplo, o Gemini 2.5 Flash e o GPT-5.1 têm desempenho inferior a vários modelos de código aberto, enquanto o Llama-3.3-70B pontua próximo a 0%.

2. Penhasco de Capacidade Emergente no Qwen 3.5

Um "penhasco de capacidade" acentuado é observado dentro da família Qwen 3.5. O desempenho salta de 0% em 4B parâmetros para 56,6% em 9B, escalando suavemente para 70,7% em 397B-A17B. Abaixo do penhasco, os agentes falham em exibir contenção em trajetória intermediária (por exemplo, aguardar janelas de manutenção); acima dele, demonstram recuperação adaptativa. Isso sugere que a capacidade está ligada a receitas específicas de treinamento, e não apenas à contagem de parâmetros.

3. Pós-Treinamento é Necessário, mas Frágil

• Necessidade: Modelos base (não ajustados por instrução) de todas as famílias pontuam 0%, indicando que a conformidade com contratos é uma capacidade de pós-treinamento, não uma propriedade emergente de pré-treinamento.
• Fragilidade (Escalonamento Inverso): A família GPT-5 exibe uma regressão não monótona em forma de "V". O GPT-5.1 mostra uma queda significativa na conformidade (48,5%) em comparação com o GPT-5 (70,7%) e o GPT-5.2 (74,8%). Essa regressão é estruturada: o GPT-5.1 reintroduz especificamente falhas de integridade ao nível de byte (por exemplo, WRONG_VALUE, MUTATED_TOKEN), sugerindo que atualizações de pós-treinamento voltadas para a utilidade conversacional podem erodir inibições específicas necessárias para a conformidade com contratos (por exemplo, aguardar antes de tentar novamente, preservar bytes exatamente).

4. Sinais de Recompensa Acionáveis

Os autores testaram se os rótulos de falha poderiam servir como sinais de recompensa em contexto. Usando 42 falhas do GPT-5.1, eles descobriram que fornecer o rótulo de falha correto como uma dica de orientação melhorou as taxas de aprovação em +7,1 pontos percentuais em comparação com uma dica de rótulo errado. Isso indica que a taxonomia fornece sinais direcionais e acionáveis para correção no momento do teste, particularmente para falhas de estilo de integridade, enquanto falhas temporais frequentemente exigem intervenções arquitetônicas (por exemplo, TTLs legíveis por máquina) em vez de simples prompts.

Significado e Contribuições

O artigo afirma três contribuições principais:

1. Formalização de Contratos de Observação: Os autores definem contratos de observação como uma classe distinta de falha de agente governada por restrições temporais e de integridade ortogonais, formalizando um problema previamente negligenciado na literatura de avaliação de agentes.
2. Benchmark CONTRACTBENCH: Eles fornecem o primeiro benchmark determinístico e programático para essa capacidade, apresentando 33 tarefas, uma taxonomia de falhas de 15 rótulos e um modelo de execução de relógio virtual que elimina a ambiguidade de juízes humanos/LLM.
3. Insights Empíricos sobre Robustez de Agentes: O estudo revela que a conformidade com contratos é uma capacidade emergente e não monótona, que não é garantida pela capacidade geral de uso de ferramentas nem melhorada consistentemente pelo escalonamento. Destaca que o pós-treinamento "útil" pode regredir inibições específicas necessárias para interação confiável com APIs, e que os modelos de ponta atuais permanecem sem solução nesta métrica crítica de confiabilidade.

Os autores concluem que os contratos de observação devem se tornar um alvo de avaliação de primeira classe para garantir que os agentes possam agir de forma confiável sob as restrições entre etapas impostas por sistemas externos reais. Eles sugerem que mitigar essas falhas pode exigir mudanças arquitetônicas (por exemplo, armazenamento de artefatos baseado em identificadores) em vez de depender exclusivamente de modelos maiores ou melhor ajustados.