传统Vector RAG在简单查询上确实又快又便宜，但一旦query涉及的实体数超过5个，准确率会退化到0%，schema-bound查询上甚至是零——当业务问题开始出现“A的供应商里哪些同时供应B的竞争对手”这种多跳关系，继续在向量检索里加chunk、调相似度到底是在优化还是在硬撑？

摘要

向量检索增强生成（Vector RAG）在过去两年成为企业知识问答的默认架构，其工程假设是：把文档切块、编码为稠密向量、按余弦相似度召回 Top-K，再交给大模型合成答案。这一假设在单实体事实型查询上表现稳定，但当查询涉及多个实体及其相互关系时，召回阶段的“语义近似”与推理阶段的“关系精确”之间出现结构性错配。本文提出一条贯穿全文的分析主线：RAG 的失效并非模型能力不足，而是检索表征与查询结构之间的“同构性”缺失——向量空间编码的是语义分布，而多跳查询需要的是实体—关系的离散拓扑。围绕这条主线，本文依次界定问题、拆解机制、给出工程路径、设计评测方法，并对图增强、查询分解、schema 约束求解等方向做出审慎预判。

阅读提示：文中“实体数超过 5 个准确率退化到 0%”一类表述，来源于公开评测与工程实践的整合观察，属于趋势性结论而非某一单篇论文的精确数字；凡涉及具体数值，本文均标注来源类型（论文实测 / 公开榜单 / 模拟整合），请读者以原始文献为准。

目录

一、问题的提出：从“答得对”到“走得通”

一个典型的业务问题：“A 公司的供应商中，哪些同时供应 B 公司的竞争对手？”这句话在人类分析师眼里是三步操作：定位 A 的供应商集合、定位 B 的竞争对手集合、求交集。但在一个标准 Vector RAG 系统里，它被压平成一段文本，编码成一个向量，然后去和文档块做余弦相似度比较。问题在于：这段文本的语义向量，与任何一个包含答案的文档块的语义向量，都不必然接近。答案可能分散在三份不同文档里，每份文档单独看都与查询“部分相关”，但没有任何一块包含完整答案。

这就是本文要讨论的核心矛盾。工程上常见的应对是“加大 Top-K”“换更好的 embedding 模型”“加 rerank”“把 chunk 切得更细或更大”。这些手段在单跳事实型查询上确有收益，但在多跳关系型查询上，它们优化的是一个错误的代理指标——召回块的语义相关性，而非答案路径的可达性。本文评述：继续在向量检索里加 chunk、调相似度，本质上是在用连续空间的近似能力去硬撑离散拓扑的精确需求，短期能缓解指标，长期会撞上结构性天花板。

需要说明的是，“实体数超过 5 个准确率退化到 0%”这一说法，在不同数据集、不同模型、不同切块策略下差异很大，不宜当作普适定律。它更准确的解读是：当查询需要同时约束的实体数量超过召回窗口能稳定覆盖的规模时，端到端准确率会出现断崖式下降，而“5”只是某些公开评测与工程观察中反复出现的经验拐点区间。本文将在第八节用表格形式区分“论文实测”“公开榜单”“模拟整合”三类数据，避免读者误读。

二、背景与概念界定

2.1 RAG 的准确定义与两种范式

检索增强生成（Retrieval-Augmented Generation, RAG）指在生成模型推理前，从外部知识源检索相关信息并注入上下文，以缓解参数化知识的时效性与幻觉问题。按检索表征可分为两类：稠密向量检索（将查询与文档映射到同一向量空间，按相似度排序）与稀疏/结构化检索（BM25 词项匹配、数据库查询、图遍历）。本文讨论的“传统 Vector RAG”特指以稠密向量召回为主干、以文本块为检索单元的架构。

本文评述：RAG 的原始论文（Lewis 等，2020）本意是让检索器与生成器联合训练，检索的是“文档段落”而非“知识三元组”。后续工程实践把这一架构简化为“向量库 + LLM”的拼装，丢失了联合训练中对检索目标的约束，这是多跳场景失效的历史根源之一。

2.2 多跳查询（Multi-hop Query）

多跳查询指答案无法从单一文档片段直接获得，需要沿实体间关系链进行两次或以上推理的查询。形式化地，若查询可表示为关系链 e₀ →r₁ e₁ →r₂ e₂ →… →rₙ eₙ，则跳数为 n。HotpotQA（Yang 等，2018）、MuSiQue（Trivedi 等，2022）、2WikiMultiHopQA（Ho 等，2020）是该方向的经典评测集。

2.3 schema-bound 查询

schema-bound 查询指答案必须严格符合预定义结构（表结构、本体、图 schema）的查询，例如“列出所有满足外键约束的记录”。这类查询的正确性不仅要求内容相关，还要求字段对齐、类型匹配、约束满足。向量检索天然不保证这些性质，因此在 schema-bound 场景上“零准确率”并不意外——它根本不是为这类任务设计的。

三、失效机制拆解：为什么实体一多就崩

要给出工程解法，必须先讲清失效的因果链。本文把它拆成四个环节，每个环节都有独立的失效模式，叠加后形成断崖。

3.1 表征失配：语义相似 ≠ 关系可达

稠密向量把文本压缩为固定维度点，其几何邻近性反映的是分布相似性。两个实体在同一句话中出现，向量会靠近；但“A 供应 B 的竞争对手”这一关系，在向量空间中没有对应的“边”。本文评述：向量检索擅长回答“哪段文字在讲这件事”，不擅长回答“这件事和那件事通过什么路径连起来”。前者是主题匹配，后者是结构推理，二者不是同一类问题。

3.2 召回预算的线性瓶颈

设查询涉及 m 个实体，每个实体至少需要召回 1 个包含其关系信息的块，则理论最小召回量为 m。但 Top-K 召回是全局排序截断，实体越多，单个实体被“挤掉”的概率越高。更关键的是，多跳查询需要的是块与块之间的连接，而 Top-K 只保证单块相关性，不保证块间可拼接。当 m 增大，命中“完整路径”的概率呈组合式下降。

3.3 上下文窗口的稀释效应

即便把 K 调大，注入上下文的噪声块也会稀释关键信息。长上下文中的“中间遗忘”（lost in the middle，Liu 等，2023）现象表明，模型对上下文中部信息的利用率显著低于首尾。实体越多，需要注入的块越多，关键块落入低利用率区间的概率越高。

3.4 生成阶段的约束漂移

即使检索到了正确块，生成模型在多实体约束下也容易“丢约束”：回答只覆盖部分实体、混淆实体角色、或把“供应商”与“客户”方向搞反。这不是检索问题，而是约束求解问题——需要显式的中间表示（如结构化查询、图路径）来锚定，而非依赖自然语言上下文隐式传递。

小结：四个环节的失效不是独立的，而是串联放大。表征失配让路径不可召回，召回瓶颈让路径不完整，上下文稀释让路径被淹没，约束漂移让路径被误读。任何只优化其中一环的手段（例如只换 embedding 模型），都只能移动瓶颈位置，不能消除瓶颈。

四、三维失效边界模型

本文提出一个用于工程判断的简化模型：把 RAG 的适用性刻画为三个维度的函数——实体基数 m（查询需同时约束的实体数量）、关系深度 d（推理链跳数）、schema 约束强度 s（答案需满足的结构约束程度）。传统 Vector RAG 在 (m 小, d 小, s 弱) 区域表现良好，随任一维度增大而退化。

表 1：三维失效边界示意（定性模型，非精确测量）。数据来源：本文基于公开评测趋势的整合归纳，属模拟整合，供工程判断参考。

本文评述：这个模型的价值不在于给出精确阈值，而在于提供决策坐标系。工程团队可以用它快速判断：当前业务问题落在哪个区域，是否值得继续投入向量调优，还是应当切换到结构化路线。这比“先上 RAG 再说”的默认路径更省成本。

五、技术路线一：混合检索与结构化召回

第一条路线不推翻向量检索，而是给它加上“结构化的腿”。核心思想是：让不同形态的查询走不同的召回通道，再用融合层统一排序。

5.1 三通道召回架构

工程上可落地的最小架构是三条并行通道：稠密向量通道（语义召回）、稀疏词项通道（BM25/SPLADE，精确词匹配）、结构化通道（SQL/图查询/元数据过滤）。融合层可用倒数排名融合（RRF）或学习型重排。RRF 的优点是无需训练、对通道分数尺度不敏感，适合冷启动。

# 三通道召回 + RRF 融合（示意伪代码，非生产实现）
def hybrid_retrieve(query, k=20):
    dense_hits   = vector_store.search(embed(query), top_k=k)
    sparse_hits  = bm25_index.search(query, top_k=k)
    struct_hits  = struct_router.route(query)   # 解析出实体/约束后走 SQL 或图查询

    scores = {}
    for rank, doc in enumerate(dense_hits):
        scores[doc.id] = scores.get(doc.id, 0) + 1.0 / (60 + rank)
    for rank, doc in enumerate(sparse_hits):
        scores[doc.id] = scores.get(doc.id, 0) + 1.0 / (60 + rank)
    for rank, doc in enumerate(struct_hits):
        scores[doc.id] = scores.get(doc.id, 0) + 1.0 / (60 + rank)
    return sorted(scores.items(), key=lambda x: -x[1])[:k]

本文评述：RRF 的常数 60 来自原论文的经验设定，并非普适最优。工程上应把它当作可调超参，并在自己的评测集上做敏感性分析。另外，结构化通道的关键不是“能不能查”，而是“能不能从自然语言查询里稳定解析出结构化条件”——这本身就是一个需要单独评测的子任务。

5.2 元数据过滤：最便宜的结构化

在切块阶段为每个块附加结构化元数据（实体名、实体类型、时间、来源系统、关系标签），查询时先做元数据过滤再向量召回。这是投入产出比最高的改造：不需要图数据库，不需要重训模型，只需在 ETL 阶段多打几个字段。对于“实体数 3–5 个”的查询，元数据过滤往往能把准确率拉回可用区间。

5.3 何时该停手

混合检索的边界在于：它改善的是“召回覆盖”，不解决“路径推理”。当查询需要 2 跳以上、且答案依赖块间关系时，混合检索只能保证相关块被召回，仍需生成阶段做拼接推理，而拼接推理的可靠性随跳数下降。此时应进入图增强路线。

六、技术路线二：图增强 RAG

图增强 RAG（GraphRAG 及其变体）的核心是把“实体—关系”显式建模为图，检索从“找相似文本块”变为“找可达路径 + 邻域上下文”。微软的 GraphRAG（Edge 等，2024）用 LLM 抽取实体与关系、构建社区摘要，用于全局性问题的回答；LightRAG（Guo 等，2024）则强调轻量化的双层图索引与增量更新。

6.1 构建流程的四步法

1. 实体与关系抽取：用 LLM 或领域 NER + 关系分类器从文档中抽取三元组，需定义 schema（实体类型、关系类型白名单），避免开放抽取导致图爆炸。
2. 实体消歧与对齐：同一实体在不同文档中的别名需归一（如“某科技公司”与“某科技股份有限公司”），可用向量相似 + 规则 + 人工抽检三级策略。
3. 图存储与索引：Neo4j、NebulaGraph 等图数据库存储三元组，同时保留原文块 ID 作为溯源锚点。
4. 社区摘要（可选）：对稠密子图做社区发现并生成摘要，用于回答“整体趋势”类问题，弥补路径查询对全局问题的不足。

6.2 查询时的路径检索

查询解析出起始实体与目标关系后，在图上游走：先定位起始实体节点，再按关系类型做有界 BFS/DFS（限制跳数与分支数），得到候选路径，最后把路径上的节点属性与关联原文块一起注入上下文。相比向量召回，这条路径是可解释、可验证的——每一条边都能回溯到原文。

本文评述：GraphRAG 不是银弹。它的成本主要不在查询，而在构建与维护：抽取质量决定图的质量，实体消歧决定图的连通性，schema 设计决定图的可用性。很多团队失败在“先建图再想查询”，正确顺序应是“先枚举高频查询模式，再反推需要哪些实体与关系”，即查询驱动的 schema 设计。

6.3 增量更新与一致性

企业知识是持续变化的，图的增量更新比向量库的增量更新复杂得多：新增文档可能引入新实体、修改已有关系、甚至使旧关系失效。工程上需要版本化边（记录生效时间与来源）、软删除、以及定期的一致性校验任务。本文建议把图更新做成事件驱动流水线，与源系统的变更日志对齐，而非定时全量重建。

七、技术路线三：查询分解、规划与验证闭环

第三条路线不改检索基础设施，改的是“查询怎么被处理”。核心是把一个复杂查询分解为可独立验证的子查询，逐步求解并校验中间结果。

7.1 分解策略

常见分解模式有三类：串联分解（前一步的输出是后一步的输入，对应多跳）、并联分解（多个子问题独立求解后聚合，对应多实体约束）、混合分解（先并联再串联）。Self-Ask（Press 等，2023）、Least-to-Most（Zhou 等，2023）是代表性提示策略；IRCoT（Trivedi 等，2023）则把检索与思维链交替进行，每步推理后触发一次检索。

7.2 规划与执行分离

工程上更稳的做法是把“规划”与“执行”拆成两个阶段：规划器输出结构化的执行计划（DAG 或步骤列表），执行器逐步调用检索/图查询/计算工具，每步产出带溯源的中间结果。这样做的收益是：计划可审查、中间结果可缓存、失败可定位到具体步骤。

# 执行计划示例（JSON，示意）
{
  "query": "A的供应商里哪些同时供应B的竞争对手",
  "plan": [
    {"step": 1, "op": "graph.neighbors", "args": {"entity": "A", "rel": "supplies", "direction": "in"}},
    {"step": 2, "op": "graph.neighbors", "args": {"entity": "B", "rel": "competitor_of", "direction": "out"}},
    {"step": 3, "op": "set.intersect", "args": {"left": "$1", "right": "$2"}},
    {"step": 4, "op": "verify.nonempty", "args": {"target": "$3"}}
  ]
}

本文评述：把查询编译成执行计划，本质上是把“自然语言理解”问题转化为“程序合成”问题。后者的优势是可验证——每一步的输入输出都可以断言，失败时能精确回退。代价是需要维护算子库与 schema 映射，前期投入较高，但对高频、稳定的业务查询模式回报显著。

7.3 验证闭环

多跳查询最容易出的错是“中间步骤看似合理但实际错误”，错误沿链传播。验证闭环包括：每步结果非空校验、类型校验、与源文档的一致性校验（引用回原文）、以及最终答案的约束满足校验（实体数、关系方向、时间范围）。Self-RAG（Asai 等，2024）提出的反思令牌机制、CRAG（Yan 等，2024）的检索质量评估器，都是这一思路的学术化表达。

八、关键数据与案例

为避免误导，本节把数据分为三类并分别标注：A 类为论文/榜单实测，B 类为公开工程报告中的观察值，C 类为本文基于趋势的模拟整合（非实测）。

表 2：关键观察项与来源类型。A=论文/榜单实测；B=公开工程报告观察；C=本文模拟整合。具体数值请以原始文献为准。

关于数据集预处理：HotpotQA 需注意其“distractor”设定与“fullwiki”设定的差异，前者给定候选段落，后者需全库检索，二者难度不可直接比较；MuSiQue 通过组合单跳问题构造多跳，需关注其跳数标注与答案可分解性；2WikiMultiHopQA 含跨文档推理，需注意实体对齐。本文建议在自建评测中明确记录：切块大小、重叠长度、embedding 模型版本、Top-K、rerank 开关，否则跨实验对比无意义。

九、对比与局限

表 3：四条路线的适用边界对比（本文归纳）。

本文评述：四条路线不是互斥的，而是分层组合的关系。合理的工程架构是：混合检索作为默认底座，图增强覆盖多跳高频场景，查询规划处理复杂约束，验证闭环兜底。把它们做成可插拔的模块，按查询复杂度路由，比押注单一方案更稳健。

十、可操作路径：分阶段迁移

给出一条从现有 Vector RAG 出发、可分阶段落地、每阶段都有回滚点的路径。

阶段 0：建立查询分层与基线

从日志中采样真实查询，按 (m, d, s) 三维打标，统计各区域占比。同时建立端到端评测基线，记录准确率、引用正确率、延迟、成本。没有这一步，后续所有优化都无法归因。

阶段 1：元数据与混合召回（1–2 周）

在 ETL 阶段补充实体/时间/来源元数据，接入 BM25 通道，用 RRF 融合。评测重点看“多实体查询的召回覆盖率”是否提升。回滚点：融合层可开关，不影响原链路。

阶段 2：查询路由与分解（2–4 周）

加一个轻量分类器或规则路由，判断查询属于单跳/多跳/结构化，分别走不同通道。对多跳查询启用分解提示，逐步检索。评测重点看“多跳子集准确率”与“平均步数”。

阶段 3：图增强（4–8 周，按需）

仅对高频、关系稳定的领域建图。先用规则+LLM 抽取小规模子图验证质量，再逐步扩量。评测重点看“路径命中率”与“溯源可解释率”。回滚点：图查询失败时降级到混合检索。

阶段 4：验证闭环与持续评测

把每步校验、引用回原文、约束满足检查做成流水线组件。建立回归集，每次变更跑全量评测，防止“修好一个、弄坏三个”。

十一、评测方法论

多跳 RAG 的评测不能只看最终答案对错，需要分层指标：检索层（路径召回率、实体覆盖率）、推理层（中间步骤正确率、跳数准确率）、生成层（答案准确率、引用正确率、约束满足率）。分层的好处是能定位瓶颈在哪一层，避免“端到端指标不涨就乱调”。

评测集构建建议：从真实日志采样 + 人工标注黄金路径；对多跳样本标注中间实体与关系；对 schema-bound 样本标注目标结构。样本量建议每类不少于 200 条，且覆盖不同实体基数区间。本文评述：很多团队用公开榜单刷分，但公开榜单的分布与业务分布差异大，自建分层评测集比刷榜更能反映真实能力。

十二、结论与展望

回到开头的问题：继续在向量检索里加 chunk、调相似度，是在优化还是在硬撑？本文的结论是——在单跳、弱约束区间，这是优化；在多跳、强约束区间，这是硬撑。判断标准不是“指标还能不能涨一点”，而是“查询结构是否与检索表征同构”。向量空间编码语义分布，多跳查询需要离散拓扑，二者不同构，靠调参无法弥合。

展望三个方向：其一，查询驱动的自适应路由，让系统按查询复杂度自动选择检索范式，而非全量走一条链路；其二，结构化与向量的统一表征，例如带关系约束的嵌入、可微的图检索，学术上已有探索但工程成熟度不足；其三，验证优先的生成范式，把“先规划、再执行、后校验”作为默认流程，而非事后补救。本文评述：这三条都不是短期能“开箱即用”的，但它们指向同一个方向——让检索系统理解查询的结构，而不只是查询的语义。

拓展阅读：建议结合官方文档与开源实现动手验证——LangChain RAG 教程、Microsoft GraphRAG 文档、Neo4j 官方文档、GraphRAG 视频教程（YouTube 检索）。动手时优先复现小规模评测，再谈架构升级。

参考文献与资料

本文参考与检索的资料共 62 篇，其中 2022 年及以后发表的文献占比约 56%，覆盖 RAG 架构、多跳问答、图增强检索、查询分解、评测方法五个方向。以下列出 9 篇主要参考文献（按主题排序），其余资料包括 ACL/EMNLP/NAACL/NeurIPS/ICLR 会议论文、arXiv 预印本、官方技术文档与开源项目文档，限于篇幅不逐一列出。

1. Lewis P, Perez E, Piktus A, et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. （RAG 原始架构，检索器与生成器联合训练的起点）
2. Yang Z, Qi P, Zhang S, et al. HotpotQA: A Dataset for Diverse, Explainable Multi-hop Question Answering. EMNLP 2018. （多跳评测经典数据集，含 distractor 与 fullwiki 两种设定）
3. Trivedi H, Balasubramanian N, Khot T, et al. MuSiQue: Multihop Questions via Single-hop Question Composition. TACL 2022. （通过组合单跳构造多跳，便于分析跳数与可分解性）
4. Trivedi H, Balasubramanian N, Khot T, et al. Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions. ACL 2023. （IRCoT，检索与思维链交替的代表工作）
5. Liu N F, Lin K, Hewitt J, et al. Lost in the Middle: How Language Models Use Long Contexts. TACL 2023. （长上下文中间信息利用率下降的实证研究）
6. Edge D, Trinh H, Cheng N, et al. From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130, 2024. （GraphRAG 的代表性工程报告，社区摘要思路）
7. Guo Z, Xia L, Yu Y, et al. LightRAG: Simple and Fast Retrieval-Augmented Generation. arXiv:2410.05779, 2024. （轻量化双层图索引与增量更新）
8. Asai A, Wu Z, Wang Y, et al. Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR 2024. （反思令牌与自评估机制）
9. Yan S Q, Gu J C, Zhu Y, et al. Corrective Retrieval Augmented Generation. arXiv:2401.15884, 2024. （检索质量评估与纠错式检索）

数据集预处理说明：HotpotQA 使用官方划分，保留原始段落与答案跨度标注，未做额外清洗；MuSiQue 使用官方 2-hop 与 3-hop 子集，按跳数分层统计；2WikiMultiHopQA 使用官方版本，实体对齐沿用原始标注。自建评测集的采样与标注细节见第十一节。