LLM Wiki实战：照着Karpathy的gist，3步搭一个替代RAG的知识库

关注

原创最新推荐文章于 2026-10-02 17:37:47 发布 317 阅读 AI 写同款· GEO 优化 ›

OpenViking上下文数据库Golang集成实践技术创新文件系统范式：将AI Agent的上下文管理从扁平向量存储提升为结构化文件系统分层检索策略：L0/L1/L2三层加载机制，减少62.1%的Token消耗记忆自迭代：会话提交触发Agent经验沉淀，实现越用越智能工程实践完整Golang实现：提供生产级可用的OpenViking客户端库企业级集成方案：涵盖文档摄入、检索、会话管理等全流程性能优化成果：检索准确率提升24.1%，响应时间减少53.3%可观测性提升可视化检索轨迹：实现检索过程的白盒化，调试效率提升77.1%全面监控指标。阅读详情

这周我把Karpathy 4月份的 gist 原文完整读完，又照着搭了一遍：3 个文件、3 篇素材、10 分钟，真的跑出了一个能回答问题、还会自己写笔记的小知识库。
这篇不谈概念，只讲我怎么动手搭的——目录长什么样、CLAUDE.md 怎么写、Ingest 和 Query 各自发生了什么，包括我踩到的坑。

**Karpathy 的原话很克制：这套东西在"约 100 个来源、数百页"的中等规模下，能替代 embedding-based RAG——不是"永远不需要"，是"现在不需要"。**我用本号自己两篇 RAG 文章的素材做了实测，验证了这句话，也验证了它的边界在哪。

一、先说清楚：我搭的不是玩具，是本号素材的复用实验

我拿了三份真实素材当"原始资料"：Karpathy 的 gist 摘要、0705《RAG 多路召回》的核心数据、0715《语料质量决定上限》的核心数据【S9】。目的很直接——验证 Karpathy 说的"index.md 能替代 embedding 检索"，用我自己的内容库试一遍是不是真的。

整个过程只用了 3 类文件、跑了 1 次 Ingest + 1 次 Query，全程没装向量数据库，没写一行 embedding 代码。

二、LLM Wiki 骨架：3 层目录，10 分钟能搭完

Karpathy 的 gist【S1】把整套系统定义成 3 层，我照着建了这个目录：

llm-wiki-demo/├── raw/                          # 第一层：原始素材，只读│   ├── karpathy-idea.md│   ├── rag-corpus-quality.md│   └── rag-multi-retrieval.md├── wiki/                         # 第二层：LLM 生成的知识库│   ├── index.md                  #   总索引│   ├── entities/│   │   └── karpathy-llm-wiki-idea.md│   ├── concepts/│   │   ├── rag-corpus-quality.md│   │   └── multi-retrieval-strategy.md│   └── comparisons/│       └── rag-vs-llm-wiki.md├── log.md                        # 操作日志，纯追加└── CLAUDE.md                     # 第三层：schema 契约

三层各司其职：raw/我只放不改，wiki/完全交给 LLM 读写，CLAUDE.md是我和 LLM 之间的"施工合同"——规定它必须怎么归档、怎么建索引、怎么写日志。

💡 这部分建议收藏，下次自己搭 LLM Wiki 时，直接照这个目录结构建文件夹，比自己想目录省一半时间。

三、Schema：CLAUDE.md 里到底该写什么

这是整套系统里我改得最久的文件，因为 Karpathy 明确说过：Wiki 质量的上限，就是 Schema 质量的上限。我最终定稿的版本长这样（精简版，完整字段更多）：

# LLM Wiki 项目说明（schema）## 目录约定- raw/：不可变原始来源，只读，不允许修改或删除。- wiki/index.md：全站目录，列出所有页面 + 一行摘要 + 分类。每次 ingest 后必须更新。- wiki/entities/：人物/项目/工具类页面。- wiki/concepts/：概念/机制类页面。- wiki/comparisons/：对比/综合分析页面。- log.md：按时间顺序追加记录。## Ingest 工作流1. 读 raw/ 里的新文件。2. 判断它属于哪类页面，已有页面就更新，没有就新建。3. 更新 wiki/index.md 对应条目。4. 在 log.md 追加一条 ingest 记录。## Query 工作流1. 先读 wiki/index.md，定位可能相关的 2-4 个页面。2. 只深入读这些页面，不读全部 wiki，不读 raw/。3. 给出带 [[wiki-link]] 引用的综合回答。4. 如果这次回答本身有复用价值，追加为 wiki/comparisons/ 下的新页面。## Lint 工作流- 定期检查：页面间矛盾、孤儿页、被提及但没有独立页面的概念。

这几行看起来朴素，但每一句都在堵一个坑：

• "只读取不修改"堵住了 LLM 顺手改事实来源的风险；
• "每次 ingest 后必须更新 index.md"堵住了孤儿页问题；
• “只深入读定位到的 2-4 个页面，不读全部 wiki”，这一句就是 Karpathy 说"避免 embedding-based RAG"的具体实现——LLM 不是暴力扫描全部文档，而是先读一份几千 token 的目录再精准下钻。

四、Ingest 实测：3 篇素材进去，发生了什么

我把 3 份素材依次"喂"进去，观察每一次 Ingest 实际改了哪些文件。

第一次：Karpathy 的理念本身

生成的实体页 wiki/entities/karpathy-llm-wiki-idea.md：

---type: entitytags: [karpathy, llm-wiki, context-engineering]source_count: 1last_ingested: 2026-07-22---# Karpathy 的 LLM Wiki 理念来源：raw/karpathy-idea.md## 三层架构- raw/：不可变原始来源，人类维护，LLM 只读。- wiki/：LLM 生成并拥有的 Markdown 页面。- schema（CLAUDE.md/AGENTS.md）：规定页面规范与工作流。## 关键主张在中等规模（~100 来源、数百页），维护良好的 index.md足以替代 embedding-based RAG。相关页面：[[rag-vs-llm-wiki]]

注意最后一行"相关页面：[[rag-vs-llm-wiki]]"——这个链接在第一次 Ingest 时并不存在，是我后面做 Query 之后，回头补写的。这就是 Karpathy 说的"一次摄取可能波及十几个页面"在小规模下的缩影：新知识进来会反过来修改旧页面的引用关系。

第二、三次：两份 RAG 数据素材

分别生成了 wiki/concepts/rag-corpus-quality.md和 wiki/concepts/multi-retrieval-strategy.md，每篇都带了 相关页面交叉引用，指向彼此。

三次 Ingest 之后，log.md里留下的是这样的纯追加记录：

## [2026-07-22 10:00] ingest | karpathy-idea.md新增页面：wiki/entities/karpathy-llm-wiki-idea.md。更新 index.md。## [2026-07-22 10:02] ingest | rag-corpus-quality.md新增页面：wiki/concepts/rag-corpus-quality.md。更新 index.md。## [2026-07-22 10:03] ingest | rag-multi-retrieval.md新增页面：wiki/concepts/multi-retrieval-strategy.md。更新 index.md。

而 wiki/index.md变成了一份几十行、几百 token 的总目录：

# Index## Entities- [[karpathy-llm-wiki-idea]] — Karpathy 2026-04 提出的 LLM Wiki 三层架构与三操作## Concepts- [[rag-corpus-quality]] — 语料质量决定 RAG 上限，检索优化收益是它的 1/2.5- [[multi-retrieval-strategy]] — Hybrid RRF + Rerank 多路召回效果对比

这份 index.md就是接下来 Query 阶段的全部导航依据——它没有向量，没有相似度分数，就是一份人也能一眼看懂的目录。

五、LLM Wiki Query 实测：不查 raw/，只读 index，答案对不对？

接下来是我最关心的验证：Karpathy 说"LLM 先读 index 定位相关页，再下钻",这样答出来的东西靠不靠谱？

我问的问题是：“语料质量和检索策略哪个优先级更高？为什么 LLM Wiki 敢说不需要 embedding？”

执行路径完全按 CLAUDE.md 里写的规矩走：读 index.md→ 命中 rag-corpus-quality和 multi-retrieval-strategy两个概念页 → 全程没有打开 raw/ 原始文件。综合出来的回答被存成了新页面 wiki/comparisons/rag-vs-llm-wiki.md：

## 综合回答两条证据同源但结论一致：语料质量的收益（+27pp）是检索架构优化收益（+10.8pp 或 +22.9pp）的 1.2~2.5 倍，且检索优化的天花板被语料覆盖度锁死——[[multi-retrieval-strategy]] 里Hybrid+Rerank 的 0.816 仍然是在"语料本身包含答案"的前提下测出来的。这恰好解释了 [[karpathy-llm-wiki-idea]] 敢说"中等规模不需要embedding-based RAG"的底气：LLM Wiki 把工程精力从"怎么更好地检索"转移到"怎么把语料先结构化、去重、写清楚"。但这也是它的边界：一旦来源数超过约 100～数百页，index.md 本身也会变成需要检索的对象。

这个回答是对的，而且是可审计的对的——每一句结论都能顺着 [[wiki-link]]点回具体页面，页面再顺着"来源：raw/xxx.md"点回原始素材。这正是 Karpathy 反复强调的透明性：向量数据库告诉你"这句话相似度 0.87"，Markdown 维基告诉你"这句话来自哪一行"。

而更关键的一点是这次查询本身也变成了知识——rag-vs-llm-wiki.md一旦存下来，下次再有人问类似问题，LLM 甚至不用重新推理一遍，直接读这张页面就有答案。这就是 Karpathy 说的"compounding artifact（复利产物）"，我在这个 10 分钟的小实验里，真的看到它发生了一次。

💡 这部分建议收藏，下次判断"要不要在自己项目里加 RAG"之前，照着这个 Query 流程走一遍，先看你的 index.md 能不能直接给出靠谱答案。

六、我踩到的坑：不是所有事都像宣传的那么美

搭完之后我去翻了社区的实测反馈【S5】和一篇专门讲落地陷阱的文章【S6】，发现我遇到的问题不是个例：

坑 1：模型坍缩（Model Collapse）。维基是 LLM 生成的，又被 LLM 反复读取去生成新内容——一代代传下去，容易悄悄丢失原始信息的多样性，越往后越"千篇一律"。我这次实验规模太小没暴露，但腾讯云的落地指南【S6】把它列为原生缺陷，给的解法是：raw/必须不可变，Lint 阶段要定期回源校验，不能光信 wiki 页面自己写的东西。

坑 2：“氛围式思考”（vibe thinking）。LLM 在维护维基时会顺手生成看起来合理但没有依据的内容——这也是为什么 CLAUDE.md 里那句"来源：raw/xxx.md"不是装饰，是防线。

坑 3：Schema 冷启动成本被低估。掘金一篇 8 万收藏帖的评论区【S5】里，有条经验总结得很实在：前 5-10 篇素材要花时间深度调校 schema，不是写完 CLAUDE.md 就一劳永逸——我这次的 CLAUDE.md 也是改了两三版才稳定下来。

坑 4：规模上限没人真正验证过。Karpathy 自己公开的例子也就 100 篇左右、40 万字规模。超出这个量级，index.md本身也会变得太长、需要检索，这时候就该切换到 qmd 这类本地搜索工具（Tobi Lutke 写的一个全离线三层混合搜索引擎：BM25 精确匹配 + 向量语义 + LLM 重排，实测能把重复检索的 token 消耗砍掉 90% 以上）【S4】——这不是否定 LLM Wiki，是承认它有边界。

七、这套东西跟"上下文工程"是什么关系

搭完之后我又去看了 Anthropic 的一篇工程博客【S7】，才想明白 LLM Wiki 在更大图景里的位置：Anthropic 把"给 Agent 喂什么上下文"归纳成写（Write）/ 选（Select）/ 压缩（Compress）/ 隔离（Isolate）四个动作。

RAG 是"选"的一种实现，LLM Wiki 是"写 + 选"的组合——摄取时先把知识"写"成结构化页面，查询时再从索引里"选"出相关的几页。两者都是"上下文工程"这个大伞下的具体技术，不是互相打对台的两个流派。

这也解释了为什么网易有道能在 4 月底把同一套理念做成零代码工具【S3】——只要"写"和"选"这两步能自动化，普通用户不用懂 embedding 也能用上复利效应。

总结

三条核心判断：

**Karpathy 说的"替代 RAG"有明确适用边界，不是万能替代。**中等规模（约 100 来源、数百页）、高信号密度的个人/小团队知识库，index.md导航确实能跳过 embedding 基础设施；企业级海量、强权限、强时效的场景，RAG 依然是刚需。

**它真正的价值不是"省掉向量数据库"，是"知识会自己长大"。**我这次实测里，一次 Query 就自动沉淀成了一个新的 wiki 页面——这是传统笔记和 RAG 都做不到的复利循环。

**Schema 质量决定一切，而 Schema 是需要反复打磨的活。**CLAUDE.md 不是写一次就完事的配置文件，是随着你踩坑不断修订的"施工合同"。

对你的实际建议

• 独立开发者/研究者：先别追求大而全，挑 3-5 篇你最近在啃的资料，照着本文的目录结构建一遍，一晚上能看到效果。
• 正在跑 RAG 项目的工程师：不用推翻现有系统，先拿一小块高价值、低更新频率的知识（比如竞品分析、内部技术选型文档）单独用 LLM Wiki 试点，验证复利效应是否成立。
• 团队 Leader：重点关注 Schema 的治理问题——谁来定义页面规范、谁来做 Lint 检查，这比技术实现本身更容易出岔子。

系统负责记账，思考仍然是你的事——这句话我搭完这一遍之后,才真正体会到分量。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～