概述
人脸搜索会生成一组精简的警告,以便您的团队了解搜索返回Approved 或 Declined 的原因。警告会在 POST /v3/face-search/ 响应的 face_search.warnings[] 数组中返回(参见人脸搜索报告)。
与工作流警告相比,此处的警告采用了精简结构:其中不包含 node_id。文档中定义的响应规范声明了五个字段:risk、additional_data、log_type、short_description、long_description,在运行时 payload 中还会额外携带 feature 字段,该字段在此 endpoint 上始终为 "LIVENESS"。
生成的警告
生成来源:
FaceSearchAPIView.add_warnings(apis/views/face_search.py:250-330);状态推导逻辑:get_face_search_status(apis/views/face_search.py:242-248),其仅针对上述两项黑名单风险执行拒绝。
值得了解的生成规则:
- 黑名单优先级高于重复人脸。 确认为黑名单命中会抑制
DUPLICATED_FACE,疑似黑名单命中会抑制POSSIBLE_DUPLICATED_FACE:对于相同的置信度区间,您绝不会同时收到两者。 additional_data仅引用第一个匹配的人脸,即使matches[]包含多个匹配项也是如此。黑名单警告携带{blocklisted_session_id, blocklisted_session_number, api_service};重复人脸警告携带{duplicated_session_id, duplicated_session_number, api_service};MULTIPLE_FACES_DETECTED携带null。api_service的值为大写格式(例如PASSIVE_LIVENESS);对于工作流会话,该值为null。- 白名单人脸会抑制重复警告:高置信度的白名单匹配会清除
DUPLICATED_FACE/POSSIBLE_DUPLICATED_FACE(但绝不会清除黑名单警告)。
警告文本明细
搜索图片校验拦截
当user_image 中未检测到人脸时,API 会在构建 face_search 对象之前直接拒绝该请求,并返回 HTTP 400 以及 {"error": "No face detected in the image"},因此成功的人脸搜索响应中绝不会出现 NO_FACE_DETECTED 警告。该信息作为顶层 error 字符串返回,而非包含在 warnings[] 中。
可配置项设置
区分确认命中(FACE_IN_BLOCKLIST、DUPLICATED_FACE)与疑似命中(POSSIBLE_FACE_IN_BLOCKLIST、POSSIBLE_DUPLICATED_FACE)的相似度区间在系统内部是固定的;按应用进行阈值调优仅适用于工作流活体检测,而不适用于此 endpoint。您可以在每次请求中控制的配置项包括:
search_type(most_similar,默认值 |blocklisted_or_approved):most_similar按相似度对所有已入库的人脸进行排序;blocklisted_or_approved将候选范围限制为黑名单人脸、白名单人脸、来自已通过会话的人脸以及导入的用户画像人脸,并优先对黑名单条目排序。save_api_request(默认值为true):将调用持久化为 API 类型会话,并将搜索到的人脸录入您的人脸搜索索引库。通过人脸搜索调用录入的人脸会在未来的搜索结果中被排除。若仅需查询而不存储或录入,请将其设为false。rotate_image(默认值为false):尝试按 90 度旋转并保留人脸检测效果最佳的方向;在缺少 EXIF 方向信息时非常有用。
示例
黑名单命中(强制为 Declined)
重复信号(状态保持为 Approved)
相关内容
- 人脸搜索报告 — 完整响应结构
- 人脸搜索 API 参考 — 请求参数
- 人脸比对警告 — 1:1 自拍照与证件比对警告(独立于人脸搜索)
- 数据模型 — 人脸搜索 — 权威架构