企业官网建设流程全解析

简介：本资源是一套基于YOLOv5的果蔬图像识别系统实现方案，面向计算机科学与技术、人工智能等相关专业的本科生毕业设计与课程实践需求，解决农业场景下常见果蔬目标检测与分类的实际问题。资源包共717个文件，涵盖546张标注JPG图像、119个备份文件（.zbak）、15个核心Python训练与推理脚本、12张可视化PNG图、7张JPEG测试样本及XML标注文件、H5模型权重等，完整呈现从数据采集、标注、预处理到模型训练、评估与部署的全流程，压缩包大小为268.88MB。已有55人学习下载，适用于具备机器学习基础的学习者开展项目复现与算法优化。读者可直接获取经导师审核获评“优秀”的完整工程代码、高质量果蔬数据集、多版本模型权重（如cnn_fv.h5、mobilenet_fv.h5等）及配套实现指南，显著降低深度学习项目落地门槛，尤其适合在有限算力环境下开展轻量化模型对比与性能调优实验。 去年我接了一个超市自助结算系统的演示项目，需求一句话就能讲完——用摄像头识别顾客托盘里的蔬菜水果，自动完成计价。干这行的人都懂，听起来越简单的需求，落地时往往越有暗坑。我最初也想直接从网上拉一个预训练模型跑通算了，结果从数据集清洗、标注格式统一到模型反复训练调优，再到最后部署成可用的识别服务，前前后后折腾了将近三周。这篇就把这套基于YOLOv5的果蔬识别系统从数据准备、训练调优到部署集成的完整链路整理出来，包括我踩过的各种坑和最终的取舍方案。

如果你是正在做目标检测相关项目、想拿YOLOv5训练自己的数据集、或者单纯对果蔬识别这个小方向感兴趣的开发者，这篇文章应该能帮你省下不少弯路。我会把数据怎么处理、超参数怎么调、训练完怎么部署这些环节全部展开讲清楚。

1. 果蔬识别为什么不能当成一个普通分类任务做

1.1 果蔬数据集的天然难点

先说结论：果蔬识别不是简单的图像分类，它本质上是一个细粒度目标检测问题，而且难度比很多人想象中大得多。

拿我这次做的项目来说，识别对象包括常见的苹果、香蕉、橙子、土豆、番茄、黄瓜等二十多类果蔬。表面上看，这些类别差异很大，但实际拍摄场景中根本不是这么回事。首先是类间相似性极高，红苹果和红番茄在特定光照下几乎难以区分，青苹果和青梨轮廓、颜色都很接近，黄洋葱和土豆在视觉特征上也非常容易混淆。其次是类内差异极大，同样是苹果，有红富士的深红、有黄元帅的明黄、有青苹果的翠绿，同一个类别内部的视觉差异甚至比不同类别之间的差异还大。

更要命的是现实场景里的遮挡和堆叠问题。超市结算时，顾客通常会把多种果蔬混放在一起，果实之间互相遮挡，有的只露出一小块表面。再加上不同成熟度的果蔬颜色饱和度差异、表面反光、拍摄角度倾斜，这些因素叠加在一起，让模型必须学习非常细粒度的纹理和形状特征，而不是简单的颜色特征。

1.2 分类、检测和实例分割的取舍

明确了难点，再看技术选型。

如果只用图像分类模型（比如ResNet、EfficientNet），模型只能告诉你"这张图里有一个苹果"，但给不了位置信息。在结算场景里，你需要知道托盘上有几个苹果、几个番茄、它们分别在哪里，分类模型根本无法满足需求。实例分割（比如Mask R-CNN）能给出像素级的分割掩码，精度高但推理速度太慢，在实时结算场景下很难跑得动。所以中间地带的目标检测是最合适的：既能给出每个目标的类别，又能给出边界框位置，允许一定程度的遮挡，速度也能满足实时需求。

目标检测模型里，我最终选了YOLOv5，原因很实际：它在精度和速度之间平衡得最好，社区生态成熟，部署工具链完善。YOLOv8虽然更新,但在部分设备上的部署兼容性还不如v5方便；YOLOX速度不错但训练资料相对少一些。对一个实际要交付的项目来说，YOLOv5足够的资料量和成熟的排错经验本身就是最大的优势。

1.3 系统整体架构设计

整个系统我分成了三个独立模块，方便分别调试和替换：

1. 数据处理模块：负责原始图片的采集、清洗、标注格式转换、数据集划分。这个模块输出的产物是标准YOLO格式的训练集和验证集。
2. 模型训练模块：基于YOLOv5官方仓库，配置数据和超参数，完成模型训练，输出最佳的权重文件。
3. 推理服务模块：加载训练好的权重，对外提供图片识别和视频流识别能力，通过HTTP接口或本地界面接入实际业务。

这三个模块之间通过文件或接口解耦，任何一个模块出问题都可以单独调试，不用全链路排查。这个设计后面帮了我大忙，尤其是当训练效果不好时，可以很快定位到是数据问题还是模型参数问题。

2. 数据集应用：别让标注细节毁了你的模型

2.1 公共数据集选型：分类和检测数据要分清

做果蔬识别，很多人的第一反应是去网上找现成的数据集。这个思路没错，但这里有一个容易踩的大坑：分类数据集和检测数据集是完全不同的东西，不能混用。

最典型的就是Fruit-360，这是一个非常有名的果蔬分类数据集，包含了上百类果蔬的清晰单果照片，图片干净、背景统一。但它是用来做图像分类的，每张图片只有类别标签，没有边界框标注信息。如果你拿这种数据去训练YOLOv5，根本没法直接使用——YOLOv5需要的标签格式是"类别ID + 归一化的中心点x、y坐标 + 归一化的宽高"这种格式，必须自己标注边界框。而且分类数据集的图片大多是单一物体、背景干净，和真实场景差距很大，模型即使训练出来了，遇到真实结算场景的复杂背景和遮挡也会效果崩盘。

真正合适的选择是检测格式的果蔬数据集。AI Challenger 2018比赛中有一个果蔬检测数据集，包含104个类别、超过12万张图片，标注格式是JSON的检测框格式，这个数据集的类别覆盖了大多数常见果蔬，图片也从真实场景中拍摄，非常适合做预训练或者微调。另外，Roboflow平台上也有不少用户共享的果蔬检测数据集，可以直接导出YOLO格式，省去格式转换的麻烦。

这里顺带说一句，COCO数据集的fruit类别虽然也能用，但COCO本身是大规模通用检测数据集，果蔬类别划分比较粗糙，只有apple、orange、banana、broccoli、carrot等少数几个大类，没有细分品种，直接用它训练果蔬识别系统会导致类别粒度不够。我自己实际采用的是"AI Challenger预训练 + 自采数据微调"的方案，这比完全从零标注数据或者完全依赖公共数据靠谱得多。

2.2 自制数据集的拍摄策略和标注规范

公共数据集即使再接近真实场景，也替代不了你自己业务场景里的数据。原因很简单：你部署的环境、摄像头位置、光照条件、果蔬摆放方式都是独特的，这些环境差异只能靠自有数据来弥补。

我这次自己拍了大概3000张图片，涵盖20个类别。拍摄策略上总结了三个要点：

• 多角度多距离：同一个果蔬，分别从俯视、平视、将近距离、远距离拍摄，模拟顾客放上托盘后摄像头可能捕捉到的各种角度。
• 还原真实遮挡场景：把多种果蔬叠放在一起拍，刻意制造遮挡、堆叠、边缘出框的情况。模型见过这些情况，推理时才不会漏检。
• 变换光照条件：在自然光、白炽灯、荧光灯、背光等不同条件下分别拍一组，提高模型对不同光照的鲁棒性。

标注工具我用的是LabelImg，老牌工具，操作简单，标注完直接保存成Pascal VOC格式或YOLO格式。虽然CVAT功能更强、支持多人协作，但个人项目不必上那么重的工具。用LabelImg标注时有一个经验：边界框尽量贴合目标边缘，不要留太多白边，也不要把目标切掉一部分。留白边会让模型学到多余的背景信息，切掉目标会让模型学到不完整的特征，这两种情况都会直接影响检测精度。

还有一个容易被忽略的细节：类别标签的ID要统一。YOLO格式的标签文件里，类别是用整数ID表示的，ID对应的类别名在data/*.yaml文件里定义。如果标注时class ID和yaml里的顺序不对应，模型训练就全乱了，而且这种错误还特别难察觉。

2.3 数据清洗与增强：过滤坏数据比增加数据更重要

数据量不是越多越好，这一点我这次深有体会。最初我从网上爬了一批图片加进训练集，结果mAP刚开始很高，但模型一到真实场景就各种漏检误检。排查发现，网上爬来的图片里混入了大量绘画作品、表情包、带水印的商品图，这些图片模型是学会了，但学到的特征和真实果蔬完全对不上。

所以数据清洗这一步千万不能偷懒。我当时的清洗规则是这样的：

清洗完数据，就到了数据增强环节。YOLOv5内置了非常强大的数据增强机制，包括Mosaic增强、随机HSV色域变换、水平翻转、随机平移和缩放等。这些增强默认开启，能有效提升模型的泛化能力。特别是Mosaic增强，把四张训练图片随机缩放拼接成一张，相当于变相增大了batch size，还能让模型学到小目标、部分遮挡目标的特征，对果蔬堆叠场景特别有用。

如果自己的数据集类别不平衡（比如苹果样本特别多、蓝莓样本特别少），可以在训练时设置每个类别的采样权重，让模型在样本少的类别上多学习几轮。不过这个参数不要一开始就调，先让模型跑一版看结果再说。

3. 环境准备、YOLOv5安装与训练前配置

3.1 训练环境搭建

YOLOv5官方仓库对环境的依赖不算苛刻，但有一些细节值得注意。我当时的训练环境是一张RTX 3060 12G显卡，配了CUDA 11.8和PyTorch 2.0.1，这个组合很稳定。

安装步骤很简单，两条命令就能搞定：

git clone https://github.com/ultralytics/yolov5 cd yolov5 pip install -r requirements.txt

这里不需要刻意追求最新版本，官方仓库的v6.0、v7.0版本都很稳定，经过大量用户验证。如果你用PyTorch 2.0以上的版本，记得在安装完requirements.txt后用pip list检查一下torch、torchvision版本是否匹配，版本不匹配会在训练时报奇怪的CUDA错误。遇到这类问题直接重装对应版本的torch即可，不用纠结。

训练之前还有一个关键步骤：下载预训练权重。YOLOv5提供了在COCO上预训练好的权重文件，用这些权重做迁移学习初始化，比从零训练收敛快得多、精度也更高。下载方式是在yolov5目录下执行：

python -c "from utils.downloads import attempt_download; attempt_download('yolov5s.pt')"

注意：预训练权重对应的类别数是COCO的80类，和你的果蔬类别数不一致。不过这没关系，YOLOv5在加载预训练权重时会自动处理输出层的权重，只加载能匹配的层，最后一层检测头会重新初始化。这也是它能做迁移学习的原因。

3.2 数据集结构改写成YOLO格式

YOLOv5要求的数据集目录结构非常固定，目录名和存放路径都不能搞错。我的目录结构如下：

datasets/ ├── fruits/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/

训练集和验证集的图片分别放在images/train和images/val下，对应的标签文件（同名.txt文件）放在labels/train和labels/val下。每张图片对应一个txt标签文件，文件名和图片名完全一致，后缀名为.txt。标签文件的每一行代表一个标注对象，格式是：

class_id x_center y_center width height

其中x_center、y_center、width、height都是归一化到0-1之间的数值。以一张640x480的图片为例，如果一个苹果的包围框左上角坐标是(160, 120)，右下角坐标是(400, 360)，那么归一化后的中心坐标就是((160+400)/2/640, (120+360)/2/480) = (0.4375, 0.5)，宽度是(400-160)/640 = 0.375，高度是(360-120)/480 = 0.5。这一条标注文本就是0 0.4375 0.5 0.375 0.5。

如果你从LabelImg导出的是Pascal VOC格式（XML文件），需要写一个脚本把XML转成txt；如果用的是AI Challenger数据集的JSON标注，也需要写脚本提取检测框信息并做归一化。这个转换过程虽然麻烦，但逻辑并不复杂，基本上就是读取XML或JSON里的坐标信息，做一遍归一化，再按类别映射成ID写入txt。

3.3 超参数设置：先把跑通，再谈调优

YOLOv5的超参数配置主要有三个地方：模型结构文件（yolov5s.yaml）、数据集配置文件（fruits.yaml）、训练参数（命令行传入）。

模型结构文件里最重要的是nc参数，表示类别数，需要改成你自己的类别数量。数据集配置文件里要写清楚训练集和验证集的路径、类别名列表。训练命令行是核心：

python train.py --data fruits.yaml --weights yolov5s.pt --img 640 --batch 16 --epochs 100 --device 0

这里几个关键参数的作用和取舍，我给你说明一下：

• img 640：输入图片尺寸。YOLOv5官方在COCO上默认用640作为训练尺寸，这个尺寸在精度和速度之间最平衡。如果你的场景里果蔬特别小（比如车厘子、蓝莓），可以试试896或1024，分辨率更高，小目标更容易被检测到，但显存占用和推理耗时会明显增加。
• batch 16：批大小。12G显存跑yolov5s，batch 16比较稳妥，再往上容易OOM。如果显存不够，可以调到8甚至4，但训练稳定性会差一些，学习率也需要相应调低。
• epochs 100：训练轮数。对于果蔬这种中等难度的任务，100轮通常可以看到不错的收敛效果。如果loss还在下降，可以继续加轮数。

还有个细节是锚框尺寸。YOLO系列算法需要预设一组初始锚框，模型在训练中会基于锚框逐步逼近真实目标框。YOLOv5默认在COCO数据集上统计出来的锚框尺寸，适用的目标大小和果蔬场景不一定匹配。好在YOLOv5有一个自动计算锚框的逻辑：训练开始时，它会用k-means算法在你自己的数据集上重新聚类计算合适的锚框尺寸，所以一般情况下你不用手动干预。只有在训练日志里看到明显的锚框异常提示时，才需要手动调整。

4. 训练过程观察：损失曲线、失败案例与调优方向

4.1 训练日志怎么看

训练过程中，终端会每个epoch打印一次关键指标，包括box_loss（边界框回归损失）、obj_loss（目标置信度损失）、cls_loss（分类损失）、mAP@0.5（IOU阈值0.5时对所有类别的平均精度）等。

一个正常收敛的训练过程，这几个指标应该呈现这样的趋势：loss持续下降然后趋于平缓，mAP持续上升然后趋于平缓。loss下降和mAP上升之间存在一定的滞后关系，所以如果你看到loss在降但mAP还没涨起来，不用着急，多等几个epoch再看。

我训练时习惯盯两个东西：

• mAP@0.5：这是最直观的指标，表示IOU阈值0.5时的平均检测精度。mAP@0.5达到0.9以上，说明检测框和真实框的重合度能满足大多数业务需求。
• mAP@0.5:0.95：这个是更严格的指标，表示在0.5到0.95的不同IOU阈值下平均精度的平均值。这个指标比mAP@0.5更能反映框的定位精度，一般会比mAP@0.5低很多，不要看到它低就以为模型不行。

另外，YOLOv5训练结束会生成混淆矩阵图（confusion_matrix.png），这个图非常有用。它能直接告诉你哪些类别之间容易互相误判。我看到自己训练的混淆矩阵后，发现"苹果"和"番茄"两个类别之间存在明显的误判，这才有了后面针对性的数据补充方案。

4.2 两个典型的训练失败案例

案例一：部分类别完全学不到

第一版训练，我的数据集中"柠檬"只有不到50张图片，而"苹果"有400多张。结果训练出来的模型，柠檬的ap（平均精度）只有0.2左右，其他类别都在0.85以上。这就是典型的样本不平衡问题。

解决办法有两个方向。一是收集更多柠檬图片，把样本数补到和苹果差不多的量级。这个最直接有效。二是降低模型对这个类别的学习难度，比如对柠檬图片做更强的数据增强（加倍增强概率），或者按类别数量调整loss权重，让样本少的类别对loss的贡献更大。在YOLOv5里，你可以修改utils/loss.py中的类别损失权重来手动调整。不过我的建议是优先补数据，调整loss权重是补救措施，数据始终是第一位的。

案例二：模型过拟合，验证集mAP虚高但真实场景崩了

有一版训练，验证集mAP@0.5达到了0.95，我当时以为模型已经接近完美了，结果拿到摄像头下实测，发现漏检、误检严重到无法使用。后来分析原因是：我的训练集和验证集来自同一批拍摄的图片，场景背景、光照条件太相似，模型实际上学到了大量背景特征，而不是果蔬本身的特征。

这个问题在学术界叫数据集偏差，在行业里我们通常就叫"数据太干净了"。解决办法是要保证训练集和验证集的数据分布有差异，比如在不同时间、不同光照、不同背景下分别采集数据。我在后续版本中专门分出了两天拍摄的数据作为验证集，确保验证集和训练集不来自同一场景。这个改动之后，验证集mAP虽然降到了0.89左右，但真实场景的表现反而大幅提升，这才是真实模型能力的反映。

4.3 调优方向和实际操作

基于上面两个失败案例和之前的多次迭代，我整理了一张调优行动表，当你自己训练果蔬模型时遇到问题，可以对照查阅：

还有一点是关于训练轮数的经验。YOLOv5默认的100轮，对果蔬识别来说通常不够让模型完全收敛。我最终训练了200轮，在150轮左右看到mAP趋于稳定，后续50轮提升不大。如果你的GPU算力比较紧张，可以训练到验证集mAP不再明显上升时就提前停止，这个机制YOLOv5默认是开启的（patience=100）。

5. 从训练模型到可用服务：推理部署与系统集成

5.1 自定义推理脚本，别直接用detect.py

模型训练完，你得到的是runs/train/exp/weights/best.pt这个权重文件。这时候你可能想先用YOLOv5自带的detect.py快速验证一下效果：

python detect.py --weights runs/train/exp/weights/best.pt --source test.jpg --conf 0.4

这个命令能用，但它是为演示设计的，不管做服务还是集成到业务系统都不合适。detect.py每次运行都要重新加载模型，内部还做了很多非必要的图像保存操作，延迟和资源消耗都偏高。实际开发时建议自己写一个推理脚本，核心逻辑非常简单：

import cv2 import torch model = torch.hub.load('ultralytics/yolov5', 'custom', path='best.pt', force_reload=True) model.conf = 0.4 # 置信度阈值 model.iou = 0.5 # NMS的IOU阈值 img = cv2.imread('test.jpg') results = model(img) # 结果解析 for det in results.xyxy[0]: x1, y1, x2, y2, conf, cls = det.tolist() name = model.names[int(cls)] print(f'{name}: conf={conf:.2f}, bbox=({x1:.0f},{y1:.0f},{x2:.0f},{y2:.0f})')

这里有两个阈值参数需要注意。conf是置信度阈值，低于这个值的检测框会被过滤掉。实际业务中，太低容易误检（背景里的图案被当成果蔬），太高容易漏检。我推荐设0.4到0.5之间，然后根据实际场景微调。iou是NMS的IOU阈值，用于去除重叠的检测框，一般0.45到0.5是安全区间，不用调。

5.2 用FastAPI把识别封装成服务

如果要把识别能力接入实际的结算系统，最直接的方式是提供一个HTTP接口。我用FastAPI封装了一下，代码量很少：

from fastapi import FastAPI, UploadFile from PIL import Image import io app = FastAPI() @app.post("/detect") async def detect(file: UploadFile): img = Image.open(io.BytesIO(await file.read())) results = model(img) detections = [] for det in results.xyxy[0]: x1, y1, x2, y2, conf, cls = det.tolist() detections.append({ "class": model.names[int(cls)], "confidence": round(conf, 4), "bbox": [round(x1), round(y1), round(x2), round(y2)] }) return {"detections": detections}

前端调用这个接口，传一张图片过去，就能拿到识别结果列表。部署时用uvicorn app:app --host 0.0.0.0 --port 8000启动服务，局域网内的设备就可以访问了。

这里有个性能上的坑：FastAPI默认是单worker运行，如果同时有多个请求进来，后面的请求需要排队。对超市结算这种并发量很低的场景，单worker完全够用。如果并发压力大，可以用gunicorn多worker部署，但要处理好模型在每个worker中的加载问题，避免重复加载浪费内存。

5.3 视频流识别和轻量化部署

静态图片接口能搞定一部分业务，但如果需要实时视频流的识别（比如摄像头连续扫描），就需要用OpenCV读取视频帧，逐帧调用模型推理。一个简单的循环框架如下：

cap = cv2.VideoCapture(0) while True: ret, frame = cap.read() results = model(frame) rendered = results.render()[0] cv2.imshow('YOLOv5 Detection', rendered) if cv2.waitKey(1) & 0xFF == ord('q'): break

逐帧推理在GPU上耗时大约30毫秒（yolov5s模型），能够达到30FPS左右的实时帧率。但如果你的部署环境没有GPU，纯CPU推理的速度会慢不少，一帧可能要一两百毫秒，看起来会有明显卡顿。这种情况下有两个优化方向：

• 导出ONNX格式，用ONNX Runtime加速推理。YOLOv5提供了现成的导出脚本：python export.py --weights best.pt --include onnx。ONNX格式在CPU上的推理速度通常比PyTorch原生快不少。
• 如果是嵌入式设备（比如RK3568、树莓派），可以进一步导出TensorRT或NCNN格式。不过这里水比较深，不同硬件平台的算子支持和优化效果差异很大，建议先在目标设备上做一下推理速度的基准测试再做决定。

6. 部署现场的坑和工程化心得

6.1 摄像头角度与识别距离要提前固定

模型是在一定拍摄距离和角度下训练的，如果你部署的时候摄像头位置变了，识别效果会大打折扣。我在项目现场就遇到过这个问题：训练时模拟的是俯视45度、距离大约50厘米，但现场安装的摄像头是正上方垂直角度，距离80厘米。结果模型漏检率飙升，最后不得不重新补拍了一组正上方视角的数据集进行微调，才把效果拉回来。

所以经验是：在项目早期就确定摄像头安装位置和角度，让训练数据尽量贴合部署环境。如果部署环境没法提前确定，就在数据集中尽量多样化，让模型见过各种角度和距离。

6.2 置信度阈值不是固定的

很多人在模型部署后就懒得调阈值了，但实际上置信度阈值应该根据实际场景动态调整。在你的系统里加上一个配置项，让阈值可调。如果业务中更看重不漏检（比如结算漏了会少收钱），就把阈值调低到0.3左右；如果更看重准确率（比如不想把背景误判成果蔬给顾客多算钱），就调高到0.5以上。

另外，YOLOv5的NMS阈值也可以微调。如果场景中果蔬堆叠严重，NMS阈值稍微调低一点（比如0.4），可以减少重叠框的保留数量，避免同一个果蔬被识别成多个。

6.3 易混淆类别要尽快做针对性优化

我最终版本里表现最差的两个类别是"苹果"和"番茄"。为了彻底解决它们之间的误检问题，我做了三件事：

1. 增加两种果蔬并排摆放、近距离接触的样本图片，让模型学习二者的边界特征。
2. 检查历史标注数据，发现有几张苹果图片误标成了番茄，逐一修正。
3. 在数据增强中，对这两种类别额外生成一些裁剪、旋转、亮度变化的样本。

这三步做完之后，混淆矩阵里"苹果→番茄"的误判率从12%降到了3%以内，效果非常明显。

6.4 关于部署硬件的建议

如果你做的是类似的商用项目，建议训练阶段用NVIDIA显卡（RTX 3060以上即可），推断阶段如果追求性价比和低功耗，可以放到边缘设备上跑TensorRT加速。但说实话，如果你是个人开发、Demo演示或者小规模门店使用，直接用一台带GPU的PC做推理服务是最省心的，没有必要一上来就上嵌入式设备。先把业务逻辑跑通，再考虑硬件优化，这个顺序不能反。

7. 整个项目过程中我最想强调的经验

数据永远是第一位的。模型架构、超参数这些当然重要，但决定果蔬识别系统最终效果的往往是数据本身。你愿意花多少时间在数据采集、清洗、标注、验证集划分上，模型就会回报给你多少精度。我在这个项目上反复体会到，同一个YOLOv5模型，用干净的数据和脏数据训练出来的效果可以说是天壤之别。

最后再分享一个工具上的小技巧：训练过程中YOLOv5会在runs/train/下保存每次训练的日志和图表。训练结束之后，我会把最终一轮的混淆矩阵、F1曲线、PR曲线这几张图单独复制出来留档，后面写项目文档或者向别人解释模型效果时，这些图就是最直接的说明材料。这套流程跑熟了以后，再做新的目标检测项目，从数据处理到模型部署基本上就是一条流水线，省下的时间相当可观。

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