AI 输出回归测试与评估日志：用固定数据集追踪模型与提示词变化

把 AI 接进业务流程之后，很多人会默认它的表现是稳定的：今天能跑通的提示词，明天应该也能跑通。实际情况并非如此。模型会更新，API 侧的默认参数可能调整，你自己改过的提示词、温度值、外挂工具、后处理逻辑，任何一处变动都可能让同样的输入返回不一样的结果。个人随手用用，凭感觉判断就够了；但如果 AI 是某条业务流水线的一环，就需要一套能回答「从什么时候开始变的」「当时改了什么」的机制。评估日志就是干这个的：它不追求把「文章好不好」这种主观判断量化，而是把每次执行的条件和结果留痕，让变化可追踪、可对比、可复现。本文面向需要长期维护 AI 功能的开发者与业务负责人，讲清楚日志该记什么、提示词怎么管版本、回归测试怎么做、指标怎么选。

准备工作

这套做法不依赖特定厂商或框架，但需要先把几件事定下来，否则记录出来的日志会互相打架。

确定记录载体

评估日志本质上是结构化记录，最省事的做法是写进一张表或一个 JSONL 文件。字段固定、追加写入、不做原地修改，这样后续对比时不会因为格式漂移而无法解析。如果已经有日志系统，直接复用即可，关键是保证每条记录都带齐下面这些字段。

确定最小字段集

只存输出是不够的，必须把「执行条件」一起存下来。建议至少包含以下字段：

timestamp：执行时间，用于定位变化发生的时点
tool_name：调用的是哪个工具或服务
model_name：具体模型标识，不要只写「默认模型」
prompt_version：提示词版本号
input_id：输入数据的编号，便于用同一批数据复跑
output：原始输出内容
latency：处理耗时
status：成功、失败或异常状态

其中 model_name 与 prompt_version 是最容易被忽略、却最影响事后归因的两项。有了它们，才能把「结果变了」拆解成「模型换了」还是「提示词改了」。

准备固定测试集

如果每次评估都用不同的输入，结果之间就没有可比性。准备一批固定数据，规模不必大，十件左右通常就够用，编号成 test_001、test_002 一直到 test_010。这批数据要覆盖你实际业务里最常见的几类输入，包括边界情况。之后每次改模型或改提示词，都拿同一批数据重跑一遍。

给提示词建立版本管理

提示词哪怕只改一句话，输出也可能明显不同。所以不要用「最新版提示词」这种模糊概念，而是显式打版本号：prompt-v1、prompt-v2、prompt-v3。每次改动时顺手记一行变更说明，例如：

v1: 基本指示
v2: 追加「回答分为 3 个项目」的要求
v3: 改为 JSON 输出

这几行说明的价值在事后才体现出来：当 v3 的 JSON 成功率下降时，你能立刻知道 v3 相对 v2 动了什么。

操作步骤

第一步：定义日志记录结构

先约定一条记录长什么样。以 JSON 为例，单条记录可以组织成下面这种形式：

{
  "timestamp": "2026-01-15T09:12:33Z",
  "tool_name": "text-generator",
  "model_name": "model-a",
  "prompt_version": "v3",
  "input_id": "test_004",
  "output": "...",
  "latency": 3.7,
  "status": "ok"
}

字段名一旦定下就不要随意改。如果确实需要新增字段，用可选字段的方式追加，不要重命名已有字段，否则历史记录和新记录无法合并分析。

第二步：在调用处埋点

每次调用 AI 之后，把上面这条记录追加写入日志。要点有三个：

记录的是原始输出，不要先做清洗或截断再存，否则后续无法判断是模型的问题还是后处理的问题。
latency 记录端到端耗时，包含网络往返，这样换服务商时才有可比性。
status 要区分「请求失败」和「请求成功但输出不合规」两种情况，后者往往才是真正需要关注的信号。

第三步：用固定测试集跑一轮基线

在还没有做任何变更之前，先用固定测试集跑一遍，把结果作为基线保存下来。这一轮的意义是给后续所有对比提供参照点。跑完后统计一遍可量化指标，形成一份基线快照。

第四步：变更时只动一个变量

需要调整时，尽量一次只改一项。对比关系写成这样：

Before: model-a + prompt-v2
After:  model-b + prompt-v2

如果同时换模型又改提示词，即便结果变好了，也说不清是哪一项起了作用。把变量拆开，一次验证一个，归因才成立。

第五步：重跑并对比指标

变更后用同一批 test_001 到 test_010 重跑，把新结果与基线逐条比对。这一步本质上就是一次简易的回归测试：输入不变，看输出是否发生偏移。偏移本身不一定是坏事，但必须是你知情且认可的变化。

第六步：记录并归档结论

每轮对比结束后，把结论写进日志或单独的变更记录里：改了哪一项、指标如何变化、是否采纳。这样积累几轮之后，你会得到一份关于这套 AI 功能的历史档案，而不是一堆散落的实验。

一个完整示例

假设有一条每天用 AI 生成商品描述的业务流程，最近发现输出开始变长、条目变少，甚至偶尔返回的 JSON 无法解析。按上面的方法排查一遍。

第一步，确认日志字段齐全。检查现有记录，确认每条都带 model_name 和 prompt_version。如果缺，先补上再继续，否则后面的对比无从谈起。

第二步，锁定固定测试集。从历史输入中挑出十件有代表性的商品，编号为 test_001 至 test_010，覆盖短描述、长描述、多规格、含特殊字符等情形。

第三步，跑基线。用当前线上配置跑一遍这十件，记录结果。假设此时配置是 model-a 加 prompt-v2，统计得到：

平均处理时间: 4.2 秒
JSON 成功率: 98%
平均输出字数: 180

第四步，定位变更点。回看提示词版本记录，发现 v3 把输出格式从自然语言改成了 JSON，而 v2 只是追加了「分为 3 个项目」的要求。输出变长、条目变少，很可能与 v3 的格式约束有关。

第五步，单变量验证。保持 model-a 不变，把提示词从 v3 回退到 v2，用同一批十件数据重跑。对比结果：

Before: model-a + prompt-v3
  平均处理时间: 4.2 秒
  JSON 成功率: 97/100
After:  model-a + prompt-v2
  平均处理时间: 4.0 秒
  JSON 成功率: 99/100

到这里可以初步判断，JSON 成功率的波动与提示词版本相关，而不是模型本身的问题。

第六步，评估换服务的可行性。如果同时在考虑另一个服务，用同一批数据跑一遍，得到类似这样的对照：

Tool A
  平均处理时间: 4.2 秒
  JSON 成功率: 98%
Tool B
  平均处理时间: 2.8 秒
  JSON 成功率: 94%

速度更快但成功率更低，是否值得切换取决于业务对格式稳定性的容忍度。这类判断只有拿到同一批数据上的实测数字才好做，凭单次体验下结论很容易翻车。

第七步，归档。把本轮结论写下来：变更项、指标变化、是否采纳、后续观察点。下一次再出现异常时，这份记录就是起点。

注意事项

不要只存输出。缺少 model_name、prompt_version 等执行条件时，事后几乎无法归因，日志的价值会大打折扣。
不要一次改多个变量。模型和提示词同时更换，即使结果改善也分不清功劳归属，反而浪费了一轮实验。
主观质量难以完全量化。文字质量这类维度无法靠数字完全表达，可量化的是输出字数、处理时间、错误率、JSON 成功率、必填项缺失数等机械可查的项目，两者需要配合使用。
固定测试集要覆盖边界情况。如果十件数据全是同类输入，回归测试能发现的偏移会非常有限。
指标波动需要结合样本量看。小样本上的百分比变化可能只是噪声，判断前先确认差异是否稳定复现。
模型标识要写具体。只写「默认模型」这类模糊名称，在服务商调整默认指向后就失去了追溯能力。
涉及价格、配额、可用模型与地区支持等信息，各服务商随时可能调整，请以官网当前公布的信息为准。