简介基于机器学习的自动音乐生成软件核心采用长短期记忆网络模型代替常见的简单循环神经网络与WaveNet方案在最少人为干预下生成一段短曲并播放缓解同质化问题。资源面向深度学习与音乐生成交叉方向的学习者适合作为课程设计、毕业设计或算法实验参考也适合对人工智能作曲感兴趣的开发者动手实践。压缩包共八个文件约四百六十六KB包含两个交互式笔记本程序、一个Python脚本、一份详细设计说明书PDF以及许可证和使用说明文件结构清晰可对照代码与文档逐步学习。目前已有二百三十九人学习下载。通过源码与说明文档可理解长短期记忆网络在音乐生成任务中的建模与训练流程复现钢琴风格自动作曲示例并学习优化生成效果的思路帮助从入门到进阶的实践。1. 基于机器学习的自动音乐生成优化为什么“能响”和“好听”之间隔着一整个调参工程自动音乐生成这个方向听起来像是让模型随便编一段旋律就完事但真正做过的人都知道模型跑通一个 demo 可能只要一晚上让输出的音乐能听、不炸音、有结构感却要在这个基础上再投入数倍的时间。这里面的差距就在于“生成”和“优化”之间的那条鸿沟。基于机器学习的自动音乐生成优化本质上解决的是三个问题用什么模型结构去建模音乐的时间序列依赖用什么数据形式和损失函数让模型真正学到音乐性以及用什么解码策略让生成结果不塌、不糊、不无聊。这篇文章不会泛泛讲音乐生成的历史而是直接按我在实际项目中验证过的路径来拆解选型思路、数据预处理、训练调参、踩坑记录以及最后落到可控生成和推理效率上的技巧。这篇文章适合的人有两大类一类是刚接触生成式 AI想用机器学习做音乐生成但不知道从哪个模型下手的开发者另一类是已经跑通过一个音乐生成管线、但生成结果总是“差点意思”想找到优化方向的研究生或算法工程师。如果你只是好奇 AI 作曲的原理那这篇可能偏工程了一些但如果你要的是能动手改代码、看得到效果提升的操作路径那这篇正合适。2. 音乐生成的技术路线选型符号生成、音频生成与混合方案的取舍2.1 符号生成为什么是多数团队的第一站自动音乐生成在技术路线上第一个分岔口就是“生成什么”。符号生成指的是让模型直接输出音乐符号层面的内容最常见的就是 MIDI 序列。你看到的可能是音符编号、时长、力度、速度标记但本质上是让模型在离散的符号序列上做预测。这条路线的最大优点是训练和评估都比较干净数据容易获得MAESTRO、Lakh MIDI Dataset 这类数据集里几十万首 MIDI 文件可以直接用而且生成结果的错误模式更可解释——某个音符不合理你能明确指出来是 pitch 预测错了还是 duration 崩了。符号生成的主流模型结构早期是 LSTM现在基本被 Transformer 系列接管。Transformer 在音乐上的应用比文本要晚一些核心原因是音乐序列不只是“下一个词”那么简单。一段旋律里同时存在水平方向的和弦进行和垂直方向的多声部关系所以单纯把音符拍扁成一维序列会丢失声部信息。常见的做法是把每个时间步上同时发生的音符打包成一个“事件”或者用复合 token 表示“此刻在响的所有音高”这属于数据表示层面的工程但选型的正确与否直接影响后续能否优化。如果要在符号生成里选一个入门成本最低的组合我会推荐用 Transformer 解码器加 MIDI-like tokenization。输入是音高、时长、速度三类 token 拼成的序列输出是下一个 token 的分布。这个方案符合你“用机器学习自动生成音乐”的最小闭环定义代码量可控训练资源要求低而且优化空间大——后面要讲的损失函数改造、解码策略调整都是在这个基础上做的。2.2 音频生成路线从频谱到波形的距离符号生成的问题也很明显它生成的 MIDI 没有音色没有演奏细节。如果一个项目要落地到“直接出可听的音乐片段”符号生成还得再接一个音源渲染环节这个环节会在一定程度上磨掉生成结果的特色。音频生成路线则是让模型直接输出音频要么输出频谱图再做声码器恢复波形要么像一些较新的模型那样直接输出波形采样点。音频生成的主流做法是频谱生成加声码器的两段式。模型先生成 mel 频谱图本质上是把音频压缩成 80 到 128 个频带的能量随时间变化的二维图再用 HiFi-GAN 之类的声码器把它恢复成波形。这条路线的效果上限更高生成的音乐在听感上更接近“音乐录音”而不只是“乐谱演奏”但代价也非常具体数据量需求大、训练时间成倍增加、生成结果不可解释。频谱上的一个小噪点恢复成波形可能就是一声刺耳的爆音。对于大多数做优化工作的团队我一般不建议直接从纯音频路线开始。更稳妥的结构是符号为主、音频为辅的混合方案先用符号模型生成旋律与和弦结构再用一个基于频谱的模型做人声或主奏乐器的音色渲染。这样你可以把优化重点放在音乐结构上而不是浪费大量算力在波形生成的稳定性上。后续要优化听感时再单独替换音频侧模型不必推倒重来。2.3 选型决策表与优化重心预判对比维度符号生成音频生成混合方案数据获取难度低公开 MIDI 数据充足高需要成对音频与标注中等训练资源消耗单卡可跑多卡集群更现实按阶段分配资源生成结果可解释性高错误可定位低问题难追溯中听感上限受限于音源渲染高接近真实录音高适合的优化方向结构逻辑、旋律质量音色、混音、表现力综合性最优选型做完之后优化重心也就跟着定下来了。符号生成的重心在序列建模和采样策略音频生成的重心在声码器匹配和频谱重建损失。我见过不少项目在选型阶段犹豫过久其实不用太纠结先跑通一个能听结果的最小闭环比什么都有说服力。后面做的所有优化都是在这个闭环上做增量。3. 把 MIDI 变成模型能学的语言数据处理与特征工程的两套方案3.1 方案一事件序列化 tokenizer 与最小实现数据处理是音乐生成项目里最容易被低估的环节。原始 MIDI 文件不能直接喂给模型你要先把音符、时长、速度、休止符这些信息转成整数 token 序列。我常用的方法是把每个音符拆成三个事件NOTE_ON 表示某个音高开始发声NOTE_DURATION 表示持续时长NOTE_VELOCITY 表示力度。这样模型序列里每个音符占三个 token 位置虽然序列变长了但每个维度的独立预测难度反而下降对后续优化更有帮助。下面是这个 tokenizer 的最小实现可以直接在本地数据集上跑通import midiutil from pathlib import Path def midi_to_event_tokens(midi_path: str, time_step: int 10) - list: 将 MIDI 文件转换为事件 token 序列。 time_step 是时间量化单位单位是 tick10 表示每 10 tick 一个时间步。 from midiutil import MIDIFile from mido import MidiFile mid MidiFile(midi_path) tokens [] current_time 0 for msg in mid: if msg.type note_on and msg.velocity 0: # 音符开始记录音高和力度 tokens.append({ type: NOTE_ON, pitch: msg.note, velocity: msg.velocity, time: current_time }) elif msg.type note_on and msg.velocity 0: # 有些 MIDI 用 velocity0 表示音符结束 tokens.append({ type: NOTE_OFF, pitch: msg.note, time: current_time }) elif msg.type note_off: tokens.append({ type: NOTE_OFF, pitch: msg.note, time: current_time }) # 按时间排序并量化到 time_step tokens.sort(keylambda x: x[time]) quantized [] for token in tokens: token[time] (token[time] // time_step) * time_step quantized.append(token) return quantized这段代码的逻辑里有几个参数值得注意。time_step10是这个方案里最关键的参数它决定模型能感知的最小时间粒度。取值太小会让序列过长训练成本上升且注意力机制难以捕捉长程依赖取值太大则会丢失音符的起始精度导致生成的节奏听起来“对不上拍子”。我一般先从 10 到 30 之间试看生成结果的节奏规整度再做调整。量化方式是直接向下取整你可以改成四舍五入但要注意量化到同一时间步的 NOTE_ON 事件在后续转回 MIDI 时可以合并为和弦这个合并逻辑要单独处理。3.2 方案二复合 token 编码与对比分析事件序列化方案的问题在于序列太长一段三分钟的音乐轻松生成上万个 tokenTransformer 的自注意力复杂度是序列长度的平方训练和推理都会变慢。另一个方案是复合 token 编码它把同一时间步上发生的所有音符打包成一个 tokentoken 内部用位掩码或集合表示音高组合。比如用长度为 128 的向量表示音高域响应的位置置 1其余置 0这样 128 个音高就是一个 16 字节的编码一个时间步只产生一个 token序列长度大幅缩短。这个方案的数学表示是设时间步 t 的 token 为集合 S_t {p_1, p_2, ..., p_k}表示此刻同时发声的音高集合。模型要预测的是 P(S_t | S_{t-1}, S_{t-2}, ..., S_{t-n})即给定历史时间步的音符集合预测当前时间步会响哪些音。和事件序列化方案相比复合 token 生成的音符天然是对齐的不会出现“某个音高提前半拍进入”这种毛刺而且序列长度降了一个数量级训练速度提升明显。但复合 token 也有代价。它天然不具备表达声部独立性的能力——两个乐器在同一个时间步各弹各的旋律编码后混在同一个集合里模型无法区分这是两件乐器的独立线还是刻意写成的和弦。如果在你的项目里声部独立性是必须保留的属性那复合 token 就不适合。它对“主旋律加伴奏”这类简单织体很友好对复调音乐就很吃力。做选择时你可以先看数据集的音乐织体复杂度再决定用哪种方案。3.3 数据增强与序列切分的边界问题数据处理的另一个关键环节是训练序列切分。一首完整的音乐可能有几千个 token直接整首喂给模型显存会炸而且注意力机制很难跨越大跨度捕捉全局结构。常见做法是滑动窗口切分窗口长度设 512 或 1024 个 token步长设为窗口的一半让相邻片段有重叠避免旋律在切割点处被生硬截断。重叠窗口的一个隐蔽坑是数据泄漏。如果训练集和验证集来自同一首歌切分后相邻窗口内容高度重合验证损失会虚低。我一般会在切分之前先把 MIDI 文件按曲目分好组确保同一个曲目的所有窗口只进入训练集或只进入验证集不做跨集合混合。这个细节看起来不起眼但直接影响你对模型是否过拟合的判断。另一个实用技巧是数据增强把 MIDI 整体平移几个半音或者把速度整体缩放 0.95 到 1.05 倍。这个操作不会改变音乐的本质结构但能有效增加数据的多样性在数据量有限时是个性价比很高的增强手段。4. 模型训练与损失优化从交叉熵到音乐性指标4.1 基线模型与训练基础配置数据处理完之后模型训练就是下一个核心环节。基线模型我推荐直接用标准 Transformer 解码器不引入太多自定义结构。层数设 6 到 8 层隐藏维度 512注意力头数 8。这个配置在单张消费级显卡上可以完成训练而且能作为后续所有优化实验的对照基准。如果你直接用更大的模型起步遇到问题时很难判断是模型容量不够还是训练策略有问题基线先跑通的意义就在于此。训练损失默认是交叉熵即预测下一个 token 的分布与真实 token 的交叉熵。这个损失对于音乐生成来说有天然缺陷它把所有 token 类型一视同仁。但在音乐里预测错一个音高和预测错一个力度严重程度完全不同。音高错了可能造成不协和音程力度错了只是轻微的情绪偏差。这个缺陷后面会在优化环节处理先按默认配置把基线跑通拿到一组可复现的损失曲线和生成样本再开始优化。4.2 损失函数优化的三个方向交叉熵优化到一定程度后生成的音乐在 token 层面已经很“正确”了但听起来仍然平淡。这时候要动手改损失函数我踩过三个可复用的方向第一个方向是分类型加权损失。把音高、时长、力度三类 token 的损失分开计算并按重要性赋权。比如音高的权重是 1.0时长 0.8力度 0.5。实现时不要直接改损失函数接口而是在计算交叉熵之前按 token 类型对 logits 和 labels 做掩码分别取均值再加权相加。这样做的原因是模型会自然偏向预测分布更均匀、样本量更大的类别加权可以纠正这种偏差。第二个方向是加入对比损失。音乐生成的一个顽疾是“均值回归”模型生成的旋律总是趋向于音高变化小、节奏单一的保守模式。对比损失的思路是把当前生成片段和训练集中一个类似片段做正样本对和随机片段做负样本对让模型学到的表示空间拉开正负样本的距离。这个策略的训练成本不高但对生成结果的多样性提升非常明显。第三个方向是强化学习微调。用交叉熵训练出的模型生成的音乐虽然合理但不一定符合人的主观听感。强化学习的做法是让模型生成完整序列然后用一个奖励模型打分再通过策略梯度更新模型参数。奖励模型可以是一个预训练的音乐情感分类器也可以是规则打分函数——比如检测和声进行是否在常见调性内、节奏变化是否丰富。这属于进阶优化一般放在基础损失优化之后做见效更直接但也更容易过拟合需要在训练中加 KL 散度约束避免模型为了高分牺牲多样性。4.3 训练策略里的关键可调参数除了损失函数训练策略里还有几个对生成效果影响很大的参数值得反复调。第一个是学习率预热步数。音乐序列比文本序列更长训练早期梯度噪声更大预热步数设得太短模型很容易在起步阶段就走偏。我从实际项目里验证的经验是预热步数在 4000 到 8000 之间比较合理具体看序列长度和 batch size。第二个是 batch size 与梯度累积步数。如果你用的是复合 token 编码batch size 可以适当增大因为序列短了如果是事件序列化单条序列很长显存压力大用梯度累积模拟更大的 batch size 是常见做法。每累积 4 步更新一次参数效果等价于把 batch size 放大 4 倍但要注意学习率要相应调低否则收敛不稳定。第三个是权重衰减系数。Transformer 模型在音乐生成任务上容易过拟合训练集里的常见节奏型权重衰减设太小会导致生成结果重复性极高设太大又会欠拟合、旋律变得杂乱。我用的范围是 0.01 到 0.1最终选 0.05 的居多。这个参数需要配合验证集上的多样性指标一起看比如统计生成样本里相邻音符音高差绝对值大于 3 的占比占比太低说明模型在复读。4.4 训练过程的检查点与评估回调训练不能只看训练损失下降就认为万事大吉还要在验证集上做评估。我常用的做法是每训练 1000 步做一次验证集损失计算并同时生成一小段样本保存为 MIDI 文件。听到样本里的问题往往比看到损失曲线更直观——损失在下降但生成结果全是同一个音说明模型退化成死循环这时候需要检查注意力权重是否出现了均匀化及时调 dropout 或权重衰减。为了快速定位训练是否异常还要在训练脚本里加序列长度统计回调。如果训练数据的序列长度分布集中在很短的范围模型对长序列生成能力会很弱。每次 epoch 结束输出序列长度均值、中位数、最长序列值与验证集生成能力对照能帮你判断是否需要调整滑动窗口长度。# 训练过程中的评估回调示例 class MusicEvalCallback: def __init__(self, tokenizer, config): self.tokenizer tokenizer self.config config def on_epoch_end(self, epoch, logs): if epoch % 5 ! 0: return # 生成一小段样本并转回 MIDI sample_tokens self.generate_sample( max_lengthself.config[eval_max_length], temperatureself.config[eval_temperature] ) midi_bytes self.tokenizer.tokens_to_midi(sample_tokens) output_path feval_samples/epoch_{epoch:03d}.mid with open(output_path, wb) as f: f.write(midi_bytes) print(fEpoch {epoch}: saved sample to {output_path})这个回调的关键在于temperature参数。评估时不要用训练时的温度 1.0用 0.8 到 0.9 之间能生成更规整的样本方便你判断模型是否学到了音乐结构如果用 1.0生成的样本随机性太强很难区分是模型没学好还是采样噪声太大。一开始就保存所有 epoch 的样本会浪费磁盘所以我每 5 个 epoch 才存一次这些样本在后续人工筛选时非常有用。5. 生成阶段的三处关键优化解码策略、可控条件与推理效率5.1 解码策略对比贪心、温度采样与 top-p 的组合拳模型训练完成后生成阶段的优化是最后一块拼图也是最容易被忽视的。很多人直接调用model.generate()用默认参数跑出一段结果听感平庸就以为是模型不行其实大部分普通听感问题都出在解码策略上。贪心解码每次取概率最高的 token生成结果最稳定但几乎没有变化听几段就觉得千篇一律。温度采样是在 softmax 之前对 logits 除以一个温度值温度大于 1.0 增加随机性小于 1.0 降低随机性但只调温度容易产生两极化高了乱低了呆。更有效的是温度采样与 top-p 核采样组合。top-p 在每个生成步只保留累计概率达到 p 的最可能 token 集合再在这个集合内按温度采样。这样既能排除概率极低的长尾噪声又保留了合理的随机性。实际项目里的有效参数范围是温度 0.8 到 1.1p 值 0.85 到 0.95。生成主旋律时温度设低一些生成伴奏织体时温度可以高一点。为了避免重复片段还可以加 repetition penalty我一般设 1.2 到 1.5 之间设太大会让旋律变得跳跃缺乏连贯性。5.2 可控生成给模型绑定条件输入音乐生成项目一旦进入优化阶段必然会需要“控制生成方向”的能力。谁都希望模型既能随机创作又能在指定调式、速度或情绪下生成。条件生成的做法是在训练时就给每首歌打标签标签参与模型输入。最简单的方式是在序列开头加一个控制 token比如TRAIN_MAJOR_120BPM也可以把标签向量压缩成 embedding与序列 embedding 逐位相加后一起送入 Transformer 层。训练时标签必须是真实标签生成时标签由你指定或随机采样。这样在推理阶段就能做到在一个模型里生成不同风格的音乐而不需要为每种风格单独训练一个模型。如果你要做的优化是让模型能模仿某位特定作曲家的风格同样的做法只要把标签换成作曲家 ID 即可。5.3 推理效率优化与生成延迟压测推理效率在音乐生成里常被忽略因为它不像在线对话那样要求百毫秒级响应但如果你要做“实时伴奏跟随”或者“交互式作曲工具”推理延迟就变成了体验瓶颈。Transformer 解码是按 token 逐个生成的音乐序列动辄上千 token逐 token 推理的速度瓶颈主要卡在自注意力的键值缓存上。第一次生成时必须为每个 token 计算并缓存 K 和 V后续每个新 token 只需要计算与新 token 相关的注意力分数然后拼接缓存即可。# 推理时缓存 K/V 的结构示意 class CachedAttentionLayer(nn.Module): def __init__(self, d_model, n_heads): super().__init__() self.n_heads n_heads self.d_k d_model // n_heads self.w_k nn.Linear(d_model, d_model) self.w_v nn.Linear(d_model, d_model) def forward(self, x, pastNone): k self.w_k(x) v self.w_v(x) if past is not None: prev_k, prev_v past k torch.cat([prev_k, k], dim1) v torch.cat([prev_v, v], dim1) return k, v这个缓存的实现细节很容易出错最常见的坑是 batch size 不匹配。推理时如果第一批只生成一个样本缓存形状是[1, seq_len, d_k]第二批换成两个样本时缓存形状不兼容代码直接报错。要提前约定推理时的 batch size 固定不变或者在缓存数据结构里对每个样本单独存一份。另一个坑是在多头注意力里缓存要按头数拆分否则注意力计算维度对不上。模型蒸馏也能压缩推理耗时常见做法是让训练一个小的学生模型学习大教师模型的输出分布蒸馏后的模型参数量降一半生成效果能保住八成以上。如果你的项目要部署到端侧设备蒸馏是比量化更有效的优化手段因为量化在音乐生成这种长序列任务上容易放大噪声生成结果明显变糙。我把优先序排一下先做 K/V 缓存再做蒸馏最后考虑量化能不做量化就不做。6. 音乐生成优化的避坑手册六条血泪经验6.1 训练集里夹杂了“无效音乐”模型生成结构松散现象模型训练到后期生成结果在 token 层面无懈可击但听感上就是没有“歌”的样子段落感弱甚至出现整段无意义的音群。原因公开 MIDI 数据集里混杂了大量自动生成的练习曲、机器扒谱的劣质 MIDI它们的音符密度不均、节奏混乱。模型把这些也当成学习目标等于在学习一个扭曲的音乐分布。解决训练前做一轮过滤我处理时按三个规则过滤掉约两成数据音符数量少于 200 的删掉平均音高在 30 个半音以内波动过大的删掉速度变化超过 64 倍删掉。这个过滤规则不复杂但对生成结果的结构感提升很大。6.2 验证损失持续下降但生成的旋律却在重复现象每 1000 步保存的样本越来越“顺”但十段样本里八段都长得差不多甚至出现一模一样的旋律片段。原因模型过度拟合了训练集里高频出现的节奏型采样时无论温度怎么调概率分布都被那几个高频模式主导多样性被覆盖掉了。解决一是降低学习率并增大权重衰减给模型更大探索空间二是把解码时的 top-p 从 0.9 降到 0.85减少采样时选中高频模式的概率三是引入对比损失拉大局内表示的距离。优先做第二种因为只需要改解码参数不涉及重新训练。6.3 低音区音符容易被截断生成结果出现“断尾”现象生成的低音或长音符在实体文件里听起来尾音突然消失像被剪辑掉一样而高音区的音符没有这个问题。原因训练序列切分时长音符被窗口边界截断窗口边缘的长音符没有对应的持续时长 token模型学到“音符可以不完整”的错误模式。解决切分序列时做一个保护机制如果窗口末尾的音符持续时长超出了窗口右边界就缩进窗口边界保证这个音符完整地保留或完整地舍弃不切片。实现时额外存一个数据索引记录每个音符的边界切分时按边界对齐。6.4 采样参数盲调浪费时间现象每换一组温度参数就要重新生成一批样本听一遍效率低而且凭感觉选参数难以复现。原因缺少自动评估手段把参数搜索变成纯主观试错。解决写一个快速的客观评估脚本对比生成样本和训练集在音符密度、音高分布、时长分布上的 KL 散度数值越小说明越接近训练风格。先用这个指标筛一组参数再对剩两三组做人工听评。这能省掉大半无效采样时间。6.5 显存够用但生成速度很慢现象模型不大显存充裕但生成一首 3 分钟的音乐要等好几秒。原因没有使用 K/V 缓存每一步都重新计算全序列的注意力计算量随序列长度线性翻倍。解决检查推理代码是否复用了训练时的 forward 接口训练时没有缓存推理时直接复用就不会自动开启缓存。改成缓存结构后生成耗时能降到原来的五分之一甚至十分之一特别是序列长于 512 的场景。6.6 微调后旧数据集上表现变差现象用新的数据集微调之后原来做好的功能变差了生成结果从“像原来的风格”滑向“四不像”。原因微调时把整个模型权重都更新了原有知识被新数据的梯度覆盖旧数据集上的能力被冲掉。解决微调时冻结底层 4 层参数只更新顶层 2 层或者把旧数据按 1:3 的比例混入新数据旧数据参与比重太高会拖慢新风格的学习太低会忘记旧风格1:3 是我实际项目里反复验证过比较稳的比例。7. 进阶用引导采样把“随机生成”变成“可控创作”——一个值得投入的优化方向如果你走到这一步说明基础的音乐生成管线已经跑通是时候做一个决定项目上限的优化了可控生成。前面在第 5 章提过条件生成是绑定标签训练但实际做下来你会发现标签条件只能控制宏观属性比如调式、速度、风格控制不了具体走向。真正要落地到“给出一段两小节的旋律线索模型延续成一首完整乐曲”这种交互体验需要引导采样。引导采样的思路是在推理的每一步给生成概率加上一个来自外部约束函数的偏置。这个约束函数可以是任何可微或不可微的规则比如强制旋律在指定终点音上结束、不允许出现连续三个相同的音高、在某个小节必须落在指定和弦音上。偏置的作用方式是计算约束函数对候选 token 的得分再把这个得分加到模型输出的概率分布上。得分高的 token 被选中的概率更大但模型自身的分布仍然主导整体走向因此生成结果既符合约束又不生硬。我在这类项目里最常用的一个约束函数是“终点音高引导”。它解决的问题是模型生成的旋律开头很有灵感但结尾经常落在不稳定的音上。约束函数这样写def endpoint_pitch_score(token, position, total_length, target_pitch, decay0.5): token: 当前候选的音高 token position: 当前生成位置 total_length: 期望的总长度 target_pitch: 期望的结尾音高 decay: 影响范围衰减系数越大影响范围越短 remaining total_length - position if remaining 0: return 0.0 influence decay ** (remaining / 10.0) if token target_pitch: return influence * 5.0 else: return 0.0这个函数的逻辑里remaining越小influence越接近 1.0结尾处的引导强度最大。decay0.5意味着每往前推 10 个 token影响强度减半这样开头部分的旋律自由度几乎不受约束只有接近结尾时才明显拉向目标音。参数5.0是引导强度的上限设太大会覆盖模型自身的分布生成结果变成硬凑设太小又拉不动旋律走向。我一般从 3.0 到 6.0 之间试具体看你对结尾音正确率的要求。引导采样要做成通用框架才能在多个优化点复用。我这里的做法是把约束函数注册成一个回调列表每一步生成时依次计算得分并累加到 logits 上。单位数的候选 token 在词表空间里的索引要提前映射好避免混淆音高 token 和时长 token。这个框架的好处是你可以不断增加新的约束函数比如最低音不超出指定范围、相邻音符音程不超过八度用来约束生成的合理边界也可以引入来自外部序列的相似度分数让模型生成与给定旋律风格匹配的延续片段。这个优化方向值得投入因为它是把音乐生成从“模型输出什么我听什么”变成“我要什么模型给什么”的关键一步。实际项目中模型本身的生成能力决定伸出的手够多远引导采样决定这只手能不能精准落到你想落的位置。我个人的习惯是先做终止音引导和音程约束这两个函数因为它们对听感的改善最直观。后面再逐渐加入小节对齐约束比如每四小节要求落在 I 级或 V 级上这在流行乐结构里非常实用。最后分享一个教训引导采样的权重不是越大越好。有一次我把强度调到 8.0结果模型生成了大量奇怪的音程跳进——因为为了满足约束它在不连续的位置强行把音高掰到目标值旋律线被扯碎了。从那以后我给自己定了个规矩每次只调一个约束参数生成十段样本全部人工试听采样参数稳定之后再叠加新的约束。音乐生成优化的本质不是让模型更强而是让你对模型行为有越来越精确的掌控。希望这些路径和坑位能帮你在自己的项目里少走一段夜路。本文还有配套的精品资源点击获取
简介基于机器学习的自动音乐生成软件核心采用长短期记忆网络模型代替常见的简单循环神经网络与WaveNet方案在最少人为干预下生成一段短曲并播放缓解同质化问题。资源面向深度学习与音乐生成交叉方向的学习者适合作为课程设计、毕业设计或算法实验参考也适合对人工智能作曲感兴趣的开发者动手实践。压缩包共八个文件约四百六十六KB包含两个交互式笔记本程序、一个Python脚本、一份详细设计说明书PDF以及许可证和使用说明文件结构清晰可对照代码与文档逐步学习。目前已有二百三十九人学习下载。通过源码与说明文档可理解长短期记忆网络在音乐生成任务中的建模与训练流程复现钢琴风格自动作曲示例并学习优化生成效果的思路帮助从入门到进阶的实践。1. 基于机器学习的自动音乐生成优化为什么“能响”和“好听”之间隔着一整个调参工程自动音乐生成这个方向听起来像是让模型随便编一段旋律就完事但真正做过的人都知道模型跑通一个 demo 可能只要一晚上让输出的音乐能听、不炸音、有结构感却要在这个基础上再投入数倍的时间。这里面的差距就在于“生成”和“优化”之间的那条鸿沟。基于机器学习的自动音乐生成优化本质上解决的是三个问题用什么模型结构去建模音乐的时间序列依赖用什么数据形式和损失函数让模型真正学到音乐性以及用什么解码策略让生成结果不塌、不糊、不无聊。这篇文章不会泛泛讲音乐生成的历史而是直接按我在实际项目中验证过的路径来拆解选型思路、数据预处理、训练调参、踩坑记录以及最后落到可控生成和推理效率上的技巧。这篇文章适合的人有两大类一类是刚接触生成式 AI想用机器学习做音乐生成但不知道从哪个模型下手的开发者另一类是已经跑通过一个音乐生成管线、但生成结果总是“差点意思”想找到优化方向的研究生或算法工程师。如果你只是好奇 AI 作曲的原理那这篇可能偏工程了一些但如果你要的是能动手改代码、看得到效果提升的操作路径那这篇正合适。2. 音乐生成的技术路线选型符号生成、音频生成与混合方案的取舍2.1 符号生成为什么是多数团队的第一站自动音乐生成在技术路线上第一个分岔口就是“生成什么”。符号生成指的是让模型直接输出音乐符号层面的内容最常见的就是 MIDI 序列。你看到的可能是音符编号、时长、力度、速度标记但本质上是让模型在离散的符号序列上做预测。这条路线的最大优点是训练和评估都比较干净数据容易获得MAESTRO、Lakh MIDI Dataset 这类数据集里几十万首 MIDI 文件可以直接用而且生成结果的错误模式更可解释——某个音符不合理你能明确指出来是 pitch 预测错了还是 duration 崩了。符号生成的主流模型结构早期是 LSTM现在基本被 Transformer 系列接管。Transformer 在音乐上的应用比文本要晚一些核心原因是音乐序列不只是“下一个词”那么简单。一段旋律里同时存在水平方向的和弦进行和垂直方向的多声部关系所以单纯把音符拍扁成一维序列会丢失声部信息。常见的做法是把每个时间步上同时发生的音符打包成一个“事件”或者用复合 token 表示“此刻在响的所有音高”这属于数据表示层面的工程但选型的正确与否直接影响后续能否优化。如果要在符号生成里选一个入门成本最低的组合我会推荐用 Transformer 解码器加 MIDI-like tokenization。输入是音高、时长、速度三类 token 拼成的序列输出是下一个 token 的分布。这个方案符合你“用机器学习自动生成音乐”的最小闭环定义代码量可控训练资源要求低而且优化空间大——后面要讲的损失函数改造、解码策略调整都是在这个基础上做的。2.2 音频生成路线从频谱到波形的距离符号生成的问题也很明显它生成的 MIDI 没有音色没有演奏细节。如果一个项目要落地到“直接出可听的音乐片段”符号生成还得再接一个音源渲染环节这个环节会在一定程度上磨掉生成结果的特色。音频生成路线则是让模型直接输出音频要么输出频谱图再做声码器恢复波形要么像一些较新的模型那样直接输出波形采样点。音频生成的主流做法是频谱生成加声码器的两段式。模型先生成 mel 频谱图本质上是把音频压缩成 80 到 128 个频带的能量随时间变化的二维图再用 HiFi-GAN 之类的声码器把它恢复成波形。这条路线的效果上限更高生成的音乐在听感上更接近“音乐录音”而不只是“乐谱演奏”但代价也非常具体数据量需求大、训练时间成倍增加、生成结果不可解释。频谱上的一个小噪点恢复成波形可能就是一声刺耳的爆音。对于大多数做优化工作的团队我一般不建议直接从纯音频路线开始。更稳妥的结构是符号为主、音频为辅的混合方案先用符号模型生成旋律与和弦结构再用一个基于频谱的模型做人声或主奏乐器的音色渲染。这样你可以把优化重点放在音乐结构上而不是浪费大量算力在波形生成的稳定性上。后续要优化听感时再单独替换音频侧模型不必推倒重来。2.3 选型决策表与优化重心预判对比维度符号生成音频生成混合方案数据获取难度低公开 MIDI 数据充足高需要成对音频与标注中等训练资源消耗单卡可跑多卡集群更现实按阶段分配资源生成结果可解释性高错误可定位低问题难追溯中听感上限受限于音源渲染高接近真实录音高适合的优化方向结构逻辑、旋律质量音色、混音、表现力综合性最优选型做完之后优化重心也就跟着定下来了。符号生成的重心在序列建模和采样策略音频生成的重心在声码器匹配和频谱重建损失。我见过不少项目在选型阶段犹豫过久其实不用太纠结先跑通一个能听结果的最小闭环比什么都有说服力。后面做的所有优化都是在这个闭环上做增量。3. 把 MIDI 变成模型能学的语言数据处理与特征工程的两套方案3.1 方案一事件序列化 tokenizer 与最小实现数据处理是音乐生成项目里最容易被低估的环节。原始 MIDI 文件不能直接喂给模型你要先把音符、时长、速度、休止符这些信息转成整数 token 序列。我常用的方法是把每个音符拆成三个事件NOTE_ON 表示某个音高开始发声NOTE_DURATION 表示持续时长NOTE_VELOCITY 表示力度。这样模型序列里每个音符占三个 token 位置虽然序列变长了但每个维度的独立预测难度反而下降对后续优化更有帮助。下面是这个 tokenizer 的最小实现可以直接在本地数据集上跑通import midiutil from pathlib import Path def midi_to_event_tokens(midi_path: str, time_step: int 10) - list: 将 MIDI 文件转换为事件 token 序列。 time_step 是时间量化单位单位是 tick10 表示每 10 tick 一个时间步。 from midiutil import MIDIFile from mido import MidiFile mid MidiFile(midi_path) tokens [] current_time 0 for msg in mid: if msg.type note_on and msg.velocity 0: # 音符开始记录音高和力度 tokens.append({ type: NOTE_ON, pitch: msg.note, velocity: msg.velocity, time: current_time }) elif msg.type note_on and msg.velocity 0: # 有些 MIDI 用 velocity0 表示音符结束 tokens.append({ type: NOTE_OFF, pitch: msg.note, time: current_time }) elif msg.type note_off: tokens.append({ type: NOTE_OFF, pitch: msg.note, time: current_time }) # 按时间排序并量化到 time_step tokens.sort(keylambda x: x[time]) quantized [] for token in tokens: token[time] (token[time] // time_step) * time_step quantized.append(token) return quantized这段代码的逻辑里有几个参数值得注意。time_step10是这个方案里最关键的参数它决定模型能感知的最小时间粒度。取值太小会让序列过长训练成本上升且注意力机制难以捕捉长程依赖取值太大则会丢失音符的起始精度导致生成的节奏听起来“对不上拍子”。我一般先从 10 到 30 之间试看生成结果的节奏规整度再做调整。量化方式是直接向下取整你可以改成四舍五入但要注意量化到同一时间步的 NOTE_ON 事件在后续转回 MIDI 时可以合并为和弦这个合并逻辑要单独处理。3.2 方案二复合 token 编码与对比分析事件序列化方案的问题在于序列太长一段三分钟的音乐轻松生成上万个 tokenTransformer 的自注意力复杂度是序列长度的平方训练和推理都会变慢。另一个方案是复合 token 编码它把同一时间步上发生的所有音符打包成一个 tokentoken 内部用位掩码或集合表示音高组合。比如用长度为 128 的向量表示音高域响应的位置置 1其余置 0这样 128 个音高就是一个 16 字节的编码一个时间步只产生一个 token序列长度大幅缩短。这个方案的数学表示是设时间步 t 的 token 为集合 S_t {p_1, p_2, ..., p_k}表示此刻同时发声的音高集合。模型要预测的是 P(S_t | S_{t-1}, S_{t-2}, ..., S_{t-n})即给定历史时间步的音符集合预测当前时间步会响哪些音。和事件序列化方案相比复合 token 生成的音符天然是对齐的不会出现“某个音高提前半拍进入”这种毛刺而且序列长度降了一个数量级训练速度提升明显。但复合 token 也有代价。它天然不具备表达声部独立性的能力——两个乐器在同一个时间步各弹各的旋律编码后混在同一个集合里模型无法区分这是两件乐器的独立线还是刻意写成的和弦。如果在你的项目里声部独立性是必须保留的属性那复合 token 就不适合。它对“主旋律加伴奏”这类简单织体很友好对复调音乐就很吃力。做选择时你可以先看数据集的音乐织体复杂度再决定用哪种方案。3.3 数据增强与序列切分的边界问题数据处理的另一个关键环节是训练序列切分。一首完整的音乐可能有几千个 token直接整首喂给模型显存会炸而且注意力机制很难跨越大跨度捕捉全局结构。常见做法是滑动窗口切分窗口长度设 512 或 1024 个 token步长设为窗口的一半让相邻片段有重叠避免旋律在切割点处被生硬截断。重叠窗口的一个隐蔽坑是数据泄漏。如果训练集和验证集来自同一首歌切分后相邻窗口内容高度重合验证损失会虚低。我一般会在切分之前先把 MIDI 文件按曲目分好组确保同一个曲目的所有窗口只进入训练集或只进入验证集不做跨集合混合。这个细节看起来不起眼但直接影响你对模型是否过拟合的判断。另一个实用技巧是数据增强把 MIDI 整体平移几个半音或者把速度整体缩放 0.95 到 1.05 倍。这个操作不会改变音乐的本质结构但能有效增加数据的多样性在数据量有限时是个性价比很高的增强手段。4. 模型训练与损失优化从交叉熵到音乐性指标4.1 基线模型与训练基础配置数据处理完之后模型训练就是下一个核心环节。基线模型我推荐直接用标准 Transformer 解码器不引入太多自定义结构。层数设 6 到 8 层隐藏维度 512注意力头数 8。这个配置在单张消费级显卡上可以完成训练而且能作为后续所有优化实验的对照基准。如果你直接用更大的模型起步遇到问题时很难判断是模型容量不够还是训练策略有问题基线先跑通的意义就在于此。训练损失默认是交叉熵即预测下一个 token 的分布与真实 token 的交叉熵。这个损失对于音乐生成来说有天然缺陷它把所有 token 类型一视同仁。但在音乐里预测错一个音高和预测错一个力度严重程度完全不同。音高错了可能造成不协和音程力度错了只是轻微的情绪偏差。这个缺陷后面会在优化环节处理先按默认配置把基线跑通拿到一组可复现的损失曲线和生成样本再开始优化。4.2 损失函数优化的三个方向交叉熵优化到一定程度后生成的音乐在 token 层面已经很“正确”了但听起来仍然平淡。这时候要动手改损失函数我踩过三个可复用的方向第一个方向是分类型加权损失。把音高、时长、力度三类 token 的损失分开计算并按重要性赋权。比如音高的权重是 1.0时长 0.8力度 0.5。实现时不要直接改损失函数接口而是在计算交叉熵之前按 token 类型对 logits 和 labels 做掩码分别取均值再加权相加。这样做的原因是模型会自然偏向预测分布更均匀、样本量更大的类别加权可以纠正这种偏差。第二个方向是加入对比损失。音乐生成的一个顽疾是“均值回归”模型生成的旋律总是趋向于音高变化小、节奏单一的保守模式。对比损失的思路是把当前生成片段和训练集中一个类似片段做正样本对和随机片段做负样本对让模型学到的表示空间拉开正负样本的距离。这个策略的训练成本不高但对生成结果的多样性提升非常明显。第三个方向是强化学习微调。用交叉熵训练出的模型生成的音乐虽然合理但不一定符合人的主观听感。强化学习的做法是让模型生成完整序列然后用一个奖励模型打分再通过策略梯度更新模型参数。奖励模型可以是一个预训练的音乐情感分类器也可以是规则打分函数——比如检测和声进行是否在常见调性内、节奏变化是否丰富。这属于进阶优化一般放在基础损失优化之后做见效更直接但也更容易过拟合需要在训练中加 KL 散度约束避免模型为了高分牺牲多样性。4.3 训练策略里的关键可调参数除了损失函数训练策略里还有几个对生成效果影响很大的参数值得反复调。第一个是学习率预热步数。音乐序列比文本序列更长训练早期梯度噪声更大预热步数设得太短模型很容易在起步阶段就走偏。我从实际项目里验证的经验是预热步数在 4000 到 8000 之间比较合理具体看序列长度和 batch size。第二个是 batch size 与梯度累积步数。如果你用的是复合 token 编码batch size 可以适当增大因为序列短了如果是事件序列化单条序列很长显存压力大用梯度累积模拟更大的 batch size 是常见做法。每累积 4 步更新一次参数效果等价于把 batch size 放大 4 倍但要注意学习率要相应调低否则收敛不稳定。第三个是权重衰减系数。Transformer 模型在音乐生成任务上容易过拟合训练集里的常见节奏型权重衰减设太小会导致生成结果重复性极高设太大又会欠拟合、旋律变得杂乱。我用的范围是 0.01 到 0.1最终选 0.05 的居多。这个参数需要配合验证集上的多样性指标一起看比如统计生成样本里相邻音符音高差绝对值大于 3 的占比占比太低说明模型在复读。4.4 训练过程的检查点与评估回调训练不能只看训练损失下降就认为万事大吉还要在验证集上做评估。我常用的做法是每训练 1000 步做一次验证集损失计算并同时生成一小段样本保存为 MIDI 文件。听到样本里的问题往往比看到损失曲线更直观——损失在下降但生成结果全是同一个音说明模型退化成死循环这时候需要检查注意力权重是否出现了均匀化及时调 dropout 或权重衰减。为了快速定位训练是否异常还要在训练脚本里加序列长度统计回调。如果训练数据的序列长度分布集中在很短的范围模型对长序列生成能力会很弱。每次 epoch 结束输出序列长度均值、中位数、最长序列值与验证集生成能力对照能帮你判断是否需要调整滑动窗口长度。# 训练过程中的评估回调示例 class MusicEvalCallback: def __init__(self, tokenizer, config): self.tokenizer tokenizer self.config config def on_epoch_end(self, epoch, logs): if epoch % 5 ! 0: return # 生成一小段样本并转回 MIDI sample_tokens self.generate_sample( max_lengthself.config[eval_max_length], temperatureself.config[eval_temperature] ) midi_bytes self.tokenizer.tokens_to_midi(sample_tokens) output_path feval_samples/epoch_{epoch:03d}.mid with open(output_path, wb) as f: f.write(midi_bytes) print(fEpoch {epoch}: saved sample to {output_path})这个回调的关键在于temperature参数。评估时不要用训练时的温度 1.0用 0.8 到 0.9 之间能生成更规整的样本方便你判断模型是否学到了音乐结构如果用 1.0生成的样本随机性太强很难区分是模型没学好还是采样噪声太大。一开始就保存所有 epoch 的样本会浪费磁盘所以我每 5 个 epoch 才存一次这些样本在后续人工筛选时非常有用。5. 生成阶段的三处关键优化解码策略、可控条件与推理效率5.1 解码策略对比贪心、温度采样与 top-p 的组合拳模型训练完成后生成阶段的优化是最后一块拼图也是最容易被忽视的。很多人直接调用model.generate()用默认参数跑出一段结果听感平庸就以为是模型不行其实大部分普通听感问题都出在解码策略上。贪心解码每次取概率最高的 token生成结果最稳定但几乎没有变化听几段就觉得千篇一律。温度采样是在 softmax 之前对 logits 除以一个温度值温度大于 1.0 增加随机性小于 1.0 降低随机性但只调温度容易产生两极化高了乱低了呆。更有效的是温度采样与 top-p 核采样组合。top-p 在每个生成步只保留累计概率达到 p 的最可能 token 集合再在这个集合内按温度采样。这样既能排除概率极低的长尾噪声又保留了合理的随机性。实际项目里的有效参数范围是温度 0.8 到 1.1p 值 0.85 到 0.95。生成主旋律时温度设低一些生成伴奏织体时温度可以高一点。为了避免重复片段还可以加 repetition penalty我一般设 1.2 到 1.5 之间设太大会让旋律变得跳跃缺乏连贯性。5.2 可控生成给模型绑定条件输入音乐生成项目一旦进入优化阶段必然会需要“控制生成方向”的能力。谁都希望模型既能随机创作又能在指定调式、速度或情绪下生成。条件生成的做法是在训练时就给每首歌打标签标签参与模型输入。最简单的方式是在序列开头加一个控制 token比如TRAIN_MAJOR_120BPM也可以把标签向量压缩成 embedding与序列 embedding 逐位相加后一起送入 Transformer 层。训练时标签必须是真实标签生成时标签由你指定或随机采样。这样在推理阶段就能做到在一个模型里生成不同风格的音乐而不需要为每种风格单独训练一个模型。如果你要做的优化是让模型能模仿某位特定作曲家的风格同样的做法只要把标签换成作曲家 ID 即可。5.3 推理效率优化与生成延迟压测推理效率在音乐生成里常被忽略因为它不像在线对话那样要求百毫秒级响应但如果你要做“实时伴奏跟随”或者“交互式作曲工具”推理延迟就变成了体验瓶颈。Transformer 解码是按 token 逐个生成的音乐序列动辄上千 token逐 token 推理的速度瓶颈主要卡在自注意力的键值缓存上。第一次生成时必须为每个 token 计算并缓存 K 和 V后续每个新 token 只需要计算与新 token 相关的注意力分数然后拼接缓存即可。# 推理时缓存 K/V 的结构示意 class CachedAttentionLayer(nn.Module): def __init__(self, d_model, n_heads): super().__init__() self.n_heads n_heads self.d_k d_model // n_heads self.w_k nn.Linear(d_model, d_model) self.w_v nn.Linear(d_model, d_model) def forward(self, x, pastNone): k self.w_k(x) v self.w_v(x) if past is not None: prev_k, prev_v past k torch.cat([prev_k, k], dim1) v torch.cat([prev_v, v], dim1) return k, v这个缓存的实现细节很容易出错最常见的坑是 batch size 不匹配。推理时如果第一批只生成一个样本缓存形状是[1, seq_len, d_k]第二批换成两个样本时缓存形状不兼容代码直接报错。要提前约定推理时的 batch size 固定不变或者在缓存数据结构里对每个样本单独存一份。另一个坑是在多头注意力里缓存要按头数拆分否则注意力计算维度对不上。模型蒸馏也能压缩推理耗时常见做法是让训练一个小的学生模型学习大教师模型的输出分布蒸馏后的模型参数量降一半生成效果能保住八成以上。如果你的项目要部署到端侧设备蒸馏是比量化更有效的优化手段因为量化在音乐生成这种长序列任务上容易放大噪声生成结果明显变糙。我把优先序排一下先做 K/V 缓存再做蒸馏最后考虑量化能不做量化就不做。6. 音乐生成优化的避坑手册六条血泪经验6.1 训练集里夹杂了“无效音乐”模型生成结构松散现象模型训练到后期生成结果在 token 层面无懈可击但听感上就是没有“歌”的样子段落感弱甚至出现整段无意义的音群。原因公开 MIDI 数据集里混杂了大量自动生成的练习曲、机器扒谱的劣质 MIDI它们的音符密度不均、节奏混乱。模型把这些也当成学习目标等于在学习一个扭曲的音乐分布。解决训练前做一轮过滤我处理时按三个规则过滤掉约两成数据音符数量少于 200 的删掉平均音高在 30 个半音以内波动过大的删掉速度变化超过 64 倍删掉。这个过滤规则不复杂但对生成结果的结构感提升很大。6.2 验证损失持续下降但生成的旋律却在重复现象每 1000 步保存的样本越来越“顺”但十段样本里八段都长得差不多甚至出现一模一样的旋律片段。原因模型过度拟合了训练集里高频出现的节奏型采样时无论温度怎么调概率分布都被那几个高频模式主导多样性被覆盖掉了。解决一是降低学习率并增大权重衰减给模型更大探索空间二是把解码时的 top-p 从 0.9 降到 0.85减少采样时选中高频模式的概率三是引入对比损失拉大局内表示的距离。优先做第二种因为只需要改解码参数不涉及重新训练。6.3 低音区音符容易被截断生成结果出现“断尾”现象生成的低音或长音符在实体文件里听起来尾音突然消失像被剪辑掉一样而高音区的音符没有这个问题。原因训练序列切分时长音符被窗口边界截断窗口边缘的长音符没有对应的持续时长 token模型学到“音符可以不完整”的错误模式。解决切分序列时做一个保护机制如果窗口末尾的音符持续时长超出了窗口右边界就缩进窗口边界保证这个音符完整地保留或完整地舍弃不切片。实现时额外存一个数据索引记录每个音符的边界切分时按边界对齐。6.4 采样参数盲调浪费时间现象每换一组温度参数就要重新生成一批样本听一遍效率低而且凭感觉选参数难以复现。原因缺少自动评估手段把参数搜索变成纯主观试错。解决写一个快速的客观评估脚本对比生成样本和训练集在音符密度、音高分布、时长分布上的 KL 散度数值越小说明越接近训练风格。先用这个指标筛一组参数再对剩两三组做人工听评。这能省掉大半无效采样时间。6.5 显存够用但生成速度很慢现象模型不大显存充裕但生成一首 3 分钟的音乐要等好几秒。原因没有使用 K/V 缓存每一步都重新计算全序列的注意力计算量随序列长度线性翻倍。解决检查推理代码是否复用了训练时的 forward 接口训练时没有缓存推理时直接复用就不会自动开启缓存。改成缓存结构后生成耗时能降到原来的五分之一甚至十分之一特别是序列长于 512 的场景。6.6 微调后旧数据集上表现变差现象用新的数据集微调之后原来做好的功能变差了生成结果从“像原来的风格”滑向“四不像”。原因微调时把整个模型权重都更新了原有知识被新数据的梯度覆盖旧数据集上的能力被冲掉。解决微调时冻结底层 4 层参数只更新顶层 2 层或者把旧数据按 1:3 的比例混入新数据旧数据参与比重太高会拖慢新风格的学习太低会忘记旧风格1:3 是我实际项目里反复验证过比较稳的比例。7. 进阶用引导采样把“随机生成”变成“可控创作”——一个值得投入的优化方向如果你走到这一步说明基础的音乐生成管线已经跑通是时候做一个决定项目上限的优化了可控生成。前面在第 5 章提过条件生成是绑定标签训练但实际做下来你会发现标签条件只能控制宏观属性比如调式、速度、风格控制不了具体走向。真正要落地到“给出一段两小节的旋律线索模型延续成一首完整乐曲”这种交互体验需要引导采样。引导采样的思路是在推理的每一步给生成概率加上一个来自外部约束函数的偏置。这个约束函数可以是任何可微或不可微的规则比如强制旋律在指定终点音上结束、不允许出现连续三个相同的音高、在某个小节必须落在指定和弦音上。偏置的作用方式是计算约束函数对候选 token 的得分再把这个得分加到模型输出的概率分布上。得分高的 token 被选中的概率更大但模型自身的分布仍然主导整体走向因此生成结果既符合约束又不生硬。我在这类项目里最常用的一个约束函数是“终点音高引导”。它解决的问题是模型生成的旋律开头很有灵感但结尾经常落在不稳定的音上。约束函数这样写def endpoint_pitch_score(token, position, total_length, target_pitch, decay0.5): token: 当前候选的音高 token position: 当前生成位置 total_length: 期望的总长度 target_pitch: 期望的结尾音高 decay: 影响范围衰减系数越大影响范围越短 remaining total_length - position if remaining 0: return 0.0 influence decay ** (remaining / 10.0) if token target_pitch: return influence * 5.0 else: return 0.0这个函数的逻辑里remaining越小influence越接近 1.0结尾处的引导强度最大。decay0.5意味着每往前推 10 个 token影响强度减半这样开头部分的旋律自由度几乎不受约束只有接近结尾时才明显拉向目标音。参数5.0是引导强度的上限设太大会覆盖模型自身的分布生成结果变成硬凑设太小又拉不动旋律走向。我一般从 3.0 到 6.0 之间试具体看你对结尾音正确率的要求。引导采样要做成通用框架才能在多个优化点复用。我这里的做法是把约束函数注册成一个回调列表每一步生成时依次计算得分并累加到 logits 上。单位数的候选 token 在词表空间里的索引要提前映射好避免混淆音高 token 和时长 token。这个框架的好处是你可以不断增加新的约束函数比如最低音不超出指定范围、相邻音符音程不超过八度用来约束生成的合理边界也可以引入来自外部序列的相似度分数让模型生成与给定旋律风格匹配的延续片段。这个优化方向值得投入因为它是把音乐生成从“模型输出什么我听什么”变成“我要什么模型给什么”的关键一步。实际项目中模型本身的生成能力决定伸出的手够多远引导采样决定这只手能不能精准落到你想落的位置。我个人的习惯是先做终止音引导和音程约束这两个函数因为它们对听感的改善最直观。后面再逐渐加入小节对齐约束比如每四小节要求落在 I 级或 V 级上这在流行乐结构里非常实用。最后分享一个教训引导采样的权重不是越大越好。有一次我把强度调到 8.0结果模型生成了大量奇怪的音程跳进——因为为了满足约束它在不连续的位置强行把音高掰到目标值旋律线被扯碎了。从那以后我给自己定了个规矩每次只调一个约束参数生成十段样本全部人工试听采样参数稳定之后再叠加新的约束。音乐生成优化的本质不是让模型更强而是让你对模型行为有越来越精确的掌控。希望这些路径和坑位能帮你在自己的项目里少走一段夜路。本文还有配套的精品资源点击获取
