外挂补丁还是内生先验？地理空间推理大模型的知识库-RAG架构深度拆解

一、问题的提出：一个被“效果不错”掩盖的能力归属问题

过去两年，地理空间推理（geospatial reasoning）成为 LLM 落地的一个热门切口。以 GeoMind 为代表的系统，其架构描述高度一致：底层是一个通用或半领域微调的语言模型，中间挂一个结构化地理知识库（行政区划、POI、路网、地名别名、经纬度、层级隶属关系），外层用向量化检索把与查询相关的地理条目召回并拼进上下文，最后用指令微调让模型学会“看到地理实体就调用检索、看到关系词就组织答案”。这套组合在行政区划问答、POI 邻近性判断、地址解析等任务上确实能跑出可用的准确率。

但工程上真正棘手的问题不是“能不能跑通”，而是跑通的能力到底来自哪里。如果模型之所以答对“A 市是否在 B 省境内”，是因为检索恰好召回了那条隶属记录，那么这本质上是数据库查询，LLM 只是自然语言接口；如果模型之所以答对“从 A 点到 B 点先向北再向东”，是因为它在预训练语料里见过足够多的路径描述模板，那么这本质上是模板匹配，与空间先验无关。两种情况下，系统都“表现良好”，但一旦知识库覆盖不到、或问题需要组合多个关系进行传递推理，能力就会断崖式下跌。

笔者认为，这个问题的尖锐性在于它触及了 RAG 在地理领域的适用边界。RAG 的经典假设是：答案存在于某个可检索的文档片段中，模型的职责是理解问题、定位片段、抽取并组织答案。这个假设在事实型问答中成立，但在空间推理中经常不成立——因为很多空间结论并不“存在于”任何单一文档里，而是需要从多个事实经由几何或拓扑规则推导出来。检索能给你“A 在 B 的北边”和“B 在 C 的北边”，但“A 在 C 的北边”这个结论是推理出来的，不是检索出来的。

本文评述：把“RAG 让模型答对了地理题”直接等同于“RAG 赋予了模型空间推理能力”，是当前大量工程报告和部分论文中普遍存在的归因谬误。要证伪它并不难——做一个知识库覆盖率的分层评测即可：当检索命中率从 95% 降到 60%、再降到 30% 时，如果准确率随命中率近似线性下滑，说明系统能力主要来自检索；如果准确率在命中率下降时仍保持相对稳定，才说明模型具备一定的内生推理补偿能力。这个简单实验，后文会给出完整设计。

因此，本文不打算再复述一遍“知识库+RAG+微调”的架构图，而是要做三件事：第一，建立一个能区分能力来源的三层模型；第二，逐层分析每一层在真实工程中的失效机制；第三，给出可操作的判定方法与改进路径。这条主线会贯穿全部章节。

二、三层能力模型：事实层、约束层、先验层的划分依据

要给“补丁还是先验”这个问题一个可检验的答案，首先需要一个可操作的能力分层。笔者借鉴认知科学与地理信息科学中对空间认知的经典划分，结合 LLM 的工程现实，提出如下三层模型。需要说明的是，这一划分不是本体论意义上的严格分类，而是按“能力可由何种机制提供”来切分的工程分类，目的是让每一层都能对应到具体的系统组件和可测量的指标。

三层模型的判定价值在于：它把“模型会不会”拆成了“哪一层在起作用”。事实层的能力几乎完全外生，检索质量决定上限；约束层的能力在理论上可由符号系统精确提供，但符号系统需要与自然语言接口对齐；先验层才是真正意义上的“模型内生空间能力”，它决定了模型在知识库未覆盖、约束未显式给出时能否给出合理推断。

2.1 为什么约束层不能靠检索解决

拓扑关系（topological relations）是约束层的核心。地理信息科学中广泛使用的区域连接演算（Region Connection Calculus，RCC）给出了 8 种基本关系：DC（分离）、EC（外部连接）、PO（部分重叠）、EQ（相等）、TPP（真部分且反向非真部分）、NTPP（非切向真部分）、TPPi、NTPPi。这 8 种关系构成一个具有明确代数性质的组合表（composition table），任意两个关系可以组合推出第三个关系。RCC-8 的组合表是有限且可查的，这意味着拓扑传递推理本质上是一个查表加组合的符号过程，而不是语言理解过程。

这一点非常关键。如果系统把“A TPP B”“B TPP C”两条事实检索进上下文，然后让 LLM 输出“A TPP C”，模型做对的真实原因可能是它在训练中见过大量“包含的包含还是包含”的语言模式，而不是它真的执行了 RCC 组合。一旦关系类型换成不常见的 NTPP 与 TPPi 组合，或者需要三步以上的链式组合，语言模式就失效了。笔者在多个公开空间推理基准的错例分析中观察到类似现象：两步以内的关系组合正确率显著高于三步以上，且错误集中在少见关系类型上，这与“符号组合能力”的预期一致，而与“语义理解能力”的预期不一致。

笔者认为，约束层的正确工程解法不是“让 LLM 学会拓扑”，而是“让 LLM 学会调用拓扑求解器”。这与计算器类比高度一致：我们从不指望语言模型内生精确的浮点乘法，而是让它生成表达式、调用工具、解释结果。拓扑组合比浮点乘法更简单（有限组合表），更没有理由硬塞进参数里。

2.2 先验层的边界：什么算“空间先验”

“空间先验”这个词在工程讨论中经常被滥用。本文给出一个较窄的定义：空间先验指模型在没有外部知识注入、没有显式规则提示的条件下，对空间概念之间关系作出的、系统性强于随机的判断倾向。例如：知道“河流通常从高处流向低处”“岛屿被水包围”“城市通常位于交通节点”“北半球朝南的坡面更暖”。这些不是某条可检索的事实，而是大量事实背后的统计规律，属于先验层的典型内容。

先验层的能力可以通过扰动实验来测：把同一道题中的实体名替换为虚构地名，保留关系结构，观察模型是否仍能给出结构正确的答案。如果替换后准确率大幅下降，说明模型依赖的是实体相关的记忆而非结构先验；如果基本稳定，说明它确实掌握了一定的结构规律。这个实验设计简单，但能有效区分“记住了”和“理解了”，后文评测章节会给出具体参数。

三、结构化地理知识库：schema 设计与拓扑表达的任务依赖

知识库是这套架构的地基，但地基的“形状”往往被低估。地理知识库的 schema 设计面临一个根本矛盾：空间关系的表达方式本身是任务依赖的。同一个“A 与 B 相邻”，在行政区划任务里指共享边界，在 POI 推荐任务里可能指步行 5 分钟可达，在生态学任务里可能指栖息地连片。如果知识库只存一种“相邻”，那么它在其他任务上就是错的；如果为每种语义都建一套关系，知识库会迅速膨胀且难以维护。

3.1 拓扑表达的三类建模路线

工程上常见的建模路线有三类，各有明确的适用边界。第一类是显式关系三元组，如 (A, 相邻, B)，存储简单、检索直接，但关系语义单一，无法表达程度和条件。第二类是几何对象存储，保存实体的坐标、边界多边形，关系在查询时由几何引擎实时计算，语义精确、可支持任意关系定义，但计算开销大且依赖高质量几何数据。第三类是混合式，高频关系预计算成三元组，低频或参数化关系走几何计算。

本文评述：多数 GeoMind 类系统的公开描述停留在“我们有结构化知识库”，但很少说明关系是预计算还是实时计算、语义边界如何界定。这个信息缺口恰恰决定了系统的真实能力上限。一个只存显式三元组的系统，在需要“距离 500 米以内”这类参数化关系时，要么答不出，要么靠 LLM 猜，而猜的结果无法验证。

3.2 覆盖范围的量化：别用“POI 数量”自欺

知识库覆盖率的常见宣传口径是“收录了多少万 POI”“覆盖多少行政区”。这个口径对空间推理几乎没有意义，因为推理任务需要的是关系密度而非实体数量。一个有一亿 POI 但彼此之间没有关系标注的库，在拓扑推理任务上的可用性接近于零。更有意义的覆盖率指标应当包括：目标区域内实体与关系的比值、关系类型的分布熵、以及针对评测集的关系召回率。

以公开的行政区划数据为例，全国五级行政区划实体数量在数十万量级，而它们之间的隶属关系数量与实体数量同阶，关系密度高、结构规整，因此这类任务上知识库+RAG 的效果天然好。反观 POI 之间的邻近、可达、同类聚集等关系，数量随半径平方增长，标注成本极高，关系密度低且噪声大，这正是 RAG 方案在 POI 推理任务上表现不稳的结构性原因。笔者认为，选任务时先看关系密度，比看模型参数量更能预测成败。

3.3 数据预处理：以开放街图与行政区划为例

涉及地理数据集时，预处理细节直接决定后续检索与推理的质量。以开放街图（OpenStreetMap，OSM）为例，原始数据是节点、路径、关系构成的图结构，转换为可用知识库通常需要：投影到统一坐标参考系（如 Web Mercator 或本地高斯投影，视任务而定）；对多边形做拓扑修复（自相交、悬挂边、重复点）；按行政边界裁剪并建立层级索引；对名称字段做规范化（全半角、繁简、别名合并）；对关系做一致性校验（如隶属关系不得成环）。行政区划数据（如国家统计局公布的行政区划代码）则需要处理历史变更、撤并、代码复用等问题，建议保留版本时间戳而非直接覆盖。

这些步骤听起来琐碎，但每一步都会在检索阶段放大。坐标参考系不统一会导致距离计算系统性偏移；拓扑未修复会导致“相邻”判断出现伪关系；名称未规范化会导致同一实体被检索成多个条目，进而让模型在上下文中看到矛盾信息。工程经验是：知识库预处理投入的时间，通常与后续 RAG 调优节省的时间成正比。

拓展阅读方面，OSM 的官方 wiki 对数据模型有完整说明（OSM Elements），PostGIS 官方文档对空间关系函数有逐条定义（PostGIS Reference），GeoPandas 的拓扑操作教程适合快速上手（GeoPandas User Guide）。

四、向量化检索：召回率、粒度与“检索到≠推理出”的鸿沟

向量化检索是这套架构的中间层，也是误解最集中的一层。常见的工程叙事是“把地理知识向量化，检索相关片段喂给模型”。但地理知识的向量化面临一个结构性困难：空间关系是结构化的，而向量检索擅长的是语义相似，两者并不天然对齐。查询“A 市北边的城市”在语义上接近“A 市 北方 城市”，但真正需要的是在坐标空间里做方向过滤，向量相似度对此无能为力。

4.1 检索粒度：条目级、片段级还是关系级

检索粒度是第一个需要明确的工程决策。条目级检索把每个实体作为一个向量，召回实体后由下游拼装属性；片段级检索把描述文本切块，适合非结构化资料；关系级检索把三元组或子图作为检索单元，最贴近推理需求但实现复杂。三者的召回特性差异明显：条目级召回率高但信息稀疏，关系级信息密度高但召回率受限于关系抽取质量。

笔者认为，对空间推理任务，纯向量检索应当只作为“实体链接”的第一跳，而不是知识注入的终点。合理的流程是：查询先做实体识别与链接（可用向量检索辅助），拿到实体 ID 后走结构化查询或图遍历获取关系子图，再把子图序列化进上下文。这样既利用了向量检索对模糊表述的鲁棒性，又避免了用语义相似度去近似结构关系。

# 伪代码：两跳式地理检索（实体链接 + 子图扩展）
def geo_retrieve(query, top_k_entity=5, hop=2, max_nodes=40):
    # 第一跳：向量检索做实体链接，只取候选实体 ID
    cand_entities = vector_index.search(query, top_k=top_k_entity)
    seeds = [e for e in cand_entities if e.score >= ENTITY_LINK_THRESHOLD]

    # 第二跳：在结构化图上做受限扩展，按关系类型白名单过滤
    subgraph = graph.expand(
        seeds,
        hops=hop,
        rel_whitelist=["隶属", "相邻", "包含", "位于"],
        max_nodes=max_nodes,
        prune=score_by_relevance(query)   # 相关性剪枝，防止上下文爆炸
    )
    return serialize_subgraph(subgraph)   # 序列化为模型可读的紧凑文本

这段伪代码的关键不在实现，而在两个设计选择：实体链接阈值与关系白名单。阈值过低会把噪声实体带进子图，阈值过高会漏召回；白名单过宽会让子图膨胀，过窄会切断必要的推理链。这两个参数没有普适最优值，必须按任务调，后文工程路径会给出调参方法。

4.2 召回率与正确率的非线性关系

“检索到≠推理出”这句话需要量化。设检索命中率为 r，模型在命中条件下的条件正确率为 p_hit，在未命中条件下的条件正确率为 p_miss，则总体正确率约为 r·p_hit + (1−r)·p_miss。这个简单分解揭示了一个常被忽略的事实：如果 p_miss 显著大于随机水平，说明模型在检索失败时仍有补偿能力，系统具备先验层；如果 p_miss 接近随机，说明系统完全依赖检索，是纯粹的补丁架构。

因此，评测报告只报总体准确率是不够的，必须同时报 p_hit 与 p_miss。笔者建议把 p_miss 作为衡量“内生空间能力”的核心代理指标。一个健康的系统应当满足：p_hit 高（检索有效）、p_miss 明显高于随机（有先验补偿）、且两者差距不过分悬殊（不出现“有检索就神、没检索就废”的极端依赖）。若 p_miss 与随机无异，那么无论总体准确率多高，都应判定为补丁架构。

本文评述：这个分解还有一个工程推论——当知识库覆盖率不足时，提升 p_miss 的边际收益可能高于提升 r。因为覆盖率的提升受数据采集成本约束，而 p_miss 的下降可以通过更好的指令微调和符号工具调用实现。很多团队把资源全押在扩库上，忽视了模型侧的补偿能力建设，这是架构层面的资源错配。

4.3 上下文污染与矛盾信息

检索还有一个隐蔽的失效模式：上下文污染。当召回片段包含相互矛盾的地理信息（如不同年份的行政区划、不同来源的坐标），模型往往不会指出矛盾，而是随机采信其中一条或试图调和，导致答案看似合理实则错误。地理数据的时效性使这个问题尤为突出——行政区划撤并、道路改建、POI 关停都会让旧数据变成“看起来对但已过时”的污染源。

工程上的缓解手段包括：为每条知识打上时间戳与来源标签，检索时按查询隐含的时间约束过滤；在上下文序列化时显式标注来源与时间，让模型有机会表达不确定性；对高冲突实体设置“需人工确认”的降级路径。这些手段不能根除问题，但能把“静默错误”转化为“显式不确定”，后者对生产系统更有价值。

五、指令微调：把查表固化成推理，还是把推理退化成查表

指令微调（instruction tuning）在这套架构中承担“教会模型使用知识库”的职责。典型做法是构造大量“问题—检索结果—答案”三元组，让模型学会在看到检索上下文时抽取并组织答案。这个做法有效，但存在一个方向性风险：如果训练数据中检索结果总是充分且正确，模型会学成“有上下文就抄、没上下文就编”的条件反射，而不是“用上下文辅助推理”的能力。

5.1 数据配比：充分、部分、缺失三档

要避免上述退化，训练数据必须刻意包含“检索不充分”的情形。笔者建议按三档配比构造：充分档（检索结果完整覆盖推理所需事实）、部分档（只覆盖一部分，需要模型用先验补全或明确表示不确定）、缺失档（检索为空或无关，模型应拒绝编造并说明原因）。三档的比例没有定论，但工程经验是部分档与缺失档合计不应低于三成，否则模型会过度依赖上下文。

部分档的构造尤其考验设计。它不能简单地把检索结果删掉一半，因为随机删除会产生语义不连贯的上下文，模型学到的是“忽略残缺上下文”而非“用先验补全”。更合理的做法是按推理链删除关键节点：保留前提、删除中间关系，让模型必须推断中间步骤；或保留关系、删除实体属性，让模型必须做实体消歧。这样构造出的样本才真正训练推理而非训练抄写。

5.2 工具调用式微调：让模型学会“不猜”

比数据配比更进一步的，是把微调目标从“生成答案”改为“生成求解计划”。具体做法是：训练模型在遇到需要精确几何计算或拓扑组合的问题时，输出结构化的工具调用（如 distance(A,B)、rcc_compose(r1,r2)），由外部引擎执行后再由模型解释结果。这种训练方式把约束层的职责交还给符号系统，模型只负责理解问题、选择工具、组织解释。

# 工具调用式样本（训练格式示意）
用户：A 县在 B 市境内，B 市在 C 省境内，A 县在 C 省境内吗？

助手（训练目标）：
{
  "plan": [
    {"tool": "rcc_query", "args": {"subject": "A县", "object": "B市"}},
    {"tool": "rcc_query", "args": {"subject": "B市", "object": "C省"}},
    {"tool": "rcc_compose", "args": {"r1": "$0", "r2": "$1"}}
  ],
  "answer_template": "根据拓扑组合，A县与C省的关系为 {result}，因此{结论}。"
}

本文评述：工具调用式微调的最大价值不是提升准确率，而是把不可验证的“模型直觉”转化为可验证的“执行轨迹”。当模型输出一个计划而非直接答案时，工程上可以逐步校验每一步的工具输入输出，错误定位从“答案错了”细化到“第几步错了”。这对生产系统的可维护性是质变，远比几个点的准确率提升重要。

5.3 微调带来的遗忘风险

指令微调并非没有代价。领域微调会带来通用能力的 catastrophic forgetting（灾难性遗忘），这在空间推理上表现为：模型在学会地理问答格式后，对需要常识推理的开放问题反而变差。缓解手段包括混合通用指令数据、使用参数高效微调（如 LoRA）限制更新范围、以及在微调后做通用能力回归测试。这些是常规工程实践，但在地理领域常被忽视，因为团队往往只关注领域指标。

六、评测方法论：如何用消融实验区分补丁效应与能力增益

前面几章的分析要落地，最终依赖一套能区分能力来源的评测方法。本节给出一套可执行的消融设计，核心思路是逐层剥离外部组件，观察性能衰减曲线。如果剥离某组件后性能断崖下跌，说明该组件是能力主来源；如果衰减平缓，说明模型有其他补偿路径。

6.1 四组消融与预期曲线

E3 的曲线形状是最有信息量的。如果准确率随覆盖率近似线性下滑，说明系统能力与知识覆盖强绑定，是补丁架构；如果曲线呈“先缓后陡”的凸形，说明模型在覆盖不足时仍能靠先验维持一段时间，具备一定的内生补偿；如果出现“平台期”，则要警惕评测集本身存在记忆泄漏。E4 则直接测先验层：结构保持率高说明模型掌握了关系结构而非实体记忆。

6.2 评测集构造的常见陷阱

评测集构造中的陷阱比模型本身更容易让结论失真。第一是实体泄漏：评测题中的实体在训练数据中出现过，模型靠记忆答对，掩盖了推理能力的缺失。第二是模板泄漏：评测题与训练题句式高度相似，模型靠模板匹配答对。第三是答案分布偏斜：是非题中“是”的比例过高，模型全答“是”也能拿到虚高准确率。第四是时效错配：用旧行政区划出题，模型答“错”其实是对的。

针对这些陷阱，构造评测集时应做：实体去重（评测实体不出现在训练集）、句式扰动（同义改写、语序调整）、答案平衡（正负样本接近 1:1）、时间锚定（每题标注有效时间范围）。这些做法增加构造成本，但能把评测从“看起来专业”变成“真的能指导决策”。

6.3 一个可复用的评测脚本骨架

# 评测骨架：分层统计 + 消融对比
def evaluate(system, dataset, coverage_levels=(1.0, 0.6, 0.3)):
    results = {}
    for cov in coverage_levels:
        system.set_kb_coverage(cov)          # 控制知识库覆盖
        hit, miss = [], []
        for item in dataset:
            ctx, hit_flag = system.retrieve(item.query)
            pred = system.answer(item.query, ctx)
            (hit if hit_flag else miss).append(pred == item.gold)
        results[cov] = {
            "acc": (sum(hit) + sum(miss)) / (len(hit) + len(miss)),
            "p_hit": sum(hit) / max(len(hit), 1),
            "p_miss": sum(miss) / max(len(miss), 1),
        }
    return results   # 关注 p_miss 随 coverage 的变化斜率

这个骨架刻意保持简单，目的是让团队能快速跑通并迭代。真正需要投入精力的是数据集构造与结果解读，而非评测框架本身。关于空间推理评测的公开资源，可参考相关基准的官方仓库与论文（如 ScienceQA 的多模态推理设计思路，以及 相关空间推理评测研究），但需注意这些基准的地理数据多来自英语世界，直接迁移到中文场景需重新校准。

七、工程路径：五步落地法与失败模式清单

把前面的分析转化为可执行路径，笔者建议按以下五步推进。这五步的顺序有意为之：先建评测再建系统，先定边界再堆组件，避免“先做出来再想为什么有效”的常见弯路。

7.1 第一步：任务分层与关系密度评估

先列出目标任务清单，对每个任务标注它主要落在哪一层（事实/约束/先验），并估算所需关系密度。关系密度高、结构规整的任务（行政区划、地址解析）适合知识库+RAG 主导；关系密度低、需要几何计算的任务（距离排序、缓冲区分析）必须以几何引擎为主；需要常识推断的任务（“这个山谷适合建水库吗”）则高度依赖先验层，RAG 只能提供辅助事实。这一步的产出是一张任务-层级映射表，它决定了后续资源分配。

7.2 第二步：知识库 schema 与几何引擎的职责切分

明确哪些关系预计算、哪些实时算。经验规则是：查询频率高且关系语义稳定的预计算（隶属、行政区划层级）；查询频率低或关系参数化的走几何引擎（距离阈值、方向扇区、缓冲区相交）。同时为每条知识打上来源、时间、置信度三元标签，为后续的污染控制留出接口。

7.3 第三步：两跳检索与上下文序列化

按第四章的两跳式检索实现：向量检索做实体链接，图遍历做关系扩展。上下文序列化要紧凑且带结构标记，例如用缩进表示层级、用显式字段名标注关系类型，避免把子图拍平成一段散文——后者会让模型难以区分事实与关系。序列化长度要设上限并做相关性剪枝，防止上下文窗口被无关节点占满。

7.4 第四步：三档数据微调与工具调用训练

按第五章的三档配比构造指令数据，并逐步引入工具调用样本。建议分两阶段：第一阶段用充分档教会模型使用上下文格式；第二阶段混入部分档、缺失档与工具调用样本，训练推理与拒答能力。第二阶段的学习率应更低，避免破坏第一阶段学到的格式能力。微调后必须做通用能力回归，防止遗忘。

7.5 第五步：消融评测与迭代

按第六章的四组消融跑基线，重点看 p_miss 与覆盖率曲线。根据结果决定迭代方向：若 p_miss 接近随机，优先补先验层（增加推理型训练数据、引入工具调用）；若 p_hit 偏低，优先修检索（实体链接阈值、关系白名单、知识库预处理）；若两者都尚可但总体不稳，检查上下文污染与时效问题。

八、前沿预判：神经符号混合与几何感知的下一步

如果“补丁论”成立，那么架构演进的方向就不是把补丁做得更大，而是改变补丁与主体的关系。笔者认为有三条值得关注的技术路线，按成熟度从高到低排列。

8.1 神经符号混合：把约束层外包给求解器

这是当前最务实的方向。核心思想是让 LLM 负责语义解析与结果解释，让符号系统负责关系组合与约束满足。RCC-8 组合表、空间数据库的空间谓词、路径规划算法都是现成的符号组件，缺的是与 LLM 的稳定接口。工程上的关键挑战是接口的鲁棒性：模型生成的工具调用参数可能格式错误、实体指代不清、单位缺失，需要一层参数校验与消歧中间件。这条路线不追求模型内生空间能力，而是承认边界、明确分工，因此最可能在短期内产出可靠系统。

8.2 几何感知的位置编码与空间预训练

更长远的路线是让模型在预训练阶段就接触空间结构，而非事后补丁。可能的形式包括：在位置编码中引入坐标或图结构信息、用地理知识图谱做对比学习预训练、用合成空间推理任务做课程学习。这条路线理论上能真正提升先验层，但面临数据构造难、评测难、收益不确定的问题。笔者认为，短期内它更适合作为研究探索而非工程选型，因为其收益难以在现有评测体系下被稳定验证。

8.3 空间约束解码

第三条路线在解码阶段施加空间约束，例如限制模型只能生成知识库中存在的实体名、对方向词与距离词做合法性校验、对拓扑关系做一致性检查。这相当于在生成时加一道“空间语法”过滤器。它的优势是无需重训模型、可即插即用；局限是只能约束形式不能提升理解，对复杂推理帮助有限。适合作为生产系统的兜底手段。

本文评述：三条路线并非互斥，合理的架构是分层组合——符号求解器承担约束层，约束解码兜底形式合法性，空间预训练作为长期投入提升先验层，RAG 继续负责事实层。把“补丁还是先验”当成二选一是个伪命题，真问题是每一层由谁负责、边界在哪、如何验证。架构设计的成熟标志，不是组件更多，而是职责更清。

九、结论

回到开篇的问题：RAG+地理知识库到底是在给 LLM 补空间推理能力，还是在给一个缺乏空间先验的模型打外部补丁？本文的答案是：在事实层，它是有效的能力扩展；在约束层，它是低效的替代方案，应当让位于符号求解；在先验层，它基本无能为力。把三者混为一谈，就会得出“RAG 提升了空间推理”的笼统结论，掩盖了能力来源的差异。

这个判断有明确的工程含义。第一，选任务时先看关系密度与层级归属，不要用统一架构硬套所有地理问题。第二，评测必须报告 p_hit 与 p_miss 的分层结果，只报总体准确率无法指导架构决策。第三，知识库 schema 要为“预计算 vs 实时计算”的切分留出空间，纯三元组方案在参数化关系上必然碰壁。第四，指令微调要刻意包含检索不充分的样本，否则会把模型训成抄写器。第五，长期看，神经符号混合比继续扩大补丁更接近问题的本质。

笔者认为，地理空间推理大模型当前所处的阶段，类似于早期计算器与语言模型的关系：不是让模型学会算术，而是让模型学会在需要算术时调用计算器。承认 LLM 在精确空间约束上的先天不足，不是悲观，而是把工程资源投向真正能产生增益的地方。当架构的每一层职责都清晰可验证时，“补丁还是先验”的争论自然消解——因为那时我们不再需要用一个模糊的“能力”概念去解释系统行为。