一、NL2SQL 的准确度天花板
NL2SQL（Natural Language to SQL）是 ChatBI 的核心引擎。用户用自然语言提问，AI 将问题翻译成 SQL 语句，在数据库中执行并返回结果。理论上很完美，但实际效果往往不尽如人意。
业界普遍报告的 NL2SQL 准确率在 70%-85% 之间，具体取决于数据复杂度和问题类型。但在企业场景中，这个准确率是不够的------每 5 次查询就有 1 次出错，业务人员很快就会失去信任。
NL2SQL 面临的挑战主要有四类：
1.1 Schema 理解挑战
企业的数据库可能有上百张表、上千个字段。AI 需要准确理解哪些表和字段与当前问题相关。表名和字段名往往是缩写或拼音（如 xsdd 代表销售订单明细），这对 AI 的理解能力提出了很高的要求。
1.2 语义歧义挑战
-
"销售额"是含税还是不含税？
-
"活跃用户"是 7 天活跃还是 30 天活跃？
-
"上个月"是自然月还是滚动 30 天？
这些歧义在没有上下文的情况下几乎不可能正确处理。
1.3 复杂查询挑战
多表关联、子查询、窗口函数、条件聚合------当查询复杂度上升时，NL2SQL 的准确率会急剧下降。
1.4 口径漂移挑战
随着业务变化，"GMV"等指标的计算口径可能发生变化。如果 AI 依赖训练数据中的历史口径，就会给出过时或错误的答案。
二、NL2Metrics：从"翻译 SQL"到"翻译指标"
衡石的 NL2Metrics 方案核心思路是：不直接把自然语言翻译成 SQL，而是先翻译成"指标查询"。中间多了一层"指标语义层"（Metrics Semantic Layer），这层由 HQL 定义。
对比两种路径：
|--------|-----------|------------------|
| 环节 | NL2SQL 路径 | NL2Metrics 路径 |
| Step 1 | 理解自然语言 | 理解自然语言 |
| Step 2 | 映射到表和字段 | 映射到指标定义 |
| Step 3 | 生成 SQL | 基于指标定义生成查询 |
| Step 4 | 执行 SQL | 执行查询（底层仍转化为 SQL） |
| 口径保障 | 依赖 AI 推断 | 由指标定义保障 |
关键区别在于 Step 2：NL2SQL 直接映射到物理表和字段，而 NL2Metrics 先映射到业务指标。业务指标是预先定义好的、经过审核的、有明确口径的------这就从根本上解决了"口径不一致"的问题。
三、指标语义层的技术架构
衡石的指标语义层由以下几个组件构成：
3.1 HQL 指标定义
每个指标用一个 HQL 表达式定义，描述其业务计算逻辑。HQL 是衡石自研的查询语言，设计目标是在保持表达力的同时降低 AI 理解的难度。
示例（简化）：
hql
复制
DEFINE METRIC MAU AS COUNT(DISTINCT user_id) WHERE event_date >= date_trunc('month', today() - interval '1 month') AND event_date < date_trunc('month', today()) AND user_status = 'active' AND is_test_user = false
这个定义描述的是业务逻辑，不关心底层表名和字段名。即使底层表从 user_events 改名为 events_2026，只要业务逻辑不变，HQL 定义就不需要修改。
3.2 指标主题域
指标按业务主题（如销售、财务、用户）分类组织。当用户提问时，系统会根据问题内容先定位到相关主题域，缩小指标搜索范围，提高匹配准确度。
3.3 指标血缘
记录每个指标的上下游依赖关系。当指标口径发生变更时，可以通过血缘追踪评估影响面。
3.4 向量检索索引
指标定义和描述通过 Embedding 模型向量化，存储在向量数据库中。当用户提问时，系统通过向量相似度检索找到最匹配的指标定义。
四、端到端查询流程
一个完整的 NL2Metrics 查询流程如下：
五、与 RAG 的协同
NL2Metrics 本质上也是一种 RAG（Retrieval-Augmented Generation）应用------检索的是指标定义，增强的是查询生成的准确度。衡石的实现中，向量数据库（预装在 HENGSHI BOX 或部署在云端）存储了所有指标定义的 Embedding。
相比通用的 RAG 方案，衡石的 NL2Metrics 有几个优化点：
5.1 领域特化的 Embedding 模型
针对 BI 指标和查询语句的语义特点进行了微调，对业务术语（如" GMV"、"客单价"、"留存率"）的理解更准确。
5.2 结构化检索 + 语义检索混合
先通过结构化规则（如指标主题域、权限范围）缩小搜索空间，再用向量相似度做精排。这比纯向量检索更可控、更可解释。
5.3 查询意图的分类处理
系统会区分不同类型的查询意图，采用不同的处理路径：
|------|----------------|---------------------------|
| 意图类型 | 示例问题 | 处理路径 |
| 查数据 | "上个月销售额是多少" | NL2Metrics → 指标查询 → 数值结果 |
| 看趋势 | "最近 6 个月的销售趋势" | NL2Metrics → 时间序列查询 → 折线图 |
| 做归因 | "为什么销售额下降了" | NL2Metrics + 归因算法 → 根因分析 |
| 比环比 | "本月同比去年增长多少" | NL2Metrics → 同比计算 → 对比结果 |
六、企业落地建议
要在企业内部落地 NL2Metrics，以下建议可以帮助提高成功率：
6.1 先建好指标字典
至少要把 Top 50 的核心业务指标定义清楚。不需要一次定义所有指标，从最常用的开始。
优先级建议：
-
高管最关注的 10 个 KPI（如营收、利润、增长率）
-
各业务部门负责人最关注的 20 个指标
-
日常运营分析最常用的 20 个指标
6.2 指标命名要规范
使用业务人员日常使用的名称作为指标别名，而不是数据库字段名。
好的命名：销售额（不含税）、月活跃用户数、客户留存率（30天） 不好的命名：sales_amt_net、mau_30d、retention_rate
6.3 积累用户查询日志
收集用户在 ChatBI 中的真实查询，分析高频问题和不匹配案例，持续优化指标定义和匹配策略。
日志分析要点：
-
哪些问题经常被误解？（可能是指标定义描述不清晰）
-
哪些指标被用不同的说法问到？（需要在指标别名中补充这些说法）
-
哪些查询 NL2Metrics 无法处理？（可能需要扩展指标语义层或改进意图理解）
6.4 设置兜底机制
当 NL2Metrics 无法匹配到合适的指标时，应该提供明确的反馈和引导，而不是"猜一个"。
兜底策略：
-
返回最可能的 TOP3 匹配结果，让用户选择
-
提示用户"没有找到精确匹配的指标，您想查的是以下哪一个？"
-
提供"手动选择指标"的备用路径
七、准确度评估框架
落地 NL2Metrics 后，需要建立准确度评估框架，持续监控和改进系统表现。
7.1 评估维度
|---------|-------------------------|-------------------|
| 维度 | 定义 | 评估方法 |
| 指标识别准确度 | 系统能否正确识别用户想查的指标？ | 人工标注测试集，计算精确率和召回率 |
| 口径匹配准确度 | 系统能否正确匹配到指标的口径（如是否含退款）？ | 对比系统返回结果和人工计算结果 |
| 条件解析准确度 | 系统能否正确解析时间、维度、过滤条件？ | 检查生成的查询条件是否正确 |
| 结果呈现准确度 | 系统返回的格式和说明是否清晰？ | 用户满意度评分 |
7.2 持续评估机制
-
每周抽样评估：随机抽取 50-100 条用户查询，人工评估准确度
-
问题分类分析：将错误案例分类（指标识别错误、口径错误、条件解析错误...），针对性改进
-
A/B 测试：对匹配算法、Embedding 模型进行 A/B 测试，选择更优方案
八、总结：NL2Metrics 不是 NL2SQL 的替代
NL2Metrics 不是 NL2SQL 的替代，而是在 NL2SQL 之前加了一层"语义护栏"。这层护栏确保了 AI 不会"自由发挥"指标口径，让 ChatBI 从"大致正确"进化到"精确可信"。
对于追求数据准确性的企业来说，这是 ChatBI 能否大规模推广的关键前提。没有指标语义层保障的 ChatBI，永远只能停留在 Demo 阶段。
衡石的 NL2Metrics 方案通过 HQL 指标语义层、向量检索、意图分类处理等技术，提供了一套可落地的 ChatBI 准确度保障方案。对于正在或准备落地 ChatBI 的企业来说，这套思路值得认真参考。