1. 基于LLM的TableQA存在的問題

利用LLM來進行表格理解任務往往會將整個表格喂給LLM，但是這種方法存在一定的局限性：

? 首先，受限于LLM上下文長度的限制；比如，一個包含100列和200行的中等大小表格，單元格數量超過40,000個，超出了LLaMA和GPT系列等流行LMs的處理能力。

? 此外，過長的上下文可能會削弱推理能力，比如：Lost-in-the-Middle。

? 最后，隨著表格尺寸的增加，計算成本和延遲也會顯著上升。

所以，直接將表格全部喂給LLM這種方案不適合與大型表格。

因此，有人提出一些新的方案用于大型表格的理解任務，如截斷表格或僅讀取表格的Schema，但是這種方法往往會丟失關鍵信息。

以及，通過檢索關鍵行和列來構建一個包含回答查詢所需基本信息的子表，將整行和整列編碼成稀疏或密集的嵌入，以減少LMs的標記成本。這種方法有兩個問題：

? 對于包含數百萬單元格的大型表格來說并不現實。

? 將長行和列壓縮成固定大小的嵌入可能會丟失語義信息，尤其是當表格包含多樣化或語義上不太豐富的內容時（例如，數值）。

2. 什么是TableRAG

基于以上問題，Google Deepmind等團隊聯合提出了TableRAG方法。TableRAG融合了模式檢索與單元格檢索，從表格中提取出核心信息，使得LLM智能體能夠依據這些信息解答查詢。

圖片

上圖展示了TableRAG與傳統表格理解任務的區別。

(a) - (d)：分別表示4種方法在提示詞中包含的數據（陰影部分），其中 （d）是TableRAG方法：

? (a)完整讀取表格：LM讀取整個表格，在大型表格中往往不現實。

? (b)只讀取Schema：LM只讀取列名和數據類型組成的模式，這種方法會導致表格內容丟失。

? (c)行-列檢索：將行和列編碼后，基于與問題相似度進行檢索。只有行和列的交集被展示給LM。對于大型表格來說，編碼所有行和列仍然不現實。

? (d)Schema-單元格檢索（TableRAG）：根據與LM生成的問題相關性，對列名和單元格進行編碼和檢索。只有檢索到的Schema和單元格被提供給LM，從而在編碼和推理上都提高了效率。

(e) 在ArcadeQA數據集上的檢索結果顯示: TableRAG在列和單元格檢索方面均優于其他方法，進而增強了后續的表格推理過程。

2.1 TableRAG的核心組件

圖片

上圖是TableRAG的核心工作流程：問題通過語言模型擴展為多個模式和單元格查詢。這些查詢依次用來檢索Schema和列-單元格配對。每個查詢的前K個候選項匯總成提示詞提供給LLM生成對應答案。

2.2 表格查詢擴展

高效處理表格的關鍵在于精確地識別出查詢所需的列名和單元格值。與傳統的表格理解任務不同的在于，TableRAG單獨為Schema和單元格分別生成獨立查詢。比如：

對于問題“錢包的平均價格是多少？”，通過LLM生成針對列名如“產品”和“價格”的潛在查詢，以及針對相關單元格值如“錢包”的查詢。這些查詢用于從表格中檢索相關的模式和單元格值。

2.3 Schema檢索

生成查詢后，Schema檢索通過預先訓練的編碼器fenc獲取相關的列名，fenc會對查詢進行編碼，并與編碼的列名進行匹配以確定其相關性。檢索到的Schema數據包括列名、數據類型和示例值。

將列轉換為整數、浮點數或日期時間數據類型；如果這幾種類型都不適合的話，保留為分類列。

? 對于被識別為數值或日期時間數據類型的列，將最小值和最大值作為示例值。

? 對于分類列，展示頻率最高的三個類別作為示例值。

匯總每個查詢的前K個檢索結果，并根據它們與最接近查詢的相似度進行排序。檢索到的Schema提供了表格格式和內容的結構化概覽，用于更精確的數據提取。

2.4 單元格檢索

Schema檢索后，提取回答該問題所需的特定單元格值。

單元格檢索的作用在于：

? 單元格識別：使LLM能夠精確地檢測表格中特定關鍵詞的存在。例如，區分“tv”和“television”，確保搜索和操作基于精確的數據條目。

? 單元格-列關聯：使LLM能夠將特定單元格與其相關的列名關聯起來。對于處理特定屬性的問題至關重要，如將“錢包”直接與“描述”列關聯，實現行索引。

單元格檢索在需要通過單元格值進行索引時特別有用。例如：

要回答“平均價格是多少？”的問題，只需識別與價格相關的列名，因為平均值的實際計算可以由程序處理。

2.5 編碼預算下的單元格檢索

在最壞的情況下，不同值的數量可能與單元格的總數相匹配（即全表都用來喂給模型）。為了在這種情況下保持TableRAG的可行性，引入了一個單元格編碼預算B。如果不同值的數量超過B，將編碼限制在出現頻率最高的B對，從而在處理大型表格時提高效率。

編碼預算僅影響單元格檢索過程。即使某個單元格未包括在檢索中，只要通過模式檢索或其他單元格知道了其列名，后續求解器仍然可以訪問該單元格。

圖片

如上圖所示，“description”列包含自由格式文本，可能導致大量獨特的值，許多可能因單元格編碼預算而被截斷。然而，只要求解器識別了該列，它仍然可以對該列執行操作以提取所需信息。

在獲得與問題相關的列名和單元格值之后，LLM可以使用這些信息有效地與表格交互。TableRAG與可以以編程方式與表格交互的語言模型智能體兼容。

智能體使用了ReAct框架，上圖展示了TableRAG如何使用ReAct。

2.6 Token復雜性

調用LLM的效率和延遲很大程度上取決于輸入token的數量。

假設列名、單元格值和問題的長度均為O(1)。其中，N代表行數，M代表列數，D代表不同文本單元格值的數量，B代表單元格編碼預算，K代表頂級檢索結果的數量。

主要表格提示方法的token復雜性如下表：

圖片

? 讀取表格：將整個表格提供給語言模型，導致推理過程中需要O(NM)數量的令牌。

? 讀取Schema：只向語言模型提供模式，僅需O(M)數量的令牌，但會丟失表格內容的信息。

? 行-列檢索：將所有行和列編碼到嵌入中，導致編碼過程中需要O(NM)數量的令牌。然后它檢索前K個行和列以構建一個K×K的子表進行推理，其復雜性為O(K^2)。

對TableRAG中每一步的token復雜性進行分析：

? 表格查詢擴展：對語言模型的提示主要基于問題，通常只包含少量詞匯，因此這部分的令牌復雜性為O(1)。

? 構建Schema數據庫：每個列名都使用編碼器函數fenc進行編碼，導致編碼器的令牌復雜性為O(M)。

? 構建單元格數據庫：這一操作涉及使用fenc編碼不同的列-值對。當超過限制時，不同對的總數D被限制在B以內。因此，構建單元格數據庫的令牌復雜性為O(min(D, B))，確保處理最頻繁的數據以優化性能。

? 語言模型推理：查詢擴展過程通常產生大約3-5個查詢，這些查詢的復雜性為O(1)。每個查詢隨后檢索前K個結果，導致語言模型提示中包含的列和單元格值的總復雜性為O(K)。這一步確保語言模型只處理表格中最相關的信息，從而提高生成響應的效率和有效性。

總體而言，由于通常M遠小于B和D，TableRAG的令牌復雜性在編碼時為O(min(D, B))，在推理時為O(K)，且兩者均不依賴于表格的整體大小。因此，TableRAG即使面對大型表格，也能保持可控的成本，優化計算資源和大規模表格理解任務的響應時間。

3. 效果如何？

3.1 回答準確性

圖片

上表展示了測試結果，TableRAG在ArcadeQA和BirdQA上的所有語言模型中均一致超越其他方法，準確率最高。

讀取全表的方法在這兩個數據集上的表現均不佳，表明它在長上下文中存在劣勢。

在三種語言模型中，GPT 3.5 Turbo無論采用哪種表格提示方法，都能穩定提供最佳性能。

3.2 檢索性能

圖片

上表評展示了召回率、精確度和f1分數。

? 在列檢索方面，由于列數較少，所有方法都實現了較高的召回率，但TableRAG在兩個數據集上都展現了更高的精確度，這表明它在快速識別最相關列方面非常有效。

? ReadSchema和RowColRetrieval的精確度較低，說明這兩個方法檢索到了更多不相關的列。

? 在單元格檢索方面，TableRAG在所有指標上均持續超越其他方法。TableRAG在單元格檢索上的高召回率與其他表格提示方法相比有了顯著提升，表明它能夠檢索到后續推理所需的大多數單元格。總

3.3 伸縮性測試

為了探究在相似條件下不同表格大小對性能的影響，基于TabFact創建了一系列合成數據，表格尺寸從50×50到1000×1000不等。

圖片

? 如上圖所示，ReadTable在初始數據上表現強勁，隨著表格尺寸的增加，其準確性急劇下降，在表格尺寸達到100及以上時變得不可行，這是由于上下文長度的限制。

? TableRAG展現了最為穩定和可伸縮的性能，即使在表格尺寸增加到1000行和列時，其性能也只是適度下降，從83.1%降至68.4%，證明了其在處理大型表格方面的有效性。

? ReadSchema和RowColRetrieval隨著表格尺寸的增加也顯示出性能下降，但仍然保持了一定的準確率，這表明它們相對于ReadTable具有較好的可伸縮性，但在處理大型表格方面不如TableRAG有效。

3.4 與WikiTableQA上最先進技術的比較

圖片

如上表所示，TableRAG超越了所有現有方法，包括TaBERT 、Text-to-SQL 、Binder 和Dater 。表明TableRAG即使在小規模環境中也具有有效性。

盡管TableRAG旨在應對大規模TableQA任務，但其方法具有通用性，并能在不同規模和復雜性的表格上保持最先進水平的性能。

3.5 消融研究

3.5.1 TableRAG中檢索方法的影響

圖片

上表比較了TableRAG內部不同的檢索方法。

? BM25：著名的基于統計的檢索方法，效率上表現出色，能夠處理所有單元格，但缺乏語義理解能力。

結果表明：基于嵌入的檢索方法性能最佳，超越了BM25和混合方法，盡管由于編碼限制它并未處理整個表格。

3.5.2 檢索結果數量K的影響

圖片

上圖展示了改變頂級檢索結果(K)數量對性能和后續語言模型推理的令牌成本的影響。

結果表明：增加K的數量增加了提示長度，但并未一致地提升性能。

較大的K值雖然允許語言模型訪問更多信息，但也導致了更長的上下文，可能加劇“Loss in the middle”現象。

TableRAG通過減少K值的需求，降低了所需的上下文令牌數量，減少了后續推理的成本，同時仍然超越了其他方法。

3.5.3 編碼預算的影響

圖片

上圖展示了不同的token編碼預算(B)如何影響TableRAG和RowColRetrieval的性能。

雖然更高的預算理論上允許檢索更多信息，但結果表明這并不總是導致更好的性能。特別是，隨著預算的增加，RowColRetrieval的性能有所下降，可能是因為檢索到的更多行使得選擇正確的行變得更加復雜，并產生了來自更長列序列的噪聲嵌入。

TableRAG在不同預算下保持了一致的性能，表明其通過單元格頻率構建語料庫的方法即使在有限的預算下也能有效地捕獲基本信息。

3.5.4 查詢擴展的影響

圖片

上圖分析了查詢擴展方法的有效性。結果表明：查詢擴展一致地提升了TableRAG在不同數據集和語言模型中的性能。

3.5.5 模式檢索和單元格檢索

圖片

上表分析了Schema檢索和單元格檢索對性能的影響。

? 模式檢索在不同數據集和語言模型中一致地提升了推理性能，最大提升了9.4%，無論是否考慮單元格值。

? 即使對于列數較少的表格（ArcadeQA中平均20.5列，BirdQA中平均11.1列），模式檢索仍然有助于只為后續推理提供相關列。

? 單元格檢索在所有數據集和語言模型中一致地提高了準確性，最大提升了11.5%，表明單元格檢索可以從表格內容中有效地提取關鍵信息。

? 論文原文: https://arxiv.org/abs/2410.04739

本文轉載自??大語言模型論文跟蹤??，作者：HuggingAGI ????