Покупатель увидел понравившуюся вещь у знакомого, сфотографировал — и хочет найти такую же или похожую в вашем магазине. Или у закупщика на руках деталь без маркировки, и он не знает, как она называется. Описать словами трудно, а сфотографировать — легко. Визуальный поиск превращает эту фотографию в короткий путь к товару и к заказу.
Эта статья — о том, как внедрить распознавание товара по фото в интернет-магазине на 1С-Битрикс: как это устроено, стоит ли писать свою модель, как подготовить каталог и изображения, где разместить кнопку и что показывать, когда точного совпадения нет. И сразу главный трезвый тезис: визуальный поиск начинается не с ИИ, а с порядка в фотоконтенте. Навести этот порядок помогает аудит и оптимизация 1С и данных каталога.
Коротко
- Визуальный поиск сопоставляет фото покупателя с изображениями каталога и выдаёт похожие товары.
- Свою модель писать почти не нужно — подключается внешний сервис по API.
- Точность держится на качестве и единообразии фото товаров, а не на «магии ИИ».
- Результат — это список похожих с сортировкой по близости, а не одно точное совпадение.
Зачем поиск по фото
Текстовый поиск требует слов, а слов у покупателя часто нет. Он не знает, как называется фасон, модель детали или узор ткани. Зато у него есть картинка — своя фотография или скриншот. Визуальный поиск снимает барьер «не знаю, как это назвать» и ведёт человека к товару напрямую от изображения.
Для бизнеса это новый вход в каталог. Часть посетителей, которые ушли бы, не сумев сформулировать запрос, находят товар по фото и оформляют заказ. Особенно это работает там, где визуальный признак важнее названия: одежда, мебель, декор, а в B2B — запчасти и комплектующие, которые проще снять, чем описать.
Как это работает: от фото к товару
Механика визуального поиска проста на уровне идеи. Сервис компьютерного зрения переводит каждое изображение в набор числовых признаков — «вектор». Фото покупателя тоже превращается в вектор, а затем система ищет в каталоге товары, чьи векторы ближе всего к нему. Результат — список похожих, отсортированный по близости.
Отсюда два важных следствия. Первое: результат почти никогда не бывает «ровно этот товар» — это выдача похожих с оценкой близости. Второе: качество зависит от того, насколько хорошо векторизованы изображения каталога, то есть от самих фотографий. Алгоритм не «додумает» товар, которого нет в базе, и не спасёт от разнородных снимков.
Своя модель или внешний сервис
Соблазн «обучить свою нейросеть» почти всегда стоит отложить. Своя модель требует большого размеченного датасета, инфраструктуры и постоянного дообучения. Для подавляющего большинства магазинов практичнее внешний сервис визуального поиска, который вызывается по API.
| Критерий | Внешний сервис по API | Своя модель |
|---|---|---|
| Старт | Быстро, после подготовки фото | Долго, нужен датасет |
| Стоимость | Оплата за использование | Высокие вложения в разработку |
| Точность | Готовая, обучена на больших данных | Зависит от вашего датасета |
| Поддержка | На стороне вендора | Ваша команда |
| Когда оправдана | Почти всегда на старте | Очень крупный специфичный каталог |
Роль сайта на 1С-Битрикс в обоих случаях одна: хранить каталог и изображения, отдавать их сервису и красиво показывать результаты. Тяжёлое распознавание живёт снаружи.
Изображения и свойства в инфоблоках
Каталог в 1С-Битрикс хранит изображения в инфоблоках: основное фото — детальная картинка товара, дополнительные ракурсы — в свойстве типа «файл». Для визуального поиска сервису обычно передают URL этих изображений или их идентификаторы, чтобы он построил векторы и сопоставлял с ними запросы.
- Основное фото — главный источник для распознавания, должно быть чистым и репрезентативным.
- Дополнительные ракурсы — повышают шанс совпадения при разных углах съёмки.
- Актуальность. При смене фото товара его вектор в сервисе нужно обновить, иначе поиск ведёт на старую картинку.
- Полнота. Товары без фото в визуальном поиске просто не участвуют — это прямая потеря.
Заведение и обновление фотоконтента — часть контент-процесса каталога, который логично автоматизировать вместе с обменом. Систематизацию карточек и данных мы закрываем услугой автоматизации на 1С.
Качество фото решает всё
Главный секрет удачного визуального поиска не в выборе сервиса, а в фотографиях. Сервис сравнивает загруженное фото с вашими изображениями, и если ваши снимки разнородны — разный фон, ракурс, обрезка, освещение — совпадения будут неточными. Единый стандарт фото поднимает точность сильнее, чем смена вендора.
Требования к фотографиям — отдельная большая тема: единый фон, ракурсы, размеры, соотношение сторон. Мы разбираем её подробно в статье про единые требования к фото товаров для всей витрины. Именно эта дисциплина — фундамент под любой визуальный поиск.
Интеграция сервиса распознавания
Технически подключение сервиса — типовая API-интеграция. Сначала каталог индексируется: сервис получает изображения товаров и строит по ним векторы. Затем на каждый запрос покупателя сайт отправляет загруженное фото, а сервис возвращает список идентификаторов похожих товаров с оценкой близости, которые сайт показывает как выдачу.
Ключевые вопросы те же, что для любой интеграции: аутентификация, тайм-ауты, поведение при сбое сервиса и синхронизация каталога (новые и изменённые товары нужно переиндексировать). Если сервис недоступен, кнопка визуального поиска должна корректно предлагать обычный поиск, а не «зависать». Практики безопасной работы с внешними API мы описывали в статье про безопасность REST и вебхуков в 1С-Битрикс.
UX: где кнопка поиска по фото
Визуальный поиск бесполезен, если его не видно. Кнопку размещают там, где покупатель ищет:
- Иконка камеры в строке поиска. Самое привычное место — рядом с обычным поиском.
- Понятное действие. «Найти по фото» с подсказкой, что можно снять или загрузить изображение.
- Прогресс загрузки. Распознавание занимает время — покажите индикатор, а не «замерший» экран.
- Результат как каталог. Похожие товары выводятся привычной сеткой с ценой и кнопкой заказа.
Чем ближе визуальный поиск к обычному, тем естественнее им пользуются. Отдельная спрятанная страница «поиск по фото» почти всегда простаивает.
Когда точного совпадения нет
Поскольку визуальный поиск возвращает похожее, а не идентичное, обработка «неточных» результатов — важная часть UX. Показывайте выдачу как «похожие товары», а не обещайте «нашли ровно это». Если близких результатов нет вовсе, честно об этом скажите и предложите альтернативу.
- Заголовок честный. «Похожие товары», а не «Найдено точно».
- Сортировка по близости. Самые похожие — первыми.
- Запасной путь. «Не то? Попробуйте обычный поиск или фильтр» — вместо пустого экрана.
- Уточнение. Возможность отфильтровать выдачу по категории или цене.
Мобильный сценарий и камера
Главный сценарий визуального поиска — мобильный: человек фотографирует вещь прямо в момент интереса. Поэтому на телефоне подключают доступ к камере и загрузку из галереи, а весь процесс делают быстрым и нетребовательным к сети. Загрузка изображения и распознавание должны быть асинхронными и не блокировать интерфейс.
Как и с любой «тяжёлой» функцией, важно не уронить скорость каталога. Само распознавание идёт на стороне сервиса, а на клиенте — только загрузка фото и вывод результатов. Основная скорость витрины держится на кэше и правильной инфраструктуре BitrixVM, а визуальный поиск подключается поверх, не мешая композитному кэшу карточек.
Частые ошибки
- Подключают ИИ к разнородным фото. Совпадения неточные, покупатель не верит результатам.
- Пытаются обучить свою модель без нужды. Дорого и долго там, где хватило бы внешнего API.
- Товары без фото. Они не участвуют в поиске — прямая потеря выдачи.
- Не обновляют векторы. После смены фото поиск ведёт на старую картинку.
- Обещают точное совпадение. Выдача «похожих» подаётся как «нашли ровно это» — разочарование.
- Кнопка спрятана. Отдельная страница вместо иконки в поиске — функция простаивает.
- Нет запасного пути. При отсутствии похожих — пустой экран вместо предложения обычного поиска.
Чек-лист внедрения
- Фото приведены к стандарту. Единый фон, ракурсы и кадрирование по всей витрине.
- Каталог полон. У товаров есть качественные изображения, участвующие в поиске.
- Сервис подключён. Каталог проиндексирован, векторы построены, интеграция устойчива к сбоям.
- Синхронизация настроена. Новые и изменённые фото переиндексируются автоматически.
- UX выверен. Иконка камеры в поиске, прогресс загрузки, выдача как каталог.
- Обработка «нет совпадений». Честный заголовок и запасной путь на обычный поиск.
- Мобильный сценарий. Камера и галерея, асинхронная загрузка, никакого блокирования.
- Пилот измерен. Точность и конверсия проверены на реальных запросах до масштабирования.
Вывод
Распознавание товара по фото — сильный способ завести в каталог тех, у кого есть картинка, но нет слов. Технически это доступно почти любому магазину на 1С-Битрикс через внешний сервис по API, без собственной нейросети. Но качество визуального поиска определяет не выбор вендора, а порядок в фотоконтенте: единые, чистые, полные изображения каталога.
Поэтому начните с аудита и стандартизации фото, затем подключите сервис на пилотной категории и оцените точность на реальных запросах. Честно показывайте похожие товары, дайте запасной путь на обычный поиск — и визуальный поиск станет удобным дополнительным входом в каталог, а не эффектной, но бесполезной кнопкой.
