高德 NL2SQL 知识工程：确定性路由 + 6 节知识卡片 + 352 表生产实践¶
Ch01.804 高德 NL2SQL 知识工程：确定性路由 + 6 节知识卡片 + 352 表生产实践¶
📊 Level ⭐⭐ | 7.9KB |
entities/amap-nl2sql-knowledge-engineering-production.md
高德 NL2SQL 知识工程：确定性路由 + 6 节知识卡片 + 352 表生产实践¶
高德（Amap）基于 QoderWork Agent Skill 构建的生产级 NL2SQL 智能取数系统。覆盖 9 个业务域、352 张 ODPS 表、30,000 行结构化知识文档。NL2SQL 准确率 >95%，取数效率提升 30 倍以上。
架构演进：V1 → V2¶
V1：分域独立 Skill（瓶颈暴露）¶
按数仓业务域拆分为 9 个独立 QoderWork Skill（8 取数 + 1 工具）。快速验证了 LLM 可行性，但暴露出 5 个结构性问题：用户选择成本高、路由天花板低、表扩充加剧域冲突、维护成本指数膨胀、扩展不便。
根因：路由决策发生在控制范围之外，无法调试也无法增强。
V2：统一 Skill + 确定性两级路由¶
核心决策：不是合并 9 个 SKILL.md，而是在一个统一 Skill 内部建立 4 层分层架构。
| 层 | 载体 | 职责 |
|---|---|---|
| L1 域路由层 | SKILL.md 内置 | 从用户问题提取意图，查确定性域路由表（~200 行），歧义时主动澄清 |
| L2 知识加载层 | references/ 目录 | 路由后只读取该域文件；9 域 30,000 行 → 单次 200-400 行 |
| L3 标准工作流层 | SKILL.md 内置 | 6 步标准流程统一所有域：前置检查→域路由→知识加载→口径确认→选表+SQL 生成→执行+结果解读 |
| L4 公共服务层 | references/common/ | 日期计算、SQL 安全约束等公共逻辑只维护一份 |
关键设计决策：确定性路由而非 RAG¶
选择规则路由而非向量检索的三个理由：
- 业务术语语义重叠（如"收入""供给"在不同域中 embedding 几乎一样但口径不同）
- 352 表按域分组后可枚举（9 个域，每域 3-96 张，有限分类问题可用规则穷举）
- 可调试可追溯（每次路由能回答"为什么选了这个域/表"）
两级路由¶
- 一级路由（SKILL.md ~200 行）：基于意图判断的域路由 + 易混淆术语消歧规则 + 主动澄清机制
- 二级路由（DOMAIN.md ~100 行/域）：域内按 ADS > DWS > DWD 优先级链选表
知识工程方法论¶
6 节知识卡片（每张表一个 Markdown）¶
352 张表各有 50-130 行的 6 节标准化 Markdown 文档（"知识卡片"）：
- S1 表元数据：全表名、数仓层级、粒度、分区、更新频率
- S2 字段列表：KEY/DIM/IDX 前缀标注 + 中文释义
- S3 场景映射：适用/不适用什么问题
- S4 关联方式：JOIN 维度表和关联键
- S5 指标口径定义：最关键的，计算公式和口径说明，口径来自知识库不由模型编造
- S6 SQL 模板：高频查询参考 SQL
元数据产出 Pipeline¶
自动化（技术元数据拉取）→ 半自动（LLM 初版 60%）→ 人工（BI 同学注入业务口径）→ 自动校验（字段覆盖率、6 节完整性）
AI-Friendly 标准分¶
知识质量评分体系：字段覆盖率、口径完整度、SQL 模板覆盖率、场景标注率、路由规则完备度。驱动评测→定位→补强→再评测的迭代循环。
质量保障体系¶
- 900+ 测试题自动化回归：错误归因分类（选表/语法/口径/语义）
- DDL 一致性监控（cici_monitoring）：检测表结构与知识文档的漂移
- 用户反馈闭环：纠正信号 + 重复提问 + 放弃对话三个沉默信号自动检测，问题解决率 >70%
设计原则¶
五条核心原则：
- 确定性优于模糊性 — 路由/选表/关键约束走规则而非概率
- 按需加载优于全量灌入 — 200 行路由表换 200-400 行按需加载
- 知识分层对齐变更频率 — 静态层/规则层/公共层
- 标准化优于自由发挥 — 统一 6 节文档、6 步工作流
- 评测驱动优于经验判断 — 标准分 + 回归测试
落地成效¶
- NL2SQL 准确率 >95%
- 智能问数场景覆盖率 >90%
- 手动取数（~8h）→ 分钟级，效率提升 30 倍以上
- 同一架构可低成本复制到不同业务方向
与已有实体的关系¶
- Alibaba Data Rd Harness Engineering Nl2Sql — 阿里数据研发 NL2SQL 的宏观 Harness Engineering 方法论（7 Agent + NL2DSL2SQL + 幻觉防控）。本文聚焦高德具体生产系统的架构设计和知识工程方法论，角度互补。
补充维度：SMQ 中间表示与确定性编译路线（2026-07-31）¶
2026-06-30 提交的 arXiv 预印本（QUVI-3 + Gemini 3 Pro Preview）提出与知识卡片路由不同的第三条路线：在大模型与数据库之间加入受治理的 Semantic Layer，并以 Semantic Model Query（SMQ） 作为业务意图与物理 SQL 之间的中间表示。
SMQ 三要素与确定性编译¶
SMQ 由 metrics / filters / group_by 三类元素组成，表达"计算什么、筛选什么、按什么维度分组"，而不是最终物理 SQL。确定性的 SMQ-to-SQL 引擎解析元素背后的字段表达式，从预先维护的 Join Graph 注入连接条件，生成目标方言 SQL。抽象业务名称与物理实现（真实表名、字段名、计算表达式）被明确分开。
与高德路线的对比¶
| 维度 | 高德知识卡片路线 | SMQ 语义层编译路线 |
|---|---|---|
| 知识载体 | 6 节 Markdown 知识卡片 + 确定性路由 | Semantic Model（Dimension/Measure/Metric）+ Join Graph |
| SQL 生成者 | LLM 在规则约束下生成 | 确定性编译器从 SMQ 编译 |
| 模型职责 | 选域、选表、写 SQL | 生成紧凑 SMQ + 长尾 SQL 组合 |
| Schema Grounding | 知识加载进上下文 | 强制经过语义层，禁止查 INFORMATION_SCHEMA |
两条路线的共同点是把易错环节（口径、Join、方言）从纯概率生成中剥离；差异在于高德把知识"喂给"模型让模型更准，SMQ 路线把知识"编译进"确定性系统让模型更少犯错。
评测与局限¶
Spider2-snow 547 项任务完成 515 项（94.15%），但该成绩是"强推理模型 + 受约束 Agent 循环 + 手工语义层 + 确定性编译器"整体能力，且无移除 Semantic Layer 的控制实验。论文未披露 Token 消耗、轮数、延迟与语义层建设人力。SMQ 只覆盖常见分析核心，长尾结构（子查询、窗口函数、递归 CTE）仍需 Agent 完成。
未解决问题¶
- 取数 Skill 与分析 Skill 之间的跨 Skill 知识共享
- 知识库从树形目录到图状结构的平台化管理（过时检测 + 冲突发现）
- 端到端 Agent 评测体系（不只看 SQL 准确率）
→ 原文存档
关联¶
- 相关概念: Harness Engineering