夜雨聆风AI 内容飞轮实验
Obsidian中同一篇文档，LLM-Wiki会留下什么？
如果你刚开始用 Obsidian，可能会有一个疑问：
我已经把文档写进知识库了，为什么还要再让 LLM-Wiki ingest 一次？
我也是最近才开始认真理解 LLM-Wiki 这套东西，下面的解释不一定完整，更像是我边用边整理出来的一些粗浅体会。如果你已经有比较成熟的使用经验，也欢迎一起补充和讨论。
这里的 ingest，可以先不要把它想得太复杂。
你可以把它理解成：把一篇原始文档交给一个会整理资料的助理，请它读完后，做一套“读书卡片”和“人物、概念、关系索引”。
它不是简单地把原文复制一遍，也不是把原文删除后换成一篇 AI 摘要。
理想情况下，原文还在；插件另外生成一些更方便查找和连接的页面。
这次我就用知识库里真实存在的一篇文档，来说明：
同一篇中文文档，经过 LLM-Wiki 后，理想上应该留下什么？
01先别急着看“知识图谱”四个字
“知识图谱”听起来很高级，但它可以先用一个生活中的例子理解。
假设你经营一家餐馆。
你每天会收到很多原材料：供应商单据、菜谱、顾客反馈、厨师经验。这些东西就是你的原始资料。
如果你只是把它们全部堆进一个仓库，当然也算保存了。但下次厨师问：
哪种番茄适合做这道菜？上次为什么换了供应商？这个做法是哪个师傅留下的？
你还得自己翻箱倒柜。如果有人帮你整理，他可能会做三件事：
保留原来的单据和完整记录； 做一张“这份资料来自哪里”的登记卡； 把“番茄”“供应商”“这道菜”“保存条件”等相关信息连接起来。
这三件事，是我目前理解 LLM-Wiki 的一个入口。对刚接触的人来说，可能比直接解释“实体、概念、图谱”更容易上手。
02一篇文档理想上会变成三层
这张图先看左、中、右三个框。可以把它想成餐馆里的三种东西：原始单据、登记卡和菜品索引。它们都和同一批食材有关，但用途不一样。
第一层：原始文档
这是你自己写下来的那篇 Markdown 文件。
这次的例子是：
`02_Knowledge/Concepts/知识价值公式.md`
里面有完整的公式、三个要素的解释、反面案例，以及“知识库不是图书馆”等上下文。
这一层最像餐馆里的原始单据，或者一本书的原文。
它的作用不是让 AI 看起来很聪明，而是让你以后可以核对：
这句话到底来自哪里？当时的完整上下文是什么？
按我目前的粗浅理解，原始文档应该保留在证据层。不能因为插件生成了新页面，就把原文当成无用的重复文件。餐馆里的采购单也是这样：菜谱可以改，但采购记录仍然有核对价值。
第二层：来源页
来源页可以理解成插件做的一张“读书卡”。
例如当前知识库中有一张来源页：
`wiki/sources/知识价值公式_fe527e.md`
它里面有一个非常关键的字段：
`source_file: [[02_Knowledge/Concepts/知识价值公式.md]]`
这句话翻译成人话就是：
这张 AI 整理出来的卡片，来自哪一篇原始文档？
这条链接很重要。如果来源页只有一大段总结，却不知道自己来自哪篇原文，那它就像一张没有出处的读书笔记：看起来完整，却无法核对，也无法在原文更新后找到它。
所以，我觉得一张比较理想的来源页，至少应该能回答：
我来自哪一个文件？ 我是什么时候被整理出来的？ 我提取了哪些人物、概念和要点？ 这些内容能不能回到原文核对？
第三层：概念页和关系
第三层是更方便以后调用的部分。
还是用“知识价值公式”这篇文档。
它里面不只是一个标题，而是至少包含这些可以独立理解的概念：
知识密度； 调用频次； 验证深度； 第二大脑； 活知识； 知识库不是图书馆。
理想情况下，LLM-Wiki 会把这些概念识别出来，再把它们之间的关系串起来。
比如：
“知识价值公式”由“知识密度”“调用频次”“验证深度”三个概念组成。
在我看来，这就比单纯记住“某篇文章提到过知识价值”更进一步：一篇文章里的不同内容，被拆成以后可以单独查找、单独连接的知识入口。
03为什么不能只保留 AI 总结？
因为总结不是证据。
一个 AI 总结即使写得很流畅，也可能漏掉上下文，把作者的猜测写成事实，或把同时出现的两个词误认为存在明确关系。
所以我目前更愿意采用这样一个比较稳妥的理解：
原文负责证明，来源页负责说明来处，概念页负责方便调用，关系负责帮助导航。
这几层各有分工，至少在我现在的使用阶段，不能简单地互相替代。
04普通搜索，和理想的 Wiki 搜索差在哪？
我们用同一个问题来理解：
知识价值是什么？
普通关键词搜索会怎么做？
普通搜索首先关心的是：
哪些文件里出现过“知识价值”这几个字？
它可能返回标题命中、正文提到，甚至只是顺带出现这个词的几篇笔记。
这类搜索很有用，而且速度通常很快。
但哪篇是定义、哪篇是案例、哪篇是来源，以及“知识密度”和“验证深度”有什么关系，仍然要你自己判断。
普通搜索更像是告诉你：“这些箱子里出现过这个词。”
理想的 Wiki 搜索希望多做一步
理想状态下，你问“知识价值是什么”，它应该先把一个整理好的知识入口放在前面：
知识价值 = 知识密度 × 调用频次 × 验证深度。
然后补充它来自哪篇原文、有哪些相关概念、概念之间是什么关系，以及应该回到哪篇原文核对。
它更像是餐馆里的店长直接告诉你：
这道菜的标准做法在这里，相关原料和供应商记录在这里，想看完整采购单可以点回原始档案。
这大概就是 Wiki 搜索和普通搜索的目标差异。这里的“店长”也不是万能的，仍然可能记错菜谱，所以最好还能把采购单拿出来核对。
请注意，这里说的是“理想状态”。
它不等于：
Wiki 搜索一定比普通搜索准确； AI 生成的关系一定正确； 只要安装插件，就能自动得到可靠答案。
真正要验证的是：在你的知识库里，它是否真的减少了你自己拼接答案和寻找来源的工作。
05我先用真实生成物做了一次粗浅检查
这次没有在主知识库里重新执行全量重建，也没有把理想示意图当作插件实测结果。
我检查的是当前知识库已经存在的来源页、来源字段和插件日志。
目前共有 113 个来源页：
112 个来源页有 `source_file` 字段； 106 个来源页能回到当前仍然存在的原始文件； 7 个来源路径已经不存在； 另有 1 个来源页缺少来源字段。
我目前对这组数字的粗浅理解是：
当前 LLM-Wiki 确实已经建立了一部分“整理结果 → 原始来源”的链条，但这条链还不完整。这个判断只是基于现有文件的检查，不代表我已经把所有使用情况都测完了。
所以，我目前不会把它归为“完全没用”或“已经完全可靠”。
06一个很容易被忽略的风险：旧路径
这次我还看到一个比较直观、但暂时不敢过度解释的样本。
同一个主题“OpenClaw 全局配置治理经验分享”，当前生成物里出现了两张语义相近的来源页：
其中一张能指向现在的文件：
`02_Knowledge/AI_Agents/OpenClaw全局配置治理经验分享.md`
另一张仍然指向一个已经不存在的旧路径：
`01_Inbox/Inspirations/voice/OpenClaw全局配置治理经验分享.md`
这不等于已经证明“中文匹配算法有 Bug”。
它可能涉及：
原始文件后来移动过； 插件保留了旧的来源页； 同名内容被重复摄入； 匹配和合并时没有很好地处理旧路径。
不过，对使用者来说，结果还是很实际：
你点进去以后，发现来源文件不存在了，就无法放心地核对这条总结。
这也是我觉得来源追溯应该成为测评指标的原因。至少不能只看“生成了多少页面”，还要看这些页面能不能回到原文。
07所以，怎样才算一份比较好的 LLM-Wiki 结果？
如果继续往下测，我个人会先用下面四个问题检查它。它们暂时只是我的检查框架，还谈不上成熟标准。
1. 原文找不找得到？
一篇真实文档被 ingest 后，应该能找到对应的来源页；如果原文没有进入来源层，后面的概念页再漂亮也值得怀疑。
2. 来源回不回得去？
来源页应该能点回当前存在的原始文档。只写模糊标题，或指向已经不存在的旧路径，都不能算完整可追溯。
3. 关系有没有把人带偏？
相关概念之间建立链接是为了减少查找成本，不是把所有共同出现的词都连起来。关系越多不一定越好，错误的关系会把人带偏。
4. 后续维护会不会丢东西？
这项目前没有在主库直接重建，只能标记为“当前证据不足”。未来如果要测，应在隔离副本里比较重建前后的来源页、主要来源、关键概念和原文。
08我现在对它的粗浅理解
如果用一句朴素的话解释，LLM-Wiki 有点像一个“会帮你整理资料的知识库助理”。这是帮助入门的类比，不一定覆盖插件的全部能力。
它最理想的工作，不是替你写一篇看起来很聪明的总结，而是帮你完成这些重复劳动：
从长文档里找出可能重要的概念； 把同一个概念在不同文档中的出现串起来； 建立一个比较容易进入的知识入口； 告诉你这条结论来自哪篇原文。
但最后仍然需要人来判断：
这个概念是不是真的重要？ 两篇文档之间是真的有关系，还是只是碰巧都提到了同一个词？ 这条来源还有效吗？ 这条总结可以直接使用，还是必须回到原文核对？
所以，我不太愿意只用“它会自动生成很多页面”来判断 LLM-Wiki 有没有价值。我更想继续观察：
它有没有让你以后找资料、理解资料、回到来源的过程变得更短、更清楚。
这次检查只能让我看到：当前知识库已经有不少来源链，但仍然存在失效路径和旧来源风险。
所以，我现在比较谨慎的说法是：
以我目前的使用阶段来看，LLM-Wiki 值得继续用真实小范围样本测试，但我还不会把它当成自动可靠的中文知识整理器。它到底能帮上多大忙，也不能只根据页面数量来判断。以上只是我的入门体会，欢迎大家一起补充和验证。