知识库检索入门：从普通 RAG、知识图谱 RAG 到 LLM Wiki，一篇讲清原理、区别与选型

知识库检索 、RAG、GraphRAG、知识图谱、LLM Wiki、向量数据库、大模型应用,、AI Agent、企业知识库

---

如果你正在学习大模型应用开发，大概率会遇到这些问题：

• 大模型为什么需要知识库检索？
• 普通 RAG 是什么？它是不是只要“切文档 + 向量搜索”就够了？
• 知识图谱 RAG、GraphRAG 和普通 RAG 有什么区别？
• LLM Wiki 又是什么？它和传统向量知识库相比有什么优势？
• 企业知识库、客服问答、AI Agent 项目里到底应该选哪种方案？

本文会用初学者也能理解的方式，把 普通 RAG、知识图谱 RAG、LLM Wiki 这三类知识库检索方案讲清楚，并结合工程实践分析它们的特点、优缺点和适用场景。

flowchart LR
  A[原始知识资料] --> B{知识组织方式}
  B --> C[普通 RAG<br/>原文 Chunk + 向量检索]
  B --> D[GraphRAG<br/>实体关系 + 图谱检索]
  B --> E[LLM Wiki<br/>主题页面 + 持续沉淀]
  C --> F[适合快速文档问答]
  D --> G[适合关系链路分析]
  E --> H[适合系统学习与知识管理]

本文关键词：知识库检索、RAG、GraphRAG、知识图谱、LLM Wiki、向量数据库、AI Agent、企业知识库、大模型问答。

---

⚠️ 智能客服快速搭建开源项目推荐: AI-Agent-Node

一、为什么大模型需要知识库检索？

大语言模型本身很强，但它有几个天然限制：

1. 不知道你的私有数据
   例如公司内部文档、产品手册、业务规则、项目代码、客户工单，这些内容不在模型训练数据里。

2. 知识可能过期
   模型训练完成后，新的政策、接口文档、产品说明不会自动进入模型。

3. 容易幻觉
   当模型缺少依据时，它可能编造看似合理但并不存在的答案。

4. 上下文长度有限
   即使现在很多模型支持长上下文，也不适合每次把所有文档都塞给模型，成本高、速度慢、噪声大。

所以我们需要一个机制：

用户提问时，先从外部知识库中找出相关资料，再把这些资料交给大模型生成答案。

这就是知识库检索增强生成，也就是常说的 RAG（Retrieval-Augmented Generation，检索增强生成）。

---

二、普通 RAG：最常见的知识库检索方案

2.1 普通 RAG 是什么？

普通 RAG 的核心流程可以概括为四步：

原始文档 → 文本切分 → 向量化入库 → 用户提问时向量检索 → LLM 基于检索结果回答

flowchart TD
  A[原始文档<br/>PDF / Markdown / Word / 网页] --> B[文本清洗与切分]
  B --> C[Chunk 文本块]
  C --> D[Embedding 模型向量化]
  D --> E[(向量数据库)]
  F[用户问题] --> G[问题向量化]
  G --> E
  E --> H[TopK 相似 Chunk]
  H --> I[拼接 Prompt + 引用来源]
  I --> J[LLM 生成答案]

更具体一点：

1. 加载 .txt、.md、.pdf、.docx、.json 等文档。
2. 使用文本切分器把长文档切成多个 chunk。
3. 使用 embedding 模型把每个 chunk 转成向量。
4. 存入向量数据库，例如 FAISS、Milvus、Qdrant、Weaviate 等。
5. 用户提问时，把问题也转成向量。
6. 在向量库中查找语义最相近的 chunk。
7. 把召回内容作为上下文交给大模型生成答案。

在工程实现中，常见配置包括：

• chunkSize：每个文本块的长度，例如 500、800、1000。
• chunkOverlap：相邻文本块重叠长度，例如 100、200。
• topK：每次检索返回多少个文本块。
• embedding model：用于文本向量化的模型。
• vector database：用于存储和检索向量。

2.2 普通 RAG 的优点

普通 RAG 是最适合初学者入门的知识库方案，因为它有这些优点：

1. 架构简单，容易理解

它本质上就是：

把文档切小 → 存向量 → 问题找相似文本 → 大模型总结

不需要复杂的数据建模，也不需要维护实体、关系、图数据库。

2. 落地成本低

普通 RAG 可以很快接入企业文档、PDF、Markdown、Word、网页内容，适合快速做一个“基于文档的智能问答系统”。

3. 对非结构化文本友好

大多数企业知识都是非结构化文本，例如：

• 产品说明书
• 用户手册
• 技术文档
• 会议纪要
• FAQ
• 政策制度
• 白皮书

普通 RAG 对这类资料非常友好。

4. 工程生态成熟

LangChain、LlamaIndex、Haystack 等框架都对普通 RAG 有成熟支持，向量数据库生态也非常丰富。

2.3 普通 RAG 的缺点

普通 RAG 虽然简单，但并不是万能的。

1. 容易“只见树木，不见森林”

普通 RAG 检索的是文本块，而不是知识结构。它擅长找到局部相关内容，但不擅长回答需要全局理解的问题。

例如：

“这份白皮书里 AI Agent 的核心组件之间有什么关系？”

普通 RAG 可能召回几个分散 chunk，但它未必知道组件之间的层级、依赖和关联路径。

2. 对实体关系理解较弱

如果问题涉及多个实体之间的关系，例如：

• 某个技术属于哪个模块？
• A 公司和 B 产品是什么关系？
• 某个概念由哪些子概念组成？
• 某个故障可能由哪些组件共同导致？

普通 RAG 只能依赖 chunk 的语义相似度，不一定能稳定找出关系链。

3. 检索质量强依赖切分策略

chunk 太大：召回内容噪声多。
chunk 太小：语义不完整。
重叠太少：上下文断裂。
重叠太多：存储和检索成本上升。

普通 RAG 的效果经常卡在“切分策略”和“召回策略”上。

4. 难以长期沉淀高质量知识

普通 RAG 通常直接基于原文 chunk 检索。问答过程中产生的新知识、总结、用户反馈，不会自然形成一个可维护的知识体系。

---

三、知识图谱 RAG / GraphRAG：让知识库理解“关系”

3.1 什么是知识图谱 RAG？

知识图谱 RAG，也常被称为 GraphRAG，它不是只把文档切成 chunk，而是进一步从文档中抽取：

• 实体：例如 AI Agent、Tool、Memory、LangChain。
• 关系：例如 AI Agent -包含-> Tool、RAG -属于-> 知识检索能力。
• 证据：实体和关系来自哪些原文 chunk。

它通常会形成类似这样的结构：

AI Agent -[包含]-> Planning
AI Agent -[包含]-> Memory
AI Agent -[调用]-> Tool
RAG -[增强]-> LLM
LangChain -[支持]-> Agent 开发

图谱 RAG 的检索流程一般是：

用户问题 → 抽取问题实体 → 图数据库匹配实体 → 多跳扩展子图 → 找相关原文证据 → LLM 结合图谱和证据回答

flowchart TD
  A[用户问题] --> B[抽取问题实体]
  B --> C[(图数据库)]
  C --> D[匹配核心实体]
  D --> E[1-2 跳扩展相关实体与关系]
  E --> F[形成问题相关子图]
  F --> G[召回关系对应的原文证据]
  G --> H[图谱结构 + 原文证据]
  H --> I[LLM 生成可解释答案]

  subgraph KG[知识图谱示意]
    X[AI Agent] -->|包含| Y[Planning]
    X -->|包含| Z[Memory]
    X -->|调用| T[Tool]
    X -->|使用| R[RAG]
  end

在工程上，常见组合是：

• LLM：用于抽取实体、关系、生成答案。
• 图数据库：例如 Neo4j。
• 原文 chunk：作为可追溯证据。
• 图查询语言：例如 Cypher。

3.2 知识图谱 RAG 的优势

1. 更擅长关系型问题

如果用户问的是“谁和谁有什么关系”“某个概念由哪些部分组成”“某个技术链路如何串起来”，知识图谱 RAG 通常比普通 RAG 更稳。

例如：

“AI Agent 与大语言模型、工具调用、记忆模块之间是什么关系？”

GraphRAG 可以从 AI Agent 出发，沿着图谱边扩展，找到相关实体和关系，再结合原文证据回答。

2. 支持多跳推理

普通 RAG 多数时候是“相似文本搜索”，而图谱 RAG 可以做多跳扩展：

用户问题命中实体 A
A 关联 B
B 关联 C
C 又关联某些证据 chunk

这对复杂问答很重要。

3. 可解释性更强

GraphRAG 可以告诉你：

• 命中了哪些实体；
• 走了哪些关系；
• 使用了哪些原文证据；
• 答案依据来自哪些 chunk。

这对于企业内部知识库、风控、医疗、法律、金融等场景非常重要。

4. 适合构建领域知识网络

当知识不是孤立文本，而是概念、系统、产品、人员、组织、流程之间相互关联时，知识图谱会非常有价值。

3.3 知识图谱 RAG 的缺点

1. 构建成本更高

你需要处理：

• 实体抽取；
• 关系抽取；
• 实体归一化；
• 同义词合并；
• 图数据库建模；
• 图谱更新；
• 错误关系清洗。

这比普通 RAG 复杂很多。

2. 抽取质量依赖模型和规则

如果 LLM 抽错实体或关系，图谱里就会出现错误边。错误边一旦进入图谱，后续检索可能持续受影响。

3. 不适合所有场景

如果你的知识库只是简单 FAQ，或者用户问题大多是“某个文档里怎么说”，普通 RAG 可能已经够用，没必要上图谱。

4. 实时性和维护难度更高

文档更新后，不仅要更新 chunk，还要重新抽取实体关系、维护图谱一致性。

---

四、LLM Wiki：把碎片文档整理成“可学习、可维护的知识页面”

4.1 LLM Wiki 是什么？

LLM Wiki 可以理解为：

让大模型先把原始文档整理成结构化、主题化、概念化的 Wiki 页面，再基于这些 Wiki 页面进行检索和问答。

它和普通 RAG 最大的区别是：

• 普通 RAG 主要检索原始 chunk；
• LLM Wiki 先把原始内容加工成“知识页面”，再检索这些页面。

一个典型 LLM Wiki 构建流程是：

原始文档 → 文档切分 → LLM 提炼主题/概念 → 生成 Wiki 页面 → 页面向量化 → 检索 Wiki 页面 → LLM 回答

flowchart TD
  A[原始文档] --> B[文档切分]
  B --> C[LLM 提炼主题 / 概念 / 关键事实]
  C --> D[生成 Wiki 页面]
  D --> E[页面向量化与索引]
  E --> F[(Wiki 知识库)]
  G[用户问题] --> H[检索相关 Wiki 页面]
  F --> H
  H --> I[结构化知识页面 + 来源引用]
  I --> J[LLM 生成回答]
  J --> K{是否值得沉淀?}
  K -->|是| L[候选学习池 / 审核]
  L --> D
  K -->|否| M[仅返回答案]

Wiki 页面通常会包含：

• 标题；
• 摘要；
• 核心概念；
• 关键事实；
• 适用场景；
• 与其他概念的关系；
• 原文引用或来源；
• 后续学习沉淀内容。

4.2 LLM Wiki 与普通 RAG 的核心差异

普通 RAG 更像是“搜索原文片段”；LLM Wiki 更像是“搜索整理后的知识卡片”。

举个例子。

假设原始文档里分散出现了很多关于 AI Agent 的内容：

• 第一章讲 Agent 定义；
• 第二章讲工具调用；
• 第三章讲记忆模块；
• 第五章讲安全性；
• 第八章讲部署平台。

普通 RAG 可能召回其中几个相似 chunk。
LLM Wiki 则可以提前生成一个 AI Agent 页面，把分散内容归纳在一起。

这样用户提问：

“AI Agent 的核心能力有哪些？”

LLM Wiki 更容易直接召回一个主题完整、结构清晰的知识页面。

4.3 LLM Wiki 的优势

1. 更适合初学者学习

LLM Wiki 的页面通常比原始文档更清晰，因为它已经经过总结、归纳和重组。

对于学习型场景，例如：

• 学习一本技术书；
• 学习项目源码；
• 学习一份白皮书；
• 学习企业内部复杂业务；
• 构建 AI 学习助手；

LLM Wiki 会比直接检索原始 chunk 更友好。

2. 降低检索噪声

原始文档可能有很多无关信息，例如页眉、目录、重复描述、例子、格式噪声。LLM Wiki 可以提前把内容提炼成主题页面，让检索目标更干净。

3. 支持持续学习和知识沉淀

一个成熟的 LLM Wiki 不只是构建一次，还可以把后续问答中的高质量内容沉淀进去。

例如用户问了一个好问题，系统给出了可靠答案，就可以把这条知识写入：

• 候选学习池；
• 待审核列表；
• 正式 Wiki 页面；
• Learned Notes 区域。

这让知识库从“静态文档检索”变成“持续演进的知识系统”。

4. 更适合构建领域知识助手

如果目标不是简单查文档，而是构建一个“懂某个领域”的助手，LLM Wiki 会更接近人类学习知识的方式：

读资料 → 提炼概念 → 形成笔记 → 建立主题页面 → 持续补充 → 用来回答问题

4.4 LLM Wiki 的缺点

1. 构建成本更高

LLM Wiki 在入库前要调用大模型生成页面，成本和耗时都高于普通 RAG。

2. 可能引入总结偏差

大模型在总结原文时，可能遗漏细节、错误归纳或过度概括。所以 LLM Wiki 最好保留来源引用，并在回答时结合证据。

3. 需要治理机制

如果允许系统自动把问答结果写回 Wiki，就必须考虑：

• 不确定答案不能写入；
• 重复内容要去重；
• 低质量内容要进入候选池；
• 重要知识最好人工审核；
• 写入频率要限制；
• 需要记录学习状态。

否则 Wiki 会逐渐被脏数据污染。

4. 对工程设计要求更高

LLM Wiki 涉及：

• 文档加载；
• 文本切分；
• 页面生成；
• 页面索引；
• 向量检索；
• 学习写入；
• 候选审核；
• 去重策略；
• 缓存策略；
• 引用追踪。

它比普通 RAG 更像一个知识管理系统。

---

五、普通 RAG、知识图谱 RAG、LLM Wiki 的区别对比

维度	普通 RAG	知识图谱 RAG / GraphRAG	LLM Wiki
核心思想	检索相似文本块	检索实体关系和证据	检索整理后的知识页面
数据形态	Chunk + 向量	实体 + 关系 + Chunk	Wiki 页面 + 向量 + 来源
主要技术	文档切分、Embedding、向量库	实体抽取、关系抽取、图数据库、多跳查询	LLM 总结、概念页生成、页面索引、学习沉淀
适合问题	“这段资料里怎么说？”	“A 和 B 有什么关系？”“结构链路是什么？”	“帮我系统理解某个主题”
优点	简单、快速、成本低	关系清晰、可解释、多跳推理强	结构化、学习友好、适合长期沉淀
缺点	全局结构弱、关系理解弱	构建复杂、维护成本高	构建成本高、需要治理
初学者上手难度	低	高	中高
适合场景	FAQ、文档问答、客服知识库	金融、医疗、法律、复杂业务网络	学习助手、领域助手、企业知识沉淀
典型存储	FAISS、Milvus、Qdrant	Neo4j + 向量库	Markdown/Wiki 文件 + 向量库

---

六、用一个例子理解三者差异

假设我们有一份《AI Agent 技术白皮书》，用户问：

“AI Agent 的核心组件有哪些？它们之间是什么关系？”

6.1 普通 RAG 会怎么做？

普通 RAG 会把问题向量化，然后从向量库中找最相似的文本块。

它可能召回：

• 某个 chunk 讲 Planning；
• 某个 chunk 讲 Memory；
• 某个 chunk 讲 Tool；
• 某个 chunk 讲 RAG。

然后大模型根据这些片段总结答案。

优点是快，缺点是如果相关内容分散在很多章节，可能召回不全。

6.2 知识图谱 RAG 会怎么做？

GraphRAG 会先从问题中抽取实体，例如：

AI Agent
核心组件
关系

然后在图数据库中匹配 AI Agent，向外扩展 1 到 2 跳，找到：

AI Agent -[包含]-> Planning
AI Agent -[包含]-> Memory
AI Agent -[调用]-> Tool
AI Agent -[使用]-> RAG
Planning -[依赖]-> Reasoning
Tool -[连接]-> 外部系统

同时召回这些实体关联的原文 chunk，最后让大模型结合图谱和证据回答。

优点是关系清楚，缺点是需要提前构建图谱。

6.3 LLM Wiki 会怎么做？

LLM Wiki 在构建阶段可能已经生成了一个 AI Agent 主题页，里面整理了：

• AI Agent 的定义；
• 核心组件；
• 组件之间的关系；
• 典型架构；
• 与 LLM、RAG、Tool Use 的区别；
• 来源文档引用。

用户提问时，系统直接检索到这个主题页，再生成结构化回答。

优点是阅读体验好、主题完整，缺点是需要提前生成并维护 Wiki 页面。

---

七、如何选择：不同业务场景用哪种知识库检索方案？

可以先用一个简单决策图来判断：

flowchart TD
  A[你的主要问题是什么?] --> B{是否主要是简单事实查询或文档问答?}
  B -->|是| C[优先普通 RAG]
  B -->|否| D{是否经常问关系、链路、依赖、多跳问题?}
  D -->|是| E[考虑 GraphRAG]
  D -->|否| F{是否希望形成可学习、可维护的知识体系?}
  F -->|是| G[考虑 LLM Wiki]
  F -->|否| H[先从普通 RAG 开始]
  C --> I[优化切分、混合检索、重排序、引用]
  E --> J[建设实体关系、图谱证据、子图检索]
  G --> K[建设主题页面、候选学习、审核治理]

7.1 如果你刚入门：先做普通 RAG

普通 RAG 是最适合入门的方案。你可以先实现：

文档加载 → 文本切分 → 向量入库 → 相似度检索 → LLM 回答

适合场景：

• 企业 FAQ；
• 产品说明书问答；
• PDF 文档问答；
• 技术文档助手；
• 客服知识库；
• 内部制度查询。

如果普通 RAG 已经能满足 80% 的问题，不必一开始就上复杂架构。

7.2 如果问题经常涉及关系：考虑知识图谱 RAG

当你发现用户经常问这些问题时，可以考虑 GraphRAG：

• “A 和 B 是什么关系？”
• “某个流程涉及哪些角色和系统？”
• “某个风险会影响哪些业务？”
• “这个概念上下游有哪些？”
• “请解释某个系统的依赖链路。”

适合场景：

• 金融风控知识库；
• 医疗知识问答；
• 法律法规关系分析；
• 企业组织和流程知识库；
• 软件系统架构问答；
• 复杂产品知识网络。

7.3 如果目标是学习和知识沉淀：考虑 LLM Wiki

如果你希望系统不只是“查文档”，而是逐渐形成可读、可维护、可复用的知识体系，可以考虑 LLM Wiki。

适合场景：

• AI 学习助手；
• 代码库知识库；
• 技术书籍学习系统；
• 企业内部知识沉淀；
• 白皮书/论文解读助手；
• 长期演进的领域知识库。

---

八、工程实践建议：不要只追求架构高级，而要解决检索质量

很多初学者会觉得 GraphRAG、LLM Wiki 更高级，于是一开始就想上复杂方案。但在真实项目里，更重要的是检索质量和可维护性。

8.1 普通 RAG 优化建议

如果你在做普通 RAG，建议优先优化这些点：

1. 合理切分文档
   按标题、段落、句号、Markdown 结构切分，避免粗暴按字符切。

2. 保留元数据
   每个 chunk 应该保存来源文件、页码、标题、段落编号等信息。

3. 使用混合检索
   向量检索适合语义相似，关键词检索适合精确匹配。两者结合通常更稳。

4. 增加重排序
   先召回较多候选，再用 reranker 按相关性排序。

5. 答案必须引用来源
   让模型回答时引用 chunk 来源，降低幻觉风险。

6. 对低置信度问题明确拒答
   如果检索不到证据，应该回答“依据当前资料无法确定”。

8.2 GraphRAG 优化建议

如果你在做知识图谱 RAG，重点关注：

1. 实体归一化
   例如 LLM、大语言模型、Large Language Model 可能指同一个实体。

2. 关系类型规范化
   不要让关系类型无限膨胀，否则图谱会变得混乱。

3. 保留原文证据
   图谱三元组本身不够，必须能回溯到原文 chunk。

4. 限制图扩展范围
   多跳扩展很容易引入噪声，需要控制 hop、边数量和 chunk 数量。

5. 图谱定期清洗
   错误实体、重复实体、错误边需要治理。

8.3 LLM Wiki 优化建议

如果你在做 LLM Wiki，建议重点做好：

1. 页面结构固定
   每个 Wiki 页面最好有统一模板，例如摘要、核心概念、关键事实、引用来源。

2. 保留引用
   所有总结都应能追溯到原始文档。

3. 候选学习机制
   不要让模型直接把所有回答写入正式知识库。可以先进入候选池，再人工审核或自动评估。

4. 去重机制
   对标题、内容、向量相似度做去重，避免重复页面和重复笔记。

5. 不确定答案不沉淀
   如果回答里出现“信息不足”“无法判断”“没有检索到”等表达，就不应该写入 Wiki。

6. 缓存与限流
   页面生成和学习沉淀都可能调用 LLM，需要控制成本。

---

九、三种方案可以组合吗？

可以，而且在复杂项目中经常组合使用。

一个比较理想的企业知识库架构可能是：

原始文档
  ├─ 普通 RAG：用于快速语义检索原文 chunk
  ├─ GraphRAG：用于实体关系、多跳推理和结构化解释
  └─ LLM Wiki：用于主题化学习、知识沉淀和长期维护

用户问题
  ├─ 简单事实查询 → 普通 RAG
  ├─ 关系/链路/依赖查询 → GraphRAG
  └─ 学习/总结/体系化理解 → LLM Wiki

也可以让三者协同：

1. 普通 RAG 召回原文证据；
2. GraphRAG 提供实体关系结构；
3. LLM Wiki 提供主题总结；
4. 最后 LLM 综合三类上下文生成答案。

这种架构成本更高，但效果也更接近真正的“领域专家助手”。

---

十、初学者学习路线建议

如果你是刚开始学习知识库检索，可以按下面路线循序渐进。

flowchart LR
  A[阶段 1<br/>普通 RAG] --> B[阶段 2<br/>检索质量优化]
  B --> C[阶段 3<br/>GraphRAG]
  C --> D[阶段 4<br/>LLM Wiki]
  A --> A1[能做文档问答机器人]
  B --> B1[能做可用的生产级 RAG]
  C --> C1[能回答复杂关系问题]
  D --> D1[能建设长期知识管理系统]

阶段 1：掌握普通 RAG

你需要理解：

• 文档加载；
• chunk 切分；
• embedding；
• 向量数据库；
• topK 检索；
• prompt 拼接；
• 基于证据回答。

目标：能做一个 PDF / Markdown 文档问答机器人。

阶段 2：优化 RAG 检索质量

继续学习：

• metadata 过滤；
• hybrid search；
• query rewrite；
• query expansion；
• rerank；
• 多路召回；
• 引用溯源；
• 低置信度拒答。

目标：让 RAG 从 demo 变成可用系统。

阶段 3：学习知识图谱 RAG

继续学习：

• 实体抽取；
• 关系抽取；
• 三元组；
• Neo4j；
• Cypher 查询；
• 多跳子图扩展；
• 图谱证据召回。

目标：能回答复杂关系型问题。

阶段 4：构建 LLM Wiki

最后学习：

• LLM 生成概念页面；
• Wiki 页面索引；
• 知识卡片化；
• 学习候选池；
• 知识审核；
• 知识沉淀；
• 页面去重；
• 长期知识治理。

目标：从“知识库问答”升级到“知识管理系统”。

---

十一、常见误区

误区 1：RAG 等于向量数据库

不对。向量数据库只是 RAG 的一部分。完整 RAG 还包括文档处理、切分、检索策略、重排序、提示词、答案生成、引用溯源和评估。

误区 2：chunk 越大越好

chunk 太大会带来噪声，模型可能读到很多无关内容。chunk 大小要根据文档结构和问题类型调整。

误区 3：GraphRAG 一定比普通 RAG 好

不一定。GraphRAG 更适合关系密集型问题。如果只是简单 FAQ，普通 RAG 更便宜、更稳定。

误区 4：LLM 总结后的内容一定正确

不一定。LLM Wiki 必须保留来源引用，并设计审核和回滚机制。

误区 5：检索到内容就一定能答对

检索只是第一步。最终答案还取决于上下文拼接方式、提示词、模型能力和是否要求引用证据。

---

十二、总结：三句话讲清普通 RAG、GraphRAG 和 LLM Wiki

如果只记住三句话，可以这样理解：

1. 普通 RAG：从原始文档 chunk 中找相似内容，适合快速搭建文档问答。
2. 知识图谱 RAG / GraphRAG：从实体和关系出发检索子图和证据，适合复杂关系、多跳推理和高可解释性场景。
3. LLM Wiki：先把原始资料整理成主题化知识页面，再检索和持续沉淀，适合学习型助手和长期知识管理。

对于大多数初学者，推荐路线是：

先做普通 RAG → 优化检索质量 → 再做 GraphRAG → 最后尝试 LLM Wiki

对于企业项目，推荐原则是：

简单问答用 RAG，复杂关系用 GraphRAG，长期知识沉淀用 LLM Wiki。

知识库检索不是单一技术，而是一套围绕“如何让大模型可靠使用外部知识”的工程体系。理解普通 RAG、知识图谱 RAG 和 LLM Wiki 的差异，才能在不同业务场景下选择真正合适的方案。

---