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

超越标准大语言模型

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

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

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

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

图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等闭源模型也属于这一类别。）

图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的框中，把它们归为同一大类也说得通。）

图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 ）

图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 线性注意力的复兴

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

图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的比例混合，如下图所示。

图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类似：

图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提升梯度流动性和稳定性。）

图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相乘。

图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的核心趋势和设计动机。

图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个使用全注意力的块，如下图所示。

图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生成速度的同时，实现了更高的建模精度。

图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等项目实现、规模化并普及开来。

图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个文本扩散模型！鉴于这类模型的热度日益高涨，我觉得是时候专门聊聊它们了。

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

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

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

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

3.2 去噪过程

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

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

图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）论文中的一个绝佳例子来说明。

图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模型不相上下。等该模型正式发布，用户在不同任务和领域中试用之后，看看它的接受度和反馈如何，将会很有意思。

图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 世界模型的核心理念

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

图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学习模拟代码运行时会发生什么。它被训练来预测执行代码修改等操作后的程序状态，比如变量的值，如下图所示。

图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）。

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

5. 小型递归Transformer

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

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

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

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

图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基准上的表现甚至更优。

图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表现非常出色，如下图所示。

图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从零搭建所有组件。

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

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

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

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

---

理解LLM的主流评估方法

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

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

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

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

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

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

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

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

图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展示的思路一致，为方便阅读，下图再次放出。

图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 datasets 或 uv 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 。

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

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

选择题作答的其他形式

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

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

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

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

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

---

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

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

图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 。）

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

---

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

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

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

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

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

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

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

图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 。

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

---

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

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

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

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

图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所示。

图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 。

图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评审器）

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

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

  • 缺点：依赖评审器的能力（集成多个评审器可以提升鲁棒性）

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

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

图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工作原理的讲解深度是你在别处找不到的。）

感谢阅读，也感谢你支持独立研究！

《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 。这对我们作者帮助很大！

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