更换或升级模型之前
按自己的业务样例复测

新版本上线后，只试问几个问题，觉得回答更通顺、速度更快，就直接启用。这样做，可能漏掉真正重要的变化：文字更好看了，某个指标却算错了；语气更肯定了，依据却不够。

我们的建议是：个人和团队都准备一套自己的业务样例，也就是一组能代表本岗位工作的任务、材料和合格标准。更换模型、升级版本、更换工具或者修改做法之前，用同样的样例、同样的标准，把原来的工作再做一遍。

一套业务样例里有什么

• 代表性任务：平时真正要做的工作，而不是泛泛的测试题。
• 固定材料：每次测试用同一份材料，保存好副本。
• 合格标准：什么样的结果可以用，运行之前写下来。
• 检查方法：怎样判断是否合格，哪些项由人来看。
• 版本记录：测试的是哪个模型、哪一版说明，测试日期和运行次数。

保存时，业务标准和表现记录要分开。业务标准回答“什么结果可以用”，由岗位负责人或业务负责人确定，不随模型改变。表现记录回答“这个版本实际做得怎样”，包括合格情况和出错类型，以及耗时、调用成本和人工复核所用的时间。

简报更通顺了，指标却错了

以下是一个示例。办公室每周编写一页重点工作简报。本周台账里有 8 项工作，完成了 6 项；其中本期到期的有 5 项，按时完成 4 项。

“全部事项完成率”是 6 ÷ 8 = 75%，“到期事项按时完成率”是 4 ÷ 5 = 80%。两个指标的分母不同，名称不能混用。

模型升级以后，简报读起来更通顺，却把 75% 写成了“到期事项按时完成率”。另一份材料缺少上期数据，它仍然写出“比上期明显改善”。

只读文字，这两处问题都不容易发现。样例中如果正好有“指标口径”和“缺少比较数据”这两类情况，测试即可发现。

怎样建一套业务样例

1. 选定样例。先准备三类材料：材料齐全的正常任务；缺少关键数据或页面的任务；两份材料的数字、日期或名称不一致的任务。再加上过去出过错的任务，和一项目前还做不好的难题。
2. 先写标准，再运行。每个样例写明必须满足的条件、允许的不同写法、怎样检查。例如材料缺少数据时，合格的做法是说明哪些内容无法比较，列出需要补充的材料，而不是直接给出结论。
3. 固定条件。一次只改一处：比较模型时，材料、说明、工具都不变，只换模型。记下模型版本、日期和运行次数。重要的样例多运行几次，保留每一次的结果，不只保留效果好的那一次。
4. 分开看结果。先看原来合格的任务是否仍然合格，再看原来做不好的任务有没有改进。然后比较质量、耗时、调用成本和人工复核的时间。
5. 作出使用判断。哪些任务可以交给新版本，哪些要加一道人工确认，哪些暂时沿用原来的方案。

模型、说明、工具如果同时更换，测出的结果只能算整套方案的比较，不能都归到模型上。

重播

一张版本对照表

每次复测填一张。“合格标准”一栏在运行前填好：

测试日期、模型版本、运行次数和复核人，记在表头。

什么时候要复测

不只是更换模型。下面几种情况，都应当照原样再测一遍：

• 模型升级了版本，或者更换了模型、服务。
• 修改了交给 AI 的说明、模板或检查规则。
• 接入的工具、资料来源发生了变化。
• 业务规则变了，例如指标口径调整。
• 实际使用中出现了新的错误。

业务规则变化时，先更新标准，再复测。其余几种情况，标准不动，只看结果有没有变化。

内网的模型升级时，谁来测、留什么记录

在内网部署的模型，升级版本或更换模型，通常由信息化部门安排。能否正常运行、响应速度如何，属于技术验证，由信息化部门完成；业务上的结果是否仍然合格，要由使用部门按业务样例复测。两项都完成，再在正式环境启用。可以按这样的顺序安排：

1. 提前告知。信息化部门在升级前告知使用部门：升级的时间，升级前后的版本，可能影响哪些应用。
2. 按样例复测。使用部门在测试环境中，用保存的业务样例照原样运行，填写版本对照表。涉及系统操作的样例，按下一节的办法核查实际结果。
3. 作出使用判断。由使用部门逐项给出。
4. 确认后启用。复测记录和使用判断经使用部门负责人确认后，再在正式环境启用。条件允许时，原版本保留一段时间，出现问题可以切换回去。
5. 记录归档。复测记录与升级记录一起归档，留存备查。

有了这份记录，日后有人问起“这个版本是怎样验证后启用的”，查得到依据。

核查系统中的实际结果

如果 AI 不只是撰写文字，还会代为查询、提交、更新系统中的记录，测试时就不能只看它回复了什么。

示例：一个代员工提交费用报销单的助手，回复“已为您重新提交”。测试时要到系统中核查：单据是否确实生成，有没有重复提交，预算是否被占用了两次。文字上说已经完成，不能代替系统中的实际结果。

这类样例要在隔离的测试环境中运行，或者用保存下来的记录回放，不在正式系统中试。团队的样例至少覆盖三类：正常流程、关键的异常情况，以及一项想了解新版本能否做到的任务。

样例也要维护

• 新发现的错误，确认以后加进样例。下次再测，就能看出它是否再次出现。
• 留一部分样例，不用来调整说明，只用来检验。否则样例会越测结果越好，却说明不了问题。
• 业务规则变了，另存一版标准，写明变化的原因。旧版本保留，用来解释以前的结果。
• 团队的样例，标准由业务负责人确认，并写明由谁维护。

从三份材料开始

不必一开始就做全。个人可以选定一项每周都做的工作，按正常、缺项、冲突各准备一份材料，写好标准，放进一个文件夹。下次模型更新，照原样运行一遍，对照记录。

团队可以从一条业务流程开始，先把样例和标准定下来，再逐步补充实际使用中遇到的新情况。

模型会一直更新。有了自己的样例，每次都能用同一把尺子衡量。