大家好，我是肆〇柒。在 RAG 系統中，傳統問答系統在處理含文本與表格的異構文檔時，常令用戶困擾。華為云 BU 研究人員創新性地提出 TableRAG 框架，采用 SQL 執行與文本檢索混合模式，嘗試破解這一難題。在 HeteQA 基準測試集上，TableRAG 整體準確率相較于最佳基線方法提升超 10%，且能在 5 步內解決約 93.55% 的問題，為異構文檔問答帶來創新方法。

異構文檔問答的困境

在企業 AI 應用落地的當下，構建能處理自然語言與結構化表格相結合文檔的問答系統，已成為人工智能關鍵任務。然而，傳統問答系統因主要基于純文本，在處理含文本與表格的異構文檔時，存在明顯缺陷。現有語言模型在處理涉及表格的文檔時，常因表格行與列關系混亂而降低回答準確性，尤其在需要跨文檔多跳推理且涉及計算、聚合等操作時，性能受限，難以滿足實際需求。

傳統 RAG 把整張表壓成 Markdown 后切塊，行列關系被徹底打亂。當需要跨行聚合時，top-N 召回只能看到局部切片，導致 “只見樹木、不見森林”。這圖直觀展示了線性化帶來的偏差，后面將給出 TableRAG 的改進思路。

異構文檔問答任務示例

上圖展示了異構文檔問答任務的一個示例，傳統 RAG 方法將表格線性化后切塊，導致行列關系被打亂，無法進行跨行聚合操作，回答準確性受到影響。

TableRAG 框架：離線建庫 + 在線四步迭代

框架總體架構

TableRAG（下文簡稱 “框架”）是一套 SQL 執行與文本檢索混合（Hybrid SQL-Text Retrieval）系統，采用離線 - 在線兩階段處理流程，確保系統的高效性和準確性。

TablesTexts離線階段DB ConstructionMySQLVector DB在線階段Iterative ReasoningQuery DecompositionText RetrievalSQL Gen & ExecCompositional Answer

• 離線階段 ：主要負責將異構文檔解析為結構化數據庫。系統會分別提取文檔中的表格與文本內容，并將其存儲于不同的數據庫中。表格存儲于關系型數據庫，以便支持后續的 SQL 查詢操作；而文本內容則存儲于分塊知識庫，用于快速檢索相關文本信息。通過這種方式，離線階段構建了兩個并行的語料庫，為在線階段的問答處理奠定了堅實的數據基礎。
• 在線階段 ：當用戶提出問題時，系統進入在線處理階段。該階段通過四步迭代過程來逐步解答用戶的問題，包括上下文敏感的查詢分解、文本檢索、SQL 編程與執行、組合式中間答案生成。系統會動態判斷問題需要文本推理還是表格推理，并根據判斷結果選擇合適的策略，將文本檢索和 SQL 執行的結果進行整合，最終生成準確、完整的答案。

SQL 把整張表視為不可分割的推理單元，一條語句即可完成多行過濾 + 聚合，而 Python - Pandas 需要把表全部加載到內存再逐行操作，大表場景下延遲高 1 - 2 個量級。

TableRAG 的總體架構

上圖展示了 TableRAG 的總體架構，包括離線階段的數據庫構建和在線階段的四步迭代推理過程。

關鍵組件解析

• 上下文敏感查詢分解（Context - Sensitive Query Decomposition）這是框架中至關重要的一步。它能夠明確文本與表格在查詢中的角色，基于檢索到的表格內容與對應架構描述，制定子查詢。以 “2008 年 Activision 發布的游戲有多少比例仍處于活躍狀態” 為例，該模塊會將其巧妙地分解為多個子查詢，① 找 Activision 2008 游戲表；② 過濾 Live = Y；③ 求占比。在商業文檔問答中，面對 “某季度銷售額增長且利潤排名前 3 的產品類別” 這類復雜問題，查詢分解模塊同樣能精準拆解，先定位相關產品類別文本信息，再聚焦表格中銷售額與利潤數據，逐步逼近最終答案，展現其強大的邏輯拆解能力。
• 文本檢索模塊文本檢索模塊采用兩階段檢索策略，以確保檢索結果的準確性和相關性。首先，基于向量的召回階段利用預訓練語言模型將查詢與文檔分塊嵌入密集向量空間，通過計算向量間的余弦相似度，快速篩選出與查詢向量最相似的候選分塊。接著，基于語義的重排序階段對召回的候選分塊進行進一步篩選和排序，選出與查詢語義最匹配的頂級候選分塊。在處理新聞報道與數據表格結合的文檔時，這一模塊能迅速定位與查詢文本高度相關的段落，為后續答案生成提供豐富的文本依據。
• SQL 編程與執行模塊當子查詢涉及表格數據推理時，SQL 編程與執行模塊就會發揮作用。通過映射函數，該模塊能夠提取檢索結果中表格架構信息，然后利用專用工具 fSQL 生成可執行 SQL 程序，并在預先構建的 MySQL 數據庫上運行。以問題 “2008 年 Activision 發布的游戲有哪些” 為例，它會精準生成 SQL 語句 “SELECT game_name FROM games WHERE publisher = 'Activision' AND release_year = 2008”，并在數據庫中執行，快速獲取答案。在企業數據分析場景中，面對 “統計各部門加班時長超 10 小時的員工人數” 這類問題，也能毫無壓力地生成相應 SQL 語句，高效查詢企業考勤數據庫。SQL 作為符號執行接口，將表格相關查詢視為不可分割的推理單元，避免了 Python 等編程語言在處理大規模數據時的計算開銷，凸顯了其在表格數據操作中的核心價值。
• 組合式中間答案（Compositional Intermediate Answer）生成模塊該模塊負責結合 SQL 執行結果與文本檢索結果，進行綜合推理。它會根據結果的一致性、可靠性權重，得出子查詢最終答案。若 SQL 執行結果與文本檢索結果出現矛盾，模塊會深入評估兩者，仔細解釋差異，并基于評估結果給出最佳判斷。例如，在整合企業財務報表表格數據與業務分析文本時，若表格顯示某產品利潤增長，但文本分析提及市場反饋不佳，組合式中間答案生成模塊會綜合考慮這些信息，給出包含詳細情況說明的全面答案，確保用戶獲得準確且富有洞察力的決策依據。

TableRAG 框架通過離線階段構建雙庫，在線階段經四步迭代處理用戶問題，各關鍵組件協同運作，精準應對異構文檔問答挑戰。

實驗：準確率提升 10%，5 步內解決 90% 問題

實驗設置與主要結果

為了驗證上述設計的有效性，研究者在 3 個公開基準及自建 HeteQA 上進行了系統性實驗。

• 數據集 ：實驗涵蓋了 HeteQA 以及 HybridQA、WikiTableQuestions 等公共基準測試集。其中，HybridQA 是涉及表格與文本信息的多跳問答數據集，WikiTableQuestions 則是跨多領域的表格問答數據集，這些數據集從不同角度對 TableRAG 進行了全方位的考驗。
• 主要結果 ：TableRAG 在多個基準測試中以卓越的性能超越所有基線方法。在 HeteQA 數據集上，TableRAG 使用不同骨干 LLM 時，整體準確率相較于最強基線方法均有至少 10% 的提升 。這主要得益于 TableRAG 的符號推理能力，它能夠精準地處理表格數據，有效融合文本與表格信息，從而更好地適應異構文檔的復雜查詢需求。

對比可見，TableRAG 在所有骨干模型上均領先，隨后我們將通過消融實驗揭示領先原因。

單源問題性能對比：

多源問題性能對比：

具體參考：

TableRAG 與基線模型在多個基準上的性能對比

上表展示了 TableRAG 與基線模型在多個基準測試中的性能對比，TableRAG 在所有骨干模型上均領先。

消融研究與錯誤分析

• 消融研究 ：對比完整架構與三種消融變體，深入分析各組件對模型性能的影響。在 HybridQA 上，文本檢索模塊尤為關鍵；在 HeteQA 上，SQL 執行模塊更具影響力。通過消融研究，充分凸顯了 TableRAG 文本檢索與程序執行推理組件的互補性，證明了完整架構的優越性。
• 錯誤分析 ：TableRAG 的錯誤輸出主要分為推理失敗與任務未完成兩類。與 ReAct、TableGPT2 對比，TableRAG 的失敗率顯著降低，通常在 5 次內迭代出有效響應。在某次實驗中，TableRAG 出現了 SQL 執行錯誤，原因是生成的 SQL 語句存在語法問題，這表明在復雜查詢條件下，SQL 生成的準確性仍需進一步提升。這充分體現了 TableRAG 設計的合理性，尤其是上下文敏感查詢分解與選擇性 SQL 執行規劃，使其在處理復雜查詢時更加穩健可靠。

錯誤案例舉例：HeteQA 中 query “Which comedy film released in July-Dec 2012 had the most cast members?” TableRAG 生成 SQL 時遺漏 genre LIKE '%Comedy%'，導致返回非喜劇片；人工修正后準確率恢復。

HybridQA 和 HeteQA 基準上的消融研究

上圖展示了 TableRAG 在 HybridQA 和 HeteQA 基準上的消融研究結果，表明各組件對模型性能的重要影響。

TableRAG、TableGPT2 和 ReAct 的錯誤分析

上圖展示了 TableRAG、TableGPT2 和 ReAct 的錯誤分析，TableRAG 的失敗率顯著低于其他方法。

效率分析

通過對執行迭代分布的分析，TableRAG 在 HeteQA 上展現了驚人的效率。約 63.55% 的實例在 5 步內解決，30% 恰好 5 步解決。相比 TableGPT2 平均執行步驟多，ReAct 執行步驟分布相似但性能差，這表明 TableRAG 在執行效率和推理準確率方面均表現出色。這一優勢主要歸因于 SQL 基于表格推理的強大能力，它能夠快速、精準地處理表格數據，減少不必要的迭代步驟，提升整體效率。

TableRAG、ReAct 和 TableGPT2 在 HeteQA 上的執行迭代分布對比

上圖展示了 TableRAG、ReAct 和 TableGPT2 在 HeteQA 上的執行迭代分布對比，TableRAG 在較少的迭代步驟內解決了大部分問題。

TableRAG 在實驗中表現卓越，準確率相較基線提升超 10%，且 5 步內解決約 93.55% 問題，效率與準確率兼具。

HeteQA：304 題、9 領域、5 類表格操作

創建目的

為了嚴格評估多跳異構推理能力，開發 HeteQA 基準測試集顯得尤為必要。現有的公共數據集在多跳推理、跨文本與表格復雜查詢方面存在明顯不足，難以全面衡量模型在異構文檔問答中的真實性能。HeteQA 的提出正是為了彌補這一缺陷，為研究人員提供一個更具挑戰性和代表性的評估平臺。

數據收集方法與特點

HeteQA 基準測試集包含 304 個高質量示例，涵蓋 9 個語義領域，全面覆蓋多個行業的業務場景。數據集涉及 5 類表格操作，包括過濾（Filtering）、分組（Grouping）、聚合（Aggregation）、計算（Calculation）、排序（Sorting）等常見且關鍵的操作類型。其中，82% 的答案基于單一來源，18% 基于多來源，充分體現了異構文檔問答中信息來源的多樣性和復雜性。此外，數據集中包含 136 個獨特表格及 5314 個維基知識實體，為模型提供了豐富的知識背景和推理素材，使其能夠在復雜的查詢中準確地定位和整合信息。

HeteQA 的數據領域分布和表格操作分布

上圖展示了 HeteQA 的數據領域分布和表格操作分布，涵蓋了 9 個語義領域和 5 類表格操作。

局限性

盡管實驗結果亮眼，研究者也坦誠指出了當前實現的兩點主要瓶頸。

TableRAG 雖在性能上取得突破，但其有效性在一定程度上依賴于底層 LLM 的能力。在實現細節中提及，使用不同骨干 LLM 時，性能表現存在差異，在 Qwen - 2.5 - 7B 上準確率相對 72B 下降約 30%。這表明 TableRAG 對語言模型的性能要求較高，限制了其在一些資源受限環境中的應用。此外，HeteQA 基準測試集目前僅涵蓋英語，這限制了 TableRAG 在多語言環境中的應用與評估。對于其他語言的異構文檔問答任務，TableRAG 的適用性有待進一步驗證與拓展，這也在一定程度上制約了其在國際舞臺上的廣泛應用。

另外，我注意到，實際部署時，社區反饋的兩個常見坑點是：MySQL 8.0.24 在 Ubuntu 22.04 需額外安裝 libtinfo5 否則初始化失敗；dev_excel.zip 必須解壓到 dataset/hybridqa/dev_excel/ 而非根目錄，否則 ingestion 報路徑錯誤。現階段最小復現配置：單卡 A100 80 GB + MySQL 8.0 + Claude-3.5-Sonnet，可在 2 小時內跑完 HeteQA 全量 304 例，顯存峰值 ~65 GB。

總結：為什么 TableRAG 值得你關注？

現在，可以一句話總結 TableRAG 的核心價值：它把“表格”從被切碎的文本重新升格為可精確查詢的“一等公民”。

1. 先破后立傳統 RAG 把表當 Markdown 字符串切塊——行列關系斷裂，聚合、排序全局操作無從談起；TableRAG 離線階段就把表寫進 MySQL，在線階段用 SQL 把整張表當作不可拆分的推理單元，徹底解決了“結構信息丟失”和“缺乏全局視野”兩大痛點。

2. 四步迭代，SQL 與文本雙輪驅動? 上下文敏感的查詢分解：先拆問題，再決定是查文本還是跑 SQL。? 向量召回 + 語義重排：兼顧速度和相關性。? SQL 生成 + 執行：把復雜的過濾、聚合、排序一次性推給數據庫，性能與準確性兼得。? 組合式答案：SQL 結果與文本片段交叉驗證，自動消歧。在 304 題的 HeteQA 上，93.55% 的查詢 5 步內收斂，平均準確率較基線再提 10%。

3. 留得青山在，也留得局限高算力依賴（72 B 模型才能發揮全部潛力）、英語單語場景仍是現實門檻；但框架本身不挑 LLM，開源倉庫已給出 MySQL + A100 的 2 小時復現腳本，開源可在此基礎上繼續打磨。

如果你正在為金融報表、科研論文或產品手冊里“文字+表格”的問答場景頭疼，TableRAG 提供了一條可落地的新路徑：讓表格回歸表格，讓 SQL 去做它最擅長的事。開源代碼地址見參考資料，想了解更多細節的朋友，建議上手摸一下。