读了9篇 LLM Wiki 文章后更迷糊了，我让 AI 帮我系统梳理知识库构建

通用知识管理方案，在专业领域需要改造才能用。

一、一件事

你敢把 AI 给你的答案，直接写进报告里吗？

我是不敢了。

但在之前，我确实是信了的——至少信到愿意把过去两年的周会记录，100 多份文件、35 万字，全部喂给一个 AI 知识库系统。

动机很朴素。

周会记录里有很多东西：项目决策的理由、技术方案的取舍、踩过的坑。东西都在，但想找的时候基本靠运气——记得讨论过，但藏在哪份文件里，真说不准。

我之前的做法是：翻文件名，凭记忆猜大概是哪一周的会，打开，Ctrl+F。

经常找不准。

所以当我读到 Andrej Karpathy 的那篇 Gist——「用 LLM 把原始资料编译成结构化 Wiki」——的时候，我觉得这可能是一个解法。

思路很简单：

1. 原始资料（周会记录）丢进 raw/ 目录

2. 让 AI 读取，编译成结构化的 Wiki 页面（Markdown）

3. 问答时直接读取编译好的页面，而不是每次重新检索原始文档

理论上，这件事做一次，好处吃三年。

二、第一个直观感受：Token 消耗巨大

好歹，在workbuddy知识库专家的帮助下，知识库做成了。

100 多份文件，35 万字，全部入库。WorkBuddy 可以回答「上次关于 XX 项目，我们为什么选了方案 A？」这类问题了。

但有一个直观感受很强烈——Token 消耗巨大。详情可见我上一篇文章：花光Workbuddy2个月积分做知识库，我踩了5个坑

每次让 AI 回答一个问题，它要读取的内容好像越来越多。我没有精确统计，但直观上，随着 Wiki 页面从 10 个涨到 37 个，每次问答的 Token 消耗明显增加。

我当时的想法是：也许本来就是这样，知识库越大，消耗越多，正常。

现在回头看，这个想法当然很天真。但当时的情况是：知识库刚建好，能回答问题了，感觉"有效果"。人在"刚看到效果"的时候，倾向于继续投料，而不是停下来质疑系统本身。

于是我按下了继续优化的键——补充更多资料，扩充知识库，让它更完整。

但 Token 消耗巨大的直观感受，让我隐约觉得「这个方向可能有坑」。只是当时没有想清楚「坑在哪里」。

于是我在公众号里搜 LLM Wiki 相关的文章，想看看别人是怎么做的。然后我刷到了一篇，里面提到了一个词——知识漂移

三、暂停键：我看到了「知识漂移」这个词

本来想按原思路继续扩充知识库。

然后我刷到了一篇文章，里面提到了一个词——「知识漂移」（Knowledge Drift）。

文章的大意是：AI 在编译 Wiki 页面的时候，会对原始内容进行「有损压缩」——它用自己的话重新表述你的原始资料。单次看没什么问题，但经过几轮更新之后，Wiki 页面里的内容，和原始文档之间会出现系统性偏差。

这才是知识漂移（Knowledge Drift）的真正含义——

它不是「错了」，而是「不够精确了」。而在专业领域，「不够精确」就是「错了」。

我读到这段话的时候，终于回过味来了。

我的 Wiki 里，有没有已经「漂掉」的内容？

这个问题我没有答案。但我知道一件事：在搞清楚之前，不应该继续往里喂数据了。

我按下了暂停键。扩充知识库的计划，暂时搁置。先解决「可靠性」问题。

四、混乱：我读了 9 篇文章，然后更迷糊了

我开始的想法很简单：去网上查一下，别人是怎么解决「知识漂移」这个问题的。

然后我掉进了一个兔子洞。

我一共读了 9 篇关于 LLM Wiki 的实践文章（参考文献附后）。读完之后的状态是：更迷糊了。

因为大家讨论的问题，和我要解决的问题，好像不是同一件事——

不是说社区讨论的方向不对，而是——

我面对的是一个「已经建好的知识库，怎么保证它不漂移」的具体问题。而社区里大部分文章在讨论的是「怎么从零开始建一个知识库」。

两个问题不是同一个。

我卡住了，思路很多很杂，已经混乱了。

五、停下来，系统整理了一遍——整理成LLM-Wiki学习笔记

卡住之后，我做了一个决定：不继续瞎搜了，把已经搜到的东西先系统整理一遍。

具体做了三件事：

① 把 9 篇实践文章去重、按维度重新组织——核心理念 / 架构模式 / 踩坑经验 / 最佳实践 / 工具生态，每个论点标注来源编号。

② 补学术来源——9 篇公众号文章读完后，我觉得权威性不够，又去 arXiv 找了 5 篇相关论文：RAG 综述、Token 优化方法、幻觉与知识漂移的学术定义、Microsoft GraphRAG 原论文。把这些和 9 篇实践文章合并，才形成了一份比较完整的认知。

③ 区分「共识」和「个例」——做完这件事之后，混乱的状态消失了。不是因为我找到了「标准答案」，而是因为我终于能分清：哪些是多篇独立提到的共识，哪些是个例，哪些是相互矛盾的（需要我自己判断）。

学习笔记的产出，是我这次优化真正的起点。

六、学习笔记里，对我最有用的三条

笔记很长，完整版我放在了我的 Wiki 库里。这里只说对我最有用的三条。

① 溯源机制不是可选项，是必选项

笔记里[3]提到，知识漂移的本质是「AI 生成摘要是有损压缩」。

解决方案里最有效的一条是：在每个关键事实后面，强制标注来源位置。

结论：该方案在限定条件下可行，不建议直接推广。 来源：raw/2024-03-周会记录.md, L128-L135

AI 在回答时，不是只输出结论，而是结论 + 来源引用，类似于学术论文的引用格式。

你可以选择信 AI 的总结，也可以点开原始记录自己核对。

这个机制在专业领域是必须的。

② 「好的回答才值得写回 Wiki」——需要更严格的定义

Karpathy 原文里说，问答中产生的有价值的新洞察，可以写回 Wiki[1]。

但在专业领域，「有价值」的判断标准应该更高。

我碰到一个具体场景：有一次 AI 回答了一个规范条款的理解问题，我核对原始记录后发现——它把两次不同时间的讨论混在一起了，得出的结论看起来合理，但实际上是错的。

这件事之后，我加了一条规则：Wiki 页面的任何更新，必须有人工确认环节，AI 不能自动写回。

③ 积木化的方向，可能比知识图谱更有用

有些用户目前在忙着给 LLM Wiki 加知识图谱、加向量检索[5][9]。这些当然有用。

但对我而言，把专业判断经验拆成可复用积木，对提升工作效率的帮助，可能比「语义检索」大得多。

具体来说，我现在在试着把每次技术评审中发现的「问题模式」，拆成积木卡片存进 Wiki。

不用看懂格式，关键是这个思路——大致长这样：

【积木卡片】  问题模式：源文件过大导致解析中断 适用场景：[技术报告, 技术文档, 批量处理] 严重程度：高  判断方法： - 文件 > 200KB → 先分块 - 文件 > 2000 行 → 先分块 - 否则 AI 解析容易中断  正确处理：分块 → 分别解析 → 合并结果

不用看懂每个字段，关键是这个思路：把经验拆成可复用的卡片。下次碰到类似场景，直接检索积木 → 匹配场景特征 → 组装评审意见。

七、结论：通用方案需要改造

通过系统的梳理，我对 LLM Wiki 的看法是这样的：

它提供了一个非常好的「知识编译」思路，但落地到相关专业领域，需要至少三个改造：

① 溯源机制从「建议」升级为「强制规范」

专业领域里，每个结论都必须能追溯到原始依据（哪份文件、哪条条款、第几页）。

② 「好的回答才写回 Wiki」增加人工确认环节

AI 自动写回，在专业场景里风险太高，必须需要人工确认。

③ 积木化的优先级，可能高于知识图谱

把专业判断经验拆成可复用积木，这件事的长期价值，可能比「语义检索」大得多。

八、后记：知识库这件事，没有银弹

我一开始以为，把周会记录做成知识库，是一个「技术问题」——只要选对工具、配好流程，就能解决「知识找不到」的问题。

现在我觉得，它更多是一个「方法论问题」——你怎么结构化地组织自己的专业经验，让它可以被检索、被复用、被传承。

工具会变化，LLM Wiki 可能只是这个阶段的一个解法。但「把隐形的专业判断经验，变成显性的、可沉淀的知识」，这件事的价值是长期的。

下一步我打算把「积木化」这个思路，更系统地应用到专业技术文档的整理上。

如果这一步能跑通，我会再来写一篇。

不是写「我成功了」，而是写「我试了什么、哪里卡住了、下次怎么改进」。

因为知识库这件事，没有银弹。

参考文献

我在整理这篇文章的时候，系统读了 9 篇实践文章 + 5 篇 arXiv 学术文献，并整理成了完整的学习笔记。本文中的论点凡标注 [N] 的，可在对应文章中找到来源；标注 [A1]~[A5] 的，为 arXiv 学术文献。

学术文献

公众号实践文章