空间推理一直是多模态大模型评测中最见真章的一类能力。你问一个视觉语言模型桌子上那本书是不是在杯子的左边它可能答得头头是道但一旦换成从 A 点走到 B 点先右转再直行最终朝哪个方向很多模型会给出自洽但完全错误的空间关系。问题不在于模型不会说话而在于它缺少一条结构化的推理路径。这正是 SCOUT 这类方法试图改变的东西。从标题可以看出SCOUT 的核心思路是把空间推理从自由文本思维链推进到结构化思维链 多目标过程奖励。本文不预设你读过原论文而是从方法设计和技术实现两个角度拆解 SCOUT 为什么值得关注、它解决了什么问题、以及如何在类似任务中落地这套思路。读完后你能理解 Structured Chain-of-Thought 和多目标过程奖励的适用边界也能自己设计一个最小可验证的空间推理流程。1. 这篇文章真正要解决的问题先聊一个开发者和算法工程师都会遇到的真实困惑CoT 不是已经能提升推理能力了吗为什么空间推理还是经常不可靠答案藏在空间任务的特质里。数学推理中CoT 的每一步都是符号计算中间状态容易校验而空间推理的中间状态是坐标、朝向、遮挡关系和相对方位语言化描述天然有歧义。模型在自由文本 CoT 中写的物体 A 在物体 B 的右侧并不代表它真正建立了对应的空间心智模型。也就是说自由文本思维链在空间任务上容易说得多、错得远。SCOUT 这类方法的核心判断是空间推理不应该依赖自由生成的文本链而应该先定义一个可解析、可验证的结构化推理过程再用过程奖励模型去分步评分。这样做有三个直接收益推理步骤可以被机器检查和定位错误不再是一团黑盒。奖励信号从只看最终答案变成每步都给反馈训练更稳定。多目标设计让模型在位置、方向、相对关系等多个维度上同时被约束减少答案对但推理错或者推理对但口误答错的情况。这篇文章适合以下读者在做视觉问答、具身智能、空间规划、自动驾驶场景理解或者多模态大模型评测的同学以及想理解过程奖励模型到底怎么用在实际任务中的算法工程师。读完你可以复现一套通用的结构化空间推理流程并设计自己的多目标评估指标。2. 基础概念空间推理、结构化思维链与过程奖励模型在进入 SCOUT 的方法拆解前先把三个关键术语讲清楚。第一个是空间推理Spatial Reasoning。它指的是模型对空间中物体的位置、方向、距离、遮挡、排列顺序以及运动轨迹进行理解和推断的能力。典型的任务包括视觉问答中的空间关系判断如水杯是否在键盘左侧。路径规划中的方向变换如先向前走 3 米再向右转终点在起点的哪个方向。三维场景理解中的前后左右遮挡关系判断。空间推理的难点在于它需要把自然语言描述映射到一个连续、几何一致的内部表示中而不是仅仅做文本模式匹配。这也是它与数学推理、常识推理的重要区别。第二个是结构化思维链Structured Chain-of-Thought。常规 CoT 让模型自由输出首先……接着……然后……的推理文本而结构化 CoT 对推理格式做了强制约束每个步骤必须有明确的类型、输入输出字段甚至可以是可解析的 JSON。这样做的好处是打破文本流畅性对推理正确性的干扰。让过程可以被外部程序读取、校验和评分。为后续使用过程奖励模型提供结构化的状态序列。第三个是过程奖励模型Process Reward ModelPRM。这一概念最早在数学推理领域被广泛研究与结果奖励模型Outcome Reward ModelORM相对。ORM 只对最终答案打分PRM 则对推理过程中的每一个步骤打分。在空间推理中PRM 的价值更大因为空间任务的错误往往是逐步累积的第一步方向判断错了后面每一步的推导都建立在错误前提上最终答案可能错得很有逻辑。可以这样理解三者的关系结构化思维链负责让推理过程可读过程奖励模型负责让推理过程可判多目标设计负责让判断标准全面。SCOUT 把这三件事放在一个统一框架里。3. SCOUT 的方法定位侦察兵式空间推理SCOUT 这个命名很有意思。英文里 scout 是侦察兵、探路者放到空间推理场景中它暗示的是模型应该像一个成熟的侦察兵一样先观察环境再建立结构化的空间认知最后分步完成推理而不是一股脑冲到终点。从标题判断SCOUT 的完整方法包含两条主线第一条主线是结构化思维链的推理流程设计。它把空间推理拆解成多个可枚举的步骤比如场景解析、实体定位、坐标系构建、关系判断、结论生成。每一步的输出都符合预定义的结构而不是自由发挥的文本。这种设计的直接效果是即使模型在最后一步答错你也能准确知道错误发生在哪一步。第二条主线是多目标过程奖励Multi-Objective Process Reward。传统过程奖励模型通常只给一个标量分数表示当前步骤正确或错误。SCOUT 的多目标设计则把步骤评分拆成多个维度例如位置准确度、方向一致度、逻辑连贯度、语言覆盖度。这背后的原因是空间推理中的错误不是单一类型一个步骤可能在方向上正确但在距离上错误或者在位置上正确但逻辑衔接错误。单一分数无法表达这种复杂性。需要说明的是这里的内容是基于方法名称和公开技术路径做的合理技术解读具体实现细节、模型规模和实验设置要以论文原文为准。但即便如此这套结构化推理 多目标过程评分的组合思路本身就可以独立应用到很多空间相关任务中。从设计动机看SCOUT 要解决的是空间推理中的两个核心矛盾一是推理过程的可解释性与可验证性矛盾二是奖励信号的稀疏性与多维度矛盾。前者通过结构化思维链缓解后者通过多目标过程奖励缓解。4. 为什么空间推理需要多目标过程奖励很多刚接触这个方向的读者会有疑问process reward 在数学推理里已经够用了为什么空间推理还非要多目标不可答案从空间推理的错误结构来看。空间任务的中间步骤包含多种性质的子任务识别目标知道场景中有哪些物体。定位判断物体的大致位置。定向判断物体的朝向或用户视角。关系推理判断两个物体之间的相对方位。多步变换从起点出发执行方向变换后判断最终方位。这些子任务的错误模式完全不同。用单一分数评价时方向错误和位置错误在数值上都会被归为这一步做错了但二者需要的纠正信号天差地别。多目标奖励的意义在于它把每一步的评分变成一个向量例如目标识别正确率物体是否找对。位置一致性坐标是否落在正确区域。方向一致性相对角度是否贴合条件。逻辑连贯性这一步骤是否承接了上一步的输出。在训练过程奖励模型时这个多维向量可以帮助模型区分哪里错了以及错在哪个维度。在推理阶段多维评分也能提供更细粒度的候选步骤排序依据。简单说多目标是对空间推理复杂性的尊重。从工程角度理解多目标奖励还有一个优势它天然支持分维度调权。如果你发现模型错误集中在方向判断上可以在奖励聚合时提高方向维度的权重而不用重新训练整个奖励模型。这种灵活性在真实项目中非常实用。5. 结构化思维链的推理模板设计现在进入可落地部分。假设我们要构建一个空间关系问答任务让模型回答类似杯子是否在笔记本的右边的问题。传统方式是直接问模型期望它输出是或否。SCOUT 思路下的做法是要求模型先完成结构化推理再给出结论。下面给出一个最小可用的推理模板设计用 JSON 格式描述每一步的输出结构。这个模板可以在提示词中直接使用也可以作为构建训练数据时的标注规范。{ scene_parse: { objects: [ {name: cup, bbox: [120, 310, 180, 390], attributes: [white, on_desk]}, {name: laptop, bbox: [300, 280, 520, 420], attributes: [silver, open]} ] }, coordinate_system: { type: image_centric, origin: top_left, horizontal: left_to_right, vertical: top_to_bottom }, relation_step: { target: cup, reference: laptop, relative_position: left, confidence: 0.92 }, answer: { is_right: false, reason: In image coordinates, cup is on the left side of laptop. } }这个模板的关键设计点有三处。第一场景解析scene_parse必须显式列出物体及其位置信息。即使最终任务只需要一个关系判断这一步也能强制模型先建立空间表示避免跳步。第二坐标系coordinate_system必须明确。空间推理的歧义很多时候来自坐标系不统一到底是图像坐标系、物体自带坐标系还是用户视角坐标系把坐标系写进推理结构是从源头消除歧义。第三关系步骤relation_step要和最终答案answer分离。这样做的用意是当最终答案错误时我们可以检查 relation_step 中的 relative_position 和 confidence判断错误到底来自感知还是来自推理。在实际项目中这个模板可以扩展。比如在路径规划任务中增加 step_by_step_path 字段在三维场景理解中增加 depth_order 和 occlusion 字段。关键是保持结构固定、字段可扩展。从工程实践来看设计结构化推理模板时最容易犯的错误是把模板写得过于自由。字段越多模型越容易输出无效结构。建议从最少字段开始先在评测集上验证格式解析成功率再逐步增加字段。格式解析成功率低于 95% 时优先调整提示词或模板而不是继续堆字段。6. 多目标过程奖励模型的打分逻辑有了结构化推理输出后需要一个自动化的过程奖励模型来给每一步打分。这里给出一个多目标过程奖励模型的伪代码用来演示怎么把多目标拆解到实际代码层面。# 文件路径demo/multi_objective_prm.py from dataclasses import dataclass, field from typing import Dict, List dataclass class StepScore: step_id: int step_type: str scores: Dict[str, float] field(default_factorydict) def aggregated(self, weights: Dict[str, float]) - float: total 0.0 for dim, score in self.scores.items(): total weights.get(dim, 1.0) * score return total / max(1, len(self.scores)) class MultiObjectiveProcessReward: def __init__(self, scorer, default_weights): self.scorer scorer self.default_weights default_weights def score_trajectory(self, trajectory: List[dict]) - List[StepScore]: results [] for idx, step in enumerate(trajectory): results.append(self.score_step(idx, step)) return results def score_step(self, idx: int, step: dict) - StepScore: step_type step.get(type, unknown) # 不同步骤类型使用不同的评分函数 if step_type scene_parse: scores { object_recall: self.scorer.object_recall(step), bbox_accuracy: self.scorer.bbox_accuracy(step), } elif step_type relation_step: scores { direction_consistency: self.scorer.direction_consistency(step), logical_coherence: self.scorer.logical_coherence(step), } else: scores {overall: self.scorer.generic_quality(step)} return StepScore(step_ididx, step_typestep_type, scoresscores) def rerank(self, candidates: List[List[dict]], weights: Dict[str, float] None) - List[dict]: 使用聚合分数对候选推理路径进行重排序。 weights weights or self.default_weights scored [] for traj in candidates: step_scores self.score_trajectory(traj) total sum(s.aggregated(weights) for s in step_scores) scored.append((total, traj, step_scores)) scored.sort(keylambda x: x[0], reverseTrue) return scored这段伪代码展示了三个关键设计。第一score_step允许不同的步骤类型使用不同的评分函数集合。这正是多目标落实到工程上的核心不是所有维度对所有步骤生效而是每个步骤绑定自己的评价维度。第二aggregated方法通过权重向量把多维度分数聚合为标量。注意权重是外部传入的在线上推理时可以动态调整不影响已训练好的 scorer。第三rerank方法实现了 best-of-n 场景采样多条推理路径用过程奖励模型的聚合分数排序取最优路径作为最终输出。这是 PRM 相比 ORM 在推理阶段的核心优势——结果奖励模型只能对最终候选排序而过程奖励模型可以更细粒度地区分那些中间推理质量不同、最终答案碰巧相同的候选。在实际工程中scorer 本身可以是一个小模型也可以是一组规则函数。如果希望快速验证多目标过程奖励是否有效先用规则函数做 scorer 不丢人它至少能帮你确认流程是通的之后再替换成神经网络评分器。7. 推理阶段的完整流程设计在多目标过程奖励模型就绪后我们需要设计一个完整的推理流程。这个过程和普通 VQA 推理不同不是问题进、答案出而是采样、解析、评分、重排四步走。我用一个 Python 伪代码来演示整体流程。# 文件路径demo/inference_pipeline.py import json import re def extract_structured_steps(raw_output: str) - list: 从模型输出中提取结构化步骤。 steps [] for block in re.findall(r\{.*?\}, raw_output, re.DOTALL): try: steps.append(json.loads(block)) except json.JSONDecodeError: continue return steps def generate_candidates(model, prompt: str, n: int 5) - list: 生成 n 条候选推理路径。 candidates [] for _ in range(n): raw model.generate(prompt, temperature0.7) steps extract_structured_steps(raw) candidates.append(steps) return candidates def run_pipeline(prompt, prm: MultiObjectiveProcessReward, model, n_candidates5, weightsNone): candidates generate_candidates(model, prompt, nn_candidates) if not candidates: return {error: no_structured_output} ranked prm.rerank(candidates, weightsweights) best_total, best_traj, best_step_scores ranked[0] return { best_trajectory: best_traj, best_step_scores: [s.scores for s in best_step_scores], best_score: best_total, candidate_count: len(candidates), }这个流程有几点需要特别留意。第一extract_structured_steps使用正则查找 JSON 块是一个工程妥协。如果模型输出了完整 JSON 数组JSON 解析会更可靠但如果模型在结构化格式前附带解释文本正则提取会更实用。强烈建议在提示词中要求模型只输出 JSON不输出任何额外文本这样可以极大降低解析失败率。第二候选数量n_candidates是一个需要调参的超参数。太小重排空间不足太大推理延迟和成本明显上升。从经验看空间推理任务里 510 个候选通常能覆盖有效路径如果模型本身稳定35 个就够。第三整个过程对每一步的可解释性非常好。返回结果里既有最优推理路径又有每个步骤的多维度分数。这在真实业务中非常有价值用户追问时你可以直接展示模型在第 2 步关系判断上置信度偏低而不是甩出一句模型觉得是这样。从实际工程的角度说这个流程并不一定要绑定大模型推理。即使你使用判别式模型作为 scorer也可以借助这个流程完成空间推理任务。它的本质是生成多条备选路径 过程维度评分 重排与具体的基座模型无关。8. 效果验证与评估维度设计很多做算法的同学会问怎么知道这套方法真的有效答案是需要建立一套包括过程质量评价和最终结果评价的多层次评估体系。这里不编造任何具体实验数字而是给出一个可以复制到你自己项目里的评估框架。第一层是最终答案准确率。这是最基础的指标与普通 VQA 任务一致用于判断整体任务完成水平。第二层是步骤级准确率。通过人工或规则标注判断每一条推理路径中每个步骤是否合理。空间推理建议至少评估四个维度场景解析是否找到了正确的物体集合。坐标信息是否与真实标注一致。相对方向判断是否正确。结论是否由前提正确推导。第三层是格式有效率和解析成功率。这一指标在结构化推理中很关键如果大量输出无法被解析成合法结构过程奖励模型就直接失效。一般来说解析成功率低于 90% 时要先解决生成格式问题再谈推理质量。第四层是错误定位率。它的含义是当最终答案错误时过程奖励模型能否把错误定位到正确的中间步骤。这听起来抽象但在实际中非常重要。一个自己知道错在哪一步的奖励模型比一个只会给最终答案打低分的奖励模型有价值得多。在评测数据集设计上建议准备三组数据简单单跳关系测试集用于确认基础空间感知没有退化。多跳变换测试集用于考察多步骤逻辑连贯性。抗干扰测试集加入遮挡、密集物体、模糊表达等噪声测试结构化推理是否比自由文本 CoT 更稳。评测的工程实现上可以先做一个小规模人工抽检脚本每类任务抽 50100 条计算四层指标。确认流程稳定后再扩展到完整测试集。这个做法能避免在流程有 bug 时大量浪费评测算力。9. 常见问题与排查思路在复现和落地类似方法时有一些高频问题值得提前了解。下面表格汇总了最常见的几类问题。问题现象可能原因排查方式解决方案模型输出大量无效 JSON提示词没有明确格式约束或模型对结构化输出不敏感查看模型原始回复统计 JSON 解析失败样例在提示词中强调只输出 JSON不要解释或改用更强的基础模型过程奖励分数整体偏高但最终答案错误评分函数与任务真实目标不对齐抽样查看高分路径是否包含明显错误步骤增加对抗性负样本训练评分器或调整目标维度权重多目标分数难以直接比较不同维度的分数量纲差异大检查各维度分值分布观察方差对各维度分数做归一化处理再计算加权和生成多条候选但彼此相似度过高温度设置偏低或模型陷入局部最优检查候选路径多样性如计算不同路径的平均编辑距离提高采样温度或在提示词中增加尝试不同解题思路指令步骤解析成功率在长任务上显著下降步骤数量增多导致早期信息遗忘出现嵌套 JSON 解析困难分段解析输出观察哪一步开始解析失败限制单个推理路径长度或允许模型按顺序输出步骤序号多目标 reward 模型训练数据标注成本高把每个步骤的每个维度都标注成了稠密标签统计哪些维度对最终结果影响最大先只标注关键维度的稀疏标签再用启发式规则补全其他维度这些问题的共性是结构化推理不是把格式约束丢给模型就完事它需要提示词设计、评分函数、指标验证三方配合。如果发现模型输出格式不稳定优先怀疑提示词约束不够明确如果发现评分与最终答案相关性不高优先怀疑评分维度定义不准确如果发现重排后没有提升优先检查候选多样性。10. 最佳实践与工程建议结合前文的分析把 SCOUT 方法背后的工程思想沉淀为几条可以直接使用的建议。第一约束推理格式时要少而稳。不要一开始就设计一个 20 个字段的复杂 JSON 模板。先让模型输出最小字段集例如场景解析、关系步骤、结论三段式跑通整体流程后再扩展。字段越多解析失败率和推理性能下降的越快。第二过程奖励模型不是越大越好。在空间推理任务中一个轻量级的判别式模型配合精心设计的维度定义往往比重型生成式裁判更稳定。原因在于生成式裁判也会引入额外的误差而判别式模型只需对给定步骤输出分数推理路径更可控。第三把坐标系和视角信息写进 prompt。空间推理最大的坑是坐标系歧义。无论做训练数据还是推理模板都建议显式声明坐标系的类型比如以图像左上角为原点水平向右为 x 正方向垂直向下为 y 正方向。这个简单的写法能消除大量看似模型变笨的失败。第四在项目中保留结构化回退方案。当模型连续多次无法输出有效结构化格式时可以自动降级为自由文本 CoT并用一个轻量规则校验最终答案。这个回退机制在实际线上系统中非常实用能避免因为格式问题导致服务不可用。第五多目标权重本身也应该纳入版本管理。随着业务场景变化方向一致性维度和逻辑连贯性维度的相对重要性会变化。把权重配置写成 JSON 文件纳入配置中心而不是硬编码在代码中可以让算法团队在线上快速调整无需重新部署。第六训练数据生成时利用多目标自举。先用少量人工标注的步骤级数据训练一个初始 PRM然后用初始 PRM 对大规模候选路径打分从中挑选高分歧样本交给人工修正再继续训练。这个自举循环能显著降低多目标过程奖励的标注成本同时提升奖励模型和推理路径的覆盖度。11. 总结与后续学习方向SCOUT 这篇文章标题本身已经给出了一个非常清晰的趋势空间推理不能只靠模型聪明还要靠推理路径结构化 过程奖励精细化。从本文拆解的内容来看有三点值得你带走第一结构化的价值不是让输出变好看而是让错误变得可以定位。自由文本 CoT 在空间推理上的失败往往不是因为模型能力不够而是因为推理过程缺乏可校验的中间状态。第二多目标过程奖励是对空间推理错误多样性的回应。方向、位置、逻辑、语言覆盖是不同的错误维度用单一分数评分会丢失大量训练信号。多目标评分不仅让训练更稳定也让推理阶段的重排结果更有区分度。第三这套方法不局限于某个具体模型。你可以把它应用在视觉问答、具身智能、路径规划、机器人操作等任何涉及空间关系理解的任务上。核心投入在于推理模板设计和过程评分函数定义而不是大模型的堆叠。如果你正在做相关方向建议下一步先做一个小实验选一个空间关系数据集把自由文本 CoT 的答案和结构化推理 过程重排的结果做对比统计中间步骤的错误类型分布。这个实验成本不高却能帮你快速判断这套思路是否适合你的任务场景。更远的路上过程奖励模型如何向三维空间推理迁移、多目标如何与强化学习偏好对齐、结构化推理如何在长程空间任务中保持一致性这些都是值得继续研究的方向。空间推理是通往更强具身智能和复杂场景理解的一道关键门槛。SCOUT 给出的路径未必是终点但结构化 过程级多目标反馈这个组合值得每一个空间 AI 方向的技术人认真对待。 SCOUT：用结构化思维链与多目标奖励提升空间推理
空间推理一直是多模态大模型评测中最见真章的一类能力。你问一个视觉语言模型桌子上那本书是不是在杯子的左边它可能答得头头是道但一旦换成从 A 点走到 B 点先右转再直行最终朝哪个方向很多模型会给出自洽但完全错误的空间关系。问题不在于模型不会说话而在于它缺少一条结构化的推理路径。这正是 SCOUT 这类方法试图改变的东西。从标题可以看出SCOUT 的核心思路是把空间推理从自由文本思维链推进到结构化思维链 多目标过程奖励。本文不预设你读过原论文而是从方法设计和技术实现两个角度拆解 SCOUT 为什么值得关注、它解决了什么问题、以及如何在类似任务中落地这套思路。读完后你能理解 Structured Chain-of-Thought 和多目标过程奖励的适用边界也能自己设计一个最小可验证的空间推理流程。1. 这篇文章真正要解决的问题先聊一个开发者和算法工程师都会遇到的真实困惑CoT 不是已经能提升推理能力了吗为什么空间推理还是经常不可靠答案藏在空间任务的特质里。数学推理中CoT 的每一步都是符号计算中间状态容易校验而空间推理的中间状态是坐标、朝向、遮挡关系和相对方位语言化描述天然有歧义。模型在自由文本 CoT 中写的物体 A 在物体 B 的右侧并不代表它真正建立了对应的空间心智模型。也就是说自由文本思维链在空间任务上容易说得多、错得远。SCOUT 这类方法的核心判断是空间推理不应该依赖自由生成的文本链而应该先定义一个可解析、可验证的结构化推理过程再用过程奖励模型去分步评分。这样做有三个直接收益推理步骤可以被机器检查和定位错误不再是一团黑盒。奖励信号从只看最终答案变成每步都给反馈训练更稳定。多目标设计让模型在位置、方向、相对关系等多个维度上同时被约束减少答案对但推理错或者推理对但口误答错的情况。这篇文章适合以下读者在做视觉问答、具身智能、空间规划、自动驾驶场景理解或者多模态大模型评测的同学以及想理解过程奖励模型到底怎么用在实际任务中的算法工程师。读完你可以复现一套通用的结构化空间推理流程并设计自己的多目标评估指标。2. 基础概念空间推理、结构化思维链与过程奖励模型在进入 SCOUT 的方法拆解前先把三个关键术语讲清楚。第一个是空间推理Spatial Reasoning。它指的是模型对空间中物体的位置、方向、距离、遮挡、排列顺序以及运动轨迹进行理解和推断的能力。典型的任务包括视觉问答中的空间关系判断如水杯是否在键盘左侧。路径规划中的方向变换如先向前走 3 米再向右转终点在起点的哪个方向。三维场景理解中的前后左右遮挡关系判断。空间推理的难点在于它需要把自然语言描述映射到一个连续、几何一致的内部表示中而不是仅仅做文本模式匹配。这也是它与数学推理、常识推理的重要区别。第二个是结构化思维链Structured Chain-of-Thought。常规 CoT 让模型自由输出首先……接着……然后……的推理文本而结构化 CoT 对推理格式做了强制约束每个步骤必须有明确的类型、输入输出字段甚至可以是可解析的 JSON。这样做的好处是打破文本流畅性对推理正确性的干扰。让过程可以被外部程序读取、校验和评分。为后续使用过程奖励模型提供结构化的状态序列。第三个是过程奖励模型Process Reward ModelPRM。这一概念最早在数学推理领域被广泛研究与结果奖励模型Outcome Reward ModelORM相对。ORM 只对最终答案打分PRM 则对推理过程中的每一个步骤打分。在空间推理中PRM 的价值更大因为空间任务的错误往往是逐步累积的第一步方向判断错了后面每一步的推导都建立在错误前提上最终答案可能错得很有逻辑。可以这样理解三者的关系结构化思维链负责让推理过程可读过程奖励模型负责让推理过程可判多目标设计负责让判断标准全面。SCOUT 把这三件事放在一个统一框架里。3. SCOUT 的方法定位侦察兵式空间推理SCOUT 这个命名很有意思。英文里 scout 是侦察兵、探路者放到空间推理场景中它暗示的是模型应该像一个成熟的侦察兵一样先观察环境再建立结构化的空间认知最后分步完成推理而不是一股脑冲到终点。从标题判断SCOUT 的完整方法包含两条主线第一条主线是结构化思维链的推理流程设计。它把空间推理拆解成多个可枚举的步骤比如场景解析、实体定位、坐标系构建、关系判断、结论生成。每一步的输出都符合预定义的结构而不是自由发挥的文本。这种设计的直接效果是即使模型在最后一步答错你也能准确知道错误发生在哪一步。第二条主线是多目标过程奖励Multi-Objective Process Reward。传统过程奖励模型通常只给一个标量分数表示当前步骤正确或错误。SCOUT 的多目标设计则把步骤评分拆成多个维度例如位置准确度、方向一致度、逻辑连贯度、语言覆盖度。这背后的原因是空间推理中的错误不是单一类型一个步骤可能在方向上正确但在距离上错误或者在位置上正确但逻辑衔接错误。单一分数无法表达这种复杂性。需要说明的是这里的内容是基于方法名称和公开技术路径做的合理技术解读具体实现细节、模型规模和实验设置要以论文原文为准。但即便如此这套结构化推理 多目标过程评分的组合思路本身就可以独立应用到很多空间相关任务中。从设计动机看SCOUT 要解决的是空间推理中的两个核心矛盾一是推理过程的可解释性与可验证性矛盾二是奖励信号的稀疏性与多维度矛盾。前者通过结构化思维链缓解后者通过多目标过程奖励缓解。4. 为什么空间推理需要多目标过程奖励很多刚接触这个方向的读者会有疑问process reward 在数学推理里已经够用了为什么空间推理还非要多目标不可答案从空间推理的错误结构来看。空间任务的中间步骤包含多种性质的子任务识别目标知道场景中有哪些物体。定位判断物体的大致位置。定向判断物体的朝向或用户视角。关系推理判断两个物体之间的相对方位。多步变换从起点出发执行方向变换后判断最终方位。这些子任务的错误模式完全不同。用单一分数评价时方向错误和位置错误在数值上都会被归为这一步做错了但二者需要的纠正信号天差地别。多目标奖励的意义在于它把每一步的评分变成一个向量例如目标识别正确率物体是否找对。位置一致性坐标是否落在正确区域。方向一致性相对角度是否贴合条件。逻辑连贯性这一步骤是否承接了上一步的输出。在训练过程奖励模型时这个多维向量可以帮助模型区分哪里错了以及错在哪个维度。在推理阶段多维评分也能提供更细粒度的候选步骤排序依据。简单说多目标是对空间推理复杂性的尊重。从工程角度理解多目标奖励还有一个优势它天然支持分维度调权。如果你发现模型错误集中在方向判断上可以在奖励聚合时提高方向维度的权重而不用重新训练整个奖励模型。这种灵活性在真实项目中非常实用。5. 结构化思维链的推理模板设计现在进入可落地部分。假设我们要构建一个空间关系问答任务让模型回答类似杯子是否在笔记本的右边的问题。传统方式是直接问模型期望它输出是或否。SCOUT 思路下的做法是要求模型先完成结构化推理再给出结论。下面给出一个最小可用的推理模板设计用 JSON 格式描述每一步的输出结构。这个模板可以在提示词中直接使用也可以作为构建训练数据时的标注规范。{ scene_parse: { objects: [ {name: cup, bbox: [120, 310, 180, 390], attributes: [white, on_desk]}, {name: laptop, bbox: [300, 280, 520, 420], attributes: [silver, open]} ] }, coordinate_system: { type: image_centric, origin: top_left, horizontal: left_to_right, vertical: top_to_bottom }, relation_step: { target: cup, reference: laptop, relative_position: left, confidence: 0.92 }, answer: { is_right: false, reason: In image coordinates, cup is on the left side of laptop. } }这个模板的关键设计点有三处。第一场景解析scene_parse必须显式列出物体及其位置信息。即使最终任务只需要一个关系判断这一步也能强制模型先建立空间表示避免跳步。第二坐标系coordinate_system必须明确。空间推理的歧义很多时候来自坐标系不统一到底是图像坐标系、物体自带坐标系还是用户视角坐标系把坐标系写进推理结构是从源头消除歧义。第三关系步骤relation_step要和最终答案answer分离。这样做的用意是当最终答案错误时我们可以检查 relation_step 中的 relative_position 和 confidence判断错误到底来自感知还是来自推理。在实际项目中这个模板可以扩展。比如在路径规划任务中增加 step_by_step_path 字段在三维场景理解中增加 depth_order 和 occlusion 字段。关键是保持结构固定、字段可扩展。从工程实践来看设计结构化推理模板时最容易犯的错误是把模板写得过于自由。字段越多模型越容易输出无效结构。建议从最少字段开始先在评测集上验证格式解析成功率再逐步增加字段。格式解析成功率低于 95% 时优先调整提示词或模板而不是继续堆字段。6. 多目标过程奖励模型的打分逻辑有了结构化推理输出后需要一个自动化的过程奖励模型来给每一步打分。这里给出一个多目标过程奖励模型的伪代码用来演示怎么把多目标拆解到实际代码层面。# 文件路径demo/multi_objective_prm.py from dataclasses import dataclass, field from typing import Dict, List dataclass class StepScore: step_id: int step_type: str scores: Dict[str, float] field(default_factorydict) def aggregated(self, weights: Dict[str, float]) - float: total 0.0 for dim, score in self.scores.items(): total weights.get(dim, 1.0) * score return total / max(1, len(self.scores)) class MultiObjectiveProcessReward: def __init__(self, scorer, default_weights): self.scorer scorer self.default_weights default_weights def score_trajectory(self, trajectory: List[dict]) - List[StepScore]: results [] for idx, step in enumerate(trajectory): results.append(self.score_step(idx, step)) return results def score_step(self, idx: int, step: dict) - StepScore: step_type step.get(type, unknown) # 不同步骤类型使用不同的评分函数 if step_type scene_parse: scores { object_recall: self.scorer.object_recall(step), bbox_accuracy: self.scorer.bbox_accuracy(step), } elif step_type relation_step: scores { direction_consistency: self.scorer.direction_consistency(step), logical_coherence: self.scorer.logical_coherence(step), } else: scores {overall: self.scorer.generic_quality(step)} return StepScore(step_ididx, step_typestep_type, scoresscores) def rerank(self, candidates: List[List[dict]], weights: Dict[str, float] None) - List[dict]: 使用聚合分数对候选推理路径进行重排序。 weights weights or self.default_weights scored [] for traj in candidates: step_scores self.score_trajectory(traj) total sum(s.aggregated(weights) for s in step_scores) scored.append((total, traj, step_scores)) scored.sort(keylambda x: x[0], reverseTrue) return scored这段伪代码展示了三个关键设计。第一score_step允许不同的步骤类型使用不同的评分函数集合。这正是多目标落实到工程上的核心不是所有维度对所有步骤生效而是每个步骤绑定自己的评价维度。第二aggregated方法通过权重向量把多维度分数聚合为标量。注意权重是外部传入的在线上推理时可以动态调整不影响已训练好的 scorer。第三rerank方法实现了 best-of-n 场景采样多条推理路径用过程奖励模型的聚合分数排序取最优路径作为最终输出。这是 PRM 相比 ORM 在推理阶段的核心优势——结果奖励模型只能对最终候选排序而过程奖励模型可以更细粒度地区分那些中间推理质量不同、最终答案碰巧相同的候选。在实际工程中scorer 本身可以是一个小模型也可以是一组规则函数。如果希望快速验证多目标过程奖励是否有效先用规则函数做 scorer 不丢人它至少能帮你确认流程是通的之后再替换成神经网络评分器。7. 推理阶段的完整流程设计在多目标过程奖励模型就绪后我们需要设计一个完整的推理流程。这个过程和普通 VQA 推理不同不是问题进、答案出而是采样、解析、评分、重排四步走。我用一个 Python 伪代码来演示整体流程。# 文件路径demo/inference_pipeline.py import json import re def extract_structured_steps(raw_output: str) - list: 从模型输出中提取结构化步骤。 steps [] for block in re.findall(r\{.*?\}, raw_output, re.DOTALL): try: steps.append(json.loads(block)) except json.JSONDecodeError: continue return steps def generate_candidates(model, prompt: str, n: int 5) - list: 生成 n 条候选推理路径。 candidates [] for _ in range(n): raw model.generate(prompt, temperature0.7) steps extract_structured_steps(raw) candidates.append(steps) return candidates def run_pipeline(prompt, prm: MultiObjectiveProcessReward, model, n_candidates5, weightsNone): candidates generate_candidates(model, prompt, nn_candidates) if not candidates: return {error: no_structured_output} ranked prm.rerank(candidates, weightsweights) best_total, best_traj, best_step_scores ranked[0] return { best_trajectory: best_traj, best_step_scores: [s.scores for s in best_step_scores], best_score: best_total, candidate_count: len(candidates), }这个流程有几点需要特别留意。第一extract_structured_steps使用正则查找 JSON 块是一个工程妥协。如果模型输出了完整 JSON 数组JSON 解析会更可靠但如果模型在结构化格式前附带解释文本正则提取会更实用。强烈建议在提示词中要求模型只输出 JSON不输出任何额外文本这样可以极大降低解析失败率。第二候选数量n_candidates是一个需要调参的超参数。太小重排空间不足太大推理延迟和成本明显上升。从经验看空间推理任务里 510 个候选通常能覆盖有效路径如果模型本身稳定35 个就够。第三整个过程对每一步的可解释性非常好。返回结果里既有最优推理路径又有每个步骤的多维度分数。这在真实业务中非常有价值用户追问时你可以直接展示模型在第 2 步关系判断上置信度偏低而不是甩出一句模型觉得是这样。从实际工程的角度说这个流程并不一定要绑定大模型推理。即使你使用判别式模型作为 scorer也可以借助这个流程完成空间推理任务。它的本质是生成多条备选路径 过程维度评分 重排与具体的基座模型无关。8. 效果验证与评估维度设计很多做算法的同学会问怎么知道这套方法真的有效答案是需要建立一套包括过程质量评价和最终结果评价的多层次评估体系。这里不编造任何具体实验数字而是给出一个可以复制到你自己项目里的评估框架。第一层是最终答案准确率。这是最基础的指标与普通 VQA 任务一致用于判断整体任务完成水平。第二层是步骤级准确率。通过人工或规则标注判断每一条推理路径中每个步骤是否合理。空间推理建议至少评估四个维度场景解析是否找到了正确的物体集合。坐标信息是否与真实标注一致。相对方向判断是否正确。结论是否由前提正确推导。第三层是格式有效率和解析成功率。这一指标在结构化推理中很关键如果大量输出无法被解析成合法结构过程奖励模型就直接失效。一般来说解析成功率低于 90% 时要先解决生成格式问题再谈推理质量。第四层是错误定位率。它的含义是当最终答案错误时过程奖励模型能否把错误定位到正确的中间步骤。这听起来抽象但在实际中非常重要。一个自己知道错在哪一步的奖励模型比一个只会给最终答案打低分的奖励模型有价值得多。在评测数据集设计上建议准备三组数据简单单跳关系测试集用于确认基础空间感知没有退化。多跳变换测试集用于考察多步骤逻辑连贯性。抗干扰测试集加入遮挡、密集物体、模糊表达等噪声测试结构化推理是否比自由文本 CoT 更稳。评测的工程实现上可以先做一个小规模人工抽检脚本每类任务抽 50100 条计算四层指标。确认流程稳定后再扩展到完整测试集。这个做法能避免在流程有 bug 时大量浪费评测算力。9. 常见问题与排查思路在复现和落地类似方法时有一些高频问题值得提前了解。下面表格汇总了最常见的几类问题。问题现象可能原因排查方式解决方案模型输出大量无效 JSON提示词没有明确格式约束或模型对结构化输出不敏感查看模型原始回复统计 JSON 解析失败样例在提示词中强调只输出 JSON不要解释或改用更强的基础模型过程奖励分数整体偏高但最终答案错误评分函数与任务真实目标不对齐抽样查看高分路径是否包含明显错误步骤增加对抗性负样本训练评分器或调整目标维度权重多目标分数难以直接比较不同维度的分数量纲差异大检查各维度分值分布观察方差对各维度分数做归一化处理再计算加权和生成多条候选但彼此相似度过高温度设置偏低或模型陷入局部最优检查候选路径多样性如计算不同路径的平均编辑距离提高采样温度或在提示词中增加尝试不同解题思路指令步骤解析成功率在长任务上显著下降步骤数量增多导致早期信息遗忘出现嵌套 JSON 解析困难分段解析输出观察哪一步开始解析失败限制单个推理路径长度或允许模型按顺序输出步骤序号多目标 reward 模型训练数据标注成本高把每个步骤的每个维度都标注成了稠密标签统计哪些维度对最终结果影响最大先只标注关键维度的稀疏标签再用启发式规则补全其他维度这些问题的共性是结构化推理不是把格式约束丢给模型就完事它需要提示词设计、评分函数、指标验证三方配合。如果发现模型输出格式不稳定优先怀疑提示词约束不够明确如果发现评分与最终答案相关性不高优先怀疑评分维度定义不准确如果发现重排后没有提升优先检查候选多样性。10. 最佳实践与工程建议结合前文的分析把 SCOUT 方法背后的工程思想沉淀为几条可以直接使用的建议。第一约束推理格式时要少而稳。不要一开始就设计一个 20 个字段的复杂 JSON 模板。先让模型输出最小字段集例如场景解析、关系步骤、结论三段式跑通整体流程后再扩展。字段越多解析失败率和推理性能下降的越快。第二过程奖励模型不是越大越好。在空间推理任务中一个轻量级的判别式模型配合精心设计的维度定义往往比重型生成式裁判更稳定。原因在于生成式裁判也会引入额外的误差而判别式模型只需对给定步骤输出分数推理路径更可控。第三把坐标系和视角信息写进 prompt。空间推理最大的坑是坐标系歧义。无论做训练数据还是推理模板都建议显式声明坐标系的类型比如以图像左上角为原点水平向右为 x 正方向垂直向下为 y 正方向。这个简单的写法能消除大量看似模型变笨的失败。第四在项目中保留结构化回退方案。当模型连续多次无法输出有效结构化格式时可以自动降级为自由文本 CoT并用一个轻量规则校验最终答案。这个回退机制在实际线上系统中非常实用能避免因为格式问题导致服务不可用。第五多目标权重本身也应该纳入版本管理。随着业务场景变化方向一致性维度和逻辑连贯性维度的相对重要性会变化。把权重配置写成 JSON 文件纳入配置中心而不是硬编码在代码中可以让算法团队在线上快速调整无需重新部署。第六训练数据生成时利用多目标自举。先用少量人工标注的步骤级数据训练一个初始 PRM然后用初始 PRM 对大规模候选路径打分从中挑选高分歧样本交给人工修正再继续训练。这个自举循环能显著降低多目标过程奖励的标注成本同时提升奖励模型和推理路径的覆盖度。11. 总结与后续学习方向SCOUT 这篇文章标题本身已经给出了一个非常清晰的趋势空间推理不能只靠模型聪明还要靠推理路径结构化 过程奖励精细化。从本文拆解的内容来看有三点值得你带走第一结构化的价值不是让输出变好看而是让错误变得可以定位。自由文本 CoT 在空间推理上的失败往往不是因为模型能力不够而是因为推理过程缺乏可校验的中间状态。第二多目标过程奖励是对空间推理错误多样性的回应。方向、位置、逻辑、语言覆盖是不同的错误维度用单一分数评分会丢失大量训练信号。多目标评分不仅让训练更稳定也让推理阶段的重排结果更有区分度。第三这套方法不局限于某个具体模型。你可以把它应用在视觉问答、具身智能、路径规划、机器人操作等任何涉及空间关系理解的任务上。核心投入在于推理模板设计和过程评分函数定义而不是大模型的堆叠。如果你正在做相关方向建议下一步先做一个小实验选一个空间关系数据集把自由文本 CoT 的答案和结构化推理 过程重排的结果做对比统计中间步骤的错误类型分布。这个实验成本不高却能帮你快速判断这套思路是否适合你的任务场景。更远的路上过程奖励模型如何向三维空间推理迁移、多目标如何与强化学习偏好对齐、结构化推理如何在长程空间任务中保持一致性这些都是值得继续研究的方向。空间推理是通往更强具身智能和复杂场景理解的一道关键门槛。SCOUT 给出的路径未必是终点但结构化 过程级多目标反馈这个组合值得每一个空间 AI 方向的技术人认真对待。