★ FEATURED ARTICLE 1. 项目核心思路为什么做茶叶病害检测系统做了几年计算机视觉项目接到过不少农业相关的需求但茶叶病害检测这个方向算是最有意思的一个。为什么因为它同时踩中了两个点一是茶叶产业本身的智能化升级需求二是CV领域从“只做检测”向“检测决策”转型的大趋势。传统茶农鉴别病害基本靠肉眼和经验效率低不说很多早期病害的辨识难度很高。我做过调研茶树常见的病害如茶饼病、茶白星病、茶炭疽病、茶云纹叶枯病早期症状非常相似非专业人士根本分不清。而市面上已有的检测方案大多是单纯的“识别告警”给出“这是什么病”就结束了。但这个项目的核心思路不一样不仅要识别出病害类型还要通过大模型做进一步的农业知识分析告诉用户这个病的成因、防治建议、用药参考。也就是把 CV 算法和 LLM大语言模型结合起来做成一套完整的“检测诊断建议”闭环。另外一个设计考量是前后端架构。检测系统如果只做成本地 Python 脚本或者 Jupyter Notebook 演示落地价值非常有限。茶叶种植户、农技站工作人员、茶企品控部门他们不会去敲命令行他们需要的是一个网页打开就能上传图片、看到结果、操作直观。所以这套系统采用了 SpringBoot Vue 的前后端分离方案Python 的 YOLO 模型通过接口服务的形式接入整个链路无论在功能上还是工程化程度上都更接近一个可交付的产品而不是一个实验室 Demo。从技术栈角度看核心关键词就是YOLO系列目标检测模型这是识别引擎、SpringBoot这是后端服务骨架、DeepSeek这是智能分析大脑、web交互界面这是使用者接触的前端。四者各司其职整个项目才能跑起来。这个项目适合谁来参考我觉得有三类人做 CV 落地项目的研究生或工程师可以参考怎么把训练好的 YOLO 模型包装成可用的 Web 服务。做农业信息化系统开发的团队可以参考前后端分离架构下的整体设计。学习 SpringBoot 或 Vue 的开发者可以通过一个真实场景业务理解目标检测模型如何与 Java 后端集成。我先把整个系统的逻辑框架画清楚再逐个环节拆解实现细节和踩坑记录。这不光是讲代码还会把我在实际开发中遇到的各种“绊脚石”一并拿出来说希望帮你少走一些弯路。2. 模型选型YOLOv8/10/11/12 到底选哪个2.1 YOLO 各版本的核心差异与适用场景先聊模型选型。标题里写了 YOLOv8、YOLOv10、YOLOv11、YOLOv12这不是罗列关键词而是实际开发中需要做横向对比和选型取舍。我接触过不少做检测的朋友最常见的困惑是“版本这么多到底用哪个”。我的回答通常是先把各版本的本质差异理清楚再看自己的数据集和部署环境。YOLOv8Ultralytics 团队推出的版本生态最成熟文档最全社区资料最多。对于农业场景YOLOv8 是默认主力因为它训练稳定、部署资料齐全、导出 ONNX/TensorRT 的教程遍地都是。如果你的需求是快速出一个可用版本YOLOv8n 或 YOLOv8s 是最稳的选择。YOLOv10主打“无 NMS 推理”去掉了传统的非极大值抑制步骤从结构上优化了端到端延迟。它的优势是推理速度更快模型结构更简洁但训练细节上有些参数配置和 v8 不太一样。对茶叶病害这种实时性要求中等、精度要求偏高的场景v10 的优势有限因为 NMS 的延迟在我们的实际场景里并不是瓶颈。YOLOv11在特征提取网络上做了升级部分任务上有更好的 mAP 表现。但 v11 发布后 Onnx 导出和量化工具链的成熟度不如 v8尤其后端集成时容易遇到小坑。YOLOv12最新的版本引入了 Attention 机制相关的改进理论上在复杂背景下的特征提取能力更强。茶叶病害的一大痛点是叶片纹理复杂、病斑边界模糊v12 的注意力机制理论上对这个场景有正向意义。这是我在做模型选型时的核心判断逻辑不要盲目追求最新版本先把数据集质量做好再根据场景需求选模型。茶叶病害检测本质上是一个小目标、细粒度分类问题对精度要求高于对速度的要求。茶饼病的病斑可能只有几个像素大小模型的特征提取能力比推理速度更重要。所以我一共训练了四个版本的模型做对比最终在精度和部署成本之间取平衡。2.2 实际测试四版模型在茶叶病害数据上的表现测试数据集我用的是自己标注的茶叶病斑数据集按 8:1:1 划分训练集、验证集和测试集。标注类别包含类别中文名称样本数量tea_brown_blight茶云纹叶枯病2100tea_white_scab茶白星病1800tea_blister_blight茶饼病1500tea_anthracnose茶炭疽病1600healthy健康叶片2200训练统一使用 640×640 输入尺寸初始学习率 0.01batch size 16训练轮次 150 轮使用 SGD 优化器配合余弦退火策略。以下是我在测试集上统计的 mAP0.5 和推理速度对比模型版本mAP0.5推理耗时GPU模型体积YOLOv8s0.8764.2ms22.5MBYOLOv10s0.8583.1ms21.2MBYOLOv11s0.8894.5ms24.8MBYOLOv12s0.9016.8ms28.1MB结论非常直观YOLOv12 的 mAP 确实最高比 v8 高了 2.5 个百分点这个提升在真实场景里是能感受到的尤其是茶饼病这类早期小病斑的召回率提升明显。但它的推理耗时也增加了将近 60%GPU 部署问题不大如果要落到 CPU 端或者边缘设备就得认真掂量一下。项目最终选了 YOLOv11s 作为线上正式模型YOLOv12s 作为备用升级方案。原因有三一是 v11 的精度足够满足业务需求二是推理速度相对友好三是 Ultralytics 对 v11 的模型导出、C 部署、SpringBoot 集成的案例已经相对丰富了。团队内部约定后续如果茶饼病的召回率持续不达标再切换到 v12 并对推理瓶颈做针对性优化。2.3 训练时的关键配置细节数据标注方面有一个很容易忽略的点茶叶病害的病斑往往被叶片阴影遮挡是否要把遮挡部分标进去直接影响到模型的召回率。我自己的做法是凡是能看出病斑轮廓的遮挡区域标注框拉大一些把周围健康叶片纹理也纳入让模型去学习“病灶周边纹理”的联合特征如果遮挡面积超过一半就放弃标注。实际跑下来这种方式比强行全标的效果好很多。超参数配置上我用的是 Ultralytics 默认配置微调后的版本关键参数改动如下# train_config.yaml task: detect mode: train model: yolov11s.pt data: tea_disease.yaml epochs: 150 patience: 30 batch: 16 imgsz: 640 optimizer: SGD lr0: 0.01 lrf: 0.01 momentum: 0.937 weight_decay: 0.0005 warmup_epochs: 3.0 warmup_momentum: 0.8 cos_lr: True close_mosaic: 10 augment: True关键点是close_mosaic: 10最后 10 轮关闭马赛克增强。因为 Mosaic 增强会引入大量拼接痕迹导致模型对真实叶片边缘的感知能力下降。训练到接近收敛时关闭它能让模型在真实分布上做最后调整。这个细节是我对比实验出来的关闭后 mAP 大概能涨 0.8~1.2 个点。还有一个每次必强调的类别不均衡问题。茶叶白星病和健康叶片的样本量明显多于茶饼病如果不做处理模型会偏向多数类。我用class weights和简单过采样两种手段同时处理最终茶饼病这个最难类的 F1-score 从 0.62 提高到了 0.74效果还是很明显的。3. 系统架构与前后端分离设计3.1 SpringBoot Python 模型服务的数据通路这是整个项目工程化的核心部分。很多做算法的人对部署感到头疼本质原因是没理清 PyTorch 模型和业务系统之间的数据流。这套项目的架构是标准的“前后端分离 算法服务独立部署”模式。架构分层大致是这样前端Vue 3 Element Plus负责图片上传、结果展示、病害信息渲染、历史检测记录管理。后端SpringBoot 2.7负责用户认证、图片存储、检测任务调度、业务数据持久化。算法服务Python FastAPI 独立部署负责接收图片、运行 YOLO 推理、返回检测框和类别信息。分析服务DeepSeek API 接口集成接收检测结果和图片信息生成病害诊断报告。为什么不让 SpringBoot 直接加载 PyTorch 模型理论上可以通过 DJL 或者 ONNX Runtime 在 Java 进程内跑推理但实操下来复杂度过高尤其是预处理逻辑、动态形状处理、多模型切换这些场景Java 端的坑远多于 Python。而把检测模型独立成 FastAPI 服务SpringBoot 通过 HTTP 调用虽然多了一层网络开销但换来的是算法迭代和业务开发完全解耦模型更新不需要重新构建 Java 工程。Python 生态里现成的预处理、可视化、评估工具直接用。可以按需水平扩展算法服务遇到并发高峰单独加机器。这个设计可以用一个生活化类比理解SpringBoot 像餐厅前台顾客点餐、结账、记录都归它管算法服务像后厨前台把菜品需求传给后厨后厨做好菜再端出来。前台不需要知道菜是怎么炒的后厨也不需要关心顾客怎么付款。3.2 接口设计与数据传输格式前后端的接口格式约定是 RESTful JSON所有模型推理结果统一走算法服务的/detect接口。这里放一个核心的接口示例# algorithm_service.py from fastapi import FastAPI, UploadFile, File from pydantic import BaseModel import cv2 import numpy as np app FastAPI() class DetectResult(BaseModel): image_id: str detections: list cost_time: float app.post(/detect, response_modelDetectResult) async def detect(file: UploadFile File(...)): contents await file.read() img cv2.imdecode(np.frombuffer(contents, np.uint8), cv2.IMREAD_COLOR) results model(img) # YOLO detection detections [] for r in results[0].boxes.data.tolist(): x1, y1, x2, y2, score, cls r detections.append({ bbox: [x1, y1, x2, y2], score: round(score, 4), class_id: int(cls), class_name: model.names[int(cls)] }) return {image_id: file.filename, detections: detections, cost_time: elapsed}SpringBoot 端用 RestTemplate 调用算法服务的接口接收到 JSON 后解析检测框信息把结果存入数据库并同步返回给前端。数据表设计上用了比较简单的三张表tea_image存储原始图片路径、上传时间、用户ID。detect_result存储检测结果包括类别、置信度、坐标。analysis_report存储 DeepSeek 生成的诊断报告内容。这里有个容易被忽略的性能问题图片传输。前端上传的原图往往 3~5MB如果每次检测都传原图算法服务和后端都会产生压力。我在前端先做了图片压缩把长边压到 1280px 再上传检测精度几乎不受影响但传输体量下降了 70% 以上。这个优化极其划算。3.3 DeepSeek 智能分析如何接进来DeepSeek 在这个项目里的定位不是替代 YOLO 去做视觉识别而是在视觉模型输出的结构结果之上生成可读的农业指导建议。换句话说YOLO 告诉系统“这是茶饼病置信度 92.3%框在哪个位置”DeepSeek 基于这个信息结合预设的农业知识库生成“该病害的成因分析、传播条件、防治窗口期、推荐用药方案”。集成方式用的是 HTTP API 调用封装在 SpringBoot 的 Service 层里。核心逻辑如下视觉检测完成拿到类别ID和置信度。后端判断置信度是否大于阈值默认0.65如果低于阈值会提示“检测结果不确定建议人工复核”。通过提示词模板构造请求把病害类型、置信度、叶片部位、季节参数传给 DeepSeek API。返回的报告解析后结构化存储前端渲染时按段落展示。提示词模板是我反复调了多轮才稳定下来的核心结构是这样的你是一个茶叶植保专家。用户上传的茶叶叶片经YOLO视觉模型检测结果为【茶饼病】置信度【0.92】。 请基于以下信息生成诊断报告 1. 病害成因与环境条件 2. 典型症状描述 3. 防治建议农业防治、生物防治、化学防治 4. 推荐用药及使用注意 5. 未来7天管理建议 要求语言通俗易懂适用于茶农阅读不用过于专业的术语堆砌。这里要特别说明一个我踩过的坑不要把大模型的回复直接当“权威结论”展示给用户。我封装了一层“分析报告后处理”逻辑把 DeepSeek 返回内容做了敏感词过滤、长度截断、格式清洗并且在页面底部固定展示免责声明——“AI 分析仅供参考最终防治方案建议咨询当地植保站”。这个设计不是为了推卸责任而是农业场景的回复直接影响农户的用药决策必须严谨。4. 前端交互界面与完整检测流程体验4.1 Web 界面的核心页面拆解前端这部分我不想讲太多组件层面的琐碎细节而是说说整体交互设计思路。用户打开系统需要完成的核心路径只有三条上传叶片照片进行检测。查看检测结果和 AI 诊断报告。浏览历史检测记录进行对比分析。首页设计成一个大卡片区域上面是拖拽上传区域下面是一键检测按钮。技术上用了 Element Plus 的 Upload 组件配置了图片压缩、格式校验只允许 jpg/png/webp、大小限制。结果页面用了左右分栏布局左侧是原图 检测框叠加渲染右侧是病害信息面板。“检测框叠加”这里有一个技术细节值得说YOLO 返回的是归一化坐标前端拿到后需要乘以图片实际宽高才能准确定位。我遇到的第一个 Bug 就是坐标系不一致——SpringBoot 里存的是归一化值前端却按像素值渲染结果所有框都画偏了。统一约定为归一化坐标、前端渲染时再做换算问题就解决了。检测框颜色也有讲究不同类别用不同颜色色块标注——茶饼病用橙色茶白星病用紫色茶炭疽病用绿色健康叶片用灰色。颜色区分的好处是农民用户看多了之后能形成条件反射不需要读文字就能快速识别病害分布。4.2 功能模块检测历史、报告导出与多模型切换除了基础检测这个系统还做了几个很重要的辅助功能模块实际使用中反馈很好。检测历史模块每次检测的图片、结果、分析报告都会持久化存储。用户可以在历史列表里按时间筛选、按病害类型筛选。做得最用心的是“同一叶片多次检测对比”功能——茶农经常会对同一棵茶树的叶片隔几天再拍一张连续记录就能看到病害的发展趋势。系统会把这些图片放在同一个时间轴上把置信度变化画成折线图让“病情在好转还是恶化”一目了然。报告导出功能前端点击“导出报告”后端会把检测结果 AI 诊断报告 叶片图片打包生成 PDF。技术实现上用了开源组件生成 PDF我对导出文档做了 A4 排版美化加了系统 logo 和页脚联系方式。这个功能的最大价值在于农技站的工作人员可以把系统生成的报告直接打印出来作为下乡指导的附件材料这就让系统真正“进入了工作流”而不只是一个演示工具。多模型切换因为这个项目训练了多个 YOLO 版本我特意做了一个模型版本选择功能。前端管理界面可以选择使用 YOLOv8s、YOLOv11s 还是 YOLOv12s 跑推理后端根据选择动态调用不同的算法服务实例。这个设计最初是为了做对比测试后来发现它其实还挺实用的——如果生产环境只有 CPU 资源就切到 v8 来跑速度快如果对精度要求高的场景再切换成 v12灵活多了。4.3 完整检测流程走查从上传到报告只花了不到3秒写代码的时候总觉得流程很简单但真正走查完整个链路才发现这里面每一步都有需要优化的地方。我在这里把完整流程按时间顺序梳理一遍帮你建立一个整体认知用户打开首页拖入一张茶树叶片的图片。前端先把图片压缩并生成预览缩略图同时显示“图片已就绪等待检测”的状态。点击“开始检测”前端通过 POST 请求把图片发送给 SpringBoot 后端的/api/detect接口。后端先保存原图到本地存储目录生成一个唯一的 image_id再把图片转发给 Python 算法服务的/detect接口。算法服务收到图片后读取像素数据、缩放到 640×640 输入尺寸执行 YOLO 推理。GPU 上推理耗时约 4~5 毫秒加上图像预处理和网络传输整个检测过程耗时约 120 毫秒。算法服务返回检测 JSONSpringBoot 再把这些数据存储到数据库提取病害类别后调用 DeepSeek API 生成分析报告。大模型生成需要的时间比较长通常在 2~5 秒所以我对这个部分做了异步优化——先把检测结果返回给前端展示报告生成后通过 WebSocket 或前端轮询补上。实测下来用户从上传图片到看到检测框和类别信息大约在 1 秒内。完整的分析报告在 2~4 秒后加载出来。体验上非常流畅基本达到了可用产品的标准。整个走查过程还帮我发现了一个问题并发场景下同时多个用户上传图片SpringBoot 在存储图片时用的是简单的 UUID 文件名数据库里记录的关联字段如果稍有疏忽图片和检测结果就对应不上。后来我统一了 ID 生成规范用“时间戳随机数”的分布式 ID 作为 image_id彻底解决了并发错乱。5. 开发实践中遇到的坑与排查实录5.1 环境依赖冲突Python 版本和 PyTorch 版本兼容问题这个项目踩到的第一个大坑就是环境冲突。算法服务这边需要 Python 3.9、PyTorch 2.1、Ultralytics 最新版。但我本机之前装了老版本的 PyTorch 1.12直接导致 YOLOv8 的推理报错提示缺少某些算子。原因很简单新版本 YOLO 用到了部分新算子如 Focus 结构相关的优化老版本环境跑不了。解决办法是直接用虚拟环境隔离用 conda 创建了一个全新的tea_yolo环境指定 Python 3.10然后安装指定版本的 PyTorch 和 Ultralytics。这里有一个很多人容易忽略的点Ultralytics 的版本更新频率非常高小版本之间也会偶发不兼容。我最终把 ultralytics 的版本锁定在了 8.2.0后续不再随意升级避免“昨天还能跑今天突然报错”的情况。5.2 模型在外网服务器上频繁超时项目部署到服务器后一个高频问题是用 FastAPI 跑 YOLO 推理时出现了超时。排查后发现不是模型慢而是 FastAPI 的默认同步方式有问题。YOLO 推理是 CPU/GPU 密集型的同步任务如果部署在单 worker 的 uvicorn 上第一个请求还没有完成第二个请求就会被阻塞表现为及时处理时间很长甚至超时。修法很简单两个层面把 FastAPI 的接口用async def改成异步推理部分用线程池处理。部署时用uvicorn的多个 worker 或加一层 Gunicorn 管理进程。这里需要特别提醒GPU 推理在多进程模式下会有显存重复加载的问题每个 worker 都要加载一次模型显存不够的话容易 OOM。我的做法是模型通过lru_cache实现全局单例每个进程只加载一次同时在代码里做进程内并发控制保证同一时刻只有一个推理任务在占用 GPU 资源。5.3 前端渲染检测框偏移的坐标问题前面提到过一次坐标系的 Bug这里把详细排查过程讲一下。症状是这样的检测框画出来位置是对的但大小不对总比实际病斑区域大一倍左右。排查后定位到原因是 YOLO 返回的框坐标已经基于 640×640 的缩放图了而前端渲染时用的是原始 1280px 图片的坐标没有做等比例还原。修改方案是在算法服务返回结果时把每个 bbox 坐标除以图片缩放比例转换回原图坐标系并且增加一个image_width和image_height字段让前端可以复核。这样前端拿到任何模型版本的结果都能正确渲染不存在 backend 和前端各自猜测的问题。这类坐标转换问题在 CV 工程里几乎每次都会遇到我的建议是把坐标系转换明确写在接口文档里并且由后端统一处理前端永远接收“已经还原到原图”的坐标。5.4 DeepSeek 返回内容异常与提示词兜底方案DeepSeek 集成到系统之后遇到的主要问题是返回内容格式不稳定。有时候返回的内容没有按预期分段有时候会在回答末尾加一段与主题无关的内容偶尔还会出现“分析结论为空”的情况。处理方案是在提示词模板里增加了严格的格式约束要求“必须按照五段式结构输出每段不超过 80 字不得输出建议之外的任何内容”。同时在后端增加了解析逻辑按段落标记截取内容如果某一段为空就填充默认文案如果整体为空就直接跳过 AI 分析只显示 YOLO 的视觉检测结果。这样可以保证用户界面永远不出现“内容为空”的尴尬状态。另外我还在 DeepSeek 调用接口加了一层错误重试遇到超时或连接异常自动重试两次。对于网络不稳定的部署环境来说重试机制是性价比极高的防御措施。5.5 打包部署的一些经验补充最后说部署这块。整个系统分三个进程部署前端 Nginx 静态资源服务、SpringBoot 后端Java 8 环境以及 Python 算法服务conda 环境管理。部署到 Linux 服务器的一个典型注意事项是 GPU 驱动和 CUDA 环境的兼容性。我去俗系统地讲一下CUDA 版本需与 PyTorch 版本匹配如果服务器装的是 CUDA 11.8PyTorch 也要选对应编译版本。这个匹配经常搞得人头痛我的技巧是在 conda 环境里直接用pytorch-cuda11.8指定避免装错。另外所有服务都用 systemd 管理设置了开机自启和异常自动重启。Python 算法服务单独部署在一个目录下SpringBoot 的后端打成 jar 包Nginx 配置反向代理到后端的 8080 端口。整个部署文档我整理成了脚本最终发布时别人按照脚本可以 20 分钟部署一套环境这也算是工程化的基本要求了。6. 项目可扩展方向与真实使用感受6.1 可以继续改进的几个方向这个系统做到能跑能用之后还有很多可以继续推进的点。我列几个在自己脑子里预演过的方向供参考移动端适配目前前端界面是 Web 响应式设计在手机上用没问题但体验一般。茶叶种植户户外作业时不会带电脑如果包装成微信小程序或者 H5 应用上传图片、查看报告的便利性会大幅提升。技术上 H5 改动成本最低小程序要额外适配上传和预览组件。边缘计算部署现在的推理跑在服务器 GPU 上对网络要求高。后续可以考虑 Jetson Nano 或者树莓派等边缘设备部署轻量化模型把摄像头直接架在茶园里定时拍照巡检实现“无人值守的病害预警”。这需要模型蒸馏和量化是另一个完整项目了。多模态数据接入目前只用了叶片图片。茶树的生长环境数据——温度、湿度、降雨量——对病害发生有直接影响。如果把环境传感器的数据也接入系统结合检测结果做联合分析预测能力会有质的提升。技术上不复杂主要是数据源打通的问题。知识库持续迭代DeepSeek 的分析报告质量依赖提示词里的知识资料。后续可以根据实际用户的反馈不断补充病害防治案例、地方性用药规范让分析结果更贴合不同地区的实际农情。6.2 从项目里总结的真实体会最后说说我做完这个项目的整体感觉。技术层面YOLO 系列模型在农业图像识别上确实很能打v8 到 v12 的迭代带来的是实打实的精度提升。但模型再强也只是系统里的一个环节。让一套 CV 系统真正发挥价值需要的是工程化能力前后端联调、接口约定、数据存储、部署运维每一样都缺一不可。在场景理解上我最大的收获是做农业信息化项目不能只盯着技术指标。茶农不关心 mAP 是多少只关心“这个系统能不能告诉我用什么药、怎么治”。所以 DeepSeek 智能分析这块虽然实现上只是简单的 API 调用加提示词工程但在整个系统里扮演的角色却非常关键——它把“机器视觉”翻译成了“农业语言”。这套系统后续我在本地又跑了一段时间不断优化检测阈值、调整提示词模板。每次调整后我都会拿真实茶园拍摄的照片做回归测试。这类项目最大的乐趣就在于你看着自己训练出的模型真的能够在田间地头发挥一些作用这种成就感是纯做实验室数据集没法比的。如果看到这里你也正准备做一个类似的检测类系统我给的建议很朴素先把数据集做扎实把单个环节的精度和稳定性跑到满意再考虑工程架构。前面的地基打好了后面盖多高的楼都不会塌。
阅读完成 · 觉得有帮助？
