标签归档:YARPP

纯文本笔记管理的最大漏洞:关键词污染

单一的纯文本文件作为数据存储单元,本质上是个“双字段结构”,即文件名是一个字段,文本内容是一个字段。文件名本质上是个字符串,受到长度限制,一般认为超过 256 个字节会产生潜在风险。

在个人知识管理领域,不超过 256 字节的字符串一般不宜存储重要信息。因此,纯文本笔记(无论是txt格式还是md格式),主要通过文本文件内部“较大的那个字段”存储纯文本信息。

在文本文件中存储多维信息,本质上是对不同维度的信息进行降维。

以这个纯文本文件为例:

这是个典型的卡片式摘录,存储了一个小的知识点:损益表和利润表的名称变迁。这样的文本内容,看起来没有大问题。但当问题复杂一点的时候,事情就会慢慢起变化。

这个卡片是阅读《以交易为生》这本书的摘记。笔记的内容讲的是心中没有主见、定力的人,到处寻找“救世主”。如果希望这个卡片可以在以后复用,除了通过 Random 函数随机碰撞复现,大抵是需要通过关键字检索的。这个时候,可以把原来的关键字:

tags: 
#《以交易为生》
#Alexander_Elder
#Y2013

扩展到:

tags: 
#《以交易为生》
#Alexander_Elder
#Y2013
#心态控制
#救世主

如此即可实现在探讨“救世主心态”或交易中的心态控制时,挖掘到这张卡片。事情发展到这里,so far so good。

但是,当另一个研究课题摆在面前时,事情会变得不一样:如果这时候的研究命题是,交易中的技术分析,我用“交易”这个关键字在卡片库中搜索,所有来自《以交易为生》这本书的卡片,由于书名中包含 交易这个关键字,这本书中所有的摘记都会被搜索出。在没有 Devonthink 或者 YARPP 这样的关联计算软件或插件介入时,整个搜索结果会被严重污染。

这一切的根源还是来自于前文的那句话:

在文本文件中存储多维信息,本质上是对不同维度的信息进行降维。

一个读书笔记卡片,或者叫摘记卡片,包含的信息是不同维度的:

  • 内容,即正文;
  • 出处,包括书名、作者;
  • 摘录的时间点;
  • 对主题的概括,以备“搜索”或“聚合”用
  • 批注

这些不同维度的数据,统统压缩到文本文件的文件内容中,以纯文本形式呈现,将不可避免地产生“关键字污染”。现在的新书书名有很长,作者都有“关键字意识”。比如这本书:

这本书里出现的一切奇闻异事、个人感受、名言警句,都会出现在“印象笔记”和“Evernote”的搜索结果中,而无论彼时彼刻的那张卡片、那条笔记究竟是否与“印象笔记”和“Evernote”有关。

这个问题,通过纯文本文件管理笔记,无法克服。这不取决于是否应用了 Markdown 格式,也不取决于是否自主掌握笔记内容,这是整个知识库的底层技术选型限制的。

目前的公共讨论空间,确实存在这样一种误区:

  • 长期有效的知识管理,一定要自己掌握数据;
  • 而自己掌握数据,一定要通过纯文本文件本地存储。

前一句话没问题,后一句话将所有权归属的问题,误读成了技术选型要用 Markdown、纯文本格式。我个人并不反对以纯文本保存信息。这是种很干净的格式,也是历久弥新的长期有效通用格式。但个人知识库的实质并不在于讲知识(无论是否是卡片形式或者“元素化”的形式)保存在硬盘。

知识库的本质是历久弥新。这个角度看,知识库就是“数字花园”或者“知识花园”,需要播种收获,需要时常翻土。指望着一次性烙进去一个文本文件,就巩固了一个知识点,是一种战略上的懒惰。

在前面《关于笔记的再思考》一文中,提到了一种以 WordPress 为核心的知识管理模式。这种模式完全可以通过只有的域名、租用的服务器、通用的 WordPress 平台以及自动化的网盘(及本地)备份实现“自主掌握全部数据”。而从数据存储格式上看,sql 数据库格式的年龄并不比 txt 文本文件的年龄小很多,而世界上 43% 的网站份额也决定了无论是开源社区还是插件市场,WordPress 都不会比任何一款“笔记软件”或“个人管理软件”差。

在结构化的 WordPress 平台上,Category 分类和 Tag 标签完全可以对内容实现“京东自营购物”似的筛选、过滤、搜索,全文检索数据库也不需要从中文分词的角度做出任何二次开发。很多时候,找出一个,或者是一类内容,甚至不需要通过搜索框。这背后的底层逻辑是,WordPress 是基于 SQL 数据库技术的、多维度、大容量的内容管理(分发)平台。

这才是目前个人知识管理最好的选择,也是解决前文所述的“关键词污染”这个纯文本系统固有缺陷的直接办法。当然,WordPress 的技术门槛比起 Obsidian/LogSeq 是略高一些的。这是另一个话题了。

原创文章,转载请注明: 转载自风云居 | Less is more

本文链接地址: https://kangjian.net/blog/2340/