RAG vs LLM Wiki 深度对比：企业知识库架构选型指南¶

Ch01.039 RAG vs LLM Wiki 深度对比：企业知识库架构选型指南¶

📊 Level ⭐ | 8.5KB | entities/rag-vs-llm-wiki-enterprise-knowledge-base.md

评分¶

价值：9/10 — 系统性对比 RAG 五大痛点的根因分析 + 场景选型决策矩阵 + 趋势预判，对该 wiki 自身建设有直接参考价值
置信度：8/10 — 源自 Karpathy/微软 GraphRAD/公开工程案例，作者有独立判断
乘积：72 — strong ★★★★★
策略对齐：与 Karpathy LLM Wiki V2 互补（概念介绍 vs 系统对比）；本文 wiki 本身就是 LLM Wiki 实践案例

与现有 wiki 的关系¶

互补：介绍 LLM Wiki V2 的 5 项核心升级，本文是 RAG vs LLM Wiki 的全面对抗性对比
填补空白：wiki 缺乏 RAG 技术架构的系统性批评分析和场景选型框架
实践关联：本文 wiki 正是 LLM Wiki 范式的实例——实体页 + 概念页 + raw 三层 + AI 驱动的 Ingest/Query/Lint

核心框架¶

RAG 五大真实痛点¶

Chunking 根本矛盾 — 块太小上下文不够，块太大噪声太多；ST段抬高案例的边界问题
无状态记忆 — 100 人问同一问题做 100 遍，无人从他人查询受益
文档越多越不准 — 向量检索与文档总量负相关，60% 问题在源文档质量
领域术语歧义 — 纯语义检索分不清 cross-domain 术语（positive=阳性/积极）
无法全局推理 — Top-K 只能找"最像片段"，做不了跨文档全局分析

LLM Wiki 三层架构¶

Schema 层（人定规则） → Wiki 层（LLM 维护） → 原始素材层（人提供，LLM 只读）

三个操作：Ingest（通读+综合+更新 10-15 页+标矛盾）、Query、Lint

成本核心差异¶

RAG：查询时花钱（每次检索+生成）
LLM Wiki：灌文档时花钱（LLM 深度读+综合），查询量大时反而更省钱

场景选型矩阵¶

场景	推荐	核心理由
知识高频变化	RAG	灌一篇搜一篇
术语密集垂直领域	RAG+KG 或 LLM Wiki	术语定义和关系管理
知识稳定+高查询量	LLM Wiki	Ingest 成本一次，查询零边际综合成本
海量文档+复杂查询	RAG+LLM Wiki 混合	各干各擅长的事
审计溯源	LLM Wiki	变更记录+原始文档追溯

趋势判断¶

不是二选一：RAG 广度检索 + LLM Wiki 深度沉淀
知识图谱从高级特性变标配（GraphRAG / LLM Wiki 轻量实现）
Ingest 成本随开源模型+推理降价快速下降
知识库从被动查询→主动维护（Agent 写+治理）

深度分析¶

1. Chunking 矛盾揭示 RAG 的架构性天花板¶

Chunking 的根本矛盾不在于分块大小策略的选择，而在于文本物理结构与语义结构天然不对齐。医疗 RAG 案例中"ST段抬高"的边界刚好把"非心梗"说明切到下个块——这是向量相似度无法感知语义边界的结果。固定长度、递归字符、语义分块、父子文档等策略各有坑，但没有任何策略能从原理上解决"块边界与语义边界不一致"这一结构性矛盾。

2. 无状态记忆使 RAG 在知识复用上存在系统性缺陷¶

100 人问同一问题做 100 遍、无人从他人查询受益，这一 RAG 固有缺陷在大规模企业部署中会被放大：相同问题被重复检索和生成，知识在查询间无法累积。GraphRAG 试图通过全局推理缓解这一问题，但其本质仍是查询时补救，而非构建有状态的知识层。

3. 文档质量是 RAG 的隐性瓶颈，往往被低估¶

"60% 问题在源文档质量"这一数据指向一个被忽视的事实：RAG 社区大量精力花在检索算法和生成优化上，但真正的瓶颈是文档本身。当企业知识库规模扩张时，向量检索质量与文档总量的负相关效应会逐渐显现——噪声文档的比例增加，稀释了高质量内容的检索命中率。

4. LLM Wiki 的核心优势在于知识的有状态化¶

LLM Wiki 在灌文档时就完成综合（Ingest 阶段），使知识本身变得有状态——Wiki 层随查询次数增加而持续优化，而非每次查询重新从碎片化片段拼装。这意味着知识库从"被动响应查询"转变为"主动维护结构"，矛盾在 Ingest 时被发现而非查询时才发现。

5. Schema 设计是 LLM Wiki 的核心壁垒，也是最大风险点¶

LLM Wiki 的质量上限由 Schema 决定：Schema 设计差，Wiki 层会系统性积累错误结构。Ingest 质量的天花板取决于 LLM 对 Schema 的遵循程度，以及 Schema 本身对知识组织方式的表达能力。与 RAG 的 Chunking 矛盾类似，Schema 设计也是"开始做之后才发现问题"的高风险决策。

实践启示¶

1. 高频变更知识场景优先选 RAG，配合主动文档治理¶

金融行情、政策法规、市场数据等每日更新的知识，RAG 的 5-15 分钟入库延迟优势明显。但必须同时建立文档质量监控：入库前做质量评分，低于阈值不灌入向量库。文档质量治理的投入优先级应高于检索算法调优。

2. 垂直领域术语密集场景优先考虑 LLM Wiki 的实体页¶

医疗、法律、航空等领域的核心痛点是跨领域歧义（positive=阳性/积极/阳性反馈）。LLM Wiki 的实体页天然适合存储术语的标准化定义和上下文约束，且可被其他页面交叉引用。Schema 设计时应优先定义术语实体类型和同义词关系。

3. 稳定知识+高查询量场景用 LLM Wiki，Ingest 成本一次性投入¶

员工手册、产品规格书、内部流程文档等"写完很少改、天天有人查"的场景，LLM Wiki 的经济模型最优：Ingest 综合成本一次付清，后续查询几乎零边际成本。当单文档月查询量超过 100 次时，LLM Wiki 的总拥有成本开始优于 RAG。

4. 复杂多文档分析任务采用 RAG+LLM Wiki 混合架构¶

制造维修手册等场景：RAG 负责广覆盖检索（快速找到相关文档），LLM Wiki 负责深度沉淀（关键维修步骤的标准化实体页）。混合架构的关键是设计好两个系统之间的接口：RAG 的检索结果作为 LLM Wiki Ingest 的候选素材，LLM Wiki 的实体更新触发 RAG 的增量索引。

5. LLM Wiki 投入产出比的关键是 Schema 前瞻设计¶

Schema 设计的失误在后期修正成本极高（需要重新 Ingest 全量文档）。建议用"最小可用 Schema"起步（只定义核心实体类型和必须的关系），通过 3-5 个真实查询案例验证 Schema 充分性后再扩展。Karpathy 的 LLM Wiki V2 的 5 项升级中，Schema 优化是核心。 → 原文存档