首页 > 专题 > Obsidian知识库 > 文章详情
返回 Obsidian知识库

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

2026年05月05日 24 阅读 Obsidian知识库

第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 了。

下一步建议：

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