如何纠正LLM的空间推理能力？从提示词到微调的实践路径

LLM 的空间推理能力一直是个很尴尬的短板。你问它“A 在 B 的左边C 在 B 的上面C 相对 A 在哪个方向”它可能第一次答对换个说法再问就错。这个现象在社区里被讨论过很多轮Hacker News 上也有人在问如何纠正 LLM 的空间推理。这个话题值得认真拆一拆。空间推理不只是一道脑筋急转弯导航、机器人动作规划、UI 布局、三维场景理解、文档排版全都依赖它。如果你正在做 LLM 应用开发、Agent 编排或者只是想让模型回答更稳定这篇文章应该能帮上忙。先说结论纠正 LLM 的空间推理不是靠一个魔法提示词而是要先把“错在哪一类任务”定位清楚再决定用提示词、外部工具、微调还是数据增强。大多数场景下提示词层和工具层能解决大部分问题剩下少部分才需要动微调。1. 先定位空间推理差差在哪一类任务1.1 语言模型为什么天然不擅长空间推理很多人以为空间推理只是“笨”其实更准确的说法是语言模型根本没有一个稳定的空间坐标系。它读进来的文字被切分成 tokentoken 之间只有语义关联没有物理上的几何关系。模型知道“左边”这个词的用法但不知道“左边”在坐标里到底对应 x 轴减小还是 y 轴翻转。这不是模型态度问题而是表示方式的问题。你让模型回答“从起点向北走 100 米再向东走 50 米现在在哪”它可以在文本层面复述方向但每一步都靠概率推理误差会累积。第一次转弯还能对上多转几次就乱了。还有一个常见误区BERT、GPT 这类模型的位置编码只表示 token 在句子里的先后顺序不代表物体在场景里的物理位置。所以模型擅长从训练文本里“背出”常见空间关系比如“桌子上面有杯子”但不擅长处理一套全新的、需要在线维护坐标的场景。1.2 用三类任务快速定位问题要纠正空间推理第一步不是换模型而是先判断你的业务到底落在哪一类任务上。常见的空间推理可以粗分成三种关系判断型A 在 B 的左边、C 在 A 的后面问 C 和 B 的关系。这类任务主要靠语言内部的逻辑推导。路径规划型从起点经过若干转向到达终点问最终位置、朝向或最短路径。这类任务需要维护一个连续更新的状态。视觉空间型给一张图判断物体之间的相对位置、遮挡关系或空间布局。这类任务纯文本模型几乎无法完成必须接视觉模型。三种任务的纠偏手段完全不同。关系判断型靠提示词和结构化推理就能改善路径规划型最好让模型写代码维护坐标视觉空间型则要接图像输入或视觉语言模型不能硬让文本模型猜。我建议你先拿业务里最典型的 10 个问题做一次分类看命中哪一类。分类清楚之后再往下走效率会高很多。2. 不要急着调模型先做一次可量化的诊断2.1 搭一个不超过 30 条的测试集很多团队一上来就调提示词调半天也不知道有没有变好因为缺乏一个固定的测试集。纠正空间推理的第一步是先建一个能对比的基线。测试集不需要大20 到 30 条就够。重点是覆盖上面提到的类型并且每条都准备好标准答案。比如“书架上有三层。红书在蓝书上面蓝书在绿书上面。哪本书在最下面”“你面向南方向左转 90 度现在面向哪里”“机器人从 (0,0) 出发先向右移动 3 格再向上移动 2 格最终坐标是多少”每条都要写成独立条目不要混在一起。测试集建好后先跑一遍当前模型把答案保存下来。这一步的目的是拿到“改进前的基线”没有基线后面所有改动都无法判断是否真的有效。2.2 记录错误类型而不是只记准确率只看准确率会掩盖真正的问题。假设模型从 60% 涨到 70%你依然不知道它错在哪里。更好的做法是把错误分类左右方向搞反常见于模型对镜像关系的理解不稳。中间状态丢失多步推理时第一步对第二步开始乱。坐标符号错误把“左移”当成“右移”或者忽略了负号。输出格式不对模型知道答案但表述含糊判断时没法自动比对。记录完错误类型你会发现很多模型的错误集中在“状态维护”而不是“语义理解”。这时候纠偏方向就清楚了想办法让模型把每一步状态显式写出来而不是在心中默默推导。我在实测中遇到过一种典型情况让模型做 5 步路径追踪它每一步都说对了方向但最后一步把“左转”和“右转”搞反。单独看每一步没问题连起来看结果错。这类问题靠增加提示词约束往往比换模型更有效。3. 提示词层纠偏把隐式空间变成显式状态3.1 强制坐标系让模型先画一张空间状态表空间推理最怕模型“凭感觉答”。一个简单有效的做法是强制它先把场景转换成显式的空间状态表。比如请先列出所有物体的相对位置关系用表格表示 物体 | 基准物体 | 方向 | 距离如果有表格一出来模型就不得不把“红书在蓝书上面”这种句子转成结构化记录。转换的过程本身就是推理的一部分。后续判断直接基于表格而不是回看原文。这个思路的原理不复杂语言模型在做多步推理时每一步都在生成下一个 token中间没有可靠的“记忆仓库”。表格相当于一个外部记忆让模型可以反复读取而不是靠注意力机制去原文里找。3.2 分步追踪当前位置、朝向、左右关系分开算路径规划类任务里最容易错的是“左右”的定义。因为“左”和“右”依赖朝向朝向一变左右就跟着变。很多模型会把相对方向和绝对方向混在一起。纠正方法是让模型分三个字段维护状态当前位置坐标用 (x, y) 表示。当前朝向用东、南、西、北表示。相对方向映射表面朝北时左是西右是东面朝东时左是北右是南。每一步先更新朝向再更新坐标。不要把两个步骤合并成一句话。实测下来这种“先算朝向再算坐标”的强制顺序能明显降低路径规划的错误率。这里有一个容易忽略的点不要让模型只在最后输出一个答案。要求它把每一步的中间状态都写出来比如“第 2 步后位置 (1,2)朝向 东”。中间状态既是给模型自己的推理依据也是你排查问题的日志。3.3 让模型写代码算坐标而不是直接猜当任务真的涉及数值计算时最稳的做法是让模型生成代码。模型负责把自然语言转换成坐标运算真正的加减法交给代码执行器。提示词可以这样约束请把以下路径规划任务转换成 Python 代码用元组表示坐标用字符串表示朝向。 只输出代码不要输出解释。模型输出代码后你在沙箱环境里执行拿到数值结果。这样做的优势很明显每一步的坐标变化都由确定的运算完成天然不会出现“方向对但数字错”的问题。代价是引入了一个代码执行环境。对大多数应用来说这个代价可以接受。代码执行要做沙箱隔离、超时控制、结果校验这些在 LLM 应用开发里已经是常规操作。如果你已经在用 Agent 框架把“空间推理”封装成一个工具调用会比反复调提示词稳定得多。4. 工具和接口层改进不会算的地方交给外部系统4.1 接视觉模型处理图片类空间问题如果你的业务涉及图片比如“判断桌面上哪个物体离摄像头最近”纯文本 LLM 无论如何优化提示词都不可靠。这类问题应该交给视觉语言模型处理或者用目标检测加坐标计算的方式完成。常见做法是先用目标检测模型拿到物体 bounding box再根据边界框的位置关系计算“左上、右下、居中”等空间判断。这个流程比让 LLM 直接看图片更可控因为 bounding box 是确定的数值。如果你的系统已经接了多模态模型也可以把图片交给它但要专门抽查结果。多模态模型对“左侧”和“右侧”的判断偶尔会受布局干扰最好在关键场景加上后置校验。4.2 通过 API 网关做空间能力的后置校验在真实系统里你不一定每次都能改模型更多时候是在 API 层做增强。一个可行的思路是在 LLM 返回结果后增加一个空间逻辑校验模块。校验器可以做两件事一致性检查如果输入里有明确的坐标或方位描述校验结果是否和输入矛盾。规则检查比如“从 (0,0) 出发向右 3 格”结果必须是 (3,0)x 坐标必须有增量。校验不通过时可以让模型重新生成或者直接回退到规则计算。这种“先让模型答再让规则兜底”的做法在工程上很常见也符合 LLM 应用开发的稳定性要求。我遇到过不少案例业务方以为模型推理错了实际是校验环节没做。加了简单的坐标一致性校验之后正确率立刻上去一大截。这不是模型进步了而是错误被拦截了。4.3 编排框架里怎么放空间纠偏模块现在很多 LLM 应用会用到编排框架比如基于 MCP、RAG、Agent 的组合架构。在这种架构里空间推理不应散落在各个 Prompt 里而应该独立成一个能力模块。你可以把空间推理封装成一个服务或工具节点输入是自然语言的空间描述输出是标准化的空间状态或坐标结果。主流程只负责调用它不负责推理。这样有几个好处可以在不改主流程的情况下单独优化空间模块。可以给空间模块单独做测试集和回归。后续如果换了更好的模型或算法只需要替换这个节点。编排框架真正的价值不是把模型串起来而是把不稳定能力拆开、隔离、降级。空间推理正好适合这种处理方式。5. 微调路线数据、精度、损耗与评估5.1 合成空间推理数据从随机场景生成问答如果提示词和工具都用了模型还是达不到要求才需要考虑微调。微调的关键不是模型结构而是数据。空间推理数据很适合同步生成。你可以写一个脚本随机生成物体、位置、方向、路径再根据规则生成对应的问答对和标准答案。比如随机生成 3 到 5 个物体及其坐标。随机生成物体之间的相对关系描述。根据描述生成问题。用坐标反推正确答案。合成数据的优势是答案一定正确而且可以控制难度。你可以生成单步关系题也可以生成多步路径题。难度递增的数据对提升模型推理能力更有帮助。但要注意合成数据的风格和真实业务可能有差异。微调之后一定要拿真实样本做验证不能只看合成测试集的分数。5.2 微调时的精度选择fp16、bf16、fp32 不是玄学微调空间推理模型时一个经常被忽略的问题是数值精度。很多人在网上看到“推荐 fp16”就直接用结果训练不稳定loss 乱跳最后效果还不如原模型。这里要区分处理fp16训练速度快显存占用低但数值范围小容易出现梯度溢出。小模型或小数据量时可以用但要注意梯度裁剪。bf16数值范围和 fp32 接近训练更稳定对新手更友好。如果你的硬件支持 bf16优先考虑。fp32最稳但显存和内存开销大。数据量不大、模型规模不大时可以直接用。这个选择跟你用的框架、硬件、模型大小强相关没有统一答案。我的建议是第一次微调先用 bf16 或 fp32 跑通确认 loss 稳定之后再考虑用 fp16 提速。千万不要一上来就把所有参数拉满然后发现 loss 一直是 NaN。5.3 怎么判断微调真的有用微调完成后不要只看测试集准确率。要把微调前的错误类型和微调后的错误类型对比一下。如果只是准确率微涨错误类型没变化说明模型只是在背题如果路径规划的错误明显减少、左右反向错误消失才是真正的能力提升。还要做一致性测试同一道题换个说法再问一遍看答案是否稳定。空间推理天然存在表述多样性模型如果换个说法就答错说明它依赖表面句式并没有建立稳定的空间状态表示。最后别忘了做灾难性遗忘测试。空间推理变好了但常识问答、代码生成、文本总结有没有变差微调最怕按下葫芦浮起瓢。保留一组业务无关的通用测试集微调前后各跑一遍。6. 实战排查顺序和适用边界6.1 出现无输出或明显错乱时先查环境再查模型空间推理任务里你会遇到两类问题一类是答错一类是答不出来或报错。答错走推理优化答不出来或报错先按下面的顺序排查。先看输入格式。空间描述里有没有歧义词比如“左边”是相对谁说的有没有多义坐标。再看温度和生成参数。空间推理适合偏低的 temperature0 到 0.3 比较好太高的温度会让答案随机性过大。接着看输出解析。很多空间推理答案被包在解释性文字里后端解析时漏掉关键数字。最后才看模型本身。我的经验是报错问题里有一大半是路径、权限、依赖版本、输出解析的问题真正要换模型的没几个。6.2 空间推理改进的边界要提前知道提示词、工具、微调能改善空间推理但做不到万能。以下情况要降低预期任务本身需要真实三维感知只看文字描述永远不够。输入描述自相矛盾模型只能猜。需要实时动态更新的空间信息比如机器人运动过程中的连续坐标单纯靠 LLM 推理不稳定必须接传感器数据。遇到这些情况最合理的方案是把空间计算交给专门的几何引擎、物理引擎或视觉系统LLM 只做语义转换和任务拆解。空间推理的边界是文本能表达清楚的可以优化文本表达不了的别硬让模型算。6.3 一条可复用的空间推理改进工作流把前面的内容收拢成一条工作流可以直接拿去落地收集 20 到 30 条业务相关的空间推理问题分好任务类型。跑一遍当前模型记录准确率和错误类型作为基线。先在提示词层加空间状态表和分步追踪重新测试。如果任务涉及数值计算改用代码执行测试稳定性和耗时。如果任务涉及图片接视觉模型或目标检测不要硬靠文本模型。如果提示词和工具都解决不了再准备合成数据做微调。微调后对比错误类型、一致性和通用能力确认没有灾难性遗忘。上线后加后置校验模块错误答案能被拦截或触发重试。这套流程不限定具体模型和框架适合绝大多数 LLM 应用场景。每次改动只动一个变量看测试集变化再去下一个环节。我在实际项目里最大的体会是空间推理不是单点问题而是一条链路问题。输入描述、推理方式、计算工具、输出校验每一环都可能造成偏差。只盯着模型层改往往解决不了最终效果。先把链路打通再按测试集一步步优化才是稳定可行的路径。