简介在计算机视觉领域目标检测技术常被用于解决复杂场景下的元素定位问题而光学乐谱识别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 的成熟生态、大量现成教程和调参经验能让你把更多精力花在数据而不是框架学习上。尤其是我这台机器的显存只有 8GBYOLOv5s 的显存占用和 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-eighthclef-treble / clef-bassaccidental-sharp / accidental-flat / accidental-naturalbarline-single / barline-doubledot附点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 的 XMLPascal 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:1train: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 640YOLOv5 的默认输入尺寸。乐谱中有大量小目标附点、临时记号我试过 960小目标召回率确实提升了一些但训练速度明显下降显存占用上升。建议先跑 640观察 mAP 和小目标指标后再决定是否增大。如果你用 960 输入最好同时开启--rect保持 batch 内图像宽高比一致减少无效计算。--batch 168GB 显存下这个值是安全的。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 个 epochmAP0.5 从 0 快速爬升到 0.6 左右这个阶段模型在学大目标谱号、小节线、符头。20~80 个 epochmAP0.5 从 0.6 缓慢上升到 0.82这个阶段主要在收敛小目标附点、临时记号、十六分音符的符杠。80~150 个 epochmAP0.5 在 0.83~0.85 区间震荡继续训练收益不大开始出现过拟合迹象验证集 loss 回升。150 epoch 后手动早停保存最优权重。最终评估指标在验证集上指标数值mAP0.50.851mAP0.5:0.950.623Precision0.876Recall0.794注意 mAP0.5:0.95 只有 0.623和 mAP0.5 差了 0.23 左右说明模型虽然能大致框住目标但框的位置精度还不够高尤其是 IoU 阈值提高后大量框被淘汰。这个问题的根源是乐谱符号的尺寸差异太大全音符的框可能是附点的 20 倍大YOLOv5 的多尺度特征融合对这种极端尺度差异处理能力有限。4.2 按类别拆分的错误分析只看 mAP 会掩盖很多问题。我把每个类别的 AP 单独列出来问题一目了然类别AP0.5note-quarter0.913note-half0.884clef-treble0.932barline-single0.907dot0.612accidental-flat0.675slur0.582dynamic0.743表现差的基本集中在三类小目标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 AugmentationYOLOv5 官方代码里没有内置这个功能但实现并不复杂。把图像 A 中的降号抠出来随机粘贴到图像 B 的谱线上同时修改 B 的 label 文件增加一个目标框。注意粘贴位置要在谱线区域内否则合成图像看起来不真实模型容易学到错误的上下文。扩充数据源从 IMSLP 上专门找降号调的乐谱补充标注。这个方法最直接效果也最好但需要人工筛选和标注成本高。我当时补充了约 400 张降号调的乐谱把降号类别 AP 从 0.67 拉到了 0.79。5.4 验证集指标虚高与真实场景落差训练时验证集 mAP0.5 到过 0.9 以上我当时还挺高兴的结果拿手机随手拍的一张纸质乐谱去推理效果惨不忍睹——大量漏检甚至谱号都检测错了。这个落差让我意识到验证集指标再好如果你的验证集和真实场景分布不一致一切都白搭。问题出在数据分布偏移训练和验证集大多是电脑生成的乐谱截图或高质量扫描件背景干净、符号清晰。手机拍照的乐谱有透视畸变、光照不均、纸张阴影、遮挡手指或谱架边缘等问题。模型没有见过“不完美”的图像泛化能力自然差。解决办法是主动污染训练数据用 OpenCV 做随机仿射变换模拟拍照角度旋转角度控制在 ±5 度以内。随机调整亮度对比度模拟阴影和反光。用高斯模糊模拟低质量扫描。更直接的办法拿手机拍 200~300 张不同环境下的纸质乐谱标注后加入训练集。这些真实照片对模型泛化能力的提升远高于人工合成的增强。现在我在评估模型时都会专门留出一部分“对抗样本”——包括手写体乐谱、低分辨率照片、强阴影环境下的图片——作为额外的验证集合防止模型“高分低能”。6. 模型导出与推理部署注意事项6.1 导出 ONNX 与 TensorRT训练好的 PyTorch 模型不能直接用于生产环境推理我一般先导出 ONNX再根据部署环境转成 TensorRTNVIDIA 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 解决的是第二步甚至同时解决第一步的一部分这个定位决定了它不是银弹但确实是整个链路中最容易先落地、也最能直观评估效果的一环。最后分享一点个人体会做这类垂直领域检测项目数据质量永远比模型结构重要。我花在清洗标注数据、修正错误框上的时间远超调参的时间带来的收益也最大。如果你的数据集已经到位但模型效果不理想先去检查标注不要急着换模型或加算力。本文还有配套的精品资源点击获取