Prompt 回归问题治理
团队已经有评测脚本，仍然可能反复遇到同一类 Prompt 回归：有人改了提示词，有人认为评分不准，有人直接放行，上线后又找不到完整的旧配置。缺少的不是另一个总分，而是从发现问题到关闭问题的责任链。
本文提供一套可落地的治理设计，示例均为说明流程而构造，不代表真实客户事故或实测收益。评测脚本与 CI 接线已在 LLM 评测接入 CI 中介绍，这里重点讨论谁判断、按什么证据判断，以及判断之后如何执行。
一、先定义什么才算回归问题
回归指原来满足的行为要求，在可比较条件下被新版本破坏。用户觉得语气不好、总分小幅变化、一次随机输出异常，都值得记录，但不应未经确认就归因到最新 Prompt。
建立问题单时，先固定任务输入、预期行为、实际行为和变化范围。比如“回答变差了”无法复现，而“同一份文档中已有合同到期日，新版回答未提取，旧版能提取”可以进入对照评测。若没有旧版结果，先把它登记为缺陷线索，不强行贴回归标签。
还要检查被比较的是否只有提示词。模型、检索结果、工具返回、输出上限和后处理逻辑变化，都可能影响答案。今天新增文章讨论的 stop sequence 边界 就是一例：字段消失可能源于截断，而不是模型没理解要求。
二、每个问题只设一位闭环负责人
负责人不必亲自修复所有问题，但要保证证据、决定和结果能串起来。小团队可以一人兼多个职责，不能让同一个问题在产品、算法和后端之间无限转交。
| 职责 | 必须交付的东西 | 不能替代什么 |
|---|---|---|
| 问题负责人 | 可复现材料、状态更新 | 不能只转发投诉 |
| 业务验收人 | 正确行为和不可接受边界 | 不能只说更自然 |
| 变更作者 | 最小修复、影响说明 | 不能只交新版 Prompt |
| 评测维护人 | 样本与评分规则版本 | 不能只给一个总分 |
| 发布执行人 | 放行记录及回滚准备 | 不能替业务接受风险 |
首次分派按故障所在链路决定。证据显示问题来自检索时，负责人可以转交，但必须保留已有结论和下一步验证项。转交成功的标准是接收方明确承担后续处理，而不是消息发出去就关闭原问题。
三、样本进入回归集之前需要审核
用户反馈不能直接等同于标准答案。先确认材料是否允许用于评测，删除身份信息、凭据和无关业务内容，再由业务验收人写明必要事实与可接受的回答范围。无法安全复用的材料，可以保留结构特征并制作合成样本，但要标明来源类型。
每个样本建议记录错误类型、风险等级、归属业务、来源日期、判断依据和维护人。修复某一失败样本之后，不要只留下完全相同的输入；增加能检验规则的变体，例如日期格式变化、资料缺失和相互矛盾，防止提示词只记住单个例子。
同时保留一组未参与日常调优的验收样本。把线上失败不断加入测试集的方向，与 OpenAI 官方关于持续评测和扩展数据集的建议一致；具体样本准入和责任分配则应由团队按业务制定。OpenAI 评测最佳实践
样本也会过期。业务规则改变时应更新其依据和生效范围，旧规则样本可以归档保留，不能悄悄修改预期答案后继续拿历史分数比较。
四、评分争议必须回到行为标准
模型评分器给低分，业务人员却认为可接受时，先看评分项是否混合了事实正确、语气、长度和排版。一个总分通常不足以解释分歧。把问题拆成必要字段是否存在、是否引用正确来源、是否有无依据结论，以及风格是否符合要求。
涉及精确字段的部分优先使用确定性检查；语义判断可用评分器辅助，并抽取争议样本做人工复核。复核人员最好在不知道新旧版本标签的情况下先判断，再看版本差异，减少“新版应该更好”的预期影响。
如果证据显示是评分器误判，单独提交评分规则变更，并用旧输出重新评分。不能一边修改 Prompt，一边放宽评分标准，再把总分上升解释成质量改善。对于仍有争议的关键案例，记录双方依据和最终决策人，避免下一次出现相同争论时从头开始。
五、发布例外要有期限和退出条件
上线门槛应区分不可妥协的行为与可以权衡的体验指标。泄露受保护信息、执行未授权操作或关键数据错误，不能被其他样本的高分抵消。风格偏好和非关键冗长可以作为单独的改善项处理，前提是业务接受影响。
若需要带着已知缺陷小范围发布，至少写清受影响场景、暂时接受的原因、负责修复的人、观察指标、截止时间和回滚条件。这不是让每次改字都走复杂审批，而是防止一次临时决定永久消失在聊天记录里。
以下记录是治理示例，字段取值应按团队实际流程填写：
change_id: prompt-example
owner: team-owner
baseline_bundle: bundle-before
candidate_bundle: bundle-after
evaluation_set: acceptance-set-version
known_issue: optional-format-difference
exception_expires: release-review-date
rollback_target: bundle-before发布前确认回滚对象仍然可用，并验证它与当前检索、工具及输出解析器兼容。仅保存一段旧提示词，不一定足够恢复旧行为。
六、恢复之后还要完成关闭验收
回滚能止损，但不代表根因已经修复。问题状态可以分为待确认、已复现、已控制影响、修复验证和关闭。每一步只需要附上能够支撑状态变化的证据，不必写长篇事故报告。
关闭至少检查三件事：原始失败能够被测试捕获，修复通过相关样本及重要相邻场景，线上观察没有再次出现同类风险。对于概率性行为，应预先确定重复评测方式和可接受范围，不因单次通过就宣布解决。
治理指标可以看重复出现的问题占比、问题定位所需时间和过期例外数量。不要把“工单关闭很多”直接当成质量提升，也不要鼓励为了缩短处理时间而删除难样本。真正有用的记录能让下一位维护者看懂当时为什么放行、怎么回滚、哪些条件仍需观察。
小团队起步时，只需一张问题表、一份版本化的配置清单和明确的发布负责人。先保证重要回归都能走完闭环，再逐步自动化评分、汇总和提醒，比堆出无人维护的治理平台更容易持续执行。