LLM实现text2SQL实战总结

LLM在组织内部的应用中，有一个典型场景正变得越来越重要——利用它的NL2SQL能力，让数据库访问变得简单。简单来说，就是让非技术人员通过自然语言直接问数据库要答案，而不用写复杂的SQL语句。

核心内容：
1. LLM的NL2SQL能力及其在组织内部的应用场景
2. 如何通过设计原则优化LLM提示，提升SQL生成准确率
3. 正确描述数据表结构对LLM生成SQL语句的重要性

先说几个核心判断。这篇文章主要聊的是怎么用LLM来生成SQL，不涉及训练模型去提升它的SQL生成能力。我们聚焦在工程落地上。

聊聊目标用户画像。很明确，我们希望服务的是那些没有太多IT技术背景的业务和运营人员。随着业务发展，他们想从数据库里拿到的信息，往往会超出现有软件系统能提供的范围。而等软件开发团队排期、开发、测试，周期太长，根本跟不上需求的迫切性。更别说，熟练使用那些复杂的商业智能工具本身就需要不低的学习成本。所以，用LLM直接生成SQL，实时获取想要的数据，就成了一个非常棒的解决方案。

这里需要排除一类用户：IT运维。他们可能会想让LLM生成一些非常复杂的SQL来方便运维。但问题在于，为了生成那么复杂的SQL，用户需要输入的文本描述本身已经极其复杂，而且必须对数据库表结构和关系有深入理解。这对一般业务人员来说门槛太高了，所以先把这类需求放一边。

很多朋友会问：LLM生成SQL的准确率到底有多高？说实话，这个问题不太容易回答。如果是在训练集上训练、测试集上测试，那指标很清晰。但今天聊的是工程落地场景，不涉及模型训练。所以，基础的NL2SQL准确率是由你选用的LLM模型本身来保障的。我们真正能做的，是通过一些设计原则优化提示词，来提升SQL生成的成功率，最终保证用户的实际体验。至于最终效果如何，完全可以准备一套测试集，对整个系统做个评测，看满不满足要求。

网上能搜到不少训练NL2SQL模型的数据集，里面的数据结构描述往往都比较简单。这容易给人一个错觉：只要把数据库表的字段名和简单的注释告诉LLM，它就能生成正确的SQL。远远不够。

在这个场景下，最好把LLM当成一个经验丰富的DBA。你想让一个DBA在没看过真实数据的情况下，就帮你写出正确的SQL，你不得把表结构说清楚？不说清楚，DBA做不到，LLM同样做不到。别指望LLM能和你心意相通，总能猜到你想要什么。

其实，这种沟通问题在人类世界里也很常见。我们总是不自觉地以为对方知道那些“显而易见”的背景信息——这些在行业或团队内被认为是常识的东西。结果呢？沟通不畅，甚至误会。有经验的沟通者，会在开始正事前先对齐这些“背景信息”。当然，这需要花点时间。这也是为什么在国内的商业环境里，甲方往往更愿意和有行业经验的乙方合作，因为不用反复对齐背景信息，效率高很多。这恰恰也是新入行者不容易拿到项目的原因之一。

对于LLM来说，它没有任何行业经验，所以我们必须尽可能给它提供恰当的“背景信息”。注意“恰当”二字，不是越多越好。信息过载会消耗掉LLM有限的上下文窗口，还可能让它理解混乱。基于实践经验，这里总结了几个数据库“背景信息”的整理原则，核心目的就是提高LLM生成SQL的正确率。

尽量全面地描述表的功能

• 用业务视角来描述这张表是干什么的。描述文字要尽量和日常业务数据对得上。比如：“这是一张学生信息表”。

• 包含表中核心字段信息，例如“包括：学号、姓名、年龄、性别、班级ID……”。这些能帮助LLM判断，用户的问题是否和这张表有关。

• 如果这张表和别的表有关联，一定要描述清楚。比如：“本表通过‘班级ID’字段与‘班级表’关联，‘班级表’的ID字段是‘班级ID’的外键”。这样LLM才能理解完整的表结构关系。

尽量全面地描述字段的功能

• 用业务视角描述字段的含义。比如：“学生的名字”。

• 数值类型的字段，如果有计量单位，一定要写清楚。比如：“千米/小时”、“万辆”。

• 枚举类型的字段，即取值有限的字段。需要根据LLM自身的能力来判断是列出全部值还是只列一部分。比如，有个字段叫“行政区县”，这样描述LLM可能还是不太清楚。可以补充：“其值包括：海淀区、昌平区、东城区等”。如果字段的业务性特别强，LLM很难把用户问题里的要素和这个字段对上，那就需要把所有可能的取值都列出来，帮助它判断。这时，一些专门针对行业应用训练的LLM就有优势了，它们本身就能理解字段的业务含义和可能取值，不必全列出来。

• 时间字段，一定要说清楚数据在表里是怎么存的。SQL里处理时间格式转换是最频繁也最容易出错的，明确告知格式能让LLM少犯很多错误。

• 如果可以，尽量描述数据的格式。比如：“学生的住址信息，格式：XXX省XXX市XXX(区/县)XXX(街道/村)XXX小区”。这能增强LLM对字段含义的理解。

• 如果是外键字段，同样需要描述和别的表的关系。

适当放弃意义等价的字段

有时候表设计会留下两个业务意义完全相同的字段。比如，学生表里既有“行政区县”这个字段，又有“行政区县编码”字段。除了性能上的特殊需求，通常可以忽略掉“行政区县编码”，因为很少会有人用行政编码来查某个区域的学生。

放弃业务上无用的字段

有些字段的设计是冗余的，对实际业务没有帮助，检索时也基本用不上。比如表里设计了“经度”和“纬度”字段，但实际应用中根本没录数据。这些字段就可以在给LLM的背景信息里直接删掉。

以上这些原则，核心就一句话：该详细的地方详细，该简略的地方简略。最终目标是让LLM能清晰理解数据库的全貌。

细心的读者可能发现了，前面描述表时提到了部分字段，后面描述字段时又做了更详细的说明，感觉有些重复，占用了上下文。其实不然。这些原则有一个配套的用法，专门应对那种有几十上百张表的大型应用。一次把所有表和字段描述都丢给LLM，大概率会超出它上下文窗口的限制。怎么办？拆解成两步：第一步，只给LLM提供表的名称和描述，让它根据“背景信息”挑选出回答用户问题可能需要用到哪几张表，输出表名；第二步，再把这几张选出来的表连同它们的详细字段结构描述交给LLM，让它生成最终的SQL。通过这种分步操作，就能有效避免上下文过长的问题。

当然，这些原则更多提供的是思想方法。具体描述信息、生成SQL时，还会受到LLM型号、版本等因素的影响，需要做一些针对性的调整。希望能给同样在LLM应用路上探索的朋友带来一些启发和帮助。

下面是一个推荐给LLM的数据库“背景信息”的结构格式示例：

{
  "tables": [
    {
      "name": "表名称",
      "note": "表描述",
      "columns": [
        { "name": "列名称", "type": "字段类型", "note": "列描述" }
        {...col-n...}
      ]
    },
    {...tab-n...}
  ]
}