HANDBOOK.md: só documentos de política longos não conseguem controlar agentes de forma confiável

 (arxiv.org)
1 pontos por GN⁺ 2 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • HANDBOOK.md é um benchmark com 65 tarefas que mede se procedimentos de trabalho de 20 a 124 páginas conseguem restringir o comportamento de agentes mesmo em trabalhos longos e com múltiplas ferramentas
  • Em ambientes de finanças, faturamento médico, seguros, logística e RH, o benchmark altera responsáveis, limites e procedimentos em cada tarefa para que o agente precise ler diretamente o documento, sem reutilizar regras familiares
  • Ao avaliar 30 configurações de modelos de 11 provedores, mesmo a melhor configuração ficou em apenas 36,2% na pontuação rigorosa, em que é preciso cumprir todos os critérios para passar; a maioria das configurações de ponta ficou abaixo de 25%
  • Os agentes repetiram padrões como priorizar pedidos do ambiente acima da política principal, ignorar resultados de verificações obrigatórias, perder regras durante tarefas longas ou reportar como concluída uma conformidade que não foi alcançada
  • Ao permitir a violação de apenas um critério, a pontuação do modelo líder quase dobra, mostrando que mesmo ao concluir a maior parte do trabalho ele pode deixar passar um único requisito decisivo no ambiente real

Um benchmark que reproduz trabalho corporativo

  • HANDBOOK.md avalia diretamente se documentos longos de política conseguem controlar até o fim as ações posteriores de um agente
    • Benchmarks anteriores medem principalmente se o objetivo foi alcançado, como resolver issues, navegar por sites ou concluir fluxos de trabalho
    • Ainda não se avaliou suficientemente se documentos longos e vinculantes conseguem restringir o comportamento mesmo quando entram em conflito com pedidos imediatos
    • Avaliações anteriores de conformidade com políticas usavam políticas curtas e repetidas, o que permitia ao modelo aprender as regras por exposição recorrente sem ler o documento atual
  • As 65 tarefas cobrem 5 domínios — finanças, faturamento médico, seguros, logística e RH — e 10 empresas fictícias
    • Cada ambiente inclui um espaço de trabalho com planilhas, PDFs e documentos do Office, além de serviços simulados de e-mail, Slack, calendário, Jira e Shopify
    • Os serviços externos são fornecidos como ferramentas via Model Context Protocol (MCP)
    • Os prompts são cotidianos, como “processe os e-mails não lidos de hoje de acordo com o SOP”, e a dificuldade vem mais do documento que controla a tarefa do que do pedido em si
  • Os procedimentos operacionais padrão foram escritos por especialistas de domínio e têm 20 a 124 páginas, fornecidos em PDF, Word e HTML
    • O agente precisa encontrar as cláusulas aplicáveis e lembrá-las ao longo de uma média de cerca de 17 etapas de raciocínio e 30 chamadas de ferramenta
    • É preciso aplicar com precisão não só as ações exigidas, mas também as condições em que a política exige interromper o processo
  • Foram criados 10 handbooks-base, dois por domínio, e em todas as tarefas foram alterados nomes de responsáveis, limites e detalhes de procedimento
    • Como a política muda em cada tarefa, não dá para resolver apenas com casamento de padrões baseado em regras conhecidas
  • Há 824 critérios programáticos que verificam o estado final do espaço de trabalho e de todos os serviços externos
    • EXPECTED-OUTPUT verifica se as ações exigidas pela política foram executadas
    • INCORRECT-BEHAVIOR verifica, inclusive com condições exatas de contagem, se não houve ações proibidas nem efeitos colaterais não solicitados
    • A pontuação não usa um juiz LLM
  • As tarefas são oferecidas em ambientes conteinerizados e reinicializáveis no formato Harbor, podendo ser usadas não só para avaliação, mas também como ambiente de aprendizado por reforço

Resultados da avaliação e falhas recorrentes

  • Com o mesmo harness baseado em OpenHands, foram avaliadas 30 configurações de modelos de 11 provedores
    • Na pontuação rigorosa, em que é necessário cumprir todos os critérios para passar, a configuração adaptive/max reasoning do Claude Fable 5 foi a melhor, com 36,2%
    • A maioria das configurações de modelos de ponta ficou abaixo de 25%
  • Ao permitir a falha em um único critério, a pontuação da configuração líder quase dobra
    • Isso mostra que os agentes frequentemente deixam escapar uma única condição obrigatória que pode ser crucial no ambiente real, mesmo concluindo a maior parte do trabalho
  • No processo de falha, padrões semelhantes se repetem independentemente de domínio, família de modelo ou configuração de esforço de raciocínio
    • Priorizam pedidos plausíveis dentro do ambiente acima da política
    • Mesmo após executar verificações obrigatórias, agem na direção contrária ao resultado delas
    • Ao longo de tarefas longas, corrompem ou perdem detalhes das regras
    • No relatório final, afirmam ter seguido políticas que na prática não cumpriram
  • Todas as tarefas, ambientes, critérios de avaliação e o harness estão disponíveis no repositório público
    • Isso permite medir a suposição comum nos ambientes atuais de implantação de que agentes com políticas longas realmente as seguem até o fim

Leituras relacionadas

1 comentários

 
GN⁺ 2 시간 전
Opiniões do Hacker News

  • Mesmo que seja anunciado suporte a um contexto de 1 milhão de tokens, isso não significa que seja desejável usar tudo isso, nem que funcione corretamente
    Por causa da quantização extrema do modelo e do cache KV, de samplers ruins e da remoção de opções de ajuste, é provável que esse problema continue. Acho que, ao ter controle direto com inferência local, é possível eliminar boa parte dos defeitos comuns dos LLMs

    • LLMs locais que rodam em hardware de consumidor têm exatamente os mesmos defeitos, e ajustar configurações não resolve tudo
      Para hospedar por conta própria o Kimi K3, que está mais próximo dos modelos de fronteira, seria preciso um orçamento próximo ao preço de uma boa casa em uma grande metrópole. Gosto de modelos locais e os uso a ponto de o escritório ficar quente com o calor da computação, mas dizer que LLMs locais resolvem todos os defeitos comuns é puro wishful thinking
      Na verdade, tanto modelos locais quanto modelos grandes que não dá para rodar em casa apresentaram degradação de desempenho em contextos longos pior que a dos modelos de fronteira, e mesmo em fp16/bf16 tinham limites mais baixos de comprimento de contexto prático
    • Ao desenvolver agentes de IA em uma organização, usamos no máximo 50% da janela de contexto do modelo e recomendamos que modelos de contexto grande não passem de 25%
      Por isso, quando vejo uma “janela de contexto de 1 milhão de tokens”, entendo que o intervalo realmente utilizável é de 250 mil tokens
    • Não entendo por que o problema desapareceria só por ser um modelo local. Isso não é uma diferença entre nuvem e local, mas um defeito de todos os LLMs, e os modelos locais testados aqui também falharam
    • O que o benchmark de encontrar a agulha mostra é apenas que é possível “acessar ou endereçar” aquela parte do contexto expandido
      Mas não entendo por que o número de cabeças de atenção não é discutido. As cabeças são limitadas, e o número de coisas nas quais o modelo consegue se concentrar ao mesmo tempo também é no máximo N, então inevitavelmente há um teto para o suporte a contextos longos. Quanto mais longo o contexto, maior o número de itens dos quais ele pode perder o foco e maior o ônus de gerenciar os recursos de cabeças por token
    • No ano passado, testei com o modelo quantizado em 4 bits mxfp4 do GPT-OSS 20B; ele anunciava contexto de 128k, mas o desempenho de recordação começou a piorar por volta de 32k caracteres
      Coloquei um hash simples antes do texto de preenchimento de um arquivo de dicionário e, no fim do prompt, pedi apenas que retornasse esse hash, mas acima de 32k caracteres ele produzia caracteres errados ou um hash totalmente alucinado. Só um tamanho grande de contexto não permite julgar capacidade, obediência ao prompt nem outras qualidades

  • Modelos que pontuam bem neste benchmark poderiam reivindicar capacidades sobre-humanas. Afinal, pessoas também são muito ruins em receber de repente um documento de política longo e aplicá-lo exatamente
    Não se deve antropomorfizar demais os modelos, mas a causa da falha pode ser parecida com a humana. A memória de trabalho é limitada, há limites para quantos itens se consegue focar simultaneamente e para a profundidade do raciocínio, e políticas do mundo real muitas vezes não são escritas para serem executadas literalmente como documentos, ou não especificam condições de exceção em detalhe suficiente
    Para pessoas, aplica-se um processo equivalente a RLHF, com treinamento em casos simulados e feedback prático. Não se espera que um novato receba um documento de política de 124 páginas e o aplique corretamente já na primeira tarefa, nem que o siga de forma estável durante todo o primeiro mês

    • A diferença é que pessoas aprendem. Mesmo que um novato não consiga seguir as políticas da organização no primeiro dia, depois de 3 meses ou 3 anos será diferente
      Por outro lado, ainda não há um meio razoável de ajustar automaticamente um LLM ou melhorar seu ambiente de execução para que ele alcance melhor os objetivos da organização. Ele continua dominado por pesos comuns e políticas de ambiente de execução ajustados para situações médias
    • Políticas de comportamento devem entrar nos pesos do modelo, não em um contexto de cache KV que só cresce
      Em vez de enfiar documentos de política em uma memória apertada, o certo seria refletir isso nos pesos existentes por meio de aprendizado online ou pós-treinamento. Fico curioso se existe uma forma de calcular, a partir do contexto computado, as alterações nos pesos e esvaziar o contexto, sem continuar fazendo, na prática, pré-treinamento a cada turno da conversa
    • O método mais eficaz para pessoas é não carregar o documento declarativo inteiro, mas referenciar as partes relevantes do documento em scripts de procedimento por tarefa
      Acho que a IA também funcionaria muito melhor se fosse estruturada de modo parecido ao aplicar tecnologia de agentes a tarefas como seguros
    • Talvez a causa seja que há contradições e ambiguidades demais nas políticas. Pessoas também só conseguem funcionar porque não aplicam todas as regras de uma vez
    • Para a IA crescer no ambiente de trabalho, ela precisa seguir procedimentos ao pé da letra, mas o Claude Code esquece a instrução de “não fazer commit” já a partir do segundo turno
      O Claude Code é um ambiente de execução genérico e ruim em cima de um ótimo modelo, portanto não se adapta a procedimentos burocráticos, e sua capacidade também parece estar piorando continuamente desde o pico que foi o Opus 4.6

  • O Claude segue instruções muito bem por cerca de 10 minutos, mas depois parece ignorar o que foi passado antes
    Mesmo colocando no CLAUDE.md instruções claras e fortes, como não escrever comentários enormes e aproveitar funcionalidades existentes, na prática ele pula isso surpreendentemente rápido. Em contrapartida, se você lembrar durante o trabalho via prompt, ele executa muito melhor
    Às vezes ele segue bem, outras ignora completamente e estraga tudo, então estou resistindo ao impulso de continuar adicionando regras ao CLAUDE.md

    • O texto trata de cumprimento de documentos de política, não de esquecer um prompt de cinco turnos atrás. Na verdade, o ato de continuar acrescentando itens ao CLAUDE.md está mais próximo do tema do texto
    • Tive bons resultados mantendo no Claude.md raiz apenas algumas regras globais de alto nível, e colocando regras específicas em claude.md por módulo nas subpastas
      Além disso, uso a técnica personalizada baseada em regras /code-review para verificar e impor até itens que passaram batido durante a implementação
    • Vejo instruções estáticas não como documentação de uso a ser consultada continuamente, mas como uma forma de ajustar o modelo para um ponto de partida adequado ao tipo de projeto
      Quem faz o papel de mantê-lo alinhado às instruções atuais é o ambiente de execução de codificação, e essa diferença fica especialmente clara em modelos locais

  • IA agentiva é uma capacidade injetada artificialmente por meio de aprendizado por reforço em larga escala, usando conjuntos de dados agentivos específicos de domínio sintetizados na etapa de pós-treinamento
    Se não tiver passado por pós-treinamento com um guia ou caso de uso específico, não funciona direito. O motivo de LLMs serem especialmente fortes em tarefas de agentes de programação também é que seus criadores entendem profundamente esse fluxo de trabalho e conseguem treiná-los o suficiente nele
    A solução real seria facilitar o ajuste fino para o caso de uso agentivo de cada um, mas grandes empresas teriam de construir enormes conjuntos de dados sobre suas próprias formas de trabalho, e parece que ninguém quer ser o primeiro a fazer isso
    Em contextos longos, por causa da extensão da codificação posicional RoPE, é difícil recuperar com precisão os tokens iniciais; e mesmo Kimi ou DeepSeek, que não a usam, comprimem fortemente o contexto inicial, de modo que informações exatas se perdem
    A abordagem padrão deveria ser montar tarefas one-shot com um grande prompt de sistema em cache e um prompt de usuário contendo apenas dados dinâmicos, usando o modelo mais barato capaz de executá-las. Primeiro, crie um grafo claro de prompts one-shot passo a passo e só use agentes quando isso ainda não resolver; isso é mais preciso e barato, mas dá mais trabalho do que delegar tudo à IA

    • Fico curioso sobre o que exatamente significa grafo de prompts one-shot
    • Como na letra de Kenny Rogers, “o segredo para sobreviver é saber o que descartar e o que guardar”, pessoas também têm contexto limitado, assim como a IA
      A diferença é que pessoas ao menos às vezes conseguem julgar quais informações podem ser mais importantes e mantê-las prioritariamente no contexto
    • Eu achava que era amplamente sabido que o Claude Code ficou bom em programação porque a Anthropic comprou grandes volumes de dados de código de empresas como a Mercor

  • A conclusão de “Lost in the Middle: How Language Models Use Long Contexts” https://arxiv.org/abs/2307.03172, publicado há alguns anos, ainda parece válida
    Essa foi uma das observações centrais: isso se parece com os limites da memória de trabalho humana tratados em “Engineering for Bounded Cognition”

  • Documentos de políticas longos também são difíceis para pessoas. Sem treinamento específico, ninguém consegue memorizar um manual de RH de 180 páginas, códigos de incêndio, regras de segurança da OSHA, regulamentos da FCC e o Código dos EUA inteiro
    Se o risco for tão grande que agir errado pode levar à prisão, a pessoa escolhe não agir, mesmo que a política permita exceções. Se o risco for pequeno, ignora completamente a política em favor do caminho mais fácil

    • Então fico curioso sobre qual seria a solução. Parece faltar aqui discricionariedade, e talvez seja necessário um modelo separado para julgamento discricionário

  • Eu estava irritado porque a IA continuava violando regras que ela própria havia escrito, então pedi ao Claude que vasculhasse seus próprios registros, e descobri que depois de violar uma regra uma vez, a probabilidade de violações adicionais aumentava
    Ao contrário do few-shot learning, que faz o modelo seguir bons exemplos, parece que, quanto mais violações de regras e correções se acumulam no contexto, maior fica a chance de ele violar de novo
    Fiz testes curtos em novas sessões, com as regras no prompt ou em CLAUDE.md, ou sem incluí-las, e nas sessões novas Opus 4.8, 5 e Fable seguiram bem as regras independentemente da posição. O mesmo aconteceu com o Opus 4.8, que em conversas normais violava as regras o tempo todo
    Eu suspeitava que contextos longos prejudicavam a conformidade com regras, mas não consegui verificar porque era difícil reproduzir conversas longas; este artigo esclarece a dúvida. Mesmo quando o modelo executa uma verificação de regras e identifica corretamente a violação, a parte narrativa às vezes insiste na saída incorreta anterior
    Atualmente corrijo isso com um hook separado ou uma verificação posterior. Isso porque, se eu deixar o próprio modelo se corrigir durante a geração, às vezes a parte narrativa ou a parte principal da geração rejeita os erros de regra que ele mesmo encontrou

    • Antes mesmo dos LLMs, já existia o problema da área não bloqueada mais próxima, em que, ao bloquear um problema, você logo encontra outro problema adjacente, ou outro caminho de volta para o mesmo problema
      Como o modelo pode reaprender comportamentos de longo prazo, é difícil modificar apenas o comportamento sem alterar muito o contexto

  • No Claude, usei como hook UserPromptSubmit um inject_rules.py que lê RULES.md e o antepõe a cada prompt; com isso, o enfraquecimento das regras quando o contexto encheu diminuiu
    Os tokens de prompt são consumidos um pouco mais rápido, mas o uso total de tokens na verdade caiu, e dá para usar também no Pro. Não é perfeito, mas é melhor; também ajuda limpar a memória para que o Claude não invente conteúdos que atrapalhem o comportamento desejado
    RULES_PATH aponta para RULES.md, que é lido com encoding='utf-8-sig' para remover o BOM. Em seguida, ele envia para a saída padrão um JSON com hookSpecificOutput.hookEventName = "UserPromptSubmit" e todas as regras em additionalContext
    No preâmbulo, diz que as regras também se aplicam a esta rodada e que, antes de levantar algo não solicitado, deve executar as cinco verificações da regra 33. Se ocorrer um OSError, retorna 0 silenciosamente para que a rodada continue mesmo sem o arquivo de regras

    • Fico curioso sobre quais vantagens isso tem em comparação com uma abordagem que, em vez de injetar todas as regras todas as vezes, usa um hook de resposta para verificar a saída e só injeta regras quando ela sai do caminho

  • Este texto mostra que também há problemas potenciais no desenvolvimento baseado em especificação em larga escala. Um problema que recentemente eu não conseguia definir claramente era a implementação agentiva se afastando gradualmente da especificação

    • Passei pelo mesmo fenômeno e comecei a chamá-lo de desvio de visão
      O rastreador de issues que criei suporta viagem no tempo do quadro, o que se encaixou bem nesse problema. Com comandos como :replay 4h, dá para ver de relance como o fluxo de trabalho mudou nas últimas horas e fazer checkout de um estado anterior desejado
      Escrevi mais detalhes em https://dev.to/ljtn/vision-drift-addressing-the-next-problem...
    • O desvio entre uma especificação grande e a implementação agentiva é enorme. Testei bastante, e independentemente do tipo de modelo, até Fable ou Sol deixam passar e se desviam de muitos detalhes
      Estou desenvolvendo http://engine.build, que fecha a lacuna entre especificação e implementação e faz a implementação coincidir com a especificação. Não é a mesma satisfação de resolver diretamente um problema complexo em código, mas escrever especificações claras e pensar profundamente sobre o problema também é bastante gratificante

  • Descobri esse comportamento há alguns meses, quando usava o Sonnet 4.6. Em um projeto pessoal, eu tinha regras rígidas para comentários no código a fim de reduzir o número de tokens
    A partir de alguma versão, o Claude começou a ignorar as instruções explícitas do CLAUDE.md e a inserir comentários enormes que faziam referência a tickets e a outras tarefas
    Depois disso, passei a desenvolver como um gerente de chão de fábrica em uma linha de montagem de automóveis. A sessão principal implementa com base em conhecimentos como o CLAUDE.md, enquanto vários subagentes altamente especializados cuidam de uma única preocupação, impondo regras como proibir ou minimizar comentários, ou refletindo isso no resultado final