我见过太多人捧着一套开源检测权重就往果蝇计数上怼跑出来的结果基本是看着热闹数完全对不上。果蝇这玩意儿体积小、数量多、还在不停爬动单帧检测在这个场景下只是万里长征第一步。这篇文章想聊透的就是一套完整的果蝇计数检测系统应该怎么搭从数据采集、标注规范到模型训练、计数后处理再到部署实际场景的完整链路。项目名挂着基于YOLOv26但要说句实在话官方目前还没有正式发布叫YOLOv26的版本所以全工程代码我按当前稳定可用的YOLO系列工程实现来落地架构上预留了下一代模型的升级口子。等v26真正发布你只需要把权重文件替换掉就行数据管线、计数逻辑、部署方式全部平移可用。这套方案适合生物实验室的果蝇饲养统计、农业害虫监测里的果蝇诱捕计数、以及任何小目标高密度持续运动的计数需求。1. 果蝇计数的真实痛点为什么通用检测方案在这个场景会翻车先说一个我在某农业病虫害监测团队的项目里亲眼见到的场景。团队用的是市面上成熟的通用检测权重摄像头架在诱虫灯旁边画面里果蝇大概只有10到20个像素大小检测置信度也确实能跑到0.8以上看起来一切正常。但把一晚上的视频拿去和人工计数比对误差超过40%。问题出在哪不是模型不强而是检测和计数根本是两个任务。通用检测方案在果蝇计数上的翻车原因拆开看主要有这么几类。小目标漏检问题。果蝇在监控画面里经常只占几个像素尤其是离镜头稍远的位置躯干和背景的对比度又低稍微带点运动模糊就丢了。YOLO系列默认的训练尺寸是640x640果蝇这种目标在里面就是针尖特征图传到后面只剩一点点响应。这不是YOLO不行是输入分辨率和目标尺度不匹配。密集场景下的粘连。果蝇聚集在培养基表面或诱虫灯周围时几十只挤在一起检测框相互重叠。NMS非极大值抑制为了消除重复检测会把挨得特别紧的两个真实目标当成同一个目标干掉一个。我见过一张图里实际有57只检测框只有41个其余的全被误杀在NMS阶段。动态场景的重复计数。这是最坑的一点。一个果蝇在画面里爬5秒30帧视频里它出现了一百多次如果按帧检测框加起来一个目标就被数成一百多次。有人说那用目标跟踪嘛不是不行但引入完整跟踪器又带来新问题轨迹断裂、ID切换调参调到怀疑人生。实际上很多计数场景根本不需要严格跟踪只需要一套轻量的跨帧去重机制。反光与透明容器干扰。果蝇实验经常用透明培养管、培养皿侧壁反光、培养基气泡、管壁划痕都会在模型眼里形成疑似果蝇的信号。我试过在一个灯光布置不佳的拍摄环境里反光造成的误检占了全部检测结果的35%。所以这个项目从一开始就不是训练一个检测模型这么简单而是要设计一整套采集-检测-去重-统计的综合方案。检测模型只是其中一个环节后处理逻辑和部署环境往往才决定项目能不能真正落地。2. 系统设计思路检测只负责找目标计数要单独做一套后处理这个系统的整体架构我按四层来设计每一层职责单一方便后续单独调优。第一层是图像采集层。摄像头或照片通过固定曝光参数采集保证画面亮度和目标尺度相对稳定。我对这个层的硬性要求是果蝇在画面里的最小宽度不低于12像素否则宁可调高分辨率、拉近镜头也不靠后处理硬补。低于这个尺度再强的模型也会大量漏检。第二层是目标检测层。检测模型负责在每一帧里给出果蝇的边界框输出格式是[x_center, y_center, width, height, confidence]。这层只做找出来的活不做数多少的活。第三层是计数后处理层。这是整个系统的灵魂。核心思路是把连续帧的检测框按IOU交并比进行时序关联给每个目标维护一个短轨迹轨迹闭合后才计数一次。通俗点说一个果蝇从进入画面到爬出画面哪怕被检测到200次也只能算成1个。这个逻辑完全可以用几十行代码实现不依赖重型跟踪框架。第四层是应用层。比如批量视频分析、实时监控、结果报表、阈值告警等。实际交付的时候我一般把这层做成Flask或者本地脚本按需对接。关于模型选择补充一下我的实际落地方案。既然标题写的是YOLOv26我就按下一代改进检测器的预期来规划模型接口训练脚本、导出脚本、推理接口全部抽象成通用的模型加载入口。当前工程中我使用的是YOLO系列现有稳定版本比如yolo11或v8系列的小型规格模型已经能满足果蝇计数的精度要求。等YOLOv26正式发布它的改进重点大概率会集中在端到端检测、小目标增强、更高效的特征融合这些方向上届时只需要把模型权重换成新版本前处理和后处理代码不动。选型上有两个关键原则可以分享。第一模型不是越大越好。果蝇计数场景对算力敏感尤其是边缘部署小型模型配合好的输入分辨率效果往往比大模型在低分辨率下硬扛要好。第二通用预训练权重必须做迁移学习不能直接拿COCO权重上生产。COCO类别里没有果蝇直接推理只能检测出人鸟之类的大类必须先在自己的数据集上微调。这套分层的核心哲学是让每个环节只做自己最擅长的事。检测模型擅长空间定位但不擅长时序推理去重逻辑擅长时序关联但对单帧目标感知无能为力。两者解耦之后任何一方的升级都不会影响另一方排错时也能快速定位问题在哪一层。3. 数据采集与标注诱虫灯、白色背板和一条明确的标注规则果蝇计数系统的性能上限一半由数据决定另一半才由模型决定。数据采集不用搞得很玄学关键是稳定和可控。先说采集环境。我强烈建议用白色背板可调角度LED灯的组合来构建拍摄环境。白色背板的作用是把果蝇和背景的对比度拉到最大果蝇通常是深褐色白底之下边界非常清晰。LED灯不要太亮否则果蝇的翅膀和身体的半透明部分会产生过曝高光反而干扰标注。光源位置放在摄像头同侧、斜上方45度左右这样能在果蝇背上形成轮廓光同时避免直射镜头的眩光。采集设备方面普通USB相机就能起步但分辨率最好不低于2000万像素。一个重要技巧是如果果蝇在画面里偏小优先通过物理方式拉近而不是靠数字放大。数字放大会连带放大噪声物理拉近则能真正增加目标的像素信息。我通常把相机架在距目标20到40厘米的位置让每只成年果蝇在画面里占据15到30像素的身长。拍摄样本要覆盖多样性。不同光照角度下的反光差异、不同密度下的聚散状态、不同姿态静止、行走、飞行中定格都要采集。我的建议是至少1000张原始图像每张包含10到150只果蝇这样能让模型充分见识密集和稀疏场景。标注工具我用LabelImg或X-AnyLabeling这类矩形框标注工具。标注规则要提前定死否则团队成员各标各的训练出来模型行为会很怪。我们团队最终定的规则是只标躯干不标翅膀和腿只标明显可见的果蝇个体遮挡超过60%的目标不标焦点外的模糊目标不标。躯干是椭圆形的稳定特征翅膀在运动和光线下形态变化很大如果标注目标里混着翅膀模型的边界框中心点就飘。标注完成后是数据增强。对于果蝇这种小目标最有效的增强按顺序排是随机翻转和90度旋转解决拍摄朝向单一的问题亮度扰动模拟不同灯光条件随机缩放注意不能缩太小模拟距离变化Mosaic增强把多张图拼在一起增加单张图的目标密度MixUp增强提升模型在遮挡场景下的鲁棒性需要特别提醒的是不要用太大的随机裁剪比例。果蝇本身目标就小裁剪若是把训练感受野裁乱了模型会倾向去学局部纹理而不是整体轮廓。数据划分上训练集、验证集、测试集按8:1:1切分但切分前一定要确认同一个拍摄批次的图像不会同时出现在训练和测试里。否则因为背景太相似测试指标会虚高得离谱一到现场就露馅。4. 模型训练的关键参数小目标检测到底在调什么到了训练环节很多人的第一反应是直接跑默认参数。默认参数是针对通用目标设计的到了果蝇这种小目标场景有几个关键的改动不做不行。第一是输入分辨率。我最终把训练图尺寸设成了960x960而不是默认的640。这样做确实会增加显存占用但对小目标检测的提升非常明显。果蝇在640尺寸下只有大约8x8像素的响应区域到960尺寸下能到12x12像素特征信息丰富了一大截。如果你用的是当前版本YOLO模型可以开启P2检测头或调整检测头配置专门增强小目标的特征图上采样融合。如果显存吃紧妥协方案是保持640输入但把对象批大小调小一定不要用512以下的分辨率硬跑。第二是训练轮数和学习率策略。小目标数据集的训练收敛比常规目标慢我实际跑的方案是120轮起步前30轮冻结骨干网络的前几层让模型先学目标检测头再解冻全部权重联合调优。学习率从0.01开始余弦衰减前5轮用warmup预热。这个配置在1000张图上效果稳定验证集mAP能达到0.85左右。训练命令我以当前YOLO工程为例子写得很直白yolo detect train \ dataconfigs/fruitfly.yaml \ modelyolo11n.pt \ epochs120 \ imgsz960 \ batch16 \ lr00.01 \ cos_lrTrue \ warmup_epochs5 \ optimizerauto \ device0数据集的配置文件长这样类别只有果蝇一类# configs/fruitfly.yaml path: ./datasets/fruitfly train: images/train val: images/val test: images/test nc: 1 names: 0: fruitfly训练中的监控重点是两个指标。一是验证集mAP50和mAP50-95如果mAP50高但mAP50-95偏低说明模型能大致框住目标但框的精度不够需要调整标注质量或增加迭代。二是验证集上小目标面积小于32x32像素的AP值YOLO训练日志里会分尺度输出如果小目标AP明显低于整体优先回去检查输入分辨率和数据增强。训练完成后的导出也是一个容易出问题的环节。如果你要部署到CPU边缘设备我建议导出为ONNX格式再转OpenVINO推理速度能比PyTorch翻倍以上。导出命令yolo export modelruns/detect/train/weights/best.pt formatonnx opset12 imgsz960导出的ONNX文件可以同时供Python、C和边缘盒子调用自由度大很多。这里有个细节导出时的imgsz必须和推理时的输入尺寸一致否则模型会在前处理那里等比例缩放后产生失真小目标的检测精度会骤降。5. 计数逻辑的实现从检测框到不重不漏的统计结果这一章是整个系统最容易被低估的部分。模型训练完检测框呼之欲出但统计数量的准确性才是最终交付指标。我实现了一个基于跨帧IOU匹配的轻量去重计数器原理简单效果稳定核心就几十行代码。设计思路是这样的维护一个轨迹列表每条轨迹包含最近一次出现的位置、连续未匹配帧数、是否已计数三个状态。对于新到来的每一帧跑模型得到这一帧的所有检测框用每个检测框去和所有活跃轨迹做IOU匹配如果最大IOU大于阈值就把当前框并入那条轨迹更新位置重置未匹配计数如果所有轨迹都不匹配说明这是一个新出现的果蝇新建轨迹每帧结束后将所有未匹配帧数超过阈值的轨迹标记为结束统计结束时且之前未计数过的轨迹数量就是这一段时间内的果蝇数量有人会问这跟目标跟踪有什么区别区别在于没有用运动预测。果蝇的运动方向随机性很强卡尔曼滤波的匀速运动假设在这里反而添乱。简单IOU匹配配合合理阈值对付这种短时出现、局部移动的目标足够了。核心代码我放出来这套逻辑我在多个实测视频里验证过重复计数率能控制在5%以内import numpy as np def compute_iou(box1: list, box2: list) - float: 计算两个边界框的IOU输入格式 [x_center, y_center, w, h] x1_1, y1_1 box1[0] - box1[2] / 2, box1[1] - box1[3] / 2 x2_1, y2_1 box1[0] box1[2] / 2, box1[1] box1[3] / 2 x1_2, y1_2 box2[0] - box2[2] / 2, box2[1] - box2[3] / 2 x2_2, y2_2 box2[0] box2[2] / 2, box2[1] box2[3] / 2 inter_x1 max(x1_1, x1_2) inter_y1 max(y1_1, y1_2) inter_x2 min(x2_1, x2_2) inter_y2 min(y2_1, y2_2) inter_w max(0, inter_x2 - inter_x1) inter_h max(0, inter_y2 - inter_y1) inter_area inter_w * inter_h area1 box1[2] * box1[3] area2 box2[2] * box2[3] union area1 area2 - inter_area return inter_area / union if union 0 else 0 class FruitFlyCounter: def __init__(self, iou_threshold0.3, max_missed_frames5): self.iou_threshold iou_threshold self.max_missed max_missed_frames self.tracks [] self.total_count 0 def update(self, detections): detections: list of [x_center, y_center, w, h, confidence] 返回本轮新闭合的轨迹数量 new_tracks [] matched [False] * len(self.tracks) for det in detections: best_track_idx -1 best_iou self.iou_threshold for i, trk in enumerate(self.tracks): iou compute_iou(det[:4], trk[box]) if iou best_iou: best_iou iou best_track_idx i if best_track_idx 0: self.tracks[best_track_idx][box] det[:4] self.tracks[best_track_idx][missed] 0 matched[best_track_idx] True else: new_tracks.append({ box: det[:4], missed: 0, counted: False, }) for i, trk in enumerate(self.tracks): if not matched[i]: trk[missed] 1 closed_count 0 still_active [] for trk in self.tracks: if trk[missed] self.max_missed: if not trk[counted]: trk[counted] True closed_count 1 else: still_active.append(trk) still_active.extend(new_tracks) self.tracks still_active self.total_count closed_count return closed_count这段代码里有两个参数需要根据实际场景调iou_threshold和max_missed_frames。果蝇爬得快、镜头帧率低时相邻帧之间同一个体的位移大IOU会变小阈值要放松到0.2左右。如果果蝇停在原地不动框的IOU会一直很高此时max_missed_frames设置太长会导致它长时间占着轨迹不闭合延迟计数结果我通常设在3到8帧之间具体看帧率。最终统计时还可以加一个ROI掩码。如果画面上有些区域压根不应该计数——比如培养瓶边缘、灯光支架——用多边形掩码把这些区域遮掉检测框落在掩码外就忽略import cv2 roi_points np.array([[10, 10], [100, 10], [100, 100], [10, 100]], dtypenp.int32) mask np.zeros((frame_h, frame_w), dtypenp.uint8) cv2.fillPoly(mask, [roi_points], 255)这个ROI掩码设置一次后能省掉后期大量的误检清洗工作。6. 完整的项目代码结构与应用层的搭建工程落地时项目结构我习惯这么组织方便分工也方便后续扩展fruitfly_counter/ ├── configs/ │ ├── fruitfly.yaml # 数据集配置 │ └── inference.yaml # 推理参数阈值、ROI等 ├── scripts/ │ ├── train.py # 训练入口 │ ├── annotate_check.py # 标注质量检查辅助工具 │ └── export_onnx.sh # 模型导出脚本 ├── detector/ │ ├── model_loader.py # 统一模型加载接口 │ └── frame_counter.py # 上面的FruitFlyCounter ├── app/ │ ├── batch_analyze.py # 离线视频批量分析 │ └── api_server.py # Flask轻量API服务 └── weights/ └── best.pt模型加载接口我封装了一下未来换成YOLOv26权重时只需要改一个配置项# detector/model_loader.py from ultralytics import YOLO import os def load_model(weights_path: str, device: str cpu): model YOLO(weights_path) model.to(device) return model def detect_frame(model, frame, conf_threshold0.35, imgsz960): results model.predict( frame, confconf_threshold, imgszimgsz, verboseFalse, ) dets [] if results and results[0].boxes is not None: for box in results[0].boxes: xywh box.xywh[0].cpu().numpy() conf float(box.conf[0]) dets.append([xywh[0], xywh[1], xywh[2], xywh[3], conf]) return dets离线批量分析脚本比较实用。输入一段视频输出总数、单位时间的数量变化曲线和每帧检测帧# app/batch_analyze.py import cv2 from detector.model_loader import load_model, detect_frame from detector.frame_counter import FruitFlyCounter def analyze_video(video_path, weights_path, video_fps25): cap cv2.VideoCapture(video_path) model load_model(weights_path) counter FruitFlyCounter(max_missed_framesvideo_fps // 5) while True: ok, frame cap.read() if not ok: break dets detect_frame(model, frame) closed counter.update(dets) cap.release() return counter.total_count实时监控API的写法也是一样只是把视频源换成摄像头或者RTSP流。部署的时候我把推理模型导出成ONNX后用OpenVINO加速在普通办公电脑的CPU上能做到单帧30毫秒以内完全满足实时需求。7. 实测过程中踩过的坑反光、闪烁与粘连的处理记录这套系统从开发到交付最耗时间的不是模型训练而是处理各种真实场景里的脏数据。我把几个典型问题记录下来大家在复现时大概率会碰到同一个。第一个坑透明容器反光造成的误检。项目刚部署时画面里的培养管有弧面反光模型把高光区域的椭圆形光斑识别成果蝇躯干误检率飙升。排查之后发现这不是模型问题是采集环境问题。解决办法是加一块白色匀光背板让背景均匀变亮反光被淹没在亮背景里同时把培养管侧壁划痕在ROI掩码里遮掉。最终误检率从35%降到了4%以下。第二个坑灯光频闪导致帧间亮度跳变。实验室用的荧光灯有频闪不同帧亮度差异很大检测框的置信度忽高忽低跟踪匹配时常断链。这个问题在排查时非常隐蔽因为肉眼看视频几乎察觉不到亮度变化但模型对亮度很敏感。解决方式是把相机曝光模式改为手动固定曝光时间和增益同时尽量使用无频闪的LED常亮光源。固定曝光之后同一目标的检测稳定性明显提高IOU跨帧匹配的成功率也上去了。第三个坑NMS把拥挤的果蝇合并掉。密集聚集时两只果蝇贴得非常近检测框高度重叠默认NMS参数会把其中一个当作重复检测去掉。我通过调低NMS的IOU阈值到0.4并检查置信度阈值不要设太高把漏检率降了下来。如果果蝇密度已经到了上百只挤在一起矩形框的检测方式本身就到了极限这时可以换一个思路用中心点的密度图回归。训练模型输出置信度热图然后对热图做局部极值检测数峰值点就是数量。这种方案在单个目标只有几个像素时比框检测更稳。第四个坑好奇心旺盛的果蝇赖在画面里不走。有些果蝇趴在诱虫灯前几分钟都不动轨迹一直不闭合计数结果迟迟不更新。这属于序列去重的边界情况。我的处理是给轨迹增加一个逗留上限如果一条轨迹连续活跃超过N帧比如5秒就强制闭合计数一次同时把目标标记为已计数。这样重复计数和延迟报告的问题一起解决了。代价是个别长时间静止的果蝇可能因为轨迹断裂被数两次但在生产环境里两害相权取其轻。这些坑给了一个重要教训检测系统的失败往往不是单点失败而是采集环境、模型、后处理三者叠加的系统性问题。遇到指标不对先排查环境和数据再动模型顺序千万别反了。8. 精度验证与扩展思路你的场景还能怎么用系统做完之后验证环节不能省。标准做法是取一段10分钟连续视频人工数出画面里出现的果蝇总数作为真值再跑系统统计。我交付时选了三段不同密度、不同光照条件的视频做验证结果表明中等密度场景下计数误差能控制在8%以内低密度场景控制在5%以内。这个精度在生物实验和农业监测里已经够用。这套架构的复用性其实很强。把数据标注换成另一个昆虫类别、把计数逻辑聚焦点换一个物种整体管线就能平移。比如农业上常见的蚜虫、粉虱、蓟马监测它们同样是小目标、高密度、连续动态核心问题和果蝇几乎一样。甚至培养基上的菌落计数、细胞培养板的孔内沉淀计数逻辑也能复用。后续可以扩展的方向一个是把多视角摄像头对准同一个培养区域通过视野重叠区域的匹配融合减少因为视角遮挡造成的漏计。另一个是把检测和计数结果接入数据库形成长期趋势报表用于果蝇种群动态研究或者农药效力评估。这些都是建立在稳定计数基础上的上层应用基础稳了上层随便盖。最后分享一个小技巧做这类计数系统时永远留一个人工复核的出口。不管后处理逻辑多精巧都要把目标和检测轨迹的关键帧截图存下来方便回头抽样检查。我在系统里加了一个抽查模式每次随机抽20条已经闭合的计数轨迹输出到文件夹人工扫一眼就能快速判断系统是否跑偏。这种设计在交付时特别能赢得信任——毕竟没人愿意把一个黑盒模型直接用到科研数据上。