Lost in the Middle : ton RAG oublie la moitié de tes documents

Ton IA a lu tes cinquante documents et elle t’a répondu avec assurance. Sauf qu’elle s’est trompée, et le pire est que la bonne réponse se trouvait bien dans le contexte que tu lui avais donné : au milieu, précisément là où le modèle regarde le moins. Ce n’est pas un bug, c’est un biais de position, il porte un nom, et il est mesurable. Ce n’est pas pour autant la cause principale des mauvaises réponses d’un RAG, et c’est ce malentendu que je voudrais lever ici.

Le phénomène

En 2023, des chercheurs de Stanford ont publié « Lost in the Middle » : même les modèles dotés de fenêtres de contexte énormes retiennent mieux ce qui se trouve au début et à la fin du prompt, et sous-exploitent le milieu. C’est l’effet de position sérielle appliqué aux LLM, le même qui fait qu’on retient le premier et le dernier élément d’une liste, rarement ceux du milieu. Depuis, les modèles ont beaucoup progressé sur la récupération d’une information isolée dans un long contexte ; le biais s’est atténué sans disparaître, et il se manifeste surtout quand la réponse exige de croiser plusieurs passages éloignés les uns des autres.

Où ça se joue vraiment

Avant de parler d’ordre, il faut parler de contenu. Si le passage qui contient la réponse n’a pas été récupéré, aucune disposition dans le prompt ne le fera apparaître : la qualité de ta recherche documentaire (indexation, découpage, reranking, déduplication) décide de ce qui est possible, tout le reste ne fait qu’en tirer parti. Vient ensuite la quantité, parce qu’un contexte encombré dilue le signal et coûte cher à chaque appel. L’ordre de présentation n’arrive qu’en troisième position. Il compte, il est gratuit à mettre en œuvre, mais il ne rattrapera jamais une recherche documentaire médiocre.

C’est pour ça que « Lost in the Middle » est une optimisation de prompt, pas une architecture. Le gain est réel quand tout le reste est déjà propre. Il est invisible quand ton pipeline ramène le mauvais chunk.

Ce que je fais en pratique

• Je soigne d’abord la récupération : un reranker sur les candidats, et de la déduplication, avant même de penser à l’ordre.
• Je limite le nombre de chunks injectés. Cinq à sept bien choisis battent vingt chunks en vrac, et coûtent moins cher.
• Je place ensuite les plus pertinents en début et en fin de contexte, jamais au milieu.
• Je structure le contexte avec des balises et des séparateurs, pour aider le modèle à le parcourir, et je répète les instructions critiques à la fin du prompt.
• Je découpe en sous-requêtes plutôt que d’envoyer un seul prompt massif, parce que deux questions précises valent mieux qu’une question large noyée dans du contexte.

La technique plus avancée consiste à tester plusieurs ordres de chunks puis à comparer les réponses obtenues : la cohérence entre les versions devient un signal de fiabilité. C’est aussi le meilleur moyen de vérifier si le biais te concerne réellement, plutôt que de le supposer.

Le mythe de la fenêtre de contexte

« Mon modèle a un million de tokens de contexte. » Très bien : cela signifie qu’il peut recevoir beaucoup de texte, pas qu’il va l’exploiter de manière uniforme. Une grande fenêtre, c’est un bureau de cinquante mètres carrés : tu as la place de tout étaler, mais tu travailles quand même avec les trois feuilles posées juste devant toi. La tentation est alors de tout envoyer « au cas où », et c’est précisément ce qui dégrade la réponse tout en gonflant la facture.

Le vrai skill du RAG

Ce n’est pas de vectoriser des documents : n’importe quel tutoriel te l’apprend en dix minutes. Le savoir-faire consiste à décider quels documents injecter et lesquels laisser de côté, dans quel ordre les présenter, comment structurer le prompt pour que le modèle utilise vraiment ce qu’on lui donne, et à quel moment découper une requête en plusieurs étapes. Construire un bon RAG, ce n’est pas empiler des embeddings, c’est concevoir la mémoire du modèle, et une mémoire se juge d’abord à ce qu’on choisit d’y mettre.

Tu as sans doute déjà croisé des réponses qui semblaient correctes mais qui ignoraient l’essentiel. Avant d’accuser le milieu du contexte, vérifie que l’information clé y était bien : la plupart du temps, elle n’y était pas.

Ton RAG répond à côté et tu ne sais pas si le problème vient de la recherche, du découpage ou du prompt ? Un échange de trente minutes suffit en général pour situer d’où vient la fuite.