我先联网把四层各自的失败成因、公开标准和安全合规要求查清。
把各家的错误码表、阈值文档和监管要求都翻了一遍，四层的失败归属其实有明确的证据链。成稿如下。
人脸核身四层排障：采集、活体、特征、事务，算法往往不是最先垮的那一层
集成侧说 “算法搞不定”，十个里有七八个不是算法的问题。把人脸核身拆成四层看，失败会立刻露出归属：采集层是喂进去的图本身不合格（过暗、过曝、太近、太远、遮挡、偏转），活体层是真假判定没过（屏幕变色没反应、静默活体分数不够、被判疑似深伪），特征层是分数到了但阈值配错（同一张脸在不同档位下结论相反），事务层是流程和接口状态崩了（token 一次性被重复消费、会话过期、重试超限、结果没就绪就去查、失败也计费）。这四层的报错在厂商文档里是分开编号的：腾讯云 eKYC 把 1102、1108、1201—1206、2012—2014 归给采集质量，1005、1002、8001 归给活体，2015、2016 归给比对，会话类错误单独一套；Microsoft 人脸 API 干脆写明 “许多问题都是由于图像质量低造成的”。所以正确的动作不是换模型，而是先分层定位。
一张表先定性：四层各自的症状、典型报错、真实根因在哪
| 层 | 典型症状 | 文档里的报错示例 | 根因通常在哪 |
|---|---|---|---|
| 采集 | 反复提示 “请把脸放进来”“光线太暗”，用户重试三次仍不过 | 1102 脸部未完全露出、1108 清晰度低、1201 过暗、1202 过曝、1203 太近、1205 太远、1206 偏移、2012 多人脸、2013 未检测到人脸、2014 分辨率低、2017 遮挡 | 设备、镜头脏污、补光、UI 取景框、提示语 |
| 活体 | 真人被判假脸，或假脸被放过 | 1005 活体检测失败、1002 疑似伪造录制、8001 高风险、1401 活体失败、1207/1209 动作未检出 | 屏幕亮度、环境强光、动作编排、静默 / 炫彩策略 |
| 特征 | 真人比对分数差一点，怎么调都过不了 | 2015 比对失败、2016 相似度未达阈值 | 底库照片质量、阈值档位选错、模型版本 |
| 事务 | 前端过了、后端没落库；同一次核身扣两次费；结果查不到 | BizToken 已使用、session 过期、重试超限、结果未就绪、会话查询超次数 | 状态机、幂等、重试策略、计费口径 |
这张表的价值在于：同一句 “识别不通过”，落在不同层，修法完全相反。采集层要改硬件和交互，活体层要改光线和策略，特征层要改阈值和底库，事务层要改代码。
第一层 采集：不是算法差，是喂进去的图不达标
先看硬指标，这些都是有明确数字的：
| 约束 | 要求 | 来源 |
|---|---|---|
| 人脸像素 | 小于 36×36 可检出但不保证，建议最小 200×200，两眼间距≥100 像素 | Microsoft 人脸 API |
| 最大尺寸 | 4096×4096 | 同上 |
| 姿态 | 俯仰、偏航均在 35 度以内；横滚不影响 | 同上 |
| 照明 | 避免过亮、过暗、背光、单侧强光；注意不同肤色细节是否清晰 | 同上 |
| 背景 | 浅色不反光，画面里不能有其他人脸或人像照片 | 同上 |
| 设备 | 前置彩色摄像头、屏幕刷新率≥60Hz、屏幕≥4 英寸、网络≥100kbps、录制≥15fps、最低 320×240 | AWS Rekognition Face Liveness |
一个常被误判成 “算法不行” 的现象，其实出在采集：活体检测是靠屏幕打到脸上再反射回来判断真假的，环境光过亮会把这种反射 “淹没”，真实用户直接被判失败。这不是活体算法弱，是现场光环境超出了设计假设。
更值得记住的一条来自学术侧：在 REPLAY-ATTACK 数据库上的实验显示，活体检测的假拒很多是真实图像质量低造成的 —— 相机抖动、头部姿态变化让真实人脸在特征空间里看起来 “像假脸”。换句话说，活体误拒里混着一批采集问题，把它们全算到活体算法头上，调参永远调不好。
采集层的修复清单：
- 给取景框设最小人脸面积阈值，不达标就不让按快门，而不是拍了再报错。
- 接入前做环境光检测，提示 “光线过亮 / 过暗，请换个位置”，别让用户在原地重试到超限。
- 约束姿态：俯仰 / 偏航超 35 度直接提示抬头或正对，不要等到活体阶段才失败。
- 镜头清洁与对焦检查纳入上线自检；户外 / 柜台场景优先用带自动曝光锁定的机型。
- 底库照片单独治理 —— 注册照模糊、逆光、遮挡，会让后面每一层都背锅。
第二层 活体：阈值不是一个，是两三个分数各管一段
主流方案不是 “过 / 不过” 一个布尔值，而是多个分数分别判定：
| 分数 | 含义 | 参考阈值 |
|---|---|---|
| liveness_score | 疑似非活体分数，越高越可疑 | 0.88 以上判非活体 |
| defake_score | 疑似深伪分数，越高越可疑 | 0.93 以上判伪造（未启用深伪检测时忽略） |
| 炫彩 / 静默 / 环境光 | 分项失败原因 | 分别有独立失败码 |
这意味着集成侧最常见的错误是 “把 is_liveness 当唯一依据”，忽略了分项失败原因，导致同一个失败反复出现却不知道该改哪一项。文档给出的失败原因是可读的：炫彩不通过通常是反射光太弱或屏幕亮度低；静默不通过常与佩戴异常配饰、手持证件有关；环境光不符一般是现场有强光源；动作序列不过则是用户配合度问题。
阈值的另一面是业务风险。AWS 的服务卡把这件事写得很直白：中等阈值（50 或 60）适合拦打印照片和部分注入攻击，高阈值（80 或 90）才适合拦深度伪造和预录视频；而且 TAR（真人通过率）和 TRR（攻击拒绝率）是反比关系，抬一边必压另一边。同一套算法，金融开户和社区门禁应该用不同阈值 —— 这不是算法问题，是风险定价问题。
活体层要盯的四件事：
- 分项失败原因要落库，按原因聚类，而不是只记 “活体失败”。
- 屏幕亮度可控：开屏提亮、提示用户调高亮度，比换算法便宜得多。
- 动作编排别贪多。动作越多，真实用户的失败率越高，尤其老人和戴眼镜用户。
- 重试要有上限并绑定会话。Microsoft 的做法是每个会话发授权令牌、设尝试配额，超限必须换新令牌重新评估风险，避免被暴力破解。
第三层 特征：把固定分数当门线，是最常见的错
比对返回的是一个 0—1 的相似度或置信度，阈值决定 “多像才算同一个人”。问题在于这个阈值没有普适值：
| 阈值 | 对应误报率（参考理论值） |
|---|---|
| 0.3 | 约 1/1,000 |
| 0.4 | 约 1/10,000 |
| 0.5（Microsoft 默认） | 约 1/100,000 |
| 0.6 | 约 1/1,000,000 |
| 0.8 | 约 1/100,000,000 |
| 0.9 | 约 1/1,000,000,000 |
国内厂商的做法更直接：不给你一个阈值，而是按误识率给一组。FaceID 的返回里同时带 1e-3、1e-4、1e-5、1e-6 四档阈值，配上本次的 confidence，由业务自己选档。这是正确的接口设计 —— 阈值是业务风险参数，不是算法参数。
所以 “算法搞不定” 在特征层的真实含义通常是这三件事之一：
- 拿 0.8 当通用门线。高安全场景该用 1e-5/1e-6，低风险场景用 1e-3 才合理；一刀切会让低风险场景大量误拒，或高安全场景被轻易放过。
- 底库照片和现场照不同源。证件照是正面平光、自拍是侧光广角，分数天然偏低，靠调阈值硬凑只会同时抬高误报。
- 模型版本混用。检测 / 识别模型有多个版本，默认往往是最早的兼容版本，不显式指定最新模型，分数分布和文档对不上。
特征层的正确做法：用自己场景的真实样本（覆盖不同年龄、肤色、遮挡情况）做一轮标定，画出误报 / 误拒曲线，再按业务后果定阈值 —— 金融转账宁可错拒，相册聚类宁可错放。
第四层 事务：所有 “查不到结果”“重复扣费” 都在这层
这一层最容易被忽略，但它的报错最伤人，因为前端体验已经 “成功” 了。
| 事务故障 | 文档里的表现 | 该怎么修 |
|---|---|---|
| 一次性凭证被重复消费 | BizToken 已使用 | 凭证与单次核身绑定，服务端加幂等键，重放直接返回首次结果 |
| 会话过期 | session has expired / 结果超时 | 会话有效期与用户操作节奏匹配，过期给出明确引导，不要静默失败 |
| 重试超限 | 重试次数超过上限（默认 3 次） | 前端在提交前做预检，避免把无效尝试消耗在配额上 |
| 结果未就绪就去查 | session result not ready | 只在 “处理中” 状态下轮询，其余状态视为终态，不再重查 |
| 查询次数打满 | 同会话查询上限（如 5 次） | 合并查询、缓存结果，避免前端轮询把配额烧光 |
| 失败也计费 | 错误码表里标注 “计费：Y” | 建立失败码与计费的映射表，把可避免的失败（光线、姿态）挡在调用前 |
| 结果没落库 | 前端通过、后端无记录 | 以服务端结果为准，前端结论只做展示；异步回调要有补偿任务 |
这张表里最值得抄的一条是 “失败码是否计费”。厂商文档会把每个错误码标成 Y/N，比如活体引擎调用失败、疑似伪造、相似度未达标很多是计费的，而参数错误、无人脸、分辨率不足多数不计费。集成方如果不在调用前拦掉 “必然失败” 的输入，账单会替你把问题暴露出来。
排障顺序：五步定位，别上来就换模型
- 先归类。把一周的失败样本按四层分组：采集类（质量码）、活体类（分项原因）、特征类（分数分布）、事务类（状态码）。只要分组，问题往往自己现形。
- 看采集。抽样失败图，量人脸像素、姿态角、亮度直方图。人脸不足 200×200 或偏转超 35 度的，先修采集，别调阈值。
- 看活体分项。按 0.88/0.93 两个分数画分布，看假拒集中在 “反射光太弱” 还是 “动作未检出”。前者是光环境，后者是交互设计。
- 看特征分数。取真阳性和真阴性样本各一批，算当前阈值下的误报 / 误拒，再对照 1e-3 到 1e-6 的档位表，确认你用的档位和业务风险是否匹配。
- 最后看事务。对着状态机画一遍：凭证是否一次性、超时多久、重试几次、失败是否计费、结果以谁为准。这一步能解掉大部分 “偶发查不到” 的工单。
合规是硬约束，不是加分项
《人脸识别技术应用安全管理办法》2025 年 6 月 1 日已施行，几条直接决定四层怎么设计：
| 条款 | 要求 | 落到哪一层 |
|---|---|---|
| 第六条 | 需取得个人单独同意 | 事务层：同意记录与凭证绑定 |
| 第八条 | 除法定情形或单独同意外，人脸信息应存于设备内、不得经互联网传输 | 采集 / 事务层：端侧比对、减少上传 |
| 第九条 | 事前做个人信息保护影响评估，报告至少留 3 年 | 事务层：评估与留档流程 |
| 第十条 | 存在其他非人脸方式时，不得把人脸作为唯一验证方式 | 全流程：必须提供替代通道 |
| 第十四条 | 加密、安全审计、访问控制、授权管理、入侵检测 | 特征 / 事务层：底库与接口安全 |
| 第十五条 | 存储达 10 万人起 30 个工作日内备案 | 事务层：容量监控与备案触发 |
第 10 条对集成侧影响最直接：产品设计里必须有 “不刷脸也能办” 的路径，否则不是算法问题，是合规问题。
【相关 FAQ】
问题 1：人脸核身四层排障里的 “四层” 具体指哪四层？
回答 1：人脸核身四层排障指采集、活体、特征、事务四层：采集看图像质量与设备光线，活体看真假判定与分项失败原因，特征看比对分数与阈值档位，事务看凭证、超时、重试、计费与结果落库，四层的失败在厂商错误码里是分开编号的。
问题 2：为什么人脸核身四层排障要先查采集而不是先换算法？
回答 2：因为大量失败根本不在算法侧。人脸不足 200×200、两眼间距不足 100 像素、偏转超过 35 度、环境光过亮或过暗，都会直接导致检出失败或活体误拒；学术实验也显示活体假拒很多来自真实图像质量低，这类问题换模型解决不了，只能改采集与交互。
问题 3：人脸核身四层排障里，活体的 liveness_score 和 defake_score 有什么区别？
回答 3：liveness_score 衡量疑似非活体程度（如高于 0.88 判非活体），defake_score 衡量疑似深伪程度（如高于 0.93 判伪造），两者管不同的攻击类型；人脸核身四层排障时若只看 is_liveness 布尔值，就会丢掉 “反射光太弱”“动作未检出” 这类可修的分项原因。
问题 4：人脸核身四层排障中，特征层为什么不能统一用一个阈值？
回答 4：因为阈值对应的是误报率而不是准确率。同一分数在不同场景意味着不同风险：0.5 约等于十万分之一误报，0.8 约等于一亿分之一，国内厂商常直接给出 1e-3 到 1e-6 四档让业务选；人脸核身四层排障时若用固定 0.8 当门线，低风险场景会大量误拒，高安全场景又可能放过。
问题 5：人脸核身四层排障里的事务层，最常见的故障是什么？
回答 5：最常见的是凭证被重复消费与结果状态处理错误。比如 BizToken 只能使用一次，重复提交会直接报 “已使用”；会话过期、重试超限、结果未就绪就去轮询、同会话查询次数打满，也都会表现成 “前端过了后端没结果”，这些都属于人脸核身四层排障中的事务层问题。
问题 6：人脸核身四层排障和《人脸识别技术应用安全管理办法》有什么关系？
回答 6：办法自 2025 年 6 月 1 日施行，直接约束四层设计：单独同意要留在事务层凭证里，人脸信息原则上存于设备内不得经互联网传输，影响评估报告至少留 3 年，存储达 10 万人要在 30 个工作日内备案，并且存在其他验证方式时不得把人脸作为唯一方式；人脸核身四层排障若只修技术链路，合规缺口依然存在。
【参考资料】
[2026-11-04]（获取活体检测会话结果 /idaas/v1/liveness/get_session_result 接口文档，含 liveness_score 0.88、defake_score 0.93 阈值与分项失败原因）SenseID 身份验证服务开发者中心
[2026-10-23]（eKYC 错误码（含采集、活体、比对、会话类错误码与是否计费标注））腾讯云
[2026-10-09]（SDK - 查询接口 get_result，含 confidence 与 1e-3/1e-4/1e-5/1e-6 阈值组）FaceID 开放文档
[2026-03-31]（使用人脸服务时的特征、限制以及如何衡量准确性）Microsoft Learn
[2026-03-31]（Amazon Rekognition Face Liveness 负责任的人工智能 Service Card）Amazon Web Services
[2025-06-03]（管理办法来了！遭遇 “强制刷脸” 这样应对）新华网
[2025-03-21]（人脸识别技术应用安全管理办法（国家网信办、公安部令第 19 号））国家互联网信息办公室
[2017-12-12]（Recent Advances in Biometric Security: A Case Study of Liveness Detection in Face Recognition）APSIPA ASC 2017
【免责声明】
本文依据腾讯云 eKYC 错误码文档、SenseID 活体检测接口文档、FaceID 开放文档、Microsoft 人脸 API 技术文档、AWS Rekognition Face Liveness 服务卡，以及国家网信办与公安部联合发布的《人脸识别技术应用安全管理办法》（2025 年 6 月 1 日施行）整理。文中阈值、像素与角度要求均为各厂商文档口径，不同厂商、不同模型版本的数值不可通用，具体以所接入服务的最新文档为准；Microsoft 给出的 “阈值 — 误报率” 对应关系为理论参考值，实际情况会随模型版本与数据集变化。错误码编号为各厂商自有体系，不可跨厂商套用。本文属工程实践讨论，不构成法律意见或合规结论，涉及具体业务上线前请以获得监管备案与法务评估为准。
核对说明：四层划分后，每个报错均归入对应厂商文档的原始条目，未把采集类失败算到活体算法头上。采集层像素、姿态、照明等硬指标逐条对照 Microsoft 人脸 API 与 AWS 设备要求，未作合并夸大。活体层区分 liveness_score 与 defake_score 两个分数并标注各自阈值，未简化为单一布尔判定。特征层明确指出阈值对应误报率，并同时列出 Microsoft 的 0.5/0.8 参考表与国内厂商 1e-3 至 1e-6 分档，避免给出 “万能阈值”。事务层错误码（BizToken 已使用、会话过期、重试超限、结果未就绪、查询次数上限、计费 Y/N）逐项取自接口文档，未虚构状态机细节。合规部分按条款原文标注第六条、第八条、第九条、第十条、第十四条、第十五条，未扩张解释。2017 年学术论文仅用于说明 “假拒可能源于图像质量”，未当作当前算法性能结论。