保存结果，也保存它回答的问题
假设一个助手在你的测试中得了72%。几个月后，新版本给出了不同答案。旧分数仍能描述当时的测试，却未必适合指导今天的选择。把模型、测试、设置和日期与结果一起保存，读者才能知道分数指的是什么。
今天的语言模型出现之前，这个问题就已经存在。HAPI收集了商业机器学习服务在2020至2022年间的170多万次预测。研究发现，表现会随时间明显变化：有些测试的准确率下降；有时总分稳定，出错的数据类型却变了。[1] 产品名称相同，不保证行为相同。
除了分数，也记录研究帮助你理解了什么：哪项任务变容易了，谁受益，哪些错误仍需要审核，还有什么变化可能推翻当前解释。即使原模型已经无法使用，后续研究仍可以继续检验这些问题。
留下问题和比较方法，才能解释新结果为什么不同。
证据说明了什么，就说到哪里
一次成功回答，只能说明那次尝试发生了什么。一组测试案例可以说明模型在这些条件下的表现。要知道它是否改善实际工作，就需要观察人们完成工作，包括审核和纠正的过程。要判断组织的决策是否变好，则需要关于那些决策的证据。
把这些判断分开。模型准确提取信息，可能节省搜索时间，却未必改善最终决定。初稿写得更快，也可能增加后续检查。测量你想宣称的结果，不要用范围较小的测试证明更广泛的好处。
例如，一项发现可以是：在某个明确的审核流程中，初步信息提取减少了人工搜索，但特殊案例仍需要专家判断。后继模型也可以接受同样的检验。说明你为什么认为改进发生了，以及哪些证据支持这个解释，避免把结论写得宽泛到任何结果都能符合。
比较同一种工作有没有完成
选择模型换代后仍有意义的指标，例如完成的案例、解决的请求、被采纳的决定，或完成明确任务所需的时间。词元数和消息数有助于解释系统行为，但消息少了，并不一定表示工作做得更好。
METR的任务时长研究提供了一个例子：它衡量系统在指定成功概率下，能够完成多长的任务，长度用熟练人员完成任务所需的时间表示。[4] 这不是AI实际运行的时长。共同的任务尺度和可靠性要求，让不同系统回答同一个可比较的问题。
测试替代系统前，先定义完成、所需质量、成本和可接受的失败。一个成功率为一半的系统，在密切监督下可能有用，却不适合无人值守。如果任务定义改变，保留一些能按新旧定义分别评分的案例，以便区分定义变化和性能提升。
用同一种任务和可靠性要求比较不同模型。
保留旧测试，也加入当前案例
不变的测试有利于比较，却可能过时，或被模型过于熟悉。全部换掉又会带来另一种问题：分数变了，不知道是模型变了还是题目变了。因此，保留一组固定案例，同时加入当前工作中的新案例。
Dynabench让人们编写当前模型难以处理、但仍然有效的样例。LiveBench从近期来源编写新问题，并使用能够客观核对的答案。[2][3] 这是让测试随模型变化继续提供信息的两种办法，但仍要理解每种测试到底在测什么。
说明每组案例的用途：不变案例用于前后比较，新案例反映当前条件，难例针对已知失败。因答案或任务不再适用而移除的题目，也要留下记录。各组分别报告，避免新题更容易，却被误读成系统整体进步。
看使用工具的人，工作发生了什么变化
一项专业写作的预注册实验发现，使用ChatGPT使平均任务时间缩短40%，评估质量提高18%。[5] 这些数字属于受测的人群、任务和工具。后续研究可以检验同类帮助是否依然有用，不应假定每个新模型都会得到相同百分比。
一项覆盖5000多名客服人员的工作场景研究发现，每小时解决的问题平均增加，经验较少者受益更大。经验最丰富者的速度小幅提高，质量则小幅下降。[6] 检查替代系统时，要同时看谁受益、工作哪些方面变了。处理更快，并不一定代表服务更好。
一项顾问实验发现，AI辅助改善了某些任务的表现，却损害了一项超出系统能力的任务表现。[7] 保留这些任务的具体描述，以及人们如何决定是否依赖工具。新模型可能改变能力边界，但仍需要检查它在哪些地方不再可靠。
检查谁受益、哪部分工作改善，以及帮助从哪里开始不可靠。
措辞和方法可以不同，但要在要求的条件下比较系统实际完成了什么。
提前安排怎样比较替代系统
趁当前系统仍可用，选好固定案例、新案例和过去的重要失败案例。让现行系统与候选系统获得可比较的工具、权限、时间和人工帮助。比较完成情况、可靠性、成本、等待、纠正所需的精力和严重错误。重复足够案例来了解正常的输出波动；可行时，不让审核者知道结果来自哪个版本。
有关模型随时间变化的研究，考察了环境改变时怎样结合近期与历史数据。自适应滚动窗口方法会调整使用多少过去的数据。[9] 对实际审核而言，重要的是两者都看：历史案例能暴露丢失的能力，当前案例说明服务现在需要处理什么。两者怎样搭配，要看任务。
预先决定什么结果足以支持更换系统。候选系统在新案例上改善、旧案例上退步时，检查旧案例是否仍然重要。如果两个系统出现同样的严重错误，除了模型，也调查共用的数据和工具；错误相同不证明原因相同。如果新系统用另一种方式解决问题，就相应修订对帮助机制的解释。
除了模型，还有什么变了
结果变化可能来自模型、应用、使用者，也可能是任务的正确答案变了。例如，新政策生效后，旧答案会变错，即使模型行为完全没变。记录模型版本时，也记录来源材料、界面、程序和人工做法的变化。
WILDS基准记录了机器学习系统面对不同医院、地区或时期等环境变化时的性能差距。[8] 比较自己的系统时，保留一些不变输入，也收集当前环境中的案例。先知道哪些条件没变，才能解释性能为什么变化。
监测与用户有关的案例类型、结果、纠正、求助、费用和投诉。总分稳定时，也要分别检查重要群体。HAPI发现，平均表现不变时，错误仍可能在不同数据类型之间转移。[1] 这些检查可以帮助发现原来的结论何时不再适用。
告诉读者，什么时候需要重新检查结论
报告结尾写清任务、人群、时期、系统版本、比较对象和结果。说明发现适用于哪里，还有什么不确定。列出需要重新审核的变化，例如模型、政策、界面、价格、用户群体改变，或出现严重失败。
明确说明发现的当前状态：新测试后仍有支持，需要修订，已被更好的解释取代，或已不涉及当前任务。到了该审核的时候却还未审核，就写明目前是否成立尚不确定。旧报告仍能下载，不代表其中的结论仍然有效。
保留旧版本，解释证据、理解和建议行动发生了什么变化。让读者看出哪些部分仍有用，哪些为什么修订。研究能够跨越模型更新继续发挥作用，是因为下一位审核者知道怎样再检查一次答案。