基于YOLOv8与Flask的人脸表情识别系统实战：从训练到部署

想聊一聊最近一个月我一直在折腾的一个项目——基于 YOLOv8 的人脸表情检测识别系统。做这个事的起因很简单有个做教育产品的小伙伴找我说想做一个能实时分析课堂学生状态的Demo需要在摄像头画面里把每个人的表情识别出来给老师一个反馈。市面上现成的表情识别API不少但要么收费要么精度不稳而且真正想在本地私有化部署的话还是得自己训练一套模型。所以我就从零开始搭了这个系统整体技术栈就是标题里写的那样YOLOv8做检测识别Flask做Web服务加上开源数据集训练。目前已经跑通了图片上传识别、摄像头实时检测两条链路今天把整个过程复盘一遍包括方案选型、数据集处理、训练调参、接口封装和部署踩坑希望对做类似项目的朋友有点参考价值。先说项目最终的形态你打开浏览器进入一个本地页面既可以上传一张带人脸的图片也可以授权摄像头实时视频流。后端跑着一个 YOLOv8 表情检测模型能识别出人脸位置并判断对应的表情类别再把结果画框、打标签返回前端。标准表情分类是七类生气、厌恶、恐惧、开心、难过、惊讶、中性。整个系统的核心代码分三块YOLOv8模型的训练脚本、Flask后端接口、前端HTML页面。数据集用的是公开的表情数据集然后自己做了清洗和YOLO格式转换。如果你只是想快速跑通一个Demo那照着下面的内容一步步来两三天时间应该能出效果。这里面有一个需要先想明白的事情YOLOv8本身是目标检测模型不是专门为表情识别设计的。表情识别更传统的做法是把问题拆成两步先用一个人脸检测模型框出人脸再把人脸区域喂给一个分类模型判断表情。这个方案很成熟我也试过精度确实高。但问题是系统会变复杂要维护两个模型、两套推理流程。YOLOv8的优势在于它可以直接输出“人脸框 类别”一个模型搞定两个任务部署链路短推理速度快。代价是如果你想要非常高的准确率YOLOv8直接做表情检测的效果通常不如“人脸检测 表情分类”的组合。所以这个方案适合什么场景呢对检测框精度要求不高、更看重实时性和工程简洁性的场景比如课堂注意力分析、门店顾客情绪统计、互动装置的实时反馈。如果是严肃的身份识别或者医疗级情绪分析就不要用这个方案了。1. 项目整体设计与方案选型1.1 搞明白这系统到底能干什么人脸表情识别这个需求听起来很垂直但应用场景其实非常广。除了前面说的课堂学情分析门店可以通过摄像头统计顾客进店后的表情分布判断服务质量和商品陈列是否吸引人智能客服终端可以感知用户情绪在用户不耐烦时转接人工还有一些陪伴类机器人需要根据用户的表情调整交互语气。这些场景都有几个共同特征多人脸、实时性要求高、硬件环境一般、不能完全依赖云端API。这决定了我们的技术选型必须满足三点推理速度要快、本地可部署、二次开发成本低。YOLOv8Flask恰好命中这三条。YOLOv8在目标检测领域属于当前开源模型里工程化做得最舒服的一档你不需要自己写网络结构也不需要手动实现NMS逻辑安装一个库就能训练和推理开了很多“傻瓜模式”的接口。Flask作为Python后端框架最大的优势是轻和简单一个文件就能起一个服务配合HTML页面就可以快速做成交互Demo。整个系统的核心链路是浏览器/脚本发送图片 → Flask接收并保存为临时文件 → YOLOv8模型推理 → 结果转JSON返回前端 → 前端画框显示。这条链路非常清晰出了问题也好排查。1.2 为什么是YOLOv8而不是更传统的分类模型或者其他检测模型在做方案选型的时候我调研过三种路线第一种是纯CNN分类模型比如用ResNet或者MobileNet输入一个人脸区域输出表情类别。这个方案的问题是你要额外解决“人脸从哪里来”还是得先接一个人脸检测器。流程上没有任何简化反而要处理两个模型的输入输出对齐。第二种是使用ultralytics库之前很多人用YOLOv5做目标检测。YOLOv5已经很成熟但YOLOv8在结构上做了几个关键改进。它把传统的Anchor-Based检测头换成了Anchor-Free简单理解就是不再需要提前定义一大组预设框的大小和比例模型直接预测目标的中心点和宽高这让训练收敛更省心尤其是遇到人脸这种宽高比相对固定的目标时Anchor-Free的优势很明显。另外YOLOv8还引入了C2f模块在保持轻量化的同时提升了梯度流动能力对小目标更友好。人脸表情检测有一个特点表情的差异往往体现在五官细节上人脸区域在整个画面里通常不大所以小目标检测能力很关键。第三种是直接用YOLOv8的官方预训练权重做迁移学习。虽然官方权重是在COCO数据集上训练的但它已经学到了通用的图像特征尤其是对人脸这种纹理丰富的物体有很强的特征提取能力。哪怕你只准备几千张标注好的表情图片微调后也能得到一个能用的模型这对没有海量算力和数据的个人开发者来说是巨大的福音。顺便说一句如果你只是做实验对比也可以试试YOLOv8的n/s/m/l/x几个不同尺寸版本。n版本最快但精度最低x版本最慢但精度最高。我做这个系统选的是s版本在CPU上推理速度大约能到每帧150毫秒左右如果换成GPU可以跑到实时。1.3 Flask在整套系统里的定位Flask在这个项目里承担的职责是“胶水层”。模型推理是核心但最终用户不可能直接去命令行里调用模型他们需要一个HTTP接口、一个可点击的页面。Flask负责的事情包括接收上传的图片、把图片交给模型推理、把结果包装成JSON返回、托管前端页面、提供视频流接口。那为什么不选DjangoDjango确实功能强大自带Admin后台、ORM、认证系统适合业务逻辑复杂的大型Web应用。但在这个项目里这些都用不上而且Django的目录结构和配置项更多反而增加了学习成本。为什么不选FastAPIFastAPI性能更高支持异步还自动生成接口文档看起来更高级。但我需要考虑的是实际运行环境这个系统经常要在没有外网的机房或嵌入式设备上跑Flask的依赖更少、兼容性更好出现问题也好定位。我当时实测了一下同样的推理逻辑在Flask和FastAPI下性能瓶颈基本都在模型推理本身HTTP框架那点差异根本感觉不出来。所以最终选了Flask图的就是少折腾。2. 数据集准备与YOLO格式转换2.1 表情数据集有哪些公开选择训练表情识别模型数据集的坑比想象中要多。目前公开的表情数据集大致有几类一类是实验室环境下采集的比如CK样本量不大但每一帧都是专家标注过的表情比较夸张清晰另一类是互联网环境采集的比如FER2013有3万多张48×48的灰度图包含七种表情特点是样本量大但噪声多很多人脸其实是歪的、遮挡的或者根本不像人脸还有一类是带情感标签的野外人脸数据集比如RAF-DB图片更接近真实场景。我在实际处理中发现这些数据集有一个共性问题它们大多是分类数据集不是检测数据集。也就是说原始数据只给了一张图对应一个表情标签并没有给人脸画框。YOLOv8训练时需要的是目标检测格式的标注格式是每张图片对应一个txt文件每一行代表一个目标内容是类别ID 中心点x坐标 中心点y坐标 框宽 框高其中坐标都是除以图片宽高之后归一化的数值范围在0到1之间。这是整个数据准备阶段最繁琐的一步。以FER2013为例它原本是一个CSV文件每一行有一串48×48的像素值和一个标签。你需要先把像素值还原成图片保存为jpg然后用类似OpenCV的人脸检测器给每张图片检测人脸位置生成标注框。这里有一个细节由于这些数据集分辨率普遍很低直接用现成的人脸检测器可能漏检我当时的处理办法是做了一个简单的循环——先用检测器检测检测不到就跳过检测到了就把框转成YOLO格式。数据清洗完之后明显感觉训练出来的模型不容易被噪声带偏。2.2 从分类数据到YOLO标注的完整转换逻辑用一个具体的例子来说明转换逻辑。假设有一张宽度为W、高度为H的图片人脸检测器返回的框是四个整数左上角x坐标x1左上角y坐标y1框宽w框高h。那么YOLO格式对应的计算方式如下中心点x坐标归一化(x1 w/2) / W中心点y坐标归一化(y1 h/2) / H框宽归一化w / W框高归一化h / H比如一张宽640、高480的图片检测到人脸的框是左上角坐标(100, 80)宽200高260那么计算出来就是中心x(100200/2)/640≈0.3125中心y(80260/2)/480≈0.4375宽200/640≈0.3125高260/480≈0.5417。txt文件里就写一行5 0.3125 0.4375 0.3125 0.5417前面的5代表表情类别编号按数据集的类别顺序排列。目录结构也需要严格按照YOLO的要求来组织像下面这样dataset/ ├── images/ │ ├── train/ │ │ ├── 000001.jpg │ │ └── ... │ └── val/ │ ├── 000101.jpg │ └── ... └── labels/ ├── train/ │ ├── 000001.txt │ └── ... └── val/ ├── 000101.txt └── ...注意图片和对应的txt文件必须同名只是后缀不同。我最初犯过一个低级错误程序生成的标注坐标没有归一化直接写成了原始像素坐标结果训练时损失函数直接爆炸loss降到一定程度就再也不动了。后来打印了一条标注数据发现数值大得离谱才意识到坐标必须除以宽高。2.3 数据增强与样本不平衡的第一道坎表情识别有一个天然痛点七类表情的样本量极度不均衡。FER2013里“开心”类别的图片可能有近万张而“厌恶”可能只有几百张。如果用原始数据直接训练模型会对低频类别非常不敏感最后的结果是无论什么表情都容易被识别成高频类别。样本均衡的常规做法有两个层面第一个层面是在构建数据集时做重采样对样本量少的类别重复多遍或者用数据增强多复制几份第二个层面是在训练参数里调整类别权重给低频类别更大的损失惩罚。我在这个项目里两层都用上了。数据增强方面YOLOv8内置了Mosaic增强、随机翻转、随机光照扰动、随机缩放等功能。Mosaic增强会把四张训练图片拼成一张相当于变相扩大了batch中的样本多样性。我训练时最常调的是随机光照扰动因为后期在真实场景中会遇到各种光线条件室内灯光、室外逆光、屏幕光线反射等如果训练数据里没有这样的多样性模型一到阳光下就瞎了。另外一个容易忽略的点是“标注框质量”。表情数据集的标注质量参差不齐有些人脸框可能只框住了半边脸有些把背景也框进去了。YOLOv8在训练时会对锚框和真实框的匹配做筛选如果你的标注框特别不准模型很难学到稳定的位置预测。我的做法是在转换完成后随机抽了200张图做可视化检查把标注框画出来直接看发现框严重偏移的就直接删掉。这个步骤虽然耗时但对最终精度的影响非常大。3. YOLOv8模型训练的核心细节3.1 环境安装和项目结构先说训练环境。我这边用的是一张普通的消费级显卡显存8G训练s版本模型完全够用。如果手头没有合适的GPU建议用云GPU平台按小时计费训练一个表情模型大概两三个小时就能搞定比在CPU上跑一整天划算得多。安装部分很简单核心依赖就是这个库pip install ultralytics这个库会把PyTorch、OpenCV等常用依赖一并带过来。需要注意的是PyTorch版本和CUDA版本的匹配问题建议先去官网确认对应版本的安装命令直接在pip环境下装CPU版本的PyTorch虽然也能跑但训练速度会慢到你怀疑人生。我第一次跑的时候用的CPU一个epoch要十几分钟全靠耐心撑着换了GPU环境之后同样的配置一个epoch只需要40秒。训练之前需要准备一个数据配置文件名称可以叫data.yaml内容格式如下train: ./dataset/images/train val: ./dataset/images/val nc: 7 names: [angry, disgust, fear, happy, sad, surprise, neutral]nc代表类别数量是7names的顺序必须和标注txt文件里的类别ID一致。我就吃过这个亏训练时按英文名排序定义了类别结果预测时发现原本标注的“开心”变成“中性”了排查半天才发现是names顺序对不上。3.2 训练参数应该怎么调训练命令的核心参数如下yolo detect train \ --model yolov8s.pt \ --data data.yaml \ --epochs 120 \ --batch 16 \ --imgsz 640 \ --device 0 \ --patience 20每个参数我都想多说一句model这里用的是yolov8s.pt预训练权重而不是从头开始训练。迁移学习能大幅缩短收敛时间这是关键。epochs我设了120但开启了早停机制patience20意思是连续20个epoch验证集损失没有改善就自动停止。我实际跑完只用了80多个epoch就停了因为后面的确没有再提升。batch设置16是因为8G显存的限制。如果你显存更大可以试着调到32训练会更稳定。imgsz是输入图片尺寸。训练时用640是通用做法。如果人脸在图像中占的面积特别大比如特写镜头反而可以适当降低到416加快训练如果场景里人脸比较多而且小可以考虑升到768。表情识别属于细粒度分类任务细节很重要我用640效果还行再高的尺寸训练时间成本会急剧上升。有一个训练小技巧先用小尺寸、小epoch快速跑一个实验确认数据格式和训练流程没有问题再上正式的参数组合。我习惯先跑30个epoch看loss曲线走势如果正常下降就放心用完整参数去训练。这样能避免因为数据问题白等几个小时。3.3 训练结果怎么分析训练完成之后ultralytics会在run目录下保存一系列文件。重点关注这几个weights/best.pt验证集上表现最好的权重后面的推理部署都用它。weights/last.pt最后一个epoch的权重有时候best.pt反而比last.pt差因为验证集和实际部署场景可能有偏差可以两个都测一下。results.csv记录了每个epoch的损失、精确率、召回率、mAP等指标。混淆矩阵图片能直观看到哪些类别容易被混淆。怎么判断模型有没有训练好开发者最常看的指标是mAP50和mAP50-95。mAP50简单理解就是预测框和真实框的重合度超过50%就算检测成功时的平均精度mAP50-95则更严格取多个重合度阈值下的平均值。表情识别场景里我们不需要特别精确的框所以mAP50的参考价值更大。我这次训练结束mAP50在0.75左右mAP50-95在0.45左右在单模型直接做表情检测的方案里算是可以接受的水平。还有一个很实用的方法把验证集的预测结果可视化出来看看模型实际画框和标签的效果。有时候指标看起来不错但实际预测的框在乱飘或者人脸边缘被裁掉太多。我在测试时就发现模型在“惊讶”和“恐惧”之间非常容易混淆因为这两个表情的张嘴瞪眼特征确实相似这种问题光看mAP看不出门道必须看可视化结果。3.4 过拟合和欠拟合的调整思路训练过程中最常遇到的两个问题一个是loss降不下去一个是loss降到一定程度后验证集指标开始变差。前者往往是学习率设置的问题后者是过拟合。我有一次把初始学习率调到了0.01结果loss前10个epoch基本没动后来换回默认的学习率0.001loss才开始正常下降。遇到loss不降的情况别急着加数据先检查学习率是不是太高或太低。过拟合的典型表现是训练集损失持续下降但是验证集mAP不再上升甚至开始抖动。解决手段按照优先级可以这样排第一是增强数据多样性把Mosaic增强打开随机增加光照变化第二是减少训练轮数早停机制在这里非常有用第三是增加Dropout或权重衰减不过YOLOv8里这些参数不像分类模型那么好调一般默认就行。如果用了这些手段仍然过拟合那就要从数据清洗入手了检查训练集和验证集是不是有大量重复图片。有一次我发现验证集里混入了训练集里几乎一样的图片导致验证指标虚高模型实际泛化能力并不好这个坑很容易踩。4. Flask接口开发与Web端部署4.1 Flask后端接口的整体结构模型搞定之后最激动人心的时刻就是把系统从前到后串起来。Flask后端我分成了两个模块一个是负责模型推理的工具模块一个是负责处理HTTP请求的路由模块。这样做的原因很纯粹推理逻辑和Web逻辑混在一起后期想切换成定时任务调用或者命令行批处理都得改一大片代码。解耦之后任何一端出问题都好排查。项目目录结构大致是这样的app.py # Flask入口 model_utils.py # 模型加载与推理 templates/ index.html # 主页面model_utils.py的核心逻辑是把YOLOv8的推理结果从ultralytics的Results对象转换成纯Python的字典方便JSON序列化。YOLOv8默认的预测结果包含很多信息比如mask、keypoints等我们这里只需要boxes、classes和confidences。4.2 图片上传与检测识别接口的完整实现先看模型推理模块的代码。这里有一个很重要的细节用Flask接收的图片是字节流而YOLOv8的模型推理接口需要的是图片路径或者numpy数组对象所以要先用OpenCV把字节流解码成numpy数组。我最开始犯过的错误是直接把字节流传给模型推理方法结果报错说类型不支持。import cv2 import numpy as np from ultralytics import YOLO class EmotionDetector: def __init__(self, model_path): self.model YOLO(model_path) def predict_bytes(self, image_bytes): # 字节流转numpy数组 nparr np.frombuffer(image_bytes, np.uint8) img cv2.imdecode(nparr, cv2.IMREAD_COLOR) results self.model.predict(img, imgsz640, conf0.4, verboseFalse) # 转换成可直接JSON化的列表 detections [] for result in results: boxes result.boxes if boxes is None: continue for box in boxes: x1, y1, x2, y2 box.xyxy[0].tolist() cls_id int(box.cls[0].item()) conf float(box.conf[0].item()) detections.append({ bbox: [int(x1), int(y1), int(x2), int(y2)], class_id: cls_id, class_name: result.names[cls_id], confidence: conf }) return detections接下来是Flask路由。这里设计了一个POST接口接收图片文件调用预测方法然后把结果拼成JSON返回。同时为了方便前端直接在页面上画框我把识别结果中的图片也一起返回了用base64编码。这样前端拿到数据之后不需要再通过接口拉取原图。import base64 import cv2 from flask import Flask, request, jsonify, render_template app Flask(__name__) detector EmotionDetector(weights/best.pt) app.route(/) def index(): return render_template(index.html) app.route(/predict, methods[POST]) def predict(): if image not in request.files: return jsonify({error: no image uploaded}), 400 file request.files[image] image_bytes file.read() # 检测 detections detector.predict_bytes(image_bytes) # 顺便把画框后的图片转成base64给前端 nparr np.frombuffer(image_bytes, np.uint8) img cv2.imdecode(nparr, cv2.IMREAD_COLOR) for det in detections: x1, y1, x2, y2 det[bbox] label f{det[class_name]} {det[confidence]:.2f} cv2.rectangle(img, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText(img, label, (x1, max(0, y1 - 5)), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2) _, buffer cv2.imencode(.jpg, img) img_base64 base64.b64encode(buffer).decode(utf-8) return jsonify({detections: detections, image: img_base64})接口本身很简单但有几个细节值得注意。第一个是conf参数的取值我设置的是0.4这个值太低会输出一堆误检框太高又会漏掉真实的人脸。如果画面比较干净建议设0.5以上如果是嘈杂的公共场所0.3左右可能更合适。第二个是OpenCV解码时如果图片格式是png且带透明通道cv2.imdecode读取后是三通道BGR不会报错但颜色会异常前端上传前最好统一转成jpg格式。4.3 实时摄像头检测的两种实现路径实时视频流检测在这个项目里做了两个版本。第一个版本是前端页面通过浏览器调用摄像头然后把每一帧图片用base64编码后POST到后端接口。这个方案优点是实现简单而且能复用上面写好的/predict接口缺点是每帧图片体积大帧率上不去实测大概只能做到3到5帧用来验证功能绰绰有余做流畅交互就有点勉强。第二个版本是Flask后端直接读取摄像头或者视频流用流式响应把处理后的帧以multipart/x-mixed-replace格式持续推送给前端。 标签可以直接显示这个流。这个方案的帧率更高但一次只能检测一路视频适合单摄像头场景。第二个版本的实现思路大概是这样的一个Python生成器函数负责循环读帧、推理、画框、编码然后用response类型把视频流返回。前端页面里只需要一个img标签src直接指向/video_feed这个地址就行。实际运行下来这个方案的帧率取决于推理耗时我测试时大概在5帧左右虽然谈不上丝滑但做Demo已经是可接受的程度。如果你后续想提高帧率可以把输入分辨率降下来或者把推理任务放到独立的线程里配合队列异步处理主线程只管取最新一帧的结果能明显减少阻塞感。def generate_frames(): cap cv2.VideoCapture(0) # 0代表默认摄像头 while True: success, frame cap.read() if not success: break results detector.model.predict(frame, imgsz640, conf0.4, verboseFalse) annotated results[0].plot() # ultralytics自带可视化 # 压缩编码成jpeg ret, buffer cv2.imencode(.jpg, annotated) frame_bytes buffer.tobytes() yield (b--frame\r\n bContent-Type: image/jpeg\r\n\r\n frame_bytes b\r\n) app.route(/video_feed) def video_feed(): return Response(generate_frames(), mimetypemultipart/x-mixed-replace; boundaryframe)这个方案里我用了results[0].plot()它会自己把人脸框和类别文字画在图上。如果你对画框样式有特殊要求比如改变颜色或者字体就用前面的cv2接口自己画效果更可控。5. 实战踩坑与性能调优5.1 环境依赖的坑一次说全整个系统从训练到部署环境依赖的坑我差不多都踩了一遍。第一个坑是CUDA和PyTorch不匹配安装完ultralytics之后运行训练命令直接报错提示CUDA不可用排查之后发现CUDA版本太新而PyTorch版本太旧两个版本没对上。这里给一个建议不管CUDA驱动是哪个版本PyTorch安装时最好用官网命令里的默认版本不要自己预装一个然后再装PyTorch很容易出问题。第二个坑是运行Flask时发现模型加载很慢每次启动都要等十几秒。这是因为YOLO()在初始化时要加载权重文件和建立模型结构。如果只想偶尔跑一次服务这点时间无伤大雅但如果开发调试中频繁重启Flask就很影响效率了。解决办法是设置模型为全局变量只在启动时加载一次不要在每个请求里重新加载。另外在debug模式下Flask会启动两个线程加载两次模型调试时最好把debug关掉。第三个坑是中文标签显示问题。OpenCV默认的字体不支持中文如果你用cv2.putText把“开心”直接画在图上最后屏幕上会显示成乱码或者问号。解决方案有两个一是前端在渲染时根据英文标签映射成中文二是把画框逻辑从前端拿到后端用PIL的字体渲染中文。我图省事就用了前端映射的方案反正结果已经是JSON了。5.2 推理速度优化从CPU到GPU再到ONNX如果你的目标是在普通电脑上跑视频流检测推理速度是绕不开的话题。我在CPU上实测过yolov8s模型单帧推理耗时约150毫秒也就是5到6帧看起来勉强能用但人脸一多实际处理就明显卡顿。如果你手头有显卡哪怕是最入门的GPU推理速度能提升到30毫秒以内。如果没有GPU还有一个方案是转成ONNX格式。ONNX是一种开放的模型交换格式配合ONNX Runtime推理在CPU上通常能比PyTorch原生推理快2到3倍。转换命令很简单yolo export modelweights/best.pt formatonnx导出的ONNX文件可以直接被ONNX Runtime加载不过需要你手动做预处理和后处理比如归一化、NMS等会比直接调用ultralytics复杂一些。如果你的部署目标是嵌入式设备或者树莓派也可以考虑导出成NCNN格式但那部分的工作量更大需要有一定模型部署经验才能搞定。还有一个小参数调整推理时把imgsz从640降到480速度能提升约30%精度损失不大。如果摄像头场景中人脸占画面比例较大这个小技巧很管用。5.3 识别效果不理想时先别急着换模型在实际测试中我发现很多“识别不准”的问题并不是模型本身的问题而是使用方式的问题。这里分享几个排查顺序。首先是检查输入图片分辨率。如果上传的图片是一张特别大的高清图YOLOv8在推理时会先把图缩放到640大小如果人脸本身比较小缩放后人脸细节就丢失了表情自然识别不准。解决办法是推理前先用OpenCV把图片缩放到合理尺寸比如最长边不超过1280或者干脆限制用户上传图片大小。其次是检查目标类别分布。上课场景和商场场景里的人脸姿态差异非常大。训练数据里正面脸多测试时全是侧面脸模型表现自然会下降。这个问题不是调参能解决的需要补充更多角度、更多光照条件的训练数据。我的建议是先用现有模型跑一批真实场景图片把置信度较低的结果抽出来人工看一遍你会很快发现模型在哪些场景下会失效然后针对这些场景去补充数据。接着要检查的是置信度阈值和NMS参数。有些情况下模型其实预测对了但因为阈值太高被过滤了。可以写一个简单的调试工具把模型的原始输出框全打出来看看置信度分布区间再决定阈值设多少。最后再谈一个个人经验如果你发现“开心”或者“中性”这类高频类别的识别准确率很高但“厌恶”这种低频类别几乎是零检出那基本可以断定是数据不平衡问题而不是模型不行。这时候先不要换模型回到第2节的类别重采样和数据增强再训练一轮。5.4 从单模型到“检测分类”的混合方案前面说过YOLOv8直接做表情检测的精度上限有限。如果项目后续对准确率有更高要求我建议往“人脸检测 表情分类”的混合架构迁移这个方向我在做进阶实验时已经验证过了。具体做法是仍然用YOLOv8的检测能力但只保留人脸框信息然后对每个裁剪出来的人脸区域再走一个轻量级的表情分类模型。这样做的理由很简单YOLOv8这类目标检测模型在训练时损失的很大一部分是位置损失也就是框得准不准。而表情识别本质上是一个细粒度分类问题模型需要重点关注的是人脸的局部纹理比如眼角的皱纹、嘴角的弧度。如果让模型同时去学习定位和分类相当于让它一心二用分类能力就会被稀释。拆成两个模型之后每个模型的任务都更纯粹分类模型可以用专门为细粒度分类设计的数据增强策略精度提升会比较明显。我给这套混合方案的建议结构是这样的Face Detector用yolov8n或者更小的模型只负责输出人脸框Face Classifier用一个轻量的分类模型输入尺寸可以设成112×112或者224×224训练数据从数据集里按人脸框裁剪得到。整体推理链路是视频帧 → 人脸检测 → N个人脸框 → 分别裁剪 → 批量分类 → 汇总结果。实际测试下来分类准确率比单模型直接检测高出5到10个百分点尤其在侧脸和遮挡场景下优势明显。不过话说回来如果你的需求就是快速验证、快速Demo单模型方案已经够用了。它的定义、训练、部署链路最短出问题的概率最低而且YOLOv8自带的可视化功能能让你在半天之内就把一个可交互的页面跑起来。技术选型没有绝对的对错只有适合当前阶段和当前场景的选择。写在最后的几个心得整个项目做下来我最深的感受是这个系统真正的难点不在“用YOLOv8训练一个模型”这太简单了一行命令就能搞定。难点在于数据准备阶段的细心程度、训练参数的理解、以及真实场景适配时那一堆看似琐碎的坑。尤其像坐标归一化这种细节一旦出错后面所有训练都是在浪费时间。所以如果你也要做类似的项目我建议先把数据可视化检查这一步老老实实做了再去碰训练按钮。另外有一个很多人都忽略的小细节模型的最终效果一定要在真实场景里验证而不是只看验证集指标。数据集的图片和真实摄像头拍到的画面有巨大的distribution gap教室里昏暗的灯光、手机屏幕发出的蓝光、摄像头本身的噪声都会让模型的置信度大打折扣。我最后一次调试时就把笔记本放到不同房间的角落分别测试正光、侧光、逆光情况针对性地加了亮度干扰的数据增强实际体验才明显变好。这套系统后续可以扩展的方向也很多比如接入人脸的年龄和性别识别形成一个更完整的用户画像、把推理结果按时间序列做统计分析生成报表、或者把模型换成姿态估计模型去判断课堂上的举手和瞌睡动作。核心的Flask接口和数据流结构都不用大改只要替换模型输出和前端展示逻辑就行。希望这篇过程复盘能给你一些启发动手做一个自己的表情识别系统时少走弯路。