Як я будував AI Gateway: Вступ до серії

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

Усе почалось із простого питання: «А що, якщо зробити одного бота для всього?»

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

Звучить як головний біль? Це так і було з початку.

Чому я почав це будувати?

Мені потрібен був сервіс, який би:

— Говорив з різними AI провайдерами (OpenAI, Google, Claude, власною моделью якщо потрібно) без того, щоб прив’язуватися до одного

— Розумів контекст розмови, не відправляючи всю історію листування AI (це дорого і повільно)

— Керував трьома типами ботів, які часто конфліктують у своїх потребах

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

І понеслось, розпочалась дикість та драйв від нового

Що насправді здійснює AI Gateway?

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

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

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

Constructor Bots — універсальні воїни з яких усе і почалось, вони налаштовуються через PHP хендлери (які знов таки по вивіреному промту може писати gpt чи cloud, поки що тре робити в чаті не автоматизовано через шлюз AI Gateway) для майже всього: опитування, збір замовлень, каптча, можливо Апки та ігри, автоматизація авторизації User Bots та багато іншого, при певних допрацюваннях звісно ж.

User Bots — справжні, живі боти з власними персональностями, тобто з власною історією, хто він звідки, як завти. Вони розмовляють як люди, запам’ятовують деталі про вас, мають своє почуття гумору. І найголовніше — вони трохи розумні, не тому що живуть всередину AI Gateway, а тому що складається таке враження у фокус групи, вони ще не ідеальні але рух в цьому напрямку буде пізніше

Чому це складно, ось тут може бути цікаво?

Уявіть: користувач пише коротке повідомлення на п’ять слів. Мені треба дати розумну відповідь.

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

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

1. Останні кілька повідомлень (негайний контекст)
2. Витяг з усієї історії (що було за місяць)
3. Подібні розмови з минулого (через векторний пошук)
4. Твої особисті факти (де ти живеш, чим займаєшся)

І все це просто, ефективно, без шуму.

Потім виявилось, що OpenAI іноді перебуває у обслуговуванні чи закінчились на рахунку грошики, Google API подекуди нестабільний, Claude теж має свої причуди, а кастомною моделю поки ще не обзавівся. Тож я зробив мультипровайдерну систему — як подстрахування. Не працює один? Автоматично переходимо на другого (не кажу що так добре, час покаже).

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

Чому я про це пишу?

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

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

Ця серія про:

— Як спроектувати систему, що росте разом з вами та компоненти якої можна використати в інших проектах

— Як парсити й розуміти контент, а не просто його передавати AI

— Як мозаїка з трьох типів ботів насправді складається в щось корисне

— Можливо у вас складеться своє бачення і ви побачите як не тре робити і зробите краще

Це для вас, якщо:

— Ви розробник, якому цікаві такі проекти не в теорії, а на практиці

— Ви розмірковуєте, як запустити власний AI сервіс без інвестиції в мільйони

— Вам цікаво, як Telegram боти можуть бути насправді розумними

— Ви джун, який хоче взяти складний проект і не знаєте, з чого почати

План серії

Я напишу цикл статей:

1. Вступ ви зараз тут
2. Архітектура — чому саме така архітектура була спасінням
3. Smart Context — як система вибирає те, що важливо
4. Парсер контенту — видобування корисної інформації з хаосу
5. AI Провайдери — як я не прив’язався до одного AI
6. Три типи ботів — який з них робить що й чому їм потрібна була така архітектура
7. Frontend і API — як все з’єднується в одну систему
8. Реальні виклики — які проблеми я вирішував, коли система вже працювала з користувачами
9. Що далі — як розширювати й невпинно покращувати

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

Чого чекати?

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

Буде код? Буде, але вибірковий — не весь, лиш той, що потрібен для розуміння.

Будуть компроміси? Будуть. Ідеалу не існує.

Буде чесно про те, що не спрацювало? Звичайно. Інакше це казки.