SCOUT：结构化思维链与多目标过程奖励强化空间推理

空间推理任务在自然语言处理里有长期且明确的落地价值。比如让模型根据一段导航描述判断当前朝向或者根据几个物体的坐标回答“B 是否在 A 的右上方”又或者判断三个物体之间的遮挡关系。这类问题看着简单但在实际评测中经常出现“最终答案碰对了、中间推理却前后矛盾”的现象。SCOUTStructured Chain-of-Thought and Multi-Objective Process Reward是一套增强空间推理的方法思路先要求模型生成结构化思维链再引入多目标过程奖励对中间的每一步空间推理分别进行反馈和优化。SCOUT 的核心判断很直接空间推理不能只优化最终答案也不能让模型随意写一段“think step by step”而必须把推理过程拆成可监督、可回溯、可评分的结构化字段并在步骤级别用多个目标去约束空间逻辑。本文会从空间推理的难点出发拆解 SCOUT 的设计思路、结构化 CoT 的数据结构、多目标过程奖励的训练方法并给出一个最小可复现实验框架、常见问题的排查顺序和落地建议。1. 空间推理为什么难坐标、方向和实体引用经常混在一起1.1 空间推理与普通推理的本质差异普通推理任务例如数学应用题或常识问答主要依赖数量关系、因果链和语义知识。空间推理的任务对象则更特殊它需要处理坐标系、方向、距离、相对位置、旋转和实体引用。同样是“A 在 B 左边”这句话普通语义理解只需要知道“左边”是一个方向词空间推理则还要知道观测视角是谁、B 自身的朝向是什么、“左边”相对哪个参照系成立。空间推理和普通文本推理的任务拆解方式也不一样。普通 CoT 可以按“先理解条件再计算再验证”来拆空间任务则需要把“从文本中抽取坐标或方向词”“确定参照对象和坐标轴”“执行坐标变换”“比较位置关系”“输出结论”这些步骤拆得更细。维度普通文本推理空间推理核心实体数字、概念、事件物体、位置、方向、坐标关系类型因果、包含、数量比较相对位置、距离、旋转、包含、遮挡主要错误数学计算、逻辑跳跃参照系混淆、方向词歧义、坐标不一致CoT 拆解重点条件提取、公式运用实体坐标化、关系建模、空间变换验证可验证性最终答案可验证中间步骤需要语义和空间一致性双重验证正因为这些差异空间推理不能简单套用“从条件推到结论”的通用 CoT。如果中间步骤只写“我认为 A 在 B 的右边”却没有说明以谁为参照、是否发生了旋转那么最终答案即使正确也无法证明模型真正理解了空间关系。1.2 普通 CoT 在空间推理中的典型失效模式只要求模型“一步步思考”的普通 CoT 在空间任务上常见三类失效模式。第一类是参照系漂移。模型前半段说“以观察者视角看A 在左边”后半段又说“B 在 A 的左边”却没有说明视角是否变化。最后答案可能正确但中间的关系链已经无法自洽。第二类是坐标与文本不一致。模型先从文本中抽取出“A(2,3)B(5,3)”后面计算距离时却写出“A(2,5)”。如果没有结构化的中间字段这种不一致很难被自动发现。第三类是方向词歧义没被消解。“左边”“前方”“上方”在不同坐标系里含义不同。普通 CoT 不会强制模型标注参照对象和坐标轴方向因此模型可能在同一段推理中使用不同的空间语义。SCOUT 的设计动机就是针对这些失效模式。它不要求模型随意写推理过程而是要求模型把空间信息落到固定字段里当前场景、实体坐标、已知关系、需要执行的变换、每一步的中间状态、最终结论。这样参照系、坐标、变换和关系可以被独立检查和评估。1.3 SCOUT 的主线结构化过程 多目标过程奖励SCOUT 的主线可以拆成两段。第一段是 Structured Chain-of-Thought即结构化思维链。模型在回答空间问题时先输出一个符合预定义 Schema 的结构化推理过程。这个过程中每个实体、每个坐标、每个相对位置关系都有明确字段。结构化设计不是为了增加输出长度而是为了让模型把“隐含的空间心智操作”显式化成机器可以解析的中间状态。第二段是 Multi-Objective Process Reward。传统做法是为最终答案训练一个奖励模型或者直接使用最终答案判断对错。SCOUT 则对结构化思维链的每一个步骤计算多维奖励至少覆盖语义正确性、实体引用忠实度、空间一致性、步骤完整性等维度。这套奖励信号可以用于三件事训练过程奖励模型、给强化学习提供步骤级反馈、在推理时做步骤级搜索或重排序。这两段加在一起解决了空间推理的两个痛点缺少可监督的中间状态、缺少可解释的步骤级反馈。理解了这条主线后面的数据结构、奖励函数和实验设计就有了统一目标。2. Structured Chain-of-Thought把“想到”变成“可检查的字段”2.1 结构化 CoT 输出 Schema结构化思维链的第一步是设计一个稳定的输出 Schema。下面是一份可在文本空间推理任务中使用的 JSON 示例用于说明思路实际项目需要根据具体任务补充字段。{ scene: { coordinate_system: absolute_2d, units: grid, observer: default }, entities: [ { entity: A, position: {x: 2, y: 3}, attributes: [] }, { entity: B, position: {x: 5, y: 3}, attributes: [] } ], relations: [ { relation: left_right, subject: A, object: B, value: left, reference: observer } ], transformations: [ { type: none, input: A(2,3), output: A(2,3), description: no transformation needed } ], reasoning_steps: [ { step_id: 1, operation: extract_coordinates, input: A is at (2,3), B is at (5,3), output: A(2,3), B(5,3) }, { step_id: 2, operation: compare_x, input: A.x2, B.x5, output: A.x B.x, so A is to the left of B } ], conclusion: A is to the left of B }这个 Schema 把空间推理中容易出错的四块内容独立出来scene 描述坐标系、单位和观察者。entities 记录每个实体的位置便于检查坐标是否被错误改写。relations 记录实体之间的关系并强制标注 reference避免参照系漂移。reasoning_steps 记录每一步做了什么空间操作方便奖励模型检查过程。2.2 从自然语言 CoT 到结构化 CoT 的 Prompt 约束要让模型输出严格的结构化 CoT需要把 Schema 和约束写进 Prompt。一个基本思路是主任务描述里不只要给问题还要给输出格式说明和错误样例。下面是一段简化后的 Prompt 模板。请回答以下空间推理问题。 输出要求 1. 先输出 JSON 格式的结构化思考过程。 2. JSON 必须包含 scene、entities、relations、transformations、reasoning_steps、conclusion 六个字段。 3. 每个实体在 entities 中必须有唯一 entity 标识。 4. relations 中必须写清 subject、object、value 和 reference。 5. 如果做了坐标变换必须在 transformations 中记录变换前后结果。 6. 最终答案只保留 conclusion 字段。 问题 {question} 输出这段模板的关键不是让模型“多想”而是逼它“把想的信息落在固定字段里”。实际项目还需要补充输出长度限制JSON 结构占空间较大解码 max_tokens 要设置足够。解析校验模型可能输出 Markdown 代码块包裹的 JSON也可能漏字段解析层要做容错。few-shot 示例给两个不同空间任务的结构化 CoT 示例可以明显提高字段完整率。2.3 空间原子操作类型与易错点空间推理过程本质上是多步原子操作的组合。梳理常见原子操作有助于设计 reasoning_steps 和数据标注模板。原子操作输入输出常见易错点抽取坐标自然语言描述实体坐标坐标单位不一致、数量读错方向判断两个实体坐标左右/前后/上下关系参照系未声明距离计算两个实体坐标欧氏距离或曼哈顿距离计算公式混用平移变换坐标和偏移量新坐标加法和减法方向搞反旋转变换坐标和旋转角度新坐标旋转中心缺失、角度符号不一致遮挡判断两个实体坐标和视线方向是否遮挡没有考虑视线方向包含判断区域和实体坐标实体是否在区域内开区间/闭区间混淆在结构化 CoT 中每一步 reasoning_steps 都应该尽量对应一种原子操作。这样奖励模型才能判断“这一步该做什么、做对了没有”而不是笼统地给整段推理打个分。2.4 结构化输出的工程保障结构化输出的工程保障要注意四点。第一解析层要尽量宽容。模型输出可能不是纯 JSON常见情况包括被代码块包裹、末尾多逗号、字段名大小写不一致、中文字段和英文字段混用。建议先做正则清理再用容错 JSON 解析器。第二字段校验不能只检查 key 是否存在还要检查值是否符合约束。例如 entities 里的 position 必须是数值relations 里的 subject 和 object 必须来自 entities否则直接判为结构错误。第三长度控制要预留。结构化 CoT 的 token 消耗远高于普通 CoT。如果 max_tokens 太小模型会在 reasoning_steps 写不完时截断导致 JSON 解析失败。调大 max_tokens 通常比强制模型压缩输出更稳。第四不要只看 JSON 合法还要看过程是否真正覆盖了问题。常见情况是模型输出的 JSON 格式很漂亮但 reasoning_steps 只有两行完全跳过了关键空间比较。这时过程奖励模型需要能够识别“步骤缺失”问题。3. Multi-Objective Process Reward在步骤级别给出多维反馈3.1 过程奖励模型和最终答案奖励的区别最终答案奖励只判断结论对错优点是比较容易获取缺点是反馈太稀疏。空间推理任务中模型可能因为坐标抽取错、参照系写错、方向词用错等原因得到错误答案但最终奖励无法告诉模型错在哪一步。过程奖励模型Process Reward ModelPRM针对每一个推理步骤输出一个得分表示这一步是否合理。SCOUT 进一步把过程奖励从“单分”扩展成“多目标得分”每个步骤同时评估多个维度。这样奖励信号能拆得更细也能避免单一分数掩盖“语义正确但空间不一致”或“坐标正确但步骤不完整”的问题。3.2 四个奖励维度怎么设计、怎么算在空间推理任务中建议至少给每个推理步骤计算四个维度的奖励奖励维度含义自动评估思路典型负样本semantic_correctness这一步语义和结论是否正确与参考步骤做语义相似度或规则匹配把 A 的坐标写错groundedness这一步是否引用了上下文中真实存在的实体和关系检查实体名、坐标值是否来自输入条件凭空出现实体 Cspatial_consistency空间关系是否与坐标值一致通过空间计算校验左右、距离、包含关系说 A 和 B 在同一水平但 y 坐标不同step_completeness关键空间操作步骤是否遗漏与任务模板中的必需步骤进行对比只抽坐标不做方向比较实际计算时semantic_correctness 和 groundedness 可以靠模型或规则模型实现spatial_consistency 适合用确定性规则校验step_completeness 可以用任务模板匹配实现。下面是一个简化的多目标奖励计算过程def compute_spatial_consistency(step_text, entities, coordinate_system): score 0.0 checks parse_step_expected_checks(step_text) for check in checks: if check.verify(entities, coordinate_system): score 1.0 return score / len(checks) if checks else 0.0关键点是有些维度可以完全用规则完成有些维度则需要训练一个奖励模型。建议将规则维度和模型维度分开计算最后再聚合这样更容易定位是规则写错还是奖励模型泛化不足。3.3 训练数据构造和奖励模型实现过程奖励模型的数据需要覆盖“好过程”和“坏过程”。空间推理任务生成坏样本的常用方式修改坐标把随机一个实体的坐标改掉。反转方向词把“左”改成“右”。删除步骤删掉关键比较步骤。引入无关实体在 reasoning_steps 或 relations 中加入原文没有的实体。改变参照系不改变实体坐标但把 reference 从 observer 改成其他实体导致关系判断变化。对每个步骤可以标注成多标签或回归目标。多标签目标适合做分类每个维度是好是坏。回归目标适合做排序奖励模型输出一个连续分。下面是一个多目标分类头的 PyTorch 示例import torch import torch.nn as nn class MultiObjectiveProcessRewardModel(nn.Module): def __init__(self, base_model_dim, num_heads4): super().__init__() self.reward_head nn.Linear(base_model_dim, num_heads) def forward(self, step_hidden, attention_maskNone): pooled step_hidden.mean(dim1) logits self.reward_head(pooled) return torch.sigmoid(logits)这段代码只是示例。实际项目通常以 encoder 或 decoder 的中间层输出为输入然后把步骤对应的 token hidden state 做平均池化再通过线性层输出 4 个维度的概率。这里的num_heads4对应对称上文的四个奖励维度。3.4 多目标聚合与策略模型优化多目标奖励在训练策略模型时需要聚合成一个标量奖励。最简单的聚合方法是线性加权reward w1 * semantic_correctness w2 * groundedness w3 * spatial_consistency w4 * step_completeness权重w1...w4需要根据任务重点调整。如果当前任务更关注方向关系那么 spatial_consistency 权重可以调高如果任务容易凭空引入实体那么 groundedness 权重可以调高。在强化学习阶段可以使用 PPO 等算法优化策略模型。由于空间推理的最终答案正确性仍然重要常见做法是把最终答案准确率作为额外奖励或作为 KL 正则的一部分。不推荐完全丢弃最终答案奖励否则模型可能生成“步骤合理但最终结论错误”的推理过程。Pseudo-code 可以这样组织for each batch: steps, final_answer policy_model.generate(prompt) multi_rewards reward_model(steps) scalar_reward weighted_sum(multi_rewards) final_answer_correct * alpha loss ppo_loss(scalar_reward, logprobs, old_logprobs) update policy_model这里的final_answer_correct可以用自动规则或裁判模型获得。多目标奖励和最终答案奖励结合是 SCOUT 方法在训练阶段最需要注意的平衡点。4. 最小实验框架从数据样例到训练闭环4.1 数据格式与样例为了便于复现建议把数据组织成 JSONL 文件每行包含一条带标注样本。下面是一个最小样例格式。{ id: spatial_001, question: A is at (2,3), B is at (5,3). Which one is left?, reference_plan: [ {operation: extract_coordinates, result: A(2,3), B(5,3)}, {operation: compare_x, result: A.x B.x}, {operation: conclude, result: A is left of B} ], reference_structured_cot: { scene: {coordinate_system: absolute_2d, units: grid}, entities: [ {entity: A, position: {x: 2, y: 3}}, {entity: B, position: {x: 5, y: 3}} ], relations: [ {relation: left_right, subject: A, object: B, value: left, reference: observer} ], reasoning_steps: [ {step_id: 1, operation: extract_coordinates, input: A(2,3), B(5,3), output: A.x2, B.x5}, {step_id: 2, operation: compare_x, input: A.x2, B.x5, output: A.x B.x} ], conclusion: A is left of B }, final_answer: A }在实际项目中最少需要几十到上百条参考样本用于人工检查再用半自动方式扩展训练数据。数据规模需要根据基础模型大小和任务复杂度决定不能直接套用一个固定数字。4.2 解码配置与推理流程生成结构化 CoT 时解码参数会影响输出质量和可解析率。建议先跑一组小实验确定参数。参数建议值说明temperature0.3 到 0.7过低容易重复过高容易结构混乱top_p0.8 到 0.9控制采样范围max_tokens1024 到 2048JSON 输出消耗大要预留stop可选按\n\n或}截断截断位置需要验证repetition_penalty1.0 到 1.1减少字段重复推理流程建议按下面的顺序python run_inference.py \ --model your_base_model \ --input data/dev.jsonl \ --output outputs/structured_cot.jsonl \ --schema config/schema.json \ --decode_temperature 0.5输出文件中的每一条都应保留原始问题、模型原始输出、解析后的结构化 CoT 和最终答案。这样后续无论是做奖励模型训练还是人工审查都有原始信息可追溯。4.3 奖励模型训练伪代码奖励模型训练的最小流程可以用伪代码表达。这里不限定具体框架重点是把数据处理和损失函数串起来。for sample in train_data: step_encoding tokenizer(sample.step_text, truncationTrue) labels torch.tensor(sample.multi_labels, dtypetorch.float32) logits reward_model(step_encoding.input_ids, step_encoding.attention_mask) loss nn.BCEWithLogitsLoss()(logits, labels) loss.backward() optimizer.step()需要注意这里的multi_labels是 4 个二分类标签比如[1, 1, 0, 1]表示语义正确、实体引用正确、空间一致性错误、步骤完整。如果希望输出连续分数可以把 BCELoss 换成 MSELoss。训练时建议做人工校验集抽查奖励模型在坏样本上的识别准确率。只观察训练 loss 下降是不够的因为模型可能学会了“格式好的样本都给高分”而没有真正理解空间一致性。4.4 评估指标和预期验证方式为了验证 SCOUT 是否生效建议分三层评估结构层JSON 解析成功率、必填字段覆盖率和类型合法率。过程层每个步骤的 semantic_correctness、groundedness、spatial_consistency、step_completeness 分数。结果层最终答案准确率、参考计划匹配率、人工评估得分。一个典型运行结果可以这样输出{ json_parse_success_rate: 0.92, field_coverage_rate: 0.95, spatial_consistency_score: 0.86, final_answer_accuracy: 0.78 }需要说明的是这些数据只是示例不是固定结论。每个数据集上的结果都会随基础模型、样本规模、任务难度变化。最关键的是“三层指标都看”而不是只看最终答案准确率。5. 复现和落地时的高频问题排查5.1 高频问题速查表问题现象常见原因检查方式处理建议模型输出 JSON 解析失败率高Schema 约束不够、max_tokens 太小、输出被截断查看原始输出统计截断位置加大 max_tokens做清理和容错解析奖励分数几乎不变训练不收敛正负样本区分度太低、奖励头仅依赖位置特征查看样本难度分布人工抽查坏样本构造更有挑战性的负样本加入人工标记结构化 CoT 格式正确但空间逻辑错误奖励没有覆盖 spatial_consistency 或权重过低单独输出 spatial_consistency 分数提高空间一致性权重增加坐标校验规则最终答案正确但过程奖励低参考答案计划过于严格对比参考计划和模型输出允许更多等价空间操作序列强化学习阶段分数崩盘多目标奖励权重未归一化、final_answer 奖励缺失检查 reward 均值和方差先做 reward 归一化再加 KL 惩罚训练时 GPU OOM结构化 CoT 序列太长、batch size 过大查看步骤长度分布截断步骤文本减小 batch使用梯度累积5.2 排查顺序与关键日志遇到问题不要先改模型按下面的顺序排查。检查输入问题是否被正确解析尤其是坐标、方向和实体名。检查模型输出是否能稳定解析成 JSON解析失败时输出原始文本。检查解析后的结构化 CoT 是否满足字段约束例如 entities 中的坐标是否被正确赋值。检查每个步骤的多目标分数重点看 spatial_consistency 是否和坐标一致。检查奖励分布确认不是所有样本都是 0 分或接近 0 分。检查最终答案准确率判断是“过程错但答案巧对”还是“过程和答案都错”。日志里至少要记录以下关键信息sample_id, question, raw_output, parsed_cot, final_answer, multi_reward_scores, reward_model_version没有这些字段问题就难以回溯。项目早期最好保留全量日志不要只保留最终指标。5.3 避免把结构化 CoT 做成“格式漂亮但逻辑错误”这是最容易犯的工程错误。模型可能学会输出 JSON但内部的空间推理仍然是一团浆糊。表现是字段齐全、格式合法但 relations 里的方向和 entities 里的坐标对不上。要避免这个问题需要做两件事。第一把 spatial_consistency 设计成确定性校验而不是只靠奖励模型学习。坐标和方向关系可以写出规则例如def check_left_right(entity_a, entity_b, reference): if reference observer: return entity_a[x] entity_b[x] # other reference systems can be added raise NotImplementedError第二在人工审查数据时把“格式正确但逻辑错误”的样本单独归类。它们不应该被当作正确样本。否则奖励模型会被错误标签带偏。6. 最佳实践与可扩展方向6.1 学习环境与生产环境配置建议学习环境重点是快速跑通最小闭环。建议使用小型开源模型做实验数据集控制在几百到几千条先不追求极致效果而是把数据格式、奖励模型、强化学习流程串起来。生产环境则需要更多保障数据版本管理每个样本的标注版本、奖励模型版本、策略模型版本都要可追溯。奖励模型监控上线后持续统计多目标奖励分布防止分布漂移。策略回滚保留历史策略权重当奖励分数异常时能快速回退。推理缓存空间推理任务的输入往往有重复可以在 parse 和 rule-based 校验层加缓存。人工抽检定期抽检结构化 CoT 质量不能只看自动指标。6.2 数据质量控制和奖励尺度对齐多目标奖励比单一奖励更容易出现维度间尺度不一致的问题。比如 semantic_correctness 的分数普遍在 0.9 以上而 spatial_consistency 的分数普遍只有 0.5这样简单加权后 spatial_consistency 会被稀释。建议先把每个维度的分数做标准化或分桶再调权重。也可以为每个维度单独训练一个回归头输出统一量纲的分值。还有一个实用方法每轮评估后把各维度分数的分布打印出来确认没有维度长时间不变。6.3 从文本空间推理扩展到多模态空间推理SCOUT 的结构化思想也可以扩展到视觉空间推理只需要处理两个额外问题。第一文本坐标来源于图片坐标或视觉 grounding 模型。可以把图片中的检测框坐标写入 entities.position再让模型输出结构化 CoT。第二多模态模型直接把图片和问题一起编码结构化的 reasoning_steps 仍然可以设计成纯文本字段。奖励模型的输入则可以从“纯步骤文本”扩展成“步骤文本 图片编码”但训练成本会明显增加。对于视觉场景spatial_consistency 校验可以沿用坐标规则比如判断“A 在 B 上方”时就比较两个检测框的 y 坐标。结构化字段的优势在这里尤其明显视觉模型的检测结果天然就是坐标值正好可以直接填充到 Schema。6.4 功能消融与更严谨的评估设计复现 SCOUT 或类似方法时建议做以下消融。去掉结构化 CoT只保留普通 CoT。去掉多目标过程奖励只保留最终答案奖励。保留多目标但去掉 spatial_consistency 维度。保留结构化 CoT 但去掉步骤级奖励只给整段打分。每一组对比都记录三层指标而不是只记录最终答案准确率。只有这样才能定量回答是结构化中间表示带来了主要提升还是多目标过程奖励提供了关键梯度信号。从工程角度SCOUT 并不是一个必须严格照搬的固定算法而是一套“显式过程 细粒度反馈”的思路。真正决定效果上限的是在具体任务里设计出既和空间逻辑自洽、又能被自动校验的结构化字段以及一组能真实反映步骤合理性的奖励目标。新手可以从一个二维坐标比较任务开始把结构化 CoT 跑通再逐渐加入旋转、遮挡、多实体关系等更复杂的空间操作最终扩展到视觉输入或真实导航场景。