| name | llm-wiki |
| description | LLM 驱动的 Obsidian 个人知识库管理。当需要评估、优化、索引 Obsidian vault,或讨论知识管理、wiki 构建、LLM 辅助笔记、索引优先检索时触发。 |
LLM Wiki - LLM 驱动的 Obsidian 知识库
把 Obsidian 当 IDE,LLM 当程序员,知识库当代码库。LLM 不只回答问题 —— 它持续编译、索引和优化你的知识网络。
核心原则
传统 RAG 的致命缺陷:没有积累。 每次提问都从头检索原始文档,答案用完即弃。知识从未沉淀。
本模式的核心差异:知识复利。 LLM 增量编译原始资料为结构化 wiki,知识被编译一次并持续保持更新。每一次探索、每一次提问都在让知识库变得更好。当索引足够优化时,表现超越 RAG。
知识库的四个层次
从底到顶,知识库由四个层次构成:
┌──────────────────────────────────────────────────┐
│ 4. 输出层 (Outputs) │
│ 问答回答、综合报告、幻灯片、图表 → 归档回 wiki │
├──────────────────────────────────────────────────┤
│ 3. Wiki 层 (LLM 编译/维护) │
│ index.md · concepts/ · entities/ · synthesis/ │
│ 每篇文章建议 ≤ 500 字,超出部分用 [[ref]] 链接延伸 │
├──────────────────────────────────────────────────┤
│ 2. 原始资料层 (Raw) │
│ raw/ · articles/ · papers/ · images/ · notes/ │
│ 不可变,LLM 只读不写 │
├──────────────────────────────────────────────────┤
│ 1. 索引地图层 (Index Map) │
│ 全局 index.md + 各目录子索引 │
│ LLM 的导航入口,查询时始终在上下文中 │
└──────────────────────────────────────────────────┘
为什么分四层而不是三层?
传统三层架构(Raw → Wiki → Outputs)忽略了最关键的一层:索引地图。
索引地图不是 wiki 的一个文件 —— 它是独立的基础设施层。它决定了 LLM 能否高效地找到、理解和关联知识。好的索引地图让 LLM 在几百篇文章中精准定位 3-5 篇相关文章,无需加载整个 wiki。索引的质量决定了整个系统的上限。
第一层:索引地图
为什么索引比 RAG 更好?
| 对比维度 | RAG(向量检索) | 索引优先 |
|---|
| 检索方式 | 语义相似性匹配片段 | 像 human expert 一样查目录 |
| 理解结构 | 不理解知识库结构 | 理解概念之间的层级和关联 |
| 可解释性 | 黑盒,不知道为什么检索这些片段 | 透明,能看到 LLM 选了哪些文章及为什么 |
| 维护成本 | 需要嵌入计算基础设施 | 维护一个 Markdown 文件 |
| 适用规模 | 任意规模 | ~200 篇文章以内最佳,超过则需要搜索引擎辅助 |
本质区别:RAG 检索的是"看起来像"查询的文本片段。索引优先让 LLM 像 human expert 一样工作 —— 先查目录,再翻到相关章节。
index.md 的设计规范
索引文件是整个系统的心脏。它必须满足三个条件:紧凑、一致、可导航。
# 知识库索引
## 概念
- [[concepts/attention]] — 让模型动态权衡 token 相关性的机制
- [[concepts/transformer]] — 基于自注意力的序列建模架构
- [[concepts/rlhf]] — 用人类反馈强化学习对齐语言模型的方法
## 实体
- [[entities/vaswani]] — Ashish Vaswani,Google Brain 研究员
## 来源
- [[sources/attention-is-all-you-need]] — Vaswani 2017,原始 Transformer 论文
## 综合(LLM 生成)
- [[synthesis/scoring-mechanisms]] — RLHF 和注意力机制本质上解决同一个问题:如何为相关性/质量分配标量分数
关键约束:
- 每个条目一行 —— 一句话描述,不超过 80 字
- 总量可控 —— 索引本身必须能完整放入 LLM 上下文(~200 篇文章 ≈ ~200 行索引)
- 分类清晰 —— 按概念/实体/来源/综合分层组织
- 增量更新 —— 每次摄入新内容后 LLM 自动追加
渐进式索引加载
当 wiki 规模超过 200 篇文章,单一索引文件过长时,采用 渐进式索引加载:
index.md(全局索引,始终在上下文中)
├── concepts/index.md(概念子索引)
│ ├── concepts/ml/index.md(机器学习子索引)
│ └── concepts/web/index.md(Web 开发子索引)
├── entities/index.md(实体子索引)
└── sources/index.md(来源子索引)
查询流程:
用户提问 → LLM 读全局 index.md(始终在上下文中)
→ 定位到 1-2 个最相关的子索引
→ 读取子索引,选择 3-5 篇具体文章
→ 读取完整文章,综合回答
这样,无论 wiki 多大,LLM 每次只需要加载 索引 + 子索引 + 3-5 篇文章,远少于加载整个 wiki。
第二层:原始资料
摄入规范
所有原始资料存入 raw/,添加 frontmatter 元数据:
---
source: https://example.com/article
ingested_at: 2026-04-06T10:00:00Z
type: web | pdf | image | note
status: uncompiled
---
核心原则:摄入与编译分离。 先捕获,后处理。可以一次性摄入 20 篇再统一编译,也可以每篇即编译。
四种输入类型
| 类型 | 处理方式 |
|---|
| URL | WebFetch 抓取,提取正文,去除导航/广告 |
| PDF | LLM 文档理解,提取文本到附属 .md |
| 图片 | LLM 视觉理解,写描述性附属文件 |
| 笔记 | 直接写入自由格式文本 |
第三层:Wiki 编译
编译流程
每篇未编译的 raw 文件经过编译流程:
- LLM 阅读原始内容
- 写入结构化摘要(建议 ≤ 500 字,超出部分用 [[reference]] 链接延伸)到
wiki/sources/<slug>.md
- 提取关键概念,创建或更新
wiki/concepts/<concept>.md
- 概念去重:如果概念页已存在,读取并更新而非创建重复
- 建立双向
[[wikilinks]] 链接
- 更新
index.md 索引
- 追加条目到
log.md
每篇文章的设计规范
关键约束:建议每篇文章核心内容 ≤ 500 字。
为什么?因为 LLM 的上下文空间是有限的。500 字的文章意味着:
- 索引中的一行描述(~80 字)让 LLM 快速判断相关性
- 完整文章(~500 字)提供足够细节用于回答问题
- 3-5 篇文章 × 500 字 = 1500-2500 字的精确上下文,远优于 RAG 返回的碎片化片段
超出 500 字怎么办? 没关系。将核心要点控制在 500 字以内,详细展开的内容拆分到子概念文章,通过 [[reference]] 链接延伸即可。文章之间靠链接串联,而非把所有内容塞进一篇。
每篇文章包含:
---
tags: [tag1, tag2]
type: concept | source | entity | synthesis
updated_at: 2026-04-06
---
# 概念标题
一句话定义。
## 核心要点
- 要点 1
- 要点 2
- 要点 3
## 关联
- [[related-concept-1]] — 关联原因
- [[related-concept-2]] — 关联原因
## 来源
- [[sources/source-1]]
自我改进:反思引擎
编译后自动运行两阶段反思:
阶段 1 —— 发现(仅读索引):从索引的一行摘要中识别:
- 跨领域主题(一个概念出现在多个不相关来源中)
- 隐含关系(两个概念看似相关但无链接)
- 矛盾(来源持对立立场)
- 空白(多来源暗示但无专门文章的主题)
阶段 2 —— 综合(定向深度阅读):对每个候选,读相关文章,证据充分则生成新的 synthesis 类型文章。
综合文章是 二阶知识 —— 从知识中生成的知识。它们捕获没有任何单一来源会表述的关联。
第四层:输出与归档
所有输出归档回 wiki,实现知识复利:
| 输出类型 | 格式 | 归档位置 |
|---|
| 问答回答 | Markdown | outputs/YYYY-MM-DD-topic.md → 索引 |
| 健康报告 | Markdown | outputs/lint-YYYY-MM-DD.md |
| 幻灯片 | Marp | outputs/slides-topic.md |
| 图表 | matplotlib PNG | outputs/chart-topic.png + .md |
核心原则:好的输出归档回 wiki。 每个答案、每次分析都让知识库为未来查询变得更丰富。
评估器:检查知识库是否 LLM 友好
为什么需要评估器?
大多数人的 Obsidian vault 是给人看的,不是给 LLM 看的。文章长短不一、结构混乱、缺少链接、信息密度低。评估器检查当前知识库是否适合 LLM 理解和高效检索。
评估维度
| 维度 | 检查项 | 通过标准 |
|---|
| 文章粒度 | 文章长度分布 | 80% 文章核心内容在 200-500 字之间 |
| 索引完整性 | index.md 覆盖率 | 每篇 wiki 文章在索引中有对应条目 |
| 链接密度 | 每篇文章的 wikilink 数量 | 平均 ≥ 3 个双向链接 |
| 结构一致性 | frontmatter 规范性 | 所有文章含 tags/type/updated_at |
| 概念去重 | 近重复文章检测 | 无语义重复的概念页 |
| 孤立检测 | 无入链文章比例 | 孤立文章 < 10% |
| 摘要质量 | 索引条目信息量 | 每条索引包含足够的判断信息 |
| 时效性 | 文章更新时间 | 无明显过时内容(可配置阈值) |
评估流程
/kb-evaluate
→ 扫描 wiki/ 所有 .md 文件
→ 统计文章长度分布、链接密度、frontmatter 完整性
→ 检查 index.md 覆盖率
→ 检测孤立文章和断裂链接
→ 生成评估报告:score.md
→ 给出优先修复建议
评估报告示例
# 知识库健康报告
## 总览
- 文章总数:87
- 平均长度:420 字 ✅
- 索引覆盖率:92% ⚠️(7 篇文章未在索引中)
- 平均链接数:2.8 ⚠️(建议 ≥ 3)
## 问题清单(按优先级)
1. 🔴 3 篇文章 > 2000 字 → 需拆分
2. 🟡 7 篇文章缺少索引条目 → 需补充
3. 🟡 12 篇文章链接数 < 2 → 需补充链接
4. 🟢 4 篇孤立文章 → 可选补充入链
从人写到人机协作:过渡策略
大多数人的 Obsidian vault 最初是纯人写的。需要一个从"人写人读"到"人机协作"的过渡路径。
阶段 1:评估现状
运行评估器,了解当前 vault 的 LLM 友好度。识别需要重构的文章(过长、缺少结构、缺少链接)。
阶段 2:建立索引
为现有文章创建 index.md。这一步让 LLM 能够导航已有内容。LLM 扫描所有文章,提取摘要,建立分类索引。
阶段 3:增量重构
不是一次性重写所有文章,而是 渐进式重构:
- 新摄入的内容按规范编译(建议 ≤ 500 字、结构化、链接丰富,超出用 [[reference]] 延伸)
- 旧文章在 LLM 查询时顺便优化(遇到长文章时拆分、遇到缺少链接时补充)
- 每次交互都可能触发对相关文章的小幅改进
阶段 4:LLM 自主迭代
当知识库达到一定规范度后,LLM 可以自主运行:
/kb-lint:健康检查,发现并修复问题
/kb-reflect:发现隐含关联,生成综合文章
/kb-merge:合并重复概念
- 输出归档回 wiki,持续积累
六种核心操作
1. 评估(Evaluate)
/kb-evaluate
检查知识库是否 LLM 友好,生成健康报告和修复建议。
2. 摄入(Ingest)
/kb-ingest https://example.com/article
/kb-ingest ~/papers/attention.pdf
/kb-ingest "我的笔记:RLHF 和 CoT 之间可能有深层联系"
将任何来源暂存到 raw/,不触发处理。
3. 编译(Compile)
/kb-compile
处理所有未编译内容,生成/更新 wiki 文章和索引,自动触发反思引擎。
4. 查询(Ask)
/kb-ask RLHF 和 chain-of-thought 有什么关系?
索引优先的问答:读索引 → 选文章 → 读全文 → 综合回答 → 归档回 wiki。
5. 检查(Lint)
/kb-lint
健康检查:矛盾、孤立页面、缺失概念、断裂链接、重复文章。
6. 合并(Merge)
/kb-merge concepts/attention concepts/attention-mechanism
合并重复概念,保持概念空间紧凑。
维护循环
摄入 → 编译 → 查询 → 归档
↑ ↓
反思 ← 检查 ← 合并
每个环节都在让知识库变得更好。知识复利的关键不在于摄入更多内容,而在于 让已有知识之间建立更多关联。
推荐目录结构
obsidian-vault/
├── raw/ # 原始资料(不可变)
│ ├── web/ # 网页裁剪
│ ├── pdf/ # PDF 文档
│ ├── images/ # 图片(本地化)
│ └── notes/ # 个人笔记
├── wiki/ # LLM 编译维护
│ ├── index.md # 全局索引(核心)
│ ├── log.md # 变更日志
│ ├── concepts/ # 概念文章(建议 ≤ 500 字)
│ │ └── index.md # 概念子索引
│ ├── entities/ # 实体页面
│ ├── sources/ # 来源摘要
│ ├── synthesis/ # 综合文章(LLM 生成)
│ └── archive/ # 归档(合并后的旧文章)
├── outputs/ # 输出文件
│ ├── YYYY-MM-DD-*.md # 问答回答
│ └── lint-YYYY-MM-DD.md # 健康报告
└── CLAUDE.md # Schema(告诉 LLM 如何管理此知识库)
工具生态
| 工具 | 用途 |
|---|
| Obsidian | 知识库的 IDE —— 图谱视图可视化知识网络、实时浏览更新 |
| Obsidian Web Clipper | 浏览器扩展,快速将网页文章转为 Markdown |
| Dataview | Obsidian 插件,对 frontmatter 运行查询生成动态表格 |
| Marp | Markdown 幻灯片,直接从 wiki 内容生成演示文稿 |
| qmd | 本地 Markdown 搜索引擎(大型 wiki 时使用) |
参考资料