什么是 NL2SQL？它是如何工作的？

该英文文本是根据法文原文自动生成的，尚未经过审查。

该页面已自动翻译。英文版具有权威性。

这个想法先于当前的主要语言模型：问题到 SQL 的翻译系统已经存在多年的学术研究，并具有 Spider 或 WikiSQL 等参考数据集。最近的法学硕士发生的变化是在任何图表上生成的 SQL 的质量，无需事先进行专门培训。本文以 Aurabase 的原生 AI 的经过验证的实现作为具体示例而不是抽象描述，逐步解释实际机制。

要点

NL2SQL（或文本到 SQL）通过 LLM 和执行前的验证步骤将自然语言问题转换为可执行的 SQL 查询。
管道始终包含相同的顺序：通过模型生成 SQL、语法验证、针对真实模式的验证、受行数上限限制的执行。
主要风险不是经典的客户端 SQL 注入，而是模型、表或发明的列所产生的 SQL 的盲目执行。
严格的 NL2SQL 引擎只接受 SELECT 查询：任何写入尝试（INSERT、UPDATE、DELETE、DROP）在到达数据库之前都会被拒绝。
Aurabase 的 NL2SQL 引擎在代码中进行了验证，可验证通过语法树解析器 (sqlparser)、十个 SQL 函数的白名单和可配置的行上限（默认为 100，最多 1000）生成的 SQL。
NL2SQL 和 RAG 满足不同的需求：一种是结构化和关系型内容，另一种是非结构化内容。

定义

NL2SQL 到底是什么？

NL2SQL 是指将自然语言问题自动翻译为可以在关系基础上执行的 SQL 查询。与以自由文本响应的通用聊天机器人不同，NL2SQL 系统生成结构化工件 SQL，它针对真实数据执行并逐行返回可验证的结果。

“文本到 SQL”一词来自自然语言处理的学术研究。 “NL2SQL”是产品和技术文档方面最常用的缩写。两者都涉及同一问题：弥合日常语言提出的问题与 SQL 引擎期望的精确语法之间的差距。

NL2SQL 与广义上连接到数据库的会话代理不同。第一个生成可读且可审核的查询；第二个可以链接多个工具调用（搜索、计算、写入），而不必产生唯一且可检查的 SQL。正确设计的 NL2SQL 系统保留在这个故意限制的范围内：翻译、验证、执行、返回结果。

机制

NL2SQL 管道如何工作（一步一步）

无论提供者如何，可靠的 NL2SQL 管道始终遵循相同的顺序：问题通过语言模型，然后在执行之前（而不是之后）验证生成的 SQL。在 aura-ai服务代码中验证的 Aurabase 实现使用具体规则而不是抽象描述来说明每个步骤。

1.收到问题时附有底座实际示意图

系统将自然语言的问题与查询数据库的模式相关联：表名、列、类型。该模式必须来自对实际基础的内省，而不是来自调用者提供的描述。接受客户声明的模式的实现将为有关不存在的表的问题或绕过项目之间的隔离打开大门。 Aurabase 引擎明确拒绝（400 错误）请求中发送的任何 schema 字段，而不是默默地忽略它。

2.LLM生成候选SQL

语言模型在提示中接收问题和模式，然后生成候选 SQL 查询以及简短的解释。 Aurabase 对三个提供商一视同仁，并提供专门的本地客户端：OpenAI、Anthropic (Claude) 和 Gemini。该候选 SQL 现阶段只是一个提案，从未直接执行。

3.候选SQL在执行前验证，而不是执行后验证

这是区分严肃的 NL2SQL 系统与简单的 LLM 调用（然后是幼稚执行）的步骤。生成的 SQL 被解析为语法树 (AST)，而不是通过关键字搜索进行检查，这很容易被绕过。带有 sqlparser库的 Aurabase 实现仅允许简单的 SELECT 查询：CTE/WITH、子查询、UNION、窗口函数和锁定子句 (FOR UPDATE) 被明确拒绝，十个函数白名单之外的任何 SQL 函数也是如此 (count、 sum、 avg、 min、 max、 lower、 upper、 coalesce、 date_trunc、 now)。

4.提交的查询以行上限运行

如果尚未有，则经过验证的 SQL 会收到 LIMIT：Aurabase 默认情况下为 100 行，最多 1000 行，这两个值均可在服务器端进行配置。超出上限的请求会被明确拒绝，而不是默默减少。响应表明该 LIMIT 是否是由服务器添加的，因此调用者知道执行的 SQL 是否与模型生成的 SQL 不同。

exemplesql

-- 问题：“高级客户本月有多少订单？”
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- 由服务器添加，生成的 SQL 中缺失

我们的在 Postgres上构建 NL2SQL 端点的分步教程中介绍了该管道的完整细节，包括每个 HTTP 调用和每个 JSON 响应。

使用案例

NL2SQL 与手写 SQL：何时使用什么

NL2SQL 并不打算在任何地方取代手写 SQL。它涵盖了一个特定的范围：由不懂 SQL 或只是想节省简单查询时间的人提出的临时、一次性问题。

由非技术人员（支持、产品、管理）对仪表板进行临时探索。
查询数据库的功能的快速原型设计，无需为每个可能的问题编写专用的 API 路径。
有限的分析自助服务：计数、过滤、简单聚合，而不向最终用户提供对数据库的直接访问权限。

一旦问题超出这个范围，手写 SQL 仍然是更好的选择。出于安全原因，像上面描述的那样经过 AST 验证的实现通过构造排除了 CTE、子查询和窗口函数。结构上需要这些构造、队列、高级时间窗口的分析不经过 NL2SQL：它是直接编码的。这是一个可接受的妥协，系统的安全性优先于生成的 SQL 的完整性。

风险

NL2SQL的风险：注入、幻觉、成本

NL2SQL 实施中系统性地重复出现三种风险，根据系统的成熟度，有不同的应对措施。

通过提示或问题进行 SQL 注入

如果问题本身包含“忽略先前的语句并且...”注入尝试，则可以操纵 LLM 来生成恶意 SQL。防御方法不是信任提示，而是验证独立于请求的内容生成的 SQL，这正是上述管道的第 3 步。该主题值得专门讨论：请参阅保护 NL2SQL 免受 SQL 注入了解精确的攻击向量和对策。

不存在的表或列的幻觉

该模型可能会发明一个看似合理但在实际模式中缺失的表或列名称，特别是在大型或文档记录不完善的模式上。根据实际数据库模式验证生成的 SQL 的实现会使用显式消息拒绝查询，列出实际可用的表，而不是让原始 SQL 错误传递回用户。

模型调用的成本和延迟

每个 NL2SQL 问题都会触发对语言模型的调用，除了 SQL 执行时间之外，还有其自身的成本和延迟。如果 NL2SQL 作为重复问题的默认层，这种成本会迅速增加，这将受益于缓存或作为标准报告公开，而不是每次都重新翻译。

信任需要衡量，而不是假设

NL2SQL 引擎返回的置信度分数（响应形式的启发式，无论 SQL 块是否格式良好）并不是语义准确性的衡量标准。它表明模型生成了语法干净的 SQL，而不是该 SQL 正确回答了所提出的问题。

建筑

原生 NL2SQL 与组装式 NL2SQL：它为开发人员带来了什么变化

两种架构产生相似的可见结果，但保证却截然不同。原生 NL2SQL 将生成、验证和执行直接集成到后端层，后端层已经知道项目的架构和访问权限：这是上面为 Aurabase 描述的逻辑，其中 aura-ai 服务与后端的其余部分共享基础架构和架构隔离。

组装的 NL2SQL 结合了通用的 LLM 服务、数据库连接器和自行构建的验证层。没有什么可以阻止这种方法的安全，但是每一个保证，服务器端内省模式，AST验证，行上限，隔离租户，都必须由将这些砖块组合在一起的团队来实现和维护，而不是由平台提供。

我们的 NL2SQL 2026 工具比较中详细比较了 NL2SQL 工具（本机和组装、开源和商业）的情况。

区别

NL2SQL 和 RAG：有什么区别？

NL2SQL 和 RAG（检索增强生成）回答了两个不同的问题系列，这些问题经常令人困惑，因为它们都依赖于连接到数据库的 LLM。

NL2SQL 针对结构化和关系数据：有多少、何时、什么比例，这些问题自然会转化为 SELECT、 GROUP BY、聚合。 RAG 的目标是非结构化内容：文档、注释、支持票，其中答案不适合表行，但需要通过语义相似性、pgvector 上的向量搜索、HNSW 索引找到相关段落，然后再将其提供给模型上下文。

The two capabilities can coexist in the same project and combine in an agent who chooses one or the other depending on the question asked. The Aurabase native AI pillar details how the two mechanisms work together, and our RAG pipeline guide on pgvector covers the implementation of the second.

常见问题解答

常见问题解答

Text-to-SQL 和 NL2SQL 是一回事吗？+

是的，这两个术语指的是同一系列系统：将以自然语言提出的问题转换为可执行的 SQL 查询。 “Text-to-SQL”是学术研究中使用的术语（参考库如 Spider 或 WikiSQL），“NL2SQL”是产品和技术文档方面最常见的缩写。这两个名称之间没有技术差异。

NL2SQL 可以幻觉不存在的表或列吗？+

语言模型可以生成虚构的表名，这是任何基于 LLM 的系统的真正风险。重要的是接下来会发生什么：根据实际数据库模式验证生成的 SQL 的实现会使用显式消息拒绝查询，而不是盲目执行它。这是在 Aurabase NL2SQL 引擎中验证的行为，该引擎列出了错误消息中实际可用的表。

NL2SQL 可以执行写入（INSERT、UPDATE、DELETE）吗？+

没有认真执行。设计良好的 NL2SQL 引擎仅在语法树级别接受 SELECT 查询并拒绝执行前的任何写入尝试，而不是通过文本中的简单关键字搜索。在采用工具之前检查这一点：一些开源 NL2SQL 原型默认情况下不施加此限制。

进行 NL2SQL 是否需要经过专门训练的模型，或者一般的 LLM 就足够了？+

如果您在提示中提供实际的数据库图表，最近的一般 LLM（GPT、Claude、Gemini）足以满足大多数用例。存在专门的模型，对问题/SQL 对进行改进，并在非常大的模式或奇异的 SQL 方言上提高精度。但生成的 SQL 的验证比系统安全模型的选择更重要。

NL2SQL 会取代数据分析师吗？+

不，它改变了工作的性质，而不是消除它。 NL2SQL 涵盖结构化和重复出现的问题、计数、过滤器、简单聚合，否则需要分析师进行一次性查询。需要业务判断、建模或措辞不当的问题重新表述的分析仍然是理解上下文的人的工作，而不是机器翻译系统的工作。