Обзор
Поиск по лицу представляет собой биометрический поиск 1:N: Didit находит самое крупное лицо в вашемuser_image и ищет его по индексу поиска по лицам вашего приложения — лицам, зарегистрированным в сессиях верификации и сохранённых автономных вызовах API, а также лицам, загруженным напрямую в профиль пользователя, и вашим спискам блокировки и разрешений. Он отличается от Сравнения лиц, которое работает в формате 1:1 — Сравнение лиц сопоставляет селфи с фотографией на конкретном документе, тогда как Поиск по лицу отвечает на вопрос: «встречали ли мы этого человека где-либо ранее?».
Перед обработкой отчёта важно понять две особенности поведения:
- Отклоняются только совпадения со списком блокировки. Поле
face_search.statusпринимает значениеDeclinedтолько в том случае, если сработало предупреждениеFACE_IN_BLOCKLISTилиPOSSIBLE_FACE_IN_BLOCKLIST. Обнаружение исключительно дубликатов возвращаетApproved— анализируйтеmatchesиwarnings, а не толькоstatus. - Опциональное сохранение и регистрация. Если параметр
save_api_request=true(по умолчанию), вызов сохраняется как сессия типа API, а найденное лицо регистрируется в вашем индексе поиска по лицам. Лица, зарегистрированные через вызовы Поиска по лицу, исключаются из будущих результатов Поиска по лицу, благодаря чему повторные поисковые запросы никогда не находят друг друга. Передайтеsave_api_request=falseдля разового запроса: ничего не сохраняется и лицо не регистрируется в индексе поиска по лицам.
Где появляются результаты
Поиск по лицу представляет собой автономный API. Результаты поиска возвращаются синхронно, только в ответе наPOST /v3/face-search/, в виде единичного объекта face_search на верхнем уровне:
face_searches[] нигде нет — соглашение об использовании массивов во множественном числе, принятое для id_verifications[], aml_screenings[] и liveness_checks[] на endpoint решения по сессии, здесь не применяется.
Если параметр save_api_request=true (по умолчанию), вызов также сохраняется как сессия типа API:
- Business Console — сессия появляется в вашем списке сессий вместе с изображением, использованным для поиска, совпадениями и предупреждениями.
GET /v3/session/{sessionId}/decision/— данные можно получить, используя возвращённыйrequest_idв качестве идентификатора сессии. Сохранённые данные отображаются как элементFACE_SEARCHвfeatures[]и как элементliveness_checks[], содержащий сохранённыеmatches(с заново подписанными значениямиmatch_image_url) иwarnings— но не как объектface_search.
save_api_request=false, параметр request_id представляет собой временный UUID для корреляции: сессия никогда не сохраняется, поэтому её нельзя получить из Console или через endpoint решения.
Схема
Канонические таблицы полей приведены в разделе Поиск по лицу в справочнике моделей данных. Представленная ниже структура отражает то, что endpoint фактически возвращает во время выполнения.- Массив
matches[]содержит не более 5 записей выше порога схожести, отсортированных по убыванию схожести (search_type=blocklisted_or_approvedсначала ранжирует записи из списка блокировки, затем из списка разрешений, а затем по схожести). sourceуказывает, откуда было зарегистрировано совпавшее лицо:session— сессия верификации или сохранённый вызов автономного API;imported— лицо, загруженное напрямую в профиль пользователя;list_entry— лицо, привязанное к одному из ваших списков;retained_template— не содержащий изображения биометрический шаблон, сохранённый приложением после удаления исходной сессии. Поляsession_id,session_number,statusиapi_serviceимеют значениеnullдля совпадений типаimported,list_entryиretained_template.- Совпадения типа
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 возвращает HTTP
400 с {"error": "No face detected in the image"} до того, как будет создан объект face_search — статус Declined для этого случая отсутствует. При недостатке кредитов возвращается HTTP 403 до любой обработки изображения.
Примеры
Approved — совпадение дубликата, нет в списке блокировки
Declined — совпадение со списком блокировки
Связанные разделы
- Предупреждения функции «Поиск по лицу» — все коды предупреждений, которые может возвращать поиск
- Справочник API функции «Поиск по лицу» — параметры запроса и режимы
search_type - Модели данных — Поиск по лицу — каноническая схема
- Webhook — payload события
status.updatedдля сохранённых сессий
Когда
save_api_request=true, значения match_image_url представляют собой подписанные временные URL — повторно вызовите endpoint решения по сессии с возвращённым request_id, чтобы получить актуальные ссылки. Когда save_api_request=false, они являются внутренними путями хранилища и недоступны для прямого скачивания. Сохраняйте на своей стороне только идентификатор совпавшей сессии, статус и similarity_percentage — не сохраняйте исходное биометрическое изображение.