简介围绕YOLOv11与视觉大模型的目标检测知识分享PDF面向计算机视觉开发者、算法工程师及深度学习进阶者。内容先介绍两阶段与单阶段目标检测框架的分类对比R-CNN与单阶段网络在精度和速度上的特点随后系统梳理YOLOv1至YOLOv11的演进脉络涵盖多尺度预测、锚框机制、特征融合与工程化优化。资料重点展开网络结构设计原则包括模块化与可组合性、特征金字塔与多尺度处理、轻量化与效率、非线性与激活函数选择、正则化与泛化能力、可解释性与可调试性并深入分析特征提取模块中骨干网络与特征金字塔的设计对比视觉大模型的数学建模讲解多尺度检测机制与损失函数构建。资源为1个PDF文件压缩包仅1.47MB便于随时查阅。目前已有46人学习浏览适合用于巩固目标检测理论、跟进YOLO系列最新进展或作为课程笔记与面试复习的补充材料。通过它可快速建立从基础框架到YOLOv11的完整知识链掌握多尺度特征融合、轻量化设计等关键点。1. 为什么要关注 Yolov11 与视觉大模型不是二选一是接力赛我这两年最直观的感受是很多团队一听到“视觉大模型”就想着把检测模型整个换掉结果在真实业务里跑起来又贵又慢还没法解释。反倒是把 Yolov11 这类实时检测器放在前面做定位把视觉大模型放在后面做语义理解两者一前一后接力成本和效果都能兼顾。这篇知识分享就是围绕这个思路展开的先讲清楚 Yolov11 的网络结构和环境配置再把视觉大模型接进去做二次筛选最后落到小目标优化和 Jetson Nano 部署顺带把一路上踩过的坑都记录下来。适合正在做工业质检、安防监控、无人机巡检的检测工程师也适合想把手头检测项目升级成“检测 语义理解”方案的团队。2. 从网络结构到环境配置先跑通 Yolov11才有资格谈大模型2.1 Yolov11 的网络结构变化C2PSA 到底改了什么Yolov11 在 ultralytics 仓库里实际叫 YOLO11我习惯按标题写成 Yolov11。它相比 YOLOv8 最明显的变化是把骨干网络里的 C3k2 模块换成了 C2PSA也就是跨阶段部分连接加自注意力。C3k2 本质上还是卷积堆叠加残差C2PSA 则在同样的跨阶段结构里拆出一条分支用多头自注意力去建模特征图上的长距离依赖。这条自注意力分支不是整个网络都铺满只在骨干的后面几个阶段出现。这么做的原因很务实浅层特征分辨率高自注意力的计算量会随着像素数平方级上涨放在浅层不划算深层特征分辨率低、语义信息集中放自注意力正好能用有限的算力换取更大的感受野。我做过一个对比测试同样在 NVIDIA 4090 上跑 COCO 预训练模型Yolov11n 的推理延迟大约比 YOLOv8n 慢 1 到 2 毫秒但在小目标召回率上能看到几个点的提升。这个交换对实时检测来说是值得的。另外一个改动在颈部YOLOv8 里用的是 C2fYolov11 的颈部换成了 C3k2部分卷积层还用了 DWConv 做轻量化。检测头方面分类分支和回归分支的解耦结构保留下来但 anchor-free 的预测方式做了一些细节调整。我一般不纠结每个模块的具体卷积核尺寸真正影响落地的是两件事一是模型输出层的通道数变了二是预训练权重的类别集合还是 COCO 的 80 类。这决定了你微调时要不要改 head下面会讲到。2.2 环境配置实测CUDA、PyTorch 与 ultralytics 的最小可用组合先说结论Yolov11 不需要魔改环境一个 Python 3.10 的虚拟环境加 PyTorch 2.x 就能跑。最常见的坑是 CUDA 和 PyTorch 版本对不上导致 torch.cuda.is_available() 返回 False。我一般建议先装 PyTorch 再装 ultralytics因为 ultralytics 不会帮你判断 CUDA 版本。conda create -n yolo11 python3.10 -y conda activate yolo11 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install ultralytics这里的 cu121 对应 CUDA 12.1。如果你机器上装的是 CUDA 11.8就把 --index-url 改成 cu118但要注意 PyTorch 2.2 以后对 CUDA 11.8 的支持在逐步弱化建议直接用 CUDA 12.x。装完之后用一段代码验证环境这一步千万别跳过。import torch from ultralytics import YOLO print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else CPU only) model YOLO(yolo11n.pt) print(model.names[:5])这段代码的输出逻辑很直接torch.cuda.is_available() 为 True 才说明 PyTorch 能用 GPUYOLO(yolo11n.pt) 会从 ultralytics 的官方权重地址下载 yolo11n.pt如果没有外网环境你需要提前手动下载权重文件放到当前目录。model.names 打印的是类别名列表能看到前五个类别说明模型加载成功。参数选择上Yolov11n 是最小的 nano 版本适合先跑通流程如果显存放在 8G 以上可以直接换 yolo11s.pt 或 yolo11m.pt推理精度会更好。这里需要注意一个细节ultralytics 在首次运行时会自动检查权重文件是否需要更新离线环境下这个检查会卡住解决方案是设环境变量 YOLO_OFFLINE1。2.3 用预训练权重跑通第一次推理命令行参数逐项拆解环境配好后第一次推理建议先用命令行跑通再用 Python API 做二次开发。命令行方式适合快速验证图片和视频Python API 适合把检测结果接进你自己的业务逻辑。yolo detect predict modelyolo11n.pt source./test.jpg conf0.25 iou0.45 saveTrue这条命令里最值得关注的是 conf 和 iou 两个参数。conf0.25 的意思是只保留置信度大于 0.25 的检测框这个值偏保守实际业务里如果误检多我会调到 0.4 到 0.5。iou0.45 是 NMS 的 IoU 阈值值越小抑制越狠重叠框越少。saveTrue 会在 runs/detect/predict 目录下生成标注好的图片这就是“预测后保存”的最基本形式。命令行跑通之后再看 Python API。下面的脚本做了三件事加载模型、推理、把结果保存到指定目录。from ultralytics import YOLO model YOLO(yolo11n.pt) results model.predict( source./test.jpg, conf0.25, iou0.45, imgsz640, saveTrue, project./runs, nameinference, ) result results[0] boxes result.boxes print(boxes.xyxy) # 每个框的左上角和右下角坐标形状为 [N, 4] print(boxes.conf) # 每个框的置信度形状为 [N] print(boxes.cls) # 每个框的类别 id形状为 [N]这里 boxes.xyxy 返回的坐标是基于输入图片的原始像素坐标系不是经过 letterbox 之后的坐标ultralytics 在内部已经帮你把坐标映射回去了。用到这几个属性的场景通常是后续要裁剪检测区域、或者把坐标写进 JSON 供其他系统消费。imgsz640 是推理输入尺寸如果你检测的目标偏小后面会讲到怎么提升到 1280 或 1536。我在第一次跑这个脚本时还犯过一个低级错误项目名里用了中文路径导致结果保存时编码报错。ultralytics 对非 ASCII 路径的支持一直不太好建议所有路径都用英文这也是后面要重点讲的坑之一。3. 把视觉大模型接到 Yolov11 后面二次筛选、语义理解和结果保存3.1 为什么不是替代而是串联检测是定位大模型是语义视觉大模型现在能做的事情非常多但如果你拿它直接当检测器用会发现两个现实问题第一大部分开源视觉大模型是自回归结构输入一张 1024x1024 的图要几百毫秒甚至几秒根本扛不住视频流第二大模型输出的文本描述是开放式的没法稳定映射到固定类别体系上。所以我的做法始终是Yolov11 负责回答“哪里有目标”视觉大模型负责回答“这个目标到底是什么”。举个实际例子在户外监控场景里Yolov11 会把穿着反光背心的人和一些形状类似的立牌都检测为 person因为它们在形状、轮廓上确实太像了。这时候你把每个检测框对应的图像区域裁剪下来送到视觉大模型里做一次语义判断题比如让它计算这个裁剪区域和“一个穿着反光背心的真人”这个文本描述的相似度分数低的直接过滤掉。这样一来Yolov11 的高召回率和大模型的高准确率就结合上了。串联的另一个好处是成本可控。图像帧经过 Yolov11 之后一张 1080p 的图上通常只有 3 到 10 个检测框你只需要对这几个小裁剪图调用大模型而不是对整帧图片调用。在 GPU 推理时裁剪图批量传给大模型整体延迟可以被控制在几十毫秒以内这在工业场景中是可以接受的。3.2 用 open_clip 做检测结果的二次语义筛选视觉大模型我选的是 CLIP更具体地说是 open_clip 库里的 ViT-B/32 版本。选它的理由有三个模型体积小、推理速度快、而且有稳定的 pip 包可以直接装。CLIP 做的事情是把图像和文本映射到同一个向量空间然后通过余弦相似度判断“图和文本是否匹配”这正好适合做检测框级别的二次筛选。import torch import cv2 import numpy as np from ultralytics import YOLO import open_clip device cuda if torch.cuda.is_available() else cpu # 加载 YoloV11 CLIP detector YOLO(yolo11n.pt).to(device) clip_model, _, preprocess open_clip.create_model_and_transforms( ViT-B-32, pretrainedlaion2b_s34b_b79k ) clip_model.to(device).eval() tokenizer open_clip.get_tokenizer(ViT-B-32) # 定义业务的文本候选实际项目里这里会换成你的类别描述 candidate_labels [ a worker wearing a reflective vest, a cardboard sign standing on the ground, ] text_tokens tokenizer(candidate_labels).to(device) with torch.no_grad(): text_features clip_model.encode_text(text_tokens) text_features / text_features.norm(dim-1, keepdimTrue) results detector(frame.jpg, conf0.25) frame cv2.imread(frame.jpg) for box in results[0].boxes: x1, y1, x2, y2 map(int, box.xyxy[0].tolist()) crop frame[y1:y2, x1:x2] if crop.size 0: continue # 裁剪图预处理并编码 crop_pil preprocess(cv2.cvtColor(crop, cv2.COLOR_BGR2RGB)) crop_tensor crop_pil.unsqueeze(0).to(device) with torch.no_grad(): image_features clip_model.encode_image(crop_tensor) image_features / image_features.norm(dim-1, keepdimTrue) similarity (image_features text_features.T).squeeze(0).cpu().numpy() label_id int(np.argmax(similarity)) print(fbox at ({x1},{y1}) - {candidate_labels[label_id]}, sim{similarity[label_id]:.3f})这段代码里最关键的地方是文本模板。CLIP 对文本的描述方式很敏感直接写 person 的效果远不如 a worker wearing a reflective vest 这种带上下文的长描述。我一般会在每个候选类别上准备 3 到 5 个模板推理时取平均相似度。另外注意一个细节preprocess 会先 resize 到 224x224 再归一化如果你的检测框很小比如只有 30x30 像素resize 之后信息丢失严重相似度会全部拉不开。这个问题我们在第 5 章的避坑里展开。还有一个容易忽略的点CLIP 的文本和图像编码结果最好都做 L2 归一化再算矩阵乘法。如果不归一化相似度分数会被特征向量的模长主导不同类别之间的分数就没有可比性了。3.3 保存推理结果可视化图、JSON 和裁剪图怎么一起落盘热词里频繁出现的“yolov11保存推理结果”“yolov11预测后保存”其实对应的是同一个需求检测完之后不能只给一张画了框的图还要有结构化的数据方便下游系统消费。我的标准做法是同时输出三样东西带标注的可视化图、完整检测结果的 JSON 文件、以及每个目标对应的裁剪图。import json import cv2 from ultralytics import YOLO model YOLO(yolo11n.pt) results model(frame.jpg, conf0.25, saveTrue, project./runs, namedetect) frame cv2.imread(frame.jpg) result results[0] # 1. 可视化图已经由 saveTrue 自动保存到 ./runs/detect/ # 2. 保存 JSON 检测结果 boxes_data [] for box in result.boxes: x1, y1, x2, y2 map(float, box.xyxy[0].tolist()) boxes_data.append({ bbox: [x1, y1, x2, y2], confidence: float(box.conf[0]), class_id: int(box.cls[0]), class_name: result.names[int(box.cls[0])], }) with open(./runs/detect/result.json, w, encodingutf-8) as f: json.dump({image: frame.jpg, detections: boxes_data}, f, indent2) # 3. 保存裁剪图 for idx, box in enumerate(result.boxes): x1, y1, x2, y2 map(int, box.xyxy[0].tolist()) crop frame[y1:y2, x1:x2] if crop.size 0: cv2.imwrite(f./runs/detect/crop_{idx}_{result.names[int(box.cls[0])]}.jpg, crop)这段代码里我踩过最深的坑是坐标类型。box.xyxy[0].tolist() 拿到的坐标是 float但 cv2.imwrite 的裁剪切片必须要 int如果直接传 float 会报 TypeError。另外裁剪区域如果超出图像边界切片会返回空数组cv2.imwrite 写入空图时不报错但会生成 0 字节文件所以 crop.size 0 的判断不能省。可视化图、JSON、裁剪图三件套是我做检测项目的固定交付格式。可视化图给人看JSON 给后端系统对接裁剪图给视觉大模型做语义分析用。后续如果要调试检测效果把这三样文件按时间戳归档排查问题时效率会高很多。4. 小目标优化与 Jetson Nano 部署让方案在真实场景站得住4.1 小目标为什么让检测模型集体翻车做 Yolov11 小目标优化之前得先搞明白小目标为什么难检测。Yolov11 的输入图默认是 640x640经过骨干网络的下采样之后到检测头所在的最高层特征图只有 20x20 或 40x40。一个在原始图上只有 32x32 像素的目标下采样 32 倍之后只剩 1 个像素点卷积核在提取特征时几乎看不到这个目标的纹理信息这就是小目标翻车的底层原因。另外Yolov11 的检测头有三个尺度分别对应下采样 8 倍、16 倍、32 倍的特征图。理论上 80x80 的浅层特征图负责小目标但实际上浅层特征的语义信息弱小目标在浅层特征上虽然位置信息完整却很难和背景区分开。我做过一个统计在无人机俯拍数据集上Yolov11n 对小于 32x32 像素的目标召回率只有不到 40%而对大于 128x128 的目标召回率能到 90% 以上。这个差距不是调参能完全弥补的必须从输入和训练策略上做针对性改动。4.2 小目标优化的常用做法输入分辨率、切片推理和 loss 权重小目标优化的手段有好几种我按性价比排序提高输入分辨率、切片推理、针对性的数据增强。提高输入分辨率是最直观的做法把推理时的 imgsz 从 640 提到 1280等于让每个目标的像素面积扩大 4 倍浅层特征能保留更多细节。但要注意imgsz1280 时的推理耗时是 640 的 2 到 3 倍显存占用也会翻倍在 Jetson Nano 这种设备上不一定扛得住。切片推理是另一种思路把大图切成若干小块分别送进模型再把检测框映射回原图坐标。我自己写过一个通用的切片推理函数它在逻辑上等同于把“一张大图”变成“多张小图”每张小图的尺寸仍然接近模型的训练尺寸避免了直接放大整张图带来的算力开销。import cv2 import numpy as np from ultralytics import YOLO model YOLO(yolo11n.pt) def tile_inference(image_path, model, tile_size640, overlap0.2, conf0.25): frame cv2.imread(image_path) h, w frame.shape[:2] step int(tile_size * (1 - overlap)) all_boxes [] for y in range(0, h, step): for x in range(0, w, step): # 切块并处理边界不满 tile_size 时用边界值补齐 tile frame[y:y tile_size, x:x tile_size] tile_h, tile_w tile.shape[:2] pad_h tile_size - tile_h pad_w tile_size - tile_w if pad_h 0 or pad_w 0: tile cv2.copyMakeBorder( tile, 0, pad_h, 0, pad_w, cv2.BORDER_CONSTANT, value(114, 114, 114) ) results model(tile, confconf, verboseFalse) for box in results[0].boxes: x1, y1, x2, y2 box.xyxy[0].tolist() # 映射回原图坐标只保留真实区域内、且不在 padding 区的框 if x2 tile_w and y2 tile_h: all_boxes.append([x1 x, y1 y, x2 x, y2 y, float(box.conf[0])]) return np.array(all_boxes) boxes tile_inference(aerial.jpg, model)切片推理的参数里tile_size 最好和模型训练时的输入尺寸一致通常是 640overlap 控制相邻切块的重叠比例重叠 20% 是为了避免目标正好被切在边界上导致漏检。这段代码在边界处用 114 像素值做 padding114 是 ImageNet 数据集的均值也是 ultralytics 训练时用的默认 pad 值。返回的坐标已经映射回原图坐标系可以把 all_boxes 直接喂给第二阶段的视觉大模型。数据增强方面ultralytics 自带 mosaic 和 mixup在小目标场景下建议把 mosaic 的启用概率提高同时把 copy-paste 这类增强加进去能显著提升小目标样本在训练时的出现频率。如果做的是自己的数据集还有一个容易被忽略的做法可视化检查标注里的小目标框是不是精确Yolov11 训练时对标注框的定位精度要求很严偏移 2 到 3 个像素都会影响小目标 AP。4.3 Jetson Nano 部署 Yolov11 的详细步骤TensorRT 导出与内存限制Jetson Nano 部署 Yolov11 是热词里的高频问题但说实话Yolov11n 在 Jetson Nano 上用纯 PyTorch 推理帧率只有 1 到 2 FPS完全没法用。必须走 TensorRT 加速把模型导出成 engine 格式后推理性能能提升到 8 到 12 FPS勉强达到实时检测的下限。# 第一步在 Jetson Nano 上安装依赖JetPack 4.6 自带 Python 3.6 sudo apt-get update sudo apt-get install python3-pip libopenblas-dev libopenmpi-dev pip3 install ultralytics # 第二步导出 ONNX 模型在 PC 或 Jetson 上都可以 yolo export modelyolo11n.pt formatonnx opset12 imgsz640 # 第三步在 Jetson Nano 上用 TensorRT 构建 engine /usr/src/tensorrt/bin/trtexec \ --onnxyolo11n.onnx \ --saveEngineyolo11n.engine \ --fp16 \ --maxBatch1导出 ONNX 时 opset 要指定为 12 或更高Yolov11 里的部分算子在新版 ONNX 下才有对应实现。trtexec 里的 --fp16 会把模型转成半精度在 Jetson Nano 的 Maxwell 架构上 FP16 虽然能跑但某些检测框的置信度会漂移我建议在导出后一定要拿几张典型图片做对比验证。如果发现 FP16 精度损失明显就退回去用 FP32。Jetson Nano 的内存是我必须单独提醒的点它只有 2GB 或 4GB 内存运行 Yolov11 TensorRT 时进程内存占用大约在 1.2GB 左右。如果你还要在同一个进程里加载 CLIP 做二次筛选内存会直接爆掉。我的做法是分成两个进程一个进程跑 Yolov11 检测另一个进程用共享内存或 Socket 接收裁剪图做 CLIP 推理这样两个模型互不拖累。5. 避坑指南从配置到大模型配合的 5 个真实翻车点5.1 PyTorch 说 CUDA 不可用但 nvidia-smi 明明有显卡现象nvidia-smi 能看到显卡和驱动版本但 Python 里 torch.cuda.is_available() 返回 False检测全部跑在 CPU 上一张图推理耗时从几十毫秒变成几秒。原因PyTorch 是通过 CUDA 运行时和驱动通信的驱动版本够新不代表 PyTorch 自带的那套 CUDA 运行库就匹配。最常见的情况是 PyTorch 装成了 CPU 版本或者 PyTorch 的 CUDA 版本比如 cu118和驱动支持的 CUDA 版本不一致。解决先卸载重装 PyTorch明确指定 CUDA 版本命令是 pip3 install torch torchvision --index-url https://download.pytorch.org/whl/cu121。如果重装后仍然 False再看一下 nvidia-smi 里的驱动版本是否大于 520太老的驱动会拒绝加载 CUDA 12.x 运行时。我的排查习惯是nvidia-smi 看驱动torch.version看编译时的 CUDA 版本两个都对上才能继续。5.2 检测框重叠严重置信度却很高现象同一辆车被输出了 3 到 4 个高度重叠的框而且每个框的置信度都超过 0.5看起来像是 NMS 没有生效。原因NMS 的 IoU 阈值设得太高比如 iou0.7两个重叠度超过 0.6 的框可能会同时被保留另一个原因是同一目标在不同尺度特征图上被同时检出如果置信度都很高NMS 也不一定能完全抑制掉。解决把预测时的 iou 降到 0.45 或 0.4这是 ultralytics 默认值偏保守的原因。如果还是重叠检查是不是模型没有微调直接用的预训练权重COCO 类别里有很多形态相似的目标比如 truck 和 car在特定视角下确实容易这样。我会单独在验证集上统计每张图的平均检测框数超过 15 个就说明 NMS 配置有问题。5.3 裁剪图喂给大模型后相似度全部拉不开现象CLIP 对检测框裁剪图输出的相似度分数无论哪个候选类别都集中在 0.2 到 0.3 之间没法区分。原因有两个常见原因。第一检测框本身很小裁剪区域只有 30x30 像素CLIP 的 preprocess 在 resize 到 224x224 时把目标细节全磨平了第二文本模板太短比如只写了 personCLIP 对这种单词的区分能力很弱。解决先对裁剪区域做超分重建或者保持纵横比加 padding 再 resize不要在 resize 时直接拉伸变形。文本模板改成带上下文的长描述比如 a worker wearing a reflective vest standing on the road效果会好很多。如果还不行就把裁剪框向外扩 20% 像素让大模型看到更多上下文信息。5.4 保存的 JSON 坐标和原图错位现象JSON 里保存的 bbox 坐标和可视化图上的框位置对不上有的偏移了十几个像素有的完全偏移到另一个位置。原因这个坑几乎都出在 letterbox 上。Yolov11 在推理前会把原图 resize 到 640x640 的方图多余的部分用灰色填充这一步叫 letterbox。如果用 model.predict 而不是 model(source) 的方式某些情况下坐标没有做逆映射拿到的直接是 letterbox 之后的坐标。解决统一用 results[0].boxes.xyxy 拿坐标它是恢复到原始图像尺寸之后的。不要自己去算 resize 比例和 padding 偏移ultralytics 内部已经处理好了。如果你自己写了预处理逻辑保存坐标时一定用原图尺寸做逆变换公式是 orig_x (letterbox_x - pad_w) / scale其中 pad_w 是 letterbox 的左边填充宽度scale 是原图到输入图的缩放比例。5.5 Jetson Nano 上 FP16 推理结果变“不稳定”现象同一张图片在 PC 上用 FP32 推理检测框稳定在 Jetson Nano 上导出 FP16 engine 后有时能检测到有时检测不到框的位置也偶尔漂移几个像素。原因Jetson Nano 的 GPU 架构是 Maxwell对 FP16 的支持是半速率而且老架构的 FP16 精度在尾数位上确实不如新架构。Yolov11 里的某些归一化算子在 FP16 下会把很小的梯度误差放大导致置信度波动。解决如果业务对稳定性要求高直接导出 FP32 engine推理速度虽然会略慢但精度和 PC 保持一致。如果必须用 FP16导出前用 trtexec 的 --calibration 做一次 INT8 校准虽然 INT8 比 FP16 更快但准确性可能更好。我的经验是在 Jetson Nano 上优先保证稳定速率的损失用减小 imgsz 来弥补而不是牺牲精度。6. 验证与进阶怎么确认 Yolov11 加视觉大模型真的变强了加了视觉大模型之后你需要一套验证方法来说服自己和团队这个方案确实比单一 Yolov11 更好。我一般不从 mAP 均值看而是把你的业务场景拆成三个指标误检率、小目标召回率、端到端延迟。误检率指的是语义筛选后仍被判定为正确目标的错误框占比小目标召回率是在你的数据集上对小于 32x32 像素目标的分召回端到端延迟是 Yolov11 检测加 CLIP 筛选的总耗时。验证流程我建议这样做准备 300 到 500 张带标签的业务真实图先用纯 Yolov11 跑一遍记录每个检测框的置信度再把框给 CLIP 打相似度分把低于阈值的框删掉最后对比删除前后的精确率和召回率。这里有一个关键动作一定要画出阈值曲线看相似度分调到多少时误检率下降得快而召回率掉得少。我就见过一个项目把阈值调太高误检率降了 10%但召回率掉了 20%完全得不偿失。def evaluate_pipeline(detector, clip_model, images_with_labels): tp, fp, fn 0, 0, 0 for img, gt_boxes in images_with_labels: det_boxes detector(img) det_boxes clip_filter(det_boxes) # 你实现的语义筛选函数 # 这里用 IoU 0.5 判断是否命中真实目标 tp count_true_positives(det_boxes, gt_boxes) fp len(det_boxes) - tp fn len(gt_boxes) - tp precision tp / (tp fp) recall tp / (tp fn) print(fprecision{precision:.3f}, recall{recall:.3f}) return precision, recall进阶方向上我个人最推荐的是把“检测 语义筛选”封装成一个独立的服务类输入是一张图片路径输出是统一的检测结果结构体。这样无论是接视频流还是接图片 API都不用改内部逻辑。如果之后要接目标跟踪记住一个原则先做检测再做语义筛选最后做跨帧关联。因为跟踪算法本质上是基于检测框做匈牙利匹配误检框会直接污染跟踪轨迹先筛掉再跟踪才能保证轨迹稳定。我现在的习惯是每做一个 Yolov11 相关的方案都会先把保存格式和验证脚本定下来再开始调模型。数据落盘的方式决定了下游系统的接入成本也决定了你后续排查问题时能回溯多少信息。这一套 Yolov11 与视觉大模型的串联方案适合很多检测场景但每一步的阈值都需要你拿自己的数据去标定。希望这篇知识分享里的环境配置、代码逻辑和避坑记录能帮到你让你少走几个我走过的弯路。本文还有配套的精品资源点击获取