目標先講清楚：
推崇Drew Breunig的blog探討上下文失敗的原因，及他所分享如何處理的方法作為結束
巨大的上下文窗口是一種強大的能力，但如果將上下文視為一個雜物櫃，那麼這些雜物將會影響您的回應 - 垃圾進，垃圾出 (Garbage in, garbage out)
| 問題類型 | 造成原因 | 會產生什麼影響 | 舉例 |
|---|---|---|---|
| 上下文毒化(Context Poisoning) | 幻覺或錯誤資訊被寫進 context，並被模型反覆引用時。 | 代理被「錯誤目標」帶著走，形成無法達成或不相關的策略與重複行為。 | Gemini 2.5 打寶可夢時，若「goals」區塊被污染，代理就會追逐不可能的目標、反覆嘗試錯誤策略。 |
| 上下文分散(Context Distraction) | 上下文變得太長，模型過度關注上下文，而忽略了它在訓練期間學到的內容 | 模型傾向重複過去動作、難以綜合出新計畫；在較小模型上「分心上限」更低，正確率提早下滑。 | （1）Pokémon 案例：超過 ~100k token 後，代理更傾向重複歷史動作而非規劃新策略。（2）Databricks：Llama-3.1-405B 約 32k 開始掉準，更小模型更早失真。 |
| 上下文混亂(Context Confusion) | 模型利用上下文中的多餘內容來生成低品質的回應 | 生成低品質回應、誤用或亂用工具；提供的工具越多，表現越差，甚至在工具全合規的情況下仍會做不該有的 function call。 | （1）Berkeley Function-Calling Leaderboard：一旦給超過一個工具，各家模型表現全面變差，且有時在「沒有相關工具」時仍會硬調用工具。（2）GeoEngine：對量化後的 Llama 3.1 8B，一次給 46 個工具會失敗，只給 19 個就成功。 |
| 上下文衝突(Context Clash) | 組裝起來的上下文包含了模型在尚未獲得所有資訊之前試圖回答挑戰的早期不正確嘗試。這些不正確的答案仍然存在於上下文中，並在模型生成最終答案時影響它 | 多輪（分片式）輸入導致平均表現大幅下滑，模型在早期錯誤假設上「迷路」且無法復原。 | Microsoft & Salesforce 實驗把單一長提示改成多輪「分片」後，平均分數掉 39%；例如 OpenAI o3 從 98.1 掉到 64.1。原因是早期嘗試的錯誤答案殘留在 context，影響最終推理。 |
| 方法 | 定義 | 相關文章 |
|---|---|---|
| RAG | 有選擇地添加相關資訊，以幫助大型語言模型 (LLM) 生成更好的回應 | 如同 Day 17 ~ Day 19 介紹的 mem0、Day 20 分享的 RAG 策略及 Day 21 分享使用 airbyte 進行 RAG 資料更新 |
| 工具載入 (Tool Loadout) | 只把與當前任務相關的工具定義放進 context。 | 如同 Day 25 有提到 Manus.ai 使用遮罩的方式去載入工具 |
| 上下文隔離區 (Context Quarantine) | 將不同任務/子任務的上下文隔離在各自的執行緒，由一個或多個 LLM 分別使用。 | Day 16 分享 LangGraph 框架透過不同的 agent 有獨立的 state |
| 上下文修剪 (Context Pruning) | 移除上下文中不相關或不需要的資訊。 | - |
| 上下文摘要 (Context Summarization) | 把累積的上下文濃縮為摘要。 | Day 15 提到 OpenAI Agent SDK 用簡單的寫法，就可以使用壓縮去處理記憶 |
| 上下文卸載 (Context Offloading) | 把資訊存放在 LLM 上下文之外 | Day 18 分享 mem0 的 MCP 工具，在需要的時候 LLM 可以呼叫 MCP 調用之前的記憶 |
完賽心得：感謝鐵人賽的主辦方舉辦這樣的活動；透過參加活動，再次梳理過去的知識點。
iThome鐵人賽
看影片追技術