API для оценки возраста и пола по изображениям профиля: запрос, чтение, хранение

Руководство для разработчиков по отправке изображений профиля для анализа и обработке данных о возрасте, поле и других внешних признаках в качестве алгоритмических оценок.

API для оценки возраста и пола получает изображение и возвращает алгоритмические предположения о человеке, который на нем изображен. AvatarLookup предлагает эту функцию в рамках услуги «Анализ профиля по изображению»: разработчики загружают файл в формате JPEG, PNG, WebP или GIF в виде multipart-формы на соответствующий конечный пункт API и получают синхронный ответ, содержащий тип изображения, а также (если на снимке есть человек) предполагаемый пол, возраст, цвет волос и цвет кожи. Ответ описывает изображение, а не учетную запись или человека, стоящего за ней. Рассматривайте каждый атрибут как оценку, помогающую при проверке контактных данных, помечайте его соответствующим образом при хранении и не используйте в процессах принятия решений, влияющих на доступ, ценообразование или право на получение услуг.

Что возвращает API для оценки возраста и пола и о чем умалчивают большинство руководств

Большинство страниц, ранжируемых по этой теме, являются списками поставщиков. Они показывают пример ответа с рамкой вокруг лица, числом возраста и показателем пола, обещая высокую точность. Они редко объясняют три вещи, с которыми разработчики сталкиваются в первую неделю: что происходит, если изображение не является портретом, насколько велика может быть погрешность оценки возраста и как хранить результаты, чтобы никто впоследствии не принял их за свершившийся факт.

«Анализ профиля по изображению» в AvatarLookup отвечает на вопрос об изображении. Первый результат — это тип изображения: фотография человека или что-то другое, например логотип, иллюстрация, объект или животное. Если на снимке присутствует человек, анализ дополняется оценками внешности. Результат содержит производный от контента «отпечаток» изображения, а не идентификатор учетной записи, поэтому в ответе нет ничего, что связывало бы изображение с номером телефона, адресом электронной почты или конкретным человеком.

Такой подход подходит для команд, работающих с контактными данными. В CRM или системе поддержки уже хранятся аватары, предоставленные клиентами или партнерами, и полезный вопрос здесь обычно звучит как «что это за изображение?», а не «кто это?».

Отправка изображения профиля: документированная multipart-загрузка

Документированный маршрут API — это единый синхронный вызов. Здесь нет задач для создания и циклов опроса.

1. Выберите файл, который у вас уже есть. Типичные входные данные — это аватары, экспортированные из CRM, изображения, прикрепленные к тикетам поддержки, или изображения из каталогов партнеров.
2. Сначала выполните локальную проверку. Принимайте только файлы JPEG, PNG, WebP или GIF и отклоняйте файлы, превышающие установленный лимит размера, до того, как они покинут вашу систему. Локальные проверки экономят время на передачу данных и упрощают чтение ваших собственных журналов.
3. Загрузите данные как multipart-форму на конечный пункт для анализа профиля, указанный в документации API, используя свои учетные данные. Следуйте приведенному там описанию запроса, а не копируйте параметры из сторонних статей.
4. Сохраните ответ рядом с вашим ключом записи вместе с датой анализа и источником изображения.

Используйте только multipart-загрузку. Полезные нагрузки Base64 и URL-адреса изображений не являются частью документированного контракта API, поэтому код, зависящий от них, может перестать работать. Инструмент на веб-сайте принимает публичный URL-адрес изображения, что удобно, когда аналитик хочет протестировать несколько снимков до того, как инженеры напишут код.

Для анимированных GIF-файлов самостоятельно решите, какой кадр представляет аватар, и преобразуйте его в статичное изображение, если ваш процесс проверки требует предсказуемых входных данных. Этот выбор относится к вашему конвейеру обработки, а не к API.

Чтение ответа: сначала тип изображения, затем атрибуты

Читайте каждый результат по уровням и сопоставляйте каждый исход с последующим шагом до запуска интеграции.

Биллинг следует тому же разделению. Завершенный результат подлежит оплате, включая изображение без человека или изображение с неизвестными атрибутами, поскольку анализ предоставил ответ. Ошибка службы, нечитаемое изображение или ответ без полей оплате не подлежат. Регистрация категории результата для каждого вызова позволяет финансовым и инженерным отделам сверять использование данных по одному и тому же журналу.

Результат «не человек» часто является наиболее полезным на практике. Логотип в записи личного контакта или мультяшный аватар в профиле поставщика — это четкий сигнал для ответственного за данные проверить запись.

Насколько точны оценки возраста и как их хранить

Независимое тестирование показывает, почему оценки нуждаются в маркировке. Национальный институт стандартов и технологий США проводит постоянную оценку технологий анализа лиц для определения возраста и сообщает о средней абсолютной ошибке в разных демографических группах и условиях съемки. Опубликованные результаты показывают большой разброс между алгоритмами и чувствительность к таким факторам, как качество изображения, возраст субъекта и условия освещения. Аватары добавляют свои проблемы: фильтры, сильное сжатие, старые фотографии и обрезанные групповые снимки.

Модель хранения, которая сохраняет честность данных:

• Называйте поля как оценки, например estimated_age_band и estimated_gender, никогда не используйте age или gender.
• Предпочитайте диапазоны вместо отдельных чисел в инструментах нижнего уровня, чтобы проверяющий видел диапазон, а не ложную точность.
• Сохраняйте происхождение: дату анализа, источник изображения и «отпечаток», возвращенный с результатом.
• Проводите повторный анализ при смене изображения, вместо того чтобы переносить старые оценки на новый аватар.
• Отделяйте оценки от данных, предоставленных клиентом, чтобы заявленная дата рождения никогда не перезаписывалась результатом работы модели.

Где API для оценки возраста и пола уместен, а где нет

Хорошо подходит для задач с низким уровнем риска, которые можно отменить: сортировка большого архива аватаров, пометка изображений, не являющихся портретами, в личных контактах, выборка странных записей для проверки человеком или обнаружение изображений-заглушек, которые так и не были заменены. В каждом случае окончательное решение принимает человек, а неверная оценка стоит лишь момента проверки.

Плохо подходит для решений, которые меняют возможности или расходы человека. Одобрение, отклонение, ранжирование или ценообразование на основе предполагаемого возраста или пола, проверка кандидатов, отслеживание лиц и создание профилей людей, которые этого не ожидали, — все это выходит за рамки ответственного использования. Оценки внешности не являются демографическими фактами, и то, как модель «прочитала» лицо, ничего не говорит о том, как человек себя идентифицирует.

Юридический контекст также имеет значение. Руководство по биометрическим данным британского регулятора объясняет, когда обработка изображений людей переходит в категорию биометрических и специальных данных; аналогичные правила существуют и в других юрисдикциях. Команды должны задокументировать свою цель, срок хранения и процесс проверки перед включением анализа изображений для реальных контактных данных.

Часто задаваемые вопросы

Как команды могут протестировать точность на своих изображениях перед интеграцией?

Соберите небольшую выборку, на которую получено согласие и которая похожа на реальные данные: размеры аватаров, сжатие, фильтры и смесь портретов и не-портретов. Пропустите ее через инструмент на веб-сайте или тестовый скрипт, а затем попросите двух проверяющих сравнить результаты с тем, что они видят. Измерьте, как часто тип изображения полезен и как часто возрастные диапазоны явно неверны, и на основе этих данных установите свои правила проверки.

Может ли API анализировать изображение по URL вместо загрузки?

Документированный маршрут API принимает multipart-загрузку файла. Публичный URL-адрес изображения поддерживается в инструменте на веб-сайте, что удобно для ручной проверки нескольких снимков. Для автоматизированных конвейеров загрузите изображение в свою систему, проверьте тип и размер, а затем загрузите файл. Это также даст вам стабильную копию того, что именно было проанализировано, что поможет, если кто-то позже поставит оценку под сомнение.

Как команды должны обрабатывать неизвестные атрибуты в ответе?

Рассматривайте «неизвестно» как нормальный, завершенный ответ. Сохраняйте атрибуты, которые были оценены, оставляйте неизвестные поля пустыми и не заполняйте их значениями по умолчанию или догадками из других полей. Панели мониторинга должны учитывать «неизвестно» отдельно от ошибок, поскольку для них требуются разные последующие действия: неизвестные значения обычно отражают само изображение, в то время как ошибки указывают на проблему с файлом или службой.

Узнать больше

Выберите информацию о продукте, которая соответствует следующему шагу в вашем рабочем процессе.

• Посетить веб-сайт продукта →