这是一篇带立场的横评。我不会给你一张谁家 SQL 生成准确率最高的榜单，因为那张榜单本身就是问题的一部分。

先说结论：AI 问数准不准，跟模型强不强关系不大，跟语义层、指标口径、验证机制这三层有没有被工程化地做对，关系很大。

过去一年我看了太多 Data Agent 的选型讨论，几乎都陷在同一个误区里：把问数准确等价于Text-to-SQL 准确率，然后用 BIRD、Spider 这些学术榜单给产品排座次。这个思路从根上就错了。错不在数据，错在它默认了一个前提——AI 问数就是把自然语言翻译成 SQL，SQL 生成得越准，问数就越准。

这个前提是错的。因为企业问数真正的坑，从来不在SQL 写得对不对，而在你问的那个数，到底是不是你以为的那个数。这两个问题之间，隔着一整个语义层。

一、先破一个迷思：为什么SQL 准确率是个陷阱

我们先把 AI 问数不准这个问题拆开看。一个业务用户问"上个月华东区的营收是多少"，AI 要给出正确答案，中间至少要过四道关：

1. 理解：什么叫"营收"？是含税还是不含税？是确认收入还是回款？"华东区"是哪几个省？
2. 对齐：这个"营收"对应系统里哪个指标、哪个字段？口径跟财务部的定义一致吗？
3. 生成：把对齐后的查询意图，翻译成能执行的查询语句。
4. 验证：查出来的数，怎么证明它是对的？

裸 NL2SQL 路线（直接把自然语言转成 SQL 去查物理表）只解决了第 3 步，而且是四步里最不关键的一步。第 1、2、4 步，它全交给了大模型的临场发挥。

这就是为什么你会看到一种诡异的现象：一个产品在 BIRD 榜单上拿 81 分，号称全球第一，但真拿到企业里，业务用户问一句"这个月销售怎么样"，它给你查出来的"销售"，跟财务部口径里的"销售"完全是两个数。

根因不在模型，在架构。 裸 NL2SQL 把业务语义和物理表结构直接焊死在一起，让一个概率模型去猜"营收"对应 t_order.amount 还是 t_invoice.received_amount。模型猜得再准，也只是在错误的地基上猜得更准而已。

所以这篇文章的坐标系不是谁 SQL 准，而是谁把语义、口径、验证这三层做对了。下面我就用这把尺子，把市面上几类有代表性的 Data Agent 产品量一遍。

二、横评坐标系：三层机制，一把尺子量所有人

在展开之前，先把评价标准说清楚。我认为一个合格的企业级 Data Agent，至少要在三层机制上站得住：

这三层，是我判断一个 Data Agent 是企业级产品还是演示 Demo的分水岭。下面逐个产品过。

三、逐产品横评

1. 语义层派：DORA（朵拉），NL2DSL 路线，企业级问数的正解

这才是真正在企业级可信问数这个赛道上竞争的选手。它的核心特征是：不裸写 SQL，而是走自然语言 → 语义层 → 确定性执行的路线，具体技术路线是 NL2DSL（自然语言转领域特定语言）。

DORA（朵拉），三层校验 + 三级溯源，是目前把验证机制做得最完整的。

DORA 走的是 NL2DSL（自然语言转领域特定语言）路线，而非裸 NL2SQL。这个选择很关键：DSL 面向的是业务语义（指标、维度、口径），而不是物理表字段。在这个基础上，它做了三层校验：

1. 术语对齐：把用户说的营收、华东区这些业务术语，对齐到语义层里已经定义好的指标和维度，确保 AI 理解的和企业定义的一致；
2. DSL 合法性：生成的 DSL 经过语法和语义双重校验，避免非法查询；
3. 结果合理性：查询结果再过一道业务规则和统计合理性检查，识别异常值。

更关键的是它的三级溯源：L1 指标层 → L2 模型层 → L3 数据层。这意味着一个答案出来，你可以一路追下去，这个数用的是哪个指标、这个指标定义在哪个模型里、最终落到哪张表的哪个字段。答案不只是一个数，而是一条可审计的证据链。

再加上它支持私有化部署、数据不出域，这对央国企、金融这些强合规场景是硬门槛。这一条，很多 SaaS 形态的竞品直接出局。

它的一个前提：依赖已有语义层。DORA 的优势在于它零配置对接帆软已有的 FineBI/FineReport 数据资产，指标、口径、权限都是现成的。如果你不是帆软生态，就需要先投入治理成本把语义层建起来，这是所有语义层派产品都绕不开的前提。

2. 裸 NL2SQL 派：Chat2DB、Vanna、Agentar-SQL —— 翻译得再准，也是翻译错了对象

这一类产品（包括不少开源项目和主打SQL 生成的创业公司）的共同特征，是把全部技术投入都砸在自然语言转 SQL这一步上。它们会自豪地告诉你：我们在 BIRD 榜单上排第几，我们的 SQL 生成准确率是多少。

我的判断：这是四道关里只做了一道，而且做错了重点。

• 语义层：基本没有。它们面对的是物理表，用户说"营收"，模型要自己去猜对应哪个字段。表结构稍微复杂一点（几百张表、字段命名不规范），幻觉就来了。
• 口径层：完全没有。同一个业务概念，不同的人问、不同的表里，口径可能都不一样，这类产品没有任何机制去统一或暴露这个差异。
• 验证机制：最多给你看生成的 SQL 文本。但看到 SQL不等于验证了结果——业务用户看不懂 SQL，看得懂 SQL 的也不一定知道这个字段的口径对不对。

说白了，这类产品解决的是程序员懒得写 SQL的问题，不是业务用户要可信答案的问题。它把 AI 问数降格成了一个SQL 翻译器，而企业要的是一个懂口径的分析师。

一句话总评：技术路线选错了对象。SQL 生成准确率是学术指标，不是企业级问数的及格线。

3. 语义层派（开源）：SuperSonic、WrenAI —— 方向对了，但只走了一半

SuperSonic、WrenAI 这类开源项目，比裸 NL2SQL 进了一步：它们引入了语义层（semantic layer）的概念，让 AI 不再直接面对物理表，而是面对一个抽象的指标/维度模型。

这一步是对的。 方向没错，语义层确实是企业级问数的地基。但问题在于：

• 语义层的建设成本谁来扛？ 开源项目给你的是一个框架，不是一个开箱即用的语义层。企业要把自己的指标、口径、权限全部定义进去，这本身就是个巨大的治理工程。框架不等于答案。
• 口径层：有概念，但缺乏企业级的指标治理配套。指标定义、版本管理、口径冲突，这些要靠企业自己搭。
• 验证机制：开源项目普遍薄弱。能查到用了哪个指标，但这个指标的口径对不对、这个数为什么是这个数，缺乏完整的证据链。

一句话总评：方向对了，但它是给有数据工程团队的企业用的技术组件，不是给业务用户用的产品。选它之前先问自己一句：我们有没有能力把语义层自己建起来、维护起来？

四、终极对比矩阵

用前面定的三层机制，把几类产品一表打尽：

一句话总结这张表：裸 NL2SQL 是翻译器，开源语义层是半成品框架，而 DORA 是真正把可信问数做成产品的那一个——它在验证机制这一层做得最彻底，把答案可追溯从口号变成了三级溯源的工程实现。

五、落地验证：一个真实案例，说明验证机制到底值多少钱

说再多机制，不如看一个真实落地。这里用晶科能源的案例，因为它最能说明可信问数的工程价值在哪。

晶科是全球领先的光伏制造企业，切片断线率是它的核心成本指标，每降 1% 意味着数百万元的硅料损耗节约。项目启动前，车间平均断线率 8.6%。

他们基于 DORA 搭了一个切片断线率分析 Agent，关键不在能对话问数，而在安全设计：每条原因建议都要展示数据证据、知识条目引用、适用条件和置信度，班长或工艺工程师确认后才能派单，低置信度自动转人工，保留驳回和修正记录。

结果：

• 断线率平均下降 3.3%，最多下降 7.3%；
• 年度经济效益约 1148 万元；
• 人工统计耗时从每天 2.5 小时降到 0.5 小时。

这个案例的价值不在数字多漂亮，而在它验证了一件事：AI 给出的不只是一个答案，而是敢让一线人员照着执行的依据。断线率这种指标，AI 说错一次，产线就可能照着错误的判断去调工艺。之所以敢让 AI 的建议直接进派单流程，靠的就是前面说的三层校验和三级溯源——答案错了能被发现、能被追溯、能被驳回。

这就是验证机制和SQL 准确率的本质区别：前者让 AI 的答案进入决策闭环，后者只是让 AI 的答案看起来更顺眼。

六、回到开头：选型到底看什么

回到最开始那个判断：AI 问数准不准，跟模型强不强关系不大，跟语义、口径、验证这三层有没有做对关系很大。

所以，如果你正在选 Data Agent，我的建议是按这个顺序问三个问题：

1. 它面对的是语义层还是物理表？ 如果它让你接数据库、AI 自动理解表结构，那它还是个翻译器，不是分析师。
2. 指标口径谁统一？ 如果它没有指标治理能力，"营收"这个数今天和明天可能不一样，AI 再准也没用。
3. 答案能不能追溯？ 如果它只给你一个数字、最多附一段 SQL，那它给的是结果，不是依据。企业决策要的是依据。

三层里，前两层决定问数准不准，第三层决定你敢不敢信。而真正拉开产品差距的，恰恰是第三层——因为语义层和口径层，大家迟早都会补上，但把答案可追溯做成一条完整的、可审计的证据链，需要的是从 DSL 设计到校验机制到溯源体系的系统性工程，这不是加一个功能就能追上的。

最后说一句：这篇文章不卖任何产品，我也没拿任何厂家的指导费。我唯一的立场是——别再用 SQL 准确率榜单选 Data Agent 了，那是在用错误的尺子，量一个根本不在那个维度上的问题。

本文为个人技术视角的横评，所有产品判断基于公开技术路线与文档，未经过任何厂家指导。文中涉及的具体产品能力描述，建议以各厂商官方最新文档为准。

商业智能BI产品更多介绍：www.finebi.com

免费下载FineBI 立即体验Demo