Vectorless RAG完全抛弃向量数据库、让LLM直接对文档树结构做推理，号称在复杂文档的精确位置定位上有优势，但它的代价是没有语义泛化能力、查询必须严格对齐文档结构——当用户的提问方式和文档的标题体系天然错位时，Vectorless RAG到底是在解决vector RAG的问题，还是在用另一种方式把问题推给用户？

摘要

检索增强生成（Retrieval-Augmented Generation, RAG）的主流实现长期建立在稠密向量检索之上：将文档切块、编码为定长向量、以近似最近邻（ANN）搜索召回候选片段。这一范式在开放域问答中表现稳健，却在"复杂文档的精确位置定位"上反复失手——跨页表格、多层编号条款、嵌套图表说明等结构敏感内容，常因切块边界与语义漂移而丢失上下文。Vectorless RAG 提出了一条反向路径：放弃向量索引，让大语言模型（LLM）直接在文档的树状结构（章节—小节—段落）上做推理式导航，逐层收敛到目标节点。

本文的核心论点是：Vectorless RAG 并非"更好的 RAG"，而是把检索问题从"语义空间匹配"重铸为"结构空间导航"。它用结构先验换取了语义泛化，用查询—结构的严格对齐换取了定位精度。笔者将这一交换代价命名为结构对齐税，并以此为主线，依次讨论其问题定义、树导航机制、成本模型、评测证据、失效边界与混合架构的工程路径。结论是：Vectorless RAG 在"结构可解析、查询可结构化"的窄带上确有优势，但它并未消除 RAG 的根本矛盾，而是把矛盾从检索器转移到了文档治理与查询改写环节——问题被重新分配，而非被消解。

目录

一、背景与问题定义：向量 RAG 的三重失配

1.1 从"检索—生成"到"切块—编码—召回"

RAG 的经典形式可写作：给定查询 q 与文档集合 D，检索器 R 返回候选集合 C = R(q, D)，生成器 G 基于 C 产出答案 a = G(q, C)。稠密检索将 q 与文档块 d_i 分别映射到同一向量空间，以余弦相似度排序。这一设计的隐含假设是：语义相关性可由向量距离近似。

该假设在开放域事实问答中大体成立，但在复杂文档场景中会遭遇三类系统性失配。笔者将其归纳为：粒度失配、边界失配、指代失配。

• 粒度失配：固定长度切块（如 512 token）与文档的自然语义单元（条款、表格行、图注）不对齐。一个跨页表格被切成两半后，任一半的向量都无法代表整表语义。
• 边界失配：切块边界处的上下文丢失，导致"上文提到的例外条款"在召回片段中缺席，模型只能凭先验补全，产生幻觉。
• 指代失配：查询中的"第 3.2 节所述方法""上表第二行"等结构指代，在纯语义向量空间中几乎没有可匹配的信号——"3.2"这个 token 的向量与"方法"的向量距离，并不因文档中二者相邻而更近。

1.2 复杂文档的"精确位置定位"为何困难

"精确位置定位"指系统需返回的不仅是相关内容，而是内容在文档中的确切坐标（章节路径、页码、表格编号），且该坐标需可被人工核验。典型场景包括：合规审计中定位某条款的修订记录、财报中定位某科目在附注中的明细、技术标准中定位某参数的适用范围。

这类任务的评价指标不是答案的语义相似度，而是定位准确率（exact localization accuracy）：返回坐标与金标坐标的匹配程度。向量 RAG 在此指标上的短板是结构性的——即便召回了正确段落，也无法保证返回的坐标是"该段落所在的章节路径"而非"某个相似段落的路径"。当文档中存在大量措辞相近的平行条款（如合同中的多份相似附件），向量相似度几乎无法区分。

1.3 研究脉络：从扁平检索到结构化检索

结构化检索并非新命题。早期工作如 RAPTOR 提出递归摘要树，在树的不同层级做检索；GraphRAG 构建实体—关系图并以社区摘要支持全局问答；LlamaIndex 的文档摘要索引与树索引亦属同类思路。这些工作的共同点是：保留向量检索，但把索引对象从"扁平块"升级为"结构节点"。

Vectorless RAG 走得更远：它取消了向量索引这一层，把树结构直接暴露给 LLM，由模型在导航过程中做"读标题—选分支—下钻"的决策。这一思路与 PageIndex 类"推理式检索"实践相呼应，也与学术界关于"LLM 作为检索器/导航器"的探索同源。

二、Vectorless RAG 的机制解剖：树、导航与推理回路

2.1 文档树的构建：从版面到层级

Vectorless RAG 的第一步是把非结构化文档转换为可导航的树。节点通常携带四类信息：标题文本、层级编号、正文摘要、子节点列表。构建流程可概括为：版面解析（识别标题层级、表格、图注）→ 层级重建（依据编号规则与字号/缩进线索）→ 节点摘要（为每个节点生成简短描述，供导航时快速判断）→ 树序列化（转为 LLM 可读的嵌套文本或 JSON）。

{
  "id": "3",
  "title": "3. 数据安全要求",
  "summary": "规定数据分级、加密与跨境传输的强制性要求",
  "children": [
    {"id": "3.1", "title": "3.1 数据分级", "summary": "四级分类标准与判定依据", "children": []},
    {"id": "3.2", "title": "3.2 加密要求", "summary": "传输与存储加密算法的最低强度", "children": []}
  ]
}

树的质量直接决定后续导航的上限。版面解析错误（如把加粗正文误判为标题）会在树中制造"伪分支"，使导航在错误层级上收敛。这一点在扫描件、双栏排版、跨页表格中尤为突出。

2.2 导航式检索：LLM 如何在树上行走

导航过程是一个"观察—决策—下钻"的循环。在每一层，模型看到当前节点的子节点标题与摘要，依据查询选择最相关的分支，直至抵达叶节点或满足终止条件。其形式可写作：

path = [root]
while not is_leaf(path[-1]) and depth < MAX_DEPTH:
    candidates = children(path[-1])
    scores = llm_score(q, candidates)      # 逐子节点相关性打分
    if max(scores) < THRESHOLD:
        break                               # 提前终止，回退到父节点
    path.append(argmax(scores))
return path

与向量检索的"一次全局排序"不同，导航是逐层贪心的。贪心的好处是每步决策的候选集小、可解释性强；坏处是早期错误无法回滚——若在第 2 层选错分支，后续再精确也无济于事。工程上通常引入束搜索（beam search）或回溯机制缓解，但会成倍增加 LLM 调用次数。

2.3 推理回路与上下文预算

导航的每一步都消耗上下文窗口。若树有 L 层、每层平均 b 个分支、每个分支摘要 t token，则单次查询的导航输入约为 O(L·b·t)。对于层级深、分支多的法规类文档，这一开销可能超过把整节内容直接塞入上下文的成本。因此，Vectorless RAG 的经济性高度依赖树的扇出控制与摘要压缩率。

三、结构对齐税：一个可量化的代价框架

3.1 定义：什么是结构对齐税

笔者将结构对齐税定义为：为使查询能够被结构导航器正确处理，用户在查询构造、文档治理与系统调优上额外付出的总成本，以及因查询与结构错位而损失的召回率。它由三部分构成：

• 查询改写税：用户需把自然语言问题转写为贴合文档标题体系的表述，或由系统插入查询改写模块。
• 文档治理税：需保证文档树的质量——标题规范、编号一致、摘要准确，否则导航在错误结构上运行。
• 错位损失：当查询措辞与标题体系天然错位时，导航直接失败，且失败是"硬失败"（返回错误分支），不像向量检索那样可通过扩大 top-k 兜底。

用公式表达，设 P_v 为向量 RAG 的定位准确率，P_t 为 Vectorless RAG 在理想对齐下的准确率，α 为查询—结构对齐度（0 到 1），则 Vectorless 的有效准确率近似为：

P_eff ≈ α · P_t + (1 - α) · P_fail
其中 P_fail 为错位时的兜底准确率（通常接近 0）

该式揭示了一个关键边界：只有当 α 足够高时，Vectorless 才优于向量 RAG。而 α 的高低并不由检索算法决定，而由"用户提问方式"与"文档标题体系"的耦合程度决定——这正是原问题所指的"天然错位"。

3.2 错位的三种典型形态

查询与结构的错位并非随机，而是有规律可循。笔者在梳理公开文档问答数据集的错误案例后，归纳出三种高频形态：

词汇错位可通过查询改写（同义词扩展、术语映射）缓解；意图错位需要跨分支聚合，单路径导航天然不适合；粒度错位则要求导航能"跳过中间层"直达叶节点，或依赖节点摘要足够细。三者叠加，构成 α 下降的主要来源。

3.3 成本结构的再平衡

从总拥有成本（TCO）看，两种范式的开销分布截然不同。向量 RAG 的前期成本集中在嵌入计算与向量库运维，查询期成本低且可预测；Vectorless RAG 的前期成本集中在文档结构化与摘要生成，查询期成本随导航深度线性增长，且受 LLM 定价波动影响。

一个常被忽略的变量是文档更新频率。向量 RAG 在文档增量更新时只需重编码变更块；Vectorless RAG 则需重建受影响的子树并刷新摘要，若更新触及高层标题，级联范围可能覆盖整棵树。对于高频更新的知识库，这一差异会显著放大运维负担。

四、关键数据与案例：公开基准与工程观测

4.1 公开基准上的结构性证据

需要说明的是，目前尚无专门针对"Vectorless RAG"的统一基准，相关证据分散在长文档问答、多跳问答与结构化检索的评测中。以下数据均来自公开论文与官方榜单，笔者仅做整合与解读，不构成对任何系统的独立复现结论。

LongBench 等长上下文评测中反复出现的"中间遗忘"（lost in the middle）现象，对本文主线有直接含义：即便把整棵树塞进上下文，模型对中段节点的注意力仍会衰减。这意味着 Vectorless RAG 的导航不能依赖"一次性读全树"，而必须真正做逐层收敛——这又回到了扇出控制与摘要质量的问题。

4.2 工程观测：一个可复现的对照设计

由于缺乏公开的 Vectorless 专用数据，笔者建议团队用如下对照设计自建观测（以下为方法描述，非虚构实验数据）：

1. 数据准备：选取 200–500 份结构清晰的文档（法规、标准、财报），用版面解析工具生成树，人工抽检 10% 节点的层级正确性。
2. 查询构造：从金标节点反向生成两类查询——"结构对齐型"（含章节号或标题关键词）与"自然表述型"（仅含业务语义，不含结构词）。
3. 对照组：向量 RAG（固定切块 + top-k）、混合检索（BM25 + 向量）、Vectorless（单路径导航）、Vectorless + 查询改写。
4. 指标：节点级定位准确率、平均导航步数、单查询 token 消耗、硬失败率。
5. 分析：按查询类型分层报告，重点看 α 的分布而非总体均值。

这一设计的关键在于分层报告。若只看总体准确率，两类查询的效应会相互抵消，得出"差不多"的误导性结论。分层后通常能看到：结构对齐型查询上 Vectorless 明显占优，自然表述型查询上向量检索更稳——这正是结构对齐税的直接体现。

4.3 案例：法规条款定位

以某类合规文档为例，用户常问"关于数据留存期限的规定在哪一条"。文档标题体系可能是"第 4 章 数据生命周期管理 / 4.3 存储与销毁 / 4.3.2 留存期限"。查询中的"留存期限"与标题"留存期限"直接对齐，α 高，导航可稳定命中。但若用户问"数据要存多久"，"存多久"与"留存期限"存在词汇错位，α 下降，单路径导航可能在"存储与销毁"与"数据归档"之间误选。

此时若引入查询改写（"存多久"→"留存期限/保存期限"），α 可回升。但改写本身引入新的失败模式：改写过度会偏离原意，改写不足则无效。这构成一个改写—导航的耦合优化问题，而非单点技术问题。

五、对比与局限：横向审视

5.1 四种范式的定位

5.2 局限的边界条件

Vectorless RAG 的适用性可被三条边界条件刻画：

• 结构可解析性：文档必须有稳定的层级结构。对于纯叙述性文本（如访谈记录、小说），树退化为单层，Vectorless 失去意义。
• 查询可结构化程度：查询需能映射到标题语义。跨章节综合问题、开放式探索问题不适合单路径导航。
• 错误容忍度：硬失败不可回滚，要求场景对"返回错误位置"的容忍度低且可人工复核——这恰是合规、审计类场景的特征。

超出这三条边界的场景，Vectorless 的收益会迅速衰减。这也解释了为何它在"复杂文档精确位置定位"上被宣传有优势——该场景恰好同时满足三条条件，属于其能力包络的中心而非边缘。

六、工程落地路径：从文档治理到混合路由的五步法

6.1 第一步：文档结构审计

在引入任何检索架构前，先量化文档的结构质量。建议统计：标题层级完整率、编号一致率、跨页表格占比、扫描件占比。若结构质量低于阈值（如标题完整率 < 80%），应优先投入版面解析与人工校正，而非直接上 Vectorless——在坏树上导航只会放大错误。

6.2 第二步：查询分布画像

从日志中采样真实查询，人工标注其"结构对齐度"（高/中/低），估算 α 的分布。若高对齐查询占比超过 60%，Vectorless 作为主路径可行；若低于 30%，应将其定位为补充通道而非主通道。这一步是决定架构走向的关键，却常被跳过。

6.3 第三步：混合路由设计

推荐的路由逻辑是"先分类、再分流、后融合"：

def route(q):
    if has_structure_ref(q):          # 含章节号、"上表"等结构指代
        return vectorless_navigate(q)
    if is_multi_hop(q):               # 跨章节综合问题
        return graph_or_hybrid(q)
    return hybrid_search(q)           # 默认：BM25 + 向量

# 融合：两路结果按节点 ID 去重，结构路径优先

路由分类器可用轻量规则（正则匹配章节号）加小模型分类器实现，避免为路由本身引入过重开销。关键是保留降级路径：当导航在某层置信度低于阈值时，回退到向量检索兜底，把硬失败转为软失败。

6.4 第四步：查询改写与结构提示

针对词汇错位，可在导航前插入改写步骤：用术语表做同义词映射，或让 LLM 生成 2–3 个候选结构表述，分别导航后取并集。需注意改写预算——每次改写都是一次 LLM 调用，应在准确率增益与成本间做权衡。

6.5 第五步：可观测性与回归

上线后需持续监控：导航平均步数、各层分支选择分布、硬失败率、改写触发率。建议建立"查询—路径—结果"的完整日志，定期抽样人工核验定位准确性。文档更新时，用回归集验证树重建是否引入层级漂移。

七、前沿预判：结构感知检索的下一步

7.1 从"二选一"到"统一表示"

当前争论的根源在于：语义与结构被表示为两套互不相通的索引。前沿方向之一是结构感知嵌入——在编码文档块时注入其层级路径（如"第4章/4.3/4.3.2"），使向量本身携带结构信号。已有工作探索在嵌入输入中拼接标题路径，或在对比学习中加入"同路径正样本"。本文评述：这类方法能部分降低结构对齐税，但无法完全替代显式导航——因为向量仍无法保证"返回坐标可核验"。

7.2 Agent 化导航与工具调用

把导航从"固定循环"升级为"工具调用"，是另一条路径：LLM 可主动调用"列出子节点""读取节点全文""回退到父节点"等工具，形成更灵活的回溯与验证。这与 Agentic RAG 的总体趋势一致。代价是调用次数与延迟上升，需要更精细的预算控制。

7.3 评测体系的缺口

目前缺少专门衡量"结构对齐税"的基准。理想的基准应同时包含：结构对齐型与自然表述型查询、可核验的节点级金标、以及文档结构的质量标注（以便分离"算法问题"与"数据问题"）。在这一基准出现前，任何"Vectorless 优于向量 RAG"的断言都应被视为场景依赖的、待验证的。

八、结论

回到开篇的问题：Vectorless RAG 是在解决 vector RAG 的问题，还是在用另一种方式把问题推给用户？笔者的判断是后者成分居多，但并非零和。

它确实解决了向量 RAG 在结构指代与坐标可核验性上的真实短板，这是增量价值；但它把"语义泛化"这一向量检索的强项交换了出去，并把负担转移到了文档治理与查询改写——即结构对齐税。对于结构规范、查询可结构化的窄带场景，这笔交易划算；对于开放、跨章节、措辞多变的场景，则不划算。

因此，工程上不应做"范式站队"，而应做"分布适配"：先用文档结构审计与查询分布画像确定 α 的直方图，再据此设计混合路由与降级路径。检索架构的演进方向，不是用一种索引取代另一种，而是让语义与结构在同一系统内各司其职、按需切换。

九、主要参考文献

文章声明