一文读懂:AI智能问数

深度思考

AI 智能问数，为什么我不敢让它直接写 SQL？

AI 最擅长"选菜单"，不是"做菜"

2026-06-04 · 阅读约 5 分钟

上周见客户，现场搭了个 AI 智能问数 Demo。用户用自然语言提问，AI 自动生成 SQL，查数据库，返回图表——典型的 Text-to-SQL，这些年最火的 AI 落地场景。

然后我就踩坑了。

第一次问"各车系的试驾率"，AI 返回 CT 试驾率37.04%。SQL 漂亮，数字合理。隔了半小时，同事换了个问法——"不同车系客户试驾的比例"，同一个意思。这次 CT 试驾率变成了42.10%。

同一张表、同一问题、不同表述——差了 5 个百分点。原因？第一次 AI 用is_test_drive = '是'统计；第二次它自作主张，把"有试驾时长记录"的也算了进去——它替业务方推断了一个口径。

最可怕的不是 AI 查不出来，是查出来了、数字看着完全合理——但没人知道是错的。

一次口径漂移，信任归零。之前十次完美演示，在这一瞬间全部清零。

用大白话说：两种模式差在哪

想象你去一家餐厅。

❌ Text-to-SQL

服务员冲进厨房自由发挥

自己选食材、定做法、放调料。端出来一盘菜——你完全不知道他用了什么。

✅ SMR 模式

给你菜单，你勾选，厨师照食谱做

清蒸鲈鱼就是清蒸鲈鱼的做法。你点的、厨师做的、隔壁桌吃的，口味一模一样。

💡 核心区别

Text-to-SQL 把"理解你想要什么"和"怎么做出来"两件事都交给 AI。

SMR 模式把两件事拆开：AI 只管选菜单（理解意图），后厨管按食谱做（执行查询）。食谱是锁死的，AI 碰不了。

三层架构，把不确定性关进笼子

核心就一句话：AI 只做 NLU（理解你想查什么），指标平台做 SQL（确定性翻译）。

1指标注册中心（Metrics Registry）

整个系统的基石。三层元数据：

物理层表名、字段名、JOIN 路径 —— AI 不可见，锁死

语义层指标名、口径描述、关键词 —— AI 的"菜单"

查询层AI 输出的结构化 JSON（SMR）

2SMR → SQL 编译器

AI 生成结构化 JSON → 编译器走五阶段确定性管道（校验→解析→计划→生成 SQL→执行）。整个过程没有 AI 参与。同样的 SMR，永远生成同样的 SQL。

3双模式智能兜底

DeepSeek API 做 NLU 理解，API 不可达时本地关键词匹配自动回退。API 挂了 ≠ 系统挂了，精度略降但从不断线。

示例一个指标的完整定义

visit_count:   display_name: "进店量"description: "到店客户总批次"keywords: [进店, 客流, 到店]      # AI 做语义匹配用sql_template: "COUNT(*)"# AI 看不到，编译器用

AI 用语义层做匹配。它看不见 SQL 模板、表名、JOIN 路径——这些由编译器确定性地处理。

示例AI 输出的结构化请求（SMR）

{   "metrics":    ["visit_count", "test_drive_rate"],   "dimensions": ["intended_series"],   "filters":    [{"field": "intended_series", "op": "equals", "value": "ES"}],   "time_range": "last_month" }

四层降级链：让能力边界可见

层级	策略	可靠性
Tier 1	命中已验证缓存 → 直接返回	✅ 已验证
Tier 2	命中相似查询模板 → 参数化改写	✅ 模板匹配
Tier 3	编译器实时生成 SQL → 执行	⚠️ 建议核对
Tier 4	超出能力 → 记录为待治理指标	📋 持续进化

传统 Text-to-SQL 只有两个状态：硬答（可能错）或拒绝（不知道为什么）。这四层让"答不了"变成了可度量的治理需求——每次 AI 答不上，都是指标目录的进化方向。

安全兜底：最坏只是查错，不会出事故

✓双模型投票
——两个不同厂商的模型独立生成 SMR，不一致时降级人工确认
✓只读连接 + AST 拦截
——DuckDB 内存模式，物理上不存在写操作
✓自动 LIMIT + 超时 KILL
——明细查询强制 LIMIT 1000，聚合查询超时即停
✓全量审计
——每次查询记录原文、SMR、SQL、耗时，出问题可逐条追溯

容错边界非常清晰：AI 最坏的情况只是选错了指标组合。用户看一眼 SMR 卡片就能发现并纠正。

它不会DROP TABLE，不会泄露敏感字段，不会返回一个"看起来对但口径完全错误"的结果。

商业落地的核心判断

⚡ 关键结论

没有指标平台的 AI 数据助理，永远是空中楼阁。

LangChain + GPT-4 一个下午搭的 Demo，放到 50 个业务用户面前就崩塌。GPT-5 也解决不了，这是结构性缺陷。

如果不用现成产品，至少自研三样：

✓指标注册中心
——存储指标名、口径 SQL、兼容维度矩阵。系统之锚。
✓查询编译器
——结构化请求 → SQL 的确定性引擎。不依赖任何 AI。
✓缓存 + 降级路由器
——SMR 级别结果缓存，四层降级逻辑。

好消息是 MVP 并不复杂。我的 Demo 总共3600 行代码，2 天写完。19 个指标、18 个维度，已覆盖经销商门店 80% 的日常数据查询。

AI 落地最关键的问题不是"AI 能做什么"

而是"AI 不能做什么，我们用什么兜底"

Text-to-SQL 把确定性责任全压在概率模型身上。我的方案多做了一步：NLU 用 AI，SQL 用编译器。每一层做自己擅长的事，每一层的失败模式都是可控的。

📂 Demo 已开源：github.com/Klevinxuan/ai-query-demo

🛠 DeepSeek v4-pro | DuckDB | FastAPI | ECharts