指标中台+大模型：解密衡石Agentic BI的NL2DSL架构实现

——Text2Metrics引擎如何攻克语义鸿沟，碾压传统NL2SQL方案

一、传统NL2SQL的“架构原罪”：业务语义的失控黑洞

当某银行尝试用NL2SQL分析“高净值客户流失率”时，系统生成如下危险SQL：

这正是NL2SQL的三大架构缺陷：

业务逻辑硬编码缺失：
“高净值客户”在业务系统中需同时满足：总资产>500万 + 近半年交易≥5次 + 风险评级≤B
NL2SQL模型无法感知业务规则库，仅依赖统计概率生成查询
维度关联断层：

1. 导致无法自动下钻区域、产品线维度

2. 权限沙箱失效：

   • 区域经理本应仅查看辖区数据，但NL2SQL直接访问原始订单表，暴露全量敏感信息

衡石科技CTO点评：
“NL2SQL本质是‘绕过业务层的数据直达’——它把BI系统退化为SQL翻译器，牺牲了企业用数的核心防线。”

---

二、Text2Metrics引擎：语义层驱动的三阶编译架构

衡石的NL2DSL方案通过指标中台（Metrics Layer）重构处理流水线：

关键模块解析：

指标仓库（Metric Store）
预置原子化业务指标公式（YAML配置示例）：

动态DSL生成器
用户提问“分析高净值用户GMV地域分布”：

1. 执行引擎优化

   • 利用Apache Doris向量化引擎，将DSL转为低延迟查询

   • 对比测试：

     查询类型	NL2SQL延迟	NL2DSL延迟
     单指标查询	320ms	110ms
     跨5表关联下钻	失败率62%	210ms

---

三、架构对决：NL2DSL vs NL2SQL 核心技术差异

能力维度	NL2SQL方案	衡石NL2DSL方案
业务逻辑承载	依赖大模型“猜测”业务规则	指标中台预置唯一真相源
权限控制	库表级粗粒度管控	基于RBAC的“数据沙箱”
复杂查询支持	多表JOIN错误率高	自动路由预计算模型（命中率>95%）
动态下钻	需手动指定维度	自动关联维度模型
扩展性	每新增业务规则需重新训练模型	修改YAML配置即时生效

制造业OEE分析实战对比：

四、防幻觉设计：语义层的双重校验机制

为避免大模型胡说，衡石在架构中植入两道“止血阀”：

1，静态规则校验层

2，动态知识注入（以金融风控为例）

五、开发者指南：扩展你的行业语义包

基于衡石开放架构快速开发金融风控插件：

创建指标规则包

绑定监管知识库

发布至衡石Agent商店

语义层——Agentic BI的“诺曼底防线”

当某零售客户用NL2DSL取代传统NL2SQL后：

• 业务术语歧义归零：全公司“销售额”“毛利”等30+核心指标口径统一

• 分析效率提升50倍：归因分析从小时级进入秒级时代

• 决策事故率下降92%：语义层拦截87%的错误查询请求

正如衡石架构师所言：“NL2DSL不是技术优化，而是架构革命——它将业务语义从‘隐藏在企业文档里的潜规则’，转化为机器可执行的精准指令。” 当指标中台成为BI Agent的“中枢神经系统”，企业才真正拥有驾驭AI决策的底气。