语义层建了，ChatBI 为什么还是不好用?

经营会上老板问了一个看起来很普通的问题“这个月华东的新客收入为什么下降”ChatBI 很快给出答案。它画了一张趋势图列出了下降幅度还给出几个原因客户数减少、客单价下降、渠道转化变差。现场看起来很智能。但销售负责人看了一眼说“这个新客不对。我们说的新客是首次签约客户不是首次下单客户。”财务接着说“这个收入也不对。你算的是订单金额不是确认收入。”区域经理又补一句“华东也不对。这个客户总部在华东但项目在华南不能算我们区域。”这时候大家才发现系统不是不会算。它算得很快图画得很漂亮解释也很完整。问题是它从第一步就理解错了。它不知道这几个词到底该怎么理解“新客”按首次下单算还是首次签约算“收入”指订单金额、开票金额、到账金额还是财务确认收入“华东”按客户注册地、销售归属地还是项目发生地这就是语义层真正难建的地方。语义层不是给字段起中文名也不是把指标整理成一张表。它真正要解决的是业务说出一句话机器该按哪套规则去理解、查询、计算和解释。很多 ChatBI 不好用第一反应都会怪模型模型不够强、提示词没调好、工具不成熟、业务问题太复杂。这些都可能有影响。但更常见的情况是模型只是最后一个犯错的人。前面的业务词、指标口径、数据路径、权限边界和反馈机制早就没有说清楚。问题不出在最后生成答案那一步而是整条语义链路没有闭上。一、先把链路拆开“华东新客收入为什么下降”这句话听起来只有十几个字。但系统要答对至少要过六关。这张表说明一件事。语义层不是一个“指标配置项”而是一条从业务问题到可信答案的链路。链路中任何一环没说清楚最后都会表现为同一个结果ChatBI 不准。二、建的不是语义层而是字段说明书很多企业做语义层第一步是盘表有哪些表、哪些字段、字段中文名是什么、含义是什么、来自哪个系统。这些工作有必要。但只做到这里还不是语义层。比如订单表里有个字段叫 amount系统里写得很清楚amount 订单金额。这当然比没有中文说明好。但业务真正问的不是“amount 是什么意思”而是“这个月华东的新客收入为什么下降”这句话背后藏着一串规则“这个月”是订单创建月还是收入确认月“新客”是首次下单还是首次签约“收入”是订单金额还是确认收入“华东”是客户所在地还是销售归属地“下降”是环比下降还是低于预算字段说明只能告诉 AI 这个字段叫什么不能告诉 AI 这个业务问题该怎么理解。所以字段中文名不是语义层数据字典也不是语义层。它们只是语义层的原材料。真正的语义层要把业务问题里的词翻译成机器可执行的规则。三、“词指什么”和“怎么算”是两件事语义层里最容易讲不清楚的是“收入”。用户说“收入”可能指的是不同的业务事实订单金额来自下单开票金额来自开票到账金额来自回款确认收入来自财务确认这四个数都可以叫收入但它们不是同一个东西。所以AI 第一步不是计算而是先判断这里的收入到底指哪一笔事实。这是业务词边界问题。再往下一步才是指标口径问题。假设已经确定这次看的是“确认收入”。那还要继续问退款扣不扣异常大单剔不剔内部交易算不算含税还是不含税经营会上可能要看剔除异常后的经营口径。财务对账时必须看一分不剔的财务口径。绩效考核时又可能有另一套考核口径。这就是第二层问题同一笔收入在不同场景下该怎么算。很多语义层建不好就是把这两步混成了一步。收入指哪笔事实没定清楚AI 会查错对象这笔收入怎么算没定清楚AI 会算偏口径。这两步不拆开ChatBI 就会一边认真回答一边从根上答偏。四、能连上不代表算得对ChatBI 最危险的错误不是 SQL 跑不出来。跑不出来大家一眼就知道错了。最危险的是SQL 能跑结果有数图也能画但业务上已经错了。比如要算“新客收入”可能要连客户表、订单表、合同表、收入确认表。客户和订单是一对多订单和合同可能是一对多合同和收入确认又可能分多个月确认。如果 Join 路径不对收入可能被重复计算。这类错误有一部分是通用 SQL 问题。比如一对多 Join 后又直接 SUM 订单金额金额被放大——这类问题强模型确实可能比弱模型少犯。但还有一类不是模型推理能解决的新客收入该走订单表还是收入确认表客户区域该用当前归属还是历史归属客户表里的测试账号要不要剔除合同分主合同和子合同哪一个参与计算这些不是 SQL 逻辑题而是企业内部规则。而且这种错模型越强反而越难当场发现。弱模型写的 SQL 一眼就离谱强模型能写出结构漂亮、却把收入翻了一倍的 SQL。表名不会告诉模型字段名不会告诉模型很多企业的外键也不会告诉模型。经验丰富的数据分析师能写对不是因为 SQL 推理比模型强而是因为他知道这家企业的历史坑。语义层要做的就是把这些历史坑从人的脑子里搬出来哪些表可以连哪些表不能连哪些路径能跑但不能用于这个问题哪些指标只能在客户粒度看哪些维度不能随便下钻能连上不代表算得对。这句话是智能问数项目里最该写进语义层的一句。五、权限是问题本身的一部分很多人理解权限是这样的谁能登录系统、谁能看哪张表、谁能打开哪个报表。但到了 ChatBI权限不是点报表的问题而是问问题的问题。同一句话不同人问答案范围应该不同总部经营人员问“本月客户收入”可能看全公司汇总区域经理问只能看本区域销售人员问只能看自己名下客户客服人员问可能只能看服务相关客户外包人员问可能只能看脱敏结果再比如“列出收入下降最大的客户”这个问题更敏感。有的人可以看客户名称有的人只能看客户编码有的人只能看行业汇总有的人需要审批后才能看明细。如果权限没有进入语义层ChatBI 会出现两种问题。一种是太保守什么都不敢答用户觉得不好用。另一种是太开放什么都答出来。后者更危险。因为 AI 不只是查单个字段它还会组合信息。单独看不敏感的字段组合起来可能就暴露了客户、金额、人员和区域。所以权限不能只放在平台最后拦一下。语义层必须提前告诉 AI这个人是谁能看哪些指标、哪些区域能不能看明细哪些字段要脱敏哪些问题要审批哪些回答要留审计日志如果没有这层规则系统不是不好用就是不敢用。六、答案要说明“这个数怎么来的”一个好的智能问数答案不能只回答“本月华东新客收入为 860 万环比下降 12%。”这还不够。它至少要说明本次“新客”按首次签约客户计算本次“收入”采用经营收入口径本次“华东”按销售归属地计算数据截止到昨天晚上结果已剔除退款和一笔异常大单当前用户只能查看汇总不能下钻明细这些解释不是废话它们决定业务敢不敢用这个数。传统 BI 时代数据分析师可以在旁边解释“这个数是经营口径不是财务口径。”但 ChatBI 时代系统必须自己解释。因为用户不是在看报表而是在和系统对话。如果答案只有数字没有口径、来源、时效、权限说明业务就会问“这个数准吗”一旦业务开始问这句话智能问数的信任就已经断了。七、最怕的不是答错是不知道错在哪ChatBI 答错并不可怕。真正可怕的是用户说“不准”以后没人知道该改哪里。是业务词识别错了是指标口径选错了是表关系连错了是权限限制导致结果不完整是数据没更新还是答案解释过度推断如果分不清最后只能落到一句话“继续优化语义层。”但这句话没有操作性。补字段说明改指标口径调提示词改 SQL 生成加权限规则让业务重新确认定义方向完全不同。所以语义层必须有两套机制。第一套答案可追溯每次回答都要留下记录业务词识别成了什么用了哪套指标口径走了哪条 Join 路径套用了哪个权限范围数据截止到哪一天最终 SQL 是什么有了这些记录才能知道这次错在哪。第二套校验集把最常见的 20 到 50 个真实问题固定下来。这组题不是给用户的问题清单用户本来也不会照着它问。它更像软件里的回归测试题固定不动每次改完语义层跑一遍才能分清这次是系统改好了还是题本身变难了。比如本月新客收入为什么下降销售收入和财务收入为什么对不上哪些客户贡献了主要增长哪个渠道转化率下降最明显这个区域增长是真增长还是口径调整每道题不只是写一个标准答案还要写清楚业务词该识别成什么、该用哪个口径、该走哪条 Join、不同角色看到什么范围、答案要不要提示口径。以后每次改语义层、升模型、调权限都拿这组题跑一遍。答错不可怕。可怕的是同一个坑改一次复活一次。没有校验集语义层就只能靠用户抱怨来修。靠抱怨修系统永远修不准。八、责任边界不清语义层一定建不好语义层建不好不能简单怪数据团队。数据团队有责任但不是所有责任都在数据团队。数据团队负责把指标、字段、表关系、血缘、质量规则和数据时效说清楚。业务部门负责告诉系统真实问题怎么问确认“收入、客户、新客、区域”这些词在业务里怎么用哪些场景有例外哪些答案可以采信。IT / 平台 / AI 团队负责把语义规则接进系统把权限、日志、模型调用、SQL 生成、审计追踪做稳定。管理者负责裁决冲突经营口径、财务口径、考核口径冲突时谁说了算默认口径是什么口径变更谁审批历史数据要不要重算哪些指标能进入正式经营会议这些问题如果没人拍板语义层就会一直悬着。最后每次出错大家都会回到同一套说法业务说系统不懂业务数据说业务没说清楚技术说模型只是执行供应商说语义资产还不完整领导说钱花了为什么不好用。每个人都能解释自己为什么没错。但系统还是不好用。因为责任边界没闭上语义链路就一定会反复断。九、修复顺序别一上来就换模型如果 ChatBI 不好用很多团队第一反应是换模型。这个顺序通常是错的。模型当然有用。通用 SQL 逻辑错误模型越强确实越可能少犯。但企业语义缺失的那部分换模型补不上。模型越强只会让错误答案说得更像真的。真正的修复顺序前四步都在“把业务说清楚”先收集真实问题不要先补全所有字段先找业务最常问、最容易出错、最影响经营判断的 20 到 50 个问题。给核心业务词定边界收入、客户、新客、订单、区域、渠道、回款、利润先说清楚默认指什么、还有哪些含义、什么场景用哪个、用户没说清时要不要反问。梳理关键指标口径尤其是经常拿去开会、汇报、考核的指标不能只有公式还要有适用场景、排除规则、版本记录、口径负责人和冲突裁决人。梳理核心实体关系重点不是画出所有表而是告诉系统哪些表可以连、哪些不能乱连、哪些 Join 会重复计算、哪些指标不能拆到明细层。后三步才轮到系统和模型加入权限和解释规则谁能看汇总、谁能看明细谁能看客户名称、谁只能看脱敏结果哪些问题需要审批答案必须说明口径、来源、时效和限制。建立标准问题校验集把前面那批真实问题变成固定测试题每次语义层调整、模型升级、权限变更都跑一遍。最后再调模型和提示词提示词当然要调模型当然要选但它们不是第一步。如果企业自己没说清楚业务词、口径、关系、权限和责任提示词再漂亮也只是提醒 AI“请认真理解业务。”问题是业务到底是什么你还没告诉它。十、下一次答错先查这六件事下一次 ChatBI 答错先别急着骂模型先问六个问题。前三个查“有没有听懂”它有没有理解用户真正想问什么用户是在查一个数还是在分析原因是在看趋势还是在找责任归属它有没有把业务词对应到正确对象收入指订单金额、开票金额、到账金额还是确认收入客户指集团客户、签约客户还是账号客户它有没有选对指标口径这次该用经营、财务还是考核口径退款、异常大单、内部交易怎么处理后三个查“有没有做对”它有没有走对数据路径客户、订单、合同、收入确认之间有没有重复 Join有没有把当前归属和历史归属混用它有没有守住权限边界这个用户能不能看这个范围能不能看明细需不需要脱敏要不要审批它有没有留下可追溯记录能不能看到这次用了什么口径、什么数据、什么 SQL修好以后能不能沉淀进校验集这六个问题问完很多所谓“ChatBI 不准”就会变成具体的链路问题。问题具体了才有修的可能。语义层之所以重要是因为它决定 AI 能不能听懂企业内部的业务语言。语义层之所以难建是因为企业内部很多业务语言本来就不清楚、不统一、带场景、带例外、带权责。所以语义层不是字段中文名不是指标说明书也不是多买一个智能问数工具。它是把企业过去靠人解释、靠经验判断、靠会议拍板的业务规则变成机器可以执行、可以解释、可以追溯、可以持续修正的规则。做不好这一层ChatBI 就只能停留在演示里简单问题能答真实问题一问就乱。欢迎加入「与数据同行」专业群第一时间推送数据领域的深度文章并围绕真实问题进行专业讨论。适合数据治理 / 数据技术 / AI/ 数智化/数据负责人不适合闲聊 / 拉广告 / 求资料「与数据同行」为求职者和招聘方提供了一个交流场所欢迎加入。