長對話上下文工程：壓縮、摘要與分段如何守住 AI 的焦點與成本

當 AI 助理被用在跨越數十輪、甚至持續好幾小時的長對話時，最常見的抱怨不是「它不夠聰明」，而是「聊到後面它就忘了前面講的規則，回答還越來越發散」。問題根源不在模型智商，而在上下文視窗（context window）是一筆有限的 token 預算。就算 2026 年 Claude、Gemini、GPT 等前沿模型幾乎都已標配百萬 token 視窗，長對話依然會把預算一路吃光，於是關鍵約束被擠出視窗、成本加速上升、注意力也被稀釋。上下文工程，就是在這筆固定預算內，決定「留什麼、丟什麼、壓縮什麼、搬去哪」的一套工程方法。

上下文視窗是有限預算：長對話撞上的三道牆

每一段對話歷史、每一份貼進去的文件，都要佔用上下文視窗的 token 額度。對話一旦拉長，你會依序撞上三道牆：

• 容量硬牆：視窗有上限，超過就必須截斷，最早的訊息會被無聲丟棄——包含你在開頭立下的規則與限制。
• 成本與延遲牆：多數 API 依輸入 token 計費，且每一輪都會把整段歷史重送一次，長對話花費不是線性、而是加速上升。視窗大也不等於便宜：Google 對 Gemini 2.5 Pro 超過 20 萬 token 的請求，輸入單價直接從每百萬 1.25 美元跳到 2.5 美元；把百萬視窗塞滿，等於每輪都付高階費率。
• 準確度牆：研究稱為「迷失在中間（lost in the middle）」——即使資訊還在視窗內，模型對放在中段的內容注意力最弱。塞越多雜訊，關鍵指令反而越容易被稀釋。

換句話說，把視窗塞好塞滿不會讓 AI 更聰明，反而更貴、更慢、更容易失焦。上下文工程的目標，是用最少的 token 讓模型在對的時機拿到對的資訊。

「越聊越笨」不是錯覺：context rot 的研究證據

長對話變差常被當成主觀感受，但已有系統性數據佐證。史丹佛大學與加州大學柏克萊分校團隊 2024 年發表的《Lost in the Middle》發現，模型讀長文時呈現 U 型曲線：答案放在開頭或結尾時準確率最高，放在中段時明顯崩落。2025 年 Chroma 的「context rot」研究更把範圍擴大到 18 個前沿模型（含 Claude Opus 4、GPT-4.1、Gemini 2.5、Qwen3），結論一致：只要輸入 token 變多，每一個模型的表現都會下滑，而且往往在遠未觸及視窗上限前就開始掉。在其 LongMemEval 測試中，同一題目餵給模型約 300 token 的精煉上下文，準確率明顯高於餵入約 11.3 萬 token 的完整歷史；研究也發現，語意接近但不相關的「干擾段」會主動誤導模型，甚至反覆出現在它的幻覺答案裡。

這個現象的關鍵含義是：它是 Transformer 注意力機制的結構性特性，不是「換一個視窗更大的新模型」就能解決的能力缺口。既然多塞內容會傷準確率，管理上下文就不是選配，而是長對話系統的基本工程。

滑動視窗與截斷：最省力，但會失憶

最直覺的做法是滑動視窗（sliding window）：只保留最近 N 輪對話，舊的自動淘汰。它幾乎不用額外運算，實作成本最低，很適合客服問答這類「大多只需近期脈絡」的場景。代價是徹底失憶——一旦使用者在開頭設下的偏好、身分或限制被滑出視窗，AI 就會像沒聽過一樣。舉個常見的坑：使用者第一句交代「所有金額都用新台幣」，聊了三十輪後這句話早被淘汰，AI 又開始報美元。也因此，實務上很少單獨使用純截斷，通常會搭配「釘選」關鍵訊息，或在淘汰前先做摘要，避免把重要約束一起丟掉。

摘要壓縮與 compaction：把歷史濃縮成精華

與其整段丟棄，不如把舊對話壓縮成摘要再留下。常見手法是滾動摘要（running summary）：歷史累積到設定的 token 門檻時，就把較早的段落交給模型濃縮成幾句重點，用摘要取代原文再繼續對話。Anthropic 在 2025 年 9 月的上下文工程指南把這套做法稱為 compaction，並揭露 Claude Code 的實作原則——摘要時刻意保留架構決策、尚未解決的錯誤與關鍵實作細節，同時丟棄冗長的工具輸出與重複訊息。

成本效益很明顯：對話越長，「先摘要再送」相對於「整段原文重送」的省錢效果就越顯著，能大幅壓低長對話每輪的平均 token 花費。但摘要品質決定成敗：反覆壓縮會產生「上下文漂移」，精確數字、細微約束會逐輪蒸發。關鍵是明確定義「哪些欄位一定要保留」，例如訂單編號、客戶身分、已確認的決策，就該指定為摘要時必留欄位，而不是任由模型自由發揮、把重要前提也一起壓掉。

分段與外部卸載：把記憶搬出視窗，要用時再取回

當背景資料量遠超過視窗容量，正確做法不是硬塞，而是卸載（offload）：把完整歷史與文件切成語意完整的片段（chunking），存到視窗以外的外部儲存，每一輪只依當前問題檢索最相關的幾段補回視窗。這讓有效知識量不再受視窗大小限制，也直接緩解「迷失在中間」——因為進到視窗的都是與當下高度相關的內容。

切段的參數會直接左右品質。實務經驗多建議一般用途以約 512 token 為一段、段間保留一到二成的重疊，避免把橫跨邊界的關鍵事實切斷；微軟 Azure 官方文件則建議以 512 token、二成五重疊作為起始設定。分段方式上，語意切段在 Chroma 測試中最佳召回率約 91.9%，優於固定長度的 85–89%；但 Vectara 在 NAACL 2025 的研究提醒，固定 200 token 的簡單切法在真實資料上往往能打平甚至超越語意切段，該研究測試 3 個嵌入模型後發現，切段設定對檢索品質的影響力，不亞於嵌入模型的選擇。換言之，與其糾結演算法，不如把段長與重疊調對。要提醒的是，這裡談的是把「當前這場長對話」的歷史搬到視窗外隨取隨用，屬於單次對話的容量工程，與為 AI 建立跨對話、跨使用者的長期記憶庫是不同層次的問題。

關鍵資訊釘選與策略組合：別讓壓縮把約束弄丟

所有壓縮與淘汰策略都有一個共同風險——把不該丟的東西丟了。因此上下文工程必須刻意保留一組「無論如何都要在場」的關鍵資訊：常見做法是把系統指令、使用者身分與硬性限制釘選（pin）在視窗固定位置，讓它們不受滑動與摘要影響；更穩健的是把這些關鍵事實抽成結構化狀態（例如一張隨對話更新的欄位表），與可壓縮的自由對話分開管理。四種策略的取捨整理如下：

實務上這四種很少單用，而是組合成一套流水線：關鍵約束釘選、近期對話保留原文、較舊的摘要壓縮、龐大背景卸載到外部檢索。有團隊把滑動視窗、相關性檢索與結構化狀態組合後，平均每次請求的 token 從約 1.8 萬降到 6,500，減少約 64%，回答品質卻沒有下降。組合的比例，取決於你的對話有多長、成本容忍度多高、以及哪些資訊絕對不能漏。

恩梯科技如何協助設計上下文工程

長對話的穩定表現，靠的不是換一個視窗更大的模型，而是一套把 token 預算花在刀口上的上下文工程。恩梯科技在協助企業導入 AI 助理與 Agent 時，會先量測實際對話長度、成本上限與必須保留的關鍵資訊，再設計滑動、摘要壓縮、分段卸載與關鍵資訊釘選的組合策略，並用可觀測的指標驗證準確率與每輪成本，讓 AI 在長對話裡既守得住焦點、控得住成本，又不會在關鍵時刻忘記你最早交代的那條規則。把上下文管好，AI 才能從「會聊天」進化成「聊得久也靠得住」。

參考資料

• Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts（Stanford University／UC Berkeley／Samaya AI，arXiv 2307.03172）
• Chroma, Context Rot: How Increasing Input Tokens Impacts LLM Performance
• Anthropic, Effective Context Engineering for AI Agents（2025 年 9 月）
• Google, Gemini Developer API Pricing
• Microsoft Learn, Chunk Documents - Azure AI Search
• Chroma, Evaluating Chunking Strategies for Retrieval
• Renyi Qu et al., Is Semantic Chunking Worth the Computational Cost?（Vectara，NAACL 2025 Findings）
• How We Handle LLM Context Window Limits Without Losing Conversation Quality