在前篇文章中，我們探討了 RAG 系統的兩個核心階段：準備階段 (Indexing) 與查詢階段 (Querying)。我們了解到，這套流程如同為 AI 精心打造一本高品質、易於查閱的「參考書」，並讓 AI 學會如何在毫秒之間，從書海中精準地翻到記載著答案的那幾頁。
然而，找到了正確的「書頁」（檢索到的文本區塊），就保證能得到完美的答案嗎？這正是 RAG 旅程的最後一哩路，也是成敗的關鍵分水嶺。如果我們只是將找到的資料一股腦地塞給大型語言模型（LLM），往往會得到不精確、甚至錯誤的結果。問題就出在連接「檢索」與「生成」的橋樑——**上下文（Context）**的建構與優化上。本文將接續昨天的內容，探討為何 Context 是 RAG 的效能瓶頸。
在 RAG 的流程中，Context 是連接「檢索」與「生成」的橋樑。它是由檢索系統從知識庫中篩選出的資訊片段組合而成，最終被「餵」給 LLM，作為生成答案的唯一依據。
要理解 Context 的挑戰，首先必須認識「上下文視窗」這個基本概念。上下文視窗（Context Window）指的是一個語言模型在單次處理中，能夠接收和理解的 Token 總量上限。這裡的 Token 是模型處理文本的基本單位，它不完全等同於一個字。對於英文來說，一個單字通常是 1 個 Token，但對於繁體中文，由於字符的複雜性，一個中文字可能需要 1 到 3 個 Tokens 來表示。
不同模型的上下文視窗大小差異極大，這也直接影響了它們處理資訊的能力。例如
GPT-3.5-turbo: 提供約 16k tokens 的視窗。GPT-4-turbo: 擴展至 128k tokens。Claude 3 Opus: 目前提供高達 200k tokens 的視窗。我們可以將上下文視窗想像成一張工作檯。過去檯面很小，只能放幾份關鍵文件。現在，這張檯面變得越來越大，可以堆放更多的參考資料。然而，這並不意味著檯面是無限的。更重要的是，一張堆滿了文件的巨大檯面，也意味著更高的成本（API 費用通常與 Token 數量掛鉤）和更長的處理時間（模型需要更久來消化所有資訊）。更糟的是，檯面上的文件越多，找到真正需要的那一張就越困難。
隨著上下文視窗的擴大，我們似乎可以將所有檢索到的資訊都丟給 LLM，讓它自行判斷。但實務證明，這種「暴力美學」往往會帶來三個嚴峻的挑戰，直接扼殺 RAG 系統的效能。
「大海撈針」與「迷失在中間 (Lost in the Middle)」
史丹佛大學等機構的研究明確指出，當 Context 過於冗長時，LLM 的注意力並非均勻分佈。它們會顯著地更關注 Context 的開頭和結尾部分，而忽略中間的大量內容。這種現象被稱為「Lost in the Middle」。這就像一個忙碌的主管，在閱讀一份長篇報告時，往往只快速掃過開頭的摘要和結尾的結論，中間的詳細論證過程很容易被忽略。
這對 RAG 系統是致命的。即使你的檢索器非常精準，成功找到了包含答案的黃金段落，但如果你將它隨意地放在一個充滿其他資訊的長 Context 中間，LLM 很可能在處理過程中「視而不見」，最終基於開頭或結尾的不相關資訊生成一個錯誤的答案。
資訊噪音 (Noise)
在典型的 RAG 應用中，我們通常會檢索 Top-k（例如前 5 或前 10）個最相關的文本區塊（Chunks）來建構 Context。然而，「相關」不等於「完全相關」。這 Top-k 個區塊中，很可能只有一兩個直接回答了問題，其餘的可能只是主題沾邊，或是提供了無關的背景資訊。這些不直接相關的內容，就構成了「資訊噪音」。
過多的噪音會嚴重干擾 LLM 的判斷力。它不僅增加了模型處理的負擔，還可能「稀釋」關鍵資訊的重要性，甚至會引導 LLM 偏離主題，產生一個聽起來合理但實際上並未回答使用者問題的答案。
資訊衝突 (Contradiction)
當你的知識庫來源多元或內容隨時間更新時，檢索到的不同資訊來源可能會提供相互矛盾的內容。例如，一份文件說「A 產品的保固期為一年」，而另一份更新的文件則說「A 產品的保固期延長至三年」。如果這兩段資訊同時被放入 Context，LLM 就會陷入兩難。
面對相互矛盾的資訊，LLM 的行為難以預測。它可能會隨機選擇其中一個作為答案，或者為了「安全起見」，嘗試融合兩者，給出一個模稜兩可、含糊不清的回答（例如「A 產品的保固期可能是一年或三年」），這大大降低了答案的可靠性和實用性。
結來說，一個未經優化的 Context 就像一份未經整理的原始檔案，充滿了干擾、矛盾和冗餘。直接將其餵給 LLM，不僅浪費運算資源，更可能導致模型「消化不良」，產出錯誤或無用的結果。這正是 RAG 的最後一哩路，也是通往高效能 AI 應用的關鍵所在。
iThome鐵人賽
看影片追技術