惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
博客园 - Franky
大猫的无限游戏
大猫的无限游戏
博客园 - 三生石上(FineUI控件)
量子位
博客园 - 聂微东
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
S
SegmentFault 最新的问题
Apple Machine Learning Research
Apple Machine Learning Research
爱范儿
爱范儿
V
Visual Studio Blog
雷峰网
雷峰网
T
Tailwind CSS Blog
宝玉的分享
宝玉的分享
Blog — PlanetScale
Blog — PlanetScale
有赞技术团队
有赞技术团队
博客园 - 叶小钗
Microsoft Azure Blog
Microsoft Azure Blog
T
The Blog of Author Tim Ferriss
U
Unit 42
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
小众软件
小众软件
阮一峰的网络日志
阮一峰的网络日志
Y
Y Combinator Blog

博客园 - SHENHUANJIE

Windows 如何运行和更新 ComfyUI Windows 修改 SVN 仓库地址(relocate 与 switch) Marvis 使用进阶:联动与外部资源整合 这是一篇用 Marvis发布的文章,让大家都去用 Marvis 程序员保持高效的5个习惯 Kimi WebBridge:让 AI 真正操控你的浏览器 腾讯突然扔出王炸!马维斯一夜刷屏,打工人终于有救了? AIGC-测试库账号密码 openspec 是什么?怎么正确使用? # Hello World 的传奇起源 Please Start Here AI助手记忆系统:从金鱼到大象的进化之路 mac 快速切换 python 版本 卢曼卡片盒笔记法介绍 Introduction to the Zettelkasten Method Uni-app页面信息与元素影响解析 DevOps 入门指南:基础知识解读 「读书计划」《啊哈!算法》7日结构化学习规划 Java RestTemplate 发送 POST 请求设置请求体示例 跨平台开发方案:优缺点对比及选择指南 Java实现简单多层感知器神经网络 Google开发者账号注册步骤详解 ipify.org:免费IP查询服务详解 Google开发者利器:云平台与Firebase服务解析 Google Fonts字体库使用指南 UNI-APP + Spring Boot 实现小程序手机号登录 UNI-APP 获取用户手机号授权与服务器端处理指南 MySQL 8.0 如何禁用 ONLY_FULL_GROUP_BY 平衡工作与生活的10个实用方法 Linux安装Ollama并启用服务教程 如何在 LobeChat 中使用 Ollama
Architecture
SHENHUANJIE · 2026-09-02 · via 博客园 - SHENHUANJIE

Architecture

Architecture

LLM Wiki 的三层架构。

三层结构

层级 管理者 职责
Raw Sources 用户 原始来源文档,不可变
Wiki LLM LLM 生成的摘要和知识
Schema 用户 + LLM 工作流规范和约定

Raw Sources(原始来源)

精心收集的来源文档集合:

  • 文章、论文、图片、数据文件
  • 不可变 — LLM 只读取,不修改
  • 这是事实来源

Wiki(维基)

LLM 生成的 Markdown 文件目录:

  • 摘要、实体页面、概念页面
  • 对比、概述和综合
  • LLM 完全拥有这一层
  • 创建页面、更新页面、维护交叉引用

Schema(模式)

定义维基组织的文档:

  • CLAUDE.md(Claude Code)
  • AGENTS.md(Codex)
  • 告诉 LLM 工作流和约定

相关概念

来源

来源: LLM-Wiki-karpathy[5]


  1. LLM Wiki

    LLM Wiki

    利用 LLM 构建个人知识库的模式。

    核心思想

    传统 RAG:上传文件 → 查询时检索 → 生成答案。每次都要从头发现知识,没有积累。

    LLM Wiki 的理念: LLM 逐步构建并维护一个持久化的维基,位于用户和原始数据源之间。新来源到达时:

    • 读取并提取关键信息
    • 整合到现有维基
    • 更新相关页面
    • 标记矛盾之处

    关键区别:维基是持续更新、不断完善的资源。

    • 交叉引用已存在
    • 矛盾之处已标记
    • 综合信息已反映所有阅读内容

    角色分工

    角色 职责
    人类 策划来源、探索、提出正确问题
    LLM 总结、交叉引用、归档、维护

    Obsidian 是 IDE;LLM 是程序员;维基是代码库。

    应用场景

    • 个人:目标、健康、心理、自我提升
    • 研究:数周/数月的深度研究
    • 阅读一本书:创建人物、主题、情节页面
    • 业务/团队:内部 wiki
    • 竞争分析、尽职调查、旅行计划、课程笔记

    相关概念

    来源

    *来源: * LLM-Wiki-karpathy[5:1] ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. Ingest

    Ingest

    摄取新来源到维基的工作流。

    工作流程

    1. 放入来源 — 将新来源放入 raw 目录
    2. 读取来源 — LLM 读取原始文档
    3. 讨论要点 — 与用户讨论关键内容
    4. 编写摘要 — 在 wiki 中创建摘要页面
    5. 更新索引 — 更新 wiki/index.md
    6. 更新关联 — 更新相关实体和概念页面
    7. 记录日志 — 在 wiki/log.md 追加条目

    影响范围

    单个来源可能影响 10-15 个维基页面

    工作风格

    方式 特点
    逐个摄取 保持参与,阅读摘要,检查更新
    批量摄取 减少监督,适合更多来源

    注意事项

    • 与用户讨论内容的关键要点
    • 指导 LLM 强调什么
    • 重要洞察可归档回维基

    相关概念

    来源

    *来源: * LLM-Wiki-karpathy[5:4] ↩︎ ↩︎ ↩︎ ↩︎

  3. Query

    Query

    针对维基提问的工作流。

    工作流程

    1. 搜索相关 wiki 页面
    2. 读取相关页面
    3. 综合整理带引用的答案

    答案形式

    根据问题不同,答案可以呈现为:

    • Markdown 页面
    • 对比表格
    • 幻灯片(Marp)
    • 图表(matplotlib)
    • 画布

    重要洞察

    好的答案可以作为新页面归档回维基。

    • 您要求的对比、分析
    • 您发现的联系
    • 这些都是有价值的,不应消失在聊天历史中

    与 Ingest 对比

    工作流 输入 输出
    Ingest 原始来源 维基页面
    Query 用户问题 答案(可归档)

    相关概念

    来源

    *来源: * LLM-Wiki-karpathy[5:5] ↩︎ ↩︎ ↩︎ ↩︎

  4. Lint

    Lint

    定期对维基进行健康检查。

    检查项目

    1. 矛盾 — 页面之间的矛盾声明
    2. 过时 — 被新来源取代的旧声明
    3. 孤立 — 没有入站链接的页面
    4. 缺失 — 提及但没有自己页面的重要概念
    5. 断链 — 缺失的交叉引用
    6. 空白 — 可以通过网络搜索填补的数据空白

    目的

    保持维基在增长过程中健康

    LLM 的角色

    LLM 擅长:

    • 建议新的研究问题
    • 寻找新的来源
    • 识别矛盾和过时的内容

    触发方式

    请 LLM 进行 Lint:

    "请对维基进行健康检查"

    相关概念

    来源

    *来源: * LLM-Wiki-karpathy[5:6] ↩︎ ↩︎ ↩︎ ↩︎

  5. LLM-Wiki-karpathy

    LLM Wiki

    利用 LLM 构建个人知识库的模式。

    这是一个概念文件,旨在复制粘贴到您自己的 LLM 代理(例如 OpenAI Codex、Claude Code、OpenCode/Pi 等)中。它的目标是传达高层次的概念,但您的代理将与您协作构建具体细节。

    核心思想

    大多数人与 LLM 和文档的交互体验都类似于 RAG:您上传一系列文件,LLM 在查询时检索相关片段,然后生成答案。这种方式虽然可行,但 LLM 每次都要从头开始重新发现知识,没有积累。当您提出一个需要综合五个文档的微妙问题时,LLM 必须每次都找到并拼凑相关的片段。没有任何积累。NotebookLM、ChatGPT 文件上传以及大多数 RAG 系统都是这样工作的。

    这里的理念有所不同。与其仅仅在查询时从原始文档检索,LLM 逐步构建并维护一个持久化的维基 —— 一个结构化的、相互链接的 Markdown 文件集合,位于您和原始来源之间。当您添加新来源时,LLM 不仅仅是为后续检索而索引它。它读取来源,提取关键信息,并将其整合到现有维基中 —— 更新实体页面,修订主题摘要,指出新数据与旧声明相矛盾之处,强化或挑战不断发展的综合分析。知识只需编译一次,然后保持最新,而不是在每次查询时重新推导。

    这就是关键区别:维基是一个持久的、不断积累的产物。 交叉引用已经存在。矛盾之处已经标记。综合分析已经反映了您所阅读的一切。维基随着您添加的每个来源和提出的每个问题而变得更加丰富。

    您几乎从不(或者很少)亲自编写维基 —— 所有内容都由 LLM 编写和维护。您负责策划来源、探索和提出正确的问题。LLM 负责所有繁琐的工作 —— 总结、交叉引用、归档和记录,使知识库能够长期发挥作用。实际上,我一边打开 LLM 代理,一边打开 Obsidian。LLM 根据我们的对话进行编辑,我实时浏览结果 —— 跟随链接、检查图谱视图、阅读更新后的页面。Obsidian 是 IDE;LLM 是程序员;维基是代码库。

    这可以应用于许多不同的情境。以下是一些例子:

    • 个人:跟踪自己的目标、健康、心理、自我提升 —— 记录日记条目、文章、播客笔记,并随着时间的推移构建一个结构化的自我形象。
    • 研究:对某个主题进行数周或数月的深入研究 —— 阅读论文、文章、报告,并逐步构建一个包含不断发展论点的综合维基。
    • 阅读一本书:边读边整理每个章节,为人物、主题、情节线索以及它们之间的联系创建页面。到最后,您将拥有一个丰富的配套维基。想想像 托尔金之门 这样的粉丝维基 —— 成千上万个相互链接的页面,涵盖人物、地点、事件、语言等,由志愿者社区历经数年构建而成。您可以在阅读的同时亲自构建类似的东西,由 LLM 处理所有的交叉引用和维护工作。
    • 业务/团队:一个由 LLM 维护的内部维基,内容来自 Slack 讨论串、会议记录、项目文档和客户电话。可能有人类参与审核更新。维基之所以能保持最新,是因为 LLM 负责团队中没有人愿意做的维护工作。
    • 竞争分析、尽职调查、旅行计划、课程笔记、爱好深入研究 —— 任何需要您随时间积累知识并希望将其组织起来而非散落各处的事物。

    架构

    有三层:

    原始来源 —— 您精心收集的来源文档集合。文章、论文、图片、数据文件。这些是不可变的 —— LLM 从中读取但从不修改它们。这是您的事实来源。

    维基 —— 一个由 LLM 生成的 Markdown 文件目录。摘要、实体页面、概念页面、对比、概述和综合。LLM 完全拥有这一层。它创建页面,在新来源到来时更新页面,维护交叉引用,并保持一切一致。您阅读它;LLM 编写它。

    模式 —— 一个文档(例如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md),告诉 LLM 维基是如何组织的,有哪些约定,在摄取来源、回答问题或维护维基时应该遵循什么工作流程。这是关键的配置文件 —— 它使 LLM 成为规范的维基维护者,而不是通用的聊天机器人。您和 LLM 共同随着时间的推移完善这一点,因为您会弄清楚什么对您的领域有效。

    操作

    摄取。 您将新来源放入原始集合,并告诉 LLM 处理它。流程示例:LLM 读取来源,与您讨论关键要点,在维基中编写摘要页面,更新索引,更新整个维基中相关的实体和概念页面,并在日志中追加条目。单个来源可能会影响 10-15 个维基页面。就个人而言,我更喜欢一次摄取一个来源并保持参与 —— 我阅读摘要,检查更新,并指导 LLM 强调什么。但您也可以一次性批量摄取多个来源,并减少监督。您可以开发适合自己风格的工作流程,并将其记录在模式中,以便将来会话使用。

    查询。 您针对维基提问。LLM 搜索相关页面,读取它们,并综合整理出带有引用的答案。答案可以根据问题的不同呈现不同的形式 —— Markdown 页面、对比表格、幻灯片(Marp)、图表(matplotlib)或画布。重要的洞察:好的答案可以作为新页面归档回维基中。 您要求的对比、分析、您发现的联系 —— 这些都是有价值的,不应该消失在聊天历史中。这样,您的探索就像摄取的来源一样,在知识库中积累。

    整理。 定期请 LLM 对维基进行健康检查。寻找:页面之间的矛盾、被更新的来源取代的过时声明、没有入站链接的孤立页面、提及但缺少自己页面的重要概念、缺失的交叉引用、以及可以通过网络搜索填补的数据空白。LLM 擅长建议新的研究问题和寻找新的来源。这使维基在增长过程中保持健康。

    索引和日志

    两个特殊文件帮助 LLM(以及您)在维基增长时导航。它们有不同的用途:

    index.md 是面向内容的。它是维基中所有内容的目录 —— 每个页面都列出链接、一行摘要,以及可选的元数据如日期或来源数量。按类别组织(实体、概念、来源等)。LLM 在每次摄取时更新它。在回答查询时,LLM 首先读取索引以找到相关页面,然后深入阅读它们。这在中等规模(约 100 个来源,数百个页面)下效果出奇地好,避免了对基于嵌入的 RAG 基础设施的需求。

    log.md 是时间顺序的。它是只追加的记录,记录发生了什么以及何时发生 —— 摄取、查询、整理。有一个有用的技巧:如果每个条目都以一致的前缀开头(例如 ## [2026-04-02] ingest | Article Title),日志就可以用简单的 unix 工具解析 —— grep "^## \[" log.md | tail -5 给出最后 5 个条目。日志为您提供了维基演变的时间线,并帮助 LLM 了解最近做了什么。

    可选:CLI 工具

    在某些时候,您可能想要构建帮助 LLM 更高效操作维基的小工具。在维基页面上构建搜索引擎是最明显的 —— 在小规模下索引文件就足够了,但随着维基的增长,您需要适当的搜索。qmd 是一个不错的选择:它是一个本地 Markdown 文件搜索引擎,结合了 BM25/向量搜索和 LLM 重排序,全部设备上运行。它既有 CLI(所以 LLM 可以调用它),也有 MCP 服务器(所以 LLM 可以将其作为原生工具使用)。您也可以根据自己的需要构建更简单的东西 —— LLM 可以帮助您随心所欲地编写一个简单的搜索脚本。

    技巧和窍门

    • Obsidian Web Clipper 是一个浏览器扩展,可将网页文章转换为 Markdown。非常适合快速将来源放入您的原始集合。
    • 将图片下载到本地。 在 Obsidian 设置 → 文件和链接中,将"附件文件夹路径"设置为一个固定目录(例如 raw/assets/)。然后在设置 → 热键中,搜索"下载"找到"下载当前文件的附件"并绑定到热键(例如 Ctrl+Shift+D)。剪藏文章后,按下热键,所有图片都会下载到本地磁盘。这是可选的,但很有用 —— 它让 LLM 直接查看和引用图片,而不是依赖可能失效的 URL。请注意,LLM 不能原生地在一次传递中读取带有内联图片的 Markdown —— 解决方法是让 LLM 先读取文本,然后分别查看一些或所有引用的图片以获得额外的上下文。这有点笨拙,但效果足够好。
    • Obsidian 的图谱视图 是查看维基形状的最佳方式 —— 什么连接着什么,哪些页面是中心,哪些是孤立的。
    • Marp 是一个基于 Markdown 的幻灯片格式。Obsidian 有相应的插件。可用于直接从维基内容生成演示文稿。
    • Dataview 是一个 Obsidian 插件,对页面 frontmatter 运行查询。如果您的 LLM 在维基页面上添加了 YAML frontmatter(标签、日期、来源数量),Dataview 可以生成动态表格和列表。
    • 维基只是一个 Git 仓库的 Markdown 文件。您免费获得版本历史、分支和协作。

    为什么这有效

    维护知识库中最繁琐的部分不是阅读或思考,而是记录工作。更新交叉引用、保持摘要最新、注意新数据何时与旧声明矛盾、保持数十个页面之间的一致性。人类放弃维基是因为维护负担增长速度快于价值。LLM 不会感到无聊,不会忘记更新交叉引用,可以一次修改 15 个文件。维基保持维护,因为维护成本接近于零。

    人类的工作是策划来源、引导分析、提出好问题并思考这一切意味着什么。LLM 的工作是其他一切。

    这个理念在精神上与 Vannevar Bush 的 Memex (1945) 相关 —— 一种具有文档间联想路径的个人、策划的知识存储。Bush 的愿景比 Web 最终成为的样子更接近这个 —— 私人的、主动策划的,文档间的连接与文档本身一样有价值。他无法解决的部分是:谁来维护?LLM 解决了这个问题。

    备注

    本文档有意保持抽象。它描述的是理念,而不是具体的实现。确切的目录结构、模式约定、页面格式、工具 —— 所有这些都取决于您的领域、您的偏好和您选择的 LLM。以上提到的所有内容都是可选的和模块化的 —— 选择有用的,忽略没用的。例如:您的来源可能只有文本,那么您根本不需要图片处理。您的维基可能很小,索引文件就是您所需的全部,不需要搜索引擎。您可能不关心幻灯片,只想要 Markdown 页面。您可能想要完全不同的输出格式集。使用它的正确方式是将其分享给您的 LLM 代理,并与它协作实例化一个适合您需求的版本。本文档的唯一工作是传达这个模式。您的 LLM 可以弄清楚其余部分。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. RAG

    RAG (Retrieval-Augmented Generation)

    检索增强生成。传统 LLM 与文档交互的方式。

    工作原理

    1. 上传一系列文件
    2. 查询时检索相关片段
    3. 生成答案

    局限性

    • 每次都要从头重新发现知识
    • 没有积累
    • 需要综合多个文档时,必须每次都找到并拼凑相关片段
    • Nothing is built up

    LLM Wiki 的改进

    LLM Wiki[1:1] 不是在查询时检索,而是 LLM 逐步构建并维护一个持久化维基,知识编译一次后保持最新。

    来源

    *来源: * LLM-Wiki-karpathy[5:2] ↩︎

  7. Memex

    Memex

    Vannevar Bush 于 1945 年提出的概念 —— 个人策划的知识库,文档间有联想路径。

    Bush 的愿景

    • 私人化
    • 主动策划
    • 文档间的连接与文档本身同等价值

    与现代 Web 的对比

    Bush 的愿景更接近 LLM Wiki[1:2] 的理念,而非后来的 Web。

    未解决的问题

    Bush 无法解决的是:谁来维护?

    LLM Wiki[1:3] 回答了这个问题 —— LLM 负责维护工作。

    来源

    *来源: * LLM-Wiki-karpathy[5:3] ↩︎