Teste da agulha no palheiro: o que ele realmente prova sobre contexto longo?

Um modelo achar uma frase escondida no meio de 1 milhão de tokens virou o print favorito dos anúncios de janela grande

Fala aí, beleza? Sempre que sai modelo novo com janela absurda, aparece aquele gráfico verdinho quase todo preenchido, e a mensagem implícita é "joga teu projeto inteiro aqui dentro que ele entende tudo"

Só que esse gráfico é o resultado do teste da agulha no palheiro, e ele mede uma coisa bem específica

Entender QUAL coisa é exatamente o que separa expectativa de frustração na hora de jogar um repositório inteiro no contexto e ver o assistente se perder

Como funciona o teste da agulha no palheiro, passo a passo do método:

O teste Needle in a Haystack foi criado e publicado por Greg Kamradt, no repositório LLMTest_NeedleInAHaystack

A descrição oficial do projeto é direta ao ponto: "Doing simple retrieval from LLM models at various context lengths to measure accuracy"

Repara na palavra simple retrieval, ela já entrega o jogo

O método é simples de entender, e é mais ou menos assim:

1. Pega um texto longo, o palheiro, e insere nele um fato aleatório que não tem nada a ver com o resto, a agulha
2. Varia a profundidade da inserção, ou seja, o fato entra lá no comecinho, no meio, no fim, e assim por diante
3. Varia o comprimento total do contexto, repetindo a mesma medição em janelas cada vez maiores
4. Pergunta pro modelo qual é o fato e registra a acurácia da recuperação

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

O erro comum aqui é achar que a pergunta é aberta

Não é. O modelo não precisa interpretar, comparar nem concluir nada, ele só precisa devolver um fato que está literalmente escrito ali dentro

O resultado costuma ser lido em grade: profundidade num eixo, comprimento no outro, cor indicando se achou ou não

Aí bate a vontade de olhar a grade verdinha e concluir que o modelo "leu tudo"

Existe também uma versão do teste mantida pela Arize AI, nos repositórios Arize-ai/LLMTest_NeedleInAHaystack e Arize-ai/LLMTest_NeedleInAHaystack2, separada do repositório original do Greg

Vale saber disso porque quando alguém fala "rodamos o NIAH", nem sempre é o mesmo código rodando 🙂

Por que 99,7% de recall em 1 milhão de tokens impressiona menos do que parece:

O relatório técnico do Gemini 1.5 trouxe um dos números mais citados dessa história: 99,7% de recall em 1 milhão de tokens

E não parou aí: 100% em 530 mil tokens e 99,2% em contextos de 10 milhões, em texto, vídeo e áudio

É um resultado real e é tecnicamente impressionante, sem ironia

Mas presta atenção no que a tarefa cobra: achar UM fato plantado

Não é conectar dez arquivos, não é rastrear uma variável que nasce num módulo e morre em outro, não é somar coisas espalhadas

É recuperar

E tem um detalhe que deixa o teste bem mais difícil quando você mexe nele: a similaridade entre a agulha e o palheiro

A Chroma, no relatório Context Rot, estendeu o teste original para casos de correspondência semântica em vez de só lexical, e também variou o conteúdo do palheiro

Quando a agulha se mistura semanticamente ao texto ao redor, o modelo tem mais dificuldade de extrair ela

Ou seja: a agulha clássica é uma frase que destoa de tudo

No teu código, a "agulha" é uma função parecida com outras quarenta funções parecidas

Sente a diferença? 😀

O modelo achou a agulha, mas se perdeu no meu repositório: por que isso acontece

O sintoma é sempre o mesmo

Você cola um monte de arquivo, pede uma coisa pontual e ele acerta em cheio, cita o trecho certinho

Aí você pede algo que exige cruzar informação espalhada, e ele começa a inventar, esquecer arquivo, contradizer o que ele mesmo tinha citado duas mensagens antes

A causa 1: lost in the middle

O artigo Lost in the Middle: How Language Models Use Long Contexts, de Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni e Percy Liang, publicado na Transactions of the Association for Computational Linguistics, vol. 12, p. 157 a 173, documenta um padrão incômodo

O desempenho é maior quando a informação relevante está no começo ou no fim do contexto, e cai bastante quando ela está no meio

Isso foi analisado em QA multi documento e em recuperação chave valor

Traduzindo pro teu dia a dia: a posição da informação dentro do prompt importa, e o meio é a zona de sombra

A causa 2: o input crescendo cobra o seu preço

O relatório Context Rot, da Chroma, avaliou 18 modelos, fechados e de pesos abertos, e concluiu que o desempenho cai de forma NÃO uniforme conforme o input cresce

Não uniforme é a parte importante da frase

Não é uma reta previsível onde você calcula "ok, com o dobro de tokens perco tanto", é irregular

Na prática isso significa que tu não consegue calcular a degradação de cabeça, tu descobre que passou do ponto quando a resposta já veio errada

E aí as duas causas se somam: quanto maior o input, mais informação boa acaba soterrada longe das pontas do contexto

A solução: encolher o palheiro em vez de confiar na janela

A saída prática não é romântica, é operacional: mandar menos coisa, e mandar a coisa certa

O Claude Code tem comandos embutidos justamente pra isso, e estão documentados nos slash commands:

• /compact reduz o histórico da conversa resumindo mensagens antigas e preservando o contexto importante
• /clear zera a conversa, contexto vazio, começo limpo
• /context, /usage e /help também estão entre os comandos disponíveis

O erro comum aqui é ficar arrastando uma sessão de três horas achando que "o modelo já conhece o projeto"

Ele não conhece, ele tem um histórico gigante onde a informação boa foi parar no meio

A Anthropic também documenta uma compactação automática de contexto como recurso da plataforma, acionada ao se aproximar do limite da janela

E se você quiser sair do achismo e medir no seu próprio material, o toolkit para replicar os resultados do Context Rot é público, no repositório chroma-core/context-rot

Agulha no palheiro, RULER, MRCR e SWE-bench Verified: o que cada teste mede

A maneira mais rápida de calibrar expectativa é ver os quatro lado a lado

O RULER tem uma sacada que eu acho MUITO útil: ele define "comprimento efetivo" como o maior tamanho de janela em que o modelo atinge pelo menos 85% de acerto

Ou seja, janela anunciada e janela que funciona são duas colunas diferentes da planilha

O dataset do OpenAI MRCR é público no Hugging Face, e a própria OpenAI declara no card que ele foi "inspired by the MRCR eval first introduced by Gemini", ampliando a dificuldade da tarefa original

Já o SWE-bench Verified nasceu em colaboração com a OpenAI pra corrigir problemas do SWE-bench original, tipo enunciado subespecificado e teste excessivamente específico

Quando o resultado do teste importa para o seu trabalho e quando ele é irrelevante

Bora aterrissar isso em cenários reais, porque aqui a coisa fica prática

A regra de bolso é olhar pra tarefa que tu vai pedir e perguntar: isso é recuperar um pedaço, ou é raciocinar em cima de vários pedaços?

Cenário 1: colar um contrato, um log gigante ou uma transcrição e pedir um trecho específico

Aqui o teste da agulha no palheiro diz algo genuinamente útil, é quase exatamente a tarefa medida: recuperação, a primeira categoria do RULER

É o mesmo espírito de quando você precisa revisar textos longos sem perder o contexto e quer só o pedaço certo de volta

Cenário 2: pedir uma refatoração que atravessa vários módulos

Aqui o teste não te ajuda em nada

A tarefa é rastreio multi salto: o modelo precisa seguir uma cadeia, arquivo puxando arquivo, e isso é outra categoria do RULER

Cenário 3: pedir um resumo que exige juntar contagens espalhadas

Tipo "quantos endpoints existem e quais não têm teste"

Isso é agregação, e agregação não é recuperação, é juntar muitos pedaços pra formar uma resposta que não está escrita em lugar nenhum do palheiro

Cenário 4: investigar um bug cuja pista caiu no meio do contexto

Esse é o caso mais cruel, porque combina QA com o efeito documentado no Lost in the Middle: informação no meio tem desempenho pior que informação no começo ou no fim

Se a pista foi parar na barriga de um prompt gigante, não é azar, é padrão conhecido

Solução preguiçosa e eficiente: reordenar

Coloca o trecho crítico no começo ou no fim do prompt, e para de contar com a sorte

Como ler anúncios de janela de 1 milhão de tokens com pé no chão

Quando cair um gráfico de contexto longo na tua timeline, roda esse checklist mental:

1. Qual tarefa foi medida? Recuperação simples? Multi salto? Agregação? A palavra "contexto longo" cobre coisas MUITO diferentes
2. Em qual profundidade? Resultado bom só nas pontas do contexto e resultado bom no meio inteiro são conversas distintas
3. Tem número de comprimento efetivo? Pelo critério do RULER, comprimento efetivo é onde o modelo mantém 85% ou mais de acerto
4. A janela anunciada foi testada? No estudo do RULER, todos os modelos avaliados anunciavam janela de 32 mil tokens ou mais, e só metade deles conseguiu lidar efetivamente com 32 mil segundo o limiar do benchmark

Esse item 4 é o meu favorito, e é o que eu recomendo guardar

Sobre o estado atual do lado da Anthropic, a documentação informa que a janela de contexto pode chegar a 1 milhão de tokens dependendo do modelo

O jeito saudável de encarar isso: janela grande é orçamento disponível, não é garantia de compreensão

Você tem mais espaço pra colocar coisa, o que não significa que colocar tudo seja a melhor jogada

Vale confiar em um modelo só porque ele passa no teste da agulha no palheiro?

Veredito honesto: o teste é um bom piso, não é um teto

Passar nele elimina um tipo de falha grosseira, aquela de o modelo simplesmente ignorar metade do que você mandou

Reprovar nele é sinal claro de problema, e aí nem precisa investigar muito mais

Mas, como a própria Chroma coloca, o benchmark "measures a narrow capability: lexical retrieval"

Escolher modelo pra trabalhar em cima de repositório olhando só pra grade verdinha é decidir com meia informação

O combo que faz sentido é ler RULER, MRCR e SWE-bench Verified junto: um te dá as quatro categorias de tarefa, o outro te dá o caso das agulhas idênticas, e o terceiro te dá issue real com patch que precisa passar em teste

E aqui vai o disclaimer que eu acho justo deixar explícito: este post não traz teste próprio, é leitura das fontes públicas citadas ao longo do texto

Se alguém te vender ranking de setembro de 2026 sem link pra página de dados viva, desconfia…

Conclusão

Achar a agulha é recuperar

Entender o repositório é raciocinar

São coisas diferentes, e o teste da agulha no palheiro mede a primeira com muita competência e a segunda nem um pouco

Próximo passo acionável, se você curte medir em vez de acreditar: abre o repositório original do Greg Kamradt ou o toolkit do Context Rot e roda a medição no TEU material, com o teu tipo de documento e o teu tipo de código

E no dia a dia, trata contexto como recurso escasso: /compact quando a conversa esticar, /clear quando o assunto mudar, /context pra saber onde você está

Palheiro menor, agulha mais fácil 😀

até o próximo post!