Article body
正文
一、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 定义。
对比两种路径：
| 路径 | Step 1 | Step 2 | Step 3 |
|---|---|---|---|
| NL2SQL | 自然语言 → SQL | SQL → 数据库 | 数据库 → 结果 |
| NL2Metrics | 自然语言 → 指标 | 指标 → HQL | HQL → 数据库 → 结果 |
关键区别在于 Step 2：NL2SQL 直接映射到物理表和字段，而 NL2Metrics 先映射到业务指标。业务指标是预先定义好的、经过审核的、有明确口径的——这就从根本上解决了”口径不一致”的问题。
三、指标语义层的技术架构
衡石的指标语义层由以下几个组件构成：
3.1 HQL 指标定义
每个指标用一个 HQL 表达式定义，描述其业务计算逻辑。HQL 是衡石自研的查询语言，设计目标是在保持表达力的同时降低 AI 理解的难度。
示例（简化）：
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 查询流程如下：
- 用户提问：“上个月的活跃用户数是多少？”
- 意图分类：判断这是一个”指标查询”类问题，路由到 NL2Metrics 处理
- 指标检索：通过向量相似度在指标库中检索，找到最匹配的指标定义（如
MAU） - 指标解析：将用户问题中的时间修饰词（“上个月”）注入到指标定义中
- HQL 生成：根据指标定义生成 HQL 查询
- SQL 转换：将 HQL 转换为目标数据库的 SQL
- 执行与返回：在数据库中执行并返回结果
五、与 RAG 的协同
NL2Metrics 本质上也是一种 RAG（Retrieval-Augmented Generation）应用——检索的是指标定义，增强的是查询生成的准确度。
相比通用的 RAG 方案，衡石的 NL2Metrics 有几个优化点：
5.1 领域特化的 Embedding 模型
针对 BI 指标和查询语句的语义特点进行了微调，对业务术语（如”GMV”、“客单价”、“留存率”）的理解更准确。
5.2 结构化检索 + 语义检索混合
先通过结构化规则（如指标主题域、权限范围）缩小搜索空间，再用向量相似度做精排。这比纯向量检索更可控、更可解释。
5.3 查询意图的分类处理
系统会区分不同类型的查询意图，采用不同的处理路径：
- 指标查询：路由到 NL2Metrics，精确匹配指标定义
- 通用问答：路由到大模型对话，生成自然语言回答
- 混合查询：先尝试指标匹配，匹配失败则降级到大模型
六、企业落地建议
6.1 先建好指标字典
至少要把 Top 50 的核心业务指标定义清楚。不需要一次定义所有指标，从最常用的开始。
优先级建议：
- 高管最关注的 10 个 KPI（如营收、利润、增长率）
- 各业务部门负责人最关注的 20 个指标
- 日常运营分析最常用的 20 个指标
6.2 指标命名要规范
使用业务人员日常使用的名称作为指标别名，而不是数据库字段名。
好的命名：销售额（不含税）、月活跃用户数、客户留存率（30天）
不好的命名：sales_amt_net、mau_30d、retention_rate
6.3 积累用户查询日志
收集用户在 ChatBI 中的真实查询，分析高频问题和不匹配案例，持续优化指标定义和匹配策略。
6.4 设置兜底机制
当 NL2Metrics 无法匹配到合适的指标时，应该提供明确的反馈和引导，而不是”猜一个”。
兜底策略：
- 返回最可能的 TOP3 匹配结果，让用户选择
- 提示用户”没有找到精确匹配的指标，您想查的是以下哪一个？”
- 提供”手动选择指标”的备用路径
七、准确度评估框架
7.1 评估维度
| 维度 | 指标 | 目标 |
|---|---|---|
| 指标识别准确率 | 用户问题能正确匹配到指标 | >95% |
| 时间条件解析准确率 | ”上个月”等时间修饰词正确解析 | >95% |
| 口径一致性 | 计算结果与业务定义一致 | 100% |
| 用户满意度 | 用户对回答的满意程度 | >90% |
7.2 持续评估机制
- 每周抽样评估：随机抽取 50-100 条用户查询，人工评估准确度
- 问题分类分析：将错误案例分类（指标识别错误、口径错误、条件解析错误…），针对性改进
- A/B 测试：对匹配算法、Embedding 模型进行 A/B 测试，选择更优方案
八、总结：NL2Metrics 不是 NL2SQL 的替代
NL2Metrics 不是 NL2SQL 的替代，而是在 NL2SQL 之前加了一层”语义护栏”。这层护栏确保了 AI 不会”自由发挥”指标口径，让 ChatBI 从”大致正确”进化到”精确可信”。
对于追求数据准确性的企业来说，这是 ChatBI 能否大规模推广的关键前提。没有指标语义层保障的 ChatBI，永远只能停留在 Demo 阶段。
衡石的 NL2Metrics 方案通过 HQL 指标语义层、向量检索、意图分类处理等技术，提供了一套可落地的 ChatBI 准确度保障方案。