# 2.3 多头注意力：为什么多个子空间更好

单头注意力将所有的表示能力集中在一个注意力函数中，但 Transformer 的作者直觉地认为这还不够。多头注意力（Multi-Head Attention）的设计让模型能够同时关注来自不同子空间的不同类型的关系。

## 2.3.1 单头注意力的局限

考虑这样一个句子：“小明在北京的大学里学习计算机科学。”

对于“学习”这个词，至少需要建立以下几种不同的关系：

* **主语关系**：谁在学习？——“小明”
* **地点关系**：在哪里学习？——“北京的大学”
* **宾语关系**：学什么？——“计算机科学”

在单头注意力中，所有这些关系的捕捉都必须通过**同一组 Q、K、V 投影**来完成。这意味着同一个投影矩阵既要捕捉主谓关系，又要捕捉动宾关系，还要捕捉修饰关系——这对单一的线性变换来说是一个过重的负担。

更直观地说：单头注意力产生的注意力权重是一个概率分布，**必须在所有位置之间分配总量为 1 的注意力**。如果“学习”需要同时关注“小明”、“大学”和“计算机科学”三个不同的位置，每个位置能分到的注意力权重就会被摊薄。

## 2.3.2 多头注意力：并行的多视角

多头注意力的解决方案是：**让模型拥有多组独立的 Q、K、V 投影，每组关注一种类型的关系，最后将结果合并。**

数学上，多头注意力定义为：

$$\text{MultiHead}(Q, K, V) = \text{Concat}(\text{head}\_1, \dots, \text{head}\_h)W^O$$

其中每个头独立计算注意力：

$$\text{head}\_i = \text{Attention}(QW\_i^Q, KW\_i^K, VW\_i^V)$$

各投影矩阵的维度为：$$W\_i^Q \in \mathbb{R}^{d\_{\text{model}} \times d\_k}$$，$$W\_i^K \in \mathbb{R}^{d\_{\text{model}} \times d\_k}$$，$$W\_i^V \in \mathbb{R}^{d\_{\text{model}} \times d\_v}$$，输出投影 $$W^O \in \mathbb{R}^{hd\_v \times d\_{\text{model}}}$$。

在原始 Transformer 中，$$h = 8$$ 个头，$$d\_{\text{model}} = 512$$，因此每个头的维度为 $$d\_k = d\_v = d\_{\text{model}} / h = 64$$。

## 2.3.3 为什么多头设计有效

多头注意力的有效性可以从多个角度理解：

**子空间分解的直觉**：每个头在一个较低维的子空间中操作，可以专注于学习一种特定类型的关系模式。研究表明，训练后的不同注意力头确实学到了不同的功能——有些头关注语法依赖（如主谓一致），有些关注邻近位置，有些关注特定的语义关系。

**信息论的视角**：在高维空间中，向量之间的关系非常丰富。将 $$d\_{\text{model}}$$ 维空间分解为 $$h$$ 个 $$d\_k$$ 维子空间，相当于从 $$h$$ 个不同的“视角”来审视同一组数据。每个视角可能捕捉到不同的模式。这与信号处理中的“多通道”概念类似。

**计算代价不变**：一个关键的设计考量是，多头注意力**并不增加总计算量**。虽然有 $$h$$ 个头，但每个头的维度从 $$d\_{\text{model}}$$ 降低到 $$d\_{\text{model}}/h$$。因此：

$$h \times O(n^2 \cdot d\_{\text{model}}/h) = O(n^2 \cdot d\_{\text{model}})$$

总计算量与单头（使用完整 $$d\_{\text{model}}$$ 维度）相同。这意味着多头注意力通过“重新分配”表示能力（而非增加计算量）来获得更好的效果。

## 2.3.4 注意力头的可视化分析

研究者对训练好的 Transformer 模型进行了注意力头的可视化分析，发现了一些有趣的模式：

{% @mermaid/diagram content="graph TD
subgraph head1\["头 1：位置关注"]
a1\["每个词"] -->|"关注"| b1\["邻近的词"]
end

```
subgraph head2["头 2：语法关注"]
    a2["动词"] -->|"关注"| b2["主语"]
end

subgraph head3["头 3：长距离"]
    a3["代词"] -->|"关注"| b3["指代对象"]
end" %}
```

图 2-2：不同注意力头学到的关注模式示意

这些可视化结果验证了多头设计的直觉：**不同的头自发地学习了不同类型的语言关系**，无需人工设定每个头应该关注什么。

> \[!NOTE] **为什么无需人工设定注意力头？**
>
> 1. **自发分工效率更高**：模型在预训练过程中，会通过反向传播自动寻找使预测误差最小化的路径。就如同复杂系统中的劳动分工，注意力头能自发演化出最高效的信息聚合方式，这往往比人类用低维语言学规则（如强制某个头只看代词）所做的约束更灵活、更全面。
> 2. **保留表示学习的自由度**：虽然技术上也能通过“注意力监督（Attention Supervision）”去人为指导各个头的运作方向，但这样反而会限制深度模型在高维隐式空间中的“表示学习（Representation Learning）”能力，削弱它捕捉复杂语义联系的潜力。
> 3. **难以匹配子空间容量**：如果人工硬性分配任务（例如“头 1 专门处理标点符号”，“头 2 专门处理长距离代词指代”），很容易出现“能力与任务不匹配”的问题。不同类型的语义关系所需的表示容量差别巨大，让模型自发学习可以根据难度动态在这些固定大小的子空间（$$d\_k$$ 维度）中分布特征。

## 2.3.5 头数的选择与权衡

注意力头的数量 $$h$$ 是一个需要权衡的超参数。原论文通过消融实验发现：

* **太少的头**（如 $$h=1$$）：无法充分捕捉多种关系模式。
* **太多的头**（如 $$h=32$$）：每个头的维度 $$d\_k$$ 太小（$$512/32=16$$），单个头的表示能力严重不足。
* **适中的头**（如 $$h=8$$）：在原始配置（$$d\_{\text{model}}=512$$）中，子空间维度为 $$512 / 8 = 64$$ 维，这是最优的平衡点。

这个权衡的本质是**专业化程度与单头容量的矛盾**：更多的头意味着更细的专业化分工，但也意味着每个头能操作的维度更少、表达能力更有限。

**基于子空间大小的设计逻辑**

实际上，从工程和架构设计的角度来看，**往往是先根据经验确定一个合适的子空间大小（单头容量），再反推得出头数。**

每个特征子空间需要足够大的维度（通常经验值为 $$64$$ 或 $$128$$）来承载复杂的语言特征。如果子空间太小（如 $$16$$ 维），就会形成信息瓶颈，无法传递丰富的上下文信息。

因此，现代大语言模型（如 GPT-4、LLaMA 等）虽然拥有几十甚至上百个头，但这并非盲目增加视角，而是遵循了以下演进逻辑：

1. **固定单头容量**：设定每个头的维度 $$d\_k$$ 保持在 $$64$$ 或 $$128$$ 左右，以保证单头拥有足够的表示能力。
2. **扩展模型规模**：随着模型总体规模扩大，总维度 $$d\_{\text{model}}$$ 大幅增加（如 LLaMA-2 7B 的 $$4096$$）。
3. **反推计算头数**：头数 $$h$$ 从而随之增加，计算公式为 $$h = d\_{\text{model}} / d\_k$$（例如 $$4096 / 128 = 32$$ 个头）。

总结来说，与其说是人为选择了多少个注意力头，不如说是受限于模型总维度与必需的单头子空间大小。只有当作为分子的大盘子（$$d\_{\text{model}}$$）足够大时，模型才有资本划分出更多的“多头视角”。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/llm_internals/di-yi-bu-fen-ji-chu-pian/02_attention/2.3_multi_head.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.