Context-Collapse

Properties2
tags狀態/草稿
aliasesContext Collapse, 上下文崩塌, 摘要失敗

閱讀時間約 6 分鐘

Context-Collapse

一句話定義

Context-Engineering 中的失敗模式——壓縮 / 摘要過程中把任務真正在意的資訊也壓沒了，導致摘要本身完整、但 LLM 之後本來能解的任務變不會做。命名來自 ACON paper；vault 中已知的兩個經典案例：Meta agent 收信事件、AppWorld 摘要降分。

核心要點

症狀辨識

  • 不是摘要失敗 — 摘要本身正常產出。
  • 是任務失敗 — 把摘要餵回 LLM，本來能 pass 的任務 fail 了。
  • 判別標準：壓縮後正確率下降 → 你損失了任務真正在意的資訊。
壓縮前：context  ──→  LLM ──→  正確答案 ✓
壓縮後：summary  ──→  LLM ──→  錯誤答案 ✗   ← Context Collapse

vault 已知案例

(a) Meta Agent 收信事件（2026-05-02-Harness-Engineering駕馭工程 末段）

  • Meta 研究員讓 AI agent 幫他收信。
  • agent 的 system prompt / 早期對話中明確要求「刪除郵件前需要人類同意」。
  • 隨對話累積，Claude-Code / 對應 harness 啟動 compact 自動壓縮。
  • 「刪信前要人類同意」這條最關鍵指令在壓縮時被弄丟了。
  • 結果：agent 開始亂刪信。
  • 這就是經典的 context collapse——壓縮後本來會發生的「人類確認」這個環節被略過，導致原本不會發生的事情發生。

(b) AppWorld Benchmark 摘要降分

ACON paper 的具體量化證據：

  • 三個不同 LLM 在 AppWorld 上：
    • 黑點（無壓縮）：正確率高、但 token 成本高
    • 紅點（單純 LLM summary）：token 變少了，但正確率比 baseline 還低
    • 紫點（ACON 的 collapse-aware summary）：正確率與 token 都優於前兩者

ACON 的解法（不微調模型）

用 Verbalized-Feedback 的精神改善摘要 LLM，完全不調參數：

  1. 訓練資料準備：拿失敗 trajectory（壓縮前對、壓縮後錯）給另一個 LLM。
  2. 反省階段：叫這個 LLM 對比「為什麼壓縮會讓任務變差」→ 產出一段 feedback 文字。
  3. 應用階段：下次摘要前，把這段 feedback 給負責摘要的 LLM 看 → 它就更知道哪些東西不能丟。
  4. 資料集區分 train/test 但完全沒調參——「訓練資料」是用來生 feedback 的、「測試資料」是用 feedback 強化摘要——兩階段都沒動參數。

另一條路：fine-tune 摘要 LLM（同篇 paper RL 路徑）

  • 用 reinforcement learning：摘要 LLM 產生摘要 → 之後 agent 用此摘要解任務 → 任務對 → positive reward；錯 → negative reward。
  • 隱藏好處：摘要 LLM 通常 = 解題 LLM（同一個模型），所以 RL 同時訓練了「摘要寫得好」+「根據摘要解題」兩個能力——兩者一起被優化才是真實有效。

啟示：不只看「摘要的形式」，要看「任務是否還能完成」

  • 李宏毅 在 2026-05-02-AI-Agent-Context-Engineering系統化 點題：摘要的好壞不是看摘要本身，而是看摘要被使用後 agent 還能不能完成任務。
  • 這對位 Verbalized-Feedback 中「feedback 形式要符合任務真正在意的維度」（同期 paper：產生物理模擬程式不能只看程式能跑、要看模擬視覺結果是否正確）——兩者都是評價維度要對齊真實目標的紀律。

與其他概念的關係

  • 父概念：Context-Engineering——本頁是該概念在「壓縮 F 變體失靈」的失敗模式診斷頁。
  • 對抗：Verbalized-Feedback——ACON 用 verbalized feedback 對抗 context collapse；本頁是「為什麼需要 verbalized feedback 在 context engineering 場景」的具體理由。
  • 對位 Steering-Vector：兩者都是 vault 中對 LLM 失靈的因果機制描述——steering vector 解釋「情緒會 causally 影響能力」、context collapse 解釋「摘要會 causally 抹除任務關鍵」。
  • 上層工程化載體：Harness-Engineering——本概念是 harness 在「控制行為」手段下的失敗模式；harness 設計者必須意識到單純 compact 會引入 context collapse 風險。

相關來源

備註

建頁理由：vault 既有 Context-Engineering 已提到 compact 不能恢復品質、context window 危機等議題，但沒有命名「壓縮會讓任務真正在意的資訊消失」這個失敗模式本身——獨立成頁讓 Meta 收信事件 / AppWorld 數據 / ACON / 未來 collapse-aware harness 設計議題有共同錨點，並讓「verbalized feedback 為什麼能改善 context engineering」的論述更清晰。

未來累積方向：(a) 更多 context collapse 的具體案例與失敗模式分類；(b) collapse-aware compact 的工業化做法；(c) 自動偵測 collapse 的 metric / monitor；(d) 對位人類 PKM 中的「過度摘要丟失原意」現象。

反向連結