Карапати раскрывает: полный метод создания личной базы знаний с помощью LLM

OpenAI 創辦團隊成員、Tesla 前 AI 總監 Andrej Karpathy 在 X 上發布「LLM Knowledge Bases」工作流程、解釋他近期把大量 token 用量從「操控程式碼」轉向「操控知識」—用 LLM 把分散的論文、文章、資料夾、影像、整理成一個自動維護的個人 wiki。整套流程已在他自己的研究專案上累積 ~100 篇文章、~400k字、且全程由 LLM 寫入與更新。本文整理 Karpathy 的完整 setup、給想自己複製的開發者一張可實作清單。

核心理念：raw 資料 → LLM 编译 → wiki → Q&A

Karpathy 的設計哲學可以濃縮成一句話：「raw data 进来、LLM 编译成 wiki、wiki 再供 LLM 查询、查询结果继续写回 wiki」。整個系统的关键是把人类的角色从「写笔记」轉成「监看 LLM 写出的笔记」、knowledge base 不再是手动维护的 Notion 或 Roam Research、而是 LLM 自动写入并维护的 markdown 文件集合。

他描述自己很少直接编辑 wiki—写入、补链接、抽取结构、检查一致性、全是 LLM 做。这個「LLM 主导内容、人类监看」的模式、与多数人手动写 Obsidian／Notion 的习惯完全不同、是這個工作流程的核心转变。

Step 1：Data Ingest—把所有 raw 資料丢进一个 raw/ 資料夹

Karpathy 的入口很简单：建一个 raw/ 资料夹、把所有来源资料倒进去—论文 PDF、新闻文章、code repo、数据集、影像、讲稿。LLM 会以这个资料夹为输入、逐步「编译」出 wiki。

他特别提到两个工具：

Obsidian Web Clipper 扩充套件—把网页文章直接转成 .md 文件放进 raw/

自訂 hotkey—把网页的相关图像下载到本地、让 LLM 在后续引用时能直接读

关键设计：所有外部资料以「离线、本地」形式存在、确保 LLM 后续查询时不会卡在「找不到原始链接」的问题。

Step 2：LLM 编译 wiki—自动产生分类、文章、反向链接

raw/ 资料就绪后、Karpathy 用 LLM 增量地（incrementally）「编译」一个 wiki—就是一堆 .md 文件组成的目录结构。LLM 会做四件事：

对 raw/ 中所有资料写摘要

把资料分类成概念（concepts）

为每个概念写一篇文章

在文章之间建立反向链接（backlinks）

这个过程是「增量」的—新加入 raw/ 的资料、LLM 只更新受影响的 wiki 区块、不必整個重编。对长期累积的研究主题（Karpathy 自己的研究 wiki 已经有 ~100 篇、400k字规模）、这种增量更新比一次性大编译实用得多。

Step 3：用 Obsidian 作为 IDE「前端」、Marp 等插件扩充

Karpathy 用 Obsidian 作为这套系统的可视化前端—可以同时看 raw/ 资料、编译出的 wiki、与衍生的可视化（slides、图表）。Obsidian 的好处是它本身就是 markdown 编辑器、与 LLM 写出的 .md 文件天然相容、且支援 plugin 扩充。

他特别提到 Marp 这个 plugin—可以把 markdown 直接渲染成投影片格式、让 LLM 不只能输出文字、还能输出简报。

Step 4：Q&A—把整个 wiki 当 LLM 的查询对象

Karpathy 的 wiki 进入「~100 篇文章、~400k字」规模后、最有趣的能力浮现：可以对 LLM agent 提任意复杂的问题、它会自己跑去研究答案、引用 wiki 中的相关段落。

原本他预计需要用「fancy RAG」（向量检索、嵌入模型、re-ranking 等）才能跑这个规模、但实测发现：LLM 自己会维护 index 文件与每篇文章的简短摘要、查询时靠这些 index 与摘要就能找到相关段落、在「~400k字」这个尺度下、不必复杂的 RAG 也能跑得不错。

这个观察与 2024 年以来「向量 DB 过热、实际很多场景不必用」的产业共识一致—当你的 knowledge base 在百万字以下、structured markdown + LLM 自管 index 已足够。

Step 5：输出—不是纯文字、而是 markdown／slides／图表

Karpathy 的另一个设计：他不要 LLM 只回 terminal 文字、而是让 LLM 产出有结构的输出—markdown 文件、Marp 简报、matplotlib 图、可视化数据。这些输出在 Obsidian 内查看。

更关键的是循环：产出的结果常常被 Karpathy 「归档」回 wiki、强化未来的查询。他形容「自己的探索与查询永远都在累加（add up）到 knowledge base」—这是 stateful、会长大的、与 ChatGPT 对话「每次都从零开始」的模式相反。

Step 6：Linting—LLM 自我健检、找一致性问题与新文章候选

Karpathy 对 wiki 跑 LLM「健康检查」、处理三类问题：

找出资料不一致（同一概念在不同篇章的描述冲突）

用网络搜寻补上缺失资料

找出有趣的跨概念链接、推荐新的文章候选

这个 linting pass 是让 wiki 随时间「越来越干净」的关键—没有它、自动编译出来的 wiki 会逐渐累积矛盾与噪声。LLM 在这个任务上表现不错、是 Karpathy 认为这套工作流程可长期运行的原因之一。

Step 7：自制额外工具—例如自建 wiki 搜索引擎

Karpathy 提到他「vibe coded」一个小型搜索引擎、跑在自己的 wiki 上。这个工具有两个用法：（1）他自己直接用 web UI 查；（2）更常见的是把这个搜索引擎通过 CLI 介面、丢给 LLM 当作工具、让 LLM 在大型查询时能精准命中相关段落。

这个模式（人类搭一个 CLI、LLM 把它当工具用）、是 Claude Code、OpenAI Codex 这类 agent 框架下的核心设计—LLM 不直接读全部资料、而是透过工具（CLI、search engine、file system）取得需要的子集。

Step 8：未来方向—合成数据生成、模型微调

当 wiki 规模够大、Karpathy 提出两个进阶方向：

用 wiki 生成合成数据（synthetic data）—让 LLM 为某些主题自动产出 Q&A 配对、教学文、范例

用合成数据微调一个专属 LLM—让你的个人 LLM「在权重中知道」这些资料、而不只是要在 context window 中读

这个方向把 knowledge base 从「外部记忆」推进到「内化记忆」、是个性化 AI 的下一步。但 Karpathy 自己也承认这需要更多基础建设、目前还是探索阶段。

Karpathy 的「Idea File」想法：分享构想、不分享 code

该则贴文爆红后、Karpathy 在后续贴文提出新概念「idea file」—在 LLM agent 时代、与其分享具体 code、不如分享「想法」、让对方的 agent 为他定制化、为他打造。

他把这套 LLM Knowledge Bases 的「idea file」放在一个 GitHub gist、刻意保持抽象、留空白给每个人的 agent 自由发挥。这可能是未来 dev community 的新分享模式—不是 GitHub repo、不是 npm 套件、而是「指令文件」、给 LLM 看的开放规格。

實作建议：台湾读者怎么开始

对想复制这套系统的台湾开发者、实务上的入门路径：

Obsidian 是免费软件、macOS／Windows／Linux 皆可、可从官网下载

Web Clipper 扩充套件可在 Chrome／Firefox／Edge 安装

LLM 端可选 Claude Code（CLI）、ChatGPT（API）、或本地 Ollama（如果你有强显卡）

raw/ 与 wiki/ 两个资料夹建议放 Obsidian vault 同层、且加入 .gitignore 之外的版本控制（万一 LLM 写坏可以救回）

从一个你最熟悉的研究主题开始—例如「2026 加密交易所合规动态」「LLM 推论架构」、累积到 30–50 篇后 Q&A 能力会明显改善

Karpathy 在贴文最后说：「这里有打造一款厉害新产品的空间、不是现在这种粗糙脚本拼凑的形式。」对 builder 来说、这条 thread 既是工作流程说明、也是创业题材—LLM 自动 wiki、是个还没有明确产品赢家的市场。

这篇文章 Karpathy 亲揭：用 LLM 打造个人知识库的完整方法 最早出现在 鏈新聞 ABMedia。