企业官网建设流程全解析

简介：在计算机视觉领域，目标检测技术常被用于解决复杂场景下的元素定位问题，而光学乐谱识别（OMR）正是其中极具挑战性的垂直应用。不同于常规文字OCR，乐谱由音符、谱号、小节线等二维符号系统组成，其空间关系复杂，对检测精度与鲁棒性要求更高。YOLOv5作为一套成熟高效的检测框架，凭借其轻量级设计和良好的工程生态，为乐谱结构化解析提供了务实可行的技术路径。本文从数据采集与标注方案切入，系统论述了类别设计、训练调参、小目标优化以及模型导出部署等关键环节，并结合实际项目中的踩坑记录，总结了解决谱线干扰、类别不平衡等问题的实用技巧。该技术方案可应用于乐谱数字化归档、自动伴奏、音乐教育辅助等场景，为后续音乐信息检索与智能乐谱理解奠定基础。 做乐谱识别，很多人第一反应是 OCR 那套思路，或者上更重的分割模型。但如果你手里已经有一批标注好的乐谱图像数据，又想在检测层面快速落地——音符、谱号、小节线、临时记号这些元素的位置都框出来——那 YOLOv5 其实是一个非常务实的选择。这个项目就是典型的“目标检测 + 垂直领域数据集”的组合：用 YOLOv5 训练一个专门检测乐谱元素的模型，把纸质或电子版乐谱变成结构化的符号位置信息，为后续的 OCR 识别、自动演奏、乐谱归档甚至音乐教育辅助提供基础。

这篇文章我会把这个项目的完整链路拆开讲清楚：从数据怎么采集、标注方案怎么设计，到训练配置怎么调、踩过哪些坑，再到模型评估和落地部署的注意事项。适合正在做 OMR（光学乐谱识别）、或者手里有图像检测需求但不确定 YOLOv5 怎么用在细分场景的朋友参考。

1. 乐谱识别任务分析与检测方案选型

1.1 乐谱识别到底要检测什么

乐谱识别和普通文字 OCR 有个本质区别：乐谱是“二维符号系统”，音符、谱号、小节线、连音线、力度记号这些元素不是像文字一样按行线性排列的，而是上下左右互相嵌套的。比如一个和弦，多个音符的符头在同一垂直线上；一个八分音符的符尾可能横跨两条谱线；连音线从高音谱表一直延伸到低音谱表。这种空间关系决定了检测任务不只是“找框”，而是要对符号本身的边界有清晰界定。

从检测目标来看，常见的乐谱元素类别可以分成几个层次：

• 音符类：全音符（空心符头）、二分音符（空心符头加符干）、四分音符（实心符头加符干）、八分音符及更短时值（带符尾或符杠）。
• 节奏与休止符：全体止符、二分休止符、四分休止符、八分休止符等，每种休止符的写法差异很大，是检测中比较容易混淆的类别。
• 谱号类：高音谱号、低音谱号、中音谱号等，外形复杂，同一个谱号在不同字体下差异不小。
• 调号与临时记号：升号、降号、还原号，这些符号尺寸小，且经常出现在谱行开头或音符前面，是典型的小目标。
• 结构类：小节线、终止线、反复记号、连线、延音线、装饰音记号等。
• 文字符号：力度记号（p、f、mf）、速度术语、表情术语，这部分严格说属于文字检测，但和乐谱符号混排在一起，检测模型也可以一并处理。

我在实际项目中把类别控制在 15~20 类左右，这个粒度既能满足下游任务的需求，又不会因为类别太细导致训练样本不足和类别混淆。如果你刚开始做，建议先从 8~10 个大类入手，跑通流程后再细分。

1.2 为什么选 YOLOv5 而不是其他方案

这个问题的答案取决于你的约束条件：数据集规模、算力、部署环境、开发周期。YOLOv5 在这几个维度的平衡性在同类型框架里是最舒服的。

先说和 OCR 方案对比。传统 OMR 流程通常是图像二值化 + 谱线检测与去除 + 符号分割 + 模板匹配或分类器识别，这个流程对图像质量要求极高，扫描倾斜、纸张发黄、手写乐谱都会导致管线崩溃。而 YOLOv5 是端到端检测，直接从图像中学习符号的空间特征，对谱线、噪声有一定的鲁棒性，省去了大量预处理步骤。

再说和其他检测模型对比。如果你用 Faster R-CNN，精度可能略高，但推理速度慢，训练收敛也慢，对服务器资源要求高；如果用更高阶的 YOLOv8 或 RT-DETR，效果当然好，但如果你只是做乐谱符号检测这个垂直任务，YOLOv5 的成熟生态、大量现成教程和调参经验，能让你把更多精力花在数据而不是框架学习上。尤其是我这台机器的显存只有 8GB，YOLOv5s 的显存占用和 batch size 组合非常友好。

不过这里也想说句实在话：如果你做的不是“检测符号位置”而是“整页乐谱转录成 MusicXML”，那 YOLOv5 只是第一步，后面还需要接符号分类、谱线消除、语义理解等多个模块。检测模型的定位是“把符号找出来”，这个定位一定要在项目初期想清楚。

2. 乐谱数据集构建：采集、清洗与标注

2.1 乐谱数据来源与采集策略

数据集是整个项目的基石。YOLOv5 对数据量的要求其实不算极端，但乐谱识别的特殊性在于：符号类型多样、书写风格差异大、排版密度高，如果数据太单一，模型很容易过拟合到某一个字体或某一种扫描质量上。

我当时的数据来源主要有几个：

• 公开数据集：IMSLP（国际乐谱图书馆项目）上有大量公有领域的乐谱扫描件，这是最方便的大规模来源。但注意扫描件质量参差不齐，有些是 100 多年前的印刷版，纸张纹理重、符号模糊，这类数据需要人工筛选。
• 开源 OMR 数据集：比如 DeepScores、Muscima++ 这类学术数据集，它们有专门的乐谱符号标注，适合做预训练或作为补充训练数据。Muscima++ 还提供了符号之间的连接关系标注，对做后续结构化识别很有帮助。
• 自建数据集：用制谱软件（如 MuseScore、Sibelius）导出不同字体的乐谱图片，再手动标注。这样能控制符号样式和排版密度，补足公开数据集中缺少的类别。

采集策略上有几个容易被忽略的点：

• 分辨率统一：乐谱扫描件的分辨率差异很大，YOLOv5 默认输入 640x640，太小的图会被拉伸变形，太大的图会丢失小目标。我建议统一缩放到 150~300 DPI 再输入，过大的图可以用滑窗切图（tiling）处理。
• 覆盖不同排版密度：独奏谱、钢琴谱（两行大谱表）、总谱（多行谱表）的目标数量和密度完全不同。如果只训练独奏谱，遇到钢琴谱会明显掉点。
• 覆盖不同书写风格：手写乐谱和印刷乐谱的符号差异很大，如果业务场景是手写谱识别，训练数据必须包含手写样本，否则模型无法泛化。

2.2 标注类别的设计：粗粒度还是细粒度

标注类别的粒度选择直接决定了模型的上限。太粗（比如只分“音符”“符号”“文字”三类）会导致类内差异过大，模型收敛困难；太细（比如把每个音的绝对音高都作为类别）会导致类别爆炸，样本不足，模型完全学不动。

我建议按“结构等价”原则设计类别：外形相似、在后续处理中作用相似的符号归为一类。举个例子，不同音高的四分音符只需要归为“四分音符”一类，因为音高信息在检测框的 y 坐标里已经隐含了，后续可以通过谱线位置计算出来，不需要让分类器去学音高。

我的类别设计方案供参考：

• note-half：二分音符
• note-quarter：四分音符
• note-eighth：八分音符
• note-sixteenth：十六分音符
• rest-whole / rest-half / rest-quarter / rest-eighth
• clef-treble / clef-bass
• accidental-sharp / accidental-flat / accidental-natural
• barline-single / barline-double
• dot（附点）
• slur（连线）
• dynamic-p / dynamic-f / dynamic-mf

一共 18 类。类别的英文命名直接用 YOLO label 文件里的 class id 对应，后续代码处理起来也方便。注意“附点”这类小符号，尺寸非常小，很容易被遗漏，标注的时候要特别仔细。

2.3 标注工具与格式转换

标注工具我用的是 LabelImg 和 Label Studio 两个。LabelImg 轻量简单，适合快速标注；Label Studio 支持多人协作和自动标注（可以先用预训练模型预标注再人工修正），适合数据量大的项目。

YOLOv5 需要的标注格式是：每个图片对应一个同名的 txt 文件，每行是class_id x_center y_center width height，其中 x_center、y_center、width、height 是归一化到 [0,1] 的相对坐标。这个格式和 LabelImg 的 XML（Pascal VOC）或 Label Studio 的 JSON 不一样，需要转换。

我写过一个转换脚本的核心逻辑，这里给个参考片段：

import xml.etree.ElementTree as ET import os def voc_to_yolo(xml_file, class_names, target_dir): tree = ET.parse(xml_file) root = tree.getroot() img_w = int(root.find('size/width').text) img_h = int(root.find('size/height').text) txt_name = os.path.splitext(os.path.basename(xml_file))[0] + '.txt' lines = [] for obj in root.iter('object'): cls = obj.find('name').text if cls not in class_names: continue cls_id = class_names.index(cls) box = obj.find('bndbox') xmin = float(box.find('xmin').text) ymin = float(box.find('ymin').text) xmax = float(box.find('xmax').text) ymax = float(box.find('ymax').text) x_center = (xmin + xmax) / 2 / img_w y_center = (ymin + ymax) / 2 / img_h box_w = (xmax - xmin) / img_w box_h = (ymax - ymin) / img_h lines.append(f"{cls_id} {x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}") with open(os.path.join(target_dir, txt_name), 'w') as f: f.write('\n'.join(lines))

标注的时候有几个操作要点：

• 框要尽量贴合符号的实际边界，不要留太多空白。YOLO 的 anchor 匹配和 NMS 都依赖框的精度，框大了会引入背景噪声，框小了会截断符号特征。
• 粘连符号要拆开标。比如连在一起的附点音符，符头和附点要分别标，不要用一个框包住。
• 被谱线穿过的符号（音符符头经常骑在谱线上）也要照常标完整框，不要因为谱线干扰就缩小框的范围。

3. 训练配置与核心参数调优

3.1 数据集划分与目录结构

YOLOv5 的数据集目录结构是约定俗成的，建议直接按官方规范来，省去后续改配置的麻烦：

music-omr/ ├── images/ │ ├── train/ │ │ ├── 001.jpg │ │ └── ... │ ├── val/ │ │ └── ... │ └── test/ │ └── ... ├── labels/ │ ├── train/ │ │ ├── 001.txt │ │ └── ... │ ├── val/ │ │ └── ... │ └── test/ │ └── ... └── music.yaml

划分比例我用的是 8:1:1（train:val:test），这个比例在 5000 张图上表现不错。划分的时候要注意：同一个来源的乐谱（比如同一本书的不同页）不要同时出现在训练集和验证集里，否则模型会“记住”来源而不是学习泛化特征，验证结果虚高。

music.yaml的内容很简单：

train: /path/to/music-omr/images/train val: /path/to/music-omr/images/val test: /path/to/music-omr/images/test nc: 18 names: ['note-half', 'note-quarter', 'note-eighth', 'note-sixteenth', 'rest-whole', 'rest-half', 'rest-quarter', 'rest-eighth', 'clef-treble', 'clef-bass', 'accidental-sharp', 'accidental-flat', 'accidental-natural', 'barline-single', 'barline-double', 'dot', 'slur', 'dynamic']

3.2 模型选型与超参数确定

YOLOv5 有 s、m、l、x 四个规模，我推荐从yolov5s开始。原因很简单：乐谱符号不是极难检测的目标，s 模型已经具备足够的特征提取能力；训练速度快，可以快速验证数据质量和标注效果；显存占用低，对显卡要求不高。如果你的数据量很大（超过 1 万张）且检测目标特别小，再考虑用 m 或 l。

关于预训练权重：我从yolov5s.pt（在 COCO 上预训练）开始微调。虽然 COCO 没有乐谱类别，但预训练模型学到的底层特征（边缘、纹理、形状）对乐谱符号同样有效。用预训练权重比从零训练收敛快得多，尤其在你的数据集只有几千张时。

训练命令和关键参数：

python train.py --img 640 --batch 16 --epochs 200 \ --data music.yaml --weights yolov5s.pt \ --cache --device 0

几个参数的取舍逻辑：

• --img 640：YOLOv5 的默认输入尺寸。乐谱中有大量小目标（附点、临时记号），我试过 960，小目标召回率确实提升了一些，但训练速度明显下降，显存占用上升。建议先跑 640，观察 mAP 和小目标指标后再决定是否增大。如果你用 960 输入，最好同时开启--rect保持 batch 内图像宽高比一致，减少无效计算。
• --batch 16：8GB 显存下这个值是安全的。batch 太小（比如 4）会导致 BN 统计不稳定，模型收敛慢。
• --epochs 200：这个要结合早停（early stopping）来看，我在实际训练中大概 120~150 epoch 就基本收敛了，后面继续训练容易过拟合。
• --cache：把图像预先加载到内存，省去每个 epoch 重新读盘的 IO 时间。数据集几百 MB 时强烈建议开启。

3.3 训练过程中的数据增强与监控要点

YOLOv5 默认开启了 Mosaic 增强，把 4 张图拼成一张训练。这个增强对乐谱识别有个隐藏问题：乐谱排版密度本来就高，4 张图拼接后目标会变得非常密集，而且拼接边界处可能产生不自然的谱线断接。我在训练到中期（比如 60 epoch 后）会把 Mosaic 概率调低，让模型在真实分布上精调。

数据增强的调整在data/hyps/hyp.scratch-low.yaml里：

mosaic: 1.0 # 初始开启 mixup: 0.0 # 乐谱场景建议关闭，mixup 会导致符号语义混淆 fliplr: 0.5 # 水平翻转，乐谱里连音线、符干方向都包含语义，翻转有风险 flipud: 0.0 # 垂直翻转基本不能用，乐谱音符上下位置代表音高

这里特别注意fliplr。乐谱中符干方向（向上还是向下）是有语义的，比如低音区音符符干通常向上，高音区通常向下。水平翻转会把这种方向关系颠倒，模型容易学到错误规律。我在实际项目里把 fliplr 调到了 0.2，只保留一定的翻转增强来提升泛化，但不至于破坏语义结构。

训练过程中要盯的指标不只是 mAP。我会同时关注：

• train/box_loss、train/cls_loss和train/obj_loss：这些值应该稳步下降，如果 cls_loss 不降反升，大概率是标注类别有错或样本不均衡。
• metrics/precision和metrics/recall：乐谱检测里，我宁可 precision 略低也要保证 recall 高，因为漏掉一个音符比多框一个音符的后果更严重（下游 OCR 会直接断掉）。
• 每个 epoch 结束后的验证集预测图：这个最直观。我会定期打开runs/train/exp*/val_batch*.jpg看预测框和真实框的贴合情况，重点关注小目标和粘连符号。

4. 实际训练结果分析与效果评估

4.1 训练过程的收敛情况

我跑了一组 200 epoch 的训练，硬件是 RTX 3060 8GB，训练集 4200 张图，验证集 520 张图。这里贴一下关键指标的变化轨迹作为参考：

• 前 20 个 epoch：mAP@0.5 从 0 快速爬升到 0.6 左右，这个阶段模型在学大目标（谱号、小节线、符头）。
• 20~80 个 epoch：mAP@0.5 从 0.6 缓慢上升到 0.82，这个阶段主要在收敛小目标（附点、临时记号、十六分音符的符杠）。
• 80~150 个 epoch：mAP@0.5 在 0.83~0.85 区间震荡，继续训练收益不大，开始出现过拟合迹象（验证集 loss 回升）。
• 150 epoch 后：手动早停，保存最优权重。

最终评估指标（在验证集上）：

注意 mAP@0.5:0.95 只有 0.623，和 mAP@0.5 差了 0.23 左右，说明模型虽然能大致框住目标，但框的位置精度还不够高，尤其是 IoU 阈值提高后大量框被淘汰。这个问题的根源是乐谱符号的尺寸差异太大：全音符的框可能是附点的 20 倍大，YOLOv5 的多尺度特征融合对这种极端尺度差异处理能力有限。

4.2 按类别拆分的错误分析

只看 mAP 会掩盖很多问题。我把每个类别的 AP 单独列出来，问题一目了然：

表现差的基本集中在三类：小目标（dot，附点），细长目标（slur，连音线），高频低频样本（accidental-flat，降号）。

附点 AP 低的原因很直接：它的像素面积太小，在 640x640 输入下可能只有 8x8 像素，特征图上的信息非常有限。连音线 AP 低是因为它通常是细长的曲线，边界框的宽高比极端，YOLO 的 anchor 设计对这种形状不友好。降号 AP 低则纯粹是样本量不足，在古典钢琴谱里升号比降号常见得多，我的数据里降号只有升号的三分之一。

这个分析告诉我们：模型整体指标不差，但针对具体类别需要单独优化，不能一概而论。具体的解决办法我在下面第五部分展开。

5. 常见问题与排查技巧实录

5.1 小目标漏检：附点和十六分音符符杠

这个问题我在训练初期就遇到了。500 张验证图里，附点的召回率只有 40% 出头，很多预测框要么偏大、要么完全漏检。

我的排查和解决过程：

• 第一步先确认不是标注问题。我在 LabelImg 里重新抽查了 50 张图的附点标注，发现前期标注确实有一部分框偏大（包含了周围谱线），后面统一修正掉了。修正后 AP 提升了 5 个百分点，但还是很低。
• 第二步是增大输入分辨率。把--img从 640 调到 960，小目标的特征更明显，AP 从 0.61 提升到 0.72。代价是训练时间增加了约 1.5 倍。如果你的业务场景对附点这类小符号要求很高，这一步值得投入。
• 第三步是调整 anchor。YOLOv5 提供了自适应 anchor 计算，在训练前会基于你的标注框尺寸重新聚类 anchor。我在train.py参数里加了--noautoanchor选项禁用自动 anchor 来测试，发现默认 anchor 对乐谱的适配一般。取消--noautoanchor（即启用自动 anchor），用小尺寸 anchor 数量增加来提升小目标召回率。

另外一个更彻底的方案：把乐谱大图切割成 tiles 训练，比如 640x640 的图切成 4 张 320x320 的图，放大后再训练。这样小目标在输入中的像素占比更大，检测效果会显著提升，但推理时也需要对应做 tile 拼接后处理。

5.2 谱线干扰导致的误检

乐谱的五线谱是贯穿整页的水平直线，YOLOv5 在检测过程中很容易把谱线片段误检成小节线或者把符头周围的谱线误检成其他符号。我的训练初期出现过一种典型错误：模型把五线谱中的某一段当成 barline-double 来预测，precision 被拉低了很大一截。

排查后定位到两个原因：

• 数据增强里的随机裁剪可能产生“只有谱线没有音符”的图像块，这些负样本不够多，模型没有学会“谱线本身不是目标”。
• 小节线的标注框在跨越谱表时比较宽，形似一段谱线，模型难以区分。

解决办法有两个方向：

• 在训练数据里增加“纯背景”图像，也就是裁切出只有谱线没有符号的乐谱区域，标注成空文件（txt 文件为空）。这让模型明确学到“谱线不等于目标”。
• 针对小节线类别做区分：单小节线通常是单根竖线，终止线是粗线加细线，反复记号是两个点加两条竖线。如果业务只关心乐谱结构，可以把“小节线”简化检测为“竖线位置”，后续再通过后处理分类。我在项目里合并了 barline-single 和 barline-double 为一个大类 barline，再在后续逻辑里区分，效果好了很多。

5.3 类别不平衡：升号多降号少

古典钢琴谱中，升号调（G 大调、D 大调、A 大调等）的数量远多于降号调（F 大调、降 B 大调等），导致 accidental-sharp 的样本量是 accidental-flat 的三倍以上。模型在测试集上对降号的召回率明显偏低，这在高精度场景下不可接受。

我用了三种方法来缓解：

• 训练集重采样：对降号样本做过采样。实现起来比较简单——训练脚本里让采样器对包含降号的图片提高采样权重，或者直接对所有含降号的图片做多次复制（复制的同时做不同的数据增强，避免模型见过完全相同的图）。
• 复制粘贴增强（Copy-Paste Augmentation）：YOLOv5 官方代码里没有内置这个功能，但实现并不复杂。把图像 A 中的降号抠出来，随机粘贴到图像 B 的谱线上，同时修改 B 的 label 文件，增加一个目标框。注意粘贴位置要在谱线区域内，否则合成图像看起来不真实，模型容易学到错误的上下文。
• 扩充数据源：从 IMSLP 上专门找降号调的乐谱，补充标注。这个方法最直接，效果也最好，但需要人工筛选和标注，成本高。我当时补充了约 400 张降号调的乐谱，把降号类别 AP 从 0.67 拉到了 0.79。

5.4 验证集指标虚高与真实场景落差

训练时验证集 mAP@0.5 到过 0.9 以上，我当时还挺高兴的，结果拿手机随手拍的一张纸质乐谱去推理，效果惨不忍睹——大量漏检，甚至谱号都检测错了。这个落差让我意识到：验证集指标再好，如果你的验证集和真实场景分布不一致，一切都白搭。

问题出在数据分布偏移：

• 训练和验证集大多是电脑生成的乐谱截图或高质量扫描件，背景干净、符号清晰。
• 手机拍照的乐谱有透视畸变、光照不均、纸张阴影、遮挡（手指或谱架边缘）等问题。
• 模型没有见过“不完美”的图像，泛化能力自然差。

解决办法是主动污染训练数据：

• 用 OpenCV 做随机仿射变换（模拟拍照角度），旋转角度控制在 ±5 度以内。
• 随机调整亮度对比度，模拟阴影和反光。
• 用高斯模糊模拟低质量扫描。
• 更直接的办法：拿手机拍 200~300 张不同环境下的纸质乐谱，标注后加入训练集。这些真实照片对模型泛化能力的提升远高于人工合成的增强。

现在我在评估模型时，都会专门留出一部分“对抗样本”——包括手写体乐谱、低分辨率照片、强阴影环境下的图片——作为额外的验证集合，防止模型“高分低能”。

6. 模型导出与推理部署注意事项

6.1 导出 ONNX 与 TensorRT

训练好的 PyTorch 模型不能直接用于生产环境推理，我一般先导出 ONNX，再根据部署环境转成 TensorRT（NVIDIA GPU）或 RKNN（瑞芯微 NPU 平台，比如 RK3568）。

YOLOv5 自带了导出脚本：

python export.py --weights best.pt --include onnx --opset 12

导出后的 ONNX 模型需要特别注意几个问题：

• 输入输出节点名称：YOLOv5 的 ONNX 输出有三个头（不同尺度），节点名是output0、output1、output2，尺寸分别是[1, 255, 80, 80]、[1, 255, 40, 40]、[1, 255, 20, 20]（以 640 输入、18 类为例，255 = 3 * (18 + 5)）。如果你是自己写推理代码，这个结构要知道。
• NMS 处理：ONNX 里不包含 NMS，需要在后处理里自己实现或依赖 TensorRT 的 EfficientNMS 插件。我建议用 TensorRT 的 EfficientNMS，省去自己写排序和去重的麻烦。
• 动态尺寸：导出时默认是固定尺寸（比如 640x640），如果要支持动态分辨率，导出时加--dynamic。但动态尺寸在 TensorRT 上性能会差一些，除非业务必须，否则建议固定尺寸。

6.2 推理时的预处理细节

推理阶段的预处理如果和训练不一致，效果会打折扣。以下几个细节我在实际部署时踩过坑：

• 灰度图转三通道：有些乐谱扫描件是灰度图，直接读入是单通道。YOLOv5 训练时用的是三通道图，推理时如果是单通道，要用cv2.cvtColor(img, cv2.COLOR_GRAY2BGR)转成三通道，或者直接np.repeat复制成三通道。不能直接喂给模型。
• 归一化方式：YOLOv5 用的是像素值除以 255 归一化到 [0,1]，和很多框架的 [0,1] 或 [-1,1] 不一样，推理代码要匹配训练时的归一化。
• 长边缩放：YOLOv5 推理时会按长边缩放到 640，短边用灰色填充（letterbox）。这个操作必须在推理代码里复现，不能粗暴 resize，否则图像比例失真，框的位置也会偏。
• 小图放大：如果输入图本身小于 640，建议先放大再推理。我试过直接输入 400x300 的小图，精度损失很大，放大到 640 后再输入就好很多。

6.3 边缘设备部署的取舍

如果你的目标是部署到边缘设备（RK3568、RV1106 这类 NPU 平台），有几个建议：

• 模型量化：从 FP32 量化到 INT8，模型体积缩小到四分之一，推理速度提升明显，但有精度损失。乐谱符号检测对精度要求不算特别苛刻，INT8 量化后 mAP 通常会下降 2~4 个百分点，可以接受。量化需要准备校准数据集（几百张代表性乐谱图即可）。
• 剪枝：如果模型体积仍然太大，可以用 YOLOv5 官方的 prune 代码做通道剪枝。但剪枝对精度的损伤通常比量化大，且需要重训练恢复，不建议在项目初期使用。
• 算子兼容性：ONNX 导出后要检查有没有不支持的算子。YOLOv5 的 SiLU 激活函数在部分 NPU 上支持不好，可能需要替换成 ReLU 或 ReLU6 后重新训练，这是一个不小的工程调整。转 RKNN 之前一定要用rknn-toolkit的仿真器逐层验证算子支持情况。

7. 模型迭代与后续扩展方向

模型训练到第一版可用的程度只是开始。我在实际使用中体会到，乐谱识别真正难的是从“框出符号”到“理解乐谱”。后续扩展可以考虑几个方向：

• 检测结果的结构化输出：把检测框转换成 MusicXML 或 MIDI，需要根据框的位置关系推断音符音高（通过谱线位置）、时值组合（通过符杠和符尾关系）、调号（通过谱号后方的升降号序列）。这一步是规则驱动的，但规则写起来非常精细。
• 谱线消除作为预处理：如果做符号分类或转录，谱线是最大的干扰源。可以先用检测模型找到谱表区域，再在该区域内做谱线检测和移除，这样能提升后续识别的准确性。
• 用检测结果做版面分析：一排谱表包含哪些小节、哪些声部，可以通过检测到的谱号、调号、小节线和音符框的坐标关系推算出来。这个对自动伴奏、乐谱自动翻页等应用很有价值。
• 从单页识别到多页交互：如果做整本乐谱转录，还需要处理页码、页眉等额外元素，这些元素会干扰谱表区域的识别，检测模型可以加一个 page-element 类别来过滤。

从工程角度来看，乐谱识别的完整链路可以拆成“版面分析 - 符号检测 - 符号分类 - 关系解析 - 结构化输出”五步，YOLOv5 解决的是第二步（甚至同时解决第一步的一部分），这个定位决定了它不是银弹，但确实是整个链路中最容易先落地、也最能直观评估效果的一环。

最后分享一点个人体会：做这类垂直领域检测项目，数据质量永远比模型结构重要。我花在清洗标注数据、修正错误框上的时间，远超调参的时间，带来的收益也最大。如果你的数据集已经到位，但模型效果不理想，先去检查标注，不要急着换模型或加算力。

本文还有配套的精品资源，点击获取