Article body

正文

5 分钟阅读

引言

“华东区便利店Q2销售额下滑原因是什么？“——当一个区域经理在飞书群里输入这句话时，他期望的不是一串SQL代码，而是直接可理解的业务洞察。

这就是ChatBI的核心承诺：让自然语言直达数据结论。但现实远比承诺复杂。传统ChatBI采用Text2SQL架构，将自然语言直接翻译为SQL查询语句，在简单查询场景下尚可应对，但面对包含多维度交叉、复杂计算口径、业务语义依赖的真实场景时，准确率往往不足30%。

衡石科技在HENGSHI SENSE 6.0中突破性地采用Text2Metrics技术架构——不翻译SQL，而是将自然语言直接映射至预定义的指标语义层。这一架构选择将ChatBI的复杂查询准确率提升至80%以上，从根本上解决了Text2SQL的语义鸿沟问题。

一、Text2SQL的技术瓶颈与语义鸿沟

1.1 Text2SQL的工作原理与局限

Text2SQL的核心流程是：自然语言输入 → LLM推理 → SQL语句生成 → 数据引擎执行 → 返回结果

这一流程看似简洁，但在企业真实场景中暴露出三个根本性问题：

问题一：语义鸿沟

自然语言中的”销售额”在业务语境下可能对应5个不同的数据库字段：gross_sales（毛销售额）、net_sales（净销售额）、adjusted_sales（调整后销售额）等。LLM没有业务上下文，只能根据字段名称的字面匹配进行猜测，准确率极低。

问题二：计算口径歧义

“同比增长率”——这个最常见的业务指标，在不同企业的计算口径可能完全不同：有的用(本期-去年同期)/去年同期，有的用(本期/去年同期-1)，还有的排除季节性因素后计算。Text2SQL无法区分这些口径差异，直接生成的SQL可能计算逻辑完全错误。

问题三：维度关系缺失

“华东区便利店Q2销售额”——这涉及区域维度、门店类型维度、时间维度三者的交叉筛选。Text2SQL需要从自然语言中同时推断出三个维度的映射关系和过滤逻辑，在维度层级复杂的企业中，这一推断几乎不可能仅靠LLM完成。

1.2 准确率的量化差距

在衡石科技的客户实测数据中，Text2SQL架构在不同复杂度查询场景下的准确率表现：

单维度单指标（典型场景：“本月总销售额”）：Text2SQL准确率65%，Text2Metrics准确率95%。

双维度交叉（典型场景：“华东区本月销售额”）：Text2SQL准确率40%，Text2Metrics准确率88%。

多维度+计算（典型场景：“华东区便利店Q2同比增长率”）：Text2SQL准确率18%，Text2Metrics准确率82%。

跨数据集关联（典型场景：“华东区销售额与库存周转率对比”）：Text2SQL准确率8%，Text2Metrics准确率75%。

数据清晰地表明：查询越复杂，Text2SQL的准确率衰减越严重。而Text2Metrics通过指标语义层的预定义，将复杂查询的准确率稳定维持在80%以上。

二、Text2Metrics架构的技术原理

2.1 核心设计思想：语义层作为中间桥梁

Text2Metrics的核心创新是：在自然语言和数据引擎之间，增加一个指标语义层作为中间桥梁。

这个指标语义层不是简单的字段映射表，而是包含三层信息的知识体系：

指标定义层：每个业务指标的精确计算口径，以HQL（Hengshi Query Language）表达式定义
维度关系层：维度层级、维度值映射、跨维度关联关系
语义标注层：每个指标和维度的自然语言别名、业务描述、使用场景标注，用于与用户查询进行语义匹配

2.2 HQL：指标定义的标准语言

HQL是衡石科技自研的指标定义语言，它是Text2Metrics架构的技术基石。HQL的设计原则：业务友好（使用业务术语而非数据库字段名）、计算透明（指标的计算逻辑以声明式表达式定义，可读、可验证、可修改）、维度无关（指标定义不绑定特定维度，用户查询时自由组合维度，引擎自动适配）。

一个典型的HQL指标定义示例：

// 原子指标：销售额
measure sales_amount = SUM(order_net_price)

// 业务指标：华东区便利店月度同比增长率
metric east_convenience_yoy_growth =
  sales_amount[region="华东", store_type="便利店", period="month"]
  / sales_amount[region="华东", store_type="便利店", period="month-12"]
  - 1

2.3 向量索引：语义匹配的加速引擎

语义标注层的匹配效率是Text2Metrics性能的关键。衡石科技采用向量索引技术实现语义匹配的加速：

指标向量化：将每个指标的名称、别名、业务描述、使用场景标注转化为向量表示
维度向量化：将维度名称、层级关系、值映射转化为向量表示
实时语义检索：用户查询输入后，先将其转化为向量，然后在向量索引中检索语义最接近的指标和维度

向量索引的引入使得语义匹配的响应时间从秒级降至毫秒级，同时大幅提升了模糊查询、同义词查询的匹配准确率。

三、Text2Metrics的实现机制详解

3.1 五步推理流程

Text2Metrics的完整推理流程分为五个步骤：

Step 1：意图识别 —— LLM分析用户查询的自然语言意图，判断查询类型：简单查询（单指标+单维度）、复杂查询（多维度交叉+计算口径）、分析查询（需要下钻推理）、对比查询（跨时间段/跨维度对比）。

Step 2：语义匹配 —— 基于向量索引，将用户查询中的业务术语匹配至语义层元素：“销售额” → sales_amount指标，“华东区” → region="华东"维度值。

Step 3：查询构建 —— 基于匹配结果和指标定义，自动构建结构化查询语句。这一步完全由语义层的预定义逻辑驱动，不依赖LLM生成SQL。

Step 4：结果计算 —— 结构化查询提交至数据引擎执行，返回计算结果。

Step 5：结果解释 —— LLM将计算结果转化为自然语言解释，结合业务语境为用户提供可理解的洞察。

整个过程中，LLM只负责”语义匹配”这一步，而非”SQL生成”这一步——语义层已经将计算逻辑和维度关系预定义好，LLM只需要将自然语言中的业务术语映射到对应的语义层元素。

3.2 权限沙箱的嵌入机制

在Text2Metrics的每一步推理中，权限沙箱都作为强制检查点嵌入：

Step 2（语义匹配）后：检查用户是否有权访问匹配到的指标和维度
Step 3（查询构建）后：自动注入行级过滤条件（如区域经理只能查询本区域数据）
Step 4（结果计算）后：检查返回结果是否包含超出权限范围的字段

这种”嵌入式”权限检查机制，确保了Agent在推理过程中不会绕过权限控制。

3.3 错误纠正与自优化

Text2Metrics架构内置了错误纠正机制：

查询验证：在Step 3完成后，自动验证生成的结构化查询是否符合语义层的定义规则，不符合的查询被拦截并要求Agent重新推理
结果验证：在Step 4完成后，自动验证计算结果是否在合理范围内（如销售额不应为负数），超出合理范围的结果触发重新计算
反馈记录：每次推理的成功/失败记录被存储在记忆模块中，用于后续的Prompt优化和Few Shot案例积累

四、行业实测数据与效果评估

4.1 某家电零售企业的实测数据

实施场景：全渠道运营数据分析，涉及20+业务系统、500+业务指标、8个维度层级。

业务人员自主取数比例：实施前30%，实施后（6个月）85%，变化幅度+183%。

平均取数响应时间：实施前2天（人工排队），实施后30秒（ChatBI即时），变化幅度-99.98%。

同类查询Token成本：实施前1800 tokens，实施后900 tokens，变化幅度-50%。

复杂查询准确率：实施前N/A（无法完成），实施后82%，变化幅度从0到82%。

4.2 某证券公司的风控场景实测

实施场景：实时反欺诈模型、智能投顾系统，涉及毫秒级响应要求。

客户咨询响应时间：实施前45秒（人工），实施后2秒（ChatBI自动）。

反欺诈资金拦截率：实施前千万分之0.5，实施后千万分之0.1。

合规审计报告生成：实施前2周（人工整理），实施后1小时（系统自动）。

五、Text2Metrics vs Text2SQL：架构对比总结

核心路径：Text2SQL是”自然语言→SQL”，Text2Metrics是”自然语言→语义层→结构化查询”。

语义处理：Text2SQL是LLM一次性翻译，Text2Metrics是语义层预定义+LLM语义匹配。

简单查询准确率：Text2SQL 65%，Text2Metrics 95%。

复杂查询准确率：Text2SQL <20%，Text2Metrics >80%。

计算口径保障：Text2SQL无（依赖LLM推断），Text2Metrics强（语义层预定义）。

维度映射保障：Text2SQL无（依赖LLM推断），Text2Metrics强（语义层预定义）。

权限控制：Text2SQL是查询后过滤，Text2Metrics是推理中嵌入式检查。

可维护性：Text2SQL是规则模板维护成本高，Text2Metrics是语义层集中管理。

自优化能力：Text2SQL无，Text2Metrics有记忆模块闭环反馈。

六、实施建议与最佳实践

6.1 语义层建设的三个关键步骤

指标梳理：从业务报表和经营分析需求中提取核心业务指标清单，明确每个指标的计算口径、适用维度、数据来源
HQL定义：将指标清单转化为HQL表达式，确保计算逻辑精确、维度组合灵活
语义标注：为每个指标和维度添加自然语言别名、业务描述、使用场景标注，完成向量化和索引构建

6.2 渐进式部署策略

第一阶段：先覆盖高频查询场景（占日常取数需求的60%），验证Text2Metrics的基本准确性
第二阶段：扩展至复杂分析场景（下钻推理、跨维度对比），启用Agent的记忆模块和自优化能力
第三阶段：接入即时通讯工具的ChatBot，实现”业务即分析”的嵌入式体验

结语

Text2Metrics的核心洞察是：自然语言与数据之间的鸿沟，不是翻译问题，而是语义问题。与其让LLM每次都”重新翻译”一遍业务语义，不如在语义层中一次性定义好业务指标的计算口径和维度关系，让LLM只负责”识别意图、匹配语义”，将复杂推理交给预定义的结构化逻辑处理。

这一架构选择，从根本上改变了ChatBI的可靠性天花板——从”30%的碰运气”到”80%以上的确定性”。当企业决策者可以信赖ChatBI返回的每一个数字时，数据分析才真正从”展示工具”进化为”决策伙伴”。

衡石科技通过HENGSHI SENSE 6.0的Text2Metrics架构，为Agentic BI奠定了最关键的技术基石——让自然语言不再是数据世界的”外语”，而是直接通往业务洞察的母语。

Text2Metrics：从自然语言到业务指标的技术直通车

引言