如果你正在用大模型做机器人抓取、UI 自动点击、3D 场景生成、室内导航甚至下棋大概率已经碰到过同一个尴尬它能写漂亮代码能解释复杂业务逻辑但一问“书架第三层右边那本书被我往后推了 20 厘米现在它的坐标大约是多少”就明显露怯。这个现象不是某个模型的偶发 bug而是空间推理spatial reasoning在大语言模型上的系统性短板。最近 Hacker News 上有人专门提出了一个很现实的问题How do you correct spatial reasoning of LLMs?评论区翻来覆去其实都在讨论同一件事——语言模型的空间感为什么这么差以及能不能靠训练、提示词或外部工具把它“救回来”。本文不打算复述原帖而是按工程化的方式把这个问题拆开先讲清楚空间推理难在哪再对比提示词、微调、多模态、工具化四条改进路线最后给出一套可以照做的评测和落地建议。无论你是做 Agent 应用、机器人控制还是单纯在调数据这篇文章都值得收藏备用。1. 这篇文章真正要解决的问题看到“LLM 空间推理差”这个结论很多人的第一反应是那多给点训练数据不就行了实际上没那么简单。这里先给一个明确判断大模型空间推理差根因不是数据量不够而是“语言符号”和“空间几何”之间的信息表征不匹配。语言模型从训练目标里学到的是“下一个词最可能是什么”的统计规律而空间推理要求模型在心智里维护一个连续的几何坐标系这恰好是统计语言建模最不擅长的隐性任务。因此纠正空间推理不是靠“多问几遍”“加个温度参数”能解决的必须同时调整三层输入层如何把空间信息写清楚让模型更容易解析。推理层如何引导模型用坐标、符号、代码而不是“感觉”来推理。验证层如何用可量化的空间任务测试模型是不是真的进步了。本文适合三类读者正在做 Agent / 机器人 / 自动驾驶 / 具身智能应用被“方向错乱”“物体位置算错”坑过的开发者。需要给大模型构建空间推理评测集验证模型能力边界的算法工程师。想系统理解“为什么语言模型空间感弱”的产品和技术决策者。读完这篇文章你可以带走一套“诊断 改进 验证”的方法能定位模型在哪种空间任务上失败能选择至少三种可落地的改进路线并且能用最小脚本判断改进是否有效。2. 空间推理到底是什么为什么对 LLM 如此困难2.1 空间推理的含义与层次空间推理并不是一种单一能力。按任务类型大致可以分四层层级任务示例对 LLM 的难度一阶关系“A 在 B 的左边”中依赖语序与常识距离与坐标“A 距离 B 约 3 米C 在 AB 中点”高需要数值计算旋转与变换“物体绕 Y 轴旋转 90 度后朝向哪边”很高需要几何建模多步规划“从客厅走到厨房绕过沙发先左转再直行”很高需要路径维护人类做这些任务时依赖视觉、动觉和一个“内在空间地图”。语言模型没有这些东西它只能从训练语料中的文字描述去反推空间关系。语料里有多少“杯子在桌子左边”它才能学到多少统计关联。一旦组合方式在语料里少见比如“坐标系有旋转且原点偏移”它就很难推断。2.2 模型为什么“答非所问”用一句话概括语言模型是离散符号系统空间推理需要连续几何系统。具体有三个技术原因第一Tokenizer 会把数字拆碎。比如“3.14 米”会被拆成多个 token模型在做数值进位、距离比较时天然处于“按 token 猜数”的状态而不是“按数值算”的状态。第二推理目标与几何约束不对齐。语言建模目标是最大化下一个词的似然几何上“自洽”并不在训练目标里。模型没有内部损失惩罚“矛盾的位置关系”。第三没有视觉或动作反馈闭环。人一旦摆错方向看一眼或碰一下就能修正LLM 在纯文本输入下没有这种闭环。这三点解释了为什么把 Prompt 换成“请仔细思考空间关系”往往无效——问题不在态度而在机制。2.3 和视觉模型、传统几何引擎的对比换个角度理解如果任务只需要“识别图片里的杯子在哪”视觉模型和检测模型做得很好如果任务需要“在三维世界里精确移动物体”传统几何引擎仿真器、CAD 内核、SLAM做得很好。LLM 夹在中间它要解决的问题是“把人类语言转换成几何约束再决定下一步动作”。它真正强的不是几何计算而是语言解析与任务分解。所以纠正空间推理的总体思路很清晰不要让 LLM 直接做几何运算而是让它擅长“翻译”和“编排”把精确计算交给代码、工具或专用模型。3. 纠正空间推理的四种路线当前实践里改进 LLM 空间推理大致有四条路各有成本和适用边界。路线核心思路成本适合场景提示词工程用结构化描述、锚点、坐标系让模型少犯错低无需训练快速验证、轻逻辑任务符号落地让 LLM 生成代码/几何命令由程序执行精确计算中需要工具坐标、路径、旋转等强计算任务数据微调用空间推理样本微调模型参数高需要算力固定场景的垂直模型多模态对齐引入视觉输入、检测模型或具身环境高工程量大真实物理世界任务不一定要互斥。实际项目里最常见的是“提示词 符号落地 多模态”组合模型负责理解语言、拆分任务、生成代码工具负责算坐标视觉模型负责检测遮挡与姿态。下面按成本从低到高逐一展开。4. 提示词层用空间锚点与结构化描述先纠正一部分4.1 为什么“认真一点”没有用很多人遇到模型空间答错第一反应是往 Prompt 里加“请仔细思考”。这种写法基本无效因为模型不是不努力而是缺少可引用的几何锚点。试一下这个例子用户房间里有桌子桌上有杯子和书杯子在书的左边30厘米。如果桌子整体右移50厘米杯子在哪里模型可能把“右边”和“移动”混在一起给出一个模棱两可的答案。原因是 Prompt 里没有给“以哪个点为原点”“是在俯视图还是正视图”这样的空间坐标框架。4.2 空间锚点提示词模板更有效的做法是在 Prompt 里显式定义坐标系、方向和单位。# 文件路径prompts/spatial_system.py SPATIAL_SYSTEM_PROMPT 你是一名空间推理助手负责把自然语言空间描述转换为结构化坐标。 请遵循以下规则 1. 默认使用二维俯视图坐标系原点为房间(0,0)x轴向右为正y轴向上为正。 2. 物体位置用 (x, y) 表示单位是米。 3. 如果用户提到左右默认按观察者视角转换。 4. 只输出结构化JSON不要输出多余解释。 示例 用户杯子在书的左边30厘米。 输出{objects:[{name:cup,position:[0.3,0],anchor:book},{name:book,position:[0.6,0]}]} 这个模板的价值不是让模型“变聪明”而是把空间推理从“开放式问答”变成“受限的结构化翻译任务”模型犯错的自由度被大幅压缩。4.3 把推理步骤拆成中间表示如果任务更复杂比如旋转、遮挡、相对运动可以引入“空间状态”中间变量。流程建议是先让模型列出已知物体、定义坐标系、写出变换步骤最后再计算。这一步在工程上叫“空间状态显式化”。# 文件路径prompts/spatial_cot.py STEP_PROMPT 请你分四步解决这个问题并把每一步单独输出 第一步列出场景中所有物体及其已知相对关系。 第二步定义统一坐标系和正方向。 第三步把用户描述的位置关系写成坐标方程。 第四步解方程并给出最终坐标。 问题书架上有三本书A在B右边10cmC在A上方20cm。如果整个书架向右平移30cmC的新位置是什么 用这种模板即便最终数值算错你也能从中间步骤定位模型是在坐标系定义、方程转换还是计算环节出错。这是后续评测和排错的基础。小结提示词工程只能纠正“语言描述不完整”导致的空间错误它对真正的几何计算痛点帮助有限。下一步要引入代码。5. 符号落地把空间问题变成代码问题5.1 核心思路这是目前最推荐的工程路线。思路很简单LLM 不擅长的连续几何计算全部交给代码库或几何引擎。LLM 的职责变成从用户语言中解析出物体、关系、坐标系。生成可执行的 Python 代码或调用几何命令。把代码执行结果格式化成用户可读的返回。这样做的好处是计算精度高、可追溯、可测试。缺点是依赖模型生成代码的正确性所以仍然要配合严格校验。5.2 一个可运行的坐标变换示例下面用二维坐标变换演示一个最简实现。假设 LLM 负责把用户描述解析成变换参数变换函数用 Python 实现。# 文件路径spatial_tool/geometry.py import math from dataclasses import dataclass dataclass class Point: x: float y: float def translate(p: Point, dx: float, dy: float) - Point: 平移变换 return Point(p.x dx, p.y dy) def rotate(p: Point, angle_deg: float, center: Point Point(0, 0)) - Point: 绕指定中心旋转角度单位度 rad math.radians(angle_deg) # 先平移到原点旋转再平移回去 dx p.x - center.x dy p.y - center.y new_x dx * math.cos(rad) - dy * math.sin(rad) center.x new_y dx * math.sin(rad) dy * math.cos(rad) center.y return Point(new_x, new_y) # 示例杯子在 (0.5, 0.2)绕桌子中心 (0.3, 0.4) 旋转 90 度 cup Point(0.5, 0.2) new_cup rotate(cup, 90, centerPoint(0.3, 0.4)) print(f旋转后杯子位置({new_cup.x:.2f}, {new_cup.y:.2f}))# 运行方式进入 spatial_tool 目录后执行 python geometry.py预期输出旋转后杯子位置(0.10, 0.60)这个例子虽然只涉及平面旋转但已经能说明问题当模型不确定“旋转后坐标是多少”时更好方式是让它调用这样一组可信函数而不是凭空给答案。5.3 让 LLM 生成工具调用在 Agent 场景里你可以把几何能力注册成一个工具{ type: function, function: { name: rotate_point, description: 绕指定中心旋转一个二维点返回新坐标, parameters: { type: object, properties: { x: {type: number, description: 点x坐标}, y: {type: number, description: 点y坐标}, center_x: {type: number}, center_y: {type: number}, angle_deg: {type: number, description: 旋转角度单位度} }, required: [x, y, center_x, center_y, angle_deg] } } }模型负责把“把杯子绕桌子中心顺时针转 90 度”解析成rotate_point(x0.5, y0.2, center_x0.3, center_y0.4, angle_deg90)几何函数负责返回精确结果。这个组合能显著减少“模型一本正经算错坐标”的问题。符号落地同样适用于三维场景可以用numpy、transforms3d、open3d等库处理旋转矩阵、四元数、点云变换。模型只需要会调用 API不需要自己掌握几何计算。6. 数据层面用微调纠正空间推理6.1 什么时候值得微调提示词和工具调用能覆盖大多数轻量场景但有一个情况绕不开你的模型需要在特定领域里频繁输出坐标或空间判断而每次调用工具都要多一轮延迟还容易受模型函数调用能力影响。这时可以考虑微调一个小型垂直模型。微调空间推理的三种常见目标输出规范化让模型学会输出固定格式的空间结构化 JSON。坐标解析让模型从长文本中稳定抽取物体位置关系。受限推理让模型在小范围数据集上学会特定几何变换规则。6.2 微调数据格式示例下面给出一个适合指令微调的数据格式示例。{ instruction: 请把下面这句话转换为空间坐标JSON。, input: 书桌上有一台显示器键盘在显示器正前方20厘米处鼠标在键盘右边15厘米处。以显示器中心为原点前方为y轴正方向。, output: {\objects\:[{\name\:\keyboard\,\position\:[0,-0.2]},{\name\:\mouse\,\position\:[0.15,-0.2]}]} }训练数据准备阶段要注意三点坐标系必须统一。同一个训练集里不要一会儿用“左上角为原点”一会儿用“中心为原点”。单位必须统一。混用厘米、米、像素会让模型学到混乱的映射。必须包含反例。比如用户描述里有歧义时模型应该输出“坐标信息不足”而不是强行编一个坐标。6.3 微调实践建议数据规模先准备 30005000 条高质量样本跑通流程再根据评测结果递增。基座选择优先选择指令遵循能力强的中小模型而不是超大模型便于迭代。评测集隔离训练集和评测集必须来自不同场景避免模型背题。回归测试每次微调后都要跑一遍旧有空间任务评测集防止“改了空间丢了语言”。7. 多模态与具身把图像和物理反馈引进来7.1 为什么纯文本有天花板纯文本输入存在一个信息瓶颈物体在真实世界里的姿态、遮挡、光照和拓扑关系很难用语言完整表达。比如“杯子在书后面”这句话在语言上只有一层关系但视觉上“挡住多少”“露出多少”会直接影响“能否抓取”这样的下游决策。纯语言模型无法得到这类信息。7.2 视觉-语言模型的基本改造思路当项目需要处理真实图像时建议把 LLM 放在一个更大的“感知 - 推理 - 执行”链路里感知层用目标检测模型或视觉语言模型输出物体的 2D/3D 位置。推理层LLM 接收这些定位结果结合用户语言生成动作计划。执行层规划好的坐标与路径交给运动控制或仿真器执行。这里的关键变化是空间感知从“模型脑补”变成“传感器返回”。LLM 不再需要猜测物体在哪它只需要根据传感器数据推理下一步动作。这种改造的实际效果通常远好于让纯文本 LLM 直接输出“物体大概在图片中间偏右”。7.3 具身智能给我们的重要启示具身智能领域有一个共识智能体需要通过与环境的交互闭环来建立空间概念。模型预测的坐标如果和真实环境不符环境反馈会立刻暴露错误从而让模型有机会修正。这种做法的工程化形式包括在仿真环境中不断生成空间任务让模型根据碰撞、遮挡、距离误差等反馈更新空间状态。用强化学习或行为克隆把“空间判断 → 动作”的映射固化进模型。对绝大多数 CSDN 读者来说直接上具身方案成本很高但可以借鉴它的思想给你的 LLM 空间推理加一个外部校验器。模型输出坐标后用一个简单的几何规则让它自检就能减少不少低级错误。8. 如何评测空间推理是否真的被纠正8.1 建立自己的评测集空间推理最怕“看起来变聪明一测就露馅”。所以改进前建议先搭一个最小评测集。评测集至少覆盖三类任务物体关系判断左右、前后、上下。数值变换平移、旋转、缩放后的坐标。多步任务结合多个相对关系的推导。每个任务准备 2050 题分成 A/B 组避免模型记忆顺序。8.2 自动评测脚本一个朴素的自动评测方法是让模型输出 JSON 坐标再用程序比较与真值的差值控制在阈值内算通过。# 文件路径eval/spatial_eval.py import json import math def distance(p1, p2): return math.sqrt((p1[x] - p2[x])**2 (p1[y] - p2[y])**2) def evaluate(model_output, expected, threshold0.05): model_output: 模型生成的JSON字符串expected: 标准答案JSON try: pred json.loads(model_output) except json.JSONDecodeError: return False, JSON解析失败 if objects not in pred: return False, 缺少objects字段 for obj in pred[objects]: name obj[name] if name not in expected: continue dist distance(obj[position], expected[name]) if dist threshold: return False, f{name}坐标误差{dist:.3f}超过阈值 return True, 通过 # 示例 expected {keyboard: {x: 0, y: -0.2}, mouse: {x: 0.15, y: -0.2}} model_out {objects:[{name:keyboard,position:[0.0,-0.21]},{name:mouse,position:[0.14,-0.19]}]} ok, msg evaluate(model_out, expected) print(ok, msg)运行python eval/spatial_eval.py预期输出True 通过如果模型输出解析失败或坐标偏差过大脚本会直接给出失败原因方便你定位问题。8.3 如何解读评测结果如果模型在“一阶关系”全对但在“旋转”全错说明它对坐标变换的几何规则没有掌握优先走“符号落地”路线。如果模型在“结构化 JSON 输出”环节频繁解析失败优先做输出格式微调。如果模型在“真实图像”任务上失败说明它缺少视觉信号必须引入多模态感知。评测的价值不在于得出“模型空间推理 80 分”而在于告诉你“在哪个环节丢分”从而决定下一步怎么改进。9. 常见问题与排查思路问题现象可能原因排查方式解决方案模型把“左边”理解成“右边”未定义观察者视角或坐标正方向检查 Prompt 中是否明确坐标系在系统提示词里固定“从观察者视角看左边为 x 负方向”输出 JSON 经常解析失败模型自由生成混杂了多余文字查看原始输出内容改用工具调用或后处理提取 JSON微调输出格式坐标数值差一位小数单位不统一或 tokenizer 拆数检查输入是否混用 cm/m统一单位数值交给代码计算不让模型直接算旋转后方向常见错误模型缺乏几何规则对比旋转前/后坐标接入几何函数或旋转矩阵工具微调后反而更差评测集与训练集分布不一致检查训练/评测场景重叠扩大数据多样性增加反例样本多模态模型对遮挡物体定位不准仅靠 2D 图片难以恢复 3D 位置检查是否使用单目还是双目输入引入深度估计或点云等 3D 感知10. 最佳实践与工程建议从工程角度看我建议把“纠正空间推理”当成一个系统问题而不是单独优化模型。第一永远让精度敏感运算远离大模型。空间推理里的加减乘除、旋转矩阵、路径计算尽可能交给人可读、可测试的代码模块。大模型负责“语义解析”和“任务编排”这就已经覆盖了大部分收益。第二Prompt 要模板化而不是靠感觉。把“空间锚点 坐标系定义 结构化输出”固化成一个模板不同任务复用同一套坐标系约定比每次临时写提示词稳定得多。第三建立回归测试。空间推理是典型的“改一处坏一片”问题。每次调整 Prompt、微调模型或换基座模型都要跑一遍已有的空间评测集避免顾此失彼。第四对模糊输入要拒绝回答。真实用户描述空间关系经常有歧义比如“右边”没有说明是观察者视角还是物体自身视角。好的系统应该提示用户补充而不是让模型“猜”。这就需要在评测集里加入“信息不足应该拒绝输出”的样本。第五安全边界。如果空间推理被用于机器人、自动驾驶、无人机等物理世界场景必须设计兜底机制模型输出的坐标或路径要经过几何合法性检查误差超过阈值就中止执行绝不能直接把未校验的结果送到执行器。11. 总结与后续学习方向这篇文章想表达的核心判断是LLM 空间推理弱是表征不匹配的结果纠正它的关键不是让模型更努力而是调整信息形式、推理路径与验证方式。提示词工程能解决“描述不完整”的问题符号落地能解决“几何计算不精确”的问题微调能解决“输出不规范”的问题多模态和具身能解决“缺少真实感知”的问题。四者不是单选题而是按成本从低到高的组合拳。如果你接下来要动手我建议按这个顺序实践先搭一个 20 题左右的空间推理评测集跑一遍当前模型找出失败集中在哪一类任务。给 Prompt 加上坐标系、锚点和结构化输出要求看一类问题能否改善。把数值计算部分替换成代码工具或函数调用再跑一遍评测。如果还不够再考虑微调或引入视觉感知。后续可以深入的方向包括三维旋转与四元数表示、复杂路径规划、空间常识知识的注入以及将空间推理能力与机器人实际控制闭环打通。空间推理不会成为大模型天生强项但它完全可以通过合理的系统设计变成可预测、可评测、可交付的工程能力。