当 RAG 不再需要向量数据库，检索变成了一场"推理游戏"

---

一、一句话理解 PageIndex

PageIndex 是一个无向量（Vectorless）的 RAG 系统。它不用 Embedding，不用向量数据库，而是让 LLM 像人类专家翻书一样，通过文档的层级结构进行推理式检索。

---

二、传统 RAG 到底在做什么？

先回顾传统 RAG 的工作流程：

核心流程：切块 → 嵌入 → 存储 → 相似度检索 → 拼接上下文 → 生成答案

---

三、生活化类比：传统 RAG vs PageIndex

类比一：找餐厅吃饭

传统 RAG = 按"颜色"找菜

想象你走进一家餐厅，想吃"酸菜鱼"。但这家餐厅的菜单被撕成了 200 个碎片，每个碎片上写着一道菜的部分描述。你没有完整的菜单，只能把"酸菜鱼"三个字转化成一种"味觉向量"，然后在 200 个碎片中找"味道最接近"的。

结果可能找到：

• “酸汤肥牛”（酸味相似）
• “水煮鱼”（鱼相似）
• “酸辣粉”（酸味相似）

虽然都沾点边，但没有一个是你真正要的。

PageIndex = 看菜单目录点菜

而 PageIndex 就像一个经验丰富的服务员，他知道菜单的结构：

菜单
├── 凉菜
├── 热菜
│   ├── 川菜系列
│   │   ├── 酸菜鱼 ← 就是这里！
│   │   ├── 水煮鱼
│   │   └── 回锅肉
│   ├── 粤菜系列
│   └── 湘菜系列
├── 汤品
└── 主食

他会推理：“你要酸菜鱼 → 这是热菜 → 属于川菜系列 → 在第 3 页”，直接翻到对的地方。

---

类比二：在图书馆找资料

传统 RAG = 用"感觉像"来找书

你要查"美联储 2023 年的通胀监控策略"。传统 RAG 会把图书馆里所有的书都撕成几页一组的碎片，然后用"语义相似度"去找碎片。

结果可能返回：

• 某本书第 42 页提到了"通胀率从 7% 降到 4%"
• 某本书第 156 页提到了"价格压力缓和"
• 某本书第 289 页提到了"CPI 增长 2.5%"

这些碎片零散且缺乏上下文，拼不出完整的策略描述。

PageIndex = 有经验的图书管理员帮你找

PageIndex 就像一个读过所有书的图书管理员。他知道每本书的目录结构：

《2023 年度报告》
├── 货币政策
│   ├── 通胀监控        ← 管理员知道去这里
│   │   └── 2023 Q4 评估  ← 第 45-52 页
│   ├── 利率决策
│   └── 量化紧缩
├── 金融稳定
└── 监管框架

他会说：“你要的在《2023 年度报告》→ 货币政策 → 通胀监控 → 第 45-52 页，这整个章节完整讲述了你要的内容。”

---

类比三：找快递

传统 RAG = 在整个小区草坪上用金属探测器找钥匙

你的快递丢了。传统 RAG 的做法是把所有快递站的包裹都拆开，给每个物品拍一张"模糊照片"（Embedding），然后在模糊照片堆里找"看起来最像你快递"的。

PageIndex = 看物流单号，一层层追踪

PageIndex 的做法是：查物流系统 → 哪个分拣中心 → 哪辆车 → 哪个驿站 → 哪个货架。每一步都有明确的推理逻辑。

---

四、架构对比

传统 RAG 架构

PageIndex 架构

---

五、核心差异一览

---

六、技术细节对比

维度	传统 RAG (LangChain/LlamaIndex)	PageIndex
索引存储	向量数据库（Pinecone, Milvus, Chroma…）	JSON 文件（树形结构）
切块方式	固定大小 / 滑动窗口 / 递归分割	自然文档层级（章 → 节 → 小节）
检索原理	余弦相似度 / 点积	LLM 推理 + 树搜索
Embedding 费用	每个文档都需要	$0，无需 Embedding
可解释性	低（相似度分数是黑盒）	高（推理路径可追溯）
上下文保留	低（切块破坏上下文）	高（保留完整章节）
适合场景	通用文档、博客、FAQ	长篇专业文档（财报、法规、教材）
基准测试	通常 70-85%	FinanceBench 98.7%

---

七、一个完整的例子

假设我们有一份 89 页的《美联储 2023 年度报告》。

传统 RAG 的做法

问题：

• 5 个块来自文档的不同位置，缺乏连贯性
• 可能漏掉了"通胀监控"这个完整章节
• 无法知道为什么选了这 5 个块（不可解释）

PageIndex 的做法

优势：

• 返回完整的 7 页章节内容，不是零散碎片
• 推理路径清晰：报告 → 货币政策 → 通胀监控
• 精确的页码引用（pp.22-28），可验证

---

八、PageIndex 的索引生成流程

---

九、什么时候该用哪个？

简单决策指南

你的场景	推荐方案	原因
长篇财报 / 法规 / 教材	PageIndex	文档结构清晰，需要精确定位
短篇博客 / FAQ / 知识库	传统 RAG	文档结构松散，语义检索足够
多文档海量数据	传统 RAG + PageIndex 混合	先向量粗筛，再 PageIndex 精确定位
需要可解释性的场景	PageIndex	推理路径可追溯，页码可验证
实时数据流	传统 RAG	PageIndex 索引构建需要时间

---

十、代码使用示例

构建索引（仅需 3 行代码）

from pageindex import page_index

# 从 PDF 构建树形索引
result = page_index("annual_report.pdf", model="gpt-4o")

# result 结构：
# {
#   "doc_name": "annual_report.pdf",
#   "structure": [
#     {
#       "title": "Financial Stability",
#       "start_index": 21,
#       "end_index": 31,
#       "node_id": "0006",
#       "summary": "Federal Reserve's financial stability...",
#       "nodes": [...]  ← 子节点
#     }
#   ]
# }

检索阶段（推理式树搜索）

import json

# 加载索引
with open("annual_report_structure.json") as f:
    tree = json.load(f)

# LLM 推理检索（伪代码）
query = "美联储如何监控通胀？"
# 1. LLM 阅读树的顶层结构，决定进入"货币政策"分支
# 2. LLM 阅读子节点，定位到"通胀监控" (pp.22-28)
# 3. 提取第 22-28 页的完整内容作为上下文
# 4. LLM 基于完整章节生成准确答案

---

十一、总结

一句话总结：

传统 RAG 是盲人摸象——摸到什么算什么，靠"感觉相似"；
PageIndex 是庖丁解牛——先看清结构，再精准下刀。

PageIndex 代表了 RAG 技术从"统计检索"向"推理检索"的范式转变。对于结构化的长篇专业文档，它提供了更高精度、更好可解释性、更低成本的全新选择。