四种AI知识管理架构全面对比与务实选型

PageIndex vs 传统RAG vs Agentic RAG vs LLM Wiki：四种AI知识管理架构全面对比与务实选型

摘要： 传统RAG、PageIndex、Agentic RAG、LLM Wiki 到底选哪个？网上流传的对比表方向是对的，却有三处关键错误会误导选型。本文逐条纠错，给出修正版12维度对比、每种架构的可运行伪代码、决策树和可落地的混合架构方案，看完就能做决定。

关键词： RAG、PageIndex、Agentic RAG、LLM Wiki、知识库、向量检索、大模型应用架构

一、先说结论：四种架构没有银弹，只有代价结构不同
二、原创辨析：那张网传对比表，对在哪、错在哪
三、四种架构的原理速览：一张流程图看懂差异
四、传统RAG：最成熟的基线，远不止"向量+单轮生成"
五、PageIndex：不用向量，靠结构树+推理找答案
六、Agentic RAG：把检索变成一个会反思的智能体任务
七、LLM Wiki：把知识"编译"一次，而不是每次重新检索
八、修正版12维度全面对比表
九、选型决策：决策表、决策树与混合架构
十、中小项目落地实例：一个能直接抄的组合方案
十一、总结
参考资料、标签与专栏建议

一、先说结论：四种架构没有银弹，只有代价结构不同

做AI知识库选型，最常见的误区就是问"哪个最先进、哪个准确率最高"。这个问题本身就问错了。

四种架构的本质差异，不是先进与落后，而是把成本花在了不同的阶段：

传统RAG把成本花在查询时，每次提问都重新检索、重新拼上下文、重新推理，建库便宜、问得贵在重复劳动；
PageIndex把成本花在建树和导航推理上，用多次大模型调用换取对长文档结构的精准定位；
Agentic RAG把成本花在多轮迭代上，用延迟和Token换取复杂问题的核查能力；
LLM Wiki把成本提前花在"编译"阶段，原始资料只读一次就沉淀成结构化页面，后续查询直接读结论，省的是重复推导的钱。

所以选型的正确问法应该是三个问题：你的文档有多少、结构清不清楚、更新频不频繁？你的问题是单轮事实查询，还是需要跨文档、多步骤核查？你的知识是查完即弃，还是需要长期沉淀、越用越厚？

这三个问题答完，选型答案基本就出来了。后文所有对比，都围绕这三个问题展开。

另一个必须先立住的结论：四者不是四选一。 生产环境里真正跑得稳的系统，绝大多数是混合架构------底层用传统RAG保召回，上层用Agentic做核查，核心长文档用PageIndex精查，高频结论沉淀成Wiki。把它们当竞品站队，是初学者最容易踩的坑。

二、原创辨析：那张网传对比表，对在哪、错在哪

最近一张"10维度对比四种知识管理架构"的表格在技术圈流传很广，很多人直接截图收藏当选型依据。我的评价是：大方向正确，适合做启蒙，综合约75分；但如果直接拿它做工程决策，会在三个地方被带偏。 这一节先把账算清楚，后面的修正版对比表就是在此基础上重做的。

2.1 说对了什么

第一，四种架构的核心机制概括基本准确。 传统RAG是向量相似度检索加单轮生成，PageIndex是结构树推理加导航式检索，Agentic RAG是代理规划加多轮迭代，LLM Wiki是离线编译加结构化查询------这四行没有原则性错误。

第二，延迟与成本的排序是对的。 传统RAG最快最便宜，PageIndex每次查询需要多次大模型调用、通常在3～8秒量级，Agentic RAG多轮迭代最慢最贵，复杂问题从数秒到数十秒不等。这个权衡是真实存在的，不是营销话术。

第三，也是全表最有价值的一句批注，是给LLM Wiki精度栏写的那句话------"存在有损压缩与幻觉固化"。这一点很多吹捧LLM Wiki的文章都刻意不提：编译阶段大模型如果写错了、过度概括了，错误会被白纸黑字写进Wiki页面，后续所有查询都会把它当事实引用，错一次、错一片，而且比原始文档里的错误更难发现。能把这句话写进对比表，说明原作者是懂行的。

2.2 三处必须修正的错误

错误一：把传统RAG和Agentic RAG的事前构建成本写成"无"。

错。传统RAG同样要做文档解析、切分、Embedding、建向量索引，还要调切分粒度、重叠长度、索引更新策略，只是这笔成本相对低。Agentic RAG更不是凭空运行的，它通常就站在传统RAG的那套索引之上，再叠加代理规划逻辑。把"低"写成"无"，会让团队在立项时低估传统RAG的运维投入------切分参数调不好、索引不更新，再好的模型也救不回来。

错误二：把LLM Wiki的查询Token写成"≈0"。

这是最容易误导人的一处。LLM Wiki省掉的，是重复阅读原文、重复跨文档推导的成本，而不是查询本身的成本。只要你是用自然语言向AI提问，它仍然要读取相关的Wiki页面和索引、组织上下文、生成答案，这部分Token一分不少。只有一种情况接近零：人自己打开Wiki页面直接阅读，不经过大模型。把"省重复推导"偷换成"查询免费"，预算做到一半就会爆。

错误三：它对比的"传统RAG"是2020年的朴素版。

原表说传统RAG精度"中"、多轮能力"弱"、相似不等于相关。这只对最原始的"纯向量检索+Top-K直塞"成立。今天生产环境里的传统RAG，标配早已是混合检索（向量+BM25关键词）+ Rerank重排序 + 查询改写：向量负责语义召回，BM25负责产品编号、错误码、人名等精确匹配，两路结果用RRF等方式融合后，再用Cross-Encoder重排。业界公开的生产经验显示，仅混合检索一项就能在典型企业数据集上提升约15%～25%的召回，Rerank又能再把Top-K精度拉高一截。用2020年的朴素版去和2025年之后的新架构比，传统RAG当然显得笨------这是田忌赛马式的对比，不公平，也不符合工程现实。

2.3 还漏了两个选型最要命的维度

除三处错误外，原表还漏了两个维度，而这两个维度恰恰是企业选型真正卡住的地方：

一是增量更新成本。知识库不是建完就不动了。新文档进来要花多大代价？传统RAG只需给新文档切分、向量化、追加索引，成本最低；LLM Wiki则可能因为一份新资料，要联动修改十几个已有页面，还要检查新旧结论是否矛盾，成本最高。更新越频繁，这个差距越致命。

二是跨文档检索能力。问题答案分散在几十份文档里时怎么办？传统RAG和Agentic RAG天生是面向全库检索的，PageIndex则擅长在单篇长文档内部钻深，跨大量文档时建树成本和导航范围都会失控。只看单文档精度、不看跨文档能力，选型必然翻车。

这两维，我已经补进第八节的修正版12维度表里。

三、四种架构的原理速览：一张流程图看懂差异

在逐个拆解之前，先用一张流程图建立整体印象。四种架构要解决的是同一个问题------让大模型基于你的私有资料准确回答------但"找资料"这一步的做法完全不同。
#mermaid-svg-nZ3qFw1Bvpk9XZ2L{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .error-icon{fill:#552222;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .marker{fill:#333333;stroke:#333333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .marker.cross{stroke:#333333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L p{margin:0;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .cluster-label text{fill:#333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .cluster-label span{color:#333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .cluster-label span p{background-color:transparent;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .label text,#mermaid-svg-nZ3qFw1Bvpk9XZ2L span{fill:#333;color:#333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node rect,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node circle,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node ellipse,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node polygon,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .rough-node .label text,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node .label text,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .image-shape .label,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .icon-shape .label{text-anchor:middle;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .rough-node .label,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node .label,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .image-shape .label,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .icon-shape .label{text-align:center;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node.clickable{cursor:pointer;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .arrowheadPath{fill:#333333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .cluster text{fill:#333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .cluster span{color:#333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L rect.text{fill:none;stroke-width:0;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .icon-shape,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .icon-shape p,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .icon-shape .label rect,#mermaid-svg-nZ3qFw1Bvpk9XZ2L .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-nZ3qFw1Bvpk9XZ2L :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} LLM Wiki：先编译
好答案回填
原始资料 raw/
LLM离线编译
互链Markdown Wiki
用户提问
读Wiki页面+索引 → 生成
Agentic RAG：派任务
不够，换个查法
够了
用户复杂提问
代理规划：改写/拆解问题
多轮检索 + 工具调用
证据够吗？反思校验
汇总核查 → 生成
PageIndex：逛目录
长文档
构建带摘要的结构树
用户提问
LLM读树摘要，推理导航
定位章节节点 → 取原文 → 生成
传统RAG：查索引
文档切分 Chunking
Embedding 向量化
向量库索引
用户提问
混合检索 + Rerank
拼上下文 → LLM单轮生成

一句话记忆法：传统RAG像搜索引擎查卡片，PageIndex像读书先看目录再翻章节，Agentic RAG像派一个助理反复跑腿核实，LLM Wiki像先请人把所有资料编成一本百科全书、以后直接查书。

理解了这四个比喻，后面每一节的优劣其实都可由比喻推导出来：查卡片快但碎，逛目录准但只适合一本书，助理靠谱但慢且贵，百科全书查起来快但编书贵、改书更贵。

四、传统RAG：最成熟的基线，远不止"向量+单轮生成"

4.1 工作原理

传统RAG，全称检索增强生成（Retrieval-Augmented Generation），流程分建库和查询两段。

建库阶段：把文档按语义或长度切成片段（Chunk），用Embedding模型把每个片段转成向量，存入向量数据库并建近似最近邻索引，同时保留关键词索引用于混合检索。

查询阶段：把用户问题同样向量化，在库中做近邻搜索，召回一批候选片段，再经Rerank重排序取最相关的几条，拼进提示词，由大模型单轮生成答案并附引用出处。

现代生产版在此之上还有两个标配动作：查询前做查询改写 ，把口语化问题改写成更适合检索的表达；检索时做混合检索，向量与BM25并行，融合排序。这两个动作成本不高，却是朴素版与生产版的精度分水岭。

4.2 优势

延迟最低、成本最可控。 向量检索本身是毫秒级，整体耗时主要在最后一次大模型生成，适合高并发、实时交互场景。
增量更新最便宜。 新增或修改文档，只处理该文档的片段即可，不牵动全库。
跨文档检索天然支持。 索引面向全库，答案在十份还是一万份文档里，机制不变。
溯源与权限最好做。 每个片段都带来源、页码、文档权限等元数据，引用可精确到片段级，企业合规场景友好。
生态最成熟。 向量库、Embedding模型、Rerank模型、评测工具链都是现成的，招人、排障、扩容都有成熟经验。

4.3 局限

相似不等于相关。 向量检索找的是"长得像"的文本，不理解"这一段能不能回答问题"。表格被切碎、脚注与正文分离、跨章节引用时，朴素版容易召回一堆貌似相关实则答非所问的片段。混合检索和Rerank能缓解，但治不了结构丢失的根。
没有知识沉淀。 每次提问都从零检索、从零推导，同一个复杂结论问一百遍就推导一百遍，系统不会因为被问得多而变聪明。
多跳问题弱。 答案需要先查A得出中间结论、再据此查B时，单轮检索往往一步到位不了------这正是Agentic RAG要解决的问题。

4.4 典型适用场景

海量文档的单轮事实问答：企业制度库、产品帮助中心、客服知识库、内部文档搜索。文档量大、问题相对直接、更新频繁、并发高------这四条占三条，就应优先传统RAG（生产版）。

4.5 最小可运行示例

python 复制代码

# 传统RAG（现代生产版）：混合检索 + Rerank + 单轮生成（伪代码）
def build_index(documents):
    chunks = []
    for doc in documents:
        for chunk in split_by_heading(doc, max_tokens=512, overlap=0.2):
            chunks.append({"text": chunk, "source": doc.id})
    vector_index.add([embed(c["text"]) for c in chunks])  # 向量索引
    bm25_index.add([c["text"] for c in chunks])           # 关键词索引
    return chunks

def answer(question):
    q = rewrite_query(question)                    # 1. 查询改写
    vec_hits = vector_index.search(embed(q), k=50) # 2. 向量召回
    kw_hits  = bm25_index.search(q, k=50)          # 3. 关键词召回
    candidates = rrf_fusion(vec_hits, kw_hits)     # 4. 融合排序
    top = reranker.rerank(q, candidates)[:5]       # 5. 重排序取Top-5
    context = "\n\n".join(c["text"] for c in top)
    return llm.generate(f"仅依据资料回答并标注出处。\n资料：{context}\n问题：{question}")

记住这段代码的结构：真正的生产差距不在最后那行生成，而在前面五步。 只写向量检索、跳过改写/混合/Rerank的，就是前文说的朴素版。

五、PageIndex：不用向量，靠结构树+推理找答案

5.1 工作原理

PageIndex是由VectifyAI提出的无向量（Vectorless）检索方案，它对传统RAG的挑战非常直接：既然"相似不等于相关"，那就干脆不用相似度，改用推理判相关。

建库阶段：不切碎、不向量化，而是按文档自身的章节层级，把整篇文档建成一棵结构树------每个节点对应一个章节或小节，带有标题、页码范围和一段节点摘要，整棵树就像一份被大模型加工过的智能目录。

查询阶段：大模型先读树的顶层摘要，推理判断答案可能在哪几个分支，逐层下钻、缩小范围，最终定位到具体节点，再取该节点的原文生成答案。整个过程走的是"相关性推理"，不是"相似度计算"，并且天然保留了从根到叶的检索路径，答案可追溯到具体章节和页码。

5.2 优势

对结构化长文档精度突出。 财报、合同、技术手册、年报这类有明确章节、表格和附录引用的文档，正是向量切分最容易翻车、结构树最能发挥的地方。其团队公布的、基于PageIndex构建的金融问答系统Mafin 2.5，在FinanceBench金融文档问答基准上取得了98.7%的成绩，明显高于典型向量方案在同类任务上的表现。
能处理跨引用和被切碎的表格。 正文写"详见附录G"时，推理导航会顺着引用找过去；表格的表头与数据行在结构上同属一个节点，不会像切分那样被拆散。
可解释性强。 每一步下钻都有推理理由，最终答案能给出"第几章、第几节、第几页"，在金融、法务、医疗等强审计场景里，这不是加分项，而是准入条件。

5.3 局限

精度有前提，前提是文档结构清晰。 树建得好不好，取决于文档本身有没有规整的层级。扫描件、格式混乱的文档、多人拼凑的杂集，建树阶段就会出错，后面推理再强也是在错地图上导航。引用它的高精度成绩时，必须同时注明测试对象是结构规整的专业长文档。
慢且贵。 一次查询要在树上做多步推理，意味着多次大模型调用，实测延迟通常在3～8秒量级，不适合对响应速度敏感的实时问答。
不适合海量文档库。 它的战场是"少数几篇长文档查得深"，而不是"海量文档里先找对哪一篇"。文档一多，每篇都建树、每次查询都推理，成本和延迟都失控。跨库场景的正确做法是先用传统RAG粗筛出目标文档，再用PageIndex在文内精查------这正是第九节混合架构的思路。

5.4 典型适用场景

少数结构清晰的长文档精查：上市公司财报与招股书分析、长合同条款审查、设备技术手册问答、法规条文定位。共同特征是：文档不多但每篇很长、很结构化，问题要求精确到章节条款，且答错代价高、慢几秒可接受。

5.5 最小可运行示例

python 复制代码

# PageIndex：结构树构建 + LLM推理导航（伪代码）
def build_tree(document):
    # 按文档天然章节切分，每个节点生成摘要，不做向量化
    tree = parse_headings(document)  # 章 -> 节 -> 小节
    for node in tree.walk():
        node.summary = llm.summarize(node.text[:2000])
        node.page_range = (node.start_page, node.end_page)
    return tree

def tree_search(node, question, depth=0):
    # 让LLM只看本层各节点的标题+摘要，推理该往哪几个分支下钻
    prompt = f"问题：{question}\n候选章节：{[ (n.title, n.summary) for n in node.children ]}\n哪些章节可能包含答案？只返回编号。"
    picked_ids = llm.pick(prompt)
    if depth >= 3 or not picked_ids:      # 到叶子或无路可走，返回当前节点
        return [node]
    hits = []
    for n in node.children:
        if n.id in picked_ids:
            hits += tree_search(n, question, depth + 1)
    return hits

def answer(tree, question):
    nodes = tree_search(tree.root, question)
    context = "\n".join(n.full_text for n in nodes)
    cites = [(n.title, n.page_range) for n in nodes]  # 天然的章节级引用
    return llm.generate(f"依据资料回答，引用来源：{cites}\n资料：{context}\n问题：{question}")

注意这段伪代码里没有一行业务在算向量------模型的调用次数，就是它为精度付的账单。评估PageIndex时先数清楚你的文档层级有多深、问题平均要下钻几层，成本估算就八九不离十了。

六、Agentic RAG：把检索变成一个会反思的智能体任务

6.1 工作原理

Agentic RAG（智能体式RAG）不是一种新的索引，而是一种新的查询时工作方式：在传统检索之上套一个能规划、能调用工具、能自我检查的代理循环。

典型流程是：代理先分析问题，把复杂问题改写或拆解成若干子问题；为每个子问题选择检索工具（向量库、关键词搜索、数据库查询、网络搜索、计算器等）；拿到结果后做自我反思------证据够不够、是否有矛盾、是否答非所问；不够就换关键词、换数据源再查一轮；证据充分后才汇总生成，并保留完整的决策过程记录。

LangChain、LlamaIndex等主流框架都已提供Agentic RAG的标准实现范式，其共同点都是这个"规划---检索---反思---再检索"的闭环，而不是一次性的单向流水线。

6.2 优势

复杂问题准确率最高。 多跳推理、跨源核查、需要先算中间结果再继续查的问题，单轮RAG原理上就做不好，多轮迭代可以一步步逼近，这类任务上Agentic RAG的优势是结构性的。
会纠错。 第一轮检索跑偏时，反思环节能发现"召回的全是无关片段"，主动改写查询重试，而不是像单轮RAG那样拿着错资料一本正经地编答案。
可扩展到检索之外的工具。 查数据库、调API、跑计算、看实时数据，都可以挂成工具，这是纯检索架构做不到的。

6.3 局限

延迟与成本成倍上升，必须算清账。 多轮迭代意味着多次检索加多次大模型调用，复杂问题延迟可达数秒乃至数十秒，Token成本通常约为传统RAG的2～3倍，问题越复杂涨得越厉害。高并发场景下，这笔账会直接决定项目能不能上线。
技术门槛最高。 要设计规划逻辑、工具协议、终止条件、失败兜底，还要防代理陷入死循环或无限重试。调不好的Agentic系统，会比单轮RAG更慢、更贵、还不一定更准。
稳定性与可复现性差。 同一个问题两次运行，代理可能走不同的检索路径，得出略有差异的结果。强合规、强一致性要求的场景要谨慎。

一条务实建议：不要默认上Agentic。 先用生产版传统RAG跑真实问题集，只有当评测明确显示错误主要来自"多跳、跨源、需核查"这类单轮解决不了的问题时，再引入Agentic层。多数知识库的真实问题分布里，简单事实问题占大头，为少数复杂问题让全部流量都付2～3倍成本，是典型的过度设计。

6.4 典型适用场景

复杂、多步骤、跨数据源的推理任务：深度研究报告生成、多财报对比分析、故障根因排查（要串联手册、日志、工单）、法律尽调中的交叉核查、需要调用实时数据的综合问答。

6.5 最小可运行示例

python 复制代码

# Agentic RAG：规划-检索-反思迭代循环（伪代码）
def agentic_answer(question, max_rounds=4):
    plan = agent.plan(question)          # 改写 + 拆解为子问题列表
    evidence = []
    for round_no in range(max_rounds):
        for sub_q in plan.pending:
            hits = tools.dispatch(sub_q) # 按子问题类型选工具：
            # 向量检索 / BM25 / SQL / Web搜索 / 计算器
            evidence += hits
        verdict = agent.reflect(question, evidence)
        # 反思：证据是否充分？有无矛盾？还缺什么？
        if verdict.enough:
            break
        plan = agent.replan(question, evidence, verdict.missing)
        # 带着"还缺什么"进入下一轮，而不是重复同样的检索
    return agent.synthesize(question, evidence, with_trace=True)
    # with_trace：保留每轮查了什么、为何停，供审计与排障

这段循环的灵魂是reflect和replan两步：没有反思的"多查几轮"只是把单轮RAG的错误重复几遍；有了反思，系统才知道自己缺什么、下一轮该换什么查法。

七、LLM Wiki：把知识"编译"一次，而不是每次重新检索

7.1 工作原理

LLM Wiki是Andrej Karpathy在2026年4月提出并公开分享的个人知识库模式，一句话概括其思想：停止反复检索，开始一次编译（Stop retrieving, start compiling）。

它批评传统RAG的根本问题是"无积累"：每个问题都要从原始文档里重新发现知识、重新拼凑关系，问完即忘。LLM Wiki反过来，让大模型扮演"编译器兼图书管理员"：把原始资料一次性读透，编译成一个持续维护的、互相链接的Markdown Wiki，此后查询直接读已经编译好的结论页，而不是回原文里大海捞针。

其结构分三层，理解这三层就理解了整个模式：

raw层（原始资料层）： 论文、文章、代码仓库、会议纪要等原始文件，只读不改，是唯一的事实源头；
wiki层（编译产物层）： 由大模型生成和维护的页面集合------来源摘要页、概念页、实体页、综述页，页面之间用双向链接互联，矛盾点会被显式标注；
schema层（规则层）： 一份约定文件（例如放在项目说明里的规范），规定页面结构、命名、链接和更新规则，约束大模型如何当这个"图书管理员"。

社区对这套模式有个非常传神的类比：Obsidian（或任意Markdown编辑器）是IDE，大模型是程序员，Wiki是代码库。 人负责选资料、提问题、做审阅；大模型负责写页面、补链接、查矛盾、做维护。查询产生的好答案还可以回填成新页面，让知识库越用越厚------这是它区别于其他三种架构的"复利效应"。

运行上有三个核心操作：Ingest （新资料进来，读它、提炼它、更新所有受影响的页面）、Query （先查索引页定位，再读相关Wiki页作答，答案可回填）、Lint（定期体检：找矛盾、找过时结论、找孤岛页面、找缺失的交叉引用）。

7.2 优势

知识真正沉淀。 跨文档的关联、矛盾、结论在编译时就建好了，不用每次查询临时拼凑。问得越多、 ingest得越多，库越聪明。
查询时省的是重复推导的钱。 高频问题直接命中已编译的结论页，不必每次都把几万字原文塞进上下文重新读一遍（注意：省的是这部分，不是全部Token，见第二节的纠错）。
完全可读、可审、可改。 产物就是一堆Markdown文件，人能打开看、能用Git管理版本、能手动纠错，没有黑盒向量索引那种"想查错都不知道从哪查"的问题。

7.3 局限

有损压缩与幻觉固化------这是它最需要警惕的风险。 编译是概括，概括必然丢细节；更危险的是大模型在编译时写错一句，错误就以"百科词条"的权威形态沉淀下来，被后续查询反复引用。防御办法只有三个：每个Wiki结论必须保留原文出处链接；定期跑Lint查矛盾；关键页面保留人工审阅环节。
增量更新成本四者最高。 新增一份资料，可能联动更新10～15个页面（摘要页、概念页、实体页、相关综述全要改），还要处理新旧结论冲突。资料增长越快、变动越频繁，维护成本涨得越陡，这决定了它只适合中小规模。
规模天花板明显。 当页面数涨到成百上千，索引页装不进上下文、页面间一致性难以维持、一次Lint的成本也水涨船高。Karpathy本人的实践规模是百篇量级的概念文章、数十万字------这是个人与小团队知识库的甜区，不是企业全量文档库的解法。

7.4 典型适用场景

中小规模、稳定增长、需要长期沉淀的知识库：个人研究知识库（读论文攒综述）、小团队项目知识库（架构决策、故障复盘、规范沉淀）、垂直领域长期跟踪（一个行业、一类技术、一套产品的持续研究）。共同特征：资料增长可预期、问题重复度高、结论值得被写下来复用。

7.5 目录结构与流程示例

text 复制代码

my-wiki/
├── raw/                    # 第一层：原始资料，只读不改
│   ├── papers/
│   ├── articles/
│   └── meetings/
├── wiki/                   # 第二层：LLM编译维护的页面
│   ├── index.md            # 总索引：每页一行摘要，查询的入口
│   ├── sources/            # 每份原始资料一页摘要，带原文链接
│   ├── concepts/           # 概念页：互链、标注矛盾与出处
│   └── synthesis/          # 综述页：跨多份资料的编译结论
└── SCHEMA.md               # 第三层：页面结构/命名/更新规则

python 复制代码

# LLM Wiki：Ingest 与 Query 流程（伪代码）
def ingest(new_source_path):
    src = read_file(f"raw/{new_source_path}")
    summary_page = llm.write_source_summary(src)     # 生成来源摘要页
    affected = llm.plan_updates(summary_page, wiki_index())
    # 一份新资料常联动 10~15 个页面：概念页、实体页、综述页
    for page in affected:
        llm.update_page(page, new_facts=summary_page,
                        keep_citations=True,        # 强制保留原文出处
                        flag_conflicts=True)        # 与旧结论冲突必须标注
    llm.refresh_index()                              # 更新 index.md
    git_commit(f"ingest: {new_source_path}")         # 全程版本管理，可回滚

def query(question):
    pages = llm.locate(question, read_file("wiki/index.md"))
    context = [read_file(p) for p in pages]         # 读的是已编译结论，
    ans = llm.generate(question, context, cite_pages=True)  # 不是原文全集
    if is_valuable(question, ans):                  # 好答案回填成新页
        llm.file_back(question, ans)
    return ans

def lint():  # 定期体检：矛盾、过时、孤岛页、断链
    return llm.audit_wiki(check=["conflicts", "stale", "orphans", "broken_links"])

工程上最值得抄走的一条经验：把Wiki当代码库管理------用Git提交每一次编译结果。 幻觉固化之所以可怕，一半是因为无声无息；有了版本历史，哪次更新改了哪个结论、依据是哪份新资料，全都可查、可回滚，风险就从"不可控"降为"可治理"。

八、修正版12维度全面对比表

下表在流传版本10个维度的基础上，修正了三处错误（构建成本、Wiki查询Token、传统RAG的版本口径），并新增"增量更新成本"与"跨文档检索能力"两维，共12维。这也是本文建议的选型对照版本。

维度	传统RAG（现代生产版）	PageIndex	Agentic RAG	LLM Wiki
核心机制	切分+向量/关键词混合检索+单轮生成	结构树+LLM推理导航	代理规划+多轮迭代+工具调用	离线编译+结构化Wiki查询
检索方式	向量+BM25混合，Rerank重排	树搜索，逐层下钻定位节点	代理驱动的动态多源检索	从预编译Wiki页面直接读取
响应延迟	低，检索毫秒级+一次生成	较高，多步推理约3～8秒	高，多轮累积数秒至数十秒	查询低（读页），编译时一次性高
查询Token消耗	中，每请求消耗一次	中高，多步推理消耗	高，约为传统RAG的2～3倍	低，但不为0：读Wiki+生成仍消耗，省的是重复读原文与重复推导
事前构建成本	低：切分+Embedding+建索引，并非"无"	中：首次构建结构树+节点摘要	低至中：依赖传统RAG的索引，另加代理逻辑设计	高：一次性完整阅读全部语料并编译
精度/准确率	中高：混合检索+Rerank后明显高于朴素版，"相似≠相关"仅针对纯向量版	高，但前提是文档结构清晰；特定基准（如FinanceBench）表现突出	高，多轮迭代可纠错，复杂问题优势明显	中高，但存在有损压缩与幻觉固化风险
可解释性	中：可给出片段级出处，但无推理过程	强：可追溯至具体章节与检索路径	强：决策与反思过程可完整记录	强：Wiki结构清晰，可人工审阅与版本追溯
知识沉淀能力	无：每次重新检索、重新推导	中：检索路径与树结构可复用	中：决策经验可复用、沉淀	强：结构化知识可长期生长，好答案可回填
技术门槛	低：生态成熟，上手最快	中：依赖文档结构质量与树构建	高：规划、工具、终止与兜底都要设计	中：初期投入较大，规则与维护流程要立好
最佳规模	海量文档，单轮查询	结构清晰的少数长文档	复杂、多步推理任务	中小规模、稳定增长的知识库
增量更新成本（新增）	最低：新文档独立切分入索引	中：新文档单独建树即可	低：与所依赖的底层索引一致	最高：一份新资料可能联动更新10～15页并处理冲突
跨文档检索能力（新增）	强：索引面向全库	弱：强在单篇文内钻深，跨库需先粗筛	强：可跨源规划、交叉核查	中：编译时已建跨文档关联，但受规模上限约束

读表时请注意两个口径：第一，表中传统RAG按现代生产版（混合检索+Rerank+查询改写）计，拿它和朴素版比没有意义；第二，所有精度描述都是条件结论------PageIndex的高精度绑定"结构清晰的长文档"，Agentic的高精度绑定"复杂多跳问题"，脱离条件的横向排名都是耍流氓。

九、选型决策：决策表、决策树与混合架构

9.1 按场景选型决策表

你的场景	首选架构	理由
海量文档、高并发、单轮事实问答	传统RAG（生产版）	延迟与成本最可控，增量更新最便宜
少数长文档，要求精确到章节条款	PageIndex	结构导航精度高、引用可审计，慢几秒可接受
多跳推理、跨源核查、要调外部工具	Agentic RAG	单轮检索原理上解决不了，必须多轮迭代纠错
中小规模、增长稳定、结论要长期复用	LLM Wiki	知识有复利，越用越厚，查询省重复推导
文档结构混乱、扫描件为主	先治理文档，再谈架构	PageIndex建不好树，RAG切不好块，任何架构都救不了烂输入
预算极敏感、问题简单直接	传统RAG朴素版起步	先跑起来，用真实问题集评测后再决定升级哪一层

9.2 文字决策树

text 复制代码

开始选型
│
├─ 问题是否需要多步推理、跨多个来源核查、调用外部工具？
│   ├─ 是 → Agentic RAG（底层仍挂传统RAG索引，复杂流量才走代理）
│   └─ 否 ↓
│
├─ 文档规模是否"少而长"，且章节结构清晰、要求精确溯源？
│   ├─ 是 → PageIndex（财报/合同/手册类长文档精查）
│   └─ 否 ↓
│
├─ 知识是否需要长期沉淀复用，且规模中小、增长可控？
│   ├─ 是 → LLM Wiki（配出处引用+定期Lint+Git版本管理）
│   └─ 否 ↓
│
└─ 默认 → 传统RAG生产版（混合检索+Rerank+查询改写）
         这是覆盖面最广的基线，拿不准时先选它不会大错

决策树的使用顺序本身就是一条经验：先排除"必须用重武器"的情况，最后落到基线。 顺序反过来、先被新概念吸引再找理由套用，是选型翻车的最常见姿势。

9.3 混合架构：生产环境的常态

再强调一次本文最重要的工程观点：四种架构是可叠加的层次，不是互斥的选项。 一个成熟系统的典型分层是：

text 复制代码

┌──────────────────────────────────────────────┐
│  沉淀层：LLM Wiki                             │
│  高频问题结论、核查报告 → 编译成页，长期复用     │
├──────────────────────────────────────────────┤
│  核查层：Agentic RAG                          │
│  复杂/多跳/高价值问题才进入，多轮检索+反思纠错   │
├──────────────────────────────────────────────┤
│  精查层：PageIndex                            │
│  核心长文档（合同/财报/手册）文内定位到章节页码   │
├──────────────────────────────────────────────┤
│  召回层：传统RAG（混合检索+Rerank）             │
│  全库粗筛保召回，所有流量的默认入口              │
└──────────────────────────────────────────────┘

流量从下往上走：普通问题在召回层一次解决；命中核心长文档的问题转精查层定位；复杂问题升级到核查层多轮求证；核查产出的可靠结论沉淀进Wiki，下次同类问题直接命中沉淀层，不再重复付核查的钱。这个分层同时拿到了四者的长处，又让每种成本只花在值得花的流量上。

十、中小项目落地实例：一个能直接抄的组合方案

设想一个典型场景：一个十几人的技术团队，要为一个持续迭代的工业软件项目建知识库------资料包括需求文档、设计说明书（几篇上百页的长文档）、接口手册、故障复盘记录和会议纪要，总量几百份，持续增长；问题既有"某个参数在哪配置"这类速查，也有"上次那类通信故障是怎么定位的"这类需要串联多份复盘的复杂问题。

按本文的框架，落地组合如下：

第一步，先上传统RAG生产版打底（第1～2周）。 全部资料切分入混合索引，配Rerank和查询改写，先解决80%的速查类问题。这一步不要追求完美，目标是让团队先用起来，并开始收集真实问题集------没有真实问题分布，后面所有选型都是猜。

第二步，给核心长文档加PageIndex精查（第3～4周）。 设计说明书和接口手册这类长文档单独建结构树，涉及参数定义、协议细节、条款定位的问题路由到精查层，答案精确到章节。路由规则先用简单的文档类型判断即可，不必一上来就做智能分发。

第三步，把高频结论沉淀成LLM Wiki（持续进行）。 故障复盘是最值得编译的资料：每次复盘结束就执行一次Ingest，把故障现象、定位过程、根因、修复方案编译成页面，并与相关设计章节互链。三个月后，团队会发现"这类故障以前遇到过吗"这种问题，查Wiki比查任何人的记忆都快、都准。这就是知识复利的起点。配套动作一个不能少：结论页强制带原文出处，每月跑一次Lint查矛盾，全库Git管理。

第四步，Agentic只留给少数硬问题（按需开启）。 跨多次复盘、多个版本找规律的问题（例如"通信超时类故障在近三个版本里出现过几次、根因是否相同"），才走Agentic多轮核查，并把核查报告回填Wiki。这类问题一周可能只有几次，为它付2～3倍成本完全划算；反过来，让日常速查也走Agentic，就是纯浪费。

这个组合的资源分配大约是：传统RAG承载绝大部分流量、成本最低；PageIndex只管几篇核心长文档；Wiki以每周数次Ingest的节奏慢慢长；Agentic按次调用。四层加起来的总成本，通常低于"全量Agentic"或"全量重编译"的任何一种极端方案，而效果覆盖面反而最广。

最后一条避坑提醒：先评测，再叠层。 每加一层之前，用收集到的真实问题集跑一遍对比------错误到底出在召回、定位、还是推理？对症加层。没有评测就堆架构，只会堆出一个又慢又贵还说不清哪层在起作用的系统。

十一、总结

回到开头的问题：四种AI知识管理架构，到底该怎么选？

传统RAG是基线 ------别拿它的朴素版说事，混合检索、Rerank、查询改写齐备的生产版，至今仍是海量文档问答性价比最高的解；PageIndex是长文档精查的利器 ------无向量、靠结构树和推理导航，在结构清晰的专业长文档上精度与可溯源性出众，但慢、贵、且不适合海量库；Agentic RAG是复杂问题的重武器 ------多轮规划与反思换来多跳核查能力，代价是数倍的延迟与Token，只应花在值得的流量上；LLM Wiki是知识沉淀的复利账户------一次编译、长期复用，特别适合中小规模稳定增长的知识库，但必须正视有损压缩与幻觉固化，用出处引用、定期Lint和版本管理把风险关进笼子。

而真正的生产答案，往往是把四者按层叠起来用。选型选的从来不是"最先进的架构"，而是与你的文档形态、问题分布、更新频率和预算最匹配的代价结构。希望本文的纠错、对比表、决策树和落地实例，能帮你少走一段弯路。

如果这篇文章对你有帮助，欢迎点赞、收藏、关注，后续我会继续更新RAG评测与知识库工程实践系列。

参考资料

PageIndex 官方网站与技术文档（VectifyAI）：无向量、基于结构树推理的检索框架说明及FinanceBench相关结果
PageIndex 开源仓库（GitHub，VectifyAI/PageIndex）：结构树构建与树搜索的参考实现
Andrej Karpathy：《LLM Wiki》想法文件（GitHub Gist，llm-wiki.md，2026年4月）：raw / wiki / schema三层架构与Ingest、Query、Lint三操作
DAIR.AI Academy：《LLM Knowledge Bases》解读文章：对Karpathy知识库模式的架构拆解
LangChain 官方文档：Agentic RAG与代理式检索的构建范式；LlamaIndex官方文档中的Agentic RAG相关指南
Anthropic：《Contextual Retrieval》技术文章（2024年）：混合检索与重排序降低检索失败率的实测数据
Cohere Rerank、BGE Reranker等重排序模型文档：生产级RAG中Rerank环节的选型参考

说明：以上均为公开可查的官方或权威来源，读者可按名称检索原文；不同来源的基准数字测试条件不同，引用时请注明口径，不要直接横向比较。

标签与专栏建议（发布参考）

推荐标签： RAG、知识库、大模型、LLM、人工智能（可另加：PageIndex、Agentic RAG、向量数据库、AI应用架构）
推荐专栏归类： 大模型应用开发 / RAG与知识库工程实践
推荐标题备选： 《知识库选型别再被网传对比表带偏了：传统RAG、PageIndex、Agentic RAG、LLM Wiki深度纠错与实战选型》