1. 先弄清楚“性能”指什么评估对象与指标体系人脸识别系统的性能评估最忌讳的就是拿一个准确率数字当结论。我在实际项目里见过太多次这种情况某同事在自建测试集上跑出 99.2% 的准确率汇报时很漂亮结果上线第一天业务侧就反馈“认错人”。问题不在模型在于评估的对象、口径和被比较的东西从一开始就错位了。人脸识别系统从来不是一个单一模型它是一条由人脸检测、关键点对齐、质量筛选、特征提取、向量比对、阈值决策再加后续的人员跟踪与 ID 维持共同组成的流水线。性能评估必须把这条流水线当成一个整体来拆否则你测的只是其中某个环节的实验室成绩。这一章我想先把“评什么”说清楚。评估对象弄不明白后面所有优化动作都是盲打。尤其是当标题里同时出现“人员检测与跟踪”和“人脸识别”时很多人会把检测指标、识别指标、跟踪指标混在一张表里汇报看起来信息量很大实际上谁也读不懂结论从哪来、边界在哪。我习惯的做法是先画一条数据流把每个环节的输入输出、可测指标、失败模式都列出来再决定测哪几项、优先级怎么排。1.1 拆解流水线五个环节各自测什么一条典型的人员检测与人脸识别流水线大致是这样走的输入视频帧或图片流检测模块给出人脸框或人体框对齐模块根据关键点做仿射变换把人脸摆正质量模块打分决定这张脸要不要参与后续特征模块输出一个定长向量比对模块在底库里做相似度检索最后结合业务阈值输出身份结论。如果还带跟踪那么检测结果要先经过多目标跟踪关联成轨迹轨迹上再做人脸识别投票。每个环节的失败都会向下游放大而最终指标是这些放大叠加后的结果。所以评估至少有五个层次。第一层是检测人脸框的召回率和定位精度常用 IoU 阈值下的 AP注意小脸、侧脸、遮挡、逆光这些子集要单独拆开看。第二层是对齐与质量对齐失败率、关键点误差、质量分分布这一层不产生漂亮数字但对最终误识率的影响远比大多数人想象的大。第三层是特征与比对1:1 验证看 ROC、EER、TARFAR1:N 检索看 Rank-1、Rank-5、mAP 和误接受率。第四层是决策与业务在特定阈值下的人均误报次数、通过率、人工复核比例。第五层是跟踪侧MOTA、MOTP、IDF1、ID Switch 次数。我一般会强调一个观点面向业务的性能评估最终只认后两层。你 EER 做到 0.3%但业务要求的是每人每天误报不超过 0.1 次中间还差着阈值选择、底库规模、质量分布三道坎。反过来只看业务指标也不行因为业务指标一旦恶化你不知道是特征模型退化、底库污染还是视频源的光照变了。两层一起看才能定位。注意不要把不同底库规模下的 1:N 识别率横向比较。底库从 1 万涨到 10 万Rank-1 掉几个点是正常的掉多少取决于特征分布和检索策略直接对比毫无意义。1.2 指标口径不统一评估基本等于白做我在不同团队之间做过几次评估体系对齐发现最容易出问题的不是算错而是口径不一致。同一个“准确率”有人指 Top-1 命中率有人指阈值化之后的通过率有人指人工复核后确认正确的比例。这三种数字放在一个会议上讨论怎么也对不上。所以做评估的第一步不是跑脚本而是把指标定义写成一张表全员确认脚本里严格按定义实现。下面这张表是我常用的指标清单直接照抄就能用重点是“注意点”那一列这是最容易踩坑的地方。指标含义适用场景注意点FAR / FRR误接受率与误拒绝率1:1 验证、门禁通行必须绑定具体阈值脱离阈值报 FAR 是耍流氓TARFAR在给定误接受率下的通过率安全等级要求明确的场景FAR 取值越小样本量要求越高1e-4 至少需要十万级负样本对EER误接受与误拒绝相等的点快速横向比较模型只在分数分布干净时有意义跨域会失真Rank-1 / Rank-5底库检索首位/前五位命中率1:N 检索、人员查找底库规模与人脸数量必须写清楚多人多照要说明合并规则mAP平均精度均值检索排序质量评估对正样本数量敏感单人单照时参考价值有限MOTA多目标跟踪总体准确度视频人员跟踪由漏检、误检、ID 跳变合成单项恶化会被平均掩盖IDF1身份维度的跟踪一致性强调 ID 稳定的场景比 MOTA 更能反映“跟丢了又找回”的问题ID Switch轨迹 ID 变更次数长时跟踪、轨迹归档统计口径要明确连续多少帧算切换表格填完还要补一条约定所有指标必须标注数据集名称、版本、底库规模、阈值、评估日期。缺任何一项这个数字三个月后就没法复现。我吃过这个亏某次降本把评估脚本的随机采样种子改了季度复盘时同一份数据跑出两个差 1.7 个点的结果查了两天才发现是负样本对采样不同。1.3 阈值这件事必须从业务反推阈值不是调出来的是算出来的。业务上常见的要求是“每人每天误报不超过 N 次”那么可以反推需要的 FAR。假设某场景日均比对请求 2000 次要求误报不超过 0.2 次那么 FAR 上限就是 0.2 / 2000 1e-4。这个数字一出来你就知道评估集需要多少负样本对才具备统计意义至少要观察到十次以上的误接受事件样本量得在十万到百万量级否则测出来的 FAR 全是噪声。正样本侧同样要算。假设底库 5 万人每人平均 3 张注册照比对时取最高分。1:N 的误接受概率粗略随底库规模线性增长5 万人规模的 Top-1 误接受率约等于单对 FAR 乘以底库人数所以单对 FAR 要求会比 1:1 场景严苛一两个数量级。这就是为什么很多团队在 1:1 上做得很好一上 1:N 就崩本质是没按检索规模重新算过阈值。实操上我会做一张阈值-业务对照表把 FAR、TAR、通过率、人工复核率、人均误报次数放一起给业务方选。选完定版写进配置模型或数据一变就重新生成这张表。这里的关键认知是阈值是业务参数不是模型参数不该由算法同学单独拍板。2. 评估集如何搭建它比模型更能决定结论我经常说评估集的质量决定了你所有结论的上限。模型再好评估集不具代表性结论一样是错的反过来评估集做扎实了哪怕模型一般你也能清楚知道它弱在哪、能不能用。这一章讲评估集怎么搭包括底库分层、跨域采样、难例构造和标注质控都是实打实能落地的做法。2.1 三层划分底库、探针集、负样本池评估集我习惯分三层来组织。第一层是注册底库模拟真实入库数据包含人员 ID、每人多张照片、入库时的质量分布。第二层是探针集模拟真实查询来源要和底库有明显差异比如不同摄像头、不同时间段、不同光照条件。第三层是负样本池用于计算 FAR必须保证里面的人在底库中完全不存在这一点最容易出错——某个 ID 只改了个名字重新入库就被当成负样本FAR 立刻虚高。三层的数据来源要尽量贴近生产。我一般会按摄像头、时段、光照、遮挡程度做交叉分层每层保证最低样本量。比如某园区有 12 路摄像头白天 8 路、夜间 4 路那么探针集里夜间样本至少占三分之一否则你永远发现不了夜间误识率飙升的问题。注册底库也一样要包含一定比例的“劣质注册照”比如侧脸、戴帽、逆光因为真实入库时业务人员不会帮你筛选。规模上给个参考底库 1 万到 5 万人、探针 5000 到 2 万张、负样本池 10 万以上这套配置跑一次完整评估大约需要十几分钟到半小时足够支撑日常迭代。如果要验证 1e-4 级别的 FAR负样本池得往百万级走这时候就得上分片评估和向量化计算不能拿单机脚本硬扛。2.2 主动构造难例让结果提前“变坏”等生产环境暴露问题太被动我习惯在评估集里主动埋难例。做法是围绕已知的薄弱维度构造子集每个子集单独出指标而不是混在一起看总分。常见的难例子集包括大角度侧脸偏航超过 45 度、强逆光、口罩或手部遮挡、低分辨率人脸框小于 60 像素、跨年龄注册照与探针相隔两年以上、双胞胎或高相似人员。这里有个经验难例子集不要追求“多”要追求“准”和“可复现”。每个子集几十到几百张就够关键是标签准确、每次评估都用同一批。我见过团队为了凑难例从网上随便下了几千张模糊人脸结果这些图和业务场景完全无关指标难看但毫无指导意义优化方向也被带偏。另一个做法是构建“高相似负样本对”也就是长相接近但不同人的照片对。这类样本对是 1:N 误识的主要来源专门拿来算 FAR 会比随机负样本对严格得多。构造方式可以借助模型自己先用当前模型跑一遍全量负样本池把相似度最高的一批人工复核确认是不同人后纳入高相似子集。这样得到的子集能持续暴露模型盲区价值很高。2.3 标注质控错误标签会把优化带进沟里标注错误在评估集里是隐形杀手。一张标错的人脸可能让你的误识率凭空多出几个百分点然后你花两周去查模型最后发现是数据问题。我现在的做法是双人标注加抽样复核冲突样本进仲裁队列。人脸识别场景的标注主要是两类身份标签和框/关键点。身份标签的冲突率一般不高但如果底库来自多个业务系统重名、一人多号、离职未清理这些问题会带来大量脏数据。具体质控手段有几个。第一用模型辅助查重对底库做全员两两相似度检索把相似度极高但标签不同的样本对挑出来人工确认这一步能捞出大部分“同一人被标成两人”的问题。第二用质量分过滤明显不可用的注册照避免它们污染比对统计。第三建立版本化机制评估集每次修改都打标签、记变更日志绝不覆盖原文件。提示评估集一旦定版就别轻易动。如果必须修改完之后要把历史结论全部重跑一遍否则前后数字不可比复盘时会非常痛苦。3. 从脚本到报告一次完整的评估实操讲完指标和数据这一章直接上操作。我把一次完整评估拆成四步环境与数据准备、各环节指标计算、跟踪侧指标计算、报告生成与结论判定。代码用 Python 写依赖 numpy、scikit-learn、faiss都是常规库。下面的代码不是示意是我实际项目里裁出来的简化版可以直接改改就用。3.1 环境准备与数据组织数据目录我固定成一套结构避免每次换项目重新想。大致是这样dataset/ gallery/ # 注册底库 id_00001/ 001.jpg 002.jpg id_00002/ ... probe/ # 探针集 id_00001/ p_001.jpg ... negative/ # 负样本池与 gallery 无交集 n_00001.jpg ... meta/ gallery.csv # id, path, quality_score, camera probe.csv split.json # 难例子集划分依赖安装很简单要注意版本锁定尤其是 faiss 和 numpy 的兼容性不同版本之间的行为差异会直接影响检索结果。pip install numpy1.26.4 scikit-learn1.4.2 faiss-cpu1.8.0 pandas2.2.2读取数据阶段我建议一次性把特征算完并缓存成.npy后面反复评估直接加载不然每次调阈值都重新提特征时间全浪费在 GPU 上。缓存文件命名带上模型版本和时间戳避免混用。import numpy as np, pandas as pd, os def load_meta(csv_path): df pd.read_csv(csv_path) assert {id, path}.issubset(df.columns), 缺少必要列 return df def build_feature_cache(df, extractor, cache_path): if os.path.exists(cache_path): return np.load(cache_path) feats, valid [], [] for i, row in df.iterrows(): f extractor(row[path]) # 返回归一化后的定长向量 if f is None: continue feats.append(f) valid.append(i) feats np.vstack(feats).astype(float32) np.save(cache_path, feats) df.iloc[valid].reset_index(dropTrue).to_csv( cache_path.replace(.npy, _meta.csv), indexFalse) return feats这里有两个细节值得说。第一特征一定要做 L2 归一化之后用内积就是余弦相似度省去每次算距离。第二提特征失败的样本必须记录下来不能静默丢弃因为失败率本身就是一个质量指标检测漏掉的人脸往往就是难例。3.2 1:1 与 1:N 指标计算1:1 验证的指标计算比较直接正样本对按 ID 组合负样本对从负样本池随机取算相似度后扫描阈值得到 ROC进而得到 TARFAR 和 EER。from sklearn.metrics import roc_curve def compute_roc(pos_scores, neg_scores): y np.r_[np.ones(len(pos_scores)), np.zeros(len(neg_scores))] s np.r_[pos_scores, neg_scores] fpr, tpr, thr roc_curve(y, s) return fpr, tpr, thr def tar_at_far(fpr, tpr, target_far1e-3): idx np.searchsorted(fpr, target_far) idx min(idx, len(tpr) - 1) return float(tpr[idx]) def eer(fpr, tpr): diff np.abs(fpr - (1 - tpr)) return float(fpr[np.argmin(diff)])注意tar_at_far里的边界处理如果测试集的负样本不够多fpr 序列根本到不了 1e-3 以下这时searchsorted会返回末尾值看起来有结果实际是外推出来的假数字。所以我在脚本里会加一条断言负样本对数量必须大于1/target_far的十倍不满足就直接报错不允许出报告。1:N 检索用 faiss 做底库向量建索引探针逐条查询取 Top-K。千万级以下用 IVF-Flat 就够nlist 按4 * sqrt(N)取nprobe 从 16 开始往上调边调边看召回和耗时的平衡点。代码大致如下import faiss def build_index(gallery_feats, nlistNone): d gallery_feats.shape[1] nlist nlist or int(4 * np.sqrt(len(gallery_feats))) quantizer faiss.IndexFlatIP(d) index faiss.IndexIVFFlat(quantizer, d, nlist, faiss.METRIC_INNER_PRODUCT) index.train(gallery_feats) index.add(gallery_feats) index.nprobe 16 return index def eval_rank(index, probe_feats, probe_ids, gallery_ids, ks(1, 5)): D, I index.search(probe_feats, max(ks)) hit {k: 0 for k in ks} for row, pid in enumerate(probe_ids): for k in ks: cand gallery_ids[I[row, :k]] if pid in cand: hit[k] 1 return {k: hit[k] / len(probe_ids) for k in ks}跑完这一步顺手把“最相似但身份错误”的样本对导出来看看通常会看到一批高相似负样本这是最有价值的分析素材。我一般会抽 100 对人工过一遍看看是姿态相近、光照相近还是底层特征在某些人群上区分度不足。3.3 跟踪侧指标MOTA 与 IDF1 怎么算带跟踪的场景还需要算 MOTA、IDF1、ID Switch。这几个指标依赖“检测框与真实框的匹配”这一步匹配用匈牙利算法基于 IoU 做。MOTA 由漏检、误检、ID 跳变三项合成公式是1 - (FN FP IDSW) / GT。IDF1 则是从身份维度算全局匹配后的 F1 值更能反映跟踪的连续性。from scipy.optimize import linear_sum_assignment def match_frame(gt_boxes, pred_boxes, iou_thr0.5): if len(gt_boxes) 0 or len(pred_boxes) 0: return [], list(range(len(gt_boxes))), list(range(len(pred_boxes))) iou compute_iou_matrix(gt_boxes, pred_boxes) rows, cols linear_sum_assignment(-iou) matches [(r, c) for r, c in zip(rows, cols) if iou[r, c] iou_thr] matched_g {r for r, _ in matches} matched_p {c for _, c in matches} unmatched_g [i for i in range(len(gt_boxes)) if i not in matched_g] unmatched_p [i for i in range(len(pred_boxes)) if i not in matched_p] return matches, unmatched_g, unmatched_p这段代码里compute_iou_matrix需要自己实现用 numpy 广播算就行注意别用循环几千个框的循环会拖到秒级。算出逐帧匹配后再按轨迹维护身份映射统计 ID Switch。这里有个统计口径要定清楚同一帧内 ID 分配混乱算不算切换、轨迹短暂消失后重新出现算不算切换。我一般按“连续丢失超过 N 帧后重新分配了不同 ID”才算一次切换N 取 5 到 10写进评估说明。3.4 报告组织结论怎么下才不心虚报告我固定成三段式。第一段是总览表给出各指标当前值和上次版本的对比只放变化超过阈值的项。第二段是分层诊断按摄像头、时段、光照、人脸尺寸分组列出指标标出最差的三个子集。第三段是样本佐证每类失败模式贴 5 到 10 张图注明失败原因分析。判断能不能上线我一般看三条线整体指标是否达标、最差子集是否在可接受范围、关键业务指标如人工复核率是否稳定。三条都过才发版任何一条红线就回退。这套流程听起来繁琐但跑顺了也就半天时间比上线后救火便宜太多。4. 优化路径先处理误识问题再谈提升准确率优化这件事方向比力度重要。很多人一上来就换更大的模型、加更多的数据结果误识率没降算力成本先翻倍。我的经验是先看误识的构成从成本和收益比最高的地方下手。通常顺序是阈值与分数校准、质量门控、检索层参数、模型侧压缩、工程侧调度。这一章逐个讲附上实测数据和参数选择的依据。4.1 分数校准与阈值分层不同模型输出的相似度分数分布差异很大直接拿同一个阈值套用会出事。校准的做法是在验证集上按人员或摄像头分组统计分数分布用等距分箱或逻辑回归把原始分数映射到统一的“可比分数”空间。最简单的做法是分段映射比如按质量分档每档单独定阈值。def calibrate_by_quality(scores, quality, bins(0.0, 0.3, 0.6, 1.0)): out np.zeros_like(scores) for lo, hi in zip(bins[:-1], bins[1:]): mask (quality lo) (quality hi) if mask.sum() 100: out[mask] scores[mask] continue # 用该档负样本分布的高分位点做平移 q np.percentile(scores[mask], 99.9) out[mask] scores[mask] - (q - 0.5) return out逻辑很朴素质量差的档位整体分数偏高且波动大那就把该档的高分位点对齐到同一个基准。实测下来分层阈值能让低质量子集的误接受率下降三成左右代价是通过率略降。如果业务不能接受通过率下降那就得回到质量门控那一步把明显不可用的图挡在比对之前。注意分档阈值一定要在生产数据上校准实验室数据的光照和摄像头型号单一校准出来的档位边界经常不适用。4.2 质量门控把垃圾挡在门外质量门控是我认为投入产出比最高的一环。具体做法是给每张人脸算一个综合质量分由清晰度拉普拉斯方差、人脸尺寸、姿态角、遮挡比例、亮度对比度加权得到低于阈值的注册照拒绝入库低于阈值的查询直接判“无法识别”交给其他手段处理。这个动作看似会让识别率下降实际上是把“高置信度错误”转化成了“明确的无法识别”业务体验反而更好。阈值怎么定我一般按召回-精度的思路来把质量分和“识别是否正确”做相关性分析画一条累计曲线找到错误率快速上升的拐点。实测某项目里把质量分最低的 8% 注册照剔除后1:N 的 Rank-1 反而提升了 1.3 个百分点因为那些照片本来就在干扰检索排序。这个结论有点反直觉但很好解释脏数据在底库里就是噪声源清掉噪声干净数据的排序自然变好。4.3 检索层优化索引参数与召回平衡底库上万以后检索层的参数对整体指标的影响开始显现。IVF 索引的核心参数是 nlist 和 nprobenlist 决定粗聚类粒度nprobe 决定每次查询扫描多少个桶。nprobe 太小真实目标可能落在没被扫描的桶里召回直接掉nprobe 太大延迟线性上升。我的调参方法是固定 nlist把 nprobe 从 8 扫到 128记录 Rank-1 和 P99 延迟找拐点。参考数据底库 20 万、512 维、IVF-Flatnlist 取 1200nprobe 从 8 提到 32 时 Rank-1 提升 2.1 个点再往上提到 64 只提升 0.3 个点延迟却翻倍。所以 32 是这批数据上的合理点。如果业务对延迟敏感还可以考虑 PQ 压缩但要注意 PQ 会损失精度量化位数越低损失越大通常 64 字节段的 PQ 在百万级底库上 Rank-1 损失在 1 到 3 个点之间需要实测确认能否接受。增量更新也是个坑。底库不是静态的每天都有新增注册IVF 索引支持 add 但训练分布会漂移长期不重训会出现召回衰减。我的做法是每周做一次小规模重训、每月做一次全量重建重建期间用双索引切换避免服务中断。4.4 模型侧量化、蒸馏、裁剪的取舍模型侧优化的前提是先确认瓶颈在哪。如果评估显示指标已经达标只是延迟或成本超预算那优化目标就是“不掉点地提速”如果指标本身不达标那应该先补数据和难例而不是压缩模型。这两种情况的方法完全不同别混。提速方面INT8 量化是最常用的手段实测在主流骨干网络上能带来两到三倍加速精度损失通常在 0.3 到 1 个点之间具体看量化方式和校准集质量。校准集一定要覆盖真实场景的分布特别是低光照和侧脸否则量化后的模型在这两类上掉点特别明显。知识蒸馏适合小模型追赶大模型用大模型的特征输出做监督小模型在同等延迟下能提升 1 到 2 个点。裁剪对精度的伤害相对更大我只在端侧场景考虑并且一定要在裁剪后做一轮短周期的微调。有个容易忽略的点优化后的模型必须重新跑一遍完整评估包括所有难例子集。我见过量化后整体指标只掉 0.4 个点但侧脸子集掉了 6 个点的情况如果只看总分这个风险就被掩盖了。4.5 工程侧流水线与资源调度工程优化的空间往往比模型优化更大。典型问题是整条流水线串行执行检测 20ms、对齐 5ms、特征 15ms、检索 8ms加起来 48ms25fps 直接跑不满。改造成流水线并行之后吞吐能提升一倍以上因为各阶段用的资源不同GPU 和 CPU 可以错峰。from concurrent.futures import ThreadPoolExecutor import queue class Pipeline: def __init__(self, stages, workers2): self.stages stages self.qs [queue.Queue(maxsize32) for _ in range(len(stages) 1)] self.pool ThreadPoolExecutor(max_workersworkers * len(stages)) def run(self, frame): self.qs[0].put(frame) for i, fn in enumerate(self.stages): def worker(idxi): while True: item self.qs[idx].get() if item is None: self.qs[idx 1].put(None) break self.qs[idx 1].put(fn(item)) self.pool.submit(worker)队列长度要设上限不然内存会一路涨上去。批处理也是关键把多路视频的帧凑成一个 batch 送 GPU利用率能从 40% 提到 80% 以上但要注意 batch 增大会带来排队延迟实时场景下 batch size 一般控制在 8 到 16。显存管理上特征提取模型的显存占用相对固定容易出问题的是检测模型在多人场景下的峰值。我的做法是给每个阶段设显存水位线超过就降 batch 或者跳帧宁可丢几帧也不要 OOM 导致整条流水线重启。5. 跟踪链路里的性能隐患检测抖动与 ID 跳变标题里带“人员检测与跟踪”这一块单独拎出来讲因为它和人脸识别耦合之后的问题特别隐蔽。很多系统单独测检测和识别都不错一连起来就出问题同一个人在两秒内被识别成三个人或者轨迹断断续续导致投票不够。这一章讲讲时序对齐、ID 跳变成因和投票策略。5.1 检测、跟踪、识别的时序对齐一个常见的错误是每帧都做人脸识别然后把结果直接覆盖到轨迹上。这样做的后果是某一帧的误识会立刻污染整条轨迹的身份而且计算量巨大。正确做法是分层检测每帧跑跟踪每帧更新人脸识别按需触发比如轨迹首次出现时、轨迹持续 N 帧后、或者质量分达到阈值时触发一次。触发策略我一般这样设轨迹连续存在 10 帧以上才触发识别触发后每 30 帧复检一次并在轨迹上累积多次识别结果做投票。这样做有两个好处一是过滤掉大量短暂出现的误检二是把识别算力集中用在稳定目标上。实测在 20 路视频的场景下识别调用量能降到原来的三分之一识别准确率反而提升因为参与识别的帧质量更高。这里有个时序上的细节要注意识别结果要绑定在“识别触发时刻”的轨迹上而不是当前帧的轨迹。如果中间发生了 ID 切换识别结果可能被错误归到新轨迹上。解决办法是在轨迹对象里记录一个版本号识别结果回填时校验版本不一致就丢弃。5.2 ID Switch 的成因与止血ID Switch 的成因我总结下来主要有四类。第一类是遮挡人走过去被柱子挡住几帧再出现时关联不上分配了新 ID。第二类是检测框抖动IoU 波动导致匹配失败。第三类是人群密集时的交叉两个轨迹短暂重叠匹配错位。第四类是检测模型在特定姿态下漏检轨迹被迫中断。止血手段按成本从低到高排降低匹配的 IoU 阈值可以缓解抖动但会增加错配加入运动模型预测位置用卡尔曼滤波给出预测框再做匹配对遮挡场景改善明显引入外观特征用轻量的行人重识别向量做二次匹配能显著降低交叉场景的错误关联最后才是换更强的检测模型。我实测过一组对比纯 IoU 匹配在遮挡场景下 ID Switch 大约每百帧 6 次加卡尔曼预测降到 4 次再加外观特征降到 1.8 次。代价是单帧关联耗时从 1ms 涨到 4ms对于 20 路以上的场景需要评估是否值得。5.3 多帧投票延迟与稳定性的平衡投票策略直接决定识别结果的稳定性。最简单的多数投票取累计结果里出现次数最多的 ID超过一定票数才确认。改进版是加权投票按质量分和相似度加权质量高的帧权重更大。我一般用加权投票并且加一个“拒绝确认”的兜底如果最高票的权重占比不到 60%就标记为待定不进业务系统。投票窗口的大小是个权衡。窗口太短几帧就能确认响应快但容易被单帧错误带偏窗口太长稳定性好但响应慢业务上可能等不了。我的经验值是门禁通行这类要求快的场景窗口取 5 到 8 帧轨迹归档这类要求准的场景窗口取 20 到 30 帧。同一套系统里可以按业务配置两套策略没必要统一。注意投票窗口要和轨迹的生命周期对齐如果轨迹平均只存活 12 帧你设 30 帧的窗口永远凑不齐票数最后全是待定。6. 常见问题速查与踩坑实录6.1 问题速查表下面这张表是我这些年攒下来的高频问题按现象、可能原因、排查动作、处理建议四列整理遇到问题时按现象查会快很多。现象可能原因排查动作处理建议整体识别率正常某时段骤降光照变化、视频源切换按摄像头和时段分组统计补该时段样本做光照归一化1:1 表现好1:N 表现差阈值未按底库规模重算核算单对 FAR 与底库规模重算阈值收紧 FAR 要求误识集中在特定人员对高相似负样本、双胞胎导出高相似错误对人工复核加入难例微调设置人工复核兜底评估结果前后不一致数据版本变更、采样种子变化对比评估集版本与脚本参数建立版本化与固定种子机制低质量图通过率异常高质量门控未生效或阈值过低检查质量分分布与门控逻辑提高门控阈值按档位分层定阈检索延迟抖动大nprobe 过高、索引未加载满监控 P99 延迟与索引状态调低 nprobe索引常驻内存轨迹 ID 频繁切换遮挡、检测抖动、密集交叉统计 ID Switch 与遮挡帧占比加运动预测与外观特征批量处理后精度掉点量化校准集不匹配分场景对比量化前后指标重做校准集覆盖低光与侧脸显存占用持续上涨队列无上限、特征缓存未释放监控队列长度与显存曲线设队列上限及时释放中间结果6.2 几条不会写在文档里的经验第一条评估脚本要和生产代码共用同一份预处理。我见过评估脚本用了一套归一化参数生产用了另一套结果线下 98%、线上 91%查了一周才发现是均值方差写错了。现在我的做法是把预处理抽成独立模块两边 import 同一份代码谁改都得走评审。第二条别迷信单一数字养成看分布的习惯。准确率是均值均值会掩盖长尾。我每次评估都会画一下相似度分数分布的正负样本直方图两条曲线的重叠区域就是难例所在。如果重叠区域突然变宽即使总分没掉也说明模型在某类数据上已经开始退化该提前介入了。第三条优化要留对照组且对照组不能同时改多个变量。我踩过的最大的坑是一次性上了量化、换了索引、调了阈值结果指标掉了 2 个点完全不知道是哪一项导致的只能全部回退重来一遍。后来我强制自己每次只改一个变量改完跑完整评估记录结果再改下一个。慢是慢一点但可靠。第四条评估周期要和数据更新节奏匹配。底库每周新增几千人评估集如果三个月不更新指标就是自欺欺人。我现在的节奏是每月做一次评估集增量更新每季度做一次全量重建每次模型发版跑一次完整评估。这三件事写进流程比任何优化技巧都更能保证系统长期稳定。第五条给业务方看的报告一页就够。技术细节放附录首页只放三个数当前的通过率、人均误报次数、最差子集的指标。业务方只关心这三个数能不能接受其余都是过程。这一点我在多个项目里验证过报告越短决策越快返工越少。
