范式对比：RAG vs LLM Wiki

构建 AI 知识基础设施的两种根本不同的路径。

管道对比

RAG 管道
────────────────────────────────────────────────────────
原始文档 → 切块 → 嵌入 → 向量存储
                                    ↘ [查询时]
                         查询 → ANN 搜索 → LLM → 答案


LLM Wiki（知识编译范式）
────────────────────────────────────────────────────────
原始文档 → LLM 编译 → 结构化 Wiki 页面 → FTS 索引
                                                    ↘ [查询时]
                              查询 → FTS / 图遍历 → 读取页面 → 答案

多维对比

维度	RAG	LLM Wiki
核心操作	查询时检索	写入时编译
存储	向量数据库 + 原始 chunk	结构化 Markdown + SQLite FTS
搜索方式	ANN 相似度搜索	FTS5 BM25 + 图遍历
知识形态	隐式（向量）	显式（可读 Markdown）
可审计性	低	高（git diff、lint）
多跳推理	依赖 LLM	通过 related 图链接
是否需要 Embedding	是	否（纯 FTS）
知识积累	无（静态索引）	随时间复利增长
查询时 Token 成本	高（原始 chunk 传给 LLM）	低（预编译页面）
延迟	较高（ANN + LLM）	较低（FTS 亚毫秒）
基础设施	需要向量数据库	仅需 SQLite
人类可读性	否（向量不透明）	是（纯 Markdown）
最适合场景	宽泛文档问答、实时/动态数据	长期知识管理、Agent 记忆、研究

如何选择

选 RAG 的场景：

• 需要查询频繁变化的大规模语料
• 需要实时或近实时数据摄入
• 异构文档间的语义相似度匹配最重要
• 不需要维护或审查知识层

选 LLM Wiki 的场景：

• 知识需要随时间积累和改进
• 知识的可审计性和人工审核很重要
• Agent 需要在精心策展的知识库上搜索和推理
• 希望最小化查询时的 Token 成本
• 希望离线可用、零基础设施依赖

两者并不互斥

许多生产系统将两者结合使用：

• RAG 负责对大规模、动态变化语料的宽泛检索
• LLM Wiki 作为精心策展的高质量知识层，覆盖已知领域

典型混合模式：RAG 管道宽泛摄入 → 高置信度结果编译为 Wiki 页面供长期复用。

---

另见：RAG 关键技术 · LLM Wiki 关键技术