01｜为什么 AI 问数“不可信”
为什么 AI 问数“不可信”
Section titled “为什么 AI 问数“不可信””1. 一个通俗类比
Section titled “1. 一个通俗类比”把自然语言问数想成一次跨语言出版：
- 用户给出中文需求，相当于“作者意图”；
- LLM 是译者，负责把意图转换成机器能处理的结构；
- SQL 是最终印刷稿；
- 数据库是印刷机，收到什么就执行什么。
直接让 LLM 写 SQL，相当于让译者同时负责理解、排版、审稿和开机印刷。一处口径误解或标点错误，都可能得到“语法合法但业务错误”的结果。Forge 在中间增加术语表、结构化稿件、编译器、审稿和留档。
2. 六类不可信
Section titled “2. 六类不可信”| 层次 | 典型问题 | Forge 的处理 |
|---|---|---|
| 口径 | “销售额”“活跃用户”“复购率”到底怎么算？ | Registry 记录组织定义，必要时先澄清。 |
| 生成 | JOIN 类型、窗口、HAVING、NULL 语义写错。 | 受约束 DSL、校验、编译器和 lint。 |
| 执行 | AI 生成的 SQL 是否会直接跑？会不会拖垮库？ | 人工审核、只读校验、超时、行数上限。 |
| 追溯 | 为什么错、谁确认、下次如何避免？ | Audit、EMS、feedback、staging 和测试回放。 |
| 兼容 | “支持 PostgreSQL”是能编译还是已在生产执行？ | 分层证据矩阵，不把编译支持等同生产支持。 |
| 算法 | 模型根本不知道需要日期序列、自关联或统计方法。 | 明确能力边界；DSL 不会凭空补足推理。 |
3. 三类逻辑错误
Section titled “3. 三类逻辑错误”3.1 生成错误
Section titled “3.1 生成错误”模型知道意图，但把它翻译错了，例如：
- 本应
LEFT JOIN却用了INNER JOIN； - 用
NOT IN排除数据，却忽略子查询中的NULL； - 将
COUNT(*) > 5放进WHERE； - 忘记窗口函数的
OVER。
这是 DSL、Schema、Compiler 和 Lint 的主要靶心。
3.2 业务逻辑错误
Section titled “3.2 业务逻辑错误”模型无法从参数中知道一家公司的私有定义。例如复购率分母可能是注册用户、下单用户或付费用户。模型再强，也不能凭空知道会议里确认过的口径。这是 Registry 的主要靶心。
3.3 算法逻辑错误
Section titled “3.3 算法逻辑错误”如果问题要求生成缺失月份、做复杂同比、统计建模或多层自关联，模型首先要知道正确算法。DSL 可以确保“表达出来的意图被稳定编译”，却不能保证模型选择了正确算法。
4. Forge 的目标函数
Section titled “4. Forge 的目标函数”Forge 不追求：
对任意陌生数据库、任意问题、任意模型都自动给出 100% 正确答案。
Forge 追求：
在明确支持的查询范围内，把组织语义、生成约束、执行控制和证据回放做成工程闭环。
这也是“已知边界内的确定性，优于未知范围内的概率性”的含义。
5. 为什么强模型也不能消除全部问题
Section titled “5. 为什么强模型也不能消除全部问题”强模型会减少语法和常见 SQL 模式错误，因此 DSL 相对裸 SQL 的增益可能收窄。但以下事实不会因为模型升级而消失：
- 企业私有口径不在模型参数里；
- 数据权限和数据库资源必须由系统控制；
- 审核者需要知道最终执行了什么；
- 线上错误需要追溯、复现并沉淀为规则或测试。
因此 Forge 的长期价值不只在“约束 SQL 语法”，更在 Registry、可信执行和证据链。
6. 本章检查题
Section titled “6. 本章检查题”- “复购率分母理解错误”属于哪一类？为什么编译器不能解决？
- 一条 SQL 能成功执行，是否代表业务结果正确？
- 为什么“应用层判定只读”不能替代数据库只读账号？
参考答案：依次是业务逻辑错误；不能，语法正确不等于口径正确；应用层规则可能有遗漏，数据库权限才是最终强制边界。