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

異構(gòu)文檔問(wèn)答的困境

在企業(yè) AI 應(yīng)用落地的當(dāng)下，構(gòu)建能處理自然語(yǔ)言與結(jié)構(gòu)化表格相結(jié)合文檔的問(wèn)答系統(tǒng)，已成為人工智能關(guān)鍵任務(wù)。然而，傳統(tǒng)問(wèn)答系統(tǒng)因主要基于純文本，在處理含文本與表格的異構(gòu)文檔時(shí)，存在明顯缺陷。現(xiàn)有語(yǔ)言模型在處理涉及表格的文檔時(shí)，常因表格行與列關(guān)系混亂而降低回答準(zhǔn)確性，尤其在需要跨文檔多跳推理且涉及計(jì)算、聚合等操作時(shí)，性能受限，難以滿足實(shí)際需求。

傳統(tǒng) RAG 把整張表壓成 Markdown 后切塊，行列關(guān)系被徹底打亂。當(dāng)需要跨行聚合時(shí)，top-N 召回只能看到局部切片，導(dǎo)致 “只見(jiàn)樹(shù)木、不見(jiàn)森林”。這圖直觀展示了線性化帶來(lái)的偏差，后面將給出 TableRAG 的改進(jìn)思路。

異構(gòu)文檔問(wèn)答任務(wù)示例

上圖展示了異構(gòu)文檔問(wèn)答任務(wù)的一個(gè)示例，傳統(tǒng) RAG 方法將表格線性化后切塊，導(dǎo)致行列關(guān)系被打亂，無(wú)法進(jìn)行跨行聚合操作，回答準(zhǔn)確性受到影響。

TableRAG 框架：離線建庫(kù) + 在線四步迭代

框架總體架構(gòu)

TableRAG（下文簡(jiǎn)稱(chēng) “框架”）是一套 SQL 執(zhí)行與文本檢索混合（Hybrid SQL-Text Retrieval）系統(tǒng)，采用離線 - 在線兩階段處理流程，確保系統(tǒng)的高效性和準(zhǔn)確性。

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

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

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

TableRAG 的總體架構(gòu)

上圖展示了 TableRAG 的總體架構(gòu)，包括離線階段的數(shù)據(jù)庫(kù)構(gòu)建和在線階段的四步迭代推理過(guò)程。

關(guān)鍵組件解析

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

TableRAG 框架通過(guò)離線階段構(gòu)建雙庫(kù)，在線階段經(jīng)四步迭代處理用戶問(wèn)題，各關(guān)鍵組件協(xié)同運(yùn)作，精準(zhǔn)應(yīng)對(duì)異構(gòu)文檔問(wèn)答挑戰(zhàn)。

實(shí)驗(yàn)：準(zhǔn)確率提升 10%，5 步內(nèi)解決 90% 問(wèn)題

實(shí)驗(yàn)設(shè)置與主要結(jié)果

為了驗(yàn)證上述設(shè)計(jì)的有效性，研究者在 3 個(gè)公開(kāi)基準(zhǔn)及自建 HeteQA 上進(jìn)行了系統(tǒng)性實(shí)驗(yàn)。

• 數(shù)據(jù)集 ：實(shí)驗(yàn)涵蓋了 HeteQA 以及 HybridQA、WikiTableQuestions 等公共基準(zhǔn)測(cè)試集。其中，HybridQA 是涉及表格與文本信息的多跳問(wèn)答數(shù)據(jù)集，WikiTableQuestions 則是跨多領(lǐng)域的表格問(wèn)答數(shù)據(jù)集，這些數(shù)據(jù)集從不同角度對(duì) TableRAG 進(jìn)行了全方位的考驗(yàn)。
• 主要結(jié)果 ：TableRAG 在多個(gè)基準(zhǔn)測(cè)試中以卓越的性能超越所有基線方法。在 HeteQA 數(shù)據(jù)集上，TableRAG 使用不同骨干 LLM 時(shí)，整體準(zhǔn)確率相較于最強(qiáng)基線方法均有至少 10% 的提升 。這主要得益于 TableRAG 的符號(hào)推理能力，它能夠精準(zhǔn)地處理表格數(shù)據(jù)，有效融合文本與表格信息，從而更好地適應(yīng)異構(gòu)文檔的復(fù)雜查詢(xún)需求。

對(duì)比可見(jiàn)，TableRAG 在所有骨干模型上均領(lǐng)先，隨后我們將通過(guò)消融實(shí)驗(yàn)揭示領(lǐng)先原因。

單源問(wèn)題性能對(duì)比：

多源問(wèn)題性能對(duì)比：

具體參考：

TableRAG 與基線模型在多個(gè)基準(zhǔn)上的性能對(duì)比

上表展示了 TableRAG 與基線模型在多個(gè)基準(zhǔn)測(cè)試中的性能對(duì)比，TableRAG 在所有骨干模型上均領(lǐng)先。

消融研究與錯(cuò)誤分析

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

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

HybridQA 和 HeteQA 基準(zhǔn)上的消融研究

上圖展示了 TableRAG 在 HybridQA 和 HeteQA 基準(zhǔn)上的消融研究結(jié)果，表明各組件對(duì)模型性能的重要影響。

TableRAG、TableGPT2 和 ReAct 的錯(cuò)誤分析

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

效率分析

通過(guò)對(duì)執(zhí)行迭代分布的分析，TableRAG 在 HeteQA 上展現(xiàn)了驚人的效率。約 63.55% 的實(shí)例在 5 步內(nèi)解決，30% 恰好 5 步解決。相比 TableGPT2 平均執(zhí)行步驟多，ReAct 執(zhí)行步驟分布相似但性能差，這表明 TableRAG 在執(zhí)行效率和推理準(zhǔn)確率方面均表現(xiàn)出色。這一優(yōu)勢(shì)主要?dú)w因于 SQL 基于表格推理的強(qiáng)大能力，它能夠快速、精準(zhǔn)地處理表格數(shù)據(jù)，減少不必要的迭代步驟，提升整體效率。

TableRAG、ReAct 和 TableGPT2 在 HeteQA 上的執(zhí)行迭代分布對(duì)比

上圖展示了 TableRAG、ReAct 和 TableGPT2 在 HeteQA 上的執(zhí)行迭代分布對(duì)比，TableRAG 在較少的迭代步驟內(nèi)解決了大部分問(wèn)題。

TableRAG 在實(shí)驗(yàn)中表現(xiàn)卓越，準(zhǔn)確率相較基線提升超 10%，且 5 步內(nèi)解決約 93.55% 問(wèn)題，效率與準(zhǔn)確率兼具。

HeteQA：304 題、9 領(lǐng)域、5 類(lèi)表格操作

創(chuàng)建目的

為了嚴(yán)格評(píng)估多跳異構(gòu)推理能力，開(kāi)發(fā) HeteQA 基準(zhǔn)測(cè)試集顯得尤為必要。現(xiàn)有的公共數(shù)據(jù)集在多跳推理、跨文本與表格復(fù)雜查詢(xún)方面存在明顯不足，難以全面衡量模型在異構(gòu)文檔問(wèn)答中的真實(shí)性能。HeteQA 的提出正是為了彌補(bǔ)這一缺陷，為研究人員提供一個(gè)更具挑戰(zhàn)性和代表性的評(píng)估平臺(tái)。

數(shù)據(jù)收集方法與特點(diǎn)

HeteQA 基準(zhǔn)測(cè)試集包含 304 個(gè)高質(zhì)量示例，涵蓋 9 個(gè)語(yǔ)義領(lǐng)域，全面覆蓋多個(gè)行業(yè)的業(yè)務(wù)場(chǎng)景。數(shù)據(jù)集涉及 5 類(lèi)表格操作，包括過(guò)濾（Filtering）、分組（Grouping）、聚合（Aggregation）、計(jì)算（Calculation）、排序（Sorting）等常見(jiàn)且關(guān)鍵的操作類(lèi)型。其中，82% 的答案基于單一來(lái)源，18% 基于多來(lái)源，充分體現(xiàn)了異構(gòu)文檔問(wèn)答中信息來(lái)源的多樣性和復(fù)雜性。此外，數(shù)據(jù)集中包含 136 個(gè)獨(dú)特表格及 5314 個(gè)維基知識(shí)實(shí)體，為模型提供了豐富的知識(shí)背景和推理素材，使其能夠在復(fù)雜的查詢(xún)中準(zhǔn)確地定位和整合信息。

HeteQA 的數(shù)據(jù)領(lǐng)域分布和表格操作分布

上圖展示了 HeteQA 的數(shù)據(jù)領(lǐng)域分布和表格操作分布，涵蓋了 9 個(gè)語(yǔ)義領(lǐng)域和 5 類(lèi)表格操作。

局限性

盡管實(shí)驗(yàn)結(jié)果亮眼，研究者也坦誠(chéng)指出了當(dāng)前實(shí)現(xiàn)的兩點(diǎn)主要瓶頸。

TableRAG 雖在性能上取得突破，但其有效性在一定程度上依賴(lài)于底層 LLM 的能力。在實(shí)現(xiàn)細(xì)節(jié)中提及，使用不同骨干 LLM 時(shí)，性能表現(xiàn)存在差異，在 Qwen - 2.5 - 7B 上準(zhǔn)確率相對(duì) 72B 下降約 30%。這表明 TableRAG 對(duì)語(yǔ)言模型的性能要求較高，限制了其在一些資源受限環(huán)境中的應(yīng)用。此外，HeteQA 基準(zhǔn)測(cè)試集目前僅涵蓋英語(yǔ)，這限制了 TableRAG 在多語(yǔ)言環(huán)境中的應(yīng)用與評(píng)估。對(duì)于其他語(yǔ)言的異構(gòu)文檔問(wèn)答任務(wù)，TableRAG 的適用性有待進(jìn)一步驗(yàn)證與拓展，這也在一定程度上制約了其在國(guó)際舞臺(tái)上的廣泛應(yīng)用。

另外，我注意到，實(shí)際部署時(shí)，社區(qū)反饋的兩個(gè)常見(jiàn)坑點(diǎn)是：MySQL 8.0.24 在 Ubuntu 22.04 需額外安裝 libtinfo5 否則初始化失??；dev_excel.zip 必須解壓到 dataset/hybridqa/dev_excel/ 而非根目錄，否則 ingestion 報(bào)路徑錯(cuò)誤?，F(xiàn)階段最小復(fù)現(xiàn)配置：?jiǎn)慰?A100 80 GB + MySQL 8.0 + Claude-3.5-Sonnet，可在 2 小時(shí)內(nèi)跑完 HeteQA 全量 304 例，顯存峰值 ~65 GB。

總結(jié)：為什么 TableRAG 值得你關(guān)注？

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

1. 先破后立傳統(tǒng) RAG 把表當(dāng) Markdown 字符串切塊——行列關(guān)系斷裂，聚合、排序全局操作無(wú)從談起；TableRAG 離線階段就把表寫(xiě)進(jìn) MySQL，在線階段用 SQL 把整張表當(dāng)作不可拆分的推理單元，徹底解決了“結(jié)構(gòu)信息丟失”和“缺乏全局視野”兩大痛點(diǎn)。

2. 四步迭代，SQL 與文本雙輪驅(qū)動(dòng)? 上下文敏感的查詢(xún)分解：先拆問(wèn)題，再?zèng)Q定是查文本還是跑 SQL。? 向量召回 + 語(yǔ)義重排：兼顧速度和相關(guān)性。? SQL 生成 + 執(zhí)行：把復(fù)雜的過(guò)濾、聚合、排序一次性推給數(shù)據(jù)庫(kù)，性能與準(zhǔn)確性兼得。? 組合式答案：SQL 結(jié)果與文本片段交叉驗(yàn)證，自動(dòng)消歧。在 304 題的 HeteQA 上，93.55% 的查詢(xún) 5 步內(nèi)收斂，平均準(zhǔn)確率較基線再提 10%。

3. 留得青山在，也留得局限高算力依賴(lài)（72 B 模型才能發(fā)揮全部潛力）、英語(yǔ)單語(yǔ)場(chǎng)景仍是現(xiàn)實(shí)門(mén)檻；但框架本身不挑 LLM，開(kāi)源倉(cāng)庫(kù)已給出 MySQL + A100 的 2 小時(shí)復(fù)現(xiàn)腳本，開(kāi)源可在此基礎(chǔ)上繼續(xù)打磨。

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