深度学习舌苔检测系统实战：从数据预处理到YOLOv8+ResNet落地

简介：该资源为一套完整的深度学习舌苔检测系统项目，主要面向计算机视觉方向的高校学生与科研人员，适用于人工智能、电子信息、自动化等专业的毕业设计或课程设计场景。项目以Python为主要开发语言，集成PyTorch训练与推理链路，核心任务是利用卷积神经网络对舌苔图像进行识别与分类，具备从数据预处理、模型训练到可视化界面的完整流程。压缩包共110个文件，包括26个Python源码文件、6个pth模型权重文件、5个json配置、2个ui界面文档，以及论文、开题报告等docx文档，总体积约105.46MB；训练图像与TensorFlow事件记录文件同步提供，便于研究训练过程与模型调优。当前已有71人学习下载，适合需要参考完整项目方案、撰写论文或快速搭建检测原型的读者使用，可直接在现有代码基础上修改扩展。

1. 收到“深度学习舌苔检测系统（含开题报告+论文）.zip”，先别急着跑，先看它值不值得复现

每年论文季，总有人手里捏着这样一个压缩包：深度学习舌苔检测系统（含开题报告+论文）.zip。它既不是拿来就能跑的“一键项目”，也不是纯粹的“交差作品”。舌苔检测这个方向，在中医信息化和基于深度学习的口腔疾病图像识别系统里，是典型的“医生看着费眼、标注又贵、模型却意外好骗”的场景。传统中医舌诊靠医生肉眼看苔色、苔质，主观且难量化；而用深度学习模型把舌体从照片里框出来，再对舌苔颜色分类，是能写满一篇论文、也能真落成演示系统的闭环项目。适合谁？视觉方向做毕设的学生，以及想验证目标检测加图像分类双任务在医疗图像上跑不跑得通的一线工程师。这个包好不好，不在于代码里贴了多少层卷积，而在于你能否把它变成一份能讲清“为什么这么设计、怎么调、怎么反驳答辩老师”的实证。

2. 数据与预处理是决定成败的上游工程：舌象数据集如何切、裁、增强

拿到这种项目的第一件事不是打开模型代码，而是先整理数据。这块做不好，后面所有训练结果都是空中楼阁。

2.1 舌苔图像的三个脏数据来源：光照、舌体区域切片、标注噪声

先看数据从哪来。常见做法是老师给一台相机，去门诊拍几百张舌头照片；或者从开放数据集找一部分，每张图有人手工用矩形框标注过舌体。这两种来源各有各的问题。

第一类脏数据是光照。门诊拍摄环境不像实验室可控，有的照片在口腔灯直射下拍，舌面出现大片高光，高光区域的颜色完全发白。如果这些图片落在训练集里，深度学习模型会把“亮斑”和“白苔”学在一起，等推理时遇到真实白苔，反而因为缺少高光而犹豫。这就是模型被脏数据欺骗的最直接解释。

第二类是舌体区域切片。常见做法是先用目标检测把舌体框出来，再裁剪，把裁剪结果交给分类网络。这一步最怕框歪：框往上偏一点，图中就多出一排牙齿；往下偏一点，就会带上嘴唇阴影。分类网络并不具备“自动忽略背景”的能力，它会抓取牙齿的白色纹理当特征，而测试集里一旦出现露齿样本，分类结果就跟着崩。

第三类是标注噪声。舌苔分类的标签本来就主观：黄苔和白苔的分界线不是几何边界，医生不同、标准不同，标签就会抖。一个黄苔和灰苔都沾边的小样本被标成某一类，模型被迫在这个样本上死记硬背，这会让它在真实数据上复现错误的判断。预处理不能消除标注噪声，但可以在增强阶段用较低的颜色扰动守住边界，不让噪声被进一步放大。

一句话结论：预处理阶段决定这个系统能不能跑过答辩，模型结构反而不是最危险的一环。

2.2 用albumentations做数据增强的最小可运行配置

以分类任务为例，先把增强管线搭起来。下面这套配置是小数据集上最常用的一套，每一行都踩过坑。

import albumentations as A import cv2 # 适用于舌苔分类任务的最小增强集 train_transform = A.Compose([ A.HorizontalFlip(p=0.5), # 舌体近似左右对称，可安全翻转 A.Rotate(limit=15, p=0.6), # 小幅旋转，模拟采集时头部轻微歪斜 A.ColorJitter( brightness=0.15, contrast=0.15, saturation=0.15, p=0.5 ), A.RandomBrightnessContrast( brightness_limit=0.1, contrast_limit=0.1, p=0.5 ), A.Resize(height=224, width=224) ]) # 验证集只做Resize，不做任何随机增强 valid_transform = A.Compose([ A.Resize(height=224, width=224) ])

逻辑说明：这套管线把几何扰动和颜色扰动分开控制。Rotate的limit只给到15度，因为舌体被裁出来之后，旋转超过15度就会把舌尖旋出画面，裁剪区域混入嘴唇或牙齿；HorizontalFlip对舌体是安全操作，但前提是样本里没有明显的“舌尖朝左”和“舌尖朝右”的语义区别，否则不建议开。ColorJitter的saturation控制在0.15以内，舌苔分类极度依赖颜色，黄苔和白苔的差距核心就在色相，饱和度或亮度抖动过狠，会让黄苔样本在增强后变成白苔样本，这种自我矛盾的数据比不增强更危险。

参数说明：p是概率不是幅度。0.5的概率意味着批量训练时约一半样本不做该变换，另一半做，这个比例能防止整个batch的分布被过度平滑。RandomBrightnessContrast的brightness_limit=0.1比ColorJitter的0.15更保守，原因是舌苔图像的高光区域在亮度增强后会产生假白斑。另外，不要在增强管线里加GaussianBlur或GaussianNoise，舌苔纹理本来就弱，一旦模糊，厚苔和薄苔的分界会彻底消失，模型只能靠颜色猜。

提示：训练集和验证集必须走不同管线。验证集只做Resize，随机增强一旦落到验证集上，验证准确率会上下乱跳，你无法判断是模型在进步还是数据在干扰。

另一个常见做法是把舌体从矩形框里再抠成圆形，只保留舌面中央区域，丢掉四周的唇齿阴影。这个方法确实能提升分类准确率，但代价是引入新的切割误差：圆形掩码的边缘一旦切到舌根，厚苔区域会被切掉一半，分类结果反而失真。我一般保留矩形框，只在预处理里把图像四周等比裁掉5%，再缩放到224。这个方案实现简单，也不引入新的误差源，作为深度学习实战项目案例来说，性价比最高。

2.3 按类别切分数据集：固定随机种子与类别均衡参数

拿到数据之后第一件事不是建模，是切分。舌苔数据集的类别不均衡往往很严重：白苔样本常是黄苔的5到8倍，灰苔和厚苔的数量更少。如果全局随机切分，稀有类别可能整个掉进训练集或验证集，验证指标的波动会大得让对比实验没法看。

import random import shutil from pathlib import Path random.seed(42) # 固定随机种子，保证论文实验可复现 src = Path("data/tongue_all") train_dir = Path("data/train") valid_dir = Path("data/valid") for cls in ["white", "yellow", "gray", "thick", "thin"]: images = list((src / cls).glob("*.jpg")) random.shuffle(images) valid_size = int(len(images) * 0.2) valid = images[:valid_size] train = images[valid_size:] (train_dir / cls).mkdir(parents=True, exist_ok=True) (valid_dir / cls).mkdir(parents=True, exist_ok=True) for img in train: shutil.copy(img, train_dir / cls / img.name) for img in valid: shutil.copy(img, valid_dir / cls / img.name)

逻辑说明：这个脚本的核心是“按类别分层切分”，而不是对整个文件夹一次性shuffle。以白苔和黄苔为例：白苔300张、黄苔40张，全局切分后验证集可能出现白苔60张、黄苔8张，黄苔类别统计上的置信区间极大；分层切分后至少保证每个类别都按同比例进验证集，比例虽然仍不均衡，但分布与训练集一致。

参数说明：random.seed(42)是复现实验的第一步，论文里写“数据集以固定随机种子按8:2分层切分”，他人就能还原你的划分。0.2的验证比例对医疗小数据集属于保守值，如果总数只有300张，建议换成5折交叉验证，而不是把验证比例降到0.1。交叉验证时同样要按类别分层，否则每一折的类别比例都不一致，五折的均值会非常不稳定。

跑这些脚本前，先把深度学习环境配置好：用Miniconda建虚拟环境，Python 3.8以上，pip install albumentations opencv-python torch torchvision。CPU也能完成增强和预处理，并不依赖GPU。如果是租用服务器跑深度学习，记得把数据集和代码放在同一块数据盘上，避免训练时反复跨节点读写图像文件。

从预处理进入模型之前，先对切分后的图像做一次人工巡检：随机抽50张训练图和20张验证图，用matplotlib拼成网格，看看有没有切错类别、有没有带着牙齿、有没有全图高光。这一遍巡检花不了半小时，但能避免后边训练出来的模型解释不清为什么对某张图判断错误。

3. 用YOLOv8搭检出、ResNet管分类：两阶段方案与训练脚本

数据管干净之后，才轮到模型选型。这里最常见的落地方案是两阶段流水线：先用YOLOv8把舌体框出来，再把裁剪区域交给ResNet分类。

3.1 先检出舌体再分舌苔：两阶段方案为什么比端到端稳

舌苔检测系统有两个任务：把舌体从照片里框出来，给框出来的舌面分类。把两个任务串成一条流水线，落地最稳。

为什么不用端到端分类？直接让分类网络看整张图，模型不知道应该看舌头哪个部位。牙齿的釉白和舌苔的白在图像上都是“白色高纹理区域”，分类网络会把牙齿统计进“白苔支持区”；嘴唇的红色区域则会干扰黄苔判断。两阶段方案把定位和分类解耦：检测模型负责把舌头从背景里拆出来，分类模型只学舌头上的纹理和颜色，背景干扰被裁剪环节挡掉。

为什么不用单阶段检测直接输出类别？比如把苔色类别直接加进YOLO的class列表，一个框同时给出位置和苔色。因为工程上数据不平衡问题会被放大。YOLO的损失函数在一个batch里平衡分类损失和定位损失，舌苔类别严重不均衡时，模型更倾向于把稀有类别忽略，边界框回归得再准也没用。两阶段方案允许单独为分类阶段做类别重采样和loss加权，处理不均衡的手段多得多。

下表是选型时的对比视角：

答辩时，评审老师大概率会问“为什么不直接检测分类一步到位”，上面这张表就是答辩底稿。两阶段看着多绕一层，但每一级的错误来源都可解释，这对医疗场景非常重要。

3.2 用预训练权重微调的命令与关键超参

检测阶段用YOLOv8做微调，因为它的生态最省事。先写一个舌体检测的数据配置，再给训练命令。

# tongue_detect.yaml path: dataset/tongue_detect train: images/train val: images/valid names: 0: tongue

yolo detect train \ model=yolov8n.pt \ data=tongue_detect.yaml \ imgsz=640 \ epochs=80 \ batch=16 \ lr0=0.005 \ optimizer=AdamW \ project=runs/ \ name=tongue_yolov8

逻辑说明：这里选了yolov8n的预训练权重，n是nano版本，参数量最小。舌体在照片里占的面积很大，检测本身的难度不高，nano级别的模型容量足够，换s或m版本只会让训练时间翻倍，边际收益很小。imgsz=640是通行默认值，舌体检测不必用1280大图，边缘模糊的舌体区域不需要太精细的边界。lr0=0.005对微调目标检测属于温和值，预训练权重里的特征不会被快速破坏。如果训练集只有几百张，把epochs降到50到60，再配一个早停patience=10到15，防止在验证集上过拟合。

参数说明：batch=16在8G显存下配合imgsz=640刚好压线；显存不够时优先降imgsz到512，而不是降batch，低batch会让BN层的统计噪声变大，训练不稳定。AdamW比SGD在检测任务上收敛快，配合余弦学习率衰减，后半段用小学习率微调网络细节。另一个容易被忽略的是model=yolov8n.pt这个文件会在第一次训练时自动下载，如果服务器连不上官方源，提前在本地把权重下载好放进项目目录，避免训练跑到一半因为网络问题挂掉。

分类阶段用ResNet18微调，脚本如下：

import torch import torch.nn as nn from torchvision import models device = torch.device("cuda" if torch.cuda.is_available() else "cpu") # 5类舌苔分类：white, yellow, gray, thick, thin model = models.resnet18(pretrained=True) model.fc = nn.Linear(512, 5) model = model.to(device) cls_counts = torch.tensor([320.0, 60.0, 40.0, 120.0, 100.0]) class_weights = 1.0 / cls_counts class_weights = class_weights / class_weights.sum() # 归一化到和为1 criterion = nn.CrossEntropyLoss(weight=class_weights) optimizer = torch.optim.AdamW( model.parameters(), lr=1e-4, weight_decay=1e-5 )

逻辑说明：先把ResNet18最后一层的全连接层从1000类换成5类，输出维度对应五个苔质类别。然后设置类别权重，做法是“反向频率”：样本数多的白苔权重低，样本数少的灰苔权重高。CrossEntropyLoss拿到weight参数后，计算损失时会给稀有类别更大的梯度，让模型不直接忽略它。但要注意，类别权重不会凭空造出信息，如果灰苔总共只有40张且存在标注噪声，模型大概率仍会把它学成一个“胆小”的类别，推理时置信度普遍偏低。这种情况要回去补数据，而不是继续加权重。

参数说明：AdamW的lr=1e-4搭配weight_decay=1e-5属于分类任务微调的常用区间；学习率再调高，预训练特征很快被打乱。常见的训练策略是先冻结backbone只训fc层10个epoch，让新的分类头先收敛，第11个epoch解冻backbone，把整体学习率下调到1e-5继续。冻结backbone的写法是把model.requires_grad_(False)，再把model.fc.parameters()设为requires_grad=True。

保存权重时不要看准确率，要看验证集macro-F1：

best_f1 = 0.0 for epoch in range(100): train_one_epoch(model, train_loader, criterion, optimizer) val_loss, val_f1 = evaluate(model, valid_loader, criterion) if val_f1 > best_f1: best_f1 = val_f1 torch.save(model.state_dict(), "best_resnet18.pt") if epoch >= 20 and val_f1 < best_f1 - 0.05: print("early stop") break

逻辑说明：以验证集macro-F1而不是准确率作为保存权重的依据，是因为类别不均衡下准确率会骗人。f1是精确率和召回率的调和平均，稀有类别被忽略时，macro-F1会立刻掉下来。早停条件是连续多个epoch里F1没有创新高，这个触发时机要等训练至少跑完20个epoch再做判断，避免前几个epoch的随机波动触发误停。

3.3 开题报告和论文里最值钱的三个图：loss曲线、混淆矩阵、PR曲线

这个压缩包里既然带开题报告和论文，那写报告就是硬需求。论文里最值钱的三张图，不是网络结构图，而是这三张。

第一张是训练集和验证集的loss曲线。横轴epoch，纵轴loss，训练loss持续下降但验证loss在第30个epoch后反弹，这就是过拟合的可视化证据。论文里写“采用早停策略，最终选择在第28个epoch保存权重”，配合曲线图就非常有说服力。

第二张是混淆矩阵。它比准确率能多讲太多东西：白苔和黄苔互相混淆，说明颜色边界模糊；灰苔经常被分成厚苔，说明分类模型把“颜色暗”和“厚度大”两个特征学混了。答辩时能指着混淆矩阵说“这两个类别的误差主要来自标注边界而不是模型结构”，评审老师就明白你真正分析过数据。

第三张是PR曲线，尤其当验证集类别不均衡时。白苔样本多，准确率自然高，PR曲线能展示稀有类别在低置信度阈值下到底有多少误检。开题报告里写“在灰苔类别上mAP@0.5达到0.72”，比写“总体准确率93%”更经得起追问。

至于深度学习对比试验怎么做，这是毕设里最常见的疑问。做法是控制成一个变量：baseline用直接对原图做分类的ResNet，实验组用“YOLOv8检测裁剪+ResNet分类”，第三组是“YOLOv8检测但只resize不裁剪”，用来验证裁剪的作用。三组实验用完全一样的切分方式、随机种子、epoch数和batch，任何超参都不要动。跑完放一张表格，列准确率、macro-F1和单张推理时间，对比试验这部分就稳了。

4. 避坑：训练舌苔检测模型时绕过这五个坑，能省两周时间

4.1 过拟合：loss降了、验证集准确率卡在60%不动

现象：训练集loss一路降到0.05，训练集准确率到98%；验证集loss在第25个epoch开始反弹，准确率卡在60%附近不动。

原因：舌苔数据集太小，模型容量相对过剩。ResNet18在小数据集上很容易把白苔样本的“光泽”直接记住，而不是学习“苔色”这种真正稳定的特征。

解决：先冻结backbone只训fc层，观察验证集准确率是否能上到80%以上；能上说明特征提取没问题，继续解冻微调；上不去就要怀疑标签噪声太大。再配合增强管线降低过拟合，把Rotate的p从0.6提高到0.8，并且添加RandomGamma的gamma_limit=(80,120)，模拟不同曝光。还是压不住，就换更小的模型，换成MobileNetV3-Small比换成ResNet34更合理，后者只会加重过拟合。看到验证loss反弹时，先拉出每个epoch的完整日志看一眼：如果训练loss仍在下滑而验证loss反弹，说明模型在死记训练集；如果验证loss从第5个epoch就开始震荡不降，那是学习率偏大或标签噪声太重，和过拟合无关。

4.2 类别不均衡：模型把整张验证集全猜成白苔

现象：训练完成后，验证集准确率显示75%，但打开混淆矩阵一看，黄苔、灰苔、厚苔所在行的召回率接近0，模型几乎把所有样本都预测成白苔。

原因：准确率在这里是“骗人”的指标。白苔占比本来就高，全猜白苔也能拿70%以上准确率。损失函数没有对稀有类别做任何补偿。

解决：用class_weights反向频率加权重训分类模型；另一个立竿见影的做法是过采样，把黄苔和灰苔的样本在训练集里复制两到三份，配合light增强让重复样本不完全相同。注意过采样只能在训练集做，验证集必须保持原始分布，否则验证指标会虚高。额外提醒：过采样后的数据要打乱顺序再送进DataLoader，否则同一个样本会连续出现多次，造成batch内分布单一，BN层统计被带偏。

4.3 光照伪影：暗光样本把“黄苔”识别成“灰苔”

现象：训练时验证集指标还过得去，一到部署现场，换了一个采集设备，拍出来的照片偏暗偏黄，模型的黄苔、灰苔输出置信度开始乱跳，甚至把正常舌苔预测成灰苔。

原因：训练集来自固定门诊环境，模型学到的颜色统计是“这台相机下的”。新设备的白平衡、曝光曲线完全不一样，颜色分布整体移位。

解决：部署前做一次色彩归一化，用标准色卡校正，或者直接在训练阶段把ColorJitter的brightness范围从0.15扩大到0.25，并加RandomGamma模拟不同相机的gamma曲线。如果条件允许，用目标设备拍50张真实样本加入训练集做微调，这是治本的方法。实际场景换个设备就翻车，原因就是数据域没有对齐，这类问题靠调模型结构是解决不了的。

4.4 旋转增强时只转了图没转标注框，训练直接崩掉

现象：用YOLOv8做检测训练，loss曲线在某个epoch后突然跳升，或者训练loss一直降不下去，上下震荡。

原因：训练前用自定义脚本把图像旋转了，但bounding box没有同步旋转。旋转后的框和舌头位置不对齐，检测模型一直在学一个“盒子”和“图形”对不上的错误对应关系。

解决：检测任务不要手写增强，直接用ultralytics内置的增强管线，或者用albumentations的BboxParams同步变换。写法是：

import albumentations as A transform = A.Compose( [A.Rotate(limit=15, p=0.6)], bbox_params=A.BboxParams(format="yolo", label_fields=["class_labels"]) )

逻辑说明：加上bbox_params之后，旋转图像时标注框会跟着旋转，并自动做越界裁剪。旋转增强后要检查有没有框被裁出图外，albumentations会把完全出界的框标记为None，这批样本要丢弃，不能带着空标签进模型。训练前用可视化脚本把增强后的图和框画出来，逐张看一编，能挡掉大半这类无语的bug。

4.5 推理环境不匹配：CPU上跑一张图要等10秒

现象：训练用的服务器是GPU，模型跑起来很流畅，换到现场的笔记本或CPU服务器上，一张640乘640的图推理时间超过10秒，根本没法做演示。

原因：训练时为了指标选了YOLOv8s或m版本，这些模型在CPU上没有优化，卷积计算量大，推理慢。

解决：演示环境用yolov8n配合imgsz=512，推理时间通常能降一半以上。再把模型导出为ONNX格式并用onnxruntime推理，CPU上的速度还能再快一截。更激进的做法是INT8量化，但INT8量化后舌苔分类的准确率容易掉，建议只对检测模型量化，分类模型保留FP32，反正分类模型小，推理不是瓶颈。

这五个坑会在这类项目的血泪经验里反复出现。如果你在训练中遇到验证集指标上下剧烈震荡，先别怀疑模型结构，回到数据管线里查找是不是切分种子没固定，或是验证集也加了随机增强。这类“玄学”问题，绝大多数出在数据管线而不是网络结构上。

5. 验证与落地：用F1和mAP验收，再用ONNX把推理从10秒压到1秒

5.1 用F1和mAP验收，不看单项准确率

训练结束后，模型的“准确率”只是热身，真正要打印的是每个类别的precision、recall、F1，以及检测模型的mAP@0.5和mAP@0.5:0.95。

打印一段这样的结果看：

white precision 0.93 recall 0.91 f1 0.92 yellow precision 0.68 recall 0.61 f1 0.64 gray precision 0.54 recall 0.47 f1 0.50 tongue detection mAP@0.5 = 0.982

如果灰苔的F1只有0.50，这不是模型的锅，而是数据只有40张的锅。验证集里的灰苔约8张，任何模型在8张样本上的F1波动都很大。论文里写这类指标时，要标注“灰苔样本量过少，结果仅供方向参考”，这样评审老师才觉得你知道自己在说什么。另一个验收点是：把测试集的错误样本全部打印出来，做一次人工复检。错得离谱的，大概率是标签标错了，而不是模型理解错了，反向修正数据集比换模型更有效。

5.2 用ONNX导出模型，把推理速度压到可演示水平

演示系统不能依赖GPU。常见做法是把训练好的检测模型导出为ONNX，用onnxruntime在CPU上跑。导出命令：

yolo export model=runs/tongue_yolov8/weights/best.pt format=onnx opset=12

再用onnxruntime加载运行：

import cv2 import onnxruntime as ort session = ort.InferenceSession("best.onnx", providers=["CPUExecutionProvider"]) image = cv2.imread("tongue_sample.jpg") # 预处理、推理、输出解析的细节在ultralytics文档中有标准实现

逻辑说明：导出时指定opset=12是为了兼容旧版onnxruntime，答辩或现场用的电脑上安装的版本往往较旧。导出为ONNX后，输入尺寸固定为640乘640，如果部署时想提速到512，导出时就要把imgsz也改成512，而不是在推理代码里临时缩放，否则模型输入尺寸不匹配会直接报错。速度目标：检测模型在CPU上从10秒压到2秒以内，分类模型因为输入只有224乘224，本身很快，不需要额外优化。

这条路的终点不是训完就完事，而是做成一个能现场演示的小系统：摄像头采集一帧画面，YOLO框出舌体，裁剪区域送进分类网络，画面左上角显示苔色判断和置信度。答辩老师看到这一幕，比看十页网络结构图更能相信你真的做出来了。我自己的习惯是：演示脚本里加一个“保存输出图片”的按钮，每跑一帧就存一张带标注的结果图。这样即使现场摄像头出问题，手里还有一叠按真实流程跑出来的图片，这是最经得起追问的验证方式。

希望这篇笔记能帮你把这个压缩包变成一份真正能讲清楚的毕业设计。还是那句老话：先把数据管干净，再谈模型结构，最后用验证指标守住底线。深度学习这一行，模型可以换，数据管线才是最容易翻车也最值得投入的地方。希望帮到你。

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