---
title: RAG vs LLM Wiki：企业知识库架构的技术深剖
source_url: https://mp.weixin.qq.com/s/VQ-RgrLYsxb_iLUMzGr3FQ
publish_date: 2026-05-07
tags: [wechat, article, agent, rag, llm]
review_value: 7
review_confidence: 7
review_recommendation: neutral
ingested: 2026-05-16
sha256: 0252a0c4c0f20d0c97c5379fa00fe9764f46db65efe81944ea489c4025223faa
---
# RAG vs LLM Wiki：企业知识库架构的技术深剖
> 作者：小道玩AI，2026-05-07。RAG 技术架构、五大痛点与 LLM Wiki 的全面对比分析，含场景选型决策矩阵。
## RAG 技术架构
**核心流水线：**
- 入库：文档 → 切块 → 向量化 → 存进向量库
- 查询：问题 → 向量化 → 检索 Top-K 片段 → 拼上下文 → LLM 生成回答
- 四组件：Embedding 模型 + 向量数据库 + LLM + 编排框架
### Chunking 策略对比
| 切法 | 优点 | 坑 |
|------|------|----|
| 固定长度 | 最好实现 | 一句话能切成两半 |
| 递归字符 | 能保段落完整 | 格式乱的文档直接抓瞎 |
| 语义分块 | 块内语义紧实 | 阈值调到怀疑人生 |
| 结构化分块 | 效果最好 | 强依赖文档有结构 |
| 父子文档 | 两头兼顾 | 复杂度直接翻倍 |
核心矛盾：**块太小上下文不够，块太大噪声太多。**
### RAG 的优势
- 更新快：新文档灌入 5-15 分钟可检索
- 模型和知识解耦：换模型不影响知识库
- 幻觉率降 40%+（多证据 RAG，医疗场景压到 5.8%）
- 上手快：2-4 周跑通可用版本
## LLM Wiki 架构
Karpathy 核心思想：**别让 LLM 当搜索引擎，让它当图书管理员。**
三层架构：
```
Schema 层 — 人来定规则（知识组织/交叉引用规范）
Wiki 层 — LLM 维护（Markdown 实体页/概念页/交叉引用/矛盾标注）
原始素材层 — 人提供，LLM 只读（PDF/文章/笔记/数据）
```
三个操作：Ingest（通读→综合→更新 10-15 个页面→标注矛盾）、Query（查已整理好的 Wiki）、Lint（矛盾/过时/孤立页面检测）
## RAG vs LLM Wiki 核心对比
| 维度 | RAG | LLM Wiki |
|------|-----|----------|
| 知识状态 | 无状态，每次现查现拼 | 有状态，知识越用越厚 |
| 综合时机 | 查询时综合 | 灌文档时综合好 |
| 矛盾处理 | 今天一个答案，明天可能反了 | 一次性发现并标注 |
| 交叉引用 | 无 | LLM 自动维护 |
| 文档越多 | 信噪比可能下降 | 网络越密质量越高 |
### 性能/成本/工程三维度
| 维度 | RAG | LLM Wiki |
|------|-----|----------|
| 首次查询 | 2-5 秒 | 5-15 秒（先综合） |
| 后续查询 | 2-5 秒（每次都来） | 2-5 秒（已综合好） |
| 准确率 | ~78%（通用） | 看 Ingest 质量，天花板更高 |
| 幻觉率 | 优化后 5.8-15% | Wiki 本身不存在幻觉 |
| 基础设施 | 向量库+存储 ~$1,200/月 | 几乎为零，就是文件系统 |
| 灌文档 | 便宜（Embedding 一次） | 贵（LLM 深度读+综合） |
| 查询 | 每次检索+生成 | 已被综合，LLM 直接回答 |
| 维护 | 盯文档质量 | LLM 自动 Lint |
| 搭建周期 | 2-4 周 | 1-2 周 |
| 调优重心 | Chunking | Schema 设计 |
| 瓶颈 | 文档质量 | Schema 设计 |
**核心成本差异：** RAG 的钱花在每次查询，LLM Wiki 的钱花在灌文档时。查询量大时 LLM Wiki 反而更省钱。
## RAG 五大真实痛点
1. **切块的矛盾**：文本物理结构与语义结构对不上。医疗 RAG 案例——"ST段抬高"的边界刚好把"非心梗"说明切到下个块，模型给出心梗诊断
2. **无记忆**：100 个人问同一问题做 100 遍，没人从别人提问中获益
3. **文档越多越不准**：向量检索质量和文档总量负相关（60% 问题出在源文档质量）
4. **领域术语硬伤**：医学 positive=阳性/日常=积极的；纯语义检索分不清跨领域歧义
5. **无法全局推理**：Top-K 相似度匹配只能找"最像的几个片段"，做不了跨文档全局分析（GraphRAG 测试：让 Baseline RAG 从几千篇新闻总结"前五大主题"——完全不相关）
## 为什么 LLM Wiki 被认真对待
1. **核心假设不同**：RAG 隐含"检索到了就能答对"——实际片段对但缺上下文仍跑偏。LLM Wiki 在灌文档时就综合好
2. **知识图谱门槛降低**：GraphRAG 开源后，全面性/多角度碾压 Baseline RAG。LLM Wiki 用 Markdown 交叉引用作为轻量知识图谱
3. **Agent 时代需要工作记忆**：Agent 要做多步推理跨文档关联，LLM Wiki Wiki 层天然是工作记忆
4. **顺手做文档治理**：LLM Wiki 的 Ingest 通读过程自动暴露矛盾/孤立/重复
## 场景选型
| 场景 | 推荐方案 | 理由 |
|------|---------|------|
| 知识天天变（金融/政策/市场） | RAG + 混合检索 | 灌一篇搜一篇 |
| 术语密集的垂直领域（医疗/法律/航空） | RAG+KG 或 LLM Wiki | LLM Wiki 实体页天然适合存术语定义 |
| 知识稳定查询量大（员工手册/规格书） | LLM Wiki | Ingest 成本一次，查已综合好的知识 |
| 海量文档+复杂查询（制造维修） | 两者一起上 | RAG 广覆盖，LLM Wiki 沉淀关键知识 |
| 审计溯源（合规/风控） | LLM Wiki | 每次更新有变更记录，结论可追溯原始文档 |
## 趋势判断
- RAG 和 LLM Wiki 不是二选一：RAG 管广度检索，LLM Wiki 管深度沉淀
- 知识图谱从"高级特性"变"标配"（GraphRAG 重实现或 LLM Wiki 轻量版）
- Ingest 成本会越来越低（开源模型能力提升+推理成本下降）
- 知识库从"被动查询"变"主动维护"（Agent 不只查，还会写和治理）