用AI问数据这件事，为什么聊两句就开始胡说

一个典型的翻车现场

业务同学问：“上个月的销售额是多少？”

AI 回答：“3,850 万元。”

然后运营同事说不对，他后台看到的是 2,100 万。财务说应该是 3,200 万。

三个数字都”对”，因为口径不同：含不含税、含不含退货、按付款时间还是发货时间、算不算关联交易。数据库里从来不止一个”上个月的销售额”。

多数 AI 问数工具失败在这里，而不是在 SQL 生成上。SQL 写错了很容易发现；口径错了，你会拿着一个错数字开完一整场会。

瓶颈一：问题本身是歧义的

人类之间能对话，是因为双方共享了大量背景。AI 不共享。

用户说	可能的含义
”销售情况怎么样”	金额？订单数？同比环比？哪个渠道？
“活跃用户”	7日活跃？30日登录？有下单算不算？
“上月”	自然月？滚动30天？财年口径？
“前三名”	按金额？按数量？按增长率？

一个成熟的系统必须在信息不足时反问，而不是猜一个然后自信地输出。

提示词里应该写死：

如果问题中存在以下任一情况，先反问，不要直接查询：
- 时间范围不明确（"最近""上个月"需确认自然月还是财年）
- 指标名对应多个口径
- 未指明维度（没说是全国还是某大区）
反问时最多问 2 个问题，且必须给出选项供选择。

“最多问 2 个”很重要。 问五个问题用户就烦了，体验比错一次还差。

瓶颈二：口径没有统一来源

这是最贵的问题，而且不是 AI 能解决的。

你需要一份”指标词典”，它是整个系统的地基：

指标: 销售额
主口径: 订单支付金额（含税），剔除取消与退货订单
统计时间: 按支付时间
可用维度: 大区/渠道/品类/客户等级
常见歧义:
  - 有人指"发货口径" → 明确告知本系统使用支付口径
  - 有人指"净销售额" → 单独提供 net_sales 指标
数据表: dws_order_daily
负责人: 数据组
更新时间: 每日 06:00 T+1

把这份词典作为检索材料，在生成 SQL 前先检索相关指标定义。这一招的效果远超调模型。

没有指标词典的 ChatBI 项目，我建议不要启动。 先把口径吵清楚，否则你只是在把混乱加速。

瓶颈三：追问链会断

单轮问答现在做得都还行。真正崩掉的是多轮：

人：“上个月华东的销售额多少？” AI：“3,200 万。” 人：“那华南呢？” AI：”……您指的是什么？” 或 “华南地区 2023 年…”

上下文继承必须显式设计。做法是把第一轮解析出的结构（指标、时间、维度、筛选）存成一个状态对象，后续只更新变化的字段：

{"metric": "sales", "period": "2026-03", "region": "华东", "group_by": []}

当用户说”那华南呢”，模型的任务不是重新理解整句话，而是输出状态补丁：

{"region": "华南"}

然后合并成完整查询。这样多轮就不会丢信息，也避免了模型越长越糊涂。

第四层：失败要明确失败

最后也是最容易被忽略的：别让 AI 在查不到时编一个数。

常见错误做法是让它”估算”或”根据趋势推测”。在数据场景里，一个编出来的数字比报错危害大一百倍。

约束：
- 只能使用查询结果中返回的数据回答，禁止任何形式的估算、外推、补全
- 查询返回 0 行时，回答"没有查到符合条件的记录"，并说明用的筛选条件
- 不确定某个字段是否存在时，先查表结构，不要猜字段名
- 所有回答必须附上：使用的口径、时间范围、筛选条件

最后那条”附上口径和筛选条件”，是让用户自己能判断这个数字对不对的唯一办法。

实施顺序建议

别一上来就追求”自然语言问一切”，按这个顺序走：

1. 先建指标词典（两周，纯人力，最值钱）
2. 限定在 3–5 个高频问题上做闭环（每句话都能答对，比什么都能答错强）
3. 加澄清机制（宁可反问，不要猜）
4. 加多轮状态管理
5. 最后才扩大覆盖面

跑通前三步之后，业务方对工具的信任度会上一个台阶；跳过前三步直接做第五步的项目，我见过的大部分在半年内被弃用。

判断一个 ChatBI 工具好不好用

问它这句话：“帮我看看上个季度的利润。”

• 回答一个数字 → 淘汰（口径没澄清，必错）
• 回答”请问是毛利率还是净利率？按订单口径还是财务口径？” → 值得考虑
• 回答数字 + 口径说明 + 数据时间 → 优秀

这一道题能筛掉市面上八成产品。