上下文工程
1. 3秒看懂
上下文工程是設計、組裝與動態管理輸入給大語言模型（LLM）的資訊結構的系統方法論。它決定了模型在單次推論中能“看到”並“理解”的上下界——不只包含提示詞怎麼寫，更包含對話歷史如何壓縮、外部檢索結果如何編排、以及在動輒十萬甚至百萬 token 的上下文窗口裡如何把有限的注意力預算分配到最關鍵的資訊片段上，使模型產生符合預期的輸出。
2. 3分鐘產業解釋
可以把上下文工程理解為大型模型的“工作記憶管理師”。大語言模型擁有一次性容納的文本長度上限（上下文視窗），當我們需要解決複雜問題——分析數百頁財報、除錯跨檔案程式碼、操作帶長期記憶的自主智慧代理——就要向模型塞進大量背景資料、工具呼叫結果和多輪對話記錄。然而視窗越長，推論成本越高，模型越容易在長文本中“迷失重點”。上下文工程要回答的核心問題就是：在給定的視窗內，放什麼、怎麼放、何時更新、何時遺忘。
工程手段包括動態提示組裝、檢索增強生成（RAG）、對話壓縮與摘要、結構化資訊抽取、思維鏈編排、多智慧代理上下文共享等。產業實踐中，上下文工程是連線基礎模型能力與真實業務場景的最後一公里——既影響最終輸出質量，又直接決定推論成本和延遲。因此，它正從“調提示的小技巧”上升為一種基礎設施能力，被企業視為提高大型模型應用可靠性和經濟性的關鍵槓桿。
3. 技術原理
上下文工程的底層依賴 Transformer 的自注意力機制：每個 token 都需與序列中所有其他 token 計算注意力權重，導致計算複雜度為 O(n^2)，其中 n 為上下文 token 數。這是所有長上下文工程實現的根本瓶頸。
關鍵機制：
- 位置編碼：為模型注入序列順序感。旋轉位置編碼（RoPE）是當前長上下文擴充套件的主流基礎，通過調整基頻可將上下文視窗外推到訓練時未見過的長度。部分模型也採用 ALiBi 等線性偏置實現外推。
- KV 快取：推論時快取歷史的 Key、Value 矩陣，避免重複計算。快取大小與上下文長度、層數、隱藏維度成正比，帶來了顯著的視訊記憶體壓力和訪存頻寬需求。
- 注意力稀疏化與視窗劃分：為了降低複雜度，部分方案強制 token 只注意到區域性視窗或預設的摘要 token，代價是可能損害全域性連貫性。
- “迷失中間”效應：模型對上下文開頭和結尾的資訊往往記得更牢，而對中間部分容易忽略（Liu et al., 2023）。上下文工程需要通過分段、索引、顯式標題等結構將關鍵資訊推入注意力的有效區域。
上下文組裝典型流程（ASCII 圖）
輸入源：
[系統指令] + [對話歷史摘要] + [檢索到的片段1,2,3] + [使用者當前提問]
┌───────────────────────────────┐
│ 上下文組裝器 (排序、去重、截斷) │
└──────────────┬────────────────┘
│ 填入上下文視窗 (如 128k tokens)
▼
┌──────────────────────────────────────────────┐
│ 模型推論時，注意力矩陣覆蓋整個視窗 │
│ 關鍵資訊最好位於視窗頭部或尾部， │
│ 或通過結構化標記提升中間內容的注意力權重 │
└──────────────────────────────────────────────┘上下文汙染也是重要關注點：過多無關或低質量資訊會導致模型輸出質量下降，因此需要設計過濾、去重和優先順序排序機制。此外，在長時間執行的任務（如客服、自主代理）中，上下文會不斷膨脹，必須引入遺忘策略、遞迴壓縮和關鍵事實提取，以維持資訊的相關性和一致性。
4. 關鍵引數
- 上下文視窗長度：模型廠商設定的最大 token 數上限。目前主流閉源模型處於 128k–200k 區間，部分模型宣告可達 1M token（如 Gemini 1.5 Pro，來源：Google AI Blog，2024年2月），開源模型常見 4k–128k。
- 有效上下文利用率：模型實際能從長文本中準確檢索資訊的比例。根據 Liu et al.（2023）的“大海撈針”實驗，在文件中間位置的關鍵資訊召回準確率較首尾可下降 20 個百分點以上，表明視窗長度與有效利用並非線性關係。
- 關鍵資訊召回率：給定長文件中分散的多條事實，模型能正確提取的比例。在多跳問答場景中，該指標直接反映上下文編排質量。
- 上下文汙染率：無關資訊引發輸出錯誤的機率增幅。衡量資訊過濾與優先順序排序策略的成效。
- 推論延遲增長係數：上下文長度每翻倍時延遲增加的倍數。理想情況為線性增加，但實際因
O(n^2)注意力計算常表現為超線性增長，受硬體、稀疏化策略影響。 - KV 快取佔用：單位 token 佔用的視訊記憶體量（約
2 × 層數 × 隱藏維度 × 精度位元組），直接影響最大併發和硬體成本。以 7B FP16 模型為例，單 token 的 KV 快取約 0.3 MB，128k token 則達約 38 GB（未最佳化前，來源：基於公開 Transformer 架構推算）。 - 壓縮率與保真度：應用上下文壓縮（如摘要、遞迴記憶）後，壓縮資訊在下游任務上的效能保持度，通常以 ROUGE/BERTScore 與任務準確率聯合評估。
5. 技術路線
| 技術路線 | 典型視窗規模 | 核心機制 | 推論延遲 | 上下文利用率 | 工程複雜度 | 適用場景 |
|---|---|---|---|---|---|---|
| 短上下文 + 豐富提示 | 2k–8k tokens | 純提示工程，拼接指令與少量示例 | 低 | 高（資訊密集） | 低 | 簡單任務、單輪問答 |
| 檢索增強生成（RAG） | 8k–32k tokens | 外部檢索 + 片段插入與排序 | 中 | 中（依賴檢索質量） | 中 | 知識問答、文件分析 |
| 長上下文原生支援 | 32k–200k tokens | 模型原生擴充套件位置編碼，滿視窗注意力 | 高（O(n²)） | 中（存在“迷失中間”） | 中高 | 長文件摘要、程式碼庫分析 |
| 超長上下文 + 智慧壓縮 | 200k–1M+ tokens | 遞迴摘要、結構化分段索引、選擇性注意力與持久記憶 | 很高 | 中等偏高 | 高 | 長篇多輪對話、自主智慧代理 |
注：視窗規模為行業常見公開揭露區間，非精確規格，2024年資料；延遲與利用率基於定性評估及公開研究報告。
6. 上游
上下文工程的上游主要包括以下幾類供給要素：
- 基礎模型能力：上下文視窗長度、位置編碼機制（如 RoPE 外推能力）、注意力實現（快閃記憶體注意力等）直接決定工程可行性。代表供給方為 OpenAI、Anthropic、Google DeepMind 等閉源廠商，以及 Meta、Mistral、阿里 Qwen 等開源社群。
- 存內/近存計算硬體：大容量高頻寬視訊記憶體（HBM）是長上下文推論的核心硬體約束。NVIDIA H200（2024 年發售）提供 141 GB HBM3e，頻寬 4.8 TB/s；AMD MI300X 提供 192 GB HBM3（來源：NVIDIA、AMD 官方規格 2024）。更高 KV 快取容量和頻寬能夠支撐更長的上下文和高併發推論。
- 向量資料庫與檢索系統：為 RAG 型上下文提供高質量片段。召回率、排序精度、混合檢索能力（稠密+稀疏）直接影響上下文組裝質量。主流系統包括 Pinecone、Weaviate、Milvus、Chroma 等。
- 提示編排架構：LangChain、LlamaIndex、Microsoft Semantic Kernel 等提供了高層次抽象，將碎片化的上下文工程元件標準化，顯著降低開發成本。
7. 下游
上下文工程的下游覆蓋幾乎所有需要將 LLM 應用於長週期、複雜認知任務的場景：
- 智慧代理與多步推論：任務分解、工具呼叫、觀察與反思的歷史連結，要求上下文保持連貫、精簡、無汙染。典型應用如程式碼智慧代理（Devin, SWE-Agent）、作業系統智慧代理。
- 企業級 RAG 應用：客服、合規審查、內部知識庫等場景依賴長文件檢索和高質量片段編排，上下文工程直接影響答案准確率與幻覺率。
- 長文本理解與生成：分析論文、法律文書、基因序列、大型程式碼倉庫，要求模型在數萬 token 上下文內精確定位資訊。
- 個性化助手與持久記憶：通過使用者畫像動態注入、跨會話記憶更新，實現“認識你，記住你”的體驗。
- AI 原生工作流：自動報告生成、多文件交叉驗證等，依賴結構化上下文注入和動態更新。
8. 受益公司
上下文工程作為系統能力層，受益方分佈於基礎設施、工具平台和行業應用等多個環節。以下根據公開資訊梳理受益的產業角色（不構成投資建議）：
| 型別 | 代表公司 / 專案 | 在上下文工程中的受益邏輯 |
|---|---|---|
| 長上下文模型先鋒 | OpenAI (GPT-4o/o1), Anthropic (Claude 3.5), Google (Gemini 1.5) | 原生支援超長視窗與記憶功能，定義能力邊界，吸引複雜任務客戶 |
| 上下文編排與中介軟體 | LangChain, LlamaIndex, Microsoft Semantic Kernel | 提供 RAG、智慧代理上下文管理的抽象架構，降低工程門檻，成為“上下文作業系統” |
| 記憶與持久化上下文 | Mem0, Letta (原MemGPT), OpenAI Memory 功能 | 實現跨會話持久化記憶管理，拓展大型模型應用場景 |
| 向量資料庫與檢索 | Pinecone, Weaviate, Chroma, Milvus | 提供高效能檢索，是上下文供給的關鍵元件，受益於 RAG 需求增長 |
| 推論硬體 | NVIDIA (H100/H200/B200), AMD (MI300X) | 高頻寬視訊記憶體提升 KV 快取容量，支撐長上下文推論，直接受益於上下文規模擴張 |
| 開源長上下文模型社群 | Meta (Llama 3.1), Mistral, Qwen 系列 | 推動低成本長上下文工程策略，降低使用門檻 |
9. 市場規模
公開資料未見專門針對“上下文工程”的獨立市場報告，其價值附著於 LLM 應用平台、向量資料庫、MLOps 工具等關聯市場。可觀測的關聯規模如下：
- 向量資料庫市場：據 MarketsandMarkets 2023 年 9 月報告，全球向量資料庫市場規模 2023 年約為 15 億美元，預計 2028 年達到 43 億美元，複合年增長率約 23.2%（來源：MarketsandMarkets, Vector Database Market Report, 2023）。
- 檢索增強生成 (RAG) 相關市場：上下文工程在很大程度上牽引 RAG 工具鏈需求。行業分析機構 Fortune Business Insights 指出，2023 年全球自然語言處理市場規模為 327.2 億美元，預計 2030 年增至 1568.0 億美元（來源：Fortune Business Insights, 2024）。RAG 與企業搜尋智慧化的滲透率提升，將持續為上下文工程工具鏈提供增長動力。
- LLMOps/大型模型運維工具：據 Grand View Research 2023 年報告，MLOps 市場 2022 年約 12 億美元，2030 年有望超過 100 億美元，其中上下文組裝與監控工具被視為新增細分。
上述資料表明，上下文工程雖無獨立測算口徑，但作為基礎設施層能力，其商業價值蘊含在百億美元級關聯市場中。
10. 玩家對比
| 玩家 / 模型 | 最大公開上下文視窗 | 是否內建記憶/持久化 | “迷失中間”緩解策略 | 生態與工程支援 |
|---|---|---|---|---|
| OpenAI GPT-4o / o1 | 128k tokens | 提供 Memory 功能（跨對話） | 系統提示展望與檢索增強；最佳化長上下文微調 | LangChain/LlamaIndex 深度整合，多模態 |
| Anthropic Claude 3.5 Sonnet | 200k tokens | 專案記憶（Projects） | 提示快取（Prompt Caching）降低重複成本，大規模最佳化“大海撈針”表現 | API 質量高，長文件分析見長 |
| Google Gemini 1.5 Pro | 1M tokens（研究環境 2M） | 無獨立記憶產品，依賴開發者實現 | 基於稀疏 MoE 與高效注意力，長上下文檢索實驗表現突出 | Google Cloud 生態，Vertex AI 整合 |
| Meta Llama 3.1 / 3.2 | 128k tokens | 無內建 | 開源可微調，社群探索 RoPE 外推和壓縮策略 | 開源社群廣泛，支援多架構 |
| Mistral Large 2 | 128k tokens | 無內建 | 位置編碼支援長上下文，準確率穩定 | 歐洲及企業級部署 |
| 阿里 Qwen 2.5 | 128k tokens（部分量化版可達 1M） | 無內建 | 提出 Dual Chunk Attention 等改進，大海撈針準確率高 | 開源生態，多語言能力強 |
注：資料基於各公司 2024 年公開文件與第三方評測，記憶/持久化功能指原生產品化狀態。
11. 風險
- 技術天花板不透明：長上下文視窗的“可用”與“好用”之間存在顯著鴻溝。“大海撈針”測試表明，多數模型在上下文中間區域的可靠檢索仍不理想，可能影響高準確率場景的交付。
- 成本非線性增長：長上下文推論的視訊記憶體佔用和計算量攀升，在超長視窗下可能導致推論延遲和經濟成本難以控制，削弱應用的經濟可行度。
- 模型原生能力吞噬工程層：若未來基礎模型在長上下文理解和記憶方面取得根本性突破（例如近乎完美且成本極低），當前大量中介軟體和編排方案的價值空間可能被壓縮。
- 隱私與資料安全：上下文中往往包含企業敏感資訊、個人對話歷史。持久化記憶和片段快取使得資料治理、合規（如 GDPR）和防洩露挑戰更為突出。
- 標準碎片化：各模型廠商的上下文格式、記憶介面、工具呼叫協議不統一，導致上下文工程層需要適配大量定製邏輯，增加開發和維護成本。
- 評估基準缺失：缺乏統一、被業界公認的上下文工程效能基準，使得方案選型和最佳化缺乏客觀座標系。
12. 誤讀糾偏
-
誤讀1：“上下文視窗越大越好，就不會有資訊丟失了。” 糾偏：視窗大小不等於有效利用。大量實測表明，諸多百萬 token 視窗的模型在中間區域的資訊召回率大幅低於首尾區域（Liu et al., 2023）。若不配合分段、摘要和位置最佳化，盲目塞滿長文本反而引入噪聲，降低輸出質量。
-
誤讀2：“上下文工程就是提示工程2.0。” 糾偏：提示工程關注單條指令的措辭與少樣本示例設計，是上下文工程的一個子集。上下文工程還包括檢索增強、記憶管理、結構化資訊注入、跨智慧代理上下文共享等系統性設計，更接近資訊架構與認知負載排程的複合學科。
-
誤讀3：“只要交給 RAG 就能解決長上下文問題。” 糾偏：RAG 雖能減輕上下文壓力，但其效果嚴重依賴檢索質量、片段排序和資訊去重。錯誤或無關的檢索片段同樣會造成上下文汙染，無法替代長上下文理解本身對資訊內部關聯的精細建模。
13. 最新事件
- 2024年2月：Google 釋出 Gemini 1.5 Pro，上下文視窗達到 1M token（提供研究環境 2M），首次在大規模多模態模型中實現實用化百萬級上下文（來源：Google AI Blog，2024年2月15日）。
- 2024年4月：Meta 釋出 Llama 3 系列，初始 8k 視窗，後續推出 128k 版本，並開源權重，推動長上下文開源生態（來源：Meta AI 官方釋出）。
- 2024年6月：Anthropic 推出 Claude 3.5 Sonnet，200k 上下文視窗，並引入 Prompt Caching 功能以降低重複上下文成本，在“大海撈針”等長上下文測試中取得領先（來源：Anthropic 官方部落格）。
- 2024年9月：OpenAI 釋出 o1-preview 和 o1-mini 模型，支援 128k 上下文，並將記憶體功能融入推論鏈條，進一步強化長鏈推論與上下文管理（來源：OpenAI 官網）。
- 2024年9月：阿里雲端釋出 Qwen 2.5 系列，支援 128k 原生上下文，其中部分量化版本可擴充套件至 1M，並提出 Dual Chunk Attention 等長文最佳化機制（來源：Qwen 官方部落格）。
- 2024年10月：記憶管理平台 Mem0 釋出更新版本，增強與 LangChain 等架構的上下文持久化整合，引發業界對“上下文即服務”的關注（來源：Mem0 GitHub 及官方公告）。
- 2024年11月：行業大會（如 COLM、NeurIPS 相關研討會）出現多個關於上下文壓縮、遞迴記憶和注意力動態剪枝的前沿工作，標誌著上下文工程學術界與工業界的加速融合。
14. 追蹤指標
- 有效上下文利用率：通過標準化“大海撈針”（Needle-in-a-Haystack）或多文件問答基準，追蹤模型在不同位置、不同文件長度的關鍵資訊召回率。
- 關鍵資訊召回率與汙染率：建置專屬評測集，衡量上下文組裝策略在真實企業場景下的資訊提取精度和噪聲引入比例。
- 推論延遲與成本指數：記錄上下文長度翻倍時，推論端到端延遲和視訊記憶體佔用（KV 快取）的增幅，監控線性度偏離。
- 壓縮保真度：對比上下文壓縮（摘要、遞迴記憶）前後在下游任務上的準確率變化，評估壓縮策略的可用性。
- 記憶永續性命中率：針對帶記憶的系統，追蹤跨會話中使用者畫像、歷史事實的召回準確性，衡量記憶系統的可靠度。
- 工具/智慧代理上下文連貫性：在多步智慧代理任務中，記錄因上下文缺失或錯誤導致的工具呼叫失敗率和任務完成率。
- 生態相容成本：衡量為適配不同模型廠商、編排架構所需的適配程式碼量和維護開銷，指導工程抽象層級的選擇。
15. 信源
- 論文：Vaswani et al., Attention Is All You Need, 2017.
- 論文：Su et al., RoFormer: Enhanced Transformer with Rotary Position Embedding, 2021.
- 論文：Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023.
- 論文：Gao et al., A Survey on Retrieval-Augmented Generation, 2023.
- 行業報告：MarketsandMarkets, Vector Database Market Report, 2023年9月.
- 行業報告：Fortune Business Insights, Natural Language Processing Market, 2024.
- 行業報告：Grand View Research, MLOps Market Size & Share, 2023.
- 官方文件：OpenAI Platform Documentation (Memory, 上下文視窗), 2024.
- 官方部落格：Anthropic Blog (Claude 3.5 Sonnet, Prompt Caching), 2024.
- 官方部落格：Google AI Blog (Gemini 1.5 Pro), 2024年2月.
- 開源專案：LangChain、LlamaIndex、Mem0、Letta GitHub 倉庫及文件.
- 硬體規格：NVIDIA H200 Datasheet, AMD MI300X Official Specifications, 2024.
注：財務與市場資料均標明年份、口徑及來源，對無法獨立核實的資料以“公開資料未見”表述；本內容不包含任何形式的投資建議或買賣推薦。