context_length_exceeded / prompt is too long——不會削弱應用程式能力的修正方法

每個模型都有上下文視窗；這個 400 錯誤表示提示詞加上要求的輸出超出了視窗容量。最直覺的修正方式——盲目截斷提示詞——會讓 RAG 應用程式在不知不覺中變笨。以下說明如何在不失去重點的情況下，讓內容符合視窗限制。

錯誤

response (HTTP 400)

// Anthropic:
{"type":"error","error":{"type":"invalid_request_error",
 "message":"prompt is too long: 214481 tokens > 200000 maximum"}}

// OpenAI-compatible:
{"error":{"type":"invalid_request_error","code":"context_length_exceeded",
 "message":"This model's maximum context length is 128000 tokens..."}}

原因與解決方法一覽

原因	解決方法
無上限的對話歷史記錄	保留滾動視窗，並持續更新摘要；不要在每一輪都重新傳送完整的對話紀錄。
RAG 檢索的區塊過多或過大	檢索數量更少、大小更小且經過重新排序的區塊——早在上下文視窗填滿之前，品質就已比數量更重要。
max_tokens 超過剩餘可用空間	上下文視窗涵蓋輸入與輸出：可用預算 = 視窗大小 − 輸入大小。請依剩餘容量設定 max_tokens。
工作負載確實需要更多上下文	改用長上下文模型層級（例如具備 100 萬 token 視窗的模型），而不是費心設計工程方案來勉強塞進現有視窗。

先測量，再刪減

以與 API 相同的方式計算 token（Anthropic 提供 count_tokens 端點；tiktoken 可近似計算使用 OpenAI 協定的模型的 token 數）。記錄每次請求的 token 數——達到上限的 1.05 倍與 5 倍時，需要不同的修正方式。

刪減檢索內容與歷史紀錄，絕不要刪減指令

依此順序刪減：(1) 過時的對話輪次 → 摘要；(2) 檢索到的片段 → 重新排序並保留 top-k；(3) 冗長的少樣本範例 → 減少數量並精簡內容。系統指令最後才處理——行為就是在那裡定義的。

若問題源於工作負載本身的結構性需求，就升級至更大的上下文視窗

如果合理的輸入每週都超過視窗上限，那就是模型選擇的問題。長上下文層級（200K–1M）正是為了合約分析、程式碼庫問答與多文件工作而設——請比較升級成本與目前花在刪減內容上的工程時間。

如果你透過 Kunavo 呼叫

Kunavo 的目錄透過一把金鑰提供多種上下文層級，包括上下文視窗為 1M 的 Claude 5 系列模型。因此，將工作負載從 200K 視窗升級至 1M 視窗，只需變更模型字串。每個模型頁面都會在每 token 價格旁標示其視窗大小，方便評估這項取捨的預算。

常見問題

max_tokens 會計入上下文視窗嗎？

會——視窗限制涵蓋輸入加上生成的輸出。上下文視窗為 200K 的模型，若提示詞已占 195K，就無法滿足 max_tokens: 8000。請計算剩餘空間，並將 max_tokens 限制在該數值以內。

提示詞快取能解決上下文溢位嗎？

不能——快取會降低重複長提示詞的成本，而不會縮小其大小。無論是否快取，計入視窗的 token 數量都相同。