夜雨聆风01三个人问AI同一个问题，得到三个答案
场景很常见——
业务同学问AI：「上个月华东区的销售额是多少？」
结果：
营销部的AI回答：1.2亿（按下单金额算） 财务部的AI回答：0.96亿（按支付金额算，扣除退款） 运营部的AI回答：1.05亿（按实际到账金额算，含税）
三个部门，同一个「销售额」，三个数字。
这个问题不是模型能解决的。换更强的模型，给更长的提示词，调更多的参数——都解决不了。因为这不是理解能力的问题，是治理的问题。
02为什么不能让AI直接查数据库？
很多企业最开始做智能问数，都会走一条看似简单的路：
用户自然语言问题→ LLM生成SQL → 查数据库 → 返回结果
做Demo很快。但一进入企业真实环境，马上崩。
举几个真实场景：
同一个「销售额」，不同部门口径不同。一张订单表里可能有支付金额、下单金额、退款金额、优惠金额。AI该用哪个？ 用户问「华东区」，是指销售大区，客户注册地，还是门店所在地？ 有些字段虽然存在，但已经废弃。AI不知道。 有些数据虽然能查，但这个用户没有权限看。AI不在乎。 有些表名字像正式表，其实只是临时表或中间表。AI分不清。
这时候，让LLM直接面对数据库，它很容易：
选错表 用错字段 join错路径 算错指标 绕过权限 返回无法解释的结果
企业级智能问数的重点不是「让模型更会写SQL」，而是：让模型只能在可信、受治理、可解释的数据语义范围内工作。
有人会说，那我用Skill、工作流来沉淀常见分析步骤不行吗？
03答案：两层可信基础，一层管「该信谁」，一层管「怎么查对」
我们的实践给出的答案是：在AI和数据库之间，建两层可信基础。
第一层：可信数据上下文层
它解决的是：可信数据上下文如何沉淀和治理。它关注的是：
企业有哪些数据资产 这些数据资产是什么意思 谁负责这些数据 数据从哪里来、流向哪里 有没有血缘 有没有质量问题 哪些表是权威表 哪些字段是敏感字段 哪些业务术语是官方定义
更直观地说，它是企业的数据资产地图和可信上下文层。
第二层：语义查询层
它解决的是：怎么按统一口径查数据。它关注的是：
指标怎么定义 维度怎么定义 表之间怎么join 用户能查哪些数据 查询如何通过API暴露 LLM或应用如何安全地访问指标
更直观地说，它是智能问数的语义查询层。
一句话区分：第一层管「该信谁」，第二层管「怎么查对」
很多团队只做了第二层，让AI能查数，但查的是不是对的数、可信的数，没人管。这就像给了一个实习生一个超级计算器，但没告诉他要算什么。
04第一层详解：让AI先明白「企业里有什么、哪些能信」
这一层不是直接算指标的，而是帮助智能系统理解：企业里有哪些数据，哪些数据可信，这些数据分别是什么意思。
数据资产上下文
企业里有很多表：ods_order、dwd_order_detail、ads_sales_summary、tmp_order_2024、finance_revenue_monthly……
业务用户问「销售额」，系统不能随便挑一张表。这一层可以帮助识别：
哪些表是正式生产表 哪些表属于销售域 哪些表已经废弃 哪些表是下游报表正在使用的权威表 哪些表有owner和说明
这让智能系统知道：哪些数据可以优先相信。
业务术语上下文
智能问数最难的不是字段映射，而是业务术语映射。例如：
这些词对业务很自然，但对数据库来说并不天然存在。这一层可以把这些术语沉淀下来，并绑定到对应的数据资产、字段、指标和负责人。
这样，当用户问「高价值客户复购率」时，系统可以先知道：
什么是高价值客户 什么是复购率 这些概念属于哪个业务域 对应哪些数据资产 是否有官方定义
血缘和影响分析
智能问数不只是要能回答，还要能解释。比如用户问：「这个销售额来自哪里？」
系统应该能回答：
该指标来自销售经营数据产品，底层依赖订单事实表、支付明细表和客户维度表，上游数据由交易系统同步，下游被经营看板和月度分析报表使用。
这就是血缘的价值。
Owner、标签和质量状态
智能问数系统还应该知道：
这张表谁负责 这个指标谁维护 这个字段是否包含敏感信息 这个数据最近是否更新 有没有质量异常 这个资产是否被认证
这些信息不适合放在LLM prompt里临时拼，而应该沉淀在这一层里。
05第二层详解：把可信数据变成「可查询、可控制、可复用」的业务语义
如果第一层告诉系统「该用什么可信数据」，那么第二层负责把这些数据变成业务可以理解的对象。
它会把底层数据库里的表和字段，封装成业务可以理解的对象：
底层字段：orders.pay_amount、orders.created_at、customers.region、customers.customer_level
↓
语义层：销售额、订单数、客户数、复购率、区域、客户等级、下单时间
这样，智能问数系统就不需要让LLM直接拼复杂SQL，而是让LLM调用已经定义好的指标、维度和过滤条件。
统一指标口径
「销售额」该怎么算？
是订单金额？ 是支付金额？ 是否扣退款？ 是否扣优惠？ 是否含税？ 是否只算已支付订单？
控制join路径
企业数据库中最容易出错的地方之一就是join。订单表可以关联客户表、商品表、门店表、渠道表、活动表。如果join粒度不对，很容易把数放大或算错。
控制权限
智能问数系统如果直接查数据库，很容易带来权限风险。比如：
区域经理只能看自己区域 门店店长只能看自己门店 财务数据只有财务可见 客户手机号、身份证号、地址等字段不能暴露给普通用户
原则上，Agent不能绕过语义层直接查原始库。所有查询都应该走受控语义层。
提供稳定API
理想状态下，LLM输出的不是SQL，而是结构化的查询参数：
{ "measure": "Sales.revenue", "dimensions": ["Region.name"], "filters": { "Region.name": "华东" }, "time_range": "last_month" }
然后由语义层根据定义生成并执行真正的查询。
LLM负责理解和编排，语义层负责执行和治理。
06完整流程：从问题到可信答案，五步走完
假设用户问：「上个月华东区高价值客户的复购率下降了吗？」
第一步：Agent理解问题
系统先拆解问题：指标是复购率，对象是高价值客户，区域是华东区，时间是上个月，分析意图是是否下降。
第二步：查询可信上下文层
系统去查：
「复购率」的官方定义是什么 「高价值客户」的定义是什么 「华东区」指哪个业务区域口径 哪些数据产品和这些术语相关 相关表是否被认证 数据最近是否有质量异常 owner是谁
第三步：选择语义层对象
根据上下文层返回的信息，选择对应的指标和维度：
measure：Customer.repurchase_rate dimension：Customer.region filter：region = 华东 filter：customer_segment = 高价值客户 time：上个月
第四步：语义层执行查询
根据已经定义好的语义模型：
使用统一复购率口径 使用正确的事实表和维表 走受控join 应用用户权限 执行查询 返回结果
第五步：Agent生成可信回答
最终答案不应该只是一句话「下降了。」而应该是：
上个月华东区高价值客户复购率为23.6%，较上上个月下降2.1个百分点。
口径说明：复购率 = 当期发生二次及以上购买的客户数 / 当期购买客户数。
数据来源：客户经营数据产品，底层依赖订单事实表和客户维度表。
治理信息：该指标由客户经营团队维护，相关数据资产为certified。本次查询未发现数据质量异常。
说明：华东区按销售大区口径统计。
这才是可信智能问数。
07四条治理硬规则
如果企业真的想把这套体系做成可信基础层，需要建立一些硬规则。
规则一：未认证数据不进入智能问数生产
未进入治理平台的数据，不允许进入智能问数 未标记owner的数据，不进入生产问数 未认证的数据，不作为默认答案来源 已废弃数据，不允许被Agent使用
规则二：核心指标进入语义层
核心指标不要散落在提示词、代码、SQL、报表、Excel里。应该统一沉淀到语义层中，成为可复用、可治理的指标对象。
规则三：Agent不直接查原始库
Agent可以理解问题、调用工具、生成解释。但真正查数应该走语义层。这样可以避免权限绕过、口径漂移和SQL幻觉。
规则四：答案可解释
可信问数的答案至少应该能解释：
指标口径 数据来源 时间范围 过滤条件 owner 数据质量状态 是否有口径限制
08这套体系的价值，远不止于智能问数
这两层组合的价值不止在ChatBI，它还可以服务于更多智能应用。
对RAG
可信上下文层可以告诉RAG系统哪些文档、报表、数据产品更可信 语义层可以提供结构化指标结果 RAG不只是回答文档问题，也能结合真实业务数据
对算法快速验证
算法Agent可以先用治理层判断数据是否存在、粒度是否合适、质量是否正常 再用语义层获取可信指标和聚合特征 形成算法验证数据
对企业本体网络
未来如果企业建设业务本体或知识图谱：
业务本体：客户、订单、商品、门店、仓库 治理层：这些实体对应哪些表和字段 语义层：这些实体上的指标怎么计算
当然，这套系统如果要运行起来，确实有一定门槛。前期需要针对场景进行调研、测试，上线之后还需要持续维护，而且维护本身是有工作量的。
所以应该优先选择高价值的核心场景。
◆
AI智能体时代，最稀缺的不是更聪明的模型。
是可信的数据基础。
没有可信数据，再强的AI也只是一个更会说谎的助手。
