Как мы построили сервис компьютерного зрения на базе внешних VLM для контроля выкладки и ценников: опыт Fix Price. ml.. ml. osa.. ml. osa. vlm.. ml. osa. vlm. Блог компании Fix Price.. ml. osa. vlm. Блог компании Fix Price. изображения.. ml. osa. vlm. Блог компании Fix Price. изображения. ИИ.. ml. osa. vlm. Блог компании Fix Price. изображения. ИИ. искусственный интеллект.. ml. osa. vlm. Блог компании Fix Price. изображения. ИИ. искусственный интеллект. Машинное обучение.. ml. osa. vlm. Блог компании Fix Price. изображения. ИИ. искусственный интеллект. Машинное обучение. машинное+обучение.. ml. osa. vlm. Блог компании Fix Price. изображения. ИИ. искусственный интеллект. Машинное обучение. машинное+обучение. разработка.

Меня зовут Кристина Истратова и я руковожу центром аналитики данных в Fix Price. В нашей Сети более 8 000 магазинов, а в каждом из них — множество   товаров. Думаю, все из нас знают, как покупатели реагируют на отсутствие ценника или неверную цену на нем, какие чувства вызывает пустая полка, где нет товара, за которым приходишь в магазин.

Так что одна из наших важных ежедневных задач – это проверка выкладки товаров и правильности ценников, и выполнять нам ее надо максимально быстро и точно. На помощь нам пришел, конечно же, искусственный интеллект: мы начали использовать сервис для автоматического контроля наличия товаров на полках магазинов и актуальности ценников – OSA (on shelf availability).

Недавно мы опубликовали новость о старте проекта. https://habr.com/ru/companies/fix_price/news/1039484 В комментариях развернулась небольшая дискуссия, поэтому я решила сделать подробный разбор. Расскажу, как и зачем мы построили этот сервис, и как совместили в одной связке статистику, общедоступные VLM и собственные ML-разработки.

Кейс для понимания сути сервиса

Чтобы описать проблему, приведу реальный пример из работы сервиса.

Заведующий магазином вынужден в течение рабочего дня решать миллион задач, причем   одномоментно, это тяжело и нередко оборачивается ошибками. В таких ситуациях сервис информирует работника: в конкретной точке перестал продаваться «Напиток суб Rich Dor Irish Cream» и система отправила заведующему задачу «Проверьте выкладку».

По всей видимости, сотрудник в спешке, выхватил взглядом слово «Rich» и не заметил характеристику  «суб Dor Irish Cream»,   сфотографировал известный газированный напиток. Ошибку выявил AI, сравнив фото с эталонным наименованием, и выставил задачу повторно. Магазин вновь присылал фото газировки и ситуация повторилась. И только на третий раз, внимательно перепроверив, сотрудник понял, что нужно было сфотографировать растворимый кофе Rich. Выкладку поправили, товар вернулся на полку и продажи пошли только после финальной проверки.

Как мы построили сервис компьютерного зрения на базе внешних VLM для контроля выкладки и ценников: опыт Fix Price - 1

Архитектура системы: от чека до задачи

Как в любом магазине, во всех наших точках есть постоянное видеонаблюдение. Но оно   не может полноценно решить эту задачу, так как текущих камер не достаточно для четкого охвата всех полок магазина, а дооснащение каждой полки камерами обойдется слишком дорого (с учетом количества магазинов в сети). В основе нашего решения лежит трехуровневая логика.

Как устроен процесс: взгляд сверху

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

[Онлайн-чеки из магазинов]

[Ночной расчёт индивидуальных нормативов для каждого SKU на завтрашний день]

[Каждые 20 минут – детекция отклонений: статистический поиск «потерянных товаров»]

[Задача заведующему в приложение: проверить выкладку и сфотографировать за 10 минут нужную позицию]

[AI-верификация: LLM-модель проверяет фото на соответствие товара и ценника]

[Если сомнения — внутренний сервис сверяет фото с эталонной базой]

[OK – задача закрыта / Не ОК – повторная задача, до трёх циклов]

А теперь разберём каждый узел подробно.

Уровень 1: Определяем аномалии

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

Ночью для каждого SKU (Stock Keeping Unit), то есть уникальной товарной позиции в конкретном магазине, система на основе накопленной истории рассчитывает индивидуальные нормативы продаж на завтрашний день.

В течение дня каждые 20 минут проходит детекция «потерянных товаров» на текущий момент – SKU, продажи которых статистически значимо отклоняются от нормы. Условно, если ожидаемый норматив в текущем моменте времени каждые 50 чеков, а товар не продавался уже 250 чеков подряд, значит, необходимо разобраться в ситуации. В модель заложены плавающие коэффициенты: сезонность, день недели и другие факторы.

На этом этапе – чистая математика и алгоритмы, ИИ мы используем уже на следующем шаге.

Уровень 2: Первичная реакция

Выявив аномалию, система создаёт задачу в мобильном приложении, которым пользуются заведующие наших магазинов. В задаче указано наименование товара, у которого надо проверить выкладку и корректность ценника. Сотруднику магазина рекомендуется сделать это за 10 минут.

Он ищет товар и проверяет: выложен ли он, доступен ли покупателю, корректен ли его ценник. Затем делает фото проблемной позиции и выбирает классификатор закрытия задачи: «Выложили товар / поправили выкладку»«Скорректировали ценник»«Нет товара для выкладки» (брак, недостача, некорректный остаток) или «Действий не произведено». Важный нюанс, мы заложили в модель определённый порог точности и сознательно допускаем некоторый уровень ложных алертов. Лучше лишний раз перепроверить полку, чем пропустить реальное выпадение товара из продаж. Тем не менее мы добавили ограничение на количество задач в день и в один интервал детекции, чтобы не перегружать магазин алертами в случае нештатной работы и т. д.

Только после того, как человек отработал задачу, мы подключаем искусственный интеллект.

Уровень 3: AI-верификация

Фотография заведующего отправляется в наш сервис, и запускается проверка в два этапа.

Первый   этап – VLM-модель. Мы используем внешние, общедоступные большие мультимодальные модели. Передаём туда фото, правильное наименование товара и промпт с просьбой сверить: соответствует ли ценник ожидаемому наименованию, совпадает ли сам товар на фото со своим ценником. Возвращаясь к спору из комментариев: один из хабровчан заметил, что распознавание полок – «обычное машинное зрение». Для нашей задачи мы использовали другой подход – компьютерным зрением дольше и дороже делать подобного рода сервисы, с VLM проще.

Почему мы взяли внешние VLM-модели? Дело в том, что мы анализируем открытые данные: товары и ценники. Так что нам не пришлось тратиться на разработку сложной системы с нуля – мы постарались собрать решение из доступных, но мощных компонентов.

Второй   этап – собственный сервис поиска товара по изображению. AI справляется сама в случае с большинством товаров, опознаёт их быстро и безошибочно. Но полагаться только на внешний контур мы не стали. Что, если товар специфический, а упаковка настолько сложна, что даже мощной VLM трудно опознать содержимое? В нашем ассортименте много азиатских позиций: яркая упаковка с множеством деталей, иероглифы, где и человек не сразу понимает, что это за товар.

Тут нам помогает собственная разработка – сервис, о котором коллега из Fix Price недавно писал на Хабре. https://habr.com/ru/companies/fix_price/articles/1034664 Сервис   сравнивает полученную фотографию с базой эталонных изображений наших товаров и с высокой точностью ищет конкретный SKU. Получается двойная проверка: первичный   контроль от AI и сверка со «стандартом».

Если ИИ фиксирует несоответствие, мы регистрируем ошибку, при этом сразу выставляем повторную задачу с уточнением: «Обнаружена повторная проблема, перепроверьте ещё раз». Цикл может повторяться до трёх раз. Это и страховка от ошибок самого ИИ, и отличный дисциплинирующий фактор: как в примере с кофе, сервис помогает нашим сотрудникам относится к деталям более внимательно.

Бизнес-эффект: растут ли продажи?

Результаты внедрения пилота в первых 500 магазинов мы оцениваем очень позитивно. В точках, где сотрудники активно и корректно отрабатывали задачи, оборот вырос. Максимальное значение – +2%.

Методология подсчета использовалась следующая: если после закрытия задачи товар продался в течение двойного нормативного окна, оборот по чекам внутри этого двойного норматива мы засчитывали в эффект алерта. Например, позиция, в момент выставления задачи магазину, должна была продаваться каждые 200 чеков. Мы выставили задачу, потому что продаж не было уже много циклов. Если после отработки задачи товар продался в течение следующих 400 чеков, значит, проблема действительно была, а наше вмешательство её решило. Мы считаем сколько помогли нам заработать такие продажи и на этой основе строим статистику прироста оборота.

Однако есть ещё один системный эффект, менее заметный снаружи, но важный для нас – корректировка «зависших» остатков и их влияние на автозаказ.

Представим, что сервис выявил «потерянный товар», заведующий не нашёл его ни на полке, ни в подсобке и закрыл задачу с классификатором «Нет товара для выкладки: брак/недостача». По учётной системе на остатках висят пять SKU этого товара, по факту их нет.

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

Что дальше?

Мы планируем развивать этот проект. Следующая наша цель – масштабировать сервис на всю сеть, то есть более чем на 8 000 магазинов.  

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

Вместо FAQ: разбор полётов вопросов хабровчан

Я постаралась   ответить на большинство вопросов сообщества прямо в тексте и резюмировать главные точки спора.

«Почему нельзя просто посчитать остатки?» – Этот вопрос звучал в разных вариациях. Ответ: теория учёта разбивается о реальность физического магазина. Остаток на полке нельзя расчитывать как «Приход минус Расход». Товар с ненулевым остатком может находиться где угодно: в подсобке, в зоне приёмки, быть повреждённым или украденным. Перед глазами покупателя его нет – нет и продаж. Наш сервис подсвечивает именно этот разрыв, и делает это не в конце дня, а почти в реальном времени.

Вместо создания громоздкой внутренней системы «с нуля», мы собрали гибкое и эффективное решение из доступных компонентов: потоков данных, своих алгоритмов, внешних VLM и нашего сервиса поиска товара по изображению. В таком подходе, на мой взгляд, наше преимущество – низкий порог входа и быстрая окупаемость за счёт использования готовых AI-технологий.

Концепция On-Shelf Availability не нова и «потерянные товары» выявляли по данным и раньше. Но мы сделали следующую новацию: объединили традиционную статистику с двойной AI-верификацией фотографий, скомбинировав внешние VLM и собственное компьютерное зрение.

В рамках пилота сервис OSA был внедрен в 500 магазинах сети с различным уровнем трафика, чтобы оценить его эффективность в условиях разной оборачиваемости.

Автор: christ1na

Источник