前言
这篇文章重点是两个: 讨论一些能跟 Obsidian 协同工作的知识库类工具, 能以什么样的成本, 解决什么样的问题?
其中 “要付出的成本” 指:
- 折腾这些新工具要花的精力
- 容易被忽略的隐形成本
- 执行嵌入和对话的时间和钱
- 可能的问题点, 追查分析这些问题的难度
- 在已有知识库上持续维护的开销
其中 “能解决的问题” 指:
- 构建本地个人知识库, 这真的有用吗? 具体怎么个有用法?
- 哪些使用场景，哪些笔记内容和笔记组织形式, 最适合用知识库?
- 哪些使用场景收益不大?
- 做到什么样的效果是可以预期和争取的, 什么样是期待过高别指望的?
- 有啥是用 Ob 搞知识库的独有收益, 以在线知识库不太好替代的?
本文尽量回避技术名词, 且不准备长篇大论具体的插件细节
知识库 RAG 是怎么回事
这一段写给不了解的朋友, 现在这些 RAG 知识库 等词到底是啥东西
RAG (中文叫检索增强生成) 是解决大模型缺少私人知识的途径之一. 就是当提问时, 工具自动把你文档中最合适回答问题的几个片段提取出来, 拼一大段话交给聊天模型, 让它据此回答问题, 大概等同于让模型 “根据你提供的几段背景素材去写作”
所以叫 “检索增强生成”: 首先根据你的提问 检索 文档里合适的背景知识, 把这些知识提供给聊天模型, 以此 增强 聊天模型 生成 文本的质量
那这跟知识库啥关系? RAG 是实现知识库的一种手段
知识库这词, 当前含义非常含混, 往小了说把一堆同主题文档搁一块儿就是知识库; 往大了说得弄一堆复杂的 RAG 框架加智能体工作流编排, 这也叫知识库. 这里事先声明, 本文讨论的是 “基于个人收集整理的笔记的, 能利用仓库里全部知识来回答用户提问的文档系统”, 但这定义太长了, 得给它取个短名字, 我们可以管这种笔记系统叫… 算了, 就叫知识库吧
个人造知识库困难在哪
我自己的理解: 依赖组件多, 如何搭配得自己琢磨, 中间执行过程漫长不透明, 对能实现啥效果有过高期待
这个东西跟编程不太一样, 比如说写脚本, 如果报错了几乎肯定是自己写的不对, 极小概率是编程语言 bug, 且无论写对写错, 脚本的运行反馈是明确和及时的. 但是 RAG 系统不像编程, 更像是 DIY 电脑, 最终没搭起来可能是买的零件型号不对, 也可能某设备就是坏的, 且退换货很慢必须得事先计划好
个人 RAG 系统的使用效果也是不好描述的. 企业级的问答知识库可以搞定量分析, 可以说这么改动让用户满意度上升 5%, 但对个人知识库这些量化手段的意义是很小的, 最后效果如何主要还得凭自己感觉. 于是这就不好交流, 代码错了可以贴出来问网友问 AI, 而造个知识库回答效果不好, 这该怎么问人呢?
好, 如果看到这里你仍对此有兴趣, 以下讨论我认为最重要的几个话题: 先聊聊知识库能做啥, 再说使用中可能遇到什么问题
个人知识库的需求和定位
更精确的说，对于以 Obsidian 笔记为核心的, 以单人力量搭建维护的, 索引文档后基于全局知识做问答的知识库, 目前能拿它做啥? 目前还不能做到什么?
以下每个小节都讨论一下适合做的, 以及相应的不适合做的事, 希望未来我能重写这些内容时, 能把更多条目归到 “适合做/能做” 这一栏
适合哪些使用场景
连查带写 你不仅需要搜索资料, 还得接着搜索结果做总结比对或续写下去
- 找论据: 想要表达 xxx 观点, 找下以前那些 xxx+yy xxx+zz 的记录, 梳理完善
- 提取资料: 记录过 xxx yyy 的对比, 把其中价格部分简单列出来
- 编程: 找一下 xxx 程序里 yyy 的写法举个示例 (编程类场景太多了且不一定用 Ob, 本文尽量少举例编程类话题)
- 基于特定背景知识改写: 这段文字 “…” 里提到了许多术语, 根据库里资料把拼错的名字改改, 带链接的都给加上
这些都属于很朴实的需求, 形式多变, 任务难度有大有小. 要说这些任务不通过知识库能解决吗? 对于其中一些任务, 你手动找找关联笔记, 文本复制到在线网页模型里也是能干的, 但也有不少情况, 最花精力的就是去找到这些合适的文本片段. 如果这类需求很常见, 就值得拿 RAG 优化一下速度
无关键词回忆 要找的东西已经完全想不起来叫啥, 只记得肯定有这东西, 名字就在嘴边
- “有个工具网站上传字体的看里面字体高级特性 font-family 的是啥”
- 目标是查到 Wakamai Fondue 但真的记不住这网站名字
- “有个 ob 插件 只有原型 在纯文本上摘抄批注 特点是划线后不影响原文内容 左原文右摘录能同步显示的”
- 目标是查到 Latticework 这也属于完全想不起来名字
以上使用笔记库的传统搜索能找到吗? 比如第一个问题, 我会搜 字体 网站 css 特性 font-family 多搜几次我也能找到, 但这具体场景我会倾向于先拿知识库搜 (你可能会问, 为啥你这信息都藏在无名角落里, 而没有整理到比如 字体知识 > 字体 css 高级特性 > 在线预览工具 里让它能直接访问呢？因为懒呗)
“无关键词回忆” 场景很多吗？我觉得是 “不算很频繁”, 因为大家都有多年搜索经验, 都知道啥关键词好搜啥不好搜, 对于 “名字不好抓住的知识点”, 写笔记时就会留好关键词
彩票式搜索 我指对大概率不存在的知识的搜索, 此时能否找到结果不抱啥希望
- xxx 有没有说过 yyy 的事, 是啥观点?
- 几个因素 xxx yyy zzz 之间的是否存在相互影响?
传统的搜索方式, 如果写上太多关键词会 “未找到结果”, 与这直觉相反, 向量嵌入的相似度计算不会返回 “没找到”, 它永远会按照库中文档的 “最相关到最不沾边” 排顺序, 把前几个文档提供出来
彩票型的搜索需求, 特征是主题跨领域, 关键词模糊, 对结果相关性也不要求很精确, 主打一个搜到就比没有强, 这些场景老实说 RAG 也未必能做的多好, 但传统搜索做的更差
查找资料且不打断当前笔记
对于一些较简单的搜索任务:
- 传统关键词搜索 复制当前笔记里关键字 => 复制到 Ob 搜索栏 => 增删关键词 => 重点查几条列出来的笔记, 过程中记得锁定工作笔记或利用任何新窗口预览机制, 以防当前窗口被替换掉
- 使用 RAG 插件搜索 复制一段描述 (含关键词就行, 允许携带些无关文字) => 后面写上要问的 => 贴侧栏对话里让它搜着 => 这时就可以继续忙当前笔记的事, 待会儿检查结果就行
这有点像是亲自做事和外包干活的区别, 后者可能不如亲自动手效率高, 但能分担一些杂务, 避免关键时刻分散注意力
此外所有 AI 聊天插件都支持历史对话存档, 那这就是个自动生成的临时笔记了, 记录着该搜索任务的全部信息, 未来再次翻找时很方便
不适合的场景
所以反过来, 在 Ob 的笔记库上叠一层知识库, 不适合的场景就是下面这些:
- 搜索需求过于简单和明确：你只需快速看一眼搜索结果, 之后不再需要加工, 此时 RAG 再快也没传统搜索快
- 笔记有精心编制的分级导航和快捷入口：…也包括笔记有合理双链和完善的标签关键词等等, 你近乎直觉的操作自己这套笔记系统, 三两下点击就能去到任何一处关键笔记, 此时知识库的收益有限
- 问题是非常困难的开放式的：RAG 不是掌管知识库的神灯精灵, 不能理解复杂逻辑, 不懂得对你而言显见的背景潜藏知识, 想要让它 “与仓库主人很有默契的” 输出满意回答并非易事
- 对知识库搜索或查看的需求不够多：我认为这是搞个人知识库的最大障碍, 比如公开知识库, 哪怕用户是半年才用一回, 这产品也有动力维护优化, 因为是给全网用户服务的, 但个人知识库要是利用次数很低, 搭建维护的精力就不太值得
- 需要智能执行操作 比如让 AI 协助重组你的笔记, 把之前写过的所有关于某主题的零碎都挪走, 自动推荐软件设置, 改善主题样式, 这 Ob 插件的功能给改成我想要的并重新加载一下…, 这些未来也许会有但现阶段还没这么智能 (一些编程类的 AI 工具在做这个, 比如用户审批之后自动创建文件运行脚本等等)
所以建议看到这里的大家, 认真的评估自己的使用需求, 对 “我如果搭建知识库, 是想要这套新系统帮我做到什么?” 有个大致的想法
擅长回答哪些问题
适合问知识库的问题:
- 对确定事实的查询, 描述越多越好
- 对自己记录对话思考的回忆, 提到线索越多越好
- 现成案例的模仿, 根据当前信息找个类似参考样例
简单的 RAG 框架里, 其召回模块 (Retrieval) 大致还是个关键词搜索, 但它搜的就好像是 “向量视角下的模糊的关键词”, 特点是能容忍同义词替换, 支持口语化表达, 兼容轻微的拼写错误, 以下是一些实例:
- “之前记录过一个作者写笔记应尽量起准确清晰标题的 找找那篇叫啥”
- 其中有用的信息是 “写笔记应尽量起准确清晰标题”
- 结果: 找到 Andy Matuschak 的文章-常青笔记应该是原子化的, 文章-笔记标题建议使用完整的句子避免模糊主张, 文章-常青笔记的标题就像 API (挺成功, 只想要一篇, 好家伙全给找出来了)
- “给列出几个 dataview 读笔记内容 await fileload 的写法样例”
- 写的是
await fileload想要去找await dv.io.load - 结果: 最后有可能实际找到了
await app.vault.cachedRead(没关系的, 都一样)
- 写的是
- “Ilya Sutkever 和 Yang leChun 观点啥区别?”
- 名字一口气全拼错了, 但这种小错不会影响它理解意图, 一般都能返回自己想要的
有人会觉得, 举例这些问题也太简单点了吧? 这是因为 Ob 现在几个插件当前 (2025-01) 确实没有复杂的 RAG 功能, 回答不了非常难的问题. 且插件们也没说自己是专为解决复杂查询的, 而都是定位在: 笔记库辅助, 发现笔记关联, 增强笔记写作, …, 对全笔记库提问的功能好多插件都做了, 但也只算功能之一
至于向知识库提问 “难题”, 有些 CRAG 项目给问题分类成为 Simple / Simple with Condition / Set / Comparison / Aggregation / Multi-hop / Post Processing / False Premise 等许多种, 其中 Set 是找全一组满足条件的对象, Comparison 是两个实体的属性对比, Multi-hop 是多跳查询且子问题有互相依赖没法并行查找, 等等. 比较难的问题别说 Ob 插件了, 拿专门搞 RAG 的系统也未必能答的多好, 见下面一节的讨论
不擅长的问题
需要多步推理的问题
给出的查询词跟希望匹配的 chunk 之间没有字面关联时, RAG 很难找回合适片段, 举个夸张的例子:
- “我常用的笔记软件的几个主要画图插件分别在哪些细节上对软件自带同类功能做出了创新和改进?”
这问题属于看似提供了丰富信息, 且每处都很好懂, 但向量召回就是做不好, 挨个解释一下:
- “我常用的笔记软件” → 在这里显然指 Obsidian, 可惜向量相似度查找时没这种推理能力, 向量查找只大致认得 笔记软件 会跟 Obsidian 有点关联, 因为讨论 Obsidian 的文档一般也有 笔记 软件 这些词
- “几个主要画图插件” → 事实上还可能召回一堆 Chart 类插件的信息, 而不是 Excalidraw
- “软件自带同类功能” → 这任务需要推理, 笔记软件指 Obsidian => 主要画图插件指 Excalidraw 等 => 软件自带同类功能: Excalidraw 除了画图还能排布笔记段落, 所以用户可能是指 “白板”
- “创新和改进” → 这需要召回功能简介甚至得有功能明细, 才好让聊天模型讨论 “创新点”
如果我执意这么问, 最后回答效果呢? 取决于仓库里含这些内容的笔记, 跟讨论其他内容的笔记, 语义距离有多远
- 如果仓库里大部分都是自己专业领域知识, 然后有一小撮笔记写着 Obsidian Excalidraw 用法白板用法啥的, 那这么问还真能得到一个有点参考价值的回答
- 如果仓库里写了大把的各种笔记工具外加各种插件的知识, 那这提问方式就悬了, 向量召回会随缘拿到一些介绍各种软件插件的片段, 然后聊天模型就对着这些 “似是而非的素材” 硬解释一通
注: 用户想这么提问当然是合理需求, 我只是解释简单的 RAG 系统搞不定这种难题 (下面几节也是如此, 不再重复说明了)
需要数据库协作的问题
- “查我最近一周日记里都干了什么”
一些带工作流编排或带 Agent 的工具, 会分析你这查询的意图, 然后自动调用合适工具, 取出结果交给 LLMs 总结, 但是简单的 RAG 工具对于这种查询就是随机给召回几个日记
解决方案:
- 这种找 “最近一周” 的活儿还是先交给 dataview 和 tasks 等插件吧
- 涉及笔记不太多时也可以人工提供上下文: “把
[[daily-2024-12-xx]] 和 [[daily-2024-12-yy]]里的想法总结一遍”
隐含着大量背景知识的提问
- “推荐个好吃的? 就是我上次想买忘了买的”
- “莞莞类卿, 卿是谁?”
大模型的有效回答依赖于合理召回文档片段, 召回文档片段依赖于问题跟文档片段的语义关联 (也有些 RAG 系统是关键词和语义混合召回的) 所以意图模糊的提问, 太短的提问, 要求推荐但不写出来具体需求, 使用了太多的小众领域行话的提问, …, 这些都无法召回最需要的片段, 导致 RAG 回答效果不好
可能不熟悉的人会有个误解: 以为笔记里用上 RAG 就可以 “花了十分钟完全了解这款仓库” 了
不是的. RAG 并没有 “在你仓库里一边读, 一边悄悄记录下来: 哦原来你是这样的人, 哦你三天前吃了啥, 哦这目录里全是关于啥主题的, 好了全记住了你随便问吧” 的机制. 此时的聊天模型仍然不知道你私人知识, RAG 只是在你提问后, 默默把跟问题关联素材临时收集起来, 一起发给那个 “大家公用的” 大模型
而同时具备着 “世界知识 + 内化了私人文档知识” 的模型, 这目前还是很难搞, 且有成本高, 更新慢, 无法溯源等等问题
解决方案:
- 需要在问话里提供足量信息, 需要堆积关键词 (甚至可以过量罗列关键词)
- 频繁调查某类问题时, 可以考虑精心构造一个 prompt, 把自己需要让模型掌握的背景知识全写进去
否定性问题
- “找出反对 xxx 观点的论据”
向量搜索能一定程度上理解含义, 但更多时候是把正方反方观点一股脑抓过来 (导致符合意图的片段排序不靠前). 与当今的聊天模型智力相比, 向量模型智力很差, 召回时能满足 “语义大致相关” 就行了, 否定也算相关, 别指望太多
之后聊天模型接手时, 基本不会误解提问者意图, 所以不算特别严重
解决方案: 一些复杂的 RAG 流程会尝试精排这些召回片段, 如果你手头工具没这么复杂, 可以试试改一下查询用词比如 xxx 有哪些不太好的地方 => xxx 有哪些问题和缺陷 效果能稍微好一点点吧
跟大模型的技术局限有关的问题
- “9.11 vs 9.8 哪个大”
- “草莓里有多少字母 r”
解决方案: 不跟知识库问这些. 即使能靠一些文档片段把它回答拗过来也没必要, 这些是大语言模型内在机制所致, 我们知道大模型局限的一面, 然后善加利用它优势一面就完了
无法简单验证的提问
- 要求找全: “把所有的关于 xxx 的想法全都列出来?”
- 要求找到最佳: “对于 yyy 做法最接近成功的三个例子?”
- 要求整理顺序: “zzz 最近一年的关注兴趣点怎么变化的?”
目前的 RAG 从机制上很难做到 “所有”, 只能做到 “随机的一些”, 至于 “最接近成功” 这换真人来做, 也不好保证说他理解的 topN 一定正确
解决方案: 问之前就想好自己能否查证这个回答, 对于不好精确查证的, 能简单看个大概脉络其实也算有用
此外 需要高层次的全局理解的问题 比如小说通篇的隐藏脉络, 这种抽象逻辑难以被 RAG 简单提取, 这些很好理解不多说了
契合的笔记风格
适合用于构造知识库的比较理想的笔记形式是:
- 大部分笔记 不会太长 (几千字, 更方便在聊天对话里组合引用, 不会爆掉上下文)
- 笔记有 清晰准确不重复的文件命名, 有 划分得当的各级小标题 (有利于正确切分 chunk)
- 笔记有 丰富的文档属性元数据, 例如标签, 摘要简述, 主题领域, 元数据跟标题差不多重要, 一般会存到每个 chunk 里, 这类数据在向量相似度计算时可能也被算进去
- 笔记 每个局部都尽可能的自我描述, 笔记的具体段落里大量提及主题而不用指代词 (指代词例如: 它, 该软件, 之前文章提到)
- 例:
[下一篇：对某话题的某细节的继续讨论](https://xxxxxxx)要好于[下](https://xxxxxxx)
- 例:
- 笔记放在规划好的多级子目录里 (有些 Ob 插件可以用指定
{子文件夹}的形式限定检索范围)
文档的内容形式不一定完全归我们控制, 以上要求难以全都满足, 只能说是大致参考一下
根据上面特点, 容易想到各类技术文档, 工具书, 字典型或维基型的资料是合适的, 这些文档从编制时就是为了人们扫读而设计, 会有很多跳转, 小标题, 索引, 且提供了大量关键词以备搜索
此外, 还有一类文档虽不太满足上述适用条件, 但拿传统搜索更加难搞的: 例如聊天记录, 其特点是话题转变快, 误拼写较多, 同一话题被反复提到很多次, 关键词藏在换行前后的零散几句话里, 这些都是运用传统搜索的阻碍, 而向量搜索就还算合适处理
不契合的风格
- 仓库里是 少量的巨幅长篇文档 (麻烦之一是
参考这个 [[一篇超长的文档]] 回答以下问题时, 聊天模型会超过上下文) - 对象名称和具体描述内容分离很远 (比如有几十篇笔记, 每篇里都写着
### 优点### 缺点而具体讨论的是啥? 只在很长一大段文字前面出现过一次) - 排版过于混乱复杂 (分块时无法找到准确的切分位置, 无法把知识单元划在一个 chunk 里)
- 许多重要内容 不在 markdown 里, 而是各种画板, pdf, docx 等格式 (主流 RAG 知识库工具基本都支持办公文档, 但 Ob 插件以及代码类 AI 工具对后面这些格式支持较差)
- 文档总是被修改 以及文档属性 YFM 总被自动修改 (大多数工具一看到笔记更新时间变化就会重索引, YFM 变化可能会使涉及 chunk 总是重新计算嵌入)
以上很多都属于文档内容如此, 没办法调整
推荐几个实践满意的知识库?
比较满意的库
我自己实践起来最满意的几个库是
技术类文档 这个好理解, 也最容易想到. 比如收集一大把 Dataview 文档后问一些脚本问题 (本文尽量不举例编程类, 而且这些可以找代码编辑器去解决, 不一定非得 Obsidian)
日记 零散的知识片段, 跳跃的思考, 缺失上下文的摘抄, 模糊的临时记忆, 表达不准的聊天片段, 这些都很契合向量检索召回. 总体来说感觉使用效果还不错, 有个小问题在于 dailynote 笔记标题全是 2024-xx-xx.md 的命名, 于是显示的 “关联笔记名” 根本分不清这些都是啥
超大型的跨领域仓库 其实就是多主题仓库联合, 话题越是涉猎广泛, 越适合向量语义搜索, (向量嵌入是对整个世界知识的, 在单个细分领域内的语义分辨率不足, 而对大范围知识的分辨水平较好), 另外当资料多时, 人力对大堆搜索结果挨个翻的效率劣势逐渐显露, 但语义搜索几乎跟小仓库一样快
我还有个感觉是, 在巨量资料时你关心重点就不是 “一定找到最好的文档”, 而是找到能用的就行了, 道理跟网络搜索一样, 不在意也没法控制能否搜到全网最佳资料, 重点会在意管用就行. 这种不争局部细节, 关注总体可用度, 通过堆数量增加容错的风格, 其实跟向量搜索有点类似
还算不错的库
陈年旧笔记 就是那种从别的笔记软件转出来的一堆 md 文档, 格式可能很乱, 能带个目录索引就算不错, 没有文件间导航 (没有双链, 没有关键词标签) 这种其实本来也不会常看了, 改造成知识库属于 “捡起来洗洗还能吃啊”. 实践发现自己确实忘了相当多的旧知识, 有点 “当代科技不如上古遗迹” 的感觉
别人整理好的现成文档 Github 上有各行业的大把资料, 从内容到形式都适合弄下来做知识库. 为啥只说 “还算不错” 呢? 因为这都是公开就能看的, 如果利用频率低不如网上搜一下就完了, 比自己造库省心. 只有切实需要频繁研究这些资料, 且还准备加些自己的见解进去时, 给做成本地知识库是好主意
艰难的领域知识 比如数学物理等, 特点是无论你用不用 AI 都很难学会, 当前的 AI 理解高层次含义的能力太过粗糙, 最后主要还是拿它查仓库里的具体知识 (这跟从网上查也没啥区别)
这里也体现了 “知识库” 跟 “笔记库” 的一个动机差别, RAG 擅长在海量信息里快速找到你所需的, 但在笔记软件里, 其实有相当多的 “加深理解, 加深记忆” 需求, 这跟 “能高效查到事实信息” 只算是有一部分联系
总之无论如何, 我们仍然得老老实实去构建自己的理解. 但相信很多朋友都已发现 AI 当学习伙伴挺好的, 可以问它特别傻的问题, 还可以问 根据 [[一些很难懂的博客文章]] 里的资料, 我这个 [[xxx学习笔记]] 哪里理解错了 之类的
失败的库
重视阅读体验的文本 主要是虚构类例如小说等, 或说一切不像文档那样可以扫读跳读, 而是需要用心思, 按顺序, 逐步读全程的文本. RAG 有时给我一种 “这些知识已能从高处掌握” 的错觉, 容易踏实不下心去面对具体细节. 事实上, 下载一堆书不看, 注册一堆课不学, 造一堆知识库不用, 都是差不多的行为
给已经读过的书造库还是可以的, 回忆不准时可以从里面搜点资料出来, 但这需求不算很多
收集 RAG 资料的库 这也是技术类文档啊, 为啥说失败这不跟上面写的矛盾吗? 其实这个库是想尝试自举, 我一边收集资料一边改进 RAG 系统自身, 然后我这套系统就能越用越厉害~
结果: 效果远不及我当初设想的
- 教训1: 变化太快的领域, 得额外花精力抓取更新资料, 于是造库, 修改库参数, 向里面放更多资料, 学习记录笔记, … 这些难吗? 单看每一项都不难, 问题是同时做就很分散精力
- 教训2: 当只需要外行的初学者见解时, 没必要弄知识库 (这时甚至提不出啥有效问题) 就网上搜一下就完了
- 教训3: 改进 RAG 时要深思熟虑, 谋定后动, 不能指望说 “唉效果不行啊我试试改下这个参数吧之后肯定特别好”, 然后就频繁折腾整个仓库的重新嵌入
- 教训4: 在细分领域的术语里, 这些 xxxRAG xxyRAG yzzRAG 的区别是至关重要的, 但在向量嵌入视角上这些词都长得差不多, 这也是为啥一些知识库会使用结合了关键字+向量的混合检索
正在尝试的库
用于搜索视频的库 拉取时间轴字幕和视频的评论区, 构造好提示词让 AI 生成回答时能直接指向我需要的视频时间戳, 这么搞也许是有点用的, 需要试试才能知道
双语阅读的库 实际上许多技术类文档也是中英双语阅读, 效果还不错, 这里的双语指的是古文翻译或者学习外语等等
具体流程方案的取舍
自建知识库的收益
这是个必须想清楚的问题：有啥是在本地自己搞一套知识库的独有好处, 而以在线知识库不太好替代的?
首先想到的自然是隐私, 数据权利归属等问题, 这些都十分重要且好理解, 这里不讨论了
除掉隐私问题后, 我把这问题分成两部分:
- 自己或小团队的知识库 vs 公共的知识库, 选前者有啥好处?
- 以 Obsidian 插件形态提供的知识库 vs 纯文本跟 Ob 无缝协作的知识库 vs 部署后需要把文档上传的知识库, 选前者有啥好处?
先说第一个问题, 为啥要自建知识库? 我觉得关键优势是: 内容随时增删, 兴趣点变化了能追加更新, 你对入库资料都把过关
实际用时我感觉这类 RAG 系统非常烦人的一点是, 如果你没搜到, 很难知道 “是库里真没有, 还是自己搜的不好” 这事对于网上和本地知识库都很难, 但如果资料都经过你手, 对于啥该搜到啥不该搜到心里会有数, 能部分缓解这个困境
此外自建库的检索范围可以更细致, 许多工具支持 “仅针对指定目录提问 @Folders”, 支持标记某些内容有额外权重, 这些都依赖于对入库资料名单能够完全控制
从另一角度, 选取哪些文档入库也是关于自己口味, 说严肃点就是关乎品位和取舍, 以及在万千同类资料里唯独见到过手头这一份的相遇之缘
知识库的形态
接上一节, 刚才说的是文档内容, 现在说工具形式, 由简到繁讨论三大类工具:
- A 以 Obsidian 插件形式提供知识库 (例如 Copilot 等)
- B 能加载本地纯文本的, 跟 Ob 自由协作的知识库 (例如 Cursor Cherry Studio 等)
- C 自身是一套完整解决方案的, 文档需要专门上传到它系统的知识库 (例如 Dify RAGFlow 等)
以上各自都有啥好处, 怎么取舍?
第一类 以 Ob 插件形式提供的工具
它们对 Obsidian markdown 的结构理解更好, 切分 chunk 准确, 有些还会利用 Obsidian 自身机制 (例如 Copilot 在展示相似笔记时会考虑反链和出链的权重) 此外 Ob 插件不只有对知识库提问功能, 在后面 “多样化使用” 的部分会提到一点
它们目前主要缺点是作为知识库时, 搞不定困难提问
这里多说一句, 智能型插件以后有个潜在可能性就是插件间可以协作, 这本质上是把 Ob 当成平台来用了, 想象一下以后某个 AI 插件发展到如下这样子:
“嗯, 用户对刚才的解答表示不满意, 我得想想这是为什么, … 需要准确过滤信息, 我看到用户已经安装了 dataview 插件, 我可以编写一段脚本找出… 好的, 通过 dataview 我找到了一些有用的, 此外还可以结合用户近期访问量最多的几个笔记标题, 这些标题是… 现在, 让我来重新猜测用户的准确意图…”
这不就厉害了么!
第二类 能加载纯文本的本地知识库软件
知识库工具 (非常多, 在 Ollama README 页面搜 Desktop) 通常操作界面优秀, 具有很好的设置引导, 在模型配置上省心, 适合新手. 且一般还支持 pdf docx 等等
编程类工具在复杂的自动交互上毫无疑问跑在最前面, 前两年 AI 是嵌在编程软件里的一个自动补全模块, 现在的 AI 可以协调软件的多个模块来干活儿. 至于编程类工具在笔记库里的应用, 我目前理解主要价值是它们都有极丰富细腻的上下文控制, 能具体操作一小段文字, 文本变化时能看到极其详尽的 diff 展示. 至于自动生成特定笔记啥的也许有用吧, 现在还用不熟
对于知识库的用途, 我比较希望这些工具能监控目录自动重做嵌入, 不要到用时才更新索引, 跟 Ob 协作时它应该是时刻备好的, 需要时就立刻派上用场
第三类 完整的知识库解决方案
主要面向企业, 部署条件高, 设置复杂, 从设计上就明确区分了知识库 “用户” 和 “后台管理者”
支持最全的文件格式, 支持逻辑复杂的问答工作流, 使用了大量的高级 RAG 技术, 管理者可看到内部所有 chunk 的召回信息, 可以调节具体 chunk 的标签或权重…
但是不会特别重视 markdown 格式, 拆分块时基本就跟对待 txt 一样剁碎就完, 未必会关心 markdown 小标题的额外权重或 YFM 文档属性等等
此外一个麻烦是, 这类方案距离 “笔记的生产端” 太远了, 无论是后期添加更新文档还是每次切换过去使用, 都欠着点对数据的掌控感
对功能的权衡排序
当前阶段, 对于 Ob 内以插件形式提供的知识库, 我自己更关心的功能排序是: 1 响应快速 > 2 执行流程透明 > 3 输出文本能溯源 > 4 提供功能灵活多样, 以下分别解释:
迅速响应的需求
要求访问便捷, 需要用就立马能用上, 避免出现以下情况: 想用知识库回答某个简单小问题 → 发现少几个关键文件没被索引 → 赶紧让它上传索引 → 咦嵌入模型出问题了? 解决一下吧 → 解决了, 等着索引, 好慢啊 → 不等了我还是传统搜索吧
等这问题过去了, 通常就会忘了优化这流程, 于是下次遇到又循环一遍
- 这也是为啥说, 在性能差的机器不太推荐 Ollama 因为要用时, 每一次加载时间都是阻碍
- 这也是测试 RAGFlow 时我的感受, 这类工具是给企业用的, 我个人用时即使一想到 “要把它这个巨大 docker 启动起来”, 我心里都得克服困难 (后来 RAGFlow 出了个 slim 版, 好一些了)
- 这也是以 Ob 插件造库而不另选工具去造库的一个优势, 我估计大家重度使用 Ob 都是一整天不关的, 里面无论啥 RAG 插件也就在最开始有个加载时间, 之后就不担心启动速度问题了, 且笔记变化后就会自动重新索引
流程透明的需求
要求能明确看到每步发生了啥, 文本块怎么切分的, 怎么召回的, 提示词每步都给拼接成啥样了, 越直观越好
因为当前阶段的 RAG 说实话没那么智能, 当前阶段大部分用户也对 RAG 优势和弱点 (以及跟自己文档的适配度) 一头雾水. 能多看到点儿中间步骤明细, 就有利于分析到底是哪里做错了, 是我提问的不好? 是默认提示词不合理? 召回的块太混乱了? …
此处顺便说一句, Ob 里几个 AI 插件大都提供了 debug 模式, 建议随时开着方便排查
溯源的需求
这意义无需多解释, 理想的效果参考各种能联网 AI 是咋显示参考资料的, 就是每句话后面有角标来源参考, 点击能在侧栏显示网址的那种
即使做不到最好, 聊天框回复文字时也要求尽量 “精确溯源到笔记具体段落”, 这要好于 “只提到参考了哪些笔记名字” 以及远远好于 “出处在哪完全不写”
那要是我插件或工具没带精确溯源的功能, 咋办? 可以提示词里写: 请一字不漏复述原文的关键短句, 并搁在引号里, 先凑合用用
多样化使用的需求
有效利用 AI 是需要磨合和练习的, 对那些惯于以搜索引擎查资料的人更是如此. 如果插件提供多种功能且出现时机符合直觉, 要用时交互顺畅自然, 就更容易养成习惯, 后续也好想着优化改进. 我自己的体会:
- 比如 TextGen 设计成双空格就自动续写下文 (我给它提示词改成了简要解释光标前的词, 遇到不懂的用一下看完就删, 很方便)
- 比如 Smart Connections 选中笔记就自动做相似推荐 (现在 Copilot 也有同款功能了)
- 比如 Smart Lookup 搜索框 (对用户的查询词只做语义近似搜索, 但不把对话发给 LLMs, 即只做 RAG 前半段)
以上这几个小功能挺好用的, 它们要么被动起效, 要么操作简单好理解, 尝试起来完全没压力
好了说这么多, 为啥不提 RAG 的复杂技巧, 为啥 RAG 问答的准确程度不放在主要考量? 为啥不聊聊重排模型和知识图谱结合 RAG 以及 xxxRAG yyyRAG? 因为当前 Ob 插件里没几个做这些的啊
几个容易忽略的问题
这部分写造库的代价
这些 SmartXXX 插件哪个也没能配成功!
嗯… 别急, 这算是折腾工具的第一个成本. 本文尽量不想提技术细节, 但这里还是稍微说说吧
对于这类知识库工具, 你需要选一个聊天模型, 选一个嵌入模型, 目前 (2025-01) 的情况是我们能用上的聊天模型有很多种, 而嵌入模型的可选项不太多, 容易出问题的也在嵌入模型这一侧
嵌入模型主要有几大类:
- 运行在模型服务商的服务器上, 注册后以 API 调用的
- 国内有智源的
bge-m3; 阿里云的通用文本向量text-embedding-v3等等 - 国外主要是 OpenAI
text-embedding-3-small别家的也有几个
- 国内有智源的
- 运行在电脑本地, 靠自己 CPU 和显卡算力的
- 例如自己安装 Ollama 后使用
bge-m3
- 例如自己安装 Ollama 后使用
- 运行在 Obsidian 插件的 javascript 环境里 (transformers.js), 靠自己 CPU 和显卡算力
Ob 里几个知名插件的支持情况如下:
- Copilot for Obsidian 支持最多的嵌入模型
- 在线的可以用 OpenAI, Cohere, Gemini, 本地的可以用 Ollama, LM Studio 里的模型
- 还支持 OpenAI 格式 (OpenAI Format) 的所有第三方嵌入模型, 国内第三方平台提供的嵌入模型一般属于这种
- Smart Composer 嵌入模型支持 OpenAI 家和本地 Ollama 的模型
- Smart Connections 嵌入模型支持本地 transformers.js 的一堆, 以及 OpenAI 家
以上这些写于 2025-01 看看就行了, 工具们时刻在改进迟早会更完善
在不熟悉插件配置时, 注意抓几个关键节点
- 模型 (包括聊天模型和嵌入模型) 配置正确了吗? verify 能通过吗?
- 最小化使用能过吗? 在聊天框 Chat 模式问一句 hello 之类的, “Chat 模式” 一般指不带知识库的对话
- 索引文档的统计正常吗? 一般插件都在设置界面里显示文档统计状态, 有的还提供命令行里的
<插件名字> debug的功能
再强调一遍, 尽量先拿小仓库测试, 熟悉后才转向实际用的仓库
跑通了, 但回答效果不好…
这个话题过于庞大了…
我认为当前阶段的 Ob 插件里的 RAG 工具, 还没法做到傻瓜式开箱即用, 所以我们即是用户又是知识库维护者, 可以不去了解技术细节但 “大关节” 得自己把着, 例如:
- 聊天模型支持输入 max_token 是多少, 跟 chunksize * topN 匹配吗?
- 召回的片段抽查几个, 跟问题的符合程度高吗?
- 对于没回答好的问题, 难在找到匹配的信息还是难在对信息的理解加工? 前者是召回模块的任务, 后者是聊天模型的任务
总之这太复杂了, 先跳过吧, 之后另行讨论
大家一般不讨论的隐形知识
这里根据我的认识, 写几个我觉得许多资料没讲的事
VSCode 的学习成本
一些可以配合 Ob 使用的工具 Cursor / Windsurf Editor / Cline RooCode 全都前置依赖 VSCode, 对 VSCode 越熟的人用起来越顺手
所以有些朋友从 Ob 跳到 Cursor 一点问题也没有, 但是有些朋友是完全没接触编程的, 直接就面对的是 “加载了一堆 AI 交互的代码编辑器” 这种经过多年进化的复杂工具
解决方案: 把 VSCode 当成大号记事本来用, VSCode 也能打开文件夹, 也有侧栏文件列表和小标题列表, 也是纯文本编辑器, 这就行了, 暂且忽视其他功能, 插件只安装界面汉化别的先不研究. 此外用 Cursor 时, 得分清哪些功能来自 Cursor, 哪些是 VSCode 本来自带, 遇到问题时也搜一下 VSCode 怎么做到 xxxx 而不仅仅是 Cursor 怎么做到 xxxx
处理 http 响应报错的研究成本
用于在线模型服务出错时能知道具体是啥错, 许多朋友不太熟悉这种从本地软件里发起并通过一种奇特的令牌 (apikey) 验明身份来使用的网络服务, 简单解释:
- 模型配置的部分
- Endpoint 是一个网址, 好比淘宝商品页面
- Model name 好比商品的具体颜色款式
- APIkey 好比用户名+密码, 告诉模型服务商这条问答的消费记谁账上
- 调用报错的部分
- HTTP Error 503 是网站方服务问题
- HTTP Error 400 是客户端参数错误, 可能是各家大模型支持参数细节有差异所致
- HTTP Error 429 是请求次数过多
我搭知识库为啥还要了解这些网络知识? 因为可以在 Ob 控制台里看到发送了啥请求, 以及完整的提示词拼接文本, 对定位问题大有帮助
解决方案：问 AI 就行, 技术细节并不难, 看 HTTP 返回状态码甚至看请求参数响应参数都很容易
理清整套流程的认知成本
RAG 类工具 (做为产品) 肯定会冲着让用户无感知 “傻瓜式使用” 去完善, 但目前看来, 我们还没法放心的就这么傻着, 现阶段: 知道 RAG 大致的工作原理, 清楚哪些参数设置重要哪些不能随便改, 分析每次聊天对话的模板怎么拼接的, … 这些关于内部实现的麻烦事, 似乎还是有一点重要
除了通用流程, 实际上每个 Ob 插件的 chunk 切分细节, Retrieval 机制, 模板套用和自动问答流程, 全都不一样… 我们了解的越多, 用着就越顺手, 或者至少对哪些问题能搞定哪些不能解决有个大致判断, 避免在无效问题上浪费时间死磕
解决方案:
- 建议不要低估难度, 折腾前预留多点调研时间, 反正 AI 也要学, 多研究个 RAG 又能咋样
- 记录一下跟知识库的交流过程, 分析为啥你的问题它答不上来
- 一边先凑合用着, 一边等各类工具完善, 明天会更好
嵌入模型的切换成本
这事其实容易想到, 但还是提一嘴 RAG 的整个流程必须使用同款嵌入模型, 即 “前期的批量索引文档” 和 “后期每次使用的具体查询语句” 的向量得经过同一个嵌入模型计算得出, 这直接决定了半途改嵌入模型代价极高
解决方案：
- 选哪个嵌入模型必须事先规划好, 在 RAG 全流程里, 这是少数几件反悔代价极高的事
- 另几个反悔代价较高的是设置 chunk size 等
- 而聊天模型选啥, 可以半路随便改
- 知识库的第一批向量嵌入的计算开销很大, 先小仓库测试好选哪个模型
- 加一个中间层 (模型中转服务), 对 Ob 这一侧提供统一接口, 对调用具体嵌入模型这一侧适应不同来源的模型
- 如果要改, 就老实删掉旧的嵌入数据, 重来
嵌入模型需要爆发使用
似乎很少见人提到, 一些平台的免费模型是有限流的
这问题在使用 “聊天模型” 时不算显著, 个人日常调不了太多次数. 但 “初始化新知识库” 需要短时间内大量调用 “嵌入模型”, 一旦触发平台流控就很麻烦, 即使你花精力定位到是这原因也啥都做不了, 只能干等数个小时后解封
解决方案：关键是能够提前避免
- 从小仓库起步, 用好各类插件的索引黑白名单, 逐批次手动添加需索引的文件
- 搭模型中转服务, 设置保守的调用频率 (自己先流控自己, 执行慢点也好过让平台给封了)
- 多个账号负载均衡
- 氪服困难
重度使用时的聊天模型花费
嵌入模型的成本刚才讨论过了, 麻烦主要在于容易出状况+调查问题费心思, 其实做向量嵌入花不了多少钱
但如果频繁跟全库对话, 就得稍微关心一下聊天模型的成本. RAG 模式下输入文本长度一般远大于输出文本, 但从对话框里你看不到这些隐藏的内部对话, 于是可能低估 token 使用量
以 最大分块大小=1000 tokens, 召回前 N 个片段=10 为例, RAG 工具在内部把这些文档块拼出来就得花掉 3000~10000 tokens, 这会是多少钱呢? 目前国内厂商大概定价 每百万输入tokens=1元~10元, 那么 3000~10000 tokens 是几分钱的样子, 再加上系统提示词和输出内容等等, 所以跟知识库交流一百个问题是几块钱到十几块钱的价位
实际情况会很复杂, 包括一些厂商模型的输入输出 token 价格不一样, 还有命中缓存的减价机制等等
解决方案:
- 调整参数, 分块小些, 少召回一些
- 提新问题就开新会话, 别把不同问题都堆一个聊天界面里
- 现在各种模型平台太多了, 除了免费还有许多平台注册后有赠费, 用完后考虑每次就充十块, 即使没注意给花光了问题也不大
处理仓库里的隐私内容
建议是从源头分离公开资料和隐私资料
以 Ob 为例, 最简单可靠就是: 隐私数据单独存一个仓库, 不安装 AI 插件. 或者相反的办法, 公开数据单拎出来存一个库, 只在这里使用 AI 插件. 如果上述办法在日常使用时麻烦, 那其次可靠的是, 公开资料 + 个人隐私放同一个仓库, 但要严格区分文件夹, 然后仔细填写 AI 插件索引目录的黑白名单
再不行就纯本地模型解决吧
这里额外备注一句, Cursor 会上传 embedding 数据以及混淆后的文件名存到它服务器见 Cursor Privacy 但不会存储笔记原文
向量嵌入数据就是一堆数啊, 暴露了有啥风险吗? 举例假设你是搞地下工作的, 笔记里存了句 “关于谁是峨眉峰” 的真实消息, 那么当这句话的 embedding 暴露后, 对方可以把 “马奎是峨眉峰”, “陆桥山是峨眉峰”, “李涯是峨眉峰”, “站长是峨眉峰” … 也以同样嵌入模型计算出 embedding, 挨个探测之后, 看相似度基本能猜出来笔记里的人名是谁 (可能还有更简单的办法)
生成代码的安全问题
有些插件会直接在聊天侧栏执行代码, 比如 AI 生成 dataview 查询之后可能会立刻运行, 应避免在聊天框询问下列问题:
- 如何挪走指定目录下带有
#task-done的文件 - 如何将所有正文中的 xxx 自动替换为 yyy, 翻译为英文
- 如何批量改掉笔记的文档属性, 参考 obsidian API 写个样例
别问我是怎么知道的
解决方案:
- 涉及代码类的提问, 且内容是 “移动删除替换” 等不可逆操作的, 就要多留神
- 笔记做好备份, 理想的是能自动定期执行的上传异地的备份, 但就算手动 zip 包搁另一块硬盘也比不备份要强
编程类 AI 工具会非常重视安全问题, 以至于有的都考虑在虚拟环境里执行, 笔记类的 AI 工具通常不会特别在意安全, 且安全性也得跟易用性平衡, 把使用步骤搞太麻烦也不好 (比如 dv 的例子, 更多时候就是想让生成 dv 代码块后自动执行)
避免笔记被自动修改
如果混合使用 Ob 和外部的文本编辑器, 或者 Ob 里有自动修改笔记的机制, 建议关掉这些自动保存, 自动格式化之类功能, 这容易引起笔记被重新嵌入
相反, 想让 AI 插件对某些笔记重做索引时, 那就改动笔记里几个字, 它就知道得重新索引一遍了
好了, 文章已经太长了, 其他的回再补充吧
总结
本文目标是探讨当前阶段 (2025 年初) 的, 围绕 Obsidian 打造的, 给个人使用和维护的知识库 能解决什么样的问题? 以及这需要 花费多大的成本, 过程中会 遇到怎样的困难
虽然我觉得, 知识库目前仍处于被大众低估, 还没到需要降温祛魅的时刻; 虽然我私心里希望有更多人能来试试这些玩意 (大家赶紧研究研究该怎么利用, 然后给我点儿启发) … 但还是要说, RAG 知识库大概不如你想象中那么万能, 折腾前要认真评估是否真有必要弄这个, 要规划使用场景, 对于达到啥目的就算成功, 心里得有个预期值
至于具体 “达到啥目的” 个人建议是抱着这个心态: 基于笔记仓库现状, 在能够不太改动整体笔记框架和不要大规模调整文档内容的前提下, 设法安排点新工具增强我笔记库的搜索效果, 做为 对传统搜索方式的补充而非替代, 如果 RAG 类工具有潜力做这件事, 那就去试试
而不应该是: 一定要全力打造出知识库, 有这知识库我就无敌了, 我要仔细研究怎么预处理文档, 怎么优选模型, 怎么调整参数, 怎么…, 对了我这知识库是准备干啥用来着的?
最后附上目前我的看法:
- RAG 以及知识库等等这些玩意真的管用吗? (有些用)
- 以个人力量弄知识库是大坑吗? (小坑, 能趟过去)
- 只要用上这些超级神奇的知识库, 我的生活一定会好起来的吧? (难说)
- 现阶段这些知识库工具已经很完善了吗? (未来可期)
- 怎么对待知识库和传统笔记工具的关系? (一起用, 多试和 AI 协作, 适当少看技术细节)
希望未来的我能完善这时一些观点, 欢迎大家交流讨论~
），通过AI插件将一些插件的功能结合起来解决用户的实际问题真的太棒了！期待~