大模型理解、推理Excel，現在變得更加精準了。

這就是來自微軟的一項最新研究——SPREADSHEETLLM，主打的就是讓大模型有條不紊地處理各種電子表格任務。

圖片

例如在下面這張圖中，如果用傳統的大模型方法，會直接忽略掉“R5:R14”這列數據。

圖片

然而，這一列數據其實是與左側單元格有著較強的語義關系，表示這些值在左側單元格中的百分比。

現在有了SPREADSHEETLLM，這種有難度的推理任務已經是可以輕松應對了。

再如當Excel表格里存在結構稀疏或者有大量空格單元的時候，大模型在識別任務上也會出錯，最終導致結果的錯誤。

圖片

而SPREADSHEETLLM就能讓大模型更加精準地“看清”Excel——

可以識別并保留表格的關鍵結構信息，同時去除多余的空單元格和行。

這項研究目前已經引來了不少網友們的圍觀，有人認為它將對那些跟數據打交道的打工人造成不小的沖擊。

圖片

不過也有網友認為微軟用大模型新研究“整治”Excel……也挺合理。

圖片

那么這項研究是如何讓大模型處理Excel的能力Pro Max的？

我們繼續往下看。

問答準確率提高了22%

在回答這個問題之前，我們先來了解一下傳統大模型在處理Excel等電子表格任務時存在的問題。

圖片

首先就是tokens的限制。

眾所周知，大部分的大模型在處理任務的時候都存在這方面的限制；而電子表格往往因為存在大量的二維網格和復雜的結構而超出了這個限制。

加之傳統的電子表格編碼方法，如HTML、XML由于需要重復使用標簽來表示數據結構，也會導致tokens的消耗較高。

即使是Markdown的編碼方法可以節省tokens，但它缺乏明確的單元格地址信息，導致在索引特定單元格位置時容易出錯。

其次還存在像結構錨點識別的問題。

在沒有有效方法來識別電子表格中的結構錨點（如表格邊界的行和列）之前，即便是GPT-4也難以理解電子表格的布局和結構。

為了解決上述的問題，微軟團隊首先提出了一個叫做SheetCompressor的編碼框架，主要包含三大模塊：

• 結構錨點壓縮（structural-anchor-based compression）
• 反向索引轉換（inverse index translation）
• 數據格式感知聚合（data-format-aware aggregation）

圖片

結構錨點壓縮的目的是識別電子表格中的結構錨點，即在表格邊界處的非同質行和列。

這一步驟主要是通過識別和提取這些結構錨點，然后移除遠離錨點的同質行和列，生成一個精簡版的“骨架”電子表格。

這種方法有效地減少了需要處理的數據量，同時保留了對理解表格結構至關重要的信息。

圖片

反向索引轉換的目的是提高tokens的使用效率，特別是在處理包含大量空單元格和重復值的電子表格的時候。

與傳統的逐行逐列的序列化方法不同，反向索引轉換采用無損的JSON格式的反向索引翻譯方法。

通過創建一個字典，將非空單元格文本作為鍵，將具有相同文本的地址合并，優化了tokens的使用，同時保持了數據的完整性。

圖片

而數據格式感知聚合，則是為了簡化對數值單元格的理解，因為相鄰的數值單元格通常具有相似的數字格式。

它先是提取單元格的數字格式字符串和數據類型，然后將具有相同格式或類型的相鄰單元格進行聚類。

通過這種方法，可以使用統一的格式字符串和數據類型來表示矩形區域，簡化了對數值數據分布的理解，減少了大量的tokens支出。

圖片

在實驗結果來看，SheetCompressor將tokens使用量減少了96%，并且與原始數據上微調的相同模型相比，性能提高了27%，在表格檢測任務上的F1分數達到了約79%。

圖片

除此之外，微軟團隊在這項研究中還提出了Chain of Spreadsheet（CoS）的框架。

它是用來擴展SPREADSHEETLLM的應用范圍，特別是在處理電子表格的下游任務的時候。

首先，CoS需要確定與特定任務查詢相關的表格，并確定相關內容的確切邊界；這一步確保了只有相關數據在后續分析中被考慮，優化了處理效率和焦點。

在確定了相關表格后，下一步是生成對查詢的準確響應。

CoS通過將處理過程分解為可管理的部分，有效地處理了復雜的電子表格，從而實現了精確且上下文感知的響應。

圖片

從結果上來看，CoS方法顯著提高了大模型在問答方面的準確性。

例如，與基線GPT-4模型相比，CoS 方法的準確度提高了22%。

微調模型在電子表格表格檢測任務上的表現也證明了CoS的泛化能力，微調后的模型在問答任務上的準確度提高了 6%。

總而言之，大模型現在處理Excel等電子表格這事兒，確實是變得更6了。

那么你覺得這項研究如何呢？歡迎在評論區留言討論。

參考鏈接：[1]https://arxiv.org/abs/2407.09025[2]https://x.com/emollick/status/1812684733538541694