结论先行
如果你被向量数据库的运维、embedding 调参、chunk 策略折磨过，PageIndex 确实值得一看。它砍掉了整个 embedding → 向量检索 → rerank 的链路，改为让 LLM 直接推理定位文档中的关键段落。听起来很激进，但跑下来——确实能用。
代价是延迟。向量检索毫秒级返回，PageIndex 要等 LLM 读完文档索引再做推理判断。如果你的场景能接受秒级延迟，这方案比传统 RAG 干净得多。
它到底做了什么
传统 RAG 的套路大家都熟了：
文档 → 切 chunk → embedding → 存向量库 → 用户提问 → 向量检索 → rerank → 喂给 LLM
链路长，坑多。chunk 大小怎么设？embedding 模型选哪个？向量检索的 top-k 取多少？每个环节都要调，调不好效果就拉胯。
PageIndex 的思路是：别搞 embedding 了，给文档建个结构化索引，让 LLM 自己去推理该读哪部分。
具体来说，它给文档建了一个 PageIndex——不是向量索引，而是一个带有语义层级的目录结构。检索时，LLM 先看索引，判断哪个章节/段落最相关，然后只读那部分原文。相当于让模型先"看目录再翻书"，而不是把整本书的每句话都变成向量然后做相似度匹配。
实测感受
我在一个 200 页的技术文档集上跑了测试。对比对象是标准的 LangChain + ChromaDB + BGE embedding 方案。
回答质量：PageIndex 在处理跨章节推理问题时表现更好。比如"这个 API 的认证方式和 v2 版本有什么区别"，传统 RAG 经常只捞到其中一段，PageIndex 能同时定位到两个章节的内容。这是因为索引保留了文档的层级关系，LLM 推理时能看到上下文。
延迟：这是最大的痛点。传统方案检索 + 生成大概 2-3 秒，PageIndex 的索引推理阶段就要 1-2 秒，再加上生成，整体 4-6 秒。对实时对话场景来说，体感差一截。
成本：索引推理需要额外消耗 LLM token。我用 Qwen3.6-14B 做推理模型，每次查询大概多花 2000-3000 input token。如果量大，这笔开销要考虑进去。
适合谁
- 文档型知识库：技术文档、产品手册、法律条款——这类有明确章节结构的文档，PageIndex 的优势最大。
- 对精度要求高于延迟的场景：内部知识助手、研究工具，用户等个几秒无所谓，但回答必须准。
- 被向量库运维搞烦了的团队：没有向量数据库、不用维护 embedding pipeline，部署确实简单不少。
不适合谁
- 实时对话：延迟问题短期无解，除非推理模型大幅提速。
- 非结构化数据：聊天记录、邮件、社交媒体帖子——没有清晰的层级结构，索引效果打折扣。
- 超大文档量：索引构建本身需要 LLM 参与，百万级文档的索引成本不低。
和传统 RAG 怎么选？
不用非此即彼。我的建议是：
- 小团队、文档型场景、对精度敏感 → 先试 PageIndex，部署成本低，效果好坏一试就知道
- 已有向量基础设施、对延迟敏感 → 继续用传统 RAG，没必要为了追新推翻重来
- 预算允许的话 → 两套并行，不同类型的问题路由到不同方案，这是最务实的
写在后面
PageIndex 的 star 增速很猛（一周 4500+），社区热情高。但我要泼点冷水：这个项目 284 个 commit，发布时间不算短，issue 区有 78 个未解决，说明还在快速迭代期。核心概念靠谱，但生产环境部署前，建议先在自己的数据上跑一轮对比测试。
至少，它证明了一件事：RAG 不一定非要用向量。这条路线如果走通了，整个 RAG 基础设施的玩法都要改写。
主要来源：