长视界搜索智能体的训练最棘手的问题往往不是“模型会不会搜索”而是“模型怎么知道自己哪一步走对了”。搜索类任务通常包含大量中间步骤搜索路径长、分支多最终答案正确不代表每一步都有价值最终答案错误也不代表整条轨迹毫无意义。这种“轨迹很长、反馈很少、过程难以评估”的局面正是强化学习中的信用分配问题Credit Assignment在 LLM Agent 场景下的核心挑战。本文围绕 ABSeeker 展开。ABSeeker 是一套面向 Long-Horizon Search Agents 的训练框架核心机制是 Answer-Backtracked Credit Assignment也就是答案回溯信用分配。它把最终答案作为监督信号回溯到搜索轨迹的每一步自动生成密集、可解释的步骤级信用信号。相比人工标注中间步骤、训练额外奖励模型或做显式树搜索ABSeeker 在训练成本、可扩展性和可解释性上都有明显优势。读完本文你可以掌握长视界搜索智能体训练为什么难ABSeeker 的原理与算法流程一份简化版 Python 实现以及工程落地中的常见问题和最佳实践。1. 背景为什么长视界搜索智能体难训练1.1 什么是 Long-Horizon Search Agent搜索智能体Search Agent是指以 LLM 为策略模型在开放环境中通过多轮交互完成复杂任务的智能体。它不只是一次性生成答案而是会调用搜索引擎、检索知识库、阅读网页、抽取证据、提出子问题、验证结论最后整合信息给出答案。Long-Horizon 体现在两个层面。第一是步骤多一个复杂查询可能对应十几次甚至几十次工具调用第二是探索空间大同一问题可以有不同的拆解方式和检索路线智能体需要在众多分支中做出选择。典型任务包括多跳问答Multi-Hop QA、知识密集型推理、程序合成、科学文献调研等。这类智能体的价值在于它们不再依赖模型参数中“记住”的知识而是通过实时查询外部信息来回答问题。这种方式减少了幻觉也扩展了模型的能力边界。然而训练这样的智能体难点恰恰不在“搜索动作”本身而在于如何让模型学会优化自己的搜索策略。1.2 训练信号稀疏长视界任务的核心痛点短任务可以靠最终答案直接打一次分但长视界搜索任务无法这么做。原因有几个第一最终奖励只能反映整条轨迹的质量无法指出哪一步出了问题。比如模型先问了三个正确子问题最后一步检索错了结果答案错误。如果只给它一个负奖励模型并不知道前三步是对的。第二中间步骤的正确性很难用规则判断。自然语言搜索动作没有固定格式很难像游戏棋局那样明确判断某个状态的优劣。第三人工标注中间步骤成本极高。一条长轨迹可能包含十几个步骤标注员需要逐一判断每个步骤是否合理、是否冗余、是否导向正确答案。这种标注既贵又不稳定难以规模化。第四采样成本高。一条搜索轨迹可能需要调用数十次 LLM 和搜索接口如果只保留最终答案正确的轨迹大量计算资源都被浪费了。所以长视界搜索智能体的训练本质上是在解决一个问题如何从稀疏的结果奖励中恢复出密集的、可用的过程监督信号。1.3 信用分配从最终答案到中间步骤信用分配Credit Assignment是强化学习的经典问题。它的核心是当系统最终获得一个奖励时如何把这个奖励归因到导致该结果的一系列动作上。在 LLM 搜索任务中信用分配变得更难。游戏环境里每个状态可以用数值向量表示但搜索轨迹中的每一步是自然语言子问题、检索关键词或抽取结果这些动作之间没有明确的状态转移矩阵无法直接计算贡献度。一个直觉做法是既然最终答案能够反映问题结论那我们可以从答案出发反向检查轨迹中的每一步是否与答案一致。如果某一步提出的约束条件被最终答案满足那这一步大概率是有效的如果某一步的约束条件与最终答案矛盾那这一步大概率把模型引向了错误方向。这正是 ABSeeker 的核心思想。它不做复杂的状态价值估计而是用“答案回溯”这种直观的操作把结果信号翻译成步骤级信用。1.4 ABSeeker 一句话定义ABSeeker 是一套面向长视界搜索智能体的训练框架通过 Answer-Backtracked Credit Assignment 机制从最终答案自动生成密集的步骤级信用信号再借助偏好优化或强化学习更新策略模型。它的特点是不需要额外训练奖励模型不需要人工标注每个中间步骤只需要最终答案作为监督信号就能完成过程级信用分配。这个设计让它比传统方法更轻量、更适合实际工程落地。2. 相关工作ABSeeker 解决了什么痛点2.1 结果监督与采样过滤简单但浪费最朴素的做法是结果监督。模型对同一个问题采样多条搜索轨迹只保留最终答案正确的轨迹然后做监督微调或强化学习。WebGPT、STaR 等方法都属于这个路线。这类方法的优点是简单直接不需要额外模型。但缺点也很明显它把整条轨迹当成一个整体来学习无法区分轨迹内部哪些步骤有效、哪些步骤冗余。一条轨迹可能前几步正确、后几步错误但在结果监督下整条轨迹会被一起丢弃或一起保留信噪比很低。另一个问题是计算浪费。为了获得有限几条正确轨迹可能需要采样大量候选成本很高。2.2 过程奖励模型信号密集但成本高过程奖励模型Process Reward Model会为每个中间步骤输出一个分数提供密集的过程监督。训练时通常需要人工标注每个步骤的质量或者让一个强模型为每个步骤生成监督标签。理论上过程奖励模型能解决信号稀疏问题。但实际工程中训练过程奖励模型本身就需要大量标注数据而且奖励模型的判断可能有偏差。如果奖励模型本身不够准确用它去微调策略模型反而会把偏差放大。ABSeeker 的路线不同它不学习显式的奖励模型而是从答案中直接推导步骤信用相当于一种“免训练”的过程信号生成方式。2.3 显式搜索增强MCTS 类方法的代价另一类方法是把推理过程建模为显式搜索例如在解码过程中使用蒙特卡洛树搜索MCTS。智能体在搜索树中维护多个候选状态通过值函数或自我评估决定扩展哪些节点。这类方法在推理时通常表现更强但训练和推理的计算量都很大。值函数估计依然存在偏差而且把自然语言推理完整建模为树搜索工程复杂度很高。ABSeeker 并不排斥搜索它更关注“训练阶段如何利用答案生成信用信号”。因此它可以与多种策略优化方法结合而不需要额外引入一套树搜索基础设施。2.4 ABSeeker 的定位总结简单说ABSeeker 处于“稀疏结果奖励”和“密集过程奖励”之间它从最终答案中自动恢复过程信号信号质量接近过程奖励但获取成本接近结果监督。这使得它特别适合那些步骤可以结构化描述的搜索任务比如多跳问答、工具调用型 Agent、模拟环境中的探索任务。对工程团队来说ABSeeker 的落地成本远低于训练一套独立奖励模型。3. ABSeeker 核心原理答案回溯信用分配3.1 总体训练流程ABSeeker 的训练流程可以拆成两阶段。第一阶段是探索阶段。策略模型对每个查询采样多条搜索轨迹每条轨迹包含若干步骤和最终答案。每个搜索步骤除了自然语言内容外还附带一个“约束描述”用来表示该步骤对最终结论的预期。第二阶段是学习阶段。拿到轨迹后系统根据最终答案回溯检查每一步的约束是否被满足从而计算每个步骤的信用得分。然后这些信用得分被转换成偏好对或加权损失用于更新策略模型。整个流程可以概括为生成轨迹 → 答案回溯 → 计算步骤信用 → 策略优化。3.2 答案回溯机制把答案变成约束答案回溯的关键观察是最终答案本身携带了对搜索路径的约束信息。举个例子如果问题问“某音乐家是否在某乐团中演出”最终答案是“是”。那么凡是提出“检索音乐家与乐团关系”的步骤都与答案一致凡是把问题引向“作曲家生平”的步骤都与答案矛盾。因此ABSeeker 把每个搜索步骤抽象为一组约束条件。一个步骤的约束条件是否被最终答案满足直接决定了该步骤的信用方向。这种操作方法不需要额外的奖励模型也不需要过程标注只要最终答案足够可靠就能回溯出步骤级的监督信号。实现上约束满足的判断既可以用规则匹配也可以让 LLM 担任判断器。规则匹配速度快但不够灵活LLM 判断更准确但需要额外调用。实际系统中往往采用两者结合。3.3 ABC 信用得分Answer-Backtracked CreditABSeeker 对每个搜索步骤计算一个 Answer-Backtracked Credit也就是 ABC 信用得分。判定逻辑可以归纳为四种情况情况含义信用方向训练处理步骤出现在轨迹中且最终答案满足该步骤的约束有效搜索路径正向保留并强化该步骤步骤出现在轨迹中但最终答案不满足该步骤的约束误导分支负向降低该步骤概率并做反事实纠错步骤未出现在轨迹中但最终答案满足其约束模型缺失的潜在关键步骤潜在正向补全为新的训练样本引导模型探索步骤未出现在轨迹中且最终答案不满足其约束与当前答案无关忽略不参与训练前两种情况是普通轨迹的信用分配第三和第四种情况是 ABC 得分最具特色的部分。它不只是评价模型已经走过的路径还会通过答案约束反推出“模型应该走但没走”的路径相当于一种自动化的数据增广。3.4 负向样本与反事实纠错负向信用步骤不能简单丢弃。如果只让模型降低错误步骤的概率模型可能学到的只是“这条路不对”却不知道怎么修正。更好的做法是把负向步骤改造成反事实纠错样本。具体来说对于一条最终答案正确但中间包含错误分支的轨迹系统会把错误步骤和最终答案拼接在一起让模型看到“你之前在错误分支上走了弯路但正确答案实际是这样的请修正你的搜索策略”。这就像考试后的错题订正不是简单地把错题扔掉而是让学生重新理解正确解法。反事实纠错的好处是让模型学会从错误中恢复而不是只会记住某条固定路径。这在长视界任务中尤其重要因为真实搜索过程中几乎不可能保证每一步都完美。3.5 与稀疏奖励、过程奖励的对比维度结果奖励过程奖励模型ABSeeker信号粒度轨迹级稀疏步骤级密集步骤级密集是否需要额外模型否是否是否需要人工标注过程不需要需要或依赖合成不需要实现成本低高中可解释性低中高答案约束可见从表格中可以看出ABSeeker 在信号密度上接近过程奖励模型但实现成本和可解释性都优于过程奖励模型。这也是它在工程上吸引人的原因。4. 核心算法与简化实现4.1 训练主流程伪代码下面给出 ABSeeker 训练主流程的简化示意。# 算法ABSeeker 训练主流程简化示意 def abseeker_train(model, queries, num_samples4): all_pairs [] for query in queries: trajectories [] for _ in range(num_samples): traj model.search(query) # 策略模型采样一条搜索轨迹 trajectories.append(traj) for traj in trajectories: scores compute_abc_scores(traj) # 答案回溯计算步骤信用 pairs build_preference_pairs(traj, scores) all_pairs.extend(pairs) # 使用偏好对进行 DPO/对比学习更新 train_with_preference_pairs(model, all_pairs) return model需要说明的是这里model.search(query)是逻辑上的采样过程真实系统中会包含搜索 API 调用、LLM 推理和步骤结构化记录。train_with_preference_pairs的具体实现取决于框架选择可以是 DPO、对比学习或带权重的策略梯度。4.2 轨迹与步骤的数据结构为了让答案回溯能够计算训练数据必须把“步骤内容”和“步骤约束”分开记录。下面是一个简化版数据结构。# 文件路径abseeker_demo/data.py from dataclasses import dataclass, field from typing import List, Dict dataclass class SearchStep: 搜索轨迹中的一步 step_id: int step_type: str # sub_question / retrieval / inference / verify content: str # 步骤的自然语言描述 constraints: List[str] # 该步骤对最终结论的约束条件 dataclass class SearchTrajectory: 一条完整的搜索轨迹 query: str steps: List[SearchStep] final_answer: str这里的关键是constraints字段。它把自然语言步骤转换成可判定的约束条件是答案回溯能够计算的基础。实际项目中约束可以由模型在生成步骤时一并输出也可以在离线阶段用 LLM 为已有步骤补充生成。4.3 约束匹配与 ABC 打分下面实现一个简化版的 ABC 打分函数。为了保持示例可运行约束匹配采用子串匹配真实系统中更推荐用 LLM 判断约束是否被答案满足。# 文件路径abseeker_demo/credit.py from typing import Dict from data import SearchStep, SearchTrajectory def match_constraint(answer: str, constraint: str) - bool: 简化版约束匹配判断最终答案是否满足某个约束。 真实系统中通常用 LLM 判断这里用子串匹配做教学示意。 return constraint.strip().lower() in answer.strip().lower() def compute_abc_scores(trajectory: SearchTrajectory) - Dict[int, float]: 根据最终答案回溯计算每个步骤的信用得分。 正向信用记为 1.0负向信用记为 -1.0。 scores {} for step in trajectory.steps: satisfied all( match_constraint(trajectory.final_answer, c) for c in step.constraints ) if satisfied: scores[step.step_id] 1.0 else: scores[step.step_id] -1.0 return scores这个函数的核心逻辑是最终答案满足步骤约束则步骤获得正向信用否则获得负向信用。配合反事实纠错后负向步骤并不会被简单抛弃而是变成模型的学习素材。4.4 偏好数据构造得到 ABC 得分后需要把得分转换成可供偏好优化算法使用的数据。最通用的是构造chosen和rejected两个文本序列。# 文件路径abseeker_demo/preference.py from typing import Dict, List from data import SearchTrajectory def build_preference_pairs(trajectory: SearchTrajectory, scores: Dict[int, float]) - List[Dict[str, str]]: pairs [] for step in trajectory.steps: score scores.get(step.step_id, 0.0) if score 0: # 正向信用步骤继续执行该方向 chosen f问题{trajectory.query}\n搜索动作{step.content} rejected f问题{trajectory.query}\n搜索动作终止当前搜索分支 pairs.append({ prompt: trajectory.query, chosen: chosen, rejected: rejected, }) elif score 0: # 负向信用步骤反事实纠错 rejected f问题{trajectory.query}\n搜索动作{step.content} chosen ( f问题{trajectory.query}\n f搜索动作该分支未导向正确答案请修正方向并检索与答案一致的证据 ) pairs.append({ prompt: trajectory.query, chosen: chosen, rejected: rejected, }) return pairs这里体现了两个关键点。第一正向信用步骤被设置为偏好项表示模型应该继续保持这一类搜索动作。第二负向信用步骤的反事实纠错体现在chosen文本上模型不是简单放弃这个分支而是被引导生成修正后的搜索方向。这种设计比纯过滤负样本更能提升模型的泛化能力。4.5 损失函数与策略更新偏好对构造完成后可以使用多种策略更新方式。最直接的是使用 DPO 类偏好优化算法。DPO 的目标是最大化chosen序列的概率同时最小化rejected序列的概率而且不需要单独的奖励模型。在trl等开源库中可以基于DPOTrainer直接训练。另一种方式是把 ABC 得分当成优势函数使用带权重的策略梯度更新。正向步骤的概率被抬高负向步骤的概率被压低。这种方式更接近传统强化学习但实现复杂度稍高。在工程实践中建议先用 DPO 跑通流程再根据效果调整训练策略。需要提醒的是不同框架的 DPO 接口存在差异训练代码需要根据实际依赖版本调整。5. 完整实战案例简化版 ABSeeker 演示5.1 项目结构本节用一个最小项目演示 ABSeeker 的核心流程。项目结构如下abseeker_demo/ ├── data.py # 数据结构与模拟数据 ├── credit.py # ABC 打分逻辑 ├── preference.py # 偏好对构造 ├── demo.py # 运行入口 └── requirements.txt这次演示的重点是从几条带约束的搜索轨迹出发通过答案回溯计算步骤信用最终生成可用于偏好优化的训练数据。5.2 环境依赖建议环境为 Python 3.10 及以上。核心依赖如下版本需要根据实际项目调整。python3.10 dataclasses typing本演示不依赖大型深度学习框架只演示数据流和算法逻辑。如果要接入真实模型训练需要额外安装torch、transformers、trl、peft等库。5.3 编写核心代码先补充一条模拟搜索轨迹和最终答案。# 文件路径abseeker_demo/data.py补充 def generate_demo_trajectories(): # 轨迹一各步骤约束均被最终答案满足应获得正向信用 good_traj SearchTrajectory( queryCompx 数据集中音乐家是否在乐团中演出, steps[ SearchStep( step_id1, step_typesub_question, content提出子问题目标人物是否属于音乐家, constraints[音乐家], ), SearchStep( step_id2, step_typeretrieval, content检索音乐家的乐团演出记录, constraints[乐团, 演出], ), SearchStep( step_id3, step_typeinference, content推断该音乐家参与了乐团演出, constraints[乐团, 演出], ), ], final_answer是该音乐家在乐团中有演出记录。, ) # 轨迹二步骤约束与最终答案矛盾应获得负向信用 bad_traj SearchTrajectory( queryCompx 数据集中音乐家是否在乐团中演出, steps[ SearchStep( step_id1, step_typesub_question, content提出子问题目标对象是否属于作曲家, constraints[作曲家], ), SearchStep( step_id2, step_typeretrieval, content检索该作曲家的个人生平, constraints[作曲家, 生平], ), SearchStep( step_id3, step_typeinference, content推断作曲家可能不参与乐团演出, constraints[作曲家], ), ], final_answer是该音乐家在乐团中有演出记录。, ) return [good_traj, bad_traj]然后写运行入口把数据、ABC 打分和偏好构造串起来。# 文件路径abseeker_demo/demo.py from data import generate_demo_trajectories from credit import compute_abc_scores from preference import build_preference_pairs def main(): trajectories generate_demo_trajectories() for idx, traj in enumerate(trajectories): print(f轨迹 {idx 1}: {traj.query}) print(f最终答案: {traj.final_answer}) scores compute_abc_scores(traj) for step in traj.steps: score scores[step.step_id] direction 正向 if score 0 else 负向 print(f Step {step.step_id} [{step.step_type}] 信用{score:.1f} ({direction})) print(f 内容: {step.content}) pairs build_preference_pairs(traj, scores) print(f生成偏好对数量: {len(pairs)}) if pairs: sample pairs[0] print(f样例 chosen:\n{sample[chosen]}\n) print(f样例 rejected:\n{sample[rejected]}\n) print(- * 60) if __name__ __main__: main()5.4 运行与验证在项目目录下执行python demo.py预期输出如下轨迹 1: Compx 数据集中音乐家是否在乐团中演出 最终答案: 是该音乐家在乐团中有演出记录。 Step 1 [sub_question] 信用1.0 (正向) 内容: 提出子问题目标人物是否属于音乐家 Step 2 [retrieval] 信用1.0 (正向) 内容: 检索音乐家的乐团演出记录 Step 3 [inference] 信用1.0 (正向) 内容: 推断该音乐家参与了乐团演出 生成偏好对数量: 3 样例 chosen: 问题Compx 数据集中音乐家是否在乐团中演出 搜索动作提出子问题目标人物是否属于音乐家 样例 rejected: 问题Compx 数据集中音乐家是否在乐团中演出 搜索动作终止当前搜索分支 ------------------------------------------------------------ 轨迹 2: Compx 数据集中音乐家是否在乐团中演出 最终答案: 是该音乐家在乐团中有演出记录。 Step 1 [sub_question] 信用-1.0 (负向) 内容: 提出子问题目标对象是否属于作曲家 Step 2 [retrieval] 信用-1.0 (负向) 内容: 检索该作曲家的个人生平 Step 3 [inference] 信用-1.0 (负向) 内容: 推断作曲家可能不参与乐团演出 生成偏好对数量: 3 样例 chosen: 问题Compx 数据集中音乐家是否在乐团中演出 搜索动作该分支未导向正确答案请修正方向并检索与答案一致的证据 样例 rejected: 问题Compx 数据集中音乐家是否在乐团中演出 搜索动作提出子问题目标对象是否属于作曲家5.5 结果说明从输出可以看出正确轨迹的三个步骤都获得了正向信用错误轨迹的三个步骤都获得了负向信用。这就是答案回溯信用分配的核心结果不需要人工标注只需要最终答案就可以为每个步骤生成明确的训练信号。这些偏好对可以直接用于 DPO 训练。训练时模型会逐步提高正向动作的概率降低负向动作的概率同时通过反事实纠错样本学会修正错误分支。需要再次强调的是实际系统中约束匹配不会这么简单。真实答案的表达方式多种多样子串匹配很容易误判因此生产环境建议使用 LLM 作为约束满足判断器。6. 实验设计与效果分析6.1 典型评估任务ABSeeker 面向的是长视界搜索和推理任务常见的评估数据集包括HotpotQA多跳问答需要检索多个文档并组合证据。Bamboogle需要多轮搜索组合的信息查询。Compx包含复杂组合逻辑的问题集。SearchBench 等综合搜索基准评估搜索策略、答案准确率和步骤效率。这些任务的共同点是单次生成无法完成需要多轮搜索和推理。因此它们非常适合用来测试训练框架对长视界搜索策略的改善效果。6.2 对比方向与分析从方法设计上看ABSeeker 要对比的对象主要有三类第一类是采样过滤型方法代表是 STaR、WebGPT 的结果监督训练。这类方法只保留答案正确的轨迹步骤级噪声高。ABSeeker 的优势在于能利用答案回溯把轨迹中的错误步骤单独识别出来而不是整条轨迹要么全对、要么全错。第二类是显式过程奖励模型。这类方法需要额外训练一个奖励模型成本更高。ABSeeker 的信号来自答案约束不依赖额外模型因此训练流程更简洁也更容易复现。第三类是 MCTS 类显式搜索方法。这类方法推理时能力强但实现复杂、计算开销大。ABSeeker 更轻量更适合快速迭代和规模化训练。从公开技术报告的综合信息来看ABSeeker 在长视界多跳任务上通常能带来明显的正确率提升同时在搜索步骤效率上也有改善。具体数值需要以论文正式发表版本为准不同数据集、不同基座模型、不同评估设置下的结果会有差异。6.3 消融视角哪些设计真正起作用如果要深入理解 ABSeeker可以关注三个消融维度第一去掉负向信用后模型是否还具备纠错能力。如果不提供负信号模型只能学到“哪些步骤要做”学不到“哪些步骤要避免”在长轨迹中表现往往会下降。第二去掉潜在正向补全后模型是否还能发现未探索的正确路径。潜在正向样本相当于引导模型探索答案约束指向的新分支对提升探索多样性有帮助。第三约束匹配方式的影响。规则匹配和 LLM 判断的准确率直接决定了 ABC 得分的质量。如果约束判断不准信用信号就会有噪声训练效果也会受到影响。6.4 可解释性优势ABSeeker 的另一个价值是可解释性。训练完成后我们可以检查每一步的 ABC 得分直观看到模型哪些搜索行为被强化、哪些行为被抑制。这种细粒度的训练日志对分析模型缺陷非常有帮助也能帮助研究者定位系统性的错误模式。7. 常见问题与排查思路7.1 问题排查表格问题现象常见原因解决思路约束匹配总把正步骤判为负约束过严或答案表达方式不同改用 LLM 判断约束满足而不是子串匹配训练后模型倾向于少搜索负向样本过多模型变得保守平衡正负样本比例对负样本做反事实纠错DPO 训练不收敛偏好对冲突同一动作既当正样本又当负样本检查同一步骤是否同时出现在 chosen 和 rejected 中长轨迹计算开销大采样数 K 设置过大减少采样数分步缓存轨迹缩短单次轨迹长度搜索步骤难以结构化动作空间不统一约束描述不规范先设计动作模板再为每类动作定义约束格式最终答案本身有噪声训练标签质量差清洗数据集或结合多数投票筛选高置信轨迹7.2 约束判断不稳定的处理约束判断是 ABSeeker 最关键的环节。如果判断不准后续所有信用分配都会被污染。建议在生产环境中设置“答案约束判断”专用 prompt让 LLM 以三元判断方式输出约束是否被满足并附上简要依据。同时可以在离线阶段抽样检查约束判断的一致率。如果同一个约束对不同表达方式的答案判断不稳定就需要调整判断 prompt 或增加示例。7.3 正负样本不平衡的处理长轨迹中负向步骤数量可能远多于正向步骤。如果不做处理模型会过度抑制搜索行为导致它在新问题上不敢探索。解决方案有三个方向一是对负向样本降采样二是对负向样本的梯度做衰减三是把负向样本改造成反事实纠错样本让模型学习“如何修正”而不是简单学习“不要做什么”。第三种方式在 ABSeeker 中尤为重要。8. 最佳实践与工程建议8.1 把搜索步骤结构化ABSeeker 对步骤结构化程度要求很高。建议在轨迹采样阶段就统一动作模板比如把步骤类型分为sub_question、retrieval、extract、inference、verify每种动作都有标准格式。这样后续约束提取和信用分配都会更容易。推荐的轨迹存储格式如下{ query: Compx 数据集中音乐家是否在乐团中演出, final_answer: 是该音乐家在乐团中有演出记录。, steps: [ { step_id: 1, type: sub_question, content: 提出子问题目标人物是否属于音乐家, constraints: [音乐家] } ] }这里的关键是constraints字段。建议在模型生成每个搜索步骤时同时输出该步骤的约束条件这样答案回溯时不需要额外推断。8.2 使用 LLM 做约束满足判断子串匹配适合教学演示但不适合生产环境。真实答案的表达方式千变万化比如约束是“包含音乐家所在乐团”答案写成“该音乐家隶属于某交响乐团”子串匹配很可能失效。推荐做法是让 LLM 判断约束是否被答案满足。可以设计一个带结构化输出的 prompt甚至要求模型输出satisfied、unsatisfied、unknown三种状态。对于unknown可以不参与训练减少噪声。8.3 反事实纠错不要省只做正负样本分离模型会学到“某些