LLM Wiki、Obsidian 与开源实现分别解决什么问题
LLM Wiki 不是单一产品名称，而是一种把原始资料逐步编译为可链接 Markdown 知识层的工作方法。
Karpathy 的 LLM Wiki 文档描述的是方法：原始资料保持不变，模型持续维护由 Markdown 组成的 Wiki，
并以规则文件约束摄入、问答和维护。Obsidian 是本地 Vault 的阅读、编辑和链接界面；它不是这套方法的唯一入口。
nashsu/llm_wiki 则是将该方法做成跨平台桌面应用的一种开源实现，其 Wiki 目录可以作为 Obsidian Vault 打开。
LLM Wiki 与 RAG 不是二选一：一个偏知识编译，一个偏查询时检索。
经典 RAG 通常在提问时检索相关文本块，再把证据交给模型生成回答。原始 RAG 论文将参数化记忆与可检索的非参数化记忆结合， 适合大规模资料的即时召回。LLM Wiki 则在资料进入时完成一次结构化整理，把摘要、实体、概念、对比和冲突写入长期存在的 Markdown。
| 比较维度 | 传统 RAG | LLM Wiki | 实际判断 |
|---|---|---|---|
| 核心动作 | 查询时检索文本块并生成。 | 摄入时增量编译，维护可读的 Wiki 页面。 | 前者重召回，后者重沉淀。 |
| 主要产物 | 索引、向量与一次回答。 | 原始资料、页面、链接、索引与维护日志。 | Wiki 可被人工直接阅读和修改。 |
| 跨资料综合 | 每次问题可能重新拼接证据。 | 在摄入和维护阶段提前形成主题页与对比页。 | 长期研究更容易积累上下文。 |
| 强项 | 资料规模大、问题分布广、需要语义召回。 | 主题边界明确、需要可审阅结论和稳定链接。 | 先确定资料规模与使用频率。 |
| 常见风险 | 切块丢失上下文、引用漂移、每次回答不一致。 | 错误结论被写入页面、规则不清导致重复或覆盖。 | 两者都需要来源、版本和人工复核。 |
| 组合方式 | 可以组合：先以 Wiki 固化结构和人工确认，再用全文、关键词或向量检索找到相关页面和原始资料。nashsu/llm_wiki 也提供可选的向量语义搜索。 |
||
对几十到数百份主题较集中的资料，先维护清晰目录、index.md 和双向链接往往比先部署复杂基础设施更可控；
当页面和来源增长、语义召回成为瓶颈时，再把搜索能力加在 Wiki 之上。目标不是淘汰 RAG，而是让检索结果有稳定的知识落点。
最小架构只有三层：原始资料、Wiki 与规则。
三层结构把“事实来自哪里”“当前如何解释”“模型怎样工作”拆开。原始资料不被模型改写；Wiki 可以持续更新； 规则文件规定哪些动作被允许、哪些结论必须标注来源。任何自动化应当建立在这三个边界之后。
-
01 / RAW
原始资料
PDF、网页摘录、Markdown 与结构化数据只读保存，作为可回溯依据。
-
02 / WIKI
可读知识层
来源摘要、实体、概念、比较、决策与索引组成可人工审阅的 Markdown。
-
03 / SCHEMA
行为规则
目录职责、命名、页面模板、摄入步骤、查询约束与 Lint 标准统一写明。
-
04 / REVIEW
人工复核
确认引用、冲突、版本和待确认项，再允许结论进入稳定页面。
短期收集区；每周归档或删除重复件，不作为长期检索入口。
按主题保存来源文件、网页摘录和人工笔记；保留出处与时间。
保存 sources、entities、concepts、comparisons、index、overview 与 log。
集中管理图像、图表与转换后的静态附件，避免页面链接分散。
purpose.md 的字段设计：定义知识库为何存在、回答哪些问题。
purpose.md 是方向文件，不是目录规则。它帮助模型在每次摄入和查询时保持同一研究目标：
哪些资料应该纳入、优先回答哪些问题、哪些内容必须排除、什么样的输出才算有价值。
如果只写“做一个知识库”，模型只能得到空泛目标；如果写清问题和验收，生成内容更容易收敛。
| 字段 | 含义是什么 | 推荐怎么写 | 避免写法 |
|---|---|---|---|
| 目标 | 这个 Vault 要沉淀的长期成果。 | 用“围绕什么资料，形成哪些可复核输出”描述。 | “收集所有内容”“做最强知识库”。 |
| 范围 | 允许摄入与明确排除的资料边界。 | 列出主题、时间范围、资料类型及排除项。 | 只写大而泛的行业名称。 |
| 核心问题 | 模型在摄入和查询时优先服务的判断题。 | 写成可以被证据回答的问题，例如“版本差异带来哪些影响”。 | “帮忙思考”“尽量详细”。 |
| 输出形态 | 希望持续维护的页面类型。 | 明确概览、概念页、对比表、决策记录或操作清单。 | 只要求“生成笔记”。 |
| 证据标准 | 主结论与来源的绑定规则。 | 要求主结论链接到 source 页面，未知项标为“待确认”。 | 让模型在资料缺失时自由补全。 |
| 验收条件 | 如何判断这套库已能使用。 | 列出可追溯、可搜索、可恢复、冲突可见等检查项。 | 只用“内容丰富”作为标准。 |
可复制模板：purpose.md
# Purpose
## 目标
- 围绕 [主题] 汇集可信资料，形成可追溯的概览、概念页、对比页与决策记录。
## 范围
- 纳入：[资料类型]、[时间范围]、[明确主题]。
- 排除：凭据、未公开资料、无来源转述、重复文件。
## 核心问题
- [问题一：需要比较或判断的事项]
- [问题二：需要持续更新的事项]
- [问题三：需要发现冲突的事项]
## 输出与证据
- 每项主要结论链接到 source 页面或原始资料。
- 无法从资料支持的内容标记为“待确认”。
- 优先维护：overview、concept、comparison、decision、procedure。
## 验收
- 能定位来源、说明版本、暴露冲突，并在备份后恢复。模板中的方括号应替换为具体主题。一个 Vault 只解决一组相近问题通常更稳妥； 当目标、隐私等级或读者群明显不同，拆分 Vault 比在同一规则文件中叠加例外更容易维护。
schema.md 的规则设计：定义目录、页面、摄入与查询怎样执行。
schema.md 是模型的操作约定，相当于知识库的接口合同。它不讨论研究方向，而是规定“资料放在哪里、
一页如何命名、何时新建或更新、问答怎样引用、哪些情况必须停止并标记待确认”。规则越具体，生成越少依赖临时猜测。
| 规则区块 | 含义是什么 | 推荐怎么写 | 模型执行结果 |
|---|---|---|---|
| 目录职责 | 各类文件的唯一归属。 | 说明 raw 只读、wiki 可更新、附件统一存放。 | 减少原始资料被覆盖与文件散落。 |
| 页面类型 | 可创建的内容种类。 | 限定 source、concept、entity、comparison、decision、procedure。 | 减少同义重复页和不必要层级。 |
| 命名与 frontmatter | 页面身份、日期、来源与状态。 | 统一标题格式，记录 type、sources、updated、status。 | 便于筛选、检查和迁移。 |
| 摄入流程 | 处理新来源的固定顺序。 | 先分析、再生成；更新索引和日志；有冲突就创建复核项。 | 每次变更可审阅、可追溯。 |
| 查询契约 | 回答可使用什么证据、如何表达未知。 | 结论附页内链接；资料不足时列出缺口，不补充事实。 | 减少幻觉式结论与来源漂移。 |
| Lint 标准 | 定期健康检查的项目。 | 检查孤立页、失效链接、陈旧结论、冲突与无来源页面。 | 库规模扩大后仍保持可导航。 |
可复制模板：schema.md
# Schema
## 目录
- raw/：原始资料；只读，不修改来源正文。
- wiki/sources/：每个来源的摘要与出处。
- wiki/concepts/：概念与定义。
- wiki/entities/：实体、项目、角色或系统。
- wiki/decisions/：带日期和证据的判断记录。
- wiki/index.md：内容目录；每次摄入后更新。
- wiki/log.md：按时间追加的操作记录。
## 页面规则
- 新概念先查找已有页面；存在主页面时更新而非重复新建。
- 每页使用 frontmatter：type、sources、updated、status。
- 重要结论以 [[wikilink]] 连接到相关概念和来源。
## Ingest
1. 读取单个来源，提取事实、主张、时间、版本与不确定项。
2. 生成或更新 source、concept、entity、comparison 页面。
3. 更新 index.md 与 log.md；冲突写入待复核项。
## Query
- 先检索 index.md 和相关页面，再形成回答。
- 主结论给出页面链接；资料不足时说明缺口并标记“待确认”。
## Lint
- 检查孤立页面、失效链接、无来源结论、重复主题和陈旧版本。用小批量运行闭环，而不是一次性导入所有资料。
第一次摄入建议只选一份结构清晰、可以公开检查的 Markdown 或 PDF。完成一次“来源摘要 → 概念页 → 索引更新 → 引用问答” 后再扩展批量。这样能同时验证模型质量、目录规则、成本、重复页和引用格式。
读取资料、记录出处、抽取事实和冲突点；原始文件保持不变。
创建或更新来源摘要、概念、实体与对比页，并补足交叉链接。
抽查主结论、来源跳转、版本日期和待确认项，修正规则而非只修单页。
要求结论、证据、冲突与未知并列输出；高价值回答可回写为 comparison 或 decision。
查找孤立页、无来源内容、失效链接、过期结论与重复主题，持续修正结构。
推荐的提问格式
基于当前 Wiki：
1. 给出 [主题] 的结论；
2. 为每条主结论列出对应页面与来源；
3. 标出资料中的冲突、版本差异和待确认项；
4. 不使用库外事实；如资料不足，列出需要补充的来源。值得长期保留的不是聊天记录本身，而是经过引用核查的比较、流程、决策和问题清单。 每次高价值探索都回写为页面，知识库才会随着使用增加，而不是重新散落在对话历史中。
一个完整示例：提交成功是否等于作业成功？
以下是依据 Slurm 公开文档手工编写的知识库演示，不是模型实际运行记录，也没有接入生产集群。原始来源为 sbatch 文档，查询日期 2026-09-05。
raw/slurm-sbatch.md：保存来源 URL、读取日期和相关段落。
wiki/sources/slurm-sbatch.md：说明 sbatch 的提交职责与返回语义。
wiki/concepts/job-lifecycle.md：引用来源，区分已提交、排队、运行与结束。
wiki/index.md：添加作业状态条目。
wiki/log.md：记录本次新增及人工复核事项。来源摘要：sbatch 将脚本提交给控制器并取得作业 ID 后即可返回，资源可能尚未分配。因此命令返回成功，只能支持“请求已被接受”，不能支持“任务已经完成”。
示例问答：问：“拿到 job ID 后，能否读取报告并交给下游？”答：“还不能确认。先检查同一作业的实际状态和本次产物，再判断报告是否完整。依据：[[sources/slurm-sbatch]] 的提交语义；产物完整性仍需由项目定义。”
纠错：若旧概念页写成“返回 0 就代表工具成功”，应改为“sbatch 提交命令成功”，并把原来的过度推断及修正原因追加到 wiki/log.md。随后重问同一问题，检查回答是否仍把提交与执行混淆。
这个例子把原文、概念、回答和纠正连在一起。扩展资料前先检查来源链接、结论的条件和未证实部分，避免把模型生成的说法再次当成来源。
可选实现与下载入口：先按使用方式选，再看功能清单。
下列项目均为公开仓库中的代表性实现或基础工具，不按热度排名。开源项目迭代快，安装前应再次检查发布页、 许可证、所需模型、文件权限和数据流向。选择标准应落在资料敏感度、是否愿意使用桌面应用、是否需要 Agent 自动化， 以及能否接受维护规则文件上。
隐私边界、版本记录与恢复能力，决定知识库是否能长期使用。
凭据、密钥、授权文件、未公开地址、资产清单、客户资料、设计源文件和内部安全架构不应直接进入未经批准的云端模型。 资料在摄入前先分类，路径、账号和主机名替换为语义清晰的占位符。公开资料、个人资料和受限资料分 Vault、 分模型策略保存；受限资料优先采用本地模型或明确批准的隔离环境，避免“先导入，后补救”。
每个主要结论能回到 source 页面或原始文件，来源日期与版本可见。
purpose.md 和 schema.md 能让新会话按同一规则工作。
冲突、待确认项、模型改动和批量摄入结果都有可查看的记录。
原始资料与 Wiki 定期备份；恢复后能重新打开链接、索引和附件。
一个合格的个人知识系统不追求把所有信息自动写入，而是稳定地保留“从哪里来、为何这样判断、哪部分仍未确认”。 模型用于压缩重复整理工作，人工负责范围、证据与最终解释。
参考资料与延伸阅读。
外链均指向项目官方页面、原始方法或论文页面；功能、发布状态与许可证应以链接中的最新说明为准。
- Obsidian 官方下载页 ↗本地知识库编辑器与平台下载入口。
- Andrej Karpathy, LLM Wiki ↗提出 Raw Sources、Wiki、Schema 及 ingest/query/lint 的方法文档。
- nashsu/llm_wiki ↗将方法落地为跨平台桌面应用的开源实现。
- green-dalii/obsidian-llm-wiki ↗Obsidian 内嵌插件路线的公开实现。
- Ar9av/obsidian-wiki ↗面向 AI Agent 的 Wiki 工作流框架。
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks ↗RAG 的原始论文，用于理解检索增强生成的基本范式。