LLMs danificam documentos ao delegar tarefas

• DELEGATE-52 é um benchmark que avalia o quanto um documento é preservado com fidelidade em fluxos de trabalho de delegação, nos quais o usuário encarrega um LLM de editar documentos longos
• Esse benchmark cobre tarefas que exigem edição aprofundada de documentos em 52 domínios especializados, como programação, cristalografia e notação musical, e a simulação de exemplo é composta por uma delegação de 20 tarefas consecutivas
• Em experimentos com 19 LLMs, até modelos de fronteira como Gemini 3.1 Pro, Claude 4.6 Opus e GPT 5.4 danificam em média 25% do conteúdo do documento ao final de fluxos de trabalho longos
• A danificação do documento aparece como erros raros, mas graves, e a degradação aumenta conforme crescem o tamanho do documento, a duração da interação e a quantidade de arquivos distratores; o uso de ferramentas agentivas também não melhora o desempenho
• Atualmente, é difícil considerar os LLMs representantes confiáveis para edição delegada de documentos, e microsoft/DELEGATE52 e datasets/microsoft/DELEGATE52 foram publicados como materiais relacionados ao DELEGATE-52

---

Padrões de falha na edição delegada

• O trabalho delegado parte do pressuposto de confiança de que o usuário entrega a tarefa ao LLM e de que o modelo a executará sem inserir erros no documento
• Em experimentos em larga escala com 19 LLMs, os modelos atuais degradam os documentos durante o processo de delegação
• Outros modelos falham de forma ainda mais grave do que os modelos de fronteira
• A danificação do documento se acumula ao longo de interações longas e corrói o documento silenciosamente

Mudanças em documentos apresentadas como exemplo

• No domínio Graph Diagrams, o documento Linux Kernel Architecture aparece no Gemini 3.1 Pro com 79% do original após 4 rodadas, 49% após 10, 48% após 14 e 48% após 20
• No domínio Textile Patterns, o documento 12-Shaft Twill Diamond aparece no Claude 4.6 Opus com 100% do original após 4 rodadas, 40% após 10, 27% após 14 e 34% após 20
• No domínio 3D Objects, o documento ActionBoy Palm Tree aparece no GPT-5.2 com 100% do original após 4 rodadas, 31% após 10, 15% após 14 e 6% após 20

Materiais publicados

• microsoft/DELEGATE52
• datasets/microsoft/DELEGATE52

[GN⁺]

Comentários do Hacker News

• Tenho ressalvas quanto aos resultados sobre uso de ferramentas

  Não é surpresa que conteúdos longos se deteriorem ao passar de ida e volta por um LLM. Quem usa LLM com frequência já sabe que não se deve fazer isso

  Fiquei surpreso com o artigo dizer que o uso de ferramentas não ajudou, mas ao mesmo tempo eles admitem que implementaram um “harness básico de agente” e que não era um sistema moderno otimizado

  Na prática, o harness só tem read_file() e write_file(), então é quase só mais uma etapa no processamento de ida e volta. Hoje em dia, harnesses de agentes de programação investem bastante no desenho de ferramentas de edição de arquivos; por exemplo, existe o conjunto de ferramentas de edição do Claude: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

  Os comandos str_replace e insert são essenciais para evitar edições arriscadas que reescrevem o arquivo inteiro

  Pelo menos eles oferecem uma ferramenta run_python(), então é possível que modelos melhores a tenham usado para fazer substituições de string. Eu gostaria de ver se o prompt de sistema incentivava manipulação via Python ou se levava o modelo a ler e reescrever arquivos

  O código do harness está aqui: https://github.com/microsoft/delegate52/blob/main/model_agen...

  O trecho relevante do prompt diz algo como “você pode abordar isso da forma que considerar mais eficaz, seja programaticamente ou escrevendo diretamente no arquivo”

  Como costuma acontecer nesses artigos, os resultados refletem mais o design do harness usado pelos autores do que o modelo em si. Seja um engenheiro de IA experiente ou um engenheiro de prompts, acho que melhorar iterativamente o próprio harness daria resultados melhores nesse teste

  • Concordo com quase tudo, exceto a parte de “quem usa LLM com frequência já sabe que não se deve fazer isso”

    Com a adoção de LLM avançando em organizações e equipes inteiras, há muita gente — talvez a maioria — que usa LLM todos os dias mas nunca chegou perto de algo técnico como um harness

    Para essas pessoas, o comportamento descrito aqui é um grande problema

  • Meio relacionado, mas eu queria ver um harness que usasse ed como ferramenta padrão de leitura/edição de arquivos. Metade do bash que o Claude executa já parece sed mesmo, então talvez fosse útil ter estado persistente em ed

    O que fazer quando um editor completo consome largura de banda^H tokens demais? Use o editor padrão ed

  • Isso está mais para um espantalho do trabalho com LLM

    Em tarefas de edição, só se deveria permitir comandos de edição programáticos, e o texto não deveria passar pelo LLM. O LLM deveria analisar o texto e, com base no feedback, emitir comandos para atingir o objetivo

  • No HN há uma tendência de interpretar os resultados da forma mais negativa possível, porque isso parece uma ameaça ao próprio trabalho e à identidade das pessoas

    Na verdade, se você pedir a uma pessoa para ler um documento, incorporar mudanças e depois ditar o documento inteiro de novo, ela pode facilmente ir pior do que uma degradação de 25%. É possível um humano chegar a 0% de degradação, claro, mas só se tiver memorizado o documento após recebê-lo centenas de vezes. O equivalente disso num LLM é treinamento; se você treinar o LLM com o documento, ele pode ficar equivalente à edição feita por alguém que o memorizou

    Mas isso não é o ponto principal. Como LLMs têm semelhanças com humanos, o harness deve ser projetado para que eles editem por meio de busca e mudanças cirúrgicas, como uma pessoa faria. Todo agente de código faz isso, então este artigo não é muito relevante

  • Seja por restrições de recursos ou por simplificação, é uma pena que artigos assim acabem perdendo valor por causa de metodologias difíceis de entender

• Como venho dizendo há tempos, qualquer texto que receba uma camada de tinta de IA perde qualidade, e isso se acumula a cada repetição

  O nome de que mais gosto para isso é “ablação semântica”: https://www.theregister.com/software/2026/02/16/semantic-abl...

  • Eu costumo chamar isso de regressão à inteligência média
  • Fico curioso se “a cada repetição” quer dizer repetir dentro da mesma sessão ou fazer isso de novo em sessões novas ou janelas de contexto novas

• A ideia é que “delegação exige confiança. É preciso esperar que o LLM execute a tarefa fielmente sem introduzir erros no documento”, e esse é exatamente o motivo de um harness com dezenas de arquivos Markdown e ritual de prompt não funcionar como a propaganda diz. Na prática, isso chega perto de uma pseudociência chamada engenharia de agentes

  No fim, engenharia de agentes é quase a mesma coisa que a tal engenharia de prompts, só que agora os prompts estão espalhados por dezenas de arquivos e diretórios Markdown

• É uma das coisas menos surpreendentes que li recentemente sobre LLMs

  LLMs são parecidos com o meme do JPEG. Cada vez que você salva como JPEG, a qualidade cai um pouco até ficar irreconhecível

  Só que, no caso dos LLMs, o ponto de partida é a intenção. A cada passagem por um LLM, a intenção se degrada, e em algo como um artigo científico preciso, nuances sutis e precisão vão se perdendo aos poucos no processo de reformulação

  LLMs são máquinas de regressão à média. Quanto mais o contexto ou a carga de trabalho atual se afastam do que estava na distribuição de treinamento, maior a tendência de puxar tudo para um estado de equilíbrio abstrato e homogêneo

  • Eu certamente já vivi isso programando com LLM. Depois de acelerar bastante em trabalho de funcionalidade, mesmo achando que fui cuidadoso, mais tarde eu olho um pedacinho de código com atenção e penso “meu Deus” com frequência

    Depois disso, preciso gastar algumas horas revisando tudo de novo e corrigindo com cuidado o que não ficou como eu queria, o que eu deixei ambíguo e o que foi efeito de alguma mania estranha do LLM

    A qualidade do código em si importa, mas o que me preocupa é exatamente esse problema de compressão iterativa. Se a base de código estiver limpa e meu modelo mental atualizado, o LLM pode ajudar a acelerar o trabalho de funcionalidade e ainda deixar o código num estado aceitável. Mas, quando o LLM começa a sujar a base de código, erros e mal-entendidos passados vão se acumulando, e ele passa a ter mais chance de errar cada vez mais coisas. Por isso eu só fico tranquilo de usar o LLM de novo depois de “restaurar” a base ao estado correto

  • O caso em que esse resultado é realmente interessante e relevante é quando um agente de código divide um arquivo-fonte grande em vários arquivos menores. Opus e Claude Code tentam recitar de memória trechos longos do código-fonte e colocá-los nos novos arquivos, em vez de usar operações como copiar/colar, como uma pessoa faria

    Mover arquivos é um pouco mais fácil. Às vezes o LLM também tenta recontar um arquivo de memória, mas se você mandar usar git mv e corrigir os erros do compilador, em geral ele se sai bem

    Já edições comuns normalmente funcionam bem com um modelo razoável e uma configuração de ferramentas decente. Até o Qwen3.6 27B dá conta disso. E alterações in-place ainda permitem revisar mudanças inesperadas com git diff

  • Existe até uma brincadeira infantil que mostra isso: https://en.wikipedia.org/wiki/Telephone_game

  • Um colega descreve LLMs como uma “camada de besteira”. Não é uma crítica totalmente depreciativa; a ideia é enfatizar que, toda vez que você passa algo por um LLM, o que sai do outro lado pode não corresponder ao que você espera ou quer

    É como ouvir, num bar, alguém meio bêbado repassar uma informação online que diz ter visto em algum lugar. Pode até estar certo, mas o risco de não estar é bem alto

    Por exemplo, você não deveria usar LLM para coletar dados via API e gerar relatórios. Isso significa passar dados determinísticos por uma camada de besteira, então o resultado não é confiável. É melhor usar LLM para escrever código que produza saídas determinísticas a partir de dados determinísticos

    Já vi colegas mandarem o LLM resumir dados determinísticos vindos de APIs, e os relatórios saírem tão errados quanto certos. Dependendo do que você estiver analisando, isso pode ser um risco desastroso

  • Passei por isso ao editar currículo. O LLM remove tudo o que me diferencia de um monte de engenheiros juniores medianos com experiência mediana. Tudo o que é especial, único ou diferente acaba substituído por frases genéricas

    Claro que eu não usei o resultado, mas foi extremamente frustrante ver o LLM insistir que aquilo era melhor do que o original

    Para currículo, o LLM foi muito mais útil quando usado em pedaços bem pequenos, por exemplo para sugerir ajustes em uma frase ou em três frases

• O problema é que pedimos coisas demais aos LLMs. Agentes deveriam ser projetados para usar o LLM como a camada mais fina possível para traduzir intenção em linguagem natural em um processo determinístico, minimizando ao máximo as idas e voltas com o LLM

  • Isso fica claro para qualquer um que tente fazer algo minimamente complexo. Se você montar um pipeline que combine fluxo de pré-processamento, direcionamento semântico de alvos e chamadas mínimas de contexto com a API de LLM, dá para obter uma etapa de automação poderosa

    Quando combinado com uma etapa separada de validação, o LLM deixa de ser um brinquedo e vira uma ferramenta útil

  • Só vira um processo automatizado de verdade quando nem pessoas entram nesse loop iterativo

• Normalmente instruo agentes a tratar a redação de documentos apenas como a etapa final de renderização. LLMs são muito bons em reunir e entrelaçar conhecimento disperso, então prefiro armazenar o conhecimento como ideias e fatos combináveis

  O que funcionou bem na prática foi dar ao agente um diretório e pedir que criasse um arquivo Markdown independente para cada fato ou descoberta encontrada. Também peço que cada arquivo tenha metadados no topo para facilitar busca

  Isso separa a maior parte do trabalho, que antes era uma mistura confusa de “pesquisar e salvar repetidamente já no formato final do documento”, em tarefas mais coesas: “pesquisar fatos e descobertas que ajudem o documento” e “montar o documento”

  Não é uma solução completa, mas, assim como no trabalho humano, a reutilização das descobertas melhora bastante

• Isso também não se aplica a humanos? É justamente por isso que crianças brincam de “telefone sem fio” para ver como a mensagem se corrompe. A solução é fornecer uma única fonte da verdade

• Estou criando ferramentas para combater esse tipo de degradação: https://github.com/JigSpec/JigSpec

• Gostei muito da metodologia de avaliação aqui. Eles testam a fidelidade fazendo uma cadeia de etapas reversíveis ir e voltar

  Achei impressionante que modelos de ponta acumulem erros mesmo em tarefas que, à primeira vista, parecem fáceis para um computador lidar

  Fico curioso se o resultado mais forte em Python é apenas um artefato de uma avaliação focada em Python, se também se estende a outras linguagens gerais comuns e se tem relação com algum aspecto específico do processo de treinamento

• Em grande parte, já sabíamos que os modelos não fracassam por causa de muitos errinhos, por “mil cortes”, e sim por falhas catastróficas: em algumas rodadas eles reconstroem quase perfeitamente, e em outras perdem de uma vez 10 a 30 pontos ou mais

  Da mesma forma, a degradação de modelos mais fracos vem sobretudo da exclusão de conteúdo, enquanto a dos modelos de ponta vem da corrupção do conteúdo. É por isso que ficamos mexendo em coisas como harness e temperatura