別再把所有東西塞進 Prompt：談 AI 的上下文架構與記憶索引

打造高效能 AI 系統的關鍵，已非追求無上限的 Context Window，而是設計精巧的「上下文架構」（Context Architecture）。許多開發者直覺地將所有資料塞進 Prompt，期望模型自行消化。然而，這種「全量化」策略不僅成本高昂，更會因引入大量雜訊而稀釋關鍵資訊，導致模型推理能力下降。一個更成熟的作法，是將知識「索引化」，透過智慧路由與最小必要原則，動態載入真正相關的上下文。這才是通往可規模化、高效率 AI 協作的務實路徑。

為什麼把所有知識都塞進 Prompt 是一個壞主意？

近年來，我們看到大型語言模型（LLM）的 Context Window 競賽愈演愈烈。從 Anthropic 的 Claude 3 提供 200K token，到 Google Gemini 1.5 Pro 將其擴展到 1M token，理論上這讓 AI 能夠「閱讀」整本書或整個程式碼庫。這帶來一種誘人的錯覺：只要把所有資料都餵給模型，問題就解決了。

然而，實務證明這是一條歧路。Google DeepMind 的研究人員在論文 〈Lost in the Middle: How Language Models Use Long Contexts〉中明確揭示了「大海撈針」（Needle in a Haystack）問題。實驗顯示，當關鍵資訊被放置在大量無關文本（Haystack）的中間時，模型的召回率會顯著下降。換句話說，過長的上下文本質上是雜訊，它會干擾模型的注意力機制，使其難以聚焦於真正重要的部分。

這不僅是理論問題，更是工程與成本的現實。每一次攜帶龐大上下文的 API 呼叫，都意味著更高的延遲與運算成本。最近我在一個專案中進行驗證，最初將大量規則與背景知識寫入一個類似 Anthropic CLAUDE.md 的核心設定檔。結果發現，模型在處理簡單任務時，反而會被那些當下無關的規則干擾，做出過度詮釋或不必要的複雜化行為。當我們將該檔案精簡到只剩下絕對規則與文件索引後，系統的反應速度與準確性都得到了顯著提升。

我們應該將 Context Window 視為一個高度專注的「工作台」，而不是一個無限大的「儲藏室」。工作台上只該放當前任務必要的工具與材料，其餘的都應存放在有條理的倉庫中，隨時等待取用。

從 Prompt Engineering 到 Context Architecture 的典範轉移

過去幾年，我們談論的重點是「提示工程」（Prompt Engineering），專注於如何用精煉的語言引導模型。但隨著 AI 系統的複雜化，我們需要將視角拉高到「上下文架構」（Context Architecture）。這意味著我們設計的不再只是一個 Prompt，而是一個完整的資訊流系統，決定了「什麼資訊、在什麼時候、以什麼形式」進入模型的注意力範圍。

這個架構的核心原則，就是從「注入」（Injection）轉向「檢索」（Retrieval）。這套架構通常包含三個關鍵組件：

• 外部知識庫（External Knowledge Base）：這是所有詳細資訊的儲藏室，例如產品文件、內部 Wiki、程式碼範例等。這些資料被預處理、分塊（chunking），並轉換成向量嵌入，存放在專門的向量資料庫中。
• 索引與路由層（Indexing and Routing Layer）：這一層是系統的大腦。當收到使用者請求時，它並非直接將請求拋給 LLM，而是先分析其意圖。它判斷這個請求是需要閒聊、執行特定功能（Function Calling），還是需要從知識庫中查找資料。
• 動態上下文生成器（Dynamic Context Builder）：在確定了任務類型後，這一層會動態地組合出一個最小且必要的 Prompt。例如，如果需要查找資料，它會執行向量搜尋，找出最相關的幾個文本片段，然後將這些片段連同原始問題一起提交給 LLM 進行最終的綜合與回答。這正是檢索增強生成（Retrieval-Augmented Generation, RAG）的核心思想。

這種分層架構，確保了送入 LLM 推理核心的上下文是高度相關且低雜訊的，從而最大化其昂貴的運算資源的效益。

如何設計一個高效的上下文管理架構？

在實作層面，我們可以將原始材料中關於 CLAUDE.md 的經驗，提升為一套通用的設計原則。一個好的上下文管理系統，應該明確區分不同層次的資訊，並避免將它們混雜在一起。例如，在系統提示中寫入長篇的 API 文件，而不是提供一個可以查詢文件的工具，就是一個常見的錯誤。那麼，正確的設計應該是：

1. 核心提示（System Prompt）保持精簡：只包含模型的角色、核心使命、絕對不可違反的規則（例如「絕對不能洩漏使用者隱私」），以及最重要的——它可用的工具（Functions/Tools）與知識庫的索引。它不包含「知識」本身，只包含「如何獲取知識」的指南。
2. 將真正的知識外部化：將詳細的文件、案例、數據等存放在外部系統中。這些系統可以是向量資料庫、傳統的 SQL 資料庫，或甚至是結構化的檔案目錄。關鍵在於它們是可被「查詢」的，而不是被「注入」的。
3. 善用工具使用（Tool Use）：與其在 Prompt 中解釋如何計算兩個數字的總和，不如提供一個 add(a, b) 的工具，並讓模型學會在需要時呼叫它。這不僅適用於計算，也適用於任何確定性的查詢或操作，例如查詢訂單狀態、讀取檔案等。

總結來說，當我們在設計 AI Agent 時，思考的焦點應該從「我該在 Prompt 裡告訴它什麼？」轉變為「我該為它準備哪些外部知識庫與工具，並教會它如何自主查詢與使用？」這種思維的轉變，是從打造一個「聽話的鸚鵡」邁向一個「能幹的助理」的關鍵一步。

隨著模型能力持續增長，決勝點將不再是誰擁有更大的 Context Window，而是誰能設計出更優雅、更高效的資訊流與記憶管理架構。將上下文視為需要精心設計的架構，而非僅僅是填充數據的容器，這將是未來 AI 應用開發的核心競爭力。

延伸閱讀

• Lost in the Middle: How Language Models Use Long Contexts (arXiv)
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv)
• A Practical Guide to Retrieval-Augmented Generation (Pinecone)

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