現代 AI 系統的「記憶」之戰：從 Context Window 到 RAG 的工程權衡

在當前的 LLM 應用開發中，最核心的矛盾之一就是：模型能「記住」多少，以及它如何「檢索」這些記憶。

很多開發者在面對長文本處理時，習慣性地認為只要 Context Window（上下文視窗）足夠大（例如 Gemini 的 2M 或 Claude 的 200K），就可以把所有文件直接塞進 Prompt。但在實際的生產環境下，這種「暴力載入」方案往往會遇到嚴重的效能和成本瓶頸。

上下文視窗（Context Window）的幻象

增加上下文視窗確實降低了開發門檻，但它帶來了三個不可忽視的問題：

1. 注意力稀釋（Lost in the Middle）：研究顯示，模型對輸入文字開頭和結尾的資訊感知最強，而中間部分的資訊極易被忽略。即使視窗支援 100K，當你塞入 50 份文件時，關鍵答案如果落在第 25 份文件中，模型給出錯誤答案的機率會顯著增加。
2. 推論成本與延遲：Transformer 的計算複雜度與序列長度呈平方關係（雖然有線性注意力機制的優化）。輸入越長，首字回應時間（TTFT）越久，且 Token 消耗呈線性成長。
3. 雜訊干擾：無關資訊的堆砌會增加模型的「幻覺」機率。當 Prompt 中包含大量冗餘資訊時，模型更容易被誤導。

RAG：精準的「外部索引」

為了解決上述問題，檢索增強生成（RAG, Retrieval-Augmented Generation）成為了工業界的標準方案。其核心邏輯是將「記憶」從模型內部轉移到外部向量資料庫中。

一個成熟的 RAG 系統不再是簡單的 Embedding -> Vector Search -> LLM，而是一套複雜的工程流水線：

1. 切片策略（Chunking Strategy）

簡單的固定長度切片會切斷語意。現代方案傾向於使用 語意切片（Semantic Chunking） 或 遞迴字元切片，確保每個 Chunk 包含一個完整的語意單元。

2. 多路召回（Hybrid Search）

單純依賴向量檢索（Dense Retrieval）在處理專有名詞、產品型號或精確 ID 時效果極差。高效的系統必須結合：
- 向量檢索：捕捉語意相關性。
- 關鍵字檢索 (BM25)：確保精確匹配。
- 重排序 (Reranking)：用一個更小但更精密的 Cross-Encoder 模型對初篩出的 Top-N 結果進行二次評分。

工程權衡：什麼時候該用什麼？

在建構 AI 系統時，建議遵循以下決策路徑：

場景	首選方案	原因
短篇文件分析 / 單次對話	直接放入 Context	低延遲，無需維護索引
海量知識庫 / 企業文件	RAG $\rightarrow$ Rerank $\rightarrow$ LLM	可擴展性強，成本可控
需要極高精確度的事實查詢	Hybrid Search + RAG	防止向量空間坍縮導致的誤檢
複雜邏輯推論 / 長程式碼庫分析	Long Context + GraphRAG	需要全域拓撲結構而非碎片化片段

未來趨勢：Long Context 與 RAG 的融合

未來的趨勢並非二選一，而是 「動態路由」。系統首先透過輕量級檢索定位關鍵片段 $\rightarrow$ 將片段及其周圍的上下文（Contextual Window）擴充 $\rightarrow$ 送入長上下文模型進行深度推論。

這種 「檢索 $\rightarrow$ 擴充 $\rightarrow$ 推論」 的鏈路，既保留了 RAG 的低成本和高精度，又發揮了長上下文模型的綜合理解能力。對於開發者而言，不要迷信視窗大小，真正的競爭力在於你如何建構那套高效的知識索引與過濾機制。