“把苹果放在杯子的右侧然后把盘子移到苹果左边最后告诉我盘子在杯子的什么方向”——如果你把这类问题抛给当前的主流大模型得到的答案可能让你意外它大概率能写出流畅的推理过程却在最终方向上给你一个完全相反的结论。这不是个别模型的缺陷而是 LLM 在空间推理spatial reasoning上普遍存在的短板。最近 Hacker News 上就有工程师发起“How do you correct spatial reasoning of LLMs?”的讨论很多人发现语言模型可以写诗、写代码、做数学题但在“左”“右”“前方”“旋转后朝向哪里”这类基础空间问题上会表现得不如一个三岁小孩。本文的核心判断是空间推理不能只靠“更聪明的提示词”来根治。真正有效的修正路线是把语言推理和空间计算分开——该让模型理解的部分用提示词和思维链强化该算的部分交给工具和环境反馈。读完这篇文章你会掌握一套从“诊断 LLM 空间推理缺陷”到“结构化提示词修复”“外接坐标计算”“回归评估”的完整实践方法可以直接用在自己项目里。1. 为什么空间推理成了 LLM 的“硬伤”1.1 什么是空间推理它到底解决什么问题空间推理指的是模型对物体位置、方向、距离、路径以及视角变化进行理解和推断的能力。它不只是“知道苹果在桌子上”这种静态描述而是能完成以下任务判断相对方位A 在 B 的左边、右边、前方还是后方。完成视角转换小明面向北他的左手边是什么方向。解决路径规划从一个点出发走几步、转几个弯最后到了哪里。理解三维空间物体体积、遮挡关系、远近关系。在现实项目中空间推理直接影响很多应用的体验智能家居助理用户说“把客厅左边那盏灯打开”模型要能理解是哪个方向的灯。机器人指令系统让机械臂把零件放到目标的左侧需要精确的方位换算。自动驾驶与导航对话乘客问“下一个路口向右转后我的目的地在左边还是右边”。游戏 AI / 虚拟现实NPC 根据玩家位置做出方向性描述和移动决策。换句话说空间推理不是理论问题而是已经写进产品需求里的硬功能。如果模型在这类问题上不可靠整个对话系统的可信度都会被打折扣。1.2 LLM 空间推理弱的三个根源要修正一个缺陷先得理解它为什么存在。LLM 在空间推理上的弱点主要来自三个层面。第一语言模型的预测对象是 token不是坐标。LLM 的核心能力是预测下一个词。它擅长从语料中学习语言的统计规律但语言中的“左边”和“右边”是高度上下文相关的。同样一个“左边”在不同观察者、不同朝向、不同坐标系下含义完全不一样。模型没有物理世界的坐标参照只靠文本中的相关性去推断很容易选错参照系。第二训练语料中充满了视角歧义。人类语言在描述空间关系时默认了大量的背景知识。例如“我的左边”“门的左边”“图片的左边”这些说法一旦脱离实际场景就存在至少两种解释。训练数据里的空间描述大概率没有统一标注视角模型学到的就是一种“模糊的、平均化的空间语义”在精确场景中自然出错。第三模型缺乏物理交互的反馈闭环。人类对空间的认知很大程度上来自身体移动、视觉观察和触觉反馈。你推一下杯子杯子倒了你会建立“作用力和位移”的关系。LLM 没有这些体验它只能从文字里间接学习空间规则遇到需要真实几何推算的问题时往往只能靠猜测。这三个根源意味着单纯换一个更大的模型不一定能解决空间推理问题。因为模型变大解决的是统计规律拟合能力而不是建立空间参照系的能力。这也是为什么社区里越来越多人开始寻找“修正”而非“升级”的方法。2. 空间推理问题的四种典型形态在动手修正之前最好先给问题分类。在实际开发中LLM 的空间推理失败可以归纳为四种形态。不同形态的修正策略完全不同。问题形态典型表现示例修正重点相对方位错误混淆左右、前后苹果在书的左边书在笔的左边问苹果在笔的哪边提示词显式化推理链视角转换失败忽略了观察者的朝向小明面向北他的左手边是哪个方向强制建立坐标系坐标与路径计算错误路线一长就出错先向北走 5 米再向东走 3 米最终在起点什么方向外部计算工具替代模型猜测空间常识缺失物理世界的基础空间关系混乱杯子放在桌子上桌子的上方是什么多模态输入或数据增强第一种最普遍问题出在模型没有把“相对关系”转成“可计算的中间状态”直接凭语感回答。第二种更隐蔽模型把“左手边”理解成了“画面左边”而不是“人物朝向的左边”。第三种暴露的是算术和几何组合推理的短板语言模型擅长模式匹配但不擅长逐步累积位置变化。第四种通常出现在嵌套较深的空间描述中模型没有世界模型只能靠语言联想。理解了这些形态就能制定有针对性的修正策略。3. 修正空间推理的六条技术路线3.1 路线一提示词工程把坐标系写进提示词这是成本最低、见效最快的路线适合相对方位和视角类问题。核心思想是不要在提示词里只问“它在左边还是右边”而是要求模型先定义坐标系、标注观察者朝向、列出物体坐标最后再得出结论。一个典型的对比是弱提示词“书在苹果的左边笔在书的左边问笔在苹果的哪一边”强提示词“请列出场景中的物体定义坐标系以苹果为原点X 轴向右Y 轴向上默认你站在苹果正前方。然后逐一标出书、笔的坐标最后根据坐标判断笔相对苹果的方位。”模型在“先定义坐标系”的约束下至少不会默认一个错误的视角。这个方法的原理不是教模型新知识而是强迫它把隐含假设变成显式步骤减少默认视角带来的歧义。3.2 路线二思维链强迫模型分步推导思维链Chain-of-ThoughtCoT对空间推理有帮助但关键不在于“多想一步”而在于“每一步只做一件小事”。很多空间推理题目失败原因是模型跳步。比如从“小明面向北”推导“左手边是西方”正确的推理链是面向北即朝向 Y 轴。左手对应左侧方向。面向北时左侧是西方。跳步的模型可能会直接给出“左边是北方”这样荒谬的结论。所以提示词中应该明确要求“输出完整推导过程并标注每一步的依据”。更好的一种做法是让模型用“伪代码”或“坐标表”来推理。例如要求第一步列出所有物体和观察者朝向。 第二步给每个物体分配坐标。 第三步根据坐标计算相对方向。 第四步输出结论。这相当于把空间推理转化成了一种近似计算流程模型的错误率会明显下降。3.3 路线三外部工具让代码替你算对于坐标、距离、路径类问题最可靠的做法不是让模型“算”而是让模型“把问题转化成代码”然后用外部函数执行计算。这是本篇文章最推荐的一种路线。理由很简单空间计算的规则是明确的、可验证的不需要模型的统计推断。求两个坐标之间的相对方向写一个atan2公式就够了模型没必要去“背”答案。工程上的常见做法是用 LLM 从用户的自然语言中抽取空间实体和坐标关系。将抽取结果传递给一个确定性的空间计算函数。将计算结果格式化成自然语言回传给用户。这种“LLM 做语义理解 工具做精确计算”的混合架构已经可以解决大部分空间推理问题。它也更接近未来 Agent 系统的设计方向——让模型专注于理解意图而不是代替一切。3.4 路线四多模态输入让模型看见空间如果任务本身涉及真实场景比如一张图片、一张地图、一段摄像头画面那么纯文本输入对模型来说信息已经丢失了大半。这时应该优先采用多模态模型把图像输入给模型让它在视觉信息上做空间判断。多模态模型在有图像参考时空间推理能力会比纯文本强一些因为它可以从画面中获取物体位置、大小、遮挡关系等视觉线索。但要注意视觉编码对细小位置信息仍然可能丢失所以不能完全依赖模型“看”最好让模型先“描述图中物体的坐标”再基于描述做推理。3.5 路线五微调训练数据当提示词和工具都无法满足需求时就要考虑微调。这条路线成本最高但效果也最可控。微调的关键是数据格式。空间推理的训练数据不能只是“问题-答案”对更好的格式是“问题-坐标系-分步推理-答案”。也就是说要把上文提到的“显式坐标化”写进训练样本让模型在微调阶段就学会先建立坐标系再推导答案。同时要注意数据中的视角标注。每条训练数据都应当明确观察者朝向、坐标系原点、方向约定避免把多义的空间描述塞进训练集。3.6 路线六Agent 与环境交互最后一种路线是把空间推理放回环境中解决。通过 Agent 在仿真环境或真实环境中执行动作观察反馈再调整判断。例如让 Agent 在模拟房间里执行“走到桌子左边”的指令如果坐标偏移了环境会给出碰撞或到达错误位置的反馈Agent 基于反馈修正内部空间模型。这种方法的优势是能建立起类似人类的“试错-反馈”闭环但工程复杂度较高一般用在机器人、自动驾驶、游戏 AI 等场景。对于大多数 Web 应用和对话系统来说前四条路线已经足够。这一条更适合做长期研究储备。4. 环境准备与前置条件为了让后续示例可以顺利跑通建议准备以下环境操作系统Linux / macOS / Windows 均可本文示例是标准 Python 代码。Python 版本3.9 及以上即可代码不依赖新特性。LLM API任意支持 Chat Completions 风格接口的大模型服务本地部署或云端 API 均可。依赖库openai如果你调用 OpenAI 兼容接口、math标准库、json标准库。如果你的项目使用 Spring AI、LangChain 或其他 LLM 编排框架也不影响理解——本文的核心是空间推理修正的思路而不是特定框架的专属写法。5. 核心流程拆解从诊断到修正修正空间推理不能上来就改提示词。正确流程是“先诊断再修复最后回归验证”。下面拆成五个步骤。5.1 步骤一构建空间推理测试集你需要一个小而精的测试集覆盖本章第 2 节提到的四类问题。建议至少准备 10 道题每个类别 2 到 3 道。测试集的价值在于它把“模型空间推理差”这个模糊感受变成了可量化的失败清单。修复之前先测一遍记录每道题的错误类型后面修改提示词或加入工具后再跑同一套测试集看通过率变化。5.2 步骤二跑基准测试记录失败模式把测试集喂给模型不要只看对错要记录每题的错误类型。是左右混淆是视角丢失还是计算错误这些失败模式直接决定你选择哪条修复路线。例如如果模型在“相对方位”类题目上大量混淆优先优化提示词如果问题集中在“路径坐标”上直接引入外部计算工具。这一步能避免你盲目试错。5.3 步骤三设计结构化提示词根据失败模式编写包含“坐标系、观察者、分步推理”要求的结构化模板。这个模板要成为后续所有空间推理问题的统一前缀让模型形成固定的推理习惯。5.4 步骤四加入工具计算辅助对于坐标计算和路径类问题不要指望提示词修复。直接把问题里的空间实体和坐标抽取出来交给确定性函数计算再把结果组织成自然语言回复。这一步的关键是让 LLM 负责“解析意图”和“组织语言”让代码负责“计算正确结果”。5.5 步骤五回归验证修改完成后回到测试集重新跑一遍。对比修改前后的通过率并确认没有引入新的错误类型。空间推理问题往往牵一发而动全身——修复了“左右混淆”可能暴露了“视角选择错误”所以回归验证必须保留。6. 完整示例与代码实现下面用四个示例把上面的流程落地成可运行的代码。6.1 示例一空间推理测试集与自动评估脚本文件路径spatial_eval.pyimport json TEST_CASES [ { id: relative_left_1, type: relative_position, question: 桌子上有一个苹果苹果左边有一本书书的左边有一支笔。请问笔在苹果的哪一边, answer: 左边 }, { id: perspective_1, type: perspective_transform, question: 小明面向北方站着他的左手边是什么方向, answer: 西方 }, { id: path_coord_1, type: path_integration, question: 从客厅出发向北走 5 米然后向东走 3 米此时你相对于客厅在什么方向, answer: 东北方向 }, { id: embedded_relation_1, type: relative_position, question: 书架在沙发的右侧花盆在书架的右侧请问花盆在沙发的哪一侧, answer: 右侧 } ] def load_test_cases(pathspatial_test_cases.json): if path: with open(path, r, encodingutf-8) as f: return json.load(f) return TEST_CASES def run_evaluation(llm_call, test_casesNone): 对给定 LLM 调用函数跑一遍空间推理测试。 llm_call 是一个接收 question 字符串、返回模型回答字符串的函数。 你可以根据自己使用的模型服务来实现该函数。 test_cases test_cases or TEST_CASES results [] passed_count 0 for case in test_cases: response llm_call(case[question]) passed case[answer] in response passed_count int(passed) results.append({ id: case[id], type: case[type], question: case[question], expected: case[answer], model_answer: response.strip(), passed: passed }) summary { total: len(test_cases), passed: passed_count, failed: len(test_cases) - passed_count, accuracy: round(passed_count / len(test_cases), 4) } return summary, results if __name__ __main__: # 演示用法传入一个简单 mock 函数 def mock_llm(question): return 左边 summary, results run_evaluation(mock_llm) print(json.dumps(summary, ensure_asciiFalse, indent2))这段代码的核心是TEST_CASES测试集和run_evaluation评估函数。实际项目中你需要把mock_llm替换成真实模型调用。6.2 示例二结构化空间推理提示词模板文件路径prompts.pySPATIAL_REASONING_PROMPT 请按以下固定步骤回答空间关系问题每一步都不能省略。 第一步列出题目中出现的所有物体或地点。 第二步定义坐标系。选择题目中最重要的物体作为原点X 轴指向右Y 轴指向前方。 第三步标注观察者。如果没有明确指定默认你站在场景正前方观察方向为 Y 方向。 第四步把每个物体或地点用坐标表示出来。 第五步根据坐标计算目标物体相对于参照物的方向。 第六步输出最终结论结论中必须包含方向和坐标依据。 注意 - “左边”和“右边”必须以观察者视角为准不是阅读视角。 - 如果题目同时存在多种坐标系定义方式先说明你的选择再继续。 - 如果题目本身无法建立坐标系请明确说明原因。 题目{question} def build_spatial_prompt(question, system_promptNone): 把用户问题和系统提示词组合成完整的请求体。 if system_prompt: return system_prompt \n\n SPATIAL_REASONING_PROMPT.format(questionquestion) return SPATIAL_REASONING_PROMPT.format(questionquestion)这个模板适用于大多数“相对方位”和“视角转换”类题目。如果你使用不同的模型服务只需要把最终字符串传给模型即可。6.3 示例三坐标计算辅助函数文件路径spatial_tools.pyimport math def relative_direction(origin, target, observer_heading_deg0): 计算 target 相对 origin 的八方向方位。 Args: origin: (x, y) 坐标参照物。 target: (x, y) 坐标目标物。 observer_heading_deg: 观察者朝向0 表示面向 Y北 90 表示面向 X东以此类推。 Returns: 八方向字符串例如 前方、右前方、右方 等。 dx target[0] - origin[0] dy target[1] - origin[1] # 先计算在标准坐标下的方位角以 Y 为 0 度顺时针 angle_deg math.degrees(math.atan2(dx, dy)) # 根据观察者朝向旋转 angle_deg (angle_deg - observer_heading_deg) % 360 directions [前方, 右前方, 右方, 右后方, 后方, 左后方, 左方, 左前方] index round(angle_deg / 45) % 8 return directions[index] def extract_origin_target_from_text(llm, question): 让 LLM 从自然语言中抽取坐标关系。注意这个函数依赖你的 LLM 接口。 extract_prompt f 从下面这个空间问题中抽取“参照物坐标”和“目标物坐标”。 如果题目没有明确给出坐标请自行设定一个合理的坐标系并输出 JSON。 格式要求 {{ origin: [x, y], target: [x, y], observer_heading_deg: 0, reason: 你选择的坐标系说明 } 问题{question} # 这里调用你的 LLM 接口解析 JSON 返回 # 示例中省略具体模型调用返回一个占位结果 return extract_promptrelative_direction是确定性函数不依赖模型结果稳定可复现。只要坐标抽取正确它的判断是可靠的。6.4 示例四融合提示词和工具的主流程文件路径main.pyimport json from spatial_eval import run_evaluation from prompts import build_spatial_prompt from spatial_tools import relative_direction class SpatialReasoningPipeline: def __init__(self, llm_call, use_toolTrue): self.llm_call llm_call self.use_tool use_tool def answer(self, question): 统一入口先抽取类型再决定使用提示词还是工具。 # 1. 判断题目类型是否涉及明确的坐标计算 type_prompt f判断下面这个问题的类型只输出 one of [relative_position, perspective_transform, path_coordinates, other]\n{question} q_type self.llm_call(type_prompt).strip() # 2. 如果涉及路径/坐标计算走工具分支 if q_type path_coordinates and self.use_tool: coords_result self._extract_coords(question) if coords_result: direction relative_direction( origincoords_result[origin], targetcoords_result[target], observer_heading_degcoords_result.get(observer_heading_deg, 0) ) return f根据坐标计算目标方位是{direction} # 3. 其他情况走结构化提示词分支 structured_prompt build_spatial_prompt(question) return self.llm_call(structured_prompt).strip() def _extract_coords(self, question): 从 LLM 输出里解析坐标。实际项目中需要处理 JSON 解析异常。 # 这里按照你的模型服务调用后解析 JSON return None if __name__ __main__: # 真实项目中llm_call 换成你的模型服务 def llm_call(prompt: str) - str: return 左边 # 占位返回 pipeline SpatialReasoningPipeline(llm_callllm_call) print(pipeline.answer(苹果左边有一本书笔在书的左边笔在苹果的哪一边))这里的SpatialReasoningPipeline展示了最核心的架构思想先判断题型再选择不同处理路径。坐标类问题走工具相对方位类问题走结构化提示词。这样既兼顾了精度也控制了调用成本。7. 运行结果与效果验证7.1 如何运行在项目根目录执行cd your_project # 运行评估脚本观察 mock 场景下的输出结构 python spatial_eval.py预期输出类似{ total: 4, passed: 1, failed: 3, accuracy: 0.25 }这里展示的是未接入真实模型前的框架运行效果。接入真实模型后准确率会反映出模型原有空间推理水平。一般基准测试通过率在 25% 到 50% 之间都是常见现象不必惊慌这正是修正流程要解决的问题。7.2 如何判断修正是否生效判断标准不是“这一次答对了”而是以下三点测试集整体通过率提升。同类错误出现频率下降。没有引入新的错误类型。例如加入结构化提示词之前相对方位类题目答对 1 题加入之后答对 3 题这时可以认为提示词修正有效。如果相对方位正确率明显提高但视角转换类新出现了错误说明模板里对观察者朝向的定义还不够清晰需要继续迭代。7.3 失败时的第一步排查如果修正后效果没有提升第一件事不是继续改提示词而是检查你调用的模型是否真的执行了新提示词。很多 LLM 接口在配置了 system prompt 时用户消息中的指令优先级可能不同。你要确认模型输出是否完整走了六步结构还是仍然只输出一个结论。如果模型无视模板直接回答了说明提示词模板没有有效覆盖到模型行为。第二个排查点是工具分支的坐标抽取是否准确。如果抽取出来的 origin 和 target 坐标本身就是错的后面的relative_direction再正确也没有意义。建议先把抽取结果打印出来人工核对。8. 常见问题与排查思路问题现象可能原因排查方式解决方案简单左右题答对题目一长就答错推理步骤丢失模型跳步让模型输出完整分步推理使用结构化模板强制输出六步模型把“左边”理解成页面左边没有定义观察者视角检查提示词是否包含观察者朝向声明在模板中固定“以观察者视角为准”坐标类题目总是算错LLM 不适合做精确算术和几何计算对比代码计算结果与模型输出改用外部relative_direction函数计算加了结构化提示词后仍不生效系统提示词与用户提示词冲突查看模型实际收到的完整请求体将模板写入系统提示词或将完整拼接后的文本发给模型工具分支返回 None走了提示词分支JSON 抽取或解析失败打印模型返回的坐标抽取结果增加 JSON 解析容错失败时要求模型重试多模态模型看图片仍答错图片中物体位置信息编码丢失让模型先说清楚图中物体的坐标再推理要求模型先生成位置描述再进行方位判断模型答对了但用户觉得表述不自然工具结果格式化生硬检查回复模板将工具结果组织成自然语言再返回表格里的每一条都来自实际项目中最常见的踩坑点。尤其是第一条和第二条几乎在每一次空间推理修正中都会遇到。9. 最佳实践与工程建议9.1 先建测试集再谈修正这是最重要的一条。没有测试集你对“空间推理差”的感知是模糊的有了测试集你可以精确知道差在哪类题目、哪个方向。测试集会成为你后续所有迭代的基准线。9.2 区分“理解问题”和“计算问题”如果模型把题目理解错了比如分不清谁是参照物那是理解问题应该优化提示词。如果模型理解正确但算错了方向那就是计算问题应该交给工具函数。两者混为一谈会让修正过程非常痛苦。9.3 能算的不要猜空间关系中的坐标计算、方向换算、路径积分都是确定性操作。这类操作不需要模型发挥“创造力”直接用代码计算是最可靠的。9.4 坐标系声明是提示词的核心很多修正失败的案例根源不是模型能力不够而是提示词没有定义坐标系。你在提示词里把坐标系、观察者朝向、方向约定都写清楚模型的错误率会显著下降。9.5 保留回归测试集空间推理的修正常常是“按下葫芦浮起瓢”。修复了左右混淆可能暴露了视角选择问题。保留一套与训练无关的回归测试集每次修改后都跑一遍才能防止旧问题复发。9.6 生产环境要做降级策略即使做了工具辅助和提示词优化模型仍然可能犯错。在面向用户的生产系统里建议对空间推理类的关键指令设置确认环节例如“你确定是想打开客厅左边那盏灯吗”这比让模型直接执行要安全得多。10. 总结与后续学习方向修正 LLM 的空间推理能力不存在一个万能技巧。更靠谱的路径是把它当作一个系统工程先用测试集定位失败类型再用结构化提示词解决语义层面的歧义用工具函数解决数学计算层面的误差最后通过回归测试验证效果。从行业趋势看空间推理问题正在从“单纯考验模型参数规模”演变成“考验系统架构设计”。那些把空间计算从语言模型中剥离出来的项目往往比单纯换更大模型更早获得稳定效果。如果这篇文章对你有帮助建议直接收藏备用。下一步你可以把自己业务中真实的空间问题整理成测试集先测一轮。在现有 Agent 框架中接入一个方向计算工具函数替代模型猜答案。如果团队有条件再尝试构造带坐标系标注的微调数据探索路线五。空间推理的战场很小但它是检验“LLM 能否真正理解物理世界”的一个关键路口。希望这篇文章能帮你少走一段弯路。