這一章我們聊聊大模型表格理解任務，在大模型時代主要出現在包含表格的RAG任務，以及表格運算元據抽取文字對比等任務中。這一章先聊單一的文字模態，既你已經透過OCR或者多模態等方式從PDF或者圖片中獲取了表格的文字資料。和前文相同，我們分別介紹微調和基於Prompt的兩種方案。
Prompt LLM
首先我們介紹基於Prompt的方案，核心節約表格問答和推理中的兩個問題：表格太大或包含的資訊散落各處，問題複雜涉及到多步推理。如何使用prompt讓模型在表格任務上更好進行COT，Dater和Chain-of-Table給出了方案，二者有前後關係，Dater在前。
而針對Prompt設計，表格推理還要解決表格資料如何輸入prompt，推理效果更好的問題，這裡微軟的Table Meets LLM也做了實驗嘗試。
Dater
- Large Language Models are Versatile Decomposers: Decompose Evidence and Questions for Table-based Reasoning
Dater的整體流程包含三個步驟：表格分解，問題分解，和合並推理。論文使用了GPT3 Codex作為模型。
Evidence Decomposer
第一步是證據拆解，從原始表格資料中，抽取和問題相關的資料，這裡Dater使用行號和列號來表示相關的資料。以下使用Few-Shot Prompt來引導模型預測哪些Cell(row, index)和提問相關並返回。之後直接使用行號和列號從原始的表格中抽取出問題相關的資料，構建成更小更聚合的新的表格。
Question Decomposer
第二步是問題拆解，論文提出如果直接使用COT進行推理，在表格問題上很容易出現幻覺，所以論文提出了"Parsing-execution-filling"的方案，其實和ReACT，Self-ASK，IRCOT的思路是一樣的，不過是適配到了表格任務上。
首先基於以下Few-Shot Prompt把原始問題拆解成子問題。這裡需要注意的是，子問題不會直接使用表格中的資料進行回答，而是會把涉及數值答案的部分用{}進行掩碼。
其次會基於以下few-shot prompt把子問題轉化成SQL語句，這在TableQA的任務正規化中較為常見，很多經典方案都是把TableQA轉化成了NL2SQL的問題進行解決。
這裡的表格資料只使用了原始的表格轉化成了文字格式，並沒有加入更多表格行，列相關Schema的資料，其實相比真實場景做了簡化，這部分Schema和NL2SQL任務相似，可以參考解密Prompt系列15. LLM Agent之資料庫應用設計
Jointly Reasoning
第三步是把前兩步得到的sub-evidence和sub-questions(sql)合併在一起，同樣是使用few-shot prompt進行推理。以下prompt是TableNLI任務，也就是基於表格資料判斷描述是對還是錯。效果我們放到後面的論文裡一起說。
Chain-of-Table
- Chain-of-Table: Evolving Tables in the Reasoning Chain for Table Understanding
谷歌提出的Chain-of-Table在Dater的基礎上加入了更多，更靈活的表格操作。整個任務同樣分成三個主要步驟：動態規劃，引數推理和最終結果。整個過程中透過大模型多步規劃和引數生成，對錶格進行變換操作，直到輸出最終變換後表格，並推理出最終的結果。
Dynamic Planning
動態規劃是模型基於當前表格狀態，歷史表格操作，和使用者提問，推理生成新的表格操作函式。對比Dater只透過選擇CELL來縮小表格範圍，這裡Chain-of-Table利用大模型In-Context Function calling的能力，定義了可以靈活擴充套件的幾個表格操作函式，以下為不同functino的解碼引數和few-shot數量，其中f_select_row + f_select_column其實就對應上面Dater的表格操作。
動態規劃部分prompt包括：以上每個函式的few-shot sample和函式描述，經過多步操作後當前的表格狀態，問題和歷史的Function chain。模型推理是下一步的操作function，或者END結束如下
Argument Generation
這裡論文其實是把Function Call拆成了兩步，分別是使用哪個操作，以及操作的入參。所以這一步是基於上面推理的操作函式，推理該函式的入參
引數生成的prompt包括：和規劃prompt相同的表格狀態，規劃生成的操作函式，和每個操作的few-shot sample。這裡不同的操作Function的推理格式會有差異，例如f_add_column，除了需要推理增加的列，還需要同時給出列的取值。再例如f_select_columns存在多列選擇，因此使用*等正規表示式來支援可變引數列表。以下分別為f_add_column, 和f_select_column的few-shot demos
Final Query
經過一步或者多步上面的動態規劃生成函式+引數生成生成入參，會使用該函式對錶格進行多步操作，最後得到的表格用於問題回答。回答部分同樣是few-shot prompt如下，基於多步操作得到的最終的表格和提問進行回答。
效果上對比Dater，使用不同的基座模型，Chain-of-Table在Wiki TQ和TabFact等表格理解任務上均有一定的提升。並且在不同大小的表格資料上也都有顯著的提升。
Table Meets LLM
- Table Meets LLM: Can Large Language Models Understand Structured Table Data? A Benchmark and Empirical Study
微軟這篇論文主要實驗並回答了兩個問題
- LLM對結構化資料的理解能力究竟如何
- 對於表格類的任務Prompt應該咋寫，包括表格的格式，內容的順序，角色描描述和分割符對最終推理效果的影響有多少
首先論文把表格理解任務拆分成了多個可以定量評估的子任務，相比直接評估表格問答能力，以下子任務的評估更加簡單直接，包括：
- Table Partition：檢測模型能否識別表格的邊界，例如表格的首位字元
- Table Size Detection：檢測模型能否正確解析結構化資料，例如有幾行幾列
- Merged Cell Detection：檢測模型能否識別出合併表格結構
- Cell Lookup & Reverse Lookup：檢測模型能否正確抽取指出value對應cell的位置，或者某位置cell的取值
- Column & Row Retrieval：檢測模型能否正確抽取出某行，某列的所有取值
基於上述的7個子任務，論文首先對比了不同的表格資料表徵形式的效果差異。這裡論文實驗了包括JSON，3種不同的標記語言markdonw，XML，HTML，以及在眾多表格任務中常見的使用“|”分隔符直接分割表的NL+Sep模式。上面的Dater和Chain of Table就是NL+Sep。以下為子任務的對比結果
以上實驗資料不難得到兩個結論
- 標記語言包括markdown，XML，HTML的效果是顯著優於NL+SEP的
- 在眾多標記語言中HTML來表徵表格的效果是最好的
之前在看新加坡Prompt大賽冠軍秘籍時就發現，prompt中不同內容的分割符，和結構化資料例如標籤，表格等資料使用XML，HTML等標記語言進行表徵，效果是顯著更好的，例如使用XML表徵分類標籤在我們的任務上分類的結果更穩定，模型更不容易在分類前後給你瞎逼逼。再例如用HTML表徵表格，模型定位到具體數值的準確率也會更高。
之後論文以HTML作為基準，進一步對其他prompt細節進行了測試，如下
以上消融實驗比較明顯的結論也有兩個
- w/o 1-shot: one-shot相當重要，模型理解結構化表格資料很大程度上依賴於one-shot，去掉one-shot準確率直接掉了30%
- w/o change order順序很重要，把問題和描述放到表格後面會帶來6.8%的效果下降，可能因為模型可以基於描述和問題有針對性的理解後面的表格資料
- 其他表格格式描述，分割符之類的影響較低，可能是因為HTML類標記文字本身已經有很好的結構化表徵
論文還提出了self-augmented prompt，個人感覺略微缺乏針對性一些，感興趣的朋友自己去看細節吧~
微調
除了以上利用GPT的Prompt方案，我們再介紹兩個微調方案：Table Llama和TableLLM
Table Llama
- TableLlama: Towards Open Large Generalist Models for Tables
Table Llama是很典型的垂直領域微調方案。論文設計了TableInstruct微調資料集，篩選了總共包括14個表格資料集的總共11類任務。其中訓練集選擇8個資料集和8類任務，測試集為6個資料集和4類任務，來檢測模型在樣本外任務型別上的泛化效果。資料集和任務分佈如下
微調資料的構成就是Instruction+Input+Quesiton為輸入，Response為輸出。這裡論文使用了NL+SEP來表徵表格資料，並加入了表格任務的描述。考慮表格資料的長度往往超過4K，這裡選用LongLora微調後的7B模型為基座，
效果上分別看下樣本內和樣本外任務上的效果提升，這裡Base使用了LongLora微調後的7B，以及對比了GPT3.5和GPT4（取樣了部分樣本）。在樣本內任務上TableLlama能超越GPT4,在樣本外任務上TableLlama相比Base有顯著提升，但部分任務效果不及GPT4
TableLLM
- TableLLM: Enabling Tabular Data Manipulation by LLMs in Real Office Usage Scenarios
- https://github.com/RUCKBReasoning/TableLLM
TableLLM論文做了以下的使用者調研，更充分地瞭解了使用者對於表格任務究竟有哪些真實需求。除了前面Table Llama涵蓋的TableQA，Table Extraction，Dialogue，Fact Verfication等傳統Table2Text任務之外，還包含了更多操作類任務，例如表格匹配，表格繪圖。
整體上論文把表格資料涉及到的操作型別分成了Query，Update，Merge和Chart四大類，這四種操作在不同型別的表格資料上側重不同，在純表格資料上四種操作型別都會有，更接近現在眾多ChatBI在做的方向，更多是code-driven。而在文字中內嵌的表格資料上query查詢是主要操作，更多用於像RAG的場景，依賴純文字的理解推理。
基於上面的兩大類表格資料和四種操作型別，TableLLM說自己使用了遠端監督構建了微調資料集，其實就是傳統的Table，SQL資料集上用大模型構建了新的推理和回答作為樣本。資料集構成包含三個主要部分
- TableQA Benchmark：包括了WikiTQ,FetaQA, TAT-QA資料集，論文使用GPT3.5在原始訓練資料（question， answer）的基礎上補充了推理過程，並使用CtitiqueLLM來對推理過程進行打分，只保留打分高的樣本。這部分樣本主要用來提升模型在文字中內嵌表格資料的文字推理能力。
- Text2SQL Benchamrk：包括了WikiSQL和Spider資料集，論文使用了DeepSeek把原始的Text2SQL轉換成了pandas程式碼，並基於最終程式碼計算結果的一致性來判斷DeepSeek構建的答案是否正確，只保留結果一致的樣本。這部分樣本主要用來提升模型在純表格資料上的程式碼推理能力
- 純模型生成樣本：為了補充更多update，merge，chart操作的資料。論文從WikiTALM，TAT-QA，FeTaQA和GitTable中取樣了部分樣本，使用GPT3.5生成了新的單表操作和多表操作的問題。之後使用GPT3.5來基於表格和問題進行回答，這裡為了提高模型生成結果的準確性，會使用GPT3.5分別從coding和文字兩個方向進行推理回答，並使用CritiqueLLM來判斷兩個答案的一致性。
之後基於上面構建的樣本，針對不同的資料和操作，論文使用了不同的prompt來構建指令微調樣本，在CodeLlama-7B和13B模型上進行了微調。整個資料構建和微調prompt如下
這裡主要是看下上面表格資料構建的流程，效果對比就不說了因為部分資料集這裡加入了訓練集，而上面的Table Llama則放到了OOB測試集，不能直接對比。
想看更全的大模型相關論文梳理·微調及預訓練資料和框架·AIGC應用，移步Github >> DecryPrompt