关于知识管理的一点反思

最近一段时间一直在快速学习大量新的技术知识。AI、LLM、Agent、系统设计、云计算、软件工程，每天接触很多新的概念。我习惯把学习内容整理到 Notion 里面，通过建立不同层级的页面，把知识按照主题进行分类。

刚开始的时候，我非常享受这种方式。树状结构非常符合人的整理习惯，一个大的概念下面包含多个子概念，子概念下面继续展开具体实现。例如 AI Engineering 下面可以拆分成 LLM、Agent、RAG，RAG 下面又可以继续拆分 Retrieval、Embedding、Reranking 等。每个知识点都有自己的位置，整个知识体系看起来非常清晰。

从数据结构的角度来看，Tree 最大的价值在于表达层级关系，它天然适合描述分类体系。文件系统、公司组织架构、数据库目录、知识分类等场景，都可以很好地利用这种结构。

但是我逐渐发现了一个问题：知识树越长，深度越大，维护和复习的成本逐渐增高，高到我逐渐变得不想去维护和复习。

一个知识点刚开始可能只有两三层路径，但是当深入学习之后，一个主题会不断展开。我发现自己越来越不愿意打开那些深层节点。每次复习一个知识，都需要沿着固定路径不断向下寻找。随着树的深度增加，访问一个知识点的成本也随之增加。

我开始重新思考知识管理这个问题。

在学习数据结构时，我们知道不同的数据结构适合解决不同的问题。Tree 解决的是层级关系，而 Graph 解决的是复杂连接关系。随着知识体系不断庞大，Graph 会变成更好的选择。

例如 Embedding 这个概念，既属于 RAG 中的 Retrieval 模块，也和机器学习中的 Representation Learning、深度学习中的 Contrastive Learning 密切相关。如果把它强行放入一个树结构中，它只能拥有一个父节点。但实际上，一个知识点往往同时连接多个领域。

人的理解过程也是通过这些连接建立起来的。我们回忆一个知识点时，通常不是沿着固定目录找到它，而是通过场景、问题、经验或者其他概念联想到它。真正有价值的知识，并不是它在目录里的位置，而是它和其他知识之间形成了多少有效连接。

所以知识管理其实和软件工程中的系统设计非常类似。最开始，我们关注如何把信息存储进去；当规模增长以后，真正影响效率的是如何访问、如何检索、如何建立连接。

Notion 的树结构非常适合帮助我建立初始认知框架，让复杂知识变得有组织。但当知识规模不断扩大时，仅仅依靠树状结构已经无法满足长期学习需求，需要结合 Tree 和 Graph 两种结构：Tree 提供整体分类和导航，Graph 记录知识之间的关联。这也迫使我重新拾起 Obsidian，其实也是因为 LLM wiki 最近有点火。

讨厌 LeetCode 的我，一边唾弃死记硬背刷 LeetCode 进大厂的 2* 模式，一边感叹数据结构与算法思维的魅力：没有一种数据结构可以解决所有问题。优秀的系统设计，核心在于选择合适的数据结构表达真实世界的关系。

学习到最后，不仅是在积累知识，也是在不断设计一个属于自己的知识系统。而这个系统最终的目标，并不是存储越来越多的信息，而是在需要的时候，能够快速找到、理解并应用这些知识。

DIKW: Data -> Information -> Knowledge -> Wisdom