过去一两年，很多企业都尝试过智能问数。
一开始大家的想法很直接：把大模型接到数据库或者数仓上，让业务人员用自然语言提问，系统自动生成 SQL，返回结果。Demo 往往效果不错，但进入真实业务后，很快会遇到问题。
同一个“收入”，销售、财务、运营的口径可能不一样；同一个“客户”，在 CRM、订单系统、会员系统里的含义也不一样。字段名看起来清楚，真实业务含义却依赖上下游系统。再加上权限、数据质量、历史口径、明细追溯，问题就变得复杂了。
企业智能问数真正难的地方，不是大模型能不能写 SQL，而是企业有没有一套清楚、统一、可复用的业务语义。
智能问数不只是查数入口
如果只是给业务人员做一个“自然语言查数”的入口，智能问数的价值会比较有限。
更合理的定位是：
智能问数是企业数据语义层之上的自然语言访问方式。
也就是说，底层应该先有统一的业务对象、指标、维度、权限和口径，而智能问数只是其中一个使用入口。
今天是业务人员通过自然语言问数，明天可能是销售 Agent、运营 Agent、投放 Agent 自动调用这些数据，后天还可能是机器学习模型使用这些指标作为特征。
如果一开始只为人类问数设计，把指标口径写在提示词里，后面给 Agent 和 ML 使用时，就很容易重新做一遍。人类问数一套口径，Dashboard 一套口径，Agent 又一套口径，最后仍然回到混乱状态。
所以企业做智能问数，最好从第一天就按统一语义层来设计。
先从一个业务域开始，不要一上来做全公司
很多智能问数项目容易犯的第一个错误，是目标太大。
一开始就想做到“全公司所有数据都能问”，看起来很有想象力，但实际落地难度很高。因为全公司数据意味着全公司口径，全公司权限，全公司历史包袱。这个范围太大，很难在早期建立信任，项目也容易因此陷入停滞。
更稳妥的做法，是先选一个边界清楚、价值明确、数据相对可控的业务域。
比如：
- 销售经营分析；
- 电商运营分析；
- 广告投放分析；
- 客服工单分析；
- 供应链履约分析；
- 财务经营里的某个窄场景。
第一阶段不需要覆盖太多，能把一个小闭环跑通就很好。
例如先整理出 30 个高频问题、20 个核心指标、10 个常用维度、3 到 5 个核心业务对象。围绕这些内容，把数据模型、指标口径、权限和问数链路跑通。
这比一开始追求“大而全”更容易成功。
补一层业务语义
很多企业已经有数仓，但没有系统梳理过指标和语义层。这种情况很常见。
这类企业不是没有数据，而是数据还没有变成可被业务稳定理解和复用的语义资产。
这时不要急着让大模型直接查数仓表。因为数仓里可能有 ODS、DWD、DWS、ADS，各层表很多，字段很多，历史逻辑很多。分析师知道怎么查，不代表模型也能稳定理解。业务人员知道自己想问什么，也不代表这个问题可以直接映射到某张表。
更好的做法是，在现有数仓之上，先选一个业务域，建立一层轻量语义层。
这个过程不一定一开始就很重，可以先做三件事。
第一，整理高频问题。
不要从表开始，而要从业务问题开始。比如“本月销售额是多少”“哪个渠道转化率下降最多”“最近 30 天退款率是否异常”。这些问题代表真实使用场景。
第二，整理核心指标。
把销售额、净收入、退款率、转化率、复购率、ROI 等指标的口径写清楚。它们的分子是什么，分母是什么，时间口径是什么，是否排除测试数据，是否包含退款，默认看哪个业务范围，都要明确。
第三，整理分析数据集。
在数仓已有基础上，为智能问数准备更稳定的分析模型。可以是数据集市、宽表、指标表，也可以是语义层工具之上的模型定义。重点不是再造一套数仓，而是让问数系统面对的是清楚的业务模型，而不是复杂混乱的底层表。
这样做之后，智能问数才有可靠基础。
统一语义层应该统一什么
前面我们讲过，语义层不仅服务人类问数，也应该服务于 Agent、ML 和 其他上层消费者。因此，智能时代的语义层应该是一层统一语义层：同一套业务对象、指标口径、权限规则和证据链，被不同入口共同复用。
语义层不是一个指标文档，也不是一张字段说明表。
企业需要在语义层统一的内容，至少包括几类。
首先是业务对象。比如客户、订单、商品、渠道、门店、合同、商机、工单。对象定义不清，后面的指标都会不清。
其次是指标。比如 GMV、净收入、退款率、转化率、活跃客户数、客单价、LTV、ROI。每个指标都要有明确口径，不能只写一个中文名称。
然后是维度。比如时间、地区、渠道、商品类目、客户类型、组织架构。指标能按什么方式拆分，要提前定义好。
还要有权限。不同角色能看的数据范围不同。销售只能看自己的客户，区域经理只能看本区域，财务可以看利润，普通运营可能只能看收入。智能问数和 Agent 调用都必须继承同一套权限规则。
最后是证据链。智能问数不能只返回一个数字，还应该说明这个数字来自哪个指标、用了什么时间范围、过滤了哪些条件、是否可以下钻到明细。
这些内容沉淀下来，才叫统一语义层。
智能问数应该走受控查询，而不是自由 SQL
企业智能问数不建议采用完全自由的自然语言转 SQL。
更稳的方式是：
自然语言问题 → 识别指标、维度、时间和过滤条件 → 映射到语义层 → 生成受控查询 → 权限校验 → 返回答案和证据。
这样做的好处是，模型不是随便猜表、猜字段、猜口径，而是在已经定义好的语义范围内工作。
例如用户问：
本月华东区销售额同比增长多少？
系统应该识别出：
- 指标：销售额；
- 时间：本月；
- 对比方式：同比；
- 维度或过滤条件：华东区；
- 权限范围：当前用户可见组织；
- 输出形式：当前值、同比变化、趋势和明细入口。
然后它去调用语义层中已经定义好的销售额指标，而不是临时生成一段不受控 SQL。
这也是企业智能问数从 Demo 走向可用的关键。
Agent 和 ML 应该复用同一套语义
服务人类用户的智能问数稳定之后，下一步通常是开放给 Agent 和 ML。
比如销售 Agent 每天生成经营简报，运营 Agent 监控渠道异常，投放 Agent 判断哪些广告计划 ROI 下降，客服 Agent 分析投诉原因。
这些 Agent 在行动之前，都需要取数。如果它们绕过语义层，直接查库或者自己生成 SQL，就会带来新的风险：口径不一致、权限不可控、结果不可审计。
所以 Agent 应该通过受控工具调用语义层，比如：
- 查询某个指标；
- 对比某个指标；
- 解释某个指标变化；
- 获取异常指标；
- 获取支撑结论的明细证据。
ML 也是一样。模型训练需要特征，比如近 30 天订单数、近 90 天退款率、客户活跃天数、广告 ROI、工单数量。如果这些特征由不同团队各自写 SQL，时间久了也会出现口径漂移。
更好的方式是让 ML 特征也尽量来自统一语义层或统一特征视图。这样人类看到的指标、Agent 调用的指标、模型使用的特征，才能保持一致。
必须建立评估和治理机制
智能问数不能只看一次演示效果，还要长期评估。
企业至少要准备一批标准问题，也就是 Golden Questions。每个问题对应标准指标、标准过滤条件、标准查询和标准答案。
例如：
- 本月销售额是多少？
- 最近 30 天退款率是多少？
- 哪个渠道 ROI 下降最多？
- 本季度销售目标完成率如何？
这些问题要反复测试。每次模型、Prompt、语义层或指标口径发生变化，都要看答案是否仍然正确。
同时，指标也要有治理流程。新增指标、修改口径、废弃指标，都要有负责人和变更记录。否则语义层也会慢慢变成新的混乱源。
一个务实的落地节奏
企业可以按这样的节奏推进。
第一步，选一个业务域。不要做全公司，先做一个价值明确的小场景。
第二步，整理高频问题。先知道业务真正会问什么，再决定建哪些指标。
第三步，整理核心指标和维度。把指标口径、时间口径、默认过滤条件和负责人定义清楚。
第四步，在数仓之上建设分析模型和语义层。不要让模型直接面对复杂底层表。
第五步，做智能问数入口。先覆盖高频问题，返回答案、口径、图表和证据链。
第六步，建立评估集和权限校验。确保系统答得准、看得对、可追溯。
第七步，再开放给 Agent、Dashboard 和 ML。让它们复用同一套语义，而不是重复建设。
结语
企业落地智能问数，真正的起点不是大模型，也不是 SQL，而是业务语义。
如果指标口径不清，权限不清，业务对象不清，数据来源不清，大模型能力再强，也只能在混乱上做推理。
更可行的路径是：
先在一个业务域里沉淀统一语义层，再在语义层之上做人类问数、Agent 调用和 ML 特征复用。
智能问数只是入口，统一语义层才是底座。
只有先把统一语义层建设起来，智能问数才不会停留在 Demo 阶段；业务人员问数、Agent 调用数据、机器学习模型使用特征，才能在统一口径下清晰、可信、稳定地运行。