這篇文章是「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）」的特殊性。
一般的平面表格（Flat Table）只有一行標題（Header），每個數據格的意義由這一行標題決定。這類表格線性化後，語意損失相對較小。
但當遇到財報、科學論文中常見的**「跨行/跨列合併（Row/Column Spans）」或「多層級複合表頭」**時，Markdown 的線性結構會徹底崩潰。行與行之間的依賴關係、表頭對數值的制約，在 Chunking 之後化為破碎的字串，LLM 看到的只是失去上下文的孤立數字——這正是 MixRAG 要解決的核心痛點。
但真實的財務報表、醫療指引、政府統計報告，通常是層級表格：
| 2013 | 2012 | |||
|---|---|---|---|---|
| Buy | Sell | Buy | Sell | |
| Euro | $— | $2.2 | $— | $1.5 |
| Canadian dollar | $— | $35.4 | $— | $18.9 |
| Mexican peso | $11.2 | $— | $10.9 | $— |
| Total | $11.2 | $37.6 | $10.9 | $20.4 |
這個表格中，11.2 這個數字的完整語意是：「墨西哥披索的 2013 年購買金額為 11.2（百萬美元）」。它同時由頂層標題的層級路徑（2013 → Buy）和左側標題的層級路徑（Mexican peso）共同定義。
當你把這張表格拍扁成 Markdown 文字，然後向量化，11.2 的 Embedding 可能只包含「這個數字在某個外匯表格裡」的模糊資訊，完全丟失了「2013 年」、「購買」、「墨西哥披索」這三個座標維度。
MixRAG 的問題意識：如果一個問題問的是「假設當前成長率持續，FES 2014 年的 Total Buy 和 Electric Sales to Affiliates 的 Revenues 加總是多少？」，向量搜尋必須找到這張表格所在的文件。但傳統方法的問題是：它可能因為問題中有「2014」這個年份，反而找到只包含「2014」字樣但不包含相關數據的文件。
H-RCL：讓每個數字記得它從哪裡來#
H-RCL（Hierarchy Row-and-Column-Level）是 MixRAG 最核心的技術貢獻。理解它需要先理解三個概念層次：
概念一：層級路徑#
每個數據格的位置，由兩條路徑共同定義：
- 頂層路徑：從最高層標題往下串接到最底層。以上面的表格為例，
11.2的頂層路徑是2013 → Buy - 左側路徑：從最左欄的標題往下串接。
11.2的左側路徑是Mexican peso這兩條路徑合在一起，唯一確定了表格裡任意一個數字的位置和語意。
概念二：RCL 摘要#
對於沒有層級結構的平面表格，RCL 為每一行和每一欄各生成一句摘要：
- 行摘要：「Mexican peso 的資料：2013 Buy 為 11.2，2013 Sell 無交易……」
- 欄摘要：「2013 Buy 欄下：Euro 為 $–，Mexican peso 為 11.2……」
概念三：H-RCL 摘要#
H-RCL 是 RCL 的層級版本——摘要句裡用的不是最末層的標題，而是完整的層級路徑。
以 11.2 為例，H-RCL 生成的行摘要是：
「Mexican peso 在 2013 年 Buy 方向的交易金額為 11.2（百萬美元）」
這句話同時包含了頂層路徑（2013 → Buy）和左側路徑（Mexican peso），向量化之後，這兩個維度的語意都保留在裡面了。
為什麼這樣有效？#
當使用者問：「2013 年 FES 的 Total Buy 和 Revenues of Electric Sales to Affiliates 各是多少？」
H-RCL 生成的行摘要可能是：
「Mexican peso 在 2013 年 Buy 方向的交易金額為 11.2（百萬美元），在 2013 年 Sell 方向無交易，在 2012 年 Buy 方向為 10.9（百萬美元）。」
這句話的向量，包含了「Mexican peso」、「2013」、「Buy」、「11.2」等所有關鍵語意。當問題中出現「2013 年的 Total Buy」時，這個行摘要的向量和問題向量之間的 cosine 相似度，會顯著高於只包含原始表格文字的 Embedding。
DocRAGLib：第一個真正的異質文件 RAG Benchmark#
在介紹完整架構之前，有必要先了解 DocRAGLib，因為這個資料集的設計本身就說明了問題的複雜度。
為什麼需要 DocRAGLib？#
現有的 benchmark（如 HybridQA、HiTab、MultiHiertt）主要針對單文件 QA——給定一份文件，從中回答問題。但真實的 RAG 場景是多文件檢索：資料庫裡有幾千份文件，你要找到正確的那份。
DocRAGLib 的設計目標是填補這個空缺：提供一個包含大量異質文件的語料庫，讓系統從中找到最相關的文件來回答問題。
DocRAGLib 的組成#
資料來源：
- MultiHiertt 資料集（金融報告，包含文字和層級表格）
- HiTab 資料集對應的原始網頁內容（通過連結爬取，重建完整異質文件）
規模：
- 2,178 份異質文件
- 每份文件平均 1,453 個詞、3.85 張表格
- 88.71% 的文件包含至少 2 張表格
- 4,468 個 QA 對（訓練/驗證/測試 = 2,990/502/976）
領域分布：金融（42.99%）、社會（25.2%）、科學（13.84%）、醫療（7.34%）、其他（10.63%）
問題複雜度：
- 9.02% 只需要文字
- 50.78% 只需要表格
- 40.20% 同時需要文字和表格（這是最難的部分）
其中約三分之一的問題，答案是需要精確計算才能得出的——不是靠語意推測就能回答的類型。
這樣的資料集設計，讓 MixRAG 必須同時處理「找對文件」和「算對答案」兩個挑戰，也就是接下來三個模組要解決的問題。
MixRAG 三模組架構#
模組一：異質文件表示模組（Heterogeneous Document Representation Module）#
這個模組為每份文件生成兩種表示：
文字部分
切塊前先做語意補全——把代詞和省略的主語還原成具體名稱：
原文：「Apple 發布了新 iPhone。它的銷量超過預期，該公司股價隨之上漲。」
補全後：「Apple 發布了新 iPhone。iPhone 的銷量超過預期，Apple 股價隨之上漲。」
補全完之後再切成句子，過濾掉少於 5 個詞的噪音句子。這樣每個 chunk 就算脫離前後文，也能獨立被理解。
表格部分
用 H-RCL 生成層級摘要，同時保留原始的 Table Level Summary。
雙語料庫設計
兩種摘要分別存進不同的語料庫：
- Embedding 語料庫：存 H-RCL 摘要，用於語意向量搜尋
- BM25 語料庫：存 Table Level Summary，用於關鍵詞搜尋 這樣設計是因為兩種搜尋方式的需求不一樣。H-RCL 摘要語意豐富，向量化之後效果很好；但它把多個關鍵詞合併進一句話，BM25 反而難以精確匹配。所以讓 BM25 用原始的 Table Level Summary，語意搜尋用 H-RCL，各自發揮優勢。
模組二：跨模態檢索#
這個模組分兩個階段，先用兩種搜尋方式廣撒網，再用 LLM 精準篩選。
第一階段：Ensemble 檢索#
同時跑兩種搜尋：
- BM25 檢索：關鍵詞匹配，從 Table Level Summary 語料庫取 top-40 候選
- Embedding 檢索：語意向量搜尋，從 H-RCL 語料庫取 top-60 候選 兩組結果合併，重複出現的文件只保留一份，平均得到約 93 份候選文件。
為什麼 Embedding 的份額（60）比 BM25（40）多？H-RCL 的語意豐富性讓 Embedding 搜尋對層級表格更有優勢；BM25 的強項是精確的關鍵詞匹配，拉太多反而引入噪音。論文實驗確認 n=40、m=60 這組配置最佳，候選集包含正確文件的比例（HiT Rate）達到 0.9805。
第二階段：LLM 精排#
從 93 份縮減到 1 份，這一步讓 LLM 來做。
但直接把 93 份完整文件丟給 LLM 會超出 context window，所以 MixRAG 先做一步動態片段過濾：對每份候選文件，只取出跟問題最相關的幾個片段，組成一個「濃縮版」，再讓 LLM 從這些濃縮版裡選出最相關的那份。
不同 Reranker 的比較：
| Reranker 類型 | 模型 | HiT@1 |
|---|---|---|
| LLM | GPT-4o | 0.73 |
| LLM | GPT-4o mini | 0.63 |
| Cross-Encoder | MiniLM-L-12-v2 | 0.56 |
| BGE-Reranker | reranker-v2-m3 | 0.58 |
GPT-4o 的 HiT@1 達到 0.73，比最強的傳統 Reranker 高出約 26%。這個差距說明在「需要跨文件邏輯推理」的精排場景，LLM 的理解能力比傳統的向量匹配更有優勢。
模組三：多步推理模組（Multi-Step Reasoning Module）#
找到目標文件 D* 之後，MixRAG 用 RECAP 策略來生成答案。
RECAP 是 MixRAG 自創的推理框架，結合了 CoT（Chain-of-Thought）的分步推理邏輯（把思考過程拆開來寫）和 PoT（Program of Thought）的工具導向計算（讓外部工具負責算數，不靠 LLM 自己算），五個字母各代表一個步驟：
R — Restate（重述問題）：
「這個問題要求我計算 2014 年的預測值，需要找到 2012-2013 年的數據並推算成長率。問題類型：數值計算型，多步計算。」
E — Extract（提取相關數據）：
「從 D* 中，Total Buy 2013 = 11.2，2012 = 10.9；Electric Sales to Affiliates Revenues 2013 = 652，2012 = 515。」
C — Compute（執行計算，寫出公式）：
「Total Buy 成長率 R₁ = (11.2 - 10.9) / 10.9 = 2.75% Revenues 成長率 R₂ = (652 - 515) / 515 = 26.60% 2014 年 Total Buy = 11.2 × (1 + R₁) = 11.508 2014 年 Revenues = 652 × (1 + R₂) = 825.52 加總 = 836.45（百萬）」
A — Answer（生成最終答案）：
如有外部計算器，驗證公式計算結果；選擇更可靠的那個作為最終答案。
P — Present（輸出格式化答案）：
「836.45（百萬美元）」
RECAP 和 PoT 的關鍵差異是：PoT 讓 LLM 寫程式，由程式執行計算；RECAP 讓 LLM 寫出計算公式，由外部計算器驗證。RECAP 的 Compute 步驟比 PoT 更靈活（可以是任何語言的公式描述），而且用外部計算器做驗證而不是完全依賴程式執行，在複雜的多步計算中更穩定。
主要實驗結果#
檢索性能對比#
| 方法 | HiT@1 | HiT@3 | HiT@5 | HiT@10 | EM（基於 HiT@1） |
|---|---|---|---|---|---|
| Standard RAG | 1.59% | 3.39% | 5.38% | 12.55% | 0.51% |
| Table Retrieval | 37.05% | 52.99% | 59.96% | 64.94% | 19.06% |
| LangChain (GPT-4o) | 23.90% | 41.04% | 48.21% | 52.19% | 13.01% |
| Self-RAG (GPT-4o) | 28.29% | 45.02% | 50.00% | 55.98% | 21.41% |
| RAG-Critic (GPT-4o) | 29.00% | 46.11% | 50.51% | 60.55% | 25.31% |
| MixRAG (GPT-4o) | 54.10% | 72.44% | 76.03% | 86.89% | 32.28% |
Standard RAG 的 1.59% HiT@1 是那個慘不忍睹的數字。MixRAG 把它提升到 54.10%，提升幅度超過 33 倍。
論文原文的說法是：MixRAG 的 HiT@1（54.10%）比表格檢索方法中最強的 baseline ——Table Retrieval（37.05%）——高出 46%（“significantly outperforming the strongest baseline (Table Retrieval) by 46%"）。注意這裡比較的對象是 Table Retrieval，不是 RAG-Critic；RAG-Critic（29.00%）只是文字類 baseline 中最強的一個，論文摘要中的「46%」也是泛指對三類 baseline（text-only、table-only、naive-mixture）的整體提升，並非單獨對某一個 baseline 的數字。
QA 性能對比#
| 方法 | GPT-4o EM | GPT-4o mini EM | Gemini-2.0 EM |
|---|---|---|---|
| Direct | 35.34% | 23.55% | 26.64% |
| CoT | 46.87% | 36.84% | 38.01% |
| PoT | 61.90% | 55.64% | 51.84% |
| RECAP | 64.66% | 58.15% | 60.25% |
RECAP 在所有測試模型上都超過了 PoT。RECAP 在 Qwen2.5-32B（開源模型）上達到 64.16%，幾乎與 GPT-4o（64.66%）持平，顯示 RECAP 策略本身的有效性不強依賴特定閉源模型。
消融實驗：H-RCL 的貢獻有多大#
這是 MixRAG 論文中最有說服力的數據：
| 表格表示策略 | HiT@1 | HiT@3 | HiT@5 | HiT@10 | EM |
|---|---|---|---|---|---|
| Table Level Summary | 36.27% | 48.05% | 59.63% | 74.28% | 23.83% |
| General RCL Summary | 39.84% | 55.02% | 68.03% | 79.81% | 26.25% |
| H-RCL Summary | 54.10% | 72.44% | 76.03% | 86.89% | 32.28% |
從 Table Level Summary 到 H-RCL：
- HiT@1 提升 +17.83%——論文原文寫的相對提升是 47%（“H-RCL improves HiT@1 by 47%… compared to the Table Level Summary”）；若直接用表格中的數字精算，(54.10-36.27)/36.27 約為 49.1%，與論文原文的 47% 略有差異，這裡以論文原文用語為準。
- EM 提升 +8.45%（論文原文稱提升 28%；用表格數字精算約為 35.4%，同樣以論文原文為準）
僅僅改變表格表示方式，不換任何模型，就帶來了接近 50% 的相對提升。
換句話說：不換模型，只是改了表格的表示方式，就帶來了將近 50% 的相對提升。這個環節在工程實踐中通常被低估或忽略。
各模組的消融實驗（論文中的Table資訊）：
| 變體 | HiT@1 | EM |
|---|---|---|
| 完整 MixRAG | 54.10% | 32.38% |
| w/o Ensemble Retrieval（保留 LLM 精排，只用單一檢索器） | ||
| ── 只用 Embedding | 47.34% | 27.77% |
| ── 只用 BM25 | 35.45% | 21.00% |
| w/o Two-stage Retrieval（同時去掉 Ensemble 與 LLM 精排，只用單一檢索器直接出結果） | ||
| ── 只用 Embedding | 27.87% | 21.31% |
| ── 只用 BM25 | 15.57% | 13.11% |
| 移除 RECAP 的 Compute 步驟 | 54.10% | 25.61% |
這裡有兩組容易混淆的消融：第一組「w/o Ensemble Retrieval」只去掉雙軌檢索中的一軌，但仍保留 LLM 精排，所以分數降幅較小（47.34% / 35.45%）；第二組「w/o Two-stage Retrieval」是同時去掉 Ensemble 和 LLM 精排兩個階段，降幅更大（27.87% / 15.57%）。兩組的「只用 Embedding」與「只用 BM25」分數並不相同，不能混為一談。
有發現「完整 MixRAG」的 EM 在表格是 32.38%，但前面主表格與表格表示策略消融寫的是 32.28%。這是依論文資訊呈現，論文本身沒有說明這個差異從何而來，這裡還是保留論文原始數字。
移除 RECAP 的 Compute 步驟，EM 從 32.38% 降到 25.61%，下降超過 6%，說明讓 LLM 寫出計算公式（而不是直接計算）是 RECAP 最關鍵的創新。
可擴展性分析#
論文在不同資料庫規模（280 / 500 / 1,000 / 1,500 / 2,178 份文件）下測試了 MixRAG 和 baseline 的性能衰減速度：
MixRAG 展現了最慢的性能衰減：當文件數量從 280 增加到 2,178 時，MixRAG 的 HiT@1 下降幅度顯著小於其他方法。特別是在 HiT@10 指標上，MixRAG 的曲線幾乎是平的，而其他方法都有明顯下滑。
這個結果說明 MixRAG 的設計在大規模文件庫下仍然有效，適合真實企業場景（通常有數千到數萬份文件）。
效率對比#
| 方法 | 前處理 Tokens | 生成 Tokens | 時間（秒） |
|---|---|---|---|
| Standard RAG | 0 | 4,614 | 5.26 |
| Table Retrieval | 1,340 | 5,372 | 3.81 |
| Self-RAG | 2,551 | 24,166 | 15.47 |
| RAG-Critic | 4,917 | 34,990 | 23.89 |
| MixRAG | 1,108 | 14,189 | 11.76 |
MixRAG 的前處理 Token 用量是最低的（1,108，比 Self-RAG 少 57%，比 RAG-Critic 少 77%）。生成 Token 用量（14,189）雖然高於 Standard RAG，但比 Self-RAG 和 RAG-Critic 少 41-59%。
這個效率表現在高性能（54.10% HiT@1）和合理計算成本之間取得了很好的平衡。
工程落地的四個思考#
一、H-RCL 的計算成本與快取策略#
H-RCL 為每張表格的每一行和每一列生成摘要，然後送給 LLM 精修。對於包含 50 行 10 列的表格，這需要生成約 60 個 LLM 請求（50 行摘要 + 10 欄摘要）。
計算成本控制策略：
- H-RCL 摘要可以在文件入庫時一次性計算並快取，不需要在查詢時重新生成
- 對於頻繁更新的表格，建立增量更新機制，只重新計算變更的行/列
- 可以用較小的本地模型（如 Qwen-7B）替代 GPT-4o 做摘要生成，降低成本
二、BM25 和 Embedding 語料庫的維護#
MixRAG 維護兩個語料庫，這增加了系統複雜度。在工程實踐中：
- BM25 語料庫（Table Level Summary）更新快，適合用 Elasticsearch 或 OpenSearch
- Embedding 語料庫（H-RCL 摘要）更新慢，適合用 Pinecone、Weaviate 或 Qdrant
- 定期的雙語料庫同步是必要的運維工作
三、LLM Reranker 的成本控制#
論文顯示 GPT-4o 作為 Reranker 最好，但成本最高。對於高併發場景：
- 可以用 Qwen2.5-32B 替代 GPT-4o，性能相近但成本低很多
- 對於不複雜的問題，可以跳過 LLM 精排，直接用 Embedding 排名結果
- 建立問題複雜度分類器，只對複雜問題觸發 LLM 精排
四、RECAP 在特定場景的變體#
RECAP 的 Compute 步驟要求 LLM 明確寫出計算公式。但對於不涉及數值計算的事實型問題（如「誰是 CEO？」），這個步驟反而是多餘的。
建議：在 RECAP 的 Restate 步驟中加入問題類型判斷，如果是非計算型問題，跳過 Compute 步驟直接到 Answer，節省 token 消耗。
在高並發或對延遲敏感的場景，可以用輕量級分類器（或小模型）在第一步就將問題分流：計算型問題走完整的 RECAP 五步流程，事實查找型問題直接簡化為單步 QA，以平衡系統的吞吐量與知識精準度，同時避免不必要的 TTFT（Time-to-First-Token）延遲。
MixRAG vs. TableRAG：選哪個？#
目前可能想比較這兩篇論文解決的問題：
| 面向 | MixRAG | TableRAG |
|---|---|---|
| 主要問題 | 從大型文件庫中找到正確文件 | 在找到表格後精確回答計算問題 |
| 核心技術 | H-RCL 表示法 + LLM Reranker | SQL 精確計算 |
| 資料庫需求 | 向量索引 + BM25 索引 | 向量索引 + MySQL/SQL 資料庫 |
| 適用場景 | 企業知識庫，文件數量多，問題需要先找文件 | 問題需要跨整張表格的精確計算（統計、聚合、排序） |
| 互補性 | ✅ 兩者解決不同子問題，可以組合使用 | ✅ |
最佳實踐建議：在一個完整的 RAG 系統中，MixRAG 的表示和檢索邏輯（H-RCL + Ensemble + LLM Reranker）和 TableRAG 的執行邏輯（SQL 精確計算）是可以組合使用的。MixRAG 找到正確文件，TableRAG 在這張表格上精確執行計算。
結論#
MixRAG 論文最值得記住的，就是這組數字：
1.59% → 54.10%
這 33 倍的提升，很大程度上來自一個決定：表格在進入向量空間之前，應該保留它的層級結構。
這個決定不需要更大的模型，不需要更複雜的推理，只需要在資料準備環節做出正確的選擇。
這是 MixRAG 最直接的工程啟示：RAG 的性能天花板，通常卡在 Data Pipeline 的品質，跟模型參數量關係不大。
系列文章導航#
- ← 綜述概覽：Advanced RAG——四篇論文的架構思考
- ← TableRAG 技術解析：SQL 精確計算如何讓表格計算精確化
- → UniversalRAG 技術解析：模態路由解決多模態 RAG 困境
- → MRAG 技術解析：時序規則計算解決時間敏感問題
延伸資源#
- 📄 論文原文：arXiv:2504.09554
- 💻 官方代碼：github.com/ChiZhang-bit/Mixture-of-RAG
- 📊 DocRAGLib Dataset：包含在論文 GitHub 倉庫中