问数系统怎么验收？从评测集到线上指标的完整度量体系

本文是「企业问数系统落地」系列第十篇。前九篇讲的是怎么把系统做对架构、接入、建模、生成、多轮这一篇讲一个更容易被跳过、但决定项目成败的问题怎么证明它做对了。一、先说一个残酷的事实准确率 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/L2L3 只在争议题和归因时用。全量 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 工程决定了它会不会越用越准多轮追问决定了它能不能天天用评测与度量决定了你知不知道上面四件事做成了什么样前四件事做得好但没做第五件的团队通常会在某个季度被业务一句话问倒上个月你们说好的效果呢所以我的建议很直接在你写第一行配置之前先把评测集的表结构设计出来。它比任何一项功能都更早地决定了项目的验收方式和最终口碑。配图对应平台能力核心处理架构、提问到答案流程、问答样例库、质量门禁质量门禁与留痕审计为平台内建指标定义、评测集构建、回归机制与线上观测方法为需要实施方与客户共同建立的方法论。欢迎在评论区交流你们团队的问数评测实践——尤其是口径一致率怎么自动化核对这个我至今觉得最难做漂亮的问题。