# 1. Text2SQL 的核心链路，用户问题→Schema 选择→SQL 生成→执行→结果解释，各环节的失败模式应如何定位与归因 A 通过在各环节保留中间产物并分段校验，可以把失败精确定位到具体环节 ✓ 正确答案 B 结果错误一定来自 SQL 生成环节，与 Schema 选择无关 C 执行环节失败与 Schema 选择无关，只需检查 SQL 语法 D 结果解释环节永远正确，因为数据来自真实数据库
# 2. Schema Linking（表/字段选择）为什么是 Text2SQL 最大的误差来源，多表、宽表与同名字段场景应如何做 Schema 裁剪与消歧 A Schema Linking 误差只影响执行速度，不影响结果正确性 B Schema Linking 错误会传导到下游，是 Text2SQL 最大误差来源 ✓ 正确答案 C 同名字段只需靠字段名区分，无需借助注释与表主题 D 宽表场景应使用全部字段以避免漏选
# 3. 如何把数据库元数据（表注释、字段注释、枚举值、索引、外键关系）组织成模型可用的 Schema 描述，注释质量如何直接影响生成正确率 A 注释质量与 SQL 生成正确率无关，模型只依赖字段名 B Schema 描述只需包含表名，字段信息可省略以省 Token C 表注释、字段注释、枚举值与外键关系都应组织进 Schema 描述 ✓ 正确答案 D 枚举值无需注入，模型会自行猜测取值含义
# 4. 多表 JOIN 的生成，如何表达表间关系（外键、多对多、星型/雪花模型），避免模型臆造不存在的连接条件 A 外键与关联路径应显式注入，并只允许模型从已声明的关系中选择 ✓ 正确答案 B 应让模型自由猜测连接字段以获得更灵活的结果 C 多对多关系无需中间表，可直接连接 D 星型模型中的维度表与事实表无需外键关系
# 5. 业务术语与字段名的映射（如“下单”对应 status 字段）应如何建立术语表并注入 Prompt，跨部门口径不一致如何处理 A 术语与字段映射靠模型每次猜测即可，无需维护 B 跨部门口径不一致时，模型应自行随意选择一种口径 C 术语表只需记录字段名，无需记录计算逻辑 D 术语表应绑定术语到具体表、字段与计算口径，并注入 Prompt ✓ 正确答案
# 6. SQL 方言（MySQL、PostgreSQL、ClickHouse、Doris 等）与函数差异如何影响生成，同一语义在不同方言下应如何适配与回归 A 所有方言语法一致，无需区分 B 函数差异不影响 SQL 正确性 C 方言只用一种即可，模型会自动适配 D 应把目标方言显式注入 Prompt，并为每个方言维护语法说明与回归用例 ✓ 正确答案
# 7. Few-shot 示例的选择，如何用“问题-表结构-SQL”三元组做示例检索，示例与当前查询的相似度如何度量 A 示例应固定不变，与当前查询无关 B 用"问题-表结构-SQL"三元组动态检索，从文本、表结构与 SQL 结构多维度度量相似度 ✓ 正确答案 C 只按问题文本长度选择示例即可 D 示例越多越好，无需考虑相关性
# 8. 复杂查询（聚合、子查询、窗口函数、时间区间、排序分页）的分解策略，先定维度、度量与过滤条件再生成 SQL，相比直接生成的正确率差异如何评估 A 直接生成 SQL 在复杂查询上一定比分解策略更准确 B 复杂查询无需考虑分组与窗口函数 C 分解策略只增加延迟，无任何正确率收益 D 应先抽取维度、度量、过滤条件形成中间规格，再基于它生成 SQL，并通过分层 A/B 评估差异 ✓ 正确答案
# 9. NL2SQL 与 RAG 的结合，表结构描述、术语表和相似示例作为“检索增强”输入时，检索质量如何影响 SQL 正确率 A 检索增强与 SQL 正确率无关，只是节省 Token B 检索结果越泛越好，可以提高召回率 C 检索到错误表结构不会影响结果 D RAG 将表结构、术语表与相似示例作为输入，检索质量直接决定 SQL 正确率 ✓ 正确答案
# 10. 数据库表规模很大（数百张表）时，如何分层（库→Schema→表→字段）缩小候选集，裁剪策略与召回率的权衡如何设计 A 分层裁剪（库→Schema→表→字段）逐层缩小候选集，并权衡召回率与精度 ✓ 正确答案 B 数百张表应全部注入上下文以保证不漏 C 裁剪越狠召回率越高 D 表规模大时无需考虑 Schema 选择
# 11. 生成 SQL 前先输出查询意图（维度、度量、过滤、排序）再生成 SQL 的“思维链”方式，中间步骤的可审计性与纠错价值是什么 A 意图输出提供了可审计与可纠错的中间产物，便于定位理解错误还是 SQL 错误 ✓ 正确答案 B 中间步骤无价值，只会增加 Token C 意图只用于展示，不参与后续生成 D 思维链方式无法区分理解错误与 SQL 错误
# 12. 多轮对话中的指代消解（“再按月份分组”“换成本周数据”）如何结合前序 SQL 与查询状态生成增量 SQL A 多轮问题无需上下文，每轮独立生成即可 B "本周"这类词只需按字面解析，无需结合上下文 C 应结合前序 SQL 与查询状态生成增量 SQL，并维护当前查询状态 ✓ 正确答案 D 前序 SQL 不应再使用，每轮完全重写
# 13. NL2SQL 的 Prompt 版本管理与评估基线，Schema 描述、示例集与模型版本如何绑定，回归门禁如何设计 A Schema 描述、示例集与模型版本应独立管理，互不绑定 B 应把 Schema 描述、示例集、Prompt 模板与模型版本组成不可变快照，并用回归门禁验证正确率不退化 ✓ 正确答案 C 模型升级无需回归测试，直接上线即可 D 回归门禁只检查语法，不检查正确率
# 14. NL2SQL 的评测指标，Execution Accuracy 与 Exact Match 的差异，为什么业界更关注执行正确率，企业评估集如何按查询复杂度分层？ A Execution Accuracy 以执行结果比对为准，更贴近业务价值，应成为主要指标 ✓ 正确答案 B Exact Match 允许等价写法，比 Execution Accuracy 更合理 C 执行正确率与 SQL 写法无关，无法反映真实能力 D 评估集无需分层，只看整体平均正确率
# 15. Schema 变更对 NL2SQL 的影响，表结构变更后 Schema 描述、示例与缓存的失效管理，如何自动检测并触发回归？ A 表结构变更不会影响已注入的 Schema 描述 B Schema 变更后缓存结果仍然有效，无需失效 C 应自动检测 Schema 变更，更新描述与示例并使相关缓存失效，再触发回归 ✓ 正确答案 D 变更检测可有可无，靠人工发现即可
# 16. 生成 SQL 的执行安全，只读控制、行数/时间限制与敏感列过滤如何在执行层强制，防止 Text2SQL 成为数据泄露入口？ A 只读与脱敏靠模型自觉遵守即可 B 敏感列过滤由用户自行决定是否开启 C 生成 SQL 可以直接执行，无需限制返回行数 D 应在执行层用只读账号、语句拦截、行数/时间限制与敏感列过滤强制约束 ✓ 正确答案
# 17. 错误 SQL 的自纠错，生成结果语法错误或执行失败时，如何用错误信息驱动重写（retry with error），重试上限与成本如何控制？ A 应无限重试直到成功为止 B 错误信息可直接原样回喂，无需净化 C 执行失败即放弃，不做任何重试 D 用错误信息驱动重写，并设置重试上限与成本预算，区分可修复与不可修复错误 ✓ 正确答案
# 18. Text2SQL 公开数据集（Spider、BIRD）与企业真实查询的分布差异在哪里，如何迁移到自建评估集 A 公开数据集与真实查询分布差异大，应以从真实日志采样构建的自建评估集为准 ✓ 正确答案 B 公开数据集足够代表企业真实查询，可直接作为上线依据 C 企业查询比公开数据集更简单，无需特殊评估 D 公开数据集不含任何业务术语，适合直接使用
# 19. NL2SQL 与 SQL 助手的边界，何时用“自然语言→SQL 编辑器预填”（人确认后执行）而非全自动执行，产品交互与安全如何取舍 A 所有场景都应全自动执行以提升效率 B 预填模式没有保留任何 NL2SQL 的价值 C 高风险或复杂查询宜采用"预填 SQL 供人确认后执行"，简单低风险可全自动 ✓ 正确答案 D 安全与效率不可兼得，只能二选一
# 20. 脏数据与口径不一致，枚举值漂移、空值比例高与时区口径差异如何影响 SQL 正确性，数据质量检查如何前置？ A 枚举漂移、高空值比例与时区差异会导致结果错误，应通过注入准确元数据并前置数据质量检查来应对 ✓ 正确答案 B 枚举值漂移与空值比例不影响 SQL 结果 C 时区差异只影响显示，不影响 SQL 正确性 D 数据质量检查只会增加成本，无助于正确性
