知识库

对比 RAG 与 LLM Wiki

Properties1
tags人工智能, 知识管理, 对比

7分钟阅读

对比：传统 RAG vs LLM Wiki

本文回答一个本质问题：RAG 和 LLM Wiki 不是同一类东西的两种实现，而是解决两个不同问题的两种方案。 关键词：LLM-Wiki-架构 · RAG · 向量检索 · 知识沉淀

一句话结论

传统 RAGLLM Wiki
本质即时检索系统持续维护的编译产物
知识形态文档切片 → 向量互链 markdown 文件
回答方式每次查询重新检索 + 拼装读已有页面，直接回答
核心问题”我手头的资料里有什么？""我目前为止知道什么？“
目标临时性、范围窄的查询长期、跨主题、累积的知识资产

核心区别：RAG 是 检索，LLM Wiki 是 编译（compile）。

详细对比

1. 工作流的根本差异

传统 RAG（每次查询）：
┌──────┐   切片   ┌────────┐   嵌入   ┌──────────┐
│文档集 │ ──────► │ chunks │ ──────► │ 向量数据库 │
└──────┘         └────────┘         └──────────┘
                                          │
                                          ▼  相似度检索
                              ┌──────────────────┐
                              │ top-k chunks      │
                              └──────────────────┘
                                          │
                                          ▼  拼装 prompt
                              ┌──────────────────┐
                              │ LLM 生成回答      │
                              └──────────────────┘

LLM Wiki（每次查询）：
┌────────────┐   读    ┌────────────┐
│ index.md   │ ──────► │  相关页面  │
│ (导航)     │         │ (已是结论)  │
└────────────┘         └────────────┘
                            │
                            ▼
                  ┌──────────────────┐
                  │ 直接回答 / 引用   │
                  └──────────────────┘

关键差异：

  • RAG 在查询时做检索 + 拼装。每次都从原始切片出发。
  • LLM Wiki 在写入时做整理（compile）。查询时是纯读取——跨源一致性、矛盾、引用都已经处理过。

2. 知识存什么？

维度RAGLLM Wiki
存储向量（数字）+ 元数据人类可读的 markdown
编辑通常需要专用工具/重新嵌入任何文本编辑器 + Obsidian
可审计不直观（要看 embedding 数值）直接读文件
跨设备需向量库同步Git / iCloud / Obsidian Sync
体积大（embedding 维度 × 切片数）小（纯文本）

3. 答案质量

维度RAGLLM Wiki
跨源一致性拼装时可能引入矛盾未被发现整理时已识别并标注
矛盾处理通常不显式处理contradictions: frontmatter + lint 提示
引用chunk ID 或文件名[[wikilink]] + provenance marker ^[来源]
上下文长度受限于 top-k（通常 5–20 段）受限于 LLM 上下文窗口，但页面自身 < 200 行
覆盖深度浅（限于检索到的切片）深（页面本身就是合成产物）
时效性取决于向量化更新频率updated: 字段 + lint 检测陈旧

4. 维护成本

操作RAGLLM Wiki
添加新资料切片 → 嵌入 → 入库（可能数分钟）读 → 写页面 → 加双链（数分钟，但产生永久结构）
修改错误通常需要重嵌入直接编辑 markdown
删除过时信息从向量库移除（不一定从源头删）移到 归档/，从 索引.md 移除
检测矛盾难以系统化发现contested: true + lint 自动汇总
评估质量检索指标（recall@k）+ 人工人工审阅 + lint（孤儿/断链/陈旧/矛盾）

5. 适用场景

✅ 用 RAG 当：

  • 一次性项目文档问答（合同、论文集、客服工单）
  • 范围窄、文档量大、不需要长期积累
  • 资料更新频繁但不需要跨文档整合
  • 团队共享文档库，不允许编辑源文档（合规/审计）

✅ 用 LLM Wiki 当：

  • 长期个人/小团队知识积累
  • 跨主题、跨资料来源需要整合出洞察（不只是检索）
  • 需要矛盾可追溯、可审阅
  • 想用通用工具（文本编辑器、git、Obsidian）而非专有平台
  • 愿意投入整理时间换取查询时间

❌ LLM Wiki 不适合：

  • 文档量大到无法人工整理（百万级文档）——这时 RAG 是必须
  • 实时性要求高的资料（新闻流、聊天记录）——RAG + 流式管道
  • 团队几十人都要写——版本冲突、协作复杂度爆炸

❌ RAG 不擅长：

  • “我对这个领域的所有认知是什么？“——它每次都从切片重拼
  • “我去年看的两本书观点相反，怎么调和？“——它不知道你说的是哪两本书
  • 长期跨主题的累积——每次都是新检索，没有”我笔记里已经想清楚过的结论”

组合用法（不是非此即彼）

实际系统中两者经常配合：

          ┌────────────────────────────┐
          │      LLM Wiki（人工整理）    │
          │  - 实体、概念、对比、问答    │
          │  - 跨源整合、矛盾已处理     │
          │  - 高置信结论              │
          └────────────────────────────┘
                      ▲ 写作时引用
                      │
          ┌────────────────────────────┐
          │   RAG（临时性、宽范围检索） │
          │  - 临时性文档问答           │
          │  - 大型语料片段定位         │
          │  - 不需要永久沉淀的资料     │
          └────────────────────────────┘

例子：

  • 你的 wiki（LLM Wiki 模式）放长期沉淀的概念、对比、读书笔记。
  • 同一台机器跑一个 RAG（llama.cpp + bge-m3）处理临时性查询——比如”我桌面上那份 PDF 第 3 章讲了什么？”
  • RAG 检索到的好东西 → 手动 ingest 进 wiki，提升为永久结构。

对本 wiki 的启示

  • 本 wiki 是 LLM Wiki 架构，不自建 RAG。原始素材/ 只作为 ingest 的源头，不切片嵌入。
  • 想要”问我的整个桌面/下载文件夹”这类问题 → 那属于 RAG 场景，不在本 wiki 范围。
  • 长期沉淀的最终归宿是本 wiki；临时性检索用 RAG 工具（如 llama-cpp skill）。

相关

关系图谱

反向链接