LayerRAG-Bench: RAG 不是只有檢索品質 — 跨層可靠性基準揭露生產環境的隱形故障點

一句話核心結論

現有 RAG 評測幾乎只關心檢索品質和答案正確性，忽略了一個更根本的問題：即使答案看起來合理，底下可能已經在證據層、工具合約層、授權層、會話狀態層全面故障。LayerRAG-Bench 設計了 8 個企業場景、240 個任務、9 種故障情境，對 9 個前沿模型進行 38,880 次實測。結果非常殘酷：schema 正規化能把 schema drift 成功率從 0.000 拉到 0.913，但對 stale evidence、missing tool output、denied permissions、wrong-session 完全無效。更糟的是，groundedness-only 評測在 stale/wrong-session 證據下會產生大量假陽性——系統回報「有落地證據」但證據本身就是錯的。這篇論文的核心訊息：RAG 可靠性必須分層評測，單一層面的修補不等於全棧修復。

問題背景：RAG 不只是檢索+生成，是一整疊可靠性棧

LayerRAG-Bench 重新定義了 agentic RAG 的可靠性模型。傳統 RAG 評測聚焦於「檢索到的段落是否包含答案」或「生成的答案是否正確」，但真正的生產環境 RAG 是一層層疊起來的系統：

1. 證據層（Evidence Layer）：檢索到的資料是不是最新的？是不是正確的版本？是不是該使用者的資料？
2. 工具合約層（Tool-Contract Layer）：API 回傳的結構跟 agent 預期的一致嗎？schema 變了 agent 會察覺嗎？
3. 授權層（Authorization Layer）：agent 是不是讀了不該讀的資料？是不是用了不該用的 API？權限被拒時的行為正確嗎？
4. 會話狀態層（Session-State Layer）：在多輪對話中，agent 有沒有搞混不同使用者的上下文？有沒有把上一輪的結果帶到不相關的下一輪？

現有 benchmark 幾乎只測第 1 層。LayerRAG-Bench 是第一份對這四層同時施壓的基準。

基準設計：240 任務 x 9 故障 x 2 合約模式

八個企業場景

HR 招募（履歷篩選）、客服（退貨處理）、金融（交易審查）、醫療（病歷查詢）、法務（合約比對）、物流（路由優化）、電商（庫存查詢）、IT 維運（事件回應）。每個場景 30 個任務，涵蓋單輪和多輪互動。

九種故障情境

• Schema Drift：API 回傳欄位名稱變更（如 employee_name -> emp_full_name），agent 能否適應？
• Stale Evidence：資料庫中的記錄已過期（如庫存數量是昨天的），agent 能否察覺？
• Missing Tool Output：工具呼叫成功但回傳空值或 null，agent 如何處理？
• Denied Permissions：API 回傳 403，agent 是否繼續嘗試還是優雅降級？
• Wrong Session：相鄰使用者的上下文混入當前對話
• Malformed Evidence：回傳資料格式損壞（如 JSON 被截斷）
• Conflicting Tools：兩個工具對同一查詢回傳矛盾結果
• Rate Limit：API 回傳 429，agent 的重試策略是否合理？
• Adversarial Injection：檢索到的文件中包含 prompt injection 嘗試

兩種合約模式

Strict Contract：工具 schema 以 JSON Schema 明確定義，agent 必須遵守。測試在有合約保護下的可靠性。Loose Contract：工具僅以自然語言描述，模擬現實中沒有完整 API 規格的情境。

核心發現：Schema 正規化是局部解藥，不是萬靈丹

發現一：Schema 正規化極度有效，但只對 schema drift

在 strict contract 模式下加入 schema 正規化（將 API 回傳的欄位名稱標準化），schema drift 情境的成功率從 0.000 暴漲至 0.913。這是最亮眼的單點結果。

發現二：同樣的 schema 正規化對其他故障完全無效

對 stale evidence、missing tool output、denied permissions、wrong-session context，schema 正規化後的表現與未正規化無顯著差異。跨層洩漏的真實案例：schema drift 的修補不該讓我們誤以為其他層也安全了。

發現三：Groundedness-only 評測有假陽性問題

在 stale evidence 和 wrong-session 情境下，模型產出的答案仍然可以通過 groundedness 檢查（答案確實來自檢索到的段落）——但那些段落本身就是錯誤的。這是 groundedness 指標的系統性盲點：它能驗證答案有落地證據，但不能驗證證據本身是否正確。

發現四：模型間差異顯著，但無一模型全棧可靠

9 個模型的跨層表現差異大，GPT-5.2 和 Claude-Fable-5 在證據層表現最佳，但工具合約層和會話狀態層仍有明顯弱點。無一模型能在所有四層全部通過 >90% 任務。

論文的核心原則：Layer-Specific Evaluation

LayerRAG-Bench 最重要的貢獻不是數字本身，而是一條原則：

可靠性干預應該被歸功於修復了它的目標層級，不該被誤認為全棧修復。

這聽起來像廢話，但在 RAG 領域非常反直覺。Schema 正規化讓 schema drift 從 0->0.913——任何工程師看到這個數字都會說「太棒了，RAG 可靠性問題解決了」。但 LayerRAG-Bench 的數據顯示：這只解決了故障矩陣的 1/9。

實務啟發：部署任何 RAG 可靠性改良時，必須問「這個改良解決了哪一層的問題？其他層的故障情境是否被驗證過？」

對 DKY 部署的啟發

LayerRAG-Bench 對 DKY 現有架構有三個直接提醒：

• 工具合約層：Hermes 的工具呼叫目前依賴自然語言描述（類似 loose contract），缺少嚴格的 schema 驗證。當 MCP 端點回傳格式變化時，agent 可能給出「看起來合理」但實際上用錯欄位的結果。
• 授權層：目前多數 agent 框架對 403/401 的處理是簡單報錯後放棄，缺少優雅降級和權限邊界感知。在企業場景中這是安全隱患。
• 會話狀態層：多使用者、多對話的隔離在 agent 框架中幾乎沒有被認真對待。LayerRAG-Bench 的 wrong-session 情境暴露了一個被嚴重低估的故障模態。

最關鍵的教訓：不要因為 groundedness 評分高就覺得 RAG 系統可靠。在證據本身可能過期或錯配的情況下，groundedness 是一個系統性誤導指標。

限制

• 8 個場景雖涵蓋主流企業領域，但每個場景的任務數（30 個）有限
• 故障情境是人工設計的，不一定反映真實生產環境
• 僅測了 OpenAI、Anthropic、Gemini 三家模型，未涵蓋開源模型
• groundedness 假陽性分析僅基於自動化指標，未經人工專家驗證
• 論文未提供跨故障情境的聯合發生分析