Як побудували AI-асистента для найбільшого маркетплейсу України Rozetka: гіпотези, AB-тести і факапи

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

У березні цього року Rozetka офіційно запустила власного АІ-асистента, який допомагає нашим клієнтам обрати товар з понад 20 млн найменувань на сайті за лічені хвилини. Ним вже користуються десятки тисяч людей щодня, і кожний четвертий користувач, який хоча б раз звернувся до нього, користується ним знову і знову.

За кулісами цього успіху — величезна робота, пророблена нашою ІТ-командою. В цій історії розробники, які безпосередньо працювали над проєктом, діляться тим, як product-driven підхід, AB-тести і чесне ставлення до факапів допомогли побудувати AI-асистента в одному з найбільших маркетплейсів Східної Європи. І він подобається клієнтам.

1. Навіщо маркетплейсу АІ-асистент, а не чат-бот

Уявіть типовий шлях покупця на маркетплейсі. Людина шукає ноутбук для роботи з дизайном. Перед нею — тисячі варіантів, десятки характеристик, сотні відгуків. Вона відкриває 15 вкладок, порівнює процесори, читає коментарі, гуглить «який екран краще для Figma» і закриває все, бо втомилась обирати. І так по колу.

Раніше проблему вибору оптимального варіанту вирішував консультант у фізичному магазині. Він знав асортимент, розумів потреби і міг за кілька хвилин запропонувати на вибір 2-3 варіанти. Але клієнти все більше купують онлайн, а консультанти — та ще проблема, їх не можна масштабувати на всіх людей одночасно. AI — можна.

Ми з самого початку розуміли: черговий FAQ-бот, який цитує опис товару — це не рішення. Таких вже повно, і користь від них мінімальна. Нам потрібен був не чат-бот, а система, яка вміє думати, шукати, порівнювати і діяти.

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

Ми сформулювали це так: «Асистент — це інтерфейс. Платформа — це мозок». AI не вигадує нічого сам. Він оркеструє існуючі сервіси — пошук, рекомендації, товарні дані, кошик — і подає результат в зручній формі.

Контекст ринку підтверджує, що це уже необхідність, AI стає дефолтним способом шопінгу. Питання вже не в тому «чи потрібен маркетплейсу AI», а «хто буде володіти відносинами з клієнтом, коли AI стане нормою». Будуєш свій — або стаєш постачальником чужого.

2. Від прототипу до production за 7 місяців

Validate before you build

Перший прототип ми зібрали на n8n — no-code платформі для автоматизацій. Це був свідомий вибір: перед тим як вкладати місяці в розробку, ми хотіли перевірити базову гіпотезу — чи будуть люди взагалі питати AI про пральні машини, телевізори і котячий корм?

Відповідь прийшла швидко: так, будуть. Причому питання виявились набагато складнішими, ніж ми очікували. Не «скільки коштує iPhone», а «порівняй ці два монітори для роботи з кольором, враховуючи, що я сиджу далеко від екрану».

Коли no-code стає блокером

За два місяці ми вперлись у стелю. n8n не давав потрібної гнучкості: складна логіка tool calls, кастомна валідація відповідей, нормальна робота з контекстом — все це потребувало повноцінного бекенду. Команда мігрувала на кастомний Go-сервіс.

Таймлайн

• Серпень 2025 — міграція на Go, перший production-ready бекенд
• Вересень 2025 — перший ролаут на 20% реальних юзерів
• Листопад 2025 — перший серйозний факап (про нього далі), Black Friday стрес-тест
• Січень 2026 — запуск на iOS, нова модель
• Березень 2026 — 100% ролаут на Web, iOS і Android

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

3. Архітектура: АІ-асистент як оркестратор

LLM не робить нічого сам

Це, мабуть, найважливіше архітектурне рішення, яке ми прийняли на старті. LLM — це не база даних, не пошуковий движок і не рекомендаційна система. Він не знає, що є в наявності, які зараз ціни і що купував юзер минулого місяця.

Натомість LLM виступає оркестратором: він аналізує запит користувача, вирішує, який інструмент викликати, інтерпретує результат і формує відповідь. Tool-based архітектура, де агент має доступ до набору інтеграцій:

• Пошук і ранкінг — знаходить товари за складними критеріями
• Товарні дані — характеристики, відгуки, Q&A
• Рекомендації — аналоги, схожі товари (Data Science моделі)
• Кошик — додати товар, перевірити стан
• Персоналізація — часті покупки, історія переглядів

Асистент вирішує, коли і яку інтеграцію викликати. Іноді достатньо просто відповісти з контексту. Іноді потрібно зробити пошук, потім підтягнути відгуки, потім порівняти — і все це в рамках однієї відповіді.

Чому ми не довіряємо LLM генерувати дані

Одна з перших проблем, з якою ми зіткнулись: LLM галюцинує ID товарів. На ранніх етапах асистент міг впевнено написати «Ось ноутбуки, які я підібрав під ваші потреби» — і показати шкарпетки, роутер і настільну лампу. Просто вигадав ID товарів, і за цими ID виявились рандомні речі.

Ми побудували систему верифікації: кожен товар у відповіді перевіряється — чи дійсно його ID прийшов з результатів tool calls (пошуку, рекомендацій, тощо). Якщо агент «вигадав» ID, якого не було в даних від інтеграцій — відповідь відхиляється і модель отримує інструкцію подумати ще раз з тими даними, які в неї реально є.

Асистент працює тільки з verified data. Все, що він показує юзеру — має джерело в реальних сервісах платформи.

Prompt як продукт

Окрема історія — еволюція промпту. Для нас промпт — це не «текст, який один раз написали і забули». Це продукт, який має версії, метрики і before/after для кожної зміни.

Кожна нова версія промпту — це окремий реліз з конкретною гіпотезою. «Якщо ми спростимо алгоритм вибору товарів, юзер швидше отримає релевантний результат» → деплоїмо → вимірюємо конверсію, час відповіді, якість взаємодії → приймаємо рішення.

Один з найцікавіших проривів: ми перестали покладатись на tool calls для базового контексту. Замість того щоб асистент щоразу «питав» сервіси про останні покупки або перегляди користувача, ми почали додавати цей контекст прямо в промпт через серверні шаблони. Принцип: передати контекст, який користувачу може не знадобитись — все одно дешевше, ніж робити tool call за контекстом, який точно знадобиться. Це зменшило час затримки і вартість кожної взаємодії.

Безпека

Окремий виклик — prompt injection. Це проблема всієї індустрії, а не конкретного продукту. Повного захисту не існує ні у кого — ні у Google, ні у OpenAI, ні у нас.

Наш підхід — багатошарова оборона. Кожен рівень ускладнює атаку. Ціль — не «зробити неможливим», а «зробити настільки важким, що не варто намагатись». Деталі механізмів не розкриваємо з очевидних причин.

4. Продуктові інсайти: що ми зрозуміли про юзерів

Цей розділ — про речі, які ми не очікували виявити. Кожен інсайт змінив наш підхід до продукту.

6% кнопок = 17.5% запитів

Ми проаналізували всі запити до агента і виявили закономірність: 6 попередньо визначених кнопок — «Опис товару», «Відгуки», «Аналоги», «Порівняти», «Аксесуари», «Додати у вішліст» — генерують 17.5% усіх запитів.

Люди не хочуть друкувати. Вони хочуть натиснути кнопку і отримати відповідь. Замість того щоб покращувати обробку вільного тексту, ми побудували нативні quick questions — кнопки з найпопулярнішими запитами прямо на картці товару. Результат перевершив очікування.

UX важливіший за якість тексту

Ми витрачали багато часу на те, щоб відповіді асистента були досконалими — детальними, структурованими, з порівняльними таблицями. А потім подивились на дані і зрозуміли: юзерам потрібен не красивий текст, а швидкий шлях до рішення.

Картка товару з кнопкою «Додати в кошик» конвертує краще, ніж три абзаци пояснень чому цей товар підходить. Ми перебудували підхід: менше прози, більше дієвих елементів.

AI працює не для всього

Асистент показує відмінні результати для технічних товарів — ноутбуки, монітори, кабелі, UPS, складна електроніка. Там, де юзер реально потребує консультації і має багато технічних питань.

Для побутових товарів — котячий корм, базова побутова хімія — AI майже не використовується. Люди і так знають, що хочуть. Ми перестали намагатись бути корисними там, де це не потрібно, і сфокусувались на категоріях з найвищим попитом на консультацію.

Ринок тільки формується

Більшість українських юзерів ще не звикли до AI-інтерфейсів. Примусити їх «поговорити з ботом» неможливо — і не потрібно. Замість цього ми вбудовуємо AI в природний шлях користувача. Людина на картці товару бачить релевантну підказку чи швидке питання — і навіть не задумується, що за цим стоїть LLM. Так ми поступово навчаємо ринок взаємодіяти з AI, не ламаючи звичний UX.

«Aha moment» на третій день

Аналіз когорт показав чіткий патерн: після трьох активних днів використання асистента drop-off різко падає. Юзер, який повернувся тричі — з високою ймовірністю стане постійним користувачем. Це визначило нашу стратегію онбордингу: найважливіше — довести юзера до третьої взаємодії.

5. AB-тести: не «ми тестували», а «ось що обрали і чому»

Кожна фіча починається з гіпотези, немає гіпотези — немає фічі. Формат такий: «Якщо ми зробимо X, то метрика Y зміниться на Z, тому що причина». Без цього задача навіть не потрапляє в беклог.

Формат відповіді: не кожен новий акронім — прорив

TOON (Token-Oriented Object Notation) — новий формат для відповідей LLM, який обіцяв 30-60% економії токенів порівняно з JSON. Для нас, де кожен токен — це гроші, звучало як must-have.

Ми імплементували його, налаштували промпт і провели AB-тест на 60,000 повідомлень.

Результат: TOON програв по кожній метриці. JSON виявився на 2.5% дешевшим по токенах. Швидкість відповіді — ідентична. А надійність JSON — вдвічі вища (вдвічі менше ретраїв).

Нуль обіцяної економії. Нуль.

До того ж TOON вимагає додаткових інструкцій в промпті — модель не знає цей формат нативно. Тобто ти витрачаєш більше токенів, щоб пояснити моделі як відповідати у форматі, який мав ці токени економити.

Для нас це означало витрачений час розробників, QA-цикли і цілий раунд AB-тесту — на формат, який програв по всіх показниках в production.

Висновок: JSON існує 20+ років. Він нудний. Він працює. Не довіряйте бенчмаркам з блог-постів — тестуйте на своїх даних.

Temperature: менше хаосу, менше витрат

Тестували temperature моделі — параметр, який визначає «креативність» відповідей. Нижча temperature (0.3 замість дефолтної) дає коротші, стабільніші, передбачуваніші відповіді.

Конверсія не постраждала, а витрати знизились. Простий вибір: менше хаосу за менші гроші.

Принцип

Кожен AB-тест — це не просто «що працює краще». Це трейдоф, де потрібно обрати між конкуруючими метриками: швидкість vs конверсія, вартість vs якість, простота vs гнучкість. Ми завжди обираємо на користь бізнес-результату, навіть якщо це означає вищі витрати або складнішу архітектуру.

6. Факапи та уроки

«Ноутбуки під ваші потреби»: шкарпетки і роутер

Один з наших улюблених ранніх факапів. Під час інтерв’ю з реальним користувачем людина попросила підібрати ноутбук. Асистент впевнено відповів: «Ось ноутбуки, які я підібрав під ваші потреби» — і показав шкарпетки, роутер і настільну лампу.

Проблема: LLM вигадував ID товарів. Іноді неіснуючі (помилка), іноді рандомні (попадав у випадкові товари). І подавав це з абсолютною впевненістю.

Рішення описане в розділі про архітектуру: верифікація кожного ID через перевірку чи він реально прийшов з tool calls. Галюцинації — це не баг LLM, це його властивість. Єдиний надійний підхід — не довіряти, а верифікувати на рівні інфраструктури.

Web search: коли AI працює проти тебе

Коли асистент отримав доступ до пошуку в інтернеті, ми швидко зрозуміли: без чітких обмежень нова capability створює більше проблем, ніж вирішує. Асистент міг знайти і радісно повідомити юзеру інформацію, яка прямо суперечить інтересам платформи.

Реакція була миттєвою: web search обмежили виключно товарними та продуктовими запитами — характеристики, типи, технології. Ніяких бізнес-тем, ніяких порівнянь.

Урок: кожна нова capability агента — це нова поверхня для проблем. Спочатку правила і обмеження, потім доступ. Не навпаки.

Від «бот для всіх» до Sniper Approach

Це не стільки факап, скільки болючий урок, на який пішло кілька місяців.

На початку ми робили те, що роблять усі: пхали AI-асистента всім підряд. Попапи на кожній сторінці, спливаючі підказки через 20 секунд, кнопка бота на видному місці. Логіка здавалась очевидною: чим більше людей побачить — тим більше скористаються.

Реальність виявилась іншою. Більшість «відкриттів» бота були випадковими тапами по попапу — особливо на мобільній версії. Люди закривали чат одразу після появи. Частина юзерів відверто дратувалась: «уберісь», «зникни» — таких повідомлень було більше, ніж хотілось би визнавати. Ми витрачали токени на аудиторію, якій AI не потрібен, і при цьому псували досвід для тих, кому він міг би допомогти.

А метрики виглядали чудово — сотні тисяч «відкриттів» на місяць. Vanity metrics у чистому вигляді.

Ми прийняли рішення, яке назвали «Sniper Approach»: показувати бота лише там, де він доречний контекстуально, і лише тим, хто виявив інтерес.

Що це означало на практиці:

• Прибрали всі стартові попапи. Тиша за замовчуванням.
• Замість нав’язливих спливашок — контекстні точки входу: швидкі питання на картці товару, блок характеристик, пошукові підказки.
• Фокус на авторизованих користувачах — найцінніший сегмент.

Результат на дашборді виглядав як катастрофа: відкриття бота впали на десятки відсотків. Але message rate — відсоток тих, хто відкрив і дійсно написав — виріс на 165%. Якість кожної взаємодії стала принципово вищою. Ми перестали рахувати міскліки і почали рахувати свідомі дії.

Урок: не всі користувачі — ваша аудиторія. Є люди, яких AI реально дратує, і це нормально. Замість того, щоб сувати асистента всім і сподіватись на конверсію, краще вбудувати його в customer journey так, щоб він з’являвся саме тоді, коли потрібен. Менше охоплення, але кожна взаємодія — свідома і якісна.

Вимірюй те, що важливо, а не те що легко порахувати. Vanity metrics — відкриття, покази, кліки — можуть місяцями маскувати реальну картину.

7. Результати

Подаємо чесно — що виміряли, що працює.

Два сценарії — дуже різна конверсія

У асистента є два принципово різні шляхи: допомогти знайти товар або допомогти завершити покупку. І конверсія між ними відрізняється кардинально.

Шлях 1 — пошук товару. Юзер описує потребу («потрібен ноутбук для дизайну до 40 тисяч»), асистент шукає, фільтрує, порівнює. Результат — перехід на картку товару. Це класична консультація, де асистент замінює годину гортання каталогу.

Шлях 2 — допомога на картці товару. Юзер вже дивиться конкретний товар і питає асистента: «а він потягне Figma?», «чим відрізняється від попередньої моделі?», «які є аналоги дешевше?». Тут конверсія з написаного повідомлення в покупку — приблизно 16%. Кожен 7-й юзер, який написав агенту на картці товару — купує.

Залученість і retention

Більше половини тих, хто відкриває асистента, пишуть повідомлення. 98% переглядають запропоновані товари, більше третини переходять на картку товару. Для AI-інтерфейсу, до якого ринок ще не звик — це сильний сигнал.

30-денний retention — 24.4%, що значно вище типового для e-commerce (10-15%). 7-денний retention виріс в 2.3 рази за 7 тижнів — з 5.8% до 13.4%. Юзери, які використовують асистента, повертаються частіше і купують з вищим середнім чеком.

Unit economics

Ми свідомо обрали якість: краща модель, більше контексту, складніша логіка. Це дорожче і іноді повільніше. Але дешевший асистент конвертує гірше — а юзер, який отримав погану відповідь, не повернеться. Якість окупається через retention і конверсію.

Пікові показники

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

8. Що далі

AI-асистент — це не кінцевий продукт, це платформа, яка буде рости.

Найближчі напрямки: глибша інтеграція AI в кожен елемент інтернет-магазину — не як окремий чат, а як вбудований помічник на картках товарів, у пошуковій видачі, в каталозі. Персоналізація на основі повної історії покупок і поведінки. Інтеграція з call-центром — AI як перша лінія з плавним переходом на оператора. Нові формати монетизації через AI-взаємодію.

Але головне — це не технології. Головне — це зміна очікувань. Юзери звикають до того, що маркетплейс їх розуміє. Що можна просто описати потребу — і отримати релевантну відповідь. Повернутись до звичайного каталогу з фільтрами після цього складно.

Гонка не за найкращий AI. Гонка за те, хто буде володіти відносинами з клієнтом, коли AI стане нормою.