EN UA RU
Головна Блог Architecture
Architecture

ШІ-персоналізація в e-commerce: як це виглядає в реальній інженерії

A
Flexor Engineering
20 серпня 2025
9 хв читання

Ми будували системи персоналізації з нуля і вбудовували їх у вже живі стеки. Чесна версія виглядає набагато брудніше, ніж будь-яке демо: cold start, компроміси по затримці, навчальні дані, що не збігаються з реальним контекстом видачі. Проблеми реальні й нетривіальні. Ось що ми з цього винесли.

Clicks Search Purchase FEATURE STORE Redis · Feast RANKING MODEL Two-Tower · BPR SERVING API <50ms p99 batch · 15min lag retrained hourly cached · real-time Cold start: new users and new items have no signal — requires separate fallback strategy PERSONALIZATION PIPELINE · SIMPLIFIED

Спрощений пайплайн персоналізації. На кожному переході — від збору подій до feature store, від моделі до serving API — своя затримка і свіжість. Розрив між «дані зібрані» і «рекомендація видана» зазвичай більший, ніж очікує команда.

Cold start — це не крайній випадок

Ми постійно бачимо, як команди ставляться до cold start як до виноски. Даремно. На більшості e-commerce магазинів від 40 до 60% сесій належать користувачам, яких система ніколи не бачила. Додайте запуски нових товарів і оновлення каталогу — і ви регулярно видаєте рекомендації по позиціях взагалі без історії покупок. У моделі не «мало даних» — у неї активно вводяча в оману відсутність сигналу.

Стратегія fallback важливіша, ніж прийнято вважати. Повернути глобальні бестселери — це підлога, не відповідь. Ми отримували кращі результати, додаючи афінітет до категорії з поточної сесії, джерело переходу і — де вдається отримати швидко — ранню поведінку в перших кількох переглядах. Це не ефектна інженерія, але вона рухає цифри.

Інференс на кожен запит не працює

Віджет рекомендацій, що додає 400 мс до завантаження сторінки, з'їсть більше конверсії, ніж персоналізація поверне. Шар видачі має бути швидким — ми цілимося в менше 50 мс на p99. Це майже завжди означає передобчислені рекомендації з кешу, а не live-інференс.

Отже, ваші рекомендації настільки свіжі, наскільки свіжий останній батч-прогін. Для більшості кейсів — каруселі на головній, сортування категорійних сторінок, email-кампанії — лаг 15 хвилин або навіть година цілком прийнятний. Все ламається з real-time сигналами: людина щойно кинула кошик або щойно купила й ви хочете одразу запропонувати апселл. Ось тут потрібен гібридний підхід — і саме там живе більша частина складності реалізації.

Колаборативна фільтрація проти embedding-моделей

Колаборативна фільтрація («користувачі, які купили X, також купили Y») — правильна відправна точка для магазинів із щільними даними про покупки. Добре вивчена, нескладна в реалізації, реально працює. Розвалюється на розріджених каталогах, товарах з одиничними покупками і всьому сезонному.

Embedding-моделі — Two-Tower і BERT4Rec — це архітектури, які ми використовуємо найчастіше — краще справляються з розрідженими даними, бо кодують атрибути товарів, а не спираються лише на історію спільних покупок. Нові товари отримують нормальні рекомендації з першого дня. Зворотній бік: дорожче навчати, складніше налагоджувати, потребують більше інфраструктури. Універсальної відповіді, що обрати, немає. Залежить від розміру каталогу, обсягу сесій і, чесно кажучи, ML-досвіду команди.

Звідки реально береться приріст

Найбільший внесок дають сортування головної та категорійних сторінок — коли товари, які користувач скоріше купить, опиняються вгорі списку. На другому місці тригерні листи: покинутий кошик, post-purchase, browse abandonment. Віджети «Схожі товари» на сторінках товарів — найпомітніша функція персоналізації і зазвичай перше, що будує команда, — але за нашим досвідом прямий ефект на конверсію у них скромний. Діскавері реальний, але його складніше атрибутувати.

Якщо будуєте вперше — не намагайтеся зробити все одразу. Спочатку нормально інструментуйте сесії. Будуйте поведінкові когорти. Викочуйте рекомендації на основі популярності і вимірюйте їх. Додавайте колаборативну фільтрацію, коли пайплайн устаканиться. Кожна команда, яку ми бачили, що намагалася одразу стрибнути на ML-шар, у підсумку поверталася і переробляла data plumbing.

Режими відмови, які ми бачимо найчастіше

Патерн, що повторюється: система персоналізації нормально працює на staging і показує нульові результати в продакшні. У дев'яти випадках із десяти навчальні дані не збігаються з контекстом видачі. Модель навчалася на авторизованих сесіях, а трафік переважно анонімний. Або пайплайн ознак лагає настільки, що «персоналізовані» рекомендації на момент видачі вже протухли — по суті випадкові.

Другий за частотою: немає holdout-групи. Не можна зрозуміти, чи допомагає персоналізація, якщо ніколи не запускали її проти контролю. Ми аудіювали магазини, де віджет рекомендацій працював більше року без A/B-фреймворку — і ніхто не міг сказати, чи приносить він хоч щось. Налаштуйте вимірювання до того, як починати оптимізувати.

Share Post on X LinkedIn
Назад до блогу

Наступний крок

Працюєте над складною commerce-системою?

Ми допомагаємо інженерним командам проєктувати, будувати та масштабувати високонавантажені платформи — з чітким процесом та передбачуваними строками.

Поговорімо