基于YOLOv8的直肠息肉检测系统：从训练到ONNX部署与GUI实现

简介：基于YOLOv8的直肠息肉检测系统是一份可直接运行的目标检测项目，主要面向医疗影像分析、计算机视觉方向的研究者与开发者，也能帮助需要快速搭建YOLOv8检测界面的人员快速上手。项目在Windows10 + Python3.8 + PyTorch1.9环境下验证，通过Ultralytics 8.2.70完成检测，模型可识别Polyp类别，附带ONNX格式权重，便于跨平台部署与二次开发。资源共32个文件，压缩包约10.38MB，包含Python源码、ONNX模型、XML标注文件、测试图片、评估指标曲线图、GUI资源文件及说明文档，结构清晰，几乎开箱即用。还带有精美PyQt5界面，支持图片检测和结果可视化，适合学习YOLOv8工程化落地流程。已有383人学习浏览，是一份轻量但完整的息肉检测入门与参考资源。 先聊点实在的：肠镜检查视频流里，医生盯着屏幕找息肉，几十秒的快速扫查加上视野盲区，确实存在漏检风险。这类基于YOLOv8的直肠息肉检测系统要做的事，就是把目标检测模型落到桌面端，让内镜影像里疑似息肉的区域自动被框出来并给出置信度。我拿到手的这套项目，包含完整的Python源码、已经导出的ONNX模型、训练评估曲线和一套可直接运行的GUI界面，属于“模型训练 + 推理部署 + 桌面交互”全都打通的那种工程。

这套东西适合谁？一是做医学影像AI课题的学生和科研人员，需要一个能跑通全流程的参考实现；二是想快速上手YOLOv8检测落地、又不想自己从头搓界面的开发者；三是医疗软件方向的技术验证团队，拿它做预研和演示。下面我从项目结构、模型选型、部署链路到界面实现，把每个关键点拆开来聊。

1. 一个可供临床辅助筛查的完整项目：从内镜影像到检测结果

1.1 医学场景为什么需要检测模型“打辅助”

肠道息肉是结直肠癌的重要前兆，早期发现并切除可以显著降低癌变风险。但在真实内镜检查里，肠道褶皱多、光线不均匀、息肉大小差异极大，再加上检查时间长、医生注意力下降，小尺寸息肉的漏检问题一直存在。计算机辅助检测的作用不是替代医生，而是在视频流里用方框标注出“这里可能有息肉，请重点关注”，相当于给医生多了一双永不疲劳的眼睛。

这种需求决定了技术选型方向：必须能做实时目标检测，推理速度要跟上视频帧率；模型对小目标要敏感，因为早期息肉往往只有几个像素大小；同时系统需要可视化界面，毕竟最终使用者是内镜医生，不是程序员，没人会对着命令行敲检测命令。

1.2 项目结构与交付物盘点

这个zip解压之后，核心交付物分四块：Python源码、ONNX模型文件、评估指标曲线、GUI界面。我建议拿到手先按下面这个清单梳理一遍，避免遗漏关键文件和目录。

这套结构的合理性在于：pt文件负责训练与调优，onnx文件负责跨平台部署，GUI只依赖onnx模型，不依赖训练环境。换句话说，就算一个没有GPU的普通电脑，只要装了Python环境和onnxruntime库，也能独立跑起完整的检测界面，这种“训练-部署分离”的思路值得借鉴。

2. YOLOv8选型逻辑与训练路径拆解

2.1 YOLOv8在设计上到底改了什么

选YOLOv8而不是Faster R-CNN或SSD，核心原因是它在精度和速度的平衡上做得非常极致。Ultralytics团队延续了YOLO系列的单阶段检测思想，在v8版本里做了三处关键调整。

第一处是C2f结构取代了v5的C3结构。C2f在特征提取阶段增加了更多的梯度流分支，让浅层和深层特征的信息交互更充分，对尺度变化明显的目标更友好——这对尺寸跨度大的息肉检测意义重大。第二处是Anchor-Free检测头，模型直接预测目标中心点和宽高，省去了锚框聚类的步骤，泛化能力更强。第三处是解耦检测头（Decoupled Head），分类和回归分支各自独立，避免两个任务互相干扰，收敛速度更快，最终精度也更高。

最后还有一个常被忽略的细节：TaskAlignedAssigner正负样本分配策略。它不再只看IoU，而是把分类得分和定位质量联合起来，挑选对齐程度高的样本作为正样本。这个策略让小目标更容易被分配到学习机会，对微小息肉的训练尤为重要。

2.2 数据集准备与标注规范：质量比数量更重要

训练这套系统，数据集结构直接影响检测效果。标准做法是准备两个目录：images放原始内镜图像，labels放对应的YOLO格式txt标注文件。txt每行格式为：

类别id 中心点x归一化坐标 中心点y归一化坐标 归一化宽度 归一化高度

比如一张640×480的图像里，一个息肉边界框左上角为(160, 120)、右下角为(320, 240)，那么归一化后应该写成：

0 0.375 0.375 0.25 0.25

数据层面有三个坑必须避开。第一个是样本不均衡，单发性和多发性息肉的图都要有，阴性帧（无息肉的正常肠镜画面）也要有一定比例，否则模型会产生很高的误报。第二个是小目标占比，如果数据集里所有息肉都很大，模型对小息肉的召回率会很难看，建议小尺寸目标图片占比不低于30%。第三个是标注一致性，不同标注员对“息肉边缘”的理解可能不同，最好在标注前制定统一规则，比如边界框必须贴合黏膜边界而不是炎症发红区域。

2.3 训练参数与训练策略

基于ultralytics库训练，命令非常简洁，但参数设计需要根据医疗图像特点调整。

yolo detect train \ --model yolov8s.pt \ --data data.yaml \ --epochs 200 \ --imgsz 640 \ --batch 16 \ --patience 30 \ --device 0

这里有几个关键参数值得展开。imgsz我建议不低于640。息肉尺寸相对于整个画面往往很小，输入分辨率太低会让小目标特征在降采样后彻底消失；如果显存允许，可以尝试768甚至1024。batch size在显存允许范围内尽可能大，小batch会导致BN层统计不稳定，医疗图像又普遍存在光照差异，BN不稳定会让模型很难收敛。patience设30，超过30个epoch验证集指标没有提升就提前停止，省时间也能防止过拟合。

另外建议打开Mosaic数据增强。它把4张图拼在一起训练，强迫模型学会在复杂背景下定位目标，对提高息肉与黏膜纹理的区分能力有明显帮助。到了训练后期，ultralytics会自动降低mosaic概率，让模型在真实分布上做微调。

3. 从PyTorch权重到ONNX模型：部署形态转化的关键一步

3.1 为什么一定要转ONNX

很多新手会问：我直接用best.pt在Python里跑推理不就行了，为什么还要折腾ONNX？答案在于部署环境的高度不确定。

PyTorch模型必须在安装了PyTorch、CUDA等一堆依赖的Python环境里才能推理，版本一旦不对就报错。而ONNX（Open Neural Network Exchange）是开放神经网络交换格式，把模型结构固化成一张静态计算图，任何支持ONNX的推理引擎都能加载运行。ONNX Runtime不仅在CPU上做了大量算子融合优化，通用性也强很多，C++、C#、Java都能调用同一个onnx文件，甚至能直接部署到移动端或边缘设备。内镜工作站环境往往很封闭，是典型的“能跑通就算赢”的场景，ONNX这种轻量中性格式优势非常明显。

3.2 pt转onnx的导出流程与参数细节

使用ultralytics框架可以直接在Python里导出：

from ultralytics import YOLO model = YOLO("best.pt") model.export(format="onnx", opset=12, imgsz=640, simplify=True)

simplify=True很关键，它会调用onnx-simplifier对计算图做常量折叠和冗余消除，裁剪掉大量不需要的算子。导出的onnx模型体积通常会比pt小30%左右，推理速度也会提升。opset表示ONNX算子集版本，我习惯用12，这个版本兼容性好，太高的opset在旧版推理引擎上可能报“Unsupported Operator”错误。

导出后我强烈建议先用onnxruntime加载验证一遍输出，不要直接丢给GUI。验证方法很简单：

import onnxruntime as ort import numpy as np sess = ort.InferenceSession("best.onnx") input_name = sess.get_inputs()[0].name # 模型输入是 [1, 3, 640, 640] 的归一化图像 fake_input = np.random.rand(1, 3, 640, 640).astype(np.float32) outputs = sess.run(None, {input_name: fake_input}) print([o.shape for o in outputs])

正常情况应该输出两个数组：一个形状是[1, 84, 8400]的检测头输出，84代表4个坐标加80个类别分数；另一个是[1, 6, 8400]的最终检测结果（x1, y1, x2, y2, conf, class）。如果形状对得上，说明模型转换成功。

3.3 ONNX Runtime推理的完整代码思路

GUI界面里的推理函数，核心逻辑可以用下面这段概括：

import cv2 import numpy as np import onnxruntime as ort class PolypDetector: def __init__(self, model_path="best.onnx", conf_thres=0.35, iou_thres=0.5): self.session = ort.InferenceSession(model_path) self.input_name = self.session.get_inputs()[0].name self.conf_thres = conf_thres self.iou_thres = iou_thres def preprocess(self, frame): img = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) img = cv2.resize(img, (640, 640)) img = img.astype(np.float32) / 255.0 img = np.transpose(img, (2, 0, 1)) return np.expand_dims(img, axis=0) def postprocess(self, output, orig_shape): # output shape: [1, 6, 8400] preds = output[0].T # [8400, 6] boxes = preds[preds[:, 4] >= self.conf_thres] if len(boxes) == 0: return [] # 坐标从640分辨率映射回原图 scale_x = orig_shape[1] / 640 scale_y = orig_shape[0] / 640 results = [] for x1, y1, x2, y2, conf, cls in boxes: results.append(( int(x1 * scale_x), int(y1 * scale_y), int(x2 * scale_x), int(y2 * scale_y), float(conf), int(cls) )) return results

这里有个实战要点：ONNX导出时NMS是非极大值抑制的一部分还是留在外面，不同导出方式结果不同。ultralytics默认把NMS放在模型外，也就是说ONNX输出的是所有候选框，后处理里需要自己做一次NMS筛选。上面的代码简化了NMS步骤，实际工程中建议用cv2.dnn.NMSBoxes或实现标准IoU抑制，否则一个息肉可能被框好几遍。

3.4 硬件加速与量化

ONNX Runtime在CPU上跑yolov8s，640分辨率大约每帧50-100ms，勉强能到10-15FPS，对静态图片检测和慢速视频分析够用，但离流畅视频检测还有差距。想提速有两个方向。

第一个方向是ONNX Runtime扩展，比如基于OpenVINO的ExecutionProvider，在Intel CPU上推理速度能快2-4倍。另一个方向是INT8量化，将权重从FP32压到INT8，模型体积缩小为四分之一，推理速度提升明显，但精度会有1-3%的下降，医疗场景需要谨慎评估。

import onnxruntime as ort providers = ['OpenVINOExecutionProvider', 'CPUExecutionProvider'] sess = ort.InferenceSession("best.onnx", providers=providers)

4. GUI界面：检测系统能不能落地的最后一公里

4.1 界面框架选型：PySide6还是PyQt5

这套项目GUI通常基于PySide6或PyQt5开发，两者同源，都是Qt的Python绑定。我的建议是优先PySide6，因为它的LGPL许可证对商业闭源更友好，且官方持续维护，API风格和PyQt5基本一致，遇到问题搜索引擎都能找到答案。如果运行环境是老系统，Python版本较低，才退而选择PyQt5。

4.2 界面布局与核心功能模块

一个合格的医学辅助检测GUI，最少要包含以下几块区域：

• 图像/视频显示区：居中大画布，实时显示原始帧和带检测框的结果
• 文件操作区：打开单张图片、打开视频文件、打开摄像头
• 参数控制区：置信度阈值滑块、IoU阈值滑块
• 统计信息区：当前帧检测到几个目标、平均置信度、推理耗时
• 结果导出区：保存当前帧、导出检测报告

界面布局参考医院工作站习惯，深色背景降低光线干扰，检测框用亮绿色（绿色在医疗场景中代表安全/提示），文字信息放右侧面板，避免遮挡影响视野。置信度滑块默认值设在0.35比较合适，过低会满屏误报，过高会漏检小息肉。

4.3 避免界面卡死的多线程方案

新手最容易踩的坑就是把推理放到GUI主线程里直接跑。视频流检测一帧要几十毫秒，加上图像缩放、绘制，主线程卡住之后窗口拖拽、按钮点击全部失去响应，体验非常差。正确做法是开两个线程：

• 工作线程：负责读取视频帧、调用ONNX推理、返回检测结果
• 主线程：只负责显示结果和处理用户交互

两个线程之间用QtSignal通信，工作线程把绘制好的QImage信号发到主线程。这里有个细节：不要在信号里传大于几MB的原始帧数据，而是先在工作线程里把检测框绘制到图像上，再只传这个最终的QImage，避免主线程还要做耗时绘制。

from PySide6.QtCore import QThread, Signal from PySide6.QtGui import QImage class DetectThread(QThread): frame_ready = Signal(QImage) def run(self): while self.running: ret, frame = self.cap.read() if not ret: break results = self.detector.detect(frame) annotated = self.draw_boxes(frame, results) rgb_image = cv2.cvtColor(annotated, cv2.COLOR_BGR2RGB) h, w, ch = rgb_image.shape qimg = QImage(rgb_image.data, w, h, ch * w, QImage.Format_RGB888) self.frame_ready.emit(qimg.copy())

4.4 GUI与模型的解耦设计

这个项目在架构上有个值得借鉴的地方：界面逻辑和检测逻辑完全解耦。界面只管文件选择、线程调度、显示结果；检测逻辑全是独立的PolypDetector类，输入帧输出坐标。这意味着想换模型，只需改加载的onnx路径，其他代码一律不动；想让界面适配TensorRT加速，也只用改DetectThread内部实现。这种“界面-推理”分离的分层设计，是做任何带界面的AI工具都该坚持的工程习惯。

5. 评估指标曲线解读：mAP不是一切，更不能只看一张loss图

5.1 训练过程中的loss曲线

项目里附带的结果图results.png，通常包含box_loss、cls_loss、dfl_loss三条下降曲线，以及precision、recall、mAP50、mAP50-95四条指标曲线。看loss曲线不能只盯着“降没降”，要关注三点。

第一点是下降趋势是否平滑。如果曲线剧烈震荡，大概率是学习率太大或batch太小；如果平稳下降后突然反弹，可能是学习率没有正确衰减。第二点是验证集loss和训练集loss的差距。两条线贴很近说明没有严重过拟合；验证集loss开始上升而训练集loss继续下降，说明模型开始“背题”了，该提前终止。第三点是收敛时验证集loss是否稳定在一个低水平，这决定了后续调参的基准。

5.2 PR曲线与召回率细节

PR曲线反映模型在不同置信度阈值下精确率（precision）和召回率（recall）的权衡，曲线越靠近右上角越好。曲线下的面积AP越接近1，说明模型在“准”和“全”之间平衡得越好。

对息肉检测来说，我个人的观点是优先保召回率。漏掉一个息肉比多标一个可疑区域风险更高，因为多标还能靠医生复核排除，漏检却可能直接造成病变漏诊。所以在调阈值时，如果PR曲线上召回率能维持在0.9以上、精确率在0.7左右，我会认为可接受。

5.3 混淆矩阵是找到“翻车原因”的关键

results.png里还有混淆矩阵confusion_matrix.png。它把真实类别和预测类别交叉统计，对角线数值表示正确分类的比例。看这个图重点看两类错误：一是息肉被预测为背景，代表漏检，需要检查是否小目标太多或光照复杂；二是背景被预测为息肉，代表误报，需要补充更多阴性样本进训练集。

混淆矩阵能直观告诉你“错在哪”，这是它比mAP更有价值的地方。mAP是一个综合分数，但你不知道问题出在哪；混淆矩阵是诊断报告，直接指出病灶位置。

5.4 部署前还需要额外验证的指标

模型训练报告里的mAP和临床实际部署之间还有一段距离，部署前建议补充测试：

• 单帧CPU推理耗时：内镜工作站通常没有独立GPU，CPU延迟必须实测
• 误报率（FPR）：对一段无息肉的正常内镜视频做测试，统计误检帧占比，目标是低于10%
• 小目标单独统计：单独计算尺寸小于32×32像素的息肉的召回率，如果远低于总体召回率，需要调整输入分辨率

6. 实测中的坑与改进思路

6.1 坑一：ONNX输出解析位置搞错

我第一次用ONNX推理时，以为是输出就是一个5元组坐标，结果跑出来一堆无效框。细查才发现输出格式是[1, 6, 8400]，不是常规的[8400, 6]，需要转置才能按行读取。另外坐标是相对于640×640输入分辨率做归一化的，必须乘回原图宽高比。这种张量形状和坐标系转换的错误，用onnxruntime的outputs[0].shape先打印出来比对，能少走很多弯路。

6.2 坑二：GUI拖动窗口时推理直接卡死

这个问题我排查了很久，表面症状是“窗口拖一下画面就冻结”，实际原因是视频读取循环里没有做帧率控制，读取速度远大于推理速度，待处理帧越堆越多，界面自然卡死。解决办法是在工作线程里加一个简单的帧间隔限制，比如每次处理完一帧后time.sleep(0.03)，把处理帧率控制在30FPS以内。还有一个更优雅的方案是用双缓冲队列，队列满了就丢弃最旧帧，保证永远处理的是最新画面。

6.3 坑三：数据集类别不均衡导致“全报背景”

如果你的训练数据里阳性息肉样本很少，而背景负样本很多，模型会倾向于把一切预测为背景来压低loss，最终结果就是什么也检测不到。解决思路有两个：一是做数据重采样，让正负样本比例不超过1:2；二是使用focal loss之类的困难样本挖掘损失函数，让模型更关注那些被分错的少数类样本。在ultralytics里，可以通过修改配置文件中的loss参数或自定义损失函数实现。

6.4 进一步优化的方向

这套系统已经能跑通全流程，但距离真正入院使用还有一些改进空间。一是视频时序平滑：单独一帧的漏检可以通过相邻帧的检测结果做投票修正，减少单帧抖动带来的闪烁框。二是多尺度融合：息肉大小差异极大，可以尝试用P2层特征或更大输入分辨率，提高微小息肉的检测率。三是结合分割模型：检测框只能给出位置，如果能配合息肉分割模型给出边缘轮廓，能帮助医生更准确判断息肉形态。四是模型的持续迭代：随着医院内镜病例累积，定期用新数据微调模型，检测能力才会逐步提高。

从拿到这个zip到真正跑起来，一个下午基本够用。先把环境搭好，装好ultralytics、onnxruntime、PySide6，然后按“训练脚本重训或直接用onnx推理 -> 用detect.py验证单张图检测 -> 启动gui_main.py加载模型”，三步就能看到完整的检测效果。在验证过程中最值得注意的，是确认onnx模型后处理输出的坐标换算和线程模型的帧率控制，这两处是项目跑通后最容易出问题的地方。后面再想深入，就往模型轻量化、数据扩充和实时性优化的方向走，这套代码已经给了很好的起点。

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