第7篇｜RAG vs LLM Wiki 选型决策指南

预计阅读时间：20分钟
核心目标：帮助你在 RAG 和 LLM Wiki 之间做出正确选择，并了解混合方案

7.1 两种知识召回范式

在进入对比之前，先理清两个核心概念：

RAG（Retrieval-Augmented Generation）

[用户问题] → [向量数据库检索 Top-K 片段] → [拼接为 Prompt] → [LLM 生成回答]

本质：每次回答问题时，从文档库中实时检索相关内容，交给 LLM 合成答案。

LLM Wiki（预编译知识库）

[来源摄入] → [Agent 预先整理成 wiki 页面] → [用户/Agent 直接读取 wiki 页面] → [回答]

本质：知识在摄入时就已经整理好，不需要每次重新检索。

7.2 深度对比

维度	RAG	LLM Wiki
知识形态	原始文档 chunks	结构化 wiki 页面
召回方式	向量相似度检索	人工/Agent 预设的 wikilinks
跨文档关联	弱（依赖 chunk 边界）	强（wikilinks 显式关联）
建库成本	低（直接灌入）	高（需要 Agent 整理）
维护成本	低（新增文档自动加入索引）	高（需要持续更新 wiki 页面）
知识一致性	难以避免矛盾（文档独立）	可主动检测矛盾（Agent 统筹）
适合规模	1000-10000+ 篇文档	50-500 篇核心文档
冷启动速度	快（小时级）	慢（周级/月级）
答案可溯源性	chunk 引用，较模糊	精确的来源标注
适用场景	问答机器人、企业知识库、搜索引擎	深度研究、个人第二大脑、团队知识管理
LLM 依赖	强（生成质量依赖 retrieval）	弱（大部分知识已整理成文）

7.3 选型决策树

你的场景有多少篇核心文档？
    │
    ├─ < 100 篇
    │   └─ LLM Wiki ✅（建库成本可控，关联价值最大化）
    │
    ├─ 100-500 篇
    │   └─ 取决于场景：
    │       ├─ 需要深度研究、持续迭代 → LLM Wiki ✅
    │       └─ 需要快速问答、覆盖面广 → 可以考虑 RAG
    │
    ├─ 500-1000 篇
    │   └─ 混合方案（见 7.5）⚖️
    │
    └─ > 1000 篇
        └─ RAG ✅（超出人类整理的经济边界）

7.4 典型场景分析

场景 A：个人 AI/ML 研究者

需求：追踪 AI 领域最新进展，持续消化论文和文章，形成自己的知识体系。

文档量：50-200 篇核心资料
更新频率：每天 1-5 篇
目标：深度理解，不是简单问答

推荐：LLM Wiki

理由：

论文/文章需要深度消化，LLM Wiki 的预编译模式更适合
wikilinks 能帮你发现跨论文的联系（比如「这篇 RLHF 论文和那篇 DPO 对比」）
个人使用，建库成本可控
结合 Obsidian Graph View，可视化知识网络

场景 B：创业公司内部知识库

需求：员工查询公司文档、产品 spec、API 文档，100+ 人在用。

文档量：500-2000 篇
更新频率：文档随时更新
目标：快速找到答案，不需要深度研究

推荐：RAG + 简单前端

理由：

文档量大，LLM Wiki 建库成本太高
用户目标是「快速找到答案」，不是深度研究
文档更新频繁，RAG 的实时索引更适合
可以加一层路由：简单问题 RAG 回答，复杂问题转人工

场景 C：开发者个人 Wiki

需求：记录自己维护的开源项目、技术踩坑、代码片段。

文档量：30-150 篇
更新频率：按需，不频繁
目标：方便自己查阅，辅助记忆

推荐：LLM Wiki（Obsidian 本地）

理由：

Obsidian 完全本地，数据安全
wikilinks 帮你把不同项目的相通问题串联起来
不需要多设备同步可以免费使用
比 Notion 更可控（没有厂商绑定）

场景 D：法律/医疗等专业领域顾问

需求：快速检索法规条文、判例、医疗指南，需要严谨的引用。

文档量：1000-10000+ 篇
目标：严谨引用，可审计

推荐：RAG（带引用增强）

理由：

文档量大，RAG 是唯一可行方案
需要精确的引用来源（chunk 级别）
LLM Wiki 的预编译可能遗漏某些罕见情况
可以加一层「矛盾检测」：同一问题多个来源冲突时标记警告

7.5 混合方案：LLM Wiki + RAG 互补

对于 500-1000 篇量级的场景，混合方案可以兼顾两者优点：

[来源输入]
    │
    ├──────────────────────┐
    ↓                      ↓
[RAG Index]          [LLM Wiki]
向量索引              Agent 预整理
    │                      │
    ↓                      ↓
[简单问答：今天发布    [深度研究：这个模型的
 的新版本有哪些功能？]  演进脉络和架构对比？]
    │                      │
    └──────────┬───────────┘
               ↓
        [用户/Agent 综合回答]

混合方案实现思路

def hybrid_query(question, rag_system, wiki_pages):
    """混合召回"""

    # 1. RAG 快速召回（适合事实性、封闭式问题）
    rag_results = rag_system.retrieve(question, top_k=5)

    # 2. LLM Wiki 精确召回（适合需要关联分析的问题）
    wiki_results = search_wiki_pages(question, wiki_pages)

    # 3. 判断问题类型，决定权重
    if is_simple_fact_question(question):
        return rag_results  # RAG 优先
    elif is_research_synthesis_question(question):
        return wiki_results  # Wiki 优先
    else:
        return merge_results(rag_results, wiki_results)  # 两者结合

什么情况下 Wiki 优先？

需要跨文档关联（如「A 和 B 两个方案的对比」）
问题涉及多个概念的交叉（wikilinks 已经建立了这些关联）
需要完整的推理链条（wiki 页面已经有 Agent 整理好的分析）
问题的答案应该是一个「叙述」而不是「片段」

什么情况下 RAG 优先？

问题非常具体（如「这个 API 的 rate limit 是多少」）
需要覆盖最新的未整理文档（Wiki 还没来得及处理的新来源）
回答需要精确的原文引用（chunk 级别）
海量文档中的一次性探索（不知道答案在哪里）

7.6 迁移路径：从小到大的演进

第一阶段：纯 LLM Wiki（0-200 篇）

Obsidian + Agent Ingest
- 建库成本最低
- 可以先手工建，Agent 辅助维护

第二阶段：加入 RAG（200-500 篇）

Obsidian (核心知识) + RAG (原始文档备份)
- 核心知识用 Wiki 管理
- RAG 作为「文档备份」的检索入口

第三阶段：分层 RAG + Wiki（500-1000 篇）

Top Layer: Wiki（Agent 整理过的知识，高置信度）
Mid Layer: RAG（已读但未整理的文档）
Bot Layer: RAG（未读的原始文档）

第四阶段：全自动 RAG（>1000 篇）

放弃 Wiki，纯 RAG
- 人工整理的成本已经超出经济边界
- 用更智能的 chunking + routing 替代人工关联

7.7 成本-收益对比

方案	建库成本	维护成本/篇	回答质量	上限规模
纯 RAG	低（自动）	低	中	无限
LLM Wiki	高（人工/Agent）	中	高	~500 篇
混合	中	中	高	~2000 篇

关键结论：

如果你能接受建库成本，LLM Wiki 的回答质量更高（因为知识已经被结构化）
如果你的文档会持续爆炸性增长，RAG 是唯一出路
混合方案适合从 Wiki 向 RAG 过渡的中间态

7.8 LLM Wiki 的不可替代性

即使 RAG 再强，以下场景 LLM Wiki 依然不可替代：

场景	为什么 RAG 不够	为什么 Wiki 更优
跨文档隐含联系发现	RAG 只能发现 chunk 边界内的关联	wikilinks 显式建立跨文档联系
矛盾主动管理	RAG 可能同时引用两个矛盾来源	Agent 维护时可以主动标记矛盾
知识的渐进深化	RAG chunk 是一次性的	wiki 页面可以持续更新、增加理解深度
个人知识体系构建	RAG 是「问答工具」	Wiki 是「第二大脑」
Obsidian Graph View	无法提供	可视化知识网络是核心体验

7.9 决策检查清单

当你纠结选 RAG 还是 LLM Wiki 时，用这个清单：

□ 文档量是否 < 500 篇？         → 是：倾向 Wiki
□ 用户目标是否是深度研究？       → 是：倾向 Wiki
□ 知识是否需要持续迭代深化？     → 是：倾向 Wiki
□ 跨文档关联是否重要？           → 是：倾向 Wiki
□ 是否需要快速冷启动？           → 是：倾向 RAG
□ 文档是否超过 1000 篇？         → 是：倾向 RAG
□ 是否需要精确 chunk 级别引用？   → 是：倾向 RAG
□ 是否有多人协作需求？           → 两者皆可，看规模
□ 预算是多少？                   → 低预算 + 小规模：Wiki
□ 是否需要多设备同步？           → Obsidian Sync/iCloud：Wiki

如果大多数回答「是」倾向于 Wiki → 选 LLM Wiki
如果大多数回答「否」倾向于 RAG → 选 RAG

7.10 小结

RAG：适合海量文档、快速问答、建库成本敏感的场景
LLM Wiki：适合精炼知识库、深度研究、跨文档关联、知识一致性要求高的场景
两者不是非此即彼——混合方案可以兼顾规模和质量
选型核心判断：你的文档规模和用户目标（问答 vs 研究）
LLM Wiki 的核心价值：wikilinks 显性关联 + Agent 主动维护 + Obsidian 可视化
RAG 的核心价值：自动建库、实时检索、无规模上限

附：全套教程目录

01｜LLM Wiki 核心概念与架构解析
02｜Obsidian 快速上手 + 最小可用 Wiki 搭建
03｜SCHEMA.md 设计规范与 Tag Taxonomy
04｜wikilinks 交叉引用与 Dataview 查询实战
05｜Obsidian Headless 服务器常驻同步方案
06｜Agent 自动化 Ingest 工作流
07｜RAG vs LLM Wiki 选型决策指南

恭喜你完成全套教程！从认知建立到工程落地，你现在应该有能力搭建并维护一个生产级的 LLM Wiki 了。

下一步建议：

用第2篇的模板，立刻创建你的第一个 Obsidian Vault
用第3篇的 SCHEMA 模板，定义你自己的领域规范
先手工跑一遍 Ingest 流程（不用 Agent），感受每个步骤
确认 Obsidian Sync（如果需要多设备）
有问题欢迎交流

7、RAG vs LLM Wiki 选型决策指南