企业官网建设流程全解析

在工具集成推理（Tool-Integrated Reasoning）任务中，TurnSight 所代表的 turn-level hindsight self-distillation 思路越来越受关注。这类方法的核心不是让模型多读几轮工具返回的结果，而是把每一轮“模型生成 + 工具执行 + 最终反馈”当作一个可学习的样本单元，用事后得到的正确性信号反过来指导当前这一轮怎么生成。对做过多轮工具调用 Agent 的开发者来说，困难通常不在“能不能调工具”，而在“调完工具之后，下一轮如何基于结果修正自己”。传统监督微调只教模型模仿正确路径，结果监督又只给最终答案一个分数，中间哪一步错了很难定位。TurnSight 的思路介于两者之间：不逐 token 打标签，也不只看最终答案，而是对每个 turn 做偏好层面的自蒸馏，让模型从自己的候选轨迹中学习“哪一类动作更可能导向成功”。这篇文章会把这类方法拆成可操作的工程框架，覆盖原理、数据构造、训练流程、评估方法和排错路径，适合正在做 ReAct、Function Calling 或工具调用 Agent 的算法工程师和研究者。

1. TurnSight 要解决的核心问题：工具推理中的反馈粒度太粗，导致模型不知道该修正哪里

1.1 什么是 turn-level，为什么不能只在最终答案上做监督

在工具集成推理任务里，一次完整任务通常包含多轮对话。每一轮里，模型可能输出一段自然语言，也可能输出一个函数调用，然后系统执行工具、把结果返回给模型，模型再根据这些信息决定下一步动作。最终任务结束后，系统只能判断整个任务成功或失败。比如用户问“帮我查北京市今天下午三点到明天上午十点的天气，并计算温差”，模型需要依次查询天气、读取返回结果、计算数值，最后生成汇总。如果只对最终回答打一个正确或错误的标签，模型无法知道是“查询参数错了”“结果解析错了”还是“总结漏了条件”。

Turn-level 做法的基本单位是“一轮完整的交互”。一个 turn 指从模型生成、工具执行到结果返回并再次输入模型的完整过程，而不是模型输出的单个 token。使用 turn 作为学习单位，可以让训练信号直接作用在产生工具调用的位置附近。例如模型在某轮把北京写成了上海，这个 turn 后续导致所有查询和计算都偏离目标，那么 turn-level 训练能够把这个错误和最终失败建立更直接的关联。

一个常见的误区是把 turn-level 当成 token-level 的过程监督。Token 级别过程监督要求在每一个中间推理步骤都给出细粒度标签，比如人工标注哪一行计算错误，这在工具调用场景里成本极高。因为工具调用结果通常是结构化 JSON，错误可能藏在参数名、参数值、调用顺序、异常处理、格式转义等各种位置，逐 token 标注几乎不可行。Turn-level 不需要这么细的标签，它只需要知道这一轮整体是“导致成功的一方”还是“不如另一个候选”，这种信号更容易自动获取。

另一个误区是认为 turn-level 只是把 sequence-level 的最终奖励搬运到每个 turn。实际上不完全是。Sequence-level 使用一次任务最终的成功与否作为训练信号，但多轮任务中早期探索即使失败，也可能不完全是早期决策的问题，也许只是后续步骤没有补救。Turn-level 是在完整路径的 hindsight 信息下重新评价每个 turn，既保留了结果信号，又通过对比候选轨迹避免单轮决策与最终结果因果混淆。

1.2 为什么用 hindsight self-distillation，而不是直接用人工标注或奖励模型

Hindsight 是指用“已经知道最终结果”的视角回看当前 turn。在自我蒸馏（self-distillation）的框架下，模型先生成多条候选路径，然后用成功或失败的结果来筛选、排序、重组这些候选，再让模型从自己和对手的路径中学习。这种方法在无法获得大量人工标注的场景里尤其有价值。

举个例子。模型在某个 turn 生成了两种动作：候选 A 调用了get_weather(city="北京", date="2025-01-01")，候选 B 调用了get_weather(city="上海", date="2025-01-01")。两个动作看起来都符合格式，但后续结果不同。如果人工只看这个 turn 很难判断哪个更优，因为城市本身依赖用户问题。但如果我们先 rollout 到任务结束，发现候选 A 所在路径最后成功了，候选 B 所在路径失败了，那么就可以凭借事后信息给这个 turn 打上偏好：A 优于 B。这个过程就叫 hindsight 引导的 self-distillation。

不使用大型奖励模型的原因主要有两点。第一，工具调用状态空间很大，工具参数、返回结构、状态变化都影响结果，通用奖励模型很难准确判断单步动作好坏。第二，奖励模型本身会引入额外误差，尤其在多轮轨迹上，奖励模型的判断可能被最终文本长度、格式美观度等无关因素干扰。TurnSight 类方法更直接，它依赖工具执行结果或最终答案是否正确，通过候选路径之间的对比形成偏好，而不是凭空打分。

1.3 这种方法适合什么任务，不适合什么任务

适合的任务有以下几个特点。第一，存在可执行且可验证的工具。例如数据库查询、搜索、代码执行、计算器、日历操作。只要工具执行结果能反馈给模型，就能计算路径成功与否。第二，任务可以分解成多个 turn。如果只需要一次工具调用就能完成，turn-level 的意义会减弱。第三，结果判断可以通过规则自动完成，或者用测试集自动判断。

不适合的任务包括纯开放生成、没有工具、或者结果无法自动校验的场景。比如让模型写一首诗，工具不是必需，成功标准主观，hindsight 信号就不好定义。还有一种情况是工具调用有大量副作用，比如电商下单、发送邮件、转账，rollout 会产生真实影响，此时不能无限制地让模型自由探索，需要先用沙箱环境或者模拟工具。

实际工程中，常见的合适载体是 RAG 型 Agent、数据查询助手、代码执行沙箱、API 编排助手。如果工具结果能稳定返回 JSON，并且任务有明确成功条件，建议优先尝试 turn-level self-distillation，而不是直接堆更多人工标注。

2. 方法拆解：TurnSight 的五个核心组件

2.1 Rollout 阶段：为每个问题生成多条候选轨迹

训练数据准备的第一步是 rollout。给定一个用户问题，让当前模型独立完成整个任务，每轮允许调用工具，直到任务结束。同一个问题可以并行采样多条路径，采样温度通常设置在 0.7 到 1.0 之间，温度过低会得到千篇一律的路径，温度过高会产生大量格式错误。采样数量一般在 4 到 16 之间，具体取决于算力。

Rollout 需要记录的不止是最终答案，还包括每一步的完整状态。建议保存为结构化日志：

{ "question": "北京今天下午3点到明天上午10点的温差是多少？", "trajectory_id": "traj_0001", "turns": [ { "turn_index": 1, "messages": [ {"role": "user", "content": "北京今天下午3点到明天上午10点的温差是多少？"}, {"role": "assistant", "content": "", "tool_calls": [{"name": "get_weather", "arguments": {"city": "北京", "start_time": "2025-01-01T15:00:00", "end_time": "2025-01-02T10:00:00"}}]}, {"role": "tool", "name": "get_weather", "content": "{\"city\":\"北京\",\"start_time\":\"...\",\"temp_max\":8,\"temp_min\":-2}"} ] }, { "turn_index": 2, "messages": [ {"role": "assistant", "content": "根据查询结果，北京今天下午3点到明天上午10点的最高气温为8℃，最低气温为-2℃，温差为10℃。"} ] } ], "final_answer": "温差为10℃", "finished": true, "success": true }

这段记录里最重要的是 turn 边界。一个 turn 结束于工具结果返回给模型，而不是以模型输出一条文本为结束。如果模型在同一轮里连续调用两个工具，工程上再拆成两个逻辑子步骤会更利于后续对比，但要保证不破坏模型输入上下文。

2.2 工具执行与结果归一化：错误反馈也值得保留

工具执行阶段经常被忽略，但它决定 hindsight 信号是否可信。推荐把工具返回结果统一格式化，无论成功失败都保留原因代码、错误信息和原始返回。比如调用失败时：

{ "name": "get_weather", "error": true, "error_code": "PARAM_INVALID", "message": "start_time 格式应为 ISO8601", "raw_return": null }

模型在下一轮看到错误信息后，可能生成修正后的调用。这个修正过程非常重要。如果数据构造时只保留成功轨迹，模型就学不到“看到错误后如何修正”。Turn-level self-distillation 的价值之一正是利用错误路径作为反例，让模型知道某些动作会导致失败。

结果归一化还需要注意工具产出的内容长度。如果工具返回超大结果，模型注意力会被长文本稀释，也增加训练成本。常见做法是截断、摘要、字段筛选。比如数据库查询返回 1000 行，只保留前 20 行并提示“结果过长，已截断”，让模型学会通过改写 SQL 缩小范围。

注意：失败的工具返回不要简单丢弃。保留错误消息并让模型在下一轮尝试修正，是工具 Agent 训练中最容易被低估的数据来源。

2.3 Hindsight beacon 的构造：给模型一个“事后才可知”的提示

这是此类方法中比较关键的设计。当模型生成一个 turn 时，它不知道未来结果。但数据构造阶段我们已经知道整条路径最终是否成功，因此可以构造一个 hindsight beacon，相当于“如果你知道这一轮继续下去会失败，你应该换成什么动作”。

Hindsight beacon 不直接修改原对话历史，而是附加一段额外提示。一个常见模板是：

你正在完成一个工具调用任务。上一轮你执行了以下动作： action: get_weather arguments: {"city": "上海", "start_time": "2025-01-01T15:00:00"} 最终结果证明，该动作导致后续查询失败，因为用户需要查询的是“北京”，而不是“上海”。请生成一个更优的下一轮动作。

这个 beacon 不会出现在最终推理时的 prompt 中，它只用于训练阶段构造对比样本。这正是 hindsight 的含义：利用事后信息为当前状态生成改进目标。

实际项目中，beacon 可以由模型自己生成，也可以由规则生成。好处是模型能自然语言描述失败原因，信息量更大；坏处是模型可能编造不存在的因果。更稳妥的方案是先用规则生成结构化反馈，再让模型改写为自然语言，并且只把明确可验证的信息写进 beacon。

2.4 偏好对与蒸馏样本的构造方式

拿到多条候选轨迹后，需要把它们转化为训练样本。常见的两种做法是偏好优化和蒸馏样本重写。

偏好优化要求每个训练样本包含一个输入状态、一个选中动作和一个拒绝动作。输入状态是当前 turn 之前的完整上下文。选中动作来自成功轨迹或更优路径，拒绝动作来自失败轨迹或更差路径。在 DPO（Direct Preference Optimization）框架下，损失函数直接优化策略在偏好对上的概率差，不需要额外训练奖励模型。

构造偏好对时要注意几个细节。第一，只有状态相同或者接近相同的 pair 才有比较意义。如果两个候选在第一个 turn 就使用不同工具，后续轨迹完全分叉，把它们的第一个 turn 直接做对比会产生噪音。第二，不要简单地把“成功路径的每一步”都标记为优于“失败路径的每一步”。长任务里早期几步可能完全一样，只有某个 turn 出现分歧，最清洗的做法是只把分歧点附近 turn 作为对比样本。第三，同一路径内部不能自己和自己比，偏好对必须来自不同 rollout。

对于蒸馏样本，可以用 hindsight beacon 指导模型重新生成当前 turn 的动作，得到改进后的动作作为 SFT 正样本。这类样本可以合并进正常监督训练数据，增强模型在相似状态下选择正确动作的能力。

数据样本示例：

{ "type": "preference", "prompt": [ {"role": "user", "content": "北京今天下午3点到明天上午10点的温差是多少？"}, {"role": "assistant", "content": "", "tool_calls": [{"name": "get_weather", "arguments": {"city": "上海"}}]}, {"role": "tool", "name": "get_weather", "content": "{\"city\":\"上海\",\"temp_max\":15,\"temp_min\":10}"} ], "chosen": { "role": "assistant", "content": "用户查询的是北京，不是上海。需要重新调用 get_weather，city 改为北京。", "tool_calls": [{"name": "get_weather", "arguments": {"city": "北京", "start_time": "2025-01-01T15:00:00", "end_time": "2025-01-02T10:00:00"}}] }, "rejected": { "role": "assistant", "content": "上海今天最高气温为15℃，最低气温为10℃。", "tool_calls": [] } }

2.5 损失目标与训练流程：SFT、DPO 还是混合

实现时可以根据数据形态选择损失函数。如果构造出来的是正样本和负样本，且正样本数量足够，可以直接做 SFT 和负样本抑制。但更常见的是用 DPO 或偏好优化，因为工具调用场景里“两个动作都不错，但一个更可能成功”的情况很多，用对比信号比单纯二分类更稳定。

DPO 的简化理解是：在同一个 prompt 下，模型应该提高 chose 序列的概率，降低 rejected 序列的概率。它不是先训练一个奖励模型，而是把奖励模型和策略之间的闭式关系代入策略优化。训练时要注意，离线偏好对可能包含 inconsistent 样本，同一个状态在多个 pair 中既被选为 chose 又被选为 rejected，这会显著干扰训练，构造时要做去重。

更完整的流程是：

1. 用现有模型 rollout 生成候选轨迹。
2. 用最终结果判断每条轨迹成功与否。
3. 对每个 turn 构造 hindsight beacon。
4. 通过 beacons 生成改进动作或偏好对。
5. 将新样本与原始 SFT 数据混合，比例一般在 1:1 到 1:3 之间。
6. 先做一轮 SFT 增强，再跑 DPO，或者联合优化。
7. 用新模型重新 rollout，进入下一轮迭代。

注意：不要在同一轮迭代里把 DPO 数据重复训练太多次。偏好优化在离线数据上反复迭代容易导致模型只记住训练集中的状态分布，真实推理时反而退化，一轮训练 1 到 2 个 epoch 通常比较稳妥。

3. 从零到一实现一个最小实验框架

3.1 环境依赖与版本策略

实际运行这类实验，建议使用以下基础组件。版本会变化，落地前要确认兼容性，这里的问题在于搜索材料没有给出锁定版本，所以应该使用模糊表述。

学习阶段不需要一次性搭复杂平台，可以按下面的顺序推进：先写好原生的工具执行函数，再实现 rollout 脚本，再构造 pair，最后接训练脚本。这样每个环节都能单独验证。

3.2 数据结构与目录规划

建议使用下面的目录结构：

turnsight_lab/ ├── data/ │ ├── raw_questions.jsonl │ ├── rollout/ │ ├── pairs/ │ └── sft_data/ ├── tools/ │ ├── registry.py │ ├── weather.py │ └── calculator.py ├── rollout/ │ ├── generate.py │ └── evaluator.py ├── training/ │ ├── build_pairs.py │ ├── train_sft.py │ └── train_dpo.py ├── eval/ │ └── evaluate.py └── configs/ ├── sample.yaml └── train.yaml

数据文件使用 JSONL 比较方便，每行一个完整样本。建议在 rollout 阶段就写入原始轨迹，不要直接写入训练样本，因为后续构造 pair 时可能需要重新处理，原始轨迹保留越多信息越容易修正。

3.3 核心代码示例：工具注册与 rollout

先定义一个简单的工具注册表，便于后续替换真实 API：

# tools/registry.py import json TOOL_REGISTRY = {} def register_tool(name): def decorator(func): TOOL_REGISTRY[name] = func return func return decorator def call_tool(name: str, arguments: dict): if name not in TOOL_REGISTRY: return { "name": name, "error": True, "error_code": "TOOL_NOT_FOUND", "message": f"tool {name} not found", "raw_return": None } try: result = TOOL_REGISTRY[name](**arguments) return {"name": name, "error": False, "raw_return": result} except Exception as e: return { "name": name, "error": True, "error_code": "TOOL_EXECUTION_ERROR", "message": str(e), "raw_return": None }

注册两个示例工具：

# tools/weather.py from .registry import register_tool @register_tool("get_weather") def get_weather(city: str, start_time: str = None, end_time: str = None): # 示例实现，实际项目替换为 API 或数据库 if city not in {"北京", "上海"}: raise ValueError("unsupported city") data = { "北京": {"temp_max": 8, "temp_min": -2}, "上海": {"temp_max": 15, "temp_min": 10}, } return data[city] @register_tool("calculate") def calculate(expression: str): # 生产环境不要直接用 eval return {"result": eval(expression)}

Rollout 脚本需要把模型输出解析成工具调用。不同模型对工具调用的输出格式不同，常见的是 OpenAI 风格的tool_calls字段。如果没有现成解析器，可以让模型输出一个严格的 JSON 代码块，然后提取：

# rollout/generate.py import json import re def parse_tool_call(text: str): # 示例解析，只处理单工具调用 json_pattern = r"```json\n(.*?)\n```" match = re.search(json_pattern, text, re.DOTALL) if not match: return None try: data = json.loads(match.group(1)) return { "name": data["name"], "arguments": data["arguments"], } except Exception: return None

实际项目里，更推荐使用推理框架自带的tool_calls结构化输出，比如 vLLM 的chat_template或 OpenAI 兼容接口。手工解析容易漏掉多工具调用场景。

3.4 构造 hindsight 训练样本的代码流程

构造 pair 时，需要按 turn 对齐多个 rollout。下面给一个简化实现，说明思路：

# training/build_pairs.py import json from collections import defaultdict def build_pairs(rollouts): # rollouts: list of dict, 每条包含 question, turns, success grouped = defaultdict(list) for r in rollouts: grouped[r["question"]].append(r) pairs = [] for question, items in grouped.items(): success_paths = [i for i in items if i["success"]] fail_paths = [i for i in items if not i["success"]] if not success_paths or not fail_paths: continue for sp in success_paths: for fp in fail_paths: # 只比较第一个出现分歧的 turn sp_actions = [t["action"]["name"] + json.dumps(t["action"]["arguments"], sort_keys=True) for t in sp["turns"]] fp_actions = [t["action"]["name"] + json.dumps(t["action"]["arguments"], sort_keys=True) for t in fp["turns"]] diff_idx = None for i in range(min(len(sp_actions), len(fp_actions))): if sp_actions[i] != fp_actions[i]: diff_idx = i break if diff_idx is None: continue pairs.append({ "question": question, "turn_index": diff_idx, "prompt_context": sp["turns"][:diff_idx], "chosen_action": sp["turns"][diff_idx]["action"], "rejected_action": fp["turns"][diff_idx]["action"], }) return pairs

这段代码只做最基础的对比，真正的项目还要处理更复杂的对齐：有些轨迹可能在中途提前结束、有些轨迹调用工具次数不同、有些轨迹虽然最终成功但某一步走了弯路。需要结合任务场景增加过滤规则。

构造完 pair 后，需要再把 prompt 转换成模型训练格式。假设训练框架使用 ChatML 格式，则需要把上下文、chosen、rejected 都转成 message 列表：

def to_chatml(context, action): messages = [] for item in context: messages.append({ "role": item.get("role", "user"), "content": item.get("content", ""), "tool_calls": item.get("tool_calls", None), }) messages.append({ "role": "assistant", "content": action.get("content", ""), "tool_calls": action.get("tool_calls", None), }) return messages

注意：不同模型在 tokenizer 层面处理tool_calls的方式不一样。如果在训练时直接把tool_calls放进 message 列表，有些 tokenizer 会忽略它，导致 loss 只计算在自然语言部分，工具调用的 JSON 部分完全没有被监督。这是工具 Agent 训练里很常见的错误，落地前一定要确认 loss 覆盖范围。

3.5 训练脚本：LoRA 微调与 DPO 的平衡

训练阶段不必全参数微调。使用 LoRA 可以在单卡或双卡上完成实验，同时避免灾难性遗忘。下面是一个基于 TRL 的极简示例，实际项目需要修改模型路径和 tokenizer 配置：

# training/train_dpo.py from datasets import load_dataset from trl import DPOTrainer from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments model_path = "Qwen2.5-7B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype="auto", device_map="auto", ) train_dataset = load_dataset("json", data_files="data/pairs.jsonl", split="train") training_args = TrainingArguments( output_dir="outputs/dpo", per_device_train_batch_size=1, gradient_accumulation_steps=8, learning_rate=5e-6, num_train_epochs=1, logging_steps=10, save_steps=100, remove_unused_columns=False, ) trainer = DPOTrainer( model=model, ref_model=None, args=training_args, train_dataset=train_dataset, tokenizer=tokenizer, ) trainer.train()

训练前要先确认数据列名与训练框架一致。TRL 的 DPO 默认使用prompt、chosen、rejected三列，如果你的数据列名不同，需要做映射。另外，如果数据量不到几千条，不要直接训练多个 epoch，建议先看验证集上的工具调用正确率是否提升。

4. 验证与评估：不能只盯着最终 answer 的准确率

4.1 主指标要拆成多层

工具集成推理的评估不能只看最终答案是否包含正确数字，还要看模型是否以合理的路径到达那里。建议至少拆成四层指标：

实践中经常出现 format validity 很高但 final success 很低的情况。这说明模型学会了输出格式，但没有学会正确决策。反过来，format validity 很低但 final success 很高的情况很少见，除非任务太简单，不需要工具也能答对。所以训练时优先保证 format validity 不塌陷。

如果要跑多采样评估，可以计算 pass@1。做法是对每个测试问题采样 N 条轨迹，若任何一条成功则视为通过。采样 4 到 8 条，使用温度 0.7 到 1.0，记录成功率和平均路径长度。除了成功率，还要关注工具调用次数分布。模型经过 DPO 后可能变得过度谨慎，调用工具次数减少，但准确率没有提升，此时需要检查训练数据里是否需要保留更多“继续修正”的正样本。

4.2 评估集选择与脚本化

评估集建议选择有明确可验证答案的数据集，例如多跳问答、表格查询、API 调用类任务。具体用哪个数据集，取决于工具集合。如果没有现成测试集，可以手工构建 100 到 300 条问题，覆盖正常情况、边界情况、缺失参数、歧义表达和工具不可用五种类型。

评估流程要脚本化，建议每个候选模型跑同一份问题集，同一套工具环境，同一组采样参数。工具环境的时间敏感问题要固定 mock 数据，避免因为外部 API 返回变化导致复现困难。示例命令行：

python eval/evaluate.py \ --model_path output/checkpoint-500 \ --data_path eval/questions.jsonl \ --output_path eval/results.jsonl \ --temperature 0.8 \ --num_samples 4 \ --max_turns 8

输出结果建议包含每个问题的最终状态、工具调用次数、每轮解析结果、错误日志。这样即使最终成功，也能排查是否走了不必要的弯路。

4.3 消融实验怎么设计

要证明 turn-level hindsight self-distillation 有效，至少要对比以下几组：

1. 基础 SFT 模型：只用人类标注或原始正样本训练，不加 hindsight。
2. 结果监督 DPO：直接用最终任务成功与否给整条轨迹打偏好。
3. Turn-level DPO：按本文方法构造 turn 级偏好对。
4. Turn-level DPO + hindsight beacon 重写：在构造 pair 时使用改进动作，而不只是直接用原轨迹动作。

对比时固定训练步数和数据量，否则无法判断差异来自方法还是数据量。一个更细的消融是只在某一个 turn 加入判断，比如在第一个工具调用后、第二个工具调用后分别评测模型修正能力。工具调用场景里特别值得关注的是“错误发生后模型能不能在下一轮自我修正”，这个能力可以直接用一个子测试集衡量：每道题给模型一个故意错误的历史上下文，看模型是否生成正确修正调用。

4.4 结果解读：成功率提升不代表方法有效

如果最终成功率和格式合法性同时提升，可以初步认为方法有效。但如果只提升了格式合法性而最终成功率没有变化，大概率是 DPO 数据让模型学会了更好看的输出，没有学会更好决策。此时需要检查偏好对构造是否准确。

另外要注意训练分布和评测分布的偏移。如果 rollout 阶段使用的工具返回结果与评测阶段不一致，模型可能记住训练工具返回结果，评测时反而表现更差。固定 mock 数据可以避免这个问题，但真实场景必须定期更新工具环境。

5. 常见坑与排查路径

5.1 工具调用格式正常，但参数和意图严重偏离

现象：模型每个 turn 都输出了合法 JSON，工具也执行成功，但最终答案完全错误。比如用户要查询北京天气，模型却查询了上海天气，且后续所有计算都基于上海数据。

可能原因：训练数据里成功轨迹的上下文与失败轨迹差异太早，模型没有把“城市名来自用户问题”这个因果关系学到。也可能是 rollout 时采样温度过高，模型在早期 turn 出现随机性错误，但最终路径成功，导致该错误样本被当成正样本进入训练。

排查方式：检查 rollouts 中成功轨迹里是否包含早期错误参数。比如成功轨迹里第一个调用参数与最终正确答案不一致，但后续又调用了两次才修正。这类轨迹如果直接当正样本，会污染偏好数据。

解决方式：构造正样本时，不能只看最终 success。建议加入“路径质量”规则，比如第一个工具调用参数与人工参考一致才算高质量轨迹。也可以把这类“先错后改”的轨迹独立保留，用于训练修正能力，而不是当作完美正样本。

5.2 Hindsight 信息泄露到推理阶段

现象：训练后的模型在推理阶段回答问题时会自言自语“根据最终结果，这一步应该选北京”，或者直接输出 final answer 而不调用工具。这说明模型学会了模仿 hindsight beacon 中的事后表述，但没有学会从对话上下文中推断。

发生原因：训练样本的 chosen 动作里包含了 hindsight 的语言描述，比如“用户查询的是北京，不是上海”，但真实推理时模型没有这个提示，于是用猜测填补空白。

排查方式：检查生成结果中是否出现“最终结果证明”“应该”这类事后口吻的词语。还可以做压力测试：给模型提供部分错误工具结果，看它是选择修正还是直接编造答案。

解决方式：将 hindsight beacon 与最终动作分开。beacon 只用于生成训练目标，但在最终训练样本中，不要显式保留“最终结果证明”这类文字。更好的做法是让模型直接输出修正后的工具调用，中间反思文本在推理时不要依赖。

注意：训练数据中任何“事后才知道的信息”都不能出现在推理时可观测的上下文里，否则模型会把幻觉当成推理。数据审核时要用脚本扫描训练样本，标记包含“最终结果”“成功”“失败”等 hindsight 关键词的 assistant 文本。

5.3 多工具调用陷入死循环

现象：模型反复调用同一个工具，即使返回结果已经明确错误，模型仍不结束任务，直到 max_turns 耗尽。

原因：多轮训练数据里缺少“工具错误时应该终止或更换策略”的样本。模型学到的模式是“只要工具返回 JSON 就继续调用”，没有学会根据错误码判断是否应该停止。

排查方式：统计每条轨迹的工具调用次数分布。如果很多轨迹都在 max_turns 处截断，说明模型缺少终止能力。查看日志中错误码出现后模型的下一轮动作，如果仍然使用同参数调用，就是循环。

解决方式：在 rollout 脚本中增加终止规则，如连续两次同类错误直接标记为失败轨迹。在训练数据中显式加入“工具返回错误后，模型告诉用户无法完成并解释原因”的正样本。同时可以在每个 turn 的 prompt 中加入“如果工具返回错误，请说明问题并询问用户”而不是继续盲目调用。

5.4 DPO 迭代发散和偏好噪音

现象：第一轮 DPO 后指标提升，第二轮或第三轮指标骤降，生成内容重复、格式崩溃。

原因：离线偏好数据存在噪音，同一状态在不同 pair 中的标签可能是相反的。训练轮次过多会让模型过度拟合这些冲突标签。另外，DPO 对数据质量非常敏感，如果 chosen 和 rejected 之间只有细微措辞差异，模型无法学到有效偏好，只会放大概率分布。

排查方式：计算 pair 的 chosen/rejected 之间 token 级别相似度。相似度太高说明 pair 区分度不够。还要统计同一个 prompt 是否在多个 pair 中出现且标签冲突。

解决方式：构造 pair 时要求 chosen 和 rejected 的动作序列在参数层面至少有明显差异。比如一个调用了get_weather(city="北京")，另一个调用get_weather(city="上海")，这种 pair 才有学习价值。如果是文本措辞不同，建议过滤。每轮 DPO 后都采样新数据重新评估，而不是在旧数据上反复训练。

5.5 训练 loss 里没有覆盖工具调用 JSON

现象：训练时 loss 下降，但工具调用格式正确率没有提升。

原因：很多 tokenizer/chat template 对tool_calls字段不做特殊处理，训练时该部分 token 被 mask 掉，模型只在自然语言部分计算 loss。这样模型就学不到工具调用格式。

排查方式：训练时打印每批样本的labels，人工检查工具调用 JSON 对应的 token 是否保留。也可以训练后直接让模型生成工具调用，如果格式依然混乱，多半是 loss 覆盖问题。

解决方式：使用支持 tool calling 的 chat template，或者把工具调用改成显式的纯文本格式，确保tool_calls作为 assistant 消息的一部分参与 loss 计算。更简单的方式是把工具调用表示成代码块，模型先输出自然语言，再输出严格的 JSON 代码块，然后解析。

6. 工程落地的可复用清单与扩展方向

6.1 学习环境与生产环境的差异

这类实验在 notebook 和单机开发环境中很容易跑通，但进入生产环境时，至少还要补上日志、权限、监控、回滚、工具沙箱和数据版本管理。

学习阶段可以跳过很多生产细节，但要注意数据格式规范和工具调用解析逻辑，避免后期迁移时重构。

6.2 数据质量与发布前检查清单

构造训练数据时，每次生成新数据集后建议按下面的清单检查：

1. 用户问题是否去重，难度分布是否覆盖简单、中等、困难。
2. 工具返回结果是否统一为 JSON，错误信息是否保留。
3. 每条轨迹是否有明确的 success 字段，以及判断依据。
4. 偏好对是否有冲突标签，同一 prompt 是否重复出现。
5. 正负样本中是否混入“格式正确但路径绕远”的轨迹。
6. 训练样本里是否出现 hindsight 关键字。
7. assistant 消息中是否包含工具调用，且对应 tool 消息确实存在。
8. 工具调用的参数是否与用户问题中的实体一致。
9. 模型生成最终答案前是否完成足够工具调用，还是直接猜测输出。

6.3 训练与评估清单

发布训练任务前，建议确认以下配置：

• 基础模型是否支持工具调用模板，是否用正确的 tokenizer。
• LoRA 训练时是否覆盖工具调用 JSON token。
• 训练数据量是否足够，一般至少几百到数千条有效 pair，太少时用 SFT 增强更稳妥。
• DPO 参考模型是否和训练模型同源，避免两个模型 tokenizer 不一致。
• 评估集与训练集问题是否重叠，避免数据泄漏导致指标虚高。
• rollout 采样参数是否和评估参数一致。

上线前可以做一个最小回归测试：准备 10 个标准化问题，覆盖工具调用成功、参数修正、工具错误、超时终止、拒绝回答五类场景。模型必须在这 10 个问题上达到预期行为，才能进入更大规模评测。

6.4 可扩展方向

Turn-level hindsight self-distillation 不是只能用在 DPO 上。可以往以下方向扩展：

• 与蒙特卡洛树搜索或 best-of-n 重排序结合，用 hindsight 评分对候选轨迹进行更细的剪枝。
• 将 hindsight beacon 扩展为自动生成的子目标，而不是只输出改进动作。
• 与多模型蒸馏结合，让强模型辅助生成 hindsight 提示，但注意不要把强模型的幻觉带进来。
• 在线版本：在模型部署后收集真实用户反馈，把失败轨迹定期离线重新构建偏好对，形成持续迭代闭环。
• 长上下文工具 Agent：把 turn 级偏好扩展到 multi-turn memory 管理，判断模型当前是否需要总结历史或查询外部存储。

这些方向里，最容易出成果的是“先跑通离线闭环”：让模型在固定工具集上 rollout，构造 turn-level pair，训练 DPO，再 rollout，形成一轮完整迭代。只要这个闭环能稳定提升最终任务成功率，方法就可以逐步扩展到更大工具集和更复杂的生产场景。

6.5 最后要记住的核心判断

TurnSight 这类方法的核心不是发明一个新损失函数，而是把训练信号的粒度从 sequence 下沉到 turn，再用事后信息构造偏好数据。它能在人工标注不足、过程标签难以获取的工具推理场景中显著缓解“不知道错在哪一步”的问题。

实际项目里最值得投入的环节不是训练代码，而是数据构造和评估链路。一对干净、无泄漏、区分度明显的偏好样本，比多跑一轮 DPO 更有价值。建议第一次尝试时，先手工检查 20 条样本，确认 chosen 动作明显优于 rejected 动作，再进入完整训练流程。对新手来说，把一个小型 mock 工具集上的训练闭环跑通，再扩展到真实 API，是最稳妥的路线。