ШІ для персоналізації пропозицій та рекомендацій продуктів

Клієнт заходить на сайт магазину B2B, переглядає електрообладнання та йде без покупки. Наступного дня отримує електронний лист з саме тим продуктом, який переглядав, доповнений двома аксесуарами, які інші покупці додавали до того ж замовлення. Конверсія становить 18%. Без цього листа було б 3%. Ця різниця не з інтуїції менеджера, а з моделі рекомендацій, побудованої на даних сесій та історії замовлень.

Персоналізація ШІ не є виключною доменою великих e-commerce платформ. Компанії з кількома сотнями клієнтів B2B, сервісні портали та спеціалізовані магазини вже впроваджують системи, які три роки тому вимагали окремого відділу data science. Нижче описано, як це працює з точки зору архітектури, де пастки та скільки реально коштує.

Терміни часто використовуються як взаємозамінні, але описують різні механізми.

Рушій рекомендацій відповідає на питання: «Що ще може зацікавити цього клієнта?». Вхідні дані — історія взаємодій (кліки, покупки, час на сторінці) та характеристики продуктів. Вихід — рейтинг продуктів або контенту, відсортований за спаданням передбачуваної релевантності для конкретної особи або сегмента.

Персоналізація пропозиції відповідає на питання: «Як адаптувати повідомлення, діапазон цін або послідовність кроків до профілю клієнта?». Вхідні дані — сегмент клієнта (галузь, розмір компанії, етап воронки покупки), історія контактів та контекст сесії. Вихід — змінений макет сторінки, пріоритизація розділів, текст електронного листа або пропозиція цінності, адаптована до ролі особи.

Обидві системи можуть працювати разом: агент RAG з доступом до каталогу продуктів персоналізує зміст розмови та одночасно використовує рушій рекомендацій, щоб запропонувати конкретні продукти. Такий дует описано в розділі про архітектуру.

Існує спектр рішень, що відрізняються вартістю, можливостями та складністю обслуговування.

Для більшості польських компаній B2B, що стартують у 2026 році, оптимальною точкою входу є ембедінги з семантичним пошуком, доповнені простим collaborative filtering на історії покупок. Агент ШІ зі складною пам'яттю підходить тоді, коли процес вимагає пояснення рекомендацій клієнту або налаштування продукту в реальному часі.

Кожен рушій рекомендацій настільки хороший, наскільки хороші дані, на яких він базується. Водночас поведінкові дані — це область, де РODO та AI Act мають конкретні вимоги.

Явні дані (explicit feedback) — це оцінки, кліки «подобається», списки бажань. Клієнт свідомо висловлює перевагу. Правова основа — договір або обґрунтований інтерес, залежно від контексту.

Неявні дані (implicit feedback) — це час на сторінці, глибина прокрутки, покинуті кошики. Тут потрібен дозвіл на маркетинг або чітко обґрунтований інтерес, задокументований у реєстрі обробки даних. Збір неявних даних без правової основи — це не лише ризик РODO, а й матеріал для аудиту AI Act, якщо система приймає рішення, що впливають на ціну або доступ до пропозиції.

Транзакційні дані (історія замовлень) мають найсильнішу правову основу (виконання договору) та є найціннішими для collaborative filtering. Пам'ятайте про анонімізацію або псевдонімізацію, перш ніж дані потраплять до шару моделі, особливо якщо модель працює в хмарі.

PII masking перед відправкою до LLM є обов'язковим. Ім'я, адреса електронної пошти, NIP клієнта не повинні потрапляти до промпту, що генерує рекомендації. Моделі потрібен лише ідентифікатор сесії, характеристики сегмента та історія взаємодій. Деталі про маскування описано в статті анонімізація PII перед ШІ.

Холодний старт — це ситуація, коли новий клієнт, новий продукт або нова компанія починає користуватися системою без жодної історії. Collaborative filtering тут не підходить. Три підходи працюють на практиці:

Фолбек на популярність сегмента. Новий клієнт з будівельної галузі отримує рекомендації на основі того, що купували інші клієнти з будівельної галузі подібного розміру компанії. Це не індивідуальна персоналізація, але точніше, ніж список загальних бестселерів.

Онбординг із запитаннями. Кілька запитань на вході (галузь, розмір компанії, що плануєте вирішити) формують стартовий профіль без історії. Система розглядає відповіді як явні дані про переваги та одразу звужує простір рекомендацій.

Content-based filtering на ембедінгах. Якщо клієнт запитує конкретний продукт або вводить фразу, система шукає продукти з подібним семантичним значенням. Історія не потрібна, оскільки базується на подібності описів. Цей підхід працює з першої сесії та природно інтегрується з семантичним пошуком у каталозі.

Рушій рекомендацій може навчитися дискримінувати, якщо історичні дані відображають нерівне ставлення до клієнтів. Це не теоретичний сценарій.

Якщо історичні дані показують, що клієнти з певних регіонів рідше отримували преміальні пропозиції (бо так працювали менеджери), модель навчиться цього патерну та закріпить його. AI Act класифікує системи, що оцінюють або диференціюють доступ до продуктів і послуг, як потенційно високого ризику, особливо якщо вони використовують classifier на демографічних ознаках.

Guardrails для рушіїв рекомендацій включають чотири шари:

1. Denylist захищених ознак. Модель не може використовувати стать, вік, національність, релігію чи подібні атрибути як сигнали ранжування. Список закодований у конфігурації, не залежить від розсуду моделі.
2. Аудит рівності виходів. Щомісяця перевіряйте, чи різні демографічні сегменти отримують порівнянну якість рекомендацій та доступ до подібних пропозицій.
3. Пояснюваність на вимогу. Клієнт або інспектор може запитати: «Чому мені рекомендовано цей продукт?». Система повинна відповісти зрозумілими підставами, а не лише вектором подібності.
4. Human-gate для цін. Якщо персоналізація впливає на ціну (наприклад, діапазон пропозиції, адаптований до сегмента), кожна зміна цінника в рушії повинна проходити через затвердження людини з комерційною роллю.

AI Act (повністю застосовний з 2025 року) категоризує системи рекомендацій та персоналізації залежно від контексту. Більшість систем e-commerce та B2B не є автоматично системами високого ризику. Винятки:

• Персоналізація у фінансовій сфері (кредитний скоринг, доступ до фінансових продуктів) — Додаток III AI Act, високий ризик.
• Рекомендації з рекрутингу або оцінка працівників — Додаток III, високий ризик.
• Системи, що впливають на поведінку великих груп користувачів з механізмом залежності (соціальні мережі, відеоплатформи) — підпадають під ст. 5 заборони маніпулятивних практик.

Для стандартного e-commerce B2B та сервісних порталів рекомендації не належать до категорії високого ризику, але вимагають: розкриття, що рекомендації автоматичні (AI Act ст. 50 прозорість), документації процесу (DPIA, якщо дані чутливі), та права відмовитися від профілювання (РODO ст. 22 для повністю автоматизованих рішень).

Детальні обов'язки компаній на 2026 рік описано в статті AI Act та РODO 2026.

Персоналізація без вимірювання — це дорогий експеримент без висновків. Три метрики, які варто відстежувати з першого дня промислової експлуатації:

Click-through rate (CTR) рекомендацій — скільки відсотків показаних рекомендацій призводять до кліку. Точка відліку — CTR до персоналізації або CTR контрольної групи (A/B тест). Зростання CTR на 20-40% після впровадження ембедінгів є типовим для першого етапу.

Uplift доходів на сесію — різниця у вартості кошика між сесіями з активною персоналізацією та сесіями без неї (або з контрольною групою). Це число для керівництва. При правильному A/B тесті з контрольною групою uplift 8-15% на сесію є реальною метою через 6-8 тижнів.

Coverage — відсоток продуктів у каталозі, які з'являються в рекомендаціях хоча б для одного користувача протягом місяця. Низький coverage (менше 30%) сигналізує про popularity bias: модель рекомендує ті самі бестселери всім, ігноруючи довгий хвіст каталогу.

Моніторинг рушія рекомендацій має подібну структуру до моніторингу агента ШІ, описаного в статті про моніторинг KPI агента ШІ — чотири шари, golden set та алерти на дрейф.

Опишіть свій каталог продуктів або послуг та поточний спосіб сегментації клієнтів, а модель вкаже, з якої архітектури варто почати та які дані є ключовими (playground: PII масковані, нульове збереження):

Так, але точка входу має бути пропорційною до масштабу. Для компанії з кількома сотнями клієнтів та стабільним каталогом часто достатньо семантичного пошуку на ембедінгах та простої логіки «клієнти з вашої галузі купували також...». Повний collaborative filtering з рейтинговою моделлю має сенс від кількох тисяч клієнтів або сотень тисяч транзакцій. Оцініть свій стартовий стан калькулятором ROI, перш ніж виділяти бюджет на шар ШІ.

Залежить від якості вихідних даних та обраної архітектури. Пілот на основі ембедінгів та семантичного пошуку на існуючому каталозі: зазвичай 3-5 тижнів від аудиту даних до першої промислової версії. Повна система з collaborative filtering, A/B тестом та guardrails: 8-14 тижнів. Терміни найчастіше зсуваються через якість вихідних даних (відсутні описи продуктів, неузгоджені категорії), а не через моделі. Покроковий план дій описано в статті план впровадження ШІ.

Найцінніші — це історія транзакцій (що куплено, коли, в якій комбінації) та поведінкові дані за згодою (кліки, час на сторінці, пошуки). Можна почати лише з історії замовлень та характеристик продуктів, без будь-яких поведінкових даних. Collaborative filtering на транзакційних даних дає напрочуд хороші результати при відносно бідному наборі вхідних даних. Перш ніж щось відправляти до моделі, сплануйте маскування PII згідно з рекомендаціями анонімізації.

Popularity bias — найпоширеніша проблема перших впроваджень. Три корекції: (1) ліміт на частоту бестселера в рекомендаціях за сесію (наприклад, максимум 1 з топ-10 популярності у наборі з 5 рекомендацій); (2) diversity penalty у функції ранжування, що просуває продукти з різних категорій; (3) exploration quota, що резервує одне місце у наборі для продукту, який клієнт ніколи не переглядав, але який семантично подібний. Coverage як місячна метрика автоматично виявить, чи працюють ці механізми.

Частково. Агент LLM з доступом до каталогу через RAG добре справляється з поясненням рекомендацій та налаштуванням продуктів у реальному часі під час розмови. Гірше справляється з обробкою сотень тисяч поведінкових сигналів, необхідних для collaborative filtering. Оптимальна архітектура поєднує обидва: класична рейтингова модель генерує кандидатів, агент LLM обирає з них та формулює зрозуміле для клієнта обґрунтування. Стаття агент ШІ vs чатбот описує межу можливостей обох підходів.