空间推理一直是多模态大模型评测中最"见真章"的一类能力。你问一个视觉语言模型"桌子上那本书是不是在杯子的左边",它可能答得头头是道;但一旦换成"从 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 Model,PRM)。这一概念最早在数学推理领域被广泛研究,与结果奖励模型(Outcome Reward Model,ORM)相对。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_factory=dict) 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_id=idx, step_type=step_type, scores=scores) 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(key=lambda x: x[0], reverse=True) 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, temperature=0.7) steps = extract_structured_steps(raw) candidates.append(steps) return candidates def run_pipeline(prompt, prm: MultiObjectiveProcessReward, model, n_candidates=5, weights=None): candidates = generate_candidates(model, prompt, n=n_candidates) if not candidates: return {"error": "no_structured_output"} ranked = prm.rerank(candidates, weights=weights) 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是一个需要调参的超参数。太小,重排空间不足;太大,推理延迟和成本明显上升。从经验看,空间推理任务里 5~10 个候选通常能覆盖有效路径;如果模型本身稳定,3~5 个就够。
第三,整个过程对每一步的可解释性非常好。返回结果里既有最优推理路径,又有每个步骤的多维度分数。这在真实业务中非常有价值:用户追问时,你可以直接展示"模型在第 2 步关系判断上置信度偏低",而不是甩出一句"模型觉得是这样"。
从实际工程的角度说,这个流程并不一定要绑定大模型推理。即使你使用判别式模型作为 scorer,也可以借助这个流程完成空间推理任务。它的本质是"生成多条备选路径 + 过程维度评分 + 重排",与具体的基座模型无关。
8. 效果验证与评估维度设计
很多做算法的同学会问:怎么知道这套方法真的有效?答案是需要建立一套包括过程质量评价和最终结果评价的多层次评估体系。这里不编造任何具体实验数字,而是给出一个可以复制到你自己项目里的评估框架。
第一层是最终答案准确率。这是最基础的指标,与普通 VQA 任务一致,用于判断整体任务完成水平。
第二层是步骤级准确率。通过人工或规则标注,判断每一条推理路径中每个步骤是否合理。空间推理建议至少评估四个维度:
- 场景解析是否找到了正确的物体集合。
- 坐标信息是否与真实标注一致。
- 相对方向判断是否正确。
- 结论是否由前提正确推导。
第三层是格式有效率和解析成功率。这一指标在结构化推理中很关键,如果大量输出无法被解析成合法结构,过程奖励模型就直接失效。一般来说,解析成功率低于 90% 时,要先解决生成格式问题,再谈推理质量。
第四层是错误定位率。它的含义是:当最终答案错误时,过程奖励模型能否把错误定位到正确的中间步骤。这听起来抽象,但在实际中非常重要。一个"自己知道错在哪一步"的奖励模型,比一个只会给最终答案打低分的奖励模型有价值得多。
在评测数据集设计上,建议准备三组数据:
- 简单单跳关系测试集,用于确认基础空间感知没有退化。
- 多跳变换测试集,用于考察多步骤逻辑连贯性。
- 抗干扰测试集,加入遮挡、密集物体、模糊表达等噪声,测试结构化推理是否比自由文本 CoT 更稳。
评测的工程实现上,可以先做一个小规模人工抽检脚本,每类任务抽 50~100 条,计算四层指标。确认流程稳定后,再扩展到完整测试集。这个做法能避免在流程有 bug 时大量浪费评测算力。
9. 常见问题与排查思路
在复现和落地类似方法时,有一些高频问题值得提前了解。下面表格汇总了最常见的几类问题。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 模型输出大量无效 JSON | 提示词没有明确格式约束,或模型对结构化输出不敏感 | 查看模型原始回复,统计 JSON 解析失败样例 | 在提示词中强调"只输出 JSON,不要解释";或改用更强的基础模型 |
| 过程奖励分数整体偏高但最终答案错误 | 评分函数与任务真实目标不对齐 | 抽样查看高分路径是否包含明显错误步骤 | 增加对抗性负样本训练评分器,或调整目标维度权重 |
| 多目标分数难以直接比较 | 不同维度的分数量纲差异大 | 检查各维度分值分布,观察方差 | 对各维度分数做归一化处理,再计算加权和 |
| 生成多条候选但彼此相似度过高 | 温度设置偏低,或模型陷入局部最优 | 检查候选路径多样性,如计算不同路径的平均编辑距离 | 提高采样温度,或在提示词中增加"尝试不同解题思路"指令 |
| 步骤解析成功率在长任务上显著下降 | 步骤数量增多导致早期信息遗忘,出现嵌套 JSON 解析困难 | 分段解析输出,观察哪一步开始解析失败 | 限制单个推理路径长度,或允许模型按顺序输出步骤序号 |
| 多目标 reward 模型训练数据标注成本高 | 把每个步骤的每个维度都标注成了稠密标签 | 统计哪些维度对最终结果影响最大 | 先只标注关键维度的稀疏标签,再用启发式规则补全其他维度 |
这些问题的共性是:结构化推理不是把格式约束丢给模型就完事,它需要提示词设计、评分函数、指标验证三方配合。如果发现模型输出格式不稳定,优先怀疑提示词约束不够明确;如果发现评分与最终答案相关性不高,优先怀疑评分维度定义不准确;如果发现重排后没有提升,优先检查候选多样性。
10. 最佳实践与工程建议
结合前文的分析,把 SCOUT 方法背后的工程思想沉淀为几条可以直接使用的建议。
第一,约束推理格式时要"少而稳"。不要一开始就设计一个 20 个字段的复杂 JSON 模板。先让模型输出最小字段集,例如场景解析、关系步骤、结论三段式,跑通整体流程后再扩展。字段越多,解析失败率和推理性能下降的越快。
第二,过程奖励模型不是越大越好。在空间推理任务中,一个轻量级的判别式模型,配合精心设计的维度定义,往往比重型生成式裁判更稳定。原因在于生成式裁判也会引入额外的误差,而判别式模型只需对给定步骤输出分数,推理路径更可控。
第三,把坐标系和视角信息写进 prompt。空间推理最大的坑是坐标系歧义。无论做训练数据还是推理模板,都建议显式声明坐标系的类型,比如"以图像左上角为原点,水平向右为 x 正方向,垂直向下为 y 正方向"。这个简单的写法能消除大量看似"模型变笨"的失败。
第四,在项目中保留"结构化回退"方案。当模型连续多次无法输出有效结构化格式时,可以自动降级为自由文本 CoT,并用一个轻量规则校验最终答案。这个回退机制在实际线上系统中非常实用,能避免因为格式问题导致服务不可用。
第五,多目标权重本身也应该纳入版本管理。随着业务场景变化,方向一致性维度和逻辑连贯性维度的相对重要性会变化。把权重配置写成 JSON 文件,纳入配置中心,而不是硬编码在代码中,可以让算法团队在线上快速调整,无需重新部署。
第六,训练数据生成时利用多目标自举。先用少量人工标注的步骤级数据训练一个初始 PRM,然后用初始 PRM 对大规模候选路径打分,从中挑选高分歧样本交给人工修正,再继续训练。这个自举循环能显著降低多目标过程奖励的标注成本,同时提升奖励模型和推理路径的覆盖度。
11. 总结与后续学习方向
SCOUT 这篇文章标题本身,已经给出了一个非常清晰的趋势:空间推理不能只靠"模型聪明",还要靠"推理路径结构化 + 过程奖励精细化"。
从本文拆解的内容来看,有三点值得你带走:
第一,结构化的价值不是让输出变好看,而是让错误变得可以定位。自由文本 CoT 在空间推理上的失败,往往不是因为模型能力不够,而是因为推理过程缺乏可校验的中间状态。
第二,多目标过程奖励是对空间推理错误多样性的回应。方向、位置、逻辑、语言覆盖是不同的错误维度,用单一分数评分会丢失大量训练信号。多目标评分不仅让训练更稳定,也让推理阶段的重排结果更有区分度。
第三,这套方法不局限于某个具体模型。你可以把它应用在视觉问答、具身智能、路径规划、机器人操作等任何涉及空间关系理解的任务上。核心投入在于推理模板设计和过程评分函数定义,而不是大模型的堆叠。
如果你正在做相关方向,建议下一步先做一个小实验:选一个空间关系数据集,把自由文本 CoT 的答案和结构化推理 + 过程重排的结果做对比,统计中间步骤的错误类型分布。这个实验成本不高,却能帮你快速判断这套思路是否适合你的任务场景。更远的路上,过程奖励模型如何向三维空间推理迁移、多目标如何与强化学习偏好对齐、结构化推理如何在长程空间任务中保持一致性,这些都是值得继续研究的方向。
空间推理是通往更强具身智能和复杂场景理解的一道关键门槛。SCOUT 给出的路径未必是终点,但"结构化 + 过程级多目标反馈"这个组合,值得每一个空间 AI 方向的技术人认真对待。