【转载】现代大语言模型注意力机制变体可视化指南

原文地址:A Visual Guide to Attention Variants in Modern LLMs,by Sebastian Raschka, on 2026-03-22

现代大语言模型注意力机制变体可视化指南

从 MHA、GQA 到 MLA、稀疏注意力与混合架构

我原本计划撰写关于 DeepSeek V4 的内容。由于该模型尚未发布,我便利用这段时间整理了一项计划已久的工作:收集、梳理并细化过去几年我研究过的各类 LLM 架构。

在过去两周里,我将这项工作整理成了一个LLM 架构图库(撰写本文时已收录 45 个模型),整合了早期文章的资料,以及数个此前未整理的重要架构。每个模型都配有可视化模型卡片,我也计划定期更新这个图库。
你可以在此访问图库:https://sebastianraschka.com/llm-architecture-gallery/

figure01

图 1:LLM 架构图库及其可视化模型卡片概览
https://sebastianraschka.com/llm-architecture-gallery/

分享初始版本后,有读者询问是否有海报版本。因此我也制作了海报版,可在此查看:https://www.redbubble.com/i/poster/LLM-Architecture-Gallery-by-Ahead-of-AI/179274487/flk2
我订购了中号尺寸(26.9×23.4 英寸)来验证打印效果,成品清晰锐利。不过该尺寸下部分最小的文字已经很小了,如果希望所有内容都清晰可读,不建议选择更小的尺寸。

figure02

图 2:架构图库海报与日常物品的尺寸对比
https://www.redbubble.com/i/poster/LLM-Architecture-Gallery-by-Ahead-of-AI/179274487/flk2

在搭建图库的同时,我也在为几个 LLM 核心概念制作简短讲解。
因此在本文中,我想系统梳理近年主流开源架构中发展并应用的各类注意力变体。
我的目标是让这份资料既能作为参考手册,也能作为轻量化的学习资源。希望对你有所帮助!

Continue reading 【转载】现代大语言模型注意力机制变体可视化指南

【转载】开源权重大语言模型的春日之梦

原文地址:A Dream of Spring for Open-Weight LLMs: 10 Architectures from Jan-Feb 2026,by Sebastian Raschka, on 2026-02-25

开源权重大语言模型的春日之梦:2026年1-2月发布的10种架构

2026 年春季 10 款开源权重大语言模型发布汇总与对比

如果你本月有些跟不上开源权重模型的发布节奏,本文将帮你梳理核心要点。

本文将按时间顺序逐一介绍这十款主流发布模型,重点分析它们在架构设计上的异同:

  1. Arcee AI 的 Trinity Large(2026 年 1 月 27 日)

  2. 月之暗面(Moonshot AI)的 Kimi K2.5(2026 年 1 月 27 日)

  3. 阶跃星辰(StepFun)的 Step 3.5 Flash(2026 年 2 月 1 日)

  4. Qwen3-Coder-Next(2026 年 2 月 3 日)

  5. z.AI 的 GLM-5(2026 年 2 月 12 日)

  6. MiniMax M2.5(2026 年 2 月 12 日)

  7. 纳米格(Nanbeige)4.1 3B(2026 年 2 月 13 日)

  8. Qwen 3.5(2026 年 2 月 15 日)

  9. 蚂蚁集团的 Ling 2.5 1T 与 Ring 2.5 1T(2026 年 2 月 16 日)

  10. Cohere 的 Tiny Aya(2026 年 2 月 17 日)

更新 1:Sarvam 30B 与 105B(2026 年 3 月 6 日)
(注:DeepSeek V4 发布后将补充加入本文。)

由于内容覆盖面较广,本文将引用我此前发布的《大语言模型架构大对比》一文(https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison)作为混合专家(Mixture-of-Experts, MoE)、QK 归一化(QK-Norm)、多头潜注意力(Multi-head Latent Attention, MLA)等技术主题的背景资料,避免内容重复。

Continue reading 【转载】开源权重大语言模型的春日之梦

【转载】提升大语言模型推理能力的推理时算力缩放分类

原文地址:Categories of Inference-Time Scaling for Improved LLM Reasoning,by Sebastian Raschka, on 2026-01-24

提升大语言模型推理能力的推理时算力缩放分类

兼述最新推理缩放研究论文(含递归语言模型)

推理缩放已经成为提升已部署大语言模型回答质量与准确率的最有效手段之一。

它的原理非常直白:如果我们愿意在推理阶段(即使用模型生成文本时)投入更多算力、花费更多时间,就能让模型输出更优质的答案。

如今,每一家主流大语言模型服务商都在采用某种形式的推理时算力缩放,学术界围绕这类方法的研究也在快速增长。

今年3月,我曾写过一篇推理缩放领域概览,总结了早期的部分技术。

《大语言模型推理模型的推理现状》

在本文中,我会在之前讨论的基础上做进一步延伸,将不同方法划分成更清晰的类别,同时重点介绍过去几个月涌现的最新研究成果。

在为《从零构建推理模型》一书撰写推理缩放完整章节的过程中,我亲自实验了这类方法的众多基础变体。为了调优超参数,我累计跑了数千次实验,花了大量精力斟酌哪些方法值得在章节中展开讲解。(这个章节最后篇幅过长,我最终拆成了两章,目前都已在抢先阅读计划中上线。)

附言:我对这两章的最终呈现非常满意。它们能把基础模型的准确率从约15%提升到52%左右,是目前整本书里成就感最强的内容之一。

本文整理了一些没有放进最终章节叙事、但仍然值得分享的思路、笔记与论文。
我也计划后续在GitHub的补充材料里加入更多代码实现。

目录概览

  1. 推理时算力缩放概述

  2. 思维链提示

  3. 自一致性

  4. N选优排序

  5. 带验证器的拒绝采样

  6. 自我精炼

  7. 解路径搜索

  8. 结论、分类与组合方式

  9. 番外:闭源大语言模型都用了哪些技术?

你可以在网页版阅读时使用左侧导航栏,直接跳转到任意章节。


1 推理时算力缩放概述

推理时算力缩放(也叫推理算力缩放、测试时缩放,或简称推理缩放)是一个统称,指代所有在推理阶段投入更多算力与时间来提升模型表现的方法。

这个概念由来已久,经典机器学习中的集成方法就可以看作推理时缩放的早期例子——使用多个模型会消耗更多算力,但能得到更好的结果。

即便在大语言模型领域,这个思路也早已存在。不过我印象中,它是去年OpenAI在o1的官宣博文《用大语言模型学习推理》里放出一张推理缩放与训练缩放的对比图后,才又一次彻底火了起来。

figure01

图1:在推理阶段(左)和训练阶段(右)投入更多资源,通常都能提升模型准确率。

Continue reading 【转载】提升大语言模型推理能力的推理时算力缩放分类

【转载】2025年大语言模型发展现状:进展、问题与展望

原文地址:The State Of LLMs 2025: Progress, Problems, and Predictions,by Sebastian Raschka, on 2025-12-30

2025年大语言模型发展现状:进展、问题与展望

随着 2025 年接近尾声,我想回顾一下这一年大语言模型(LLM)领域最重要的若干进展,反思当前仍然存在的局限与待解决问题,并对未来的发展方向分享几点看法。

和我每年常说的一样,2025 年对于 LLM 与 AI 领域而言是大事频发的一年,并且今年完全没有出现进展饱和或放缓的迹象。

1. 推理之年:Reasoning、RLVR 与 GRPO

我想覆盖的有趣话题很多,但不妨从 2025 年 1 月按时间顺序说起。

模型规模缩放(scaling)依然有效,但它并没有真正改变 LLM 在实际使用中的表现与体验 —— 唯一的例外是 OpenAI 刚发布的 o1,新增了推理思维链(reasoning traces)。因此,当 DeepSeek 在 2025 年 1 月发布论文(https://arxiv.org/abs/2501.12948),证明可以通过强化学习培养出类推理行为时,整个领域为之震动。(在 LLM 语境中,reasoning(推理)指模型会解释其答案,而这种解释过程本身往往能提升答案的准确率。)

figure01

图 1:简短回答与包含中间推导步骤的长回答 —— 推理模型的典型输出形式

1.1 DeepSeek 时刻

DeepSeek R1 引发广泛关注有多重原因:
第一,DeepSeek R1 以 open‑weight(开放权重)模型形式发布,性能表现十分出色,在当时足以比肩最顶尖的 proprietary models(闭源模型)(ChatGPT、Gemini 等)。

第二,DeepSeek R1 的论文促使许多人 —— 尤其是投资者与记者 —— 重新审视 2024 年 12 月发布的更早一篇论文(https://arxiv.org/abs/2412.19437)。人们由此得出了一个修正结论:尽管训练顶尖模型成本依然高昂,但可能比之前设想的低一个数量级,估算更接近 500 万美元,而非 5000 万或 5 亿美元。

figure02

图 2:摘自论文https://arxiv.org/abs/2412.19437的表格,估算训练 671B 参数 DeepSeek V3 模型的成本

DeepSeek R1 的论文(https://static‑[content.springer.com/esm/art%3A10.1038%2Fs41586](https://content.springer.com/esm/art%3A10.1038%2Fs41586)‑025‑09422‑z/MediaObjects/41586_2025_9422_MOESM1_ESM.pdf)测算,在 DeepSeek V3 基础上训练 DeepSeek R1 模型仅需额外投入 29.4 万美元,同样远低于所有人的预期。

figure03

图 3:摘自 DeepSeek R1 论文的表格,估算在 DeepSeek V3 基础上训练 R1 模型的额外成本

当然,500 万美元的估算存在很多前提限制。比如,它只计算了最终模型训练的算力成本,没有计入研究人员薪资,以及超参数调优、实验探索相关的其他研发成本。

第三,也是最有意思的一点:这篇论文提出了 Reinforcement Learning with Verifiable Rewards(RLVR,可验证奖励强化学习),并将 GRPO 算法作为一种全新(或至少经过改进的)算法路径,用于开发所谓的推理模型,并在后训练阶段提升 LLM 能力。

figure04

图 4:强化学习的应用方式与阶段概览。本概述省略了大量细节,感兴趣的读者可以参阅我的文章《大语言模型推理模型训练现状》了解更多

在此之前,后训练方法比如 Supervised Instruction Fine‑tuning(SFT,有监督指令微调)和 Reinforcement Learning with Human Feedback(RLHF,人类反馈强化学习)—— 它们至今仍是训练管线的重要组成部分 —— 都受限于需要昂贵的人工标注回复或偏好标签。(当然,也可以用其他 LLM 合成生成这些标签,但这多少有点 “先有鸡还是先有蛋” 的问题。)

DeepSeek R1 与 RLVR 的关键意义在于,它们让我们可以在海量数据上对 LLM 进行后训练。只要有可用的算力预算,就能通过后训练阶段的算力缩放来提升模型能力、解锁新特性。

RLVR 中的 “V” 代表 “verifiable(可验证)”,意味着我们可以用确定性方法为答案标注正确性标签,而这些标签足以让 LLM 学会复杂的问题求解。(典型的应用领域是数学与代码,但这一思路也可以扩展到其他领域。)

figure05

图 5:可验证奖励的简单示例

我不想在这里过多陷入技术细节,因为这篇年度回顾还要覆盖其他方面。关于推理 LLM 与 RLVR,完全可以写出整篇文章甚至整本书。感兴趣的读者可以参考我之前的文章:
‑ 《理解推理型大语言模型》:https://magazine.sebastianraschka.com/p/understanding‑reasoning‑llms
‑ 《大语言模型推理模型训练现状》:https://magazine.sebastianraschka.com/p/the‑state‑of‑llm‑reasoning‑model‑training

总而言之,今年 LLM 发展的核心主线,本质上就是采用 RLVR 与 GRPO 的推理模型占据主导。
基本上,每一家主流的开放权重或闭源 LLM 厂商,都在 DeepSeek R1 之后推出了各自模型的推理版本(常被称为 “thinking” 版本)。

1.2 LLM 发展焦点演变

如果要我按年份简要总结 LLM 的发展焦点 —— 除了单纯的架构缩放与预训练算力提升之外 —— 我的列表如下:
‑ 2022 年:RLHF + PPO
‑ 2023 年:LoRA + SFT
‑ 2024 年:Mid‑Training(中期训练)
‑ 2025 年:RLVR + GRPO

预训练始终是一切的基础。此外,RLHF(通过 PPO 算法)正是 2022 年催生初代 ChatGPT 的核心技术。

2023 年,行业重点大量放在 LoRA 及类 LoRA 的参数高效微调技术上,用于训练小型定制 LLM。

figure06

图 6:历年闭源与开放权重 LLM 研发的部分焦点领域。注:这是累计叠加的关系,例如 RLHF + PPO 至今仍在使用,只是不再是最热门的讨论话题

到了 2024 年,所有主流实验室都开始优化其(预)训练管线,手段包括合成数据、优化数据配比、使用领域专属数据,以及加入专门的长上下文训练阶段。我在 2024 年的文章中总结过这些方法(当时我将它们归为预训练技术,因为 “中期训练” 这个说法还没出现):
当时我将这些视为预训练技术,因为它们使用的是同样的预训练算法与目标。如今,这些在通用数据常规预训练之后进行的、更具针对性的预训练阶段,通常被称为 “中期训练”—— 作为常规预训练与后训练(包括 SFT、RLHF,以及现在的 RLVR)之间的桥梁。

那么你可能会问,接下来会是什么?
我认为明年我们会看到 RLVR 得到更多拓展应用。目前,RLVR 主要应用于数学与代码领域。

下一个合理的方向,是不只用最终答案的正确性作为奖励信号,还要在 RLVR 训练中对 LLM 的解释过程进行评分。这种做法早已有之,多年来一直以 Process Reward Models(PRM,过程奖励模型)的研究方向存在。不过它至今尚未取得特别大的成功。例如,DeepSeek R1 论文中提到:

4.2 未成功的尝试
…… 总而言之,尽管 PRM 在重排模型生成的 Top‑N 回复、或辅助引导搜索方面表现不错(Snell 等人,2024),但在我们的实验中,相比于其在大规模强化学习过程中引入的额外计算开销,它带来的优势十分有限。

不过,从上个月发布的 DeepSeekMath‑V2 论文(我在上一篇文章中讨论过:https://magazine.sebastianraschka.com/p/technical‑deepseek)来看,我认为未来我们会看到更多 “解释评分” 作为训练信号的应用。

目前对解释的评分需要用到第二个 LLM。这也引出了我所观察到的 RLVR 的另一个发展方向:向数学与代码之外的其他领域拓展。

所以,如果现在问我 2026 与 2027 年的发展方向,我的判断是:
‑ 2026 年:RLVR 领域拓展 + 更多 inference‑time scaling(推理时缩放)
‑ 2027 年:Continual learning(持续学习)

除了上述 RLVR 的拓展,我认为 2026 年会更关注推理时缩放。推理时缩放指的是:训练完成后,在 LLM 生成答案时投入更多时间与算力,从而大幅提升效果。

推理缩放并不是新范式,LLM 平台其实早已在底层使用了相关技术。它是延迟、成本与回复准确率之间的权衡。不过在某些应用场景中,当准确率比延迟和成本更重要时,极致的推理缩放完全物有所值。例如,近期一篇论文(https://arxiv.org/html/2511.22570v1)显示,该方法让模型在一项高难度数学竞赛基准上达到了金牌水平。

figure07

图 7:两种推理时缩放方法的结合:自一致性(self‑consistency)与自我精炼(self‑refinement)。增加自我精炼迭代次数可提升准确率。改绘自论文https://arxiv.org/html/2511.22570v1。自一致性与自我精炼在我的书《Build A Reasoning Model (From Scratch)》的第 4、5 章中有详细讲解

今年业内也大量讨论了持续学习。简而言之,持续学习是指让模型在新数据或新知识上训练,而无需从头重新训练。

这并不是新概念,我也好奇今年为何它被频繁提及 —— 因为目前持续学习领域还没有出现全新的、实质性的突破。持续学习的核心挑战是 catastrophic forgetting(灾难性遗忘):正如持续预训练的实验所示,学习新知识意味着 LLM 会在一定程度上遗忘旧知识。

尽管如此,既然这一话题如此火热,我确实预计未来几年会在缓解灾难性遗忘、推动持续学习方法发展方面取得更多进展。

2. GRPO:年度研究宠儿

近年来,在 LLM 训练成本高昂的背景下,学术研究多少有些受限。当然,即便预算有限,学术界依然能做出成为主流、成为 LLM 进步关键支柱的重要发现与突破。

近年典型的例子包括 LoRA(https://arxiv.org/abs/2106.09685,2021 年)及相关的参数高效微调方法。

figure08

图 8:基于代码的 LoRA 入门示例,来自代码仓库https://github.com/rasbt/LLMs‑from‑scratch/blob/main/appendix‑E/01_main‑chapter‑code/appendix‑E.ipynb

另一个例子是 DPO(https://arxiv.org/abs/2305.18290)及相关的无奖励模型对齐方法,作为人类反馈强化学习的替代方案。

figure09

图 9:基于代码的 DPO 入门示例,来自代码仓库https://github.com/rasbt/LLMs‑from‑scratch/blob/main/ch07/04_preference‑tuning‑with‑dpo/dpo‑from‑scratch.ipynb

在我的观察范围内,今年的研究亮点当属 GRPO。尽管它是在 DeepSeek R1 论文中提出、并非起源于学术界,但它依然让研究者们度过了激动人心的一年:RLVR 与 GRPO 在概念上都富有洞见,并且根据规模不同,实验成本并非高不可攀。

因此,今年我在 LLM 研究文献中看到了许多针对 GRPO 的数学改进(来自企业与学术研究者双方),这些改进后来都被顶尖 LLM 的训练管线所采纳。例如,部分改进包括:

出自论文https://arxiv.org/abs/2512.13961
‑ 零梯度信号过滤(出自 DAPO 论文:https://arxiv.org/abs/2503.14476
‑ 主动采样(出自 DAPO 论文)
‑ Token 级损失(出自 DAPO 论文)
‑ 无 KL 散度损失(出自 DAPO 论文与 Dr. GRPO 论文:https://arxiv.org/abs/2503.20783
‑ 高位裁剪(出自 DAPO 论文)
‑ 截断重要性采样(https://fengyao.notion.site/off‑policy‑rl)
‑ 无标准差归一化(出自 Dr. GRPO 论文)

出自论文https://arxiv.org/abs/2512.02556
‑ KL 调优,搭配领域专属 KL 强度(数学领域为 0)
‑ 重加权 KL
‑ 离策略序列掩码
‑ 保留 Top‑p/Top‑k 采样掩码
‑ 保留原始 GRPO 优势归一化

我可以证实,这些 GRPO 技巧或改进在实践中效果非常显著。比如,采用其中部分或多项改进后,糟糕的参数更新不再会破坏我的训练进程,我也不再需要定期重载检查点。

即便对于非常短的训练跑,我也观察到采用这些技巧后收益明显。

figure10

图 10:我从零实现的 GRPO 训练代码的小部分结果截图,代码位于https://github.com/rasbt/reasoning‑from‑scratch/tree/main/ch06/02_rlvr_grpo_scripts_original

总之,我的 reasoning‑from‑scratch 代码库(https://github.com/rasbt/reasoning‑from‑scratch)里有一个基础版 GRPO 实现脚本,大家可以拿去把玩。(我很快会补充更多对应各改进版的消融实验。)

3. LLM 架构:分岔路口?

在架构层面,顶尖模型依然采用经典的 decoder‑style transformer(解码器式 Transformer)。不过今年,开放权重 LLM 基本都趋同于采用 Mixture‑of‑Experts(MoE,混合专家)层,以及至少一种 “效率优化” 的注意力机制:Grouped‑query attention(分组查询注意力)、sliding‑window attention(滑动窗口注意力)或 multi‑head latent attention(多头潜注意力)。

除了这些相当标准的 LLM 架构之外,我们也看到了针对注意力机制的更激进效率优化,目标是让注意力复杂度随序列长度线性增长。例子包括 Qwen3‑Next 与 Kimi Linear 中的 Gated DeltaNets(门控 DeltaNet),以及 NVIDIA Nemotron 3 中的 Mamba‑2 层。

总之,我不想在这里展开太多细节,因为我有一篇长达 1.3 万字、近期刚更新的专门文章讨论这些架构,想深入了解的可以看这里:《大语言模型架构大对比》(https://magazine.sebastianraschka.com/p/the‑big‑llm‑architecture‑comparison)。

figure11

图 11:《大语言模型架构大对比》全文导读图,文章地址:https://magazine.sebastianraschka.com/p/the‑big‑llm‑architecture‑comparison

我的预测是,至少在未来几年内,就顶尖建模性能而言,我们会继续沿用 Transformer 架构。

同时我也认为,我们会看到越来越多类似 Gated DeltaNet 和 Mamba 层的效率与工程优化。因为从 LLM 训练、部署与使用的规模来看,对于仍在投入大量资金提供 LLM 服务的企业而言,这从财务角度而言完全合理。

这并不意味着没有其他替代路线。比如我在《超越标准大语言模型》(https://magazine.sebastianraschka.com/p/beyond‑standard‑llms)一文中写过,text diffusion models(文本扩散模型)就是一个有意思的方向。目前它们还属于实验性研究模型范畴,但 DeepMind 即将推出 Gemini Diffusion 模型。它在建模质量上还无法与顶尖产品媲美,但在低延迟需求场景(比如代码补全)中会非常快、很有吸引力。

另外,两周前开放权重的 LLaDA2.0(https://github.com/inclusionAI/LLaDA2.0)发布了。其中最大的版本参数量达 100B,是目前最大的文本扩散模型,性能与 Qwen3 30B 相当。(没错,它没有整体刷新顶尖水平,但在扩散模型领域依然是值得关注的进展。)

4. 同样重要的一年:推理时缩放与工具调用

通过训练数据与架构缩放来提升 LLM,是一条久经考验且依然有效的路径。但尤其在今年,它不再是 “唯一” 的有效配方。

我们从 GPT 4.5(2025 年 2 月)身上看到了这一点 —— 有传言称它的规模远大于 GPT 4(以及后来发布的 GPT 5),而单纯的规模提升通常并不是性价比最高的前进方向。GPT 4.5 的能力或许强于 GPT 4,但增加的训练预算被认为 “投入产出比不佳”。

取而代之,更优的训练管线(更聚焦中期与后训练)以及推理缩放,是今年大部分进展的核心驱动力。

比如之前提到的、取得金牌数学水平的 DeepSeekMath‑V2,推理缩放就是我们可以拉动的杠杆之一,让 LLM 按需解决极其复杂的任务(GPT Heavy Thinking 或 Pro 是其他例子;当然不可能所有场景都用这些模式,因为延迟与成本很高,但在某些场景下 —— 比如高难度数学或编程问题 —— 高强度的推理缩放非常值得。)

另一大进步来自:在训练 LLM 时就将 tool use(工具调用)纳入考量。众所周知,hallucinations(幻觉)是 LLM 最大的问题之一。可以说幻觉率一直在持续下降,而我认为这很大程度上归功于工具调用。比如,当被问及 1998 年 FIFA 世界杯冠军是谁时,LLM 不需要强行记忆,而是可以通过工具调用传统搜索引擎,从该主题的可信网站(比如本例中的 FIFA 官网)抓取并筛选信息。数学题可以调用计算器 API,诸如此类。

例如,OpenAI 的 gpt‑oss 系列模型,就是今年较早发布的、专门围绕工具调用设计的开放权重模型之一。

figure12

图 12:摘自论文https://arxiv.org/abs/2508.10925的标注表格

遗憾的是,开源生态还没有完全跟上这一步伐,很多(甚至大多数)工具默认还是以非工具调用模式运行这些 LLM。原因之一是这是一个较新的、仍在演进的范式,配套工具需要适配。另一个原因是这个问题本身难度更高 —— 安全层面的考量:赋予 LLM 不受限制的工具调用权限,可能存在安全风险,或者对你的系统造成其他破坏。我认为始终值得一问的是:你会放心让一个新来的实习生拥有这么高的系统权限吗?

我确实认为,未来几年,在本地使用 LLM 时启用工具调用会变得越来越普遍。

5. 年度关键词:Benchmaxxing

如果要我选一个词或趋势来描述今年的 LLM 发展,那就是 “benchmaxxing”。

这里的 benchmaxxing,指的是行业高度聚焦于拉升排行榜分数,有时甚至到了基准测试成绩本身成了目标,而非通用能力代理指标的地步。

一个典型例子是 Llama 4,它在众多成熟基准上得分极高。然而当用户与开发者拿到手之后,发现这些分数并不能反映真实世界的能力与实用性。

常言道:如果测试集是公开的,那它就称不上真正的测试集。而如今的问题是,测试集数据不仅(有意或无意地)被纳入了训练语料,甚至在 LLM 开发过程中还会被直接针对性优化。

早年,即便公开测试集上的基准分数有水分,至少模型排名还基本保持不变。比如 2019 年论文《Do ImageNet Classifiers Generalize to ImageNet?》(https://arxiv.org/abs/1902.10811)中的图示。

figure13

图 13:改绘自 2019 年论文https://arxiv.org/abs/1902.10811的图示

在 LLM 发展中,这一问题已经严重到基准分数不再是模型性能可信指标的地步。

不过我仍然认为,基准是 LLM 必须跨过的必要门槛。也就是说,如果我看到某个 LLM 在基准 Y 上得分低于 X,我就知道它不是一个好模型。但如果它在基准 Y 上得分高于 X,并不代表它就比另一个同样超过 X 的模型好很多。

另一个需要考虑的维度是:图像分类器只有一个任务,就是分类图像。但 LLM 要用于各种各样的任务:文本翻译、文本摘要、写代码、头脑风暴、解数学题等等。评估图像分类器有明确的指标比如分类准确率,而评估 LLM 既要做确定性任务、也要做自由形式任务,要复杂得多。

除了实际使用 LLM、不断生成新基准之外,很遗憾这个问题没有完美解。

顺便说一句,如果你想了解 LLM 评估的主要类别,可能会喜欢我的文章《理解 LLM 评估的四大主流方法(从零实现)》:
https://magazine.sebastianraschka.com/p/llm‑evaluation‑4‑approaches

6. AI 在编程、写作与研究中的价值

因为这个话题经常被提起,我想分享一下我对 “LLM 会不会在某些任务(甚至工作)上取代人类” 的看法。

从宏观层面,我将 LLM 视为赋予特定职业人群 “超能力” 的工具。我的意思是,用好 LLM 可以大幅提升个人生产力,消除日常工作中的大量摩擦。小到确保章节标题大小写一致这种相对琐碎的事,大到在大型代码库中找出复杂 bug。

6.1 编程

时至今日,我在乎的代码大部分还是自己写。所谓 “在乎”,是指在那些我必须理解代码、确保代码正确的场景里。比如搭建 LLM 训练脚本时,我会自己实现并仔细检查训练逻辑。一来确保它按我预想的运行,二来保留我在这项任务中的知识与专业能力。不过现在我会用 LLM 来写周边更琐碎的代码,比如加上命令行 argparse 模板,这样我就能更方便地在命令行使用自己的代码。

figure14

图 14:用提示词 “为 training‑script.py 添加所有超参数选项的 argparse 命令行解析” 生成的代码示例

但我也越来越多地依赖 LLM 来发现问题、提出改进建议,或者对想法做合理性检查。同时,我希望理解自己在构建的东西,而我的个人目标是深化知识与技能,持续提升专业能力。

与此同时,LLM 对于我核心专业领域之外的任务极具价值。它让我能把那些不然没时间没精力做的事自动化。一个例子是我最近写的一个工具,用来把我的 Substack 文章提取并备份为 Markdown。(我所有内容都用 Markdown 起草,但经常直接在 Substack 编辑器里编辑扩展,所以本地草稿不总是最新的。)LLM 还帮我清理了网站上的 CSS—— 那些代码积累了多年的重复与不一致。今年还有很多类似的场景,我都用到了 LLM。

简而言之,我认为关键在于知道什么时候该用 LLM、什么时候不该用。以及如何使用 LLM,既能帮你提升专业能力,又能获得满足感。

6.2 代码库与代码生态

LLM 写代码的能力越来越强,但尽管我听到其他人有不同说法,我不认为代码会变得可有可无、会被淘汰。LLM 赋予人们 “超能力”,可以生成某些原本要耗费大量精力的编程项目。

但是,纯由 LLM 生成的代码库,取代不了专家精心打造的代码库。这些专家代码库甚至可能就是程序员自己借助 LLM 创建的。但重点是:有领域专长的人投入了大量时间精力去创建、测试、打磨它。其他人要复刻需要付出大量工作,所以既然已经存在了,为什么不直接采用?

简而言之,我认为一个精通全栈 Web 开发、深谙优秀设计模式与权衡、职业生涯中研究过、见过、搭建过大量平台的专家,肯定比一个随便给 LLM 发提示的人搭出来的平台更好。

厉害的地方在于,普通人现在也能搭建平台了,即便不是最好的。但光靠提示 LLM,能达到的高度有限,平台质量可能会遇到瓶颈。所以如果这个人真的想提升平台,最好深入学习,看看别人是怎么搭建的,带着更多知识回来,再用 LLM 更有效地指导和改进平台设计。

6.3 技术写作与研究

和编程类似,我不认为 LLM 会让技术写作过时。写一本好的技术书需要数千小时,以及对主题的深刻熟悉。这个过程中可以用 LLM 来提升清晰度、检查技术正确性、探索替代方案,或者跑小型实验,但核心工作依然依赖人类的判断与专业能力。

figure15

图 15:一个真实场景示例:LLM 帮我发现并修正了前一篇文章中的一处错误

没错,LLM 可以让技术书变得更好。它能帮作者发现错误、扩充参考文献,总体减少花在琐碎事务上的时间。这就把更多时间解放出来,留给真正需要创造力与经验的深度工作。

从读者的角度,我也不认为 LLM 能取代技术写作。用 LLM 学习某个主题,对于快速提问和入门级解释很有效。但当你想要建立更深入的理解时,这种方法很快就会变得混乱。

这时候,与其自己花好几个小时去筛选 LLM 关于某个你还不熟悉主题的回复,通常更合理的做法是跟随专家设计的结构化学习路径。(这位专家可能用了 LLM,也可能没用。)

当然,在上课或读书的过程中,用 LLM 来澄清问题、探索旁支知识点依然非常合理。用它来设计测验或练习题来巩固知识也很棒。

总体而言,我认为 LLM 对作者和读者都是净收益。

但我也认为,这里的诀窍依然是学会什么时候该用 LLM、什么时候不该用。比如,主要的坏处是,当话题变难时,人们很容易立刻就去求助 LLM,但自己先啃一啃难题,往往能带来更扎实的学习效果。

我看研究也是同理。LLM 在查找相关文献、发现数学公式问题、建议后续实验方面非常有用。但让人类研究者坐在主导位置上,依然很有必要。

或许这里的经验法则大概是这样的:
‑ 如果这篇(研究)文章或书完全由人类写成,它本可以被进一步优化。
‑ 如果这篇(研究)文章或书光靠提示 LLM 就能生成,那它可能不够有新意,也不够有深度。

6.4 LLM 与职业倦怠

LLM 还相当新,仍在快速发展,我认为过度使用 LLM 还有一个较少被讨论的坏处。比如,我觉得如果所有执行工作都由模型完成,人类主要负责监督,工作会开始变得空洞。

当然,有些人真心喜欢专注于管理系统、协调工作流,这完全是合理的偏好。但对于喜欢亲手做事的人来说,我认为这种工作模式会加速倦怠。(尤其是那些因为有了 LLM 就要求更快出成果的公司,这种情况可能更明显。)

苦苦攻克一个难题,最终看到它跑通,会带来一种特别的满足感。如果 LLM 一下就给出答案,我完全得不到同样的感觉。我猜这和做饭有点像(只是打个比方,我不是大厨)。如果你喜欢做披萨,用现成的饼胚只加配料,可能会剥夺大部分乐趣,做饭就变成了达成目的的手段。这不一定不好,但我想如果你成年累月每天都做这份工作,持续几个月几年,很容易觉得空虚,最终导致倦怠。

所以一个有点 “自私” 的视角是:写代码也比读代码更有乐趣。你可能也同意,提交拉取请求通常比评审拉取请求更有意思(当然,这不是对所有人都成立)。

或许,关于我们该如何可持续地使用 AI,一个理想的(虽不完美的)类比是国际象棋。

国际象棋引擎几十年前就超过了人类棋手,但职业棋手对弈依然活跃且蓬勃发展。我不是国际象棋专家,但我认为这项运动甚至变得更丰富、更有意思了。

据我所知(比如卡斯帕罗夫的《深度思考》一书,还有马格努斯・卡尔森参与的播客),现代棋手会用 AI 探索不同思路、挑战自己的直觉、深度分析失误,达到了以前根本不可能的深度。

我认为,对于其他形式的智力工作,这是一个很有参考价值的模式。用得好,AI 可以加速学习,拓展一个人能合理承担的范围。我们应该更多把它当作伙伴,而非替代品。

但我也认为,如果用 AI 把思考和编程完全外包出去,会有损害积极性与长期技能发展的风险。

7. 前沿壁垒:私有数据

LLM 的通用编程、知识问答与写作能力在持续提升。这很大程度上是因为,训练管线与范式(比如 RLVR)的改进,以及推理缩放与工具调用的发展,让规模缩放依然能带来正向的投资回报。

然而,除非我们不断发明新的训练方法和 / 或架构,这种进步迟早会进入平台期(类似我们在 GPT 4 到 GPT 4.5 发展中看到的情况)—— 目前没人知道新方法新架构会是什么样子。

LLM 目前已经能解决很多通用任务和那些相对容易的 “低垂果实”。但要在特定行业深耕,还需要更多领域专业化。我认为 LLM 厂商都非常渴望拿到高质量的领域专属数据。就目前来看,这依然是个挑战。

比如,据称多数被接触的公司都拒绝了这类交易,恰恰因为这些数据是专有的,是其业务差异化的核心。(我从多个渠道听到过这一点,而且还有一篇相关报道:https://www.theinformation.com/articles/openai‑anthropic‑discuss‑data‑deals‑biotech‑companies)

在我看来,这完全合乎逻辑。我认为,把宝贵的专有数据卖给 OpenAI 或 Anthropic,可能有点短视 —— 这些数据未来可能成为企业的竞争优势。

figure16

图 16:可用于训练领域专属 LLM 的行业与数据类型示例(说明:仅为举例,不构成法律建议。可以想见,如果是运行在公司安全服务器内部的本地 LLM,用患者健康数据训练模型,和开发其他处理同类患者数据的内部软件没有本质区别)

目前,大规模 LLM 开发成本极高、难度极大,这也是为什么只有少数几家大公司在开发顶尖 LLM。但我认为 LLM 开发正变得越来越商品化:随着 LLM 研发人员频繁跳槽,最终会有更多大型金融机构、生物科技公司以及其他有预算的企业,开发具备竞争力的内部 LLM,从自有私有数据中获益。

这些 LLM 甚至完全不需要从头训练;DeepSeek V3.2、Kimi K2、GLM 4.7 等众多顶尖 LLM 都已经开放发布,可以基于它们做适配与进一步后训练。

8. 从零构建 LLM 与推理模型

你可能好奇我今年都在忙什么。我的精力几乎全部放在了 LLM 相关的工作上。去年我决定独立出来创办自己的公司,主要是为了有更多时间做自己的研究、写书、运营 Substack 专栏,以及开展行业合作。

作为一名独立研究者,咨询项目是我维持这套模式的收入来源之一。这不仅覆盖日常开销(从食品杂货到医保),也包括那些不太显眼的成本,比如做实验的云算力费用。

长期来看,我的目标是进一步减少咨询工作,把更多时间花在长篇研究与写作上,尤其是我在这里分享的技术深度解析内容。

我很幸运,已经有很多公司向我伸出橄榄枝,邀请我加入全职岗位 —— 如果独立发展不顺利,这也是可行的选择。但就目前而言,我打算继续保持独立。

如果你觉得我的内容有用,并且力所能及的话,订阅我的 Substack 或者买一本我的书,真的能帮我维持这类创作,我由衷感谢你的支持。

《Ahead of AI》是读者支持的出版物。想要收到新文章并支持我的工作,可以考虑成为免费或付费订阅者。

我的年度个人亮点

今年我个人的一大亮点,是我的书《Build A Large Language Model (From Scratch)》(https://amzn.to/4fqvn0D)收到了非常多正面反馈。我收到了来自全球各地企业与高校读者的大量 thoughtful 留言。

这些反馈覆盖了广泛的使用场景:从大学教授将这本书作为主讲教材,教授 LLM 工作原理;到毕业生用它准备面试、拿下新岗位;再到工程师以它为跳板,在生产环境中实现定制 LLM。

我也很开心地得知,这本书目前已经被翻译成至少 9 种语言。

figure18

图 18:《Build A Large Language Model (From Scratch)》已被翻译成多种语言

很多读者还问会不会出第二版,覆盖更新、更前沿的主题。我确实考虑过,但我很谨慎,不想让这本书的入门门槛变得太高。比如,用 DeepSeek 等新模型采用的多头潜注意力之类更复杂的变体,取代标准的多头注意力,会大幅提升学习门槛。

所以目前我更倾向于保持这本书原貌,因为它对想入门 LLM 的人来说非常友好。而对于想了解更进阶内容的读者,我今年在这本书的 GitHub 仓库(https://github.com/rasbt/LLMs‑from‑scratch)里补充了大量额外资料。我计划未来继续扩充这些内容。

figure19

图 19:今年我在https://github.com/rasbt/LLMs‑from‑scratch 仓库中新增的部分补充材料截图

此外,大家可能知道,我目前正在写续作《Build A Reasoning Model (From Scratch)》(https://mng.bz/Nwr7)。
第一本书《Build A Large Language Model (From Scratch)》(https://mng.bz/M96o)聚焦于大语言模型核心架构与预训练基础。

这本推理模型的书,则承接上一本书的内容,从预训练好的基础模型开始,探索专门用于提升推理能力的推理时缩放方法与强化学习技术。

figure20

图 20:两本 “从零实现” 系列图书的内容关系示意

除了运营 Substack,我正全力投入这本推理书的写作。在很多方面,我认为这是我迄今为止构思最缜密、打磨最精细的一本书。

figure21

图 21:《Build A Reasoning Model (From Scratch)》内容节选,书籍地址:https://mng.bz/Nwr7

目前我估计,每写一章我要花 75 到 120 小时。如果你好奇的话,大致的时间分配如下:
‑ 3‑5 小时:头脑风暴与修订主题选择
‑ 5‑10 小时:搭建内容结构
‑ 20 小时:编写初始代码
‑ 10‑20 小时:补充实验、研读最新文献以获取更多洞见
‑ 10‑20 小时:制作图表
‑ 10 小时:撰写初稿文本
‑ 10‑20 小时:重写与润色章节
‑ 5‑10 小时:设计习题并运行实验
‑ 2‑5 小时:吸收编辑与读者建议

目前我写到了第 6 章,内容是实现用于训练推理模型的可验证奖励强化学习(GRPO)代码。

figure22

图 22:第 6、7 章可验证奖励强化学习相关实验的早期结果

写这本书非常辛苦,但我乐在其中!希望你和其他读者会觉得它像《Build A Large Language Model (From Scratch)》一样实用。

9. 2025 年的意外与 2026 年展望

我想用一些核心要点来收尾这篇文章,聚焦于那些我觉得有点意外的发展,以及我对 2026 年的预测。

9.1 2025 年值得关注的意外事件

先说说 2025 年的意外之处。如果一年前(2024 年)你问我,这些进展我大概率不会预料到:

  1. 多款推理模型已经在大型数学竞赛中达到人类金牌水平:包括 OpenAI 的未命名模型、Google DeepMind 的 Gemini Deep Think,以及开放权重模型 DeepSeekMath‑V2。总体方向我并不意外,但我没想到 2025 年就实现了,原以为要到 2026 年。

  2. Llama 4(或者说整个 Llama 系列)在开放权重社区几乎彻底失宠,Qwen 的受欢迎程度已经超过 Llama(以下载量与衍生模型数量衡量,数据来自 Nathan Lambert 的 ATOM 项目报告:https://www.atomproject.ai/)。

  3. Mistral AI 在 2025 年 12 月发布的最新旗舰 Mistral 3 模型,采用了 DeepSeek 架构。

  4. 除了 Qwen3 与 DeepSeek R1/V3.2 之外,顶尖开放权重模型赛道还涌现出了众多竞争者,包括 Kimi、GLM、MiniMax、零一万物(Yi)等。

  5. 更便宜、高效的混合架构已经成为头部实验室的更优先方向,而非由零散实验室各自开发。

  6. OpenAI 发布了开放权重模型(gpt‑oss),我今年早些时候也专门写过文章分析。

  7. 模型上下文协议(Model Context Protocol, MCP)已经成为 Agent 式 LLM 系统中工具与数据访问的事实标准(至少目前是);我原本以为 2025 年生态会更碎片化,至少要到 2026 年才会统一。

9.2 2026 年预测

  1. 我们很可能会看到面向消费级的行业级扩散模型,主打低成本、可靠、低延迟推理,Gemini Diffusion 大概率会率先落地。

  2. 开放权重社区将稳步普及具备本地工具调用能力的 LLM,Agent 能力也会越来越强。

  3. RLVR 将更广泛地拓展到数学与代码之外的其他领域(比如化学、生物等)。

  4. 传统 RAG 作为文档查询默认方案的地位将逐渐下降。开发者不会每次文档查询都走检索流程,而是更多依赖更好的长上下文处理能力 —— 尤其是随着更优秀的 “小尺寸” 开放权重模型出现。

  5. LLM 基准与性能的大量提升,将来自工具链优化与推理时缩放,而非来自训练或核心模型本身。看起来 LLM 会变得强很多,但这主要是因为周边应用在进步。与此同时,开发者会更专注于降低延迟,在不需要的场景减少推理模型的思维 token 消耗。

别误会,2026 年依然会推动顶尖水平进一步提升,但今年进步的权重将更多来自推理端,而非单纯的训练端。

总而言之,我认为如果说 2025 年有什么元教训的话,那就是 LLM 的进步很少来自单一突破,而是通过多个独立的抓手在多条战线上齐头并进。这包括架构微调、数据质量提升、推理训练、推理缩放、工具调用等等。

同时,评估依然困难,基准并不完美,关于何时以及如何使用这些系统,良好的判断力依然至关重要。

我对 2026 年的期望是,我们能继续看到有意思的进步,同时也能理解这些进步究竟来自哪里。这既需要更好、更一致的基准测试方法,当然也需要透明度。

感谢你的阅读,也感谢这一年来在评论区、各个平台(从 Substack Notes 到 GitHub)所有 thoughtful 的反馈与讨论。

这些正面反馈与深入交流,真的激励着我投入时间与精力去写长篇文章,去深入钻研 LLM 研究与实现细节。我从这些交流中学到了很多,希望你也一样。

我非常期待 2026 年领域继续演进,我们继续交流!

祝好,
Sebastian

figure23

10. 附录:2025 年 7‑12 月精选 LLM 研究论文列表

6 月的时候,我曾向付费订阅者分享过一篇精选收藏的研究论文清单(上半年),正是这些订阅者让这个 Substack 得以运营。

类似地,作为对所有支持者的感谢,我整理了一份 2025 年 7 月到 12 月我收藏并分类的所有有意思的研究论文清单。我浏览了这些论文的摘要,但只精读了其中很小一部分。不过我依然喜欢收集整理这些清单,因为做项目的时候经常会回头查阅。

不过鉴于这篇文章已经很长了,我把这份清单放在另一篇文章里,链接如下:
《2025 年 LLM 研究论文精选(下)》:
figure24
https://magazine.sebastianraschka.com/p/llm‑research‑papers‑2025‑part2

感谢你订阅我的《Ahead of AI》博客,也感谢你今年对我工作的支持。我真的非常感激。你的支持让这份工作得以切实可行,也让我能够持续投入时间,去写作、实验、深入思考这些话题!

【转载】大语言模型研究论文:2025年下半年精选(7-12月)

原文地址:LLM Research Papers: The 2025 List (July to December),by Sebastian Raschka, on 2025-12-30

大语言模型研究论文:2025年下半年精选(7-12月)

今年 6 月,我曾向付费订阅用户分享过一篇附赠文章,整理了我收藏标记的研究论文清单 —— 正是这些订阅者支撑着这个 Substack 专栏的运营。

本着同样的心意,为了感谢所有热心支持者,我整理了 2025 年 7 月至 12 月期间我标记归档的优质研究论文,清单如下。

这些论文我都通读了摘要,但真正全文精读的只有极少一部分。不过我依然坚持整理这类分类清单,因为在开展具体项目时,我常常会回头查阅这些资料。

顺便一提,我同时也在撰写年度大语言模型综述文章《2025 年大语言模型发展现状:进展、问题与展望》,今天也同步发布了。大家可以通过以下链接查看:

《2025 年大语言模型发展现状:进展、问题与展望》

原本我打算把这份论文清单放进上面这篇综述里,但文章篇幅已经过长,因此决定单独成篇分享。希望大家不介意今天收到两封推送邮件。我的考虑是,拆分后两篇文章都更便于阅读、快速浏览和日后回顾,不用在超长的页面里费力查找。

本次论文清单分为以下类别(大家可以在网页版文章的目录中直接跳转对应章节):

  • 推理模型

    • 1a. 推理模型训练

    • 1b. 推理阶段推理策略

    • 1c. 大语言模型评估与推理解析

  • 大语言模型的其他强化学习方法

  • 其他推理阶段扩展方法

  • 模型发布 / 技术报告

  • 模型架构

  • 高效训练

  • 基于扩散的语言模型

  • 多模态与视觉 – 语言模型

  • 数据与预训练数据集


Continue reading 【转载】大语言模型研究论文:2025年下半年精选(7-12月)

【转载】从DeepSeek V3到V3.2:架构、稀疏注意力与强化学习更新

原文地址:From DeepSeek V3 to V3.2: Architecture, Sparse Attention, and RL Updates,by Sebastian Raschka, on 2025-12-03, updated on 2026-01-01

从DeepSeek V3到V3.2:架构、稀疏注意力与强化学习更新

解读 DeepSeek 旗舰开源权重模型的演进之路

与 DeepSeek V3 的发布节奏类似,团队选择在美国一个重要假期的周末推出了这款全新旗舰模型。DeepSeek V3.2 的性能达到了 GPT-5 与 Gemini 3.0 Pro 的级别,同时还是一款开源权重模型,绝对值得深入研究。

figure01

图 1:DeepSeek V3.2 与闭源旗舰模型的基准测试对比。本图为 DeepSeek V3.2 报告的标注版插图。

我曾在《LLM 架构大盘点》一文的开篇详细介绍过其前身 DeepSeek V3,过去几个月里,随着新架构不断发布,我也一直在持续更新这篇文章。原本刚和家人过完感恩节假期回来,我只打算给这篇文章新增一个小节,补充 DeepSeek V3.2 的相关内容,但后来发现值得探讨的亮点太多,便决定单独写一篇更完整的长文。

他们的技术报告中有大量值得挖掘的内容与经验,我们这就开始。

Continue reading 【转载】从DeepSeek V3到V3.2:架构、稀疏注意力与强化学习更新

【转载】超越标准大语言模型

原文地址:Beyond Standard LLMs,by Sebastian Raschka, on 2025-11-04

超越标准大语言模型

线性注意力混合架构、文本扩散模型、代码世界模型与小型递归Transformer

从DeepSeek R1到MiniMax-M2,如今规模最大、能力最强的开源权重大语言模型(LLM)依然是自回归解码器式Transformer,它们均基于原始多头注意力机制的各类变体构建而成。

然而近年来,我们也见证了标准LLM之外的各类替代方案不断涌现,从文本扩散模型到最新的线性注意力混合架构不一而足。其中部分方案旨在提升效率,而另一些(比如代码世界模型)则致力于优化建模性能。

几个月前我分享了《大语言模型架构大对比》一文,聚焦于主流的基于Transformer的大语言模型,之后收到了很多关于我对这些替代方案看法的提问。(我最近也在2025年PyTorch大会上做了相关主题的简短分享,当时也向参会者承诺会后续撰写一篇关于这些替代方案的文章。)于是便有了这篇内容!

figure01

图1: 大语言模型领域概览。本文介绍黑色边框标注的这些架构。解码器式Transformer已在我的《大架构对比》一文中展开介绍。其余未加框的架构将在未来的文章中探讨。

需要说明的是,上图中展示的每个主题理想情况下都至少需要一整篇文章来详细阐述(希望未来能逐一覆盖)。因此为了控制本文篇幅,很多章节的内容会相对精简。但我依然希望本文能作为一份入门导引,带大家了解近年来涌现的这些值得关注的LLM替代方案。

附言:前文提到的PyTorch大会演讲将上传至PyTorch官方YouTube频道。在此之前,如果你感兴趣,可以先看下面的练习录制版本。

(也可以直接看YouTube版本:https://youtu.be/lONyteDR4XE 。)

1. 基于Transformer的大语言模型

基于经典https://arxiv.org/abs/1706.03762架构的Transformer大语言模型,目前在文本和代码领域依然代表着最顶尖的水平。仅回顾2024年末至今的亮点,代表性模型就包括:

  • DeepSeek V3/R1

  • OLMo 2

  • Gemma 3

  • Mistral Small 3.1

  • Llama 4

  • Qwen3

  • SmolLM3

  • Kimi K2

  • gpt-oss

  • GLM-4.5

  • GLM-4.6

  • MiniMax-M2
    以及更多其他模型。

(以上列表聚焦于开源权重模型;GPT-5、Grok 4、Gemini 2.5等闭源模型也属于这一类别。)

figure02

图2: 过去一年发布的最具代表性的解码器式Transformer概览。

鉴于我已经多次谈论和撰写基于Transformer的大语言模型,我默认大家已经熟悉其基本思路和架构。如果你想了解更深入的内容,可以在我的这篇文章中对比上述(及下图展示的)所有架构:https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison

(旁注:我本可以将Qwen3-Next和Kimi Linear与概览图中的其他Transformer-状态空间模型(SSM)混合架构归为一类。在我看来,其他Transformer-SSM混合架构属于“带有Transformer组件的SSM”,而本文讨论的这些模型(Qwen3-Next和Kimi Linear)属于“带有SSM组件的Transformer”。不过,既然我已经把IBM Granite 4.0和NVIDIA Nemotron Nano 2放在了Transformer-SSM的框中,把它们归为同一大类也说得通。)

figure03

图3: 我的《大语言模型架构大对比》(https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison)一文中讨论的部分架构。

如果你正在从事大语言模型相关工作——比如搭建应用、微调模型或者尝试新算法——我会把这些模型作为首选。它们经过了充分验证,表现成熟且优异。

此外,正如《大架构对比》一文中讨论的,目前已经有很多效率优化手段,包括分组查询注意力、滑动窗口注意力、多头潜在注意力等等。

但如果研究人员和工程师不去探索替代方案,那未免太过无趣,也太过短视。因此,接下来的章节将介绍近年来涌现的一些有意思的替代方向。

2. (线性)注意力混合架构

在讨论“差异更大”的方案之前,我们先来看采用了更高效注意力机制的基于Transformer的大语言模型。具体来说,重点关注那些计算量随输入token数量线性增长、而非二次增长的方案。

最近,线性注意力机制迎来了一波复兴,用以提升大语言模型的效率。

https://arxiv.org/abs/1706.03762(2017年)中提出的注意力机制,即缩放点积注意力,至今仍是大语言模型中最主流的注意力变体。除了传统的多头注意力之外,它也被应用于更高效的变体中,比如分组查询注意力、滑动窗口注意力以及多头潜在注意力,详见:https://youtu.be/lONyteDR4XE

2.1 传统注意力与二次代价

原始注意力机制的计算量随序列长度呈二次增长:

这是因为查询(Q)、键(K)、值(V)都是n×d的矩阵,其中d是嵌入维度(一个超参数),n是序列长度(即token的数量)。

(更多细节可以参考我的文章:https://magazine.sebastianraschka.com/p/understanding-and-coding-self-attention

figure04

图4: 多头注意力中传统缩放点积注意力机制示意图;注意力的二次代价由序列长度n导致。

2.2 线性注意力

线性注意力变体其实早已存在,我记得2020年代就有大量相关论文。比如我印象中最早的一篇是2020年的https://arxiv.org/abs/2006.16236,研究人员在文中对注意力机制做了近似:

此处,ϕ(⋅)是核特征函数,取ϕ(x) = elu(x)+1。

这种近似之所以高效,是因为它避免了显式计算n×n的注意力矩阵QKᵀ。

我不想在这些早期尝试上花费太多篇幅。但核心结论是:它们将时间和内存复杂度从O(n²)降到了O(n),让长序列下的注意力效率大幅提升。

然而,这些方案从未真正普及,因为它们会降低模型精度,而且我从未见过哪一种变体被应用到开源的顶尖大语言模型中。

2.3 线性注意力的复兴

今年下半年,线性注意力变体迎来了复兴,部分模型开发者之间也出现了一些反复,如下图所示。

figure05

图5: 线性注意力混合架构概览。

第一个代表性模型是搭载闪电注意力的https://arxiv.org/abs/2506.13585。

MiniMax-M1是一个参数量4560亿的混合专家(MoE)模型,激活参数量460亿,于今年6月发布。

随后在8月,通义千问团队推出了Qwen3-Next,我在前文已经略有提及。到了9月,DeepSeek团队发布了https://huggingface.co/deepseek-ai/DeepSeek-V3.2-Exp 。(DeepSeek V3.2的稀疏注意力机制严格来说不算线性,但计算代价至少是亚二次级的,因此我认为把它和MiniMax-M1、Qwen3-Next、Kimi Linear归为同一类是合理的。)

这三个模型(MiniMax-M1、Qwen3-Next、DeepSeek V3.2)都在其大部分或全部层中,用高效的线性变体替换了传统的二次注意力。

有意思的是,最近出现了一个反转:MiniMax团队发布的全新230亿参数M2模型没有采用线性注意力,而是回归了常规注意力。团队在https://huggingface.co/blog/MiniMax-AI/why-did-m2-end-up-as-a-full-attention-model?utm_source=chatgpt.com中提到,线性注意力在生产级大语言模型中存在棘手问题。它在常规提示下表现尚可,但在推理和多轮任务中精度较差——而这些能力不仅对常规聊天场景很重要,对智能体应用同样关键。

这原本可能成为一个转折点,让线性注意力变得不再值得探索。但事情变得更有意思了:10月,Kimi团队发布了搭载线性注意力的全新https://arxiv.org/abs/2510.26692模型。

在线性注意力方面,Qwen3-Next和Kimi Linear都采用了门控DeltaNet(Gated DeltaNet),接下来几节我会将其作为混合注意力架构的一个例子展开讨论。

2.4 Qwen3-Next

我们先从Qwen3-Next说起,它用https://arxiv.org/abs/2412.06464 + https://arxiv.org/abs/2505.06708 的混合架构替换了常规注意力机制,从而在内存层面支撑了原生262k token的上下文长度(此前的235B-A22B模型原生支持32k,通过https://arxiv.org/abs/2309.00071缩放可支持131k)。

它的混合机制将门控DeltaNet模块与门控注意力模块按3:1的比例混合,如下图所示。

figure06

图6: 搭载门控注意力与门控DeltaNet的Qwen3-Next。

如上图所示,注意力机制要么实现为门控注意力,要么实现为门控DeltaNet。也就是说,该架构中的48个Transformer块(层)在二者之间交替。具体来说,如前所述,它们按3:1的比例交替。例如,Transformer块的排布如下:

──────────────────────────────────
第1层:线性注意力 → MoE
第2层:线性注意力 → MoE
第3层:线性注意力 → MoE
第4层:全注意力 → MoE
──────────────────────────────────
第5层:线性注意力 → MoE
第6层:线性注意力 → MoE
第7层:线性注意力 → MoE
第8层:全注意力 → MoE
──────────────────────────────────
……

除此之外,该架构整体相当标准,和Qwen3类似:

figure07

图7: 此前“常规版”Qwen3模型(左)与Qwen3-Next(右)对比。

那么,门控注意力和门控DeltaNet到底是什么?

2.5 门控注意力

在介绍门控DeltaNet本身之前,我们先简单聊聊门控。正如上一张图中Qwen3-Next架构的上半部分所示,Qwen3-Next采用了“门控注意力”。它本质上就是常规的全注意力,额外增加了一个Sigmoid门。

这种门控是一种简单的修改,我在一个多头注意力实现中(基于我的https://amzn.to/4fqvn0D第3章的代码)加入了该机制,用于演示:

可以看到,在按常规方式计算出注意力之后,模型从同一输入中生成一个单独的门控信号,经过Sigmoid函数将其约束在0到1之间,再与注意力输出相乘。这使得模型可以动态地放大或缩小特定特征。Qwen3-Next的开发者在https://qwen.ai/blog?id=4074cca80393150c248e508aa62983f9cb7d27cd&from=research.latest-advancements-list中提到,这有助于提升训练稳定性:

……注意力输出门控机制有助于消除注意力沉没(Attention Sink)和大幅激活(Massive Activation)等问题,保障模型全流程的数值稳定性。

简而言之,门控注意力对标准注意力的输出进行调制。下一节我们将讨论门控DeltaNet,它用一种递归的delta规则记忆更新机制替换了注意力机制本身。

2.6 门控DeltaNet

那么,什么是门控DeltaNet?门控DeltaNet(Gated Delta Network的缩写)是Qwen3-Next中的线性注意力层,旨在替代标准的Softmax注意力。它改编自前文提到的https://arxiv.org/abs/2412.06464论文。

门控DeltaNet最初是作为Mamba2的改进版本提出的,它将Mamba2的门控衰减机制与delta规则相结合。

Mamba是一种状态空间模型(Transformer的替代方案),是一个很大的主题,未来值得单独撰文介绍。

delta规则部分指的是:计算新值与预测值之间的差值(delta,Δ),用以更新作为记忆状态的隐藏状态(后文会详细展开)。

(旁注:熟悉经典机器学习文献的读者可以把它理解为类似生物学启发的赫布学习:“同步放电的神经元,连接也会同步增强。”它本质上是感知机更新规则和基于梯度下降学习的前身,但不需要监督。)

门控DeltaNet有一个和前文讨论的门控注意力类似的门,只不过它使用的是SiLU激活函数而非Logistic Sigmoid,如下图所示。(选择SiLU可能是为了相比标准Sigmoid提升梯度流动性和稳定性。)

figure08

图8: 门控注意力与门控DeltaNet对比。

然而,如上图所示,除了输出门之外,门控DeltaNet中的“门控”还指代几个额外的门:

  • α(衰减门)控制记忆随时间衰减或重置的速度

  • β(更新门)控制新输入对状态的修改强度

在代码中,上述门控DeltaNet的简化版本(不含卷积混合)可以实现为如下形式(代码灵感来自Qwen3团队的实现:https://github.com/huggingface/transformers/blob/0ed6d51ae8ed3f4fafca67a983b8d75bc76cd51b/src/transformers/models/qwen3_next/modular_qwen3_next.py#L835):

(注意:为了简洁起见,我省略了Qwen3-Next和Kimi Linear使用的卷积混合部分,让代码更易读,同时聚焦于递归特性。)

由此可见,它和标准(或门控)注意力有很多不同。

在门控注意力中,模型计算所有token之间的常规注意力(每个token都关注或查看其他所有token)。得到注意力输出后,由一个门(Sigmoid)决定保留多少输出。核心要点是:它依然是常规的缩放点积注意力,计算量随上下文长度呈二次增长。

回顾一下,缩放点积注意力的计算公式为softmax(QKᵀ)V,其中Q和K是n×d矩阵,n是输入token数量,d是嵌入维度。因此QKᵀ会得到一个n×n的注意力矩阵,再与n×d维度的值矩阵V相乘。

figure09

图9: 传统注意力机制(再次展示),其计算量随token数量n增长。

而在门控DeltaNet中,不存在n×n的注意力矩阵。相反,模型逐个处理token,维护一个持续更新的运行记忆(状态),每输入一个新token就更新一次。其实现方式为,其中S是每个时间步t都会递归更新的状态。

门控控制着记忆的变化方式:

  • α(alpha)调节需要遗忘(衰减)多少旧记忆

  • β(beta)调节当前时间步t的token对记忆的更新程度

(还有最终的输出门,上面的代码片段中没有展示,作用和门控注意力类似,控制保留多少输出。)

因此从某种意义上说,门控DeltaNet中的状态更新和循环神经网络(RNN)的工作方式类似。它的优势在于:计算量随上下文长度呈线性增长(通过for循环实现),而非二次增长。

这种递归状态更新的缺点在于,和常规(或门控)注意力相比,它牺牲了全成对注意力带来的全局上下文建模能力。

门控DeltaNet在一定程度上依然能捕捉上下文,但必须通过记忆(S)这个瓶颈。该记忆是固定大小的,因此效率更高,但它会把过去的上下文压缩成单个隐藏状态,和RNN类似。

这就是为什么Qwen3-Next和Kimi Linear架构没有把所有注意力层都替换成DeltaNet层,而是采用了前文提到的3:1比例。

2.7 DeltaNet的内存节省

上一节我们讨论了DeltaNet相比全注意力的优势:上下文长度维度下的计算复杂度是线性而非二次的。

除了线性计算复杂度之外,DeltaNet的另一大优势是内存节省——因为DeltaNet模块不会增大KV缓存。(关于KV缓存的更多信息,参见我的文章:https://magazine.sebastianraschka.com/p/coding-the-kv-cache-in-llms )相反,如前所述,它们维护一个固定大小的递归状态,因此内存不会随上下文长度变化。

对于常规的多头注意力(MHA)层,我们可以这样计算KV缓存大小:

KV_cache_MHA ≈ batch_size × n_tokens × n_heads × d_head × 2 × bytes

(乘以2是因为缓存中同时存储键和值。)

对于上面实现的简化版DeltaNet,我们有:

KV_cache_DeltaNet = batch_size × n_heads × d_head × d_head × bytes

注意,KV_cache_DeltaNet的内存大小不依赖上下文长度(n_tokens)。此外,我们只存储记忆状态S,而非分开的键和值,因此“2 × bytes”变成了“bytes”。不过要注意,这里出现了d_head × d_head的二次项,这来源于状态:

S = x.new_zeros(b, self.num_heads, self.head_dim, self.head_dim)

但这通常无需担心,因为头维度通常相对较小。比如在Qwen3-Next中是128。

带卷积混合的完整版本会稍微复杂一些,还涉及卷积核大小等因素,但上面的公式已经足以说明门控DeltaNet的核心趋势和设计动机。

figure10

图10: KV缓存大小增长对比。3:1比例指门控DeltaNet层与全注意力层的比例。计算假设emb_dim=2048,n_heads=16,n_layers=48,bf16。你可以在这里找到复现代码:https://github.com/rasbt/LLMs-from-scratch/tree/main/ch04/08_deltanet。

2.8 Kimi Linear与Qwen3-Next对比

Kimi Linear与Qwen3-Next有若干结构相似性。两个模型都依赖混合注意力策略,具体来说,都是将轻量级线性注意力与更重的全注意力层相结合。二者都采用3:1的比例——即每3个采用线性门控DeltaNet变体的Transformer块,就搭配1个使用全注意力的块,如下图所示。

figure11

图11: Qwen3-Next与Kimi Linear并排对比。

门控DeltaNet是受循环神经网络启发的线性注意力变体,包含源自https://arxiv.org/abs/2412.06464论文的门控机制。从某种意义上说,门控DeltaNet就是带有Mamba风格门控的DeltaNet,而DeltaNet本身是一种线性注意力机制(下一节会详细说明)。

如上图11右上角方框所示,Kimi Linear中的MLA没有使用Sigmoid门。这一省略是有意为之,以便作者能更直接地与标准MLA对比,但他们在https://x.com/yzhang_cs/status/1984631714464088563中表示,未来计划加入该门控。

另外要注意,上图中Kimi Linear部分省略了RoPE框也是有意的。Kimi在多头潜在注意力(MLA)层(全局注意力)中采用了NoPE(无位置嵌入)。正如作者所述,这使得MLA在推理时可以作为纯多查询注意力运行,并且避免了长上下文缩放下的RoPE重调(位置偏差据称由Kimi Delta注意力块处理)。关于MLA和多查询注意力(分组查询注意力的一种特例)的更多信息,请参见我的《大语言模型架构大对比》一文:https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison

2.9 Kimi Delta注意力

Kimi Linear通过Kimi Delta注意力(KDA)机制对Qwen3-Next的线性注意力机制做了改进,它本质上是门控DeltaNet的优化版本。Qwen3-Next使用标量门控(每个注意力头一个值)来控制记忆衰减速率,而Kimi Linear将其替换为针对每个特征维度的通道级门控。据作者称,这让记忆的可控性更强,进而提升了长上下文推理能力。

此外,在全注意力层,Kimi Linear用多头潜在注意力(MLA)替换了Qwen3-Next的门控注意力层(本质上是带输出门控的标准多头注意力层)。这和DeepSeek V3/R1使用的MLA机制是同一种(我在《大语言模型架构大对比》一文中讨论过),但额外增加了一个门。(回顾一下:MLA通过压缩键/值空间来减小KV缓存大小。)

目前没有直接和Qwen3-Next的对比,但和门控DeltaNet论文中的Gated DeltaNet-H1模型(本质上是带滑动窗口注意力的门控DeltaNet)相比,Kimi Linear在保持相同token生成速度的同时,实现了更高的建模精度。

figure12

图12: 摘自Kimi Linear论文(https://arxiv.org/abs/2510.26692)的标注图,显示Kimi Linear速度与门控DeltaNet相当,远快于多头潜在注意力架构(如DeepSeek V3/R1),同时基准测试表现更优。

此外,根据https://arxiv.org/abs/2405.04434中的消融研究,当超参数选择得当时,MLA的表现与常规全注意力相当。

而Kimi Linear在长上下文和推理基准上的表现优于MLA,这让线性注意力变体再次有望应用于更大规模的顶尖模型中。话虽如此,Kimi Linear有480亿参数,但比Kimi K2小20倍。看看Kimi团队是否会在即将推出的K3模型中采用这一方案,将会很有意思。

2.10 注意力混合架构的未来

线性注意力并非新概念,但近期混合方案的复兴表明,研究人员又开始认真探索让Transformer更高效的实用方法。比如Kimi Linear相比常规全注意力,KV缓存减少了75%,解码吞吐量最高提升6倍。

新一代线性注意力变体与早期尝试的不同之处在于:它们是与标准注意力搭配使用,而非完全取而代之。

展望未来,我预计下一波注意力混合架构将聚焦于进一步提升长上下文稳定性和推理精度,从而向全注意力的顶尖水平靠拢。

3. 文本扩散模型

与标准自回归大语言模型架构相比,更具颠覆性的一类方案是文本扩散模型家族。

你可能对扩散模型并不陌生,它基于2020年的https://arxiv.org/abs/2006.11239论文,用于图像生成(作为生成对抗网络的继任者),后来经Stable Diffusion等项目实现、规模化并普及开来。

figure13

图13: 图像扩散过程示意图,引自2022年的文章《AI前沿1:创新的扩散》(https://magazine.sebastianraschka.com/p/ahead-of-ai-1-a-diffusion-of-innovations)。图中从左到右逐步加入高斯噪声,模型的任务是学习如何去除噪声(从右到左)。

3.1 为什么要研究文本扩散?

随着2022年https://arxiv.org/abs/2205.14217论文的发表,我们开始看到研究者将扩散模型应用于文本生成的趋势萌芽。2025年我已经看到了大量文本扩散相关论文。刚翻了一下我的论文书签列表,里面居然有39个文本扩散模型!鉴于这类模型的热度日益高涨,我觉得是时候专门聊聊它们了。

figure14

图14: 本节介绍文本扩散模型。

那么,扩散模型的优势是什么?为什么研究者要将其作为传统自回归大语言模型的替代方案来研究?

传统的基于Transformer的(自回归)大语言模型一次生成一个token。为简洁起见,我们下文简称其为自回归LLM。而基于文本扩散的大语言模型(我们称之为“扩散LLM”)的核心卖点是:它们可以并行生成多个token,而非顺序生成。

注意,扩散LLM依然需要多个去噪步骤。但即便一个扩散模型需要比如64步去噪,每一步并行生成所有token,其计算效率依然高于执行2000步顺序生成来产出2000个token的回复。

3.2 去噪过程

扩散LLM中的去噪过程,与常规图像扩散模型中的去噪过程类似,如下图动图所示。(核心区别在于:文本扩散不是向像素添加高斯噪声,而是通过按概率掩码token来破坏序列。)

在这个实验中,我运行了今年早些时候发布的https://arxiv.org/abs/2502.09992(LLaDA)论文中的8B指令微调模型。

figure15

图15: 使用8B LLaDA模型的去噪过程示意图。

如上面的动画所示,文本扩散过程会逐步将[MASK] token替换为文本token,从而生成答案。如果你熟悉https://arxiv.org/abs/1810.04805和掩码语言建模,你可以把这个扩散过程理解为BERT前向传播的迭代应用(BERT在不同掩码率下使用)。

从架构上看,扩散LLM通常是解码器式Transformer,但没有因果注意力掩码。比如前面提到的LLaDA模型就使用了Llama 3架构。我们把这种没有因果掩码的架构称为“双向”架构,因为它们可以同时访问所有序列元素。(注意这和BERT架构类似,由于历史原因,BERT被称为“编码器式”。)

因此,自回归LLM和扩散LLM的主要区别(除了去掉因果掩码之外)在于训练目标。扩散LLM(如LLaDA)使用生成式扩散目标,而非下一个token预测目标。

在图像模型中,生成式扩散目标很直观,因为我们有连续的像素空间。比如,添加高斯噪声和学习去噪在数学上是很自然的操作。然而文本由离散的token组成,我们无法像连续空间那样直接添加或去除“噪声”。

因此,这些扩散LLM不是扰动像素强度,而是通过逐步随机掩码token来破坏文本——每个token都以指定概率被替换为特殊的掩码token。模型随后学习一个逆过程,在每一步预测缺失的token,从而有效地将序列“去噪”(或解掩码)还原为原始文本,如图15的动画所示。

解释其背后的数学原理更适合单独写一篇教程,但大致来说,我们可以把它看作是扩展到概率最大似然框架下的BERT。

3.3 自回归LLM vs 扩散LLM

前文提到,扩散LLM的吸引力在于它们并行生成(或去噪)token,而非像常规自回归LLM那样顺序生成。这让扩散模型有望比自回归LLM更高效。

但话虽如此,传统LLM的自回归特性也是其核心优势之一。而纯并行解码的问题,可以用最近《ParallelBench:理解扩散大语言模型中并行解码的权衡》(https://arxiv.org/abs/2510.04767)论文中的一个绝佳例子来说明。

figure16

图16: 摘自《ParallelBench:理解扩散大语言模型中并行解码的权衡》(https://arxiv.org/abs/2510.04767)的标注图,展示了并行解码存在的问题。

比如,考虑以下提示:

“选一个随机旅游城市:纽约、新奥尔良、墨西哥城、还是巴拿马
城市?”

假设我们让LLM生成两个token的答案。它可能首先根据条件概率p(y_t = ”New” | X)采样出token“New”。

到下一次迭代时,它会基于之前生成的token,大概率选择“York”或“Orleans”,因为条件概率
p(y_{t+1} = ”York” | X, y_t = ”New”) 和 p(y_{t+1} = ”Orleans” | X, y_t = ”New”)
都相对较高(因为训练集中“New”经常和这些后缀共同出现)。但如果两个token是并行采样的,模型可能会独立选出两个最高概率的token p(y_t = “New” | X) 和 p(y_{t+1} = “City” | X),导致出现“New City”这种奇怪的输出。(这是因为模型缺少自回归条件约束,无法捕捉token之间的依赖关系。)

无论如何,上面的描述是简化的,听起来好像扩散LLM完全没有条件依赖。事实并非如此。如前所述,扩散LLM并行预测所有token,但这些预测通过迭代细化(去噪)步骤相互关联。

每一步扩散都会基于当前全部带噪文本进行条件计算,token之间通过每一步中的交叉注意力和自注意力相互影响。因此,尽管所有位置同时更新,但更新过程通过共享的注意力层互为条件。

但如前所述,理论上,生成2000个token的答案时,20-60步扩散可能比自回归LLM的2000步推理更划算。

3.4 文本扩散的现状

一个有趣的趋势是:视觉模型在吸收大语言模型的组件,比如注意力和Transformer架构本身;而基于文本的大语言模型也在从纯视觉模型中汲取灵感,将扩散应用于文本。

就我个人而言,除了试过几个演示之外,我还没有大量使用扩散模型,但我认为这是一种权衡。如果用较少的扩散步数,生成答案更快,但答案质量可能下降;如果增加扩散步数来生成更好的答案,最终模型的成本可能和自回归模型差不多。

引用https://arxiv.org/abs/2510.04767论文作者的话:

……我们系统分析了扩散LLM和自回归LLM,发现:(1)并行解码下的扩散LLM在真实场景中可能出现严重的质量下降;(2)当前的并行解码策略难以根据任务难度调整并行度,因此无法在不牺牲质量的前提下实现有意义的速度提升。

此外,我发现另一个特别的缺点是:扩散LLM无法在其生成链条中使用工具,因为根本不存在链条。或许可以在扩散步骤之间插入工具调用,但我猜这绝非易事。(如果我错了请指正。)

简而言之,扩散LLM似乎是一个值得探索的有趣方向,但就目前而言,它们可能还无法取代自回归LLM。不过我认为,它们可以作为小型端侧LLM的有趣替代,或者替代小型、蒸馏后的自回归LLM。

比如,谷歌宣布正在研发用于文本的https://deepmind.google/models/gemini-diffusion/模型,他们称其:

  • 快速响应:生成内容的速度甚至远超我们目前最快的模型。

而且在速度更快的同时,其基准表现似乎和他们的快速版Gemini 2.0 Flash-Lite模型不相上下。等该模型正式发布,用户在不同任务和领域中试用之后,看看它的接受度和反馈如何,将会很有意思。

figure17

图17: (更快的)扩散LLM(Gemini Diffusion)与快速自回归LLM(Gemini 2.0 Flash-Lite)的基准表现对比。数据基于https://deepmind.google/models/gemini-diffusion/#capabilities公布的数值。

4. 世界模型

到目前为止,我们讨论的方案都聚焦于提升效率,让模型更快、更易扩展,而这些方案通常都会略微牺牲建模性能。

本节的主题则从另一个角度切入,聚焦于提升建模性能(而非效率)。这种性能提升是通过教会模型“理解世界”来实现的。

世界模型传统上是独立于语言建模发展的,但2025年9月最新发布的https://www.arxiv.org/abs/2510.02387论文,首次让世界模型与语言建模直接产生了关联。

理想情况下,和本文的其他主题一样,世界模型本身就值得一整篇文章(甚至一整本书)来介绍。不过在讨论《代码世界模型》(CWM)论文之前,先让我简单介绍一下世界模型。

4.1 世界模型的核心理念

最初,世界模型的理念是隐式地对结果建模,也就是在结果实际发生之前就预判可能发生的情况(如下图所示)。这类似于人类大脑会根据过往经验持续预测即将发生的事件。比如,当我们伸手去拿一杯咖啡或茶时,大脑已经预判出它大概有多重,我们甚至在碰到杯子之前就会调整握力。

figure18

图18: 世界模型系统的概念概览。智能体通过观察环境当前状态(t)并采取行动(t)来与环境交互,以达成既定目标。与此同时,智能体学习一个内部世界模型,作为环境的心智模拟,让它可以在真实世界执行行动之前就预测结果、规划动作。

据我所知,“世界模型”这个术语是由Ha和Schmidhuber在2018年的同名论文https://arxiv.org/abs/1803.10122中普及的,该论文使用VAE+RNN架构为强化学习智能体学习一个内部环境模拟器。(但这个术语或概念本身本质上就是对世界或环境的建模,其源头可以追溯到20世纪80年代的强化学习和机器人学研究。)

说实话,直到Yann LeCun 2022年的文章https://openreview.net/pdf?id=BZ5a1r-kVsf发表之前,我都没有关注到世界模型的这种新解读。那篇文章本质上是在描绘一条不同于大语言模型的AI替代路径。

4.2 从视觉到代码

话虽如此,此前的世界模型论文都聚焦于视觉领域,涵盖的架构也非常广泛:从早期基于VAE和RNN的模型,到Transformer、扩散模型,甚至Mamba层混合架构。

而作为目前更专注于大语言模型的研究者,https://www.arxiv.org/abs/2510.02387(2025年9月30日)这篇论文第一次完全抓住了我的注意力(双关语)。据我所知,这是第一个从文本到文本(或者更准确地说,从代码到代码)映射的世界模型。

CWM是一个320亿参数的开源权重模型,上下文窗口为131k token。从架构上看,它依然是一个带滑动窗口注意力的稠密解码器-only Transformer。和其他大语言模型一样,它也经历了预训练、中期训练、监督微调(SFT)和强化学习阶段,但中期训练数据引入了世界建模组件。

4.3 代码世界模型 vs 常规代码大语言模型

那么,它和常规代码大语言模型(比如https://huggingface.co/Qwen/Qwen3-Coder-480B-A35B-Instruct )有什么不同?

Qwen3-Coder这类常规模型纯粹通过下一个token预测进行训练。它们学习语法和逻辑模式来生成合理的代码补全,这让它们对编程拥有静态的文本层面的理解。

相比之下,CWM学习模拟代码运行时会发生什么。它被训练来预测执行代码修改等操作后的程序状态,比如变量的值,如下图所示。

figure19

图19: 代码世界模型(CWM)中的代码执行追踪示例。模型预测每一行代码执行时变量状态的逐步演变。图中模型本质上在模拟代码的行为。图标注摘自https://www.arxiv.org/abs/2510.02387

在推理时,CWM依然是自回归Transformer,一次生成一个token,就像GPT风格的模型一样。核心区别在于:这些token可以编码结构化的执行轨迹,而非纯文本。

所以,我或许不会称它为世界模型,而是“世界模型增强的大语言模型”。

作为首次尝试,它的表现好得惊人,在参数量大致相当的情况下,表现与gpt-oss-20b(中等推理强度)相当。

如果使用测试时缩放技术,它的表现甚至略优于gpt-oss-120b(高推理强度),但模型尺寸只有后者的1/4。

注意,他们的测试时缩放使用了带生成单元测试的best@k流程(可以理解为一种更复杂的多数投票机制)。如果能对比CWM和gpt-oss的每秒token数或解题时间会很有意思,因为它们使用了不同的测试时缩放策略(best@k vs 每步推理更多token)。

figure20

图20: 代码世界模型(CWM)与其他主流大语言模型在编码基准(SWE-bench)上的表现对比。图标注摘自https://www.arxiv.org/abs/2510.02387

5. 小型递归Transformer

你可能已经注意到,前面所有方案依然建立在Transformer架构之上。本节的主题也不例外,但和之前讨论的模型不同,这些是专为推理设计的小型专用Transformer。

没错,专注于推理的架构不一定非得很大。事实上,随着https://arxiv.org/abs/2506.21734(HRM)的出现,一种新型小型递归Transformer最近在研究界引发了大量关注。

figure21

图21: 大语言模型领域概览;本节介绍小型递归Transformer。

更具体地说,HRM的研究者证明,即便是非常小的Transformer模型(仅4个块),只要经过训练逐步细化答案,就能在特定问题上展现出惊人的推理能力。这让它在ARC挑战赛上登顶。

figure22

图22: ARC-AGI 1任务示例(上)来自arcprize.org/arc-agi/1;分层推理模型(HRM)在排行榜上的排名(下)来自arcprize.org/blog/hrm-analysis。

HRM这类递归模型的理念是:模型不是一次前向传播就生成答案,而是以递归方式反复细化自己的输出。(在这个过程中,每次迭代都会细化一个潜在表示,作者将其视为模型的“思考”或“推理”过程。)

第一个代表性例子是今年初夏的HRM,随后是https://arxiv.org/abs/2507.10524

而就在最近,https://arxiv.org/abs/2510.04871(2025年10月)提出了小型递归模型(Tiny Recursive Model,TRM),如下图所示。它是一种更简单、甚至更小的模型(700万参数,大约比HRM小4倍),在ARC基准上的表现甚至更优。

figure23

图23: 小型递归模型(TRM)。图标注摘自https://arxiv.org/abs/2510.04871

本节剩下的部分,我们来稍微详细地了解一下TRM。

5.1 这里的“递归”指什么?

TRM通过两次交替更新来细化答案:

  1. 它根据当前的问题和答案计算一个潜在推理状态。

  2. 然后基于该潜在状态更新答案。

训练时,每批次最多执行16步细化。每一步都会执行若干无梯度循环,迭代细化答案。随后是一个梯度循环,通过完整的推理序列反向传播,更新模型权重。

需要重点注意的是,TRM不是处理文本的语言模型。但由于:(1)它是基于Transformer的架构;(2)推理是当前大语言模型研究的核心焦点,而该模型代表了一种截然不同的推理思路;(3)很多读者要求我介绍HRM(而TRM是其更先进的继任者),因此我决定把它纳入本文。

虽然TRM未来可以扩展到文本问答任务,但目前它处理的是基于网格的输入和输出。换句话说,“问题”和“答案”都是离散token组成的网格(比如9×9的数独,或者30×30的ARC/迷宫谜题),而非文本序列。

5.2 TRM与HRM有何不同?

  • HRM由两个小型Transformer模块(各4个块)组成,跨递归层级通信。TRM仅使用单个2层Transformer。(注意前面TRM的图中Transformer块旁边标了4×,但那可能是为了方便和HRM对比。)

  • TRM通过所有递归步骤反向传播,而HRM仅通过最后几步反向传播。

  • HRM包含显式的停止机制,以决定何时停止迭代。TRM用简单的二元交叉熵损失替代了该机制,学习何时停止迭代。

在性能方面,TRM相比HRM表现非常出色,如下图所示。

figure24

图24: 分层推理模型(HRM)与小型递归模型(TRM)的性能对比。

论文中包含了数量惊人的消融研究,得出了一些有意思的额外结论。这里列出两个最突出的:

  • 层数越少,泛化性越好。从4层减少到2层,数独准确率从79.5%提升到了87.4%。

  • 注意力并非必需。用纯MLP层替换自注意力同样提升了准确率(从74.7%到87.4%)。但这只有在上下文较小且长度固定的情况下才可行。

5.3 更宏观的视角

虽然HRM和TRM在这些基准上取得了非常好的推理表现,但把它们和大型大语言模型相比并不太公平。HRM和TRM是针对ARC、数独、迷宫寻路等任务的专用模型,而大语言模型是通用模型。当然,HRM和TRM也可以应用于其他任务,但都必须针对每个任务专门训练。因此从这个意义上说,我们或许可以把HRM和TRM看作高效的便携计算器,而大语言模型更像电脑,还能做很多其他事情。

尽管如此,这些递归架构依然是令人振奋的概念验证,彰显了小型高效模型如何通过迭代自我完善来“推理”。或许未来,这类模型可以作为推理或规划模块,嵌入到更大的使用工具的大语言模型系统中。

就目前而言,大语言模型依然是泛用任务的理想选择,但一旦目标领域足够清晰,像TRM这样的领域专用递归模型就能更高效地解决特定问题。除了数独、迷宫寻路和ARC这些概念验证基准之外,这类模型在物理和生物领域可能还有很多应用场景。

一个有趣的小细节:作者分享说,训练这个模型只花了不到500美元,用4张H100显卡训练了大约2天。很高兴看到,不用数据中心也依然能做出有意思的研究。

6. 结论

我原本计划覆盖概览图中的所有模型类别,但由于文章篇幅超出预期,我只能把xLSTM、液态基础模型、Transformer-RNN混合架构以及状态空间模型留到下次再讲(不过门控DeltaNet已经让我们初步领略了状态空间模型和递归设计)。

作为本文的总结,我想重申之前的观点:标准的自回归Transformer大语言模型经过了充分验证,至今依然经受住了时间的考验。如果不把效率作为首要考量,它们依然是目前的最佳选择。

传统解码器式自回归Transformer

  • 经过验证、工具链成熟

  • 原理清晰易懂

  • 缩放定律明确

  • 性能顶尖
    – 训练成本高昂
    – 推理成本高昂(除了前文提到的优化技巧)

如果我今天要启动一个新的基于大语言模型的项目,自回归Transformer大语言模型会是我的首选。

我确实认为即将到来的注意力混合架构非常有前景,尤其是在处理长上下文、效率成为核心痛点的场景中。

线性注意力混合架构

  • 和解码器式Transformer特性一致

  • 长上下文任务下减少计算量和KV内存
    – 复杂度增加
    – 用一定精度换取效率

在更激进的一端,文本扩散模型是一项有意思的进展。我对它们在日常使用中的表现依然持一定的怀疑态度,因为我只试过几个快速演示。希望谷歌的Gemini Diffusion很快能带来大规模的生产级部署,让我们可以在日常任务和编码任务中测试,看看用户实际体验如何。

文本扩散模型

  • 迭代去噪是文本领域的全新思路

  • 并行性更好(无下一个token依赖)
    – 无法流式输出答案
    – 无法从思维链(CoT)中受益?
    – 工具调用难度大?
    – 模型扎实但未达顶尖水平

虽然文本扩散模型的主要卖点是提升效率,但代码世界模型处于光谱的另一端,它们致力于提升建模性能。在撰写本文时,基于标准大语言模型的编码模型大多通过推理技术来优化,但如果你在更棘手的挑战上试过它们,可能已经发现它们或多或少依然存在不足,无法很好地解决很多更难的编码问题。

我认为代码世界模型特别有意思,相信它们可能是迈向更强大编码系统的重要一步。

代码世界模型

  • 提升代码理解的前景广阔

  • 可验证的中间状态
    – 加入可执行代码轨迹让训练更复杂
    – 代码运行增加延迟

最后,我们介绍了小型递归Transformer,比如分层推理模型和小型推理模型。这些都是非常有意思的概念验证模型。但截至目前,它们主要还是谜题求解器,而非通用文本或编码模型。因此它们和本文介绍的其他非标准大语言模型替代方案不属于同一类别。尽管如此,它们依然是非常精彩的概念验证,我很高兴有研究者在深耕这些方向。

如今,GPT-5、DeepSeek R1、Kimi K2等大语言模型都被开发为面向自由文本、代码、数学问题等场景的专用模型。它们给人的感觉像是一种蛮力、全能的方案,被用来解决从常识问答到数学、代码的各种任务。

然而,当我们重复执行相同任务时,这种蛮力方案会变得低效,甚至在专业化方面也未必理想。这正是小型递归Transformer的价值所在:它们可以作为轻量级、任务专属的模型,针对重复性或结构化推理任务做到高效且定制化。

此外,我还可以把它们看作其他调用工具的大语言模型的潜在“工具”;比如,当大语言模型使用Python或计算器API解决数学问题时,专用的小型推理模型可以填补其他类型谜题或推理问题的空白。

小型递归Transformer

  • 架构非常小巧

  • 在谜题任务上泛化性好
    – 属于专用模型
    – 目前仅适用于谜题场景

这篇文章很长,但我希望你能从中发现一些常被主流大语言模型聚光灯忽略的迷人研究方向。

如果你已经对或多或少有些常规的大语言模型发布感到有些厌倦,希望这篇文章能重新点燃你对AI的热情——因为当下正有大量有趣的研究在发生!

这本杂志是个人热情项目,你的支持是它持续运转的动力。

如果你愿意支持我的工作,可以考虑我的著作https://amzn.to/4fqvn0D,或者它的续作https://mng.bz/Nwr7 。(我相信你会从中学到很多,它们对大语言模型工作原理的讲解深度是你在别处找不到的。)

感谢阅读,也感谢你对独立研究的支持!

《从零构建大语言模型》现已在https://amzn.to/4fqvn0D发售。《从零构建推理模型》可在https://mng.bz/Nwr7获取。

如果你读过这本书,能抽出几分钟时间的话,我会非常感谢你在https://www.amazon.com/Build-Large-Language-Model-Scratch/dp/1633437167留下评价。这对我们作者帮助很大!

你的支持意义重大!谢谢!

【转载】从零开始理解大语言模型评估的四大主流方法

原文地址:Understanding the 4 Main Approaches to LLM Evaluation (From Scratch),by Sebastian Raschka, on 2025-10-05

从零开始理解大语言模型评估的四大主流方法

选择题基准测试、验证器、排行榜与LLM评审器(附代码示例)

我们究竟该如何评估大语言模型(LLM)?这个问题看似简单,却往往能引出一场宏大的讨论。

在为项目提供咨询或协作开发时,我最常被问到的问题之一就是:如何在不同模型之间做选择?如何解读市面上五花八门的评估结果?(当然,还有在微调或自研模型时,该如何衡量进展。)

由于这个问题反复出现,我觉得有必要简要梳理一下业界用于对比LLM的主流评估方法。诚然,LLM评估是一个极其庞大的议题,单篇文章无法穷尽,但我认为,对这几类核心方法建立清晰的认知框架,能大幅帮助我们解读各类基准测试、排行榜和学术论文。

我原本打算把这些评估技术写入即将出版的新书《Build a Reasoning Model (From Scratch)》(https://mng.bz/Nwr7),但最终发现它们略超出了全书的核心范围(该书更聚焦于基于验证器的评估方法)。因此我想把这部分内容整理成一篇长文,搭配从零实现的代码示例分享给大家。

在《Build a Reasoning Model (From Scratch)》(https://mng.bz/Nwr7)一书中,我采用了动手实践的方式,从零开始构建一个推理型LLM。如果你喜欢《Build A Large Language Model (From Scratch)》,那么新书也延续了同样的风格——全程用纯PyTorch从零搭建所有组件。

figure00

图0:推理能力是近年来LLM领域最激动人心、也最重要的进展之一,但如果只听过“推理”这个名词、只读过理论层面的介绍,也很容易产生误解。因此在《Build a Reasoning Model (From Scratch)》(https://mng.bz/Nwr7)中,我采用了手把手实操的思路,从零搭建推理型LLM。

该书目前处于抢先阅读阶段,已有超过100页内容上线,我刚刚又完成了约30页的内容,目前正在由排版团队处理。如果你已经加入了抢先阅读计划(非常感谢你的支持!),内容上线后你会收到邮件通知。

附言:当下LLM研究领域日新月异,我还在陆续消化我收藏夹里越来越多的论文,计划在下一篇文章中重点介绍其中最有意思的几项研究。

不过现在,让我们先来讨论LLM评估的四大核心方法,搭配从零开始的代码实现,帮你更好地理解它们各自的优缺点。


理解LLM的主流评估方法

实践中,训练好的LLM常见的评估方式有四种:选择题测试、验证器评估、排行榜和LLM评审器,如图1所示。学术论文、宣传材料、技术报告以及模型卡(LLM专属的技术报告)通常会包含其中两类或更多类方法的结果。

figure01

图1: 本文涵盖的四种评估模型概览

此外,这里介绍的四大类方法可以归为两大阵营:基于基准测试的评估和基于评判的评估,如上图所示。

(还有一些其他指标,比如训练损失、困惑度、奖励值等,但它们通常用于模型开发的内部环节。)

下面的小节将简要概述每一种方法,并给出相应示例。

方法1:评估选项作答准确率

我们从一种基于基准测试的方法说起:选择题作答。

历史上,应用最广泛的评估方法之一就是选择题基准测试,比如MMLU(全称为Massive Multitask Language Understanding,大规模多任务语言理解,https://huggingface.co/datasets/cais/mmlu)。为了说明这种方法,图2展示了MMLU数据集中的一道典型题目。

figure02

图2: 在MMLU上评估LLM:将模型的选择题预测结果与数据集的正确答案做对比

图2只是MMLU数据集中的一个例子。完整的MMLU数据集涵盖57个学科(从高中数学到生物学),总共约1.6万道选择题,性能用准确率来衡量(答对题目的占比)——比如1.6万道题中答对1.4万道,准确率就是87.5%。

MMLU这类选择题基准测试,以一种直接、可量化的方式考察LLM的知识回忆能力,类似于标准化考试、各类学业考试或者驾照理论考试。

注意图2展示的是简化版的选择题评估方式:直接将模型预测的答案字母与正确答案做比对。还有另外两种更常用的方法涉及对数概率评分(log-probability scoring),我已经在这个仓库中实现了它们:https://github.com/rasbt/reasoning-from-scratch/tree/main/chF/02_mmlu 。(由于这部分内容建立在本文讲解的概念之上,建议读完本文后再去查看。)

下面的小节将演示如何用代码实现图2所示的MMLU打分方式。

1.2 加载模型

首先,在MMLU上评估模型之前,我们首先要加载预训练模型。这里我们使用纯PyTorch从零实现的Qwen3 0.6B模型,它只需要约1.5GB内存。

注意Qwen3的模型实现细节不是本节重点,我们只把它当作一个待评估的LLM即可。如果你感兴趣,可以在我之前的文章《Understanding and Implementing Qwen3 From Scratch》中看到从零实现的完整教程,源代码也可以在Github获取:

我们不用复制粘贴大段Qwen3源代码,而是直接从我的Python库reasoning_from_scratch中导入,安装方式如下:

pip install reasoning_from_scratch

或者

uv add reasoning_from_scratch

代码块1:加载预训练模型

from pathlib import Path
import torch
from reasoning_from_scratch.ch02 import get_device
from reasoning_from_scratch.qwen3 import (
    download_qwen3_small, Qwen3Tokenizer,
    Qwen3Model, QWEN_CONFIG_06_B
)

device = get_device()
# Set matmul precision to "high" to
# enable Tensor Cores on compatible GPUs
torch.set_float32_matmul_precision("high")

# Uncomment the following line
# if you encounter device compatibility issues
# device = "cpu"

# Use the base model by default
WHICH_MODEL = "base"

if WHICH_MODEL == "base":
    download_qwen3_small(
        kind="base", tokenizer_only=False, out_dir="qwen3"
    )
    tokenizer_path = Path("qwen3") / "tokenizer-base.json"
    model_path = Path("qwen3") / "qwen3-0.6B-base.pth"
    tokenizer = Qwen3Tokenizer(tokenizer_file_path=tokenizer_path)
elif WHICH_MODEL == "reasoning":
    download_qwen3_small(
        kind="reasoning", tokenizer_only=False, out_dir="qwen3"
    )
    tokenizer_path = Path("qwen3") / "tokenizer-reasoning.json"
    model_path = Path("qwen3") / "qwen3-0.6B-reasoning.pth"
    tokenizer = Qwen3Tokenizer(
        tokenizer_file_path=tokenizer_path,
        apply_chat_template=True,
        add_generation_prompt=True,
        add_thinking=True,
    )
else:
    raise ValueError(f"Invalid choice: WHICH_MODEL={WHICH_MODEL}")

model = Qwen3Model(QWEN_CONFIG_06_B)
model.load_state_dict(torch.load(model_path))
model.to(device)

# Optionally enable model compilation for potential performance gains
USE_COMPILE = False
if USE_COMPILE:
    torch._dynamo.config.allow_unspec_int_on_nn_module = True
    model = torch.compile(model)

1.3 检查生成的答案字母

本节我们实现最简单、也最直观的MMLU打分方法:检查模型生成的选择题答案字母是否与正确答案匹配。这和之前图2展示的思路一致,为方便阅读,下图再次放出。

figure02

图3: 在MMLU上评估LLM:将模型的选择题预测结果与数据集的正确答案做对比

我们以MMLU数据集中的一道题为例:

example = {
    "question": (
        "How many ways are there to put 4 distinguishable"
        " balls into 2 indistinguishable boxes?"
    ),
    "choices": ["7", "11", "16", "8"],
    "answer": "D",
}

接下来,我们定义一个函数来格式化LLM的输入提示。

代码块2:格式化提示

def format_prompt(example):
    return (
        f"{example['question']}\n"
        f"A. {example['choices'][0]}\n"
        f"B. {example['choices'][1]}\n"
        f"C. {example['choices'][2]}\n"
        f"D. {example['choices'][3]}\n"
        "Answer: "
    )
# Trailing space in "Answer: " encourages a single-letter next token

我们对上面的MMLU例题执行这个函数,看看格式化后的LLM输入是什么样的:

prompt = format_prompt(example)
print(prompt)

输出为:

How many ways are there to put 4 distinguishable balls into 2 indistinguishable boxes?
A. 7
B. 11
C. 16
D. 8
Answer: 

如上所示,模型提示会列出所有候选答案,最后以Answer:结尾,引导模型生成正确答案。

虽然不是必须的,但有时也可以在输入中附带几道例题和正确答案,让模型观察解题的规范格式。(比如提供5道例题的设置也叫5-shot MMLU。)不过对于当前世代的LLM,哪怕基座模型也已经具备足够的能力,这一步并非必需。

加载不同的MMLU样本

你可以通过datasets库直接加载MMLU数据集的样本(安装方式:pip install datasetsuv add datasets):

from datasets import load_dataset

configs = get_dataset_config_names("cais/mmlu")
dataset = load_dataset("cais/mmlu", "high_school_mathematics")

# Inspect the first example from the test set:
example = dataset["test"][0]
print(example)

上面我们使用了“高中数学”子集;要查看其他子集列表,可以使用以下代码:

from datasets import get_dataset_config_names

subsets = get_dataset_config_names("cais/mmlu")
print(subsets)

接下来,我们对提示进行分词,并用PyTorch张量包装,作为LLM的输入:

prompt_ids = tokenizer.encode(prompt)
prompt_fmt = torch.tensor(prompt_ids, device=device)
# Add batch dimension:
prompt_fmt = prompt_fmt.unsqueeze(0)

准备工作完成后,我们定义核心打分函数:生成少量token(这里默认8个),并提取模型输出中出现的第一个A/B/C/D字母。

代码块3:提取生成的字母

from reasoning_from_scratch.ch02_ex import (
    generate_text_basic_stream_cache
)

def predict_choice(
    model, tokenizer, prompt_fmt, max_new_tokens=8
):
    pred = None
    for t in generate_text_basic_stream_cache(
        model=model,
        token_ids=prompt_fmt,
        max_new_tokens=max_new_tokens,
        eos_token_id=tokenizer.eos_token_id,
    ):
        answer = tokenizer.decode(t.squeeze(0).tolist())
        for letter in answer:
            letter = letter.upper()
            # stop as soon as a letter appears
            if letter in "ABCD":
                pred = letter
                break
        if pred:
            break
    return pred

然后我们就可以用上面的函数检查生成的字母了:

pred1 = predict_choice(model, tokenizer, prompt_fmt)
print(
    f"Generated letter: {pred1}\n"
    f"Correct? {pred1 == example['answer']}"
)

结果为:

Generated letter: C
Correct? False

可以看到,这个例子中模型生成的答案是错误的(False)。

这只是MMLU高中数学子集中270道题里的一道。下图(图4)展示了基座模型和推理版本在完整子集上的表现,对应代码可以在这里查看:https://github.com/rasbt/reasoning-from-scratch/blob/main/chF/02_mmlu/1_letter_matching.py

figure04

图4: 基座模型与推理模型在MMLU高中数学子集上的表现

假设每个选项出现概率均等,随机猜测者(均匀选择A、B、C、D)的预期准确率是25%。所以基座模型和推理模型的表现都不算理想。

选择题作答的其他形式

注意本节为了演示,实现的是简化版的选择题评估,直接比对答案字母。实践中更常用的是对数概率评分(log-probability scoring)这类变体:我们衡量模型认为每个候选答案的可能性,而不只是检查最终输出的字母。(我们会在第4章讨论基于概率的打分。)对于推理模型,评估还可以包含:当把正确答案作为输入时,模型生成它的概率有多大。

figure05

图5: 其他MMLU打分方法已在这个仓库中说明和共享:https://github.com/rasbt/reasoning-from-scratch/tree/main/chF/02_mmlu

但无论使用哪种MMLU打分变体,评估的本质都是检验模型能否从预设的选项中做出选择。

MMLU这类选择题基准测试的局限在于:它们只衡量LLM从预设选项中做选择的能力,因此除了检查模型相比基座版本遗忘了多少知识之外,对评估推理能力的作用有限。它无法衡量自由写作能力,也无法反映模型在真实场景中的实用性。

尽管如此,选择题基准测试依然是简单实用的诊断工具:比如,MMLU高分不一定代表模型实际应用能力强,但低分却能凸显出潜在的知识缺口。


方法2:用验证器检查答案

和上一节讨论的选择题作答相关,基于验证的方法也通过准确率指标来量化LLM的能力。但与选择题基准测试不同的是,验证方法允许LLM给出自由形式的答案,然后我们提取出相关的答案部分,用所谓的“验证器”将答案与数据集提供的标准答案做对比,如图6所示。

figure06

图6: 用基于验证的方法在自由问答场景下评估LLM。模型生成自由形式的答案(可能包含多步推导)和最终的框选答案,提取后与数据集的正确答案做对比。

在对比提取出的答案和标准答案时,我们可以使用外部工具,比如代码解释器或者计算器类工具/软件。

这种方法的缺点是:只能应用于容易(最好是确定性)验证的领域,比如数学和代码。此外,这种方法会引入额外的复杂度和依赖项,并且可能把部分评估负担从模型本身转移到了外部工具上。

但由于它支持通过编程生成无限多的数学题目变体,并且能受益于逐步推理过程,它已经成为推理模型评估和开发的基石。

我在《Build a Reasoning Model (From Scratch)》一书中用整整35页的篇幅详细讲解了这个主题,所以这里就跳过代码实现了。(我上周刚提交了这一章。如果你有抢先阅读版,内容上线后你会收到邮件,到时候就可以阅读了。与此同时,你可以在这里找到分步代码:https://github.com/rasbt/reasoning-from-scratch/blob/main/ch03/01_main-chapter-code/ch03_main.ipynb 。)

figure07
figure07

图7: 基于验证的评估方法节选,代码见:https://github.com/rasbt/reasoning-from-scratch/blob/main/ch03/01_main-chapter-code/ch03_main.ipynb


方法3:用偏好度和排行榜对比模型

到目前为止,我们介绍了两种能给出可量化指标(比如模型准确率)的方法。但上述方法都没有从更整体的角度评估LLM,包括对回答风格的评判。本节我们讨论一种基于评判的方法——LLM排行榜,如图8所示。

figure08

图8: 本书覆盖主题的思路框架,聚焦于附录中介绍的基于评判和基于基准的评估方法。前面已经讲了基于基准的方法(选择题、验证器),现在我们引入衡量LLM性能的基于评判的方法,本小节重点讲排行榜。

这里介绍的排行榜方法是一种基于评判的思路:模型的排名不是依据准确率或其他固定基准分数,而是依据用户(或其他LLM)对其输出的偏好度。

一个很有名的排行榜是LM Arena(https://lmarena.ai/,前身为Chatbot Arena):用户对比两个指定或匿名模型的回答,投票选出自己更喜欢的那个,如图9所示。

figure09

图9: 基于评判的排行榜界面示例(LM Arena)。给两个LLM输入相同的提示,并排展示回答,用户投票选出更偏好的答案。

这些偏好投票会像上图那样收集起来,再聚合到所有用户中,生成一个按用户偏好度排名的模型排行榜。图10是LM Arena排行榜的当前快照(数据获取于2025年10月3日)。

figure10

图10: LM Arena排行榜截图,展示了基于用户文本任务偏好度的当前领先LLM

在本节余下部分,我们将实现一个简单的排行榜示例。

为了构造具体的例子,假设用户在类似图9的设置下向不同LLM提问。下面的列表代表两两投票结果,第一个模型是获胜者:

votes = [
    ("GPT-5", "Claude-3"),
    ("GPT-5", "Llama-4"),
    ("Claude-3", "Llama-3"),
    ("Llama-4", "Llama-3"),
    ("Claude-3", "Llama-3"),
    ("GPT-5", "Llama-3"),
]

上面的列表中,votes里的每个元组代表两个模型的两两偏好,格式为(获胜者,失败者)。比如("GPT-5", "Claude-3")表示用户更偏好GPT-5的回答,而非Claude-3。

接下来,我们把这个投票列表转换成排行榜。我们会使用很流行的Elo评级体系(https://en.wikipedia.org/wiki/Elo_rating_system),它最初是为棋手排名设计的。

在看具体代码实现之前,先简单说下原理:每个模型以基准分起步,每次对比和投票后,模型的评级会更新。(在Elo体系中,更新幅度取决于结果的“冷门程度”。)

具体来说,如果一个当前模型战胜了排名远高于自己的模型,它的排名会得到较大幅度的提升,在排行榜上位置更靠前。反之,如果战胜的是排名很低的对手,提升幅度就很小。(如果当前模型输了,也会按类似逻辑扣分。)

将两两排名转化为排行榜的代码如下所示。

代码块4:构建排行榜

def elo_ratings(vote_pairs, k_factor=32,
                initial_rating=1000):
    # Initialize all models with the same base rating
    ratings = {
        model: initial_rating
        for pair in vote_pairs
        for model in pair
    }

    # Update ratings after each match
    for winner, loser in vote_pairs:

        # Expected score for the current winner
        expected_winner = 1.0 / (
            1.0 + 10 ** (
                (ratings[loser] - ratings[winner])
                / 400.0
            )
        )

        # k_factor determines sensitivity of updates
        ratings[winner] = (
            ratings[winner]
            + k_factor * (1 - expected_winner)
        )
        ratings[loser] = (
            ratings[loser]
            + k_factor * (0 - (1 - expected_winner))
        )

    return ratings

上面定义的elo_ratings函数接收投票数据,输出排行榜,用法如下:

ratings = elo_ratings(votes, k_factor=32, initial_rating=1000)
for model in sorted(ratings, key=ratings.get, reverse=True):
    print(f"{model:8s} : {ratings[model]:.1f}")

输出的排名如下,分数越高表现越好:

GPT-5    : 1043.7
Claude-3 : 1015.2
Llama-4  : 1000.7
Llama-3  : 940.4

这背后的原理是什么?对于每一组对决,我们用下面的公式计算获胜者的预期得分:

expected_winner = 1 / (1 + 10 ** ((rating_loser - rating_winner) / 400))

expected_winner是基于当前评级,模型在无平局设定下的预测获胜概率,它决定了评级的更新幅度。

首先,每个模型的初始分initial_rating = 1000。如果两个模型评级相等,那么expected_winner = 0.5,说明双方势均力敌。这种情况下,更新幅度为:

  • 获胜者:rating_winner + k_factor * (1 - 0.5) = rating_winner + 16

  • 失败者:rating_loser + k_factor * (0 - (1 - 0.5)) = rating_loser - 16

如果是大热门(高评级模型)赢了,expected_winner ≈ 1,胜者只加很少的分,败者也只扣很少的分:

  • 获胜者:rating_winner + 32 * (1 - 0.99) = rating_winner + 0.32

  • 失败者:rating_loser + 32 * (0 - (1 - 0.99)) = rating_loser - 0.32

但如果是冷门选手(低评级模型)赢了,expected_winner ≈ 0,胜者几乎拿到全部k_factor的分数,败者也扣差不多的分数:

  • 获胜者:rating_winner + 32 * (1 - 0.01) = rating_winner + 31.68

  • 失败者:rating_loser + 32 * (0 - (1 - 0.01)) = rating_loser - 31.68

顺序的影响

Elo方法是每次对决后更新评级,因此后面的结果建立在已经更新过的评级之上。这意味着同样的一组比赛结果,如果呈现顺序不同,最终分数可能略有差异。这种影响通常不大,但如果冷门对局出现在早期和晚期,结果可能会不一样。

为了降低这种顺序效应,我们可以打乱投票对的顺序,多次运行elo_ratings函数,然后取评级的平均值。

上面介绍的这类排行榜方法,比静态基准分数更能动态反映模型质量。但结果会受到用户群体构成、提示选择、投票偏差的影响。基准测试和排行榜也都存在被“刷分”的可能,而且用户可能更看重回答风格而非正确性。最后,和自动化基准测试相比,排行榜无法对新开发的模型变体提供即时反馈,因此在活跃的模型开发阶段使用起来更困难。

其他排名方法

LM Arena最初使用本节介绍的Elo方法,但最近换成了基于布拉德利-特里(Bradley–Terry)模型的统计方法。Bradley-Terry模型的主要优势是:由于有统计学基础,它可以构建置信区间来表达排名的不确定性。此外,和Elo评级不同,Bradley-Terry模型是基于整个数据集做统计拟合,同时估算所有评级,因此不受顺序效应影响。

为了让分数保持在大家熟悉的区间,Bradley-Terry模型拟合后会输出和Elo相当的数值。尽管排行榜官方已经不再正式使用Elo评级,但“Elo”这个说法在LLM研究者和从业者对比模型时依然被广泛使用。Elo评级的代码示例可以在这里查看:https://github.com/rasbt/reasoning-from-scratch/tree/main/chF/03_leaderboards

figure11

图11: Elo与Bradley-Terry排名对比;源代码见:https://github.com/rasbt/reasoning-from-scratch/tree/main/chF/03_leaderboards


方法4:用其他LLM评判回答

早期,LLM是用统计和启发式方法来评估的,包括BLEU指标——一种粗略衡量生成文本与参考文本匹配程度的标准。这类指标的问题在于,它们要求精确的单词匹配,没有考虑同义词、语序变化等情况。

如果我们想从整体上评判生成的回答文本,一个解决方案是使用上一节讲的相对排名和基于排行榜的方法。但排行榜的缺点在于,偏好对比带有主观性,因为需要人类反馈(以及收集反馈带来的种种挑战)。

另一种相关方法是:使用另一个LLM,搭配预定义的评分标准(即评估指南),将待评估LLM的回答与参考答案做对比,按照预设标准评判回答质量,如图12所示。

figure12

图12: LLM评审器评估示例。待评估模型生成答案,然后由另一个独立的评审LLM根据评分标准和参考答案打分。

实践中,只要评审LLM足够强,图12这种基于评审的方法效果就很好。常见的设置是通过API调用顶尖的闭源LLM(比如GPT-5 API),不过也有专门的评审模型。(比如这篇论文就是众多例子之一:https://arxiv.org/abs/2405.08029 ;归根结底,大多数这类专用模型都是小模型经过微调,获得了和闭源GPT模型相近的打分行为。)

评审方法之所以有效,原因之一是:评判一个答案往往比生成一个答案更容易。

要在Python中编程实现图12所示的基于评审的模型评估,我们既可以用PyTorch加载一个更大的Qwen3模型,给它输入评分标准和待评估的模型回答;也可以通过API调用其他LLM,比如ChatGPT或者Ollama API。

既然我们已经知道如何用PyTorch加载Qwen3模型,为了更有意思,本节剩下的部分我们将用Python调用Ollama API,实现图12的评审式评估。

具体来说,我们会使用OpenAI的200亿参数gpt-oss开源模型,它在能力和效率之间取得了很好的平衡。想了解更多关于gpt-oss的信息,可以看我的文章《From GPT-2 to gpt-oss: Analyzing the Architectural Advances》:
https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the
https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the
https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the
https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the
https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the https://substack.com/profile/27393275-sebastian-raschka-phd
·
2025年8月9日
https://magazine.sebastianraschka.com/p/from-gpt-2-to-gpt-oss-analyzing-the

4.1 在Ollama中实现LLM-as-a-judge方法

https://ollama.com/ 是一款高效的开源工具,用于在本地电脑上运行LLM。它封装了开源的llama.cpp库(https://github.com/ggerganov/llama.cpp)——后者用纯C/C++实现LLM,以最大化运行效率。不过注意,Ollama只是利用LLM生成文本(推理)的工具,不支持训练或微调LLM。

要运行下面的代码,请先访问Ollama官网https://ollama.com/,按照对应操作系统的说明安装Ollama:

  • macOS和Windows用户:打开下载的Ollama应用,如果提示安装命令行工具,选择“是”。

  • Linux用户:使用Ollama官网提供的安装命令。

在实现模型评估代码之前,我们先下载gpt-oss模型,通过命令行终端使用Ollama,验证它能正常运行。

在命令行(不是Python会话中)执行以下命令,体验200亿参数的gpt-oss模型:

ollama run gpt-oss:20b

第一次执行这个命令时,会自动下载200亿参数的gpt-oss模型,占用14GB存储空间。输出大致如下:

$ ollama run gpt-oss:20b
pulling manifest
pulling b112e727c6f1: 100% ▕██████████████████████▏  13 GB
pulling fa6710a93d78: 100% ▕██████████████████████▏ 7.2 KB
pulling f6035677647: 100% ▕██████████████████████▏  11 KB
pulling d8ba2f9a17b3: 100% ▕██████████████████████▏   18 B
pulling 55c108d8e936: 100% ▕██████████████████████▏  489 B
verifying sha256 digest
writing manifest
removing unused layers
success
可选的Ollama模型

注意ollama run gpt-oss:20b命令中的gpt-oss:20b指的是200亿参数的gpt-oss模型。运行这个模型大约需要13GB内存。如果你的机器内存不够,可以试试更小的模型,比如40亿参数的qwen3:4b,命令为ollama run qwen3:4b,只需要约4GB内存。

配置更高的电脑也可以用更大的1200亿参数gpt-oss模型,把gpt-oss:20b换成gpt-oss:120b即可。但请注意,这个模型需要的计算资源会显著增加。

模型下载完成后,我们就进入命令行界面,可以和模型对话了。比如问问模型“1+2等于几?”:

>>> What is 1+2?
Thinking...
User asks: "What is 1+2?" This is simple: answer 3. Provide explanation? Possibly ask for simple arithmetic. Provide answer: 3.
...done thinking.
1 + 2 = **3**

输入/bye就可以结束这个ollama run gpt-oss:20b会话。

在本节剩下的部分,我们将使用Ollama API。这种方式要求Ollama在后台运行,有三种实现方式:

  1. 在终端运行ollama serve命令(推荐)。这会将Ollama后端作为服务运行,通常地址是http://localhost:11434。注意,在通过API调用之前,它不会加载模型。

  2. 像之前一样运行ollama run gpt-oss:20b命令,但保持窗口打开,不要输入/bye退出会话。如前所述,这相当于在本地Ollama服务外包了一层简易的交互封装,底层用的是和ollama serve一样的服务API。

  3. Ollama桌面应用。打开桌面应用会自动运行相同的后端,并在上面提供图形界面,如图12所示。

figure13

图13: 两种保持Ollama服务(或应用)运行的方式,以便我们在Python中通过Ollama API调用它

Ollama服务IP地址

Ollama在本地机器上运行时,会启动一个类似本地服务的进程。在终端运行ollama serve时,你可能会遇到报错:Error: listen tcp 127.0.0.1:11434: bind: address already in use.

如果出现这种情况,可以尝试命令OLLAMA_HOST=127.0.0.1:11435 ollama serve(如果这个地址也被占用,就把数字逐个加1,直到找到空闲地址。)

下面的代码会在我们用Ollama评估上一节生成的测试集回答之前,验证Ollama会话是否正常运行:

代码块5:检查Ollama是否运行

import psutil

def check_if_running(process_name):
    running = False
    for proc in psutil.process_iter(["name"]):
        if process_name in proc.info["name"]:
            running = True
            break
    return running

ollama_running = check_if_running("ollama")

if not ollama_running:
    raise RuntimeError(
        "Ollama not running. "
        "Launch ollama before proceeding."
    )
print("Ollama running:", check_if_running("ollama"))

确保执行上面代码后输出Ollama running: True。如果显示False,请确认ollama serve命令或者Ollama应用正在运行(见图13)。

在本文余下部分,我们将通过Python调用Ollama REST API,与运行在本地机器上的gpt-oss模型交互。下面的query_model函数演示了API的使用方法:

代码块6:调用本地Ollama模型

import json
import urllib.request

def query_model(
    prompt,
    model="gpt-oss:20b",
    # If you used
    # OLLAMA_HOST=127.0.0.1:11435 ollama serve
    # update the address below
    url="http://localhost:11434/api/chat"
):
    # Create the data payload as a dictionary:
    data = {
        "model": model,
        "messages": [
            {"role": "user", "content": prompt}
        ],
        # Settings required for deterministic responses:
        "options": {
            "seed": 123,
            "temperature": 0,
            "num_ctx": 2048
        }
    }

    # Convert the dictionary to JSON and encode it to bytes
    payload = json.dumps(data).encode("utf-8")

    # Create a POST request and add headers
    request = urllib.request.Request(
        url,
        data=payload,
        method="POST"
    )
    request.add_header("Content-Type", "application/json")

    response_data = ""

    # Send the request and capture the streaming response
    with urllib.request.urlopen(request) as response:
        while True:
            line = response.readline().decode("utf-8")
            if not line:
                break
            # Parse each line into JSON
            response_json = json.loads(line)
            response_data += response_json["message"]["content"]

    return response_data

下面是使用我们刚实现的query_model函数的示例:

ollama_model = "gpt-oss:20b"
result = query_model("What is 1+2?", ollama_model)
print(result)

输出结果是“3”。(和直接运行ollama run或者桌面应用的结果会有差异,因为默认设置不同。)

利用query_model函数,我们就可以评估模型生成的回答了:我们构造一个包含评分标准的提示,让gpt-oss模型以1到5分的尺度,根据参考答案来打分。

我们使用的提示如下:

代码块7:设置包含评分标准的提示模板

def rubric_prompt(instruction, reference_answer, model_answer):
    rubric = (
        "You are a fair judge assistant. You will be "
        "given an instruction, a reference answer, and "
        "a candidate answer to evaluate, according to "
        "the following rubric:\n\n"
        "1: The response fails to address the "
        "instruction, providing irrelevant, incorrect, "
        "or excessively verbose content.\n"
        "2: The response partially addresses the "
        "instruction but contains major errors, "
        "omissions, or irrelevant details.\n"
        "3: The response addresses the instruction to "
        "some degree but is incomplete, partially "
        "correct, or unclear in places.\n"
        "4: The response mostly adheres to the "
        "instruction, with only minor errors, "
        "omissions, or lack of clarity.\n"
        "5: The response fully adheres to the "
        "instruction, providing a clear, accurate, and "
        "relevant answer in a concise and efficient "
        "manner.\n\n"
        "Now here is the instruction, the reference "
        "answer, and the response.\n"
    )

    prompt = (
        f"{rubric}\n"
        f"Instruction:\n{instruction}\n\n"
        f"Reference Answer:\n{reference_answer}\n\n"
        f"Answer:\n{model_answer}\n\n"
        f"Evaluation: "
    )
    return prompt

rubric_prompt中的model_answer代表实际场景中我们自己的模型生成的回答。为了演示,这里我们硬编码一个合理的模型回答,而不是动态生成。(不过你也可以用本文开头加载的Qwen3模型来生成真实的model_answer。)

接下来,我们生成渲染后的提示,传给Ollama模型:

rendered_prompt = rubric_prompt(
    instruction=(
        "If all birds can fly, and a penguin is a bird, "
        "can a penguin fly?"
    ),
    reference_answer=(
        "Yes, according to the premise that all birds can fly, "
        "a penguin can fly."
    ),
    model_answer=(
        "Yes – under those premises a penguin would be able to fly."
    )
)
print(rendered_prompt)

输出如下:

You are a fair judge assistant. You will be given an instruction, a reference answer, and a candidate answer to evaluate, according to the following rubric:

1: The response fails to address the instruction, providing irrelevant, incorrect, or excessively verbose content.
2: The response partially addresses the instruction but contains major errors, omissions, or irrelevant details.
3: The response addresses the instruction to some degree but is incomplete, partially correct, or unclear in places.
4: The response mostly adheres to the instruction, with only minor errors, omissions, or lack of clarity.
5: The response fully adheres to the instruction, providing a clear, accurate, and relevant answer in a concise and efficient manner.

Now here is the instruction, the reference answer, and the response.

Instruction:
If all birds can fly, and a penguin is a bird, can a penguin fly?

Reference Answer:
Yes, according to the premise that all birds can fly, a penguin can fly.

Answer:
Yes – under those premises a penguin would be able to fly.

Evaluation: 

提示以Evaluation:结尾,引导模型生成分数。我们来看看gpt-oss:20b模型对这个回答打几分:

result = query_model(rendered_prompt, ollama_model)
print(result)

回答如下:

**Score: 5**

The candidate answer directly addresses the question, correctly applies the given premises, and concisely states that a penguin would be able to fly. It is accurate, relevant, and clear.

可以看到,回答得到了最高分,这很合理,因为它确实是正确的。这只是一个手动演示的简单例子,我们可以把这个思路进一步扩展,写一个循环,用评估数据集里的问题逐个查询模型(比如前面加载的Qwen3模型),通过gpt-oss进行评估,然后计算平均分。你可以在这里找到这样的脚本实现:我们在MATH-500数据集上评估Qwen3模型,地址是https://github.com/rasbt/reasoning-from-scratch/tree/main/chF/04_llm-judge

figure14

图14: Qwen3 0.6基座版与推理版在MATH-500前10道例题上的对比,由gpt-oss:20b担任评审。代码见:https://github.com/rasbt/reasoning-from-scratch/tree/main/chF/04_llm-judge

用过程奖励模型为中间推理步骤打分

和符号验证器、LLM评审器相关的,还有一类被称为过程奖励模型(Process Reward Models,PRMs)的训练模型。和评审器一样,PRMs不止评估最终答案,还能评估推理轨迹;但和通用评审器不同的是,PRMs专门聚焦于推理的中间步骤。而且和验证器不同——验证器通常只在结果层面做符号化的正确性检查——PRMs会在强化学习训练过程中提供逐步骤的奖励信号。我们可以把PRMs归类为“步骤级评审器”,它们主要是为训练开发的,而非纯粹的评估。(实践中,大规模可靠训练PRMs难度很高。比如DeepSeek R1就没有采用PRMs,而是结合了验证器来做推理训练。)

基于评审的评估相比基于偏好的排行榜,优势在于可扩展性和一致性,因为它不依赖大量人类投票者。(从技术上讲,排行榜背后的偏好评级也可以外包给LLM评审器。)但LLM评审器也和人类投票者有类似的弱点:结果会受到模型偏好、提示设计、回答风格的偏差影响。此外,它高度依赖评审模型和评分标准的选择,并且缺乏固定基准测试的可复现性。


结论

本文我们介绍了四种不同的评估方法:选择题测试、验证器评估、排行榜和LLM评审器。

我知道这篇文章很长,但希望它能帮你全面了解LLM的评估方式。这种从零开始的讲解方式可能略显繁琐,但却是理解这些方法底层原理的绝佳途径,反过来也能帮我们发现它们的不足和改进方向。

说到这里,你可能会问:“那评估LLM的最佳方式是什么?”遗憾的是,没有唯一的最优解,因为正如我们所见,每种方法都有不同的取舍。简而言之:

  • 选择题测试

    • 优点:大规模运行速度相对较快、成本较低

    • 优点:跨论文(或模型卡)标准化、可复现

    • 缺点:只衡量基础的知识回忆能力

    • 缺点:无法反映LLM在真实世界中的使用方式

  • 验证器评估

    • 优点:对有标准答案的领域,评分标准化、客观

    • 优点:允许自由形式作答(对最终答案格式有一定约束)

    • 优点:如果使用过程验证器或过程奖励模型,也可以为中间步骤打分

    • 缺点:只适用于可验证的领域(比如数学或代码),并且构建优秀的验证器难度不小

    • 缺点:只看结果的验证器只评估最终答案,不评估推理质量

  • 竞技场式排行榜(人类两两偏好)

    • 优点:直接回答“人们更喜欢哪个模型?”,基于真实场景的提示

    • 优点:允许自由形式作答,并且隐含考虑了风格、实用性和安全性

    • 缺点:对人类来说成本高、耗时长

    • 缺点:不衡量正确性,只衡量偏好度

    • 缺点:人群构成的变化会影响排名稳定性

  • LLM-as-a-judge(LLM评审器)

    • 优点:可跨多种任务扩展

    • 优点:允许自由形式作答

    • 缺点:依赖评审器的能力(集成多个评审器可以提升鲁棒性)

    • 缺点:依赖评分标准的选择

虽然我平时不太喜欢雷达图,但在这里用它来可视化这些不同的评估维度还是很有帮助的,如下图所示。

figure15

图15: 雷达图示意:理想情况下,我们需要从不同维度评估LLM,才能识别它的优势和劣势。

比如,选择题得分高说明模型的通用知识扎实。如果再加上验证器得分高,那模型很可能也能正确回答技术问题。但如果模型在LLM评审器和排行榜评估中表现差,那它可能在写作或清晰表达方面有困难,可以通过RLHF来改善。

所以,最好的评估方式是多维度结合。但理想情况下,还要使用和你的目标或业务问题直接对齐的数据。比如,如果你要部署一个LLM来辅助法律相关工作,那跑一遍MMLU这类标准基准做快速 sanity check 是合理的,但最终你还是要针对目标领域(比如法律)定制评估。你可以在网上找到公开的基准测试作为很好的起点,但最终还是要用自己的专有数据来测试。只有这样,你才能比较有把握地确认模型在训练时没有见过这些测试数据。

总之,模型评估是一个非常庞大且重要的议题。希望这篇文章能帮你理解主流方法的工作原理,也希望下次你看模型评估或者自己做评估时,能从中获得一些有用的洞见。

一如既往,快乐折腾!


这本杂志是我的个人心血之作,你的支持就是它持续更新的动力。

如果你愿意支持我的工作,可以考虑我的这本书《Build a Large Language Model (From Scratch)》(https://amzn.to/4fqvn0D),或者它的续作《Build a Reasoning Model (From Scratch)》(https://mng.bz/Nwr7)。(我相信你会从中学到很多,它们对LLM工作原理的讲解深度是你在别处找不到的。)

感谢阅读,也感谢你支持独立研究!

figure12

《Build a Large Language Model (From Scratch)》现已在亚马逊上架:https://amzn.to/4fqvn0D
《Build a Reasoning Model (From Scratch)》抢先阅读地址:https://mng.bz/Nwr7

如果你读过这本书,能抽出几分钟时间的话,我会非常感谢你在亚马逊留下评价:https://www.amazon.com/Build-Large-Language-Model-Scratch/dp/1633437167 。这对我们作者帮助很大!

你的支持意义重大!谢谢!

【转载】从零理解并实现Qwen3

原文地址:Understanding and Implementing Qwen3 From Scratch,by Sebastian Raschka, on 2025-09-06

从零理解并实现Qwen3

深度解析主流开源大语言模型之一

此前,我在《大语言模型架构大比拼》一文中对比了2025年最具代表性的开源权重架构;随后又在《从GPT-2到gpt-oss:架构演进概念分析》中,从概念层面深入拆解了各类架构组件。

好事成三。在介绍今年夏天值得关注的研究亮点之前,我打算从代码层面动手实践,深入拆解这些架构。跟着本文一步步操作,你就能理解模型的底层运行原理,还能获得可复用的基础模块,适配到自己的实验或项目中。

为此我选择了Qwen3(5月首次发布,7月完成更新)——截至撰文时,它是最受青睐、应用最广的开源权重模型系列之一。

在我看来,Qwen3系列模型广受欢迎的原因如下:

  • 采用对开发者与商业应用友好的开源协议(Apache 2.0许可证),除开源许可证本身条款外无任何附加限制(其他部分开源大模型会额外设置使用约束)。

  • 性能表现优异:截至撰文时,开源权重的235B-Instruct版本在LMArena排行榜上位列第8,与闭源模型Claude Opus 4持平。排名更高的开源大模型仅有两款——参数量是其3倍的DeepSeek 3.1,以及参数量是其4倍的Kimi K2。9月5日,Qwen3在其平台发布了1万亿参数的“max”版本,在所有主流基准测试中均超越Kimi K2、DeepSeek 3.1与Claude Opus 4;不过该模型目前为闭源状态。

  • 覆盖多种模型尺寸,适配不同算力预算与应用场景,从0.6B稠密模型到480B参数的混合专家(MoE)模型一应俱全。

本文篇幅较长,因为包含纯PyTorch从零实现的完整代码。尽管代码部分看起来篇幅较多,但我相信相比单纯的概念示意图,代码能更好地帮你理解各个基础模块的原理。

提示1:如果你是在邮件收件箱中阅读本文,较窄的行宽可能导致代码片段换行错乱。为获得更好的阅读体验,建议在网页浏览器中打开本文。
提示2:你可以使用网站左侧的目录,在各章节间更便捷地跳转。

figure01

图1:本文将用纯PyTorch讲解并复现的Qwen3稠密架构与混合专家(MoE)架构示意图

Continue reading 【转载】从零理解并实现Qwen3

【转载】从GPT-2到gpt-oss:架构演进深度解析

原文地址:From GPT-2 to gpt-oss: Analyzing the Architectural Advances,by Sebastian Raschka, on 2025-08-09

从GPT-2到gpt-oss:架构演进深度解析

包括与 Qwen3 的横向对比

OpenAI 于本周发布了两款全新开源权重大语言模型:gpt-oss-120b 与 gpt-oss-20b。这是自 2019 年 GPT-2 之后,OpenAI 首次推出开源权重模型。而且得益于一系列精巧的优化方案,两款模型均可在本地运行(后文会详细展开)。

这是 GPT-2 之后 OpenAI 首次开源大规模完整权重模型。早期的 GPT 系列模型验证了 Transformer 架构的规模化潜力;2022 年 ChatGPT 的发布则通过在写作、知识问答(以及后来的编程)场景中展现出的实用价值,让大模型真正走向大众。如今,这款备受期待的开源模型终于面世,其架构也有不少值得玩味的细节。

过去几天我通读了模型代码与技术报告,整理出了最核心的亮点。(就在本文发布几天后,OpenAI 又公布了 GPT-5,文末我会结合 gpt-oss 系列做简要讨论。)

本文核心内容概览如下,建议使用文章左侧的目录快速跳转感兴趣的章节:

  • 与 GPT-2 的模型架构对比

  • 助力 gpt-oss 单卡运行的 MXFP4 优化

  • 宽度与深度的权衡(gpt-oss vs Qwen3)

  • 注意力偏置与注意力汇点

  • 基准测试表现及与 GPT-5 的对比

希望本文能为你提供有价值的信息。

Continue reading 【转载】从GPT-2到gpt-oss:架构演进深度解析