企业官网建设流程全解析

最近在 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 的空间推理缺陷不是单一原因造成的，通常表现为以下几类。

一个关键结论是：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", encoding="utf-8") as f: return json.load(f) def ask_model(base_url, model, prompt, max_tokens=512): payload = { "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": 0, "max_tokens": max_tokens, } resp = requests.post( f"{base_url}/chat/completions", json=payload, timeout=120 ) 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", default="http://127.0.0.1:8000/v1") parser.add_argument("--model", default="qwen2.5-7b") parser.add_argument("--cases", default="cases.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(f"Accuracy: {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(f"delta=({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(title="Spatial Reasoning API") class SpatialRequest(BaseModel): question: str = Field(..., description="用户的空间推理问题") mode: str = Field("reflection", description="reflection / 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_model=SpatialResponse) def spatial_reasoning(req: SpatialRequest): # 这里实际调用评测脚本或外部工具函数 # 本示例返回占位结果，实际项目需要替换为你的推理逻辑 return SpatialResponse( answer="东北", reasoning="分步计算得到目标点相对坐标为正 x 和正 y", confidence=0.92 ) if __name__ == "__main__": uvicorn.run(app, host="0.0.0.0", port=8000)

启动命令：

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, delay=0.5): results = [] for idx, question in enumerate(questions): try: resp = requests.post(API_URL, json={"question": question}, timeout=60) 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", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) 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. 常见问题与排查方法

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。这个组合在工程上的稳定性，远高于单纯依赖模型参数内部的“空间感”。