之前在做一个基于大模型的室内导航问答助手时我遇到了一个很典型的“翻车现场”用户问“从会议室出发先向左转再直行 10 米到达的是哪个房间”模型一本正经地回答了 A 房间但实际地图上那个方向是 B 房间。更麻烦的是反复调整提示词后模型偶尔能答对偶尔又答错结果完全不可控。后来我意识到这已经不是“提示词写得不够好”的问题而是大语言模型在空间推理上的系统性短板。本文就从“为什么大模型学不会空间关系”讲起再给出我实际使用的评测方法、提示词修正策略、外部工具补偿方案以及一套完整的 Python 修正 Pipeline。无论你是做 RAG 问答、Agent 开发、机器人控制还是只是对 LLM 能力边界感兴趣这篇文章都能给你一套可以直接落地的思路。1. 什么是空间推理为什么 LLM 做不好1.1 空间推理的通俗解释空间推理简单说就是让模型理解“物体在哪里、朝向哪里、彼此之间是什么位置关系”并能根据这些关系推出新的结论。举几个具体的任务类型方位判断A 在 B 的左边B 在 C 的左边那么 A 在 C 的哪边距离估算从点 1 出发向东走 5 米再向北走 3 米离起点直线距离是多少旋转与镜像一个箭头朝右旋转 90 度后朝向哪里镜子里看到的左右和实际左右为什么相反网格导航在一个 5x5 网格中从 (1,1) 走到 (4,3)最短路径有几条三维空间一个正方体放在桌面上从上方俯视和从侧面看分别能看到几个面这些任务对人类来说非常自然因为人类有视觉系统、身体感知和长期的空间经验。但 LLM 没有这些它只能从文本的统计规律中去“猜”。1.2 LLM 空间推理的典型失败场景我在实际测试中总结了几个高频失败场景场景一左右方位颠倒问题小明面向北他的左手边是哪个方向 错误回答东边正确答案西边这是最经典的失败类型。模型经常把“面向北时的左手”和“面向地图时的左手”搞混本质原因是它没有稳定的“视角锚点”。场景二多跳空间关系推不动问题A 在 B 的右边B 在 C 的右边C 在 D 的右边那么 A 在 D 的哪边单跳关系模型还能应付一旦超过两跳错误率会急剧上升。因为每一步都需要在内部维护一个“空间状态”而 Transformer 的注意力机制并不擅长这种显式的状态累积。场景三坐标与自然语言互转出错让模型把“从原点出发先向右 3 格再向上 2 格”转成坐标模型经常把 X/Y 轴搞反或者把“向右”误认为是 X 轴负方向。场景四网格类计数问题不稳定在一个网格中数“从左上角到右下角有多少条最短路径”模型有时能随口背出组合数公式但一旦网格尺寸变大或加入障碍物它就开始胡编。1.3 本质原因分析为什么 LLM 空间推理这么弱我总结了四个层面的原因理解这些对后续修正非常重要。原因一训练数据以文本为主缺乏连续空间表征LLM 的输入是 token 序列不是连续坐标。它对“左边 3 米”和“左边 5 米”的感知本质上只是两个 token 序列没有像人类视觉皮层那样的空间编码。模型学到的是语言统计规律而不是几何规律。原因二语言本身存在视角歧义“左边”到底是以说话人视角为准还是以地图北方为准不同语境下含义完全不同。训练语料中的这类歧义会被模型以“平均化”的方式吸收导致它在具体任务上表现不稳定。原因三多步空间变换需要显式状态维护空间推理天然是“状态依赖”的每一步的结果是下一步的输入。而 Transformer 的自回归机制在长上下文中的状态保持能力有限一旦中间某一步出错后续步骤会全部跑偏。原因四模型倾向于“记住答案”而不是“计算答案”训练数据里包含大量类似题目的标准答案模型学会了“背答案”而不是“算答案”。换一个数据分布之外的布局错误率就会暴露出来。搞清楚了这些原因我们才能对症下药要么在提示词层面帮模型“补上状态”要么用外部工具替代模型做确定性计算。2. 先建立评测基准没有度量就没有修正很多同学一上来就急着调提示词这其实是本末倒置。你应该先建一个空间推理评测集把模型的“基准水平”测出来再谈修正。否则你根本无法判断修改到底有没有效果。2.1 评测任务设计空间推理评测集建议覆盖以下几类任务任务类型示例评分方式方位判断面向北时左手边是哪个方向答案精确匹配多跳关系A 在 B 右边B 在 C 右边A 在 C 哪边答案精确匹配坐标转换“向右 3 格向上 2 格”对应哪个坐标坐标精确匹配网格导航网格中两点间最短路径长度数值误差距离计算向东 5 米向北 3 米直线距离数值误差每个任务建议准备 20 到 50 道题题目难度要覆盖“单步”和“多步”两种。初期先不用追求数量关键是让评测集能够稳定复现。2.2 自动化评测脚本下面是一个简单的评测脚本模板它会批量发送问题、解析模型输出、按规则打分。这里以 OpenAI 兼容 API 为例你换成其他模型只需要改请求部分。# 文件路径eval_spatial.py import json import re from openai import OpenAI client OpenAI( api_keyYOUR_API_KEY, base_urlYOUR_API_BASE # 自建网关或代理时使用 ) TASKS [ { question: 小明面向北他的左手边是哪个方向, answer: 西, type: direction }, { question: A 在 B 的右边B 在 C 的右边那么 A 在 C 的哪边, answer: 右边, type: direction }, { question: 从原点出发先向右 3 格再向上 2 格最终坐标是什么, answer: (3, 2), type: coordinate }, { question: 在一个 6x6 网格中从左上角到右下角移动每次只能向右或向下最短路径长度为多少, answer: 10, type: number } ] def ask_llm(prompt: str, temperature: float 0.0) - str: resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperaturetemperature ) return resp.choices[0].message.content.strip() def normalize(text: str) - str: # 去掉空格、全半角括号差异便于精确匹配 text text.replace( , ).replace(, ().replace(, )) return text def evaluate(tasks: list, prompt_builder) - dict: results [] correct 0 for task in tasks: prompt prompt_builder(task[question]) raw ask_llm(prompt) ok normalize(raw) normalize(task[answer]) if ok: correct 1 results.append({ question: task[question], expected: task[answer], actual: raw, correct: ok }) return { total: len(tasks), correct: correct, accuracy: correct / len(tasks), details: results } def default_prompt_builder(question: str) - str: return f请回答下面的空间推理问题只输出答案不要解释\n{question} if __name__ __main__: result evaluate(TASKS, default_prompt_builder) print(f准确率: {result[accuracy]:.2%}) for item in result[details]: print(f[{✓ if item[correct] else ✗}] {item[question]} {item[actual]})运行后你会得到一个基准准确率。通常这个数字不会太高尤其是多跳方位类问题。保存这个脚本和结果后面每调整一次提示词或策略都跑一遍同一份评测集用准确率变化来判断是否有效。3. 提示词层面的修正策略评测有了基线之后先从最廉价的手段开始提示词工程。注意提示词不能完全解决空间推理问题但它能把模型已有的能力充分“激活”并且为后续工具化修正打基础。3.1 结构化分解法空间推理最大的敌人是“一步到位”。让模型把复杂问题拆成显式步骤每个步骤只做一次空间变换能显著降低错误率。下面是我常用的提示词模板你是一个空间推理助手。对于用户的问题你必须按以下步骤处理 第一步提取所有实体及其初始位置/朝向。 第二步以表格形式列出每一步空间变换。 第三步逐行执行变换记录中间状态。 第四步根据最终状态回答问题。 要求 - 坐标系使用平面直角坐标系向右为 X 轴正方向向上为 Y 轴正方向。 - “左边/右边”以当前面对方向为基准判断。 - 每一步必须写出中间坐标。 - 最后一行以“答案”开头给出结论。对比测试效果非常明显。用这个模板问“A 在 B 的右边B 在 C 的右边那么 A 在 C 的哪边”模型会先列出 B 在原点A 在 (1,0)C 在 (-1,0)然后正确推出 A 在 C 的右边。3.2 坐标显式化自然语言里的“左右前后”歧义太大而坐标是唯一确定的信息。一种有效的策略是先让模型把自然语言转换成坐标再做计算。以网格导航为例请把下面的导航指令转换成一系列坐标变换不要直接回答结果。 指令从 (0,0) 出发向右 3 格向上 2 格向左 1 格。 输出格式 起点(0,0) 第1步向右3格 - (3,0) 第2步向上2格 - (3,2) 第3步向左1格 - (2,2) 最终坐标(2,2)先转坐标再计算的思路本质上是把“语言理解”和“空间计算”两个阶段解耦。语言理解负责把指令翻译成确定性的坐标操作空间计算则由模型按规则逐行执行。比起直接让模型给出最终答案这个解耦过程能大幅降低错误率。3.3 思维链与自校验思维链Chain-of-Thought已经是常识但空间推理场景下有几个特殊技巧技巧一强制输出中间状态。不要只说“请一步步思考”要明确要求“每一步都写出当前坐标或方位”。技巧二让模型自己校验。在模型给出答案后追加一轮校验提示请检查你刚才的推理过程。重新执行一遍所有步骤确认每一步的坐标变换是否正确。 如果发现不一致请指出哪一步错了并给出修正后的答案。这个“二次校验”在空间推理上效果不错因为模型在检查阶段往往会发现自己第一次推理中的轴方向错误。代价是 API 调用量翻倍所以可以只在评测集或高价值请求上启用。技巧三内置几个 few-shot 示例。每个示例都要包含“问题、推理步骤、最终答案”三部分特别是要包含一个容易出错的旋转问题示例。这样模型能照猫画虎地输出规范格式。4. 用外部工具补偿空间能力提示词修正解决的是“模型能力发挥”问题但模型本身的计算能力边界仍然存在。对于需要精确计算的空间任务最可靠的方式是让 LLM 只做“理解”把“计算”交给确定性代码。4.1 代码执行校验思路非常简单让 LLM 把自然语言指令转换成可执行的 Python 代码或 JSON 配置然后在沙箱环境中执行代码得到确定结果。由于执行结果是精确的可以反过来修正 LLM 的答案。下面是一个最小示例# 文件路径spatial_tool.py # 目标把自然语言导航指令转换为坐标变换 import ast import json def parse_navigation(prompt: str) - list: 调用 LLM 把导航指令解析成结构化操作。 这里用简单规则模拟实际项目中调用 LLM 接口。 operations [ {action: move, direction: right, distance: 3}, {action: move, direction: up, distance: 2}, {action: move, direction: left, distance: 1} ] return operations def apply_operations(ops: list, start(0, 0)) - tuple: 确定性执行坐标变换不依赖 LLM结果精确。 x, y start direction_map { right: (1, 0), left: (-1, 0), up: (0, 1), down: (0, -1) } for op in ops: dx, dy direction_map[op[direction]] x dx * op[distance] y dy * op[distance] return (x, y) if __name__ __main__: user_prompt 从 (0,0) 出发向右 3 格向上 2 格向左 1 格 ops parse_navigation(user_prompt) final apply_operations(ops) print(f最终坐标: {final})在这个方案里LLM 负责“理解语义并结构化”代码负责“精确计算”。因为计算的每一步都是确定性规则误差为零。这个模式可以扩展到距离计算、矩形面积、路径规划等所有能用几何公式表达的题型。4.2 可视化辅助另一个非常实用的补偿手段是让模型或 Agent 调用绘图工具把空间关系渲染成图片后再做判断。这一点对有视觉能力的多模态模型尤其有效。例如对于“三张桌子 A、B、C 的摆放位置”这类问题可以调用 matplotlib 画出平面图然后把图片交给多模态模型做视觉判断# 文件路径draw_scene.py import matplotlib.pyplot as plt def draw_scene(points: dict, filenamescene.png): fig, ax plt.subplots() for name, (x, y) in points.items(): ax.plot(x, y, o) ax.text(x 0.1, y 0.1, name) ax.set_xlim(-1, 5) ax.set_ylim(-1, 5) ax.set_aspect(equal) ax.grid(True) plt.savefig(filename) plt.close() if __name__ __main__: scene { A: (1, 1), B: (3, 1), C: (3, 3) } draw_scene(scene) print(场景图已生成: scene.png)这里要说明一下适用范围视觉化辅助适合“模型能生成正确布局但判断关系时错误”的情况。如果 LLM 连布局的坐标都生成错了那么可视化反而会把错误固化成图片。此时应该先用代码校验坐标正确性再考虑可视化。4.3 与专业空间模型结合在实际工程中还有一种方式是把 LLM 与专门的“视觉定位/空间理解”模型结合。比如多模态大模型对图像中的物体位置有更强的感知能力可以用它来替代纯文本 LLM 完成“这张图里茶杯在键盘的哪边”这类需要视觉输入的空间判断。这种方案的架构通常是LLM 负责理解用户意图判断是否需要视觉信息。视觉模型负责从图像中提取物体边界框和坐标。LLM 基于视觉模型的输出结合用户语言指令做最终判断。需要提醒的是这种方案对部署成本和推理时延要求较高适合空间信息必须来自真实图像的业务场景。如果只是纯文本逻辑题优先用代码执行方案就足够了。5. 数据与微调方向如果提示词和工具方案都试过模型在某个特定空间任务上仍然不达标而且你有充足的训练预算那么下一步可以考虑数据增强与微调。5.1 合成空间数据空间推理数据的最大优势是可以程序化生成不需要人工标注。只要定义好规则就能批量产出“问题-推理过程-答案”三元组。一个简单的合成数据生成器思路# 文件路径generate_spatial_data.py import random import json def generate_direction_question(): # 生成“面向X方向左右手边”类题目 directions [北, 南, 东, 西] facing random.choice(directions) hand random.choice([左手边, 右手边]) answer calculate_answer(facing, hand) # 本题答案用确定性函数计算 question f小明面向{facing}他的{hand}是哪个方向 return {question: question, answer: answer} def calculate_answer(facing: str, hand: str) - str: order [北, 东, 南, 西] # 顺时针 idx order.index(facing) if hand 左手边: idx (idx - 1) % 4 else: idx (idx 1) % 4 return order[idx] if __name__ __main__: samples [] for _ in range(1000): samples.append(generate_direction_question()) with open(spatial_train.json, w, encodingutf-8) as f: json.dump(samples, f, ensure_asciiFalse, indent2) print(生成 1000 条空间推理训练样本: spatial_train.json)关键原则是答案必须由代码计算不能由 LLM 生成。如果用 LLM 生成训练数据的答案错误会被当成正确答案学进去这叫“自污染”。5.2 微调注意事项微调空间推理能力有几个坑需要避开问题格式要统一。训练数据里的提问方式和推理格式不一致模型学到的是格式不是推理。推理过程不能省。只给“问题-答案”对模型学不到空间变换过程效果很差。要显式包含中间坐标或方位。评测集要分离。训练数据和评测数据的生成规则要不同至少参数分布要不同否则模型“背题”会让你误以为真的提升了。小模型优先。如果你用的是 7B、13B 这类小模型先做评估确认任务确实无法通过提示词解决再投入微调资源。坦白说微调是成本最高、周期最长的方案。对于大多数应用场景我建议把它放在提示词和工具方案之后。6. 完整实战一个空间推理修正 Pipeline下面把这套思路整合成一个完整的可运行 Pipeline。它能处理“自然语言导航指令”类问题自动完成LLM 理解 - 代码计算 - 答案校验 - 输出修正后的最终答案。6.1 项目结构spatial_pipeline/ ├── config.py # 模型 API 配置 ├── llm_client.py # LLM 调用封装 ├── spatial_solver.py # 确定性空间计算器 ├── pipeline.py # 主流程理解-计算-校验 ├── eval.py # 评测脚本 └── data/ └── cases.json # 测试用例6.2 编写核心模块先看 LLM 调用封装# 文件路径llm_client.py from openai import OpenAI class LLMClient: def __init__(self, api_key: str, base_url: str None, model: str gpt-4o-mini): self.client OpenAI(api_keyapi_key, base_urlbase_url) self.model model def chat(self, prompt: str, temperature: float 0.0) - str: resp self.client.chat.completions.create( modelself.model, messages[{role: user, content: prompt}], temperaturetemperature ) return resp.choices[0].message.content.strip() def parse_navigation(self, instruction: str) - list: 让模型把自然语言指令解析成结构化操作。 输出要求是 JSON 数组。 prompt f 把下面的导航指令解析成 JSON 数组每个元素包含 action、direction、distance 三个字段。 只输出 JSON不要解释。 指令{instruction} 示例输出 [{{action: move, direction: right, distance: 3}}] raw self.chat(prompt) # 这里建议用 json 解析并做异常处理简化起见直接返回 import json # 清理可能的 Markdown 代码围栏 raw raw.strip().strip(json).strip().strip() return json.loads(raw)再看确定性计算器# 文件路径spatial_solver.py class SpatialSolver: 确定性空间计算器所有几何计算都在这里完成。 DIRECTION_VECTORS { right: (1, 0), left: (-1, 0), up: (0, 1), down: (0, -1) } def __init__(self, start(0, 0)): self.x, self.y start def move(self, direction: str, distance: int): if direction not in self.DIRECTION_VECTORS: raise ValueError(f未知方向: {direction}) dx, dy self.DIRECTION_VECTORS[direction] self.x dx * distance self.y dy * distance return (self.x, self.y) def reset(self, start(0, 0)): self.x, self.y start然后组装成主流程 Pipeline# 文件路径pipeline.py from llm_client import LLMClient from spatial_solver import SpatialSolver class SpatialPipeline: def __init__(self, llm: LLMClient): self.llm llm self.solver SpatialSolver() def solve_instruction(self, instruction: str) - dict: # 第一步LLM 理解并结构化为操作序列 ops self.llm.parse_navigation(instruction) # 第二步确定性代码执行空间变换 self.solver.reset() trace [] for op in ops: pos self.solver.move(op[direction], op[distance]) trace.append({op: op, position: pos}) # 第三步返回最终坐标和中间过程 return { result: trace[-1][position] if trace else (0, 0), trace: trace } if __name__ __main__: llm LLMClient(api_keyYOUR_API_KEY) pipeline SpatialPipeline(llm) instructions [ 从 (0,0) 出发向右 3 格向上 2 格向左 1 格, 从 (1,1) 出发向下 2 格向右 4 格 ] for ins in instructions: out pipeline.solve_instruction(ins) print(f指令: {ins}) print(f执行轨迹: {out[trace]}) print(f最终坐标: {out[result]}) print(- * 40)6.3 运行与验证运行 pipeline.py 后预期输出类似指令: 从 (0,0) 出发向右 3 格向上 2 格向左 1 格 执行轨迹: [{op: {action: move, direction: right, distance: 3}, position: (3, 0)}, {op: {action: move, direction: up, distance: 2}, position: (3, 2)}, {op: {action: move, direction: left, distance: 1}, position: (2, 2)}] 最终坐标: (2, 2)与纯 LLM 输出相比这个 Pipeline 的核心优势是无论模型理解是否正确最终的坐标计算永远精确。如果模型解析出错误的方向程序员只需要校验 JSON 结构而不需要担心计算错误。当然模型解析错误仍然会导致最终结果错误所以实际项目中还要在解析后加一层合法性校验比如方向字段是否在枚举范围内、距离是否为正数等。这就是“LLM 负责理解代码负责计算”的真正含义。7. 常见问题与排查思路在实践空间推理修正方案的过程中下面这些问题是出现频率最高的问题现象常见原因解决思路模型总是把左右搞反没有明确视角基准模型默认以地图方向判断在提示词中显式说明“左右以当前面向方向为基准”并给出坐标示例同样的问题多次回答不一致temperature 过高采样随机性大将 temperature 设为 0 或接近 0开启固定种子简单问题能答对多跳就出错模型缺少显式状态维护能力用结构化分解法强制分步输出或用代码执行代替模型计算工具计算结果和 LLM 答案不一致模型解析指令出错或模型直接“猜”答案校验 JSON 结构、方向枚举让 LLM 输出推理轨迹定位解析错误模型输出的 JSON 无法解析输出包含 Markdown 围栏或多余文字提示词约束“只输出 JSON”代码中做清洗和异常兜底微调后评测集提升但真实场景下降训练数据分布与真实场景分布不一致扩充合成数据的随机范围确保评测集与训练集生成规则不同请求量大导致 API 成本高每个空间问题都调用多次 LLM对固定题型用规则转换替代 LLM 解析缓存相同指令的结果排查时我习惯按照“先定位层级再定位原因”的思路先确认是解析层错误LLM 没有正确提取方向/距离还是计算层错误代码逻辑有问题还是表示层错误坐标方向定义与题目不一致。大部分问题都出在解析层和表示层代码计算本身很少出错这正是把它从 LLM 中剥离出来的价值。8. 最佳实践与工程建议8.1 定义坐标系统且只在提示词里定义一次空间推理最大的隐患是坐标系不统一。在提示词开头就固定“向右为 X 轴正方向向上为 Y 轴正方向”之后所有问题都沿用这个约定。不要让用户或下游系统自行揣测方向定义。8.2 能用代码算的就不要让模型算这是整篇文章最重要的工程原则。空间推理中的距离、坐标、路径长度本质上都是确定性计算。让 LLM 做这些事等于拿一个概率模型去做非概率计算。正确的做法是让 LLM 负责将自然语言转换为结构化指令把数值计算全部交给代码。这既能保证准确性也能降低推理成本。8.3 先建评测集再谈优化任何“修正”都必须有可量化的验证。建议把空间推理评测集接入 CI/CD 流程每次修改提示词模板或模型版本后自动运行以准确率阈值作为回归把关。没有评测的调优都是盲目的。8.4 对模型输出做严格校验在集成工具方案时LLM 输出的结构化数据必须校验方向字段是否在枚举值内。距离是否为有限正数。坐标是否在预期范围内。操作序列长度是否超过限制。校验失败的请求应该走兜底逻辑比如重新请求一次、转人工处理而不是直接使用未校验的 LLM 输出。8.5 区分安全关键场景如果空间推理结果用于物理世界控制机器人、自动驾驶、仓储调度切忌把 LLM 的答案直接作为执行指令。这类场景必须采用“LLM 理解 代码规划 传感器校验 人工兜底”的完整链路同时记录完整的推理与决策日志便于事故回溯。8.6 日志与可观测性建议为空间推理 Pipeline 增加结构化日志原始指令、解析后的结构化操作、代码计算结果、最终答案、耗时、模型版本。这样当出现线上问题你可以快速定位是模型理解、代码执行还是数据问题。9. 总结与下一步回到文章开头的问题如何修正 LLM 的空间推理能力我的结论是空间推理不像知识问答不能指望靠“多问几次”或“换个大模型”彻底解决。它是一个需要系统工程化处理的问题先用评测集度量能力基线再用提示词工程激活模型已有能力接着用代码执行或外部工具替代确定性计算最后在必要时用合成数据微调特定能力。四条路径的成本和深度依次递增你可以根据业务需求选择组合。对于初学者我的建议是先用本章的评测脚本跑一遍你正在用的模型记录它的空间推理基线然后从结构化分解提示词开始看准确率提升了多少如果还不够再接入代码执行方案。这套方法不仅适用于空间推理也适用于所有“LLM 需要精确计算”的场景比如数学计算、日期计算、单位换算等。空间推理是 LLM 迈向实体世界应用时绕不开的一道坎。本文给出的思路与代码希望能帮你少走一些弯路。如果你在实际项目中摸索出了更好的方法也欢迎在评论区交流我们一起把这条路的经验补全。