Перейти к основному содержанию

Обзор

Поиск по лицу представляет собой биометрический поиск 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 — совпадение со списком блокировки

Связанные разделы

Когда save_api_request=true, значения match_image_url представляют собой подписанные временные URL — повторно вызовите endpoint решения по сессии с возвращённым request_id, чтобы получить актуальные ссылки. Когда save_api_request=false, они являются внутренними путями хранилища и недоступны для прямого скачивания. Сохраняйте на своей стороне только идентификатор совпавшей сессии, статус и similarity_percentage — не сохраняйте исходное биометрическое изображение.
Последнее изменение 7 ноября 2026 г.