我做企业数据分析平台落地这件事，前后快八年了。中间接手过不少 AI 问数、NL2SQL 相关的项目，也踩过不少坑。今天想聊一个我反复被问到、也反复被误解的话题：NL2SQL 评测，到底该怎么看执行准确率。

一个让我重新审视"准确率"的项目

先讲一个让我印象很深的项目。那会儿我们团队要给一家制造企业上自然语言取数能力，让业务人员直接用大白话查数据。选型阶段，我们拿着业内常用的公开评测集去测各家方案，结果有一家方案的执行准确率跑到了 90% 以上，远超其他家。当时所有人都觉得，就它了。

结果上线三个月，业务人员的真实反馈是：问十句，能对上预期的大概五六句。准确率腰斩。问题出在哪？不是那家方案变差了，而是我们当初那个"90%"的评测，本身就没测对地方。

这篇文章，我想把这件事讲透：为什么"执行准确率"这个指标，在企业场景里会严重失真；一个真正面向生产环境的 NL2SQL 质量评价体系，应该长什么样。

执行准确率，到底在测什么

先把概念掰开。NL2SQL 里的"执行准确率"（Execution Accuracy），标准定义是：模型生成的 SQL 在数据库上执行后，返回的结果集和标准答案 SQL 的结果集完全一致的比例。它比"文本匹配准确率"更宽松——只要结果对，SQL 写法不同也算对。

这个指标本身没毛病，在学术研究和公开榜单里，它是衡量模型能力最主流的指标。问题在于，它默认了一个前提：标准答案只有一个，且是"正确"的。

这个前提，在公开评测集里成立。因为评测集是人工构造的，每道题都配了一个精心标注的标准 SQL，语义清晰、口径明确、没有歧义。但在企业真实场景里，这个前提几乎处处不成立。

企业场景里，标准答案常常不存在

企业真实数据里，"标准答案"这件事本身就是稀缺品。一个业务问题，往往对应着好几种合理的 SQL 写法，对应着好几个可能的口径，甚至对应着好几个业务部门各自认定的"正确答案"。

举一个我实际遇到过的例子。业务人员问："上个月的销售额是多少？"这句话看着简单，但"销售额"三个字，在财务口径里是含税开票额，在销售口径里是不含税签单额，在运营口径里可能又是回款额。同一个问题，三个部门三个答案，到底哪个算"标准答案"？

如果评测时只拿其中一个口径当标准答案，那么另外两个口径生成的 SQL，执行结果不一样，就会被判为"错误"。但这个"错误"，对使用它的那个业务部门来说，恰恰是"正确"的。

这就是执行准确率在企业场景失真的第一个根源：口径不唯一，标准答案本身就不唯一。

准确率高，不代表"能用"

第二个更隐蔽的问题，是执行准确率测不出"结果有没有用"。

我见过太多这样的案例：模型生成的 SQL 语法完全正确、执行完全成功、结果集也和标注答案一模一样，但业务人员拿到这个结果，依然觉得"没用"。为什么？因为结果虽然是"对"的，却不是业务人员"要"的。

比如业务人员问"最近销售怎么样"，模型可能返回一个全公司的总销售额数字。语法对、执行对、结果和标注答案也对，但业务人员真正想要的是"分区域的趋势对比"，想要的是"和去年同期比"。模型给了一个"正确但无用"的答案，执行准确率却把它记成了满分。

再比如，业务人员问"哪些客户流失了"，模型返回了所有流失客户的长名单，几百行。执行准确率满分，但业务人员要的其实是"流失客户的特征画像"或者"流失金额占比"，一个几百行的名单对他来说毫无操作价值。

执行准确率测的是"结果对不对"，却测不出"结果是不是用户想要的"。而在企业场景里，后者才是决定 AI 问数能不能被真正用起来的关键。

一个"满分"但被弃用的功能

我在另一个项目里见过一个极端例子。当时我们给一套 BI 产品接了一个自然语言查询入口，内部评测执行准确率高达 95%，团队一度很乐观。但上线后，这个入口的使用率持续走低，最后几乎没人用。

复盘时我们发现，问题不在准确率，而在"体验"。业务人员问问题，模型返回的是一段 SQL 加一个结果表格，但业务人员看不懂 SQL，也不确定这个结果是不是自己想要的，更不知道这个结果是怎么算出来的。他们宁可回到原来的拖拽式操作，至少每一步都是自己点的、自己看得懂的。

这个例子说明，企业场景里，光有"执行准确率"远远不够。一个结果要真正被用起来，还需要可解释、可追溯、可信任。而这些维度，执行准确率一个都测不到。

企业真正该测的，是这四件事

那企业场景的 NL2SQL 质量评价，到底该测什么？结合我这几年踩过的坑，我认为至少要从四个维度去建评价体系。这四个维度，执行准确率只是其中一个，而且远不是最重要的那个。

下面逐一展开讲。

维度一：口径正确性

这是企业场景里最基础、也最容易被低估的维度。它要回答的问题是：模型给出的结果，符不符合企业认定的业务口径。

前面说过，企业里同一个指标往往有多个口径。所以评价口径正确性，不能只拿一个标准答案去对，而是要先把"这个场景下，正确的口径是什么"定义清楚，再看模型有没有理解并遵守这个口径。

这里有一个关键的工程手段，就是语义层。语义层把物理表字段，映射成业务指标和维度，把口径在源头就固化下来。模型面对的是已经对齐过口径的业务指标，而不是一堆含义模糊的物理字段。这样一来，口径歧义从源头就被消解了，模型生成的结果自然更符合业务口径。

我在落地时的一个体会是：没有语义层，口径正确性基本靠运气；有了语义层，口径正确性才有了工程上的保障。这也是为什么现在做企业级 AI 问数的产品，几乎都在语义层上做文章。

维度二：意图匹配度

这个维度要回答的是：模型给的结果，是不是用户真正想要的。

这比口径正确性更难测，因为它涉及对用户意图的理解。同一个问题，不同用户、不同场景下的意图可能完全不同。评价意图匹配度，不能靠自动化的标准答案比对，而需要引入业务人员的真实判断。

我的做法是，在企业里建一个"业务问题—期望结果"的评测库，这个库不是公开评测集那种通用问题，而是企业自己沉淀的真实业务问题，每一道题都标注了业务人员真正期望得到的结果形态。评测时，让业务人员来判分：这个结果，是不是我想要的。

这个评测库的价值，不在于追求一个漂亮的分数，而在于它能真实反映"AI 问数到底帮没帮上忙"。它也是持续迭代的基础——每次发现意图匹配失败的案例，就补进库里，倒逼模型和语义层改进。

维度三：可解释性

这个维度要回答的是：结果能不能被追溯、被理解、被信任。

企业场景里，业务人员对 AI 给出的结果，天然是不信任的。这种不信任，只有靠可解释性来消解。一个结果，如果能让用户看到它用了什么口径、数据来自哪、计算过程是什么，用户才敢信、才敢用。

评价可解释性，可以从几个方面看：结果能不能下钻到明细数据；能不能追溯到数据血缘；能不能展示计算逻辑。能追溯的结果，才是能进入经营决策的结果。

这一点，前面那个"95% 准确率却被弃用"的案例就是最好的反证。准确率再高，结果不可解释，用户也不敢用。可解释性，是 AI 问数从"参考工具"升级为"决策依据"的分水岭。

维度四：鲁棒性

这个维度要回答的是：模型面对真实世界的"不完美"，能不能保持稳定。

企业真实数据和真实问法，处处是不完美。数据有脏值、有缺失、有口径冲突；问法有歧义、有口语、有错别字。模型在干净评测集上表现再好，到了真实环境里，能不能扛住这些不完美，才是关键。

评价鲁棒性，要专门构造"对抗性"的测试：往数据里加脏值，看模型会不会崩；用有歧义的口语问法，看模型会不会误解；用跨表、跨主题的复杂问题，看模型会不会跑偏。能扛住这些测试的模型，才具备上生产的资格。

企业级质量评价体系，怎么落地

把四个维度讲清楚了，接下来是落地的问题。一个评价体系，如果不能落地、不能持续运转，就只是纸上谈兵。结合我的实践，落地这件事，可以拆成三步。

第一步，建评测库。这是整个评价体系的地基。评测库要包含三类题目：一是企业真实业务问题（测意图匹配度和口径正确性），二是带脏数据、歧义问法的对抗性问题（测鲁棒性），三是需要追溯和解释的问题（测可解释性）。这个库不是一次建完就完事，而是要在使用中持续扩充——每次线上发现问题，就沉淀进库。

第二步，定评价流程。评测不能是一次性的选型动作，而要嵌入到持续迭代的流程里。每次模型升级、语义层调整、数据源变更，都要跑一遍评测库，看四个维度的分数有没有下降。把评测变成"发布前的门禁"，而不是"事后的事故复盘"。

第三步，引入人工判分。口径正确性和意图匹配度这两个维度，自动化判分能力有限，必须引入业务人员的人工判分。这不是效率低，而是必要——因为"结果对不对、有没有用"，最终只有业务人员说了算。可以设计一个轻量的判分流程，让业务人员在日常使用中顺手给结果打分，这些分数反过来又喂给评测库。

一个可参考的评价指标表

为了让大家落地时有个抓手，我把四个维度和对应的评价指标整理成一张表。这张表可以作为企业自建评价体系的起点。

这张表的价值，在于把"感觉模型还行"变成"每个维度都有数可依"。企业可以根据自己的业务特点，调整每个维度的权重，但四个维度缺一不可。

语义层，是评价体系的底座

讲完评价体系，我想单独强调一下语义层这件事。因为在四个维度里，有三个维度（口径正确性、意图匹配度、可解释性）都直接或间接地依赖语义层。

语义层解决的是"业务语言和数据结构之间的鸿沟"。业务人员说"销售额""大客户""退货率"，这些是业务语言；数据库里存的是字段名、表名、关联关系，这些是数据结构。语义层在中间做翻译和固化，让模型面对的是业务指标，而不是物理字段。

有了语义层，口径正确性有了保障（口径在语义层固化），意图匹配度有了基础（业务指标天然贴近用户意图），可解释性有了支撑（结果可以追溯到语义层定义的指标和口径）。可以说，语义层是企业级 NL2SQL 评价体系的底座，没有它，评价体系就是空中楼阁。

这也是为什么，我在选型时，会把"有没有语义层、语义层做得好不好"作为比"执行准确率"更重要的判断标准。执行准确率是表象，语义层才是决定长期表现的内核。

帆软 FineBI（AI原生版）是怎么做的

说到语义层，可以拿帆软的 FineBI（AI原生版）举个例子。这款产品在做 AI 问数时，一个核心思路就是把业务语义层做扎实——先把企业的指标、维度、口径在语义层里定义清楚，再让模型基于这个语义层去理解问题、生成查询。

这个思路带来的直接好处，是口径正确性和可解释性有了工程保障。模型面对的是已经对齐口径的业务指标，结果可以追溯到语义层定义的指标和计算逻辑。业务人员拿到结果，能看懂、能追溯、能信任。

当然，我不建议把任何一家产品神化。语义层这件事，各家都在做，只是深度和成熟度不同。企业在选型时，应该用自己的真实数据、真实问题去验证，看语义层到底能不能解决自己业务里的口径和追溯问题，而不是只听厂商讲概念。

别再被"准确率"这一个数字骗了

回到开头那个项目。如果让我重新选一次，我会怎么做？

免费试用

我不会再只盯着那个"90% 的执行准确率"。我会先建一套包含真实业务问题、对抗性问法、可解释性检查的评测库，然后让候选方案在这个库上跑，看四个维度的表现。我会特别关注：面对我司真实的口径歧义，它能不能理解；面对业务人员真实的口语问法，它能不能扛住；给出的结果，业务人员能不能看懂、敢不敢用。

我相信，这样选出来的方案，上线后的真实表现，会比当初那个"90%"靠谱得多。

执行准确率不是没用，它是个必要的基础指标，但它远远不是充分指标。企业场景的 NL2SQL 质量，是一个多维度的、需要持续运营的体系，而不是一个可以一锤定音的数字。谁要是只拿"执行准确率"这一个数字来跟你谈 NL2SQL 能力，你就要多留个心眼了——他要么不懂企业场景，要么在回避真正重要的问题。

把评价体系建扎实，把语义层做扎实，把人工判分跑起来，AI 问数才能真正从"演示的惊艳"走向"生产的可靠"。这条路我走了好几年，踩了不少坑，也攒下了一点经验。希望这篇复盘，能让正在这条路上的人，少走一点弯路。

免费试用

常见问题（FAQ）

1. 执行准确率（Execution Accuracy）到底是什么？

执行准确率是 NL2SQL 评测里最主流的指标，指模型生成的 SQL 执行后，返回的结果集和标准答案 SQL 的结果集完全一致的比例。它比"文本匹配准确率"更宽松，只要结果对、SQL 写法不同也算对。这个指标在学术研究和公开榜单里很有价值，但在企业场景里会严重失真，因为它默认"标准答案唯一且正确"，而企业里口径往往不唯一。

2. 为什么企业里执行准确率会失真？

主要有两个原因。一是口径不唯一：企业里同一个指标（比如"销售额"）往往有多个业务口径，标准答案本身就不唯一，拿其中一个口径当标准答案，会把其他口径的正确结果误判为错误。二是"结果对不对"不等于"结果有没有用"：模型可能给出语法正确、执行正确、结果也匹配标注答案的 SQL，但这个结果不是业务人员真正想要的，执行准确率却记成了满分。

3. 企业场景的 NL2SQL 质量，应该从哪几个维度评价？

建议从四个维度建评价体系：口径正确性（结果是否符合业务口径）、意图匹配度（结果是否是用户真正想要的）、可解释性（结果能否被追溯和理解）、鲁棒性（面对脏数据、歧义问法是否稳定）。执行准确率只是基础指标之一，远不是最重要的那个。

4. 语义层在质量评价里起什么作用？

语义层把物理表字段映射成业务指标和维度，把口径在源头固化下来。它对四个维度中的三个都有直接支撑：口径正确性有了保障（口径在语义层固化）、意图匹配度有了基础（业务指标贴近用户意图）、可解释性有了支撑（结果可追溯到语义层定义的指标）。可以说，语义层是企业级 NL2SQL 评价体系的底座，没有它，评价体系就是空中楼阁。

5. 这套评价体系怎么落地？

可以分三步：第一步建评测库，包含企业真实业务问题（测意图和口径）、带脏数据和歧义问法的对抗性问题（测鲁棒性）、需要追溯解释的问题（测可解释性），并在使用中持续扩充；第二步定评价流程，把评测嵌入持续迭代流程，作为发布前的门禁；第三步引入人工判分，口径正确性和意图匹配度这两个维度必须由业务人员判分，日常使用中的打分反过来喂给评测库。