内化层：让 Wiki 进入人的判断HERMES & AGENT ENGINEERING · 课时 05

5.1 内化不能靠额外任务解决

一说到“内化知识“，我们第一个想到的就是刷题、做任务、打卡。但这不是最佳的方式，必要的刷题是需要的，但是刷题的目的是为了加深理解，而不是为了让用户记住。

如果胶囊系统要求用户额外复习、回答问题、定期打卡，大多数人坚持不了多久。

知识库工具应该尊重人的真实习惯。用户保存资料，是因为当下遇到了材料；用户打开资料，是因为要写文章、做方案、查概念、判断一个问题。系统如果在这些动作之外再制造一套学习流程，很容易变成负担。

所以内化层不能靠“多问用户几个问题”或者让“用户去做练习”这种额外任务来实现。它应该尽量藏在用户本来就要做的事情里。

更准确地说，内化层要解决的是这个问题：

系统怎样把外部资料整理成一种结构，让用户在反复打开、引用和修改的过程中，逐渐形成自己的判断。

这不是一次完成的事情。它更像一种长期沉淀：资料不断进入，主题页不断被融合，用户一次次回到同一条知识线，慢慢就知道这个领域里哪些判断重要，哪些概念容易混淆，哪些边界已经被修正过。

你要说原理，其实我觉得没有什么神秘的。它遵守的还是很朴素的规律：多看、多读，勤能补拙，不厌其烦。时间久了，知识才可能内化成自己的结构。

5.2 主题页本身要不断变成好文章

这是内化层最基础的一点。如果主题页只是资料堆积，用户每次打开都要重新筛选，他不会内化。他只会觉得累。但如果主题页每次都已经被融合过，情况就不一样了：

这样用户每次读这篇主题页，其实都是在读一份已经整理过的知识结构。这比让用户看十篇原文有效得多。原文保留在证据层里，用来核对；主题页负责把资料变成一篇值得反复阅读的知识文章。

所以演化层本身就是内化的第一步：把外部资料整理成一篇好文章。内化层再让这篇文章里的判断和索引更容易被人吸收。

5.3 让用户总是回到同一篇主题页

人的记忆是基于重复循环模式的。内化也需要人重复接触相同或者相似的内容，才能刺激记忆形成，但这种重复不能像背单词。没有哪个成年人有时间去背海量的知识，靠背诵的知识也无法真正进入人的判断。

更合适的方式，是让相关资料不断回到同一篇主题页。比如“Embedding 向量”这个主题，用户今天存一篇“什么是 Embedding”，明天存一篇“词向量为什么能表示语义”，后天存一篇“Embedding 如何用于语义检索”。系统不应该生成三篇摘要，而应该不断更新同一篇“Embedding 向量”主题页。

这样用户每次回来，看的都是同一条知识线的最新状态。时间久了，他脑子里自然会形成结构：

Embedding 是什么
为什么文本可以表示成向量
向量空间如何表示语义关系
为什么语义相近的文本向量距离更近
Embedding 为什么能用于语义检索

所以主题页不能拆得太碎。一个主题页如果能承载一条长期知识线，就应该让相关资料优先回到这里。等某一部分知识足够丰富了，再拆出概念页或新的主题页。

5.4 把知识嵌进输出任务里

最有效的内化方式，往往是输出。但输出不一定是“请你复述一下”。这种方式太像学习软件，很容易让人烦。更自然的方式是：用户本来就要写东西、做方案、整理观点，胶囊系统把相关主题页带进去。

比如用户要写一段：

为什么 Embedding 能用于语义检索？

Hermes 不应该只给资料链接，而应该基于主题页帮他组织一版草稿。用户修改这版草稿的时候，就会把知识重新过一遍。这个过程比单独复习有效，因为它服务的是用户当下的真实任务。用户不是为了学习而学习，而是在写作、方案和判断里使用知识。

当然，这种方式必须要求用户对产出有责任心，即，他会去复核 Agent 生成的草案是否符合自己的预期。如果看都不看，直接拿去用，那知识就不会被内化。

所以内化不是单独的学习流程。它应该发生在用户的输出任务里：写文章、写方案、做课程、整理观点、判断一个问题。知识被真正用过以后，才更容易留在人的结构里。

5.5 当前判断保留主题页的理解状态

一篇主题页不能只有资料和解释。它还应该写出对知识的判断。不过这里的“对知识的判断”不是一个独立模块，也不是给每个知识增加注解。它更像主题页的一种写作要求：Hermes 在融合资料以后，要把这条知识线当前最核心的判断写出来。

这件事很重要。人真正记住的往往不是一堆细节，而是对这件事形成的判断。细节可以忘，后面还可以查；但判断会影响你下一次怎么解释问题、怎么写文章、怎么做选择。一个知识点能不能进入人的脑子，很大程度上就看它有没有被压缩成一个可以调用的判断。

这里要先理解什么是判断。

其实如果不做对比，定义和解释也可以作为判断。

比如上面表格中的定义“Embedding 会把文本变成一组数字向量”，你觉得是判断吗？是的，“Embedding 会 还是 不会”不就是一个判断吗？

你甚至会发现其实任何一个句子都可以被视作判断。那什么才是我们要的判断？

抓住核心的那些判断，才是我们要的判断。读者可以再反复阅读上面表格里的三句话，体会下为什么判断抓住了核心。

Embedding 会把文本变成一组数字向量。

这句话不够，但可以作为定义保留。主题页还应该进一步写出更有压缩力的核心判断：

Embedding 的关键价值，是把文本之间的语义关系变成可以计算的距离关系。

判断不是越长越好。比如写成下面这样，解释会更完整，但句子也会变长，未必适合记忆。

Embedding 的价值，不只是把文本变成数字，而是让模型可以在向量空间里比较语义关系。语义检索之所以可行，是因为相似文本在这个空间里通常会更接近。

真正好的判断应该短、有压缩力，能在用户以后解释问题时被调出来。用户以后再解释 Embedding，或者写一段“为什么向量检索能找到语义相近的内容”，思维里真正会被调出来的，往往就是这类短判断。

所以“当前判断”应该进入主题页。它不是资料摘要，也不是最终真理，而是这篇主题页当前沉淀出来的核心判断。这样的核心判断应该单独列出来，不能只是藏在正文里。否则读者会把它当成普通解释句读过去，不会意识到这是这篇主题页想留下来的判断。

当前判断不是永远不变的。新资料进入以后，如果发现旧判断太粗，演化层就应该修正它。比如原来只说：

Embedding 能表示语义

后面发现这个说法太空，就可以改成：

Embedding 把语义关系变成可计算的距离关系。

这句话仍然很短，但比原来的说法更有解释力。

5.6 主题索引提供知识结构的地图

搜索能解决“我知道自己要找什么”的问题，但不能解决“我知道自己知道什么”的问题。一个人要形成知识结构，不能只靠搜索。他还需要看到自己有哪些知识线，这些知识线之间是什么关系，哪些主题正在变厚，哪些主题彼此相邻。

所以内化层需要维护一个全局主题索引。它不是普通文件夹目录，也不是所有页面的机械列表。它更像一张知识地图：

大模型基础原理
├─ 文本表示
│  ├─ Token
│  ├─ Embedding 向量
│  └─ 向量空间
├─ 语义检索
│  ├─ 语义相似度
│  ├─ 余弦相似度
│  └─ 向量召回
└─ RAG
   ├─ 检索增强生成
   ├─ Chunk
   └─ 召回与重排

这个索引页让用户知道：自己的知识不是一堆资料，而是几条正在生长的知识线。当某条知识线逐渐变厚时，索引页也应该体现出来。比如“Embedding 向量”下面已经长出了 Token、向量空间、语义相似度和 RAG 这些相邻页面，用户不需要被系统追问，也能意识到：这已经不是一个孤立概念，而是一条正在展开的大模型基础知识线。

这种地图感本身就是内化的一部分。人脑里的知识结构，不只是记住某个结论，还包括知道某个结论属于哪条知识线，和哪些问题相邻。

现在主流的方式是做「知识图谱」，但我认为这是一个错误的方向或者是很多人误解了「知识图谱」的意义。没有人会花时间在众多星图点里去看一个个知识点的关联。

「知识图谱」更多的应该是一种存储方式，一种澄清知识关联的机制。它的本意不应该是为了给人阅读，而是应该像「数据库」一样记录关联，然后在具体的应用中来体现出来。

常见的知识图谱应用，最简单的就是类似「wiki」的相关词条。当人类在阅读一个主题时，会看到一些关联的词条，即使他不去点击这些词条，只是“扫一眼”，其实也对建立知识结构有裨益，如果有兴趣，能点击进去阅读，那是再好不过的了。

5.7 不是所有知识都值得内化

这里还要补一个边界：不是所有知识都值得内化。

尤其在编程领域，我认为绝大多数具体知识都不值得塞进脑子里进行内化，这是负担。

API 怎么调用，某个参数叫什么，某个框架今天推荐哪种写法，这些东西大多是工具性的、说明性的，而且更新很快。没有内化的价值。它们更适合留在文档、主题页、证据页里，需要的时候查出来用。

真正值得内化的，通常不是这些具体细节，而是更持久的判断和结构。

编程知识尤其要注意这一点。很多内容看起来很技术、很具体，但其实只是工具说明。把这些东西全部内化，人的脑子会变成一个过期文档仓库。

更值得内化的，是那些经验性质、持久性质、能够迁移到其他问题里的东西。

回到 Embedding 这个例子，具体某个向量数据库的 API 不值得内化，某个 SDK 的参数也不值得内化。但“Embedding 为什么能用于语义检索”、“向量空间如何承载语义关系”、“为什么关键词检索和语义检索不是一回事”，这些就值得沉淀成主题页里的核心判断。

所以内化层不是把所有资料都往人的脑子里搬。它真正要做的，是帮用户筛掉大量具体、短期、工具性的东西，把更概括、更持久、更能迁移的知识结构留下来。

知识结构一定要去伪求真，越精辟越好。外部 Wiki 可以很丰富，但人的脑子应该尽量得「轻」。

5.8 小结

本教材不会继续把内化层做成一套具体实现。

原因有几个。

第一，每个人关注的方向不一样，适合采用的内化方案也不一样。前面讲到的这些做法，并不是要求全部塞进同一个知识库里。有人更需要主题索引，有人更需要当前判断，有人更看重输出任务里的调用。真正使用时，应该根据自己的兴趣、工作内容和学习目标，选择几种合适的方案组合起来。

第二，现在很多功能都可以交给 AI 去实现。只要你想清楚了自己的方案，把需求描述给 AI，它就可以帮你把相应的页面结构、索引方式和写作规则做出来。也就是说，内化层真正困难的地方不是“怎么写代码”，而是你能不能想清楚自己需要怎样的知识结构。

第三，内化本来就是一个相对抽象、也很依赖个人环境的事情。即使我在这里演示一套具体步骤，换到你的资料、你的职业、你的写作方式里，也未必能很好复现。与其给一个看起来完整、但很难迁移的演示，不如把原则讲清楚，把具体组合留给读者自己完成。

所以，内化层在本章里更像一个作业。胶囊系统可以帮你保存资料、融合主题、维护 Wiki，但哪些知识值得进入脑子，应该怎样进入你的知识结构，最终还是要由你自己决定。

5.9 ■ 学点英语