打算做自然语言查数据多数团队的第一步是先让大模型对着 Schema 写 SQL。这套走法起步非常快但随着业务侧开始较真——口径为什么前后不一致、跨部门看到的数字为什么打架、归因为什么解释不出来——系统会撞上一堵墙。撞墙之后才有动力往下走。本文从语义责任迁移的视角梳理一个企业数据问答系统从跑通 Demo 到进入生产环境会依次遇到的四层瓶颈以及每一层的应对思路。如果你在做企业数据问答你的系统现在大概率处在四个阶段中的某一个。每个阶段都有自己特有的磕碰每个阶段要解决的根本问题也不一样。很多人觉得这是个技术选型问题——到底选 LLM 直出 SQL、选 DSL 模板、选 MQL 指标语义层、还是选更重的逻辑计划但说实话大部分团队不是选到某个阶段的是撞上去的。你一开始可能只是想让自然语言能跑通跑通之后发现不稳定然后开始加约束约束多了发现维护不过来然后开始抽象抽象到一定程度发现只能查数、解释不了原因然后开始建模。这个过程不是技术路线的切换是语义责任从模型身上一层一层往外剥离的过程。每剥一层系统的确定性就上一个台阶但你也要多承担一层的建设成本。我们顺着这个顺序捋一遍。阶段一先跑起来再说这个时候你没有太多包袱就是想看看效果。把数据库里的表名、字段说明、再加几条示例 SQL 拼在一起塞进大模型的上下文让模型直接把问题翻译成 SQL。用户输入上个月华东区销售额前十的门店系统输出一段 SQL 去查数据库返回几个数字。这个阶段的核心快感来自速度。一周之内就能跑通不需要提前定义任何指标、任何语义模型、任何业务规则。对分析师来说是个好用的辅助工具——写完复杂查询让模型帮着改方言或者日常查一些临时性的、口径不敏感的粗粒度数据。问题不会立刻出现。它会在某一天某个同事发现昨天和今天问的同一个问题返回了不同的数字之后冒出来。你会开始翻 Prompt发现模型在某次生成里选了一张快照表而不是明细表你开始翻 Schema 描述发现销售额在三个部门对应三种不同的计算口径而模型不知道应该沿用哪一种你开始翻 Join 逻辑发现跨表的时候模型选了一条看起来合理、但在业务上完全错误的关联路径。这些事情没法通过调 Prompt 彻底修复。因为根因不在 Prompt在架构——你让模型在一次生成里同时扛起了理解意图、识别实体、匹配表结构、推断关联路径、判断时间规则、适配数据库方言的所有责任。这些责任没有任何一层被单独管理所以任何一环出错你都没法精准地只修那一环。所以这个阶段的核心矛盾是你用最低的前期成本换取了最宽的覆盖面但代价是每多覆盖一种业务场景排查和修正的成本就往上窜一截。不是在找 bug而是在一片没有路标的地图里靠经验摸索。如果你的系统永远不需要面对口径敏感、权限严格、或者需要解释归因的场景停在这个阶段完全没问题。很多分析师 Copilot 工具就是停在这里因为用户本身会兜底——他看一眼 SQL 就知道哪里不对不会直接拿去交报告。但如果你的系统是要交到那些不懂 SQL、不看过程、只管结果的人手里你就会被迫进入第二个阶段。阶段二把能出错的地方圈起来这时候你的思路会变。你会开始问自己我的用户真的需要那么多自由提问方式吗你复盘了一下过去两个月的查询日志发现 80% 的实际问题是高度模式化的——Top10 排名、环比涨跌、区域切片、品类占比、同比对比。用户可能在措辞上多变但底层的分析结构就那么几十种。于是你开始建模板。你先定义好每个模板的槽位——指标、维度、时间范围、过滤条件——然后让系统把用户问题先归类到模板把槽位匹配上对应的值再用确定性的规则把填好的槽位翻译成 SQL。这条路好就好在它不追求万能它追求够用且不出错。同一类问题不管用户换什么说法问最后的 SQL 结构是同一个模板生成的不可能出现今天是这个 Join 路径、明天是另一个 Join 路径的随机性。权限也好管——模板引擎里硬编码即可每个角色能看到哪些指标、哪些维度可以提前写死。但你很快就会触到这条路的天花板。原因在于模板是刚性的。每多一个解释维度、多一种时间语义、多一个业务过滤条件不是加一条规则就完事了——每个新模板意味着整套开发、测试、部署流程再走一遍。而且模板之间彼此孤立你没法在模板 A 的查询结果上继续追问模板 B 覆盖的问题因为上下文在两个互不相干的规则空间里。这就引出另一个判断如果你的查询场景是封闭的、可穷举的——比如某个固定报表页面的语音辅助入口、客服系统里若干标准话术对应的话术查询——那这个阶段已经是终点了不需要再往前。但如果你面对的是一个开放式的分析入口用户随时可能从你没预料到的角度提问那这条路能替你守住高频场景的安全底线但守不住上限。所以模板路线最恰当的角色不是全量方案而是地基里的承重墙。它帮你稳住最常见、最怕出错的那部分查询让你可以腾出手去处理真正开放的问题。阶段三让数字的口径不再靠模型猜很多团队是在经历了一次口径事件之后才开始往前走的。比如 CEO 在周会上看到的上月销售额和 CFO 手上的数字差了 8%倒查发现一个是用了月度快照表、另一个用了交易明细表比如运营总监问新客转化率业务团队说应该按首单算技术团队配的 Prompt 里写的是按注册时间算。这类问题的共同特征是它不是模型生成了错误的 SQL而是即便 SQL 执行完全正确得到的数字在业务语境下也是错的。因为模型不知道这个数应该怎么算。要解决这个问题不能靠在每个模板或者每段 Prompt 里反复叮嘱。你需要在自然语言和 SQL 之间加一层专门管理口径的语义模型。这层模型里存的不再是表和字段而是企业里已经达成共识的业务概念哪些是核心指标销售额、毛利率、活跃用户数、履约率每个指标依赖哪些维度区域、渠道、品类、客户等级指标的计算依赖哪些事实表和数据源它们之间的关系又是什么。用户问题进来之后系统不再直接从自然语言跳 SQL而是先从语句中提取出指标、维度、过滤条件和时间语义对齐到这层语义模型里对应的定义再按照定义好的口径去编译 SQL。这层东西一旦建好最明显的收益是同一句话、同一批人、任何时候问出来的数字是一致的。不再依赖临场发挥也不依赖那一段 Prompt 里恰不恰好写对了某个要命的边界条件。但这条路也有一个很明确的边界它解决的是这个数怎么算解决不了这个数为什么变成这样。当你往下追问为什么华东区女装复购率连续三季度走低的时候MQL 能告诉你的只有复购率的数值和趋势变化。它无法告诉你原因层面的事——哪些客户群体在流失、哪些渠道的客单价在缩水、是不是缺货导致断供、还是竞品在上半年做了密集促销。这些信息不在指标定义里在业务过程里——在客户发生的行为事件链里在门店和商品的动态关系里在库存状态的因果传导里。如果说前三个阶段解决的是看数的问题那再往前走一步就要进入理解数背后的业务。阶段四把业务世界翻译给机器走到这个阶段你要建的不再是指标口径而是一套企业业务世界的结构化描述。这套描述里有几类基本的语义组件。对象——客户、门店、商品、合同、渠道、组织事件——下单、支付、发货、退款、拜访、入库、出库关系——门店归属哪个区域、商品属于哪个品类、合同关联到哪个客户状态——库存健康还是告警、客户处于首次购买还是复购阶段、某笔审批在哪个环节时间规则——财年对齐方式、数据延迟补偿、T1 口径差异权限约束——哪级角色能看到哪个粒度的数据、行级和列级的过滤规则。建这层东西的投入不小。梳理业务对象需要业务部门深度参与事件建模需要和埋点、数仓、ETL 团队反复对齐关系图谱不是画一次就结束的——每新增一个业务线、一个渠道、一套数据源图谱就得跟着更新。所以它不适合做为短期的 PoC 抓手更适合面向那些查数不是目的、归因和决策才是目的的核心分析场景。但回报也是对应的。因为系统知道对象之间的业务关系它处理上海各区县女装销售额时不需要猜应该用哪个字段连表——沿着门店→区域的关系链走过去就行了。因为系统知道时间的业务语义——财年从 4 月开始、数据延迟 T1、同比要扣掉春节波动——它不会在每年 1 月把去年同期算成一个离谱的值。因为系统知道工资代发客户是通过事件条件定义的客户子集它就能把这个定义变成可复用的计算单元无论在哪个分析、哪个报表、哪次追问中出现口径都是一致的。在第四阶段的架构里SQL 退回到了执行层的一个方言。真正的核心能力是那层语义运行时——它负责在自然语言理解之后、具体执行之前把问题拆解成一棵可以被审计、可以被修正、可以被复用的逻辑计划。四层放在一起看把这四个阶段排在一起其实能看到一条很清晰的规律每往下一个阶段走你的前期建设成本就多出一大截但系统的语义确定性也跟着上一个台阶——能回答的问题从量变成了值从值变成了因从因变成了下一步。阶段一阶段二阶段三阶段四你在解决什么能不能跑通会不会出错数算得对不对企业世界机器理解得了吗核心手段Prompt Schema模板 槽位指标语义层企业世界语义层前期成本极低中等较高很高口径一致性看运气模板内强指标范围内强全链路系统保证跨对象归因几乎不支持不支持有限核心能力追问能力每次重来不支持部分支持原生支持维护成本曲线前期低、后期陡线性增长前期高、后期平前期很高、后期边际递减性价比最高的场景Demo、分析师辅助固定报表问答、客服辅助经营指标查询、口径统一复杂归因、经营分析 Agent这张表的意义不在对比维度在时间线。你可以把它当成一份系统的成长阶梯来读你现在站在哪里什么信号会推着你往前走往前走一步分别要补什么能力。怎么判断你该往前走了这个问题比四条路怎么选更实际因为在真实的企业场景里很少有人是从零开始做完整规划再逐步落地的。大部分人是边走边撞墙撞到了才有动力投下一层。下面几个信号可以作为你该补哪一层的参考如果你的系统经常因为同一类问题生成不同的 SQL 结构但业务口径本身很固定——建议补阶段二。花一两周建几十个高频模板ROI 极其明显。如果你的系统每次出来的数字都不一样而且每次用户说不清了是 Prompt 问题还是口径问题——建议往阶段三走。建一层基础的指标语义模型先把口径问题解耦出来让模型不再兼做会计。如果你的系统查数很准但用户开始问为什么下降、按渠道拆一下什么原因你发现给不出来——补阶段四。你缺的不是更好的 SQL是一层业务关系的可推理结构。如果以上三个信号都出现了——也正常这说明你的系统在各个层级都被拽着走。先稳住阶段二的高频场景同时把阶段三的指标体系建起来阶段四的业务建模可以从最核心的一两个业务域开始切入不用一上来就全量。有两个坑不管在哪个阶段都别踩第一个坑是把字段注释当成语义层。给字段写说明、加别名、配同义词能显著提升阶段一的准确率但这不是语义层。语义层要表达的不只是这个字段存了什么而是这个字段在业务上代表什么事实、它的取值依赖哪些前提、它和其他字段在业务逻辑上有什么关系。前者帮模型少猜字段名后者帮模型不再猜业务逻辑——两个量级的事情。第二个坑是拿离线评测的准确率当系统质量指标。测试集跑出 92% 只能证明这一版在样本上表现稳定。生产系统真正考验的是几件事Schema 变了以后结果漂不漂、新指标接入后会不会拉低已有场景的稳定性、同一个问题换一个方言版的函数会不会出错。这些靠人工跑回归是顶不住的需要在架构里把回归自动化。最后做企业数据问答最早期大家的关注点都在准不准上——能不能把自然语言变成一段对的 SQL。几年下来行业慢慢看明白了一件事SQL 写对只是第一步真正拉开差距的是你能不能把自己的业务世界组织成一整套机器可以稳定理解、稳定执行、持续迭代的语义基础设施。这件事从零到一可能拉不开分差——一个聪明的 Prompt 工程和一个精密的语义建模在 Demo 阶段看起来差别没那么大。但一旦系统到了要接住跨部门口径、接住复杂归因、接住多轮追问、接住模型升级后的回归验证的阶段前面省下来的建模功夫后面都会以排查成本和信任损耗的形式加倍还回来。至于要不要一次性把所有阶段铺满——大概率不用。先看你站在第几个阶段先把当前最痛的墙翻了再决定要不要往前多走一步。FAQ我们团队就 5 个人需要搞阶段四那些建模吗不需要也不应该。阶段四的建设成本靠小团队业余时间是扛不动的。5 人团队的正确起手式是阶段一先把 PoC 跑出来然后优先投入阶段二——把你最高频、最怕出错的几十个查询场景用模板箍起来ROI 最好维护压力最小。如果有余力再挑一两个核心指标建阶段三的语义模型。阶段四是给查数已经不是瓶颈、归因和决策才是的团队的。是不是可以把不同阶段的能力混合使用不是可以是应该。一个企业的自然语言入口很难只用一种架构扛住所有场景。最外层用阶段一的通用能力接住开放式提问高频固定场景用阶段二的模板保证稳定关键指标用阶段三语义模型锁住口径核心经营分析把阶段四的建模拉满。用户不需要关心背后走的是哪条链路只需要觉得准、快、能追问。阶段二是不是过时了没过时在它的主场上谁都打不过它。如果你的查询场景天然封闭、可穷举——比如一个标准报表页面的自助问答、或者客服系统里预设好话术的查询入口——阶段二就是你能拿到的最优解。过时的是把阶段二当成唯一方案去应对开放式分析的用法而不是技术本身。四个阶段是不是必须按顺序走不一定。有些团队一上来就带了成熟的指标平台和数据治理体系可以直接从阶段三切入。有些团队日常面对的就是复杂跨对象的归因问题可以直接从阶段四起步。顺序是常见的成长路径不是唯一的入场路径。
)
