Dès lors qu’un modèle peut lire un million de tokens dans un seul prompt, il est tentant de déclarer la récupération morte : il suffirait de tout lui donner. Une étude rigoureuse montre que la réponse est plus intéressante que cela.
TL;DR
- Avec suffisamment de ressources, fournir le document entier à un modèle à long contexte tend à surpasser la récupération sur la qualité des réponses.
- La récupération (RAG) est nettement moins coûteuse parce qu’elle envoie bien moins de tokens.
- Un simple routeur qui envoie les questions faciles au RAG et les difficiles au long contexte récupère l’essentiel de la qualité pour une fraction du coût.
Deux façons de donner du contexte à un modèle
Il existe deux grandes stratégies pour ancrer une réponse dans votre contenu. La génération augmentée par récupération (RAG) fouille vos données, en extrait les quelques fragments les plus pertinents et ne place que ceux-là dans le prompt. Le long contexte se passe de récupération et place directement le document entier (ou de nombreux documents) dans la fenêtre. À mesure que les fenêtres ont dépassé la centaine de milliers de tokens, on s’est mis à se demander si le RAG valait encore la tuyauterie qu’il exige.
Ce que montre la recherche
Dans Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach, des chercheurs de Google DeepMind ont opposé les deux approches sur les trois modèles à long contexte les plus performants de l’époque — Gemini-1.5-Pro, GPT-4o et GPT-3.5-Turbo — à travers un ensemble de jeux de données de question-réponse sur documents longs, tirés de benchmarks établis. Pour chaque question, ils ont comparé deux configurations : fournir le document entier au modèle (long contexte) ou récupérer les k meilleurs fragments et ne fournir que ceux-là (RAG).
Leur conclusion phare : lorsque le modèle est puissant et que l’on peut se permettre de tout lui fournir, le long contexte produit systématiquement de meilleures réponses que le RAG en moyenne. La récupération laisse parfois tomber le seul fragment qui contenait réellement la réponse ; placer le document complet dans la fenêtre élimine ce mode d’échec. Mais les deux approches étaient aussi fortement corrélées — sur la grande majorité des questions, elles renvoyaient la même réponse, un fait que les auteurs allaient exploiter.
Le RAG, à l’inverse, n’envoie qu’une poignée de passages récupérés ; il est donc bien moins coûteux par requête. L’étude présente cela comme un véritable arbitrage plutôt que comme un vainqueur : le long contexte achète de la qualité, le RAG achète de l’efficacité.
L’hybride : router, plutôt que choisir
Cette corrélation est l’ouverture. Les auteurs proposent Self-Route, un pipeline en deux étapes qui laisse le modèle décider lui-même, requête par requête, quelle voie emprunter :
- Le RAG d’abord, avec une issue de secours. On donne au modèle les fragments récupérés et on lui demande soit de répondre, soit de déclarer la question « sans réponse possible » à partir de ce qui lui a été montré — sans deviner.
- N’escalader que les questions sans réponse. Les questions que le modèle signale comme sans réponse possible sont rejouées avec le document complet dans la fenêtre ; tout le reste conserve la réponse RAG bon marché.
Comme le RAG et le long contexte s’accordent déjà sur la plupart des questions, seule une minorité atteint la voie coûteuse. Le résultat : une qualité de réponse proche du toujours- long-contexte pour un coût proche du toujours-RAG.
La bonne question est rarement « RAG ou long contexte ? » — c’est « de laquelle cette requête précise a-t-elle besoin ? »
Ce que cela signifie pour vous
Deux choses en découlent pour quiconque bâtit sur un LLM. D’abord, une fenêtre de contexte plus grande ne rend pas la récupération inutile — elle change le moment où l’on y a recours. Ensuite, le choix par défaut avisé n’est pas « toujours tout déverser » mais « garder le contenu organisé pour que le système puisse en extraire la bonne tranche, et ne payer le tout que lorsqu’une question l’exige vraiment ».
Où FocusLM intervient
FocusLM conserve votre contenu sous forme de mémoire structurée plutôt que comme un unique prompt en croissance permanente. C’est cette structure qui rend la voie bon marché possible : la plupart des questions trouvent réponse à partir des quelques fichiers pertinents et sourcés, et le contexte plus large reste disponible lorsqu’une question en a réellement besoin — la même logique du router-plutôt-que-choisir, appliquée à une mémoire qui grandit avec vous.