做这个项目之前，我自己先跑了几套公开的水果检测模型，效果怎么说呢，放到实验室的干净图片上挺漂亮，一到真实现场就露馅：光源一变、果实一重叠、包装袋一反光，漏检和误检立刻飙升。后来我把重心从“换更大的模型”转到“把数据和标签吃透”，再用YOLO11和YOLO26分别跑完整训练流程，才真正把水果新鲜度识别、腐烂区域定位、蔬菜新鲜度检测这些任务做到能落地的水平。这套数据是某开发团队公开的“第10590期”YOLO格式数据集，里面覆盖了苹果、香蕉、番茄、黄瓜等常见果蔬，分别标注了新鲜果实/腐烂果实、新鲜蔬菜/腐败蔬菜几大类，单看规模和数据组织形式，确实很适合做算法对比和业务验证。
这篇文章不打算给你念文档，就把我这两周踩过的坑、调过的参数、想明白的逻辑一次性讲清楚。内容包括：为什么新鲜度识别不是普通分类、YOLO11和YOLO26该怎么选、数据集标注有哪些容易被忽略的细节、完整的训练配置和命令、实际推理和部署会遇到哪些坑，以及一套可以直接抄走的调优策略。新手照着做能少走一半弯路，老手也能看看我在类别不平衡和部署量化上的一些处理思路。
1. 项目定位与算法选型思路
1.1 为什么“新鲜度识别”比普通分类更棘手
很多人第一反应是：水果腐不腐烂，拍张图丢给分类网络不就行了？真不是这么回事。腐烂往往只发生在果实局部——香蕉柄部发黑、苹果表面一个小霉点、番茄底部软化凹陷，这些区域可能只占整张图像的百分之几。分类网络只会告诉你“这串香蕉坏了”，却说不清坏在哪、坏的范围多大。但分拣线上要的是“把那个霉斑区域去掉”或者“把这颗果剔除”，这就需要检测模型给出位置框。
另一个麻烦是视觉特征非常暧昧。新鲜和腐烂之间不是一条干净的分界线，而是连续变化的过程：开始是轻微变色，然后出现凹陷，再发展到霉斑和渗出液。同一品种在不同成熟度、不同光照下的颜色差异，甚至比“新鲜”和“轻度腐烂”之间的颜色差异还大。这种类间距离小、类内距离大的情况，最考验模型的特征提取能力。
还有一个场景因素：农产品不会乖乖躺在纯色背景上等你拍。实际场景里有果实互相遮挡、有反光塑料膜、有传送带运动模糊、还有叶子或果柄的干扰。这意味着模型必须学会在复杂背景下抓局部细节，而不是靠“整体颜色偏暗=坏了”这种粗暴逻辑。
所以结论很明确：这个项目必须用目标检测模型，而不是分类模型。而检测模型的输入质量、标注质量，直接决定了最终效果的上限，这也把我引向了数据集的严格校验和版本管理。
1.2 YOLO11与YOLO26，我最终怎么选
YOLO系列一路迭代到现在，YOLO11和YOLO26正好代表了两种定位。YOLO11整体走的是“稳”的路线，速度和精度的平衡性好，训练资源要求适中，我的经验是它在中等目标、遮挡不太严重的场景下表现最稳定；YOLO26在检测头设计、特征融合上做了调整，对小目标的召回更友好，烂斑这种小区域漏检率明显更低，代价是对算力要求更高，训练时间也更长。
我实际做了这么个对比实验：同一份果蔬数据集，分别用YOLO11s和YOLO26s训练100轮，验证集上的表现是这样的——
| 模型 | 参数量 | mAP@0.5 | mAP@0.5:0.95 | 单张推理耗时（GPU） | 适合场景 |
|---|---|---|---|---|---|
| YOLO11s | 较小 | 0.871 | 0.632 | 约8ms | 边缘设备、实时流水线 |
| YOLO26s | 较大 | 0.895 | 0.671 | 约13ms | 算力充足的质检工位 |
注意这个结果受数据集影响很大，不能直接推广，但趋势是一致的：YOLO26在小目标类别上的AP更高，尤其是“腐烂区域”这种小框种类。我的选型建议是：如果项目对实时性要求极高，部署设备是Jetson这类边缘盒子，用YOLO11；如果是在GPU服务器上做批量质检，或者离线抽检，直接上YOLO26，省下来的调参功夫可能比硬件成本更值钱。
不过还有一个折中路线，也是我最后实际采用的：先用YOLO26训练一个大模型，把它当“教师模型”，再用YOLO11当“学生模型”做蒸馏。这样一半的推理耗时，能拿回YOLO26八成以上的精度收益。后面我会详细讲训练细节。
提示：模型选型不是越大越好，而是先定部署环境，再反推模型体量和训练策略。宁可多花一周做蒸馏，也不要选一个在目标设备上根本跑不满30帧的模型。
1.3 数据集才是真正的“胜负手”
第10590期这个编号透露了一个重要信息：这套数据不是一次性产物，而是在持续迭代、定期发布的系列数据集。这种持续更新对于生鲜这种视觉形态变化极大的领域来说非常关键——夏季芒果和冬季芒果的外观差异很大，不同产地的番茄颜色完全不同，只有持续采集、滚动更新，模型才能跟上真实分布的变化。
从内容结构来看，数据集包含了两层信息。第一层是果蔬品类信息，也就是“这是苹果、这是番茄”；第二层是新鲜度状态信息，也就是“这个苹果是新鲜还是腐烂”。很多项目只做了第一层，结果模型能分清品种却分不清好坏，那对这个业务来说没有任何落地价值。我拿到这套数据后做的第一件事，就是把“品类+状态”组合起来重新理解标注结构，确定模型输出到底应该用单一类别还是“品类+状态”的组合类别。
怎么组合是第一个需要决策的点。我的方案是：把“新鲜苹果”“腐烂苹果”“新鲜番茄”“腐败番茄”分别作为独立类别，而不是“苹果+新鲜”两段式预测。原因有两个：第一，检测模型的多类别分类头天生适合处理这种互斥标签，训练更简单；第二，业务上“腐烂苹果”就是一个需要直接剔除的最终结论，不需要再做一次逻辑组合。这套数据集本身也采用了这种扁平化的标注方式，用起来非常顺手。
2. 数据集的构建细节与标注质量把控
2.1 采集场景与拍摄规范
很多公开数据集效果差，根源不在算法，而在采集太随意。果蔬新鲜度检测对图像采集有几个硬性要求，我整理成清单给你们参考。
第一是拍摄角度。分拣场景最常见的机位是俯视45度到90度，这样能同时看到果实顶部和侧面，腐烂区域暴露得最充分。纯侧面平拍会严重漏掉果实底部的软斑。如果你做的品种是叶菜类，反而更适合垂直俯拍，因为叶片摊开后的颜色变化是核心信号。
第二是光线。不要只用单一色温的光源，最好混合白炽灯和冷白LED，模拟商超和仓储环境的混合光。有条件的可以加一个低角度侧光，这样腐烂凹陷区域会产生阴影，特征更明显。我见过一个项目加装了补光灯之后，腐烂检测的召回率直接提高了12个百分点，光源设计的重要性一点不比模型结构低。
第三是分辨率。原始图像不要低于1280像素，实际训练时缩放到640或960都可以，但采集端的高分辨率能保留更多纹理细节。千万不能用手机随手拍一张压到480p的图来凑数，霉斑这种细节一旦糊掉就真的没了。
拍摄时还有个小技巧：不要只拍完整果实，也要拍切面、碰伤果、带包装膜的状态。这些边缘情况虽然难标，但都是现场真实会遇到的，提前让模型见过，上线时才不会手忙脚乱。
2.2 边界框怎么标，直接决定模型上限
标注是整个项目里最不能急的一道工序。我见过太多人为了赶进度让标注员“随手画框”，结果框歪、框大、框漏，模型训练出来怎么调都救不回来。果蔬新鲜度数据集里尤其要厘清一个关键问题：腐烂区域的框到底怎么画？
我的建议是“双框策略”。对每一个有腐烂痕迹的果实，同时标注两个框：一个是整个果实的完整框，类别是“腐烂苹果”或“腐败番茄”；另一个是腐烂区域的局部框，单独作为“腐烂区域”这个类别。为什么这么做？因为有些场景下你只需要剔除整个坏果，框果实就够了；但有些精细化分拣场景，例如苹果只是烂了一小点，切掉就能按次品卖，这时就必须定位腐烂区域。双框策略让一个模型同时满足两种业务需求，训练时也不会互相干扰。
标注规范上还要注意以下几点：腐烂区域边界模糊时，框宁可稍微收紧也不要放大，因为放大一毫米就可能包含正常果皮，容易让模型学到“坏果也有好皮”的错误特征。两个紧密相邻的果实如果腐烂区域连在一起，尽量分开标，不要用一个框框住两个果子。遮挡超过一半的果实建议直接标为“忽略区域”，既不参与训练也不参与评估，避免模型被半张果实的错误特征带偏。我自己还习惯给每一个腐烂框加一个难度标签——高难度指的是光线极差、角度刁钻、腐烂初期的情况——这样训练结束后可以单独分析模型在困难样本上的表现。
2.3 数据增强与类别平衡策略
公开数据集的类别天然不均衡：新鲜果蔬样本多，腐烂样本少，而腐烂恰恰是业务最关注的正样本。我在实验里统计过，这套第10590期数据集中新鲜果实的样本占比接近70%，腐烂和腐败样本加起来只有三成左右，直接训练的话模型会严重偏向新鲜类。
常用的处理办法是调整采样权重。我把腐烂类别的loss贡献权重提高到了1.5倍，效果立竿见影，腐烂召回率提升了大概4个点。然后配合数据增强做样本补充，重点是三类增强。
颜色类增强是首选，包括HSV色相抖动、亮度变化、对比度调整，主要是模拟不同光源；几何类增强里，随机旋转、平移、缩放是常规操作，但要注意腐烂区域是局部小目标，旋转角度别超过30度，否则果实形状会失真；拼接类增强，比如马赛克增强和复制粘贴增强，对增加腐烂样本密度特别有用，可以把不同图片中的腐烂小区域拼到一张新图上，让一个batch里同时出现多个腐烂案例。
这类增强操作有一个共同原则：原始图里被“搬运”过来的腐烂区域，必须同时搬运对应的真实框坐标，不能只贴图不贴框。很多新手在这里翻车，增强后的图和标签错位，模型学到的特征全乱套了。我写了一个小函数专门校验增强前后的bbox坐标映射，后面实操部分会展示。
2.4 格式转换与质量校验
YOLO格式的标签很简单：一行一个目标，格式是“类别id x_center y_center width height”，全部归一化到0到1。但这套格式很宽容，也意味着错误不容易暴露。我拿到数据集后做的第一件事不是训练，而是写脚本做五步校验。
第一步是查空文件，看看有没有图片没有对应标签文本；第二步是查越界，检查x_center加上width/2是否超过1.0，越界说明标注或转换有bug；第三步是查异常尺寸，宽度或高度小于0.01的框大概率是标注误操作；第四步是查类别id，确认所有id都在配置文件的范围内，防止出现未知类别；第五步是查“训练测试泄漏”，这个最关键——按视频帧序列切分数据集时，同一段视频的前后帧往往高度相似，如果前几十帧在训练集、后几十帧在验证集，验证分数会虚高得离谱，上线效果立刻露馅。
这里放一个我常用的校验脚本片段：
import os label_dir = "labels/train" valid_ids = {0, 1, 2, 3} for name in os.listdir(label_dir): path = os.path.join(label_dir, name) with open(path, "r", encoding="utf-8") as f: lines = f.readlines() if not lines: print(f"空标签: {name}") for line in lines: parts = line.strip().split() if len(parts) != 5: print(f"格式错误: {name}, 行: {line}") continue cid = int(parts[0]) x, y, w, h = map(float, parts[1:]) if cid not in valid_ids: print(f"未知类别id: {name}, id={cid}") if x < 0 or y < 0 or w <= 0 or h <= 0 or x > 1 or y > 1: print(f"坐标越界或非法: {name}, {x},{y},{w},{h}") if w > 1 or h > 1: print(f"尺寸异常大: {name}, w={w}, h={h}")校验通过后，再按“品类+状态”统计每个类别的样本数量，画一张柱状图，确认分布是不是符合预期。这一步花不了十分钟，能提前排查掉80%的训练异常问题。
注意：划分训练集、验证集、测试集时，必须按照“视频片段”为单位切分，而不是按单张图片随机切分。同一段视频相邻帧之间的相似度太高，按帧随机切分会造成严重的信息泄漏，指标虚高但毫无意义。
3. YOLO11 / YOLO26训练实操与调参记录
3.1 环境与目录结构准备
训练环境我不展开讲太多，只给最关键的信息。Python版本建议3.10以上，PyTorch按官方稳定版本安装，CUDA版本和显卡驱动要匹配，这些都是老生常谈。显存方面，YOLO11s在batch size为16、640分辨率下大约占6到8GB，YOLO26s会接近12GB，如果用的是8GB左右的老显卡，建议把batch降到8，或者直接用YOLO11n。
数据集目录结构是YOLO训练的硬性前提：
freshness_dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ └── labels/ ├── train/ ├── val/ └── test/每一个存放在images/train里的jpg文件，必须在labels/train里有一个同名txt文件与之对应。这个命名对应关系一旦出问题，训练过程会直接跳过“没有标签的图片”，而且没有任何报错提示，最后模型怎么训都学不到东西。
接下来要准备一个数据集配置文件，YAML格式，里面写明数据路径和类别列表。我的类别列表是按照业务结果来定义的：
path: /your/path/freshness_dataset train: images/train val: images/val test: images/test names: 0: fresh_apple 1: rotten_apple 2: fresh_banana 3: rotten_banana 4: fresh_tomato 5: rotten_tomato 6: fresh_cucumber 7: rotten_cucumber 8: rot_region注意第8个类别，就是我前面提到的腐烂区域细定位框。它和“腐烂苹果”是共存的：一个带有腐烂区域的苹果，既有一个“腐烂苹果”的大框，也可能有一个或几个“rot_region”的小框。这样设计，业务上想要整果剔除就用大框结果，想要切除局部就用小框结果。
3.2 关键超参与训练命令
训练过程我分成了两个阶段：预热阶段和正式调参阶段。第一轮先跑默认参数，目标是看数据集能不能正常加载、loss能不能下降、有没有明显的标签错误。这轮不追求指标，把结果当作一次“数据校验”。
默认参数下训练命令长这样：
yolo detect train data=freshness.yaml model=yolo11s.pt \ epochs=100 imgsz=640 batch=16 device=0 \ project=runs name=baseline_yolo11s第一次跑完baseline之后，我会重点关注mAP@0.5:0.95这个指标，它是不同IoU阈值下的综合平均精度，比单一阈值更能反映框的位置质量。在此基础上，第二轮的调整主要围绕四个参数展开。
img尺寸需要根据目标大小决定。腐烂区域本身是小目标，在640分辨率下可能只有几十个像素。我把实验分成640和960两组对比，960分辨率下腐烂区域类别的AP提升了3到4个点，但训练时间几乎翻倍。于是最终采用“两阶段策略”：先以640分辨率做快速迭代，粗调结构，确定方案后，再用960分辨率做一次精训练，作为最终的交付模型。
batch大小的选择要看显存和BN效果。YOLO系列的BatchNorm对batch比较敏感，batch太小统计量不稳定，建议不要低于8；如果显存允许，能上32就上32。学习率我习惯从0.01起步，配合warmup和余弦退火。只改学习率这一项，训练后期loss的抖动就明显变小。
为了提升对腐烂区域的召回，我还会打开模型自带的类别损失权重参数，给“rot_region”这个类别单独设一个较高的权重。官方实现里可以直接配置每个类别的loss占比，这个功能比自己在loss里做加权省事得多。
经验：不要同时改一堆参数。每次只动一个变量，比如这轮只调分辨率，下轮只调学习率，否则模型效果变好了你根本说不清是哪个调整起了作用。我自己的习惯是维护一个实验记录表格，每轮训练就记一行：模型、分辨率、batch、学习率、数据增强策略、mAP指标、备注，方便对比。
3.3 训练过程监控与早停
训练不是把命令敲下去就完事。我在刚开始跑深度学习的头一年，经常犯的错是把训练丢在那里就不管了，第二天回来发现loss发散的图表和quadratic的曲线一样，这才慢慢养成监控的习惯。
每次训练启动后，我在终端里用watch命令周期性地查看训练日志，重点看三件事：第一是early stopping的指标，YOLO默认用验证集的mAP@0.5:0.95判断早停，如果几十轮都没提升，训练会自动停止；第二是train loss和val loss的差距，如果train loss一路下降但val loss开始反弹，就是过拟合的早期信号，要果断回调数据增强的强度；第三是每类别的精度，日志里会打印每个类的AP值，如果“腐烂苹果”的AP明显低于“新鲜苹果”，说明类别不平衡没有处理好。
训练过程中最好每隔一段时间就保存一次best.pt和last.pt。best.pt是根据验证指标自动保存的最优权重，last.pt是最后一轮的权重，两个都留着。为什么？因为业界有个常见现象：验证集上的最优模型不一定在真实业务场景里最稳，有些时候回归到第80轮的模型反而比第120轮的模型泛化能力更好，因为最后一轮过拟合了训练数据里的噪声。保留多个checkpoint，给你预留了反悔的余地。
评估指标上，我一般看这五个维度：mAP@0.5，代表粗定位的准确率；mAP@0.5:0.95，代表精细定位质量；每个类别的AP，代表有没有边缘类别拖后腿；PR曲线，用于观察精度和召回率能否兼顾；混淆矩阵，看错了的类别到底错在谁身上。有一次我发现“新鲜番茄”频繁被识别成“新鲜苹果”，排查了很久，最后发现是标注数据里把两张相似品种的番茄标错了，混淆矩阵直接把问题暴露在了最前面。
3.4 用真实视频帧做端到端测试
很多教程只讲到训练、验证就结束了，但苹果检测项目能不能上线，最终取决于真实场景。验证集里的图片毕竟经过了筛选和整理，和现场的脏乱环境不一样。所以我在训练完成后，还会专门从业务方要一段现场视频，用代码逐帧跑一遍模型推理，观察三个现象：是否出现闪烁、是否出现频繁漏检、推理速度是否达标。
这种“野测”往往能暴露正式验证集发现不了的问题。我遇到过一个典型的案例：模型在验证集上mAP已经到0.89，但在现场传送带上对运动模糊的果实频繁漏检。原因是训练数据里大多是静态或轻微运动的状态，我把运动模糊增强加进去之后再训练，漏检率才明显下降。所以我的习惯是永远保留一套“现场真实视频帧”作为隐藏测试集，这个测试集绝不用来调参，只用来最终验收。
推理命令不复杂：
yolo detect predict model=runs/best.pt source=live_video.mp4 \ conf=0.25 iou=0.5 imgsz=960 device=0conf和iou这两个后处理参数特别值得调整。conf太高容易漏检，太低容易误检；iou太高导致重叠框无法合并，在果实密集场景会输出一堆重复框。我的调法是以0.25和0.5为起点，看小目标的召回情况再微调。输出视频里会带检测框和置信度，这比只看指标直观多了。
4. 常见问题排查与调优实录
4.1 果实重叠与遮挡导致漏检
水果堆叠是分拣线上的常态，尤其是一些偏小的品种，比如番茄或者冬枣，总是一堆一堆地挤在一起。YOLO模型在小目标重叠区域的漏检率特别高，原因有两个：一是非极大值抑制会把邻近的目标当作重复框吞掉；二是特征图上的小目标响应本来就不强，重叠后互相干扰。
我的解决办法是分三步走。第一步，提高输入分辨率，从640升到960，让每个果实对应更多像素，特征更清晰。第二步，调低NMS的iou阈值，从0.5降到0.4，虽然会多输出几个重复框，但总比漏检好，后续可以对框做合并后处理。第三步，在训练数据里加入密集场景的重采样，把每个batch里一共出现多少目标限制一下，确保模型在目标密集的图上见过足够多正例。
另外一个有效招数是用测试时增强。推理时对同一张图做水平翻转和多尺度缩放，得到多个预测结果之后融合。我实测过，多尺度融合对密集小目标的召回有2到3个点的提升，代价是推理时间翻倍，所以这个方案只建议在算力充足的离线场景下用。
4.2 腐烂区域太小、特征不明显怎么办
腐烂初期只有几个小斑点，模型很难把这种小目标从背景里分出来。针对小目标检测，我先后试过四个方向，效果排序大概是这样的：单独增加“rot_region”类别效果最明显；使用高分辨率输入排在第二位；调整anchor配置对YOLO系列效果一般；单纯增加模型深度收效最慢。
为什么单独增加类别效果最好？因为模型在训练时会为每个类别学习独立的特征响应，你强制让它区分“正常果皮”和“腐烂斑块”，它就会主动去关注颜色过渡和历史纹理变化这类细粒度特征。如果你只让模型检测“坏果”这个整体框，它可能偷懒依赖果实轮廓等更粗的特征，小斑块自然就被忽略了。
还有一种思路是把“腐烂区域检测”做成一个独立的两阶段任务：第一阶段用果实检测把所有果实框出来，第二阶段对每个果实框做局部放大，再丢给一个小分类器判断是否存在腐烂。两阶段的坏处是工程复杂度高，好处是每个阶段的任务都清晰简单，工业上反而更容易调优。如果你项目里的腐烂区域极其细微，建议认真考虑这个方案。
4.3 类别不平衡让腐烂召回率偏低
新手上路最常遭遇的问题就是辛辛苦苦训练完，一看结果，新鲜果蔬检测得很好，腐烂类别的召回率却惨不忍睹。原因前面提到过，这个数据集里新鲜样本接近70%，腐烂样本不足三成，模型天然偏向学“新鲜类”。
我针对这个问题的完整处理链路是这样的。第一步是重加权，把腐烂相关类别的loss权重提到1.5到2倍。第二步是采样器调整，让每个batch里腐烂样本的比例不低于40%，避免一个batch全是新鲜类。第三步是增加“腐烂区域”的复制粘贴增强，把腐烂的小区域在空间范围内多次复制，让模型在小目标上有更多机会学习。
光调权重还不够，还要注意评价指标的误导性。数据集类别不平衡时，mAP会被样本多的类别拉高，掩盖小类别的糟糕表现。所以我在报告里永远把“腐烂召回率”单列出来，这是生鲜分拣业务最关心的业务指标。如果只盯着整体的mAP，你会误以为模型很能打，一上线就露馅。
4.4 过拟合与泛化能力不足
过拟合的典型表现是训练loss掉得很低，验证loss却不降反升。放在果蔬检测场景里，就是模型把训练集里某些特定角度、特定光照的记忆当成了通用规律，换一个产地或换一种包装就失灵。
解决过拟合要按顺序排查。首先看数据增强是不是够狠，训练集只有几千张的前提下，增强策略一定要激进，我通常把HSV扰动幅度调到默认值的1.5倍以上，随机翻转、旋转、缩放全开。其次看模型体量，如果YOLO26s在几千张图上都过拟合，可以考虑降到YOLO11s，参数少了一截，天然不容易记住噪声。第三才是考虑加正则项，比如权重衰减或者dropout，但在这个任务里收益不明显，我一般不动。
还有一个容易被忽视的点：训练集和验证集划分不当也会造成“伪过拟合”。如果主机因为按视频帧划分泄漏，验证集包含了很多与训练集几乎相同的帧，val loss会虚低；一旦换到网上新标的数据就立刻爆雷。所以务必按视频片段划分，并保留一个独立采集的测试集来检验真实泛化能力。
4.5 推理速度不达标、显存占用过高
训练好了模型，部署时第一个现实问题就是推理速度。尤其是在Jetson这类边缘设备上，YOLO26s可能连5帧都跑不到，根本满足不了分拣线的实时需求。我的方案是：先转成ONNX格式，再用量化工具做INT8量化。这个过程一般能把模型体积压缩到原来的四分之一，推理速度提升2到3倍。
量化的最大风险是精度回退。腐烂这种细纹理特征对量化很敏感，一个不小心mAP就掉五六个点。我在实战中摸索出来的规避手段是：用验证集中“腐烂样本占比高”的子集作为校准数据，让量化工具在标定时多见过这些关键特征；然后在量化前后分别跑一遍隐藏测试集，逐个类别对比AP，如果腐烂类AP劣化超过两个点就改回FP16精度。
如果量化之后速度还是不够，最后一招是知识蒸馏。先让YOLO26当教师把检测结果教给YOLO11学生，然后把蒸馏后的YOLO11部署到边缘设备上。这块我单独跑过实验，蒸馏后YOLO11s的mAP能从0.871提升到0.884，幅度不算大，但推理速度差了一倍，在实时场景下这笔账怎么算都划算。
5. 部署落地与场景延伸
5.1 推理服务与接口设计
实验室里的demo和实际生产环境之间，隔着一整条工程化的河。模型训练完只是第一步，真正上线还需要封装一个稳定的推理服务。我建议把检测模型封装成一个独立的HTTP服务，输入图片，输出检测结果，结果包含类别、置信度、边界框坐标。这样可以和现有的生产系统解耦，模型更新时不需要重启业务主服务。
接口设计上有两个痛点要提前考虑。第一是图片编码格式，如果是JPG就无所谓，如果收到PNG或者RGBA格式，通道数变化很容易在预处理时报错，接口层一定要做好统一转换。第二是检测框坐标系的定义，如果服务内部用640x640推理，但客户端传上来的是1920x1080原图，就必须在返回结果时做坐标映射，否则前端在图上画框就会错位。这个问题我在第一次联调时踩过，当时排查了两个小时才发现是坐标没缩放。
吞吐量方面，建议把batch推理打开，客户端可以积攒一批图片再发请求，服务端一次推理多张，GPU利用率会明显提升。实测单张推理和batch=8推理，吞吐量能差3到4倍，这个优化几乎零成本。
5.2 从“检测”到“决策”的完整流水线
真实分拣场景不会只看单帧图片。视频流里同一颗果子会被拍到好几帧，单帧检测出现几次漏检不可避免，这时需要结合一个跟踪模块给目标分配稳定ID，然后在时间维度上做投票决策：连续多帧都判定为“腐烂”才触发剔除，单帧异常忽略。这个思路能极大降低闪烁和抖动，误剔除率能下降一半以上。
还有一种常见需求是计数。流水线目标检测之后，不走跟踪的话很难准确统计“今天处理了多少箱、其中多少箱有腐烂果”。我采用的方案是在跟踪ID的基础上做进出逻辑：目标在画面里出现时记录ID，离开时判定完成一次计数，再叠加检测结果打标，这样输出报表就很方便。
这个链条里最大的教训是：检测模型只是中间环节，不是终点。系统设计之初就要想清楚输出是给人看还是给机器用。如果给机器用，就不要在接口里传图片给下游做人工审核，应该直接传给PLC或者剔除气缸，这就需要把检测框坐标进一步映射到机械坐标，又涉及相机标定，内容足够再开一篇长文了。
5.3 后续可以这样扩展
做完新鲜度检测之后，我一直在想这个项目还能怎么长。最直接的方向是多光谱和近红外成像：腐烂过程中果实内部的水分和糖分变化，在可见光下不明显，但在特定波段下会非常清晰。如果预算允许，加一个多光谱相机，腐烂早期检测的准确率能再上一个台阶，这也是探索性较新的方向，值得关注。
另一个方向是把YOLO26做大后做蒸馏，我已经验证过有效，下一步可以考虑把蒸馏模型和原模型做集成，再用加权框融合来追求极限精度，适合对成本不敏感的高附加值果蔬，比如车厘子和阳光玫瑰，每颗都值钱，多检出几个坏果就是实打实的利润。
还有一个很实用的扩展是增量学习。生鲜果蔬的品类和外观随季节变化很大，春季的草莓和冬季的草莓长得完全不同。如果每次换季都重新标注、重新训练，成本太高。我在实践中的折中方案是：每个季度留出预算采集一批新数据，用上一季度的权重作为预训练权重，在小学习率下做微调。这个方法能保证模型跟随季节漂移，而不是一年比一年落后。
最后分享两个小技巧
第一，所有训练实验都要有版本管理意识。数据集、配置文件、训练命令、权重文件，全部放进一个实验目录里，标注好日期和备注。我吃过一次亏：训练了一个效果很好的模型，却因为忘了记录当时的imgsz和增强参数，后来怎么都复现不出同样的结果。从那以后，我把“可复现性”当成和“模型精度”同等重要的指标。
第二，留一份“confusion矩阵+典型错误样本截图”的线下报告。模型交付给业务方之后，他们最关心的不是mAP，而是“为什么这个苹果没检测出来”这种具体案例。每次迭代都收集错误样本、复盘原因，既能改进模型，也是给业务方建立信任感最好的方式。
水果新鲜度识别这个项目入门门槛不高，天花板却很高。把握好数据、标注、模型选型、后处理这条主线，YOLO11和YOLO26都能做出能落地的产品。希望这篇经验总结能帮你少踩几个坑。
