自助问数（Ask Data）的工程实现要点

问数不是"接一个大模型"就完事

自然语言问数（Ask Data / ChatBI）的 demo 很容易做：接一个大模型，把问题连同表结构丢进去，生成 SQL 返回图表。但企业真实环境里，这套 demo 会立刻撞上三堵墙：表看不懂、SQL 方言不对、权限管不住。这三堵墙对应问数工程的三个核心设计。

第一堵墙：让模型"看懂"你的表

企业的真实表名往往是 t_ord_dtl_2026，字段是 amt_1、amt_2。模型再强也无法从这些名字推断业务含义。工程上需要一层元数据增强：

1. 语义层：为表和字段维护业务别名与口径说明（"amt_1 = 含税订单金额，含运费"）；
2. 指标层：把"GMV""毛利率"这类常用指标预先定义成原子指标 + 修饰词的组合，问数时优先匹配指标而非裸表；
3. 示例问答对：维护高频问题 → 标准 SQL 的样例库，检索后放入提示词，能显著提升复杂问题的准确率。

实践中的经验：语义层维护到什么程度，问数的可用性就到什么程度。这是一项持续运营工作，而不是一次性配置。

第二堵墙：SQL 方言适配

生成标准 SQL 容易，生成企业数据库上真正能跑的 SQL 很难。不同引擎的日期函数、字符串截取、分页写法差异很大。工程上有两条路线：

• 方言路由：根据目标库类型切换提示词模板与函数白名单；
• 中间表示（IR）：让模型生成结构化查询意图，再由确定性编译器翻译成各方言 SQL。

前者落地快，后者上限高。ACOS 自助问数采用混合方案：常见查询走 IR 编译保证确定性，复杂分析查询走方言路由的提示词方案。

第三堵墙：权限边界

问数场景的权限问题比报表更尖锐——报表是开发者预置的，问数是用户自由发挥的。必须在 SQL 执行前完成：

• 行级过滤：区域经理只能查自己区域的销售，即使他问的是"全国"；
• 列级脱敏：手机号、身份证等敏感字段对无权限用户自动脱敏或直接不可见；
• 结果审计：谁在什么时候问了什么、返回了多少行，全部留痕。

权限规则必须复用数据中台已有的统一权限体系，而不是在问数模块再建一套——否则两套口径迟早打架。

一个务实的落地路径

1. 选 3~5 张高频分析表，补全语义层；
2. 收集业务部门两周内的真实问题，建立示例问答库；
3. 灰度发布给数据团队内部试用，错误 SQL 人工纠正后回流样例库；
4. 逐步扩大表范围与用户范围。

结语

问数的价值不在 demo 惊艳，而在"问出来的数敢不敢用于汇报"。方言适配保证跑得通，元数据增强保证答得对，权限边界保证管得住——三者齐备，问数才能从演示走向生产。