用LLM和Obsidian搭建个人知识库：从收藏夹到RAG驱动的wiki

搞 llm_wiki 这个项目的起因挺朴素——我的书签、收藏夹和会议视频链接越来越多但真正要用的时候一个都找不到。与其叫知识管理不如叫知识失踪。直到我把 Obsidian 里零散的双链笔记逐渐做成了一套围绕大语言模型LLM的个人 wiki才发现问题根本不在工具而在结构和检索。这个项目的核心就一句话把学习 LLM 过程中遇到的论文、框架、实战案例、经验教训用 wiki 的方式沉淀下来并且让 LLM 本身参与知识库的整理和检索。如果你正在学大模型或者已经在做 RAG、Agent 相关的开发但总觉得知识碎成一地那这篇文章值得看完。我不打算给你一套“标准答案”而是分享我从零搭 llm_wiki 的真实过程包括内容架构怎么定、Obsidian 怎么配、为什么后来非得上语义检索不可以及踩过的几个坑。1. 为什么“收藏夹式学习”注定走不远知识库的定位比工具更重要很多人的知识库失败不是因为没用 Obsidian也不是因为没用 Notion而是从第一天起就没想清楚一个问题这个库是给谁用的解决什么问题。llm_wiki 从一开始就定死了两个目标第一让我能在 30 秒内找到“某个概念我当时是怎么理解的”第二让所有内容最终能串成一个体系而不是一座孤岛。1.1 从“收藏”到“理解”的四个阶段我把自己过 LLM 相关资料的过程分成四层llm_wiki 的内容组织也完全照这个逻辑来收集层原始链接、论文 PDF、视频回放、Github 仓库。这一层只做一件事——暂存不做整理。拆解层把一篇文章拆成“核心结论”“关键图”“我的疑问”“可复现的代码”四个字段。这个动作强制我读进去而不是只点收藏。关联层通过双链把概念和概念连接起来比如“Transformer”链接到“多头注意力”和“位置编码”再把“位置编码”链接到“RoPE”和“ALiBi”。输出层把一个主题下的所有笔记串成一篇汇总文档比如“LLM 推理优化全景图”这其实就是 wiki 里的“索引页”。绝大多数人停在第一层然后抱怨工具不好用。llm_wiki 真正花时间的不是搭 Obsidian而是强迫自己走到第二层和第三层。1.2 为什么是 wiki 而不是“笔记”笔记和 wiki 的区别在于笔记是给自己看的流水账wiki 是给别人包括未来的自己看的说明书。我见过太多人的“知识库”其实就是一堆带标题的文档堆在一起没有任何交叉引用也没有目录页更谈不上结构。wiki 的核心特征是“页面之间互相链接、可以从任何一个页面跳到相邻概念”。Obsidian 的双链机制天然适合这个场景但它不会自动帮你把笔记变成 wiki——你必须主动去建“索引页”。我的做法是每个主题领域都有一个导航页比如“推理优化导航页”下面列出所有相关笔记的链接和一句话摘要。这样整个知识库就不是树状目录而是一张网。1.3 给 wiki 定下边界还有一个很容易被忽略的问题知识库需要边界。llm_wiki 只覆盖“大语言模型本身”的内容包括原理、训练、推理、微调、评估、Agent、RAG、多模态扩展不包含 Python 语法教程不包含 Linux 命令大全不包含公司内部业务文档。一旦边界清晰做内容归类的时候就再也不会纠结一篇笔记该放哪。提示项目叫 llm_wiki目标读者是“想系统理解 LLM 的开发者”而不是“所有对 AI 感兴趣的人”。这个定位决定了内容密度和深度也决定了 wiki 的目录结构。2. 用“学习路线”倒推内容架构llm_wiki 的目录怎么设计才不散架搭建 llm_wiki 的第一步不是打开 Obsidian 建文件夹而是先画一张 LLM 知识地图。我当时把市面上的学习路线翻了个遍结合自己带团队做 LLM 应用的经验把整个领域拆成六个主干模块然后让每个模块都对应一个 Obsidian 文件夹。2.1 六模块内容骨架模块核心问题典型笔记基础原理LLM 是怎么工作的Transformer、Tokenization、注意力机制、预训练与微调训练与数据处理模型是怎么训出来的损失函数、数据配比、指令微调、RLHF、评测推理与部署模型怎么跑起来量化、KV Cache、vLLM、TensorRT-LLM、推理优化应用与架构模型怎么用起来RAG、Agent、Function Calling、Prompt 工程生态与工具有哪些现成轮子LangChain、LlamaIndex、Dify、Ollama、vLLM深层议题边界和风险在哪幻觉、安全、评测基准、成本、模型能力边界这个架构的好处是任何一篇新笔记都有一个“应该待的位置”不会因为找不到地方而被随便丢进“未分类”。它也不是死板不变——学得越深越需要往里加新模块但主干骨架足够稳定后面调整只是微调。2.2 索引页是 wiki 的“导航台”每个模块的文件夹里第一份笔记永远是“导航页”也就是_README.md或者_Index.md。我当时在包管理器里对_前缀的页面做了排序置顶这样打开任何一个文件夹第一眼看到的就是导航页而不是一大堆散落的文件名。导航页的内容很简单本模块覆盖哪些子主题、每个子主题对应哪几篇笔记、哪些笔记是核心必读、哪些是选读扩展。这就叫“wiki 的感觉”——你永远知道下一步该往哪走。后面我还会在每个导航页里加一个“待补充列表”记录我暂时没看懂但想搞清楚的概念这样知识库会自然长出一个“TODO 分支”。2.3 双链不等于乱链链接节制的艺术Obsidian 让人最容易上头的是双链但双链滥用会让知识库变成一团乱麻。llm_wiki 里我给自己定了三条链接纪律每个页面最多 5 个核心出链只链接直接相关的概念必须链接到“粒度匹配”的页面。比如在“RLHF”笔记里链接到“奖励模型”而不是“机器学习总纲”关键是反向链接。每篇笔记底部我都会扫一眼“反向链接面板”看看有哪些页面引用了它。如果一篇笔记没有任何反向链接说明它是个孤儿页需要被挂接到某个导航页上。这样坚持半年之后Obsidian 的图谱视图看起来非常舒服有一团“银河系”而不是一个“毛线球”。但图谱只是结果不是目标——目标是每个概念都能从两个以上入口被找到。3. Obsidian 搭建实操模板、命名规范与“卡片盒”工作流理论说了很多这章讲实际配置。我用的是 Obsidian 加 Git 同步的方案所有 markdown 文件都放在一个仓库里换电脑直接 clone 就能继续写。这个选择带来的安全感是任何云笔记软件都给不了的。3.1 命名规范决定检索效率llm_wiki 里每篇笔记的命名遵循一个简单模式主题-视角.md。比如transformer-结构拆解.mdtokenizer-从BPE到SentencePiece.mdrag-向量检索优化实战.mdllm-推理量化对比.md对比一下“未命名笔记”、“新建文档 42”这种名字你就知道命名的价值了。我用英文连字符加中文后缀的方式既保证了文件名在 Git 和跨平台环境下的兼容性又保留了中文语义的直观性。3.2 三个模板覆盖 90% 的笔记场景我不为每类笔记建一大堆花哨模板只做三个核心模板概念卡模板用于解释一个概念比如“KV Cache”“LoRA”“困惑度”。--- tags: [概念, 推理优化/训练] 来源: {原始链接} 相关: [[前一个概念]], [[后一个概念]] --- # 概念{名称} 一句话定义 {用一句话说清楚这个概念} 详细解释 {展开说明图文并茂} 为什么重要 {对理解 LLM 的意义} 我的理解 {用自己的话写一遍避免抄原文}论文/文章卡模板用于拆解一篇外部资料。--- tags: [论文/文章, 微调] 作者: 链接: --- # {标题} 核心问题 {这篇论文解决了什么问题} 方法 {怎么解决的} 关键结论 {实验结果 / 结论} 对 llm_wiki 的价值 {这篇资料补全了知识库的哪块拼图}实战卡模板用于记录代码实验和排错过程。--- tags: [实战, RAG] 环境: vLLM 0.6, BGE-M3 --- # {实验名称} 目标 {我想验证什么} 方案 {用了什么工具和参数} 结果 {成功/失败数据说话} 坑与心得 {值得记住的教训}这几个模板看起来简单但真正用起来之后我发现“我的理解”和“坑与心得”这两个字段是最值钱的。它们强制我在收集资料之后做一次思考加工而不是把 wiki 变成收藏夹的豪华版。3.3 卡片盒工作流输入、加工、输出三步走Obsidian 只是一个工具真正改变效率的是工作流。我是按“闪念卡片 → 文献卡片 → 永久卡片”的流程来写的闪念卡片看到一段有价值的信息随手用 3 分钟建一个临时笔记只写“这是什么、来源、为什么值得记”。文献卡片每周花 1-2 小时把闪念卡片结合原文做扩展补全背景、原理、我的理解挂上链接。永久卡片当一个主题下的文献卡片超过 5 张我就把它们合并成一张导航页加若干子页形成真正的 wiki 页面。这个流程最大的作用是防止知识库变成“一次性垃圾桶”。每次往 wiki 里写东西都在做一次整理和筛选而不是简单搬运。4. 让 LLM 参与 wiki 建设从手动整理到半自动化知识管线项目叫 llm_wiki如果里面完全没有 LLM 参与那就太讽刺了。我的目标是让大模型帮我把“原始资料”变成“结构化笔记”再帮我把“结构化笔记”变成“可检索的知识库”。4.1 自动摘要与内容补全先粗后细的信息漏斗我现在用 Claude 和国内的一些大模型 API 做资料预处理流程是把一篇 PDF 或网页正文丢给 LLM让它输出“核心观点、关键数据、适用场景、潜在盲区”四个字段把输出结果放进 wiki 的“草稿区”人工审核一遍之后转成正式笔记对已有笔记定期用 LLM 做“补全检查”——找出缺少“为什么”的部分并生成问题引导我去补齐。这里有一个我踩过的坑LLM 生成的笔记质量高得让人容易放松警惕但幻觉永远存在。特别是技术细节、参数数值和论文标题必须人工核对原文件才能进 wiki。后来我干脆在模板里加了一个字段叫“核验状态”只有标记为“已核对”的笔记才会进入知识库的正式检索范围。4.2 嵌入与语义检索标签不够用的终极方案内容超过几百篇之后靠标签和文件名检索已经完全不够用了。我试过两三次搜索“推理优化”却找不到自己写过的 vLLM 笔记因为当时我把它命名成“部署问题记录”了。这正是传统关键词检索的绝望之处。解决方案是给 wiki 加一层语义检索。我的做法是用嵌入模型比如 BGE-M3 系列把每篇笔记的内容向量化向量存到一个本地向量数据库我用的是 Chroma部署简单适合个人项目写一个检索脚本输入自然语言问题返回最相关的 5-10 篇笔记继续用 LLM 做“检索增强生成”RAG把相关笔记内容拼接起来生成一个综合答案。这个方案本质上就是个小号 RAG 系统。不同的是知识源不是一堆乱七八糟的 PDF而是我已经整理好的 wiki 笔记——质量高了一截检索出来的答案自然靠谱得多。4.3 用 LLM 发现知识盲区wiki 的反向输出知识库不应该只是被动接受内容它应该反过来逼我去学新东西。我定期会跑一个脚本把 wiki 里所有“待补充列表”收集起来用 LLM 生成一个“学习路线建议”告诉我这几个待补充概念之间的依赖关系以及哪几个掌握了之后能解锁一大片新知识。比如当我发现“KV Cache”和“PagedAttention”都停留在“知道名字”的状态时LLM 给出的建议是先从“KV Cache”入手因为它是 PagedAttention 的前置概念。这个建议本身不惊艳但问题在于——如果知识库没有记录这些盲区我根本不会想到去补它们。提示与其追求“笔记数量”的增长不如追求“死角”的减少。llm_wiki 最值钱的部分不是那些成熟的笔记而是“待补充列表”——它们就是个人知识版图的盲区地图。5. 从原理到实践的认知校准几个容易踩的概念陷阱做 llm_wiki 期间我反复整理了几组概念发现很多初学者都卡在同一个地方。这些内容我都单独建了页面称为“辨析卡”作用是避免概念的混淆。5.1 预训练、微调、RLHF 到底谁负责什么很多入门文章把这三个词混着讲导致新手总觉得“微调”是万能的。我在 wiki 里画了一张类比图预训练是“把人培养成大学生”微调是“让大学生去某家公司实习”RLHF 是“让实习生在真实反馈里学会为人处事”。预训练负责“语言能力”——语法、知识、推理基础微调负责“行为对齐”——学会按用户指令输出RLHF 负责“偏好对齐”——输出的东西更符合人类喜好。理解这个层次你才能明白为什么“模型笨”不一定需要微调也许改改提示词或者换个更大的基础模型更有效。这个认知在项目选型时极其重要。5.2 训练端与推理端两套完全不同的关注点另一个我在 wiki 里反复强调的区别是“训练端”和“推理端”。这两个场景对硬件的需求、对框架的选择、对优化的目标都不一样维度训练端推理端核心目标降 loss提精度降延迟提吞吐算力瓶颈矩阵运算、梯度同步显存带宽、KV Cache 管理典型框架DeepSpeed、Megatron-LMvLLM、TensorRT-LLM、SGLang优化手段ZeRO、混合精度、梯度累积量化、PagedAttention、Continual Batching很多场景下同样的硬件做推理优化获得的速度提升比重新训练一个微调模型获得的收益大得多。llm_wiki 里专门有一整个文件夹是“推理与部署”因为这是从“技术玩家”走向“工程落地”的关键一环。5.3 TextCNN、BERT 和 LLM 做意图识别为什么不能盲目选 LLM“文本分类”任务我整理过一组对比传统 TextCNN、BERT 类模型、LLM 做意图识别它们的适用边界差别很大。很多人做项目一上来就上大模型其实可能是在用大炮打蚊子。TextCNN速度快、部署成本低适合样本量少、类别固定的简单短文本分类BERT 系列需要标注数据做微调效果通常比 TextCNN 好一截适合意图类别比较多、语义边界模糊的场景LLM适合零样本场景、类别经常变动、需要复杂推理才能理解意图的情况。我的建议是如果用户意图固定且数据标注成本可控先别急着上 LLM。对中小团队来说TextCNN 或 BERT 微调的性价比远高于调用大模型 API。这个判断在避免项目成本失控上非常关键。6. 检索增强生成RAG接入 wiki 之后从个人笔记到“第二大脑”RAG 是 llm_wiki 让我收获最大的一个模块因为它在改造个人知识管理这件事上几乎是量身定做。但很多人的 RAG 效果不好不是模型不行而是前面的数据质量不行。6.1 RAG 的完整链路切分、向量化、召回、重排、生成我在 wiki 里把 RAG 拆成了五个环节每个环节都单独建了一个页面文档切分按语义块而不是固定字数切避免把一个完整段落切开导致检索语义丢失向量化用中文场景下效果好的嵌入模型BGE-M3 或同类把文本块变成向量召回用向量相似度召回 Top-K重排用 Rerank 模型比如 BGE-Reranker对召回结果重新排序把最相关的排到前面生成把重排后的文本块和用户问题拼进提示词交给 LLM 生成回答。很多教程会跳过“重排”这一步。但实践中向量召回 Top-K 的结果前几名经常只有一两条是真正有用的。加入重排模型之后回答质量提升非常明显强烈建议不要省。6.2 接入 wiki 笔记的细节教训我给 llm_wiki 做 RAG 时踩过很多次坑说几个影响最大的教训一不要直接向量化整篇笔记先切块再入库。比如一篇“Transformer 结构拆解”笔记有 5000 字整篇向量化之后检索“什么是位置编码”返回的可能是整篇内容生成器会被大量无关信息干扰。正确做法是按 Markdown 标题和段落切块每块 300-500 字左右保留来源链接。教训二把元数据一起存进去。每个文本块保留所属笔记的路径、标签、来源链接。这样生成答案时可以附上“参考来源”方便回溯核对。很多 RAG 项目只存了向量和文本丢了元数据最后无法溯源等于给自己埋雷。教训三定期重建索引。笔记改了内容之后向量库不会自动更新。我开始时完全没意识到这个问题导致 Retriever 老是返回旧版本笔记内容。后来加了一个简单方案每次更新笔记时自动触发该块重新向量化入库。6.3 让 wiki 具备“对话式检索”能力语义检索做得差不多了我给它套了一个极简的交互层在终端里输入一个问题脚本去向量库召回然后调用 LLM 生成综合回答并把参考笔记的链接列出来。这个“对话式 wiki”本质上就是一个本地部署的 RAG 应用。实际体验下来它的价值不在于回答得有多准确而在于它改变了我查资料的方式——以前我需要先想起来“这篇笔记可能在哪个文件夹下”再打开 Obsidian 去翻现在直接输入问题得到答案答案下面带着原始笔记链接极大地降低了“回访知识库”的心理门槛。7. 走向 Agentic Wiki让 LLM Agent 自动维护知识库llm_wiki 最近半年在做一件更激进的事让 Agent 自动维护知识库。如果说 RAG 是“被动检索”那 Agentic Wiki 就是“主动整理”。这一步走下来知识库才真正开始有“生命感”。7.1 Agent 的四个核心能力设计我设计的知识库 Agent 包含四个工具检索工具从向量库召回相关笔记更新工具往指定路径写入新卡片或修改已有笔记链接工具扫描某个新笔记自动找出知识库中相关的旧笔记并添加双向链接导航工具维护导航页当新主题出现时把它挂到正确的模块下。实现上并没有多高深——就是 Function Calling 加一个状态机。但真正把四个工具串起来之后我可以直接把一篇长文链接丢给 Agent它自己完成“提取要点 → 建卡片 → 挂链接 → 更新导航页”的过程最后只给我一份结果摘要。7.2 坑全自动维护的边界在哪里全自动维护一开始非常美好直到有一天我发现 Agent 把两篇标题相似但内容方向相反的笔记链接到了一起并且修改了导航页让结构看起来没什么问题。虽然改动不大但让我警惕起来。最终我采取的方案是“半自动”Agent 只负责建议和草稿任何写操作都走 Git 分支合并之前必须人工 review。这个流程听起来没那么酷但知识库的准确性比自动化程度更重要。维护知识库这件事百分之五十的自动化已经能省掉大量重复劳动剩下的百分之五十留给人工判断刚刚好。7.3 一个有趣的效果知识库开始“长出新想法”Agent 定期扫描所有笔记的“待补充列表”和“我的理解”把这些碎片汇总给 LLM 做联想。有时候它会把两个本来互相独立的概念结合起来提出一个我没想到的延伸方向。这个概念还挺有意思——当知识积累到一定规模结构化让连接变得容易LLM 又能基于显式连接做组合就很容易产生新的理解。当然这类输出我也只是当作“参考线索”不会直接进正式笔记。但 wiki 的价值已经不只是“记录”而是“激发”。8. 一些给后来者的建议如果你也想搭一个 llm_wiki最后分享几条实操层面的建议。这些东西是我踩了半年坑才总结出来的希望对打算动手搭个人 LLM 知识库的人有用。8.1 先别折腾工具先写一个月笔记很多人搭知识库的第一步是研究 Obsidian 插件、装修主题、买 NAS、配同步最后发现笔记没写几篇。我的建议是先用最简单的纯文本 Markdown 写一个月笔记了解自己的笔记习惯再逐步加上双链、模板、语义检索。工具永远应该服务于工作流而不是反过来。8.2 每周固定“整理时间”否则 wiki 会腐烂知识库最大的敌人是“只进不出”。信息不断进入草稿区但经年累月没有被整理成正式卡片最后整个库变成一堆僵尸笔记。我给自己定的规矩是每周两小时整理只做三件事——把草稿转成正式笔记、给新笔记挂链接、更新导航页。这个节奏基本能保证知识库健康成长。8.3 用 Git 做版本管理容量焦虑会消失Obsidian 的所有东西都是 Markdown 文件天然适合 Git 管理。我把整个 llm_wiki 仓库放在 Git 远程每次整理完提交一次历史版本随时可回溯。想改结构就大胆改反正随时可以回滚。向量库不在 Git 里因为内容可以基于笔记随时重建。这种“内容与索引分离”的模式让我彻底摆脱了“改坏了怎么办”的焦虑。8.4 对初学者从这六个模块的第一步开始就够了如果你想复刻 llm_wiki不要像我一样一开始就想做全套。先把“基础原理”模块做出来——每篇概念卡写 300 字就好重要的是坚持。等写完十个概念卡之后再做下一个模块。知识库是长出来的不是规划出来的。骨架可以提前定但内容需要时间去填。我在实际维护 llm_wiki 的过程中最大的体会是真正让知识库产生价值的不是知识库本身而是整理和检索这个过程倒逼出来的思考。你每写一篇概念卡都会被迫发现自己哪里有理解漏洞你每做一次语义问答都会发现哪篇笔记其实没写透。当你把“学什么”和“怎么记”这两件事统一起来知识库就不再是负担而是你思考的外置延伸。