简介：一份面向零售行业智能化升级与AI工程化应用的技术文档，聚焦如何以轻量级Transformer完成商品陈列合规性检测，并落地到移动端。文档先指出传统人工巡检效率低、成本高、易漏检等痛点，随后深入讲解Transformer架构、注意力机制改进、模型剪枝与量化，再结合TensorFlow Lite、PyTorch Mobile、ONNX Runtime等框架，给出从数据预处理、规则定义到模型转换、性能优化、隐私保护的全链路方案。资源为1个PDF文件，共27页，压缩包大小约2MB，支持目录跳转与阅读器大纲定位，已有46人学习。内容覆盖实验环境设置、模型性能对比、消融实验及实际应用效果验证，并展望了多模态融合、智能规则管理等方向。适合零售技术管理者、AI算法工程师及移动端开发人员参考，可借此快速建立从算法设计到端侧部署的完整认知。
1. 零售货架智能巡检：轻量级Transformer在商品陈列合规性检测的移动端部署
连锁便利店的督导每周去门店巡店，拍几百张货架照片回传总部，再由运营人员逐张复看缺货、排面不足、错放和价签问题——一张图盯十秒，一组图看二十分钟，漏检率直接跟人的疲劳成正比。零售货架智能巡检要做的，就是让手机或手持PDA靠近货架扫一圈，轻量级Transformer在端上实时给出商品陈列合规性检测结果，违规问题当场标记出来。这篇笔记适合正在做零售场景视觉方案的算法工程师、物联网平台的技术负责人，以及想把检测模型真正压到移动端的开发者。核心结论先放在这里：合规性检测里最难的不是缺货检测，而是细粒度、高相似度、依赖共现上下文的错放判定；移动端部署的成败不只看模型精度，量化策略、输入分辨率、算力预算三者共同决定能不能用。
2. 商品陈列合规性检测先定义检项：缺货、排面不足、错放与价签
很多人一上来就把这个任务当通用目标检测做，直接拿几百个SKU当类别标框，训练出来的模型一上线就废。原因很简单：合规性检测不是“识别这是哪个商品”，而是“判断陈列状态是否符合标准”。前者是细粒度识别，后者是状态判定加关系理解，两者的数据分布、标注口径和模型输出设计完全不一样。在做任何模型选型之前，先把业务方的陈列标准转成机器可读的检项，才是整个项目真正的第一步。
2.1 四个检项：判什么、难在哪、标准谁来定
零售货架的合规性检查通常落到四个检项，它们各自对应的算法难度完全不同：
| 检项 | 直观定义 | 判定难点 |
|---|---|---|
| 缺货 | 托位或层板出现明显空位，该位置的SKU不可售 | 空位也可能是有意压缩排面，不能只看“有没有物体” |
| 排面数不足 | 该SKU实际陈列排面数少于陈列图标准，例如可乐要求4排实际只摆2排 | 第一排完整但后补不足时需要推断，单框分类解决不了 |
| 错放 | SKU出现在不属于它的品类区域或层板，或同系列不同口味混放 | 同类产品包装差异极小，只有结合周围品类的共现关系才能判定 |
| 价签异常 | 价签缺失、价签与实物不符、促销签未更新 | 文字小，通常需要OCR组件配合，单靠检测框输出不够 |
这里关键的一点是：检项标准不能由算法团队自己定，而要由运营部门提供Planogram陈列图，再转换成机器可读规则——每个货架位绑定一组SKU，每SKU绑定一个标准排面数。算法负责的是“检测事实”，比如某个区域有6罐330ml汽水，陈列标准负责的是“判定合规”，比如4排就是合规、2排就是不足。把标准从人看的图变成数据集的标注规则，是后期所有自动化的前提。
这里面还隐藏着一个常见的认知误区：业务方嘴上说“帮我做个缺货检测”，实际要的往往是“缺货、排面、错放都要管”。如果第一版只做缺货，模型结构、标注体系和部署流程后面都要推翻重来。所以即使业务方只提了一个诉求，也要在第一轮就把四类检项的数据口径和告警等级聊清楚。
2.2 训练数据怎么建：SKU类型与状态分成两层标注
常见做法是找几家合作门店，用两台手机从不同角度拍真实货架，再在一些闭合货架区做补拍。起步数据不必贪多，我一般建议先覆盖100到150个高流转SKU，每个SKU至少要有合规、缺货、排面不足三种状态，错放案例按品类单独补充，总量在15000到25000张之间就可以训练第一版能上真机实测的模型。关键在于标注体系，不要直接标“SKU_ID+框”。
如果把SKU_ID当类别做检测，项目会死在SKU长尾上：门店一年要上几百个新品，每个新品都要重新拍图、标注、重训模型，这个成本零售企业根本扛不住。我习惯把标注拆成两层，第一层是“陈列对象”检测，框住一个陈列单元，类别用“商品大类+包装形态”，例如碳酸饮料易拉罐、乳制品盒装、膨化食品袋装；第二层是“状态属性”，同一个框再标合规、缺货、排面不足三选一，错放单独作为另一个输出维度。SKU身份不进训练集，由后处理阶段查映射表绑定。
标注行的组织方式大致是这样：
# 标注行结构：图片名, 框坐标, 商品大类, 状态, 错放标记, 备注 IMG_0001.jpg 812,1103,1058,1280 碳酸饮料易拉罐 排面不足 0 第二排有空隙 IMG_0001.jpg 1214,1095,1406,1280 碳酸饮料易拉罐 合规 0 无 IMG_0001.jpg 1560,1120,1688,1244 功能饮料瓶装 合规 1 混入果汁区说明一下这里的逻辑：状态和错放不是互斥标签，一个商品本身陈列完好，但它放错了位置，这时状态标合规、错放标1。模型的两个输出头分别预测状态和错放概率，最后在告警合并层把两者组合。这个口径如果一开始不统一，标注员很快会产生大量无效样本，后面清洗成本极高。
标注完成之后还要做一致性抽检。我踩过的坑是：标注员默认“看得见第一排”就算合规，但运营规定的排面数包含后补存货的可见度，两边的“合规”根本不是一回事。解决办法是给标注规范里的每组状态配三张参考图，图上直接标出判定边界，抽检时专门挑边界图过一遍。
2.3 成像约束：手持拍摄的距离、角度与光照
零售巡检和炼化装置智能巡检系统那种固定点位、固定机位不同，零售场景是手持设备在过道里边走边拍，距离大约在1.2到2米之间，俯角30到45度，货架层板经常会切掉商品下半部分。这意味着训练数据里如果全是相机平视、正对货架的“虚拟样式图”，真机上第一次走店就会大量漏检。
采集和仿真阶段建议按下面的参数范围去约束：
| 参数 | 建议范围 | 说明 |
|---|---|---|
| 拍摄距离 | 1.2到1.8米 | 过近导致单框比例过大，过远则超出移动端输入分辨率的上限 |
| 俯角 | 30到45度 | 符合真实巡店习惯，避免平视正面图占比过高 |
| 光源 | 600到1200lux混合照明 | 门店筒灯混自然光，色温4000K到6000K都要覆盖 |
| 图片长边 | 1920像素以上 | 模型输入只需要192到224，原图保留高分辨率用于ROI裁剪 |
训练时数据增强要比一般目标检测更激进一些。把随机裁剪尺度下限调到0.5以下，用来模拟侧向看货架时单件商品被层板遮挡的情况；颜色增强里把亮度扰动和色温扰动分开做，亮度模拟不同灯管老化差异，色温模拟靠窗位置的自然光混入。不要只喂“完美正面图”，否则摄像头一歪精度就掉。
我见过团队把标注工作量翻倍后精度仍然提不上去，后来发现是拍图太“干净”，每张图都是标准光照、标准角度。真实的移动端巡检画面里，反光、手指遮挡、走路抖动造成的运动模糊才是常态。与其堆更多完美样本，不如先把手持拍摄的脏数据按20%左右的比例混进训练集，模型对部署环境的适应会快得多。
3. 轻量级Transformer选型：从MobileViT到EdgeNeXt的取舍与最小可跑代码
模型选型的核心不是“用Transformer一定比CNN好”，而是“在移动端的算力预算内，Transformer在合规性检测这类任务上能不能把精度做够”。我需要先给“轻量级”画一条边界：骨干网络参数量在1.5M到8M之间，输入224×224时FLOPs在0.5G到2G之间，真机单帧推理延迟控制在20到30毫秒。超过这个区间就不叫轻量级Transformer，叫“自找麻烦”。
3.1 为什么移动端选Transformer而不是继续用CNN
三个理由决定了我不会优先选同等参数量的CNN。第一是细粒度差异：缺货是强特征，空货架的区域纹理和满货架差异巨大，任何模型都能学得会；但“错放”的判定依赖上下文，比如一罐汽水放在酸奶区，模型需要同时看到汽水的包装特征和周围商品构成的品类背景。CNN的局部感受野在浅层捕捉不到这种跨区域的共现关系，要等网络层数堆深之后才有可能，而轻量级Transformer在浅层就可以通过自注意力直接聚合远端信息。
第二是动态感受野。货架上商品的尺寸跨度非常大，一盒口香糖和一袋5kg大米在同一张图里出现，锚框尺寸可以差出十倍。CNN的固定kernel对多尺度对象的自适应能力有限，Transformer的注意力机制可以根据输入内容动态调整聚合范围，这个特性对密集货架场景非常友好。
第三是移动端NPU的演进方向。过去大家觉得Transformer算子重，不适合端侧，但现在主流移动端SoC的NPU对softmax、LayerNorm、GELU这几类算子的加速支持越来越好，MobileViT这类“浅层卷积+深层注意力”的混合架构在最新一代NPU上的实测速度并不吃亏。反而是同等参数量的CNN在网络结构上没有吃到硬件演进的额外红利。
但这里必须泼一盆冷水：不要在手机上部署ViT-Base甚至更大规模的模型。Transformer对数据量和训练时长的敏感度比CNN更高，小模型在数据不足时更容易欠拟合。如果你手里的训练数据不到一万张，老老实实先用MobileViT的极小版本跑通链路，比追求高精度架构更有意义。
3.2 三种可落地架构与一套加载代码
目前移动端能跑得动的轻量级Transformer方案里，我实际验证过且愿意推荐的是三条路线：MobileViT系列、EdgeNeXt系列和FastViT系列。它们的设计取向有明显差异，适合的检项组合也不同。
| 架构 | 参数量级 | FLOPs @224 | 强项 | 弱项 |
|---|---|---|---|---|
| MobileViT系列 | 1.3M到5.6M | 0.7G到1.8G | 卷积与注意力混合结构，量化稳定性好，社区资料多 | 深层token计算量偏大，小模型上错放能力一般 |
| EdgeNeXt系列 | 1.3M到5.6M | 0.5G到1.8G | 局部注意力加通道卷积，真机延迟低 | 极小模型下错放召回容易掉 |
| FastViT系列 | 3.5M到9M | 1.2G到2.0G | 多尺度特征聚合强，复杂背景稳定 | 对NPU算子兼容性更挑剔 |
选择逻辑可以按业务占比走：如果告警量里缺货和排面不足占九成，MobileViT-XXS级别就能胜任，省下来的算力给预处理和前处理；如果“错放”是主要告警来源，建议直接上EdgeNeXt-S或FastViT-S，它们在不同尺度特征融合上的设计更充分，能更好地利用“周围是什么品类”这种上下文信息。
用timm加载预训练模型的代码非常短，但要注意模型名的写法随timm版本有调整，跑之前先用list_models筛一遍：
import timm import torch # 列出当前timm里可用的轻量Transformer模型名 available = timm.list_models("*vit*", trained=True) print(available) # 示例：加载MobileViT-S，把分类头改成3类 # 3类对应：合规、缺货、排面不足；如果有错放则改成4类输出 model = timm.create_model("mobilevit_s", pretrained=True, num_classes=3) model.eval() # 固定输入尺寸前向一次，确认输出维度和参数量 x = torch.randn(1, 3, 224, 224) out = model(x) print(f"输出shape: {out.shape}") total_params = sum(p.numel() for p in model.parameters()) print(f"骨干参数量: {total_params / 1e6:.2f}M")这里的逻辑是先用timm把预训练权重加载进来，改掉最后的全连接层分类数。pretrained=True虽然在ImageNet上预训练，对货架场景迁移依然有效，因为浅层学到的边缘、纹理、颜色分布与商品外观有大量重叠。这段代码只能验证backbone结构，真正接入检测框架时还要把分类头拆掉，接FPN和检测头。
如果不想自己写检测头，常见做法是拿mmdetection这类框架注册自定义backbone，继续沿用RetinaNet或Cascade R-CNN的检测头。需要注意的坑是：MobileViT输出的通常是单尺度深层特征，不像ResNet天然输出多尺度特征图，接入FPN时要手动把浅层的16×16或32×32特征图并进去，否则小体积商品（口香糖、润喉糖）的检测精度会明显偏低。
3.3 从PyTorch到ONNX：固定shape、算子兼容与NPU适配
模型训练好后，导出到移动端的第一步是转ONNX。这里最容易踩坑的就是动态shape。很多人在训练时用224，导出时想留一点弹性，给高度宽度都加了dynamic_axes，结果到了移动端框架要么转换失败，要么推理速度大幅下降。我的习惯是直接固定输入尺寸，最多放开batch维度：
import torch # 加载训练好的权重，这里是完整检测模型，不只是backbone model = torch.load("best_compliance.pt", map_location="cpu") model.eval() # dummy输入的shape必须与最终部署输入完全一致 dummy = torch.randn(1, 3, 224, 224) torch.onnx.export( model, dummy, "compliance.onnx", opset_version=17, input_names=["input"], output_names=["cls_logits", "box_pred"], # 移动端不要用dynamic_axes，固定H/W是王道 )dummy的shape为什么不能改？因为后续移动端框架做内存预分配时完全依赖导出的输入输出shape，导出时224，部署时想用192或288，轻则性能下降，重则直接跑不起来。opset_version取17到18之间和主流移动端框架对齐，太高会导致部分算子无法映射到NPU。
导出之后强烈建议用onnx-simplifier过一遍：
import onnx from onnxsim import simplify model = onnx.load("compliance.onnx") model_sim, check = simplify(model) print("simplify是否通过:", check) if check: onnx.save(model_sim, "compliance_sim.onnx") else: # 如果失败，优先排查模型里的动态shape和控制流（if/循环） print("检查动态shape或控制流节点")simplify会把PyTorch导出时留下的冗余Reshape、Identity、Cast节点清理掉，这些节点在NPU编译器里经常导致额外的内存搬运。check返回False的时候，优先检查模型里有没有Python级别的if或循环分支，这类控制流不会因为模型在eval模式就消失，需要改写成torch.where或固定逻辑。
算子兼容性是这节最后要提醒的事。轻量级Transformer里最容易出问题的是unfold算子（MobileViT用到）、LayerNorm和GELU。不同厂家的NPU对这些算子的支持程度差异很大，有些在CPU上跑得飞快，一上NPU就回退到CPU算，延迟直接爆表。遇到这类问题我一般有两种处理方式：一是把激活函数换成量化友好的近似形式，二是把LayerNorm替换成GroupNorm，后者在低比特量化时的数值稳定性更好。算子支持情况在具体硬件上属于“有些玄学”，最好的办法是导出后立刻在真机跑一遍算子级调试，不要等整包集成完成再排查。
4. 训练与量化：把轻量级Transformer压到移动端还要保住合规检测精度
模型架构定了，接下来才是真正拉开差距的部分：训练超参与量化策略。合规性检测任务和通用检测有一个显著差异——类别不平衡极其严重。缺货样本在数据集中可能只占不到5%，而“合规”样本占了七成以上。这个分布直接决定了学习率、损失权重和量化校准策略都要针对性调整。
4.1 训练参数基线与调整方向
轻量级Transformer在小型数据集上比CNN更容易欠拟合，所以训练轮数和正则参数不能照搬ResNet的训练经验。我常用的一组基线参数如下：
| 参数 | 基线值 | 说明 |
|---|---|---|
| 输入尺寸 | 224×224 | 再大会吃掉移动端算力预算，再小缺货检测先掉精度 |
| 优化器 | AdamW | 对Transformer比SGD更稳定，是首选项 |
| 初始学习率 | 2e-4 | 1e-4到3e-4之间可接受，高于5e-4容易训练震荡 |
| Batch Size | 64 | 显存不够降到32，但同步BN的统计量会不太稳定 |
| 训练轮数 | 80 | 轻量Transformer收敛速度慢于CNN，60轮以下经常欠拟合 |
| Weight Decay | 5e-5 | 不要太高，自注意力对正则强度更敏感 |
| EMA | 0.999 | 移动端部署强烈建议用EMA权重替换训练权重 |
| Mixup | 0.2 | 相当于廉价的遮挡增强，但不要开到0.8 |
训练循环的核心代码如下，注意混合精度、EMA保存和多卡同步的逻辑：
import torch from torch.optim import AdamW from torch.optim.lr_scheduler import CosineAnnealingLR from torch.cuda.amp import GradScaler, autocast epochs = 80 optimizer = AdamW(model.parameters(), lr=2e-4, weight_decay=5e-5) scheduler = CosineAnnealingLR(optimizer, T_max=epochs) scaler = GradScaler() for epoch in range(epochs): model.train() for images, targets in train_loader: optimizer.zero_grad() with autocast(): loss_dict = model(images, targets) # 检测框架一般返回分类损失和回归损失，直接求和 loss = loss_dict["loss_cls"] + loss_dict["loss_box"] scaler.scale(loss).backward() scaler.step(optimizer) scaler.update() scheduler.step() # 每5轮保存一次EMA权重用于真机验证 if (epoch + 1) % 5 == 0: ema.apply_shadow() torch.save({"model": model.state_dict()}, f"ema_epoch{epoch+1:02d}.pth") ema.restore()这里强调两点：EMA权重在量化感知训练和混合精度推理下往往比原始训练权重更稳，因为它相当于对权重做了时间维度的平滑处理，权重的极端离群点更少；另一个是混合精度训练时损失缩放因子如果出现inf，要回退到FP32跑两步看看是不是某个位置的梯度爆炸，常见原因是错放类别的难样本在浅层产生了过大的梯度。
输入尺寸是移动端精度杠杆里最重要的单项。训练时如果全程用224，真机上遇到近距离大目标时特征金字塔的上采样会明显吃力。我习惯在最后10个epoch把输入分辨率切到288或320做微调，这个操作对近距离货架的“排面数不足”判定很有帮助，代价是CPU或NPU的端侧延迟不变（端侧推理时仍用224），只影响训练速度，属于免费的精度提升。
4.2 量化感知训练：INT8下保住缺货检出
不做量化的模型在移动端几乎没有实用价值。INT8量化可以把模型体积缩小到约四分之一，推理延迟通常降到FP32的二分之一到三分之一。但对合规性检测来说，直接做训练后量化（PTQ）有一个非常典型的翻车场景：缺货检出率暴跌，而错放精度反而没什么损失。
原因也不难理解。缺货检测的核心特征是“空位”的低纹理区域，它的激活值集中在极低的幅值区间；而校准集如果大部分是满载货架，量化scale会被中高幅值的纹理像素主导，低幅值部分的量化步长被拉大，空货架区域的有效信号直接变成0。错放检测依赖的是品类间的对比特征，这些特征来自中高幅值激活，受影响较小。
因此量化感知训练（QAT）的配置里，除了模型本身的qconfig，更关键的是校准集怎么组：
from torch.ao.quantization.qconfig import get_default_qat_qconfig # 给模型配置QAT model.qconfig = get_default_qat_qconfig("qnnpack") model.train() torch.ao.quantization.prepare_qat(model, inplace=True) # 校准集必须按状态均匀采样，不能随机抽样 calib_loader = build_calib_loader( include_full_shelf=0.3, # 满载货架占30% include_partial_empty=0.4, # 半空货架占40% include_large_empty=0.3, # 大面积空位占30% ) # 冻结BN统计量，避免QAT过程中moving_mean/cov被更新 freeze_bn_stats(model)这段代码里prepare_qat之后做的一件重要事情是冻结BatchNorm的统计量，否则QAT训练过程中BN统计量和量化参数互相拉扯，最后导出的模型在真机上误差会非常大。QAT的训练学习率要比普通训练低一个数量级，我一般用1e-5到3e-5，训练10到15个epoch足够。
另外一条重要的经验是量化粒度要按模块区分。检测头的分类质量直接关系到“错放”的细粒度判定，对量化误差最敏感。常见的落地手法是：backbone全量INT8，颈部FPN和检测头保留FP16或BF16，整体延迟只增加2到3毫秒，但错放精度不会崩。这个做法是在部署阶段的推理管线里配置，不需要改训练代码。有些NPU支持混合精度算子分配，可以在模型转换配置里给指定节点设置精度，这里要花一点时间对照硬件文档，不要盲目全量化。
4.3 蒸馏：用大模型当老师，保住SKU长尾
轻量级Transformer在训练数据只有一两万张时，长尾SKU上的表现比较吃力。一种有效做法是知识蒸馏：用一个在相同数据上训练的更大学模型当老师，把分类概率分布和特征图语义蒸馏给学生模型。这比单纯堆数据效率高，因为老师模型已经把数据里的共现关系、光照不变性等知识压缩在参数里了。
以分类logits的蒸馏为例：
import torch import torch.nn.functional as F # 知识蒸馏温度T，常用3~5 # 温度越低，分布越尖锐，能蒸馏出的类间关系越少 T = 4.0 def kd_loss(s_logits, t_logits, alpha=0.5): # 学生logits取log_softmax，老师logits取softmax，保证同尺度 s_prob = F.log_softmax(s_logits / T, dim=-1) t_prob = F.softmax(t_logits / T, dim=-1).detach() # T^2用于补偿softmax温度缩放带来的梯度量级变化 kd = F.kl_div(s_prob, t_prob, reduction="batchmean") * T * T return kdalpha的含义是蒸馏损失在总损失中的占比。我一般前70个epoch关闭蒸馏，只让模型学习空间结构，最后10个epoch再把alpha设为0.5；对“错放”类别，alpha调到0.8，因为老师模型在错放判定上比在缺货判定上更可信，缺货本身就是强特征，老师对小模型的增益有限。
蒸馏时有一个关键细节：不要对背景类做蒸馏。货架数据里背景占比极高，且老师模型在背景上非常自信，会把大量学习容量引导到“区分货架缝隙和层板边缘”这类与业务无关的任务上。做法是蒸馏分支的logits只包含商品和状态类别，背景类单独挂在普通的交叉熵损失上。这个细节对小模型的最终精度影响明显，一开始漏掉这个设置的同学，后面都会返工一轮。
5. 移动端部署的四个常见坑与排查思路
模型导出之后，真正的工程挑战才开始。下面四个坑是我在零售巡检项目里实际踩过、也帮别人排查过的，每一条都按“现象、原因、解决”的顺序讲，方便你对号入座。
5.1 量化后缺货检出率暴跌
现象：QAT在PC端验证时mAP只掉了0.8个点，真机一跑缺货召回率从91%掉到79%，导出的告警图里全是“看似空位但实际有商品”的误报，督导完全不敢信这个结果。
原因：校准集里满载货架占比太高，INT8的量化scale由中高幅值纹理像素决定，空货架区域低幅值信号被量化成接近0的离散值，缺货判定依赖的“空位低谷”特征被抹掉了。
解决：按状态分布重新采样校准集，空位区域样本占到30%以上；更实用的是给缺货单独保留一个FP16分支，因为缺货是业务方最看重的告警，不值得为了省那一点算力牺牲它的精度。我最后用的做法是在后处理里叠加一个层板区域的纹理能量阈值，纹理能量低于阈值直接置为缺货候选，模型只负责精修边界。传统CV方法和神经网络兜底组合，在这个场景意外地好用。
5.2 错放类目在真机上误检率偏高
现象：训练集上错放mAP有0.87，真机每天产出几十条错放告警，人工复核发现全是同系列商品不同口味之间的互相误判，比如草莓味酸奶和原味酸奶。
原因：同系列SKU的类间距离本来就小，某些口味只差一个局部色块或者一行小字，224输入分辨率下包装上的口味字体在特征图里只剩几个像素；同时NPU的INT8算子对细粒度特征的数值扰动会被判定阈值放大。
解决：把同系列口味判定从模型任务里摘出去。模型只输出“品类组正确/品类组错误”，对组内口味不一致的情况统一降级为“疑似错放，请人工确认”，不在端上做最终判定。这样误报在业务层面变成了“需要人工复核的提示”，可接受度大幅提升。如果一定要在端上区分口味，唯一可行的方案是提升输入分辨率加局部放大识别，但算力代价太大，商业上不划算。
5.3 摄像头预览卡顿与发热
现象：宣称25fps的NPU模型上真机实测只有12fps，跑三分钟之后因为发热被系统降频，掉到8fps左右，画面肉眼可见地卡顿。
原因：三个问题叠加。一是没有做NPU预热，前几帧在编译和权重重排上消耗大量时间；二是为了看清小字把输入分辨率从224提到320，但卷积和注意力算力随分辨率近似平方增长；三是预览流和推理流放在同一个线程，互相抢CPU资源。
解决：固定推理输入分辨率，不要跟随预览分辨率走；推理线程做双缓冲加“最近帧丢弃”策略，处理不过来时直接丢掉当前帧去取最新帧，而不是排队阻塞；应用启动后在相机预览开启前先跑20帧预热，用无业务含义的灰色图把NPU调度器激活。一个实测经验：输入192加双缓冲的端到端延迟（从摄像头帧到告警输出）通常比输入224加排队更短，精度损失只有0.2到0.3个点。
5.4 新品SKU上线后旧模型漏检
现象：门店做了一次陈列调整，旧包装下架、新口味上架，旧模型把新包装当作未知目标直接忽略，缺货和排面统计全部失效，要等两到三周新数据积累才能重训上线。
原因：模型的分类边界在旧SKU外观上过拟合了，对没见过的包装只能输出低置信度；而标注体系又没覆盖新SKU，整个链路在“身份”这一层就断了。
解决：架构上把“身份”和“状态”解耦，这也是我在第2章标注口径里强调两层结构的原因。检测模型只负责输出“这是商品区域+陈列状态”，身份识别交给一个独立的轻量特征嵌入分支，对检测框内的商品区域提取256维特征向量，跟门店SKU特征库做最近邻匹配。新品上线时只需要给特征库增量添加新SKU的样例特征，不用重训检测主干。放弃让模型直接记忆SKU身份，是合规性检测项目后期唯一可持续的方案。
6. 影子模式加特征漂移监测：让模型在不该信的时候闭嘴
自动告警系统最怕的不是精度不够，而是误报太多之后运营团队对系统失去信任。我常用的做法是上线前跑两周影子模式：新模型和旧规则并行，系统只记录两者判定不一致的样本，不向门店下发告警。两周之后人工复看这些不一致样本，把误报率和漏报率算清楚，再决定是否全量放量。这一步看起来多花了两周时间，实际等于给模型买了份后悔药。
影子模式跑通后，还有一个容易被忽略的问题：模型上线后货架变了怎么办。灯光改造、货架位移、新品上架都会让输入分布发生偏移，但系统还在按旧标准输出告警，这就是“该闭嘴的时候没闭嘴”。我的习惯是用特征漂移监测来兜底：每次巡检时把检测框内的商品特征向量回传服务器，按货架位为单位做分布统计，然后计算当日特征均值与历史分布的马氏距离。
from scipy.spatial.distance import mahalanobis import numpy as np # samples: 当天某个货架位的N个256维特征向量 # hist_mean/hist_cov: 历史窗口的特征均值与协方差矩阵 day_mean = np.mean(samples, axis=0) dist = mahalanobis(day_mean, hist_mean, hist_cov) # 阈值取历史马氏距离中位数的3倍，具体倍数按数据量调整 if dist > 3 * median_dist: # 进入观察名单：关闭自动告警，只落盘图片 disable_alert(shelf_id)这个监测脚本的逻辑是：货架位是固定的，商品陈列短期不变，特征分布应该很稳定；马氏距离突然变大，意味着灯光、货架结构或者商品本身发生了变化，此时自动告警不再可信，应当降级为“只记录样本”的被动模式。阈值不能上线第一天就定死，要先用历史两周的数据把中位数和协方差矩阵算稳，否则刚启动头几天就会误触。
这段时间做零售货架巡检项目，我最深的教训是：移动端部署不是把模型导出成ONNX就结束了，量化误差、真机帧率、运营流程三者互相牵制。在训练集上把mAP刷到0.95的意义，远小于把“错放”的误报率控到运营能接受的范围。另一个保持到现在的习惯是，每次版本上线前都会拿真机跑一遍全链路日志：从摄像头帧到告警弹窗逐帧打时间戳，看队列有没有堆积、模型在哪些帧上“不该信却硬报了”。模型的能力边界和业务的可接受边界之间那条线，只能靠这类笨办法一点一点试出来。希望这些经验能帮到你。
本文还有配套的精品资源，点击获取
