评测证据与反馈闭环
本节目标
学完本节，你应能区分模型指标、任务指标和系统结果，组合离线测试、人工评审、试运行与线上监控，并说明为什么用户反馈不能直接当成训练真值。
评测先回答“为了什么”
评测（evaluation）不是模型给自己打分，而是使用事先定义的任务、标准和证据，判断系统是否满足目标与风险容忍度。开始前至少写清：
- 谁使用系统，谁会受到影响；
- 哪些结果算成功，哪些错误后果最严重；
- 对照基线是什么；
- 测试数据代表哪个时间、语言和场景；
- 由谁判断复杂或高风险结果；
- 哪个门槛会阻止发布、触发人工或要求回滚。
如果先看完结果再挑指标和阈值，很容易只保留有利数字。
三层目标不要混在一起
| 层次 | 例子 | 主要用途 |
|---|---|---|
| 模型/组件指标 | 分类 F1、检索 Recall@k、JSON 通过率 | 诊断某个组件是否改善 |
| 任务指标 | 行动项是否完整、有证据、无虚构 | 判断系统能否完成目标任务 |
| 系统结果 | 用户完成率、人工改判、事件、成本、延迟 | 判断真实部署是否产生净价值 |
组件指标变好不保证端到端结果变好。检索召回提高后，上下文可能更拥挤；结构化输出通过后，业务参数仍可能错误。三层证据应能互相追溯，而不是只汇报一个总分。
基线与门槛
**基线（baseline）**是当前人工流程、简单规则或上一稳定版本。它回答“复杂方案是否真的带来收益”。没有基线，只能知道系统做到了某个数字，不知道是否值得增加成本与风险。
门槛应在正式测试前定义，并包含：
- 核心任务最低质量；
- 不可接受错误的零容忍或人工门禁；
- 关键语言、群体与高风险切片；
- 延迟、费用和依赖失败；
- 安全、隐私、越权和提示注入；
- 回归不得退化的旧能力。
门槛不是通用常数。漏报可能危及安全的任务，与写营销草稿的容忍度不同。
五类证据各自看见什么
| 证据 | 适合发现 | 主要盲区 |
|---|---|---|
| 单元与规则测试 | schema、解析、权限、边界和确定性逻辑 | 开放语义与真实分布 |
| 冻结离线集 | 版本间质量、安全、成本和错误切片 | 新用户行为与依赖故障 |
| 专家/人工评审 | 复杂正确性、语境、伤害和可用性 | 成本高，评审者可能不一致 |
| 影子或小流量试运行 | 真实流量下的集成、延迟与人工行为 | 覆盖仍有限，不宜放开高风险副作用 |
| 线上监控与事件 | 分布变化、故障、滥用和长期效果 | 只能观察预先记录的信号 |
**影子模式（shadow mode）**指新系统接收真实或近真实输入并产生结果，但结果不直接影响用户或业务动作；团队把它与现有流程比较。它降低副作用，不等于数据可以不经授权，也不等于已经完成上线验证。
人工评审也要设计
复杂生成常需要人工 rubric（评分规则）。一个可复现 rubric 应说明：
- 评价单位是整段回答、逐项事实还是工具轨迹；
- “正确、完整、有据、安全”分别怎样判定；
- 允许哪些等价表达；
- 证据不足、冲突或任务本身有歧义时怎样处理；
- 评审者是否看到系统名称和候选顺序；
- 如何测量评审分歧并升级专家裁决。
LLM-as-a-judge 可以扩展初筛，但评审模型也会受提示、顺序、语言与版本影响。它需要与人工样本对齐并记录版本，不能自动成为真值。
反馈不等于标签
点赞、接受建议、修改文本、重复提问和投诉都是观察信号，却可能受到：
- 界面默认选项；
- 用户没有时间核查；
- 只有极满意或极不满的人反馈；
- 错误直到很久以后才暴露；
- 用户无权看到真正证据；
- 自动化偏见导致机械接受。
安全的反馈闭环应区分原始事件、用户意见和经审核标签；去除不必要敏感信息；按错误类型与场景切片；由授权人员决定进入数据、提示、规则还是产品流程；最后用独立回归集验证。
一个版本化闭环
真实需求与风险假设
↓
冻结测试集 + rubric + 基线
↓
候选系统版本（模型/提示/知识库/工具/代码）
↓ 离线门槛
影子/小流量试运行
↓ 线上指标、人工改判、事件
经审核的问题样本
↓
修数据 / 规则 / 提示 / 检索 / 模型 / 流程
↓
全量回归、批准与可回滚发布每次改变一个主要因素最容易归因。若同时更换模型、重写提示、更新知识库并调整工具，结果变化就很难解释。
最小示例
对“会议行动项抽取”定义：
- 基线：关键词与日期规则；
- 任务指标：任务、负责人、日期、状态和证据逐项判断；
- 安全指标：不得根据不可信文本泄露私人信息，不得自动发送；
- 切片：无行动项、缺负责人、冲突日期、中英混合、注入文本；
- 门槛：所有证据都能映射回原文，关键字段不得无依据补全；
- 试运行：只生成草稿，人工确认并记录改判原因；
- 线上信号：校验失败、人工拒绝、延迟、费用与敏感输入事件。
这比“模型回答看起来不错”更接近可审计证据。
常见误区
| 误区 | 问题 | 改进 |
|---|---|---|
| “平均分最高的模型最好” | 可能在关键切片失败且成本更高 | 同时比较质量、风险、延迟和费用 |
| “离线通过就可全量上线” | 真实流程与依赖行为尚未观察 | 影子、小流量、监控和回滚 |
| “用户没投诉说明没问题” | 伤害可能不可见或无法申诉 | 主动抽查、切片和事件渠道 |
| “让另一个 LLM 评就客观” | 评审模型也有偏差和漂移 | 与人工对齐并版本化 |
| “失败样本直接加入训练” | 可能含隐私、错误标签或选择偏差 | 先审核、归因和最小化 |
练习
为一个“内部政策问答”系统设计三层指标、一个非 AI 基线、六种测试切片、一个发布门槛和两个回滚条件。说明哪些结果由规则检查、哪些由人工判断、哪些只能在线观察。
自测
- 组件指标与系统结果为什么可能相反？
- 为什么阈值应在正式测试前设定？
- 影子模式解决了什么，没解决什么？
- LLM judge 为什么需要人工对齐？
- 用户修改结果为什么不能直接成为训练标签？
范围与下一步
本节只建立“证据怎样闭环”的概念。数据独立性见 泛化、数据划分与泄漏；正式指标、实验与评审设计见 评测体系；要把离线失败、线上事件和发布决策接成可审计交接，继续阅读 离线到线上证据交接与回归闭环；运行信号见 运行监控。
下一节进入 LLM如何生成答案，把通用模型生命周期具体化为语言模型的数据流。
参考资料
获取日期：2026-07-22。