自然语言问数为什么会出现指标偏差：语义层与权限设计

自然语言问数接入企业数据后，一个常见现象是：同一句业务问题，由分析师查询、固定报表统计和 AI 回答，可能得到三种不同结果。问题未必出在模型不会写 SQL，而是业务语言进入数据系统时，缺少明确的转换规则。

以“上周新客转化率下降了多少”为例。新客可能按首次访问、首次注册或首次下单定义；转化率可能指注册转化、支付转化，也可能只统计某个渠道；上周还可能按自然周或活动周期计算。对业务人员而言，这些条件往往已经包含在日常语境里，但对系统而言，每一项都必须落到确定的数据对象和计算口径。

当自然语言直接越过业务语义层生成查询语句，答案就容易随字段选择、表关联方式和上下文变化而漂移。要让问数进入日常分析，系统需要先解决三个问题：如何理解业务术语，如何调用确定的分析方法，以及如何控制数据与工具的访问范围。

业务问题不能直接等同于数据库查询

企业数据通常以表、字段和任务的形式组织，而经营问题使用的是客户、订单、渠道、活动和转化等业务概念。两者之间需要一层稳定映射。

首先要明确分析对象。用户、设备、会员、门店和订单并不是可以随意替换的统计主体。App、网站和小程序还会产生不同的匿名标识，如果设备 ID、OpenID 与会员账号没有关联，同一位客户的行为会被拆成多段，漏斗和留存结果自然会失真。

其次要固定事件和指标定义。注册成功、提交订单、支付完成、退款等事件应有明确边界；新客数、激活率和首购转化率等指标则要引用已经确认的计算逻辑。AI 的任务是理解提问中的目标和条件，不应临时重新发明一套指标。

AI 如何理解一个经营问题

让 AI 调用分析能力，而不是临时拼接答案

问一个总量或趋势，普通聚合查询通常就能完成。但当问题进入“哪个渠道变化最大”“流失集中在哪一步”“不同版本的留存是否有差异”，系统需要调用漏斗、路径、留存、归因等专业模型。

一种更稳定的实现方式，是先把自然语言解析为指标、事件、时间范围、过滤条件和分析目标，再将这些参数交给已经定义好的指标服务与分析 API。这样，大模型负责理解意图和组织步骤，数值计算仍由确定的分析引擎完成。

GrowingIO 在分析云与 DeciAGI 的协同中采用了类似方法：通过主体、事件、属性、统一指标和 OneID 组织业务数据，再把自然语言问题映射到既有指标与漏斗、留存、路径等分析能力。用户继续追问渠道、版本或人群差异时，系统沿用原有指标口径，只调整分析维度，减少同一问题在多轮对话中发生定义漂移。

这类设计还有一个实际好处。经过确认的分析过程可以保存为看板或固定任务，高频问题不必每次从头生成查询，团队也能在同一口径上继续复盘。

权限要覆盖数据读取和工具调用

传统报表权限通常控制某个用户能否查看页面或数据集。Agent 会主动拆解问题、选择数据并调用工具，权限范围因此还要覆盖分析过程。

例如，区域运营人员可以查看所负责市场的转化趋势，但未必需要读取客户敏感字段；AI 可以生成流失人群的分析结果，但把人群同步到运营系统仍应经过相应权限与业务确认。数据范围、字段脱敏、可调用模型和可执行动作应分别控制，不能只依赖一个笼统的角色开关。

分析结果还应保留必要的上下文，包括指标定义、时间范围、筛选条件和使用的分析方法。当答案出现疑问时，团队能够找到差异发生在哪个环节，而不是只能重新提问。

可信 AI 分析链路

从一个真实问题检查系统是否稳定

验证自然语言问数，不妨选择一项团队正在跟踪的业务指标。例如以“新用户激活率下降”为起点，观察系统能否识别既有的新用户与激活定义，能否关联跨端身份，能否按渠道、版本和人群继续拆解，并调用漏斗或留存模型定位变化。

如果多轮追问始终沿用同一业务口径，数据访问符合当前用户权限，图表和结论还可以被团队继续使用，这套能力才真正进入了生产分析。自然语言只是新的交互入口，稳定的业务语义、确定的分析模型和清楚的权限边界，才是答案可以被长期采用的基础。