基于YOLOv11自定义模型的人脸检测与表情识别系统实践指南

简介：一份面向深度学习与计算机视觉开发者的人脸检测与表情识别项目资源，以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 在这里的角色，本质上是把目标定位和表情分类合并成一个多任务学习问题。每个预测框输出六元组：中心坐标、宽高、目标置信度和表情类别分布。对比传统人脸检测器加分类器的做法，我列了一张选型表：

选型上有一些例外：如果你只需要单人脸且人脸已经对齐，纯分类网络仍然更简单；如果场景里需要额外输出人脸关键点做活体检测，那 YOLO 也要搭配一个关键点模型。但就题目里的“人脸检测 + 表情识别”而言，把两者合成一个自定义 YOLO 模型是当前性价比最高的方案。

3. 自定义 YOLO 模型训练前的准备工作：环境、数据集与标签格式

3.1 环境配置：适合 0 基础纯小白的 ultralytics 安装与显卡检查

先把环境搭起来，这一步不麻烦，但很多纯新手会卡在“到底装 CPU 版还是 GPU 版”。我一般建议用 Conda 建独立环境，避免把系统 Python 弄乱：

# 建一个 Python 3.10 的虚拟环境 conda create -n yolo11 python=3.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 python=3.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 保持一致：

我踩过的坑是：有些开源数据集会把disgust去掉，只保留六类，如果你直接沿用别人的data.yaml，类别 ID 全部错位，训练出来的模型把 angry 识别成 disgust。所以切数据之前，先统计一遍每个类别实际有哪些标签，再生成 YAML。标注顺序一旦确定，整个训练周期内不要改。

4. 从零训练一个 YOLOv11 表情识别模型：命令、参数与推理保存

4.1 下载预训练权重并自定义 YAML：yolov11n.pt 与模型结构的选择

第一次运行训练命令时，Ultralytics 会自动下载yolov11n.pt权重文件，不需要手动到处找资源。如果你希望更稳，可以先用一个明确指定模型的命令行，让它把权重拉下来：

# 自动下载并训练，以 yolov11n 作为预训练起点 yolo detect train \ model=yolov11n.pt \ data=expression_dataset.yaml \ epochs=100 \ batch=16 \ imgsz=640

参数说明：model=yolov11n.pt是 nano 版本，参数量最小，显存占用低，适合 0 基础新手；如果场景里人脸多且密集，可以换成yolov11s.pt或yolov11m.pt。imgsz=640是训练输入尺寸，不是最终部署尺寸。名人脸或小脸场景建议把imgsz调到 768 甚至 1280，但显存和训练时间会随之上升。

权重选择这块，我一般按显卡显存来定。8GB 显存用yolov11n没问题；16GB 可以上yolov11s；32GB 显存跑yolov11m比较舒服。YOLOv11 继续沿用 n/s/m/l/x 的层级划分，参数量和计算量递增，但精度不一定线性上涨，尤其表情识别这种数据量不大的任务，nano 和 small 的差距可能很小。

4.2 训练命令与必须调的 4 个超参数（batch/img/epochs/optimizer）

训练命令看起来很直接，但真正决定成败的是下面这几个超参数。我给出一套适合表情识别起步的训练命令，并逐一说明：

# 表情识别训练命令，推荐在 GPU 服务器上执行 yolo detect train \ model=yolov11n.pt \ data=expression_dataset.yaml \ epochs=120 \ imgsz=640 \ batch=32 \ optimizer=SGD \ lr0=0.01 \ patience=20 \ cache=True \ project=runs/expression \ name=train_v1

参数解释：epochs=120对于自定义表情数据集来说不算大，因为量级通常只有几千到几万张，训练太久容易过拟合；batch=32需要根据显存修改，如果报CUDA out of memory，就先降到 16 或 8；imgsz=640是速度和精度的折中，人脸占比小就上调；optimizer=SGD是我在数据量不大时的保守选择，AdamW 也能用，但要配更低的学习率。

还有两个隐藏参数值得注意。patience=20是早停机制，连续 20 个 epoch 验证集 mAP 不提升就停止，避免训练到后期反复震荡。cache=True在训练开始前把图像预先加载进内存，能显著缩短每个 epoch 的等待时间，但内存不够时不建议开。

如果你发现模型对小脸表情识别效果差，不要急着换网络结构，先把这个参数调大：

# 加大输入尺寸，小脸优化最直接的手段 yolo detect train \ model=yolov11n.pt \ data=expression_dataset.yaml \ epochs=120 \ imgsz=1280 \ batch=8

imgsz=1280会让 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") # 对图片推理，save=True 会把标注结果保存到 runs/infer/demo 目录 results = model.predict( source="test.jpg", conf=0.25, iou=0.45, save=True, project="runs/infer", name="demo" ) # 同时把结果对象打印出来，方便调试 for result in results: print(result.boxes.xyxy) # 人脸框坐标 print(result.boxes.cls) # 表情类别索引 print(result.boxes.conf) # 置信度

逻辑说明：source可以是图片路径、视频路径或摄像头序号；conf=0.25是置信度阈值，低于这个值的框会被过滤，表情识别场景里这个值建议在 0.2 到 0.3 之间，调太高容易漏检；iou=0.45是 NMS 的 IOU 阈值，人脸密集时建议降到 0.3，防止重叠框被误删；save=True会自动把标注图像保存到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 \ model=yolov11n.pt \ data=expression_dataset.yaml \ epochs=120 \ batch=16 \ imgsz=640 \ mixup=0.2

mixup=0.2让模型在训练时看到更多类间混合样本，对不平衡数据有一定缓解。如果还不够，可以把少数类别的标签先人工清洗一遍，去掉明显标错的图片，效果往往比调参更明显。

5.3 第 3 个坑：人脸密集叠加时漏检和重叠框严重

现象：单人或两人场景正常，一到教室、会议或地铁这种多人脸场景，经常漏掉后排小脸，同时前排人脸出现多个重叠框，一个框把整张脸包住，另一个框只框住下半张脸。

原因：这是 NMS 参数和输入分辨率共同导致的。人脸框本身是近乎方形的，彼此之间 IOU 偏高，容易在 NMS 阶段被合并或误删；后排人脸像素面积太小，模型在 640 输入下很难提取有效特征。

解决：推理时把iou从 0.45 降下来，同时限制最大检测数：

results = model.predict( source="crowd.jpg", conf=0.2, iou=0.3, max_det=50, save=True )

参数说明：iou=0.3会让 NMS 对重叠框更敏感，减少重复框；max_det=50保证一张图最多输出 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(source="video.mp4", half=True, verbose=False)

half=True会把输入和权重切到 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", verbose=False)[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", encoding="utf-8") as f: json.dump({"faces": faces}, f, ensure_ascii=False, indent=2)

这段代码把每个检测框的类别、置信度和左上右下坐标写进 JSON，方便后续接业务逻辑。参数上要注意result.names[int(box.cls)]一定来自模型自身的 names，前端展示也需要用同一个映射。我一般还会把整张图的原始宽高一并写入，否则下游同学无法还原图上坐标。

6.2 导出到 ONNX/TensorRT：部署时该保守的地方

训练不是终点，部署环境往往没有 Python、没有 PyTorch。常见做法是用 YOLOv11 导出 ONNX，再转成 TensorRT engine，在 GPU 上做低延迟推理：

# 导出 ONNX yolo export model=best.pt format=onnx imgsz=640 half=True # 在 NVIDIA GPU 上导出 TensorRT engine yolo export model=best.pt format=engine device=0 imgsz=640 half=True

导出 ONNX 后用onnxruntime做推理验证，是一个很稳的步骤。TensorRT 引擎和显卡驱动、CUDA 版本高度绑定，换一台机器往往需要重新导出，所以别指望把它当便携文件拷来拷去。我在部署时会在服务器上跑一段测试视频，统计平均延迟和每类表情的置信度分布，确认与 PyTorch 推理结果基本一致后再上线。

这个项目最让我印象深刻的教训，是不管训练指标多漂亮，都要在“目标机器”上做一次端到端验证。之前我习惯把所有参数调到极限，imgsz 拉到 1280，mAP 确实高了一点，但 TensorRT 在边缘设备上的延迟直接翻倍，得不偿失。后来我改成先在目标设备上导出，再根据实际 FPS 回推训练参数，反而少走了很多弯路。

如果你也是第一次接触自定义 YOLO 模型，建议从 nano 权重、640 分辨率、一份干净的小数据集开始，先把闭环跑通，再慢慢优化小脸和速度。希望帮到你。

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