本文介绍了如何利用 WorkBuddy Obsidian LLM wiki 搭建个人知识库重点讲解了 Obsidian 的优势、Agent 和 LLM wiki 的作用以及如何使用 claude-obsidian 项目实现高效的知识库构建。文章还讨论了知识摄入、查询、保存等操作并提出了知识库健康检查和自动研究的建议。最后作者分析了 LLM wiki 在个人和企业场景下的适用性指出其在个人使用中更具优势。做了快 2 年的 AI 课题了终于出了一篇 10万 爆款这里也从侧面反映了一个问题大家对 Agent Obsidian LLM wiki 搭建个人知识库这件事兴趣挺高的之前只是介绍了搭建的大致流程大家真正要去做搭建时会发现还存在许多问题有点不知道从何下手或者搭建起来之后发现效果也不咋滴。今天给大家介绍一种更快的搭建方法、以及过程中需要注意的一些问题。开始前还是先科普一下为什么是 Agent Obsidian LLM wiki 这套组合它们的分工是怎么样的Obsidian 的优势先说分工问题其中 Obsidian 是一款本地化的笔记软件负责文件管理而 LLM wiki 是一套构建知识库系统的框架Agent 则是负责整理我们的知识然后我们看为啥要用 Obsidian用 Notion、IMA、NotebookLM 不行吗Obsidian 第一个优势是绝对的数据主权不被平台绑定。它所有的笔记都以 Markdown 格式保存在电脑本地而不是保存在厂商的服务器上完全不用担心数据泄漏、或因平台停止服务而迁移笔记等问题并且所有本地 Agent 都可以便捷的读取或写入你的本地笔记文件。而 Notion、IMA、NotebookLM 等死死的依附于平台你后续想要做知识迁移从一个平台到另一平台格式可能不兼容。Obsidian 第二个优势是不鼓励使用文件分类去管理笔记而是用双向链接去关联知识通过[[笔记标题]]语法就能在两篇笔记间创建双向链接。基于这些链接Obsidian 会自动生成一个关系图谱让我们能直观地看到所有笔记和概念之间的关联就像一张由我们的思想编织成的网络模拟了人脑的联想方式。另外就是Obsidian 有强大的插件生态可以像搭乐高一样为它添加看板像 Trello、表格数据库、日历、思维导图等功能。其中最著名的如 Dataview 插件能让你像操作数据库一样查询笔记可玩的属性非常高我们能把它改造成任何模样。综合这几点在构建个人知识库这个场景下是很有优势的。在这个组合中Obsidian 更多的是承担文件管理或可视化的职责而知识库的构建质量并不取决于 Obsidian 本身而是在于使用的 Agent 能力或者构建知识库系统的框架因此大家不要神化它而 Agent 工具的选择主要看大家的使用门槛选择一款你平常主流使用的即可比如 WorkBuddy、QoderWork、Codex、Claude Code 都行。因为 Agent 这里的职责是根据要求读取本地笔记内容然后整理文件、编译知识以及长期维护知识系统每个 Agent 都能干这些事情。其实这里比较重要的是模型优质模型会带来优质的编译LLM wikiLLM wiki 是这套知识库系统的灵魂所在具体的思想之前聊了几次大家可以自己看看这里就不再赘述了这里我们更进一步来看怎样更好的实践这套理念这里我找了一个 Github 上面比较火的项目 claude-obsidian也是目前很多人都在使用的。它是基于 Karpathy 提出的 LLM wiki 这套理念的实践并把整个流程 Skill 化了还做了很多的优化。这里大家不要被名字误导它不只是在 claude code 中能使用也可以在 WorkBuddy、Codex、Cursor 等 Agent 中使用。下面我们依次来看整体流程安装 Claude-Obsidian 插件这里我们以 Claude-Code 为例子默认大家已经 Claude-Code 使用没问题。打开命令行依次执行如下命令# 第一步: 添加插件市场 claude plugin marketplace add AgriciDaniel/claude-obsidian # 第二步安装插件 claude plugin install claude-obsidianagricidaniel-claude-obsidian初始化仓库首先我们打开 Obsidian点击【创建】在指定文件夹下创建一个新的仓库这里命名为 llm-wiki-claude并使用 Git 版本管理工具初始化仓库便于后续管理版本记录然后在路径下使用Claude-Code打开并输入/claude-obsidian:wiki指令初始化项目。在这一步它会询问我们创建知识库的主要用途是啥并罗列出了6种模式让我们选择每一种模式对应的目录结构设计是不同的这里我们选择项目研究最终搭建出来的项目结构如下如果选择其它的模式wiki这一层的目录结构会存在差异因为它是由标准基础结构模式特有层组合而成的。下面是标准的基础结构从这个步骤来看我们之前的搭建过程有个小错误一开始就没有明确搭建知识库的目的是啥直接就创建了一套由 karpathy 提出的标准化结构其实并不一定匹配场景。目录结构的设计本质上是对知识的抽离模型的设计不同场景的知识库结构还是存在很大不同的。Claude Obsidian 这个项目它内置了 6 种知识库场景每种模式的具体的目录结构可以看项目源码中的 wiki 这个 skill 下的 modes 文件这里不做展开。模版完善通过上一步我们完成了仓库的初始化操作按理来说可以直接进行知识的摄取了但是不要着急我们先得看看生成的框架是否真的可用。原始知识从 raw 文件中被 Agent 抽离到 wiki 中结构元素需要被约束不能让 AI 随意发挥其中/_templates文件夹中的模版文件就很重要它约定了被写入 wiki 中的知识结构是怎样的以及每个页面需要包含的元信息有哪些。如果这个没有被约束大模型在编译知识的时候就会随意发挥从上面文件结构可以看出来模版文件和wiki下的目录并不是一一对应的其中 gaps、meta、domains、thesis、comparison 就没有模版文件那么最这里最好是补齐未定义的页面类型模版。下面我们看一个模版文件的基本构成这里以 Question 为例子--- type:question status:answered question: sources_consulted:[] confidence:medium tags:[question] created:{{date}} updated:{{date}} --- # Q: {{title}} ## Question *Theoriginalquestionasasked.* ## Answer *Synthesizedanswerbasedonwikicontext.* ## Sources *Whichwikipageswereconsulted.* ## Confidence *Howconfidentweareinthisanswerandwhy.* ## Follow-ups *Openthreadsfromthisquestion.*开头部分是页面的元信息元信息的设计是有标准可循的基于都伯林核心元数据标准图书团学的国际标准扩展的主要用途是结构化描述这个页面的基本信息便于后续做查询过滤、知识状态标记、图谱构建等。而正文部分则是每个知识单元的关键构成比如Quesion这个模版中它包含用户问的原始问题、基于wiki生成的答案、生成答案时参考了哪些wiki页面、这个答案生成的置信度和理由、衍生问题。把优质回答写回wiki时就要遵循这套模版要求确保答案一定是基于wiki页面生成的而不是靠大模型预训练知识回答的并且还要做知识溯源和置信度评分。这里主要想通过这个示例模版文件来表达每个类型的知识生成一定是有框架去限制的而不是让模型自由发挥。知识摄入这里我找一篇之前写过的公众号文章《向量检索、知识图谱与 LLM WikiRAG 被嘲笑了三年但企业还是离不开它》作为知识源先加入.raw文件夹中然后进行知识编译。知识摄入操作使用如下命令/claude-obsidian:wiki-ingest基于单篇文章最终新建了16个页面主要抽离了6个核心概念、5个实体对象、并抽离出文章中的重要观点、以及下一步知识补足建议。结合原文内容以及编译结果整体质量还是很不错的实体和概念以及观点都能一一对应。不过多次操作之后会遇到一个实际的问题如果重复执行摄入指令如何避免知识源文件被重复的编译生成呢比如前面我的指令并没有指定文件路径那下一次我又加入了新的知识文件后是不是要指定编译新加的文件路径呢不需要的直接输入前面的摄入指令就行。因为每次摄入时都会为文件生成内容hash值然后在.raw/.manifest.json 文件中检查是否有相同 hash如果命中则跳过编译未命中则正常处理。编译完成后在把本次摄入的源文件hash值记录到.manifest.json中下次再 ingest 它会直接跳过。另外经过一段时间的实践发现少量知识摄入的质量是很高的可能跟短上下文和内容足够聚焦有关系。但单次知识摄入太多、或主题分散的时候抽离的质量会出现明显下降对应的概念、实体、结论会漏掉。另外知识源的质量也非常的关键如果一股脑的把看到的文章都直接塞入进来模型基于错误的知识进行加工生成的知识也是错误最终就是典型的垃圾进垃圾出了。所以要想保证知识库的质量除了合理控制单次摄入量还得从源头把关慎重选择知识源文件。知识查询知识查询操作使用如下命令/claude-obsidian:wiki-quey rag 有哪些检索技术检索结果如下图其中红框中的核心判断是高度符合原文表达的。在上一篇文章中我们讲过它的检索思路是先查 wiki/index.md 这个索引文件然后在按需查找相关的页面跟 Skill 的渐进式披露机制类似。这样设计的有个好处是提升检索效率、同时能减少 Token 的消耗。Claude Obsidian 还做了一个优化措施每次操作后无论是写入还是查询都会把本次关键上下文写入到hot.md文件中大约500词注意这里写入是直接覆盖。后续会话过程中无论是新开会话还是跨项目使用都会优先读取hot.md的缓存内容相比直接读index N 个页面单次 query 能省下 70% 的 token。它是通过本地文件把会话关键信息持久化保存确保上下文在不同会话中能够被衔接无需我们重复解释让下一次 query 不必从零开始从而节省很多的Token消耗。回答保存如果这个回答质量高我们可以把对话内容归档到wiki中去使用如下命令/claude-obsidian:save结果如下这里就会用到前面的Question模版文件了把刚刚对话的问题和答案以及参考的wiki页面写入到wiki/questions中。看下面的截图我打开一个新的会话询问相同的问题从结果可以看出当我们再问同样的问题时没有重新去wiki里面找相关的页面然后在组织答案而是直接基于现成答案进行回答的回答的内容与前面完全一致。但是这里有个问题答案被沉淀到wiki中如果对应的知识页面发生了更新但是这里答案可能仍然没有更新我们下次检索时拿到的答案就是落后的。这里有两种处理办法第一种是在检索流程中增加交叉验证不仅从wiki/questions中查找拿到结果还要从相关的概念、实体等页面中检验现在的答案是否正确。第二种是从源头解决在知识摄入时如果已有的wiki页面发生了更新同步更新引用该wiki页面的question页面的元信息把 stale字段设置为true。后续在统一扫描过期的答案集中治理。自动研究前面说的知识摄入处理流程是我们提供资料Agent帮我们整理。但是实际情况是我们提供的资料难免会有空缺导致我们知识缺口长期存在。比如前面我只加入了一篇文章关于RAG知识体系还差很多内容我想补足Agentic RAG这部分知识到wiki中来但是又没有高质量的知识摄入这时候就可以用autoresearch的能力自动补足缺口知识。使用方式如下它的工作流程是根据我们输入的Topic分解成3-5个搜索角度跑3轮大约45次webSearch。第一轮围绕主题从不同角度分别去找资料第二轮基于第一轮发现的空白和矛盾在做针对性搜索第三轮如果仍然存在关键缺口就继续补充否则就进入整理阶段。最后把结果沉淀到wiki中。过程听起来很好但是实践下来你会发现效果很糟糕这里我的经验是autoresearch仅适合补足空白知识并且主题范围越小结果越好。因为它是联网搜索去抓取内容你主题定得太大它可能抓回来一堆主题分散的资料并且这里还要限定抓取的信息源优先抓官方文档避开营销软文。在编写提示词的时候就需要花些功夫把研究主题聚焦、研究范围写明确、约束条件写清楚像上面的示例一样。健康检查通过前面可以发现整个知识摄入过程完全取决于大模型的处理一开始笔记少的时候靠人工二次确认也没问题但是知识库页面增长后问题就会出现比如孤立页面、死链接、过期结论、缺失页面、交叉引用缺失、元信息缺失、索引漂移等。这时候就需要定期执行/claude-obsidian:wiki-lint这个skill会帮我们完成上面的检查检查完成后它会在wiki/meta下面生成一份检测报告告诉当前知识库哪里有问题哪些可以自动修哪些需要人工判断。这一步很重要建议定期检测每摄入15次就做一次健康检查让知识库wiki保持健康状态。但这里的问题是如何让wiki记住摄入的次数以便到达对应次数的时候主动提醒我们否则很容易忘记。这里的处理办法是在摄入工作流末尾添加如下规则摄入完成后读取 log.md 1. **计算距上次 lint 操作的 ingest 次数** 2. **如果 ≥ 15 次主动告述用户建议进行健康检查并等待确认** 3. **如果 15 次不提**LLM wiki不是一次性工程而是一个会长期生长的系统只要持续摄入就需要持续治理。本地检索前面讲的查询流程默认是先查hot.md在查index.md然后查相关页面这种方式对于小型知识库很好用但是当我们的wiki持续变大之后检索效率就极大下降并且Token消耗也很大。要解决这个性能瓶颈Claude-Obsidian这个项目集成了本地检索方案也就是wiki-retrieve它的核心流程是先把wiki页面拆分为小的chunk;给每个chunk生成上下文前缀确保这个chunk脱离原文也能被理解基于这些chunk构建BM25关键词索引查询时先用BM25召回候选片段在用向量相似度做语义重排Agent读取命中的原始页面在生成最终答案。注意这里方案是基于BM25关键词进行检索的而不是用纯向量检索它只是用向量进行语义重排。之所以这样做因为本地知识库内容经常变纯向量构建成本太高。这种检索方案是可选的需要单独初始化才可用默认还是的前面介绍的检索流程。当你的个人知识出现性能瓶颈的时候才建议激活使用。总结以上就是 Claude-Obsidian 搭建个人知识库的实践整体流程还是很简单清晰使用成本也很低只是搭建过程中仍有些细节需要注意希望这篇能帮你更顺利地构建属于自己的知识库系统。最后之前有很多同学在关注这个东西能不能用到企业场景我这里也简单的说下吧首先LLM Wiki 这套架构的核心优势是自动知识提炼与结构化从文章、笔记等原始资料中Agent 能自动生成概念页、实体页、论点页等把隐性知识网络显性化、结构化这比人手一条条整理快得多。若以此兴必以此亡因为 LLM Wiki 吃了大模型整理文档的红利那就天生要承担其缺陷第一知识质量高度依赖模型和源材料。如果源文件垃圾或者模型能力不行那么抽出来的信息就要完蛋。虽然现在模型多数第二多人实时协作与权限控制薄弱。它是基于本地文件 Git 的工作流没有类似钉钉文档、飞书文档那样的多人实时共同编辑、细粒度的页面级权限。如果要团队使用得依赖 Git 分支、拉取请求来协作对非技术背景的成员门槛较高。最后就是数据量大了后的情况我还没测试但想来单机文件系统可能也不太容易所以这里结论是LLM Wiki 更适合个人使用企业可能很难使用因为要考虑成本和效率的单单是Token 消耗、查询频次、文档后置的维护成本就过不去。所以如果你的目标是要做一个对外的、多用户的、成本敏感的企业知识库LLM Wiki 这条纯 Agent 驱动的技术路径需要大量工程改造如增加问答缓存、分层检索等而改造后的系统可能已经偏离了LLM Wiki强调的零摩擦、自生长的初衷了…最后如果说程序员已经是高薪职业那么干AI的程序员就是高薪中的高薪。现在的市场已经用数据给程序员指明了方向学AI大模型就是冲刺高薪的最优解看着身边越来越多的同行转型大模型、拿到高薪offer很多人心里都动了心但真正的难题来了零基础小白不知道从哪入门有基础的程序员找不到系统学习路径实战项目练手无门面试不知道考什么别慌今天就给大家整理了一份【2026年最新版】AI大模型免费学习资源包覆盖从入门到实战、从理论到面试、从基础到进阶的全流程所有资料均已整理归档无冗余、无套路免费分享给每一位想抓住AI风口的程序员和小白扫码免费领取全部内容1、大模型系统化学习路线2、大模型学习书籍文档3、AI大模型最新行业报告4、大模型项目实战配套源码5、大模型大厂面试真题四阶段精细化学习规划附时间节点可直接照做结合上述资源给大家整理了一份可直接落地的四阶段学习规划总时长约2个月小白可循序渐进程序员可根据自身基础调整节奏高效掌握大模型核心能力快速实现从“入门”到“能落地、能面试”的跨越。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】https://mp.weixin.qq.com/s/mrlUwWk158urYwE4mlETywhttps://mp.weixin.qq.com/s/mrlUwWk158urYwE4mlETyw
本文介绍了如何利用 WorkBuddy Obsidian LLM wiki 搭建个人知识库重点讲解了 Obsidian 的优势、Agent 和 LLM wiki 的作用以及如何使用 claude-obsidian 项目实现高效的知识库构建。文章还讨论了知识摄入、查询、保存等操作并提出了知识库健康检查和自动研究的建议。最后作者分析了 LLM wiki 在个人和企业场景下的适用性指出其在个人使用中更具优势。做了快 2 年的 AI 课题了终于出了一篇 10万 爆款这里也从侧面反映了一个问题大家对 Agent Obsidian LLM wiki 搭建个人知识库这件事兴趣挺高的之前只是介绍了搭建的大致流程大家真正要去做搭建时会发现还存在许多问题有点不知道从何下手或者搭建起来之后发现效果也不咋滴。今天给大家介绍一种更快的搭建方法、以及过程中需要注意的一些问题。开始前还是先科普一下为什么是 Agent Obsidian LLM wiki 这套组合它们的分工是怎么样的Obsidian 的优势先说分工问题其中 Obsidian 是一款本地化的笔记软件负责文件管理而 LLM wiki 是一套构建知识库系统的框架Agent 则是负责整理我们的知识然后我们看为啥要用 Obsidian用 Notion、IMA、NotebookLM 不行吗Obsidian 第一个优势是绝对的数据主权不被平台绑定。它所有的笔记都以 Markdown 格式保存在电脑本地而不是保存在厂商的服务器上完全不用担心数据泄漏、或因平台停止服务而迁移笔记等问题并且所有本地 Agent 都可以便捷的读取或写入你的本地笔记文件。而 Notion、IMA、NotebookLM 等死死的依附于平台你后续想要做知识迁移从一个平台到另一平台格式可能不兼容。Obsidian 第二个优势是不鼓励使用文件分类去管理笔记而是用双向链接去关联知识通过[[笔记标题]]语法就能在两篇笔记间创建双向链接。基于这些链接Obsidian 会自动生成一个关系图谱让我们能直观地看到所有笔记和概念之间的关联就像一张由我们的思想编织成的网络模拟了人脑的联想方式。另外就是Obsidian 有强大的插件生态可以像搭乐高一样为它添加看板像 Trello、表格数据库、日历、思维导图等功能。其中最著名的如 Dataview 插件能让你像操作数据库一样查询笔记可玩的属性非常高我们能把它改造成任何模样。综合这几点在构建个人知识库这个场景下是很有优势的。在这个组合中Obsidian 更多的是承担文件管理或可视化的职责而知识库的构建质量并不取决于 Obsidian 本身而是在于使用的 Agent 能力或者构建知识库系统的框架因此大家不要神化它而 Agent 工具的选择主要看大家的使用门槛选择一款你平常主流使用的即可比如 WorkBuddy、QoderWork、Codex、Claude Code 都行。因为 Agent 这里的职责是根据要求读取本地笔记内容然后整理文件、编译知识以及长期维护知识系统每个 Agent 都能干这些事情。其实这里比较重要的是模型优质模型会带来优质的编译LLM wikiLLM wiki 是这套知识库系统的灵魂所在具体的思想之前聊了几次大家可以自己看看这里就不再赘述了这里我们更进一步来看怎样更好的实践这套理念这里我找了一个 Github 上面比较火的项目 claude-obsidian也是目前很多人都在使用的。它是基于 Karpathy 提出的 LLM wiki 这套理念的实践并把整个流程 Skill 化了还做了很多的优化。这里大家不要被名字误导它不只是在 claude code 中能使用也可以在 WorkBuddy、Codex、Cursor 等 Agent 中使用。下面我们依次来看整体流程安装 Claude-Obsidian 插件这里我们以 Claude-Code 为例子默认大家已经 Claude-Code 使用没问题。打开命令行依次执行如下命令# 第一步: 添加插件市场 claude plugin marketplace add AgriciDaniel/claude-obsidian # 第二步安装插件 claude plugin install claude-obsidianagricidaniel-claude-obsidian初始化仓库首先我们打开 Obsidian点击【创建】在指定文件夹下创建一个新的仓库这里命名为 llm-wiki-claude并使用 Git 版本管理工具初始化仓库便于后续管理版本记录然后在路径下使用Claude-Code打开并输入/claude-obsidian:wiki指令初始化项目。在这一步它会询问我们创建知识库的主要用途是啥并罗列出了6种模式让我们选择每一种模式对应的目录结构设计是不同的这里我们选择项目研究最终搭建出来的项目结构如下如果选择其它的模式wiki这一层的目录结构会存在差异因为它是由标准基础结构模式特有层组合而成的。下面是标准的基础结构从这个步骤来看我们之前的搭建过程有个小错误一开始就没有明确搭建知识库的目的是啥直接就创建了一套由 karpathy 提出的标准化结构其实并不一定匹配场景。目录结构的设计本质上是对知识的抽离模型的设计不同场景的知识库结构还是存在很大不同的。Claude Obsidian 这个项目它内置了 6 种知识库场景每种模式的具体的目录结构可以看项目源码中的 wiki 这个 skill 下的 modes 文件这里不做展开。模版完善通过上一步我们完成了仓库的初始化操作按理来说可以直接进行知识的摄取了但是不要着急我们先得看看生成的框架是否真的可用。原始知识从 raw 文件中被 Agent 抽离到 wiki 中结构元素需要被约束不能让 AI 随意发挥其中/_templates文件夹中的模版文件就很重要它约定了被写入 wiki 中的知识结构是怎样的以及每个页面需要包含的元信息有哪些。如果这个没有被约束大模型在编译知识的时候就会随意发挥从上面文件结构可以看出来模版文件和wiki下的目录并不是一一对应的其中 gaps、meta、domains、thesis、comparison 就没有模版文件那么最这里最好是补齐未定义的页面类型模版。下面我们看一个模版文件的基本构成这里以 Question 为例子--- type:question status:answered question: sources_consulted:[] confidence:medium tags:[question] created:{{date}} updated:{{date}} --- # Q: {{title}} ## Question *Theoriginalquestionasasked.* ## Answer *Synthesizedanswerbasedonwikicontext.* ## Sources *Whichwikipageswereconsulted.* ## Confidence *Howconfidentweareinthisanswerandwhy.* ## Follow-ups *Openthreadsfromthisquestion.*开头部分是页面的元信息元信息的设计是有标准可循的基于都伯林核心元数据标准图书团学的国际标准扩展的主要用途是结构化描述这个页面的基本信息便于后续做查询过滤、知识状态标记、图谱构建等。而正文部分则是每个知识单元的关键构成比如Quesion这个模版中它包含用户问的原始问题、基于wiki生成的答案、生成答案时参考了哪些wiki页面、这个答案生成的置信度和理由、衍生问题。把优质回答写回wiki时就要遵循这套模版要求确保答案一定是基于wiki页面生成的而不是靠大模型预训练知识回答的并且还要做知识溯源和置信度评分。这里主要想通过这个示例模版文件来表达每个类型的知识生成一定是有框架去限制的而不是让模型自由发挥。知识摄入这里我找一篇之前写过的公众号文章《向量检索、知识图谱与 LLM WikiRAG 被嘲笑了三年但企业还是离不开它》作为知识源先加入.raw文件夹中然后进行知识编译。知识摄入操作使用如下命令/claude-obsidian:wiki-ingest基于单篇文章最终新建了16个页面主要抽离了6个核心概念、5个实体对象、并抽离出文章中的重要观点、以及下一步知识补足建议。结合原文内容以及编译结果整体质量还是很不错的实体和概念以及观点都能一一对应。不过多次操作之后会遇到一个实际的问题如果重复执行摄入指令如何避免知识源文件被重复的编译生成呢比如前面我的指令并没有指定文件路径那下一次我又加入了新的知识文件后是不是要指定编译新加的文件路径呢不需要的直接输入前面的摄入指令就行。因为每次摄入时都会为文件生成内容hash值然后在.raw/.manifest.json 文件中检查是否有相同 hash如果命中则跳过编译未命中则正常处理。编译完成后在把本次摄入的源文件hash值记录到.manifest.json中下次再 ingest 它会直接跳过。另外经过一段时间的实践发现少量知识摄入的质量是很高的可能跟短上下文和内容足够聚焦有关系。但单次知识摄入太多、或主题分散的时候抽离的质量会出现明显下降对应的概念、实体、结论会漏掉。另外知识源的质量也非常的关键如果一股脑的把看到的文章都直接塞入进来模型基于错误的知识进行加工生成的知识也是错误最终就是典型的垃圾进垃圾出了。所以要想保证知识库的质量除了合理控制单次摄入量还得从源头把关慎重选择知识源文件。知识查询知识查询操作使用如下命令/claude-obsidian:wiki-quey rag 有哪些检索技术检索结果如下图其中红框中的核心判断是高度符合原文表达的。在上一篇文章中我们讲过它的检索思路是先查 wiki/index.md 这个索引文件然后在按需查找相关的页面跟 Skill 的渐进式披露机制类似。这样设计的有个好处是提升检索效率、同时能减少 Token 的消耗。Claude Obsidian 还做了一个优化措施每次操作后无论是写入还是查询都会把本次关键上下文写入到hot.md文件中大约500词注意这里写入是直接覆盖。后续会话过程中无论是新开会话还是跨项目使用都会优先读取hot.md的缓存内容相比直接读index N 个页面单次 query 能省下 70% 的 token。它是通过本地文件把会话关键信息持久化保存确保上下文在不同会话中能够被衔接无需我们重复解释让下一次 query 不必从零开始从而节省很多的Token消耗。回答保存如果这个回答质量高我们可以把对话内容归档到wiki中去使用如下命令/claude-obsidian:save结果如下这里就会用到前面的Question模版文件了把刚刚对话的问题和答案以及参考的wiki页面写入到wiki/questions中。看下面的截图我打开一个新的会话询问相同的问题从结果可以看出当我们再问同样的问题时没有重新去wiki里面找相关的页面然后在组织答案而是直接基于现成答案进行回答的回答的内容与前面完全一致。但是这里有个问题答案被沉淀到wiki中如果对应的知识页面发生了更新但是这里答案可能仍然没有更新我们下次检索时拿到的答案就是落后的。这里有两种处理办法第一种是在检索流程中增加交叉验证不仅从wiki/questions中查找拿到结果还要从相关的概念、实体等页面中检验现在的答案是否正确。第二种是从源头解决在知识摄入时如果已有的wiki页面发生了更新同步更新引用该wiki页面的question页面的元信息把 stale字段设置为true。后续在统一扫描过期的答案集中治理。自动研究前面说的知识摄入处理流程是我们提供资料Agent帮我们整理。但是实际情况是我们提供的资料难免会有空缺导致我们知识缺口长期存在。比如前面我只加入了一篇文章关于RAG知识体系还差很多内容我想补足Agentic RAG这部分知识到wiki中来但是又没有高质量的知识摄入这时候就可以用autoresearch的能力自动补足缺口知识。使用方式如下它的工作流程是根据我们输入的Topic分解成3-5个搜索角度跑3轮大约45次webSearch。第一轮围绕主题从不同角度分别去找资料第二轮基于第一轮发现的空白和矛盾在做针对性搜索第三轮如果仍然存在关键缺口就继续补充否则就进入整理阶段。最后把结果沉淀到wiki中。过程听起来很好但是实践下来你会发现效果很糟糕这里我的经验是autoresearch仅适合补足空白知识并且主题范围越小结果越好。因为它是联网搜索去抓取内容你主题定得太大它可能抓回来一堆主题分散的资料并且这里还要限定抓取的信息源优先抓官方文档避开营销软文。在编写提示词的时候就需要花些功夫把研究主题聚焦、研究范围写明确、约束条件写清楚像上面的示例一样。健康检查通过前面可以发现整个知识摄入过程完全取决于大模型的处理一开始笔记少的时候靠人工二次确认也没问题但是知识库页面增长后问题就会出现比如孤立页面、死链接、过期结论、缺失页面、交叉引用缺失、元信息缺失、索引漂移等。这时候就需要定期执行/claude-obsidian:wiki-lint这个skill会帮我们完成上面的检查检查完成后它会在wiki/meta下面生成一份检测报告告诉当前知识库哪里有问题哪些可以自动修哪些需要人工判断。这一步很重要建议定期检测每摄入15次就做一次健康检查让知识库wiki保持健康状态。但这里的问题是如何让wiki记住摄入的次数以便到达对应次数的时候主动提醒我们否则很容易忘记。这里的处理办法是在摄入工作流末尾添加如下规则摄入完成后读取 log.md 1. **计算距上次 lint 操作的 ingest 次数** 2. **如果 ≥ 15 次主动告述用户建议进行健康检查并等待确认** 3. **如果 15 次不提**LLM wiki不是一次性工程而是一个会长期生长的系统只要持续摄入就需要持续治理。本地检索前面讲的查询流程默认是先查hot.md在查index.md然后查相关页面这种方式对于小型知识库很好用但是当我们的wiki持续变大之后检索效率就极大下降并且Token消耗也很大。要解决这个性能瓶颈Claude-Obsidian这个项目集成了本地检索方案也就是wiki-retrieve它的核心流程是先把wiki页面拆分为小的chunk;给每个chunk生成上下文前缀确保这个chunk脱离原文也能被理解基于这些chunk构建BM25关键词索引查询时先用BM25召回候选片段在用向量相似度做语义重排Agent读取命中的原始页面在生成最终答案。注意这里方案是基于BM25关键词进行检索的而不是用纯向量检索它只是用向量进行语义重排。之所以这样做因为本地知识库内容经常变纯向量构建成本太高。这种检索方案是可选的需要单独初始化才可用默认还是的前面介绍的检索流程。当你的个人知识出现性能瓶颈的时候才建议激活使用。总结以上就是 Claude-Obsidian 搭建个人知识库的实践整体流程还是很简单清晰使用成本也很低只是搭建过程中仍有些细节需要注意希望这篇能帮你更顺利地构建属于自己的知识库系统。最后之前有很多同学在关注这个东西能不能用到企业场景我这里也简单的说下吧首先LLM Wiki 这套架构的核心优势是自动知识提炼与结构化从文章、笔记等原始资料中Agent 能自动生成概念页、实体页、论点页等把隐性知识网络显性化、结构化这比人手一条条整理快得多。若以此兴必以此亡因为 LLM Wiki 吃了大模型整理文档的红利那就天生要承担其缺陷第一知识质量高度依赖模型和源材料。如果源文件垃圾或者模型能力不行那么抽出来的信息就要完蛋。虽然现在模型多数第二多人实时协作与权限控制薄弱。它是基于本地文件 Git 的工作流没有类似钉钉文档、飞书文档那样的多人实时共同编辑、细粒度的页面级权限。如果要团队使用得依赖 Git 分支、拉取请求来协作对非技术背景的成员门槛较高。最后就是数据量大了后的情况我还没测试但想来单机文件系统可能也不太容易所以这里结论是LLM Wiki 更适合个人使用企业可能很难使用因为要考虑成本和效率的单单是Token 消耗、查询频次、文档后置的维护成本就过不去。所以如果你的目标是要做一个对外的、多用户的、成本敏感的企业知识库LLM Wiki 这条纯 Agent 驱动的技术路径需要大量工程改造如增加问答缓存、分层检索等而改造后的系统可能已经偏离了LLM Wiki强调的零摩擦、自生长的初衷了…最后如果说程序员已经是高薪职业那么干AI的程序员就是高薪中的高薪。现在的市场已经用数据给程序员指明了方向学AI大模型就是冲刺高薪的最优解看着身边越来越多的同行转型大模型、拿到高薪offer很多人心里都动了心但真正的难题来了零基础小白不知道从哪入门有基础的程序员找不到系统学习路径实战项目练手无门面试不知道考什么别慌今天就给大家整理了一份【2026年最新版】AI大模型免费学习资源包覆盖从入门到实战、从理论到面试、从基础到进阶的全流程所有资料均已整理归档无冗余、无套路免费分享给每一位想抓住AI风口的程序员和小白扫码免费领取全部内容1、大模型系统化学习路线2、大模型学习书籍文档3、AI大模型最新行业报告4、大模型项目实战配套源码5、大模型大厂面试真题四阶段精细化学习规划附时间节点可直接照做结合上述资源给大家整理了一份可直接落地的四阶段学习规划总时长约2个月小白可循序渐进程序员可根据自身基础调整节奏高效掌握大模型核心能力快速实现从“入门”到“能落地、能面试”的跨越。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容6、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】https://mp.weixin.qq.com/s/mrlUwWk158urYwE4mlETywhttps://mp.weixin.qq.com/s/mrlUwWk158urYwE4mlETyw
)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
