本文是「企业问数系统落地」系列第十篇。前九篇讲的是怎么把系统做对（架构、接入、建模、生成、多轮），这一篇讲一个更容易被跳过、但决定项目成败的问题：怎么证明它做对了。
一、先说一个残酷的事实："准确率 90%" 是个无意义的数字
几乎每次方案评审都会被问同一个问题：
"你们这个问数，准确率能到多少？"
如果我回答"90%"，这个回答在工程上是不可证伪的——因为没人知道：
- 这 90% 是在什么题目上测出来的？谁出的题？有没有偏袒？
- 剩下 10% 错在哪里？是算错了，还是口径理解不同，还是干脆没查出来？
- 今天 90%，明天改了一条口径规则，还是 90% 吗？
- 业务问的"上个月收缴率多少"和评测集里那道"2026 年 8 月收缴率"是同一道题吗？
所以真正专业的回答不是给一个数字，而是给出一套指标体系 + 一套可复现的评测方法。这篇文章就是把这件事情讲清楚：评测集怎么建、指标怎么定义、回归怎么做、线上怎么持续观测。
下面所有内容分两层：一层是平台自带的能力（质量门禁、留痕审计等），一层是需要实施方和客户一起建起来的方法论。我会在每一节明确标注，避免把"建议这么做"讲成"产品已内建"。
二、四层指标：把"准不准"拆成可度量的四个问题
"准确率"之所以没有信息量，是因为它把四件不同的事压成了一个数。工程上应该拆开度量：
| 指标 | 定义 | 回答什么问题 | 谁来兜底 |
|---|---|---|---|
| 可执行率 | 生成的查询能成功执行的比例 | 模型会不会写"跑不通"的代码 | 查询网关 + 语义层 |
| 语义命中率 | 执行成功且查对了对象/维度/过滤条件的比例 | 问的是空置，有没有去查合同 | 语义层建模 |
| 口径一致率 | 结果与业务确认过的口径数值一致的比例 | 收缴率的分子分母对不对 | 口径注册 + 规则 |
| 首答可用率 | 首轮答案无需追问修正即可直接使用的比例 | 用户要不要反复问才拿到要的东西 | 建模 + 样例库 |
再加两个体验类指标（不衡量对错，但决定系统会不会被用起来）：
- 追问收敛轮次：从提问到拿到可用答案平均需要几轮（越少越好，但它和"敢不敢追问"存在权衡）
- 端到端延迟：从提交问题到答案渲染完成的分位值（P50/P95），单位为秒级/分钟级
为什么必须分层？因为四层的修复手段完全不同：
- 可执行率低 → 问题在网关和字段类型对齐，看执行错误日志就能定位
- 语义命中率低 → 问题在建模，是对象和字段没注册清楚
- 口径一致率低 → 问题在口径，必须回到业务确认，不是技术能单方面解决的
- 首答可用率低 → 问题在问法覆盖，靠样例库和规则补充
只报一个"准确率"，等于把四种病当成一种治。
三、评测集怎么建：这是整个体系里最不能省的一步
指标体系是骨架，评测集是血肉。没有评测集，前面那四个指标一个都算不出来。
3.1 分层抽样，而不是"挑几道好答的题"
一个像样的评测集应该覆盖三个维度的组合：
| 维度 | 取值示例 | 为什么要覆盖 |
|---|---|---|
| 业务对象 | 房源 / 合同 / 账单 / 收缴 / 租户 | 防止只测了最熟的那一类 |
| 问法类型 | 单指标 / 多指标对比 / 分组排名 / 趋势 / 占比 / 明细下钻 | 不同问法难度差异巨大 |
| 难度 | 直问 / 同义改述 / 省略指代 / 需要澄清 | 真实用户不会按建模字段名提问 |
建议规模：POC 阶段 30–50 题（够看出方向），上线阶段 80–150 题（够做回归），之后按每次新增场景追加。
3.2 标准答案从哪来
这是最费人力、也最不能偷懒的部分。标准答案的唯一来源是业务确认的口径 + 人工核对过的结果，不是"模型答的看起来对"。
推荐流程：
- 业务出题并给出预期口径描述（不是数字，是定义：分子是什么、分母是什么、时间按哪个字段算）
- 实施方按该口径在数据库里手工或独立 SQL 跑出基准值
- 双方确认后，把「问题原文 + 口径描述 + 基准值 + 校验方式」一起入库
一条经验：评测集条目和 FewShot 样例库条目同源但不同用。样例库是给模型看的"示范写法"，评测集是给团队看的"验收标尺"。同一道题不能既当练习题又当考卷——否则你会得到一个漂亮的分数和一堆线上事故。
3.3 评测集也是资产
它有三个用途，价值依次递增：
- 验收依据：上线前跑一遍，量化交付效果
- 回归基线：任何变更跑一遍，确认没有退化
- 需求清单：没通过的题就是下一步要优化的清单，逐条销项
四、怎么跑评测：结果比对的三档严格度
评测不是"看一眼答案对不对"，需要明确的比对方式。按严格度分三档：
| 档位 | 比对内容 | 适用场景 | 成本 |
|---|---|---|---|
| L1 结果比对 | 最终数值/明细是否与基准一致 | 数值型问题（金额、间数、占比） | 低 |
| L2 逻辑比对 | 对象/维度/过滤/时间范围是否与口径一致（数值允许因数据更新而波动） | 趋势、排名类问题 | 中 |
| L3 过程比对 | 生成 SQL 与基准 SQL 的语义结构一致（不要求字面相同） | 排查争议题、回归归因 | 高 |
实操建议：大部分题用 L1/L2，L3 只在争议题和归因时用。全量 L3 会把人拖死，而且 SQL 写法本来就不唯一。
一个容易被忽略的点：多轮追问要单独测。单轮全过、多轮全崩的系统很常见——因为追问涉及指代消解和上下文裁剪，属于另一套机制。评测集里应该有 10–20% 的多轮题，按"链路上最终是否收敛到正确答案"计分。
五、回归：把评测集接进变更流程
有了评测集，下一步是让它自动跑起来。问数系统有一类特殊的风险：大部分变更是"静默退化"——改了 A 场景的口径规则，B 场景的答案悄悄错了，没人发现，直到业务对账时炸出来。
四类变更必须触发回归：
| 变更类型 | 风险 | 回归范围 |
|---|---|---|
| 语义层建模变更 | 字段/对象/度量定义改动，影响面最广 | 全量回归 |
| 回答规则（Prompt）变更 | 规则互扰，可能修好一个坏了三个 | 全量回归 |
| 样例库新增/修改 | 新样例与既有口径冲突，导致同类问题被"带偏" | 相关对象切片 |
| 接入层/数据源变更 | 表结构、字段类型、数据源切换 | 全量回归 + 可执行率专项 |
回归结果的看法也有讲究：不要只看总分，要看切片。
整体通过率 : 92% → 91% ← 只掉 1%，看起来没事 切片 - 收缴类 : 88% → 71% ← 单类暴跌 17%，这就是事故 切片 - 多轮追问 : 75% → 75%总分掩盖问题，切片暴露问题。建议把评测集按「对象 × 问法类型」打标签，回归报告按标签出切片。
六、线上怎么持续观测：日志就是最好的数据源
离线评测集总有覆盖不到的问法——线上才是真实分布。好在问数系统的每次交互天然产生一条完整记录（提问、生成的查询、执行结果、返回答案），这套留痕本身就是观测数据源。
线上建议重点看六个指标：
| 线上指标 | 计算方式 | 异常信号 |
|---|---|---|
| 未命中率 | 相似检索未找到匹配样例的提问占比 | 上升 = 出现新问法，样例库该补了 |
| 零结果率 | 查询成功但返回空结果的占比 | 上升 = 过滤条件理解错，或数据本身缺失 |
| 重问率 | 同一用户短时间内改写同一问题的占比 | 上升 = 首答不可用，看是口径还是理解问题 |
| 追问轮次分布 | 每条会话的追问轮数 | 集中在高轮次 = 需要优化澄清策略 |
| 口径争议反馈量 | 用户标记"答案不对"并填写差异 | 最高价值信号，直接产出修复任务 |
| 延迟分位值 | P50/P95 端到端耗时 | P95 恶化 = 大表/复杂关联问题 |
其中口径争议反馈是最值钱的：它同时是 bug 报告、口径澄清记录和新的评测集条目。设计上应该让用户能一键反馈"原话 + 预期值 + 差异点"，一键落库。
线上指标和离线评测的关系是：
- 离线评测回答"我们承诺的能力还在不在"（守底线）
- 线上指标回答"真实用户在怎么用它、哪里卡住了"（找方向）
两者缺一不可，且评测集应该定期用线上高频问法更新——从真实分布里抽样，比闭门造题有效得多。
七、一个可落地的节奏
把上面所有东西压成一张时间表：
阶段一：POC / 试点（1–2 周）
- 选 1 个对象、1 个真实业务问题
- 建 30–50 题评测集（含 10% 多轮题）
- 跑一轮基线，记录四层指标
- 输出：一份带有具体失败案例的评测报告（比通过率数字有说服力得多）
阶段二：上线（接入 1–3 个系统）
- 评测集扩到 80–150 题，覆盖全部接入对象
- 建立变更触发回归的机制（哪怕先手动执行）
- 定下验收阈值并写进验收文档（建议：可执行率 ≥98%，语义命中率 ≥85%，口径一致率 100%——口径类不允许错，错一条修一条）
阶段三：运营（持续）
- 线上六个指标纳入例行周报
- 口径争议反馈按周销项（修复即入库）
- 评测集每季度用线上高频问法扩充一轮
- 每次口径变更后，回头扫一遍样例库和评测集里的相关条目
八、五个反模式
① 用演示题当评测集。演示题是设计过的、答案已知的、口径最清楚的。用它评测等于开卷考试，分数必然好看，落地必然出事。
② 只测数值不测口径。数值对了但分子分母理解不同，是最隐蔽也最致命的一类错——因为对账时才暴露，而且业务会连带不信任整个系统。
③ 口径类问题允许"大部分正确"。口径是零容错的：99 条对、1 条错，那 1 条会被反复引用。宁可覆盖少，不可口径错。
④ 上了线就不再评测。问数系统是持续演进的（样例在增、规则在改、数据在动），没有回归机制的系统会缓慢劣化，而且劣化过程完全静默。
⑤ 只看总分不看切片。总分 92% 听起来很好，但如果收缴类已经从 88% 掉到 71%，这个 92% 只是在掩盖事故。
九、上线自检清单
| # | 检查项 | 状态 |
|---|---|---|
| 1 | 评测集是否覆盖全部接入对象 × 主要问法类型 × 难度分层？ | ☐ |
| 2 | 每道题的标准答案是否来自业务确认口径 + 独立核对？ | ☐ |
| 3 | 是否测量了四层指标，而不是一个笼统的"准确率"？ | ☐ |
| 4 | 多轮追问是否有独立测试集，按链路收敛计分？ | ☐ |
| 5 | 语义层/规则/样例/接入四类变更是否都会触发回归？ | ☐ |
| 6 | 回归报告是否按对象与问法类型出切片，而不是只报总分？ | ☐ |
| 7 | 线上是否采集了未命中率、重问率、争议反馈量等指标？ | ☐ |
| 8 | 用户是否能一键反馈"答案不对"并带上原话与预期值？ | ☐ |
| 9 | 口径类指标是否设定为零容错（发现一条修一条）？ | ☐ |
| 10 | 评测集是否有明确的 owner 和更新节奏？ | ☐ |
小结
回头看整个系列，一条线索其实很清晰：
- 架构与接入决定了系统能不能跑起来
- 语义层与口径治理决定了答案对不对
- 样例库与 Prompt 工程决定了它会不会越用越准
- 多轮追问决定了它能不能天天用
- 评测与度量决定了你知不知道上面四件事做成了什么样
前四件事做得好但没做第五件的团队，通常会在某个季度被业务一句话问倒："上个月你们说好的效果呢？"
所以我的建议很直接：在你写第一行配置之前，先把评测集的表结构设计出来。它比任何一项功能都更早地决定了项目的验收方式和最终口碑。
配图对应平台能力：核心处理架构、提问到答案流程、问答样例库、质量门禁（质量门禁与留痕审计为平台内建；指标定义、评测集构建、回归机制与线上观测方法为需要实施方与客户共同建立的方法论）。
欢迎在评论区交流你们团队的问数评测实践——尤其是"口径一致率怎么自动化核对"这个我至今觉得最难做漂亮的问题。
