跳转到主要内容

概述

人脸搜索是一种 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 - 黑名单匹配

相关内容

当 save_api_request=true 时,match_image_url 的值为带签名的短期有效 URL — 使用返回的 request_id 重新请求会话决策 endpoint 即可获取最新 URL。当 save_api_request=false 时,它们是内部存储路径,无法直接下载。请仅在您方存储匹配的会话 ID、状态以及 similarity_percentage — 请勿保留底层的生物特征图像。
最后修改于 2026年11月7日