Enterprise RAG Bloss0m Note 084 RAG 系統最難維護的地方,通常不是模型能不能寫出流暢答案,而是團隊能不能回答:它找到哪些證據?為什麼使用這些證據?引用是否真的支援答案?如果讓 Agent 多走幾步,品質是否提高,還是只增加延遲與成本?
TREC RAG 2026 提供了一個很好的入口。官方 track 把 2026 年描述為 TREC 的第一個 Agent-first track,並將評測拆成 Retrieval 與 Retrieval-Augmented Generation 兩個互補任務;同時提供新的 ClimbMix-400b corpus 與 RAGDoll 評測工具。這些設計讓「找不到證據」與「找到證據卻沒有用對」有機會被分開討論。
先理解公開 benchmark 在量什麼
官方定義的兩項任務可以簡化成:
- Retrieval: 給定 narrative,回傳與該 narrative 相關、且可作為答案證據的 ClimbMix 文件排名清單。
- Retrieval-Augmented Generation: 從 ClimbMix collection 找到相關證據,回傳以證據為根據的摘要答案。
這個拆分很重要。只看 end-to-end answer score,會把 parser、index、retriever、context assembly、generation 與 citation 的失敗混在一起;有 Retrieval run 作為參照,才知道必要文件是否根本沒有進入候選集合。
截至 2026 年 8 月 9 日,官方頁面的 results and judgments 仍標示為 TBD。因此本文不解讀任何參賽結果,而是把公開任務與工具當成一套值得觀察的評測基礎設施。RAGDoll 的 README 顯示,它可以 materialize prompts、產生 gold-standard artifacts、做 relevance 與 nugget 流程、解析 citation support,並計算支援 metrics;這些是可觀察的流程介面,不是生產可靠性的保證。
為什麼這對企業 RAG 有用?
企業 RAG 的品質問題,往往分布在不同階段:
- 文件沒有被正確解析或索引。
- 相關文件沒有進入 top-k,或被錯誤排序。
- 證據在 context 組裝時被截斷、重複或淹沒。
- 模型看到正確證據,卻產生沒有被支援的推論。
- 答案有 citation,但 citation 指向錯誤版本或只支援句子的一部分。
TREC RAG 2026 的價值,在於它讓工程師可以從「答案看起來好不好」往前追到「候選文件、證據單位與引用支援」。它不會自動涵蓋 ACL、撤回文件、tenant isolation、延遲與成本,但它提供了設計診斷流程時可以借用的語言。
下一篇會深入哪些技術細節?
如果你想知道如何把這個想法落地成自己的 evaluation harness,請接著閱讀:
TREC RAG 2026 技術深讀:從 Evidence Lineage 到可重播的 RAG Evaluation Harness
下一篇會從資料結構與執行流程開始,具體討論:
- Retrieval-only 與 end-to-end RAG run 如何使用同一組 test cases;
- candidate documents、final context、nuggets、answer sentences 與 citations 如何串成 evidence lineage;
- relevance、support、coverage、correctness、abstention、latency 與 cost 如何放進同一張 scorecard;
- Agent trace 要記錄哪些狀態,才能分辨多走一步帶來品質,還是只帶來浪費;
- judge prompt、人工抽樣、版本 manifest 與 corpus snapshot 如何支援可重現比較;
- 何時應該維持簡單的 hybrid baseline,何時才值得引入 Agentic RAG。
在進入深度實作前,可以先閱讀 Enterprise RAG 完整指南 理解資料、權限、版本與檢索架構,再閱讀 AI Agent 指南 補上工具呼叫與失敗路徑。這三篇的閱讀順序是:先看 RAG 評測問題,再看 harness 設計,最後把它放回企業架構與 Agent runtime。