LLM Wiki

269 字

LLM Wiki

类型: 知识管理方法论
提出者: Andrej Karpathy(OpenAI联合创始人 / Anthropic)
首次公开: 2026-04,GitHub Gist
核心工具: Obsidian + AI Agent(Hermes / Claude Code / OpenClaw 等)

定义

LLM Wiki 是一种由 AI Agent 全自动构建、维护和更新的结构化知识库模式。其核心理念是将 LLM 当作"知识编译器":昂贵的工作(阅读、综合、交叉引用)在查询前一次性完成,查询时面对的是预编译好的知识,而非原始碎片。

"The insight is that the LLM should compile a wiki incrementally, rather than be asked to retrieve at query time." — Karpathy

三层架构

vault/
├── raw/              ← 原始资料层(只读,不可修改)
│   ├── articles/
│   ├── papers/
│   └── notes/
├── wiki/             ← Wiki层(LLM 全权管理)
│   ├── entities/     实体页(人物、项目、产品)
│   ├── concepts/     概念页(技术、方法论)
│   ├── sources/      来源页(每条资料的摘要)
│   └── index.md      全局索引
└── CLAUDE.md         ← Schema/指令层(规则与约定)

三大操作

操作 说明 效果
Ingest 录入新资料 → LLM 提取实体/概念 → 创建/更新页面 → 建交叉引用 → 更新 index 和 log 一篇资料可联动 10-15 个 Wiki 页面
Query 提问 → LLM 检索 Wiki 页面 → 综合回答(带引用)→ 高质量答案可归档 知识复利:越问越厚
Lint 健康检查:矛盾检测、过时信息、孤儿页面、缺失引用 知识库持续健康

与 RAG 的核心区别

维度 传统 RAG LLM Wiki
工作原理 每次查询临时检索原文 读已整理的笔记
知识积累 ❌ 无积累,每次从零 ✅ 越用越密
交叉引用 运行时发现 已预建立
可见性 向量库黑盒 全量 Markdown 可审查
部署 向量库 + GPU 本地文件夹
错误修复 调 embedding/检索策略 直接编辑文件
规模天花板 理论无限 ~100 来源 / ~数百页后需增强

工程化演进路径

  1. LLM Wiki(极简):Karpathy 原始方案,一个 llm-wiki.md 文件 + Agent
  2. Obsidian-Wiki(增强):Delta 追踪(SHA-256)、来源可信度边界、溯源标记(extracted/inferred/ambiguous)、hot.md 热缓存、20+ 标准化 Skill
  3. GBrain(规模化):混合检索(向量粗筛+文件精读)、图谱关系(typed edges)、"潜在空间 vs 确定性"分层设计
  4. 云端方案(降门槛):有道云笔记 youdaonote-llm-wiki Skill、飞书妙搭 LLM Wiki

为什么有效

人类放弃 wiki 是因为维护负担增长得比价值更快。LLM 不觉得无聊,不忘记更新引用,一次处理 15 个文件。维护成本接近零。

  • 人负责:策划来源、引导分析、提出好问题、思考意义
  • LLM 负责:总结、交叉引用、归档、记账、一致性维护

关键文件

文件 作用
SCHEMA.md / CLAUDE.md 约束 Agent 行为:目录结构、命名规范、wikilink 规则、log 要求
index.md 内容导向:Wiki 所有页面的目录,Agent 查询时先读索引定位
log.md 时间导向:追加记录,给 Wiki 演化时间线

适用场景

  • 个人深度研究(长期跟踪、渐进式构建)
  • 结构化读书笔记(概念/人物/观点拆解关联)
  • 项目知识管理(ADR、架构演变、经验文档)
  • AI Agent 记忆固化(从交互历史提取隐性知识)
  • 小团队内部 Wiki

局限性

  1. 规模天花板:index.md 驱动检索在数百到低千页面后性能下降
  2. 无自动化调度:需手动触发或外部脚本
  3. 弱结构化图谱:wikilink 缺乏 typed edges,无法表达复杂语义关系
  4. 非实时关联:cross-linker 等维护 Skill 需手动触发

相关概念

相关实体

来源