Transformer on Khari Z's LogBook

从 Karpathy 的 LLM Wiki 到我的知识系统

Sun, 12 Apr 2026 00:00:00 +0000

引子：从一次性问答到可维护知识库

2026 年 4 月的一天，Andrej Karpathy 在 GitHub Gist 上发布了一篇名为 LLM Wiki 的文档。它讨论的不是一次性使用 ChatGPT，而是如何让 LLM 持续维护个人知识库。

这篇笔记记录两件事：Karpathy 的 LLM Wiki 模式是什么，以及我怎么把它落到自己的 LLM 学习系统里。复习时主要看三层结构和三种操作。

一、LLM Wiki：从 RAG 到持久知识编译

1.1 它想解决什么

常见的 LLM 文档问答模式是 RAG（Retrieval-Augmented Generation）：上传文档 -> 检索相关片段 -> 生成回答。它能解决单次问答，但有个问题：知识不会自动沉淀。昨天问答中的归纳、矛盾和交叉引用，不会自然变成今天可复用的知识结构。

Karpathy 提出的替代方案是让 LLM 增量构建并维护一个持久 Wiki：

当你加入新资料时，LLM 会阅读它、提取关键信息、整合进现有 Wiki，并更新实体页面、修订主题总结、标记新数据与旧论断的矛盾、强化或质疑正在演进的综合分析。

区别在于：Wiki 是一个持续维护的知识层。它不只是临时检索结果，而是把摘要、概念页、实体页、矛盾标记和综合分析长期保存下来。

1.2 三层架构

1
2
3
4
5
6
7


┌──────────────────────────────────────┐
│ Schema（AGENTS.md / CLAUDE.md） │ ← 你和 LLM 共同维护的行为规范
├──────────────────────────────────────┤
│ Wiki（markdown 文件目录） │ ← LLM 写、你读的知识层
├──────────────────────────────────────┤
│ Raw Sources（原始文档） │ ← 不可变的来源真值
└──────────────────────────────────────┘

Raw Sources：原始材料层，保存论文、文章、代码笔记等来源。只读，不让 LLM 修改。
Wiki：知识加工层，保存摘要页、实体页、概念页、比较分析等 Markdown 页面。LLM 主要维护这一层。
Schema：维护规则层，用来规定 LLM 如何 ingest、query、lint，以及页面格式、引用规范和日志规则。

1.3 三种操作

操作	描述	产出
Ingest	投入新资料，LLM 阅读、摘要、更新现有页面	一次 ingest 可能触及 10–15 个 Wiki 页面
Query	向 Wiki 提问，LLM 综合相关页面生成带引用的回答	好的回答可以回写为 Wiki 新页面
Lint	LLM 对 Wiki 做健康检查——矛盾、孤立页、缺失引用	维护 Wiki 的长期质量

1.4 为什么这行得通

维护知识库的难点不在于阅读或思考——在于记账。更新交叉引用、保持摘要最新、标记新旧数据冲突、维护一致性。人类放弃 Wiki 是因为维护成本增长得比价值更快。LLM 不会厌倦，不会忘记更新引用，能一次性修改 15 个文件。

复习锚点：Raw Sources 保真，Wiki 负责综合，Schema 约束维护行为。这个模式的价值不在“自动写笔记”，而在降低长期维护成本。

这个模式让我想到 Vannevar Bush 1945 年的 Memex 构想：一个带有文档间关联路径的个人知识存储。过去的难点是“谁来维护链接和摘要”；LLM 让这部分维护成本降了下来。

二、实践：我的 LLM Wiki 搭建

我在自己的知识库中按这个模式搭了一个最小结构：

2.1 目录结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


Wiki/
├── AGENTS.md # Schema：工作流规范
├── index.md # 内容索引：按类别编目所有页面
├── log.md # 时间线：append-only 的操作日志
├── raw/ # Raw Sources 层
│ ├── index.md # 来源注册表
│ └── inbox/ # 新材料暂存区
│ └── llm-zero-to-one/ # LLM 学习专题
└── pages/ # Wiki 层
 ├── sources/ # 每份来源的摘要页
 ├── concepts/ # 跨来源的概念归纳页
 ├── entities/ # 实体页（人物/工具/模型）
 ├── queries/ # 问答沉淀页
 └── synthesis/ # 综合分析页

2.2 流程实录

以收录 Happy-LLM 第一章为例，一次 ingest 大概是这样：

将文章 Markdown 放入 raw/inbox/llm-zero-to-one/
在 raw/index.md 登记为 Status = selected
LLM 阅读全文，生成 pages/sources/happy-llm-chapter1-nlp-basics.md
LLM 判断该来源属于 “LLM 从零学习” 概念域，更新 pages/concepts/llm-zero-to-one-learning-path.md
更新 index.md 的概念表条目
在 log.md 追加操作记录

一份来源会触及多个页面。随着来源增多，概念页会不断补充证据、链接和对比关系，这就是 Wiki 模式区别于普通摘抄的地方。

2.3 我学到的一点

实践之后，我最想留下的是这句话：

先搭可持续维护的知识系统，再扩充学科内容，可以少掉很多碎片化学习的损耗。

这和传统“先学东西再整理笔记”的路径不同。学习系统先就位后，每一份新材料都会进入已有页面、索引和日志，而不是散落成临时笔记。

三、这个模式具体解决什么

这个知识管理模式带来几个直接好处：

学习有据可查：每次 ingest 和 query 都留有 log 记录，可以回溯学习轨迹。
碎片能慢慢成系统：零散笔记会进入概念页和综合页，不再只是一堆临时摘抄。
交叉引用不用全靠手动维护：不同知识点可以自动链接起来。
学习路径更可见：通过 Obsidian 的图谱视图，可以看到哪些知识节点已经建立，哪些还是空白。

四、下一步

按照 Happy-LLM 的课程路线，接下来的学习计划包括：

预训练语言模型：比较 Encoder-only (BERT)、Encoder-Decoder (T5)、Decoder-only (GPT) 三种范式
大语言模型专题：LLM 的定义、涌现能力、训练策略
动手搭建：基于 PyTorch 实现 LLaMA2，从 Tokenizer 到预训练的完整链路
训练实践：预训练 → SFT → LoRA/QLoRA 高效微调
应用层：RAG 检索增强、Agent 智能体

每个阶段的学习材料都会通过 Wiki 的 ingest 流程进入知识网络。这篇博文本身，也算是一次从 Wiki 到 Blog 的输出。

参考资料

Karpathy, A. LLM Wiki. GitHub Gist, 2026.
Datawhale. Happy-LLM：从零开始构建大模型. GitHub, 2025.
Bush, V. As We May Think. The Atlantic, 1945.

从 NLP 基础到 Transformer：我先补的几块地基

Sun, 12 Apr 2026 00:00:00 +0000

进入大语言模型之前，我先补两块东西：文本如何变成模型能处理的向量，以及 Transformer 如何用注意力机制建模上下文。这两件事没理顺，后面看 tokenizer、embedding、mask、训练目标和生成过程时很容易断线。

这篇文章分成两部分：先梳理文本表示从统计方法到上下文化表示的演化，再整理手写 Transformer 时最容易混淆的九个实现问题。复习时重点看三条线：张量形状怎样变化、mask 怎样限制信息流、Encoder/Decoder 各自承担什么任务。

一、温故知新：文本表示是如何进化到大模型时代的？

在接触大模型结构之前，先回答一个底层问题：文本怎样被表示成模型可以计算的对象？

1.1 NLP 范式的演进

NLP 的技术路线可以粗略分成三段。每一段都在回答同一个问题：如何把语言现象变成可计算、可学习的形式。

规则方法（手写模板）：早期需要语言学专家人工定义无数规则。
统计方法（概率模型）：利用马尔可夫模型、隐马尔可夫模型等，让模型学习词串在语料库中出现的概率分布。
深度学习方法（端到端）：采用神经网络构建端到端的系统，无需繁杂的特征工程。

1.2 文本表示的“进化链”

大模型能处理长文本和上下文，前提是文本表示已经从稀疏统计特征走到稠密、上下文化向量。复习时我按这条链看：

方法	核心思想	特点与局限
VSM (词袋模型)	将文本表示为高维稀疏向量，基于词频统计。	忽略了词语的先后顺序，也完全丢失了语义相似性信息。
N-gram	考察连续 n 个词的共现概率。	能捕捉一定的局部词序，但面临严重的维度爆炸和数据稀疏问题。
Word2Vec	用稠密、低维的向量表示词语，语义相近的词距离更近。	静态表示（Static Embedding），每个词具有固定的向量表征，无法解决“一词多义”问题。
ELMo	基于双向 LSTM，根据上下文动态生成词向量。	实现了动态表示，但受限于 RNN 架构，长距离依赖的建模能力仍然有限。

RNN/LSTM 按时间步递归处理序列，不利于大规模并行，也很难稳定抓住超长距离依赖。Transformer 的自注意力机制改成一次性比较序列中所有 token 之间的关系，所以更适合并行训练和长上下文建模。

二、直面硬核：Transformer 学习过程中的 9 个迷思与解答

学习 Transformer 时，真正容易卡住的不是公式，而是公式落到代码以后：每个张量在哪一层、是什么形状、表示什么语义。下面九个问题都围绕一件事：把结构设计和实现细节对上。

复习时可以把这些问题当成检查表：能回答清楚，就说明注意力、mask、残差、位置编码和编解码器分工已经基本接上。

Q1：关于多头注意力参数的组织方式

为什么通常使用三个“组合特征矩阵”（比如 $W_Q, W_K, W_V$）而不是给每个注意力头分配单独的矩阵？

在实现时，代码经常直接使用 nn.Linear(d_model, 3 * d_model) 或等价组合。这是因为 $X \cdot W_{combined}$ 在数学上完全等价于先分别对每个头进行特征映射然后再将结果拼接起来。使用组合矩阵能够在 GPU 上将所有的计算打包成一次矩阵乘法（matmul），极大提升了计算并行度与效率。

Q2：Causal Mask（因果掩码）的切片逻辑

代码中经常看到 scores = scores + mask[:, :, :seqlen, :seqlen]，这样做的意义是什么？

因果掩码用来防止 Decoder 在自回归生成时“偷看未来”。通常这个 mask 张量会被构造成一个上三角全为 $-\infty$、下三角（含对角线）全为 $0$ 的矩阵。把它加到注意力分数 scores 后再做 softmax，未来位置的权重就会变成 $0$。最后的切片 :seqlen, :seqlen 是为了从预分配的大掩码里，取出当前序列长度真正需要的那一块。

Q3：残差连接到底发生在什么位置

经常看见 Attention 模块里面有 self.wo 和 resid_dropout，它是直接在 Attention 里计算残差吗？

这是一个常见误解。Attention 模块内部通常只做注意力计算、输出投影 self.wo 和 dropout，并不直接把输入 x 加回来。残差连接一般发生在外层的 EncoderLayer 或 DecoderLayer 中，以 x + sublayer_output 或 x + dropout(sublayer_output) 的形式完成。

Q4：Encoder 与 Decoder 到底差在哪

作为整体，它们的分工到底有什么不同？

Encoder 负责建模源序列内部的上下文。它是一个“通读全文”的结构，通常不需要因果掩码。
Decoder 在生成时必须遵守时间顺序。它先用带掩码的自注意力层（Masked Self-Attention）看自己已经生成的历史，再用交叉注意力层（Cross-Attention）读取 Encoder 的输出，最后通过前馈网络（FFN）得到用于预测下一个词的隐状态。

Q5：Self-Attention 🆚 Cross-Attention

自注意力和交叉注意力的结构区别在哪里？

属性	Self-Attention (自注意力)	Cross-Attention (交叉注意力)
Q的来源	当前序列内部	目标序列（Decoder 端）
K/V的来源	当前序列内部	源序列（Encoder 端）
解决的问题	“我这句话里的词之间，谁和谁有什么联系？”	“我在生成当前目标词时，应该把注意力放在上一句（源句）的哪几个词上？”

Q6：为什么 Decoder 必须要设计 Cross-Attention

只使用自回归生成不行吗？为什么还要多加一层交叉注意力？

如果只靠 Masked Self-Attention，Decoder 只能看到目标侧已经生成的历史 token，无法直接利用源序列信息。Cross-Attention 让 Decoder 在每个生成位置都用当前目标侧状态作为 Query，去 Encoder 输出中检索相关的 Key/Value。这个机制相当于软对齐：不需要人工指定源词和目标词的对应关系，模型会通过注意力权重自己选择源端信息。

Q7：位置编码（Positional Encoding）的直觉理解

Transformer 摒弃了 RNN 的时序结构，那它是怎么解决词语顺序问题的呢？

注意力机制本身只计算 token 之间的相似度，不天然包含顺序信息。如果不加入位置编码，模型很难区分“猫追狗”和“狗追猫”这类词相同但顺序不同的句子。

位置编码的作用是把位置信息放进 token 表示里。将位置编码向量加到词嵌入后，模型在计算注意力时既能比较“token 内容是什么”，也能利用“token 在哪个位置”。Sin/Cos 绝对位置编码使用不同频率的三角函数表示位置；三角函数有平移关系，所以它也能帮助模型推断相对距离。

Q8：`register_buffer` 在 PyTorch 实现中的意义

有些模型参数会使用 register_buffer，这是为什么？

register_buffer 用于注册那些随模型保存（会被序列化进入 state_dict）并且会随模型调用 to(device) 自动迁移到 GPU，但不参与梯度更新（不可训练） 的状态张量。比如上面提到的、预先计算好的三角位置编码缓存以及因果掩码矩阵，这就是典型的使用场景。

Q9：`view` 操作的作用场景

在多头注意力实现中，为什么最后经常要调用 view？

多头注意力需要把隐藏层维度拆成多个头。例如把 [batch, seqlen, dim] 改成 [batch, seqlen, n_heads, head_dim]，其中 dim = n_heads * head_dim。view 的作用是重新解释张量形状，不改变元素总数，也不改变底层数据。复习时要记住：view 解决的是形状组织问题，不是新增参数或复制语义。

三、接下来还想继续补上的问题

复习这篇时，我会把问题压成三句：

文本表示的演化，是从稀疏词频走向上下文化向量。
Transformer 用注意力计算 token 间关系，再用 mask 和位置编码约束信息流。
手写实现时，最该盯住张量形状、残差所在层级、Encoder/Decoder 的信息来源。

接下来继续往下学时，重点就会自然转向三条路线：BERT 的 Encoder-Only、T5 的 Encoder-Decoder、GPT/LLaMA 的 Decoder-Only。