Розробка AI-чат-бота для e-commerce: RAG і семантичний пошук

AI-чат-бот для інтернет-магазину: де ламається пошук

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

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

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

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

Розширити словник синонімів і дописати ключові слова в описи товарів допомагає лише частково — поки формулювання повторюються. Пошук за описами товарів, зав'язаний на точні слова, не витягує одруки, інший порядок слів, змішування мов і побутові назви категорій.

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

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

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

Що дає семантичний пошук і діалоговий асистент

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

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

Завдяки цьому зникає цілий клас відмов «нічого не знайдено»: підбір товару за вільним описом працює й там, де покупець не знає точної моделі.

Індекси тримаємо поруч із каталогом: PostgreSQL з розширенням для векторного пошуку дозволяє оновлювати представлення товару в тій самій транзакції, що й саму картку.

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

Діалоговий асистент ставиться поверх цього пошуку й бере на себе уточнення: призначення, розмір, сумісність із уже купленим.

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

Друга половина ефекту — підтримка. Типові звернення (статус доставки, умови повернення, сумісність) закриваються без оператора, а люди переключаються на нестандартні випадки.

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

Формати рішення: пошук за каталогом, асистент, гібрид

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

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

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

Етапи роботи: аудит, схема, налаштування, приймання

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

1. Аудит пошукових запитів. Вивантажуємо журнал пошуку по сайту й звернення в підтримку: де видача порожня, які формулювання не знаходять товар — синоніми, одруки, артикули, побутові назви замість каталожних.
2. Розбір каталогу. Структура карток і атрибутів, наявність, залишки: що потрібно доповнити, щоб бот відповідав за фактом, а не за загальним описом.
3. Схема інтеграції з каталогом. Як надходять актуальні дані, як часто оновлюється база знань, що відбувається при знятті товару з продажу або збої вивантаження. Точки відмови й поведінку бота в них фіксуємо заздалегідь.
4. Правила відповідей та ескалації. Що бот не має права домислювати, за яких умов передає діалог оператору, окремі гілки для доставки, оплати й гарантії.
5. Перевірка якості відповідей. Набір еталонних питань з очікуваними відповідями й прогони на ньому: частка правильних влучань, частка чесних «не знаю» замість вигадки, час відповіді.
6. Приймання на реальному трафіку. Тіньовий режим на частині відвідувачів, порівняння з поточним пошуком, ручна розмітка спірних діалогів — до повного включення.
7. Передача керування. Документація, панель з метриками, порядок поповнення бази знань і відкат до попередньої версії.

Після приймання у вашої команди залишається регламент: як додавати категорії, як перевіряти нові відповіді й куди дивитися, якщо якість просіла.

Комплект постачання: конфігурації, схеми, регламенти

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

• Робочі конфігурації асистента — сценарії діалогу, системні інструкції, правила ескалації на оператора, пороги впевненості. Розгортаються в чистому середовищі одним прогоном, без ручних правок.
• Схема інтеграцій з обліковою системою — карта обміну: які сутності (наявність, ціни, статуси замовлень) звідки читаються, з якою періодичністю, що відбувається при недоступності джерела. Діаграма плюс опис точок відмови й поведінки при розсинхронізації.
• Політики доступу до даних — розмежування ролей, що асистент бачить з картки клієнта й історії замовлень, що маскується в журналах звернень. Окремим блоком — правила й строки зберігання листування.
• Регламент оновлення бази знань — хто і як завантажує нові статті, у якому форматі, як перевіряється якість відповідей після оновлення, як відкочується невдала версія пошукового індексу.
• Документація щодо асистента — архітектура рішення, словник сутностей предметної області, перелік сценаріїв, інструкції для оператора підтримки й для контент-менеджера.
• Набір перевірок — тестові питання з очікуваними відповідями; прогін перед кожним оновленням бази знань показує, які теми асистент перестав закривати.
• План передачі — сесія з командою замовника, розбір типових інцидентів, видача доступів і ролей, порядок ескалації на період супроводу.

Після передачі асистента можна розвивати своїми силами: правки сценарію або поповнення бази знань не потребують нас як посередника.

Кейс: асистент для каталогу на кілька десятків тисяч позицій

Запускали асистента на каталозі близько сорока тисяч позицій: інструменти, витратні матеріали, сумісні артикули. До цього пошук працював за точним збігом слів, і запити виду «насадка для старого перфоратора» йшли до оператора — клієнт або чекав, або закривав кошик.

Що вимірювали і що змінилося

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

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

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

Що робити, якщо чат-бот уже зібрано на готовій платформі

Готову платформу викидати не потрібно — вона залишається каналом і діалоговим каркасом, змінюється лише шар, який готує відповідь. Бот перестає шукати збіг за ключовим словом і починає ходити в каталог: спочатку за фактами про товар, потім за формулюванням.

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

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

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

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

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

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

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

Технічні сумніви: питання перед стартом проєкту

Перед стартом проєкту замовники ставлять одні й ті самі практичні питання — і це правильні питання. Нижче — короткі відповіді на чотири технічні сумніви, які найчастіше виринають на етапі оцінки рішення.

Як асистент відповідає, якщо товару немає в наявності?

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

Звідки беруться актуальні залишки й ціни?

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

Як ви контролюєте якість відповідей асистента?

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

За цими цифрами правимо інструкції асистента, склад пошукового індексу й поріг передачі живому менеджеру.

Обговоримо задачу й повернемося з оцінкою та планом робіт

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

Що корисно підготувати і що ми розберемо на дзвінку:

• вивантаження каталогу: категорії, атрибути, варіанти товару, наявність — за ними будується семантичний індекс і підбирається стратегія чанкінгу карток;
• логи пошуку: частка запитів без результату, довжина формулювань, одруки й синоніми — показують, де поточний пошук втрачає покупця;
• як влаштований пошук зараз: правила ранжування, словники синонімів, фільтри й сортування — щоб не зламати працююче;
• точки інтеграції: каталог, склад, служба підтримки, канал звернення — визначають склад і порядок етапів;
• обмеження: персональні дані, права доступу, вимоги до зберігання історії діалогів;
• еталонні питання: 20–30 типових звернень з очікуваною відповіддю — база для перевірки якості;
• критерії приймання: частка правильних відповідей, частка відмов, час відповіді — фіксуємо до старту.

Опишіть задачу у вільній формі — повернемося з оцінкою проєкту асистента й планом робіт за етапами: від розбору пошуку й підготовки даних до підключення до каналу й передачі документації.