最近在 Hacker News 上有一个讨论度很高的问题How do you correct spatial reasoning of LLMs?中文翻译过来就是“你怎么纠正大语言模型的空间推理能力”。如果你让 GPT、Claude 或者本地部署的 Llama、Qwen 回答“从教室门口走到讲台先向左还是先向右”“A 在 B 的东北方向C 在 B 的西南方向A 相对于 C 在哪个方向”你会发现它们经常给出看似合理、实际方向完全相反的回答。这个问题不是个别模型的毛病而是整个 LLM 体系的结构性短板。本文会把这个问题拆开讲清楚为什么 LLM 空间推理弱、怎么设计和批量跑评测任务、用哪些修复手段最有效、如何把空间推理能力封装成 API 服务以及从工程角度如何验证每一步是否真的有效。如果你平时在做 LLM Agent、RAG、ComfyUI 工作流、CAD 工具集成、GIS 数据解析或者只是想让模型能正确回答“桌面上从左到右有三个杯子最右边的是哪个”这篇文章可以直接收藏。1. 空间推理问题拆解LLM 到底错在哪里先把“空间推理能力差”这个模糊说法拆成可测试、可修复的具体问题。LLM 的空间推理缺陷不是单一原因造成的通常表现为以下几类。问题类型典型表现可能根因可行修复方向左右与镜像混淆“站在对面的人举起右手对应我的哪只手”回答错误自回归模型缺少具身视角切换模块提示词显式声明坐标系与观察者位置方位与方向推理错误无法正确计算“A 在 B 的东北B 在 C 的南边A 在 C 的什么方向”中间推理步骤不可解释、符号计算能力弱强制输出推理步骤让模型扮演“坐标计算器”相对位置描述解析失败无法把“放在桌子左上角的红色方块”转成坐标训练数据中坐标标注样本少用代码解释器或外部工具把文本解析为坐标空间关系链多跳错误“我的左边第二个人的右边第三个人是谁”回答混乱关系链长度过长注意力分散拆分为多步局部操作每一跳单独验证尺寸、距离、比例估计错误“这块区域大概多少平方米”估算偏差大缺乏真实物理尺度先验接入地图/测量 API 或结构化数据源语言歧义影响空间判断“在门后面”和“在门后面躲着”两种空间语序理解错误自然语言与空间语义映射不充分RAG 检索典型空间表达语料补充提示一个关键结论是LLM 在空间推理上的错误往往不是单一逻辑错误而是“文本形式的空间表达”和“可计算的几何关系”之间的转换失败。模型擅长生成语言但不擅长把语言中的空间语义稳定映射到坐标系。这个判断决定了后面的修复策略不能只靠某一个技巧而是要多层配合。2. LLM 空间推理能力为什么难提升在动手修复之前需要先理解问题根源否则容易在提示词层面反复尝试却看不到效果。第一自回归生成机制本身不适合几何计算。LLM 的每一步输出都是基于前文预测下一个 token它没有“先画一个坐标系再计算坐标最后根据坐标生成描述”这样的结构化中间过程。对于空间推理模型被迫在文本空间内完成几何计算而 token 级别的计算误差会随推理步骤累积。第二空间信息在 Token 化过程中被切碎。像“左上角”“东北方向”“离门 3 米”这样的空间短语经过 tokenizer 后变成若干个独立的 token模型很难把相邻 token 重新绑定成一个稳定的空间实体。这会导致模型理解了“左上角”这个短语却没有理解它在整段描述中对应哪个对象。第三训练数据中高质量空间推理样本不足。模型大规模训练时更多接触到的是百科知识、代码、对话和文本生成任务而带有精确坐标、方向、空间关系标注的语料非常稀少。即使模型“看过”大量包含“东南”“西北”等词汇的文本它也只是学会了词汇共现并没有建立真实的几何语义。第四模型缺少“观察者视角”建模。人类说“左边”时有一个不言自明的前提相对于谁、面向哪个方向。LLM 经常默认了一个视角但用户问的可能是另一个视角。如果不把这个前提显式化模型的错误率会非常高。理解了这四点就明白修复策略应该包括显式化坐标系、让推理步骤可计算、为模型提供外部空间数据源以及通过模型评测持续定位哪一类错误还在发生。3. 如何正确评估 LLM 的空间推理能力不要凭一两个问题就判断模型空间推理“行”或“不行”。要做一次可复现的评测。3.1 设计最小评测集把空间推理拆成几类能力每一类至少准备 5 到 10 个测试用例左右判断站在不同朝向的人判断左右。方位计算已知两个相对方位求第三个方位。网格定位在 3x3 或 5x5 网格中根据指令定位对象。空间关系链连续执行“左边第二个、右边第三个”等多跳指令。尺寸与距离估计根据文本描述估计物品摆放距离或区域面积。每一道题都给出标准答案同时给出“宽松判断标准”——例如要求最终返回的方位词正确但允许推理过程多种多样。3.2 写一个批量评测脚本下面给出一套通用的批量评测模板不需要依赖具体模型 SDK只要模型提供 OpenAI 兼容接口或本地 HTTP 接口就能接入。# eval_spatial.py # 用法python eval_spatial.py --base_url http://127.0.0.1:8000/v1 --model qwen2.5-7b import argparse import json import requests def load_cases(path): with open(path, r, encodingutf-8) as f: return json.load(f) def ask_model(base_url, model, prompt, max_tokens512): payload { model: model, messages: [{role: user, content: prompt}], temperature: 0, max_tokens: max_tokens, } resp requests.post( f{base_url}/chat/completions, jsonpayload, timeout120 ) resp.raise_for_status() return resp.json()[choices][0][message][content] def judge(answer, expected): # 宽松判断正确答案中的关键词是否出现在模型输出中 for key in expected[keywords]: if key not in answer: return False return True def main(): parser argparse.ArgumentParser() parser.add_argument(--base_url, defaulthttp://127.0.0.1:8000/v1) parser.add_argument(--model, defaultqwen2.5-7b) parser.add_argument(--cases, defaultcases.json) args parser.parse_args() cases load_cases(args.cases) total 0 correct 0 for case in cases: answer ask_model(args.base_url, args.model, case[prompt]) ok judge(answer, case[expected]) total 1 correct 1 if ok else 0 print(f[{PASS if ok else FAIL}] {case[name]}) print(f prompt: {case[prompt]}) print(f answer: {answer}) print() print(fAccuracy: {correct}/{total} {correct / total:.1%}) if __name__ __main__: main()评测用例文件格式如下[ { name: simple_left_right, prompt: 你面向北方站着你的左手边是哪个方向, expected: {keywords: [西]} }, { name: relative_direction_multi_hop, prompt: A 在 B 的东北方向B 在 C 的南边。请问 A 相对于 C 在哪个方向, expected: {keywords: [东]} } ]用这个脚本跑一遍你就能得到一份量化结果。修复之前先记录 baseline修复之后重新跑同一组用例才能判断改动是否有效。这一步是整个空间推理修复工作的基础不能跳过。4. 环境准备与模型选型空间推理评测对硬件的要求取决于你选用什么模型。4.1 模型梯队如果只做提示词层面的尝试建议按以下梯队选模型API 模型GPT-4o、Claude 3.5 Sonnet、DeepSeek 等适合先确认“当前最强商用模型的空间推理上限在哪里”。本地 7B 到 14B 模型Qwen2.5-7B-Instruct、Llama-3.1-8B-Instruct可以在 8G 到 16G 显存的消费级显卡上运行适合批量测试和后续微调。更大本地模型32B 以上模型需要 24G 显存或量化加速适合对效果要求高且硬件条件允许的场景。4.2 精度选择对空间推理的影响LLM 推理时的精度问题会在空间推理这类需要精确计算的场景中暴露得更明显。fp16、fp32、bf16 是三种常见精度fp32数值精度最高显存占用最大推理速度偏慢。fp16显存占用减半但部分模型在低精度下可能出现数值稳定性问题。bf16指数范围和 fp32 一致显存占用和 fp16 相同是目前本地大模型推理中的常用选择。空间推理任务不是单纯的“取最大概率 token”它需要模型在长上下文中保持多个实体的相对关系。如果你的模型在 fp16 下方向判断错误率明显高于 fp32换 bf16 或直接开 fp32 试试可能比修改提示词更有效。这是很多人在排查空间推理问题时忽略的一个变量。4.3 部署方式推荐直接使用支持 OpenAI 兼容接口的推理服务例如 vLLM、Ollama、LM Studio、llama.cpp 等。以 Ollama 为例拉起服务后默认会监听 11434 端口vLLM 启动后默认监听 8000 端口。前面的评测脚本只需要改 base_url 就能接入。5. 从提示词开始的修复实验当评测集和模型都准备好之后开始实验。这里给出的提示词策略是从简单到复杂逐级递进建议每一步都跑一遍评测脚本记录准确率变化。5.1 显式声明观察者与坐标系最简单的修复方式是让模型在一个明确坐标系的约束下回答问题。请在一个虚拟坐标系中解决问题 - 你是一个面向北方的观察者。 - 东 (1, 0)西 (-1, 0)南 (0, -1)北 (0, 1)。 - 每一步都写出当前的坐标位置。 - 最终回答只输出方位词。 题目A 在 B 的东北方向B 在 C 的南边。请问 A 相对于 C 在哪个方向这种方式把模型从“语言联想模式”切换到“坐标计算模式”。对很多 7B 到 14B 模型这个改动通常能显著提高简单方位题的准确率。5.2 强制分步推理并让每一步结果可见空间关系链越长模型越容易在中间步骤出错。使用“分步推理 每步自检”的提示词结构回答问题时必须按以下步骤 1. 确定每个对象的初始坐标或方位。 2. 确定每一步的参考系以谁为原点面向哪个方向。 3. 逐步更新坐标。 4. 最后根据坐标给出答案。 5. 如果发现前后矛盾回到第 2 步重新计算。这种做法本质上是把隐蔽的单次错误变成可见的多步计算过程方便定位报错位置。5.3 让模型充当代码解释器如果模型支持函数调用或代码执行可以让模型输出一段 Python 代码来计算最终坐标而不是直接输出文字答案。例如# 示例伪代码实际使用时由模型生成并执行 def solve(): # B 为原点C 在 B 南边 B (0, 0) C (0, -1) # A 在 B 东北方向 A (1, 1) # A 相对于 C 的方向 dx A[0] - C[0] dy A[1] - C[1] print(fdelta({dx}, {dy})) # 根据 delta 判断方位这一步对修复效果非常重要LLM 直接回答几何问题时容易出错但让它生成计算代码时出错率会明显降低。因为代码执行结果是由解释器保证的而不是由模型“猜”出来的。5.4 风格模板的作用在跨领域场景里比如把桌面上物品的位置描述转成坐标或者把 CAD 图纸里的空间判断转换为文本建议把上面的策略组合成一个风格模板固定在系统提示词中[System] 你是一个空间推理助手。你的任务是将自然语言中的空间关系转成坐标并基于坐标回答问题。 规则 - 默认观察者面向北方除非题目另行说明。 - 使用标准方位东、南、西、北、东北、东南、西北、西南。 - 能分步计算时先写推理过程再给最终答案。 - 当计算复杂时输出可执行的 Python 代码片段而不是直接猜测。6. 用外部工具和知识库增强空间推理提示词能够解决一部分问题但要让空间推理能力在真实业务场景中稳定通常需要引入外部工具。6.1 工具调用让模型使用空间处理器与其让 LLM 自己“心算”坐标不如让模型学会调用一个确定性的空间计算函数或 API。例如def get_relative_direction(reference_point, target_point): # 输入坐标返回方位字符串 dx target_point[0] - reference_point[0] dy target_point[1] - reference_point[1] # 将 dx, dy 映射为 8 方位 ... return direction在 LLM Agent 架构中模型只需要负责解析用户的语言意图、提取对象坐标、调用这个函数最后把函数返回的方向结果转成自然语言。空间计算完全交给确定性代码模型不再参与几何推理。这类思路与目前热门的LLM Agent和MCP工具协议很契合。空间推理能力可以做成一个工具服务模型通过工具协议调用而不是强制模型在参数内部完成所有计算。6.2 RAG补充空间描述语料如果你的场景是特定领域的地图、园区、仓库或建筑空间模型可能缺少这些特定空间结构的先验知识。可以用 RAG 方案把空间描述文档、历史问答对、楼层平面图的文字描述存入向量库检索后拼入上下文。检索内容建议包括具体位置的坐标描述。特定空间对象之间的相对关系描述。不同历史问题中已经验证过的正确答案。典型歧义表达的正反例。RAG 不能解决所有空间推理问题但可以有效解决“模型不了解这个场的空间结构”这一类知识不足问题。6.3 CAD / GIS 工具集成的可行性如果你的场景涉及 CAD 图纸或 GIS 系统正确的做法不是让 LLM 直接“看懂”图纸而是让 LLM 调用 CAD/GIS 的查询接口把坐标、方向、距离等结构化数据取回来。在 ComfyUI 与 LLM 联动这类工作流中也可以用类似思路由 LLM 解析用户意图由确定性节点负责空间坐标转换最后再让 LLM 组织成自然语言结果。空间推理的稳定性由工具链保证LLM 只承担“意图理解”和“语言生成”这两部分。7. 接口 API 与批量任务实践空间推理能力做出来之后最终要服务于实际业务。这里给出一个最小可用的接口封装方案和批量任务调用模板。7.1 用 FastAPI 封装一个空间推理服务# spatial_api.py from fastapi import FastAPI from pydantic import BaseModel, Field from typing import Optional import uvicorn app FastAPI(titleSpatial Reasoning API) class SpatialRequest(BaseModel): question: str Field(..., description用户的空间推理问题) mode: str Field(reflection, descriptionreflection / tool / code) observation: Optional[str] Field(observer faces north, description观察者朝向) verbose: bool Field(False, description是否返回推理过程) class SpatialResponse(BaseModel): answer: str reasoning: Optional[str] None confidence: Optional[float] None app.post(/api/spatial_reasoning, response_modelSpatialResponse) def spatial_reasoning(req: SpatialRequest): # 这里实际调用评测脚本或外部工具函数 # 本示例返回占位结果实际项目需要替换为你的推理逻辑 return SpatialResponse( answer东北, reasoning分步计算得到目标点相对坐标为正 x 和正 y, confidence0.92 ) if __name__ __main__: uvicorn.run(app, host0.0.0.0, port8000)启动命令python spatial_api.py注意上面的占位逻辑只是为了演示接口结构实际部署时要把你实验出的最优提示词、工具调用或代码执行逻辑接入到spatial_reasoning函数内部。7.2 curl 调用示例curl -X POST http://127.0.0.1:8000/api/spatial_reasoning \ -H Content-Type: application/json \ -d { question: A 在 B 的东北方向B 在 C 的南边。请问 A 相对于 C 在哪个方向, mode: reflection, verbose: true }7.3 Python 批量任务调用模板import requests import json import time API_URL http://127.0.0.1:8000/api/spatial_reasoning def process_batch(questions, output_path, delay0.5): results [] for idx, question in enumerate(questions): try: resp requests.post(API_URL, json{question: question}, timeout60) resp.raise_for_status() result resp.json() result[question] question result[index] idx results.append(result) print(f[{idx 1}/{len(questions)}] {result[answer]}) except Exception as e: results.append({question: question, index: idx, error: str(e)}) print(f[{idx 1}/{len(questions)}] ERROR: {e}) time.sleep(delay) with open(output_path, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: questions [ 桌子左上角有一个苹果右下角有一个香蕉。苹果在香蕉的哪个方向, 你面向南站着你的右手边是哪个方向, ] process_batch(questions, spatial_batch_result.json)批量任务建议每次任务前记录输入文件路径、模型版本、提示词版本、日期。输出的 JSON 包含 question、answer、reasoning、error 字段方便统一分析。失败任务不要直接结束记录 error 后继续跑完整个批次。大批量任务建议加 0.5 秒到 2 秒的延迟避免触发服务端的限流或导致本地资源过载。8. 资源占用与性能观察空间推理任务本身不会比普通对话任务消耗更多显存但批量评测和 API 服务会同时运行多个请求资源占用需要重点观察。8.1 如何观察显存与内存Linux 下用nvidia-smi查看显存占用。如果服务运行在 Docker 中用docker stats查看容器内存。不要只看启动瞬间的显存要看推理过程中峰值占用。如果使用 vLLM 部署可以通过curl http://127.0.0.1:8000/metrics读取吞吐和延迟指标。8.2 CPU 与 GPU 的差异空间推理评测集通常只有几十到几百道题数据量不大。如果你的模型是 7B 以下用 CPU 跑也能得到结果但单题耗时可能是 GPU 的 5 到 10 倍。大模型的逐 token 生成过程在 CPU 上是串行计算的而 GPU 能并行处理。如果只是做几十题的提示词实验CPU 够用如果要跑几百题或作为接口服务对外提供必须用 GPU。8.3 精度与性能权衡使用 bf16 或 fp16 通常能获得更快的推理速度。如果发现空间推理在低精度下错误率明显上升优先尝试 fp32。如果显存不够先量化到 int8 或 int4但要意识到量化后模型的空间推理能力可能进一步下降。对空间推理这类精度敏感任务建议至少对比 bf16 和 fp32 两组准确率。8.4 降低资源占用的手段开启 vLLM 的 continuous batching提高批量吞吐。限制并发请求数避免显存溢出。如果不需要长输出把max_tokens调低。本地部署时关闭日志中的重复打印减少 IO 开销。9. 常见问题与排查方法问题现象可能原因排查方式解决方案同一道题多次回答结果不同采样温度过高检查请求参数 temperature将 temperature 设为 0 或 0.1提示词加入坐标描述后准确率反而下降模型对复杂坐标描述理解出现偏差对比不同提示词版本的前后准确率简化坐标描述只保留必要规则低精度下方向判断错误率升高fp16 数值稳定性问题切换不同精度重跑评测集尝试 bf16 或 fp32批量任务跑一半卡住请求超时或服务崩溃查看服务日志和请求重试状态添加超时重试和失败记录API 服务返回 500接口逻辑异常或模型服务不可用查看 FastAPI 日志检查模型服务是否在监听确认接口路径工具调用时模型生成错误的函数参数提示词没有给出函数签名示例检查模型输出 JSON 结构在提示词中补充函数签名与示例模型回答“无法确定”比例过高问题本身缺少空间参考系检查用户问题是否给出观察者朝向在提示词中显式补全缺失前提更换模型后准确率波动大不同模型空间推理能力差异大用同一评测集对比多个模型选择效果达标的模型避免频繁更换10. 最佳实践与使用建议综合前面的实验方法和工程经验这里给出一套可复用的空间推理修复工作流。10.1 先建立评测基线没有评测基线之前任何提示词优化都可能是主观感觉。建立一个 20 到 50 题的固定评测集涵盖左右、方位、网格定位、关系链和距离估计五个维度。每次修改提示词或更换模型后都跑一次脚本并记录准确率。10.2 把确定性计算从模型推理中剥离模型的强项是语言理解和生成弱项是精确计算。空间推理任务中能用代码计算的不要用模型“心算”能用工具查询的不要靠模型记忆。把确定性操作从模型 Prompt 中剥离出来放入工具层或代码层是稳定性最高的方案。10.3 保留一套最小可运行配置无论体验哪种方案都要保留一套最小可运行配置一个评测脚本。一个经过验证的提示词模板。一类模型例如 Qwen2.5-7B-Instruct。一组标准测试题。这套最小配置可以作为后续所有空间推理实验的对照组。10.4 批量任务必须加日志与重试空间推理批量任务建议输出结构化日志包含输入、输出、耗时、错误信息。失败任务自动重试一次重试仍失败则写入错误文件。不要在批量任务中直接跳过失败条目否则最终统计准确率时缺少分母。10.5 接口服务要限制访问范围对外提供空间推理 API 服务时建议监听127.0.0.1而非0.0.0.0如果只在本地使用。增加简单的 API Key 校验。限制单 IP 请求频率。日志中不要记录完整用户输入如果涉及敏感空间数据。10.6 数据与授权合规空间推理的测试数据如果涉及具体地址、园区图纸、人名位置关系务必确认数据来源合法。使用地图数据、CAD 图纸、人脸位置等空间信息前必须获得授权。涉及人的位置信息时要注意隐私保护避免输出可定位到具体个人的敏感信息。如果你用第三方 API 模型做空间推理测试不要把未授权的私有数据直接发送到外部接口。10.7 发布或商用前做效果复核空间推理任务在模型替换、精度切换、提示词改动之后都可能发生变化。发布前用评测集做全量回归不要只测试两三个示例就上线。商用场景下尤其是导航、仓储、地图、辅助驾驶等对空间判断要求高的领域人工复核仍然不可替代。11. 总结与下一步回到最初的问题怎么纠正 LLM 的空间推理从本文的实验路径来看答案不是“某个单一提示词技巧”而是一条工程链路先用批量评测集量化模型当前的错误类型和准确率再通过显式坐标系提示、分步自检、代码解释器等手段提升提示词层面的效果对稳定性要求高的场景把空间计算下沉到确定性工具层最后用 API 服务和批量任务模板把能力暴露给业务系统。最容易踩的坑有三个第一没有评测基线就乱改提示词第二忽略 bf16/fp16/fp32 精度对空间推理准确率的影响第三试图让模型“硬算”而不是调用工具。最值得先做的事就是建一个 20 题左右的最小评测集用你已经部署好的模型跑一次 baseline然后加上“面向北方、方位坐标化、分步计算”这个提示词模板再跑一次对比准确率变化。这个过程只花十几分钟但能立刻告诉你提示词层面的空间推理修复到底还有没有空间。如果你想把空间推理能力接到自己的 Agent 或工作流里下一步建议是做一个确定性空间计算函数让模型只负责解析意图和生成语气词把几何计算交给 Python。这个组合在工程上的稳定性远高于单纯依赖模型参数内部的“空间感”。