llm_wiki用 Obsidian 建立你的第一座大模型知识库入行做 NLP 这几年我电脑里的资料比头发掉得还快。PDF 论文、微信公众号文章、GitHub 上的教程、飞书文档链接散落在各个文件夹里真到用的时候什么都找不到。后来我花了一个周末把思路捋顺用 Obsidian 搭了一个叫 llm_wiki 的知识库专门用来装大模型相关的所有东西——从 transformer 原理到 LoRA 微调从 RAG 架构到 agent 工作流现在每天查资料都在这个库里完成。这篇文章就是把我当时怎么设计、怎么搭、后期怎么维护的经验完整写出来给同样被 LLM 知识淹没的朋友一个可以直接抄作业的方案。这个项目核心回答三个问题LLM 的知识体系应该长什么样个人知识库怎么搭才能长期用而不烂尾以及怎么把零散的笔记变成真正能检索、能复用的资产。适合正在系统性学习大模型的人、做 AI 应用的工程师或者打算转型做算法岗位的开发者参考。如果你只是想收藏几篇文章那用不着这么麻烦但如果你要在这条路上走很久一个结构化的 wiki 知识库绝对值得投入时间。1. 为什么是 Wiki 而不是一堆收藏夹1.1 LLM 知识的特点决定我们不能用旧方法先聊聊大模型这个领域本身。LLM 相关的知识有一个很明显的特征网状结构而非线性结构。你今天学的是注意力机制明天就可能要用到位置编码然后发现还得回去翻 transformer 的原始论文你研究 RAG除了要理解向量化、检索排序还得懂 embedding 模型怎么选、向量数据库怎么配、prompt 怎么写。传统那种文件夹分门别类的管理方式本质上是在用线性的方式组织一个立体的知识网络装着装着就会发现同一篇笔记放在 A 类也对、放在 B 类也行最后干脆乱扔。再加上这个领域迭代速度极快。去年大家还在讨论 BERT 和 GPT 的区别今年都在聊 MoE 和长上下文前阵子微调还主流现在 RAG 又成了标配。如果没有一个能快速更新、方便建立关联的载体你收藏夹里的资料一两个月就变成了旧闻博物馆。1.2 Wiki 对个人知识管理意味着什么Wiki 这个词大家都不陌生但多数人的理解停留在一个能多人编辑的网页。其实 wiki 的核心在于词条之间的互相引用和网状关联——每个页面只写一个相对聚焦的主题页面之间用链接形成语义网络。这恰恰是 LLM 知识管理的理想形态。我最早试过 Notion它更适合做项目管理和协作数据库视图好用但页面之间的关系还是偏结构化写起来不够自由。也试过语雀适合团队知识库但个人深度整理时总感觉少了点什么。直到切到 Obsidian 才发现它天生就是干这个的本地 Markdown 文件双链自由插件生态丰富数据完全在自己手里。用 Obsidian 搭 LLM wiki本质上就是用一个本地的、个人化的 wiki 引擎来承载一套大模型知识体系。注意好工具只是起点真正的关键是你怎么设计分类和关联规则。工具是骨架结构是灵魂。1.3 这个项目到底能解决什么问题具体到我自己的场景llm_wiki 当初设立的目标有四条把散落在各处的 LLM 资料统一收编形成单一入口。跟正文相关的内容可以引用跟建模相关的代码段可以留存看到好文章能随手剪藏并标注来源。让笔记之间自动形成知识网络而不是躺在文件夹里吃灰。看到RAG这个词条就能顺着链接跳到向量数据库、EmbeddingChunking 策略等相关的页面。给自己做一份持续迭代的 LLM 学习路线。每学完一个主题就打一个勾相关笔记自然沉淀为阶段性产出。必要时可以把库里的素材快速整理成一篇技术博客或者一份分享 PPT实现知识的二次输出。说白了它就是一个可以陪着你从入门到进阶、随时能查阅的私人维基百科。2. 目录、标签与双链整体设计先定好2.1 顶层目录设计以知识点为中心一个知识库用久了会不会乱第一眼就看它的目录结构。有个现成的思路叫PARA 法Projects项目、Areas领域、Resources资源、Archives归档。但我试过之后发现这个方法适合通用知识管理放在 LLM 这种专业性极强的领域里还是太抽象了。我在 llm_wiki 里用的是按知识域划分的一级目录加上一个专门的 Inbox 作为临时收集箱llm_wiki/ ├── 00-Inbox/ # 临时捕获区 ├── 01-Basics/ # LLM 基础理论 ├── 02-Architecture/ # 模型架构 ├── 03-Training/ # 训练与微调 ├── 04-Inference/ # 推理与部署 ├── 05-Application/ # 应用与工程化 ├── 06-Tools/ # 工具与框架 ├── 07-Papers/ # 论文笔记 ├── 08-Projects/ # 个人项目 ├── 09-Archives/ # 归档区 ├── _templates/ # 模板目录 └── _assets/ # 图片附件目录这套结构的好处是你拿到一篇新文章时大多能立刻判断出该放进哪个大类。比如看到一篇《从零实现一个 GPT》放 02-Architecture看到《RLHF 的工程实践》放 03-Training看到《vLLM 部署技巧》放 04-Inference 或者 06-Tools 都可以看你自己的核心关注点。2.2 双链wiki 的灵魂所在Obsidian 里的[[双链]]是我最看重的功能。在 llm_wiki 里我给自己定了一条硬规矩每篇笔记的正文中至少包含 3 个与其他笔记的链接。没有链接的笔记就是一座孤岛那跟普通文件夹里的 Markdown 文件没区别。我的实际操作习惯是只要某个概念在笔记里出现且它是值得单独展开的话题就顺手加上双链比如写 RAG 的时候必然会提到[[向量数据库]]、[[Embedding]]、[[重排模型]]。这样积累一段时间后Obsidian 的图谱视图会自动长出一张知识网络你能很直观地看到哪些主题是枢纽节点、哪些领域还有待补充。双链还有一个隐性好处它倒逼你把概念拆得更细。以前我收藏一篇讲 LoRA 的文章就是收藏一整篇现在我会把它拆成[[LoRA 原理]]、[[QLoRA]]、[[PEFT 库]]三个词条每个词条聚焦一个点相互链接。以后要查什么从入口进来之后顺着链接走就行不用反复翻长文。2.3 标签纵向维度的补充有了双链还需要标签吗我的答案是需要但别太复杂。我对标签的使用原则是——标签负责属性和状态双链负责知识关系。在 llm_wiki 里我只保留了这几类标签标签类型示例用途内容状态#status/idea#status/developing#status/done标记笔记成熟度资料类型#type/paper#type/tutorial#type/code标记素材来源学习阶段#stage/beginner#stage/intermediate#stage/advanced筛选学习路线阅读标记#read/to-read#read/reading#read/finished管理阅读进度注意标签千万不要做成年月日这种毫无意义的维度也不要做得太细导致每个标签下只有一篇文章那就失去筛选的意义了。3. 用什么搭我对 Obsidian 和个人 Wiki 方案的选型对比3.1 为什么从 Notion、语雀、Doku 一路换到 Obsidian做 LLM 知识库工具选型看起来是小事实际上对长期使用体验影响极大。我把主流方案都过了一遍简单说下我的真实感受Notion的编辑体验和数据库功能确实强适合做团队协作和项目管理。但对个人知识库来说有三个问题一是内容存在云端搜索速度依赖网络二是 Markdown 兼容性一般从其他平台导入经常格式错乱三是页面层级限定严格双链逻辑是为数据库服务的用起来总觉得笨重。语雀在国内访问体验好文档排版漂亮尤其适合知识沉淀和分享阅读。但它的定位还是偏团队知识管理系统单人深度整理时自定义能力有限比如本地存储、插件扩展都做不到。Doku、BookStack这类开源 Wiki 系统解决的是团队协作场景适合做项目 Wiki 或者公司内部文档做成个人知识库就太重了部署、运维都要花精力。Obsidian刚好补全了上面这些短板本地 Markdown 文件数据不锁定双链语法原生支持插件生态非常活跃而且有全文搜索和图谱视图。对个人搭 LLM wiki 来说它是最省心的选择。其实也不用担心本地存储不方便多设备查看的问题网上大把方案可以做多端同步我后面会细说。补充一句如果你本来就是重度 VS Code 用户也可以考虑用 Markdown 仓库 Foam 插件实现类似效果。但 Foam 的双链体验和插件生态还是比不上 Obsidian综合看 Obsidian 更开箱即用。3.2 需要装的插件清单和使用配置Obsidian 默认功能其实够用但装了合适的插件效率能上一个台阶。我在 llm_wiki 项目里长期在用的是这几个Dataview所有查询类需求都靠它。比如你要列出某个目录下所有#status/done的笔记、列出所有链接到[[Transformer]]但还没有写正文的空笔记它都能做到。查询语句长这样dataview TABLE file.ctime as 创建时间, file.mtime as 修改时间 FROM 02-Architecture WHERE contains(tags, status/done) SORT file.mtime DESC- **Templater**配合 _templates 目录使用。每次新建笔记时自动带入模板比如论文笔记模板、术语词条模板、项目复盘模板。这能保证所有笔记结构一致不会因为今天心情好就多写几段、明天心情差就只扔一个标题。 - **Excalidraw**画架构图、流程图、模型结构图用的。直接内嵌支持在图上做双链跳转。我整理模型架构对比时经常用它比手写 Markdown 表格直观得多。 - **Recent Files**快速切换近期编辑过的笔记查资料的时候少点几下鼠标。 - **Calendar**如果你有写日志的习惯用它按天快速建笔记做工作日志和 idea 记录很方便。 - **Smart Connections**利用本地 embedding 找到语义相近的笔记这也算是AI 辅助建 wiki的一种玩法。不过它比较吃性能库太大的时候会卡我后来关掉了。 插件别贪多装得多不代表用得多反而会让 Obsidian 启动变慢。**我的原则是先默认功能用到一个痛点再补一个插件不提前堆装备。** ### 3.3 工作流设计Inbox → 清洗 → 入库 知识库搭好之后最大的挑战其实是怎么持续喂内容。很多人坚持不下去不是因为不知道用什么工具而是因为没有一个标准的物料流转流程。 我在 llm_wiki 里设计了三步走流程跟 GTD 的思路有点像 1. **收集**平时看到好文章、好教程随手扔到 00-Inbox标题简单写成日期加来源比如 20240612-huggingface-blog-随想。甚至可以给 Obsidian 的移动端装一个快捷插件手机端看到什么就一键保存到 Inbox。 2. **清洗**每周抽 30 到 60 分钟处理 Inbox 里的内容。读一遍决定它属于哪个知识域移动文件到对应目录并改成规范命名在正文里提取关键点、添加双链懒的时候至少也要加标签和摘要。 3. **入库**如果原文很长我会拆成骨架放进目标笔记外链保留在笔记顶部作为参考来源。如果原文只是某段话对我有启发我就把那句话摘录进相关词条在引用块里注明出处。 这套流程的核心思想是**先捕获后整理**。看资料的时候不用纠结该放哪每周统一处理一次就够不会给自己增加维护负担。 ## 4. LLM 知识内容体系梳理这个 Wiki 里到底装什么 ### 4.1 从入门到主线先把学习路线想清楚 目录结构搭好了具体往里面装什么就成了关键。我在建库初期踩过一个大坑贪多嚼不烂什么热词都往 wiki 里塞结果库建好了里面的词条十个有九个是空的。后来我重新梳理了学习主线只保留跟自己当前方向强相关的内容库存量一下子就健康了。 对于现在准备系统性学习 LLM 的朋友我的建议是先把一条主线走通具体可以参考这个顺序 - **入门基础**了解什么是大语言模型、语言模型的基本任务、Transformer 核心组件注意力机制、位置编码、层归一化。 - **模型架构**GPT 系列演进、BERT 和 GPT 的区别、Encoder-Decoder 架构、MoE 架构、长上下文技术。 - **训练与后训练**预训练目标与损失函数、SFT有监督微调、RLHF / DPO、LoRA / QLoRA 等参数高效微调方法。 - **推理优化**KV Cache、量化、vLLM 等推理引擎、批处理策略。 - **应用开发**Prompt Engineering、RAG 架构、Agent 与工具调用、评估方法论。 - **工具链选型**HuggingFace Transformers、LangChain、LlamaIndex、Dify、Ollama 等。 这条主线不是暑假两个月就能学完的但每一步走的都是核心不会绕远路。你的 wiki 里的词条应该围绕这条主线来建。 ### 4.2 词条分类方法词条越细使用越顺手 在 llm_wiki 里我把词条分成三类 **概念词条**比如 [[注意力机制]]、[[温度系数]]、[[上下文窗口]]。这类词条的标准写法是一句话定义、核心细节、直观比喻、相关链接。以 [[温度系数]] 为例我一般先写温度系数是控制生成随机性的超参数值越大输出越发散值越小越发确定一般 0.1 到 1.0 之间使用然后写 sample 函数里除以 temperature 的数学公式再给一个做饭调料的类比最后链接到 [[解码策略]]、[[生成参数调优]]。 **论文词条**比如 [[Attention Is All You Need]]、[[LoRA: Low-Rank Adaptation]]。模板固定为研究背景、核心方法、关键实验、我的理解、可复现代码链接。注意一定要写我的理解也就是用自己的话把论文的贡献说清楚这能帮你确认自己真的读懂了。一行字也好坚持写。 **项目词条**比如 [[本地知识库问答机器人]]、[[论文摘要工具]]。记录项目的目标、技术选型、踩坑记录、结果复盘。以后写简历或者做分享的时候直接在 wiki 里翻出项目词条改一改就能用。 ### 4.3 如何避免 Wiki 烂尾维护节奏与最小可行笔记 这是我想重点聊的话题。Obsidian 类的 wiki 工具上手很容易但大多数人会在两周左右放弃为什么因为维护成本失控了总觉得要把每篇笔记写到完美才行然后越想越焦虑最后干脆不写了。 我给自己定了一条最小程度可用的规矩 - **新词条只要能在 5 分钟内写出一段话就算完成**不用追求论文级别的完整度。以后看到相关内容随时回来补充。 - **每周只花 60 分钟整理 Inbox**。超过时间就停留给下周绝不熬夜清空。 - **空链接不可怕**。Obsidian 里允许创建还没有对应文件的链接比如你写 [[RLHF]] 时它还没有词条这时链接会变红这反而是好事——它是一个待办事项提醒你哪里需要补充。 有了这条规矩之后我的 llm_wiki 基本能稳定每周增加 10 到 20 条笔记而不是成堆的半成品吃灰。知识库这东西细水长流远比一蹴而就重要。 ## 5. 关键实操环节从空白仓库到可用的 LLM Wiki ### 5.1 本地方案初始化 我自己当时是这么起步的步骤很简单你也可以照做 第一步打开 Obsidian新建一个仓库仓库名字就叫 llm_wiki存放在一个盘符空间充裕的位置。建议直接放在本机固态硬盘上不要放在云盘同步目录里否则 Obsidian 的索引会频繁触发同步体验很差。 第二步按 2.1 节的目录结构建好顶层文件夹同时在设置里开启新建笔记默认存放位置为 00-Inbox这样你按快捷键 CtrlN 随手记的内容会先落到收件箱不会污染正式分类。 第三步打开核心插件里的模板指定模板文件夹为 _templates。把下面几类模板文件创建好 - 术语词条模板 - 论文笔记模板 - 项目复盘模板 - 学习日志模板 以术语词条模板为例我常用的内容结构是 markdown --- tags: [status/developing, stage/intermediate] --- # {{title}} 一句话定义... 核心原理... 关键细节... 直观类比... ## 相关链接 - [[]] - [[]]这里的{{title}}是 Templater 或核心模板功能自动填充的占位符用的时候会替换成当前文件名。第四步安装 Dataview 插件把 2.3 节那段查询代码放到一个叫索引页的笔记里。这样你每次打开这个索引页就能自动看到所有已完成词条的最新列表对整个库的进度一目了然。5.2 多端同步方案本地为主、加密云端为辅提到 Obsidian很多人第一反应就是数据都在本地那手机上看不了怎么办。这确实是需要解决的一个问题。我目前的方案是核心库放在本地通过同步盘做加密备份和多端访问。Git 配合私有仓库同步是很多技术人用的方案GitHub 和 Gitee 都行只在能正常访问的环境下使用即可。不想折腾 Git 的话也可以直接用坚果云、OneDrive 这类网盘工具进行目录同步。我自己用 Git 方案比较多因为还能顺便做版本管理。常用流程是写完一批笔记之后git add . git commit -m update llm wiki再推送到远程私有仓库。另外在.gitignore里排除.obsidian/workspace.json这类本地状态文件避免多设备同步时界面布局乱掉。需要注意如果你在手机端也要编辑建议在手机上只保留一个只读副本或者用网盘按需同步不然手机空间会被撑爆。5.3 与外部工具结合Dify、API 和自动化脚本llm_wiki 虽然是个人知识库但它完全可以跟大模型应用生态打通。最典型的就是知识库问答。Dify 这类 LLM 应用开发平台天然支持知识库功能你可以把 llm_wiki 里的 Markdown 文件作为离线知识源在处理后上传到 Dify 里构建 RAG 应用。我第一次是用 llm_wiki 的论文摘要笔记和架构笔记生成了一份内部 FAQ然后上传到 Dify 构建了一个LLM 知识问答机器人。效果很好因为笔记都是自己写的风格和术语比较统一检索时的命中率比直接喂网页文本高得多。如果你有一定的编程能力还可以写个小脚本每周自动扫描 llm_wiki 目录里修改时间最近的笔记生成一份本周更新摘要然后推送给自己。这既是学习回顾也相当于给知识库做周报很有仪式感。6. 常见问题速查我在搭建和使用中的踩坑实录6.1 链接失效、图片丢失、文件命名混乱怎么办问题一笔记里的双链是文字没有变成可点击的链接大部分情况是语法写错了。Obsidian 双链必须是[[笔记名]]如果笔记名里有特殊字符比如LoRA: Low-Rank Adaptation包含冒号也需要注意有没有闭合括号。建议命名规范统一用中文-英文或者纯语义化短语避免冒号、斜杠、问号这类容易出问题的字符。问题二图片附件到处都是库越来越乱一开始我图省事直接把图片粘贴进笔记Obsidian 默认存在根目录下的附件文件夹用久了文件一多就成了垃圾场。后来我设置了附件默认存放路径为_assets并通过插件把已有笔记中的图片统一迁移过去。现在新笔记插入图片会自动归位库的整洁度提升很多。问题三文件名重复手写笔记时容易不小心创建两个名字几乎一样的文件比如RAG.md和rag.md在 Obsidian 文件系统里这其实是两个文件。Windows/Mac 大小写不敏感会自动合并但同步到 Linux 服务器或者 Git 上就会出问题。我的建议是新建笔记时直接搜索一下有没有同名文件或者用命名带编号的方式来规避。6.2 Dataview 查询不出结果、性能变差问题一Dataview 查出来的列表是空的检查三处是否在笔记的 YAML 区写了正确的标签注意 YAML 数组的写法是tags: [a, b]或者tags:\n- a查询语句里的路径是否写对Obsidian 对大小写敏感是否把查询代码块指定为dataview而不是js。问题二库笔记多了之后打开图谱或者 Dataview 明显卡顿我的经验是图谱视图不要开全局展开只按需查看某个文件夹或者某个关键词的局部图谱Dataview 查询尽量缩小范围不要全库扫描比如写成FROM 02-Architecture而不是全库。另外一些重插件比如 Smart Connections如果吃资源不要开机自动启动。6.3 内容不知从何下手或者不知道怎么分类如果问这个主题应该放哪个目录我一般按下面的逻辑快速判断理论、概念类放01-Basics或02-Architecture训练、微调、数据相关放03-Training推理、部署、性能优化放04-Inference写代码、做应用、调 API 放05-Application或08-Projects拿不准的都先丢00-Inbox等整理时再归位。建库初期最容易犯的错是为了结构完美而迟迟不开始写。别管分类对不对先写了扔进 Inbox后面移动文件就是几秒钟的事。一个不完美的词条永远比一个不存在的词条有用。7. 加分项从能用的 Wiki到好用的 LLM 助手7.1 把 Wiki 变成 Prompt 素材库llm_wiki 积累到一定量之后我发现它不仅能被动查资料还能主动变成大模型的 prompt 素材库。比如我写技术方案之前会先把 wiki 里相关的词条全部打开然后把关键结论复制给 ChatGPT让它基于这些材料帮我起草一份方案初稿。因为材料都是我自己的笔记背景信息交代得很清楚生成的效果比直接问帮我写一个 RAG 方案好非常多。这个用法给我的启发是知识库的价值不只是给自己看它还是喂给大模型的上下文缓存。与其每次临时写一堆 prompt 背景还不如直接在库里把背景知识写清楚用的时候一并贴进去。7.2 用 LLM 反向整理 Wiki反过来也能用 LLM 的能力辅助维护 wiki。比如把一部分零散的 Inbox 笔记交给模型让它帮忙总结成结构化词条然后你再人工校对一遍。这能大幅降低整理笔记的心理负担。我个人现在每周清理 Inbox 时会跑一个小脚本把 Inbox 里各条笔记汇总生成一篇 Markdown然后丢给大模型让它给出建议的文章分类和标题优化再人工过一遍。这样整理时间从原来的 60 分钟降到了 20 分钟左右而且分类的错误率不高。提示用模型生成的条目不要直接入库一定要经过人工检查和修正毕竟大模型可能会一本正经地胡说八道。知识库一旦被污染越往后越难收拾。7.3 后续可以怎么扩展llm_wiki 做了一段时间之后完全可以往多个方向扩展把它变成团队小圈子共享的知识库用 Git 或者局域网同步让团队新人从 wiki 开始了解技术栈。把其中的部分词条整理成系列文章发布到技术社区相当于自己的公开版 wiki。和自动化脚本绑定每天自动从论文网站拉取最新论文标题和摘要入库形成持续更新的论文追踪系统。和日历结合每个月自动生成学习统计看看自己的知识分布在哪些领域、最近有没有偏离主线。我从一个只会收藏小黄书签的初学者到现在能靠这个库支撑起一个又一个技术方案最大的体会是知识库的价值不取决于工具的强大程度而取决于你愿不愿意用结构化的方式对待自己的知识。工具只是给你提供了一片可以自由生长的土壤真正的种子和耕耘还得靠你自己。最后再分享一个小技巧也是我现在还在坚持的习惯每次学到一个重要概念第一件事不是收藏原文而是先用自己的话在 llm_wiki 里写一条一两句话的词条哪怕很粗糙也没关系。先建链接再慢慢丰满内容。长期积累下来你不仅会拥有一个别人抄不走的 LLM 知识库更会在写作的过程中真正建立起自己的技术理解框架。这个过程本身就是收获。
