100萬上下文是謊言嗎？聊聊「大海撈針」測試背後的真相與實際工程陷阱

最近大型語言模型廠商在捲一個指標：上下文視窗（Context Window）。從 32k 到 128k，再到 1M 甚至 10M。很多開發者看到這個數字就興奮了，覺得以後不需要做 RAG（檢索增強生成），直接把整個專案程式碼庫或者幾百篇文件全部塞進 Prompt 就行。

但作為在 SFD 實驗室每天跟 Agent 打交道的工程人員，我想告訴你：不要迷信長上下文，它在很多時候是個「昂貴的幻覺」。

什麼是「大海撈針」（Needle In A Haystack）？

為了證明長上下文的有效性，業界流行一種測試叫 Needle In A Haystack。簡單來說，就是在一段極長的無關文本（乾草堆）中，隨機插入一個無關的事實（針），然後問模型這個事實是什麼。

如果模型能準確答出，就說明它在長上下文中具有良好的檢索能力。很多模型在 128k 甚至 1M 的測試中都能拿到接近 100% 的分數。

但這裡有一個巨大的工程陷阱：「撈針」不等於「理解」。

真相 1：Lost in the Middle（中間遺失現象）**

早期的研究（如史丹佛大學的論文）發現，模型對資訊的提取能力呈 U 型分佈：它能很好地記住 Prompt 的開頭和結尾，但對於位於中間部分的資訊，召回率會大幅下降。

雖然現在的模型透過訓練優化減輕了這個問題，但在實際生產環境下，當你塞入 10 萬個 token 時，模型依然傾向於給開頭和結尾更高的權重。如果你把最關鍵的業務邏輯放在文件中間，模型很有可能在生成答案時將其忽略，或者產生幻覺。

真相 2：推理品質隨長度下降**

這是一個被廠商掩蓋的細節：上下文越長，模型的推理能力（Reasoning）往往越弱。

當你給模型提供極少量的精準資訊時，它能進行深度的邏輯推演；但當你給它提供海量資訊時，模型會進入一種「檢索模式」而非「思考模式」。它傾向於在文本中尋找原話並進行簡單的拼接，而不是綜合多處資訊進行複雜的分析。

我們在 SFD Lab 做過一個對比實驗：
- 方案 A (RAG)：檢索出最相關的 3 段話 $\rightarrow$ 模型分析 $\rightarrow$ 輸出結論。
- 方案 B (Long Context)：直接塞入所有相關文件 $\rightarrow$ 模型分析 $\rightarrow$ 輸出結論。

結果發現，方案 B 在處理簡單事實查詢時速度快且準確，但在處理需要跨文件對比、邏輯推演的任務時，錯誤率比方案 A 高出約 20%。

真相 3：成本與延遲的指數級增長**

即便不考慮品質問題，長上下文在工程上也是極其昂貴的。

LLM 的 Attention 計算複雜度在理論上是序列長度的平方 $O(n^2)$。雖然現在有了 FlashAttention 等優化技術將其降低到線性或近線性，但 KV Cache 的顯存佔用依然是硬傷。

如果你給每個用戶都開一個 1M 的上下文視窗：
1. 首 token 延遲 (TTFT)：預填充（Prefill）階段會變得極其緩慢。你可能需要等待數秒甚至數十秒才能看到第一個字跳出來。
2. 顯存壓力：KV Cache 會迅速吃掉所有可用顯存。這意味著你的併發量會斷崖式下跌——原本一台伺服器能支撐 50 個併發用戶，現在可能只能支撐 5 個。

工程建議：如何正確對待長上下文？

既然長上下文有坑，是不是就不用了？當然不是。正確的做法是將它作為 「短期工作記憶體」 而非 「長期知識庫」。

1. RAG $\rightarrow$ Long Context 的兩級跳

不要直接塞全量資料。採用「粗篩 $\rightarrow$ 精篩 $\rightarrow$ 長上下文」的鏈路：
- 用向量資料庫做粗篩（召回 top-50 chunks）。
- 用一個小模型或重排序模型（Reranker）做精篩（選出 top-5 chunks）。
- 將這 top-5 精準內容放入長上下文視窗中交給強模型處理。

2. 給關鍵資訊加權重

如果你必須使用長上下文且擔心遺失資訊，嘗試將最核心的指令、約束條件重複放在 Prompt 的開頭和結尾各一次。這種簡單的冗餘操作能顯著提高模型的遵循率。

3. 設定「截斷閾值」

在工程實現上，為你的 Agent 設定一個合理的 context limit（例如 32k 或 64k）。一旦超過這個閾值，強制觸發總結機制（Summarization）或清理歷史記錄 $\text{Memory Cleanup}$，而不是無限制地增加視窗長度。

SFD 編者註

我們經常聽到有人說：「現在有了 Gemini/Claude 的百萬視窗，RAG 已死。」這完全是誤導。

RAG 的本質是 「高效的資訊索引」；而長上下文的本質是 「寬廣的注意力範圍」。索引是為了快速定位 $\text{Find}$，注意力是為了深度加工 $\text{Process}$。兩者不是替代關係，而是協作關係。

在 SFD Lab 的實踐中，我們依然堅持用 Qdrant 做底層索引 + MEMORY.md 做結構化記憶 + 短上下文做即時推理。因為在生產環境下，「穩定且可預測」永遠比「參數看起來很牛」更重要。