摘要ChatBI 是 AIBI 融合中最受关注的方向但「自然语言问数」的准确度一直是落地难题。衡石 ChatBI 选择了一条与主流方案不同的技术路线——NL2Metrics自然语言转指标以指标语义层替代 NL2SQL从根本上解决了企业级场景中的准确度、安全性和可治理问题。本文从技术架构、实现原理和应用效果三个维度深度解析衡石 ChatBI 的设计思想。一、ChatBI 的现状热闹但难落地过去两年几乎所有 BI 厂商都在做 ChatBI——用户可以像聊天一样问数据问题大模型自动生成 SQL 并返回结果。听起来很美好但企业实际落地时普遍遇到三个问题准确度不稳定。同一个问题换一种问法大模型生成的 SQL 可能完全不同。销售团队问「上个月华东区营收多少」数据分析师问「5月华东区域收入」两个看似相同的问题可能得到不同的答案——因为大模型对「营收」和「收入」的口径理解不一致。安全不可控。NL2SQL 方案要求大模型直接生成并执行 SQL这意味着模型拥有数据库的查询权限。一旦模型生成的 SQL 包含了越权查询比如访问了不该访问的表或是产生了笛卡尔积导致数据库压力后果严重。结果不可治理。当业务决策基于 ChatBI 的输出时后续如果发现数据有问题很难追溯到底是「模型理解错了」还是「指标口径有问题」。而且不同版本的模型对同一个问题的回答可能不一样数据一致性无从保证。这三个问题指向同一个根源把准确度寄托在大模型的生成能力上而不是业务流程的确定性上。二、衡石的技术路线NL2Metrics vs NL2SQL衡石 ChatBI 的核心设计选择是NL2Metrics——不让大模型实时生成 SQL而是让大模型匹配预定义的指标语义层。2.1 NL2SQL 的工作方式用户提问 → 大模型理解意图 → 生成SQL → 执行SQL → 返回结果这个链条上每个环节都可能出错意图理解偏差用户说的「营收」可能指的含税/不含税、GMV/实收SQL 生成错误语法正确但逻辑错误比如JOIN错了表执行风险生成低效查询导致数据库压力结果不可复现不同模型版本生成不同SQL2.2 NL2Metrics 的工作方式用户提问 → 大模型理解意图 → 匹配指标语义层 → 执行预定义指标查询 → 返回结果关键差异在于第三步大模型不做 SQL 生成而是做语义匹配。它检索企业的指标定义库找到最匹配的指标如「华东区月度营收」然后调用该指标的预定义查询逻辑。2.3 为什么 NL2Metrics 更准维度NL2SQLNL2Metrics口径管理每次生成时由模型「猜测」事前定义Agent 只做匹配复现性同一问题可能每次不同答案同一指标同一口径结果必定一致安全控制大模型直接生成数据库查询通过指标层权限隔离无法越权更新影响模型升级可能导致结果变化指标逻辑变更可控、可追溯业务治理无指标血缘、版本管理、变更审查核心洞察NL2Metrics 不是否定大模型的能力而是把大模型用在它擅长的地方语义理解与匹配而不是它不稳定的地方逻辑生成。这就像让大模型做翻译而不是做数学题。三、技术实现三层架构拆解衡石 ChatBI 的技术架构可以拆解为三层3.1 建模层指标语义层的构建这是整个 ChatBI 准确度的基础。衡石指标平台支持企业通过以下方式构建指标体系拖拽式建模业务人员可以像操作 Excel 透视表一样通过拖拽定义指标的计算逻辑HQL 编码建模数据分析师可以通过 HQLHengshi Query Language编写复杂指标逻辑支持多表关联、窗口函数、聚合运算等高级操作模板复用预置常用分析模型同环比、RFM、漏斗分析等降低建模门槛每个指标定义包含——指标名称如「华东区月度营收」计算逻辑SUM(amount) WHERE region华东 AND timemonth数据来源关联的数据集和数据表口径说明业务含义的文字描述帮助大模型理解这个指标在业务语境中的含义权限控制哪些角色/用户可以查询这个指标3.2 匹配层NL2Metrics 的语义匹配当用户提问时ChatBI 的匹配流程如下意图解析大模型解析用户的自然语言问题提取关键实体区域、时间、指标类型和意图查询/对比/趋势语义检索在指标语义层中检索匹配的指标定义优先精确匹配其次模糊匹配多候选排序如果有多个匹配的指标大模型根据业务上下文选择最合适的那个参数填充将用户问题中的参数如时间范围、区域填充到指标查询模板中执行查询调用指标平台的查询接口按定义逻辑执行关键设计如果大模型找不到匹配的指标ChatBI 不会「猜一个 SQL」而是提示用户该指标尚未定义、建议联系数据团队建模。这种「不回答比瞎回答好」的设计哲学才是企业级产品应该有的态度。3.3 交付层结果呈现与交互ChatBI 的查询结果不只是返回一个数字而是——结构化呈现自动选择最合适的可视化形式表格/柱状图/趋势线智能解读对结果进行一句话的上下文解读如「华东区5月营收环比增长12.3%主要受618预热活动拉动」追问支持用户可以在当前上下文内继续追问如「那华南区呢」无需重新描述完整问题一键转看板ChatBI 的问答结果可以一键保存为仪表盘组件沉淀为持续监控的分析资产四、企业级特性不只是能问对还要能放心用4.1 安全控权衡石 ChatBI 的安全模型有三层指标层权限用户只能查询自己被授权的指标数据层权限通过行级权限Row-Level Security控制数据可见范围比如华东区负责人只能看到华东区的数据功能层权限区分「只能问数」「可以建模」「可以管理指标」等不同角色4.2 多租户隔离面向 ISV独立软件厂商场景衡石 ChatBI 支持——租户级指标隔离不同客户的指标体系完全独立租户级数据隔离数据物理或逻辑隔离租户级大模型配置不同客户可以使用不同的大模型服务4.3 多渠道接入ChatBI 能力可以通过多种方式嵌入到企业的工作流中HENGSHI SENSE 内嵌在 BI 平台的报表查看页面一键唤起 ChatBI 对话API 接入通过 RESTful API 嵌入企业自有应用如 OA、CRM、企业微信HENGSHI BOX 本地部署所有推理和数据查询在本地完成数据不出企业边界五、应用场景场景一业务人员自助问数传统痛点销售 VP 想知道「各区域本季度重点客户的留存率趋势」需要先找数据分析师排期等两三天拿到报告。ChatBI 体验直接输入问题秒级获得结构化结果和趋势图。发现异常后可以追问「华东区是哪些客户流失了」获得明细数据。场景二管理层经营驾驶舱传统痛点每月经营分析会前BI 团队加班赶制几十页报告管理层看完后发现新的问题角度又要等下一版。ChatBI 体验管理层在会议中可以直接对着大屏提问「对比一下去年同期的数据」「按产品线拆分的毛利率变化」实时获得洞察无需等待。场景三嵌入 ISV 产品传统痛点SaaS 厂商想为自己的客户提供 AI 分析能力但自研 ChatBI 成本太高准确度难以保证。ChatBI 体验通过衡石的嵌入式 ChatBISaaS 厂商可以为每个客户提供基于该客户数据的智能问答能力。不同客户之间的数据和指标完全隔离开箱即用。六、与 ChatBI 竞品的核心差异需要明确的是衡石 ChatBI 的定位不是通用的对话式 AI而是企业级 BI 场景的专用 ChatBI。这个定位决定了它在几个关键决策上的不同准确度优先而非体验优先— 宁可说「不知道」也不乱回答指标语义层是基础设施而非可选件— 没有建模就没有准确度这是设计前提面向 ISV 的多租户场景— 从第一天就考虑了B2B2B的权限和隔离需求Agent 可调度— ChatBI 不只是独立产品还是 Data Agent Family 的一个模块可以通过 CLI 被 Agent 调用七、常见问题Q1NL2Metrics 是不是限制了大模型的能力比如用户问了一个没有预定义指标的问题怎么办A这正是 NL2Metrics 的核心设计理念——「不回答比瞎回答好」。当用户问到未定义指标时ChatBI 会明确告知该指标尚未建模并引导用户联系数据团队。这看似减少了灵活性实际上保护了决策准确性。而且衡石的建模 Agent 可以加速新指标的创建让指标库随业务需求动态生长。Q2推荐什么样的企业先从 ChatBI 开始A建议已具备基础数据建模能力的企业优先。ChatBI 的准确度直接取决于指标层的质量如果企业连基本的数据仓库和指标定义都没有直接上 ChatBI 只会放大混乱。衡石的建议路径是先用衡石平台完成数据集成和指标建模再进行 AI 增强。Q3ChatBI 能处理多轮复杂对话吗A支持上下文连贯的多轮对话。比如「华东区上个月营收多少」→「环比呢」→「拆到城市粒度」→「把趋势图放到我的驾驶舱里」。每一轮都在前一轮的上下文基础上执行。八、总结衡石 ChatBI 最大的差异化不在于它的对话体验有多好而在于它选择了一条更难但更正确的技术路线——用建模保障准确度用语义层替代 SQL 生成。在企业级场景中ChatBI 的终极问题不是「AI 能不能理解问题」而是「企业敢不敢相信 AI 给出的答案」。从这个角度看NL2Metrics 的正确率不是 95% 或 98% 的问题而是「可以错还是不可以错」的问题——在决策支持场景中答案是后者。