1. 为什么我把散落的学习资料重构成了llm_wiki先说说这个项目的由来。过去一年我在系统性地学习大模型相关技术从Transformer起源到Agent应用资料散落得到处都是浏览器收藏夹里躺着上百个链接微信文件传输助手里存了各种PDF和截图飞书文档里有一些零零散散的笔记还有几十个打开的掘金、知乎、CSDN页面。等到真正想写一篇总结或者回答一个问题的时候发现找资料本身就要花掉半天时间更糟糕的是很多内容当时看过觉得懂了一个月后完全想不起来细节又要重新翻。后来我意识到这不是记忆力的问题而是知识管理方式的问题。散装的信息如果不经过结构化整理本质上和没看过没什么区别。于是我开始着手搭建一个属于自己的大模型知识库起名llm_wiki目标很朴素把学习大模型过程中产生的文档、链接、代码片段、问答记录、视频回放全部收敛到一个系统里并且让这个系统具备快速检索、双向关联、甚至智能化问答的能力。这篇文章不是什么高深的理论讲解而是一份完整的实战记录。我会把llm_wiki从零到一的过程拆开内容包括知识库的定位设计、目录体系怎么划分、Obsidian里如何工程化落地、怎么给wiki接入LLM能力变成可对话的知识助手以及我在这个过程中踩过的一些坑。不管你是刚开始接触大模型的新手还是已经有一定基础、想梳理自己知识体系的开发者这篇文章应该都能给你一些可参考的思路。需要提前说明的是这个项目并不是从某个开源模板直接fork来的而是基于自己的学习场景一步步迭代出来的方案。所以里面很多设计决策带有明显的个人色彩比如我用了Obsidian而不是Notion我选了Dify来做RAG工作流而不是直接用LangChain这些选择都有具体的理由我在后面会展开讲。2. 明确定位这个Wiki是给谁用、解决什么问题的2.1 传统收藏夹的失效为什么“存了”不等于“会了”在动手搭建llm_wiki之前我认真想了一个问题我需要的到底是一个资料收藏夹还是一个真正的知识库。这两者的区别非常大。收藏夹的逻辑是“先存下来以后再看”但它有两个致命的缺陷。第一个是缺乏统一的组织框架存进去的内容处于完全无序的状态收藏了一百个链接之后你根本不会记得第一百个链接是什么、和前面的内容有什么关系。第二个缺陷是没有对内容进行内化处理你收藏了一篇讲LoRA微调原理的文章收藏的动作并不会让微调的数学原理进入你的大脑等到实际要写训练脚本的时候你还是要重新读一遍文章甚至要读两三遍才能理解。知识库的底层逻辑完全不同。知识库关注的不是“存了没有”而是“理解了没有、能不能快速调用”。所以llm_wiki的首要原则不是资料的堆砌而是对资料的加工和重组。每一篇资料进入知识库之前都要经过一层处理我会用自己的话写一个摘要标注这篇文章解决了什么问题和哪些已有笔记存在关联。这个加工过程本身就是在倒逼理解效果比单纯收藏好得多。2.2 llm_wiki的核心使命学习辅助、快速检索、智能化问答明确了收藏夹的局限性之后我给自己定了三个核心目标。第一个目标是学习辅助。wiki的第一使用者是未来的我自己所以内容组织一定要服务于人的认知习惯比如从基础理论到实践应用的学习路径而不是机器的存储逻辑。第二个目标是快速检索。当我写代码的时候突然想确认一下“transformers库的generate方法和model.chat有什么区别”我应该能在十秒之内定位到对应的笔记而不是在几十个收藏夹里翻找。第三个目标是智能化问答。这个目标是在后期引入的也就是把知识库里的内容喂给大模型形成一个能回答我个性化问题的问答系统。举个例子我写了一篇关于“预训练损失函数选择”的笔记当我问“如果我做领域模型预训练损失函数应该怎么选”的时候系统能结合我笔记里的内容给出回答而不是泛泛地生成一段通用的话。这三个目标分别对应了三层建设内容组织层目录结构和笔记类型规范、工具工程层Obsidian插件配置与自动化、智能增强层RAG问答链路搭建。后面的内容就按照这三层一步一步展开。3. 内容体系的搭建从零到一组织LLM知识地图3.1 领域知识拆解大模型学习路径的七个模块知识库最怕一上来就稀里糊涂地往里塞内容。我花了大概两三天的时间先梳理了一张大模型学习路径的整体框架然后按照这个框架去规划wiki的顶层目录。我最终把知识库分成了七个核心模块。基础理论Transformer架构、注意力机制、位置编码、词向量表示等前置知识模型架构GPT系列、LLaMA系列、Mistral、DeepSeek等主流模型的结构特点和设计演进训练与调优预训练、指令微调、RLHF、LoRA/QLoRA、分布式训练框架推理与部署模型量化、推理加速、vLLM、TensorRT-LLM、服务化部署应用开发Prompt工程、RAG、Function Calling、Embedding模型选型、Dify/LangChain等框架Agent与多模态ReAct框架、AutoGPT类项目、视觉语言模型、AIoT方向探索工程实践数据集构建、评测方法、成本核算、上线运维这七个模块的划分参考了业内公认的学习路线但我也根据自己的兴趣做了调整比如AIoT人工智能物联网方向就是因为我个人在做相关项目才单独列出来的。如果你自己搭建知识库完全不需要照搬这个分类你应该根据自己关注的方向去调整比如你是做金融领域的那“金融大模型落地”就可以单独成一个模块。3.2 笔记类型规范概念笔记、论文笔记、实战笔记、资料索引目录分好之后接下来就是笔记的类型问题。如果所有内容都用一个模板检索的时候会非常痛苦。我在实践过程中逐渐沉淀出四种笔记类型每种类型有明确的定位和结构。概念类笔记用来解释一个具体的技术概念比如“什么是RoPE旋转位置编码”“什么是KV Cache”这类笔记的特点是短小精悍重点是讲清楚“是什么”和“为什么需要它”。论文类笔记对应具体的论文阅读结构包括论文要解决的问题、方法的核心思路、实验结论、和我已有知识的关联、个人评价。这类笔记偏长是知识库的深度来源。实战类笔记记录我实际动手做过的事情比如“用LoRA微调Qwen实现意图识别”“在Dify里配置一个本地知识库问答应用”内容包括环境版本、踩坑过程、关键代码、效果截图。资料索引类笔记是一类特殊的MOCMap of Content内容地图页面它本身不承载具体的知识而是把某个主题下的所有相关笔记、外部链接聚合在一起起到导航的作用。比如“LLM学习路线全图”就是一条典型的资料索引笔记里面按顺序排列了我整理的所有基础理论笔记链接。这四种笔记类型在Obsidian里通过不同的文件夹和属性字段Properties来区分具体怎么落地我会在下一节详细讲。3.3 学习路线的沉淀从热词追踪到大纲落地的转化方法我注意到很多人加进知识库的时候有个问题看到什么热词就往里存什么今天存一个“PagedAttention”明天存一个“Mamba”结果知识库变成了一堆孤立名词的集合没有形成主干。llm_wiki的做法是反过来的先用学习路线图确定主干再往里填充枝叶。主干的来源是我对“大模型知识体系”的整体判断枝叶则来自日常实践中遇到的热词和问题。热词从哪来比如行业社区的讨论、公众号文章、技术周刊、甚至搜索引擎的热搜词。在我的热词监控列表里“llm agent”“RAG”“预训练损失函数”“意图识别”这些词反复出现我就会去追踪这些词背后的原理并把相关内容挂到学习路线的对应节点下。这个方法类似于项目管理里的“先搭骨架再填肉”好处是知识库始终呈现一棵树的形态而不是一盘散沙。每当出现一个新的热词我都会问自己一个问题它在我的知识体系里属于哪个模块如果找不到所属模块那就说明这个热词要么不重要要么我需要为它单独开辟一个新的分类。这套机制保证了知识库不断增长的同时结构不会腐化。4. Obsidian工程化把Vault变成真正可用的知识系统4.1 为什么选Obsidian而不是Notion或语雀知识库的承载工具选择上我几乎没有犹豫就选了Obsidian。不是说Notion或语雀不好而是对于llm_wiki这个场景Obsidian有几个不可替代的优势。第一本地存储。Obsidian所有的笔记都是纯Markdown文件存在本地文件夹里这意味着我的知识库不依赖任何云服务商的稳定性也不用担心平台关闭导致资料丢失。对于积累了几个月甚至几年的知识资产来说这个特性极其重要。第二双向链接与关系图谱。Obsidian最核心的功能就是WikiLink[[双向链接]]。在做笔记的时候我可以随手把当前笔记和已有的概念笔记链接起来这种链接关系会在图谱视图里形成网络化的知识结构帮助我发现不同知识点之间的潜在联系。第三插件生态。Obsidian有非常活跃的社区Dataview元数据查询、Templater模板系统、Juggl进阶图谱等插件能让我像写程序一样管理和操作知识库这种可编程性在Notion里远没有这么顺滑。第四和LLM工具链的天然亲和。因为笔记都是纯文本/纯Markdown格式解析成本极低后面做RAG问答的时候分块解析非常方便不用处理复杂的数据库导出或API限制。当然Obsidian也有一些让人抓狂的短板比如同步功能需要付费移动端体验一般。但这些都不影响它作为个人知识库基底的地位。4.2 Dataview、Templater、Juggl三件套的配置逻辑要让Obsidian真正工程化光装官方插件库那些核心功能还不够我主要依赖三个社区插件它们分别解决了不同的痛点。Templater解决的是“新建笔记”时的效率问题。我定义了四套模板对应前面说的四类笔记。每次新建笔记的时候只需要调用对应的模板Obsidian会自动填充当前日期、标签、属性字段等元信息我只需要专注于内容本身。比如概念笔记的模板会自动生成“定义”“原理拆解”“直观类比”“相关笔记”这几个二级标题实战笔记的模板会自动生成“环境版本”“完整步骤”“遇到的问题”“效果与反思”这几个板块。有了模板之后记笔记的门槛大幅下降。Dataview解决的是“批量检索”的问题。知识库变大了之后靠手工维护“相关内容”列表是不现实的Dataview允许你用类SQL语法在笔记里查询元数据。比如我可以写一个Dataview块自动列出所有标签为“#论文笔记”且创建日期在本月的笔记这个列表是实时更新的不需要手工维护。在我的“LLM学习路线全图”页面里就有很多这样自动生成的列表。Juggl解决的是“可视化关联”的问题。官方自带的图谱视图在网络很大的时候会乱成一团Juggl允许我按标签、按文件夹过滤节点的展示还可以分层展开让知识关系看起来更加清晰。不过说实话图谱视图在实操中更多是一种辅助确认手段真正高频使用的还是双向链接和Dataview。4.3 属性字段设计让Markdown笔记拥有数据库能力这部分是我觉得最值得分享的地方。纯Markdown笔记有一个弱点缺乏结构化字段。而Obsidian从1.4版本开始强化了Properties功能允许在笔记的YAML头部定义键值对这让纯文本笔记拥有了类似数据库记录的能力。llm_wiki里每篇笔记的YAML头部大概长这样--- type: concept module: 基础理论 tags: [transformer, attention, 原理] created: 2025-06-10 updated: 2025-06-15 difficulty: intermediate status: done source: https://example.com/attention-is-all-you-need ---这个设计看似简单实际价值非常大。type字段让Dataview可以分类型统计和展示笔记module字段对应知识库的七大领域status字段标记学习状态todo/doing/done方便我随时看到还有哪些内容没有啃完。difficulty字段用来标记难度每隔一段时间我会重新整理一遍所有标记为“hard”的笔记看哪些现在已经可以理解了。有了这些属性字段之后知识库真正变成了一种“可计算”的存在。我甚至写过几个Dataview查询实现类似“最近两周内用户态为doing的实战笔记”“所有和注意力机制相关的论文笔记按年份排列”这样的动态列表。这些能力在纯笔记场景里是想象不到的。5. 给Wiki装上一颗大脑LLM接入与RAG问答链路5.1 为什么需要RAG让模型基于你的笔记回答而不是编段子知识库从“人用”升级到“机器也能协助用”最关键的一步是接入RAGRetrieval-Augmented Generation检索增强生成。RAG的原理其实不复杂当用户提了一个问题之后系统先去你的知识库里检索相关的文本片段把检索到的片段作为上下文和问题一起提交给大模型让模型根据这个上下文来生成回答。这样做的好处有两个——第一回答有依据不会凭空编造第二模型不需要重新训练就能更新知识知识库里新增的内容马上就能影响回答结果。对于llm_wiki来说RAG的落地意味着我可以直接对知识库里的笔记提问。比如问“LoRA和QLoRA在显存占用上有什么区别”系统会先在我的笔记里找到相关内容再结合大模型的生成能力组织出答案。答案的准确率高不高完全取决于我的知识库质量这就形成了一个正向循环知识库越完善问答效果越好我就越愿意完善知识库。5.2 AI Search/Dify/本地Embedding技术栈选型对比在RAG具体实现上我前后对比了好几种方案最后锁定了一套组合。这里把选型思路还原出来供大家参考。我最初试的是LangChain OpenAI的方案它能跑通但有几个问题一是配置繁琐链路搭起来之后不好维护二是依赖外部API每次问答都产生费用而且数据要传到外部服务三是调参很不直观检索的结果出了问题很难调试。后来我尝试了Dify这个选择很大程度上解决了我前面的痛点。Dify是一个开源的大模型应用开发平台内置了知识库管理、RAG流水线、Agent编排等功能更重要的是它提供了可视化的操作界面我可以在界面上直接看到知识库的分块情况、检索命中的结果片段、提示词模板的执行流程。在Embedding模型的选择上我对比了OpenAI的text-embedding-3-small和开源的BGE-M3。最终考虑到数据隐私和长期成本我选择了本地部署的BGE-M3在Dify里配置了一个本地Embedding服务。单条笔记的向量化处理速度非常快效果也足够好。如果你对数据隐私没那么敏感用OpenAI的Embedding也能达到不错的检索效果但如果你在意的点是可控性那本地Embedding是更稳妥的选择。在LLM推理端的选择上我同时接了两路一路走云端的模型API日常对话用成本和速度都比较理想另一路用本地部署的小模型通过Ollama跑Qwen系列完全离线状态下也能使用知识库问答。两条路各有适用的场景本地模型虽然效果略逊但在断网、数据敏感等场景下有不可替代的价值。5.3 从笔记到可回答系统的完整落地步骤整个RAG链路搭起来大概花了我一个周末的时间步骤如下。第一步是准备知识源。我用Obsidian的文件夹把所有笔记整理成纯Markdown格式按照知识库的体系放在合适的路径下。这里有个小细节要注意把每篇笔记的文件名改成有语义的名字比如“RAG技术综述.md”“LoRA微调实战.md”而不是“未命名笔记.md”。文件名在检索中会作为重要权重参与匹配好的命名习惯能显著提升召回率。第二步是在Dify里创建知识库。选择“上传新的知识库”把Obsidian的笔记文件夹整个拖进去。Dify会自动解析Markdown文档但它默认的分块逻辑不一定完全符合你的知识库结构需要在“分块设置”里调整。我个人习惯把分块大小设置在500-800个token之间重叠量在50-100个token这样既能保留上下文又不会让向量化后的语义过于稀薄。如果你的笔记比较长可以按标题语义切块Dify的“结构化分块”模式能识别标题层级效果更好。第三步是配置Embedding模型。在Dify的“模型供应商”页面添加一个OpenAI兼容的Embedding API或者用本地Ollama提供的Embedding接口。我用的是BGE-M3通过Ollama跑起来之后在Dify里填一下API地址和模型名称就行。配置完会自动对知识库执行索引生成向量库。第四步是创建AI应用。在Dify里新建一个“聊天助手”应用关联刚才配置的知识库然后在“提示词编排”里设置角色指令比如“你是我的大模型学习助手请根据知识库内容回答问题如果答案不在知识库中请直接说明你不知道而不是编造答案”。这个提示词直接决定了问答系统的工作方式建议多花点心思调优。Dify里的LLM设置就在应用编排页面的“模型”下拉框里选择可以随时切换不同的模型提供商同时把“知识库”作为工具配置进去。第五步是联调验证。这个步骤的核心任务是测试不同类型问题的回答效果。经验是准备三组测试问法第一组是直接能得到答案的问题比如“什么是KV Cache”第二组是需要跨笔记整合的问题比如“训练一个领域模型需要做哪些数据准备”第三组是知识库覆盖不到的问题比如“如何做量化交易”。通过三组测试可以判断系统的检索准确率和拒答能力。5.4 检索优化实测分块策略、命中率监控、Rerank链路跑通只是第一步真正让问答效果从“能用”到“好用”后面还有很多优化工作。我分享几个经过实测有效的方法。第一个是分块策略的精细调整。我一开始用Dify默认的分块方式500个token直切结果发现很多跨块的语义被切断了。比如一篇讲“预训练损失函数”的笔记前半部分在讲交叉熵后半部分在讲对比损失直切之后会对检索造成干扰。后来我改成按Markdown标题分割并在Dify的“分块设置”里开启“按Markdown标题分割”模式命中率明显提升。第二个是关注命中的顺序和分数。Dify知识库的命中结果可以在调试面板里查看里面有一栏显示了知识库命中的文档片段和相似度分数。如果一个问题命中的不是我希望的文档我会点开看看是哪些片段命中了然后调整提问方式或者补充缺失的内容。这个过程就跟调搜索引擎一样需要反复迭代。第三个是引入Rerank重排。Dify平台支持配置Rerank模型它的作用是从知识库里召回更多候选片段再对候选片段进行相关性重排取最相关的结果提交给大模型。加了Rerank之后效果提升非常明显特别是那些知识库内容较多、容易命中噪声片段的场景。我用的Rerank模型还是一个本地的BGE-Reranker通过Ollama部署整个链路完全本地化。6. 资料收集与回放归档让Wiki持续“长”起来6.1 信息源分类与收集工作流的落地知识库的一大难题是更新。如果建完之后就扔在那里不管几个月就变成死库了。llm_wiki的更新机制我设计了一套半自动化的流程核心思路是把信息源分类给每一类信息源规划一条固定的收集路径。我把信息源分成了五类在线文章和博客、论文和预印本、视频和直播回放、代码仓库和发行说明、自己产出的实践笔记。每一类都有对应的收集方式。在线文章用浏览器插件一键剪藏到Obsidian的Inbox文件夹论文直接保存PDF到附件目录并顺手创建一篇论文笔记视频回放记录标题、链接和时间戳如果有配套的PPT或文档也一并归档代码仓库则记录版本号和关键commit信息。这套工作流的核心是“随手收集、定期清理”的原则。Obsidian里我专门建了一个“0-Inbox”文件夹所有来不及处理的资料先丢进去每周抽一个固定时间处理一次Inbox该归档的归档该写笔记的写笔记该丢弃的直接删除。没有这个环节收集流程很快就会因为垃圾内容堆积而失效。6.2 直播回放与技术会议资料的知识化处理在大模型这个领域技术分享直播和回放是非常宝贵的学习资源。热词列表里有一条“资料以及回放汇总”的链接这类的汇总我通常会在观看之前就建好一篇资料索引笔记把回放链接、日程安排、演讲人信息记录下来。等看完之后再把每一场分享的重点提炼成要点挂到对应的知识模块下。这里有一个人人都会踩的坑很多人把回放链接往收藏夹一扔就相当于看过了。实际上回放的观后整理效率非常低因为视频是线性的翻某个知识点要拖进度条。我的办法是在观看回放的同时结合大会官网发布的讲义或PPT文档来做补充笔记视频内容只是辅助理解最终沉淀的知识载体是文字笔记而不是视频本身。如果一场分享我只看视频没有形成笔记那么这次学习在知识库层面的收益几乎为零。6.3 知识生命周期谁来决定条目该被淘汰或升级知识库建久了一定会遇到一个问题有些笔记过时了。比如我早期记录的一些关于“LLaMA微调”的内容在今天看来指令微调的技术方案已经有了很大的变化旧笔记里的某些结论已经不准确了。llm_wiki处理这个问题的办法是给每条笔记定义了一种“状态”todo没看、doing正在整理、done已完成、stale已过时、merged已合并到其他笔记。每过两三个月我会根据当前的知识水平重新评估一遍知识库里的笔记过时的内容不会直接删除而是标记为stale保留在知识库中作为历史记录同时新建一篇升级版笔记来替代它。这种处理方式兼顾了知识的迭代和历史的追溯。另一个常见情况是两篇或多篇笔记内容高度重合。比如我有一篇叫做“什么是Prompt Engineering”的概念笔记还有一篇“Prompt编写技巧汇总”的实战笔记时间长了之后两者的内容开始重叠。遇到这种情况我会把内容合并进更完整的那篇另外一篇标记为merged再用双向链接把两篇关联起来。7. 踩坑记录我在llm_wiki建设中交过的学费7.1 双向链接一时爽过度设计火葬场我刚开始用Obsidian的时候陷入了双向链接的狂热中。每篇笔记都要关联五六篇相关笔记图谱视图密密麻麻像蜘蛛网一样看起来很酷炫实际使用的时候发现根本没帮助。因为链接一旦过多就丧失了导航的作用你看到一堆蓝色链接根本不知道该点哪一个。后来我给自己定了一个规则每篇笔记的“相关笔记”最多列五个而且必须是对理解当前这篇内容真正有帮助的链接而不是看起来相关但实际作用不大的链接。泛滥的链接宁可删掉保持知识库的“轻量感”。相信我知识库维护的核心矛盾不是信息不足而是噪声太多。7.2 本地小模型的效果边界别对离线问答期待过高我在前面提到了本地部署小模型作为离线兜底方案。实测下来本地模型的问答效果确实和云端大模型有明显差距特别是跨笔记整合复杂信息的时候。比如问“比较一下几种主流的Embedding模型选型思路”本地小模型给出的答案往往会遗漏几个重要的对比维度而云端模型因为本身的推理能力更强同样的上下文条件下回答质量会高一块。所以我的建议是如果你主要用知识库来处理日常问题和深度整合分析优先选择能力强一些的云端大模型API把本地模型作为隐私要求极高的场景的保底方案。不要因为追求“本地部署”的极客光环牺牲了问答效果的核心体验。7.3 RAG检索不到先从分块和命名排查遇到RAG检索效果不好的问题大多数人第一反应是换模型、调提示词但实测下来大部分检索问题出在数据侧。我有一次问“什么是MHA和MQA的区别”系统死活检索不到那篇笔记后来排查发现那篇笔记在文件夹里但是Embedding索引在知识库创建之后没有重建新笔记没有被纳入向量库。重新建一次索引就好了。另一个常见问题是笔记的标题和内容不一致。比如我有一篇笔记标题叫“大模型的推理优化笔记”里面其实详细讲了PagedAttention、连续批处理、投机采样这些技术但是如果用户问“什么是投机采样”系统靠标题和开头的语义可能命中不了这篇笔记。解决办法是第一篇大文档里的关键概念拆分成独立的笔记或者在原笔记开头写一个小目录摘要让检索更容易命中。7.4 Embedding模型与检索语境的匹配问题最后一个值得展开的坑是Embedding模型的选择。我一开始偷懒用了一个比较老的本地Embedding模型结果发现检索效果特别差很多明显相关的文档都搜不到。后来换了BGE-M3之后检索质量立刻上了一层楼。不同Embedding模型的语义理解能力差距非常大特别对于中文内容老模型的词表覆盖和语义编码能力都会成为瓶颈。另外要注意检索时的问题也应该和Embedding模型兼容正常情况下不用额外处理但如果你的用户习惯抛出很口语化的长句建议在接入LLM之前先用提示词对问题做一次改写和压缩把口语化提问转换成更贴近官方文档语气的检索式提问这样检索的准确率会有比较明显的提升。8. 这个项目后续还能怎么扩展llm_wiki走到现在已经不只是我个人的学习笔记了它逐渐变成了一个可以承载多种智能化任务的底座。我还在持续完善它这里分享几个正在做和打算做的扩展方向。第一个方向是和Agent结合。热词列表里频繁出现的“llm powered autonomous agents”让我意识到知识库和Agent结合之后可以做的事情远超现在的问答系统。比如我可以让一个Agent在知识库基础上自主规划学习路径根据我对某个知识模块的掌握程度自动推荐下一阶段应该学什么、练什么甚至自动生成针对性的练习题。这样llm_wiki就不光是“被动的问答库”而是变成了“主动的学习助理”。第二个方向是数据准备能力的强化。热词里有“垂域llm数据准备”这和知识库的积累其实一脉相承。llm_wiki里大量的整理好的领域内容本身就是训练领域大模型的优质语料素材。我打算后续把知识库导出的Markdown文件做进一步的清洗和格式化按照对话式QA对整理成训练数据集迁移到模型微调的场景里使用。这样一来wiki积累的知识能够反过来反哺模型本身。第三个方向是更复杂的知识推理能力。当前的RAG问答还是偏“单跳检索”也就是一个问题对应一段直接相关的知识。但实际场景里很多问题需要跨多篇笔记进行推理。Dify也支持多路知识库检索然后汇总答案但要真正做到让模型在不同笔记之间进行深度推理整合还需要在设计上引入知识图谱或者更复杂的索引结构。这个方向我正在调研后续完全落地了再写一篇专门的分享。第四个方向是社区化。如果把llm_wiki的目录体系和模板规范做成一整套可以导出的模板库发布出去让其他学习者直接套用就能避免大家从零开始搭知识库的痛苦。比如热词搜索里关于“英灵神殿wiki”“后室wiki”等游戏和社区wiki的讨论让我看到很多人对wiki的想象依然是“别人搭好的站点”但实际上个人知识库的搭建门槛已经降到很低了。我打算后续把这套体系整理成一份可直接导入的Obsidian Vault模板包含目录结构、四类笔记模板、Dataview查询示例和Dify配置指南有需要的朋友可以直接拿去用。最后再分享一个小技巧无论知识库用了多复杂的工具链最终的核心还是“持续地产出你自己的理解”。llm_wiki本质上是一个用工具倒逼思考的系统工具再完善如果不坚持每周往里填充属于自己的内容它很快就变成一堆华而不实的空架子。所以从今天开始哪怕只建一个文件夹、写一篇三百字的概念笔记也比等所有条件完美再开始要强得多。 基于Obsidian与RAG的大模型个人知识库llm_wiki搭建实战
1. 为什么我把散落的学习资料重构成了llm_wiki先说说这个项目的由来。过去一年我在系统性地学习大模型相关技术从Transformer起源到Agent应用资料散落得到处都是浏览器收藏夹里躺着上百个链接微信文件传输助手里存了各种PDF和截图飞书文档里有一些零零散散的笔记还有几十个打开的掘金、知乎、CSDN页面。等到真正想写一篇总结或者回答一个问题的时候发现找资料本身就要花掉半天时间更糟糕的是很多内容当时看过觉得懂了一个月后完全想不起来细节又要重新翻。后来我意识到这不是记忆力的问题而是知识管理方式的问题。散装的信息如果不经过结构化整理本质上和没看过没什么区别。于是我开始着手搭建一个属于自己的大模型知识库起名llm_wiki目标很朴素把学习大模型过程中产生的文档、链接、代码片段、问答记录、视频回放全部收敛到一个系统里并且让这个系统具备快速检索、双向关联、甚至智能化问答的能力。这篇文章不是什么高深的理论讲解而是一份完整的实战记录。我会把llm_wiki从零到一的过程拆开内容包括知识库的定位设计、目录体系怎么划分、Obsidian里如何工程化落地、怎么给wiki接入LLM能力变成可对话的知识助手以及我在这个过程中踩过的一些坑。不管你是刚开始接触大模型的新手还是已经有一定基础、想梳理自己知识体系的开发者这篇文章应该都能给你一些可参考的思路。需要提前说明的是这个项目并不是从某个开源模板直接fork来的而是基于自己的学习场景一步步迭代出来的方案。所以里面很多设计决策带有明显的个人色彩比如我用了Obsidian而不是Notion我选了Dify来做RAG工作流而不是直接用LangChain这些选择都有具体的理由我在后面会展开讲。2. 明确定位这个Wiki是给谁用、解决什么问题的2.1 传统收藏夹的失效为什么“存了”不等于“会了”在动手搭建llm_wiki之前我认真想了一个问题我需要的到底是一个资料收藏夹还是一个真正的知识库。这两者的区别非常大。收藏夹的逻辑是“先存下来以后再看”但它有两个致命的缺陷。第一个是缺乏统一的组织框架存进去的内容处于完全无序的状态收藏了一百个链接之后你根本不会记得第一百个链接是什么、和前面的内容有什么关系。第二个缺陷是没有对内容进行内化处理你收藏了一篇讲LoRA微调原理的文章收藏的动作并不会让微调的数学原理进入你的大脑等到实际要写训练脚本的时候你还是要重新读一遍文章甚至要读两三遍才能理解。知识库的底层逻辑完全不同。知识库关注的不是“存了没有”而是“理解了没有、能不能快速调用”。所以llm_wiki的首要原则不是资料的堆砌而是对资料的加工和重组。每一篇资料进入知识库之前都要经过一层处理我会用自己的话写一个摘要标注这篇文章解决了什么问题和哪些已有笔记存在关联。这个加工过程本身就是在倒逼理解效果比单纯收藏好得多。2.2 llm_wiki的核心使命学习辅助、快速检索、智能化问答明确了收藏夹的局限性之后我给自己定了三个核心目标。第一个目标是学习辅助。wiki的第一使用者是未来的我自己所以内容组织一定要服务于人的认知习惯比如从基础理论到实践应用的学习路径而不是机器的存储逻辑。第二个目标是快速检索。当我写代码的时候突然想确认一下“transformers库的generate方法和model.chat有什么区别”我应该能在十秒之内定位到对应的笔记而不是在几十个收藏夹里翻找。第三个目标是智能化问答。这个目标是在后期引入的也就是把知识库里的内容喂给大模型形成一个能回答我个性化问题的问答系统。举个例子我写了一篇关于“预训练损失函数选择”的笔记当我问“如果我做领域模型预训练损失函数应该怎么选”的时候系统能结合我笔记里的内容给出回答而不是泛泛地生成一段通用的话。这三个目标分别对应了三层建设内容组织层目录结构和笔记类型规范、工具工程层Obsidian插件配置与自动化、智能增强层RAG问答链路搭建。后面的内容就按照这三层一步一步展开。3. 内容体系的搭建从零到一组织LLM知识地图3.1 领域知识拆解大模型学习路径的七个模块知识库最怕一上来就稀里糊涂地往里塞内容。我花了大概两三天的时间先梳理了一张大模型学习路径的整体框架然后按照这个框架去规划wiki的顶层目录。我最终把知识库分成了七个核心模块。基础理论Transformer架构、注意力机制、位置编码、词向量表示等前置知识模型架构GPT系列、LLaMA系列、Mistral、DeepSeek等主流模型的结构特点和设计演进训练与调优预训练、指令微调、RLHF、LoRA/QLoRA、分布式训练框架推理与部署模型量化、推理加速、vLLM、TensorRT-LLM、服务化部署应用开发Prompt工程、RAG、Function Calling、Embedding模型选型、Dify/LangChain等框架Agent与多模态ReAct框架、AutoGPT类项目、视觉语言模型、AIoT方向探索工程实践数据集构建、评测方法、成本核算、上线运维这七个模块的划分参考了业内公认的学习路线但我也根据自己的兴趣做了调整比如AIoT人工智能物联网方向就是因为我个人在做相关项目才单独列出来的。如果你自己搭建知识库完全不需要照搬这个分类你应该根据自己关注的方向去调整比如你是做金融领域的那“金融大模型落地”就可以单独成一个模块。3.2 笔记类型规范概念笔记、论文笔记、实战笔记、资料索引目录分好之后接下来就是笔记的类型问题。如果所有内容都用一个模板检索的时候会非常痛苦。我在实践过程中逐渐沉淀出四种笔记类型每种类型有明确的定位和结构。概念类笔记用来解释一个具体的技术概念比如“什么是RoPE旋转位置编码”“什么是KV Cache”这类笔记的特点是短小精悍重点是讲清楚“是什么”和“为什么需要它”。论文类笔记对应具体的论文阅读结构包括论文要解决的问题、方法的核心思路、实验结论、和我已有知识的关联、个人评价。这类笔记偏长是知识库的深度来源。实战类笔记记录我实际动手做过的事情比如“用LoRA微调Qwen实现意图识别”“在Dify里配置一个本地知识库问答应用”内容包括环境版本、踩坑过程、关键代码、效果截图。资料索引类笔记是一类特殊的MOCMap of Content内容地图页面它本身不承载具体的知识而是把某个主题下的所有相关笔记、外部链接聚合在一起起到导航的作用。比如“LLM学习路线全图”就是一条典型的资料索引笔记里面按顺序排列了我整理的所有基础理论笔记链接。这四种笔记类型在Obsidian里通过不同的文件夹和属性字段Properties来区分具体怎么落地我会在下一节详细讲。3.3 学习路线的沉淀从热词追踪到大纲落地的转化方法我注意到很多人加进知识库的时候有个问题看到什么热词就往里存什么今天存一个“PagedAttention”明天存一个“Mamba”结果知识库变成了一堆孤立名词的集合没有形成主干。llm_wiki的做法是反过来的先用学习路线图确定主干再往里填充枝叶。主干的来源是我对“大模型知识体系”的整体判断枝叶则来自日常实践中遇到的热词和问题。热词从哪来比如行业社区的讨论、公众号文章、技术周刊、甚至搜索引擎的热搜词。在我的热词监控列表里“llm agent”“RAG”“预训练损失函数”“意图识别”这些词反复出现我就会去追踪这些词背后的原理并把相关内容挂到学习路线的对应节点下。这个方法类似于项目管理里的“先搭骨架再填肉”好处是知识库始终呈现一棵树的形态而不是一盘散沙。每当出现一个新的热词我都会问自己一个问题它在我的知识体系里属于哪个模块如果找不到所属模块那就说明这个热词要么不重要要么我需要为它单独开辟一个新的分类。这套机制保证了知识库不断增长的同时结构不会腐化。4. Obsidian工程化把Vault变成真正可用的知识系统4.1 为什么选Obsidian而不是Notion或语雀知识库的承载工具选择上我几乎没有犹豫就选了Obsidian。不是说Notion或语雀不好而是对于llm_wiki这个场景Obsidian有几个不可替代的优势。第一本地存储。Obsidian所有的笔记都是纯Markdown文件存在本地文件夹里这意味着我的知识库不依赖任何云服务商的稳定性也不用担心平台关闭导致资料丢失。对于积累了几个月甚至几年的知识资产来说这个特性极其重要。第二双向链接与关系图谱。Obsidian最核心的功能就是WikiLink[[双向链接]]。在做笔记的时候我可以随手把当前笔记和已有的概念笔记链接起来这种链接关系会在图谱视图里形成网络化的知识结构帮助我发现不同知识点之间的潜在联系。第三插件生态。Obsidian有非常活跃的社区Dataview元数据查询、Templater模板系统、Juggl进阶图谱等插件能让我像写程序一样管理和操作知识库这种可编程性在Notion里远没有这么顺滑。第四和LLM工具链的天然亲和。因为笔记都是纯文本/纯Markdown格式解析成本极低后面做RAG问答的时候分块解析非常方便不用处理复杂的数据库导出或API限制。当然Obsidian也有一些让人抓狂的短板比如同步功能需要付费移动端体验一般。但这些都不影响它作为个人知识库基底的地位。4.2 Dataview、Templater、Juggl三件套的配置逻辑要让Obsidian真正工程化光装官方插件库那些核心功能还不够我主要依赖三个社区插件它们分别解决了不同的痛点。Templater解决的是“新建笔记”时的效率问题。我定义了四套模板对应前面说的四类笔记。每次新建笔记的时候只需要调用对应的模板Obsidian会自动填充当前日期、标签、属性字段等元信息我只需要专注于内容本身。比如概念笔记的模板会自动生成“定义”“原理拆解”“直观类比”“相关笔记”这几个二级标题实战笔记的模板会自动生成“环境版本”“完整步骤”“遇到的问题”“效果与反思”这几个板块。有了模板之后记笔记的门槛大幅下降。Dataview解决的是“批量检索”的问题。知识库变大了之后靠手工维护“相关内容”列表是不现实的Dataview允许你用类SQL语法在笔记里查询元数据。比如我可以写一个Dataview块自动列出所有标签为“#论文笔记”且创建日期在本月的笔记这个列表是实时更新的不需要手工维护。在我的“LLM学习路线全图”页面里就有很多这样自动生成的列表。Juggl解决的是“可视化关联”的问题。官方自带的图谱视图在网络很大的时候会乱成一团Juggl允许我按标签、按文件夹过滤节点的展示还可以分层展开让知识关系看起来更加清晰。不过说实话图谱视图在实操中更多是一种辅助确认手段真正高频使用的还是双向链接和Dataview。4.3 属性字段设计让Markdown笔记拥有数据库能力这部分是我觉得最值得分享的地方。纯Markdown笔记有一个弱点缺乏结构化字段。而Obsidian从1.4版本开始强化了Properties功能允许在笔记的YAML头部定义键值对这让纯文本笔记拥有了类似数据库记录的能力。llm_wiki里每篇笔记的YAML头部大概长这样--- type: concept module: 基础理论 tags: [transformer, attention, 原理] created: 2025-06-10 updated: 2025-06-15 difficulty: intermediate status: done source: https://example.com/attention-is-all-you-need ---这个设计看似简单实际价值非常大。type字段让Dataview可以分类型统计和展示笔记module字段对应知识库的七大领域status字段标记学习状态todo/doing/done方便我随时看到还有哪些内容没有啃完。difficulty字段用来标记难度每隔一段时间我会重新整理一遍所有标记为“hard”的笔记看哪些现在已经可以理解了。有了这些属性字段之后知识库真正变成了一种“可计算”的存在。我甚至写过几个Dataview查询实现类似“最近两周内用户态为doing的实战笔记”“所有和注意力机制相关的论文笔记按年份排列”这样的动态列表。这些能力在纯笔记场景里是想象不到的。5. 给Wiki装上一颗大脑LLM接入与RAG问答链路5.1 为什么需要RAG让模型基于你的笔记回答而不是编段子知识库从“人用”升级到“机器也能协助用”最关键的一步是接入RAGRetrieval-Augmented Generation检索增强生成。RAG的原理其实不复杂当用户提了一个问题之后系统先去你的知识库里检索相关的文本片段把检索到的片段作为上下文和问题一起提交给大模型让模型根据这个上下文来生成回答。这样做的好处有两个——第一回答有依据不会凭空编造第二模型不需要重新训练就能更新知识知识库里新增的内容马上就能影响回答结果。对于llm_wiki来说RAG的落地意味着我可以直接对知识库里的笔记提问。比如问“LoRA和QLoRA在显存占用上有什么区别”系统会先在我的笔记里找到相关内容再结合大模型的生成能力组织出答案。答案的准确率高不高完全取决于我的知识库质量这就形成了一个正向循环知识库越完善问答效果越好我就越愿意完善知识库。5.2 AI Search/Dify/本地Embedding技术栈选型对比在RAG具体实现上我前后对比了好几种方案最后锁定了一套组合。这里把选型思路还原出来供大家参考。我最初试的是LangChain OpenAI的方案它能跑通但有几个问题一是配置繁琐链路搭起来之后不好维护二是依赖外部API每次问答都产生费用而且数据要传到外部服务三是调参很不直观检索的结果出了问题很难调试。后来我尝试了Dify这个选择很大程度上解决了我前面的痛点。Dify是一个开源的大模型应用开发平台内置了知识库管理、RAG流水线、Agent编排等功能更重要的是它提供了可视化的操作界面我可以在界面上直接看到知识库的分块情况、检索命中的结果片段、提示词模板的执行流程。在Embedding模型的选择上我对比了OpenAI的text-embedding-3-small和开源的BGE-M3。最终考虑到数据隐私和长期成本我选择了本地部署的BGE-M3在Dify里配置了一个本地Embedding服务。单条笔记的向量化处理速度非常快效果也足够好。如果你对数据隐私没那么敏感用OpenAI的Embedding也能达到不错的检索效果但如果你在意的点是可控性那本地Embedding是更稳妥的选择。在LLM推理端的选择上我同时接了两路一路走云端的模型API日常对话用成本和速度都比较理想另一路用本地部署的小模型通过Ollama跑Qwen系列完全离线状态下也能使用知识库问答。两条路各有适用的场景本地模型虽然效果略逊但在断网、数据敏感等场景下有不可替代的价值。5.3 从笔记到可回答系统的完整落地步骤整个RAG链路搭起来大概花了我一个周末的时间步骤如下。第一步是准备知识源。我用Obsidian的文件夹把所有笔记整理成纯Markdown格式按照知识库的体系放在合适的路径下。这里有个小细节要注意把每篇笔记的文件名改成有语义的名字比如“RAG技术综述.md”“LoRA微调实战.md”而不是“未命名笔记.md”。文件名在检索中会作为重要权重参与匹配好的命名习惯能显著提升召回率。第二步是在Dify里创建知识库。选择“上传新的知识库”把Obsidian的笔记文件夹整个拖进去。Dify会自动解析Markdown文档但它默认的分块逻辑不一定完全符合你的知识库结构需要在“分块设置”里调整。我个人习惯把分块大小设置在500-800个token之间重叠量在50-100个token这样既能保留上下文又不会让向量化后的语义过于稀薄。如果你的笔记比较长可以按标题语义切块Dify的“结构化分块”模式能识别标题层级效果更好。第三步是配置Embedding模型。在Dify的“模型供应商”页面添加一个OpenAI兼容的Embedding API或者用本地Ollama提供的Embedding接口。我用的是BGE-M3通过Ollama跑起来之后在Dify里填一下API地址和模型名称就行。配置完会自动对知识库执行索引生成向量库。第四步是创建AI应用。在Dify里新建一个“聊天助手”应用关联刚才配置的知识库然后在“提示词编排”里设置角色指令比如“你是我的大模型学习助手请根据知识库内容回答问题如果答案不在知识库中请直接说明你不知道而不是编造答案”。这个提示词直接决定了问答系统的工作方式建议多花点心思调优。Dify里的LLM设置就在应用编排页面的“模型”下拉框里选择可以随时切换不同的模型提供商同时把“知识库”作为工具配置进去。第五步是联调验证。这个步骤的核心任务是测试不同类型问题的回答效果。经验是准备三组测试问法第一组是直接能得到答案的问题比如“什么是KV Cache”第二组是需要跨笔记整合的问题比如“训练一个领域模型需要做哪些数据准备”第三组是知识库覆盖不到的问题比如“如何做量化交易”。通过三组测试可以判断系统的检索准确率和拒答能力。5.4 检索优化实测分块策略、命中率监控、Rerank链路跑通只是第一步真正让问答效果从“能用”到“好用”后面还有很多优化工作。我分享几个经过实测有效的方法。第一个是分块策略的精细调整。我一开始用Dify默认的分块方式500个token直切结果发现很多跨块的语义被切断了。比如一篇讲“预训练损失函数”的笔记前半部分在讲交叉熵后半部分在讲对比损失直切之后会对检索造成干扰。后来我改成按Markdown标题分割并在Dify的“分块设置”里开启“按Markdown标题分割”模式命中率明显提升。第二个是关注命中的顺序和分数。Dify知识库的命中结果可以在调试面板里查看里面有一栏显示了知识库命中的文档片段和相似度分数。如果一个问题命中的不是我希望的文档我会点开看看是哪些片段命中了然后调整提问方式或者补充缺失的内容。这个过程就跟调搜索引擎一样需要反复迭代。第三个是引入Rerank重排。Dify平台支持配置Rerank模型它的作用是从知识库里召回更多候选片段再对候选片段进行相关性重排取最相关的结果提交给大模型。加了Rerank之后效果提升非常明显特别是那些知识库内容较多、容易命中噪声片段的场景。我用的Rerank模型还是一个本地的BGE-Reranker通过Ollama部署整个链路完全本地化。6. 资料收集与回放归档让Wiki持续“长”起来6.1 信息源分类与收集工作流的落地知识库的一大难题是更新。如果建完之后就扔在那里不管几个月就变成死库了。llm_wiki的更新机制我设计了一套半自动化的流程核心思路是把信息源分类给每一类信息源规划一条固定的收集路径。我把信息源分成了五类在线文章和博客、论文和预印本、视频和直播回放、代码仓库和发行说明、自己产出的实践笔记。每一类都有对应的收集方式。在线文章用浏览器插件一键剪藏到Obsidian的Inbox文件夹论文直接保存PDF到附件目录并顺手创建一篇论文笔记视频回放记录标题、链接和时间戳如果有配套的PPT或文档也一并归档代码仓库则记录版本号和关键commit信息。这套工作流的核心是“随手收集、定期清理”的原则。Obsidian里我专门建了一个“0-Inbox”文件夹所有来不及处理的资料先丢进去每周抽一个固定时间处理一次Inbox该归档的归档该写笔记的写笔记该丢弃的直接删除。没有这个环节收集流程很快就会因为垃圾内容堆积而失效。6.2 直播回放与技术会议资料的知识化处理在大模型这个领域技术分享直播和回放是非常宝贵的学习资源。热词列表里有一条“资料以及回放汇总”的链接这类的汇总我通常会在观看之前就建好一篇资料索引笔记把回放链接、日程安排、演讲人信息记录下来。等看完之后再把每一场分享的重点提炼成要点挂到对应的知识模块下。这里有一个人人都会踩的坑很多人把回放链接往收藏夹一扔就相当于看过了。实际上回放的观后整理效率非常低因为视频是线性的翻某个知识点要拖进度条。我的办法是在观看回放的同时结合大会官网发布的讲义或PPT文档来做补充笔记视频内容只是辅助理解最终沉淀的知识载体是文字笔记而不是视频本身。如果一场分享我只看视频没有形成笔记那么这次学习在知识库层面的收益几乎为零。6.3 知识生命周期谁来决定条目该被淘汰或升级知识库建久了一定会遇到一个问题有些笔记过时了。比如我早期记录的一些关于“LLaMA微调”的内容在今天看来指令微调的技术方案已经有了很大的变化旧笔记里的某些结论已经不准确了。llm_wiki处理这个问题的办法是给每条笔记定义了一种“状态”todo没看、doing正在整理、done已完成、stale已过时、merged已合并到其他笔记。每过两三个月我会根据当前的知识水平重新评估一遍知识库里的笔记过时的内容不会直接删除而是标记为stale保留在知识库中作为历史记录同时新建一篇升级版笔记来替代它。这种处理方式兼顾了知识的迭代和历史的追溯。另一个常见情况是两篇或多篇笔记内容高度重合。比如我有一篇叫做“什么是Prompt Engineering”的概念笔记还有一篇“Prompt编写技巧汇总”的实战笔记时间长了之后两者的内容开始重叠。遇到这种情况我会把内容合并进更完整的那篇另外一篇标记为merged再用双向链接把两篇关联起来。7. 踩坑记录我在llm_wiki建设中交过的学费7.1 双向链接一时爽过度设计火葬场我刚开始用Obsidian的时候陷入了双向链接的狂热中。每篇笔记都要关联五六篇相关笔记图谱视图密密麻麻像蜘蛛网一样看起来很酷炫实际使用的时候发现根本没帮助。因为链接一旦过多就丧失了导航的作用你看到一堆蓝色链接根本不知道该点哪一个。后来我给自己定了一个规则每篇笔记的“相关笔记”最多列五个而且必须是对理解当前这篇内容真正有帮助的链接而不是看起来相关但实际作用不大的链接。泛滥的链接宁可删掉保持知识库的“轻量感”。相信我知识库维护的核心矛盾不是信息不足而是噪声太多。7.2 本地小模型的效果边界别对离线问答期待过高我在前面提到了本地部署小模型作为离线兜底方案。实测下来本地模型的问答效果确实和云端大模型有明显差距特别是跨笔记整合复杂信息的时候。比如问“比较一下几种主流的Embedding模型选型思路”本地小模型给出的答案往往会遗漏几个重要的对比维度而云端模型因为本身的推理能力更强同样的上下文条件下回答质量会高一块。所以我的建议是如果你主要用知识库来处理日常问题和深度整合分析优先选择能力强一些的云端大模型API把本地模型作为隐私要求极高的场景的保底方案。不要因为追求“本地部署”的极客光环牺牲了问答效果的核心体验。7.3 RAG检索不到先从分块和命名排查遇到RAG检索效果不好的问题大多数人第一反应是换模型、调提示词但实测下来大部分检索问题出在数据侧。我有一次问“什么是MHA和MQA的区别”系统死活检索不到那篇笔记后来排查发现那篇笔记在文件夹里但是Embedding索引在知识库创建之后没有重建新笔记没有被纳入向量库。重新建一次索引就好了。另一个常见问题是笔记的标题和内容不一致。比如我有一篇笔记标题叫“大模型的推理优化笔记”里面其实详细讲了PagedAttention、连续批处理、投机采样这些技术但是如果用户问“什么是投机采样”系统靠标题和开头的语义可能命中不了这篇笔记。解决办法是第一篇大文档里的关键概念拆分成独立的笔记或者在原笔记开头写一个小目录摘要让检索更容易命中。7.4 Embedding模型与检索语境的匹配问题最后一个值得展开的坑是Embedding模型的选择。我一开始偷懒用了一个比较老的本地Embedding模型结果发现检索效果特别差很多明显相关的文档都搜不到。后来换了BGE-M3之后检索质量立刻上了一层楼。不同Embedding模型的语义理解能力差距非常大特别对于中文内容老模型的词表覆盖和语义编码能力都会成为瓶颈。另外要注意检索时的问题也应该和Embedding模型兼容正常情况下不用额外处理但如果你的用户习惯抛出很口语化的长句建议在接入LLM之前先用提示词对问题做一次改写和压缩把口语化提问转换成更贴近官方文档语气的检索式提问这样检索的准确率会有比较明显的提升。8. 这个项目后续还能怎么扩展llm_wiki走到现在已经不只是我个人的学习笔记了它逐渐变成了一个可以承载多种智能化任务的底座。我还在持续完善它这里分享几个正在做和打算做的扩展方向。第一个方向是和Agent结合。热词列表里频繁出现的“llm powered autonomous agents”让我意识到知识库和Agent结合之后可以做的事情远超现在的问答系统。比如我可以让一个Agent在知识库基础上自主规划学习路径根据我对某个知识模块的掌握程度自动推荐下一阶段应该学什么、练什么甚至自动生成针对性的练习题。这样llm_wiki就不光是“被动的问答库”而是变成了“主动的学习助理”。第二个方向是数据准备能力的强化。热词里有“垂域llm数据准备”这和知识库的积累其实一脉相承。llm_wiki里大量的整理好的领域内容本身就是训练领域大模型的优质语料素材。我打算后续把知识库导出的Markdown文件做进一步的清洗和格式化按照对话式QA对整理成训练数据集迁移到模型微调的场景里使用。这样一来wiki积累的知识能够反过来反哺模型本身。第三个方向是更复杂的知识推理能力。当前的RAG问答还是偏“单跳检索”也就是一个问题对应一段直接相关的知识。但实际场景里很多问题需要跨多篇笔记进行推理。Dify也支持多路知识库检索然后汇总答案但要真正做到让模型在不同笔记之间进行深度推理整合还需要在设计上引入知识图谱或者更复杂的索引结构。这个方向我正在调研后续完全落地了再写一篇专门的分享。第四个方向是社区化。如果把llm_wiki的目录体系和模板规范做成一整套可以导出的模板库发布出去让其他学习者直接套用就能避免大家从零开始搭知识库的痛苦。比如热词搜索里关于“英灵神殿wiki”“后室wiki”等游戏和社区wiki的讨论让我看到很多人对wiki的想象依然是“别人搭好的站点”但实际上个人知识库的搭建门槛已经降到很低了。我打算后续把这套体系整理成一份可直接导入的Obsidian Vault模板包含目录结构、四类笔记模板、Dataview查询示例和Dify配置指南有需要的朋友可以直接拿去用。最后再分享一个小技巧无论知识库用了多复杂的工具链最终的核心还是“持续地产出你自己的理解”。llm_wiki本质上是一个用工具倒逼思考的系统工具再完善如果不坚持每周往里填充属于自己的内容它很快就变成一堆华而不实的空架子。所以从今天开始哪怕只建一个文件夹、写一篇三百字的概念笔记也比等所有条件完美再开始要强得多。