1. 在准备各种变体之前，先写下问题
一次有用的比较，要回答一个明确的决策问题：增大最大长度能否避免回答被截断？某个细节级别能否保留必要的轮廓？更大的批处理能否顺利跑完而不报错？选定一个问题，只改一个参数。“找出最佳设置”对第一次测试来说范围太宽了。
把 A 称为基准，把 B 称为变体。记录下精确改动的数值。同时改动模型、尺寸和迭代次数，可能会得到一个不同的结果，却无法揭示究竟是哪项改动造成的。把这些尝试留给另外的对比测试。
2. 固定一份小型语料和评判规则
为 A 和 B 准备同样的输入。只要涵盖了项目中的难点——图片里的细小文字、长文档、缺失的数据或异常格式——十来个案例就足以支撑一次范围有限的初步决策。这个数量是一种实用选择，不是统计学保证。不要只挑那些本来就成功的例子。
对每个输入，在测试之前就写好成功的条件。要把排版上的偏好和阻碍性的缺陷区分开来。在文档助手里，即使答复读起来更顺眼，只要它凭空编造了一条规则，也可能仍要判为不合格。对产品图来说，讨喜的颜色无法弥补重要元素的缺失。
还要确定通过案例的最低数量、禁止出现的缺陷以及检查的最长时间。在查看结果时，这些依项目而定的阈值必须保持一致。
| 需要固定的内容 | 记录示例 | 为什么这很重要 |
|---|---|---|
| 输入 | case-01 至 case-12，相同的文件和相同的表述 | 比较同样的难点 |
| 质量标准 | 答复可在文档中核实，且无编造内容 | 避免流畅的输出掩盖错误 |
| 严重失败 | 把不存在的规则当作确定事实来陈述 | 即使总体看起来更好，也要拒绝这类缺陷 |
| 变量 | A：最多 128 个新 token；B：最多 256 个新 token | 把差异归因于一项已识别的改动 |
3. 保持同一次会话和相同的依赖项
保留模型、其版本、扩展、计算引擎及其他参数。使用相同的环境和相同的 GPU，不要在两次变体之间启动其他处理。记下你无法控制的因素：可见的并发活动、强制版本变更或不同的加载情况。受这些变化影响的比较需要更加谨慎。
如果工具使用随机种子并允许固定它，请为每一对运行保留该值。这有助于比较，但并不能保证各处输出完全一致。PyTorch 指出，即使种子相同，跨版本或跨平台也无法保证完全可复现。
创建两个文件夹 A 和 B，包含相同的标识符列表。在进行任何手动修正之前，保留原始输出。事后修改应作为一项额外操作出现，并计入其工作时间，而不能归因于生成初始文件的那项设置。
4. 先做一次控制运行，再逐对比较
首先确认一个简单的输入能一直走到获取到的文件或响应。这次运行用于检验方法。单独指出首次加载或特殊准备工作：不要将 A 的完整启动与所有元素都已加载的 B 运行相比较。
对 A 和 B 执行相同的用例。如果工具允许，交替顺序，然后以相反顺序重跑几对关键用例。确认单个结果或顺序上的优势没有主导整个结论。
也要记录错误和被拒绝的输出。如果 B 在大输入上失败，不要为了拉高它的平均值而将其从表格中删除。可以在单独的一次 B2 试验中修正原因。这样你能保留一份清晰的比较，而不是一个随着困难变化而改变变体的档案。
5. 将接受的答案与观察到的时间分开
首先在实际尺寸或实际使用的工具中检查质量。如有可能，在评判时暂时隐藏 A 和 B 的名称。一个人可以按打乱的顺序查看输出，然后再恢复它们的对应关系。保留事先宣布的标准，并为每一次拒绝给出简短理由。
对于时间，选择单一定义：例如从启动到完整输出保存下来。然后将人工检查和修正分开。围绕一次 GPU 调用计时并不总是对计算完成的测量：在 PyTorch/CUDA 下，操作可以是异步的。如果你想单独测量计算，请使用工具记录的测量方法。
如果多次重复相互重叠，或计时仍然粗略，请注明「时长差异不具决定性」。单次运行上的微小差距不足以支撑一个被说成确定无疑的增益百分比。
示例：文档助手使用 128 还是 256 个新 token
一个小团队希望在十二个固定问题上得到完整回答。他们保持相同的模型、相同的文档、相同的指令和相同的 GPU。只有回答长度限制改变：A 允许 128 个新 token，B 允许 256 个。在 Transformers 中，max_new_tokens 限制生成内容，不计入输入文本的 token。一个 token 不等于一个词：该限制并不能确定确切的句子数量。
在试验之前，团队设定一条示例性规则：十二个回答中至少十个被接受，且不得臆造规则。下表是解读结果的虚构情景。它并不描述某个被测量过的助手，也不预测这些数值对你的模型会产生什么效果。
A 达到了最低要求，B 获得了更多被接受的回答，但仍保留一个严重缺陷。决定是在此范围内保留 A 并复核回答，同时在另行比较之前查找 B 缺陷的原因。更长的长度既不是质量的证明，也不是臆造的确定原因。
团队重跑那些能区分 A 和 B 的问题，以及两个已经成功的问题。如果该缺陷在 A 上也出现，他们就暂停结论：最初的语料不足以确立稳定性。他们保留两次运行的记录，而不是只留下更有利的那一次。
| 情景标准 | A：最多 128 个 token | B：最多 256 个 token |
|---|---|---|
| 已通过的答案 | 12 个中的 10 个 | 12 个中的 11 个 |
| 关键缺陷 | 0 | 1 条臆造的规则 |
| 时长 | 需在实际会话中核查 | 需用同样方法核查 |
| 是否符合已公布的规则 | 是的,在这个有限场景中 | 不是,尽管总分最高 |
避免得出测试无法支持的结论
不要因为 B 的某一个输出很惊艳、而其他输出却在变差就选择 B。不要在过程中更换语料,不要把两次重试算作两个不同的条目,也不要把失败从分母中抹掉。提交的十二个条目仍然是十二个需要解释的案例,即使其中有些没有产出任何文件。
所选的配置只适用于受检的条目、版本和标准。面对长十倍的文件或不同的图像,它可能就不再适用。请逐步加入有代表性的案例。这种推进扩展了管控范围,但不会把一次小测试变成对系统的认证。
保留一份简短的决定和下一步核查
你的最终档案包含语料、两套配置、输出、每个标识符的判定以及几行结论。写明所选的配置、理由和局限:“在这十二个问题上保留 A;两个回答仍有待复核;未覆盖额外的长文档”。另一个人应当无需参加那次会话就能理解决定。
保留下 A 作为下次诊断的对照。如果没有任何变体满足标准,就不要为交付选用其中任何一个;请提出新的假设。在启动这轮后续测试前,留出复制和核查的时间。一次带有明确局限的完整试验已经能带来决定;它并不要求你一直做到找出赢家。