Por que o modelo ignora o que está no meio do contexto?

Lost in the middle é a queda de desempenho quando a informação relevante está no meio da entrada em vez das pontas. O nome vem de um trabalho de 2023 que mediu o efeito com o conteúdo fixo e só a posição variando: o acerto é mais alto no começo e no fim, e cai no meio. Aparece inclusive em modelos vendidos como de contexto longo.

O resultado incomoda porque contraria a intuição de que uma janela grande é um espaço homogêneo. Ela não é. Onde você coloca o trecho importa, e importa mais do que a maioria dos ajustes de redação que um time faz antes de descobrir isso. É por essa razão que a ordem das instruções muda o resultado e que estruturar um prompt longo é uma decisão de engenharia, não de estética.

O efeito é uma das causas do fenômeno mais amplo de degradação com o acúmulo de contexto. Não é o mesmo problema, mas é o mais bem medido dos dois.

A curva em U

O desenho do experimento é o que dá força ao resultado, então vale detalhar.

Os autores montaram uma tarefa de perguntas e respostas sobre múltiplos documentos: uma pergunta real do Google, extraída do NaturalQuestions, e um conjunto de passagens da Wikipédia em que exatamente uma contém a resposta e as outras são distratoras recuperadas por um sistema de busca. Aí variaram uma coisa só — a posição da passagem que responde — mantendo todo o resto idêntico¹.

Com 20 documentos no contexto, o GPT-3.5-Turbo perdeu mais de 20 pontos entre a melhor e a pior posição. E o número que fecha o argumento: nos arranjos de 20 e 30 documentos, o desempenho na pior posição ficou abaixo do desempenho do mesmo modelo sem documento nenhum, que era de 56,1%. Ter a resposta na janela, na posição errada, foi pior que não ter a resposta.

Para contexto, o mesmo modelo com apenas a passagem certa, sem distratoras, chegava a 88,3%. A distância entre 88,3% e algo abaixo de 56,1% é o preço da posição somado ao preço dos distratores.

Duas observações do mesmo trabalho fecham as saídas fáceis. Modelos de contexto estendido não se saíram melhor que suas versões não estendidas quando a entrada cabia nos dois: as curvas ficaram praticamente sobrepostas. E o GPT-4, avaliado em um subconjunto, teve desempenho absoluto mais alto que todos e ainda assim desenhou a mesma curva em U¹.

Só a posição muda

Vale insistir nesse ponto porque ele é o que torna o resultado acionável.

Não se trata de o modelo ter menos informação, nem de o contexto ser mais longo, nem de a pergunta ser mais difícil. As três linhas da figura têm os mesmos vinte documentos, o mesmo número de tokens e a mesma pergunta. A única diferença é a ordem em que os documentos foram concatenados.

Num sistema de recuperação, essa é uma variável que você controla de graça. O ranqueador já devolve os trechos ordenados por relevância, e a decisão de como posicioná-los na janela costuma ser feita por acidente — pela ordem em que o laço percorre a lista.

Uma nota de arquitetura que ajuda a entender o mecanismo: modelos encoder-decoder se mostraram relativamente robustos à posição, mas só dentro do comprimento de sequência que viram no treino. Avaliados em sequências mais longas que isso, eles também desenham a curva em U¹. Os modelos que todo mundo usa hoje são decoder-only, e neles cada token só enxerga o que veio antes — o que torna a posição um fator estrutural, não um detalhe de implementação.

Como o efeito aparece na sua aplicação

O sintoma raramente chega rotulado como “problema de posição”. Chega de outras três formas.

A resposta certa estava lá e o modelo não usou. É o caso mais frustrante de depurar, porque o log da busca mostra o trecho correto entre os recuperados. Você confere, o conteúdo está certo, e conclui que o modelo é ruim. Ele leu, mas leu com pouca atenção, porque o trecho estava na quarta posição de seis, no meio de uma janela que já tinha histórico.

Aumentar o top-k piorou o sistema. Alguém sobe de cinco para quinze trechos “por segurança” e a taxa de acerto cai. Faz sentido: os dez novos entram majoritariamente no meio, empurram o que era bom para longe das pontas, e o que entrou é quase-relevante o bastante para competir.

O mesmo caso acerta e erra dependendo do dia. Se o número de documentos recuperados varia por consulta, a posição relativa do trecho certo varia junto. O resultado é uma taxa de acerto que oscila sem que nada no código tenha mudado, e uma equipe convencida de que o provedor mexeu no modelo.

Os três se diagnosticam com a mesma instrumentação: registre, para cada resposta avaliada, em que posição da janela estava o trecho que deveria ter sido usado. Duas semanas de log respondem se o seu problema é de posição, e é um dos poucos diagnósticos de contexto que dá um gráfico limpo.

Por que acontece

A explicação não é única e o campo ainda não fechou. Três linhas de evidência se combinam.

Os tokens iniciais atraem atenção desproporcional. Um trabalho de 2023 descreveu o que chamou de sumidouro de atenção: os primeiros tokens da sequência recebem pontuações de atenção altas mesmo quando não são semanticamente importantes. Os autores mostraram isso ao investigar por que a atenção em janela deslizante quebra quando os primeiros tokens saem do cache — preservar apenas esses tokens iniciais recupera boa parte do desempenho². É um mecanismo plausível para a ponta esquerda da curva.

Existe um viés de recência que puxa para o outro lado. Um trabalho do mesmo ano mediu que informação relevante situada mais cedo no contexto recebe menos atenção em média, e usou isso para propor reordenar os documentos pela atenção que recebem, colocando os mais atendidos por último³. Junte os dois efeitos e o meio fica sem defensor: não é começo nem é fim.

O viés é posicional, não semântico. A medição mais direta é de 2024. Os autores conectaram o lost in the middle a um viés intrínseco de atenção em forma de U: os tokens do começo e do fim recebem mais atenção independentemente da relevância deles. A partir disso construíram um mecanismo de calibração que desconta o componente posicional, e relataram ganho de até 15 pontos percentuais sobre métodos existentes em tarefas de geração aumentada por recuperação⁴.

Uma hipótese que o trabalho original testou e descartou merece registro, porque ela é a primeira que ocorre a todo mundo: não é culpa do instruction tuning. Como a instrução costuma aparecer no começo dos dados de ajuste, seria razoável supor que o modelo aprendeu a olhar para lá. Mas o modelo base, antes de qualquer ajuste, também desenha a curva em U. O ajuste apenas reduziu a distância entre a melhor e a pior posição, de cerca de 10 pontos para algo perto de 4¹.

E há uma dependência de escala que raramente é citada. Avaliando a família Llama-2 em três tamanhos, os autores encontraram a curva em U só nos modelos de 13B e 70B; o de 7B era puramente enviesado para o fim¹. O viés de primazia parece ser algo que emerge com escala, e o de recência já está lá desde sempre.

O que não resolve

Recuperar mais documentos. É a reação instintiva e ela piora a situação. No mesmo estudo, passar de 20 para 50 documentos recuperados melhorou cerca de 1,5% no GPT-3.5-Turbo e 1% no Claude-1.3, com o contexto mais que dobrando de tamanho¹. O desempenho satura muito antes da cobertura da busca.

Repetir a pergunta antes e depois dos documentos. Essa técnica funciona espetacularmente numa tarefa e quase nada na outra. Na recuperação sintética de chave-valor, os modelos passaram a acertar quase tudo, contra um pior caso de 45,6% sem ela. Nas perguntas sobre múltiplos documentos, ela melhorou levemente o caso em que a informação está no começo e piorou levemente os demais¹. Vale testar, não vale assumir.

Esperar o próximo modelo. Em 2025, um benchmark atacou um viés dos testes anteriores: quando a pergunta e a passagem compartilham as mesmas palavras, o modelo resolve por casamento literal e o teste fica fácil demais. Com sobreposição lexical mínima, 11 de 13 modelos que anunciam pelo menos 128 mil tokens caíram abaixo de metade do próprio desempenho em contexto curto ao chegar em 32 mil. O GPT-4o, um dos melhores da leva, foi de 99,3% para 69,7%⁵. Os autores atribuem a queda à dificuldade que a atenção enfrenta em contextos longos quando não há casamento literal para se apoiar.

Confiar no teste de agulha no palheiro. Um modelo pode acertar a agulha em um milhão de tokens e falhar em 32 mil quando a tarefa exige agregar informação espalhada. Foi o que o RULER mediu em 17 modelos e 13 tarefas: metade dos que anunciavam pelo menos 32 mil tokens não sustentou desempenho aceitável nesse comprimento⁶. O teste simples de recuperação quase não distingue os modelos, e por isso ele é o mais divulgado.

Trocar o ranqueador e parar por aí. Um reranker melhor coloca o trecho certo em primeiro lugar com mais frequência, o que ajuda de verdade. Mas ele não decide onde o primeiro lugar vai parar dentro da janela, e a resposta padrão das bibliotecas é “no começo da lista de documentos”, que num contexto com histórico pode ser exatamente o meio da sequência que o modelo lê. Ranquear e posicionar são duas decisões, e só uma delas costuma ter dono.

O que fazer

1. Corte antes de ordenar. Cinco trechos bem escolhidos ganham de vinte quase sempre. O ganho de reduzir o top-k costuma ser maior que o de qualquer reordenação.
2. Ponha o mais provável nas pontas. Se o ranqueador dá uma pontuação, coloque o primeiro colocado no fim, logo antes da pergunta, e o segundo no começo. O meio fica com o resto.
3. Repita a pergunta depois dos documentos. É barato, ajuda em algumas tarefas e não custa quase nada em tokens. Meça antes de adotar como regra.
4. Delimite os blocos. Cabeçalho com origem e data em cada trecho ajuda o modelo a saber o que está lendo e ajuda você a auditar de onde a resposta saiu.
5. Meça o seu caso com o teste de três posições. Pegue vinte perguntas reais, monte cada uma com o trecho que responde no começo, no meio e no fim, e compare o acerto. Uma tarde de trabalho e você tem a magnitude do efeito no seu modelo, com a sua tarefa.
6. Refaça a medição a cada troca de modelo. A curva muda de forma e de profundidade entre famílias, e a sua ordenação foi calibrada para a anterior.

O passo 5 é o que substitui a discussão pela evidência. A literatura diz que o efeito existe e dá a ordem de grandeza; ela não diz quanto ele custa no seu pipeline, com o seu ranqueador e o seu modelo. Esse número é seu e ninguém vai medir por você.

Footnotes

1. Liu et al. (2023) variaram a posição da passagem que responde em perguntas sobre múltiplos documentos e em recuperação de chave-valor, medindo curva em U, queda abaixo do desempenho sem documento, ausência de ganho em modelos de contexto estendido e persistência do efeito em modelos base. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. Xiao et al. (2023) descreveram o sumidouro de atenção: os primeiros tokens recebem pontuação de atenção alta mesmo sem importância semântica, e preservá-los no cache recupera o desempenho da atenção em janela deslizante. ↩

3. Peysakhovich e Lerer (2023) mediram que informação relevante situada mais cedo recebe menos atenção em média e propuseram reordenar os documentos pela atenção recebida. ↩

4. Hsieh et al. (2024) conectaram o efeito a um viés de atenção em forma de U independente da relevância e propuseram uma calibração que desconta o componente posicional, com ganho de até 15 pontos percentuais em tarefas de recuperação aumentada. ↩

5. Modarressi et al. (2025) construíram testes com sobreposição lexical mínima entre pergunta e passagem, forçando associação latente, e mediram queda grande a partir de 32 mil tokens em modelos que anunciam 128 mil ou mais. ↩

6. Hsieh et al. (2024) avaliaram 17 modelos em 13 tarefas, incluindo rastreamento em múltiplos saltos e agregação, e encontraram queda acentuada bem antes do limite anunciado. ↩