LFM3拉長上下文之後，測試需要追蹤證據之間的關係

2026年10月27日，Liquid AI發佈LFM3。其文字架構結合卷積、局部注意力和全域注意力，標示上下文視窗為256K token。Liquid AI公告。

對應用團隊而言，更值得追問的是：準備拿這段空間做什麼？把更多材料放進一次請求，可能減少事先決定哪些頁面應被檢索保留的壓力，但也改變了助手承擔的工作。它不再只是根據一份簡短摘錄回答，而可能需要核對一段內容互相衝突的完整紀錄。本文的分析是，驗收應圍繞這些關係展開，而不是把能夠成功裝入的最長提示，直接當成產品的有效容量。

找到事實，只是任務的開始

設想一個處理配送爭議的客服團隊。最初訂單寫著一個送貨地址；後續郵件修改了地址；再下一封郵件說明，修改僅適用於第二批貨。每句話單獨引用都不難。真正有用的答案，卻必須把修訂與正確的批次連接起來，並保留第一批貨的原地址。助手即使找回了全部三段，也仍可能給出錯誤的操作指令。

這個例子提示了一種比在長文件中藏一個編號更有解釋力的測試：保持案件事實不變，把修訂說明移到距離原指令更遠的位置，在兩者之間加入看似合理卻無關的往來郵件。正確決定應當保持不變。如果答案隨之改變，團隊就發現了一種值得調查的呈現依賴，即使被引用的每段話都真實存在。

2024年的RULER論文把長上下文評估從簡單檢索擴展到追蹤、聚合等任務。它早於LFM3，不能證明這款模型的表現。原始論文，首次提交於2024年4月9日。

在上述假想客服場景裡，追蹤意味著記住哪項修訂修改哪條指令；聚合則可能是核對幾批部分交貨是否滿足一張訂單。這是不同的出錯機會。若將它們混成一個通過率，團隊反而更難判斷：需要改善的是檢索、文件結構，還是助手在流程中承擔的權限範圍。

改變呈現，但保留原意

設計良好的測試，需要區分無關變化和有意義的變化。只移動段落、不改日期和適用範圍，不應改變答案；把「僅第二批」改成「兩批都適用」，則應該改變答案。評估集必須同時包含兩類變化，否則一個固執重複原答案的系統，也可能顯得十分穩定。

2023年的《Lost in the Middle》研究發現，證據位置會影響其所評估模型和任務的表現。這項歷史結果不是對LFM3的診斷。原始論文，首次提交於2023年7月6日。

本文提出的應用測試，不止問位於中間的材料能否被找到，而是問材料排列改變後，決定是否仍由同一組事實支撐。把有約束力的修訂分別放在開頭、中間和結尾，再把它放到一項相似但無關的修訂附近。記錄答案，也記錄用於連接當事人、對象和生效日期的段落。答案正確、證據鏈錯誤的結果仍然脆弱：它可能只是碰巧答對，而非可以重複的表現。

這種辦法有一個重要限制：真實文件的順序有時本身就有意義。觀察紀錄的先後，可能決定作出某項決定前已知什麼；對話輪次也決定誰在回答誰。隨意打亂這類材料，可能破壞任務，而不是檢驗任務。評估者必須先說明哪些變換保留原意，哪些變換需要新的標準答案。這是實質性的領域工作，不是上下文視窗擴大後自動獲得的屬性。

驗收邊界屬於應用本身

架構會影響模型處理資訊的方式，但產品團隊不應根據某個架構元件的名稱，直接推斷一種業務錯誤；也不應認為局部和全域運算的組合，就保證能夠正確核對紀錄。實際證據來自模型、執行設定和文件流程共同工作的表現。一個部署設定的測試結果，不能自動代表所有量化方式、提示格式或之後的模型版本。

假設客服團隊為了縮短紀錄，加入一份早期往來郵件的摘要。這份摘要就成為新的評估對象。如果它漏掉「僅適用於第二批」的限制，下游模型可能只是忠實執行了一份不完整的敘述。只測試最終助手，會把失敗歸錯位置。保留原材料及中間摘要，才有機會找出起控制作用的關係在哪一步消失。

長上下文助手與搜尋結合時，道理相同。搜尋可以減少干擾，讓證據更便於檢查，但它同時決定了助手看不到什麼。更有意義的比較，是給長上下文路徑與檢索路徑提供同一組底層案件，分別統計已解決案件、漏掉的修訂，以及恰當地轉交覆核的案件。選擇不必一刀切：簡短且索引清楚的案件可能適合檢索，有爭議的紀錄則可能值得更廣泛地檢查。

一種合理的反對意見是，這樣測試成本較高，而不少應用只需要粗略分類。這個意見應當改變測試範圍，而不是抹去範圍。對可逆的排序工作，適度證據或許就夠；對會改變配送的指令，漏掉例外的代價不同。驗收邊界應跟隨助手獲准採取的行動，而不是它能接收的最大token數量。

LFM3的發佈讓這個產品問題變得及時，卻沒有讓答案自動確定。我們沒有獨立測試這款模型。下一份真正有用的結果，應是邊界清晰的陳述：在指定流程、具體文件和有意義的變體中，助手保住了回答所需的關係，或者知道這些關係仍未釐清。與單純容量相比，這才是更可操作的「有效上下文」定義。