Обзор
Поиск по лицу формирует небольшой набор предупреждений, позволяя вашей команде понять, почему поиск вернулApproved или Declined. Предупреждения возвращаются в массиве face_search.warnings[] ответа POST /v3/face-search/ (см. Отчёт Поиска по лицу).
Предупреждения здесь имеют сокращённую структуру по сравнению с предупреждениями сценариев: в них отсутствует 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 отклоняет запрос с кодом HTTP 400 и {"error": "No face detected in the image"} до создания объекта face_search — поэтому предупреждение 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)
Связанные материалы
- Отчёт Face Search — полная структура ответа
- Справочник API Face Search — параметры запроса
- Предупреждения Face Match — предупреждения при сравнении 1:1 селфи с документом (отдельно от Face Search)
- Модели данных — Face Search — каноническая схема