数字经济观察网 - 软信官网

数据库和分析厂商正借助大型语言模型（LLM）重燃"自然语言转SQL"的梦想。AWS、Snowflake、MongoDB等巨头相继推出Text-to-SQL工具，旨在让业务用户无需掌握SQL即可查询数据。然而，多伦多大学教授Nick Koudas指出，当前系统准确率仅约80%，存在生成语法正确但语义错误查询的风险。他建议将人工审核机制引入流程，并认为现阶段该技术更适合提升开发者效率，而非完全替代SQL专业人员。

近年来，数据库与分析领域的各大厂商纷纷投身一场技术浪潮，试图将普通数据查询从专业查询语言SQL的限制中解放出来。

本月早些时候，AWS承诺推出"一套自然语言转SQL的解决方案，能够将业务问题转化为数据库查询，并返回可操作的结果"。

然而，多伦多大学计算机科学系教授、自然语言SQL系统研究者Nick Koudas在接受媒体采访时提醒道：尽管文本转SQL工具或许能帮助本已掌握SQL的数据库开发者节省时间，但在让业务用户直接使用这类工具之前，各组织应保持审慎。

Koudas指出，问题在于：对于业务用户而言，系统生成的查询语句在语法上可能完全正确，却并不符合用户的真实意图。

SQL最初的设计目标是尽可能贴近自然语言。其联合设计者Donald Chamberlin曾表示，正是由于自然英语本身的局限性与歧义性，在打造这门如今几乎无处不在的数据语言时，不得不做出一定妥协。

由于掌握SQL技能的人才数量有限，各大厂商纷纷入局填补空缺，将大语言模型视为构建自然语言数据系统的理想途径。

以AWS为例，该公司介绍了用户如何借助其Bedrock平台，开发文本转SQL的概念验证项目，从而构建生成式AI应用与智能体。

AWS表示："许多组织发现，获取数据洞察仍是业务决策过程中的重大瓶颈。传统方式要么需要学习SQL语法，要么等待技术人员处理，要么只能依赖无法回答具体问题的预制报表。"

AWS认为，此类工具有助于打破阻碍快速分析的SQL专业壁垒。"大多数业务用户缺乏访问复杂数据所需的SQL技术知识。简单的问题往往涉及多表关联、时序计算和层级聚合。这种依赖关系造成了瓶颈：业务用户需要长时间等待定制报告，而分析师则将大量精力耗费在重复性查询请求上，而非战略性分析。"

AWS并非孤军奋战。2024年，云数据平台提供商Snowflake推出了一项新服务，声称可帮助组织构建聊天机器人，为用户提供来自其自身分析系统及外部系统的数据。该方案采用了厂商托管的AI服务Cortex。

此后，Snowflake推出了Cortex Analyst，引入了一套语义模型，据称能够"将业务术语与数据库结构相连接"，并"引导大语言模型通过包含正确的关联和筛选条件来生成更准确的SQL查询"。

即便是文档存储型NoSQL数据库MongoDB，也基于LangChain软件框架，推出了自己的文本转MongoDB查询API。

科技行业也为开发者提供了评估工具。例如，基准测试集BIRD-SQL宣称提供了一套跨领域数据集，用于考察海量数据库内容对文本转SQL解析的影响。目前排名靠前的是一项结合AskData与OpenAI GPT-4o的研究，执行准确率接近82%，而人类专家的水平约为93%。

尽管如此，Koudas仍对过度依赖此类系统提出警示。

"SQL作为数据库语言已有50余年历史。早在大语言模型出现之前，人们就曾设想通过自然语言转SQL使其更加易用。从纯学术研究的角度来看，研究人员一直在尝试，也一再印证了这一任务的难度。而如今有了大语言模型，得益于预训练所带来的深层语义理解能力，相关研究得以快速推进。"

他解释说，这一过程通常分为两个步骤：第一步是将自然语言映射到数据库结构，以确定查询涉及哪些数据表和字段；第二步是生成SQL语句。

"几乎所有数据库厂商都已以某种形式实现了这一功能。无论是Snowflake还是Databricks，都提供了某种文本转SQL的接口，让用户可以直接用自然语言获取SQL查询。"

目前开箱即用的准确率约为80%，原因在于大多数组织使用的系统包含专有数据集和专有结构，并有一套公司内部特定的术语体系。在缺乏额外训练的情况下，大语言模型无法获取这些定义。

不过，这类工具依然能为数据库开发人员和管理员节省时间，因为他们具备审查大语言模型生成的SQL并加以验证的能力。

"可以把它理解为一种辅助工具——服务于懂SQL的数据库开发者，让他们能够判断大语言模型返回的查询是否正确，并在出现错误时加以修正。"Koudas说道。

但他同时警告，在没有懂SQL的人参与监督的情况下使用文本转SQL系统存在风险。语法错误的查询或许无害，因为它根本无法执行；然而真正的隐患在于另一种情形。

"大语言模型经过几次尝试后，完全有可能生成一条语法完全正确、但语义上却错误的SQL查询。如果你信任它，却得到一个与实际需求毫无关联的结果，那就会造成严重问题。我认为人们已经意识到这一点。"

为了提升准确率或降低使用风险，当前研究的重点方向是将人重新纳入协作流程——但这里需要的不是SQL专家，而是用户本身。大语言模型可以在生成查询的过程中向用户主动寻求进一步澄清。

"自然语言本身充满歧义，且存在大量细微差别。因此，当大语言模型接收自然语言并开始生成SQL时，需要在推理过程中内置一套机制：一旦检测到下一个Token的生成将产生极大的不确定性，就触发该机制。由于模型能够感知自身的不确定性，并结合数据库结构映射，在遇到不确定的Token时，可以分析数据库结构，并以自然语言向用户反问，例如：'您的问题是指这个还是那个？这个字段是您需要的答案的一部分吗？'通过人与大语言模型的协同配合，人可以帮助大语言模型正确完成任务。"Koudas说道。

但就目前而言，文本转SQL的大多数应用场景与将大语言模型用于软件开发类似：它们是提升效率的工具，而非替代开发者的手段。Koudas表示，尽管文本转SQL的大语言模型系统带来了诸多便利，50年来人们对完全自然化数据查询与管理方式的探索，至今仍未画上句号。

Q&A

Q1：文本转SQL系统的准确率大概是多少？为什么达不到100%？

A：目前最先进的文本转SQL系统开箱准确率约为80%至82%，而人类SQL专家的水平约为93%。无法达到更高准确率的主要原因在于，大多数企业使用的数据库包含专有数据集、专有结构以及内部特定术语，而大语言模型在未经针对性训练的情况下，无法理解这些定义，导致生成的查询语句可能与用户真实意图存在偏差。

Q2：文本转SQL系统最大的风险是什么？

A：最大的风险在于大语言模型可能生成语法完全正确但语义错误的SQL查询。语法错误的查询因无法执行而不会造成实质影响，但一条语法正确却语义偏差的查询，可能返回看似合理却与用户真实需求毫不相关的数据结果，从而导致错误的业务决策。因此，在没有懂SQL的人参与监督的情况下直接使用此类工具存在较大风险。

Q3：如何提升文本转SQL系统的可靠性？

A：当前研究重点是将用户重新纳入协作流程。具体方式是在大语言模型的推理过程中内置不确定性检测机制：当模型判断某个Token的生成存在高度不确定性时，主动以自然语言向用户提问，请求进一步澄清。通过人与大语言模型的协同配合，用户可以帮助模型更准确地理解查询意图，从而显著提升生成结果的可靠性。