{"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-hant","path":"/content/papers/zh-hant/retrieval-augmented-generation/self-route.c08b5e187666.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}}}