W
AI-Wiki
SOURCE

Rohit 基于 Karparthy 的 gist 更新LLM Wiki V2 - 今日头条 摘要

文档概览

这篇文章把 LLM Wiki 的演进分成两个阶段：

  • 原版关注的是“让知识开始复利”
  • V2 关注的是“当知识库做大之后，如何不烂掉”

作者认为，Karpathy 的原版其实相当克制：它反对只做临时 RAG，即每次回答问题都回到原始材料里捞 chunk、临时拼答案，因为这样不会累积结构化理解。相对地，原版主张先把 raw sources 编译成 wiki，再让 Agent 基于 wiki 回答问题。

在这个框架下，Rohit 的 V2 并不是推翻原版，而是把原版在生产环境中迟早会遇到的问题显性化，包括：

  • memory lifecycle
  • confidence
  • supersession
  • forgetting
  • typed knowledge graph
  • hybrid search
  • event-driven ingestion / updates
  • quality governance
  • multi-agent coordination

文章整体态度是：方向正确，但不能把 V2 当现成蓝图照抄；它更像问题清单、路线图和工程评审输入。

原版 LLM Wiki 的核心思想

反对只做临时 RAG

原版最核心的观点是：不要把知识系统只做成“问一次、捞一次、拼一次”的临时检索回答系统。 如果每次提问时，模型都只是重新从 raw documents 中检索片段，再即时生成答案，那么系统不会真正积累对材料的整理、抽象与链接。

原版提出的替代方案是：

  1. 先把文章、论文、会议记录、代码讨论等原始材料放入 raw sources
  2. 让 LLM 读取这些原始材料
  3. 再由 LLM 更新 wiki 中的 summary、entity page、concept page、overview、index、log 等页面
  4. 后续 Agent 回答问题时，优先读取 wiki，而不是每次都回到未经整理的原始材料

作者用一句话概括这种差异：

  • RAG 是“每次重算”
  • LLM Wiki 是“持续累积”

原版的三层结构

原版被概括为一个很清晰的三层结构：

  • Raw sources：原始材料，且不被 LLM 修改
  • Wiki：由 LLM 维护的 Markdown 页面
  • Schema：如 CLAUDE.md、AGENTS.md 一类规则文件，用来规定写作和维护规范

这三层分别解决不同问题：

  • Raw sources 负责保留原始证据与不可变输入
  • Wiki 负责形成可读、可维护、可交叉引用的知识表示
  • Schema 负责让不同 Agent 在同一套规则下写作、更新、校验

原版的最小可运行组件

作者特别点出，Karpathy 版本适合启动个人研究库、读书库或项目知识库，因为它只要求少量核心部件先跑起来。文中列出的最小可运行组件包括：

  • raw
  • wiki
  • schema
  • index
  • log
  • ingest
  • query
  • lint

作者的判断是：原版的重点不是一开始就建复杂系统，而是先构造一个可以运行、可以持续更新、可以被人审查的最小闭环。

原版的类比：Obsidian 是 IDE，LLM 是 programmer，wiki 是 codebase

文章非常强调这个类比，因为它解释了原版的人机分工：

  • Obsidian 是 IDE
  • LLM 是 programmer
  • wiki 是 codebase

在这个类比下：

  • 人负责选题、判断、取舍和最终审阅
  • LLM 负责维护性工作，如整理、交叉引用、补 index、查孤儿页、同步页面结构

作者认为，这个类比比“知识库自动生成器”更准确，因为原版真正想解决的是维护成本，而不是一次性生成文档。

V2 相比原版新增的生产层议题

1. Memory lifecycle：知识不应一律同权

V2 的一个现实出发点是：wiki 启动不难，难的是变大之后仍然保持“清醒”。

原版里，wiki 页面默认大致同等可信；V2 则明确认为这不够。文章给出的关键例子是：

  • 一个昨天刚从三份材料确认过的事实
  • 与一条半年前随手记下、未经重新验证的猜测

这两类内容不应在检索与回答中拥有相同权重。

因此 V2 引入了 memory lifecycle，把知识区分为多种记忆形态：

  • working memory
  • episodic memory
  • semantic memory
  • procedural memory

作者对这个设计的解释是：越往后越压缩，证据越强，生命周期越长。也就是说，系统不只是存内容，还要表达内容所处的成熟度、时效性与稳定性。

2. Confidence、supersession、forgetting

V2 还提出了三个彼此关联的话题：

  • confidence
  • supersession
  • forgetting

作者对其中的 confidence 提出明确批评：如果它只是一个单独数值，比如 0.85，那么很容易制造“没来由的权威感”。文章主张，可信度不应只表现为一个数字，而应尽量落实为可追溯的证据结构，包括：

  • 这个 claim 来自哪个 ADR
  • 来自哪次 commit
  • 来自哪篇 source
  • 来自哪次 session
  • 最近一次是什么时候确认过
  • 是否已被新信息替代

也就是说，作者更赞成把 confidence 还原为“证据链 + 来源 + 时间 + 替代关系”，而不是抽象单值。

在 forgetting 上，作者和评论区都倾向谨慎态度。旧内容不一定应该被简单遗忘，因为旧 bug、旧 ADR、旧决策经常恰恰能解释今天为什么会有当前架构，也能帮助未来避免重复踩坑。

在 supersession 上，文章反而更认可：系统应明确表达“新信息替代旧信息”的关系，而不是让旧内容静默消失。

原版主要依赖 Markdown wikilink 和可视化 graph 来表示页面之间的连接。V2 则把这件事推进到更强语义层：需要 typed knowledge graph。

作者说明其写作语境不是“为了做图而做图”，而是因为真实查询常常不是找某个页面，而是在问影响链与决策链，例如：

  • 升级 Redis 会影响哪些服务？
  • 某个鉴权决策牵涉哪些 bug 和负责人？

对于这类问题，仅靠普通 双链 不够，需要带明确语义的边。文中点名的关系类型包括：

  • uses
  • depends_on
  • contradicts
  • supersedes

作者认为，这类 typed edges 的意义在于：

  • 支持影响分析
  • 支持历史决策追踪
  • 支持冲突识别
  • 支持结构化查询，而不仅是“相关页面跳转”

因此，V2 并非只是把 wiki 做大，而是试图把 wiki 从弱语义文档网络推向带关系契约的知识图结构。

4. Hybrid search：index.md 在中大规模下会成为瓶颈

原版默认认为 index.md 在中等规模下仍然有用，几百页内容时也能撑一段时间。V2 则更明确地指出：当 wiki 超过约 100 到 200 页后，index 会逐渐成为瓶颈。

对应地，V2 不再把检索寄托在单一路径，而是组合三类能力：

  • BM25
  • 向量检索
  • 图遍历

再用 RRF 进行融合排序。

作者特别记录了 Rohit 在评论中的补充说明：这不是“把 index 替换成 hybrid search”就结束了，而是不同检索方式承担不同任务。 其中：

  • BM25 和向量检索负责找“此刻相关”的材料
  • 图遍历负责找“结构上相关”的影响链

这一定义非常关键，因为它说明图遍历不是普通搜索的替代品，而是用来回答结构关系问题的专门通道。

5. Event-driven 与自动维护

原版主要还是人在需要时触发 ingest 或 lint。V2 则往更自动化的方向推进，提出：

  • hooks
  • event-driven updates
  • 更主动的自动维护

作者承认这在生产上有吸引力，但态度明显偏谨慎。他支持“session end 自动生成候选 summary”这类半自动化动作，但反对 Agent 直接改主 wiki。更偏好的方式是：proposal-first。

即：

  1. Agent 自动抽取事实
  2. 自动找冲突
  3. 生成拟议变更与 diff
  4. 高风险写入进入 review queue
  5. 由人进行最后确认

6. 多 Agent 与治理问题

V2 还扩展到原版几乎没有展开的多 Agent 与治理层问题，包括：

  • mesh sync
  • shared/private memory
  • coordination
  • privacy filter
  • audit
  • reversible bulk ops

作者认为，这些议题说明 V2 的目标已不只是个人知识库，而是逐步逼近“可治理的 Agent Memory 系统”。

原版与 V2 的表格化差异总结

文章给出一张对照表，核心差异可整理如下：

知识变旧

  • 原版：主要在 lint 时发现 stale claim
  • V2：通过 lifecycle、supersession、retention 来显式管理过期、替代与保留

搜索扩展

  • 原版：index.md + 可选搜索工具
  • V2：BM25 + vector + graph 的混合检索

结构关系

  • 原版：主要依赖 wikilinks
  • V2：typed entities and relations

自动维护

  • 原版：以人工触发 ingest/lint 为主
  • V2：通过 hooks 与事件驱动进行更自动的更新

多 Agent

  • 原版：只略提团队场景
  • V2：进一步考虑 mesh sync、shared/private、coordination

治理

  • 原版：默认 Git 历史天然可用
  • V2：进一步引入 privacy filter、audit、reversible bulk ops 等治理层能力

作者对这张表的总判断是：原版解决“启动”，V2 解决“扩张后的失控”。

落地方式：作者建议的实施顺序

作者明确反对一上来就做完整 V2，理由是这样会把系统做得过重，并且很难知道究竟哪一层真正有效。文章给出了一条循序渐进的实施路径。

第一步：先做原版风格的 MVP

建议先保留以下核心要素：

  • raw/
  • wiki/
  • index.md
  • log.md
  • AGENTS.md

工作方式是：每次 ingest 时，让 Agent 更新相关页面，然后由人查看 Git diff。

作者给出的 MVP 验收标准很朴素，但很具体：

  • 一次 source 输入后，系统能稳定更新 summary
  • 能更新 entity 页面
  • 能更新 concept 页面
  • 能更新 index
  • 能更新 log
  • 人能看懂每个改动

这意味着 MVP 的目标不是“全自动”，而是“每次写入都可解释、可审阅、可接受”。

第二步：补 claim id 与 source_ref