RAG

這篇文章是四篇技術解析系列的入口，包含完整的論文對比框架與工程實踐建議。如果想把這些技術真正用在工作上，歡迎繼續讀下去，並點開各篇連結。 一個讓人好奇的問題 # 有沒有想過，公司現在跑的 RAG 系統，在「真實文件」上的準確率是多少？ 指的不是乾淨的 Wikipedia 段落，也不是精心挑選的 benchmark，是企業實際業務文件：財務年報、法規手冊、技術規格書、會議記錄。這些文件通常同時包含大量文字敘述、多層次的表格、過時的數據，以及時間敏感的政策資訊。 我最近閱讀了四篇 2025–2026 年發表的頂尖 RAG 論文，得到了一個有點驚訝的答案。 傳統 RAG 在真實異質文件上的 HiT@1，可以低到 1.59%。 這不是劣質系統。這是企業通用的標準向量搜尋方法，套用在包含層級表格的真實文件上的表現。 這四篇論文，從四個不同維度回答了「為什麼會這樣」，以及「我們應該怎麼做」： 論文 核心問題 解法方向 TableRAG（Huawei Cloud, arXiv 2506.10380） 表格被拍扁後，跨列計算完全失準 讓資料庫直接計算，取代 LLM 語意猜測 MixRAG（BIT/Zhejiang, KDD 2026） 層級表格的行列語意在向量化時消失 H-RCL 層級表示法保留結構路徑 UniversalRAG（KAIST, arXiv 2504.20734） 不同模態強迫共享 Embedding 空間導致偏差 模態感知路由 + 粒度動態選擇 MRAG（NTU/NYU, arXiv 2412.15540） 日期匹配不等於時間推理，現有系統幾乎不懂 語意分數 × 時序計分規則的混合排名 這篇文章是這四篇RAG系列的入口，主要是為了先建立一個全局視野：Advanced RAG 到底在解決什麼問題，這四篇論文各自站在哪個位置，它們合在一起說了什麼。

這篇文章是「Advanced RAG 架構思考」系列的第四篇技術解析，對應的綜述概覽在這裡。本篇聚焦 MRAG（arXiv:2412.15540），完整拆解 TEMPRAGEVAL benchmark 的設計動機、MRAG 三模組架構，以及時序計分規則的具體實現邏輯。 前言 # 「2021 年 5 月 6 日，英國首相是誰？」 正確答案是 Boris Johnson。他在 2019 年 7 月 24 日就任，2022 年 9 月才離職。所以 2021 年 5 月 6 日，他確實在任。 但如果你的 RAG 系統去搜尋這個問題，它很可能找到 Nicola Sturgeon 的相關文件——因為她在 2021 年 5 月 6 日蘇格蘭議會選舉中獲勝的新聞，正好包含「2021 年 5 月 6 日」這個精確日期，而 RAG 系統的日期匹配機制把它識別為「高度相關的文件」。 系統輸出：「Nicola Sturgeon」。 這是一個自信、清晰、完全錯誤的答案。更麻煩的是，如果你不知道正確答案，你很難判斷它是錯的——畢竟它提供了一個「真實事件」（Sturgeon 確實在那天贏得選舉）作為依據。

這篇文章是「Advanced RAG 架構思考」系列的第二篇技術解析，對應的綜述概覽在這裡。本篇聚焦 MixRAG（KDD 2026, arXiv:2504.09554），說明 H-RCL 表示法的數學定義、DocRAGLib 資料集、雙階段檢索設計，以及為什麼這一篇和 TableRAG 解決的是不同的問題。 前言：同樣是表格問題，但不一樣 # 讀完 TableRAG 之後，你可能會想：「好，我把表格放進 SQL 資料庫，問計算問題就交給 SQL，問題不就解決了？」 MixRAG 說：還沒。 TableRAG 解決的是「計算」問題——如何在完整表格上執行精確計算。但 MixRAG 解決的是「檢索」問題——當文件庫裡有 2,178 份文件，每份文件都包含文字和多張層級表格時，你怎麼找到「這個問題應該從哪份文件的哪張表格回答」？ 這是 RAG 中的文件選擇問題，不是問答問題。而且在加入層級表格之後，這個選擇問題變得格外困難。 MixRAG 是在 KDD 2026 上發表出來的，它的核心貢獻可以分三層理解： DocRAGLib：第一個真正包含層級表格的異質文件 RAG benchmark H-RCL 表示法：讓層級表格在向量化後保留結構語意 三模組框架：從資料表示到跨模態檢索到多步推理的完整架構 核心問題：為什麼層級表格特別難 # 在進入 H-RCL 的細節之前，必須先理解「層級表格（Hierarchical Table）」的特殊性。

這篇文章是「Advanced RAG 架構思考」系列的第三篇技術解析，對應的綜述概覽在這裡。本篇聚焦 UniversalRAG（arXiv:2504.20734），解析模態差距問題的理論基礎、模態路由的設計邏輯，以及在 10 個 benchmark 上的全面驗證。 前言：一個問題，三種可能的答案來源 # 給你一個問題：「USNS Carl Brashear 軍艦下水典禮上懸掛的是什麼顏色的氣球？」 這個問題的答案，不在任何文字段落裡。答案在一張典禮現場的照片裡——紅色、白色和藍色。 如果你的 RAG 系統只有文字語料庫，它會努力搜尋、找到一些關於這艘船的文字描述，然後告訴你「藍色和金色的氣球」（海軍傳統顏色的語意聯想），或者直接說「文件中找不到相關資訊」。 如果你的系統有圖片語料庫，但架構是「把圖片和文字都放進同一個 Embedding 空間」呢？可能更糟——因為模態差距（Modality Gap），文字查詢會偏向文字結果，圖片的正確答案反而被壓制在排名後面。 這就是 KAIST 的 UniversalRAG（arXiv:2504.20734）試圖解決的問題。 同一個問題，三種架構給出不同結果 核心挑戰：模態差距的本質 # 左：統一 Embedding 方法偏向文字結果。右：UniversalRAG 路由器分配到正確模態空間（Modality Acc 95.28%） UniversalRAG 的最重要貢獻之一，是把「模態差距」這個現象做了精確的理論和實驗驗證。

這篇文章是「Advanced RAG 架構解析」系列的第一篇技術解析，對應的綜述概覽在這裡。本篇聚焦 TableRAG（arXiv:2506.10380），逐步拆解它的架構設計、HeteQA benchmark 數據，以及工程實踐中值得借鑒的設計方式。 前言 # 某人問 RAG 系統：「2008 年由 Activision 發行且仍在上架的遊戲，占全部仍在上架遊戲的百分比是多少？」 系統回答：50%。 正確答案是：20%。 這個錯誤不是因為模型不夠聰明，也不是因為向量搜尋失效——相關的表格確實被找到了。問題在於：RAG 只找到了「部分表格片段」，然後讓 LLM 在這殘缺的資料上估算百分比。LLM 盡力了，但它總不可能從片段資料算出全局正確的統計數字。 這就是 Huawei Cloud 在 TableRAG（arXiv:2506.10380）論文中，為所有現有 RAG 方法找出的根本性缺陷，他們稱這為「缺乏全局視角（Lack of Global View）」。 這篇文章會拆解 TableRAG 的架構設計，分析它在三個 benchmark 上的數據表現，探討實驗告訴我們的事，並思考這框架在真實工程場景中的落地意義。 核心問題：為什麼 Naive RAG 操作表格會失敗 # TableRAG 論文一開頭就點出現有 RAG 方法處理表格時的兩個根本問題，先弄懂這兩點，後面的設計才看得比較懂。