查询管线与治理关卡
KnowFlow 智能问数没有让 LLM 直接输出最终 SQL。
自然语言问题
→ Mapper：说法映射到已发布业务名
→ Parser：生成只包含业务名的 S2SQL
→ Corrector：校验成员、过滤、聚合和确认义务
→ Translator：绑定冻结路径，编译参数化物理 SQL
→ Guard：只读 AST 白名单、结果上限和执行超时
→ 数据库
LLM 擅长理解「用户想问什么」，但指标公式、聚合方式、事实粒度和 Join 路径不应该每次都由它重新猜。
五个阶段
1. Mapper
把自然语言里的说法映射到已发布的业务名。依赖业务词典、别名与语义索引。
2. Parser
生成只包含业务名的 S2SQL。这一步的输出里没有物理表名、物理列名和 Join 语句。
3. Corrector
检查成员、过滤、聚合和人工确认是否完整。判据包括：
- 引用的名称是否都已发布
- 已确认的过滤值是否仍在
- 聚合写法是否与治理聚合一致
- 人工在澄清卡上的选择是否真的被用上
- 是否存在经常量折叠归约为 FALSE 的
WHERE/HAVING
4. Translator
根据冻结的语义模型绑定物理字段与安全 Join 路径，编译参数化 SQL。
作用域是生成后确定性反推的：编译器逐个真实作用域尝试翻译，恰好一个成功即绑定；零个说明问题跨了事实根；多个则按粒度收敛取最粗的那个。
模型提议、编译器裁定——校验比选择容易，而翻译本身已经在验证成员归属、冻结路径可达性和全部治理规则。
5. Guard
访问数据库前的最后一道关：
- 只读 AST 白名单
- 结果行数上限
- 执行超时
- 只读事务
Fail closed
如果成员、路径或版本无法被证明安全，系统会拒绝执行或请求澄清，而不是带着不确定性继续查库。
这与「SQL 语法合法就执行」是完全不同的失败策略。
支持的查询形态
| 形态 | 说明 |
|---|---|
| 聚合查询 | 带 GROUP BY 的语句一律判为聚合查询 |
| 明细查询 | 无聚合的行级查询 |
| Set operations | 集合运算 |
| 同比 / 环比 | 期间比，按带符号增长率展示 |
| 滚动比率 | 滚动窗口计算 |
| 组内占比 | 窗口占比 |
| 每组取前 N | 分组 Top-N |
更换模型不改变口径
把规则交给确定性编译器后：
- 更换 Chat 模型不会顺带改变业务口径
- Agent 不需要了解物理表名和字段名
- 同一份 Release 服务所有入口，口径一致