# 1. NL2SQL 评估指标，执行准确率（Execution Accuracy）与精确匹配（Exact Match）的差异，为什么执行准确率更贴近业务 A Exact Match 比 Execution Accuracy 更贴近业务 B 两种指标等价，无差异 C Execution Accuracy 以执行结果是否一致为准，更能反映真实业务能力 ✓ 正确答案 D 执行准确率无法容忍等价写法
# 2. 企业自建 NL2SQL 评估集，从真实查询日志采样、标注标准答案与判定口径（数值等价、语义等价）如何制定 A 从公开数据集直接复制即可 B 应从真实查询日志分层采样，标注标准答案，并制定明确的数值/语义等价判定口径 ✓ 正确答案 C 只需标注问题，无需标注标准 SQL D 判定口径无需统一，标注者各自判断即可
# 3. Bad case 回流，线上 SQL 错误如何分类（Schema 选错、JOIN 错、过滤遗漏、方言错误）并驱动 Schema 描述与示例优化 A 错误无需分类，统一优化即可 B 应把线上错误分类（Schema 选错、JOIN 错、过滤遗漏、方言错误等），并分别驱动 Schema 描述与示例优化 ✓ 正确答案 C 分类只用于统计，不指导优化 D Bad case 无法转成示例供优化
# 4. NL2SQL 的 Agent 化，把“查询意图澄清→Schema 选择→SQL 生成→执行→结果验证→修正”编排为多步 Agent 的价值与成本如何评估 A Agent 化只增加成本，无正确率收益 B Agent 化比单步生成更简单易实现 C Agent 化通过多步编排提升复杂场景正确率，但需权衡延迟与成本，可对简单查询保留单步路径 ✓ 正确答案 D Agent 化无需评估正确率与成本
# 5. BI/数据分析场景落地，NL2SQL 与指标平台（指标口径、维度字典）如何结合，避免“口径打架” A NL2SQL 应忽略指标平台，自行从明细表计算 B 应把指标平台的口径与维度字典注入 NL2SQL，以平台口径为权威，避免口径打架 ✓ 正确答案 C 指标口径无需统一，各自计算即可 D 口径打架只会影响展示，不影响数据
# 6. Text2SQL 与可视化，SQL 结果如何驱动图表生成（图表类型选择、指标与维度映射），自动图表误选如何校验 A 图表类型由用户随意指定，无需推断 B 应根据结果集的维度/度量/时间特征选择图表类型，并校验自动选图是否合理 ✓ 正确答案 C 指标与维度的映射对图表无影响 D 自动选图无需校验，一定正确
# 7. 生成 SQL 的单元测试，如何用参数化用例（表结构固定）验证模型对不同查询模式的正确率，回归如何自动化 A 单元测试只需覆盖一种查询模式 B 参数化与查询模式无关 C 回归只能手工执行，无法自动化 D 在固定表结构上用参数化用例覆盖各查询模式，并在 CI 中自动回归、正确率退化即拦截 ✓ 正确答案
# 8. 模型选择，通用旗舰、代码模型与专用 SQL 模型（如 SQLCoder、DB-GPT 方案）在正确率、延迟与成本上如何用自有评估集对比 A 直接选最贵的通用旗舰一定最优 B 专用 SQL 模型在所有场景都优于通用模型 C 应在自有评估集上对比正确率、延迟与成本，并依据业务优先级综合权衡 ✓ 正确答案 D 正确率与成本无关，只看正确率即可
# 9. 查询澄清与兜底，用户问题模糊（如“销售情况”）时如何主动追问 vs 使用默认口径兜底，产品的交互设计如何取舍 A 应根据问题置信度在"主动追问"与"默认口径兜底并提示可调"之间取舍 ✓ 正确答案 B 必须无条件追问，不能兜底 C 默认兜底无需提示口径，直接给结果 D 模糊问题应直接拒绝回答
# 10. 慢查询治理，生成的 SQL 是否走索引、是否全表扫描，如何通过执行计划检查与规则提示优化生成 A 慢查询只能靠事后优化，无法前置识别 B 用 EXPLAIN 评估是否走索引/全表扫描，并通过索引提示与规则改写优化生成 ✓ 正确答案 C 全表扫描不影响性能，无需处理 D 索引字段与 SQL 效率无关
# 11. NL2SQL 与语音/IM 场景集成，口语化问题（如“这月还剩多少预算”）的转写纠错与指代消解如何接入 A 口语化问题可直接接入，无需处理省略与指代 B 口语场景无需复用对话上下文 C 语音转写错误不影响理解 D 应先做转写纠错与指代消解，把口语归一化为规范查询描述再进入 NL2SQL ✓ 正确答案
# 12. 评估标注的一致性治理，多人标注 SQL 标准答案时如何定义"语义等价"判定规则、控制标注者间一致性（如 Cohen’s Kappa），不一致样本如何仲裁？ A 无需定义判定规则，标注者各自判断即可 B 应定义语义等价规则、用 Kappa 度量一致性，并对不一致样本由专家仲裁并更新规则 ✓ 正确答案 C 标注不一致时保留多个答案即可，无需仲裁 D Kappa 只用于统计，不用于控制质量
# 13. NL2SQL 的线上效果度量，上线后如何用采纳率、用户改错率与执行成功率持续度量，与离线评测的差距如何弥合？ A 只需看离线评测结果，无需关注线上 B 线上一旦上线就无需再度量 C 用采纳率、改错率、执行成功率等线上指标度量，并把线上样本回流评估集以弥合离线差距 ✓ 正确答案 D 用户改错率与生成质量无关
# 14. 查询意图分类与路由，如何先用分类器把问题分为"可直接查询/需澄清/超出范围"，再决定走 NL2SQL、RAG 还是拒答，减少无效生成？ A 所有问题都应直接走 NL2SQL，无需分类 B 先用分类器区分可直接查询/需澄清/超出范围，再决定走 NL2SQL、追问或拒答，减少无效生成 ✓ 正确答案 C 分类与路由只影响性能，不影响正确性 D 超出范围的问题也应生成 SQL
# 15. Schema 描述的自适应优化，如何从失败案例中自动发现"描述缺失或误导"的字段（注释为空、口径含糊），并驱动描述维护流程？ A 应从失败案例中统计高频出错字段，检测注释缺失或口径含糊，并驱动描述修复与回归验证 ✓ 正确答案 B 描述质量靠人工逐个检查即可，无需自动化 C 失败案例与描述优化无关 D 注释为空不影响生成正确率
# 16. 多轮追问的数据权限校验，每轮生成的 SQL 是否都要重新校验权限与租户隔离，状态如何跨轮保持 A 首轮通过后，后续轮次无需再校验权限 B 状态保持就可以代替权限校验 C 每轮 SQL 都需重新校验权限与租户隔离，查询状态可跨轮保持但权限必须每轮重验 ✓ 正确答案 D 租户隔离只需在首轮做一次
# 17. NL2SQL 的灰度发布，Schema 描述、示例集或模型版本变更时，如何用影子查询与离线回归做安全放量 A 变更可一次性全量上线，无需验证 B 灰度放量只适用于模型版本，不适用于 Schema 描述 C 影子查询会影响真实用户，不宜使用 D 应先做离线回归，再用影子查询在真实流量下验证，最后逐步放量并监控、异常回滚 ✓ 正确答案
# 18. NL2SQL 结果的“防幻觉”，模型对数据中不存在的部分（如“上季度环比”但库里无环比字段）应如何识别并拒答，而不是编造 A 模型应尽量编造缺失的指标以满足用户 B 应基于已声明的字段/指标生成，对无法计算的查询明确拒答，并用字段存在性校验兜底 ✓ 正确答案 C 库中不存在环比字段时，模型应自行推算 D 防幻觉只影响展示，不影响正确性
# 19. NL2SQL 的成本控制，Schema 注入与示例检索的 Token 成本、执行失败重试的额外成本应如何核算与优化 A 成本只与模型单价有关，与 Schema 和重试无关 B 裁剪 Schema 会必然破坏正确率，不应优化 C 重试次数越多越好，无需考虑成本 D 应核算 Schema 注入、示例检索与重试的 Token 成本，并通过裁剪 Schema、精选示例、降低重试率优化 ✓ 正确答案
