评测、版本与知识维护
建议用时:25 分钟(含练习)
学习目标
能够为工作流建立固定样例、评分规则、版本记录和定期复核机制。
本节产出
一套小型评测集与维护日历
核心知识:用相同问题比较不同版本
模型、提示、资料和工具都会变化。如果每次只凭感觉判断“这次更好了”,很难知道改进来自哪里,也容易忽略某类任务退化。
评测集
一个小型评测集可以固定代表性输入和评分规则,让不同版本在相近条件下比较。
评测不是寻找一组永远不会失败的演示。应包含常见任务、缺失输入、冲突资料和容易误判的边界。样例数量可以从少量开始,但要说明覆盖范围;五个样例通过只能证明这些样例的表现,不能推断系统在所有真实任务上可靠。
图中的维护有两条来源:计划性的资料复核,以及实际失败触发的修订。前者帮助处理产品更新和链接失效,后者帮助发现原先没有想到的问题。两者都需要留下原因与证据。
案例:研究简报的五个样例
假设你的模板需要生成带证据的短文,可以先选择三个正常样例和两个边界样例。正常样例覆盖不同长度与结构,边界样例分别包含缺失正文和相互冲突的说明。每个样例都保存输入版本与期望结果范围。
| 维度 | 示例通过条件 | 检查方式 |
|---|---|---|
| 事实准确 | 关键事实均由材料支持 | 人工逐项核对证据表 |
| 来源可用 | 所用链接与出处对应 | 链接检查加内容抽查 |
| 未知表达 | 缺失与冲突没有被补写抹平 | 检查指定边界样例 |
| 输出结构 | 必要部分完整且可读 | 自动字段检查与阅读 |
| 范围遵守 | 没有读取或发布未授权内容 | 核对实际工具记录 |
对于关键边界,可以设为必须通过,而不是与文风分数平均。一次越权操作不能因为语言优美就被综合分掩盖。对于表达清晰度,可以用简短量表,例如读者是否能复述结论、找到来源并理解限制。
保留基线和运行条件
记录模型或应用版本、提示版本、资料版本、运行日期、可用工具和必要参数。某些托管产品不会提供完整内部版本信息,就记录实际可观察到的设置与限制,不编造精确标识。
生成式系统可能在相同输入下产生不同输出。一次运行可以发现明显问题,但对稳定性要求较高时,应重复运行并记录波动。重复次数要与成本和风险相称,不能用一个幸运结果替代稳定表现。
改进要定位到失败类型
若输出漏掉来源,可能是模板要求不清;若引用支持不了结论,可能是证据判断失败;若正文抓取不完整,问题在资料处理;若旧事实被反复使用,问题在维护与版本管理。不同原因需要不同修复,不能每次都只换模型。
可以每次只改变一个主要因素,再重跑评测,这样更容易判断影响。如果同时换模型、改提示、替换资料和更新工具,结果改善也难以归因。实际工作有时必须同时变更,但要诚实记录比较限制。
维护日历与事件触发
高频使用且易变化的产品资料可以安排较短复核周期;稳定概念可在出现新证据、错误反馈或课程改版时检查。链接失效、实际行为与说明不符、来源修改关键条件,都应触发提前复核。
更新后保留变更摘要与旧版本定位,必要时能够恢复。评测集也需要维护:新增真实失败样例,移除不再适用的情况时说明理由,避免悄悄删除失败测试让结果看起来更好。若训练或提示反复围绕同一组样例优化,还应加入未用于调试的新样例检查泛化。
动手练习
- 为一个简报模板建立五个样例和明确的通过条件。
- 比较两个提示版本,记录一个改善和一个没有改善的地方。
- 制作维护安排,包含周期复核、事件触发和回滚记录。
参考答案与推演
缺正文样例应输出缺口,不生成虚构细节;冲突样例应保留双方条件;正常样例应形成可追溯正文。版本比较可以发现新提示减少格式遗漏,却没有改善引用判断,下一步就应针对证据映射修订,而不是宣称全面提升。
维护记录应包含变更原因、受影响资料、评测结果和未解决问题。若新版本在一个关键边界失败,即使平均分提高,也应先修复或限制使用。通过标准必须在看结果前明确,避免事后为喜欢的版本修改规则。
完成检查
- 评测包含代表性正常与边界样例。
- 通过条件明确,关键边界不被平均分掩盖。
- 运行条件、版本与波动有记录。
- 维护由日期和失败事件共同驱动,修改后回归检查。
参考与来源
- OpenAI:Evaluation best practices:评测设计与持续改进的官方实践说明。
- Anthropic:Demystifying evals for AI agents:任务、评判器、轨迹和结果评估的工程讨论。
评测、版本与知识维护
3 道题 · 及格分 60 分