Я — тот человек, которого зовут, когда красивый Jupyter Notebook дата-саентиста нужно "впихнуть" в самописный PHP-движок интернет-магазина 2015 года. Я интегратор. Моя работа — соединять несоединимое: высокие технологии и грязные данные, быстрые тензоры и медленные SQL-запросы.

За последние три года через мои руки прошло более сотни проектов по внедрению рекомендательных систем (RecSys) в e-commerce: от магазинов крафтового мыла до федеральных сетей запчастей.

Знаете, сколько из них реально взлетели и приносят деньги? Около 15%.

Остальные 85% — это кладбище потраченных бюджетов и разочарований. И дело почти никогда не бывает в качестве самой модели. Нейросети умные. Бизнес-процессы — нет.

Ниже — сухая статистика моих "вскрытий" и ответ на вопрос, почему кнопка "Сделать мне Amazon" не работает.

анатомия провала: статистика причин

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

Проблема данных (45%): «У нас есть база за 5 лет» на деле оказывается свалкой разношерстных Excel-таблиц без единых ID.
Техническая несовместимость (25%): Легаси-код сайта не может отправить запрос к API модели и получить ответ быстрее, чем пользователь уйдет со страницы.
Ошибка целеполагания (20%): Бизнес оптимизирует CTR (клики), а теряет в марже (рекомендуем дешевые товары вместо маржинальных).
Экономика инференса (10%): Стоимость работы сервера с GPU превышает прибыль, которую приносит "умная лента".

Давайте разберем самые болезненные точки, о которых не пишут в рекламных буклетах.

ложь №1: «у нас отличные данные»

Это классика. Клиент утверждает, что у него идеальная CRM. Я прошу выгрузку каталога и истории заказов.

Приходит файл.

В одной строке цвет товара указан как "Красный", в другой — "Red", в третьей — "Алый (распродажа)". Для человека это одно и то же. Для модели — это три разных вектора. Она не понимает, что пользователь, купивший "Красные носки", может захотеть "Алую шапку". Для нее это товары с разных планет.

Еще хуже — история действий.

Чтобы рекомендательная система (особенно коллаборативная фильтрация) работала, нам нужны не только покупки, но и просмотры, добавления в корзину и лайки.

У 80% малого и среднего бизнеса эти логи либо не пишутся вообще, либо хранятся 30 дней.

Вердикт: Пытаться обучить трансформер на 50 заказах в день — это как учить ребенка высшей математике, когда он еще не умеет говорить. Тут работают только простые эвристики или готовые предобученные модели, которые знают контекст товаров (item-to-item), а не поведение юзера.

ложь №2: «мы хотим персонализацию как у netflix»

Netflix тратит миллионы долларов на то, чтобы "холодный старт" (когда о пользователе ничего не известно) проходил незаметно.

Клиент с посещаемостью 2000 человек в сутки хочет того же.

Но вот суровая математика: если у вас мало трафика, матрица взаимодействий "пользователь-товар" будет разреженной на 99.9%. Модель будет выдавать бред или предлагать всем одни и те же "хиты продаж".

В одном проекте для магазина зоотоваров мы три месяца тюнили сложный алгоритм. В итоге A/B тест показал, что он проигрывает тупому правилу: "Тем, кто купил корм для кошек, предлагай наполнитель для туалета".

Инсайт: Не внедряйте сложные кастомные модели, пока не уперлись в потолок простых правил. Или берите готовые решения с платформы вроде Qubu, которые уже обучены на похожих доменах и требуют только донастройки (fine-tuning).

проблема «тяжелого» инференса

Допустим, данные мы почистили. Модель обучили. Она лежит в контейнере и ждет запроса.

Пользователь заходит в карточку товара. Сайт отправляет запрос к модели: "Что рекомендовать к этому дивану?".

Запрос летит на сервер с GPU.
Модель (какой-нибудь тяжелый BERT) переваривает контекст.
Ответ летит обратно.
Сайт рендерит блок "Вам может понравиться".

В идеальном мире это занимает 50 мс. В мире дешевого хостинга и кривой архитектуры — 1.5–2 секунды.

Знаете, что делает пользователь за 2 секунды? Он скроллит страницу вниз или уходит. Блок с рекомендациями появляется где-то вверху, когда его уже никто не видит.

Мы называем это "призрачный инференс". Вы платите за вычисления, сервер греется, а бизнес-польза равна нулю.

Решение здесь одно: либо предварительный расчет (pre-calc) рекомендаций ночью (но тогда мы теряем реакцию на действия «здесь и сейчас»), либо использование оптимизированных, легких моделей через быстрый API.

как перестать сжигать деньги

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

Вместо того чтобы строить свой "CERN" с коллайдером внутри CMS Bitrix, используйте подход микросервисной интеграции.

Не обучайте с нуля, если вы не гигант.
Используйте раздел "Модели" на маркетплейсах. Возьмите готовую модель для векторизации описаний товаров (NLP). Она сразу поймет, что "красный" и "алый" — это рядом, без обучения на ваших дырявых данных.
Начните с Item-to-Item.
Не пытайтесь угадать душу пользователя. Начните с качественного подбора "похожих товаров". Это проще, дешевле в интеграции и дает 80% профита.
Чистите данные на входе.
Наймите интегратора не для того, чтобы он написал нейросеть (это сейчас делает школьник), а для того, чтобы он написал скрипт нормализации вашей базы данных. Это лучшая инвестиция.
Считайте экономику запроса.
Если 1000 рекомендаций приносят вам 1 дополнительную продажу с прибылью 500 рублей, а аренда GPU стоит 600 рублей — выключайте рубильник. Ищите легковесные модели или SaaS-решения с оплатой за результат.

ИИ в ритейле — это не магия. Это просто еще один модуль в вашей ERP, который должен быть рентабельным. Перестаньте гнаться за хайпом и начните считать задержки (latency) и чистоту данных. Тогда и внедрение пройдет успешно.

Почему ваш бизнес (не) готов к ИИ: Анализ 100 провальных попыток внедрения рекомендательных систем

Похожие статьи

Поделиться в соц. сетях

Комментарии