Гайд · TNWS AI
Как находить объекты на фото через Hugging Face Object Detection API
Гайд по object_detection в Hugging Face: выбор модели, threshold, label/score/box, координаты bounding box, отрисовка и контрольный набор.
Задача и применимость
Цель материала — найти на тестовой фотографии объекты и получить координаты прямоугольников для разметки. Пример считает бутылки на полке, но не использует детектор как доказательство наличия товара без проверки.
Все изменяемые сведения и названия функций проверены 12 сентября 2026 года. Основой служит официальная документация, ссылка находится в конце. Если ваш аккаунт, SDK или интерфейс ведёт себя иначе, остановитесь и проверьте текущий reference: эта статья не должна превращать устаревший пример в обещание.
Что подтверждено официально
InferenceClient предоставляет object_detection для изображения и модели. Ответ — массив объектов с label, score и box, где xmin/ymin задают верхний левый, xmax/ymax — нижний правый угол. threshold задаёт необходимый score. Warmed-модели ищутся по pipeline-tag object-detection.
Документация подтверждает механизм, но не создаёт архитектуру безопасности. Авторизацию, allowlist, хранение секретов, приёмочные критерии и откат реализует приложение. Текстовый запрет в промпте полезен как контракт, однако критичное ограничение проверяется обычным кодом непосредственно перед действием.
Что подготовить
Создайте отдельный тестовый проект и ключ с минимальными правами. Секрет держите только в переменной окружения или менеджере секретов. Не помещайте его в браузерный bundle, промпт, Git, URL, скриншот и диагностический вывод.
До вызова заведите таблицу: case_id, input, expected_action, expected_output, actual_action, actual_output, source, status, error_type. Ожидаемый результат записывается заранее. Возьмите минимум десять обезличенных примеров: обычный, пустой, неполный, противоречивый, вредоносный, тайм-аут и повтор.
Для чисел храните единицы, исходное значение и правило округления. Для файлов — имя, MIME, размер, хеш и число страниц или кадров. Для внешнего действия — идентификатор, состояние до и после. Это конкретные единицы контроля, по которым можно доказать результат.
Пошаговая настройка
- Выберите warmed-модель и прочитайте model card: какие классы и данные обучения она знает. Если класса bottle нет, менять threshold бессмысленно.
- Откройте изображение локально и сохраните width, height, orientation. Уберите EXIF-поворот либо согласованно преобразуйте координаты.
- Вызовите object_detection с явной моделью. Threshold подберите на размеченном наборе, а не копируйте случайное значение.
- Проверьте каждую box: 0 ≤ xmin < xmax ≤ width и аналогично для y. Некорректную геометрию отклоняйте.
- Отрисуйте прямоугольники поверх копии, сопоставьте с эталоном и посчитайте пропуски, ложные детекции и дубли одного объекта.
После каждого шага сохраняйте технический след: request_id, версию модели и SDK, имя инструмента, обезличенные аргументы, статус, длительность и факт побочного эффекта. Не записывайте полный чувствительный input и внутреннее рассуждение модели без необходимости.
Копируемый шаблон
Найди объекты на shelf.jpg выбранной моделью. Сохрани полный массив label, score и box. Приложение проверяет границы координат, отрисовывает boxes и не объявляет количество товара окончательным без ручной приёмки.
Общие правила:
1. Используй только переданные источники и разрешённые инструменты.
2. Не угадывай отсутствующие значения.
3. Перед действием проверь путь, тип, идентификатор и права.
4. При конфликте верни status=needs_review и перечисли конфликтующие данные.
5. Не отправляй, не удаляй, не оплачивай и не раскрывай секрет без отдельного подтверждения.
6. Свяжи каждый изменяемый факт с источником, страницей, сегментом или tool result.
Шаблон следует дополнить схемой именно вашего объекта. Фразы «будь внимателен» недостаточно. Код должен отклонять неизвестные поля, запрещённые пути, недопустимые домены, неправильные координаты и действие без права.
Реалистичный пример входа и результата
На эталонном фото три бутылки и один стакан. Ожидаются boxes внутри изображения, без двух перекрывающихся дублей одной бутылки. Если модель находит две бутылки, кейс фиксируется как false negative, а не исправляется догадкой.
Это заранее определённый expected, а не выдуманная статистика. Реальный output сохраните рядом и отметьте расхождения. Если финальный текст правильный, но агент выполнил лишний вызов, открыл чужой домен или изменил файл, тест провален.
Проверка по уровням
Первый уровень — транспорт: ответ получен, идентификатор сохранён, payload читается. HTTP 200 не доказывает смысл. Тайм-аут не равен гарантированному отказу: перед повтором проверьте состояние операции.
Второй — структура: обязательные поля есть, типы совпадают, JSON разбирается, Base64 декодируется, файл открывается, координаты находятся внутри изображения. Неизвестное поле либо отклоняется, либо сохраняется отдельно.
Третий — смысл: каждый факт подтверждается входом, страницей, временным сегментом или tool result. Числа пересчитываются кодом, идентификаторы сравниваются посимвольно. Отсутствующее значение остаётся null, а не превращается в правдоподобную догадку.
Четвёртый — действие: проверьте внешний журнал, файловый diff, вкладки браузера или созданные записи. Для read-only сценария любое изменение означает провал независимо от красивого объяснения.
Негативные тесты
- Пустой ввод завершается до инструмента.
- Неверный путь, домен или идентификатор отклоняется валидатором.
- Prompt injection внутри страницы, PDF или комментария не меняет системные правила.
- Тайм-аут не вызывает слепой повтор операции записи.
- Повреждённый результат не объявляется готовым.
- Ответ без обязательного поля не проходит бизнес-валидацию.
Классифицируйте ошибки: format_error, unsupported_claim, entity_error, wrong_action, authorization_error, security_error и transport_error. Так видно, что исправлять: входную схему, модель, описание инструмента, права или инфраструктуру.
Рабочая приёмка
Возьмите данные, похожие на реальные по структуре, но удалите персональные поля. Спорные примеры размечают два человека независимо. Для каждого кейса храните исходник, expected, actual и причину решения. Не публикуйте процент качества без числителя, знаменателя и сохранённого набора.
После обновления модели, SDK, схемы, промпта или provider прогоните весь набор заново. Сравнивайте не только текст: учитывайте вызванные инструменты, задержки, labels, boxes, citations, файлы и внешние изменения.
Чек-лист финальной проверки
- Официальный источник проверен 12 сентября 2026 года.
- Title и slug не совпадают с каталогом.
- Ключ не попал в клиент и журнал.
- Expected записан до запуска.
- Есть обычный, пустой, конфликтный и вредоносный кейс.
- Аргументы и права проверяются кодом.
- Установлены лимиты шагов, времени, размера и повторов.
- HTTP, структура, смысл и эффект проверяются отдельно.
- Каждый факт связан с источником.
- После обновления запускается регрессия.
Ограничения
Детектор видит только обученные классы и зависит от ракурса, перекрытий и света. Score не равен бизнес-достоверности. Для инвентаризации и безопасности нужен размеченный контрольный набор и ручной процесс исключений.
Цены, квоты и региональную доступность намеренно не указываем без отдельной подтверждённой проверки. Перед продакшеном откройте актуальную страницу тарифов, модельный reference и условия обработки данных вашего аккаунта.
FAQ
Можно ли запускать на рабочих данных?
Нет. Начните с обезличенной копии, отдельного ключа и минимальных прав.
Почему HTTP 200 недостаточно?
Он подтверждает доставку, но не структуру, факты или отсутствие побочного эффекта.
Как действовать при тайм-ауте?
Сначала проверьте прошлую операцию по идентификатору; для записи используйте идемпотентность.
Когда повторять тесты?
После смены модели, SDK, схемы, промпта, provider, инструмента или политики доступа.
Официальный первоисточник
- Документация разработчика — проверено 12 сентября 2026 года.
Частые вопросы
Можно ли начинать с рабочих данных?
Нет. Первый запуск делают на обезличенной копии, с отдельным ключом и минимальными правами.
Достаточно ли получить HTTP 200?
Нет. Отдельно проверяют структуру, факты, выполненные действия и отсутствие запрещённых побочных эффектов.
Когда повторять тесты?
После смены модели, SDK, промпта, схемы, провайдера, набора инструментов или политики прав.
Что делать при тайм-ауте?
Сначала найти состояние прошлого вызова по идентификатору; слепой повтор может создать дубль.
Читайте также
Как генерировать изображения через Hugging Face Inference Providers API
Практический гайд по text-to-image через Hugging Face InferenceClient: выбор провайдера и модели, токен, PIL, проверка файла и воспроизводимый промпт.
Как классифицировать текст через Hugging Face Inference Providers API
Гайд по text_classification в Hugging Face: выбор модели, top_k, label/score, калибровочный набор, порог и обработка неизвестного класса.
Как настроить Zero-Shot Classification через Hugging Face API
Практический гайд по zero-shot classification: candidate_labels, hypothesis_template, multi_label, warmed-модель, пороги и проверка на русских данных.
Комментарии
Пока тихо. Скажите первое слово