简介计算机视觉技术CV简要介绍是一份面向入门学习者、算法工程师及科研人员的PDF文档系统讲解CV的核心概念、完整处理流程与主流任务类型。文档从图像获取、前期处理、特征提取到图像分析与解释逐层展开梳理了传统特征方法如SIFT、SURF与深度学习卷积神经网络CNN在特征学习上的差异并详细拆解图像分类、物体检测、图像分割、人脸识别、姿态估计、光流估计、立体视觉等任务的原理与实现思路针对分割任务还对比了阈值、区域、边缘等不同技术的适用场景。应用部分涵盖图像搜索、自动标记、监控安防、医学影像、自动驾驶、农业分析等案例能帮助读者快速建立计算机视觉知识图谱。全包仅1个PDF文件大小约483KB轻量易携带。目前已有175人学习适合希望在较短时间内了解计算机视觉全貌并明确进阶方向的读者。1. 为什么一份 CV 简要介绍值得从业者逐行读完很多人看到“简要介绍”四个字会下意识觉得这是给入门者扫盲用的自己做过两年视觉工程直接跳过就好。我见过不止一个开发者栽在这个判断上要么把注意力机制当成新范式讨论半天却没分清分类与检测的评估口径要么一上来就选最重的检测模型被标注成本和训练周期拖垮。计算机视觉技术CV领域的技术资料真正价值不是把某个算法讲深而是把任务版图、算法路线和工程门槛一次摊开让你在做技术决策前先看清边界。这份名为“简要介绍”的文档恰好是这类资料的骨架。这篇笔记不替 PDF 复述原文而是顺着它的目录逻辑把任务分类、模型选型、最小实现、落地踩坑和进阶习惯串成一条可以直接照做的路径给准备入行、跨端转岗以及要给项目定技术路线的工程师对齐认知用。2. CV 的任务版图分类、检测、分割与跟踪分别在解决什么问题计算机视觉不是单一技术而是一组输入输出形态完全不同的任务集合。选错任务类型后面所有工作都会南辕北辙。很多人拿着一个“识别图片里有没有问题”的需求就去找模型结果对方可能只是要做分类也可能要做缺陷定位两者的标注成本、模型结构和评估指标完全不同。所以先建立任务版图是动手前第一件事。2.1 图像分类从“这是一只猫”到嵌入特征图像分类是视觉里最基础、也最容易被低估的任务。它的定义很简单给一张图打一个标签输出可以是单标签的“猫/狗/车”也可以是多标签的“草地上有一只猫”。模型的核心是特征提取器加一个分类头分类头通常是一个全连接层加 softmax训练时用交叉熵损失。真正要说清楚的是评估口径。单标签分类最常用 Top-1 准确率也就是预测概率最高的类别对了就算对细粒度场景还会看 Top-5只要正确类别落在前五个预测里就算对。多标签分类则用 mAP 和 F1因为“预测了多余的标签”和“漏了真实标签”是两类不同错误准确率这种单一指标表达不了。分类模型还有另一个价值特征嵌入。把分类头去掉倒数第二层的特征向量可以直接拿来做图像检索、聚类和少样本分类。很多实际项目不是从零训练模型而是拿一个在 ImageNet 上预训练的分类模型做骨干迁移到自己的数据上微调。这就是为什么分类看起来“简单”但几乎所有视觉项目的第一版 Baseline 都从它开始。有一点容易被忽略分类任务对标注成本的要求最低一张图打一个标签就行几百张图就能起步。但如果图片里同时有多个对象或者缺陷只有拇指大小纯分类模型就会被迫学习“看哪里”效果通常不稳定。这时任务边界就变了应该往检测或分割走。2.2 目标检测与分割输出框、掩膜与像素级理解目标检测在分类的基础上增加定位输出每个目标的类别和边界框常见的边界框格式是 xyxy 或 xywh。检测模型的评估不看准确率看 mAP其中 IoU预测框和标注框的交并比是核心度量。mAP0.5 表示 IoU 阈值取 0.5 时的平均精度mAP0.5:0.95 则把 0.5 到 0.95 每隔 0.05 都算一遍再取平均后者对定位精度要求严格得多。语义分割对每个像素做分类输出和输入同尺寸的掩膜实例分割更进一步同一类别的不同对象也要分开输出每个对象的独立掩膜。实例分割的标注成本是几个任务里最高的因为要沿着物体边缘逐像素描边还要区分实例编号。实际项目里如果只需要知道“缺陷在哪个区域”语义分割往往够用不必一上来就上实例分割。任务类型输出形态标注成本典型评估指标适用场景图像分类类别标签低Top-1 / Top-5 / 多标签 F1图片整体判断目标检测类别 边界框中mAP0.5 / mAP0.5:0.95定位多个目标语义分割逐像素类别掩膜中高mIoU区域级判断实例分割逐对象掩膜高mAP掩膜版本区分个体轮廓关键点检测坐标点集合中PCK / OKS姿态、人脸、部件定位检测和分割的选择不只看精度还要看下游动作。如果下游是“框出来由人去复核”检测就够了如果下游要做面积测量、形状判断就得上分割。这个决策要在标注开工之前定下来否则返工成本极高。2.3 关键点、OCR 与视频跟踪任务形态与工程成熟度关键点检测输出的是结构化坐标比如人脸的 68 个点、人体的 17 个骨骼点。它常被用于姿态估计、表情识别和手势交互。技术路线上主流做法是输出热力图也就是网络为每个关键点生成一张概率图位置取概率峰值。关键点的评估指标常用 PCK 或 OKS核心是“预测点距离标注点的归一化误差”不只看点有没有落在正确位置还看误差大小。OCR 是另一个独立任务族通常拆成检测加识别两条流水线先用文本检测模型把每行文字框出来再用识别模型把框里的文字转成字符串。中文场景还要额外处理长文本、竖排和表格结构工程复杂度不低。视频跟踪则是在检测基础上增加跨帧关联输出稳定的目标 ID难点在于遮挡、目标交错和 ID 跳变这类问题在单帧图上永远复现不出来。这些任务有一个共同特征它们很少以孤立模型的形式落地更多是组合管线的一部分。比如一个质检系统可能是“检测 关键点 分类”的串联OCR 则永远包含前置定位步骤。读技术资料时如果只理解了单个模型很容易忽略管线各环节之间的误差累积——前置步骤漏检后置步骤做得再准也白搭。2.4 生成式视觉与多模态值得留意但不等于要上生成式视觉这两年热度很高扩散模型能做图像生成、编辑和控制多模态模型能把文本与图像对齐。在工程落地里它们的现实价值目前集中在两处一是数据增强用生成模型补充边缘案例和稀缺类别二是异常样本合成给缺陷检测项目造出真实场景里收集不到的负样本。但要泼一盆冷水生成式模型产出内容的稳定性目前还是玄学。同一个提示词多次生成的图像细节常有偏差用在工业质检上合成缺陷和真实缺陷的纹理、光照、背景差异可能导致模型在真机上误检率飙升。我的建议是把它当作数据补全手段而不是替代真实数据的方案。多模态模型适合做图文检索、视觉问答这类理解类任务但如果目标是像素级定位或高精度测量传统视觉模型仍然更可控、更好评估。选型时别被热度带走先看任务要什么输出。3. 算法与工具选型给三类视觉项目定一套不后悔的基线方案任务图景理清之后下一步是给具体项目选算法和工具。这一步最考验经验因为“最新”不等于“最合适”。选型的原则是先定一个能稳定跑通的基线方案把端到端流程打通再用数据迭代精度。一上来就追 SOTA 模型往往三个月后还卡在环境配置上。3.1 选型之前先回答三个问题第一个问题任务边界是什么。是要整图判断还是要定位到具体位置这直接决定分类、检测还是分割也决定标注方案和人力投入。第二个问题数据形态与规模。数据是静态图片还是视频流类别数量多少每类样本量是否均衡。少于一万张的数据量不建议从零训练大模型预训练模型加微调几乎是唯一高效路径。第三个问题部署形态。是跑在服务器 GPU 上还是边缘设备、手机端、工业相机嵌入式平台部署形态决定模型大小上限和推理耗时预算服务器上 200ms 可以接受产线上往往要求在 50ms 内完成。这三个问题回答完之后选型范围基本就缩小到两三个候选。我见过最典型的翻车是需求方只给了“识别准确率要 99%”没有说清楚部署环境和响应时间结果开发团队选了一个又大又重的模型精度达标但推理速度差一个数量级产品周期白白延后两个月。先问清楚这三个问题比早一天动手训练更重要。3.2 任务与模型选型对照表我按任务类型给一份实际项目里常用的选型对照。这里不追最新论文只列工程成熟、社区资料多、踩坑经验能搜得到的路线。任务类型推荐基线备选路线适用条件图像分类ResNet 系 预训练微调ViT 系数据量 10 万优先 ResNet数据量充足且无较强归纳偏置需求时考虑 ViT目标检测YOLO 系双阶段检测器实时性要求高选 YOLO精度优先且小目标多、允许较慢速度时选双阶段语义分割通用分割模型轻量化分割模型精度优先选原版边缘部署选轻量版本实例分割通用实例分割模型检测加裁剪后二次分割对象数量少时用两段式标注成本更低关键点检测热力图回归模型坐标回归方案标注质量高时热力图稳定追求轻量时试坐标回归但精度风险更大OCR检测 识别两段式端到端识别版式固定且长文本少时两段式调参更可控选型逻辑有一条主线同类任务里优先选推理依赖少的。YOLO 系相比双阶段检测器少一个候选框提取阶段部署简单训练也更省显存双阶段检测器在密集小目标上精度更高但工程复杂度也更高。给一个靠谱建议第一版永远先用列表里的“推荐基线”它足够稳、资料足够多、出了问题能搜到解决方案备选路线留给后续精度调优阶段。3.3 一套通用基线的关键参数同一个模型参数设置不同结果差异很大。下面是一套我在多个项目里验证过、可以作为起点的参数配置按实际数据规模调整。参数常见初始值调整依据输入分辨率640×640检测 / 224×224分类小目标多就提高分辨率但训练和推理时间同步上升Batch Size16 / 32显存够就往大调分类任务 32 起步检测按显存量力而行初始学习率1e-3微调 / 1e-4全量训练微调用过大学习率会把预训练权重冲坏训练轮次分类 20~50检测 100~300检测任务收敛慢看验证集指标决定是否提前停止NMS 阈值0.45检测框冗余时调低目标密集时调高但会引入重叠框置信度阈值0.25训练 / 0.5推理推理阈值影响精确率和召回率的平衡这里最容易犯错的是学习率。很多新手拿预训练模型微调时直接用 1e-3结果前几个 epoch 损失不降反升因为预训练特征被大步长更新破坏了。我一般会先小步试微调从 1e-4 起步观察 5 个 epoch 的验证集趋势再决定是否上调。NMS 阈值默认 0.45 不是金科玉律目标密集的场景里调到 0.3 能把重叠框压下去代价是可能漏掉互相遮挡严重的对象要结合验证集 mAP 一起看。3.4 开源视觉生态的四层分工视觉项目的工程结构通常分成四层。第一层是图像读写与预处理负责读图、缩放、归一化、颜色空间转换和数据增强第二层是模型定义与训练包括模型结构、损失函数、优化器和训练循环第三层是训练过程可视化与调参看损失曲线、验证指标和中间输出第四层是部署运行时把训练好的模型导出成推理格式封装成服务或嵌入设备。第一层最常用的是 OpenCV 和 PIL 这类图像库注意 OpenCV 读图默认是 BGR 通道顺序而 PyTorch 训练时用的是 RGB这个顺序搞反会导致模型精度莫名其妙掉几个点。第二层以 PyTorch 生态为主预训练模型可以直接从官方模型库加载。第三层用训练日志和可视化工具看指标曲线判断过拟合和欠拟合。第四层在训练环境里另开一套导出流程常见做法是先把模型导出成通用推理格式再用推理引擎加载这样部署环境不需要完整训练框架。四层各管各的最忌讳的是训练和部署共用一套代码、不做导出封装。那样每次迭代模型都要重新部署整个环境线上更新一次耗时以小时计。把四层边界划清楚训练迭代和上线部署才能互不阻塞。4. 本地跑通视觉 Demo一套可复现的分类与检测脚本选型定了接下来要亲手跑通一条最小的流程。很多人卡在第一步就放弃了环境装不上、依赖冲突、CUDA 版本对不上。这条链路只要跑通一次后面的迭代都顺畅跑不通再好的方案也停留在纸面。我按分类和检测两个任务分别给最小实现。4.1 准备虚拟环境把依赖隔离当成习惯不要在系统 Python 里直接装视觉依赖。不同项目依赖的包版本冲突是常态一套环境里装了检测库和分割库常常互相打架。我一般会给每个项目建独立虚拟环境并且在此之后把依赖导出成文件随项目一起保存方便后续复现。# 创建 Python 3.11 虚拟环境 python3.11 -m venv venv_cv_demo # 激活环境 source venv_cv_demo/bin/activate # 安装基础依赖版本建议按官方文档选稳定组合 pip install torch torchvision opencv-python pillow这段命令做了三件事创建隔离环境、激活环境、安装三个最基础的视觉依赖。torch 和 torchvision 负责模型定义与训练opencv-python 负责图像读写与预处理pillow 在 torchvision 的数据加载链路里是常见的图像后端。这里特意没有写死版本号因为不同显卡驱动对应的 torch 版本不同正确做法是先去 torch 官方页面查自己机器匹配的版本再安装。# 验证环境是否可用 python -c import torch; print(torch.__version__, torch.cuda.is_available())这行命令验证两件事torch 是否装好以及 CUDA 是否可用。如果输出里cuda.is_available()是 False说明要么装的是 CPU 版 torch要么显卡驱动和 CUDA 版本不匹配。这是整个流程里最容易翻车的位置也是后面避坑章详细展开的地方。环境通了再走模型代码别在没验证的情况下直接跑训练脚本否则报错时很难判断是环境问题还是代码问题。4.2 图像分类ResNet 预训练模型的推理脚本用预训练模型跑一次推理效果最直观也能验证环境链路是否完整。下面这段脚本用 torchvision 自带的 ResNet 权重对单张图片做分类预测。import torch from torchvision import models, transforms from PIL import Image # 加载预训练分类模型并切换到推理模式 model models.resnet50(weightsmodels.ResNet50_Weights.IMAGENET1K_V1) model.eval() # 预处理要与 ImageNet 预训练时的配置保持一致 preprocess transforms.Compose([ transforms.Resize(256), # 短边缩放到 256 transforms.CenterCrop(224), # 中心裁剪到 224 transforms.ToTensor(), # PIL 图像转张量像素归一到 0~1 transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), # ImageNet 统计量 ]) img Image.open(sample.jpg).convert(RGB) input_tensor preprocess(img).unsqueeze(0) # 增加 batch 维度 with torch.no_grad(): output model(input_tensor) # 取概率最高的前 5 个类别索引 probs, idxs torch.topk(torch.softmax(output, dim1), 5) print(probs, idxs)这段脚本的关键在于预处理必须和预训练时一致。Resize 到 256 再 CenterCrop 到 224是 ImageNet 分类的标准配套Normalize 用的均值方差也是 ImageNet 的统计量换掉任何一个都会导致输入分布偏移精度下降。model.eval()会关闭 dropout 和 BatchNorm 的统计更新推理时必须调用。no_grad()关闭梯度记录省显存也加速。参数调整上也说两句如果你要分类的对象是小物体可以把输入分辨率拉到 384 甚至更大但推理时间会明显上升如果部署在边缘设备把 resnet50 换成更小的骨干精度降一点但速度能快一个量级。先跑通这个脚本确认输入输出链路正确再做模型替换。4.3 目标检测通用调用模式与输入输出约定检测模型的具体接口因工具包而异但调用模式高度一致加载权重、读图、带阈值参数推理、解析输出框。下面是一段通用模板你用时按实际安装的工具包接口微调。import cv2 def run_detector(model, image_path, conf_thres0.25, iou_thres0.45): # OpenCV 读图注意通道顺序是 BGR img cv2.imread(image_path) # 推理接口以所装工具包为准先用 help 确认参数名 results model.predict(img, confconf_thres, iouiou_thres) # 从结果对象中取检测框列表 boxes results.boxes for box in boxes: x1, y1, x2, y2 box.xyxy[0].tolist() # 边界框左上角和右下角 score float(box.conf[0]) # 置信度 cls_id int(box.cls[0]) # 类别编号 print(f{x1:.0f},{y1:.0f},{x2:.0f},{y2:.0f} cls{cls_id} conf{score:.3f}) return results这段代码展示了检测推理的标准流程读图、推理、解析框。两个阈值参数很关键——conf_thres是置信度阈值低于它的框直接丢弃调高可以减少误检但可能漏检iou_thres是 NMS 去重阈值控制两个重叠框是否被合并。OpenCV 读图默认是 BGR 顺序如果你的模型训练时用的是 RGB 输入推理前要转通道顺序否则检测结果会异常。不同工具包的接口名有差异有的叫model.forward有的叫model.predict输出结构也不一样。拿到不熟悉的包时我习惯先在 Python 里执行help(model)或直接打印结果对象的属性花两分钟看清结构再写解析逻辑。4.4 跑通之后的三个验证动作模型能出结果不算跑通还要做三个验证。第一用独立的验证集图片测试而不是只跑训练集里那张示例图防止模型过拟合到特定图像上给你造成“效果很好”的假象。第二统计验证集上每一类别的预测数量与真实数量看类别分布是否严重失衡这一步能提前暴露数据问题。第三用 Python 脚本记录单张图的平均推理耗时确认当前模型在目标硬件上是否满足性能预算。这三个动作完成后才算真正具备进入迭代循环的条件后续调参才有数据支撑。5. 视觉工程落地避坑数据、环境与评估的 5 个典型翻车现场跑通 Demo 和项目落地之间的距离通常是用坑填平的。这一章整理我在多个视觉项目里实际踩过、以及在社区里反复见到的五类典型问题每一条都按现象、原因、解决的顺序展开方便你遇到问题时直接对照排查。5.1 分类偏爱大类数据不均衡的翻车现场现象模型在验证集上整体准确率 96%看起来不错但按类别拆开一看占样本量 90% 的“正常”类准确率 99%占 5% 的“轻微缺陷”类准确率只有 60%占 5% 的“严重缺陷”类干脆只有 20%。模型几乎把所有缺陷都判成正常。原因分类模型用交叉熵训练时损失在样本量大的类别上累计更多梯度更新方向被大类主导。模型学到“全部预测为正常类”就能拿到 90% 准确率局部最优比认真区分缺陷更容易达到。解决我在分类训练里会强制做两件事。一是数据层面对少数类做过采样或数据增强将每类样本量拉到接近均衡二是损失层面给每个类别设置权重少数类权重更大。另外一个容易被忽略的手段是评估指标不要只看整体准确率而是同时打印每个类别的精确率和召回率把“平均准确率高但某类等于没做”的问题暴露出来。数据不均衡从来不是调参能完全解决的最后还要靠持续补充真实样本。5.2 检测框对不齐NMS 阈值与标注质量的坑现象检测模型在验证集上的 mAP 不高画出来看边界框大面积紧贴目标、位置偏左上或偏右下有的框明显小于真实目标。模型似乎“大致知道目标在哪”但框总是差一点。原因检测框对不齐通常是两个原因叠加。一是标注框本身不贴合目标边缘标注员画框时习惯性留白或者切到目标内部二是 NMS 阈值设置不当重叠框没有正确合并导致输出位置被多个相近框的平均值拉偏。解决先用可视化工具把标注框直接画在原始图上人工抽查 10% 的样本凡是框的贴合度差的标注直接返工——数据标注质量不过关模型不可能学出精确的定位能力。接着检查 NMS 阈值在验证集上分别跑 0.3、0.45、0.6 三组值观察 mAP 和可视化输出选最优。记住一条经验标注框如果都不贴边先标注返工再谈模型结构升级后者救不了前者。5.3 环境复现失败CUDA、Python 与包版本错配现象项目代码在一台机器上训练正常换到另一台机器后导入模型库时直接报错报错信息指向 CUDA 相关名词或动态链接库加载失败。代码完全没改但环境就是起不来。原因torch 这类框架的版本与 CUDA 驱动版本存在绑定关系驱动太老会加载不了新版本编译的框架Python 版本差异也会导致某些包找不到可用版本。多数项目没有把依赖环境固化下来换机器时全靠现场排查。解决我的习惯是同一套依赖信息记两个文件一份是 Python 层面的依赖列表记录具体版本号一份是运行环境说明记录系统版本、显卡驱动版本、CUDA 版本、Python 版本。换机器时先按说明恢复基础环境再装依赖。不要盲目装最新版先查官方页面对照显卡驱动支持的 CUDA 版本再选匹配的 torch 版本。这条规则能省去大量无头绪的重装操作。5.4 评估虚高同源数据切分造成的泄漏现象训练时验证集 mAP 一路涨到 95%模型保存下来上线试跑实际效果远不如预期。回到训练流程里反复检查代码、环境都没问题数据划分也做了但就是找不到原因。原因最常见的情况是数据集划分时没有做序列去重。同一场景连续采集的帧或者同一目标在不同角度拍的图片被拆进了训练集和验证集。模型在训练时已经见过“长得几乎一样”的图片验证指标自然虚高换到真实场景就露馅。解决划分数据时以“目标样本”为单位而不是以图片为单位。时间序列数据按时间段切分同一目标的所有图片归入同一个集合缺陷检测项目要按缺陷实例去重保证同一缺陷只出现在训练集或验证集里。另外设置一个完全独立的测试集只用于最终评估日常调参只用验证集。这个习惯坚持下去能避免大量被虚高指标误导的返工。5.5 指标好看但落地难mAP 与业务诉求的错位现象模型在验证集上 mAP0.5 达到 90%项目方仍然反馈“不好用”。追问下来才知道产线上的漏检率超标而 mAP 反映的是框定位和分类的总体精度并没有把“某一种缺陷漏检”的代价突出出来。原因mAP 是一个综合指标它把所有类别的检测表现平均化。错检一个正常样品和漏检一个严重缺陷在 mAP 里贡献的数值差异不大但业务场景里漏检的代价远高于错检。指标与业务诉求错位导致模型优化的方向偏移。解决做完模型后要单独输出混淆矩阵统计每一类别的漏检率和误检率和业务方约定哪类错误不可接受。对不可接受的错误类别单独调高置信度阈值或增加该类样本权重甚至给该类别单独训练一个专用检测器把结果融合进主模型。技术指标是过程指标业务指标才是最终验收口径。上线前的模型评估报告里应该有这两套数据而不是只贴一个 mAP。6. 进阶动作轻量化、数据闭环与指标对表的三个日常习惯项目进入稳定迭代期后决定天花板的往往不是模型结构而是工程习惯。6.1 轻量化先剪枝、蒸馏再考虑换骨干模型跑通了部署发现速度不够第一反应不要是换小模型。换骨干意味着重新训练、重新调参成本很高。常见做法是先做模型蒸馏用大模型当老师把输出分布教给小模型小模型保留 90% 以上的精度但速度提升明显。再往前走一步是剪枝和量化把权重精度降到 8bit推理框架配合优化后速度又能上一个台阶。只有在这些手段都用过之后才值得考虑从头换轻量化骨干。6.2 数据闭环难样本收集要变成日常上线之后的模型不会越用越准但数据会越积越多。我在每个视觉项目里都会留一个固定动作每天把线上预测置信度偏低、人工复核时改判过的样本捞出来归入训练集下一轮补充。这个动作的价值比调任何参数都大因为真实场景的分布和训练集永远有偏差只有把偏差样本持续回灌训练集模型才会慢慢逼近真实边界。难样本收集不是额外工作而是视觉迭代的一部分。6.3 指标对表把视觉指标翻译成业务语言最后是一个容易被忽略的习惯维护一张指标对照表左边是技术指标右边是业务含义。mAP 下降 2 个点对应多少漏检置信度阈值上调后误报率下降多少、召回损失多少这些映射关系要用真实样本验证过而不是拍脑袋估算。每次模型更新后把两组指标一起更新发给业务方对齐。这样做的好处是下次业务方提出“准确率再高一点”时你能直接说清楚代价是什么而不是一味堆数据。我最早带视觉项目的时候也走过只看 mAP 的弯路上线后被业务方用真实场景的漏检案例堵得无话可说。后来养成这三个习惯模型迭代的效率反而比当年纠结于最先进模型结构时高出不少。技术选型会过时但这套“先跑通基线、再按指标和业务对表迭代”的流程放到今天依然适用。希望帮到你。本文还有配套的精品资源点击获取