{"notes":[{"id":"retrieval-augmented-generation/self-route","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Self-Route","subtitle":"Savoir dire qu'on ne sait pas","author":"Z. Yuan","paperDate":"2024-07-23","publishedOn":"2026-08-12","paperTitle":"Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach","paperUrl":"https://aclanthology.org/2024.emnlp-industry.66/","bibliography":{"title":"Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach","authors":["Zhuowan Li","Cheng Li","Mingyang Zhang","Qiaozhu Mei","Michael Bendersky"],"url":"https://aclanthology.org/2024.emnlp-industry.66/","pdfUrl":"https://aclanthology.org/2024.emnlp-industry.66.pdf","codeUrl":null,"preprint":{"id":"2407.16833","submittedOn":"2024-07-23","url":"https://arxiv.org/abs/2407.16833"},"publication":{"venue":"EMNLP Industry Track","year":2024,"kind":"conference","url":"https://aclanthology.org/2024.emnlp-industry.66/"},"citation":"@misc{retrievalaugmentedgenerationselfroute2024,\n  title = {{Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach}},\n  author = {Zhuowan Li and Cheng Li and Mingyang Zhang and Qiaozhu Mei and Michael Bendersky},\n  year = {2024},\n  eprint = {2407.16833},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2407.16833}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/self-route.9d3f24607371.bib"},"thumbnail":{"src":"/content/papers/assets/977e711ec46055e2207ae7f021de5d8f1140e73a8d3dadcc2c3daf7a8d146a43.png","width":639,"height":420},"locale":"fr","path":"/content/papers/fr/retrieval-augmented-generation/self-route.962e3ca81960.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"protocole-de-comparaison","text":"Protocole de comparaison","depth":3},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"première-comparaison--lc-lemporte","text":"Première comparaison : LC l'emporte","depth":3},{"id":"un-résultat-intéressant--souvent-les-deux-répondent-pareil","text":"Un résultat intéressant : souvent, les deux répondent pareil","depth":3},{"id":"self-route--laisser-le-modèle-dire--je-ne-sais-pas-","text":"Self-Route : laisser le modèle dire « je ne sais pas »","depth":3},{"id":"combien-économise-t-on--un-premier-calcul","text":"Combien économise-t-on ? Un premier calcul","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"résultats","text":"Résultats","depth":3},{"id":"combien-de-blocs-récupérer-","text":"Combien de blocs récupérer ?","depth":3},{"id":"pourquoi-le-rag-échoue-t-il-","text":"Pourquoi le RAG échoue-t-il ?","depth":3},{"id":"le-piège-des-données-synthétiques","text":"Le piège des données synthétiques","depth":3},{"id":"les-critiques-ultérieures","text":"Les critiques ultérieures","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"Mi-2024, les modèles à long contexte progressaient rapidement.\n\nGemini 1.5 Pro pouvait recevoir un million de tokens et GPT-4o en acceptait 128K. Même un document de plus de cent pages pouvait être transmis en entier.\n\nAvait-on encore besoin du RAG ?\n\nBeaucoup d'équipes se posaient la question. Donner directement tout le document au modèle permettait de supprimer l'étape de recherche : une solution apparemment simple et fiable. Mais envoyer cent mille tokens à chaque demande finissait aussi par se voir sur la facture.\n\nCet article de Google DeepMind et de l'université du Michigan, publié dans l'Industry Track d'EMNLP 2024, procède en deux temps. Il compare d'abord le RAG et le long contexte sur les mêmes données, puis exploite les résultats pour concevoir une méthode hybride.\n\n## Définir le problème\n\nUne étude comparative de Xu et al. (2023) concluait auparavant que les modèles à long contexte restaient derrière le RAG. Pour les auteurs, les progrès réalisés en un an justifiaient une nouvelle vérification.\n\nPremière question :\n\n- **Avec les modèles les plus récents, le RAG ou le long contexte — LC dans la suite — donne-t-il les meilleurs résultats ?**\n\nEt, si LC l'emporte :\n\n- **LC coûte plus cher. Peut-on le réserver aux cas qui en ont besoin ?**\n\n### Protocole de comparaison\n\nLes auteurs sélectionnent dans LongBench et ∞Bench neuf jeux de données en anglais, fondés sur des textes réels et comportant des questions explicites :\n\n- **LongBench** : NarrativeQA, pour les romans et scénarios ; Qasper, pour les articles scientifiques ; MultiFieldQA ; HotpotQA, 2WikiMultihopQA et MuSiQue, ces trois derniers portant sur des questions Wikipédia à plusieurs étapes ; et QMSum, pour les comptes rendus de réunion.\n- **∞Bench** : En.QA et En.MC, avec environ 147 000 mots en moyenne, bien plus longs que les précédents.\n\nLes questions ouvertes sont évaluées par F1, les choix multiples par l'exactitude, et les tâches de résumé par ROUGE.\n\nTrois modèles sont testés : Gemini-1.5-Pro, un million de tokens ; GPT-4O, 128K, version `gpt-4o-2024-05-13` ; et GPT-3.5-Turbo, 16K, version `gpt-3.5-turbo-0125`.\n\nLe pipeline RAG est classique : découper le document en blocs de 300 mots, utiliser l'un des deux moteurs de recherche dense Contriever ou Dragon, puis sélectionner les cinq blocs dont la similarité cosinus avec la requête est la plus élevée. Ils sont insérés dans le prompt par ordre de score.\n\n\n> [!TIP]\n> \n> **Le modèle aurait-il déjà mémorisé la réponse ?**\n> \n> Une bonne partie de ces données provient de Wikipédia, que les modèles commerciaux ont probablement rencontrée à l'entraînement. Les auteurs observent parfois des réponses reprenant exactement un mot de la référence, comme « meticulously », alors que ce mot est absent du document fourni.\n> \n> Ils ajoutent donc « based only on the provided passage » aux prompts RAG et LC pour imposer un appui exclusif sur les documents. L'annexe montre que cette consigne fait bien baisser le score LC moyen de Gemini-1.5-Pro, de 50,57 à 45,53 : elle limite effectivement le recours aux connaissances mémorisées. Les auteurs reconnaissent toutefois que la contamination des données d'évaluation reste un problème ouvert.\n\n\n## Résoudre le problème\n\n### Première comparaison : LC l'emporte\n\n[![Table 1 de l'article : scores LC, RAG et Self-Route de Gemini-1.5-Pro, GPT-4O et GPT-3.5-Turbo sur neuf jeux de données, avec proportions de questions jugées traitables et de tokens consommés](/content/papers/assets/bdedfb9a9df07b3ecad6c4f8fee397d8b051787576334f930ad25ea74f7be78e.png)](/content/papers/assets/bdedfb9a9df07b3ecad6c4f8fee397d8b051787576334f930ad25ea74f7be78e.png)\n\n*Table 1 de l'article, extraite de la [**page 4 du PDF ACL Anthology**](https://aclanthology.org/2024.emnlp-industry.66.pdf#page=4), CC BY 4.0. Recherche avec Contriever ; le gras indique le meilleur score du modèle sur chaque jeu de données.*\n\nCe tableau contient beaucoup d'informations. Commençons par les deux premières lignes de chaque modèle : `*-1 LC` et `*-2 RAG`. La colonne Avg, à gauche, donne la moyenne des neuf jeux de données.\n\n| Modèle | LC | RAG | Écart |\n| --- | ---: | ---: | ---: |\n| Gemini-1.5-Pro | 49,70 | 37,33 | 12,37 |\n| GPT-4O | 48,67 | 32,60 | 16,07 |\n| GPT-3.5-Turbo | 32,07 | 30,33 | 1,74 |\n\n*Écarts calculés à partir des moyennes de la Table 1.*\n\nLC est meilleur pour les trois modèles, et l'écart grandit avec les modèles plus récents.\n\nLes seules exceptions concernent GPT-3.5-Turbo sur En.QA et En.MC : le RAG atteint respectivement 15,39 et 43,67, contre 14,73 et 34,50 pour LC. Ces documents font environ 147 000 mots en moyenne, alors que GPT-3.5-Turbo n'accepte que 16K tokens : impossible d'y faire entrer le document entier. Les auteurs y voient un usage clair du RAG, lorsque l'entrée dépasse largement la fenêtre de contexte.\n\n\n> [!NOTE]\n> \n> **Un point à garder en tête en lisant l'article**\n> \n> Plusieurs chiffres du texte ne correspondent pas à la Table 1. Le texte annonce par exemple des gains moyens de LC sur le RAG de 7,6 %, 13,1 % et 3,6 %, une proportion de questions traitables de 81,74 % pour Gemini, et des scores Self-Route et LC de 46,83 et 47,04 pour GPT-4O. Les valeurs correspondantes de la Table 1 sont les écarts du tableau ci-dessus, 76,78 %, puis 48,89 et 48,67. Cette note utilise systématiquement les chiffres de la Table 1.\n\n\n### Un résultat intéressant : souvent, les deux répondent pareil\n\nÀ regarder les seules moyennes, on pourrait conclure : « Prenez LC si votre budget le permet. »\n\nMais les auteurs comparent ensuite les réponses question par question :\n\n[![Distribution de la différence de score entre RAG et LC pour chaque question, fortement concentrée autour de zéro](/content/papers/assets/977e711ec46055e2207ae7f021de5d8f1140e73a8d3dadcc2c3daf7a8d146a43.png)](/content/papers/assets/977e711ec46055e2207ae7f021de5d8f1140e73a8d3dadcc2c3daf7a8d146a43.png)\n\n*Figure 2 de l'article, extraite de la [**page 3 du PDF ACL Anthology**](https://aclanthology.org/2024.emnlp-industry.66.pdf#page=3), CC BY 4.0. L'axe horizontal indique le score RAG moins le score LC pour une même question ; la couleur représente leur score moyen.*\n\nLes scores sont ramenés sur une échelle de 0 à 100. À zéro, une barre domine très largement : **pour 63 % des questions, les réponses sont exactement identiques**. Pour 70 %, la différence de score reste dans les 10 points.\n\nRegardons les couleurs. Le bas de cette barre est bleu : les deux méthodes ont raison. Sa partie supérieure est rouge : elles ont toutes les deux tort.\n\nRAG et LC réussissent donc souvent ensemble, et échouent souvent ensemble aussi.\n\nPuisque, sur la plupart des questions, le RAG fait aussi bien que LC, il suffirait d'identifier celles qu'il ne sait pas traiter et de les confier à LC.\n\n### Self-Route : laisser le modèle dire « je ne sais pas »\n\nMais comment identifier les questions que le RAG ne sait pas traiter ?\n\nLa réponse des auteurs est directe : **le demander au modèle lui-même.**\n\nSelf-Route comporte deux étapes :\n\n1. **RAG avec routage.** On fournit la question et les passages récupérés au modèle, en ajoutant : « Si les passages fournis ne permettent pas de répondre, écrivez unanswerable. » S'il répond, on conserve directement sa réponse.\n2. **Prédiction en long contexte.** Seules les questions marquées unanswerable sont soumises à nouveau au modèle, cette fois avec le document complet.\n\nEn code, cela donne à peu près :\n\n```python\ndef self_route(question, document, k=5):\n    chunks = retrieve(question, document, k=k)       # Blocs de 300 mots, les k premiers\n    answer = llm(question, context=chunks, allow_unanswerable=True)\n    if answer != \"unanswerable\":\n        return answer                                # La plupart des questions s'arrêtent ici\n    return llm(question, context=document)           # Le document entier pour les cas restants\n```\n\nAucun classifieur supplémentaire n'est entraîné. Le routage repose entièrement sur l'auto-évaluation du modèle après lecture des extraits. Les auteurs supposent qu'il sait juger assez correctement si ces extraits permettent de répondre.\n\n### Combien économise-t-on ? Un premier calcul\n\nOn peut se faire une idée du gain en tokens avec une estimation simple.\n\nNotons $L$ la longueur du document complet, $\\ell$ celle des passages récupérés et $a$ la proportion de questions que le modèle juge traitables. Chaque question paie d'abord le coût $\\ell$ du RAG avec routage. Celles jugées intraitables paient ensuite le document complet $L$. Le nombre moyen de tokens d'entrée par question vaut environ :\n\n$$\n\\ell + (1-a)\\,L\n$$\n\nRapporté aux $L$ tokens du LC seul :\n\n$$\n\\frac{\\ell}{L} + (1-a)\n$$\n\nDans leur exemple, les auteurs prennent environ 1,5K tokens d'extraits et 10K à 100K tokens pour le document entier. Avec un document de 100K et une proportion $a=0.77$ :\n\n$$\n\\frac{1.5}{100} + (1-0.77) = 0.015 + 0.23 \\approx 25\\%\n$$\n\nSi cette proportion tombe à $a=0.57$, on arrive à environ 44 %.\n\nCe calcul néglige la longueur des instructions et des sorties. Il sert surtout à montrer que **les économies dépendent principalement de la fréquence à laquelle le modèle accepte de répondre avec les seuls extraits**.\n\n## Discussion\n\n### Résultats\n\nRevenons aux trois dernières lignes de chaque modèle dans la Table 1 :\n\n| Modèle | LC | Self-Route | Questions jugées traitables | Proportion de tokens |\n| --- | ---: | ---: | ---: | ---: |\n| Gemini-1.5-Pro | 49,70 | 46,41 | 76,78 % | 38,39 % |\n| GPT-4O | 48,67 | 48,89 | 57,36 % | 61,40 % |\n| GPT-3.5-Turbo | 32,07 | 35,32 | 74,10 % | 38,85 % |\n\n*D'après la Table 1. La proportion de tokens compare la consommation de Self-Route à celle de LC.*\n\nGPT-4O utilise environ six dixièmes des tokens pour un score presque identique à LC. Gemini-1.5-Pro en utilise moins de quatre dixièmes, avec 3,29 points de moins. GPT-3.5-Turbo dépasse même LC de 3,25 points, notamment sur les deux jeux de données trop longs pour ses 16K : 22,03 contre 14,73 sur En.QA, et 44,54 contre 34,50 sur En.MC.\n\nLes trois modèles jugent plus de la moitié des questions traitables avec les extraits, ce qui soutient l'idée de départ : la plupart des questions n'ont pas besoin du document entier.\n\nGPT-4O juge sensiblement moins de questions traitables et consomme donc une proportion plus élevée de tokens. Les auteurs avancent une explication liée à l'alignement : les modèles OpenAI seraient plus enclins à refuser de répondre avec les seuls extraits, mais leurs réponses seraient plus précises lorsqu'ils acceptent ; Gemini répondrait plus volontiers. Cette interprétation n'est pas vérifiée plus avant dans l'article.\n\nAvec Dragon comme moteur de recherche, Gemini-1.5-Pro suit la même tendance : LC à 49,70, RAG à 38,09, hybride à 46,81, proportion traitée par RAG de 77,88 % et proportion de tokens de 37,87 %, selon la Table 2.\n\n### Combien de blocs récupérer ?\n\nQuand $k$ augmente, le RAG voit davantage de passages et se rapproche de LC, mais le coût du routage augmente aussi pour chaque question.\n\nLes auteurs tracent ce compromis de $k=1$ à plus de 50. Avec $k=1$, le RAG ne fait que 20,24, contre 37,9 pour Self-Route : l'intérêt de l'hybride est alors le plus marqué. Au-delà de 50, les trois méthodes ont des scores proches.\n\nLa courbe de coût, elle, n'est pas monotone. En moyenne, $k=5$ est le plus économique. Trop petit, $k$ envoie beaucoup de questions vers LC ; trop grand, il alourdit le routage de toutes les questions. L'optimum dépend toutefois du jeu de données : pour NarrativeQA et QMSum, qui ne nécessitent pas de raisonnement à plusieurs étapes, $k=1$ coûte le moins cher.\n\n### Pourquoi le RAG échoue-t-il ?\n\nLes auteurs regroupent les questions jugées intraitables par RAG en quatre catégories. Avec quelques exemples annotés manuellement, ils demandent ensuite à Gemini-1.5-Pro de classer tous les échecs :\n\n- **A. Plusieurs étapes** : il faut trouver la réponse à une première recherche pour savoir quoi chercher ensuite. Par exemple : « De quel pays vient l'interprète de la chanson XXX ? »\n- **B. Trop vague** : « Que pense ce groupe de XXX ? » Le moteur a du mal à construire une bonne requête à partir de cette formulation.\n- **C. Trop long ou complexe** : le moteur peine à comprendre la question dans son ensemble.\n- **D. Implicite** : il faut saisir tout le contexte. Par exemple, dans un long dialogue sur un voyage spatial, on demande d'où vient l'ombre derrière le vaisseau, alors que le passage révélant sa cause ne contient pas le mot « ombre ».\n\n[![Répartition des causes d'échec du RAG sur sept jeux LongBench : plusieurs étapes, question vague, complexe, implicite et autres](/content/papers/assets/c571b153dec93eecff057696a2888bf48a13750fe10ac943cc49b0c4e2bc9d92.png)](/content/papers/assets/c571b153dec93eecff057696a2888bf48a13750fe10ac943cc49b0c4e2bc9d92.png)\n\n*Figure 4 de l'article, extraite de la [**page 6 du PDF ACL Anthology**](https://aclanthology.org/2024.emnlp-industry.66.pdf#page=6), CC BY 4.0. La hauteur de chaque barre est le nombre de questions échouées par le RAG sur le jeu correspondant.*\n\nLes causes correspondent bien à la nature des données.\n\nDans les trois jeux Wikipédia à plusieurs étapes, HotpotQA, 2WikiMQA et MuSiQue, le bleu « plusieurs étapes » domine. NarrativeQA contient de longues histoires riches en dialogues : le vert « implicite » occupe presque toute la barre. QMSum pose des questions ouvertes sur des réunions : le rouge « trop vague » y est majoritaire.\n\nLes auteurs examinent manuellement la catégorie « autres » et y trouvent surtout des questions ambiguës à plusieurs étapes.\n\nPour construire un système RAG, cette figure est utile : identifier d'abord le type de questions auquel on fait face, puis décider s'il faut améliorer la recherche, reformuler les requêtes ou passer directement au long contexte. Les auteurs suggèrent aussi d'essayer une chaîne de raisonnement dans le RAG pour les questions à plusieurs étapes, et de réexaminer l'expansion de requête pour les questions vagues ou complexes.\n\n### Le piège des données synthétiques\n\nUne dernière petite expérience mérite le détour.\n\nPassKey, dans ∞Bench, suit le principe de l'aiguille dans une botte de foin : cacher « the passkey is 123456 » dans du texte sans rapport, puis demander « What is the passkey ».\n\n| Formulation | RAG | LC |\n| --- | ---: | ---: |\n| What is the passkey | 80,34 | 65,25 |\n| What is the special token hidden inside the texts | 4,58 | 69,32 |\n| Deux passkeys sont présents : lequel est le plus grand ? | 47,63 | 64,24 |\n\n*D'après la Table 3, avec Gemini-1.5-Pro.*\n\nAvec la formulation initiale, le RAG gagne largement. Mais demander simplement quel token spécial est caché dans les textes le fait passer de 80,34 à 4,58, tandis que LC reste presque inchangé.\n\nL'explication est assez intuitive : le mot « passkey » apparaît à la fois dans la question et dans la phrase cible. Le moteur trouve immédiatement la correspondance. Une reformulation supprime ce recoupement et il perd la piste.\n\nLes auteurs concluent que la construction des données synthétiques peut infléchir fortement, et sans intention explicite, la comparaison entre RAG et LC. C'est aussi pourquoi ils privilégient des données réelles pour leurs expériences principales.\n\n### Les critiques ultérieures\n\nSelf-Route commence par essayer le RAG, puis se replie sur LC en cas d'échec. En mai 2026, [**Route Before Retrieve**](https://arxiv.org/abs/2605.10235) qualifie cette famille de repli piloté par l'échec, qu'il juge passif, peu efficace et difficile à expliquer. Il propose de choisir la route avant de répondre, à partir d'informations légères sur le document.\n\nCette critique met en lumière une hypothèse de Self-Route : après lecture des extraits, le modèle doit correctement évaluer sa capacité à répondre. Trop optimiste, il livre une réponse RAG incomplète ; trop prudent, il déclenche inutilement le coût supplémentaire de LC.\n\n## Conclusion\n\nLa réponse de cet article comporte deux volets.\n\n**Pour la précision, LC gagne.** Sur neuf jeux de données réelles, Gemini-1.5-Pro, GPT-4O et GPT-3.5-Turbo obtiennent tous un meilleur score moyen avec LC qu'avec RAG, avec des écarts plus grands pour les modèles récents. Lorsque les documents dépassent largement la fenêtre de contexte, le RAG reste toutefois plus adapté.\n\n**Pour le coût, l'hybride est avantageux.** Les deux méthodes donnent exactement la même réponse à 63 % des questions. En laissant le modèle répondre d'abord avec les extraits, puis en ne lui envoyant le document complet qu'en cas d'échec, GPT-4O atteint un score comparable à LC avec environ 61 % des tokens. Gemini-1.5-Pro en utilise environ 38 %, pour quelque trois points de moins.\n\nDeux autres résultats sont à retenir : les échecs du RAG proviennent surtout de questions à plusieurs étapes, vagues ou implicites ; et, dans un test synthétique, une simple reformulation peut inverser complètement le résultat de la comparaison avec LC.\n\nLire d'abord la fiche, puis ouvrir le livre entier si elle ne suffit pas. La méthode semble toute simple. Son coût dépend pourtant de l'honnêteté avec laquelle le modèle sait dire : « Je ne sais pas. »\n","imageSizes":{"/content/papers/assets/bdedfb9a9df07b3ecad6c4f8fee397d8b051787576334f930ad25ea74f7be78e.png":{"width":1289,"height":575},"/content/papers/assets/977e711ec46055e2207ae7f021de5d8f1140e73a8d3dadcc2c3daf7a8d146a43.png":{"width":639,"height":420},"/content/papers/assets/c571b153dec93eecff057696a2888bf48a13750fe10ac943cc49b0c4e2bc9d92.png":{"width":650,"height":381}}}