RAG 跑了三年，所有人都默认了一个前提：你得先把文档切片、embedding、存进向量数据库，然后检索的时候做相似度匹配。
PageIndex 说：不用。
它的标语是「Document Index for Vectorless, Reasoning-based RAG」。无向量的、基于推理的文档索引。30.6k star，一周涨了 4300。
这个增长速度说明一件事：大家对现有 RAG 方案的不满已经积累到一定程度了。
向量数据库到底有什么问题
不是向量数据库不好用。是它在一个特定的场景下很别扭——当你的文档结构复杂、需要理解语义关系而不是简单的文本相似度时。
举个例子：你有一份 200 页的技术文档，里面有一章讲"认证流程"，另一章讲"API 权限"，还有一章讲"OAuth 集成"。用户问"怎么配置第三方登录"。
传统向量 RAG 的做法：把用户问题 embedding，跟所有文档片段的 embedding 做相似度匹配，取 top-k 个片段丢给 LLM。
问题在于：相似度匹配只能找到文本上接近的片段，但找不到逻辑上相关的片段。"第三方登录"可能在这三个章节里都有涉及，但只有"OAuth 集成"那段的 embedding 跟问题的 embedding 最接近。结果就是你拿到的是一个不完整的回答。
PageIndex 的思路是：不用 embedding 做相似度匹配，而是让 LLM 直接"推理"哪些文档片段是相关的。
它怎么做的
从代码结构看，PageIndex 有几个关键组件：
pageindex/：核心索引逻辑cookbook/：使用示例examples/：具体场景的实现
它用的是 agent-based 的检索策略——一个 agent 负责理解查询，另一个 agent 负责在文档索引中定位相关内容，不需要经过向量相似度这一层。
代码里用到了 LiteLLM 做模型路由，说明它支持多种 LLM 后端。最近的 commit 在优化 retrieve_model 的自动前缀处理，说明模型配置这块还在打磨。
性能怎么样
这是最关键的问题，也是官方文档里目前说得不够清楚的地方。
Vectorless RAG 的代价是：每次检索都要调用 LLM 做推理，而不是在向量空间里做一次近邻搜索。这意味着：
- 延迟更高：向量搜索是毫秒级的，LLM 推理是秒级的
- 成本更高：每次检索都消耗 LLM 的 token
- 并发能力差：LLM 推理是计算密集型，向量搜索是内存密集型
如果 PageIndex 不能在这些方面给出有说服力的数据，那"vectorless"就只是个营销概念。
不过从另一个角度想：如果你的 RAG 场景对延迟和成本不敏感（比如离线文档分析、研究报告生成），那 vectorless 方案可能反而更准确——因为 LLM 的理解能力确实强于 embedding 的相似度计算。
283 commits 意味着什么
这个项目有 30.6k star，但只有 283 commits。这个比例不太正常。
两种可能：要么代码量不大但概念很好所以 star 多，要么大量代码不在公开仓库里。不管哪种情况，都说明项目还远未成熟。
78 open issues，68 open PRs。社区参与度高，但核心团队的处理能力可能跟不上。
值不值得试
值得关注的场景：
- 文档结构复杂、需要跨章节关联理解的企业知识库
- 对检索准确率要求高、对延迟要求不高的离线分析任务
- 不想维护向量数据库基础设施的小团队
暂时不建议的场景：
- 高并发、低延迟的实时检索需求
- 文档量巨大（百万级以上）的场景
- 对成本敏感的生产环境
判断
Vectorless RAG 是一个有意思的方向。它本质上是在说：既然 LLM 越来越强，为什么还要用 embedding 这种有损的中间表示来做检索？直接让 LLM 理解文档不就行了？
这个问题的答案取决于 LLM 的能力增长曲线和成本下降曲线的交点在哪。目前来看，对于高价值、低并发的场景，vectorless 已经有实用价值了。但对于大规模、高频的检索，向量数据库短期内还是更务实的选择。
PageIndex 能不能把这个方向跑出来，接下来几个月的性能优化和社区反馈会给出答案。
主要来源：