1. 河道巡检这件事为什么值得用“无人机YOLO大模型”重做一遍我做河道巡检相关的项目断断续续有几年了最早接触的时候人工巡河还是主流两三个人一组沿着堤岸走拿着本子记遇到排污口、漂浮物、岸线违建就拍照存档。这种方式的问题不用我多说一条十几公里的河道走下来大半天人累得够呛漏检率还高尤其是那些藏在芦苇荡后面、桥洞底下的问题肉眼根本够不着。后来陆续上了无人机效率确实上来了但新的麻烦也跟着来了——飞机是飞了可拍回来的视频和照片堆成山靠人一张张翻等于把体力活换成了眼力活本质上没解决“看得快、看得准、看得懂”的问题。这套基于深度学习YOLO算法加Qwen、DeepSeek大模型的无人机河道巡检系统平台就是冲着这个痛点去的。它的核心逻辑其实很清晰无人机负责“看”YOLO负责“找”大模型负责“想”和“写”。无人机按规划航线自动飞把河道影像实时传回来YOLO系列算法在边缘端或者服务端做目标检测把漂浮垃圾、排污口、违规船只、岸线侵占这些目标框出来检测结果再喂给Qwen或者DeepSeek这类大语言模型让它结合上下文做研判、生成巡检报告甚至支持一线人员用自然语言跟系统对话问“今天这段河道有没有异常”“帮我出一份上午的巡检简报”。这套东西适合谁看我觉得有三类人值得花时间读下去。第一类是做智慧水利、环保监测的工程技术人员你们可能正在评估要不要上类似的系统或者已经上了但效果不理想第二类是做计算机视觉落地的算法工程师YOLO你们熟但怎么跟大模型串起来、怎么在无人机这种算力受限的场景下跑通这里面有不少坑第三类是想了解AI工程化全链路的爱好者这套系统从数据采集、模型训练、边缘部署到大模型接入基本把当前主流的AI落地环节都覆盖了一遍。下面我就按实际做项目的思路把整套系统的设计、实现和踩过的坑掰开揉碎讲一遍。2. 系统整体架构与方案选型为什么是YOLO加双大模型2.1 从“飞完再看”到“边飞边判”的架构演进早期做无人机巡检最省事的做法是飞机飞完把SD卡拔下来拷到电脑上慢慢分析。这种离线模式的好处是简单坏处是时效性极差等你分析完污染可能已经扩散了。所以这套系统我一开始就定了调子必须支持实时或准实时回传与推理。整体架构分四层从下往上分别是采集层、传输层、推理层和应用层。采集层就是无人机本体加挂载常见的是可见光云台相机条件好的会加红外或者多光谱。传输层走的是无人机图传链路加地面站转发把视频流推到边缘计算盒子或者云端。推理层是核心YOLO模型在这里做目标检测检测结果结构化之后送进大模型做语义理解和报告生成。应用层就是给用户看的Web端或者移动端支持地图标注、告警推送、AI对话和文档导出。这里有个关键决策点推理放在边缘还是云端。我实测下来如果对实时性要求高比如要边飞边告警那YOLO必须放在无人机机载或者地面站附近的边缘设备上因为图传链路带宽有限把原始4K视频全传回云端再推理延迟和流量都吃不消。但大模型推理又吃算力边缘设备跑不动Qwen或者DeepSeek的完整版本。所以我的方案是边缘做检测、云端做理解边缘端跑YOLOv8n或者YOLOv8s这种轻量模型只把检测框、类别、置信度和对应的小图切片传回云端云端再调用大模型做深度分析。这样带宽占用能降到原来的十分之一以下实测很稳。2.2 YOLO版本选型为什么最终落在YOLOv8YOLO系列迭代很快从v5到v8再到v9、v10每个版本都有拥趸。我选型的时候主要看三个维度精度、速度、部署便利性。YOLOv5社区生态最成熟资料多但架构相对老一些YOLOv8在精度和速度的平衡上做得更好而且Ultralytics官方把训练、验证、导出、部署的链路整合得很顺yolo命令行工具和Python API都很友好YOLOv9、v10虽然论文指标好看但实际部署时算子兼容性和量化工具链还不够稳踩坑成本高。所以最终定的是YOLOv8具体用哪个尺寸看场景。如果边缘设备是Jetson Orin Nano这种跑YOLOv8nnano版能到30帧以上够用如果是地面站有独立显卡可以上YOLOv8m甚至YOLOv8l精度更高。这里给个实测数据参考在自建的河道漂浮物数据集上YOLOv8n的mAP0.5大概在0.82左右YOLOv8s能到0.87YOLOv8m能到0.90。如果只是检测大块漂浮垃圾nano版完全够如果要区分排污口和普通水渍那就得上s或者m。2.3 大模型选型Qwen和DeepSeek怎么分工大模型这块我用了两个Qwen和DeepSeek。不是非要两个都用而是它们各有擅长。Qwen系列在中文理解和多模态方面积累深尤其是Qwen-VL可以直接读图适合做“看图说话”式的巡检描述DeepSeek在推理和代码生成上强适合做结构化报告生成和复杂逻辑研判。实际部署时我一般让Qwen负责对话交互和图像理解DeepSeek负责报告生成和数据分析两者通过API或者本地推理服务串起来。这里要提一下本地部署的考量。河道巡检数据往往涉及地理信息有些项目方要求数据不出内网那就得本地部署。Qwen有多个尺寸7B、14B、72B都有7B在消费级显卡上就能跑量化之后甚至能在Mac上跑DeepSeek也有不同参数版本按需选择。如果算力实在紧张可以用API调用云端服务但要注意数据脱敏。我个人的建议是检测模型必须本地大模型可以灵活因为检测涉及原始影像大模型处理的是结构化文本和少量切片风险可控。3. 核心细节解析从数据集构建到模型微调3.1 河道巡检数据集怎么建才不白费功夫做YOLO训练数据集是命根子。河道巡检的目标类别跟通用COCO差别很大COCO里没有“排污口”“漂浮垃圾”“违规网箱”这些类。我一开始想偷懒拿公开的水面垃圾数据集凑合结果模型在自家河道上表现一塌糊涂因为不同水域的光照、水色、背景差异太大了。后来老老实实自己采数据总结了几条经验。第一采集要覆盖多时段多天气。早上、中午、傍晚的光照完全不同晴天、阴天、雨后的水面反光也不一样。我至少保证每个目标类别在三种光照条件下都有样本。第二标注要定好边界。比如“漂浮垃圾”和“水生植物”容易混标注规范里要写清楚人工丢弃的塑料瓶、泡沫、包装袋算垃圾自然生长的水草不算。这个边界不统一模型学出来就是乱的。第三负样本不能少。河道里有很多类似目标的干扰物比如反光的水波、桥墩阴影、白色浪花这些都要作为负样本喂进去不然误检率下不来。数据量方面我的经验是每个类别至少500到1000个实例总数据集在5000张以上比较稳。如果某些类别实在难采可以用数据增强但增强要合理翻转、裁剪、亮度调整可以别搞那种把漂浮物旋转90度的操作因为无人机视角下目标朝向是有物理意义的。3.2 YOLOv8训练环境配置与关键参数环境配置这块我推荐用Anaconda建虚拟环境Python版本3.9或者3.10都行太新了有些库还不兼容。核心依赖就是ultralytics、torch、torchvision如果有GPU就装CUDA版本的torch。这里给一个我常用的环境配置命令实测在Ubuntu和Windows上都能跑通conda create -n river_yolo python3.10 conda activate river_yolo pip install ultralytics pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118训练的时候data.yaml要写清楚训练集、验证集路径和类别名。关键参数我一般这么设epochs100起步imgsz640batch16根据显存调整lr00.01lrf0.01。如果数据集小可以用预训练权重yolov8n.pt做迁移学习收敛快很多。这里有个坑预训练模型下载有时候会卡可以提前手动下载好放到指定目录或者用国内镜像源。训练过程中要盯紧几个指标box_loss和cls_loss是否稳定下降mAP0.5是否在涨。如果loss震荡厉害可能是学习率太大或者batch太小如果mAP早早饱和可能是数据量不够或者类别不平衡。我一般会跑一次baseline然后根据混淆矩阵看哪些类别容易混再针对性补数据。3.3 模型微调与置信度门限调整的实战技巧YOLOv8训练完之后直接拿来做推理往往会有误检和漏检。这时候置信度门限的调整就很关键。默认是0.25但河道场景下我一般会调高到0.4到0.5因为水面反光造成的误检太多宁可漏检也不能让系统天天报假警。但调太高又会漏掉小目标所以我的做法是分类别设门限大目标如船只、网箱设0.5小目标如漂浮垃圾设0.35排污口这种容易跟阴影混的设0.45。如果发现某个类别怎么调都不行那就得考虑微调了。微调有两种路子一种是冻结骨干网络只训练检测头适合数据量小的情况另一种是全部解冻用更小的学习率再训几十轮。我试过在YOLOv8基础上做LoRA式的轻量微调效果不错显存占用也低。具体操作是在train的时候设置freeze参数或者用ultralytics的高级API自定义训练循环。还有一个实战技巧用检测结果反哺训练。系统上线后把误检和漏检的样本自动存下来定期人工复核后加入训练集迭代几轮之后模型会越来越贴合实际场景。这个闭环跑起来比一次性训练一个完美模型要现实得多。4. 大模型接入Qwen与DeepSeek怎么跟YOLO串起来4.1 检测结果结构化与大模型输入设计YOLO输出的是一个个检测框格式是[x1, y1, x2, y2, confidence, class_id]。大模型看不懂这个所以中间要做一层结构化转换。我的做法是把每一帧的检测结果聚合成一个JSON包含时间戳、经纬度从无人机遥测数据里取、目标类别、数量、置信度、以及对应的小图切片路径。然后把这个JSON转成自然语言描述比如“2024年5月10日14时23分在坐标E120.15,N30.28处检测到3个漂浮垃圾置信度分别为0.87、0.79、0.65另有1个疑似排污口置信度0.52”。这个描述就是喂给大模型的prompt的一部分。为什么要转成自然语言因为大模型对结构化文本的理解不如对自然语言的理解直接而且自然语言描述方便后续做对话交互。当然如果用的是支持function calling的模型也可以直接传JSON让模型自己解析。DeepSeek的API支持tool calls这块可以做得更工程化。4.2 Qwen本地部署与AI对话功能实现Qwen的本地部署我推荐用Ollama或者vLLM。Ollama最简单一条命令就能拉模型跑起来适合快速验证vLLM吞吐高适合生产环境。如果是在Mac上Ollama跑Qwen2.5-7B量化版很流畅如果是在Linux服务器上可以用vLLM跑14B甚至72B。AI对话功能的实现逻辑是这样的前端用户输入问题后端把问题加上当前巡检上下文最近的检测结果、河道基本信息拼成prompt发给QwenQwen返回回答。这里的关键是上下文管理不能把整天的检测数据都塞进去token扛不住。我的做法是做一个滑动窗口只保留最近N条检测记录再加上一个摘要。摘要也是大模型生成的定期更新。实测下来Qwen在中文对话上的表现很自然问它“今天这段河道有什么异常”它能结合检测结果给出“上午10点左右在XX段发现较多漂浮物建议关注上游是否有排放”这样的回答。如果接入Qwen-VL还能直接让它看检测切片判断“这是塑料瓶还是泡沫箱”准确率比纯文本描述高不少。4.3 DeepSeek做报告生成与数据分析的落地方法DeepSeek我主要用来做巡检报告自动生成。传统做法是人工整理检测数据写Word报告一套流程下来半小时起步。现在把结构化数据喂给DeepSeek让它按模板生成报告几秒钟就出来了。模板可以自定义比如“一、巡检概况二、异常统计三、重点问题四、处置建议”。DeepSeek生成的文本逻辑清晰而且能根据数据自动调整措辞比如检测到大量漂浮物时它会写“建议立即组织打捞”检测到少量时写“建议持续关注”。数据分析方面DeepSeek可以做趋势研判。比如把一周的检测数据给它让它分析“漂浮物数量是否有上升趋势”“哪个河段问题最集中”。它给出的结论虽然不能全信但作为辅助参考很有价值。这里要注意大模型会有幻觉所以关键结论一定要有数据支撑不能让它凭空编。我的做法是让DeepSeek在生成结论时附上数据来源比如“根据5月1日至5月7日的检测记录XX段漂浮物数量从12个增加到23个”这样人工复核时能快速验证。5. 实操过程从零搭一套可运行的巡检系统5.1 无人机航线规划与影像采集要点无人机巡检不是随便飞航线规划直接影响数据质量。我的经验是沿河道中心线飞高度控制在50到80米重叠率不低于70%。高度太低视野窄太高目标太小重叠率高是为了后续做正射影像拼接也方便YOLO检测时有多角度参考。如果河道弯曲可以用航点飞行提前在地图上打好点。采集频率方面如果是视频流25帧每秒足够如果是定时拍照建议每2到3秒一张。要注意光照和阴影尽量避开正午顶光因为水面反光会干扰检测。我一般选上午9点到11点、下午3点到5点飞这两个时段光照斜射目标轮廓清晰。另外起降点要选好河道附近往往有树木和电线起降平台要开阔最好有RTK定位保证航线精度。5.2 YOLO推理服务封装与边缘部署训练好的YOLO模型要封装成服务才能被系统调用。我用FastAPI写了一个简单的推理接口接收图片或者视频帧返回检测结果JSON。核心代码大概长这样from fastapi import FastAPI, File, UploadFile from ultralytics import YOLO import cv2 import numpy as np app FastAPI() model YOLO(best.pt) app.post(/detect) async def detect(file: UploadFile File(...)): contents await file.read() nparr np.frombuffer(contents, np.uint8) img cv2.imdecode(nparr, cv2.IMREAD_COLOR) results model(img, conf0.4) detections [] for r in results: for box in r.boxes: detections.append({ class: model.names[int(box.cls)], confidence: float(box.conf), bbox: box.xyxy.tolist()[0] }) return {detections: detections}边缘部署的话如果是Jetson设备可以用TensorRT加速把YOLO导出成engine文件推理速度能提升2到3倍。导出命令是yolo export modelbest.pt formatengine。注意TensorRT版本要和CUDA版本匹配不然会报错。如果是用RK3588这类国产芯片可以用RKNN工具链转换流程类似但细节不同。5.3 大模型服务串联与前后端联调大模型服务的串联我建议用消息队列解耦。YOLO检测完把结果丢进Redis或者RabbitMQ大模型服务从队列里取处理完再写回数据库。这样即使大模型服务挂了检测也不受影响恢复后继续消费就行。前端通过WebSocket订阅结果实现实时更新。前后端联调的时候最容易出问题的是数据格式不一致。YOLO输出的坐标是像素值前端地图需要的是经纬度这中间要做坐标转换。我的做法是在无人机遥测数据里直接取经纬度跟检测框关联而不是从像素反推。另外时间戳要统一用UTC避免时区混乱。联调阶段多打日志每个环节的输入输出都记下来出问题好排查。6. 常见问题与排查技巧实录6.1 模型检测效果差的排查思路检测效果差是最常见的问题排查要按顺序来。第一步看数据训练集里目标类别的样本够不够标注有没有错。我遇到过标注把水草标成垃圾的情况模型学出来全是误检。第二步看训练loss曲线是否正常mAP是否收敛。如果训练集mAP高但验证集低那是过拟合要加数据或者加正则。第三步看推理置信度门限是否合理输入图像尺寸是否跟训练一致。我见过有人训练用640推理用1280结果小目标全漏了。还有一个隐蔽的坑图像预处理不一致。训练时YOLO会自动做归一化和resize推理时如果自己用OpenCV读图可能颜色通道顺序不对BGR vs RGB导致检测结果完全乱掉。这个坑我踩过排查了半天才发现是通道问题。6.2 大模型输出不稳定与幻觉的应对大模型输出不稳定主要表现为同样的问题每次回答不一样或者编造不存在的数据。应对方法有几个一是降低temperature设成0.1到0.3输出会稳定很多二是用few-shot在prompt里给几个示例告诉它该怎么回答三是加校验让大模型输出结构化JSON然后用代码校验字段是否合法不合法就重试。幻觉问题在报告生成时尤其要注意。我的做法是把关键数据以表格形式硬编码进prompt让大模型只做文字组织不做数据推断。比如检测到5个漂浮物我直接在prompt里写“漂浮物数量5”而不是让它从原始数据里自己数。这样虽然灵活性差一点但准确性高很多。6.3 系统性能瓶颈与优化方向系统跑起来之后瓶颈往往不在YOLO也不在大模型而在数据传输和存储。无人机图传带宽有限如果传原始视频几公里下来流量惊人。优化方向是边缘预处理在无人机或者地面站先把视频抽帧只传有检测目标的帧或者传低分辨率全帧加高分辨率切片。存储方面检测结果和小图切片存数据库原始视频定期清理或者冷存储能省不少成本。另一个瓶颈是大模型推理延迟。如果并发请求多单个GPU扛不住。优化方法有用vLLM做批处理多个请求合并推理或者用更小的模型比如Qwen2.5-3B牺牲一点质量换速度。实测下来7B模型在A100上单次推理大概1到2秒3B能到0.5秒以内看业务能接受多少延迟。常见问题可能原因排查方法解决方案检测漏检严重置信度门限过高、小目标训练不足降低门限测试、检查小目标样本量分类别设门限、补充小目标数据误检频繁负样本不足、水面反光干扰查看误检样本特征增加负样本、调整光照条件大模型回答跑偏prompt不清晰、上下文过长检查prompt模板、token数量优化prompt、做上下文摘要推理速度慢模型太大、硬件算力不足测单帧推理耗时模型量化、TensorRT加速图传延迟高带宽不足、编码效率低测实际带宽占用边缘抽帧、只传检测切片7. 一些实操心得与后续扩展方向这套系统我从原型到上线跑了大概半年最大的体会是AI落地不是模型越牛越好而是整条链路越顺越好。YOLO用v8n还是v8mQwen用7B还是14B这些选择对最终效果的影响远不如数据质量、部署稳定性和人机交互设计来得大。我见过太多项目死在“模型指标很好看但实际用起来各种别扭”上。另外分享一个小技巧把巡检人员的反馈做成闭环。系统里加一个“误报/漏报”按钮巡检员发现检测错了点一下就能把样本存下来。每周导出一次人工复核后加入训练集再跑一轮微调。这个循环跑上三四轮模型在自家河道上的表现会有质的提升。比一次性花大力气标一个完美数据集要务实得多。后续扩展的话我觉得有几个方向值得试一是多模态融合把可见光、红外、多光谱数据一起喂给模型排污口在红外下往往有热特征能提高检出率二是时序分析把连续帧的检测结果串起来判断漂浮物的移动方向预测它接下来会漂到哪里三是边缘大模型随着端侧算力提升未来也许能把小参数大模型直接部署在无人机上实现完全自主的“边飞边判边报告”。这些方向我都在陆续尝试有新的进展再跟大家分享。 无人机河道巡检系统：YOLOv8目标检测与Qwen、DeepSeek大模型实战
1. 河道巡检这件事为什么值得用“无人机YOLO大模型”重做一遍我做河道巡检相关的项目断断续续有几年了最早接触的时候人工巡河还是主流两三个人一组沿着堤岸走拿着本子记遇到排污口、漂浮物、岸线违建就拍照存档。这种方式的问题不用我多说一条十几公里的河道走下来大半天人累得够呛漏检率还高尤其是那些藏在芦苇荡后面、桥洞底下的问题肉眼根本够不着。后来陆续上了无人机效率确实上来了但新的麻烦也跟着来了——飞机是飞了可拍回来的视频和照片堆成山靠人一张张翻等于把体力活换成了眼力活本质上没解决“看得快、看得准、看得懂”的问题。这套基于深度学习YOLO算法加Qwen、DeepSeek大模型的无人机河道巡检系统平台就是冲着这个痛点去的。它的核心逻辑其实很清晰无人机负责“看”YOLO负责“找”大模型负责“想”和“写”。无人机按规划航线自动飞把河道影像实时传回来YOLO系列算法在边缘端或者服务端做目标检测把漂浮垃圾、排污口、违规船只、岸线侵占这些目标框出来检测结果再喂给Qwen或者DeepSeek这类大语言模型让它结合上下文做研判、生成巡检报告甚至支持一线人员用自然语言跟系统对话问“今天这段河道有没有异常”“帮我出一份上午的巡检简报”。这套东西适合谁看我觉得有三类人值得花时间读下去。第一类是做智慧水利、环保监测的工程技术人员你们可能正在评估要不要上类似的系统或者已经上了但效果不理想第二类是做计算机视觉落地的算法工程师YOLO你们熟但怎么跟大模型串起来、怎么在无人机这种算力受限的场景下跑通这里面有不少坑第三类是想了解AI工程化全链路的爱好者这套系统从数据采集、模型训练、边缘部署到大模型接入基本把当前主流的AI落地环节都覆盖了一遍。下面我就按实际做项目的思路把整套系统的设计、实现和踩过的坑掰开揉碎讲一遍。2. 系统整体架构与方案选型为什么是YOLO加双大模型2.1 从“飞完再看”到“边飞边判”的架构演进早期做无人机巡检最省事的做法是飞机飞完把SD卡拔下来拷到电脑上慢慢分析。这种离线模式的好处是简单坏处是时效性极差等你分析完污染可能已经扩散了。所以这套系统我一开始就定了调子必须支持实时或准实时回传与推理。整体架构分四层从下往上分别是采集层、传输层、推理层和应用层。采集层就是无人机本体加挂载常见的是可见光云台相机条件好的会加红外或者多光谱。传输层走的是无人机图传链路加地面站转发把视频流推到边缘计算盒子或者云端。推理层是核心YOLO模型在这里做目标检测检测结果结构化之后送进大模型做语义理解和报告生成。应用层就是给用户看的Web端或者移动端支持地图标注、告警推送、AI对话和文档导出。这里有个关键决策点推理放在边缘还是云端。我实测下来如果对实时性要求高比如要边飞边告警那YOLO必须放在无人机机载或者地面站附近的边缘设备上因为图传链路带宽有限把原始4K视频全传回云端再推理延迟和流量都吃不消。但大模型推理又吃算力边缘设备跑不动Qwen或者DeepSeek的完整版本。所以我的方案是边缘做检测、云端做理解边缘端跑YOLOv8n或者YOLOv8s这种轻量模型只把检测框、类别、置信度和对应的小图切片传回云端云端再调用大模型做深度分析。这样带宽占用能降到原来的十分之一以下实测很稳。2.2 YOLO版本选型为什么最终落在YOLOv8YOLO系列迭代很快从v5到v8再到v9、v10每个版本都有拥趸。我选型的时候主要看三个维度精度、速度、部署便利性。YOLOv5社区生态最成熟资料多但架构相对老一些YOLOv8在精度和速度的平衡上做得更好而且Ultralytics官方把训练、验证、导出、部署的链路整合得很顺yolo命令行工具和Python API都很友好YOLOv9、v10虽然论文指标好看但实际部署时算子兼容性和量化工具链还不够稳踩坑成本高。所以最终定的是YOLOv8具体用哪个尺寸看场景。如果边缘设备是Jetson Orin Nano这种跑YOLOv8nnano版能到30帧以上够用如果是地面站有独立显卡可以上YOLOv8m甚至YOLOv8l精度更高。这里给个实测数据参考在自建的河道漂浮物数据集上YOLOv8n的mAP0.5大概在0.82左右YOLOv8s能到0.87YOLOv8m能到0.90。如果只是检测大块漂浮垃圾nano版完全够如果要区分排污口和普通水渍那就得上s或者m。2.3 大模型选型Qwen和DeepSeek怎么分工大模型这块我用了两个Qwen和DeepSeek。不是非要两个都用而是它们各有擅长。Qwen系列在中文理解和多模态方面积累深尤其是Qwen-VL可以直接读图适合做“看图说话”式的巡检描述DeepSeek在推理和代码生成上强适合做结构化报告生成和复杂逻辑研判。实际部署时我一般让Qwen负责对话交互和图像理解DeepSeek负责报告生成和数据分析两者通过API或者本地推理服务串起来。这里要提一下本地部署的考量。河道巡检数据往往涉及地理信息有些项目方要求数据不出内网那就得本地部署。Qwen有多个尺寸7B、14B、72B都有7B在消费级显卡上就能跑量化之后甚至能在Mac上跑DeepSeek也有不同参数版本按需选择。如果算力实在紧张可以用API调用云端服务但要注意数据脱敏。我个人的建议是检测模型必须本地大模型可以灵活因为检测涉及原始影像大模型处理的是结构化文本和少量切片风险可控。3. 核心细节解析从数据集构建到模型微调3.1 河道巡检数据集怎么建才不白费功夫做YOLO训练数据集是命根子。河道巡检的目标类别跟通用COCO差别很大COCO里没有“排污口”“漂浮垃圾”“违规网箱”这些类。我一开始想偷懒拿公开的水面垃圾数据集凑合结果模型在自家河道上表现一塌糊涂因为不同水域的光照、水色、背景差异太大了。后来老老实实自己采数据总结了几条经验。第一采集要覆盖多时段多天气。早上、中午、傍晚的光照完全不同晴天、阴天、雨后的水面反光也不一样。我至少保证每个目标类别在三种光照条件下都有样本。第二标注要定好边界。比如“漂浮垃圾”和“水生植物”容易混标注规范里要写清楚人工丢弃的塑料瓶、泡沫、包装袋算垃圾自然生长的水草不算。这个边界不统一模型学出来就是乱的。第三负样本不能少。河道里有很多类似目标的干扰物比如反光的水波、桥墩阴影、白色浪花这些都要作为负样本喂进去不然误检率下不来。数据量方面我的经验是每个类别至少500到1000个实例总数据集在5000张以上比较稳。如果某些类别实在难采可以用数据增强但增强要合理翻转、裁剪、亮度调整可以别搞那种把漂浮物旋转90度的操作因为无人机视角下目标朝向是有物理意义的。3.2 YOLOv8训练环境配置与关键参数环境配置这块我推荐用Anaconda建虚拟环境Python版本3.9或者3.10都行太新了有些库还不兼容。核心依赖就是ultralytics、torch、torchvision如果有GPU就装CUDA版本的torch。这里给一个我常用的环境配置命令实测在Ubuntu和Windows上都能跑通conda create -n river_yolo python3.10 conda activate river_yolo pip install ultralytics pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118训练的时候data.yaml要写清楚训练集、验证集路径和类别名。关键参数我一般这么设epochs100起步imgsz640batch16根据显存调整lr00.01lrf0.01。如果数据集小可以用预训练权重yolov8n.pt做迁移学习收敛快很多。这里有个坑预训练模型下载有时候会卡可以提前手动下载好放到指定目录或者用国内镜像源。训练过程中要盯紧几个指标box_loss和cls_loss是否稳定下降mAP0.5是否在涨。如果loss震荡厉害可能是学习率太大或者batch太小如果mAP早早饱和可能是数据量不够或者类别不平衡。我一般会跑一次baseline然后根据混淆矩阵看哪些类别容易混再针对性补数据。3.3 模型微调与置信度门限调整的实战技巧YOLOv8训练完之后直接拿来做推理往往会有误检和漏检。这时候置信度门限的调整就很关键。默认是0.25但河道场景下我一般会调高到0.4到0.5因为水面反光造成的误检太多宁可漏检也不能让系统天天报假警。但调太高又会漏掉小目标所以我的做法是分类别设门限大目标如船只、网箱设0.5小目标如漂浮垃圾设0.35排污口这种容易跟阴影混的设0.45。如果发现某个类别怎么调都不行那就得考虑微调了。微调有两种路子一种是冻结骨干网络只训练检测头适合数据量小的情况另一种是全部解冻用更小的学习率再训几十轮。我试过在YOLOv8基础上做LoRA式的轻量微调效果不错显存占用也低。具体操作是在train的时候设置freeze参数或者用ultralytics的高级API自定义训练循环。还有一个实战技巧用检测结果反哺训练。系统上线后把误检和漏检的样本自动存下来定期人工复核后加入训练集迭代几轮之后模型会越来越贴合实际场景。这个闭环跑起来比一次性训练一个完美模型要现实得多。4. 大模型接入Qwen与DeepSeek怎么跟YOLO串起来4.1 检测结果结构化与大模型输入设计YOLO输出的是一个个检测框格式是[x1, y1, x2, y2, confidence, class_id]。大模型看不懂这个所以中间要做一层结构化转换。我的做法是把每一帧的检测结果聚合成一个JSON包含时间戳、经纬度从无人机遥测数据里取、目标类别、数量、置信度、以及对应的小图切片路径。然后把这个JSON转成自然语言描述比如“2024年5月10日14时23分在坐标E120.15,N30.28处检测到3个漂浮垃圾置信度分别为0.87、0.79、0.65另有1个疑似排污口置信度0.52”。这个描述就是喂给大模型的prompt的一部分。为什么要转成自然语言因为大模型对结构化文本的理解不如对自然语言的理解直接而且自然语言描述方便后续做对话交互。当然如果用的是支持function calling的模型也可以直接传JSON让模型自己解析。DeepSeek的API支持tool calls这块可以做得更工程化。4.2 Qwen本地部署与AI对话功能实现Qwen的本地部署我推荐用Ollama或者vLLM。Ollama最简单一条命令就能拉模型跑起来适合快速验证vLLM吞吐高适合生产环境。如果是在Mac上Ollama跑Qwen2.5-7B量化版很流畅如果是在Linux服务器上可以用vLLM跑14B甚至72B。AI对话功能的实现逻辑是这样的前端用户输入问题后端把问题加上当前巡检上下文最近的检测结果、河道基本信息拼成prompt发给QwenQwen返回回答。这里的关键是上下文管理不能把整天的检测数据都塞进去token扛不住。我的做法是做一个滑动窗口只保留最近N条检测记录再加上一个摘要。摘要也是大模型生成的定期更新。实测下来Qwen在中文对话上的表现很自然问它“今天这段河道有什么异常”它能结合检测结果给出“上午10点左右在XX段发现较多漂浮物建议关注上游是否有排放”这样的回答。如果接入Qwen-VL还能直接让它看检测切片判断“这是塑料瓶还是泡沫箱”准确率比纯文本描述高不少。4.3 DeepSeek做报告生成与数据分析的落地方法DeepSeek我主要用来做巡检报告自动生成。传统做法是人工整理检测数据写Word报告一套流程下来半小时起步。现在把结构化数据喂给DeepSeek让它按模板生成报告几秒钟就出来了。模板可以自定义比如“一、巡检概况二、异常统计三、重点问题四、处置建议”。DeepSeek生成的文本逻辑清晰而且能根据数据自动调整措辞比如检测到大量漂浮物时它会写“建议立即组织打捞”检测到少量时写“建议持续关注”。数据分析方面DeepSeek可以做趋势研判。比如把一周的检测数据给它让它分析“漂浮物数量是否有上升趋势”“哪个河段问题最集中”。它给出的结论虽然不能全信但作为辅助参考很有价值。这里要注意大模型会有幻觉所以关键结论一定要有数据支撑不能让它凭空编。我的做法是让DeepSeek在生成结论时附上数据来源比如“根据5月1日至5月7日的检测记录XX段漂浮物数量从12个增加到23个”这样人工复核时能快速验证。5. 实操过程从零搭一套可运行的巡检系统5.1 无人机航线规划与影像采集要点无人机巡检不是随便飞航线规划直接影响数据质量。我的经验是沿河道中心线飞高度控制在50到80米重叠率不低于70%。高度太低视野窄太高目标太小重叠率高是为了后续做正射影像拼接也方便YOLO检测时有多角度参考。如果河道弯曲可以用航点飞行提前在地图上打好点。采集频率方面如果是视频流25帧每秒足够如果是定时拍照建议每2到3秒一张。要注意光照和阴影尽量避开正午顶光因为水面反光会干扰检测。我一般选上午9点到11点、下午3点到5点飞这两个时段光照斜射目标轮廓清晰。另外起降点要选好河道附近往往有树木和电线起降平台要开阔最好有RTK定位保证航线精度。5.2 YOLO推理服务封装与边缘部署训练好的YOLO模型要封装成服务才能被系统调用。我用FastAPI写了一个简单的推理接口接收图片或者视频帧返回检测结果JSON。核心代码大概长这样from fastapi import FastAPI, File, UploadFile from ultralytics import YOLO import cv2 import numpy as np app FastAPI() model YOLO(best.pt) app.post(/detect) async def detect(file: UploadFile File(...)): contents await file.read() nparr np.frombuffer(contents, np.uint8) img cv2.imdecode(nparr, cv2.IMREAD_COLOR) results model(img, conf0.4) detections [] for r in results: for box in r.boxes: detections.append({ class: model.names[int(box.cls)], confidence: float(box.conf), bbox: box.xyxy.tolist()[0] }) return {detections: detections}边缘部署的话如果是Jetson设备可以用TensorRT加速把YOLO导出成engine文件推理速度能提升2到3倍。导出命令是yolo export modelbest.pt formatengine。注意TensorRT版本要和CUDA版本匹配不然会报错。如果是用RK3588这类国产芯片可以用RKNN工具链转换流程类似但细节不同。5.3 大模型服务串联与前后端联调大模型服务的串联我建议用消息队列解耦。YOLO检测完把结果丢进Redis或者RabbitMQ大模型服务从队列里取处理完再写回数据库。这样即使大模型服务挂了检测也不受影响恢复后继续消费就行。前端通过WebSocket订阅结果实现实时更新。前后端联调的时候最容易出问题的是数据格式不一致。YOLO输出的坐标是像素值前端地图需要的是经纬度这中间要做坐标转换。我的做法是在无人机遥测数据里直接取经纬度跟检测框关联而不是从像素反推。另外时间戳要统一用UTC避免时区混乱。联调阶段多打日志每个环节的输入输出都记下来出问题好排查。6. 常见问题与排查技巧实录6.1 模型检测效果差的排查思路检测效果差是最常见的问题排查要按顺序来。第一步看数据训练集里目标类别的样本够不够标注有没有错。我遇到过标注把水草标成垃圾的情况模型学出来全是误检。第二步看训练loss曲线是否正常mAP是否收敛。如果训练集mAP高但验证集低那是过拟合要加数据或者加正则。第三步看推理置信度门限是否合理输入图像尺寸是否跟训练一致。我见过有人训练用640推理用1280结果小目标全漏了。还有一个隐蔽的坑图像预处理不一致。训练时YOLO会自动做归一化和resize推理时如果自己用OpenCV读图可能颜色通道顺序不对BGR vs RGB导致检测结果完全乱掉。这个坑我踩过排查了半天才发现是通道问题。6.2 大模型输出不稳定与幻觉的应对大模型输出不稳定主要表现为同样的问题每次回答不一样或者编造不存在的数据。应对方法有几个一是降低temperature设成0.1到0.3输出会稳定很多二是用few-shot在prompt里给几个示例告诉它该怎么回答三是加校验让大模型输出结构化JSON然后用代码校验字段是否合法不合法就重试。幻觉问题在报告生成时尤其要注意。我的做法是把关键数据以表格形式硬编码进prompt让大模型只做文字组织不做数据推断。比如检测到5个漂浮物我直接在prompt里写“漂浮物数量5”而不是让它从原始数据里自己数。这样虽然灵活性差一点但准确性高很多。6.3 系统性能瓶颈与优化方向系统跑起来之后瓶颈往往不在YOLO也不在大模型而在数据传输和存储。无人机图传带宽有限如果传原始视频几公里下来流量惊人。优化方向是边缘预处理在无人机或者地面站先把视频抽帧只传有检测目标的帧或者传低分辨率全帧加高分辨率切片。存储方面检测结果和小图切片存数据库原始视频定期清理或者冷存储能省不少成本。另一个瓶颈是大模型推理延迟。如果并发请求多单个GPU扛不住。优化方法有用vLLM做批处理多个请求合并推理或者用更小的模型比如Qwen2.5-3B牺牲一点质量换速度。实测下来7B模型在A100上单次推理大概1到2秒3B能到0.5秒以内看业务能接受多少延迟。常见问题可能原因排查方法解决方案检测漏检严重置信度门限过高、小目标训练不足降低门限测试、检查小目标样本量分类别设门限、补充小目标数据误检频繁负样本不足、水面反光干扰查看误检样本特征增加负样本、调整光照条件大模型回答跑偏prompt不清晰、上下文过长检查prompt模板、token数量优化prompt、做上下文摘要推理速度慢模型太大、硬件算力不足测单帧推理耗时模型量化、TensorRT加速图传延迟高带宽不足、编码效率低测实际带宽占用边缘抽帧、只传检测切片7. 一些实操心得与后续扩展方向这套系统我从原型到上线跑了大概半年最大的体会是AI落地不是模型越牛越好而是整条链路越顺越好。YOLO用v8n还是v8mQwen用7B还是14B这些选择对最终效果的影响远不如数据质量、部署稳定性和人机交互设计来得大。我见过太多项目死在“模型指标很好看但实际用起来各种别扭”上。另外分享一个小技巧把巡检人员的反馈做成闭环。系统里加一个“误报/漏报”按钮巡检员发现检测错了点一下就能把样本存下来。每周导出一次人工复核后加入训练集再跑一轮微调。这个循环跑上三四轮模型在自家河道上的表现会有质的提升。比一次性花大力气标一个完美数据集要务实得多。后续扩展的话我觉得有几个方向值得试一是多模态融合把可见光、红外、多光谱数据一起喂给模型排污口在红外下往往有热特征能提高检出率二是时序分析把连续帧的检测结果串起来判断漂浮物的移动方向预测它接下来会漂到哪里三是边缘大模型随着端侧算力提升未来也许能把小参数大模型直接部署在无人机上实现完全自主的“边飞边判边报告”。这些方向我都在陆续尝试有新的进展再跟大家分享。