你的 RAG 正在悄悄失效，那LLM+Wiki呢？我动手验证了一遍，结果却有点意外

推荐语

探索LLM+Wiki方案如何解决RAG的致命缺陷，实测结果令人意外！

核心内容：
1. RAG方案在跨文档推理和矛盾检测中的实际表现分析
2. LLM+Wiki方案的核心机制与优势对比
3. 混合方案在真实业务场景中的测试结果与启示

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

上一篇我们用了 400 行源码和 7 个维度，从底层拆解了RAG为什么「两份相同的查询永远不会变聪明」。但原理讲得再透彻，终究要看实战。这一次，我们拿一组真实的后端组周报作为私有化知识，用两种方案实际跑了一遍，结果有些在意料之中，有些则又出乎意料。

如果你是第一次读到这篇文章，一句话补上前情提要：RAG（检索增强生成）是目前企业接入 LLM 私有知识的主流方案，把文档切成碎片、转成向量、查询时按相似度召回。但它的致命缺陷是无状态：昨天查过的内容，今天再查，系统从零开始，没有任何积累。

而上篇详细拆解的 LLM+Wiki 方案（Andrej Karpathy 提出），核心思路是让 LLM 持续维护一个结构化知识图谱，每次摄入新文档，不只是索引，而是提取概念、对齐已有知识、追加演化日志、标注矛盾。

背景：你所在的后端团队每周产出工作周报（团队有 200+ 篇历史文档）。CTO 提了一个需求，做一个内部 AI 助手，让团队成员能直接提问获取答案。

测试文档：一组真实的后端组周报，内容涵盖支付中心迁移、连接池超时排查、Redis 集群迁移计划、traceId 需求等。

测试问题：三类典型场景

• 「支付中心迁移后连接池配置怎么调整？」（跨文档推理）
• 「Redis 迁移到集群版有什么风险？」（矛盾检测）
• 「连接池超时问题排查进展如何？」（知识积累）
• 「SSL 证书什么时候到期？」（长尾覆盖）

测试方案：纯 RAG → 纯 LLM+Wiki → RAG+Wiki 混合，逐一对比。

技术栈：text-embedding-3-small+ Pinecone + Claude + LangChain。

将 200+ 篇文档（含周报.md）切分成约 1500 个 Chunk，向量化后存入 Pinecone。

问题 1：跨文档综合能力弱

问：「支付中心迁移后，连接池配置需要做哪些调整？」

源码层根因：

# RAG 的检索本质上是在做：chunks = vector_db.similarity_search(query, k=10)# 返回 10 个语义最接近的离散 Chunk# 但 Chunk 之间没有关系, # 系统不知道 Chunk_001 和 Chunk_005# 来自同一份周报，# 更不知道它们在业务逻辑上存在因果关联

backend-weekly-2026-04-20→connection-pool-timeout→hikari，查询时可以直接遍历这条关系链。

问题 2：无矛盾感知

RAG 回答：召回了周报.md 中李四的迁移计划片段，也召回了另一份半年前文档中推荐 Redis Sentinel 的片段。两个片段拼在一起，回答自相矛盾, 一会说「迁移到集群版」，一会说「推荐 Sentinel」。

源码层根因：

# RAG 的视角chunk_a = "下周计划：Redis 迁移到集群版"         # 来自周报.mdchunk_b = "推荐 Redis Sentinel，因为运维更简单"   # 来自半年前的架构文档similarity = cosine_similarity(embed(chunk_a), embed(chunk_b))# 相似度很高（都涉及 Redis 部署方案）# 但系统无法理解它们是在推荐两个不同的方向

LLM+Wiki 的 Contradictions 节为此设计, 两份不同来源的不同观点被显式记录，而不是被向量相似度掩盖。

问题 3：知识无法积累

第 17 周摄入了周报.md。第 18、19 周的周报中，赵六持续更新连接池超时的排查进展。但 RAG 中：

# 第 17 周query = "连接池超时 Hikari 版本问题"result = rag.query(query)  # 返回 3 个 Chunk，包含周报.md 的片段# 第 19 周（两轮排查后，根因已确认）query = "连接池超时 Hikari 版本问题"result = rag.query(query)  # 重新检索，返回更多 Chunk（含第 17-19 周的周报片段）# 但系统没有从之前的查询中学到任何东西# 它不知道第 17 周是"怀疑"、第 18 周是"确认"、第 19 周是"已解决"

每次查询的计算成本相同，结果质量并不因使用频次而提升。

经历了 RAG 的种种问题后，团队中有人提议：「既然 RAG 的问题都出在 Chunk 没有结构，那我们干脆只用 Wiki 行不行？把 200+ 篇文档全部摄入知识图谱。」

这个想法直觉上很合理, Wiki 能解决 RAG 的所有缺陷。但实际执行起来，很快遇到了覆盖范围的硬天花板。

实际情况：不可能全量摄入

团队花了两周时间，通过 INGEST 流程手动确认核心要点，最终从 200+ 篇文档中成功摄入了30 篇核心文档, 主要是架构设计文档、关键技术方案、以及最近 3 个月的周报（含周报.md）。这 30 篇文档提取出了约50 个概念页和 40 个实体页，构成了一个高质量但覆盖不全的知识图谱。

剩下的 170+ 篇文档（历史周报、会议纪要、一次性的技术调研、已废弃的方案）没有被摄入, 不是因为它们没用，而是因为每篇文档的 INGEST 都需人类参与确认，全量摄入的时间和成本不现实。

纯 Wiki 的优势：质量极高

对于已摄入的核心领域，纯 Wiki 的表现远超 RAG：

问：「支付中心迁移后，连接池配置需要做哪些调整？」

知识积累也完全生效, 第 19 周查询连接池超时时，系统自动知道第 17 周是「怀疑」、第 18 周是「确认」、第 19 周是「已解决」。

纯 Wiki 的致命缺陷：覆盖率盲区

但当问题超出已摄入的 30 篇核心文档范围时，Wiki 直接静默失败：

Wiki 回答：无法回答。该信息在 2025 年 9 月的一份历史周报中, 这份周报在 Wiki 覆盖的「最近 3 个月」窗口之外，未被摄入。

纯 Wiki 的覆盖率问题不是技术缺陷，而是经济约束, 每篇文档的 INGEST 都有 LLM 调用成本和人类确认成本。覆盖率天花板决定了 Wiki 不能作为唯一的检索层。

这个阶段的教训是：Wiki 在深度上无敌，在广度上有硬天花板。团队意识到需要的是把 RAG 的广度和 Wiki 的深度组合起来，而不是二选一。

团队在 RAG 之上叠加了结构化知识图谱层，让两者各司其职：但「各司其职」不是把两个系统的结果简单拼在一起就完事了。真正的挑战在于：当一个查询到来时，RAG 和 Wiki 各自返回了结果，系统如何决策用哪个、怎么合并？

混合查询的决策逻辑，系统在查询时遵循一个明确的分流规则，Wiki 优先，RAG 兜底，合并时标注来源。

       用户提问          │          ▼┌─────────────────────────────┐│ Step 1: Wiki 图谱检索        │ ← 先在 concepts/、sources/ 中匹配│ 命中 → 获取结构化知识节点      ││ 未命中 → 标记「Wiki 盲区」    │└──────────┬──────────────────┘           │           ▼┌─────────────────────────────┐│ Step 2: RAG 向量检索         │ ← 始终执行，全量文档扫描│ 召回 Top-10 Chunk 片段       │└──────────┬──────────────────┘           │           ▼┌─────────────────────────────┐│ Step 3: 结果合并决策          ││                             ││ 若 Wiki 命中 + RAG 命中：     ││   → Wiki 作为主答案骨架       ││   → RAG 片段作为补充证据/最新信息 ││   → 显式标注每部分来源         ││                              ││ 若 Wiki 未命中 + RAG 命中：    ││   → RAG 片段作为唯一答案       ││   → 标注「⚠ 此答案未经 Wiki 结构化验证」││   → 若该主题被多次查询 → 触发 INGEST 建议 ││                              ││ 若两者均未命中：               ││   → 诚实回答「未找到相关信息」  │└──────────┬──────────────────┘           │           ▼   最终答案（分层标注来源 + 置信度）

场景 A：Wiki 盲区 → RAG 兜底

问：「UAT 环境的 SSL 证书什么时候到期？」

Wiki 检索：未命中。「SSL 证书到期」从未被提取为概念页，它是一条一次性运维信息。 RAG 检索：命中。从周报.md 的 Chunk_005 中检索到表格片段： | UAT 环境认证证书 5.1 到期 | @运维 | 已申请新证书，等待审批 |

合并结果：以 RAG 片段直接回答：「证书 5 月 1 日到期，已申请新证书，等待审批。」 标注 ⚠ 此答案来自原始文档检索，未经 Wiki 结构化验证。 若后续有人再次查询同类问题 → 系统建议将「SSL 证书管理」纳入 INGEST 队列。

场景B：Wiki 已覆盖 → Wiki 骨架 + RAG 补充最新细节

问：「连接池超时 Hikari 版本问题排查进展如何？」

Wiki 检索：命中connection-pool-timeout概念页。返回：

• Definition（Hikari 超时的标准定义）

• Key Points（常见根因列表）

• Evolution Log（「怀疑」→ 「确认」→ 「已解决」的完整演进）

• Sources（3 份周报）

• Confidence: medium（3 份来源交叉验证）

RAG 检索：召回Chunk。

合并结果：

• 主答案骨架来自 Wiki：Evolution Log 提供完整的排查演进史，Contradictions 节标注了数据库端 wait_timeout 的备选根因

• RAG 补充最新进展：周报中的最终解决方案（Wiki 中尚未更新）

同时，系统标记 connection-pool-timeout 概念页需要更新,下次 INGEST时，Evolution Log 会自动追加。

场景 C：两者都有但 Wiki 可能存在矛盾 → Wiki 主动暴露分歧

问：「Redis 应该用集群版还是哨兵版？」

Wiki 检索：命中 redis-cluster-migration 概念页。Contradictions 节显式记录了：

• 来源 A（周报.md，架构组李四，2026-04）：「下周计划：Redis 迁移到集群版」→ 倾向 Cluster

• 来源 B（架构文档，运维组，2025-12）：「推荐 Redis Sentinel，运维更简单」→ 倾向 Sentinel

RAG 检索：召回了若干提及 Redis 的 Chunk，但没有明确的结论。

合并结果：

• Wiki 的 Contradictions 节直接成为答案的核心结构，向用户展示两种方案及其适用场景

• RAG 片段作为背景补充，但不会被「拼接」成一个貌似一致的假答案

• 避免了纯 RAG 时代「随机选一个方案」或「自相矛盾」的问题

三种方案效果对比

总结

RAG 和 LLM+Wiki 不是替代关系，而是分工关系。

RAG 解决召回（recall），保证你不会漏掉任何文档中任何角落里的信息。包括那些不值得进入 Wiki 的一次性记录、刚上传尚未摄入的新文档、以及只被问过一次的长尾内容。

Wiki 解决精度（precision），保证那些被反复引用的核心知识不会在每次查询时从零拼凑，而是持续积累结构、置信度和矛盾记录。

单独使用任何一方，都会在另一个维度上付出代价。 纯 RAG 让你永远在翻笔记却从不整理；纯 Wiki 让你对 15% 的核心领域了如指掌，却对另外 85% 的文档装聋作哑。混合架构，Wiki 优先做骨架，RAG 兜底补盲区，才是企业知识平台的务实答案。

上一篇参考：《你的 RAG 系统正在悄悄失效，两份相同的查询，它永远不会变聪明。那 LLM+Wiki 呢？》

—End—

如果觉得不错 随手点个赞、在看、转发三连吧

关注+星标⭐ 可第一时间收到更多精彩思考和总结

您的支持是我继续写下去的动力

注：原创不易，合作请在公众号后台留言，未经许可，不得随意修改及盗用原文。