音乐生成中的等变Transformer：从架构层面解决转调泛化问题

如果你做过 AI 作曲或者音乐生成，大概率遇到过这种问题：同一个旋律，从 C 调改成 D 调，模型生成的伴奏和和弦走向就可能崩掉。旋律并没有变得更复杂，音高只是整体平移了一点点，模型却表现出了“不认识”的态度。

这不是某一个模型实现得不好，而是通用 Transformer 生成音乐时的一个结构性问题：模型把音高和位置当作独立的信息去记忆，转调之后每个 token 都变了，但曲子内部的相对关系其实完全没变。传统做法是拼命扩充数据，把各种调的乐曲都喂进去，让模型“看多了就学会”。而等变（Equivariance）视角给出的答案更彻底：这种对称性不应该靠数据慢慢学，应该直接在架构层写死。

Equivariant Music Transformer 就是这样一个方向。它把转调、平移这类音乐中天然存在的对称操作，作为约束条件嵌入 Transformer 结构，让模型在数学层面尽可能满足“输入先变换再计算”等于“先计算再对输出变换”。这篇文章会用尽量通俗的方式拆解它的核心原理，并给出一套可运行的 PyTorch 验证示例，帮助你理解如何用代码衡量一个音乐 Transformer 是否对转调保持稳定。

读完之后，你会理解：等变性和不变性的区别，音乐 Transformer 为什么很难跨调泛化，位置编码与对称性之间的关系，以及怎么用几十行代码验证一个模型是否真的对转调“不变形”。

1. Equivariant Music Transformer 解决的是什么问题

音乐生成和自然语言生成有一个本质差异：语言序列的合理替换往往是离散且稀疏的，而音乐中的音高平移是稠密的、结构性的。把一首曲子整体升两个半音，它的旋律轮廓、和弦功能、节奏骨架统统不变，只是“底座”变了。这种变换在数学上叫群作用，在音乐术语里就是转调。

大多数音乐生成模型把这个问题交给了数据。训练集里 C 调、D 调、E 调的曲子各来一批，模型靠统计规律硬学出一种近似不变性。问题在于，这种从数据里“悟”出来的对称性是不可靠的：

• 长尾调式覆盖不足，模型遇到不熟悉的调仍然会犯错；
• 数据和参数规模变大，代价成倍增加；
• 即使单个调内部学得不错，组合到和弦进行、旋律模进时仍然可能结构崩坏。

Equivariant Music Transformer 想做的事情，是把对称性从“训练时希望模型学到的性质”变成“模型结构自带的性质”。用一句直白的话说：让模型在数学上就没办法区分一个旋律和它的移位版本，除非你额外告诉它当前的调中心在哪里。

这个方向的受众很明确。如果你正在做自动作曲、旋律生成、和弦标注、音乐信息检索，或者只是对“如何把先验知识注入 Transformer”感兴趣，这篇文章都值得读下去。它不要求你有很深的理论背景，但需要你熟悉 PyTorch 的基本用法。

2. 等变性（Equivariance）：从对称性到网络结构

2.1 先理解对称性

说“对称性”可能有点抽象，换个说法：存在某一类变换，作用在输入上之后，系统的行为是可预测的。比如一张图片左右翻转，图片里的物体类别不变；一段旋律整体上移三度，旋律的“身份”不变。

在数学里，这类变换集合构成一个群（Group）。群不只描述“有哪些变换”，还描述“变换之间怎么复合”。对音乐来说，最典型的群是循环平移群：对每个音高 token 加上同一个偏移量，得到一个转调版本。偏移量可以是正数、负数，可以复合两次，本质上都在同一个群里面。

2.2 等变和不变的区别

这是最容易混淆的一组概念。很多文章把它们混在一起讲，但应用到模型设计时，区别非常关键。

如果模型的任务是给一段音乐标注调性，那它需要的是不变性：C 调的卡农和 D 调的卡农，都该被识别为“卡农”。但如果模型的任务是生成下一段音符，那么 C 调卡农生成的下一句，转到 D 调后也应该正好是 D 调卡农的下一句。这时要求的是等变性。

等变性不是更强或更弱，而是更精确。它要求模型“理解”变换，“配合”变换，而不是“无视”变换。

2.3 音乐里还有哪些对称性

转调是最直观的对称性，但不是唯一的：

• 音高平移：所有音符整体升或降若干半音；
• 时间平移：把整段序列向右移动若干拍，输出也应该整体右移；
• 时间反转：把旋律倒放，对应到模型上是序列反转操作；
• 节奏缩放：把时值统一乘一个比例，属于更复杂的标度对称。

大多数音乐生成任务中，最值得先做的是音高平移等变和时间平移等变。原因很实际：这两类变换在音乐里最常见，也最容易在 token 层面定义清楚。Equivariant Music Transformer 的切入点，通常也是围绕这两类对称性展开的。

3. Transformer 做音乐生成的瓶颈在哪里

要理解为什么“等变 Transformer”有价值，得先回到普通 Transformer 做音乐生成时的薄弱环节。

3.1 音乐如何变成 token

和文本一样，音乐也需要先 token 化。常见做法是把 MIDI 事件切分成音符、节拍、速度等离散符号，组成序列。比如用类似[BOS, note_on_60, note_off_60, note_on_62, ...]这样的格式，或者用 REMI 这类专门为音乐设计的 token 方案。

不管采用哪种 token 化方案，一个核心事实不会变：模型看到的是一串整数 ID。音高 60 和音高 62 在 token 空间里只是两个不同的整数，模型并不会天生知道它们之间只差一个“音高移位”。

3.2 绝对位置编码的问题

普通 Transformer 使用绝对位置编码，给序列中每个位置分配一个固定的向量。这个设计在文本里问题不大，因为文本中“第 5 个词”通常有意义；但音乐里的位置关系往往是相对的：一个强拍相对前面的弱拍出现，一组旋律音相对一组和弦音运动。

更麻烦的是，绝对位置编码不满足平移等变性。把输入序列整体往后挪一位，位置向量全部变了，模型内部的计算结果也变了。这是否一定不好？不一定。音乐里确实存在“绝对位置”信息，比如小节号、节拍位置，这些都是有用的先验。但当模型需要在不同调上泛化时，绝对位置编码会导致训练数据里没有出现过的“位置组合”成为空洞，模型只能硬猜。

3.3 数据增强为什么不彻底

很多项目的第一反应是：我把训练数据里的所有曲子都做几个调性的移调，问题不就解决了吗？数据增强确实有效，但它只是“经验性”地让模型更接近等变，不是“结构性”地保证等变。

原因很简单：数据增强改变的是训练分布，而不是模型函数族的表达能力。模型仍然可以学习到一个非等变的映射，只是由于训练数据的覆盖，在常见输入上表现接近等变。一旦遇到训练分布之外的组合，比如新的调式、特殊的和弦进行、超长的旋律片段，模型就可能“原形毕露”。

等变设计的价值，就是把这种“经验性接近”升级为“结构性约束”。模型不需要重新学转调规则，因为它的结构本身就兼容转调。

4. Equivariant Music Transformer 的核心设计思路

这个方向没有一个官方唯一实现，不同论文和工程项目的做法会有差异。但从思路来看，核心设计基本围绕以下几层。

4.1 在 token 空间定义群作用

先把对称性落到具体实现上：转调作用在 token ID 上，就是一个偏移量shift。输入序列x变成x + shift，输出序列的期望也变成原来的输出y + shift。这是整条验证逻辑的起点。

这里要特别小心特殊 token。序列里的BOS、EOS、休止符、速度标记，并不应该参与音高平移。所以真实系统里，群作用不是简单地对所有 token ID 做加法，而是只作用在“音高类 token”上，其他 token 保持不变。这个细节很容易被新手忽略，导致验证数据全都对不上。

4.2 输入输出共享嵌入

Transformer 的嵌入层（Embedding）把 token ID 映射成向量，输出层再从向量映射回 token ID。如果输入输出使用两组独立参数，那就意味着“音高 60”在输入端的表示和“预测音高 60”在输出端的表示不共享，转调前后的一致性没有结构保障。

一个成本极低的改进是权重绑定（Weight Tying）：让输出投影矩阵的权重直接等于输入嵌入矩阵。这样模型的输入空间和输出空间共用同一个“音高语义空间”，转调操作在两端的作用方式天然一致。这不是完整方案，但它是工程上最容易落地的一步。

4.3 相对位置编码与旋转位置编码

绝对位置编码破坏平移等变，那换成相对位置编码呢？相对位置编码让注意力的计算只依赖两个 token 之间的相对距离，而不是它们在序列里的绝对位置。这样，整个序列平移若干个时间步，注意力的计算结果不变。这一步能显著提升时间平移等变性。

旋转位置编码（RoPE）是另一个被广泛采用的做法。RoPE 把位置信息编码成旋转矩阵，作用在 query 和 key 上，注意力最终只依赖相对位置。它在语言模型里已经是大规模验证过的方案，用在音乐序列上同样有助于时间维度的等变。

不过有一点要提醒：时间平移等变和音高平移等变是两件不同的事。RoPE 解决的是时间维度，音高维度的等变需要在 token 语义上做文章，比如上面说的共享嵌入、音高区间归一化、以及注意力权重的音高相对距离设计。

4.4 注意力机制的等变约束

Transformer 的自注意力主体是置换等变的：如果把输入序列的顺序打乱，注意力的输出也会按同样的顺序打乱。这意味着，在没有位置编码的极端情况下，循环平移会被当作一种特殊的置换，模型自然“等变”。问题是模型同时也失去了顺序信息，音乐就没法生成了。

所以设计难点在于：既要保留相对顺序信息，又不让绝对位置信息破坏对称性。实践中通常是把“相对位置”和“绝对调性”分开表示。模型主体只依赖相对关系，而把真实的调中心通过一个全局条件向量（比如调性 embedding）提供给模型。这样模型既知道“现在是什么调”，又不需要在结构上为每一种调单独再学一套映射。

4.5 与数据增强、条件生成的关系

结构等变不等于完全放弃数据增强。更合理的组合方式是：

1. 结构上保证模型函数族“天生偏向等变”；
2. 训练时仍然做适量的移调增强，覆盖边界情况；
3. 推理时通过条件信息告诉模型当前调中心，避免生成结果“过度平均”。

这也是为什么我不能说“等变就万事大吉”。等变保证的是变换的一致性，但音乐生成仍然需要模型知道“这首曲子当前落在哪个绝对调性上”，否则所有调的音乐都会被生成成同一个中性的音高范围。这个信息可以通过条件输入注入，而不是让结构去强行记忆。

5. 环境准备与最小验证示例

到这里，我们用代码验证一下“一个模型是否对转调等变”。这个示例不追求实现完整可用的作曲模型，而是给出一套可复用的验证框架。你可以用它来评估自己的实验模型，也可以把它作为改造模型时的测试基准。

5.1 环境准备

建议环境如下：

• Python 3.9 及以上；
• PyTorch 2.x，本文示例使用torch和torch.nn.TransformerEncoder；
• 如果希望处理真实 MIDI 数据，可以另外安装mido或music21，本示例不需要。

安装 PyTorch 的命令和常规项目完全一致，具体版本请以你的 CUDA 环境为准：

pip install torch --index-url https://download.pytorch.org/whl/cu118

如果只是在 CPU 上跑验证逻辑，直接安装默认版本即可：

pip install torch

注意：本示例不需要外部音乐数据集，所有输入都是随机生成的 token 序列，目的是验证等变误差计算方式，而不是训练一个完整模型。

5.2 核心验证代码

我们把验证逻辑拆成三步：

1. 定义一个转调操作，作用于 token 序列；
2. 定义一个简化的音乐 Transformer 模型；
3. 计算f(g·x)和g·f(x)之间的误差。

为了演示群作用，这里假设 token 集合就是 MIDI 音高 0 到 127，转调通过循环移位模拟。真实系统里需要把特殊 token 排除在转调之外，我们会在第 7 部分讨论。

import torch import torch.nn as nn def transpose_tokens(x, shift): """ 对音符 token 序列做整体音高平移。 注意：这里用 torch.roll 做循环移位，只是为了演示群作用； 真实系统中需要对特殊 token 单独处理，不能直接 roll。 """ return torch.roll(x, shifts=shift, dims=1) def roll_logits(logits, shift): """ 对应地对输出 logits 的类别维度做循环平移。 如果模型具备转调等变性，则： model(transpose_tokens(x, shift)) == roll_logits(model(x), shift) """ return torch.roll(logits, shifts=shift, dims=-1) class SimpleMusicEncoder(nn.Module): """ 一个极简音乐 Transformer 编码器。 输入是 (batch, seq_len) 的 token 序列，输出是每个位置的 logits。 """ def __init__(self, vocab_size, d_model=64, nhead=4, num_layers=2, max_len=256): super().__init__() self.vocab_size = vocab_size self.embed = nn.Embedding(vocab_size, d_model) self.pos = nn.Parameter(torch.randn(1, max_len, d_model) * 0.02) encoder_layer = nn.TransformerEncoderLayer( d_model=d_model, nhead=nhead, batch_first=True, dim_feedforward=128, dropout=0.0 ) self.encoder = nn.TransformerEncoder(encoder_layer, num_layers=num_layers) self.out_proj = nn.Linear(d_model, vocab_size, bias=False) # 输入输出共享嵌入，是等变设计里成本最低的一步 self.out_proj.weight = self.embed.weight self.max_len = max_len def forward(self, x): seq_len = x.size(1) h = self.embed(x) + self.pos[:, :seq_len, :] h = self.encoder(h) logits = self.out_proj(h) return logits class NoPosEncoder(SimpleMusicEncoder): """ 去掉绝对位置编码的版本，用于对比实验。 注意：这个版本在音乐生成里不可用，因为它丢失了顺序信息； 这里只是用它说明“位置编码会影响等变误差”这个现象。 """ def forward(self, x): h = self.embed(x) h = self.encoder(h) logits = self.out_proj(h) return logits def equivariance_error(model, x, shift): """ 计算某个转调偏移量下的均方等变误差。 误差越小，说明模型在这个 shift 下的行为越接近严格等变。 """ with torch.no_grad(): logits_orig = model(x) logits_shifted_input = model(transpose_tokens(x, shift)) expected = roll_logits(logits_orig, shift) error = (expected - logits_shifted_input).pow(2).mean() return error.item() if __name__ == "__main__": torch.manual_seed(42) vocab_size = 128 # MIDI 音高 0~127 batch_size = 4 seq_len = 32 model_with_pos = SimpleMusicEncoder(vocab_size=vocab_size) model_without_pos = NoPosEncoder(vocab_size=vocab_size) x = torch.randint(0, vocab_size, (batch_size, seq_len)) print("=" * 60) print("Equivariance Error Comparison") print("=" * 60) for shift in [1, 3, -2, 7]: err_pos = equivariance_error(model_with_pos, x, shift) err_no_pos = equivariance_error(model_without_pos, x, shift) print(f"shift={shift:3d} | with pos: {err_pos:.6f} | without pos: {err_no_pos:.6f}")

代码里的NoPosEncoder刻意做得“过拟合”到等变：因为没有位置编码，模型只依赖 token 本身的信息，循环平移作为一种置换会被 Transformer 的置换等变性自然消化。这个对比能让你直观看到，绝对位置编码是破坏时间平移等变的主要因素。

但请注意：NoPosEncoder不能用来生成音乐。这个对比要说明的不是“去掉位置编码更好”，而是“单纯追求等变误差降低没有意义，必须在保留序列信息的前提下设计对称性”。

5.3 代码关键逻辑解释

• transpose_tokens是群作用在输入空间的实现。用torch.roll能让边界 token 也参与循环，避免 clamp 带来的边界不对称。
• roll_logits是群作用在输出空间的实现。它把模型输出的类别分布整体平移。
• SimpleMusicEncoder里最重要的两个设计：绝对位置编码用于保留顺序信息；输入输出共享嵌入用于统一音高语义空间。
• equivariance_error计算的是两个输出之间的“距离”。理想等变模型应该让这个距离接近 0。

6. 运行结果与效果判断

运行上面的代码，你会在控制台看到类似下面的输出：

============================================================ Equivariance Error Comparison ============================================================ shift= 1 | with pos: 0.xxxxxx | without pos: 0.xxxxxx shift= 3 | with pos: 0.xxxxxx | without pos: 0.xxxxxx shift= -2 | with pos: 0.xxxxxx | without pos: 0.xxxxxx shift= 7 | with pos: 0.xxxxxx | without pos: 0.xxxxxx

具体数值会因为 PyTorch 版本、随机种子、运行设备不同而有差异，这不重要。重要的判断方法是：

• 对比with pos和without pos两列误差。通常without pos会明显更小，因为它完全牺牲了顺序信息，换取了对置换的高度等变。
• 如果with pos的误差在多个 shift 上都比较分散，说明绝对位置编码让模型对不同平移量产生了不同的敏感性。
• 检查模型是否真的可用于音乐生成，要看它是否保留了“相对顺序”信息，而不是只看等变误差数字。

如果运行报错，先检查两点：

1. 是否使用了较新的 PyTorch 版本。batch_first=True在 PyTorch 1.9 之后才稳定可用，建议使用 2.x。
2. 是否由于d_model=64、nhead=4导致注意力头维度非整数。这个组合是整除的，如果你改小了d_model，要注意保证d_model能被nhead整除。

7. 常见问题与排查思路

8. 工程实践与训练建议

8.1 不要只盯等变误差

等变误差是一个有用的诊断指标，但不是唯一的训练目标。模型可以在结构上非常等变，生成出来的音乐依然无聊且生硬。因为音乐的好坏不只取决于“转调是否一致”，还取决于旋律的流畅度、节奏的张力、和声的丰富度等。

正确的用法是：把等变误差当作“健康指标”之一，长期监控。如果它随训练波动很大，说明模型对转调不稳定，需要检查数据结构或训练设置。

8.2 真正落地的 token 处理

真实 MIDI token 里，音高 token 只占一部分。工程上建议在数据预处理阶段就给每个 token 打上类型标签，并在实现群作用时按标签区分：

def transpose_tokens_safe(x, pitch_mask, shift): """x: token 序列；pitch_mask: 标记哪些位置是音高 token。""" x = x.clone() x[pitch_mask] = x[pitch_mask] + shift # 按需 clamp，避免超出 MIDI 音高范围 x[pitch_mask] = torch.clamp(x[pitch_mask], 0, 127) return x

这里只是示意。更符合消息队列语义的做法是给transpose函数传入一个“音高区间”参数，把音乐域内可平移的 token 范围写清楚。

8.3 用转调测试集做评估

训练之外，建议固定一个“转调测试集”：选取若干首旋律，对每一首生成多个调的版本，分别喂给模型，检查输出之间的转调一致性。

def evaluate_transposition(model, dataloader, shifts=(0, 2, 5, 7)): """ 在转调测试集上评估模型的转调一致性。 返回值越高，说明模型对转调的泛化越稳定。 """ total_tokens = 0 correct_tokens = 0 model.eval() with torch.no_grad(): for x, y in dataloader: base_pred = model(x).argmax(dim=-1) for shift in shifts: x_shift = transpose_tokens_safe(x, shift) y_shift = transpose_tokens_safe(y, shift) pred_shift = model(x_shift).argmax(dim=-1) correct_tokens += (pred_shift == y_shift).sum().item() total_tokens += y_shift.numel() return correct_tokens / max(total_tokens, 1)

这个指标比只看生成音频更客观：如果模型对不同调的表现差异很大，说明等变约束还没做到位。

8.4 与数据增强搭配

结构等变和移调增强不冲突。移调增强能帮助模型处理边界情况，比如音高接近上下限时的截断行为，以及不同八度区域之间的写作风格差异。建议在训练时保留一个较小的移调增强概率，比如 20% 到 40%，而不是完全依赖结构约束。

8.5 采样时的约束

推理阶段不要对输出 logits 直接做roll。生成是自回归的，每一步的采样结果会进入下一步输入。如果你的模型只在训练时见过某个音高范围，推理时把 logits 强行平移到边界外，反而会让生成质量下降。更稳妥的做法是给采样函数加上音高范围约束，把最终输出限制在合理区间内。

9. 总结与后续学习方向

这篇文章想传递的核心判断是：音乐生成里的“转调泛化”问题，不能只靠数据增强硬扛，应该把对称性设计进 Transformer 结构里。等变性提供了一套准确的数学语言，帮助我们描述“模型应该如何响应输入变换”，也提供了一套可计算的验证指标，让我们能直接量化一个模型是不是真的对转调稳定。

如果你正在做音乐生成，建议先从两个简单动作开始：一是把输入输出嵌入共享，二是在模型内部使用相对位置编码替代绝对位置编码。这两个改动成本很低，但会显著改善模型对转调和平移的泛化表现。然后，用本文的等变误差验证框架测试改动前后的差异，再根据结果决定是否引入更强的群约束。

如果还想继续深入，值得研究的方向包括：旋转位置编码（RoPE）在音乐序列上的性质、等变图神经网络与音乐结构建模的结合、以及如何在生成模型中同时处理音高平移等变和时间伸缩等变。从 Vision Transformer 到 Swin Transformer，再到音乐领域的 Equivariant Music Transformer，Transformer 的改进思路其实一脉相承：把领域里真正重要的先验，用结构化的方式放回网络里，而不是指望模型从海量数据里自己猜出来。