RAG 不一定非得靠向量库：一套更偏工程落地的“结构化推理检索”方案

这两年只要聊 RAG，大家脑子里默认浮现出来的，基本都是同一套流程：

切 chunk。
做 embedding。
进向量库。
top-k 检索。
必要时 rerank。
最后把上下文塞给 LLM。

这套东西当然没问题。直到今天，它依然是工业界最主流、最成熟、工程上最好落地的一条路。OpenAI 的 file_search 依然是围绕 vector store 做解析、分块、embedding 和检索；Anthropic 也没有抛弃这条路线，而是在它之上继续补强，提出了 Contextual Retrieval，希望缓解"文本一切就碎、碎了就丢上下文"的问题。Anthropic 官方给出的结果是，这套方法能把 failed retrieval 降低 49%，配合 reranking 后降低 67%。

但如果你做过财报、合同、技术手册、政策文件这类长文档问答，很快就会发现一个更本质的问题：

很多 RAG 的瓶颈，不在生成层，而在检索层一开始就把文档处理错了。

不是所有知识都适合先被切碎，再靠相似度拼回来。

有些文档天生就是按目录、章节、小节、表格、脚注、附录组织的。你把它先打散，再问"哪段最像问题"，在很多高价值场景里，其实已经输了一半。

我最近一直在认真看一条路线：结构化推理检索 。

有人叫它 tree-based retrieval，有人叫 reasoning-based retrieval，也有人直接打出 vectorless RAG 的旗号。名字不重要，重要的是它背后的判断很清楚：

不要上来就问"哪段最像"，而是先问"答案更可能藏在哪一层、哪一节、哪一页"。

这篇文章不再停留在概念层，而是直接往工程落地走，重点回答五个问题：

这套架构到底长什么样？
模块应该怎么拆？
哪些地方最容易翻车？
怎么评测它不是"看着很聪明、线上很脆"？
如果只给你一周时间，怎么做一个真的能跑的 demo？

一、我们到底在替换什么？

先说一个特别容易误解的点。

这套方案不是在说：

向量库没用了，以后全部换成树搜索。

我不这么看。

更准确的说法应该是：

我们不是在替换"检索"这件事，而是在替换"默认把文档看成扁平 chunk 集合"的习惯。

传统 RAG 的默认假设是：

文档可以被切成一堆相互独立的 chunk
chunk 之间的结构关系不那么重要
query 和 chunk 的语义相似度，足以代表"答案是不是在那里"

这个假设在 FAQ、客服知识库、内部 Wiki 搜索这种场景下非常好用。

但在长文档、强结构、低容错场景里，它经常不成立。

微软在 GraphRAG 文档里把这个问题说得很直接：baseline RAG 擅长局部片段匹配，但在两类问题上容易掉链子，一类是 connect the dots ，也就是答案分散在多处，需要连点成线；另一类是 holistic understanding，也就是需要理解整体结构和抽象概念的问题。

换句话说，传统 RAG 最大的短板不是"找不到相关句子"，而是：

它对"文档结构本身也是信息"这件事，天然不够敏感。

二、把最小闭环先讲清楚：这套方案到底怎么工作？

如果把这套东西说得足够朴素，它其实就是把"人翻目录找答案"这件事程序化。

你想想自己是怎么在一本教材里找内容的：

你不会从第一页看到最后一页。

你也不会把全书切成 500 段，然后逐段比较哪一段和问题最像。

你会先看目录，先判断大概属于哪一章，再定位到哪个小节，最后才认真读原文。

结构化推理检索，本质上就是在模拟这个过程。

一个最小可运行闭环，大概只有五步：

1）先把文档变成树

不是按固定 token 长度一刀切，而是先按章节、小节、子节组织成层级树：

根节点：整份文档
中间节点：section / subsection
叶子节点：足够小、可以直接拿来回答问题的原文片段

2）自底向上生成摘要

叶子节点基于原文生成 summary；

父节点不直接看原文，而是基于所有孩子节点的 summary，再生成更高层的 summary。

最后整棵树上的每个节点，都有一个能代表"这一支主要在讲什么"的摘要。

3）把索引持久化

最简单的方式就是序列化成 JSON。

实际工程里当然不建议只靠 JSON，但对 demo 来说，它足够把闭环跑通。

4）查询时不是 top-k，而是沿树往下走

query 进来后，不再是：

做 embedding，然后去全库 top-k

而是：

从根节点开始，看这一层有哪些 children，根据它们的摘要，判断下一步更该往哪一支走

模型就这样一层一层往下，直到走到足够具体的叶子节点。

5）把叶子原文拿给回答模型

最终回答阶段，模型拿到的不是一堆全局检索出来的散块，而是一个通过结构路由筛出来的局部上下文。

如果只看表面，这好像只是"换了一种索引形式"。

但它真正改变的，其实不是索引，而是检索本身的性质。

传统 RAG 问的是：

哪个 chunk 和 query 更像？

这类方案问的是：

如果答案在这份文档里，下一步最应该往哪边走？

这不是一个实现细节上的小改动。

这是把 retrieval 从"近邻搜索"改成了"路径决策"。

三、为什么这条路不是异想天开，而是刚好踩在行业主线上？

如果只盯着某个项目名字，比如 PageIndex，很容易误以为这是个突然冒出来的新概念。其实不是。

把时间线拉开看，过去两年，RAG 一直在朝同一个方向缓慢但坚定地移动：

从扁平 chunk 检索，走向结构化、多层级、带路径感的检索。

1）RAPTOR：先把"树"引进检索

RAPTOR 的核心思想是：别只在底层 chunk 上检索，而是对文本块递归聚类和摘要，形成一棵多层级树，再在棵多层级树，再在不同抽象层级上一起检索。论文里给出的结果很亮眼：在需要复杂推理的 QuALITY 任务上，RAPTOR 配合 GPT-4，能把当时最佳结果再提升 20 个点search3

RAPTOR 真正重要的地方，不是某个数字，而是它第一次把一个观念立住了：

检索对象不一定非得是最底层文本，也可以是更高层级的语义节点。

2）GraphRAG：再把"结构语义层"引进来

微软走的不是树，而是图。它先从语料里抽实体、关系和 claim，再构建社区层次结构和自底向上的 summary，最后在 query time 用这些结构增强回答。形式不同，但底层判断一致：

扁平 snippet 不够，必须给检索一个更接近知识组织search4

3）LATTICE：开始认真研究"怎么让 LLM 稳定地走树"

LATTICE 更进一步，它不再满足于"有一棵树"，而是专门解决另一个更现实的问题：

如果让 LLM 在树上做导航，怎么才能让它稳定地走对？

论文的关键结论很直接：LLM 的局部 relevance judgment 是有噪声的，所以不能只做最朴素的 greedy search，而要做路径相关性校准。它在 BRIGHT benchmark 上报告的结果是，Recall@100 提升 9%，nDCG@10search5

你把这几条线放在一起看，会发现一个很清楚的趋势：

RAPTOR 先把树引进检索
GraphRAG 把结构语义层引进检索
LATTICE 开始把"让模型走结构"这件事做成一个严肃的问题

所以我现在看这类结构化推理检索，并不会觉得它只是一个新玩具。

它更像是 RAG 走到今天之后，很自然会长出来的一步。

四、真正能上线的架构，应该长什么样？

如果只是做 demo，最简单的结构当然是：

文档进来 → LLM 切树 → LLM 做摘要 → 存 JSON → 查询时逐层选 child → 叶子回答

但如果你真想上线，我不建议照这个结构直接做。

因为 demo 的问题不是"方向不对"，而是少了太多工程护栏。

我更推荐下面这种生产化架构。

这张图里，最重要的不是"树"本身，而是我故意多加出来的五个模块：

Structure Parser
Node Enricher
Beam Search Traversal
Fallback Retrieval
Evidence Pack Builder

因为真正的生产问题，恰恰都出在这五个地方。

五、模块拆分：每个模块到底该干什么？

1. Structure Parser：别让 LLM 当主解析器

这是整套系统里最容易被低估、但最该先重视的部分。

很多 demo 都默认文档很规整：有标题、有段落、有层级，切起来像教科书一样顺滑。现实不是这样。PDF 可能标题层级丢失，多栏布局可能 OCR 成一条，表格会跨页，页脚会混进正文，图表标题和段落可能交错在一起。

所以生产版系统里，第一原则不是"让 LLM 自己切树"，而是：

先尽可能吃文档原生结构，LLM 只补语义，不主导版面解析。

这个模块的输出不应该只是原始文本，而应该是一个规范化文档模型，至少包含：

标题层级
页码范围
段落块
表格块
图表块
列表项
脚注
原始文本 span

简单说，先把文档还原成"有位置感的内容单元"，再往后做树。

2. Tree Builder：树不是越深越好，而是要"刚好够用"

很多人一看到"层级检索"，就会下意识把树做得很深。

我反而建议，第一版别贪深。

对于大多数单文档问答，两层到三层已经够用了：

root
section
subsection / leaf

原因很简单。树太浅，定位不够细；树太深，query-time traversal 会变慢，而且每多一层就多一次路由出错的机会。

第一版建议加两个规则：

规则一：节点粒度不要只看字数，还要看结构边界。

一个 500 字的表格说明，可能比 1500 字的普通段落更应该单独成节点。

规则二：叶子不要只存 content，要存完整 path。

json 复制代码

{
  "node_id": "sec_2_3",
  "path": ["Risk Factors", "Supply Chain", "Semiconductor Dependence"],
  "page_start": 47,
  "page_end": 48,
  "content": "...",
  "parent_id": "sec_2"
}

这样 query-time 不只是拿内容，还能拿位置和层级。

3. Node Enricher：不要只有 summary

如果节点上只有 title + content + summary，系统会很脆。

因为 query-time 路由几乎全押在 summary 上，而 summary 本质是压缩过的信息，天然会丢细节。

所以节点至少还应该补一批结构化特征：

keyword_set
named_entities
数值范围
时间表达式
表头
单位
页码区间
heading path
sibling titles

这样做的目的不是让它立刻变成知识图谱，而是给 query-time 更多"低成本、可对齐"的信号。

我通常会把 summary 拆成三种：

routing_summary：给路由模型看，短、概括、强调主题边界
answer_summary：给回答模型看，强调事实和限定条件
citation_summary：给审计和溯源看，强调页码、章节和原文位置

一句话：

路由信息和回答信息，不应该共用同一份摘要。

4. Summary Builder：摘要要自底向上，但别把内容越压越空

这类系统通常会做标准的 bottom-up summary：叶子先总结，父节点再根据子摘要继续总结。这个方向没问题。

问题在于，生产里要防两种坏事：

第一种坏事，越往上越空泛 。

到了根节点，最后只剩"这份文档主要讨论收入、风险和战略"，这种东西拿来路由几乎没用。

第二种坏事，关键限制条件在摘要过程中被抹掉 。

尤其是财报、合同、政策场景，很多真正决定答案对不对的，恰恰是一些 caveat。

所以 Summary Builder 最好做成两阶段：

阶段 A：Extractive hints

先抽关键句、关键字段、表头、实体。

阶段 B：Abstractive summary

再生成自然语言摘要，但要求模型必须保留限定条件。

这样摘要不会完全漂在空中。

5. Index Store：别只存 JSON

对 demo 来说，JSON 很方便。

但只要你开始考虑下面这些问题：

多文档
增量更新
节点过滤
路径查询
trace 回放

你就会发现，纯 JSON 很快不够用。

第一版工程系统至少建议拆成两层存储：

对象存储层

存：

原文
分页文本
表格抽取结果
OCR 结果
图像和附件

索引存储层

存：

节点元数据
树结构
摘要
特征
引用路径
版本号

最简单的落地方式可以是：

文本 / 对象：本地文件系统或对象存储
索引元数据：SQLite / PostgreSQL
缓存：Redis
trace：日志或时序库

这里不一定要上很重的 infra，关键是把"内容"和"索引"分开。

六、查询阶段怎么做，决定了它到底是玩具还是系统

很多人觉得"这套方法的重点在索引构建"。

我反而觉得，真正决定工程质量的是 query-time。

因为 demo 之所以看起来好用，是因为它把查询阶段做得太理想化了。

1. 先做 Query Rewriter，而不是直接拿原问题走树

用户的原始问题常常很脏：

口语化
带指代
混有多个约束
没说清到底要事实、解释还是对比

所以 query-time 第一步，我建议先做轻量 query rewrite，把问题拆成三件事：

查询意图：lookup / compare / explain / summarize
关键实体：公司名、产品名、年份、条款号
路由提示：更像应该去哪类章节

例如：

"为什么这家公司去年毛利率掉了？"

rewrite 后可以变成：

json 复制代码

{
  "intent": "explain",
  "entities": ["gross margin", "year-over-year"],
  "route_hints": ["management discussion", "cost of revenue", "risk factors"]
}

这一步会显著改善 traversal 的稳定性。

2. 不要做单路 greedy，至少上 beam search

这是最想强调的一点。

最小 demo 每层只选一个 child，这在教学上很直观，但工程上太脆。

LATTICE 那篇论文真正有价值的地方，就是它明确指出：LLM 的局部 relevance judgment 是 noisy 的，所以不能把每一步选择search5

所以生产里至少要这样做：

每层保留 top-2 或 top-3 child
累计 path score
加 depth penalty / breadth penalty
低置信度触发 fallback

一个非常简单但够用的打分式子可以是：

<math xmlns="http://www.w3.org/1998/Math/MathML"> p a t h s c o r e = Σ ( r o u t e s c o r e i ∗ d e p t h w e i g h t i ) − o v e r l a p p e n a l t y − u n c e r t a i n t y p e n a l t y path_score = Σ(route_score_i * depth_weight_i) - overlap_penalty - uncertainty_penalty </math>pathscore=Σ(routescorei∗depthweighti)−overlappenalty−uncertaintypenalty

第一版甚至不用训练，就能跑起来。

3. 一定要有 Fallback Retrieval

任何单一路径策略，最终都得有兜底。

树搜索也一样。

尤其下面这些场景，纯树路由很容易失手：

用户问题包含精确术语，但 summary 没保留
表格节点语义太稀疏
标题起得很烂
答案横跨多个 sibling
query 更像 keyword lookup，而不是 semantic routing

所以我建议 query-time 至少准备三种 fallback：

metadata filter

按年份、章节、文档类型、页码范围过滤。

keyword / BM25 fallback

专打精确术语、条款号、表头、数值问答。

vector fallback（可选）

但别全库上 dense retrieval。

更合理的方式是：

先靠树把范围缩小，再在局部范围内允许 BM25 / 向量 / 正则检索补救。

这才是更现实的 hybrid。

4. 不要只返回一个叶子，返回一个 Evidence Pack

很多专业问题天然不是单段可答。

FinanceBench 这类长文档问答基准，本身就是为了测这种能力而建的：它包含 10,231 个问题，每个问题都有对应 evidence string，作者也明确指出，单纯依赖 long-context stuffing 在企业场景里会遇到 latencysearch8

所以 query-time 的理想输出，不应该只是：

命中这个 leaf 了。

而应该是：

json 复制代码

{
  "primary_leaf": "...",
  "parent_summary": "...",
  "supporting_siblings": ["...", "..."],
  "related_tables": ["..."],
  "page_spans": [47, 48],
  "path_trace": ["Risk Factors", "Supply Chain", "Semiconductor Dependence"]
}

也就是一个 evidence pack。

最后再由 answer model 去做 grounded synthesis。

这一步的好处很大：

更稳
更容易做 citation
更方便回放错误路径
更适合多跳问题

七、给一套真正能跑的模块拆分

如果今天就起 repo，我会这么拆：

javascript 复制代码

rag-tree/
├── app/
│   ├── api/
│   │   ├── ask.py
│   │   ├── ingest.py
│   │   └── eval.py
│   ├── core/
│   │   ├── config.py
│   │   ├── models.py
│   │   └── logging.py
│   ├── parsing/
│   │   ├── loader.py
│   │   ├── structure_parser.py
│   │   └── canonicalizer.py
│   ├── indexing/
│   │   ├── tree_builder.py
│   │   ├── enrichers.py
│   │   ├── summarizer.py
│   │   └── storage.py
│   ├── retrieval/
│   │   ├── query_rewriter.py
│   │   ├── router.py
│   │   ├── beam_search.py
│   │   ├── fallback.py
│   │   └── evidence_pack.py
│   ├── generation/
│   │   ├── answerer.py
│   │   └── citation_checker.py
│   └── eval/
│       ├── metrics.py
│       ├── datasets.py
│       └── judge.py
├── data/
├── scripts/
│   ├── build_index.py
│   ├── run_demo.py
│   └── run_eval.py
├── tests/
├── index.db
└── README.md

这个结构背后的设计原则很简单：

parsing 负责把文档读对
indexing 负责把结构建对
retrieval 负责把路径走对
generation 负责把答案说对
eval 负责告诉你到底哪一层错了

这样系统出了问题，才好定位。

八、实现建议：第一版怎么做，第二版怎么升级

第一版：先把闭环跑通

如果你想一周内做个 demo，我建议功能先收敛到这些：

输入只支持 markdown / txt / 简单 PDF
树深固定为 2 层或 3 层
只做单文档问答
节点字段保留 title/content/summary/path/page_range
traversal 用 beam_size=2
fallback 先只做 BM25
answer 阶段输出引用页码
CLI + 一个最简单的 FastAPI 接口

这个版本不求"聪明"，求的是能稳定跑完 ingest → index → ask → eval 的闭环。

第二版：加工程护栏

当第一版能跑后，再补这些能力：

OCR / 复杂 PDF 版面处理
表格节点单独建模
query rewrite
routing_summary / answer_summary 分离
path trace 可视化
缓存
批量评测
多文档索引
权限控制

到了这一步，系统才开始从"能跑"往"能用"走。

第三版：再考虑和主流 RAG 融合

这一步我反而建议别太早做。

等前两版稳定后，再加：

局部向量 fallback
reranker
graph-style cross-node expansion
agentic query decomposition

这时候你做出来的，就不是一个纯粹的 vectorless demo 了，而是一套更现实的 structure-first hybrid RAG。

这也是我更认同的方向。

因为今天主流世界并没有抛弃向量检索。OpenAI 的托管文件检索还是 vector store 路线；Anthropic 的优化也是在 retrieval 体系内部演进，而search1

九、评测怎么做，才能知道系统不是"看起来很聪明"

RAG 项目最常见的问题之一，就是最后只看 answer accuracy。

但这对树式检索尤其不够。

因为一个答案错了，可能错在四个不同层次：

路径一开始就走歪了
路径大体对，但 evidence pack 不完整
证据到了，但 answer synthesis 出错
答案看着像对，实际 claim 对不回原文

所以评测必须拆层。

第一层：Path Metrics

这是树式检索独有、也最应该重点看的指标。

Path Exact Match：模型走的路径是否和标注路径一致
Path Prefix Accuracy：前 n 层是否走对
Branch Recall@k：gold node 是否出现在 beam 中
Traversal Steps：平均走了几层
Fallback Rate：多少请求触发 fallback

这层告诉你：

系统到底是"走歪了"，还是"最后回答没组织好"。

第二层：Evidence Metrics

Leaf Hit Rate：是否召回 gold leaf
Evidence Recall@k：gold evidence 是否出现在 evidence pack
Citation Coverage：答案里的 claim 有多少能指回节点 / 页码
Table Hit Rate：表格问题是否召回表格节点

这层特别关键，因为很多看起来"答对"的系统，实际证据召回是错的，只是模型猜对了。

第三层：Answer Metrics

answer relevance
completeness
grounded faithfulness
numeric exactness

RAGVUE 这类新评估框架的价值，就在于它把 RAG 不再只看成一个 answer score，而是拆成 retrieval quality、answer relevance & completeness、claim-level faithfulness、judge calibsearch9

你完全可以照这个思路，为树式检索做一版更细的内部评测。

第四层：Ops Metrics

这一层很多文章不写，但线上最要命。

ingest latency
index build time
query p50 / p95 latency
tokens per query
cache hit rate
index size
cost per 1000 queries

长上下文模型今天已经能支持 1M token 级别，Google 官方文档也在强调 long-context 的能力；Anthropic 则把"context engineering"提到了更高优先级，强调真正重要的是如何组织上下文，而不是search7

所以你在评测里一定要把一个问题问清楚：

这套结构化检索，相比直接长上下文塞入，真的更省、更稳、更可控吗？

如果这个问题答不清，方案就还没站住。

十、给一个"本周末就能开工"的可运行 demo 设计

如果你今天就想做，我建议别上来挑战"全功能 PageIndex"。

先做一个足够小，但工程闭环完整的 demo。

Demo 目标

做一个单文档问答系统，支持：

ingest 一份 markdown / txt / 简单 PDF
构建 2 层树索引
生成节点摘要
查询时用 beam search 走树
fallback 到 BM25
输出答案 + 节点路径 + 页码
跑一组小型评测

Demo 技术选型

后端：Python + FastAPI
存储：SQLite
缓存：本地内存或 Redis
评测：JSONL 格式小数据集
前端：先不用，CLI + Swagger 就够

Demo 数据集

第一版别上太复杂的企业文档，先拿 3 类样本：

一份产品手册
一份财报节选
一份政策文件

每类自己写 10--20 个问答，手工标 gold node 和 gold evidence。

总共 30--50 条，就够你看到系统的真问题了。

Demo 的 6 个核心脚本

bash 复制代码

python scripts/ingest.py --input data/annual_report.md
python scripts/build_index.py --doc-id annual_report
python scripts/run_demo.py --doc-id annual_report --query "What drove gross margin decline?"
python scripts/inspect_path.py --trace-id xxx
python scripts/run_eval.py --dataset data/eval/finance_eval.jsonl
python scripts/report.py --run-id latest

Demo 的 4 个关键接口

bash 复制代码

POST /ingest
POST /build_index
POST /ask
POST /eval

Demo 最少要保留的 trace

每次查询，至少保留这些字段：

json 复制代码

{
  "query": "...",
  "rewritten_query": "...",
  "candidate_paths": [
    {"path": ["root", "Risk Factors"], "score": 0.82},
    {"path": ["root", "MD&A"], "score": 0.76}
  ],
  "selected_path": ["root", "MD&A", "Margins"],
  "fallback_used": true,
  "evidence_nodes": ["sec_2_3", "table_7", "sec_2_2"],
  "final_answer": "...",
  "citations": [{"node_id": "sec_2_3", "page": 47}]
}

为什么 trace 这么重要？

因为树式检索最大的优势之一就是路径可解释 。

如果你不把路径存下来，那这个优势就白白浪费了。

十一、我会怎么给这条路线下最终判断？

如果只站在"概念新不新"的角度，这条路当然很吸引人。

但如果站在工程视角，我更愿意把它总结成一句更冷静的话：

它最重要的价值，不是"去向量库"，而是"让检索重新尊重文档结构"。

这是两回事。

向量检索不会消失。

OpenAI 的 file search 还在走 vector store 路线。

Anthropic 也在继续优化 retrieval，而不是宣布 retriesearch1

但与此同时，另一条趋势也已经很清楚了：

RAPTOR 在把树引进检索
GraphRAG 在把图引进检索
LATTICE 在把 LLM 导航树做成更严肃的检索问题
Anthropic 在强调 context engineering
长上下文模型在变强，但并没有自动消灭"怎么组织上下文search7

所以我现在真正认可的，不是"纯血 vectorless RAG"这个标签，而是这条更现实的路线：

Structure-first, hybrid, reasoning-aware retrieval

也就是：

先保住文档结构
再让模型顺着结构导航
出错时允许 keyword / BM25 / vector 补救
最后按 evidence pack，而不是单 leaf，交给回答模型

如果你问我，这条路值不值得做？

我的答案是：非常值得。

但前提是，别把它当一个"更酷的 demo"，而是把它当一套真正的检索系统来设计。

结语

过去很多 RAG 系统，其实是在把知识处理成一种最方便机器算相似度的形式。这个方向没有错，它也确实带来了巨大的工程红利：简单、成熟、扩展性强。

但现在越来越多高价值场景在逼着我们承认另一件事：

不是所有知识都适合先碎片化，再向量化。

有些知识，本来就应该先被组织，再被检索。

有些问题，本来就不是"找最像的句子"，而是"顺着结构找到真正该看的那一节"。

有些检索，本来就不是数学近邻，而是带路径感的判断过程。

从这个意义上说，我并不觉得结构化推理检索在"颠覆 RAG"。

它更像是在纠偏。

它提醒大家，RAG 如果继续往前走，检索层迟早会从"扁平 chunk 搜索"走向"结构化导航 + 推理路由 + 多级证据组织"。

这件事，值得继续看。

如果你愿意，我下一步可以直接继续帮你做一版更适合掘金发布的标题、摘要、封面文案、结尾引导语。