RAG、LLM Wiki 与 PageIndex 三种检索范式对比三者本质上回答的是同一个问题:怎么让 LLM 用上比上

三者本质上回答的是同一个问题:怎么让 LLM 用上比上下文窗口更多的知识? 但它们给出的答案完全不同 —— 在"什么时候做工作"和"知识以什么形态存在"这两件事上分歧巨大。

一、三种范式概览

假设你有一份 300 页的年报,想问"递延资产的总价值是多少?"。

把全文切成 512 token 的小块,每块嵌入成向量。查询时把"递延资产总价值"也变成向量,从向量库里捞出余弦相似度最高的几块塞给 LLM。

问题是:向量检索假设语义上最相似的文本就是最相关的,但在专业领域这个假设经常失效。"递延资产"在文档里可能出现 50 处,但真正含答案的那段可能用的是"延期项目""未来期间收益"这类近义词,反而被埋掉。

它根本不在查询时检索原文。当你把这份年报喂进去时,系统会让 LLM 把它"消化"一遍:抽出关键实体、生成结构化的 Markdown 维基页(比如一个"递延资产"页),再把它和已有维基互链、综合、修订。

合成提示词强制一个不变量:"保留并扩展现有内容 —— 永远不丢弃页面上已有的信息"。这就是知识能复利而非覆盖的原因。下次你问问题时,模型查的是这份它自己写的、不断长大的维基,而不是原始 PDF。

它像 AlphaGo 下棋一样让 LLM 在"目录树"里搜索。PageIndex 不预先计算向量,而是构建一棵代表文档结构的"全局索引"树,节点对应章节、小节、子节。查询到来时,LLM 执行树搜索,基于查询的完整上下文,显式地把每个节点判定为相关或不相关。

回到那份年报:模型会推理"递延资产总额一般在财务摘要或附录 G 里,先去那儿看",然后逐层下钻 —— 这正是人类专家的读法。

维度	经典 RAG	LLM Wiki	PageIndex
工作时机	查询时	摄入时(重)	摄入 + 查询
知识载体	向量 + 原文块	LLM 写的 Markdown	文档结构树
数据库	向量库(Pinecone / FAISS)	文件系统 + 可选向量	关系库即可(PostgreSQL)
是否复利	否,每次从零	是,每次更新维基	否,树是只读
解释性	弱(为什么取这块?)	强(链接可追溯)	强(树搜索有审计轨迹)
摄入成本	低(只嵌入)	很高(LLM 通读 + 综合)	中(LLM 建结构)
查询成本	低	中	中
抗噪能力	弱(分块易丢上下文)	强(已综合过)	强(LLM 推理过滤)

你面对的是 变化频繁、规模庞大、查询型 的语料(客服知识库、产品文档、企业搜索)。它的工程成本最低,生态也最成熟。

你想构建的是 个人或团队长期的领域知识,源材料相对稳定、需要跨文档综合(研究笔记、行业研究、组织记忆)。它的核心价值在于"知识会复利",而不是每次重新拼图。这也是为什么 Karpathy 把它形容为"摆脱无状态 RAG"的方案。

你处理的是 长篇结构化文档 —— 财务报表、法律合同、技术规范 —— 而且 解释性和准确率比规模更重要。这个开源框架在复杂文档检索上达到了 98.7% 的准确率,完全不需要专门的向量数据库。代价是它对文档结构有要求 —— 一堆零散的微博帖子套不上这套机制。

三者并非互斥。在实际系统里,完全可以让:

三者各司其职,而不是互相替代。这才是工程现实里的常态。