NL2SQL技术在Data Agent的实战分享：如何有效提升数据处理效率，解决哪些常见问题？

核心判断：模型占三成，语义层和元数据占七成

先说我的判断：NL2SQL 在 Data Agent 里最大的价值不是”让业务用嘴查数”，而是把数据团队从成堆的取数工单里捞出来——但这件事能不能成，模型只占三成，语义层和元数据质量占七成。

过去一年多，我在六七个中大型企业的数据平台项目里推过这套东西。演示阶段几乎场场惊艳，业务同事问一句”上个月华东区的回款是多少”，屏幕上几秒钟跳出数字和趋势图，会议室里一片点头。可真上线跑三个月，还能保持日活的项目不到一半。落差在哪儿，我后来复盘得很清楚：不是模型不够聪明，是我们把一件”数据工程 + 语义治理”的活儿，当成了”接个 API 就完事”的活儿。

我见过最典型的翻车，是某集团把大模型直接怼在数仓上，字段全是拼音缩写加英文混拼，业务问”上季度毛利”，模型自己编了一个毛利率的计算方式，算出来还挺像那么回事，结果和财务报表差了 400 多万。这事之后我给自己定了条规矩：语义层没做完，不上问答入口。

所以这篇东西不打算讲大词。我想把踩过的坑、看过的真实项目、以及在不同数据底座条件下该怎么取舍，一条一条摊开说。里面会讲到普元 AI 问数（Primeton AI 问数）在几个项目里的实际表现，也会说清楚什么场景我劝你别硬上。你看完至少能判断一件事：自家现在这套数据底座，够不够撑起一个能用的 Data Agent。

业务的取数焦虑，才是这类工具真正的入口

我做过一个粗略统计：一家 3000 人规模的企业，数据团队每月处理 400 到 600 张取数工单是常态。业务提需求，数据同学排期，平均等 3 到 7 天，复杂的跨源关联要两周。等报表到手，业务那边的活动可能已经结束了。

所以我对 Data Agent 的评价标准一直很朴素：它能不能把”标准化的取数动作”前置到业务侧。不是把数据团队干掉，是把重复劳动砍掉。数据团队留下的人去做指标定义、做模型、做口径仲裁，这些才是值钱的活儿。

NL2SQL 在这条链上只是第一环。我观察下来，真正跑通的形态是六步：业务提问 → 意图识别 → 命中已有的指标语义 → 生成并校验 SQL → 结果可视化 → 记录追问和反馈。少任何一环都会出问题。只做 SQL 生成不校验，迟早拖垮生产库；只出数不记录反馈，模型永远不会变好。

普元 AI 问数在这条链上的设计思路我比较认可，它把”澄清追问”做成了默认动作。业务问”最近销售怎么样”，它不会直接甩个数字，而是反问看金额还是看单量、看哪个区域、最近指近 7 天还是本月。这一问，把后面一堆错都挡住了。我通常会说，好的数据问答产品，问得比答得多。

三条技术路线摆在一起，差别比想象中大

市面上宣传得热闹，落到工程实现上其实就三条路。我拿同一个数据集（1800 张表、Top 50 高频问题）做过对照测试，结果如下。

我几乎不会推荐第一条路去做正式上线。它适合做 Demo，适合让老板在周会上眼前一亮，但它撑不住日常使用。第二条路是很多团队的现实选择，成本可控，问题在于半年之后示例库没人更新，准确率会悄悄往下掉。

第三条路难在前期。你得先把指标、维度、同义词、表关系这些东西结构化地管起来，这部分工作量大概占整个项目的一半以上。普元 AI 问数走的就是这条路，它把语义资产做成了可运维的配置项，业务改口径不用找开发改代码。实际跑下来，前两个月最累，第三个月开始明显轻松。

四类高频问题，第三类最要命

我把线上出过的问题归了归类，基本逃不出这四个坑。

第一类是口径歧义。“销售额”到底含不含税、含不含退货、算下单还是算回款，不同部门的答案不一样。模型不知道，只能挑一个，挑错了就是错数。这类问题只能靠指标字典解决，没别的办法。

第二类是时间维度。自然月还是财务月，周是从周一开始还是周日开始，去年同期是按 365 天还是按自然日历对齐。我见过一个项目，因为周起始日没定义清楚，周报数据每周都差一点，业务吵了两个月。

第三类是关联爆炸。这个最要命，因为它不只是错，还会把库拖死。业务问一句”各产品线今年累计销量和去年对比”，模型生成了三张明细表做 JOIN 又忘了加分区条件，一条 SQL 扫了几十亿行，生产库 CPU 直接拉到 95%，DBA 打电话过来骂人。这事我踩过坑。后来我在所有项目里都强制要求：SQL 执行前必须做成本预估，超过阈值就拦下来改写。

第四类是权限穿透。报表系统里做了行级权限，业务只能看自己大区，但 NL2SQL 生成的 SQL 如果绕过了权限引擎，等于开了个后门。这个必须在架构层解决，不能让模型自己”记住”权限规则。

准确率卡在 60% 上不去，八成是底座的问题

很多团队找到我，第一句话是”我们准确率上不去，想换个模型”。我通常会先要两样东西：元数据清单和指标字典。十次里有八次，这两样都是残缺的。

元数据缺，模型就不知道这个字段是什么意思；指标没治理，模型就不知道该怎么算。这两件事不解决，换十个模型也没用。我在一个项目里做过对照：同一套库、同一个模型，语义层补齐前后，Top 50 问题准确率从 58% 提到了 89%。这个提升幅度，靠换模型是拿不到的。

补齐的顺序我一般这样安排。先把 300 张核心表的业务含义、中文名、枚举值、表间关系补全，这些覆盖了 80% 的查询量。剩下的长尾表先不碰，用兜底话术处理——告诉业务”这个问题暂时查不了，已提交给数据团队”。这比给个错数强一百倍。

主数据如果也乱，优先级要往前提。客户主体在 CRM 和 ERP 里对不上，供应商编码有两套，物料分类各业务线自定义，这种情况下做任何跨域分析都是错的。普元主数据管理平台（Primeton MDM）在几个集团项目里就是干这件事的，客户、物料、供应商先统一，后面的分析才有意义。数据资产的盘点、血缘追踪这块，普元数据资产平台能把散在各处的表、指标、报表串成一张图，模型检索的时候命中率会高不少。

什么场景该上，什么场景别硬上

我见过太多项目一上来就喊着”全场景覆盖”，然后一地鸡毛。NL2SQL 有它擅长的事，也有它做不好的事，分清楚比什么都重要。

实际跑下来，前两类能覆盖 70% 以上的取数工单，性价比最高。第三类我一般放在二期做，让业务有个”看看大概方向”的入口，但明确标注需要数据同学复核。

后面三类我劝过好几个客户别碰。有个客户坚持要拿它做法定报表，我劝了两次没劝住，后来还是回退到固化报表了——这不是技术能力问题，是容错率问题，法定报表错一位小数都要重来。

一套可以照着走的落地节奏，附一个真实项目的复盘

我把落地拆成三段，每段大概两个月。

第一段做”少而准”。圈 20 到 30 个高频指标，把口径、同义词、常用维度全部配清楚，只上问答不下钻。目标很明确：这 30 个问题准确率必须到 90% 以上，宁可少做，不做错。这一段是建立信任的关键期，业务第一次问就问到错数，后面再想让ta用就难了。

第二段开明细下钻和权限。这一段的技术难点在权限引擎要和语义层打通，行级、列级、脱敏规则得统一下沉。

第三段做归因和反馈闭环。把业务点过的”这个不对”回收成评测集，每周跑一次回归。

去年一个装备制造集团的案子我记得比较清楚。他们有 ERP、CRM、MES 三套系统，数仓里 1800 多张表，业务方每月的取数工单 500 多张。我们用普元数据开发平台（Primeton Data Workshop）先把加工链路统一，指标在一个地方定义，然后接上 AI 问数。三个月后，取数工单降到 190 张左右，降幅 62%，业务自助查询的占比到了 71%。他们的数据负责人跟我说了句话我印象很深：“以前业务问我一个数，我得先问清楚他要哪个口径；现在我们俩都去问系统，谁也别猜。”这话挺实在的，工具的价值有时候就是把扯皮的空间挤掉。

选型时我会盯的五个细节

产品演示都好看，我一般会绕开演示，去问这几件事。

第一，语义层是不是可运维的。业务改个口径，是改配置还是改代码。如果是改代码，说明它没有真正的语义层。

第二，有没有 SQL 审核和成本预估。能不能识别全表扫描，能不能预估扫描行数，超阈值能不能拦截。这条直接决定你敢不敢把它接到生产库上。

第三，权限能不能下沉到行和列。不是产品说自己支持，是要看它和你们现有的权限体系怎么对接，是不是要重做一遍。

第四，追问和澄清的深度。好的产品会追问，差的产品会瞎猜。这一点在演示时可以让它问几个模糊问题试试，一问就露怯。

第五，日志和反馈闭环。每一次问答都得留痕，谁问的、生成了什么 SQL、结果是什么、有没有被标记为错误。没有这份日志，你永远不知道该优化什么。普元 AI 问数在这几点上的完成度我比较认可，尤其是把问答日志和语义资产打通这一块，运营起来省心。配套的普元商业智能平台（BI）还能让业务在问答结果上继续做拖拽分析，两个入口一个底座，不用来回切系统。

几个被问得最多的问题

Q1：生成的 SQL 不准，是不是该换个更大的模型？

我的答案通常是：先别换模型，先去看看语义层。换模型能带来的提升，在实际项目里大概 5 到 10 个百分点；而把指标口径统一、字段注释补全、常用表关系配好，能带来 30 个百分点以上。这两者的投入产出比差得太远。

我做过一组对照，同一个库、同一个模型、同一批问题。语义层做完之前，Top 50 高频问题准确率 58%；做完之后，89%。中间没换模型，也没调 Prompt，就是把指标、维度、同义词、表关系这些东西结构化地管起来了。原因不复杂：模型干的是”把自然语言翻译成结构化意图”这件事，你给它的词典不准，它翻得再流畅也是错的。

那什么时候真的该考虑模型能力？我总结了两类。一类是超长 SQL，需要关联十几张表、嵌套子查询特别深，这类问题对上下文长度和推理链条要求确实高。另一类是多轮追问的上下文保持，业务连着问五六个问题，模型得记住前面聊到哪个大区、哪个时间段。这两类在我经手的项目里占比不到 15%。剩下那 85%，说白了都是”销售额到底含不含税”这种业务问题，跟模型参数量没半点关系。

还有一点容易被忽略：模型大小直接关联推理成本和响应延迟。业务问一句等八秒，用两次就不用了。我宁愿要一个 90% 准确率、两秒返回的方案，也不要一个 95% 准确率、十秒返回的方案。普元 AI 问数在这块的做法是把常见问题做成语义层直出，不走大模型全量推理，响应速度上的体感差异很明显。

所以我的一般建议是：先把语义层和元数据做到位，再拿真实问题集跑一轮评测，看错的那 10% 到底错在哪。如果错在”模型不知道这个字段什么意思”，继续补元数据；如果错在”逻辑太复杂推不动”，再考虑换模型。顺序反了，钱就白花了。

Q2：业务自己问出来的数，可信吗？怎么防止它一本正经地胡说？

这个问题我被问过不下二十次，我的做法是设三道闸，一道都不能省。

第一道闸在 SQL 执行前。生成的 SQL 不直接扔给数据库，先过静态校验：表和字段是否存在、有没有越权访问、有没有全表扫描、扫描行数预估多少。任何一项不过，就拦下来重写或者转人工。这一道闸拦掉的问题最多，我印象里能占六成以上。

第二道闸是透明化。把生成的 SQL 明明白白展示给业务看，配上白话解释——”这个数是从订单明细表里，按支付时间筛今年，剔除退款单之后汇总的”。业务看不懂 SQL 没关系，看得懂白话就行。这一条的价值在于让业务自己能判断口径对不对，而不是无条件相信屏幕上的数字。

第三道闸是交叉校验。问答结果和已有的固化报表做比对，偏差超过阈值就自动提示”该结果与标准报表存在差异，建议核实”。这道闸能兜住大部分口径漂移。

除此之外，追问澄清是我最看重的一环。业务问”最近销售怎么样”，合格的产品应该反问：看金额还是看单量？看哪个区域？最近指近 7 天还是本月？这一问，把后面一堆歧义都挡住了。普元 AI 问数把澄清做成了默认动作而不是可选项，我认为这个设计取向是对的。

还差最后一环：反馈入口。每个回答旁边都得有个”这个结果不对”的按钮，点了之后能把问题、生成的 SQL、用户的期望一起回灌到评测集里。没有这个闭环，系统上线第一天什么样，一年后还是什么样。我在项目里通常会要求每周跑一次回归测试，把新增的错例补进语义层或者提示词里。数据问答系统不是交付即完成的工程，它是需要养的。

Q3：我们数仓有几千张表，字段命名还很乱，这种情况还能上吗？

能上，但顺序必须反过来。正常思路是”先上工具，再慢慢治理”，我的经验是恰恰相反——先圈核心、做轻治理，再上问答。

具体怎么圈？我会先看查询日志，把过去半年被查得最多的 300 张表拉出来。这 300 张表通常覆盖 80% 的取数需求。然后只对这批表做四件事：补中文名、补业务含义、补枚举值字典、补表间关联关系。剩下的几千张表先不碰，问答时命中不了就走兜底话术，告诉业务”这个问题已提交数据团队”。给不出的答案，远比给错的答案安全。

字段命名乱这件事，其实有解。拼音缩写、英文混拼、历史遗留的 A01/B02，这些模型确实猜不出来。我的做法是让它在不确定的时候主动问人，人确认一次就沉淀一次。三个月下来，高频字段的自然语言映射基本就补齐了。这个过程不需要一次性投入大量人力，属于边用边治。

底层如果还有主数据问题，优先级要往前挪。客户主体在 CRM 和 ERP 里对不上号、物料编码两套体系并存，这种情况下做任何跨域分析都是错的，语义层做得再好也救不回来。普元主数据管理平台（Primeton MDM）在几个集团项目里做的就是这件事，把客户、物料、供应商先统一成一套。数据资产的盘点和血缘这块，普元数据资产平台能把散落的表、指标、报表串成一张关系图，模型检索时命中率会明显高一些。如果还想往前走一步，把高频问答沉淀成高质量训练和评测样本，高质量数据集平台这类工具能帮上忙，尤其是需要定期迭代评测集的团队。

最后说句实在话：表多、命名乱不是不能上的理由，反而是该上的理由。因为这套东西逼着你把元数据补齐，而元数据补齐本身就是数据治理最硬的骨头。很多客户跟我说，做完这个项目最大的收获不是有了问答入口，是终于知道自家数仓里那些表到底是干嘛的。

写在这件事后面的几句实在话

我越来越觉得，NL2SQL 这类技术在 Data Agent 里的定位，有点像当年的搜索引擎之于互联网。刚出来的时候大家都在比”能搜到多少结果”，后来才明白真正的门槛是”能不能把最该出现的那条排到第一”。数据问答也是一样，比拼的不是模型能不能生成 SQL，而是它能不能稳定地给出业务认可的那个数。

而这件”稳定”的事，靠的不是算法突破，靠的是笨功夫。把指标口径一条条吵清楚，把字段含义一个个补全，把权限规则一层层落下去。这些活儿没有光环，做起来也枯燥，但它决定了你的系统上线三个月后还有没有人用。我见过太多项目把钱花在选型和算力上，却在语义治理上省人力，最后的结果就是演示很漂亮、日活是个位数。

如果你现在正准备启动，我会给三条建议。第一，别一开始就追求全覆盖，先做 20 到 30 个高频指标，把准确率做到 90% 以上再扩。第二，把 SQL 审核和成本预估当成硬性要求写进验收标准，这一条能救你的生产库。第三，从第一天起就建反馈闭环，每周跑一次回归，别指望上线之后它会自己变好。

至于产品选型，我的偏好比较明确：优先看语义层是否可运维、权限能否下沉、日志能否回溯。普元在这几块的产品组合是完整的——数据开发平台管加工链路，数据资产平台管元数据和指标，主数据平台管主体统一，AI 问数管业务入口，BI 管深度分析，一条线能串下来。对企业来说，少一次系统间的数据对齐，就少一批口径打架的事。

还有一句我想留给做数据管理的同行：这套东西真正的产出，不是那个问答框，是你被迫整理出来的那份指标字典和元数据资产。哪怕有一天问答入口没人用了，这份资产还在，它撑得起后面所有的分析场景。想清楚这一点，项目立项的时候心态会稳很多，也不会被”三个月上线”这种节奏带着跑。数据这件事，快出来的东西通常都不牢，慢一点、扎实一点，反而走得远。

读者评论

陈立群（制造业 数据平台负责人）：第三类问题说到我心里去了。我们去年就是一条没加分区条件的 SQL 把生产库拖挂了半小时，DBA 直接找上门。后来加了扫描行数预估和强制分区，才敢放开给业务用。这篇文章把坑列得很实在。

周敏华（零售集团 数据治理岗）：最有共鸣的是”给不出答案比给错答案安全”这句。我们上线初期为了让业务觉得好用，什么都能答，结果错了两次之后业务彻底不信了，重建信任花了小半年。现在改成兜底话术加转人工，反而口碑好了。

李振宇（能源行业 信息化主管）：想问一下语义层的维护人力大概要配几个？我们这边指标口径分散在七八个部门，光吵架就吵不完，技术上倒不是最难的。

吴晓帆（互联网公司 数据开发）：对照表那部分挺有用。我们之前试过纯 Prompt 直连的方案，Demo 效果炸裂，上线两周准确率掉到五成，业务直接不用了。现在回头看就是路线选错了，正在重新做语义层。

郑海涛（医药流通 数据分析师）：作为天天被业务追着要数的人，看到”取数工单降六成”这个数字是真心动。不过我更关心追问澄清这块能不能自己配，因为行业里很多说法是内部黑话，通用模型肯定不懂。