概述
人脸搜索是一种 1:N 生物识别搜索:Didit 会提取您user_image 中检测到的最大人脸,并在您应用的人脸搜索索引中进行检索,包括从验证会话、已保存的独立 API 调用和直接上传至用户资料中录入的人脸,以及您的黑/白名单。它与 1:1 的人脸比对不同:人脸比对是将自拍照与特定证件上的头像进行比对,而人脸搜索则是探寻“我们之前是否在任何地方见过这个人?”。
在解析报告之前,有两项行为值得深入了解:
- 仅黑名单匹配会导致拒绝。 仅当触发
FACE_IN_BLOCKLIST或POSSIBLE_FACE_IN_BLOCKLIST警告时,face_search.status才会为Declined。仅存在重复匹配时仍会返回Approved,请检查matches和warnings,而不仅仅是status。 - 可选的持久化与录入。 当
save_api_request=true(默认值)时,该调用将作为 API 类型的会话持久化保存,且被搜索的人脸将被录入至您的人脸搜索索引中。通过人脸搜索调用录入的人脸将从未来的人脸搜索结果中排除,因此重复搜索绝不会相互匹配。如需进行一次性查询,可传入save_api_request=false:此时不会存储任何内容,也不会录入人脸。
结果显示位置
人脸搜索是一个独立的 API。搜索结果仅在POST /v3/face-search/ 响应中同步返回,作为顶层的单个 face_search 对象:
face_searches[] 数组:会话决策 endpoint 上用于 id_verifications[]、aml_screenings[] 和 liveness_checks[] 的复数数组约定在此不适用。
当 save_api_request=true(默认值)时,该调用还会作为 API 类型的会话持久化保存:
- Business Console:该会话将出现在您的会话列表中,并显示搜索图像、匹配项和警告。
GET /v3/session/{sessionId}/decision/:可以使用返回的request_id作为会话 ID 进行检索。持久化的数据将在features[]中显示为一个FACE_SEARCH条目,并在liveness_checks[]项中携带存储的matches(附带新签名的match_image_url值)和warnings,而不是作为face_search对象呈现。
save_api_request=false 时,request_id 是一个临时的关联 UUID:该会话永远不会被存储,因此无法从控制台或决策 endpoint 获取。
数据结构
有关规范的字段表格,请参阅数据模型参考中的人脸搜索。下方的结构反映了 endpoint 在运行时实际返回的内容。matches[]最多包含 5 个高于相似度底线的条目,按相似度降序排列(search_type=blocklisted_or_approved会优先排列黑名单条目,其次是白名单,最后按相似度排序)。source指示匹配的人脸是从何处录入的:session(验证会话或已保存的独立 API 调用);imported(直接上传至用户资料的人脸);list_entry(附加到您某个名单的人脸);retained_template(应用在删除源会话后保留的不含图像的生物特征模板)。对于imported、list_entry和retained_template匹配项,session_id、session_number、status和api_service均为null。retained_template匹配项包含vendor_user_id、vendor_data和biometric_template_id,而match_image_url、user_details以及所有与会话相关的内容始终为null:生成该人脸的会话已不复存在,且该模板不包含任何图像或身份数据。对于保留的模板,is_blocklisted始终为false;被列入黑名单的人脸会作为list_entry匹配项单独报告。可以使用DELETE /v3/biometric-templates/{biometric_template_id}/清理该模板。api_service是匹配会话的独立 API 类型(大写,例如PASSIVE_LIVENESS),当匹配的人脸来自常规工作流验证会话时为null。user_details来自匹配会话的证件验证。对于source: imported匹配项,它将改为从用户资料中提取填充(已设置full_name,document_type/document_number为 null);当不存在身份数据时(例如仅进行活体检测的会话),它为null。- 警告采用了简化结构(与工作流警告相比):其中没有
node_id。文档记录的响应约定(FaceSearchResponseSerializer)声明了五个字段:risk、additional_data、log_type、short_description、long_description;运行时的 payload 还会额外携带feature,在此处始终为"LIVENESS"。请参阅人脸搜索警告。 - 未排除同一用户的匹配:与工作流重复检测不同,该独立 endpoint 不会过滤具有相同
vendor_data的先前会话,因此合法老用户会与其自己早期的会话发生匹配。
状态值
顶层的face_search.status 源自 warnings[]。匹配项级别的 status 反映了匹配会话的验证结果,两者相互独立。
注意:当 API 未能在搜索图像中检测到人脸时,API 会在构建
face_search 对象之前返回 HTTP 400 及 {"error": "No face detected in the image"},这种情况下不存在 Declined 状态。额度不足时会在进行任何图像处理之前返回 HTTP 403。
示例
Approved - 重复匹配,无黑名单
Declined - 黑名单匹配
相关内容
- 人脸搜索警告 — 搜索可能发出的所有警告代码
- 人脸搜索 API 参考 — 请求参数与
search_type模式 - 数据模型 — 人脸搜索 — 规范模式
- Webhook — 持久化会话的
status.updatedpayload
当
save_api_request=true 时,match_image_url 的值为带签名的短期有效 URL — 使用返回的 request_id 重新请求会话决策 endpoint 即可获取最新 URL。当 save_api_request=false 时,它们是内部存储路径,无法直接下载。请仅在您方存储匹配的会话 ID、状态以及 similarity_percentage — 请勿保留底层的生物特征图像。