在理解 WikiLLM 之前，我们需要先建立一个完整的技术地图：知识系统的三种主要架构，以及它们各自能解决什么问题、不能解决什么问题。

1.1 架构一：经典 RAG（检索增强生成）

工作原理：

你的知识被切成"块"（chunks），每一块被转化成一个向量（embedding），存进向量数据库。当你问问题时，系统把问题也转成向量，在数据库里找相似的块，把这些块塞进上下文，让 AI 基于这些块回答。

在经典 RAG 里，每一个新问题都让 LLM 重新开始：索引、检索、综合。模型在每个问题上"从头重新发现知识"，没有任何积累。LLM Wiki 模式把重心转移了：与其每次从原始文档重新生成答案，不如让模型建立并维护一个随时间增长的持久化 Markdown Wiki。

RAG 的致命弱点——语义密度失败：

向量检索是大多数 RAG 系统的主力，但它与多跳推理任务存在根本性的架构错配。2026 年的一项分析直白地指出：核心问题是研究者所称的"语义密度失败"——嵌入空间会把逻辑上不同但语义相似的关系压缩坍塌。知识图谱可以避免这些失败，因为它存储的是显式的、有类型的关系，而不是几何距离。

对 IP 创作者，这意味着什么？

想象你问："在第二纪元末期，主角所在势力的核心矛盾是什么？"

RAG 系统会检索所有"第二纪元"相关的块，所有"主角"相关的块，所有"势力矛盾"相关的块——然后试图拼接它们。但"第二纪元的主角势力的核心矛盾"这个跨三个维度的推理，需要的不是更多相似的块，而是理解三个维度之间的关系。

切分可能会主动破坏结构化内容的连贯性。LLM Wiki 保留了它。

RAG 的优势：速度快，成本低，适合简单的事实性检索。

RAG 的劣势：多跳推理弱，知识不积累，每次回答都从零开始。

RAG 配置的设置代价是巨大的：

设置一个 RAG 流水线需要：选择向量数据库，挑选嵌入模型，编写摄入脚本，处理切分策略，调整检索参数，构建评估循环来检查检索质量。对于一个非平凡的知识库，这需要数天的工作。而一个 Markdown Wiki 可以在一个下午内运转起来。

1.2 架构二：Agent 记忆（Session Memory）

工作原理：

AI Agent 在会话中记录关键信息，存成记忆条目，下次对话时加载相关记忆。

根本限制：

聊天机器人会忘记。每次对话都从新开始。

即使有了会话记忆，它解决的是"记住用户"的问题，但仍然无法跨会话综合知识。记忆是用户画像，不是知识图谱。

你加入了记忆。更好了，但现在 Agent 记住了用户，仍然无法跨会话综合知识。

适用场景：个性化对话助手，需要记住用户偏好的场景。

不适用：需要深度知识推理、跨主题连接、长期知识积累的场景。

1.3 架构三：LLM Wiki（智能知识编译系统）

工作原理：

LLM 是一个编译器，不是对话伙伴。你给它原始材料，它产出结构化知识。输出是你永远拥有的纯 Markdown 文件。

这是根本性的范式转变：

RAG：每次问题 → 即时检索 → 即时回答（知识不积累）

LLM Wiki：持续摄入 → 编译成知识页面 → 知识网络持续增长 → 基于知识网络回答（知识在积累）

LLM Wiki 模式（由 Andrej Karpathy 在 2026 年 4 月 4 日的 gist 中提出）用一个由 LLM 增量维护的持久化 Markdown Wiki 替代了临时的 RAG 重新生成。三个层次（来源、Wiki、模式）、摄入/查询/检查工作流、工具：Obsidian、Git、qmd。

1.4 三种架构的决策矩阵

为了更好的阅读体验，来飞书看吧：

https://aaf55djl41.feishu.cn/wiki/RZJFw0s0Gi149Zk9nm0c3KQgnpc