利用 Schemonic 优化数据库模式描述以降低大语言模型成本

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前沿技术追踪​​，作者： 爱读论文的吴彦祖