1.研究背景

1.1 背景

隨著 GPT-4 等大語言模型在數據管理領域的廣泛應用，如文本到 SQL 的生成和信息提取任務，向模型準確描述關系數據庫的 schema 成為解決問題的關鍵步驟。但由于 LLM 提供商通常按輸入（和輸出）文本的令牌數量收費，數據庫 schema 描述的長度直接關系到成本。例如，在文本到 SQL 的生成場景中，較長的 schema 描述會增加輸入令牌數量，進而提高每次轉換的成本。常見的描述 schema 的方法如使用 DDL 命令，雖能準確表達模式，但往往不夠簡潔。因此，如何生成簡潔且準確的數據庫 schema 描述，成為亟待解決的問題。

2.問題提出

2.1 相關術語定義

模式（Schema）：與一組表相關聯，每個表包含名稱和列，列又包含名稱和注釋，表還可能有約束，涉及列組的約束如主鍵、外鍵約束等。例如，在創建學生表的模式中，表名為 Students，包含 UniStu_ID、UniStu_Name等列，各列有相應的數據類型和約束注釋。

CREATE TABLE Students (
  UniStu_ID INT PRIMARY KEY,
  UniStu_Name VARCHAR (120) NOT NULL,
  UniStu_Street_Name VARCHAR (255) NOT NULL,
  UniStu_Street_Nr INT NOT NULL,
  UniStu_City VARCHAR (255) NOT NULL
);
# SQL 命令創建架構：需要 93 個帶有 GPT 的令牌。

標識符、令牌（Identifier, Token）：標識符令牌包括表名（前綴為“table”）、列名（非歧義時為單獨名稱，否則為表名前綴加列名）以及列或表的注釋，還包括括號等。如在學生表模式中，Table Students、UniStu_ID等都是標識符令牌。

TABLE Students (
  UniStu_ID (INT PRIMARY KEY) 
  NOT NULL (VARCHAR (255) (
      UniStu_Name UniStu_Street_name UniStu_City) 
      INT (UniStu_Street_Nr)
  ))
# （b）第一個關聯的架構文本：需要 54 個帶有 GPT 的令牌
#（在刪除為提高可讀性而添加的制表符和換行符后）。

描述語法（Description Syntax）：空字符串是有效描述，兩個有效描述的連接也是有效描述，標識符令牌與有效描述的組合同樣是有效描述。

* means UniStu_
TABLE Students(
    *ID(INT PRIMARY KEY)
    NOT NULL(VARCHAR(255)(
    *NAME *Street_name *City)
    INT(*Street_Nr))
)
# （c） 第二個關聯的架構文本：需要 39 個帶有 GPT 的標記
#（在刪除為提高可讀性而添加的制表符和換行符后）。

描述語義（Description Semantics）：從模式描述中可推斷出一組關于模式的事實，準確的描述應包含模式中所有表與列的關聯及適用注釋，且不能傳達錯誤事實。

令牌映射（Token Mapping）：將令牌映射到文本表示的函數，可能會縮短令牌名稱，不同的函數可用于表示模式中的令牌。

模式文本（Schema Text）：通過關聯的令牌映射將模式描述轉換為文本描述，其大小取決于目標模型中表示該文本所需的令牌數量。

2.2 模式壓縮問題

3.Schemonic  系統概述

3.1 系統上下文

Schemonic  系統旨在將數據庫模式壓縮為適合大語言模型的文本表示，以最小化令牌使用數量，從而降低成本。如圖2所示，輸入為待壓縮的數據庫模式和目標LLM，系統通過一系列預處理步驟，將模式壓縮問題轉化為  ILP  實例，利用 Gurobi 等求解器求解，最終將解決方案轉換為簡潔的文本模式描述。該描述可作為LLM輸入提示的一部分，用于各種與數據庫相關的任務，如文本到SQL翻譯、模式匹配、數據整理和信息提取等。雖然生成優化的模式描述可能計算成本較高，但由于數據庫模式變化相對較少，壓縮后的描述可多次重復使用，在零次或少量樣本場景中，能有效降低每次調用LLM的成本。

3.2 主算法

算法1詳細描述了  Schemonic  的模式壓縮過程。首先，生成候選前綴，通過統計模式中標識符的前綴出現頻率，篩選出有限數量（個）的高預期效用前綴，這有助于減少 ILP 問題的規模。接著，合并具有相同注釋的列，降低搜索空間大小。然后，使用簡單的貪婪算法生成初始解，該解雖不一定最優，但為 ILP 求解器提供了有用的起始點。隨后，將模式壓縮實例轉換為 ILP 實例，并通過 ILP 求解器求解，根據用戶指定的優化開銷限制（如時間限制），找到最優或接近最優的解決方案。最后，從 ILP 解決方案中提取優化的模式描述。

4.Schemonic 關鍵技術

4.1 前綴排名

為減少模式描述大小，Schemonic 考慮縮寫常見前綴來縮短令牌名稱。算法2 展示了確定潛在有用前綴的方法。首先，通過??PrefixFreqency???函數統計每個前綴在模式中的出現次數，這需要先獲取模式中所有標識符的列表（包含重復項），然后遍歷所有可能的前綴長度，提取并計數每個前綴。接著，??Prune??函數對前綴進行修剪，去除只出現一次的前綴，以及被更長且更頻繁出現的前綴所支配的前綴。最后，返回出現頻率最高的 個前綴。通過這種方式， Schemonic 能在不顯著增加計算復雜度的前提下，找到可能帶來更優解的前綴。

4.2 整數線性規劃（ ILP ）轉換

變量：ILP 實例使用多種整數變量來表示模式描述的不同方面。變量 表示令牌在槽中的選擇，表示令牌的表示方式，表示是否引入表示函數，表示槽位是否為空，表示令牌添加到上下文，表示令牌在上下文層中的情況，和

用于關聯模式描述與語義。這些變量共同構建了模式描述的完整表示，確保了在 ILP 框架下對模式壓縮問題的準確建模。約束：通過一系列線性約束確保 ILP 解決方案代表有效的模式描述。約束 C1-C5 保證變量? 和的有效賦值，如每個槽最多一個標識符和一個括號，空槽的一致性等。C6-C8 確保括號的正確使用。C9-C19 準確表示上下文與令牌的關系。C20-C26 確保描述的語義正確性，提及所有相關事實且不包含錯誤陳述。C27-C28 關注令牌的表示，確保每個令牌映射到唯一表示且引入所有使用的表示函數。

目標函數：優化目標是最小化模式描述的長度，以降低使用 LLM 的成本。目標函數通過對選定的令牌表示和使用的函數進行加權求和來實現，權重為相應文本描述的長度。雖然實際中 LLM 可能對令牌有合并處理，但實驗表明該目標函數能顯著改善成本。

4.3 優化策略

合并列：為減少搜索空間， Schemonic 合并具有相同注釋且屬于同一表的列。算法3展示了具體過程，通過遍歷模式中的所有表，收集列注釋集，將具有相同注釋的列分組，若組中列數大于1，則創建合并列名稱，最后用合并列替換原始列。這樣在不改變事實的前提下，簡化了模式表示，有助于后續壓縮過程。

貪婪算法：利用Gurobi等 ILP 求解器可接受初始解的特性， Schemonic 使用貪婪算法生成起始解。該算法遍歷所有表，合并相等注釋的列，然后根據特定語法生成描述，為 ILP 求解器提供初始值，加速優化過程。例如，對于學生表模式，貪婪算法會合并具有相同注釋的列，生成相應的初始描述。

值提示： ILP 求解器允許指定變量值的提示， Schemonic 根據令牌在原始模式描述中的出現頻率對其排序，為低頻令牌相關的上下文變量提供零值作為默認提示。這有助于在搜索過程中優先考慮更可能產生有效解的變量值組合，提高求解效率。

5.實驗結果分析

5.1 實驗設置

Schemonic 及基線方法均用 Python 3.10 實現， Schemonic 使用 Gurobi 10 作為 ILP 求解器，實驗在 EC2 c5.4xlarge 實例上進行。實驗比較了 Schemonic 與多種基線方法，包括SQL DDL命令（SQL）、文本到SQL翻譯提示模板中的模式表示（PB）和貪婪算法的輸出（Greedy）。使用來自 PublicBI 、TPC-H和 SPIDER 基準的模式，用GPT分詞器測量令牌數量， Schemonic 配置為使用所有優化策略，限制上下文層數為 3，考慮 9 個前綴，每個實例超時 20 分鐘。

5.2 壓縮方法比較

模式描述大小：圖4比較了不同壓縮方法的模式描述大小。對于 PublicBI 和 SPIDER 基準（包含多個數據庫模式），結果以箱線圖展示，TPC-H基準（單數據庫）結果為一條線。Schemonic 在平均上顯著減少了模式描述的大小，在 TPC-H 中壓縮因子達1.7， PublicBI 中達2，在 SPIDER 中某些情況下接近3。與貪婪算法相比， Schemonic 在三個基準中平均至少減少 20% 的描述長度，如在 SPIDER 中平均減少超23%，對某些模式最多減少76%。

費用：由于處理費用與模式大小成正比，第二行報告了使用 GPT-4 讀取模式描述的費用（對數軸）。傳統模式表示的讀取費用可達28美分，而 Schemonic 生成的描述費用始終低于11美分，表明優化模式描述可顯著降低成本，尤其在模式讀取頻繁的場景中，如文本到 SQL 翻譯。

壓縮時間：除 Schemonic 外的基線方法壓縮時間均小于 100 毫秒，僅在處理大型模式（讀取成本10美分及以上）時超過10毫秒。Schemonic 最多消耗5分鐘（達到超時），但能生成接近最優解的模式描述。在模式變化少而讀取頻繁的場景中，如文本到 SQL 翻譯， Schemonic 在壓縮上投入的時間可被后續處理模式描述時的節省所抵消。

5.3 壓縮對LLM準確性的影響

使用 SPIDER 基準及其變體（包含SQL查詢和自然語言問題）評估壓縮對文本到SQL翻譯準確性的影響。采用特定提示模板進行翻譯，用生成的SQL查詢與真實結果比較來計算成功翻譯的查詢數量。圖5展示了不同模型（ GPT-3.5 Turbo和 GPT-4 ）和不同模式描述下的結果，在所有場景中，各基線方法的成功率相似，表明壓縮對LLM的結果質量影響不大， Schemonic 在某些基準中表現良好，即使較小的 GPT-3.5 Turbo 模型也未因壓縮而顯著降低結果質量。

5.4 進一步分析

ILP 大小與模式維度的關系：圖6展示了模式維度與 ILP 大小的關系，表明 ILP 變量和約束數量與槽數量線性增長，與不同令牌數量二次增長，與理論分析一致。由于列名通常是令牌的主要部分，令牌數量與模式長度高度相關，結果顯示超線性增長。

優化策略的影響：圖7通過消融研究展示了優化策略的影響，依次移除貪婪解插入、變量值提示和列合并優化。結果表明，所有優化策略啟用時可解決 100% 的測試用例，而全部禁用時無法解決任何問題，證明了優化策略對 Schemonic 性能的重要性。

6.總結

本文介紹了 Schemonic 系統，它致力于優化包含關系數據庫 schema 的提示，以減少大語言模型的令牌使用數量，進而降低調用開銷。通過將 schema 壓縮建模為組合優化問題，并利用整數線性規劃求解器， Schemonic 能夠自動生成簡潔且準確的數據庫模式描述。實驗表明，該系統在顯著降低成本的同時，不影響大語言模型在任務（如文本到SQL翻譯）中的準確性。這一研究成果為在實際應用中更經濟高效地使用大語言模型處理數據庫相關任務提供了重要的技術支持，有助于推動人工智能在數據管理領域的進一步發展。

論文地址：???https://www.vldb.org/pvldb/vol17/p3511-trummer.pdf???

Generating Succinct Descriptions of Database Schemata for Cost-Eficient Prompting of Large Language Models  

代碼地址：???https://github.com/itrummer/schemacompression??

原文鏈接：??https://www.yuque.com/u21774036/qnmlr1/gmtdxrgyq4z4wohv?singleDoc??

本文轉載自 ??AIGC前沿技術追蹤??，作者： 愛讀論文的吳彥祖