llm-wiki

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 和注意力机制本质上解决同一个问题：如何为相关性/质量分配标量分数

关键约束：

1. 每个条目一行 —— 一句话描述，不超过 80 字
2. 总量可控 —— 索引本身必须能完整放入 LLM 上下文（~200 篇文章 ≈ ~200 行索引）
3. 分类清晰 —— 按概念/实体/来源/综合分层组织
4. 增量更新 —— 每次摄入新内容后 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 文件经过编译流程：

1. LLM 阅读原始内容
2. 写入结构化摘要（建议 ≤ 500 字，超出部分用 [[reference]] 链接延伸）到 wiki/sources/<slug>.md
3. 提取关键概念，创建或更新 wiki/concepts/<concept>.md
4. 概念去重：如果概念页已存在，读取并更新而非创建重复
5. 建立双向 [[wikilinks]] 链接
6. 更新 index.md 索引
7. 追加条目到 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 时使用）

参考资料

• Karpathy 原文 Gist：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• 方法论完整原文（中文翻译）：references/llm-wiki-pattern.md
• Karpathy 推文实践总结（中文翻译）：references/karpathy-tweet-translation.md
• 实战案例：构建自我改进型个人知识库（中文翻译）：references/self-improving-kb.md
• 开源实现：louiswang524/llm-knowledge-base（9 个 Claude Code skills）
• 灵感来源：Vannevar Bush 的 Memex（1945）—— 个人策划的知识存储，文档间的关联轨迹