在工具集成推理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北京, date2025-01-01)候选 B 调用了get_weather(city上海, date2025-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 之前的完整上下文。选中动作来自成功轨迹或更优路径拒绝动作来自失败轨迹或更差路径。在 DPODirect 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_weathercity 改为北京。, 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这会显著干扰训练构造时要做去重。更完整的流程是用现有模型 rollout 生成候选轨迹。用最终结果判断每条轨迹成功与否。对每个 turn 构造 hindsight beacon。通过 beacons 生成改进动作或偏好对。将新样本与原始 SFT 数据混合比例一般在 1:1 到 1:3 之间。先做一轮 SFT 增强再跑 DPO或者联合优化。用新模型重新 rollout进入下一轮迭代。注意不要在同一轮迭代里把 DPO 数据重复训练太多次。偏好优化在离线数据上反复迭代容易导致模型只记住训练集中的状态分布真实推理时反而退化一轮训练 1 到 2 个 epoch 通常比较稳妥。3. 从零到一实现一个最小实验框架3.1 环境依赖与版本策略实际运行这类实验建议使用以下基础组件。版本会变化落地前要确认兼容性这里的问题在于搜索材料没有给出锁定版本所以应该使用模糊表述。组件作用常见选择基础模型执行推理和工具调用Qwen2.5-7B-Instruct、LLaMA-3.1-8B-Instruct 等开源模型推理服务加速 rolloutvLLM、SGLang 等训练框架加载模型并执行 LoRA/DPOtransformers、TRL、LLaMA-Factory 等工具执行环境安全执行工具调用本地 Python 沙箱、模拟 API、Docker数据管理记录轨迹与样本JSONL、SQLite、WB学习阶段不需要一次性搭复杂平台可以按下面的顺序推进先写好原生的工具执行函数再实现 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: ftool {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 rjson\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_keysTrue) for t in sp[turns]] fp_actions [t[action][name] json.dumps(t[action][arguments], sort_keysTrue) 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_codeTrue) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypeauto, device_mapauto, ) train_dataset load_dataset(json, data_filesdata/pairs.jsonl, splittrain) training_args TrainingArguments( output_diroutputs/dpo, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate5e-6, num_train_epochs1, logging_steps10, save_steps100, remove_unused_columnsFalse, ) trainer DPOTrainer( modelmodel, ref_modelNone, argstraining_args, train_datasettrain_dataset, tokenizertokenizer, ) trainer.train()训练前要先确认数据列名与训练框架一致。TRL 的 DPO 默认使用prompt、chosen、rejected三列如果你的数据列名不同需要做映射。另外如果数据量不到几千条不要直接训练多个 epoch建议先看验证集上的工具调用正确率是否提升。4. 验证与评估不能只盯着最终 answer 的准确率4.1 主指标要拆成多层工具集成推理的评估不能只看最终答案是否包含正确数字还要看模型是否以合理的路径到达那里。建议至少拆成四层指标指标含义计算方式备注Format validity工具调用是否格式合法模型输出能否被解析为工具调用 JSON多轮任务中每轮都要计算Tool call accuracy工具名和参数是否正确与参考调用对比参数严格匹配或部分匹配Turn success rate单个 turn 是否成功推进任务自定义规则例如工具调用无错误且朝目标前进需要人工抽检Final task success rate整个任务是否完成最终答案比对或执行器验证主结果指标实践中经常出现 format validity 很高但 final success 很低的情况。这说明模型学会了输出格式但没有学会正确决策。反过来format validity 很低但 final success 很高的情况很少见除非任务太简单不需要工具也能答对。所以训练时优先保证 format validity 不塌陷。如果要跑多采样评估可以计算 pass1。做法是对每个测试问题采样 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 有效至少要对比以下几组基础 SFT 模型只用人类标注或原始正样本训练不加 hindsight。结果监督 DPO直接用最终任务成功与否给整条轨迹打偏好。Turn-level DPO按本文方法构造 turn 级偏好对。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 和单机开发环境中很容易跑通但进入生产环境时至少还要补上日志、权限、监控、回滚、工具沙箱和数据版本管理。维度学习实验生产系统工具执行直接调用本机函数Docker/K8s 沙箱限制网络、文件系统、超时数据存储JSONL 文件对象存储 数据库版本管理模型服务单卡脚本vLLM 多副本接口层做限流评估本地评测脚本回归集 线上监控指标回滚checkpoint 手动切换模型服务版本化自动 rollback权限无防止模型调用高危工具需要审批流日志打印到控制台全链路 trace保存每轮工具请求和响应学习阶段可以跳过很多生产细节但要注意数据格式规范和工具调用解析逻辑避免后期迁移时重构。6.2 数据质量与发布前检查清单构造训练数据时每次生成新数据集后建议按下面的清单检查用户问题是否去重难度分布是否覆盖简单、中等、困难。工具返回结果是否统一为 JSON错误信息是否保留。每条轨迹是否有明确的 success 字段以及判断依据。偏好对是否有冲突标签同一 prompt 是否重复出现。正负样本中是否混入“格式正确但路径绕远”的轨迹。训练样本里是否出现 hindsight 关键字。assistant 消息中是否包含工具调用且对应 tool 消息确实存在。工具调用的参数是否与用户问题中的实体一致。模型生成最终答案前是否完成足够工具调用还是直接猜测输出。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是最稳妥的路线。 Turn级事后自我蒸馏：工具调用Agent训练新范式
在工具集成推理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北京, date2025-01-01)候选 B 调用了get_weather(city上海, date2025-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 之前的完整上下文。选中动作来自成功轨迹或更优路径拒绝动作来自失败轨迹或更差路径。在 DPODirect 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_weathercity 改为北京。, 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这会显著干扰训练构造时要做去重。更完整的流程是用现有模型 rollout 生成候选轨迹。用最终结果判断每条轨迹成功与否。对每个 turn 构造 hindsight beacon。通过 beacons 生成改进动作或偏好对。将新样本与原始 SFT 数据混合比例一般在 1:1 到 1:3 之间。先做一轮 SFT 增强再跑 DPO或者联合优化。用新模型重新 rollout进入下一轮迭代。注意不要在同一轮迭代里把 DPO 数据重复训练太多次。偏好优化在离线数据上反复迭代容易导致模型只记住训练集中的状态分布真实推理时反而退化一轮训练 1 到 2 个 epoch 通常比较稳妥。3. 从零到一实现一个最小实验框架3.1 环境依赖与版本策略实际运行这类实验建议使用以下基础组件。版本会变化落地前要确认兼容性这里的问题在于搜索材料没有给出锁定版本所以应该使用模糊表述。组件作用常见选择基础模型执行推理和工具调用Qwen2.5-7B-Instruct、LLaMA-3.1-8B-Instruct 等开源模型推理服务加速 rolloutvLLM、SGLang 等训练框架加载模型并执行 LoRA/DPOtransformers、TRL、LLaMA-Factory 等工具执行环境安全执行工具调用本地 Python 沙箱、模拟 API、Docker数据管理记录轨迹与样本JSONL、SQLite、WB学习阶段不需要一次性搭复杂平台可以按下面的顺序推进先写好原生的工具执行函数再实现 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: ftool {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 rjson\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_keysTrue) for t in sp[turns]] fp_actions [t[action][name] json.dumps(t[action][arguments], sort_keysTrue) 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_codeTrue) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypeauto, device_mapauto, ) train_dataset load_dataset(json, data_filesdata/pairs.jsonl, splittrain) training_args TrainingArguments( output_diroutputs/dpo, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate5e-6, num_train_epochs1, logging_steps10, save_steps100, remove_unused_columnsFalse, ) trainer DPOTrainer( modelmodel, ref_modelNone, argstraining_args, train_datasettrain_dataset, tokenizertokenizer, ) trainer.train()训练前要先确认数据列名与训练框架一致。TRL 的 DPO 默认使用prompt、chosen、rejected三列如果你的数据列名不同需要做映射。另外如果数据量不到几千条不要直接训练多个 epoch建议先看验证集上的工具调用正确率是否提升。4. 验证与评估不能只盯着最终 answer 的准确率4.1 主指标要拆成多层工具集成推理的评估不能只看最终答案是否包含正确数字还要看模型是否以合理的路径到达那里。建议至少拆成四层指标指标含义计算方式备注Format validity工具调用是否格式合法模型输出能否被解析为工具调用 JSON多轮任务中每轮都要计算Tool call accuracy工具名和参数是否正确与参考调用对比参数严格匹配或部分匹配Turn success rate单个 turn 是否成功推进任务自定义规则例如工具调用无错误且朝目标前进需要人工抽检Final task success rate整个任务是否完成最终答案比对或执行器验证主结果指标实践中经常出现 format validity 很高但 final success 很低的情况。这说明模型学会了输出格式但没有学会正确决策。反过来format validity 很低但 final success 很高的情况很少见除非任务太简单不需要工具也能答对。所以训练时优先保证 format validity 不塌陷。如果要跑多采样评估可以计算 pass1。做法是对每个测试问题采样 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 有效至少要对比以下几组基础 SFT 模型只用人类标注或原始正样本训练不加 hindsight。结果监督 DPO直接用最终任务成功与否给整条轨迹打偏好。Turn-level DPO按本文方法构造 turn 级偏好对。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 和单机开发环境中很容易跑通但进入生产环境时至少还要补上日志、权限、监控、回滚、工具沙箱和数据版本管理。维度学习实验生产系统工具执行直接调用本机函数Docker/K8s 沙箱限制网络、文件系统、超时数据存储JSONL 文件对象存储 数据库版本管理模型服务单卡脚本vLLM 多副本接口层做限流评估本地评测脚本回归集 线上监控指标回滚checkpoint 手动切换模型服务版本化自动 rollback权限无防止模型调用高危工具需要审批流日志打印到控制台全链路 trace保存每轮工具请求和响应学习阶段可以跳过很多生产细节但要注意数据格式规范和工具调用解析逻辑避免后期迁移时重构。6.2 数据质量与发布前检查清单构造训练数据时每次生成新数据集后建议按下面的清单检查用户问题是否去重难度分布是否覆盖简单、中等、困难。工具返回结果是否统一为 JSON错误信息是否保留。每条轨迹是否有明确的 success 字段以及判断依据。偏好对是否有冲突标签同一 prompt 是否重复出现。正负样本中是否混入“格式正确但路径绕远”的轨迹。训练样本里是否出现 hindsight 关键字。assistant 消息中是否包含工具调用且对应 tool 消息确实存在。工具调用的参数是否与用户问题中的实体一致。模型生成最终答案前是否完成足够工具调用还是直接猜测输出。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是最稳妥的路线。