01 · Complete the composite key
找到金额字段后，补齐租户与订单键
中文订单问题初始召回 6 列；路径补全后保留 10 列，覆盖同一查询策略的全部必要列。固定参考查询得到 C1：2 单、10 件、7000 分；C2：1 单、2 件、4000 分。
联合键按完整关系处理，避免仅按订单号关联同号租户数据。
展开候选与查询结果 →Open-source contribution · Reproducible evaluation
Text-to-SQL：
从 Schema 选择到可验证查询
围绕订单统计，验证候选字段能否支撑正确关联、何时需要补齐联合键，以及遇到权限限制和多条关系时如何处理。将设计写入开源工程手册，再用 Python / SQLite 实验验证。
上游 PR 已合并9 个测试输入34 项测试通过2026.09
问题从哪里来
用户问“按客户汇总未发金额”，检索可能找到数量和单价，却漏掉租户、订单关联键，以及日期、状态等必要字段。SQL 生成之前，上下文就已经不完整。
目标：检查检索结果是否覆盖一条有效查询策略需要的表、列和关系，并保留可解释的遗漏原因。
完成了什么
为 awesome-ai-roadmap 补充中英双语 Schema 选择与路径评测说明，PR 经维护者审阅完善后合并。
进一步完成独立评测工具：读取 SQLite Schema、检索候选列、补齐已批准关系，输出 HTML / JSON 对比报告及固定参考查询结果。
工具开发采用 AI 辅助；评测代码作为后续独立实现发布。
四个环节，分别验收
- 权限过滤先排除不可访问的表和列，再计算候选相关性。
- 候选检索用维护过的中英业务别名选列，保留 top-k 预算与评分规则。
- 关联补全沿已批准外键补齐端点与中间表，继续检查权限；多路径返回歧义。
- 独立评测分别衡量策略覆盖、候选数量和参考 SQL 结果，展示每例遗漏。
维护者在合并前进一步明确了扩展时的权限保持、业务语义与关系基数检查，以及多个有效策略分别评分；这些要求也用于后续实现。
实验结果与上下文成本
| 指标 | 仅候选检索 | 检索 + 路径补全 |
|---|---|---|
| 必要列召回，宏平均 | 58.2% | 86.0% |
| 平均候选列数 | 4.8 | 8.4 |
| 完整策略覆盖 | 1 / 5 | 4 / 5 |
| 固定参考 SQL 结果匹配 | 1 / 5 | 4 / 5 |
2026-09-29 运行记录。另有 4 个权限、歧义与断路输入，补全后的处理状态均符合预期。完整数据见 JSON 报告。
这是手工词表、合成数据与固定参考 SQL 上的机制验证。中英订单输入属于同一业务问题；数值用于分析这组用例，不能解释为模型生成 SQL 的准确率或真实业务收益。
三个值得展开的案例
02 · Clarify the relationship
“仓库名称”可能指起始仓，也可能指目的仓
物流表到仓库表存在两条已声明关系。系统返回两条候选路径和歧义状态，等待业务澄清；同样，被禁止的联合键也不会在补全时重新进入上下文。
查看多路径用例 → · 查看权限用例 →03 · Preserve missing intent
只问“未发金额”，仍然缺少业务口径
图补全不能推断用户需要的日期窗口、状态规则和分组方式。该用例保留缺失字段与未执行状态。把 top-k 降到 3 后，完整策略覆盖也降至 1/5，展示初始候选不足对后续阶段的影响。
查看未完整覆盖的用例 →下载后，两条命令复现
仅需 Python 标准库；已在 Python 3.11.9 验证。解压并进入目录，运行：
python3 evaluate.py
python3 -m unittest -v报告生成在 reports/。源码包括 8 张表的合成数据、检索与图扩展逻辑、测试标签、参考 SQL 和 34 项测试；运行不需要 API Key 或数据库服务。