Розробка AI-чат-бота для Facebook і Instagram з RAG і fine-tuning

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

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

У розробці AI-чат-бота ми починаємо саме з цих місць: вони й визначають, чи буде автоматизація корисна підтримці або додасть їй роботи.

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

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

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

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

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

Що змінюється після впровадження: вимірювані ефекти

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

Частка звернень без оператора

Бот закриває типові сценарії — статус замовлення, умови доставки, запис, повернення — і на них припадає основна маса вхідних. На каналах Meta — Facebook та Instagram — частка автовідповідей виходить на 60–75%, решта переходить до оператора вже зі зібраним контекстом діалогу.

Швидкість першої відповіді

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

Робота в пікові години

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

Зниження навантаження на підтримку

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

Варіанти реалізації: пошук у базі знань і дообучення

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

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

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

Етапи робіт: від розбору переписок до передачі в підтримку

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

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

Комплект постачання: налаштування, схеми та регламенти

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

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

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

Кейс: автовідповіді замість черги — метрики до та після

До впровадження підтримка у двох соцмережах працювала в режимі наздоганяння: 4-5 тисяч звернень на місяць, уночі та на вихідних черга зростала, перша відповідь надходила в середньому через 43 хвилини, а кожне п'яте повідомлення залишалося без відповіді взагалі. Зміни йшли на однотипне — статус замовлення, наявність, терміни доставки, умови повернення.

Що змінили

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

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

На чому стоять цифри

Зріз зібрано за Meta Business Suite та логами діалогів: шість тижнів до запуску і шість тижнів після, за одними й тими самими типами звернень, щоб сезонність і рекламні сплески не спотворювали картину. Нічна черга перестала бути вузьким місцем.

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

Чим пошук у базі знань відрізняється від дообучення моделі?

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

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

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

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

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

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

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

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

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

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

Мітки накопичуються, раз на тиждень розбираємо вибірку: що дописати в базу знань, які формулювання переписати, де модель зобов'язана передати розмову оператору.

Хто відповідає за якість після запуску?

Ми. Метрики, розбір помилок і оновлення бази знань входять у супровід. Від замовника потрібне лише підтвердження бізнес-правил: що вважати правильною відповіддю.

Чи видно, звідки бот узяв відповідь?

Так. У кожної репліки зберігається джерело — фрагмент бази знань або правило. Це робить розбір помилок предметним, а не спором про формулювання.

Обговоримо задачу: що знадобиться з вашого боку

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

• Адміністративний доступ до сторінки Facebook і бізнес-акаунта Instagram з правами на підключення застосунку.
• База знань у вихідному вигляді: регламенти, статті підтримки, каталог, прайс, скрипти операторів. Приводити її до ладу заздалегідь не потрібно — розбір і структурування під пошук за знаннями наша частина роботи.
• 200–300 реальних діалогів за останні місяці, включно з невдалими та ескалаціями: за ними видно фактичну мову клієнтів і місця, де бот помиляється без дообучення на ваших прикладах.
• Перелік сценаріїв з обов'язковою передачею оператору: скарга, повернення, юридичне питання, нетипова заявка.
• Відповідальний за сценарії з вашого боку — людина, яка затверджує тон, формулювання та правила ескалації.
• Дані про навантаження: добова кількість звернень і пікові години — від них залежать вимоги до стійкості та поведінка бота під час сплеску.
• Правила роботи з персональними даними: що допустимо надсилати в модель, а що залишається у вашому контурі.

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