智能问数落地翻车真相：语义层才是核心，三张表格就能拆解

智能问数（ChatBI）正在成为企业 AI 落地清单上的高频选项。演示环境下，它能秒回「昨天全店销售额」，精准得像魔法；真正上线后，运营总监对着 AI 返回的数字去经营看板核对，发现差了整整 5 万。根因很简单：数仓的订单还没同步完，AI 查的是那份滞后的数据。这个场景暴露了一个行业共识：智能问数项目失败，九成不是模型不够聪明，是数据没有统一说法。本文用大白话拆解问数是什么、为什么难落地，以及产品经理如何通过三张表格构建语义层，让问数系统真正可用。

问数的本质与价值边界

智能问数的本质是一个能听懂人话、自己去查数据库的问答助手。用户用自然语言提问，AI 生成 SQL 语句执行查询，直接把数字告诉用户。相比传统报表，问数能回答临时起意的问题，比如「按品类看昨天退货率」，而报表的列是提前定死的、想改得排队等排期。相比数据工单，问数秒级响应，而找分析师写 SQL 可能要排两天。但问数有明确的边界：它只负责查数，不管改数、审批、下单这些操作。换句话说，它回答「是多少」，不负责「为什么」和「怎么办」。判断一个场景是否适合上问数，标准只有一条：用户要的是一个具体的数，且这个数已经在系统里了。

问数难落地，不是难在 AI 写 SQL——这是目前大模型最成熟的能力之一。真正的卡点是：AI 不知道查哪张表、按什么口径算。这两件事不在问题里，也不在数据库里，在老员工的脑子里。裸奔上线的问数系统，错误只有三种：查错表导致数据滞后、编口径导致数字失真、编字段导致结果为空。其中第三种最危险——用户根本看不出错。46 万和 51 万摆在一起，你知道信谁；但 AI 补了个 0 出来，你可能还以为这就是正确答案。主流技术方案已经演进到第三代：第一代裸翻译，把全部表结构扔给 AI 让它自己猜；第二代 RAG 找表，靠语义相似性召回相关表，但「长得像」不等于「用得上」；第三代语义层，提前把业务定义整理成一张标准地图，告诉 AI 该查哪张表、怎么算，这是目前行业公认的方向。

三种错误与语义层原理

语义层里装的不是代码，是业务事实：哪个系统是权威、口径怎么算、谁能看什么。这些事实模型买不来，得有人一条一条整理出来，这就是产品经理的核心职责。具体做法是把语义层落地成三张表格，顺序不能乱。先填名词表，告诉 AI「业务里有哪些东西」——每一行是一个业务对象，如会员、订单、商品；列包括对象定义、唯一标识、常用字段、权威数据源、访问权限。这里最关键的一列是权威源：同一个东西往往好几个系统都有记录且互相不一致，必须有人提前拍板用哪份数据，46 万对 51 万的根子就在这里。再填指标口径表，告诉 AI「每个数怎么算」——每一行是一个指标，如销售额、退货率；列包括指标定义、时间口径、常见问法、负责人。定义要写到不懂技术的人照着能复算出一模一样的数，才算合格；常见问法那一列最容易被省，但它既是 AI 的匹配样例，也是测试题库。三填规则表，告诉 AI「什么不能说、什么时候闭嘴」——按条件触发，分为权限类、口径类、拒答类两类，规则必须有出处、必须写预期表现，数据没同步时正确行为是明说不知道，禁止估算。

三表建模的实战方法

三张表填完交给开发后，名词表变成 AI 开卷时能看到的业务说明书，代替几百张裸表让 AI 只看见定义过的对象；指标表变成口径预先写死的查询，AI 只负责填时间、品类这类参数；规则表变成出口的守卫代码。实际运行时，用户提问后系统先匹配指标表，匹配上了就定位权威源出数，出数后过三道守卫——角色能看吗、敏感字段打码了吗、数据够不够新鲜，最后回答并附带口径说明。匹配不上时，大多数问题只是问法新鲜而非真的答不了，比如「双 11 那周客单价多少」，拆开就是客单价加一个时间范围，所以生产系统通常中间垫一层兜底：让 Agent 自己规划路径再执行自检，不行才拒答。关键纪律是：权限必须用代码在答案出口过滤，不能靠提示词——提示词是建议，代码才是护栏。

模型只占问数系统的三成，七成是把公司口径从人脑里挖出来、变成 AI 能用的结构。这个活琐碎、不炫，没有模型能替你干，所以大多数团队跳过了它，所以大多数问数项目翻车。产品经理在这里的价值不是调 prompt，是当那个把口径挖出来、把冲突拍掉、把边界立起来的人。记住一句就够了：先把数据的说法统一，再让 AI 开口。