Что такое машинное обучение
Классическая программа исполняет правила, написанные человеком. Модель машинного обучения получает исторические примеры и подбирает параметры так, чтобы минимизировать ошибку предсказания на этих примерах, — а затем применяет найденную зависимость к новым данным.
В e-commerce разница видна на простом примере. Правило «показывать аксессуары того же бренда» описывает одну гипотезу категорийного менеджера. Модель, обученная на миллионах сессий, обнаруживает, что для одной категории решающим фактором оказывается ценовой диапазон, для другой — сочетание бренда и размера, а для третьей — время до предыдущей покупки. Ни одна из этих зависимостей не была задана явно.
Это не означает, что правила не нужны. Промышленные системы почти всегда гибридны: модель отвечает за ранжирование в условиях неопределённости, правила — за бизнес-ограничения, которые модель знать не может (контракты с поставщиками, распродажа коллекции, юридические ограничения).
Типы обучения
| Тип | Что подаётся на вход | Задачи в e-commerce |
|---|---|---|
| С учителем | Примеры с известным правильным ответом | Прогноз оттока, скоринг вероятности отклика, ранжирование |
| Без учителя | Данные без разметки | Сегментация клиентов, поиск похожих товаров, выявление аномалий |
| С подкреплением | Обратная связь от среды на действия | Динамическое распределение трафика между вариантами, оптимизация выдачи |
Обучение с учителем — основной рабочий инструмент: почти любая бизнес-задача сводится к предсказанию числа или класса по набору признаков. Обучение без учителя используют, когда разметки нет в принципе, — например, при кластеризации клиентской базы на группы со схожим поведением. Обучение с подкреплением в ритейле чаще всего встречается в облегчённой форме многоруких бандитов: алгоритм постепенно перераспределяет трафик в пользу выигрывающего варианта.
Отдельная ветка — глубокое обучение на нейронных сетях. Оно даёт векторные представления объектов (эмбеддинги) и хорошо работает с последовательностями поведения и текстами, но требует больше данных и инфраструктуры. Для табличных задач градиентный бустинг остаётся практичным выбором по соотношению качества и стоимости.
Признаки решают больше, чем алгоритм
Качество модели определяется в первую очередь тем, какие признаки ей доступны. Feature engineering — превращение сырых событий в набор чисел, описывающих объект.
Сырое событие:
{user: u_18422, event: product_view, sku: 77301, ts: 2026-03-14T19:22:10}
Признаки пользователя, построенные из потока событий:
просмотров за 7 дней = 34
уникальных категорий за 30 дней = 6
средний чек последних 3 заказов = 4 820 ₽
дней с последней покупки = 41
доля просмотров в ценовом диапазоне 3–6к = 0.62
аффинити к бренду A = 0.31
Ошибка, которая обесценивает всю работу, — утечка целевой переменной: в признаки попадает информация, недоступная на момент предсказания. Например, признак «сумма заказов за месяц» при прогнозе покупки в этом же месяце даёт отличные метрики на валидации и нулевую пользу в продакшене. Правило простое: все признаки рассчитываются строго по данным до момента, для которого делается предсказание.
Жизненный цикл модели
1. Сбор данных → события сайта и приложения, каталог, заказы
2. Признаки → агрегаты по пользователю, товару, паре «пользователь × товар»
3. Обучение → подбор параметров на обучающей выборке
4. Валидация → проверка на отложенном по времени периоде
5. Оффлайн-оценка → сравнение с текущим решением по метрикам качества
6. A/B-тест → проверка на живом трафике против контроля
7. Инференс → применение в продакшене в бюджете латентности
8. Мониторинг → метрики качества, распределения признаков, дрейф
9. Обновление → регулярное обучение на свежих данных
Два узла, на которых чаще всего теряется результат:
Валидация. Случайное разбиение выборки в задачах с временной структурой завышает оценку: модель «подглядывает» в будущее. Корректная схема — обучение на периоде до даты X, проверка на периоде после. Переобучение обнаруживается именно здесь, а регуляризация и упрощение модели — стандартные средства борьбы с ним. Общая рамка баланса между недообучением и переобучением описывается компромиссом смещение–дисперсия.
Инференс. Модель, требующая 300 мс на ответ, непригодна для ранжирования листинга. Инференс в реальном времени укладывается в десятки миллисекунд, поэтому тяжёлые вычисления выносят в предрасчёт: эмбеддинги товаров и агрегаты пользователей считаются заранее, в онлайне остаётся быстрое скалярное произведение и сортировка. Часть задач вообще не требует онлайна — прогноз оттока считается батчем раз в сутки.
Модель деградирует без единого сбоя. Обновился ассортимент, изменилась структура трафика, поменялась разметка событий на сайте — и распределение признаков уезжает от того, на котором шло обучение. Мониторинг распределения входных признаков обязателен наравне с мониторингом метрик качества: он ловит проблему раньше, чем её увидит бизнес.
Задачи ML в e-commerce
| Задача | Тип обучения | Что на выходе | Как проверяется |
|---|---|---|---|
| Товарные рекомендации | С учителем + без учителя | Ранжированный список SKU | A/B-тест по выручке на посетителя |
| Ранжирование поиска и листингов | С учителем (learning to rank) | Порядок выдачи | A/B-тест по CR категории |
| Сегментация клиентов | Без учителя | Разбиение базы на группы | Интерпретируемость + отклик в кампаниях |
| Прогноз оттока | С учителем (классификация) | Вероятность оттока по клиенту | Качество на отложенном периоде + эффект удерживающих кампаний |
| Похожие товары | Без учителя (эмбеддинги) | Векторная близость SKU | Клики и добавления из блока |
| Аномалии спроса | Без учителя | Флаг отклонения | Ручная верификация категорийным менеджером |
| Распределение трафика в тестах | С подкреплением | Доли трафика по вариантам | Совокупная выручка эксперимента |
Отдельно стоит отметить границу применимости. Машинное обучение предсказывает то, что закодировано в исторических данных. Если событие не логируется, модель о нём не знает; если процесс изменился скачком (новый рынок, новая бизнес-модель), история о будущем говорит мало.
Чек-лист перед запуском ML-задачи
- Сформулировать предсказание в терминах бизнес-решения. «Предсказать вероятность оттока» бесполезно без ответа на вопрос, какое действие последует за высоким скором.
- Проверить, что целевое событие логируется и число примеров достаточно — считать примеры целевого класса, а не общий объём данных.
- Зафиксировать бейзлайн. Простое правило или популярность — обязательная точка отсчёта; модель без сравнения с бейзлайном не оценить.
- Валидировать по времени, а не случайным разбиением.
- Проверить признаки на утечку целевой переменной.
- Заложить бюджет латентности до выбора архитектуры, а не после.
- Предусмотреть фолбэк на случай недоступности модели — неперсональная выдача лучше пустого блока.
- Запланировать регулярное обучение на свежих данных и мониторинг дрейфа с первого дня в продакшене.
- Проверять эффект A/B-тестом. Улучшение оффлайн-метрики не является результатом до подтверждения на живом трафике.