它明明讀完了好幾萬字，為什麼關鍵資訊還是漏了：lost in the middle

你大概見過這種場景：把一份 30 頁的需求文件整個餵給大型語言模型，讓它總結並列出驗收標準。它洋洋灑灑回你一頁，結構漂亮，語料庫裡的術語一個不少——但恰好漏掉了第 14 頁那句「退款必須在訂單建立後 48 小時內發起」。

更扎心的是：參數更大的模型並不一定更靠譜。2023 年史丹佛論文 Lost in the Middle 測過一批當時主流的開源模型，把關鍵資訊放在長文件的不同位置，看它檢索回來的準確率。結果是熟悉的 U 形曲線：資訊在開頭或結尾，答對的機率明顯更高；放在正中間，準確率掉一截，有些模型直接腰斬。後面的長文本模型把這個 U 形拉平了大半，但至今沒有完全抹平。

原因可以直接寫在推理引擎裡，而不是拋給玄學。

第一，注意力分佈不均勻。Transformer 生成第 n 個 token 時，KV cache 裡存著前面所有位置，每個位置都參與 softmax 歸一化。上下文越長，總注意力份額被攤得越薄，加上位置編碼對遠離生成位置的 token 天然不友好，中間的 chunk 實際分到的注意力權重就是個偏低值。資訊還在 KV cache 裡，但它「不夠響」。

第二，訓練分佈和真實用法錯位。論文裡有個乾淨的控制實驗：同一批第 k 個事實，讓模型閉卷直接回答 k 是多少，準確率掉得很少；一旦換成開卷——把它放進一篇更長的文章裡再問——準確率明顯下滑。也就是說，它不是「記不住第 40 個事實」，而是「知道第 40 個事實，但在一堆無關上下文裡不知道該看哪一個」。長文本能力訓練裡，有效資訊基本都堆在文件兩端，中間位置在預訓練語料裡就是垃圾堆，模型學到了「去兩頭找」的性價比，而不是均勻檢索。

這件事對生產系統有三個直接落點。

一，別把關鍵要求埋在中段。長 system prompt 裡的硬性約束（輸出格式、紅線、必須引用的資料），放開頭或放結尾，中間留給背景資料。這是零成本改動，卻直接對著機制來的。

二，能拆就別硬塞。文件可以先切片、做向量檢索，只把 top-k 相關段落連同頁碼塞進上下文。檢索不完美，但相關段落通常不超過幾千 token，此時模型實際面對的還是「短文件」，lost in the middle 的折損基本消失。工程上這叫 RAG，但它的本體不是「省 token」，而是改寫資訊的位置分佈。

三，把提示詞和素材分層。任務指令、約束、例子是一類應緊貼生成位置的資訊；事實素材是另一類。前者無論多短都放首尾，後者再長也讓給檢索管。很多「模型不聽話」的 bug，最後發現不是它能力不行，是它的指令在 50 段資料的第 38 段。想確認自己有沒有踩中這條曲線，方法很土：從那份長文件裡抽出 10 條硬性要求，人工標註它們在原文的分位（前 1/4、中間半區、後 1/4），讓模型逐條複述，按位置分桶統計漏答率。如果中間桶的漏答率顯著高於兩端，說明你餵進去的材料結構和模型的位置偏好是反向的，重排再跑一次就能對出結論。

視窗 size 是它「能塞多少」，檢索和佈局決定的是「塞進去之後還能不能用」。前者是硬體指標，後者是工程問題，而生產環境裡翻車的大多發生在後者。

下一篇會講注意力分佈為什麼對尾部更偏心，以及 sliding window attention 為什麼會讓長對話的狀態悄悄漂移。