Lost in the Middle
Le « lost in the middle » est le constat empirique, documenté par Liu et al. dans un article de Stanford/Samaya AI de 2023, selon lequel les LLM obtiennent les meilleurs résultats lorsque les informations clés se trouvent au tout début ou à la toute fin d'un long contexte, et nettement de moins bons résultats lorsque les mêmes informations se situent au milieu. Même les modèles dotés de fenêtres de plus de 100 000 tokens présentent toujours cette courbe d'attention en forme de U.
Le « lost in the middle » est le constat empirique, documenté par Liu et al. dans un article de Stanford/Samaya AI de 2023, selon lequel les LLM obtiennent les meilleurs résultats lorsque les informations clés se trouvent au tout début ou à la toute fin d'un long contexte, et nettement de moins bons résultats lorsque les mêmes informations se situent au milieu. Même les modèles dotés de fenêtres de plus de 100 000 tokens présentent toujours cette courbe d'attention en forme de U.
Pourquoi c'est important
Une « grande fenêtre de contexte » n'équivaut pas à « lire tout de manière égale ». Un modèle doté d'un contexte de 200K peut techniquement ingérer un livre entier, mais la précision pratique sur une question dont la réponse se trouve à la page 300 d'un PDF de 500 pages est bien moins bonne que pour la même question dont la réponse se trouve à la page 5 ou à la page 495. Pour les développeurs, cela a des conséquences concrètes : la manière dont vous ordonnez le contexte au sein d'un prompt modifie considérablement la qualité de la réponse, souvent davantage que la quantité de contexte que vous fournissez. La plupart des échecs des RAG en production attribués au fait que « le modèle a ignoré le passage récupéré » sont en réalité des échecs de type lost-in-the-middle déguisés.
Le constat initial
L'article de 2023 de Liu et al. « Lost in the Middle: How Language Models Use Long Contexts » a testé GPT-3.5, GPT-4, Claude et plusieurs modèles ouverts sur des tâches de réponse à des questions multi-documents. Pour chaque question, ils ont placé le document pertinent aux positions 1, 5, 10, 15, 20 sur un total de 20 documents. Résultats :
- La précision était la plus élevée lorsque le document pertinent était en premier (en haut du contexte).
- La précision était presque aussi élevée lorsqu'il était en dernier (en bas).
- La précision chutait de 20 à 30 points lorsque le document pertinent se trouvait aux positions du milieu.
La forme ressemble à un U : forte aux deux extrémités, faible au milieu. Des travaux ultérieurs ont montré que ce schéma se maintient sur les modèles Claude, Gemini et Llama, même à mesure que leurs fenêtres de contexte s'agrandissaient.
Pourquoi cela se produit
Plusieurs hypothèses, probablement toutes partiellement vraies :
Distribution des données d'entraînement : les données d'entraînement ont tendance à placer les informations importantes au début (titres, phrases d'accroche) et à la fin (conclusions, résumés). Le modèle apprend ces a priori positionnels.
Atténuation de l'attention : la portée effective de l'auto-attention se dégrade sur de très longues séquences, même avec des techniques comme RoPE ou ALiBi : les tokens éloignés du milieu reçoivent moins de masse d'attention que les extrémités proches.
Limites de l'encodage positionnel : les modèles à contexte étendu héritent d'encodages de position calibrés pour des séquences plus courtes, de sorte que les positions du milieu sont relativement sous-entraînées.
Biais de récence : les modèles accordent plus de poids aux tokens récents, ce qui amplifie l'extrémité finale forte mais n'aide pas le milieu.
Comment concevoir en conséquence
1. Placez le contexte le plus important en premier ou en dernier : pour le RAG, placez le passage récupéré le mieux classé au tout début ou à la toute fin du bloc de contexte.
2. Reclassement après récupération : utilisez un reranker pour trier les segments récupérés par pertinence, puis placez le meilleur à l'extrémité.
3. Réorganisez par pertinence, et non par ordre de récupération : la recherche vectorielle renvoie souvent les résultats par ordre de distance ; réorganisez-les de sorte que les plus pertinents se retrouvent aux positions à forte attention.
4. Résumez le milieu : au lieu de déverser le contexte brut du milieu, résumez-le et placez le résumé en haut. Un milieu compressé survit mieux qu'un milieu brut.
5. Raccourcissez le contexte : la courbe en U s'aggrave à mesure que la longueur augmente. Moins de segments mais plus pertinents valent mieux que de nombreux segments marginaux.
6. Répétez les faits essentiels : placer le même fait clé à la fois en haut et en bas exploite la courbe en U au lieu de la combattre.
7. Instruction de la tâche aux deux extrémités : certains prompts gagnent à répéter la question en haut et en bas du contexte, en encadrant les preuves.
Cela s'applique-t-il toujours en 2026 ?
Les modèles plus récents à contexte long (Gemini 1.5 / 2.0, Claude 3.5+/4.x, GPT-4 Turbo et la série o) ont considérablement amélioré la mémorisation du milieu du contexte. Les tests de l'aiguille dans la botte de foin sur Gemini 2.0 montrent une récupération quasi parfaite sur l'ensemble de la fenêtre. Mais dans les tâches réelles multi-faits impliquant un raisonnement complexe, la courbe en U réapparaît, simplement de manière moins marquée. Le conseil pratique n'a pas beaucoup changé : un contexte plus court et bien ordonné l'emporte toujours sur un contexte long et ordonné de façon aléatoire.
Erreurs courantes
Supposer que plus de contexte = de meilleures réponses : vrai seulement jusqu'à un certain point ; la dégradation du milieu entre alors en jeu.
Déverser les passages récupérés dans l'ordre de la recherche vectorielle : la distance vectorielle n'équivaut pas à l'importance positionnelle.
Sauter le reclassement : récupération + reclassement est plus efficace qu'un contexte plus long avec une récupération naïve.
Ne pas tester avec des aiguilles à des positions réalistes : les tests jouets de l'« aiguille dans la botte de foin » placent souvent l'aiguille à des positions aléatoires uniformes, ce qui masque la courbe en U. Testez sur des cas d'usage réalistes.
Croire le marketing : un « contexte de 1M de tokens » ne signifie pas que le modèle traite tous les 1M de tokens de manière égale.
Sources :