{"notes":[{"id":"retrieval-augmented-generation/self-route","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Self-Route","subtitle":"不知为不知","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":"zh-hans","path":"/content/papers/zh-hans/retrieval-augmented-generation/self-route.b0b13200dd43.md","headings":[{"id":"定义问题","text":"定义问题","depth":2},{"id":"比较设置","text":"比较设置","depth":3},{"id":"解决问题","text":"解决问题","depth":2},{"id":"先比再说lc-赢了","text":"先比再说：LC 赢了","depth":3},{"id":"有趣的发现两边常常答得一样","text":"有趣的发现：两边常常答得一样","depth":3},{"id":"self-route让模型自己说不知道","text":"Self-Route：让模型自己说「不知道」","depth":3},{"id":"省多少先算一下","text":"省多少？先算一下","depth":3},{"id":"讨论","text":"讨论","depth":2},{"id":"结果","text":"结果","depth":3},{"id":"该取几块","text":"该取几块？","depth":3},{"id":"rag-为什么会失败","text":"RAG 为什么会失败？","depth":3},{"id":"合成数据的陷阱","text":"合成数据的陷阱","depth":3},{"id":"后来的批评","text":"后来的批评","depth":3},{"id":"结论","text":"结论","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"2024 年中，长上下文模型的进展很快。\n\nGemini 1.5 Pro 能吃下 100 万 token，GPT-4o 支持 128K。一份上百页的文档，直接整份贴进去也放得下。\n\n那 RAG 还需要吗？\n\n这是当时很多团队都在问的问题。直接把整份文档交给模型，省掉检索这一关，听起来简单又可靠；但每次都送上十万个 token，账单也很可观。\n\n这篇来自 Google DeepMind 与密歇根大学的论文，发表于 EMNLP 2024 的产业论文场次（Industry Track）。作者做了两件事：先把 RAG 和长上下文放在同一组数据上比较，再根据比较结果，设计一个两者混用的方法。\n\n## 定义问题\n\n在这之前，Xu 等人（2023）的比较研究认为，长上下文模型仍然落后 RAG。作者认为，模型这一年进步很多，结论值得重新检查。\n\n所以第一个问题是：\n\n- **用最新的模型，RAG 和长上下文（long-context，以下简称 LC）谁比较准？**\n\n假如 LC 比较准，还有第二个问题：\n\n- **LC 比较贵。能不能只在需要的时候才用它？**\n\n### 比较设置\n\n作者从 LongBench 和 ∞Bench 挑出英文、真实文本、而且有明确问题的数据集，共 9 个：\n\n- **LongBench**：NarrativeQA（小说与剧本）、Qasper（论文）、MultiFieldQA、HotpotQA、2WikiMultihopQA、MuSiQue（后三个是维基百科多跳问答），以及 QMSum（会议记录）。\n- **∞Bench**：En.QA 与 En.MC，平均长度约 14.7 万个词，比前面的数据集长很多。\n\n开放式问答用 F1，选择题用准确率，摘要类用 ROUGE。\n\n模型有三个：Gemini-1.5-Pro（100 万 token）、GPT-4O（128K，`gpt-4o-2024-05-13`）与 GPT-3.5-Turbo（16K，`gpt-3.5-turbo-0125`）。\n\nRAG 的做法很标准：把长文切成每块 300 个词（word）的片段，用 Contriever 或 Dragon 这两种稠密检索器，依查询与片段的 cosine 相似度取前 5 块，按分数排序后放进提示词。\n\n\n> [!TIP]\n> \n> **模型是不是早就背过答案了？**\n> \n> 这些数据集有不少来自维基百科，商用模型很可能在训练时看过。作者就发现，有时模型给出的答案，用字和标准答案一模一样（例如「meticulously」），但那个字根本没出现在提供的文档里。\n> \n> 所以 RAG 和 LC 的提示词都加上「based only on the provided passage」，要求模型只依据文档作答。附录验证这句话确实压低了 Gemini-1.5-Pro 的 LC 平均分数，从 50.57 降到 45.53，表示它有效限制了模型使用自己记得的知识。作者也承认，评测数据外泄仍是个开放问题。\n\n\n## 解决问题\n\n### 先比再说：LC 赢了\n\n[![原论文 Table 1：Gemini-1.5-Pro、GPT-4O、GPT-3.5-Turbo 在九个数据集上，LC、RAG 与 Self-Route 的分数，以及可回答比例与 token 比例](/content/papers/assets/bdedfb9a9df07b3ecad6c4f8fee397d8b051787576334f930ad25ea74f7be78e.png)](/content/papers/assets/bdedfb9a9df07b3ecad6c4f8fee397d8b051787576334f930ad25ea74f7be78e.png)\n\n*原论文 Table 1，取自 [**ACL Anthology PDF 第 4 页**](https://aclanthology.org/2024.emnlp-industry.66.pdf#page=4)，CC BY 4.0。使用 Contriever 检索；粗体为该模型在该数据集的最高分。*\n\n这张表一次放了很多东西，我们先只看每个模型的前两行：`*-1 LC` 和 `*-2 RAG`。最左列 Avg 是九个数据集的平均。\n\n| 模型 | LC | RAG | 差距 |\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*依原论文 Table 1 的平均分数计算。*\n\n三个模型都是 LC 较好，而且越新的模型差距越大。\n\n唯一的例外在 GPT-3.5-Turbo 的 En.QA 与 En.MC：RAG 分别拿到 15.39 和 43.67，LC 只有 14.73 和 34.50。这两个数据集平均约 14.7 万个词，GPT-3.5-Turbo 却只能放 16K token，整份文档根本塞不进去。作者也把这当成 RAG 的一个明确用途：输入远超过上下文长度的时候。\n\n\n> [!NOTE]\n> \n> **读这篇论文时的小提醒**\n> \n> 论文正文有几处数字和 Table 1 对不上。例如正文写 LC 平均分别胜过 RAG 7.6%、13.1%、3.6%，Gemini 的可回答比例为 81.74%，GPT-4O 的 Self-Route 与 LC 分别是 46.83 和 47.04；但 Table 1 的对应数值是上面那张表的差距、76.78%，以及 48.89 和 48.67。这篇笔记一律采用 Table 1 的数字。\n\n\n### 有趣的发现：两边常常答得一样\n\n如果只看平均分数，结论似乎是「预算够就用 LC」。\n\n但作者接着比较了每一题的答案，画出下面这张图：\n\n[![RAG 与 LC 在每一题上的分数差分布，绝大多数集中在 0](/content/papers/assets/977e711ec46055e2207ae7f021de5d8f1140e73a8d3dadcc2c3daf7a8d146a43.png)](/content/papers/assets/977e711ec46055e2207ae7f021de5d8f1140e73a8d3dadcc2c3daf7a8d146a43.png)\n\n*原论文 Figure 2，取自 [**ACL Anthology PDF 第 3 页**](https://aclanthology.org/2024.emnlp-industry.66.pdf#page=3)，CC BY 4.0。横轴为同一题 RAG 分数减 LC 分数，颜色为两者平均分数。*\n\n横轴是同一题的 RAG 分数减去 LC 分数（分数换算到 0 到 100）。0 的位置有一根非常高的柱子：**63% 的题目，两边的答案一模一样**；分数差在 10 分以内的，则有 70%。\n\n再看柱子的颜色。那根柱子底部是蓝色，代表两边都答对；上半截却是红色，代表两边都答错。\n\n也就是说，RAG 和 LC 不只常常一起答对，也常常一起答错。\n\n既然大部分题目 RAG 就答得和 LC 一样好，那只要找出 RAG 处理不了的那些题，再交给 LC 就好。\n\n### Self-Route：让模型自己说「不知道」\n\n问题是，怎么知道哪些题 RAG 处理不了？\n\n作者的答案很直接：**问模型自己。**\n\nSelf-Route 分成两步：\n\n1. **RAG 加路由**。把问题和检索到的片段交给模型，提示词多加一句：「如果根据提供的文本无法回答，请写 unanswerable」。模型答得出来，就直接采用这个答案。\n2. **长上下文预测**。模型回答 unanswerable 的题目，才把完整文档交给 LC 重新作答。\n\n写成程序大概是这样：\n\n```python\ndef self_route(question, document, k=5):\n    chunks = retrieve(question, document, k=k)       # 每块 300 个词，取前 k 块\n    answer = llm(question, context=chunks, allow_unanswerable=True)\n    if answer != \"unanswerable\":\n        return answer                                # 大部分题目在这里结束\n    return llm(question, context=document)           # 少数题目才送整份文档\n```\n\n这里没有额外训练任何分类器，路由完全靠模型读完片段后的自我判断。作者假设模型对「能不能从这些片段回答」有足够准确的判断。\n\n### 省多少？先算一下\n\n那这样能省多少 token？我们可以先用简单的估算感受一下。\n\n设整份文档长度为 $L$，检索片段的长度为 $\\ell$，模型判断可回答的比例为 $a$。每一题都要先付一次 RAG 加路由的成本 $\\ell$；判为不可回答的题目，还要再付一次完整文档 $L$。平均每题的输入 token 约为：\n\n$$\n\\ell + (1-a)\\,L\n$$\n\n和纯 LC 的 $L$ 相比，比例是：\n\n$$\n\\frac{\\ell}{L} + (1-a)\n$$\n\n作者在正文举的例子是，检索片段约 1.5K token，完整文档约 10K 到 100K token。假设文档是 100K，可回答比例 $a=0.77$：\n\n$$\n\\frac{1.5}{100} + (1-0.77) = 0.015 + 0.23 \\approx 25\\%\n$$\n\n如果可回答比例只有 $a=0.57$，就会变成约 44%。\n\n这个式子忽略了提示词与输出的长度，只是用来看出一件事：**省下多少，主要取决于模型多常愿意用片段作答。**\n\n## 讨论\n\n### 结果\n\n回到 Table 1，看每个模型的后三行：\n\n| 模型 | LC | Self-Route | 可回答比例 | token 比例 |\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*整理自原论文 Table 1。token 比例为 Self-Route 使用的 token 数相对于 LC。*\n\nGPT-4O 用了约六成的 token，分数和 LC 几乎一样；Gemini-1.5-Pro 只用不到四成的 token，分数低 3.29；GPT-3.5-Turbo 甚至比 LC 高出 3.25，其中两个塞不进 16K 的超长数据集差距特别明显：En.QA 是 22.03 对 14.73，En.MC 是 44.54 对 34.50。\n\n三个模型的可回答比例都超过一半，这也验证了作者的出发点：大部分题目，不需要整份文档。\n\nGPT-4O 的可回答比例明显较低，token 比例也就比较高。作者推测这和模型的对齐方式有关：OpenAI 的模型比较倾向拒绝只用片段作答，可回答比例较低，但答出来的比较准；Gemini 则比较常直接回答。这是作者的解读，论文没有进一步验证。\n\n换成 Dragon 检索器，Gemini-1.5-Pro 的结果趋势相同：LC 49.70、RAG 38.09、混用 46.81，RAG 处理的比例 77.88%，token 比例 37.87%（原论文 Table 2）。\n\n### 该取几块？\n\n$k$ 越大，RAG 看到的片段越多，成绩越接近 LC，但每题的路由成本也越高。\n\n作者画出了 $k$ 从 1 到 50 以上的取舍曲线。$k=1$ 时，RAG 只有 20.24，Self-Route 有 37.9，混用的好处最明显；$k$ 超过 50 之后，三种方法的成绩差不多。\n\n成本的曲线则不是单调的。平均来说 $k=5$ 最省：$k$ 太小，很多题被送去 LC；$k$ 太大，每题的路由成本又变高。不过最省的 $k$ 因数据集而异，像 NarrativeQA、QMSum 这类不需要多跳推理的数据集，$k=1$ 反而最便宜。\n\n### RAG 为什么会失败？\n\n作者把 RAG 判为不可回答的题目整理成四种原因，再让 Gemini-1.5-Pro 以少量人工标注示例，替所有失败案例分类：\n\n- **A. 多步骤**：要先查到第一步的答案，才知道第二步该查什么。例如「XXX 这首歌的演唱者是哪国人？」\n- **B. 太笼统**：例如「这群人对 XXX 有什么看法？」检索器很难从这种问题组出好的查询。\n- **C. 太长太复杂**：检索器不容易理解整个问题。\n- **D. 隐含的**：答案需要理解整个上下文。例如一段太空航行的长篇对话，问「太空船后面的影子是怎么来的？」，揭晓原因的段落根本没提到「影子」。\n\n[![七个 LongBench 数据集中，RAG 失败原因的分布：多步骤、笼统、复杂、隐含与其他](/content/papers/assets/c571b153dec93eecff057696a2888bf48a13750fe10ac943cc49b0c4e2bc9d92.png)](/content/papers/assets/c571b153dec93eecff057696a2888bf48a13750fe10ac943cc49b0c4e2bc9d92.png)\n\n*原论文 Figure 4，取自 [**ACL Anthology PDF 第 6 页**](https://aclanthology.org/2024.emnlp-industry.66.pdf#page=6)，CC BY 4.0。每根柱子的高度是该数据集的 RAG 失败题数。*\n\n失败原因和数据集的性质很吻合。\n\nHotpotQA、2WikiMQA、MuSiQue 这三个维基百科多跳数据集，蓝色的「多步骤」占最多。NarrativeQA 是充满对话的长篇故事，绿色的「隐含」几乎占满。QMSum 是会议记录的开放式问题，主要是红色的「太笼统」。\n\n作者人工检查了「其他」类，发现大多也是带有歧义的多步骤问题。\n\n这张图对做 RAG 的人很实用：先看看自己的问题比较像哪一类，再决定该改检索、改查询，还是直接交给长上下文。作者也建议，多步骤问题可以试试在 RAG 里加入 chain-of-thought，笼统和复杂的问题则可以重新审视查询扩展等技术。\n\n### 合成数据的陷阱\n\n最后有一个很值得一看的小实验。\n\n∞Bench 的 PassKey 是大海捞针式的测试：在一堆无关文本里藏一句「the passkey is 123456」，再问「What is the passkey」。\n\n| 问法 | 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| 有两个 passkey，问哪个比较大 | 47.63 | 64.24 |\n\n*整理自原论文 Table 3，模型为 Gemini-1.5-Pro。*\n\n原始问法下，RAG 大胜。但问题只是换成「藏在文本里的特殊符号是什么」，RAG 就从 80.34 掉到 4.58，LC 则几乎不受影响。\n\n原因不难想像：「passkey」这个字同时出现在问题和那句话里，检索器一对就中；换了说法，字对不上，检索器就找不到了。\n\n作者的结论是，合成数据集的建构方式，可能在不经意间大幅左右 RAG 与 LC 的比较结果。这也是他们主要使用真实数据集的原因。\n\n### 后来的批评\n\nSelf-Route 的路由是「先试 RAG，失败了再退回 LC」。2026 年 5 月的 [**Route Before Retrieve**](https://arxiv.org/abs/2605.10235) 就把这类方法称为由失败驱动的退回机制，认为它被动、效率不高，也难以解释，并提出在作答前先依据文档的轻量信息决定路线。\n\n这个批评点出 Self-Route 的一个前提：模型得在读完片段后，正确判断自己「答不答得出来」。判断太乐观，RAG 就会交出不完整的答案；判断太保守，又会白白多付一次 LC 的成本。\n\n## 结论\n\n这篇论文的答案分成两半。\n\n**比准确度，LC 赢**。在 9 个真实数据集上，Gemini-1.5-Pro、GPT-4O、GPT-3.5-Turbo 三个模型的 LC 平均分数都高于 RAG，越新的模型差距越大。例外是文档长度远超过上下文的时候，这时 RAG 还是比较好用。\n\n**比成本，混用划算**。两边有 63% 的题目答案完全相同。让模型先用检索片段作答、答不出来才送整份文档，GPT-4O 用约 61% 的 token 就达到和 LC 相当的分数，Gemini-1.5-Pro 则用约 38% 的 token，分数低约 3 分。\n\n另外两个发现也值得记住：RAG 的失败大多来自多步骤、笼统与隐含的问题；而合成测试只要换个问法，RAG 和 LC 的胜负就可能完全翻转。\n\n先看小抄，不够再翻整本。这个做法看起来很朴素，但它的成本，取决于模型多诚实地说出「我不知道」。\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}}}