Привет, Хабр! Меня зовут Кристина Истратова и я руковожу центром аналитики данных в 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. Выкладку поправили, товар вернулся на полку и продажи пошли только после финальной проверки.
Архитектура системы: от чека до задачи
Как в любом магазине, во всех наших точках есть постоянное видеонаблюдение. Но оно не может полноценно решить эту задачу, так как текущих камер не достаточно для четкого охвата всех полок магазина, а дооснащение каждой полки камерами обойдется слишком дорого (с учетом количества магазинов в сети). В основе нашего решения лежит трехуровневая логика.
Как устроен процесс: взгляд сверху
Прежде чем погружаться в детали, давайте охватим взглядом всю цепочку целиком. Вот путь, который проходит каждый такой алерт:
[Онлайн-чеки из магазинов]
↓
[Ночной расчёт индивидуальных нормативов для каждого 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 магазинах сети с различным уровнем трафика, чтобы оценить его эффективность в условиях разной оборачиваемости.
ссылка на оригинал статьи https://habr.com/ru/articles/1053156/