简介一份面向深度学习与计算机视觉开发者的人脸检测与表情识别项目资源以YOLOv11为基础同时展示如何针对特定任务定制YOLO模型覆盖人脸检测、关键点定位与表情分类全流程适用于智能交互、安全监控、课堂考勤与用户行为分析等落地场景。压缩包共1022个文件总大小约56.71MB文件构成上396个Markdown文档提供原理说明与使用指引190个Python脚本覆盖数据预处理、模型训练与推理59个模型权重文件可直接加载测试97个YAML配置便于调整参数另有C源码、样例图片、视频与Dockerfile辅助部署。当前已有61人学习下载。借助这套项目读者可以系统理解YOLOv11的网络结构改进、SPP多尺度融合、注意力机制在表情识别中的作用并能够基于自定义数据集完成迁移训练和效果验证。项目采用模块化设计代码组织清晰适合作为课程设计、毕业设计或快速搭建人脸表情分析原型的参考资料。1. 基于 YOLOv11 与自定义 YOLO 模型的人脸检测与表情识别系统为什么值得照着复现一遍看到一个 zip 标题是「基于 YOLOv11 与自定义 YOLO 模型的人脸检测与表情识别系统」先要搞清楚它在解决什么不是拿别人训好的人脸检测器框一下脸再用一个分类网络猜表情的玩具级 demo而是把“人脸在哪”和“表情是七类中的哪一类”放进同一个 YOLO 推理流程里跑通并支持你用自己的数据集重新训练自定义模型。适合谁适合已经跑过目标检测环境、但没碰过表情数据集的同学也适合手里只有分类标注、想转成目标检测输出的从业者。我按这套方案复现过几次90% 的卡点根本不在 YOLOv11 网络结构而在数据集格式、类别索引和训练参数上。下面直接按可以落地执行的顺序展开。2. 人脸检测 表情识别的技术选型YOLOv11 在这里到底扮演什么角色2.1 表情识别为什么不能用纯分类网络硬扛很多人的第一反应是表情识别不就是把一张人脸图像喂进 CNN输出“开心、难过、中性、惊讶、恐惧、愤怒、厌恶”七选一吗这个想法在 FER2013 这类竞赛数据集里没错因为图像已经裁剪成人脸你只需要做分类。可一旦换到摄像头画面、多人合影或视频帧问题就变成“人到底在哪”然后才谈得上“表情是啥”。如果强行用一套“外部人脸检测器 表情分类器”的流水线你会遇到两个很现实的问题。第一是误差被两级放大。检测器少框了一个人后面分类器再准也没用检测框稍微偏一点裁剪出来的区域可能带上额头、头发甚至背景表情分类精度立刻掉。第二是部署成本高。检测和分类是两个模型、两组推理视频流要做到实时每一帧都要跑两遍显存和内存开销直接翻倍。更麻烦的是不同的人脸检测器输出的人脸框尺度不一样你还需要在中间加对齐和缩放逻辑这一步很容易变成整个系统的黑匣子。所以常见做法是走端到端目标检测路线用 YOLOv11 的检测头直接输出每个人的边界框同时对每个框给出表情类别概率。这就是标题里“自定义 YOLO 模型”的主要含义——把原本识别 COCO 80 类的 YOLO改成识别你自己定义的表情类别。这样做的好处很明显一次前向拿到所有人脸的位置和表情小脸、遮挡、多人场景都由锚框和特征金字塔统一处理训练和部署都只有一个模型好维护。2.2 自定义 YOLO 模型的边界一个检测头同时输出 bbox 和表情类别“自定义 YOLO 模型”这个词很容易被误解成要去改 YOLOv11 网络结构、自己写 C 推理代码甚至重新发明注意力模块。其实在 Ultralytics 这套生态里自定义模型通常只是改数据配置和类别数网络主干和检测头保持 YOLOv11 原样。你真正要做的是把标注文件里的类别索引映射成自己的 7 个表情类然后让模型在预训练权重基础上微调。训练前最关键的配置文件是这个 YAML# expression_dataset.yaml # 用于表情识别的自定义 YOLO 数据集配置 path: ./datasets/expression train: images/train val: images/val names: 0: neutral 1: happy 2: sad 3: surprise 4: fear 5: angry 6: disgust这个文件的逻辑很简单但它是整套系统最容易翻车的地方。names的索引顺序必须和每张图像对应的.txt标签文件第一列完全一致。举例来说如果你的标签 txt 里写的是2 0.5 0.5 0.2 0.3那这代表类别 2也就是 sad如果你为了看起来顺眼把 happy 写在第一位但 txt 里第一列还是 0那训练出来的模型就会把 neutral 认成 happy而且你几乎察觉不到因为 loss 可能照样降。YOLOv11 在这里的角色本质上是把目标定位和表情分类合并成一个多任务学习问题。每个预测框输出六元组中心坐标、宽高、目标置信度和表情类别分布。对比传统人脸检测器加分类器的做法我列了一张选型表对比项人脸检测 表情分类级联YOLOv11 自定义模型多人脸人脸检测器输出几个框就分类几次一次前向全部识别小脸依赖检测器裁剪质量容易崩可通过调大输入分辨率缓解标签准备检测和分类数据要分开做一份检测格式标签搞定部署两个模型需要分别打包单模型导出 ONNX 或 TensorRT可视化需要自己拼接两级结果推理结果自带框和类别选型上有一些例外如果你只需要单人脸且人脸已经对齐纯分类网络仍然更简单如果场景里需要额外输出人脸关键点做活体检测那 YOLO 也要搭配一个关键点模型。但就题目里的“人脸检测 表情识别”而言把两者合成一个自定义 YOLO 模型是当前性价比最高的方案。3. 自定义 YOLO 模型训练前的准备工作环境、数据集与标签格式3.1 环境配置适合 0 基础纯小白的 ultralytics 安装与显卡检查先把环境搭起来这一步不麻烦但很多纯新手会卡在“到底装 CPU 版还是 GPU 版”。我一般建议用 Conda 建独立环境避免把系统 Python 弄乱# 建一个 Python 3.10 的虚拟环境 conda create -n yolo11 python3.10 -y conda activate yolo11 # 安装 ultralytics它会自动带上匹配的 torch 版本 pip install ultralytics # 验证 GPU 是否可用 python -c import torch; print(CUDA available:, torch.cuda.is_available()); print(torch.cuda.get_device_name(0))逻辑说明conda create -n yolo11 python3.10指定解释器版本避免和系统自带 Python 冲突pip install ultralytics会拉取 YOLOv11 相关的训练和推理接口最后一行代码是检查 CUDA 能不能被 PyTorch 看到。如果输出CUDA available: False先不要急着去改训练参数大概率是 NVIDIA 驱动和 CUDA 工具包版本不匹配或者你装到了 CPU 版 PyTorch。实际经验是完全 0 基础的小白不要在装环境阶段去追求“最新驱动”。Ultralytics 对版本有一定宽容度但你要是把显卡驱动升级到太新的版本反而可能让旧版 CUDA 失效。先用nvidia-smi看一下驱动支持的最高 CUDA 版本再决定 PyTorch 用什么渠道安装。CPU 版也能跑通整个流程但训练速度大概只有 GPU 的十分之一建议至少准备一张 8GB 显存的 NVIDIA 显卡。3.2 把 FER2013 或 RAF-DB 转成 YOLO 格式转换脚本和标签映射表这里有一个非常关键的认知FER2013 本身是已经裁剪好人脸的 48x48 灰度图它只有表情标签没有人脸框所以不能直接拿去训练 YOLO。你需要的是类似 RAF-DB、AffectNet 这样带原始图像的数据库或者自己收集图像并用标注工具画框。如果数据集提供的是人脸框坐标你要把它们转成 YOLO 需要的归一化格式。转换脚本我一般会写成下面这样直接读取一张图像和一个人脸框生成对应的.txt文件import os import cv2 def convert_bbox_to_yolo(image_path, box_xyxy, class_id, label_dir): box_xyxy: [x1, y1, x2, y2]左上角右下角坐标 class_id: 表情类别索引和 expression_dataset.yaml 保持一致 img cv2.imread(image_path) h, w img.shape[:2] # YOLO 需要归一化到 0~1 的中心点坐标和宽高 x_center (box_xyxy[0] box_xyxy[2]) / 2.0 / w y_center (box_xyxy[1] box_xyxy[3]) / 2.0 / h box_w (box_xyxy[2] - box_xyxy[0]) / w box_h (box_xyxy[3] - box_xyxy[1]) / h # 检查越界和非法框避免训练时 loss 变成 NaN if box_w 0 or box_h 0: print(skip invalid bbox:, image_path) return txt_path os.path.join(label_dir, os.path.splitext(os.path.basename(image_path))[0] .txt) with open(txt_path, a) as f: f.write(f{class_id} {x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}\n)注意几个参数box_w 0 or box_h 0的判断是为了过滤空框和重合点class_id必须对应 YAML 里的索引不能只写字符串同一个 basename 的图像和 txt 文件要放在images/和labels/两个目录YOLO 通过相同文件名关联它们。表情类别索引映射表建议固定成以下顺序这也和前面 YAML 保持一致表情文本class_idneutral0happy1sad2surprise3fear4angry5disgust6我踩过的坑是有些开源数据集会把disgust去掉只保留六类如果你直接沿用别人的data.yaml类别 ID 全部错位训练出来的模型把 angry 识别成 disgust。所以切数据之前先统计一遍每个类别实际有哪些标签再生成 YAML。标注顺序一旦确定整个训练周期内不要改。4. 从零训练一个 YOLOv11 表情识别模型命令、参数与推理保存4.1 下载预训练权重并自定义 YAMLyolov11n.pt 与模型结构的选择第一次运行训练命令时Ultralytics 会自动下载yolov11n.pt权重文件不需要手动到处找资源。如果你希望更稳可以先用一个明确指定模型的命令行让它把权重拉下来# 自动下载并训练以 yolov11n 作为预训练起点 yolo detect train \ modelyolov11n.pt \ dataexpression_dataset.yaml \ epochs100 \ batch16 \ imgsz640参数说明modelyolov11n.pt是 nano 版本参数量最小显存占用低适合 0 基础新手如果场景里人脸多且密集可以换成yolov11s.pt或yolov11m.pt。imgsz640是训练输入尺寸不是最终部署尺寸。名人脸或小脸场景建议把imgsz调到 768 甚至 1280但显存和训练时间会随之上升。权重选择这块我一般按显卡显存来定。8GB 显存用yolov11n没问题16GB 可以上yolov11s32GB 显存跑yolov11m比较舒服。YOLOv11 继续沿用 n/s/m/l/x 的层级划分参数量和计算量递增但精度不一定线性上涨尤其表情识别这种数据量不大的任务nano 和 small 的差距可能很小。4.2 训练命令与必须调的 4 个超参数batch/img/epochs/optimizer训练命令看起来很直接但真正决定成败的是下面这几个超参数。我给出一套适合表情识别起步的训练命令并逐一说明# 表情识别训练命令推荐在 GPU 服务器上执行 yolo detect train \ modelyolov11n.pt \ dataexpression_dataset.yaml \ epochs120 \ imgsz640 \ batch32 \ optimizerSGD \ lr00.01 \ patience20 \ cacheTrue \ projectruns/expression \ nametrain_v1参数解释epochs120对于自定义表情数据集来说不算大因为量级通常只有几千到几万张训练太久容易过拟合batch32需要根据显存修改如果报CUDA out of memory就先降到 16 或 8imgsz640是速度和精度的折中人脸占比小就上调optimizerSGD是我在数据量不大时的保守选择AdamW 也能用但要配更低的学习率。还有两个隐藏参数值得注意。patience20是早停机制连续 20 个 epoch 验证集 mAP 不提升就停止避免训练到后期反复震荡。cacheTrue在训练开始前把图像预先加载进内存能显著缩短每个 epoch 的等待时间但内存不够时不建议开。如果你发现模型对小脸表情识别效果差不要急着换网络结构先把这个参数调大# 加大输入尺寸小脸优化最直接的手段 yolo detect train \ modelyolov11n.pt \ dataexpression_dataset.yaml \ epochs120 \ imgsz1280 \ batch8imgsz1280会让 YOLOv11 在原始图像的更高分辨率特征上做检测小脸的锚框能覆盖更多像素比任何网络结构魔改都有效。代价是显存占用急剧升高训练时间变长所以要根据自己显卡量力而行。4.3 预测后保存用 YOLOv11 把结果写回图片与视频训练结束后runs/expression/train_v1/weights/下会有best.pt和last.pt。best.pt是验证集 mAP 最好的权重推理时优先选它。下面这段代码完成“读图片、推理、保存结果”一条龙from ultralytics import YOLO # 加载自定义模型权重 model YOLO(runs/expression/train_v1/weights/best.pt) # 对图片推理saveTrue 会把标注结果保存到 runs/infer/demo 目录 results model.predict( sourcetest.jpg, conf0.25, iou0.45, saveTrue, projectruns/infer, namedemo ) # 同时把结果对象打印出来方便调试 for result in results: print(result.boxes.xyxy) # 人脸框坐标 print(result.boxes.cls) # 表情类别索引 print(result.boxes.conf) # 置信度逻辑说明source可以是图片路径、视频路径或摄像头序号conf0.25是置信度阈值低于这个值的框会被过滤表情识别场景里这个值建议在 0.2 到 0.3 之间调太高容易漏检iou0.45是 NMS 的 IOU 阈值人脸密集时建议降到 0.3防止重叠框被误删saveTrue会自动把标注图像保存到runs/infer/demo/。如果要对视频保存推理结果只需要把source改成视频文件路径YOLOv11 会自动逐帧处理并输出一个带标注的新视频。这个功能在我调试摄像头数据时很有用直接输出一个 MP4 文件不用自己去拼接 Python 代码。5. 避坑指南YOLOv11 人脸检测与表情识别最常见的 5 个坑5.1 第 1 个坑训练 loss 不降反升模型不收敛现象训练开始后第一个 epoch 的 box_loss 和 cls_loss 波动很大后面不仅没下降反而越跑越高最终训练中断或 mAP 一直是 0。原因超过九成是标签和验证集配套出了问题。我在做表情识别时曾把train: images/train和val: images/val写成同一个目录结果验证集等于训练集模型在训练集上过拟合但验证集评估完全失真另一种常见情况是某些 label txt 文件里面class_id超出了 YAML 中names的长度YOLOv11 训练时会把无效类别当成错误标注导致 loss 突增。解决训练前写一个 Python 脚本遍历所有 txt检查类别索引是否都在0~6范围内同时确认 train 和 val 目录是两批不同的人脸图像。我还会随机挑 10 张图调用cv2把框画出来看一遍确保人脸框没有明显错位。5.2 第 2 个坑检测框置信度低表情类别来回乱跳现象人脸框能框住但 conf 普遍只有 0.2 左右同一张脸在不同帧被识别成 happy 和 sad非常不稳定。原因表情数据分布不均衡是最主要的原因。公开数据集中 neutral 和 happy 数量可能占 60%fear 和 disgust 可能各不到 5%。YOLOv11 默认用普通交叉熵损失少数类别学不到判别特征推理时自然在低置信度区间乱飘。另一个原因是标签噪声某些人脸的表情本来就是模棱两可的标注者自己都可能分错。解决我一般会先统计每个类别的样本量对少数类做过采样复制或者对图像使用随机水平翻转、亮度变化和轻微旋转来扩增。效果更直接的是在训练命令里开启 MixUp 增强yolo detect train \ modelyolov11n.pt \ dataexpression_dataset.yaml \ epochs120 \ batch16 \ imgsz640 \ mixup0.2mixup0.2让模型在训练时看到更多类间混合样本对不平衡数据有一定缓解。如果还不够可以把少数类别的标签先人工清洗一遍去掉明显标错的图片效果往往比调参更明显。5.3 第 3 个坑人脸密集叠加时漏检和重叠框严重现象单人或两人场景正常一到教室、会议或地铁这种多人脸场景经常漏掉后排小脸同时前排人脸出现多个重叠框一个框把整张脸包住另一个框只框住下半张脸。原因这是 NMS 参数和输入分辨率共同导致的。人脸框本身是近乎方形的彼此之间 IOU 偏高容易在 NMS 阶段被合并或误删后排人脸像素面积太小模型在 640 输入下很难提取有效特征。解决推理时把iou从 0.45 降下来同时限制最大检测数results model.predict( sourcecrowd.jpg, conf0.2, iou0.3, max_det50, saveTrue )参数说明iou0.3会让 NMS 对重叠框更敏感减少重复框max_det50保证一张图最多输出 50 张人脸防止误检无意义的小框。如果还是漏检训练时把imgsz提高到 1280并适度增加hsv_h、hsv_s等增强参数让模型见过更多尺度变化。这是 YOLOv11 小目标优化最常见的做法不要一开始就想着改网络结构。5.4 第 4 个坑自定义模型加载时报 names 文件或类别索引不一致现象模型训练完成后在训练环境里推理一切正常换到另一台机器或者用 OpenCV DNN 加载导出的 ONNX 时输出类别名称变成0、1、2或者一堆 unknown系统代码怎么也接不上。原因这就是典型的自定义模型类别对齐问题。best.pt里保存的model.names来自训练时的 YAML但你在部署代码里很可能硬编码了一个类别列表两者顺序不一致。我的习惯是在训练脚本里直接把 YAML 路径传给模型导出时也保留同样的 names而不是在推理代码里重新写一份字典。解决加载模型后先打印模型自带的名字表model YOLO(runs/expression/train_v1/weights/best.pt) print(model.names) # 正确输出{0: neutral, 1: happy, 2: sad, 3: surprise, 4: fear, 5: angry, 6: disgust}如果部署端需要自定义一个 names 映射必须用这段输出做基准逐 key 对齐。不要凭记忆写这个坑我踩了不止一次最后发现是训练时把某两个类别的顺序交换了。5.5 第 5 个坑视频推理 FPS 上不去GPU 显存没吃满现象在 GPU 上做视频推理任务管理器显示 GPU 利用率只有 30%FPS 大概 10 帧左右训练时明明很快推理却很慢。原因很可能是模型太大、输入分辨率太高或者是图像解码环节卡在 CPU 上。还有一个小问题是 PyTorch 默认在每次推理时重新调整卷积算法导致时间开销不稳定。很多人以为部署就必须用大模型实际上 YOLOv11 nano 在表情识别这种七分类任务上已经完全够用。解决先用半精度推理和不重新评估 BN 层来加速model YOLO(runs/expression/train_v1/weights/best.pt) results model.predict(sourcevideo.mp4, halfTrue, verboseFalse)halfTrue会把输入和权重切到 FP16在 NVIDIA GPU 上能明显提速但要注意半精度在部分老显卡上可能不支持。如果再配上torch.backends.cudnn.benchmark True对固定输入尺寸的视频流推理会更稳。视频源如果来自摄像头尽量先调整到模型输入分辨率再推理而不是让模型内部去做放大缩小。6. 进阶验证与部署技巧把 YOLOv11 表情识别变成可交付的视频流推理6.1 用预测结果做结构化输出JSON 里面的人脸坐标与表情置信度很多业务系统并不关心可视化框它们要的是“这一帧里谁在什么位置、表情是什么、置信度多少”。这时候把预测结果导出成 JSON 比保存图片更实用。我通常在推理脚本里顺手做一层结构化封装import json from ultralytics import YOLO model YOLO(runs/expression/train_v1/weights/best.pt) result model(test.jpg, verboseFalse)[0] faces [] for box in result.boxes: faces.append({ class: result.names[int(box.cls)], confidence: round(float(box.conf), 4), bbox: [round(v, 2) for v in box.xyxy[0].tolist()] }) with open(result.json, w, encodingutf-8) as f: json.dump({faces: faces}, f, ensure_asciiFalse, indent2)这段代码把每个检测框的类别、置信度和左上右下坐标写进 JSON方便后续接业务逻辑。参数上要注意result.names[int(box.cls)]一定来自模型自身的 names前端展示也需要用同一个映射。我一般还会把整张图的原始宽高一并写入否则下游同学无法还原图上坐标。6.2 导出到 ONNX/TensorRT部署时该保守的地方训练不是终点部署环境往往没有 Python、没有 PyTorch。常见做法是用 YOLOv11 导出 ONNX再转成 TensorRT engine在 GPU 上做低延迟推理# 导出 ONNX yolo export modelbest.pt formatonnx imgsz640 halfTrue # 在 NVIDIA GPU 上导出 TensorRT engine yolo export modelbest.pt formatengine device0 imgsz640 halfTrue导出 ONNX 后用onnxruntime做推理验证是一个很稳的步骤。TensorRT 引擎和显卡驱动、CUDA 版本高度绑定换一台机器往往需要重新导出所以别指望把它当便携文件拷来拷去。我在部署时会在服务器上跑一段测试视频统计平均延迟和每类表情的置信度分布确认与 PyTorch 推理结果基本一致后再上线。这个项目最让我印象深刻的教训是不管训练指标多漂亮都要在“目标机器”上做一次端到端验证。之前我习惯把所有参数调到极限imgsz 拉到 1280mAP 确实高了一点但 TensorRT 在边缘设备上的延迟直接翻倍得不偿失。后来我改成先在目标设备上导出再根据实际 FPS 回推训练参数反而少走了很多弯路。如果你也是第一次接触自定义 YOLO 模型建议从 nano 权重、640 分辨率、一份干净的小数据集开始先把闭环跑通再慢慢优化小脸和速度。希望帮到你。本文还有配套的精品资源点击获取