Найскладніше в цьому проєкті було не написати бота. Найскладніше — зробити так, щоб він не вигадував. У ХАРАКТЕР парку вже був AI-асистент від іншого виконавця, і саме через вигадані відповіді ним перестали користуватися. Нижче — як ми будували заміну: звідки взялося замовлення, чому на другому тижні все пішло не за планом, що довелося переписати й що з цього вийшло. З перепискою, скріншотами й відгуком замовника наприкінці.

Як нас знайшли і чому обрали

ХАРАКТЕР парк — комплекс відпочинку в Крюківщині під Києвом: будиночки й шале, два басейни, ресторан. Вони знайшли наше оголошення про розробку ботів на майданчику оголошень і вийшли на зв’язок самі.

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

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

Що було до нас

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

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

Що будували

Асистент у Telegram на aiogram 3, база знань — вісім документів від клієнта, приблизно 71 тисяча символів: опис будиночків, правила, меню ресторану, умови бронювання.

• PostgreSQL 16 з pgvector — основна база й векторне сховище в одному сервісі, без окремої векторної БД
• RAG-пошук по базі знань, зверху — переранжування результатів
• GPT-4o-mini як основна модель, Claude Haiku як резерв на випадок недоступності
• Redis — стани діалогу, rate-limit, кеш
• Стрімінг відповіді через редагування повідомлення: текст з’являється поступово, а не після п’ятисекундної паузи
• Адмінка для власників і менеджерів — щоб редагувати інформацію без розробника

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

Де все пішло не за планом

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

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

Рішення: окремий шар фактів

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

1. 1

   Класифікація запиту

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

2. 2

   Добір фактів під категорію

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

3. 3

   Фільтр релевантності на великих категоріях

   У категорії будиночків фактів 79 — це близько 5,7 тисячі токенів. Якщо висипати всі, потрібні один-два рядки просто тонуть. Понад поріг у 25 фактів лишаємо тільки релевантні запиту.

4. 4

   Захист від втрати базового

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

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

Ціни, які не можна вигадати

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

Інтеграція read-only: жодних записів у чужу систему. Плюс кеш токена авторизації в Redis, ретраї з паузами на тимчасові помилки й окрема обробка блокування з боку Cloudflare — щоб збій на їхньому боці не перетворювався на мовчазну неправильну відповідь.

Як виглядав робочий процес

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

Що вийшло

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

Парк запустив бота публічно й представив його гостям в Instagram як окремого «співробітника», доступного цілодобово. За перший тиждень — близько 500 користувачів.

Відгук замовника

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

Часті питання про цей проєкт

Коротко

• Клієнт прийшов після невдалого AI-бота від іншого виконавця: «не консультував зовсім, плутанина між інфою, помилки зовсім не виправлялись».
• Нас обрали з трьох виконавців і не за найнижчою ціною — вирішило питання про підтримку після запуску.
• MVP за два тижні, потім ще один-два тижні переробки через галюцинації. Доплату не брали.
• Рішення: шар структурованих фактів у запиті до моделі плюс живі ціни й доступність із системи бронювання.
• Клієнт редагує інформацію сам через адмінку — саме цього не вистачало в попередньому рішенні.
• Результат: близько 500 користувачів за перший тиждень і анонс бота в Instagram парку як «ще одного колеги».