# Bad Case To Dpo

把生产 bad case / 失败轨迹转成训练数据时使用, , 从失败归因、轨迹前缀截取、DPO 偏好对构造、LoRA...

- Repository: https://github.com/bojieli/ai-agent-book (56844 stars)
- Category: Engineering
- License: Apache-2.0
- Last updated: 2026-10-08
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add bojieli/ai-agent-book --skill bad-case-to-dpo -g -a claude-code -y`
Codex: `npx skills add bojieli/ai-agent-book --skill bad-case-to-dpo -g -a codex -y`
Cursor: `npx skills add bojieli/ai-agent-book --skill bad-case-to-dpo -g -a cursor -y`
Gemini CLI: `npx skills add bojieli/ai-agent-book --skill bad-case-to-dpo -g -a gemini-cli -y`

## Description

把生产 bad case / 失败轨迹转成训练数据时使用, , 从失败归因、轨迹前缀截取、DPO 偏好对构造、LoRA 训练到边界集与保留集双集验证的完整链路；也用于判断某类问题该走 SFT、DPO、RL 还是先修 Harness/工具/tokenizer，以及如何从运行轨迹中提取带证据的结构化学习信号。触发词：bad case、失败归因、DPO、偏好对、轨迹前缀、拒绝采样、过度矫正、边界集、保留集、过早结束、reward hacking、LoRA 微调、训练评估隔离。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 从问题案例到训练数据

## 何时使用

- 生产出现 bad case：用户纠正、点踩、事后审计发现失败轨迹，想把它变成后训练输入
- 判断某类失败该修 Harness/工具/tokenizer，还是值得投入训练
- 构造 DPO 偏好对、轨迹前缀回归任务、决策边界示范
- 决定一个失败案例该进 SFT 数据、DPO 偏好对、PRM 负标签还是 RLVP 惩罚规则
- 训练后验证修复效果，担心"修好一个、弄坏一片"
- 从运行轨迹中提取可学习信号，而不是只存一个总分

## 核心原则

- **归因到首个错误步骤，不是整条轨迹。** 以 Coding Agent "过早结束"为例：读代码、改代码可能都没错，错的是"在缺乏证据时下结论"那一个决策边界。归因记录必须落到这一步，训练数据才能对着它构造。
- **失败轨迹不应直接当作正确的 SFT 示范。** 它的正确用法是：构造偏好对、发现任务覆盖缺口，或补上诊断与修复后再加入训练。
- **判定必须靠模型写不了的机制。** "是否完成"要由隐藏测试、状态断言或外部终止钩子给出；测试必须读取真实文件或环境状态，不能只检查模型是否说了"已完成"，否则模型会学会口头承诺验证而不真正验证。
- **边界集与保留集缺一不可。** 边界集（任务未完成）看模型是否选择继续验证而非宣称完成；保留集（任务已完成）看模型是否仍能正常收尾。只盯边界集会把模型训练成永远不敢结束的**过度矫正**状态：每个任务都无限验证下去，延迟与成本崩溃。这是"改动不能破坏既有行为"在参数层面的版本。
- **训练与评估严格隔离。** 训练集与评估集必须是不同的任务、不同的参数、不同的模板组合；参考解法、隐藏测试和验证器反馈不能泄露给模型。隔离规则应由单元测试强制检查，而不是靠人记得。
- **先排除非模型原因。** 沿"文件原始字节 → 工具返回 → Harness 序列化 → 模型上下文 → 模型 token 输出 → 解码字符串 → JSON/tool-call 解析 → 工具匹配"逐层对比。只有模型收到的上下文与原始字符串完全一致、而**模型输出是链路上首个出现差异的位置**，才能标为模型能力问题。否则修工具/Harness/tokenizer，修完再看还剩多少。
- **小数据 DPO 必须混入通用任务数据。** 案例数量少时，按小配比混入通用任务做 LoRA 微调，避免把"逢收尾必验证"学成新的过拟合，也降低灾难性遗忘风险。
- **学习信号必须带证据。** 单一总分无法指出该改哪里。可供学习的评价至少包含：任务成功/部分成功/失败、每个维度各自的结论、每条结论对应的证据位置（哪一轮对话、哪一次工具调用）、失败的类型标签。验证器还应被允许在证据不足时**拒绝评分**, , 低置信度案例应排除在学习集之外，而不是当作事实固化。

## 实践模式

### 完整链路：失败归因 → 双集验证

**① 采集与归因。** 从用户纠正、点踩、事后审计三类生产信号收集失败轨迹，按错误分类定位**首个错误步骤**并记录错误类别。轨迹前缀回归任务就是从这个决策边界截取的。

**② 分流：该不该训练。** 先问 prompt、工具、代码约束、上下文管理能否解决；再沿字节链路排除工具/Harness/tokenizer 问题。都不要动权重时就不训练。

**③ 选训练形态。** 按第七章评估数据集的类型映射到第八章用法：

| 你手上的材料 | 训练用法 |
|---|---|
| 端到端回归任务（含验证器） | RL rollout 任务与可验证奖励（RLVR）；拒绝采样（RFT）的采样池 |
| 轨迹前缀回归任务 | DPO 偏好对、决策边界的 SFT 示范、On-Policy Distillation 的教师状态 |
| 失败归因记录（首个错误步骤与错误类别） | 过程监督的负标签（PRM）、RLVP 路径惩罚的规则来源 |
| Rubric 多维评分与人工金标集 | 向量奖励的各维度、生成式奖励模型（GRM）的训练与校准数据 |

**④ 截取轨迹前缀，构造偏好对。** 在决策边界上截出"准备宣称完成"的轨迹前缀：rejected 是过早结束的错误行为，chosen 是"先运行测试、逐条核对验收条件，再下结论"的期望行为。chosen 由教师模型生成，再经规则验证器过滤（拒绝采样）。案例太少时用数据扩充（换任务类型、换缺失的验证项、换完成措辞）形成数百条偏好对。失败原因、适用条件和验证器应随样本保存，方便追溯和复查。

The rest: https://github.com/bojieli/ai-agent-book/blob/HEAD/skills/bad-case-to-dpo/SKILL.md