1 pontos por GN⁺ 2025-06-22 | 1 comentários | Compartilhar no WhatsApp
  • Modelos de linguagem de grande porte (LLMs) são bons em encontrar informações específicas em entradas longas, mas têm limitações para identificar informações ausentes
  • O novo benchmark AbsenceBench avalia a capacidade dos LLMs de detectar informações omitidas em 3 domínios: sequências, poesia e PRs do GitHub
  • Até mesmo o modelo mais recente, Claude-3.7-Sonnet, apresenta desempenho baixo, com apenas 69,6% de F1-score em um contexto de 5 mil tokens
  • Isso ocorre por causa de uma limitação do mecanismo de atenção (attention) baseado em Transformer, que não funciona de forma eficaz sobre os “espaços em branco” de um documento
  • O estudo mostra a diferença intrínseca de dificuldade entre detecção de informação inserida e detecção de informação ausente em LLMs

Visão geral

  • Modelos de linguagem de grande porte (LLMs) melhoraram bastante sua capacidade de encontrar informações em documentos longos
  • O teste ‘Needle in a Haystack (NIAH)’ avalia a capacidade de encontrar informações surpreendentes em entradas extensas, e os LLMs têm desempenho excelente nesse cenário
  • Mas saber se um LLM consegue encontrar informações claramente ausentes é uma questão diferente
  • Para isso, foi proposto o benchmark AbsenceBench, que remove explicitamente partes de um documento e pede ao modelo para identificar o que está faltando

Explicação do benchmark AbsenceBench

  • O AbsenceBench avalia a capacidade do modelo de detectar omissões em 3 domínios: poesia, sequências numéricas e Pull Requests (PRs) do GitHub
  • O documento original e uma versão modificada com partes removidas intencionalmente são fornecidos simultaneamente ao LLM, e então é avaliado se ele consegue identificar as informações ausentes
  • Com comprimento médio de contexto de 5 mil tokens, ele se enquadra como um benchmark de ‘contexto intermediário’, mais curto que testes tradicionais de contexto longo

Principais problemas observados na avaliação

  • Foram avaliados 14 LLMs representativos (como GPT-4, Claude-3.7-Sonnet e Gemini-2.5-flash), e mesmo os modelos mais recentes apresentaram F1-score de cerca de 69,6%, um valor baixo
  • Embora os LLMs já estejam em nível ‘sobre-humano’ no teste NIAH, no AbsenceBench o desempenho despenca 56,9%
  • Quanto maior o comprimento do contexto, maior a queda de desempenho, especialmente no domínio de poesia
  • Mesmo com uso de inference-time compute, o desempenho sobe apenas 7,9%, enquanto o consumo de tokens de chain-of-thought é, em média, 3 vezes maior
  • Em contrapartida, quanto menor a taxa de omissão (omission rate), pior é, de forma inesperada, o desempenho dos LLMs

Causas e análise aprofundada

  • O mecanismo de self-attention baseado em Transformer tem dificuldade para focar em ‘informações ausentes’ (lacunas), porque, pela estrutura de atenção baseada em chaves, é difícil rastrear algo que não está presente
  • Durante os testes, ao adicionar uma string placeholder nas partes ausentes, o desempenho subiu em média 35,7%

Estrutura e exemplos do AbsenceBench

  • Cada tarefa é definida da seguinte forma
    • São fornecidos o documento original (Dorig) e a versão modificada (Dmodified)
    • Remove-se p% dos elementos de Dorig para criar Dmodified, e o LLM deve comparar os dois para produzir o conjunto de respostas com o que foi omitido (Domit)
  • Exemplos dos três domínios:
    • Poesia: seleção de poemas do Gutenberg Poetry Corpus, com omissão aleatória de linhas
    • Sequências numéricas: omissão de números com certa probabilidade em sequências geradas aleatoriamente
    • GitHub PRs: remoção aleatória de algumas linhas alteradas em arquivos diff de PRs populares de open source

Exemplo de template de avaliação (domínio de poesia)

  • Prompt de sistema: “Um aluno recitou um poema, mas algumas linhas podem estar faltando. Encontre exatamente quais linhas foram omitidas.”
  • São fornecidos tanto o poema original quanto a versão recitada, e pede-se como resposta apenas as linhas que realmente faltam

Principais resultados experimentais

  • Foram feitos experimentos variando comprimento de documento, taxa de omissão e outros fatores por domínio
  • Em GitHub PRs, poesia e sequências numéricas, os LLMs não conseguem identificar completamente as partes ausentes
  • Principal diferença entre NIAH e AbsenceBench: o NIAH exige atenção a uma chave/informação existente, enquanto o AbsenceBench exige atenção a uma ‘parte inexistente’, o que o torna estruturalmente mais difícil

Conclusão e implicações

  • O AbsenceBench mostra que os LLMs ainda são frágeis diante da pergunta ‘o que está faltando?’
  • Isso sugere que é preciso cautela com a confiabilidade do uso de LLMs como avaliadores na prática (por exemplo, LLM-as-a-Judge)
  • São necessárias novas abordagens para superar essa fraqueza estrutural do design Transformer
  • O dataset e o código do AbsenceBench estão disponíveis publicamente e são propostos como ponto de partida para pesquisas sobre detecção de omissões em LLMs

Resumo das principais contribuições

  • Projeto e disponibilização de um novo benchmark para detectar elementos explicitamente omitidos em documentos de contexto intermediário (5 mil tokens)
  • Avaliação de 14 LLMs recentes, confirmando que detectar informação inserida é quase perfeito, mas detectar informação ausente continua sendo difícil
  • Mostra que até mesmo inference-time compute tem limites para melhorar o desempenho real
  • Verifica-se que o desempenho sobe bastante quando placeholders explícitos são inseridos nas partes ausentes
  • O AbsenceBench revela uma limitação fundamental do mecanismo de atenção dos Transformers

Composição do dataset AbsenceBench

  • Poetry: um poema é cortado em documentos de diferentes tamanhos, entre 100 e 1000 linhas, com omissões por linha
  • Numerical Sequences: o primeiro número é definido aleatoriamente, os números seguintes são arranjados segundo várias regras (crescente, decrescente, aleatório, com diferentes intervalos), com algumas omissões
  • GitHub PRs: em diffs de 10 a 200 linhas dos 20 repositórios mais populares, selecionam-se apenas as linhas alteradas e omitem-se algumas para refletir situações reais

Exemplos reais do benchmark

  • Exemplo de poesia
    • Original: “And so, to you, who always were / To me, I give these weedy rhymes / In memory of early times...”
    • Modificado: “And so, to you, who always were / In memory of early times...”
    • Resposta: “To me, I give these weedy rhymes”
  • Exemplo de sequência numérica
    • Original: 117, 121, 125, 129, 133, 137 ...
    • Modificado: 117, 125, 129, 133 ...
    • Resposta: 121, 137
  • Exemplo de GitHub PR
    • Algumas linhas alteradas do código no PR são omitidas

Aplicações e relevância prática

  • Na prática, isso está diretamente ligado à capacidade de detectar omissões em diffs de PR ou ausência de informações necessárias em documentos
  • Ao aplicar LLMs em automação de revisão/verificação, a detecção de omissões exige medidas complementares separadas

1 comentários

 
GN⁺ 2025-06-22
Comentários do Hacker News
  • Compartilhamento de uma experiência em que, após assistir a uma palestra de Gerald Sussman, a pessoa inseriu uma imagem do triângulo de Kanizsa no Claude e fez uma pergunta vaga para verificar se o Claude reconheceria o triângulo. Como o Claude reconheceu corretamente a imagem e até a resumiu, tentou novamente após girar a imagem em 90 graus. Porém, o Claude não conseguiu reconhecer a imagem e ainda errou a contagem dos elementos. O conteúdo descrito pelo Claude era composto por “quatro semicírculos parecidos com Pac-Man, dois triângulos pretos finos ou formas de seta e um fundo cinza-claro”

    • Previsão de que, no futuro, esse problema talvez possa ser resolvido adicionando ao processo de treinamento versões de todas as imagens rotacionadas em 90 graus

    • Compartilhamento da opinião de que, como o escopo do artigo está limitado a documentos de texto, o experimento com o triângulo de Kanizsa não se aplica diretamente à discussão em questão. Destaca-se que LLMs ainda estão pouco desenvolvidos em processamento de imagens. Explica-se que a maior parte dos recursos de visão entra no transformer como tokens após pré-processamento separado, mencionando exemplos de etapas como OCR, reconhecimento de padrões baseado em CNN, imagens em vários ângulos e ampliações

    • Aponta-se uma falta de compreensão sobre computação em si. São compartilhados links para discussões antigas no Hacker News relacionadas ao debate e para vídeos de palestras da Strange Loop: link, link

    • Opinião de que, se você mostrar a um LLM uma foto de um cachorro com 5 pernas, ele provavelmente não conseguirá identificar corretamente a quantidade de pernas

    • Como exemplo de generalização por abstração, menciona-se a capacidade humana de reconhecer imediatamente um triângulo quando inúmeros pontos estão dispostos nesse formato. A pessoa diz ter sentido que a essência da inteligência pode ser encontrada em exemplos simples como esse, defendendo que o significado de QI está justamente na capacidade de perceber padrões simples em meio a enorme complexidade. Também apresenta a visão de que, se esses pontos fossem na verdade vértices de um cubo de 10 dimensões levemente rotacionado, isso seria um padrão muito fácil dentro de um pensamento em 10 dimensões

  • Compartilhamento de um resumo da alegação dos autores do artigo de que até modelos recentes têm baixo desempenho quando precisam identificar informação ausente vendo simultaneamente a versão original e a modificada, e de que, pelo mecanismo de attention do Transformer, não é possível prestar atenção a tokens que já foram removidos

    • Na prática, a chave a ser encontrada está no texto original, então, se o modelo receber ambos como entrada, ele poderia prestar atenção a essa chave, segundo uma opinião apresentada. Do ponto de vista da attention,

      Original: {parte em comum} {parte removida} {parte final em comum}
      Modified: {parte em comum} {parte final em comum}
      

      e

      Original: {parte em comum} {parte final em comum}
      Modified: {parte em comum} {parte adicionada} {parte final em comum}
      

      não seriam casos tão diferentes. É proposta uma abordagem concreta dizendo que talvez fosse possível implementar, via RASP, um algoritmo do tipo: na etapa 1, localizar as posições dos tokens de Original/Modified; na etapa 2, calcular o valor médio dos tokens de cada um e obter a diferença; na etapa 3, determinar que o token mais próximo dessa diferença corresponde à {parte removida}/{parte adicionada}. Restaria apenas a questão de de qual lado subtrair a diferença. Se o modelo acerta adições mas não remoções, analisa-se que talvez ele conheça o princípio, mas tenha sido menos treinado por falta de dados de remoção

    • Aponta-se que os resultados experimentais com os modelos topo de linha mais recentes (OpenAI opus, o3, Gemini 25 pro etc.) não foram incluídos no artigo

    • Curiosidade sobre se modelos de visão talvez pudessem aprender isso por meio de foto negativa, rotação de imagem etc. Também se menciona a possibilidade experimental de um formato de perguntas e respostas de preencher lacunas, como em madlib

    • Como o desempenho varia entre os modelos, afirma-se que, agora que o benchmark e o interesse existem, é de se esperar melhora de desempenho daqui para frente. Há espaço claro para progresso

  • Argumenta-se que, pela própria estrutura do mecanismo de attention, é natural não conseguir encontrar partes ausentes não classificadas. Em problemas do tipo needle-in-a-haystack, há um alvo específico a encontrar, então a attention funciona bem; já em casos de omission, não se sabe o que está faltando, então é preciso comparar o contexto inteiro, algo para o qual as camadas de attention existentes têm limitações. Explica-se que isso é semelhante a problemas como ordenar listas longas

    • Como nos experimentos de busca por omission o LLM de fato recebe as informações necessárias (por exemplo, original e modificado), considera-se que isso seria um problema de ajuste do modelo, não uma limitação estrutural. Por exemplo, ao procurar omissões em artigos de ML, o cérebro compara artigos de ML entre si, e não com memórias irrelevantes como Star Wars ou Top Gear; portanto, entende-se que a redução de contexto permite um funcionamento eficiente
  • Embora ainda não tenha lido o artigo, a pessoa diz concordar com a explicação sobre as limitações do mecanismo de attention. Como não se sabe o que foi omitido, é difícil simplesmente encontrar isso, o que reforça a necessidade de comparar o contexto completo

  • Algumas críticas a uma nova forma de benchmark como a do AbsenceBench são consideradas válidas, mas o fato de esse tipo de tentativa estar acontecendo já é visto positivamente, como um passo rumo a algo melhor

  • Concordância parcial com a opinião dos autores de que, ao contrário dos humanos, os LLMs nem chegam perto de localizar omissões no contexto, mas também há dúvida sobre por que a arquitetura seria matematicamente menos adequada para isso. Curiosidade sobre o efeito de fine-tuning para esse tipo de tarefa. Menciona-se que o resultado de que entradas curtas com poucas omissões são mais difíceis também lembra uma limitação humana: perceber a ausência de uma ou duas palavras também pode ser difícil. Diz-se que é surpreendente que modelos de raciocínio tenham se saído melhor, mas ainda assim não tenham chegado a 100% de acerto. Aponta-se que, como mostra o artigo, esse é um problema facilmente resolvido por um programa simples. A pessoa acha interessante que o artigo sugira que há muitos aspectos da inteligência humana ainda não definidos formalmente, nos quais LLMs podem ser fracos

  • Procurar um diff literal de strings seria um caso de alocação excessiva de complexidade, parecido com pedir a um LLM para fazer cálculo aritmético. Observa-se que pode ser mais vantajoso usar raciocínio, por exemplo mandando o LLM listar o documento inteiro e comparar diretamente. Isso seria semelhante ao fenômeno em que problemas aritméticos são melhor resolvidos quando quebrados em etapas. Sugere-se que modelos com bom desempenho talvez usem arquitetura MoE (Mixture of Experts), e especula-se que o Gemini Flash também seja um modelo baseado em MoE

  • Se for permitido ao LLM um acesso “meta”, haveria a possibilidade de ele mesmo escrever e executar um script em Python para detectar omission

    • Porém, preocupa a possibilidade de o LLM não conseguir distinguir algoritmicamente quando deveria usar Python. Parte-se da premissa de que dar a instrução para sempre tentar usar código reduziria erros. Aponta-se que até problemas triviais podem ser difíceis para LLMs, e que esse tipo de fraqueza talvez também limite sua capacidade de programação
  • Expressa-se insatisfação com o benchmark específico. No exemplo de prompt, o modelo qwq-32b encontra perfeitamente o item omitted em um experimento com 3 itens. A pessoa acredita que ele também conseguiria resolver fielmente um caso com 100 itens, embora isso exija muito mais tokens. Argumenta-se que o limite de 5.000 tokens é muito baixo para um reasoning model e que, na prática, se forem repetidos mais lotes e processos de simplificação, ele sempre conseguirá encontrar corretamente. Propõe-se uma metodologia de tokenizar o documento inteiro e compará-lo repetidamente para obter a resposta. [Exemplo completo de prompt compartilhado]

    • De fato, a própria pessoa realizou um experimento com qwq-32b usando uma lista de 26 manchetes do HN da qual 3 foram removidas, e demonstrou experimentalmente que encontrou todas corretamente sem consumir 50 mil tokens. Link para o material do experimento

    • Critica-se que simplificar o problema para algo como contagem de números é uma pesquisa sem muito sentido, enfatizando que o verdadeiro objetivo do estudo é identificar áreas de limitação dos LLMs que não podem ser resolvidas com ordenação/classificação

  • Compartilhamento de uma experiência real em que a pessoa perguntou ao ChatGPT se a expressão “utter love” aparecia em Hamlet. O ChatGPT respondeu que havia verificado todas as falas de Hamlet e que a expressão não existia. Porém, ao pesquisar diretamente o texto original online, a pessoa a encontrou imediatamente. Quando esse trecho foi mostrado ao ChatGPT, ele reconheceu o erro, pediu desculpas e até forneceu novamente a fala inteira. Compartilha-se isso como uma experiência em que “no fim, a memória humana foi superior ao índice do ChatGPT”

    • Corrige-se que a resposta correta é Ato 2, Cena 1, e que o falante é Polonius

    • Reconhece-se que, sem loop de busca ou ferramentas, os LLMs têm recall muito fraco; até o modelo 4o falhou sem busca, e só com a função de search foi possível chegar à resposta correta. Daí se tira o insight de que a importância de “usar corretamente a ferramenta certa para o problema” tende a crescer cada vez mais

  • Sugere-se que LLMs conseguem detectar relativamente bem existência com base em input sensorial, mas têm dificuldade com absence (ausência), porque não há input sensorial correspondente. Para detectar isso, seria preciso um modelo de mundo muito forte e expectativas bem formadas. Propõe-se que esse tipo de tarefa neurológica de ordem superior talvez ainda seja uma capacidade exclusiva de organismos, e não de LLMs

    • Aponta-se que LLMs podem ter problemas de consistência por projeto, com parte do comportamento baseada em memorização simples e outros caminhos dependendo de correspondência avançada de padrões

    • Em comparação com pensamento em tempo real, observa-se que LLMs raciocinam com base em uma realidade “fixa e estática”, o que também revela uma limitação temporal

    • A detecção real de ausência está intimamente ligada à memória. Por exemplo, quando uma caneta que estava sobre a mesa desaparece, o cérebro reconhece a ausência ao comparar o input sensorial passado (a lembrança de ter visto a caneta) com a situação atual. Conclui-se que, neste momento, o thinking (pensamento) ainda é uma característica própria dos organismos