智能问数落地指南

你有决策权，能推动数据治理落地，能容忍前期投入大、见效慢。

如果项目本身是面子工程，这篇帮不了你。

---

背景：技术换了四轮，为什么还是没跑起来？

智能问数从大模型出现第一天就有人在做，技术路线已经换了三四轮：

RAG + Text-to-SQL  →  模型微调  →  Agent 自主探索  →  多 Agent 流水线 + 语义层

但到今天，真正在企业里跑起来、业务方天天在用的，几乎没有。

原因只有一个：大家，起码我了解到的甲方们，都只是把它当 AI 项目做了，实际上它是数据治理项目，AI 只是挂在上面的一个入口。

---

第一步：用户定位------从"全员用"到"分析师优先"

很多团队上来就画大愿景：让全公司任何人都能用一句话问到数据。听上去美，但每类人的需求完全不一样：

角色	真实需求	适合智能问数？
老板	看看板和报告，不查明细	❌ 不是目标用户
一线员工	月报、周报、临时指标	⚠️ 适合固化场景
数据分析师	每天大量随机新需求	✅ 核心目标用户

成功落地的案例，一开始都把产品定位成分析师辅助工具。听上去立意不高，但定位准了，后面所有决策都顺。

为什么分析师是最佳切入点？

• 懂 SQL，能自己判断生成结果对不对
• 能接受不那么自然的输入方式（手动选指标、维度也行）
• 能容忍偶尔出错------他自己写 SQL 也会写错

💡 类比参考：Coding Agent 的上手程度，程序员明显高于非技术人员。"业务人员也在用 Coding Agent"------这里有严重的幸存者偏差，沉默的大多数试了一次就再也不打开了。

定位全员用的风险： 某个同事被错误结果坑了一次，永远不会再打开。第二次使用率断崖下降，反馈只剩"这东西太烂了"。信任一旦崩掉，几乎没法修补。

第一步必须想清楚三件事：

1. 明确的用户画像------谁在用？
2. 明确的使用场景------用来做什么？
3. 明确的失败可接受度------出错了怎么办？

从一个小场景切入，做精做透，再逐步扩展。

---

第二步：架构决策------两条路线，一套分层体系

业界经常把 Text-to-Metric 和 Text-to-SQL 混着谈，但它们的可靠性逻辑完全不同。

两条路线的本质区别

Text-to-Metric
─────────────────────────────────────────────────
把可信查询提前固化，AI 只做意图理解和参数填充
可靠性来自离线已验证的工作
AI 犯错空间被压到极小

Text-to-SQL
─────────────────────────────────────────────────
让 AI 现场从 Schema 推理出查询
可靠性完全依赖在线推理
Schema Linking 准不准、字段语义猜没猜对、
JOIN 逻辑通不通，每一步都有出错概率，还会累积

能用 Metric 解决的问题去用 SQL 解决，等于把已验证的确定性问题重新降级成概率问题------这是反向操作。

正确架构：分层兜底

┌─────────────────────────────────────────────────────┐
│              用户自然语言查询                         │
└──────────────────────┬──────────────────────────────┘
                       │
           ┌───────────▼───────────┐
           │    意图理解 & 分流     │
           └───────────┬───────────┘
                       │
        ┌──────────────┴──────────────┐
        │                             │
┌───────▼────────┐           ┌────────▼───────┐
│ Text-to-Metric │           │  Text-to-SQL   │
│  高频 · 确定性  │           │  长尾 · 低频   │
│    覆盖 ~80%   │           │   覆盖 ~20%   │
│  可靠性 ≈ 100% │           │  可靠性 ≈ 80% │
└────────────────┘           └────────────────┘

整个项目的核心工作，本质上就是不断扩大 Text-to-Metric 能覆盖的范围，压缩 Text-to-SQL 需要兜底的长尾。

---

第三步：数据治理 + 语义层------占 70% 工作量的硬骨头

Text-to-Metric 这一层怎么建起来？答案是数据治理 + 语义层。

所谓 AI 数据助理的挑战，绝大多数其实是数据本身的问题：

• 表之间关系复杂、缺乏维护
• 字段命名晦涩（比如 AEFAMT）
• 同一概念跨系统编码不一致
• 业务术语在不同部门含义不同
• 大表里夹杂脏数据

再贵的模型、再牛的 Agent 框架，碰到 status_code = 3，也猜不出来这是"已发货"还是"已退款"。

治理工作分四类：

① 元数据与字段语义标注

那些叫 AEFAMT、FLAG_X 的字段，必须重新标注：

• 业务别名
• 字段含义、单位、取值范围
• 空值的业务解释

② 表关系与跨系统编码对齐

主键、外键、JOIN 条件必须显式画出来。

系统	客户字段名
CRM	cust_id
订单系统	customer_no
会员系统	member_id

这三套编码必须有明确的映射表。否则 AI 生成的 JOIN 结果看着合理，但全是错的------这种错最可怕，因为没人会怀疑。

③ 业务术语与同义词词典

问题示例	难点
"复购率"	是按 30 天算，还是自然月？
"活跃用户"	市场部、运营部、财务部各有口径
"客户"	销售叫客户、市场叫用户、运营叫会员、CRM 叫联系人------是同一拨人吗？

AI 不可能凭空知道你们公司的业务规则，必须人工定义和确认。

④ 指标平台与公式化知识库（核心）

每个核心指标必须有唯一定义：

指标名称: 活跃用户
─────────────────────────────────────
市场部口径: 过去 30 天打开过 APP
运营部口径: 过去 7 天有下单或加购行为  
财务部口径: 过去 90 天有过付费行为
默认口径: [由业务负责人确认]
─────────────────────────────────────
计算公式: COUNT(DISTINCT user_id) WHERE ...
时间口径: "最近一周" = 滚动 7 天 or 自然周？
业务规则: 核心客户 = 年消费额 ≥ 100 万 AND 下单频次 ≥ 12 AND 合作年限 ≥ 2 年

规则必须是可计算的，不是一句"那些重要的客户"。

技术实现： 向量库做语义召回 + 倒排索引做精确匹配，混合检索后将结果作为 Evidence 拼入 Prompt。命中已治理指标的，直接走 Metric 路径。

组织协同才是真正的难点

业务术语词典要业务负责人逐条确认------他没空。

指标口径要财务、销售、运营三方对齐------他们对不齐，因为对齐了就意味着以后谁也不能私下改口径。

数据团队和业务团队要一起维护公式库------数据团队人手永远不够，业务团队觉得这不是自己的活儿。

能不能把业务一号位拉进来站台？能不能让财务总监同意公开毛利口径？能不能让各事业部交出私有定义？这些组织问题决定了项目天花板。

预算和工期的 70% 花在这里一点都不夸张。这一步做好了，后面全是顺水推舟；这一步糊弄过去，就躺平交差吧。

---

第四步：Text-to-SQL 长尾兜底------Schema Linking 怎么做

为什么不能直接塞全量 Schema？

企业数据库随便几百张表、上千个字段，全塞进上下文：

• Token 成本爆炸
• 模型在大上下文里找重点本来就费劲
• 无关 Schema 是噪声------模型看见两张名字相似的表，可能随便挑一张 JOIN，结果完全错

两种代表性方案

方案一：CAS（多阶段串联筛选）

用户问题
  → 关键词抽取 → 匹配实体值 & 字段描述 → 候选证据池
  → 粗筛
  → 字段选表
  → 精挑列
  → 最终子集 Schema

优点：流程清晰，出问题好定位

缺点：LLM 调用次数多，延迟和成本不低

方案二：MACSQL 的 Selector Agent（按需触发）

两个务实设计：

1. 按需触发：只有 Schema Prompt 长度超过阈值才启动 Selector，短 Schema 直接塞进去，反而更省 Token
2. 结构化输出协议：告诉模型哪些表整张保留、哪些整张丢掉、哪些只保留指定列，输出必须是 JSON，下游直接消费

📊 Bird Benchmark 消融实验数据：去掉 Selector 后，简单查询准确率完全没掉，但困难查询从 40.28% 降到 35.14%。

结论：Schema Linking 对简单查询基本没用，对复杂查询贡献显著。Selector 本身就该按需触发，不是无脑全开。

Schema Linking 的边界

Schema Linking 再准，也只解决"找哪些表、哪些字段"的问题，解决不了业务口径问题。

活跃用户该用哪张表，Selector 能选对；但活跃是 7 天还是 30 天，得靠指标平台回答。两件事缺一不可。

---

第五步：查询复杂度分流------一定要用 Agent 吗？

不一定。Agent 适合多步骤、多工具、不确定路径的任务，但企业内部符合这个画像的 Query 不到 20%。

┌────────────────────────────────────────────────────┐
│                  查询复杂度分流                     │
├──────────────┬───────────────┬────────────────────┤
│   简单查询   │   中等查询    │     复杂查询       │
│ 单表 1-2 列  │  多表 JOIN    │  跨多数据源        │
│              │               │  路径无法预规划    │
│ ① 命中缓存  │ Decomposition │                    │
│   直接返回  │ + QT 拆子问题 │   Agent 登场 ✅    │
│ ② Few-shot  │               │                    │
│   一次生成  │               │                    │
├──────────────┴───────────────┴────────────────────┤
│  占比估计：   ~60%              ~20%        ~5-20% │
└────────────────────────────────────────────────────┘

为了 5% 的复杂查询把整套系统做成 Agent，让剩下 95% 的查询都付出多次 LLM 调用的代价------这是最常见的过度工程。

一个被忽略的小技巧：中间表示

直接让大模型生成 SQL，它要同时考虑子句、表别名、字段限定、GROUP BY 等，出一个错整条 SQL 就废了。

让模型先生成简化版中间表示，再用确定性规则翻译成可执行 SQL，效果好很多：

实验数据：引入中间表示后，含 JOIN 的查询准确率从 69% 提升到 ~77%

如果模型总在 JOIN 和嵌套查询上栽跟头，引入轻量中间表示比换更大的模型见效更快。

---

第六步：AI 输出层收口------降级链设计

Text-to-Metric 的输出设计

不让 AI 输出原始 SQL，而是输出结构化的指标查询请求：

{
  "metric": "活跃用户数",
  "dimensions": ["城市", "渠道"],
  "filters": { "platform": "APP" },
  "time_range": "last_30_days",
  "granularity": "day"
}

由指标平台翻译成最终 SQL 执行。三个核心优势：

1. AI 犯错空间被极大压缩------不需要知道表名、字段名、JOIN 条件
2. 业务口径被锁死------指标平台里已验证的 SQL 版本，AI 不会自己写一个口径不一致的版本
3. 底层数据源解耦------后面接什么数据库都不重要

降级链设计（四层）

第一层：命中 Metric → 直接返回 ✅

第二层：历史 SQL 缓存中找相似 Query → Few-shot 改写 ⚠️

第三层：Text-to-SQL 兜底 → 明确标注"未经业务验证，请人工核对" ⚠️⚠️

第四层：超出系统能力 → 告知用户，建议联系数据团队
        同时记录该 Query → 推送给治理团队作为新指标候选 📋

第四层的反馈闭环非常重要。一个好的系统应该知道自己不会什么，并且能把不会的东西反馈给治理团队去补齐。长期看，治理覆盖率会随着使用越来越高。

如果公司还没有指标平台，强烈建议在做 AI 数据助理之前先搭起来。不一定要用 Cube、dbt Semantic Layer 这些现成产品，但至少要有一套自研的指标注册 + 查询编译 + 缓存机制，否则 AI 这一层永远是空中楼阁。

---

第七步：兜底安全与上线评估

投票机制（对抗幻觉）

两个模型各跑一遍，结果一致才执行，不一致让用户选：

听上去土，但能把幻觉率从 8% 压到 0.5%
代价是 Token 多一倍，企业内部场景这个钱花得起

安全护栏（必须项）

• AI 使用的数据库账号必须只读
• 生成的 SQL 过一遍 AST 解析，发现 DROP、DELETE、UPDATE 直接拒绝
• 所有查询自动加 LIMIT
• 手机号、身份证、薪资等敏感字段要么脱敏，要么禁止查询
• 每次查询记录：谁、什么时间、问了什么、生成了什么 SQL、执行结果

这层做完，最坏情况也就是查询结果错误，不会出数据事故。

上线评估（三层递进）

第一层：公开数据集测试（如 Spider、Bird）
        → 了解模型能力天花板

第二层：业务样本测试
        → 向业务部门收集真实问题，验证业务准确率

第三层：灰度上线（选一个部门，跑一周）
        → 看实际使用准确率
        → 通常比第二层掉 10~20 个百分点
           因为真实用户的提问方式永远比你预想的奇怪

⚠️ 查询变体测试：同一个问题用不同方式问，AI 能不能给出一致答案？POC 阶段如果只测一种问法，上线立马露馅。

---

总结：七步里真正是 AI 的部分有多少？

┌─────────────────────────────────────────────────────────┐
│  七步工作拆解                                            │
├─────────────────────────────────────────────────────────┤
│ ✅ 属于 AI 技术    │ Schema Linking                      │
│                   │ 查询复杂度分流                       │
├─────────────────────────────────────────────────────────┤
│ 🔧 属于工程 & 产品 │ 用户定位与场景切入                  │
│                   │ 数据治理与语义层建设（最重要）       │
│                   │ 指标平台搭建                         │
│                   │ 降级链 & 输出层设计                  │
│                   │ 安全护栏 & 上线评估                  │
└─────────────────────────────────────────────────────────┘

框架可以通用，内容必须定制。 Schema Linking 策略、投票机制、安全护栏这些是框架层面的东西，可以做成通用产品；但语义层、指标定义、字段映射、业务口径是每家公司独有的，没法搬。

那些号称"开箱即用"的企业 AI 数据助理，要么定位极窄（只做某个垂直行业的标准化场景），要么是 PPT 产品。

---

结论

智能问数不是 AI 项目，是数据治理项目。

核心路线：用治理把高频查询尽可能搬到 Text-to-Metric 层，让 Text-to-SQL 只兜长尾。

这条主线想清楚了，剩下的都是工程问题。想不清楚，技术再花哨也救不回来。