← #791

LLM 是如何工作的——基于 Karpathy 讲座的交互式可视化指南

文章摘要

这是一份基于 Andrej Karpathy 技术讲座制作的交互式可视化教学，旨在把”从原始互联网文本到对话式 AI 助手”的完整流程系统呈现出来。整套内容围绕大模型训练的两大阶段展开：预训练（pre-training）和后训练（post-training），覆盖了从数千 GPU 上长达数月的算力投入，到最终落地为聊天助手的全过程。

预训练阶段：从”采集海量文本”开始，作者展示了网页爬虫的数据流水线——URL 黑名单过滤、HTML 解析、语言识别、去重、PII 移除——最终形成约 44TB 的语料、对应 15 万亿 token。接下来是分词环节，使用 Byte Pair Encoding（BPE）把字符对按频率合并，得到约 10 万 token 的词表，这种子词机制能很好地处理新词和形态变化。然后是 Transformer 训练循环：采样 token 序列，预测下一个 token，计算 loss，更新数十亿参数。可视化展示了 loss 从 11.2 下降到 2.4 的过程，让读者直观看到模型逐渐”学到”语言模式。

后训练阶段：先做监督微调（SFT），用人工标注的对话数据让基础模型学会按规范回答；再用 RLHF（基于人类反馈的强化学习），通过偏好奖励模型把回答优化得更有用、结构更好、更诚实。

文章还提炼了几个关键认知点：基础模型本质上是”token 模拟器”，是高级版的自动补全，并不存在真正”理解”；所有生成都是从概率分布中采样而非”刻意推理”；嵌入向量在网络层之间不断被上下文调整，从而被赋予语义；知识同时存在于参数（长期、压缩记忆）和上下文窗口（精确的工作记忆）；RAG 通过检索文档把回答锚定在事实上，从而减少在”时新信息”上的幻觉。

HN 评论精华

值得注意的是，这篇 HN 帖子下大部分评论是负面的，这本身也是一种现象。

lateral_cloud / skiing_crawling / dylkil 三位评论者都直接指出文章”完全是 AI 生成的”，质疑这种内容的发布价值——任何人都能用同样 prompt 让 LLM 复述一遍，发出来意义有限。
arcza 措辞更尖锐：”又一个低投入的 dark mode slop 站点。在’44TB’还没看到 em-dash 之前我就已经放弃了。@dang，什么时候加’flag as slop’按钮？”。这反映出 HN 社区对 AI slop 内容的不耐烦正在累积。
PetitPrince 给出了具体的事实指摘：文章宣称 44TB”差不多就是一块普通硬盘的容量”，但事实上正常人都不会这样想（市场上目前 32TB 已是上限），暴露出作者发布前缺少校对。他强调”用 LLM 做炫酷可视化没问题，但缺乏校对会让人对内容质量失去信心”。
gushogg-blake 提出了一些非常基础却经常没被解释清楚的问题：神经网络的输入端到底长什么样？它是否就是”context size 个 token”的位宽？输入比 context size 短时怎么处理？嵌入如何处理”bank”这种多义词（河岸 vs 银行）？训练时和推理时嵌入是否会更新？这些问题正好暴露出当前科普文都”轻轻带过”的技术细节，恰恰是读者最想知道的部分。
lukeholder 抱怨在 iOS Safari 上页面会持续抖动几像素，这是个用户体验细节问题。
总体看，社区共识是：与其再做一份漂亮的”AI 二次咀嚼” Karpathy 讲座，不如直接看 Karpathy 本人的原版视频。