来源：HN (355pts)
URL: https://simedw.com/2026/08/20/midi-autocomplete/
精读日期：2026-08-21
模型：DeepSeek V4 Flash（AI 生成，人工未审校）
正文获取：全文

一、核心论点/事实

  • 训练了一个 125M 参数 的 transformer 模型，用于实时钢琴自动续写（autocomplete），在 iPhone 15 上达到 ~108 notes/sec 的推理速度。
  • 最大的性能提升来自三个关键点：找到正确的 MIDI 表示方式、激进的数据清洗、以及 DPO（Direct Preference Optimization）后训练。
  • 项目经历了 14 次实验 才达到满意的效果，核心场景是“MIDI 钢琴 + 手机 + AI 续写”，类比 GitHub Copilot for piano。
  • 最终采用 按音符（note-level）的表示方式，每个音符用一个 token 表示，包含 pitch、delta_onset、duration、velocity 四个字段，相比逐事件（event-level）表示大幅减少推理步数。
  • 最终数据集包含 数十万 MIDI 文件，约 3 亿个音符事件，经过密度/音高/时间覆盖过滤、去重（忽略全局移调）等清洗。
  • 延音踏板（sustain pedal）在预处理阶段被“烘焙”进音符时长，模型无需预测踏板事件，简化了建模问题。

二、方法/架构拆解

1. MIDI 表示方式演进（关键实验路径）

  • Naive event-level：每个 MIDI 事件一个 token（note-on/note-off/velocity 等），词汇表膨胀（128 pitch × 128 velocity），稀疏组合多，模型难以学习。
  • Grammar-factorized：[NOTE_ON, PITCH, VELOCITY] | [NOTE_OFF, PITCH] | [TIME_SHIFT, DURATION]，通过 mask 强制语法合法，但模型易出现 note-off 漂移（忘记释放音符、悬挂音）。
  • Note-duration 表示：[NOTE, PITCH, VELOCITY, DURATION] | [TIME_SHIFT, DURATION]，避免 note-off 问题，但每个音符需 ~4 个自回归步骤，推理慢且消耗上下文窗口。
  • 最终方案（Note-level with delta_onset）：NOTE(pitch, delta_onset, duration, velocity)，每个音符一个 token，delta_onset 表示距上一个音符 onset 的时间间隔，和弦用多个 delta=0 的音符表示。每个音符只需 1 次 transformer 前向传播。

2. 模型架构细节

  • 每个音符内部有 5 个分类字段：[event_type, pitch_id, delta_id, duration_id, velocity_id]，每个字段有独立 embedding，音符 token 为各 embedding 之和。
  • 模型有 多个输出头（pitch、delta、duration 等），字段间有一个 小型嵌套 decoder，使后续字段可条件于先前预测的字段。
  • Transformer 主干每个音符只运行一次，而非每个字段一次，这是推理速度的关键。

3. 数据与预处理

  • 数据来源：公开数据集，以公有领域古典音乐为主，质量参差，需大量清洗脚本。
  • 清洗策略：移除/降低病态多轨混合、按密度和音高/时间覆盖过滤、按忽略全局移调/均匀移调的指纹去重。
  • 延音踏板处理：若踏板踩下时释放琴键，音符延长至踏板抬起；若同音高再次触发，则截断前音。最终音符时长近似实际发声时长。

4. 后训练

  • 使用 DPO（Direct Preference Optimization） 进行后训练，进一步提升生成质量（具体偏好数据构造未在文中详述）。

三、值得注意的局限/争议

作者承认的局限

  • 视频质量“potato-quality”，因为好手机在跑模型（演示环境受限）。
  • 项目聚焦于 钢琴独奏续写，对多轨/多乐器 MIDI 支持有限（其他音轨被移除或降低）。
  • 延音踏板的手势细节丢失，模型无法学习踏板踩放的艺术性表达。

AI 判断的局限/争议

  • 数据偏向古典音乐（公有领域为主），对流行、爵士、现代风格的泛化能力未知。
  • delta_onset 的离散化：时间步长的粒度未说明，过粗会丢失节奏细节，过细会增大词汇表，存在权衡。
  • 单音符 token 的表示虽然快，但可能限制模型对复杂和声进行、跨音符结构的建模能力（相比逐事件表示）。
  • DPO 的偏好数据来源和构造未公开，可复现性存疑。
  • “~108 notes/sec” 是生成速度，但端到端延迟（含音频合成、UI 渲染）未披露，实际体验可能受影响。
  • 模型规模（125M）和数据集（3 亿音符）的配比是否最优，缺乏消融实验证据。

四、与 RRLab 研究的关联

Harness 工程

  • 推理效率优化：单 token 表示 + 多输出头 + 嵌套 decoder 的设计，是典型的“减少自回归步数”工程实践，可借鉴到 RRLab 的模型推理 harness 中，尤其适合低延迟场景。
  • 语法约束生成：通过 mask 强制合法输出的思路，可用于 RRLab 工具链中结构化输出（如代码、JSON）的生成控制。

多模型协同

  • 端到端流水线：MIDI 输入 → 模型续写 → 音频合成，展示了“感知模型 + 生成模型 + 渲染引擎”的协同模式，可类比 RRLab 多模型协作架构中的角色分工。

模型评测

  • 数据清洗方法论：密度过滤、指纹去重（忽略移调）等策略，对 RRLab 构建评测数据集有直接参考价值。
  • 主观评测：作者用音频示例展示效果，提示评测不仅依赖客观指标，还需结合人工听感。

Agent 落地

  • 实时交互式生成：模型在设备端实时响应人类输入，是 Agent 落地中“人类-AI 协作创作”的典型案例，可借鉴其交互设计和延迟优化经验。

AI 原生产品

  • “Copilot for piano” 的产品定位，展示了 AI 原生产品如何将生成模型嵌入创作工具，RRLab 可参考其“提示 + 续写”的交互范式，应用于写作、编程、设计等场景。

本笔记由 DeepSeek V4 Flash 自动生成，未经人工审校。原文链接：https://simedw.com/2026/08/20/midi-autocomplete/