直接回答
重复运行模型并不自动意味着每次都应得到逐字节相同的文本。结果变化可能来自制品、runtime 修订、backend、采样参数、线程或执行设置、预处理、提示模板或输入发生变化，而不一定是模型质量回归。可复现协议应固定已知变量，记录每次实际配置，并预先说明任务需要哪种等价性。这不同于一般的答案回归测试：这里首先要解释两次运行为何不同，以及比较前必须控制哪些条件。 先创建不可变的运行清单。记录精确模型制品身份或摘要、runtime 与 delegate/backend 版本、应用构建、设备和系统、提示/模板修订、已知 tokenizer 身份、输入夹具、预处理、解码参数及相关线程/执行设置。区分请求的配置与观察到的实际行为。请求某个 backend 的开关不能证明它执行了；源码里的提示也不能证明模板展开后的请求完全相同。清单应与输出属性和测量方法一并保存。 测试之前先定义可复现声明。对于确定性的解析或前后处理，精确相等可能合理。对于生成文本，需明确要求的是字节相同、结构有效、关键事实保留、数值受限、引用有依据，还是经人工评估可接受。逐字相同是强条件，不能无理由要求；但只接受“读起来流畅”又可能过弱。协议要命名必须满足的属性和允许变化的范围。 按预先确定的顺序执行重复试验。固定制品和输入；若研究某个采样参数，一次只改这个参数并创建新的条件标签。用保护隐私的夹具报告保存全部输出；若正文必须受保护，则只保存经过审核的派生属性。失败、格式错误、空输出、取消和回退都需保留。不能挑最有利的一次，也不能不断重试到结果满意为止。如果设备或 backend 行为本身存在非确定性，应报告观察结果，不要声称所有变化来源都已受控。 先将配置漂移与运行间变化分开。比较前核对制品、软件、模板、预处理和设备配置。若其中有差异，应把样本视为不同测试条件，而不是直接称为随机性。如果清单匹配，再检查已声明的采样参数、backend 行为、线程调度和应用状态。协议不能假设未记录的 runtime 保证；应查验所用准确版本的官方文档。没有明确保证，就不能承诺确定性。 用成对测试研究有意义的变化。固定输入集合能显示 runtime 或制品变化后重要属性是否改变，却不能自动给出普遍质量评分。记录评分表、评审人和可接受替代答案。结构化输出或引用任务，应把语法检查与文本措辞分开。翻译或语音转写应使用人工审核标签，不能在不考虑合法替代表达的前提下仅做字符串比较。 保护测试数据。可复现性不要求上传用户提示或媒体。使用合成或已获同意的夹具，适当记录 ID、版本和摘要。私人输出不要放入 issue tracker 或普通 CI 日志。若确需保留生成文本，应配置访问范围与保留期限。项目事实要求基准结论有可复现方法和实际证据；清单使运行可检查，但本身不构成准确率、速度或设备兼容的证据。 最后只做有限结论。报告有多少运行使用了匹配配置、检查了什么属性、差异还有哪些，以及制品/runtime/设备范围。如果某项属性在已测夹具中稳定，可以这样描述，但不能承诺未来每次生成都相同。如果 runtime 悄悄选了不同 backend 或制品身份缺失导致不可复现，应说明证据缺口并在可追溯设置下重跑。诚实表达不确定性，远胜捏造确定性保证。 还可用输入与输出摘要检查意外更改，但摘要不能替代夹具版本和来源。若只编辑提示模板中的一处文字，即使用户输入未变，也应创建新运行条件。记录采样器配置的有效值，而非只写“默认”；默认值可能随 runtime 升级变化。只有准确配置被固定后，运行对比才有解释基础。 对于多模态结果，输入处理也影响一致性。图像旋转、裁切或音频分段变化会改变模型接收的内容；必须把转换版本记入清单。否则将内容变化称为推理随机性是不准确的。系统可记录转换元数据和校验摘要，不需要保存敏感原图或录音。对隐私敏感任务，公开报告只展示聚合属性，并删除可逆标识。 差异分析按顺序进行：先验证输入和制品一致，再检查模板与预处理，再核对 runtime/backend/参数，最后判断属性变化是否构成真正产品回归。这个顺序减少误报，也防止团队仅调采样温度掩盖输入管线错误。出现安全或关键事实错误时应进入人工审查流程，无论其他运行是否输出流畅。
同一提示词两次生成的 JSON 格式不同
开发者重复运行结构化提取测试，一次输出有效 JSON，另一次多出解释句。第一次结果没有记录应用、提示模板和 backend。
决策
固定并比较完整运行清单，把 schema 有效作为验收属性，同时保留两次结果，不挑选更好的一次。
预期结果
团队能够区分配置变化与运行表现差异，并准确说明测试结论范围。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- BENCHMARK-01：基准结论应有可复现方法及实际记录，不能只挑有利样本。
- LITERT-01：runtime 与 backend 条件需绑定具体执行证据；选项请求不等于实际运行结果。
发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。
实施流程
- 创建完整运行清单. 记录制品身份、runtime/backend、应用与系统、提示模板、tokenizer（若可知）、预处理、采样参数、线程、输入夹具及请求和观察到的执行方式。
- 为任务选择等价规则. 决定要求字节一致、结构可解析、关键事实保留、引用有依据还是人工评审可接受；在看到试验输出前说明理由。
- 重复固定条件并保留所有结果. 以预定次数和顺序使用同一夹具。保留错误、取消、fallback、畸形和空输出，不挑结果后再重试。
- 先分类配置漂移再谈变化. 优先比较清单。制品、模板、预处理、设备或 backend 变化属于不同条件；只有记录匹配后才分析运行间表现。
- 限定结论并保护数据. 使用同意或合成夹具，按需脱敏输出，并说明制品/runtime/设备/属性覆盖。不能推断总体准确率或确定性保证。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每次运行清单注明制品、runtime、backend、提示、输入夹具与重要执行参数。
- 等价规则在评审输出前定义，并在安全或结构要求较高时强于“语句流畅”。
- 所有预定试验、失败、取消、格式错误和回退结果都得到保留。
- 除非准确 runtime 合同和证据支持，不承诺逐字一致或普遍可复现。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 确定性变换 | 输入和实现固定时可断言精确相等 | 适用于稳定解析或规范化，不自动适用于生成文本。 |
| 生成文本或多模态回答 | 验证任务属性与允许变化 | 可评估任务要求而不虚构逐字节相同保证。 |
| 运行清单不同的样本 | 比较前归类成不同条件 | 配置漂移不构成模型随机性或回归证据。 |
需要避免的失败模式
- 假设同一提示词必然逐字输出一致答案。
- 没有记录制品、backend 或模板就把输出差异归因模型能力变化。
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
相同提示词每次都应输出完全一致吗？
不要假设如此。固定准确配置并查看 runtime 合同；不需要逐字一致时，应按任务属性判断，并记录允许变化的范围、标准和评审方式。
一次 JSON 有效能证明输出稳定可靠吗？
不能。它只证明一项结构属性。还要在声明的夹具中验证必需字段、关键事实、失败情况和预定重复次数，并报告未覆盖情形。
两次运行使用不同 backend 怎么办？
将它们视为不同条件。核对请求与实际执行方式，然后在配置匹配时重测，再讨论输出差异；不要合并两组摘要或样本后下结论。按任务解释差异 under the same conditions.