RAG 与 LLM Wiki：两种 AI 知识库方式怎么选
把几十篇文档上传给 AI，问它一个问题，得到一段带引用的回答。这已经是很常见的知识库体验。
但用久了会发现两种不同的需求。一种是查资料：“当前版本的接口限制是什么？”另一种是积累理解：“读了这么多文章，这些方案到底有哪些差别？上次分析出的结论能不能保留下来，下次继续用？”
RAG 通常从前一个问题出发，LLM Wiki 更重视后一个问题。它们都让模型使用外部资料，但整理资料的时机和维护对象不同。先把这两个问题分清，再决定搭什么系统。
为什么不直接把所有资料发给模型
假设有一批产品资料：旧版手册、新版补充说明、支持工单，以及几次内部讨论。用户问某个功能有没有调用次数限制。
把所有文件塞进上下文，看起来最省事。但资料增加后，输入成本和处理时间会增长，也可能超过上下文限制。即使能装下，模型也需要分辨哪些规则有效、哪些只适用于旧版本，不能保证每次都从长文里找到正确段落。
只保留一段总摘要也有问题。“每天允许调用一千次”可能漏掉“仅限免费套餐”的条件。以后用户问企业套餐，摘要就会成为错误依据。
可用的知识库至少需要满足这些条件：找到相关内容、保留适用范围、能追溯出处，并在资料更新时避免继续使用旧结论。模型说得顺不顺，是另一个问题。
RAG：在问题到来时找证据
RAG 是 Retrieval-Augmented Generation，检索增强生成。简单理解，就是先找资料，再把找到的资料交给模型回答。
资料进入系统时做什么
常见流程如下：
原始文档
→ 提取文字和结构
→ 分成可检索片段
→ 保存片段、来源、版本与权限
→ 建立关键词索引或向量索引提取文字并不总是直接读取文件。扫描 PDF 可能要 OCR，表格需要保留行列关系，网页需要去掉导航和广告。输入在这一阶段被读错，后面换更大的回答模型也无法可靠补救。
切片通常把长文拆成较小片段，便于检索和放进上下文。但切片不能只看字符数。如果把“限制说明”和“例外条款”拆开，检索时只找到前者，模型就可能给出没有条件的答案。
向量检索会用 Embedding 模型把文本转换成数值向量，再按相似度查找。它擅长处理表达不同但意思接近的问题；关键词检索则适合找明确的接口名、错误码和产品编号。两者可以组合，不需要把 RAG 理解成“必须用向量数据库”。
用户提问后做什么
用户问题
→ 确定可访问的资料范围
→ 检索候选片段
→ 根据相关性重排序
→ 把证据与问题放进上下文
→ 生成回答并标明来源例如，检索“调用限制”后，同时找到旧版手册和新版补充说明。系统需要利用版本、时间和适用套餐筛选，而不是只让模型在两个冲突数字里任选一个。
这里的重排序，也就是 Reranker，会进一步判断候选片段和问题的相关性。它可以改善排序，但不会自动知道某份文档已经作废，版本信息仍要保留。
RAG 的价值和限制
它把事实来源放在模型之外，更新规则时可以更新资料和索引，不必为了每次规则变化重新训练模型。回答还可以给出证据，方便人检查。
但“已经接入知识库”不等于“回答一定正确”。失败可能发生在不同层：
- 原文没被正确提取，索引里根本没有那个事实。
- 检索漏掉正确片段，只找到了相似的其他产品。
- 片段找对了，却没有连同例外条件一起提供。
- 模型看到了完整证据，仍把不同版本混在一起。
- 给出的引用看似相关，实际不支持那个结论。
排查时先看检索返回了什么，再看最终提示词包含什么，最后才判断回答模型。只看到错误答案就换模型，可能是在绕过真正的故障。
LLM Wiki：在资料进入时先整理知识
这里的 LLM Wiki 指 Karpathy 描述的一种知识维护方式：由模型协助把原始资料整理成持久、相互链接的知识页，并随新来源更新。
它不是统一协议，也不是某个必须安装的软件。Markdown 文件、目录和版本管理就能构成基础。Obsidian 可以作为阅读这些文件的界面，但不是这套方式成立的必要条件。
不只保存文件，还保存读过之后的理解
对同一批产品资料，Wiki 可以形成几类页面：
- 产品页：当前能力、适用版本与相关资料。
- 概念页：什么是调用额度，额度如何计算。
- 比较页：不同套餐的限制和例外。
- 查询页：某次有价值的分析，连同出处保留下来。
原始文件保留不动。整理页可以改，但每个重要结论应能追溯到来源，不能让模型生成的摘要替代原文成为唯一依据。
一套示意目录可以这样安排，具体名称不必照搬：
knowledge/
├── raw/ 原始资料
├── entities/ 产品、机构、人物等实体页
├── concepts/ 概念页
├── comparisons/ 比较与分析
├── queries/ 值得保留的查询结果
├── index.md 内容目录
├── log.md 变更记录
└── schema.md 整理与维护规则这里最容易忽略的是规则文件。它需要约定页面类型、来源记录、更新方式和冲突处理，避免模型每次按不同习惯建一批新页面。
新资料进来，要更新哪些地方
假设新版手册改变了免费套餐的调用额度。
在 Wiki 方式里，模型先读新来源，找到已有的额度概念页和套餐比较页，再更新受影响的结论。旧数字可以保留为历史记录，但必须标明版本；如果两份仍有效的资料互相矛盾，要记录争议，而不是擅自把其中一份删掉。
然后更新目录和变更日志。这样下一次问套餐区别时，系统可以先读取已整理的比较页，不必从头对照每份手册。
提问本身也可以带来更新。比如用户要求比较三个方案，得到一份经过核对的分析，就可以把分析存为页面。以后新方案出现，再在这份比较上继续维护。
维护不是自动获得的能力
模型能一次修改多个文件，不代表它一定修改完整。它仍可能漏掉引用、误读原文，或把自己的推断写成事实。
Wiki 至少需要定期检查：有没有失效链接、缺来源的结论、过期页面，以及相互矛盾的说法。新增资料会影响多少页面，也需要追踪。否则页面越多，旧摘要传播得越广，修正反而越困难。
LLM Wiki 把一部分查询时的综合工作前移到整理时，不代表没有成本。阅读来源、更新页面、检查引用都消耗 Token 和时间；最终省不省，要看资料变化频率和相同主题被反复查询的次数。
两者差别：什么时候做综合，留下什么产物
| 问题 | 常见 RAG 实现 | LLM Wiki 方式 |
|---|---|---|
| 资料进入后 | 提取、切片、建立索引 | 阅读、综合并更新知识页 |
| 提问时 | 检索证据后组织回答 | 读取知识页，必要时回查原文 |
| 主要持久产物 | 文档、片段与索引 | 文档、概念、实体、比较及其链接 |
| 新资料到来 | 更新检索数据、处理版本 | 找出并更新受影响的页面 |
| 跨文档分析 | 常在查询时进行 | 可以提前整理并持续维护 |
| 常见失误 | 漏检、错检、丢上下文 | 错误摘要、漏更新、来源丢失 |
这个对比描述的是常见实现，不是技术边界。RAG 系统也可以预先生成摘要、构建图谱或保存分析；Wiki 查询也需要搜索。不能把它们说成“一个只会搜索，一个才有理解”，更不能据此宣布 Wiki 已经替代 RAG。
两者都不等于训练，也不自动提供长期记忆
在这两种方案里，知识通常保存在模型之外。模型回答时读取资料或知识页，其参数并没有因为导入文件而改变。
换一个模型，只要新模型能使用同样的资料和工具，就可能继续使用这套知识库。反过来，即使 Wiki 文件一直存在，如果本次请求没有加载相关页面，模型也不会自动知道里面的内容。
微调解决的是进一步训练模型的问题，常用于调整行为、格式或任务表现。它不是维护经常变化的文档事实的唯一方法，也不能保证准确背下所有规则。
可以把它们放进同一套系统
两者结合的一个实际流程是：
原始资料 → 提取与版本记录 → 原文检索索引
↓
整理成 Wiki 页面
↓
Wiki 目录与检索索引
用户问题 → 先找知识页 → 回查相关原文 → 带出处回答Wiki 提供跨文档整理好的结构，原文提供具体证据。问题涉及金额、权限、合同或版本变更时，优先核对原文，不能只引用一层模型摘要。
回答后是否写回 Wiki，需要单独决定。临时闲聊不一定值得保存；新比较或经核验的新结论可以保存。未经核验的生成内容不应自动回流为“事实”，否则系统以后检索到的只是自己之前的错误。
这套流程也可以采用固定工作流，不必一开始就放任 Agent 自主改写全部文件。初期让它提出改动，再由人确认，通常更容易发现规则设计中的遗漏。
怎么选：先看你的资料和问题
主要查规则、找条款：先做 RAG
面对大量说明书、工单、政策文档，问题主要是“哪一条规定”“这个错误怎么处理”，可以先做提取、检索和引用。重点在查全、查准、版本和权限，不必为了显得完整给所有文档生成概念页。
更新频繁不代表 RAG 不需要维护。旧版片段要撤销或标记，权限变化需要同步到检索层，索引更新也应有可检查的结果。
长期研究一个主题：可以从 Wiki 开始
如果你持续读论文、技术文章或行业资料，经常需要跨来源比较，并希望保存每次分析，Wiki 更贴近需求。先从少量可靠来源开始，建立概念页和比较页，观察来源是否能顺利追溯。
资料不多时，目录与全文搜索就可能够用。页面增长后，再判断是否需要向量检索和重排序，没必要为了采用这个名字先部署一套复杂数据库。
既查事实又做研究：两者结合
需要反复综合很多文档，又需要逐条核对事实，就保留原文检索，同时维护知识页。整理页负责导航和综合，原文负责证据，两个层次都明确来源与版本。
如果只临时读两三份短文件，直接放入上下文可能已经足够。系统的维护成本应该由真实需求支撑，而不是由术语推动。
实现时容易漏掉的边界
权限必须在读取资料前控制。 先把机密文档交给模型，再提示它不要泄露，不能替代访问控制。Wiki 摘要也应继承相关敏感信息的访问约束，不能让原文私密、总结公开。
来源里的指令只是资料。 网页或文档可能写着“忽略之前要求”“执行这段命令”。检索系统应把这些内容当作待分析文本，而不是执行指令，尤其不能让资料直接触发删除或外发操作。
外部模型调用涉及数据传输。 本地保存文档不代表处理过程全部本地。如果摘要或向量化使用远程 API，资料可能被发送给服务商。部署前应明确哪些步骤出站、哪些内容需要脱敏。
删除要覆盖衍生内容。 删除原文后，检索片段、索引、缓存和 Wiki 页面里仍可能保留同一信息。要按来源关系清理或重算，不能只删一个文件就认为信息消失。
怎么判断真的可用
不要只测试“上传后能聊天”。准备一组可以核对的问题，覆盖明确事实、跨文档比较、旧版与新版冲突、没有答案的问题，以及无权查看的资料。
对每个结果分别检查：
- 系统有没有找到正确来源？
- 返回的片段或知识页是否保留完整条件？
- 引用能否支持具体结论，而非只是提到同一主题？
- 资料没有答案时，系统有没有明确说明，而不是猜？
- 更新或删除来源后，旧结论是否还会出现？
RAG 额外查看检索候选和排序；Wiki 额外查看哪些页面被更新、来源是否完整、冲突是否保留。性能则记录等待时间、总 Token 用量和维护成本，不只比较一次回答速度。
本文的目录和流程是实现示意，不是已部署系统的测试报告。真正选型时，应该用自己的资料和这组检查方法验证。
总结
RAG 帮你在回答时找到证据；LLM Wiki 帮你保留并维护已经整理过的知识。前者的关键是检索和证据质量，后者的关键是来源关系和持续更新。
先确定自己要“查资料”还是“积累研究”，再选择维护哪些产物。无论采用哪一种，保留原文、控制权限、核对引用和检验更新，都是不能交给一个名字代替的工作。