再見，感謝所有上下文

大型語言模型（LLM）在處理長上下文時存在一個被稱為“U形”的顯著問題：模型對上下文開頭和結尾的資訊利用最好，而對中間部分的資訊則容易忽視。這一現象最初由斯坦福大學的研究人員Nelson Liu及其團隊在論文《Lost in the Middle: How Language Models Use Long Contexts》中系統闡述，後續研究進一步表明，U形問題並非個別模型的缺陷，而是Transformer架構的內在特性，甚至存在於隨機初始化的模型中。

本文作者在開發開原始碼質量工程技能Quality Playbook時親身遇到了這一問題。在執行缺陷報告生成階段時，儘管所需的指令和資料都明確存在於上下文中，模型卻生成了空白模板檔案，而不是填充完整資訊的報告。經過分析，作者意識到這正是U形問題的典型表現：相關資訊正好位於上下文的中間位置。

研究顯示，U形問題的根源在於Transformer結構中的兩種偏差：首要偏差（primacy bias）使模型傾向於關注上下文開頭，而新近偏差（recency bias）則使模型關注末尾。這兩種力的平衡導致中間區域的資訊被削弱。2025年和2026年的論文進一步從數學上證明了U形是Transformer的幾何屬性，因此透過更多資料或微調來消除它的可能性很低。

儘管更大的上下文視窗（如百萬token級別）在一定程度上提升了單點檢索能力（如“大海撈針”測試），但並未使長上下文智慧體工作變得可靠。實際上，更大的視窗意味著更大的中間盲區。因此，開發者需要主動管理U形問題。

作者總結出五種實用技術：

1. 精選而不積累（Curate, don't accumulate）：定期清空上下文，僅重新載入關鍵資訊。在Quality Playbook的釋出準備中，作者透過編寫上下文簡報（context brief），並每次在新會話中從頭讀取簡報，顯著改善了模型表現。
2. 將關鍵資訊置於邊緣（Position critical information at the edges）：利用U形特性，將最重要的指令或資料放在上下文開頭或最新位置。例如，在Claude Code中使用--append-system-prompt將簡報作為系統提示，保證模型始終關注。
3. 短會話優於長會話（Short sessions over long ones）：執行多個短會話，每個會話從磁碟重新讀取相關資訊，而非依賴累積的上下文。
4. 外部化重要資訊（Externalize important information）：將關鍵內容寫入檔案，而非僅保留在上下文視窗中，以便後續會話引用。
5. 驗證代理輸出（Verify agent output）：將模型聲稱知道的內容與實際磁碟檔案進行比對，確保一致性。

總之，U形上下文問題並非暫時性bug，而是LLM架構的固有特徵。透過上述技術，開發者可以在當前已釋出的模型中有效緩解這一問題，並確保智慧體工作更加可靠。