Усе почалось із простого питання: “А що, якщо зробити одного бота для всього?”
Це звучало просто, поки я не зрозумів, що мені потрібні три зовсім різних типи ботів одночасно. Кожен має розуміти користувача, але по-своєму. Кожен має приймати рішення, але за своїми правилами. І всі вони мають використовувати одну AI систему, яка насправді розумна.
Звучить як головний біль? Це так і було спочатку.
Чому я почав це будувати?
Мені потрібен був сервіс, який би:
- Говорив з різними AI провайдерами (OpenAI, Google, Claude, власною моделью якщо потрібно) без того, щоб прив’язуватися до одного
- Розумів контекст розмови, не відправляючи всю історію листування AI (це дорого і повільно)
- Керував трьома типами ботів, які часто конфліктують у своїх потребах
- Парсить контент — видобував важливу інформацію з повідомлень користувачів, сайтів, документів
Розпочалась дикість.
Що насправді здійснює AI Gateway?
AI Gateway — це мікросервіс. Він сидить посередині: ловить повідомлення від користувачів, розуміє, що там написано, витягує релевантну інформацію, обирає найкращого AI помічника й повертає відповідь, що звучить природно.
Але це не просто шлюз до ChatGPT. Це був мій спосіб організувати екосистему з трьох типів ботів:
Integration Bots — мої робочі коні. Розсилають новини в канали, керують заявками на вступ до груп, запускають ігри. Він лише один для проекту (один користувач може мати декілька проектів), й він просто робить свою роботу, не ставлячи запитань.
Constructor Bots — універсальні воїни. Я можу налаштувати їх через PHP хендлери (які знов таки по вивіреному промту може писати gpt чи cloud, поки що тре робити в чаті не автоматизовано) для майже всього: опитування, збір замовлень, складні діалоги. Це як давати учню завдання та дивитись, як він його виконує.
User Bots — справжні, живі боти з власними персональностями. Вони розмовляють як люди, запам’ятовують деталі про вас, мають своє почуття гумору. І найголовніше — вони розумні, тому що живуть всередину AI Gateway.
Чому це складно?
Уявіть: користувач пише коротке повідомлення на п’ять слів. Мені треба дати розумну відповідь.
Але як? Весь чат історії? Дорого, повільно, токени летять. Три останніх повідомлення? Контекст буде втрачатись. Ви замовили кави три дні тому, а тепер запитуєте про ціну — система забула?
Так я вигадав Smart Context — систему, яка обирає найважливішу інформацію з чотирьох джерел:
- Останні кілька повідомлень (негайний контекст)
- Витяг з усієї історії (що було за місяць)
- Подібні розмови з минулого (через векторний пошук)
- Твої особисті факти (де ти живеш, чим займаєшся)
І все це просто, ефективно, без шуму.
Потім виявилось, що OpenAI іноді перебуває у обслуговуванні, Google API подекуди поправляється, Claude має свої причуди. Тож я зробив мультипровайдерну систему — як подстрахування. Не працює один? Автоматично переходимо на другого.
Додайте сюди бази даних, систему черг, Docker, шифрування, логування — і ось ви вже управляєте складною машиною, яка має працювати 24/7.
Чому я про це пишу?
Останні місяці я не просто кодив. Я робив помилки, вирішував їх, знаходив елегантні рішення й іноді повертався й переробляв все спочатку.
Я вирішив поділитися цим досвідом не як “вот дивіться, як я крутий”. А як: “Ось що я навчився, коли будував систему для реальних людей, які очікують, що вона просто працює”.
Ця серія про:
- Як спроектувати систему, що росте разом з вами
- Як парсити й розуміти контент, а не просто його передавати AI
- Як мультипровайдерна архітектура врятувала мене від lock-in
- Як мозаїка з трьох типів ботів насправді складається в щось корисне
Це для вас, якщо:
- Ви розробник, якому цікава Clean Architecture не в теорії, а на практиці
- Ви розмірковуєте, як запустити власний AI сервіс без інвестиції в мільйони
- Вам цікаво, як Telegram боти можуть бути насправді розумними
- Ви джун, який хоче взяти складний проект і не знаєте, з чого почати
План серії
Я напишу цикл статей:
- Вступ ← ви тут
- Архітектура — чому Clean Architecture була спасінням
- Smart Context — як система вибирає те, що важливо
- Парсер контенту — видобування корисної інформації з хаосу
- AI Провайдери — як я не прив’язався до одного AI
- Три типи ботів — який з них робить що й чому їм потрібна була така архітектура
- Frontend і API — як все з’єднується в одну систему
- Реальні виклики — які проблеми я вирішував, коли система вже працювала з користувачами
- Що дальше — як розширювати й невпинно покращувати
Кожна стаття буде невеликою, але повнота. Без води. Лиш факти, дизайнерські рішення й дещо про помилки.
Чого чекати?
Це не приватна документація компанії. Це моя історія розробки — про те, як один розробник вирішував складні задачі й робив помилки, які варто знати іншим.
Буде код? Буде, але вибірковий — не весь, лиш той, що потрібен для розуміння.
Будуть компроміси? Будуть. Ідеалу не існує.
Буде чесно про те, що не спрацювало? Звичайно. Інакше це казки.