Accueil › Glossaire › Lost in the Middle

Lost in the Middle

« Lost in the Middle » désigne le phénomène selon lequel les grands modèles de langage (LLM) exploitent moins bien les informations situées au milieu d’un contexte long que celles placées au début ou à la fin, produisant une courbe de performance en U caractéristique.

La découverte : une courbe en U inattendue

En juillet 2023, Nelson F. Liu et ses co-auteurs publient un article qui va devenir l’un des plus cités dans le domaine du long contexte. Leur question est simple : les LLM qui acceptent des fenêtres de contexte de 4K, 16K, voire 100K tokens utilisent-ils réellement toute cette capacité de manière uniforme ? La réponse est non.

L’équipe teste plusieurs modèles (GPT-3.5-Turbo, GPT-3.5-Turbo 16K, Claude-1.3, Claude-1.3 100K, MPT-30B-Instruct, LongChat-13B 16K) sur deux tâches : le question-answering multi-document et la recherche de paires clé-valeur. Dans les deux cas, ils déplacent l’information pertinente à différentes positions dans le contexte (début, milieu, fin) et mesurent la précision du modèle.

Le résultat est frappant : la performance suit une courbe en U. Les modèles sont les plus précis quand l’information pertinente se trouve au tout début ou à la toute fin du contexte. Quand cette information est positionnée au milieu, la précision chute significativement, parfois de plus de 30 points de pourcentage. Ce biais positionnel affecte tous les modèles testés, y compris ceux spécifiquement conçus pour le long contexte.

Protocole expérimental

Tâche 1 : Question-answering multi-document

Les chercheurs utilisent le dataset NaturalQuestions-Open. Ils construisent des contextes contenant 10, 20 ou 30 documents (passages Wikipedia), dont un seul contient la réponse à la question posée. Ce document « gold » est placé à différentes positions dans la liste (position 1, 5, 10, 15, 20, etc.). Le modèle doit trouver la réponse en se basant uniquement sur les documents fournis.

Tâche 2 : Recherche de paires clé-valeur

Cette tâche plus synthétique présente au modèle un objet JSON contenant des paires clé-valeur (identifiants UUID 128 bits). Le modèle doit retrouver la valeur associée à une clé donnée. C’est un test de rappel pur, sans ambiguïté sémantique. Malgré la simplicité de la tâche, certains modèles échouent lorsque la paire cible se trouve au milieu du contexte.

Résultats clés de l’article original

Causes mécanistes du phénomène

Le masquage causal (causal masking)

Une recherche de 2025 menée au MIT (Xinyi Wu et al.) a apporté un éclairage théorique fondamental. Dans un Transformer decoder-only (l’architecture de la quasi-totalité des LLM actuels), le masquage causal fait que chaque token ne peut « voir » que les tokens qui le précèdent. Les chercheurs du MIT ont construit un cadre théorique basé sur la théorie des graphes pour montrer que ce masquage introduit un biais structurel vers le début de la séquence, même quand les données d’entraînement ne contiennent pas ce biais.

Concrètement, les premiers tokens d’un contexte sont « vus » par tous les tokens suivants (via les couches d’attention successives), tandis que les tokens du milieu ne bénéficient pas de cette diffusion complète. C’est l’une des causes de l’effet de primauté observé dans les LLM.

La décroissance de RoPE (Rotary Position Embedding)

La plupart des LLM modernes utilisent RoPE comme encodage positionnel. RoPE introduit une décroissance naturelle de l’attention en fonction de la distance entre tokens. Plus deux tokens sont éloignés, plus le signal d’attention est atténué. Ce phénomène amplifie le biais positionnel : les tokens au milieu d’un long contexte se trouvent à grande distance à la fois du début (instruction/question) et de la fin (tokens récemment générés), et reçoivent donc moins d’attention des deux côtés.

Le biais du fine-tuning d’instruction

Liu et al. font une observation importante : tous les modèles testés sont instruction-tuned. Or, dans les données de instruction tuning, la consigne est presque toujours placée au début du contexte. Le modèle apprend implicitement à accorder plus d’importance au début. Ce biais lié aux données d’entraînement s’additionne aux biais architecturaux décrits ci-dessus.

Les « attention sinks »

Des travaux complémentaires (Xiao et al., 2023) ont montré que les LLM allouent une proportion disproportionnée d’attention au tout premier token de la séquence, indépendamment de son contenu sémantique. Ce phénomène, appelé « attention sink », détourne des ressources attentionnelles qui pourraient servir à traiter les tokens en milieu de contexte.

Impact sur les systèmes RAG

Le Lost in the Middle est un problème critique pour les pipelines de Retrieval-Augmented Generation. Dans un système RAG typique, un retriever renvoie 5, 10, voire 20 documents pertinents qui sont concaténés dans le prompt du LLM. Si les documents les plus pertinents se retrouvent au milieu de cette concaténation, le modèle risque de les ignorer au profit des premiers et derniers documents, même si ceux-ci sont moins pertinents.

Les études de Chroma Research (2025) ont confirmé et étendu ces résultats sur 18 modèles frontier, incluant GPT-4.1, Claude Opus 4 et Gemini 2.5. Leurs conclusions sont sans appel : tous les modèles testés présentent une dégradation de performance quand le contexte s’allonge (phénomène qu’ils nomment « context rot »). Les modèles Claude se dégradent le plus lentement, mais aucun modèle n’est immunisé. La chute de précision peut atteindre 20 à 50 % entre 10K et 100K tokens.

Du et al. (2025) ont même démontré que la longueur du contexte seule suffit à dégrader la performance, indépendamment de la qualité du rappel. Autrement dit, même si votre retriever est parfait, ajouter du texte dans le prompt peut nuire à la qualité de la réponse.

Solutions et atténuations

Stratégie 1 : Re-ranking et ordonnancement stratégique

La solution la plus immédiate et la plus efficace en production consiste à ré-ordonner les documents avant de les injecter dans le prompt. Le principe est simple : placez les documents les plus pertinents au début et à la fin du contexte, et les moins pertinents au milieu. Vous exploitez le biais positionnel du modèle au lieu de lutter contre lui.

Un pipeline robuste fonctionne en deux étapes. Premièrement, une phase de retrieval large (20 à 100 documents via similarité vectorielle) qui maximise le rappel. Deuxièmement, une phase de re-ranking avec un modèle cross-encoder (BERT-based) qui évalue la pertinence de chaque document par rapport à la requête, puis les ordonne stratégiquement.

Stratégie 2 : Réduction du contexte

Moins de contexte signifie moins de « milieu » où perdre de l’information. La compression de contexte est l’une des atténuations les plus efficaces du Lost in the Middle. Microsoft LongLLMLingua a démontré une amélioration de précision allant jusqu’à 21,4 points de pourcentage avec un ratio de compression de 4×. L’idée est de supprimer les tokens à faible signal informatif avant de passer le contexte au LLM, en conservant les passages pertinents intacts.

En pratique, limitez-vous aux 3 à 5 documents les plus pertinents dans votre prompt. Au-delà, le gain marginal en rappel est annulé par la perte d’attention sur le milieu du contexte.

Stratégie 3 : Recherche hybride

Combinez la recherche sémantique (similarité d’embeddings) avec la recherche lexicale (BM25) pour améliorer la qualité initiale du retrieval. Un retrieval de meilleure qualité signifie que vous pouvez injecter moins de documents dans le prompt tout en couvrant la requête, ce qui réduit mécaniquement le problème Lost in the Middle.

Stratégie 4 : Multi-scale Positional Encoding (Ms-PoE)

Ms-PoE (Zhang et al., 2024) est une approche « plug-and-play » qui ne nécessite ni fine-tuning ni surcoût mémoire. Elle modifie le remapping des indices positionnels de RoPE en attribuant des ratios d’échelle différents à différentes têtes d’attention. Les têtes avec un faible score de sensibilité positionnelle reçoivent un ratio de rescaling plus élevé, ce qui atténue la décroissance à longue distance. Les évaluations montrent une amélioration de 20 à 40 % de la précision sur les positions centrales du contexte.

Stratégie 5 : Prompt engineering structuré

Structurez votre prompt pour signaler explicitement la hiérarchie d’importance des documents. Exemple :

Vous recevez plusieurs passages classés par pertinence.
Utilisez d'abord les « Passages principaux ».
Si nécessaire, consultez les « Passages secondaires ».
Ne fabriquez pas d'information absente des passages.

## Passages principaux
[vos 3 meilleurs documents ici]

## Passages secondaires
[documents complémentaires ici]

Ce format donne au modèle deux signaux convergents : un signal positionnel (les passages principaux sont en haut du prompt) et un signal sémantique (l’instruction les désigne comme prioritaires). La combinaison des deux est nettement plus efficace que chaque signal isolé.

Stratégie 6 : Approche par fenêtres (windowed processing)

Pour les documents très longs (livres, corpus juridiques, transcriptions multi-jours), découpez le matériel en fenêtres, traitez chaque fenêtre séparément pour en extraire les éléments pertinents, puis synthétisez les résultats dans un second passage. À aucun moment le modèle ne reçoit un prompt unique contenant des dizaines de passages non filtrés.

État des lieux en mars 2026

Les modèles de la génération actuelle (GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro) ont significativement amélioré leur gestion du long contexte par rapport à 2023. Le test Needle in a Haystack standard (single-needle) est désormais réussi quasi systématiquement. Toutefois, le Lost in the Middle n’a pas disparu : il s’est déplacé vers des tâches plus complexes (raisonnement multi-hop, synthèse, comparaison d’informations dispersées) et des contextes plus longs (au-delà de 100K tokens).

L’avantage d’Anthropic est notable sur ce plan. Claude Opus 4.6 et Sonnet 4.6 bénéficient d’une fenêtre de contexte de 1M tokens en GA sans surcoût au-delà de 200K tokens, là où GPT-5.4 (surcoût au-delà de 272K tokens) et Gemini 3.1 Pro (surcoût au-delà de ~200K tokens) facturent un supplément pour les longs contextes. Sur la robustesse attentionnelle, les études de Chroma Research indiquent que les modèles Claude se dégradent le plus lentement avec la longueur de contexte, bien qu’aucun modèle ne soit entièrement immunisé.

Les recherches récentes (Wu et al., MIT, 2025) pointent vers des solutions plus fondamentales au niveau de l’architecture elle-même : modifier les masques d’attention et les encodages positionnels pendant l’entraînement pourrait réduire structurellement le biais. Les Sparse Autoencoders positionnels (HPA-SAE, Challagundla et al., 2025) ont démontré une amélioration de 14,2 points de pourcentage sur la compréhension des positions centrales sur LLaMA-2. Ces approches sont encore expérimentales, mais elles suggèrent que le problème pourrait être significativement atténué dans les prochaines générations de modèles.

Relation avec d’autres concepts

Verdict

Le Lost in the Middle est l’un des problèmes les plus concrets et les plus impactants des LLM en production. Contrairement à beaucoup de limitations théoriques, celui-ci affecte directement la fiabilité de vos applications dès que vous injectez plus de quelques documents dans un prompt. La bonne nouvelle : les solutions côté ingénierie (re-ranking, réduction du contexte, prompt structuré) sont accessibles et efficaces. Ne comptez pas sur la taille de la fenêtre de contexte pour compenser : plus de tokens ne signifie pas meilleure utilisation. Investissez dans la qualité du contexte injecté, pas dans sa quantité.