最近在翻 RAG 相关项目时，看到一个挺反直觉的思路，忍不住多看了几眼！
它就是——PageIndex
它做了一件不一样的事：把向量数据库，从 RAG 里彻底拿掉了
不是“少用”，也不是“可选”，而是从设计一开始就假设：检索这一步，不一定非要靠相似度
向量 RAG 的老问题
如果你平时主要在处理财报、招股书、监管文件，或者各种技术规范、专业教材，那大概率遇到过这种情况：向量检索给你的段落“看起来很像”，但一问深一点，答案却感觉总是差那么一口气
问题往往不在 embedding，而在于一个被忽略很久的事实 相似度并不等于相关性。
尤其是那些需要跨章节理解、顺着逻辑一路推下去的问题，向量 RAG 很容易把你带到一个“似是而非”的位置
PageIndex 想解决的，正是这种场景。
PageIndex 在做什么？让模型像人一样“翻书”
PageIndex 并没有去优化向量效果，也没有试图用更复杂的 chunk 策略，而是直接换了一条路走。
它从文档本身的结构出发，把整份文档整理成一个层次清晰的索引，让模型先理解目录和章节之间的关系，再一步步缩小范围，判断接下来更可能相关的部分在哪里。
整个检索过程更像是在不断做选择题：这一问更像属于哪一章？是不是应该继续往下翻？而不是在一堆零散文本里比对“像不像”。
这种设计思路受到了 AlphaGo 树搜索的启发，本质上是用推理路径来完成检索，而不是用距离来筛选文本。
为什么它在专业长文档上特别有优势？
这种基于结构和推理的方式，在面对专业长文档时优势会非常明显。
一方面，它不会把一个完整的论证过程切碎，模型拿到的上下文始终是连续、有逻辑的；另一方面，检索的每一步都有明确的来源位置，可以回溯到具体章节和页码，可解释性也更强。
官方给出的结果也很有说服力：基于 PageIndex 构建的推理型 RAG 系统，在 FinanceBench 基准测试中达到了 98.7% 的准确率，明显高于传统向量 RAG 的表现
至少在金融这种强结构、强逻辑的场景下，这条路线已经被验证过是可行的。
快速上手：三步，把文档变成“可推理的索引”
从使用角度看，PageIndex 的上手并不复杂，你可以把它理解成一个“文档理解前处理”的工具
1. 安装依赖
pip3 install --upgrade -r requirements.txt
2. 设置OpenAI API密钥
在项目根目录创建.env文件，添加：
CHATGPT_API_KEY=your_openai_key_here
3. 运行PageIndex处理PDF
python3 run_pageindex.py --pdf_path /path/to/your/document.pdf
这一步的核心不是切文本，而是让模型先读目录、理解章节关系，再生成一份可以被逐层导航和推理的索引结构。后续无论你是做问答还是做 Agent 调用，这个结构都会成为检索的基础。
如果你处理的是 Markdown 文档，也可以直接指定 --md_path，PageIndex 会按 # / ## / ### 的层级自动识别结构，这种情况下体验会更自然。
可选参数
• --model：使用的OpenAI模型（默认：gpt-4o-2024-11-20）• --toc-check-pages：检查目录的页数（默认：20）• --max-pages-per-node：每个节点的最大页数（默认：10）• --max-tokens-per-node：每个节点的最大token数（默认：20000）• --if-add-node-id：是否添加节点ID（默认：是）• --if-add-node-summary：是否添加节点摘要（默认：是）• --if-add-doc-description：是否添加文档描述（默认：是）
生成之后，可以怎么用？
PageIndex 并不会强行绑定某个具体的 RAG 框架。
你可以把生成的索引结构接进自己的 Agent 系统，也可以作为推理型 RAG 的检索层使用，甚至通过 API 或 MCP 的方式暴露给其他服务。它更像是一个文档理解底座，而不是一整套“开箱即用”的解决方案。
最后
PageIndex 并不是要否定向量 RAG。
但它清楚地提醒了一件事：当我们处理的文档足够长、足够专业时，RAG 的瓶颈往往不在 embedding，而在模型是否真正理解了文档的结构和逻辑脉络。
如果你正在折腾专业文档分析、金融或合规类 RAG，这个项目，非常值得你认真看一眼。
