長上下文的陷阱：為何模型總是忽略中間的關鍵資訊？

大型語言模型的上下文視窗（context window）競賽看似永無止境，從數千 token 擴展到百萬級別，給人一種能處理無限資訊的錯覺。然而，實務證明這是一廂情願。研究顯示，即使在巨大的上下文長度中，模型對資訊的注意力分佈並不均勻，存在顯著的「中間遺忘」（Lost in the Middle）現象。這意味著，決定回答品質的關鍵，並非塞入多少資料，而是如何策略性地設計資訊佈局，也就是所謂的「上下文工程」（context engineering）。

「中間遺忘」：上下文長度的 U 型效能詛咒

當我們將大量文件、對話紀錄或程式碼一次性餵給大型語言模型（LLM）時，我們直覺地假設模型會平等地對待所有資訊。但 2023 年由史丹佛大學、UC Berkeley 與 Samaya AI 共同發表的論文 《Lost in the Middle: How Language Models Use Long Contexts》 徹底打破了這個迷思。

研究人員透過在長篇文件中插入特定事實（俗稱「大海撈針」測試）並要求模型回憶，發現模型的檢索成功率呈現一個明顯的 U 型曲線。換句話說，模型對於上下文開頭與結尾的資訊記憶最為清晰，檢索準確率最高；但對於被夾在中間的大量內容，其注意力會顯著下降，導致關鍵資訊被忽略或誤解。

這個現象不僅存在於早期的模型，即使是上下文能力大幅提升的 Claude 2.1 或 GPT-4 Turbo 等模型，在特定條件下也依然存在類似的效能衰減。這告訴我們，更大的上下文視窗僅僅是提供了更大的「工作台」，但如果我們只是隨意地把工具和材料扔在上面，找到真正需要的東西依然會非常困難。

更大的上下文視窗不等於更強的有效記憶。它更像一個容量更大的暫存記憶體，如果沒有好的資訊管理策略，資料存得進去，卻不代表能被有效提取出來。

為什麼會發生「中間遺忘」現象？

這個現象的根源，很可能與 Transformer 架構中的注意力機制（attention mechanism）以及模型的預訓練方式有關。以下是幾個可能的解釋：

• 位置偏見（Positional Bias）：在典型的對話或指令遵循任務中，最重要的資訊通常位於開頭（如系統指令、使用者角色設定）或結尾（如使用者提出的最後一個問題）。模型在龐大的訓練資料中，可能學會了優先關注這兩個位置，而將中間部分視為相對次要的補充資訊。
• 注意力飽和與稀釋：當上下文長度急遽增加，模型有限的「注意力資源」需要分配到更多的 token 上。這會導致對每個特定 token 的關注被稀釋。位於中間的資訊，如果沒有特別的結構或標記來凸顯其重要性，就很容易在數千、數萬個 token 中被「淹沒」。
• 訓練與微調的侷限：雖然模型的理論上下文長度很長，但其在預訓練與微調階段接觸到的長文本範例可能有限，或是在處理長文本時的訓練目標並非專門優化中間資訊的檢索。

值得慶幸的是，模型開發者也意識到這個問題。例如，Google 在其 Gemini 1.5 Pro 的技術報告中，就特別強調其透過架構改良，在長達 100 萬 token 的「大海撈針」測試中實現了接近 100% 的召回率。這顯示「中間遺忘」是個工程問題，而非無法克服的理論限制。但在這些先進模型普及之前，我們開發者必須學會如何主動管理上下文。

如何透過「上下文工程」克服這個限制？

與其被動等待模型進化，不如主動出擊！所謂的「上下文工程」，就是透過設計資訊的呈現方式，引導模型將注意力放在我們認為最關鍵的地方。這不是什麼黑魔法，而是一系列基於實證的務實策略：

1. 策略性排序（Strategic Reordering）：這是最簡單也最有效的方法。基於 U 型曲線的觀察，我們應該將最重要的資訊，例如核心指令、關鍵數據點或使用者最重要的問題，放置在提示（prompt）的最開頭或最結尾。例如，在一個需要模型總結多份報告的任務中，可以先給出總結的指令，然後附上報告內容，最後再重申一次：「請根據以上文件，完成摘要。」
2. 結構化標記（Structured Tagging）：不要將所有資訊都以純文本形式呈現。使用類似 XML 或 Markdown 的標記來區分不同區塊的內容，可以幫助模型更好地理解文件的結構與層次。例如，將關鍵段落用 <critical_info>...</critical_info> 包起來，或為不同文件來源加上明確的標頭如 ### Document A ###。這就像是為混亂的書桌加上標籤和文件夾。
3. 分塊與檢索（Chunking & Retrieval）：這就是檢索增強生成（Retrieval-Augmented Generation, RAG）的核心思想。與其將一個 10 萬字的龐大文件庫全部塞進上下文，不如先透過一個高效的檢索系統（如向量資料庫）找出與使用者問題最相關的 3-5 個段落。然後，只將這些高度相關的「資訊精華」放入上下文中，並將它們放在開頭或結尾。這種作法不僅大幅降低了「中間遺忘」的風險，也更具成本效益。

總結來說，上下文長度是 LLM 應用程式的基礎建設，但上下文工程才是決定應用效能的建築藍圖。將所有希望寄託於無限擴展的上下文視窗，是一種既昂貴又低效的作法。作為開發者與產品設計者，我們需要從「塞更多資料」的思維，轉向「如何更聰明地呈現資料」，才能真正釋放大型語言模型的潛力。

延伸閱讀

• Liu, N. F., et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." arXiv.
• Google (2024). "Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context." Technical Report.
• Anthropic's Guide to Prompt Engineering

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。