Naive RAG 已死？Advanced RAG 不是換模型——四篇論文的架構思考

這篇文章是四篇技術解析系列的入口，包含完整的論文對比框架與工程實踐建議。如果想把這些技術真正用在工作上，歡迎繼續讀下去，並點開各篇連結。

一個讓人好奇的問題

#

有沒有想過，公司現在跑的 RAG 系統，在「真實文件」上的準確率是多少？

指的不是乾淨的 Wikipedia 段落，也不是精心挑選的 benchmark，是企業實際業務文件：財務年報、法規手冊、技術規格書、會議記錄。這些文件通常同時包含大量文字敘述、多層次的表格、過時的數據，以及時間敏感的政策資訊。

我最近閱讀了四篇 2025–2026 年發表的頂尖 RAG 論文，得到了一個有點驚訝的答案。

傳統 RAG 在真實異質文件上的 HiT@1，可以低到 1.59%。

這不是劣質系統。這是企業通用的標準向量搜尋方法，套用在包含層級表格的真實文件上的表現。

這四篇論文，從四個不同維度回答了「為什麼會這樣」，以及「我們應該怎麼做」：

這篇文章是這四篇RAG系列的入口，主要是為了先建立一個全局視野：Advanced RAG 到底在解決什麼問題，這四篇論文各自站在哪個位置，它們合在一起說了什麼。

為什麼「Naive RAG」不夠用

#

在進入各論文之前，需要先理解「標準 RAG 失敗」的根本原因。

Naive RAG 的流程很簡單：把文件切塊 → 向量化 → 問問題時找最相似的部分 → 把那些餵給 LLM。

這個流程在同質、非結構化、時間穩定的文件上運作良好。但真實世界的企業文件通常是：

• 異質的：同一份文件裡有段落、表格、圖表、附錄
• 高度結構化的：財務表格的 340 這個數字，離開了「亞太區 / 2024Q1 / 淨利潤」這個座標就沒有意義
• 時間演化的：「誰是 CEO？」這個問題，去年的答案可能是錯的
• 多模態的：答案可能在圖片裡、影片裡、或表格裡，而不在文字段落裡

Naive RAG 的 Chunking 策略，本質上是在摧毀這些結構：它把二維表格拍成一維字串，把時間相關性壓縮進語意向量，把不同模態混在同一個 Embedding 空間裡。

這就導致 HiT@1 是 1.59%。

四個維度，四個突破

#

維度一：異質文件 × 精確計算——TableRAG

#

核心：對於表格數據，「計算問題」不應該讓 LLM 用語意猜，應該用 SQL 執行。

以這個問題：「2008 年 Activision 發行且仍在上架的遊戲，占全部上架遊戲的百分比？」

Naive RAG 的失敗路徑：找到幾個包含 Activision 的「表格片段」→ LLM 在局部資料上估算 → 答案 50%（正確是 20%）。

TableRAG 的路徑：把整張表格匯入 MySQL → LLM 生成 SQL → 資料庫執行精確計算 → 答案 20%（正確）。

關鍵數據：TableRAG (Claude-3.5) 在需要多跳表格推理的 HeteQA 整體達到 44.19%，比最強的 Naive RAG baseline 高出近 10%，比 ReAct 高出 15%。

→ 文章：TableRAG 技術解析：SQL 才是操作表格的正確選項

維度二：層級表格的結構保存——MixRAG

#

核心：表格在進入 Embedding 空間之前，必須保留它的行列座標語意，而不是直接拍扁成一串文字。

MixRAG 提出的 H-RCL（Hierarchy Row-and-Column-Level） 表示法，為每個數據格生成包含完整層級路徑的自然語言描述。不再只是「340」，而是「亞太區淨利潤在 2024 Q1 為 340（百萬）」。

關鍵數據：光是改變表格表示方式這一個決策，HiT@1 從 36.27% 提升到 54.10%。這還不包含後續的 LLM Reranker 和 RECAP 推理策略帶來的額外增益。

→ 文章：MixRAG 技術解析：H-RCL 如何讓向量搜尋讀懂層級表格

維度三：多模態查詢的路由困境——UniversalRAG

#

核心：把文字、圖片、影片強迫放進同一個 Embedding 空間，會產生「模態偏差（Modality Gap）」——文字查詢永遠偏向文字內容，即使答案在圖片裡。

UniversalRAG 提出模態感知路由（Modality-Aware Routing）：先預測這個問題最適合哪種模態和粒度（段落/文件/表格/圖片/短片/長片），再只在對應的模態 Corpus 裡做向量搜尋。

這樣做有兩個好處：一是迴避模態偏差，二是縮小搜尋空間讓效率更高。

關鍵數據：UniversalRAG（訓練式路由，Qwen3-VL-2B）在跨 10 個 benchmark 的平均分達到 42.40，比最強的統一 Embedding 方法（GME，33.88）高出約 25%，接近這套架構的理論性能上限（42.45）。

→ 文章：UniversalRAG 技術解析：一個 RAG 搞定文字、圖片、表格與影片的模態路由設計

維度四：時間敏感問題的推理困境——MRAG

#

核心：「日期匹配」不等於「時間推理」。現有 Retriever 看到問題裡有「2021」就找文件裡有「2021」的段落，但問的是「截至 2021 年的現任首相」，答案在 2019 年上任的文件裡。

MRAG 的解法是把問題分解成「主要內容（語意）」和「時間限制（規則）」兩個維度，分別評分再相乘。時序分數用計算規則（「截至 1981 年」→ 時間戳 1970 的句子得高分，1988 的句子得 0 分），完全不依賴語意向量。

關鍵數據：MRAG 在時間擾動問題上，對比最強 baseline 的 top-1 答案召回率提升 6.6%（SituatedQA） 到 11.9%（TimeQA）；端到端 EM 提升約 5%（Llama3.1-8B）。

→ 文章：MRAG 技術解析：時間推理是 RAG 的弱點，MRAG 如何用計分規則解決它

四篇論文合在一起說了什麼

#

讀完這四篇，我有想到一個架構圖。現代 Advanced RAG 系統，需要在四個層面做出正確的設計決策：

Advanced RAG 系統設計框架

這個框架最重要的啟示是：Advanced RAG 從來就不只是演算法問題，底層是系統設計問題。需要在資料進入系統之前、在查詢進來的時候、在推理過程中，每個環節都做出正確的決策。

三個值得記住的事

#

一、資料準備的品質，比模型更重要

#

MixRAG 的 H-RCL 告訴我們，在「怎麼把資料放進系統」這個問題上，開發者通常只花了 5% 的精力，但這個決策決定了 50% 的最終性能。

在下一次建立 RAG 系統之前，問自己：「我的表格 Embedding，有沒有保留住行列的語意座標？」

二、讓 LLM 做語意，讓規則邏輯做計算

#

TableRAG 的哲學是：LLM 擅長語意理解，資料庫引擎擅長精確計算。讓它們各司其職，不要讓 LLM 去心算複雜的聚合統計。

MRAG 的哲學是：向量模型擅長語意相似度，規則邏輯擅長時序推理。不要試圖用語意向量解決規則邏輯問題。

三、先決定去哪裡搜尋，再決定搜什麼

#

UniversalRAG 最根本的貢獻是：在開始「搜尋」之前，先弄清楚「應該搜什麼」。模態路由、粒度選擇、時間感知——這些都是路由問題，而不是搜尋問題。

結語

#

這四篇論文發表的時間橫跨 2025–2026 年，但它們共同指向了一個高度一致的現實：

Naive RAG 是在「完美條件」下設計的——乾淨文字、單一模態、時間穩定。真實企業文件不符合這些條件，這就是為什麼系統在生產環境中表現得不如測試環境。

解法不是「換一個更大的模型」。解法是在數據表示、工具選擇、路由設計三個環節做出正確的架構決策。

這是讀完這四篇後我認為最值得的東西。

文章系列

#

• 📄 TableRAG 技術解析：讓資料庫直接計算，讓表格問答更精確
• 📄 MixRAG 技術解析：H-RCL 層級表示法與雙階段檢索設計
• 📄 UniversalRAG 技術解析：模態路由與粒度感知的全模態 RAG 架構
• 📄 MRAG 技術解析：用計算規則解決時間敏感問題

延伸資源

#

• 📄 TableRAG：arXiv:2506.10380 | GitHub
• 📄 MixRAG：arXiv:2504.09554 | GitHub
• 📄 UniversalRAG：arXiv:2504.20734 | Project
• 📄 MRAG：arXiv:2412.15540