如果你还在用”切块→嵌入→向量库→相似度搜索”的 RAG 流程，PageIndex 可能是今年最重要的 wake-up call。
痛点
传统 RAG 流程的每一步都在丢信息：
- 切块（Chunking）：把连贯文档切成碎片，上下文关系断裂
- 嵌入（Embedding）：语义压缩成固定维度向量，细节丢失
- 向量库检索：基于余弦相似度召回，但”相似”不等于”相关”
- 拼接上下文：把碎片塞进 prompt，LLM 需要自己拼凑完整含义
PageIndex 的思路是：为什么不让 LLM 像人类一样，按结构浏览整份文档？
PageIndex 方案
PageIndex 的核心机制是文档树索引：
- 对文档构建层次化树结构（章节→段落→子段落）
- LLM 从根节点开始，逐层导航到相关叶子节点
- 每一步由 LLM 自主决定下一步走向哪个分支
- 最终只读取最相关的完整内容段，而非碎片化 chunk
这个流程完全跳过了 embedding 和向量搜索，而是让模型像翻阅书籍目录一样定位信息。
数据对比
| 维度 | 传统 RAG | PageIndex |
|---|---|---|
| 是否需要向量库 | 是（Pinecone/Milvus 等） | 否 |
| 是否需要 Embedding 模型 | 是 | 否 |
| 是否切块 | 是 | 否 |
| 是否相似度搜索 | 是 | 否 |
| FinanceBench | ~80-85% | 98.7% |
| 长文档处理 | 信息碎片化 | 保留层级结构 |
| 部署复杂度 | 多组件（embedder + vector DB + retriever） | 单组件 |
98.7% 的 FinanceBench 分数超过了所有基于向量检索的 RAG 方案。这不仅仅是边际改进，而是方法论层面的碾压。
为什么现在才出现？
PageIndex 的成功依赖两个前提条件，这两个条件在 2026 年才真正成熟：
- LLM 上下文窗口足够大：1M+ token 上下文让模型可以同时处理整棵文档树
- LLM 导航能力足够强：模型需要在树结构上做多步决策，每一步都选择正确的分支
换句话说，PageIndex 不是”不需要 LLM”，而是”需要更强的 LLM”。当模型足够聪明时，传统的 embedding 和向量搜索反而成了不必要的中间层。
上手
# 安装
pip install pageindex
# 基本用法
from pageindex import PageIndex
# 构建文档索引
index = PageIndex.from_documents([
"financial_report_2026.pdf",
"annual_summary.md"
])
# 查询（LLM 自动导航树结构）
result = index.query("2026年Q1的营收增长主要来自哪些业务线？")适用场景与限制
| 适合 | 不适合 |
|---|---|
| 长文档（百页以上的报告、手册） | 短文本集合（社交媒体帖子、简短评论） |
| 结构化文档（有明确章节层级） | 无结构文本流 |
| 金融/法律等高精度要求场景 | 需要极低延迟的实时搜索 |
| 减少基础设施依赖的团队 | 已有成熟向量库管线且表现良好的团队 |
三判断
增量：完全跳过 embedding + vector DB + chunking 的 RAG 方案此前没有大规模验证。98.7% 的 FinanceBench 分数是实打实的成绩。
噪音：目前只在 FinanceBench 上有详细数据，其他基准（如 HotpotQA、2WikiMultihopQA）的表现尚未公布。树索引的构建成本在超大规模文档集上的表现待验证。
信号：5775 赞 + 9809 收藏的 X 推文说明社区对这一方向的高度关注。当”不需要向量数据库的 RAG”成为话题中心，向量数据库厂商需要认真考虑产品定位了。