设计给老板的「用嘴查数」系统（NL2SQL），准确率不够怎么兜底？

把表结构和字段注释喂给模型，让它生成 SQL，执行后把结果返回，同时展示生成的 SQL 供核对。schema 太大就先做一次表检索，只把相关的表喂进去。准备一批 few-shot 示例提高准确率。加只读权限和超时限制，防止跑挂库。准确率不够的话可以让用户确认 SQL 再执行。

技术要素基本齐了，及格。问题在最后一句：「让用户确认 SQL」对老板这个用户是无效的——他不会看 SQL。整个方案的兜底建立在一个不存在的能力上。

① 先问四个问题：谁用——分析师（能看懂 SQL、能自己验证）还是业务负责人（不能）？这决定了兜底方式完全不同。数据量级和 schema 稳定性——几十张表还是几千张？有没有指标口径的统一定义——「活跃用户」在公司里有几个版本？错了的后果——是满足好奇心，还是要拿去开会做决策？

假设：用户是不看 SQL 的业务负责人、几百张表、口径散落在各个报表里、结果会被拿去做决策。

② 基线：先不做 NL2SQL。 把最常问的二三十个问题做成参数化模板（下拉选时间、区域、产品线），覆盖八成需求。这套东西准确率是 100%，因为 SQL 是人写好的。先摆基线，是为了把问题限定成「剩下那两成长尾值不值得用 NL2SQL 换正确性风险」——很多团队跳过这一步，最后发现自由问答里九成的问题其实就是那二三十个。

③ 加挂，每样说代价：

• 语义层（这是全场最值钱的一层，也是最多人漏掉的）。在物理表之上定义指标、维度和口径：「复购率」是什么公式、分母是谁、剔不剔退款、按下单时间还是支付时间。模型面对的是语义层而不是裸表。解决什么：把「SQL 写对了但口径用错了」这类最高发的错误从根上消掉。代价：语义层要人来定义和维护，且要和数据团队达成一致——这是组织工作不是技术工作，也是这个项目真正的工期所在。什么时候不该用：探索性分析场景，语义层反而会限制自由度。

• schema 裁剪与检索：几百张表不能全塞。做法是先按表和字段的语义做一次检索，只把候选表的 DDL 与样例值喂进去。代价：检索错了表就全错，且这类错误很隐蔽；配套：把最终用到的表显式展示给用户，并对「本次用到了一张很少被使用的表」做提示。

• 执行前的确定性校验：SQL 静态检查（只读、无笛卡尔积、有时间过滤）、行数与代价预估、超时与结果行数上限。代价：会拦掉一些合法的复杂查询；收益：防止跑挂生产库，这条没有商量余地。

• 兜底四件套（本题核心，针对「用户无法验证」这个前提设计）：

  ① 口径回译   用自然语言复述这次的计算口径：「复购率 = 30 天内二次支付用户 / 首购用户，
                已剔除退款，按支付时间」——让不看 SQL 的人也能核对口径
  ② 数据说明   展示数据更新时间、数据源表、以及本次结果的样本量
  ③ 异常提示   与历史同期做比较，偏离超过阈值时明确标注「该结果与上月差异较大，建议核对」
  ④ 置信降级   检索到的表把握不足、或问题含未定义指标时，不给数，给模板或转人工
  

  这四件套解决的都是同一件事：把静默错误变成有声错误。 其中口径回译最重要——它把验证任务从「看懂 SQL」降级成「确认一句中文」，而后者老板是能做的。

④ 评测：分两个指标，不能合并成一个「准确率」。

• 执行正确率：SQL 能跑且结果与标准答案一致。
• 口径正确率：即使结果数值对了，用的表和口径是否正确——这两个在 NL2SQL 里经常分离，一个查错了表但恰好数值接近的查询，前者算对、后者算错，而后者才是真风险。
• 评测集用黄金查询集：真实问题 + 人工写的标准 SQL + 标准结果，按问题类型分层（单表聚合 / 多表关联 / 时间窗口 / 嵌套与占比）。难度分层很重要——总准确率 85% 可能意味着单表 98%、多表关联 40%，而后者恰恰是高价值查询。
• 零成本信号：用户重问率、导出后手工改数的比例、以及结果被采纳率。
• 统计关照旧：黄金集通常只有一两百条，几个点的波动说明不了问题。

⑤ 演进：某类问题的口径正确率长期稳定 → 才把它从「需确认」放到「直接出数」；出现「用户反复问同一类问题」→ 沉淀成模板（这是最重要的一条：NL2SQL 的产出之一是发现该被固化的查询）；出现「口径争议频繁」→ 该做的是治理语义层，不是调模型。退路：任何一次错数被用于决策，立刻把对应问题类型退回模板或人工。