Article body
正文
企业部署 ChatBI 的首要工作，是让业务人员的提问落在可解释的数据、口径和权限范围内。缺少这层准备，“华东销售为什么下滑”可能得到一段听上去合理、却无法复核的解释。完成准备后，销售负责人可以继续追问到大区、门店、产品和时间窗口，并把每一步查询回到同一套业务定义中核对。
衡石把这一过程放在已有的 BI 工程上推进：用数据集、模型与 HQL 沉淀指标语义，用指标管理组织业务主题，再通过以建模语义层为核心的 NL2Metrics 让自然语言匹配企业已有的指标、维度、时间和过滤条件。Data Agent 可以承接对话式问数、指标创建和仪表盘生成等任务；企业仍需要为数据质量、口径确认、授权和验收结果负责。以下以销售经营分析为例，说明一条适合企业试点的实施路线。
围绕一个经营问题启动试点
示例： 一家消费品企业的销售总监每周都要判断华东大区是否完成阶段目标，并找出落后门店和主要产品线。这个场景看似只需回答“本季度销售额是多少”，实际上包含五个需要先确定的条件：销售额按下单、支付还是发货计算；退款怎样扣减；统计时间按自然月还是业务周；总监和区域经理分别能看到哪些地区；当数字异常时，团队需要下钻到哪一级明细。
试点应把问题写成可验证的业务句子，例如“截至本周，华东大区已支付销售额与阶段目标相差多少，哪些城市和品类贡献了差异”。这句话为建模划出边界：订单、支付、退款、目标和组织归属是首批数据；已支付销售额、退款金额、净销售额、目标完成率是首批指标；大区、城市、门店、品类和日期是首批分析维度。把范围收窄到一个经营问题，业务人员才有足够时间确认口径，数据团队也能把结果与现有经营报表逐项核对。
先用 HQL 与业务配置固化销售语义
衡石的指标管理以数据集或模型上的聚合计算为基础。数据团队可将订单事实、门店和组织关系建成面向业务的模型，再用 HQL 表达原子指标的聚合、过滤与计算逻辑。对上面的示例，团队可以先定义“已支付销售额”为符合已支付状态的金额汇总，“退款金额”为退款记录的金额汇总，再在业务指标中明确净销售额、目标完成率所使用的维度、时间轴和限定条件。业务名称、计算表达式、描述和展示格式应一起维护；页面标题不能代替指标定义。
这里最容易被忽略的是“一个指标”并不等于“一个固定数字”。同一项已支付销售额，按华东大区、按某门店、按本周或按本季度计算，会因维度和过滤条件得到不同结果。团队要把支付日期、退款处理、数据刷新时点和适用的组织层级写进验收规则。若财务使用结算日期，销售使用支付日期，应分别建立名称清楚的指标或业务口径，而不是在问数时让模型猜测。
这也是衡石 HQL 和指标语义层的价值所在。计算逻辑从图表和临时 SQL 中抽离出来，指标可以按业务主题组织并供多处消费。仪表盘、经营报告、嵌入页面与 ChatBI 可以围绕同一组定义工作；每个入口仍需带上自身的过滤、时间和数据时点，结果差异才能被解释，而不是被误判为“系统算错”。
用 NL2Metrics 对齐问题与指标
衡石的 NL2Metrics 路线把自然语言问数放在建模语义层之上。销售总监提出问题后，系统需要识别其中的候选指标、时间范围、分析维度和过滤条件，再在已准备的数据与指标语义中完成查询。这样，用户可以用自然语言提出“华东本季度净销售额落后目标的城市有哪些”，数据团队则能检查该问题是否匹配了正确的销售指标、目标版本和地域层级。
Data Agent 适合承接这种对话式分析，也可以辅助创建指标和生成仪表盘。为了提高业务语义的相关性，团队应维护数据集名称、字段名称、字段与指标描述、同义词和不参与分析的对象；再用真实问题持续发现缺失的定义。模型输出仍需要按固定样本复核，尤其是存在“销售额”“收入”“回款”等近义业务词时。遇到歧义，项目组应补充描述、限定问题或将候选口径交由业务负责人确认，而不是把一次看似合理的回答直接作为经营结论。
把权限边界设计成问数链路的一部分
销售总监可以看全国汇总，华东区域经理只能看本区域，门店经理还要隐藏客户联系方式和个人提成字段。衡石的连接权限、应用数据权限模式与数据集行列权限可分别构成这条边界。行规则可以按用户、用户组、参数或部分用户属性分发数据；列规则可限制字段可见性。项目组应先确定应用按应用作者、数据集作者还是当前使用者的数据范围运行。应用作者、数据集作者模式可设置应用内行列权限；使用者模式使用当前登录人的源数据权限，不能照搬前两种模式的规则配置。
权限配置不能只在仪表盘上看一次总数。联表或加工产生新的数据集后，团队要检查目标数据集上的权限规则。例如，上游数据集的行权限不会自动下推到 join 后的新数据集，需要在新对象上配置并测试。ChatBI、独立页面、嵌入页面和机器人等入口也应由真实角色分别测试。权限范围不同而得到不同数值，验收记录应说明数据范围差异；同一角色在不同入口得到不应有的明细时，团队要回到连接、应用模式和目标数据集逐层排查。
用小范围验收把“能问”交付为“可复核”
第一轮试点可只覆盖一组固定销售问题：本周华东净销售额、按城市拆分的目标完成率、某门店的退款变化、全国与区域角色对同一指标的可见范围。每次测试同时记录登录角色、数据集和指标名称、时间窗口、过滤条件、数据刷新时点、返回数值以及与基准报表的比对结果。出现差异时，先判断它来自口径、权限、数据批次还是提问歧义，再决定修改哪一层。
建议把验收分成两个闭环。第一个闭环由业务负责人确认销售口径和可接受的解释粒度，数据团队核对 HQL 计算和源端结果；第二个闭环由区域角色复测问数、下钻和明细可见范围。只有当固定问题在指定角色和入口中得到可解释结果，团队才把相邻的品类、渠道或更多业务主题纳入范围。项目组应为口径确认、审核和业务动作指定负责人，并在验收记录中保留判断依据。
按业务责任选择接入与扩展方式
试点跑稳后，企业可以让业务人员直接使用独立 ChatBI 页面，也可以按产品形态选择 iframe、JS SDK 或 API。iframe 适合复用完整页面；JS SDK 适合在自有页面中嵌入聊天窗口或结果卡片；API 适合由企业后端负责编排与展示。接入方式解决的是界面和系统边界，不能替代指标、身份认证和数据权限的验收。
企业 ChatBI 应把真实经营问题接到已治理的 BI 资产上。衡石以 HQL、指标管理、NL2Metrics、Data Agent 和多种集成方式提供了这条链路中的能力。销售试点先跑通语义、权限与复核，再逐步扩展到财务、供应链或客户运营，业务人员才能把自然语言问数用于日常决策，数据团队也能说明每个数字从何而来、谁能看到、如何验证。