这次我们来看一个空间推理方向的训练与推理方法SCOUT全称是SCOUT: Unlocking Enhanced Spatial Reasoning via Structured Chain-of-Thought and Multi-Objective Process Reward。一句话讲清楚它瞄准的是视觉语言模型在空间关系判断、坐标定位、路径规划上经常“看起来会实际乱猜”的问题解决思路是两条腿走路——一方面把思维链改成结构化中间表示另一方面用多目标过程奖励模型给推理的每一步打分再做推理时搜索。从标题能挖出三个关键词Structured Chain-of-Thought结构化思维链、Multi-Objective多目标、Process Reward过程奖励。它不是今天就能双击启动的普通应用项目而更像一套“训练数据构造 奖励模型训练 推理搜索”的方法框架。如果作者开源你能拿到的通常包括空间推理数据构造脚本、过程奖励模型训练脚本、推理搜索脚本以及基于某个开源 VLM 底座微调出来的权重如果只公开方法你也仍然可以借鉴它来改进自己的空间推理数据清洗和强化学习流程。本文会做五件事拆解 SCOUT 的核心方法逻辑说明空间推理任务需要什么样的结构化数据和评测方式给出一套复现、部署、验证 SCOUT 时可以参考的环境准备和推理接入思路补充资源占用观察方式最后列出常见坑和最佳实践。适合的读者是三类人正在训练视觉语言模型、准备给模型加空间推理能力的工程师对 CoT 蒸馏、过程奖励模型、推理时搜索感兴趣的研究同学以及在具体项目里需要判断“模型的空间能力到底靠不靠谱”的评测工程师。先给结论SCOUT 的技术路线不是把模型变大而是通过“结构化中间推理 过程级反馈 推理时搜索”三件事压低空间任务上的随机错误。这种思路的好处是即使基础模型参数量不变只要推理步骤可控、每一步都被过程奖励监控最终空间任务的准确率和可解释性也会明显改善。下面从核心能力开始拆。1. 核心能力速览从标题和关键词可以整理出 SCOUT 的定位边界能力维度说明项目类型视觉语言模型空间推理的训练与推理方法框架核心贡献结构化思维链 多目标过程奖励 推理时搜索面向任务空间问答、左右/前后关系判断、相对坐标定位、路径规划、空间变换依赖底座通常基于开源 VLM如 Qwen-VL、LLaVA 等方向的模型具体以原文为准训练阶段需要先构造结构化空间推理数据再训练过程奖励模型最后微调策略模型推理阶段通过过程奖励模型对生成步骤打分配合采样或搜索选择高置信结果推荐硬件取决于底座模型规模7B 级模型一般需要单张 16GB 以上显存更大模型需要多卡显存占用需按实际模型版本和输入分辨率测试无法从标题直接确认启动方式论文源码/脚本方式运行不是一键整合包是否支持 API若基于 vLLM 等框架部署推理服务可提供 OpenAI 兼容接口需要自行搭建是否支持批量任务推理阶段可批量跑评测集训练阶段需要按框架的分布式流程执行适合场景空间关系问答、机器人指令理解、图表空间解析、多步空间推理评测说明一下以上标注“需确认”的项是这类方法复现时的常见边界。因为目前能看到的信息只有论文标题没有开源仓库和具体版本号更稳妥的判断是先按通用 VLM 微调 过程奖励训练 推理搜索三件套来理解再以原文实际的模型和代码为准。2. 适用场景与使用边界2.1 适合什么场景空间推理能力在真实项目里有几类刚需空间关系问答例如“椅子在桌子的左边还是右边”模型要正确感知物体位置以及观察视角。坐标与目标定位例如“图片里位于中心偏右的红色杯子在哪”模型需要输出相对坐标或边界框。路径规划例如“从起点到终点给出绕开障碍的顺序”模型要把视觉信息和空间约束翻译成可执行路径。空间变换理解例如旋转、镜像、放大缩小后物体相对位置是否发生变化。机器人指令跟随例如“把工作台左侧的螺丝刀拿起来”VLM 需要把语言指令映射到具体空间实体。SCOUT 这类方法的价值在于它不满足于让模型直接吐一个答案而是要求模型先生成结构化步骤再让过程奖励模型判断每一步是否合理。对于接故障诊断、接自动化流程的团队这种可解释性是很有价值的因为你可以知道模型在哪一步开始出错。2.2 不适合什么场景SCOUT 的设计重心在空间推理不是在图像生成、语义对话、非空间常识推理上。如果你的任务根本不涉及空间关系比如普通文本问答、摘要、代码生成那这套“空间结构化 CoT 多目标奖励”并不会带来额外收益。此外它也不是零成本方案结构化数据标注、奖励模型训练、推理时多次采样搜索都会增加开发和计算成本。2.3 使用边界与合规提醒如果未来用 SCOUT 处理真实场景图像例如室内监控、街景、设备操作画面务必确认数据来源合法、有授权并且不包含未脱敏的个人隐私信息。任何空间推理能力落到机器人控制、自动驾驶、安防等场景时都要先做小范围封闭测试不能直接在生产环境里依赖模型的单次输出。涉及人脸、车牌、个人住所等敏感信息时先脱敏再入数据集。3. 为什么空间推理不能只靠标准 CoT很多团队已经在 VLM 上试过思维链在数学和代码任务上效果不错但空间推理不一样。3.1 空间任务的语言定义不唯一“左边”到底是谁的左边取决于观察视角。模型如果只生成一句“杯子在桌子的左边”它没有区分“图像视角的左边”“物体自身的左边”还是“参考系的左边”。标准 CoT 不会强制模型显式声明参考系所以经常出现答案看起来通顺、实际上空间逻辑完全错误的情况。3.2 标准 CoT 的步骤之间缺少约束自由文本思维链可以有任意长度的中间句没有任何机制保证“第 2 步使用了第 1 步的对象”“第 3 步的方向推导基于第 2 步的坐标”。空间推理是强递进任务一步错后往往全线错。更麻烦的是标准 CoT 出错后你很难定位模型到底是认错了物体还是关系判断错了还是最后回答问题错了。3.3 结果奖励不够用如果用“最终答案是否正确”训练模型模型学到的是“试运气”。在空间任务里正确路径和错误路径往往只差一个词比如“左”和“右”。结果奖励模型无法告诉模型你到底在哪一步产生了偏差浅层微调很容易震荡。SCOUT 的立场很明确空间推理需要结构化、可校验的中间步骤以及能对每个步骤反馈正误的过程奖励。只有把推理过程拆到足够细奖励信号才不会被稀疏结果掩盖。4. SCOUT 方法框架拆解基于标题的语义可以把 SCOUT 拆成三个模块结构化思维链、多目标过程奖励、推理时搜索。4.1 模块一结构化思维链与自由文本 CoT 不同结构化思维链要求模型每一步输出都符合固定形式。常见做法是分四层感知层从输入图片中识别实体对象并给出位置信息。典型输出是“物体名 边界框/中心坐标 置信度”例如bottle: [120, 340, 210, 420]。关系层基于感知层结果抽取空间关系采用结构化三元组。例如(bottle, left_of, cup)同时声明参考系reference: image_view。推理层在关系层基础上完成空间变换或路径推导每一条推导都引用前述对象。例如 “从 bottle 到 cup需要向右移动 60 像素再向下移动 20 像素”。输出层根据推理层生成最终答案可以是选项、坐标、路径文本或边界框。这种设计的好处非常明显每一层都需要显式写出依据模型很难“瞎编一个看起来合理的中文句子”。评测人员也可以把错误定位到具体层级如果感知层坐标错那就是检测问题如果关系层三元组错那就是关系推理问题如果关系层正确但最终答案错那就是推理输出映射问题。结构化并不一定意味着 JSON但训练时通常会把 JSON 或类似 XML 的中间格式作为监督信号。推理时可以选择让模型先输出完整结构化步骤也可以强制拆成多轮生成每轮只补全一个槽位。4.2 模块二多目标过程奖励多目标过程奖励的核心不是只给一个总分而是把“步骤质量”拆成多个维度分别打分。从空间推理场景出发至少可以有四类目标感知一致性模型提到的对象是否真的存在于图中位置描述是否与视觉特征匹配。关系正确性空间关系三元组是否符合参考系定义。步骤连贯性当前步骤是否引用了前面步骤的对象是否存在逻辑跳跃。答案忠实性最终答案是否由前面的结构化步骤推导而来而不是凭空生成。过程奖励模型通常在“步骤 当前上下文”上训练每个步骤都会产出一个分数向量。比如说第 2 步“杯子在桌子的左边”如果参考系不明确那么“关系正确性”分数会很低即便最终答案刚好蒙对模型也不会得到高分。多目标设计的价值是避免“一票否决”和“单一分数过拟合”。训练时可以采用加权融合也可以为每个目标单独训练打分头再在推理时按任务需求动态调整权重。对空间推理来说关系正确性通常权重最高因为它是中间层的核心产物。4.3 模块三推理时搜索有了过程奖励模型推理时就可以做“采样 筛选”第一步让策略模型基于当前状态生成若干个候选步骤。第二步过程奖励模型给每个候选步骤打分。第三步保留高分候选继续扩展低分分支被修剪。第四步达到终止状态后综合各步分数选择最终答案。常用算法包括 Best-of-N、Beam Search、以及逐步拒绝采样。这类搜索的核心收益是模型单次生成的空间推理答案可能带有随机错误但通过多次采样和过程奖励筛选最终答案的正确率通常明显优于单次 greedy 解码。搜索意味着推理开销增加。每多保留一个候选分支就会多一次前向计算。落地时需要在性能和准确率之间做取舍高可靠场景可以设置较大 beam 数或采样数高吞吐场景则压缩候选数量。5. 评测空间推理能力要关注哪些基准复现或使用 SCOUT 时一定要把评测做好。空间推理不是“模型能说出来就行”需要可量化、可对比的指标。通常可以从这几个维度选择基准空间关系理解例如判断两个物体之间的左右、上下、前后关系常见数据集包括 VSR、SpatialBench 等方向。关系问答给定一张图和一个空间关系问题回答正确与否。目标定位输出目标对象的边界框或坐标用 IoU 或相对误差评估。路径规划给定栅格地图或真实场景图像评估模型给出的路径是否有效、是否最短、是否绕开障碍。空间变换旋转/镜像/缩放后的关系保持能力评估模型是否理解坐标变换。看论文实验时重点盯几个点是否和同规模普通 CoT 模型对比。是否区分了“感知错误”“关系错误”“输出错误”三类失败。是否报告了推理时采样次数或搜索开销只看准确率不看计算成本没有意义。需要特别提醒空间评测集很容易被“背答案”污染。如果模型在训练阶段见过评测图准确率会虚高。所以实际项目里最好自建一小批未见过的空间关系测试图用来做最终验收。6. 复现 SCOUT 的环境准备虽然目前没有确认的官方仓库但这类“VLM 微调 过程奖励 推理搜索”框架的复现环境可以按通用清单准备。6.1 硬件环境GPU训练阶段需要至少一张支持 CUDA 的显卡显存大小取决于底座模型和分辨率。7B 级模型微调建议 24GB 以上显存推理阶段 16GB 左右可以跑得比较轻松更大尺寸模型需要多卡。CPU只负责数据预处理和调度建议 8 核以上。内存32GB 起步处理高分辨率图片数据时建议 64GB。磁盘模型权重、训练数据、中间缓存都会占空间建议预留 100GB 以上。6.2 软件环境这里给一套通用环境检查命令实际版本需要以项目官方仓库为准# 创建虚拟环境 conda create -n scout python3.10 -y conda activate scout # 安装基础依赖 pip install torch transformers accelerate peft datasets pip install vllm # 如果要部署推理服务 # 检查 CUDA 是否可用 python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))如果要复现过程奖励模型训练通常还需要deepspeed、flash-attn、wandb这类训练辅助库。建议先在小数据集上跑通全流程再上完整训练集。6.3 数据准备空间推理数据是这套方法的关键。典型做法包括从现有空间理解数据集中清洗出“对象 坐标 关系三元组”。用程序合成图片自动生成带空间标签的数据这种方法最容易控制质量。用图像标注工具给真实图片打上边界框和关系标签。每个样本至少应包含输入图片、结构化推理步骤、最终答案、每步的过程标注正确/错误或分数。过程奖励模型的训练质量完全取决于过程标注质量所以最理想的来源是“程序化合成数据”或“半自动标注 人工复核”。6.4 启动脚本的通用模板如果没有官方脚本可以参考下面的模板组织流程# 1. 数据预处理 python preprocess_data.py \ --input_dir ./raw_data \ --output_dir ./processed_data \ --image_size 512 # 2. 训练过程奖励模型 python train_prm.py \ --base_model_path ./models/qwen-vl-7b \ --train_data ./processed_data/prm_train.jsonl \ --output_dir ./outputs/prm_model \ --batch_size 4 \ --learning_rate 1e-5 # 3. 训练策略模型带结构化CoT监督 python train_policy.py \ --base_model_path ./models/qwen-vl-7b \ --train_data ./processed_data/policy_train.jsonl \ --output_dir ./outputs/policy_model \ --load_prm ./outputs/prm_model这只是一个结构参考。真正复现时需要把脚本名、参数、数据格式全部替换成项目仓库里实际提供的文件不要直接照抄。7. 推理部署与 API 接入思路SCOUT 推理阶段如果做成了服务通常会暴露一个“图片 问题 搜索参数”的接口。由于没有具体仓库这里给出基于 HuggingFace Transformers 和 vLLM 的通用接入模板。7.1 使用 Transformers 做单次推理import torch from transformers import AutoModelForVision2Seq, AutoProcessor model_path ./models/qwen-vl-7b processor AutoProcessor.from_pretrained(model_path) model AutoModelForVision2Seq.from_pretrained( model_path, torch_dtypetorch.bfloat16, device_mapauto ) image_path ./test_samples/living_room.jpg question 杯子是在桌子的左边还是右边请先输出结构化推理步骤。 prompt fimage\n{question} with open(image_path, rb) as f: image processor.image_processor(f.read(), return_tensorspt) inputs processor( textprompt, imagesimage, return_tensorspt ).to(model.device) output model.generate( **inputs, max_new_tokens512, do_sampleFalse, temperature1.0, ) response processor.decode(output[0], skip_special_tokensTrue) print(response)注意这里的model_path需要替换成实际权重路径max_new_tokens要按结构化输出长度调整太短会截断推理过程。7.2 用 vLLM 起 OpenAI 兼容服务如果要把 SCOUT 集成到业务系统建议用 vLLM 启动服务便于复用 OpenAI 客户端生态。vllm serve ./models/qwen-vl-7b \ --served-model-name scout-vlm \ --dtype bfloat16 \ --max-model-len 4096 \ --port 8000调用示例import requests import base64 url http://127.0.0.1:8000/v1/chat/completions with open(./test_samples/living_room.jpg, rb) as f: base64_image base64.b64encode(f.read()).decode(utf-8) payload { model: scout-vlm, messages: [ { role: user, content: [ {type: image_url, image_url: {url: fdata:image/jpeg;base64,{base64_image}}}, {type: text, text: 杯子是在桌子的左边还是右边请先输出结构化推理步骤再给出最终答案。} ] } ], temperature: 0.2, max_tokens: 512 } response requests.post(url, jsonpayload, timeout120) print(response.json()[choices][0][message][content])这一步跑通后就可以把模型接到自动化流程或评测脚本里。7.3 批量评测的目录设计空间推理需要批量验证。建议把输入输出分目录管理project/ ├── inputs/ │ ├── images/ │ └── questions.jsonl ├── outputs/ │ ├── responses/ │ └── metrics.jsonl ├── scripts/ │ ├── run_eval.py │ └── parse_result.py批量任务建议逐条写入outputs/metrics.jsonl每一步记录图片路径、问题、模型输出、评分、是否成功。这样即使批量任务中断也能从断点继续不用重跑全部。8. 功能测试与效果验证拿到模型或复现成功后建议按下面几个维度做功能测试。每个维度都要有明确输入、预期输出和失败判定标准。8.1 基础空间关系测试测试目的验证模型能否判断两个物体之间的左右、上下关系。输入示例一张桌上左边放杯子、右边放书本的图片问题“杯子和书本的位置关系是什么”。预期输出模型输出结构化步骤最后给出“杯子在书本左边”或等价关系。成功标准最终关系正确且中间步骤中的对象定位和三元组也正确。常见失败对象识别错或把“参考系”判断错。8.2 坐标定位测试测试目的验证模型能否输出目标对象的坐标或边界框。输入示例一张卧室场景图问题“床的位置在哪里”。预期输出边界框坐标例如[x1, y1, x2, y2]。成功标准输出坐标和人工标注框的 IoU 达到设定阈值。常见失败坐标格式不符合约定或模型位置偏移明显。8.3 路径规划测试测试目的验证模型能否完成带空间约束的路径推理。输入示例一张俯视地图标注起点、终点和一个障碍物问题“从起点到终点怎么走”。预期输出步骤化路径描述例如“先向右移动两格再向上移动一格”。成功标准路径有效、可执行、绕开障碍且没有空间跳跃。常见失败模型遗漏障碍物或方向描述与地图坐标系不一致。8.4 多步空间变换测试测试目的验证模型能否理解旋转、镜像等变换。输入示例一张包含三个物体的图片问题“如果把图片水平翻转杯子还在桌子的左边吗”。预期输出模型先描述翻转前关系再描述翻转后关系最后给出答案。成功标准翻转后的关系推导正确。常见失败模型直接给答案跳过中间推理或对翻转理解错误。8.5 过程奖励分数可用性测试测试目的验证 PRM 分数是否能区分好坏步骤。输入示例构造一个正确步骤和一个错误步骤分别输入 PRM。预期输出正确步骤得分明显高于错误步骤。成功标准分数排序稳定多次测试不反转。常见失败PRM 对细微错误不敏感说明训练数据里这类负样本太少。9. 资源占用与性能观察9.1 显存占用观察推理时可以用nvidia-smi观察显存占用nvidia-smi -l 1也可以封装一层记录import subprocess def get_gpu_memory_mb(): result subprocess.run( [nvidia-smi, --query-gpumemory.used, --formatcsv,noheader,nounits], capture_outputTrue, textTrue, checkTrue ) return int(result.stdout.strip().split(\n)[0])显存占用主要取决于三个因素底座模型参数量7B 通常比 13B 少一半左右。输入图片分辨率分辨率越高视觉 token 越多显存增长明显。采样候选数量搜索时保留多个分支显存会按分支数量扩大。9.2 时间开销观察SCOUT 推理阶段比普通 VLM 多了一个搜索循环。假设每次生成 5 个候选步骤每个步骤打分一次实际推理时间可能是普通模型生成答案的 3 到 10 倍。落地时建议先用小 beam 数跑通确认准确率提升效果。如果 beam 从 1 增加到 3准确率提升明显就值得保留如果提升很小说明搜索收益有限应该优先修数据。批量推理时注意控制并发防止单卡显存被打满。9.3 如何降低资源占用降低输入分辨率按任务裁剪目标区域。限制 max_new_tokens结构化输出不需要无限制长度。搜索时先过滤明显低分候选减少后续扩展。使用 vLLM 的 continuous batching 提升吞吐。10. 常见问题与排查方法问题现象可能原因排查方式解决方案模型输出格式不稳定未在数据中约束结构化输出格式查看全部错误输出统计格式偏离模式在 prompt 中加格式示例或训练阶段统一格式PRM 分数区分度低训练数据中负样本太少打印每个样本分数分布增加对抗性负样本如左右互换、参考系缺失最终答案正确但中间步骤错误奖励权重不合理分目标检查 PRM 分数提高关系正确性和步骤连贯性的权重显存不足图片分辨率太高或采样分支太多观察 nvidia-smi 的占用曲线降低分辨率、减小 beam 数、开启 flash attention接口返回超时搜索步骤太多导致推理时间过长记录单次请求耗时减少候选数量或改用异步任务队列批量任务卡住个别图片损坏或模型输出乱码增加异常捕获记录失败样本增加重试机制跳过不可处理样本复现结果和论文不一致底座模型或数据清洗差异对比权重版本和解码参数先复现论文的评测集再迁移到自有数据空间关系总是反的标注参考系和推理参考系不一致抽样检查标注和 prompt 描述统一“图像左侧/物体左侧/参考系”的定义这里要特别强调一点空间推理模型最容易踩的坑不是模型能力不够而是数据标注的参考系定义混乱。左边是谁的左边前边是谁的前边如果不给标注员和模型同时明确规则再好的过程奖励也学不到一致信号。11. 最佳实践与合规建议11.1 工程化建议第一第一次尝试先小参数跑通。先用一个较小的底座模型、小批量数据跑通“结构化 CoT 生成 - PRM 打分 - 搜索选择”的完整链路确认没有格式和接口问题后再放大到完整数据集。第二保留最小可运行配置。把数据预处理、训练、推理、评测四段脚本固化下来保证任何时候都能快速复现。代码、权重、数据一定要分目录管理避免互相污染。第三批量任务必须有日志和失败重试。空间推理批量评测可能跑几个小时中途卡住很常见。建议所有中间结果实时写入磁盘不要全部堆在内存里。第四接口服务要限制访问范围。如果部署了 vLLM 服务默认监听地址要设置为本地或内网不要无脑映射到公网。鉴权可以复用 API Key 或网关代理。11.2 数据与模型合规空间推理方法常常要处理真实场景图片。使用公开数据集时要确认许可协议使用自有图片时要注意是否包含个人隐私或敏感信息。涉及室内布局、车辆行驶、人体动作等场景时先做数据脱敏再进训练流程。不要使用来源不明的爬虫数据集。11.3 上线前复核模型在测试集上分数高不代表上线稳定。空间任务对视角、光照、遮挡非常敏感建议最后用一批“和训练分布不同的新场景”图片做盲测。如果盲测准确率明显低于测试集说明泛化能力还不够应该增加数据多样性而不是继续调搜索参数。12. 总结与下一步SCOUT 最值得关注的点是它把“空间推理”从黑盒问答变成了“结构化拆解 过程奖励 搜索验证”的工程问题。如果你想复现或借鉴最先应该验证的能力是“结构化思维链是否真的能提高关系判断准确率”以及“PRM 分数是否能稳定区分好步骤和坏步骤”。最容易踩的坑是数据参考系混乱以及中间步骤格式不统一。下一步可以延展的方向很多在自有业务数据上构造空间推理结构化标注把 SRM 的多目标权重按任务动态调节结合具身智能场景做真实环境测试甚至把搜索策略从 best-of-n 换成更高效的树搜索。空间推理不会只停留在问答榜单上它在机器人、文档理解、自动驾驶数据标注辅助里都有实际价值。建议先本地跑通一个小流程确认数据格式、奖励设计和推理搜索的效果再决定是否投入完整训练资源。这篇解读先到这里后续如果仓库和实验细节公开可以再出一篇分步复现和调参的实测笔记。