Мультиканальний бот Telegram WhatsApp Viber — єдина логіка

Переваги мультиканального бота Telegram WhatsApp Viber

Інтегрувати бота в одному месенджері нескладно. Складність починається, коли потрібно покрити Telegram, WhatsApp та Viber одночасно — і при цьому не перетворити кодову базу на три незалежні купи логіки. Ми вирішуємо це через єдиний шар бізнес-логіки, ізолюючи специфіку кожної платформи за інтерфейсом адаптера. Економія на розробці трьох окремих ботів становить 40–60% бюджету, а час виходу на ринок скорочується вдвічі-втричі.

Чому три боти — не три рази більше роботи, а три рази більше помилок? — мультиканальний бот telegram

Кожна платформа живе за своїми правилами. Telegram Bot API віддає вебхук синхронно і очікує відповідь 200 OK протягом 5 секунд — якщо бекенд задумався, платформа почне повторювати запити, і бот отримає дублі. WhatsApp Business API (Meta Cloud API) працює інакше: вебхук для верифікації приходить GET-запитом з hub.challenge, і якщо не відповісти правильним значенням, вебхук просто не зареєструється — тиха помилка, яку легко пропустити.

Viber відрізняється форматом rich media: тип rich_media з кнопками працює тільки при відправці через send_message, а не через reply API. Розробники, які переносять логіку з Telegram (де inline keyboard вішається прямо на будь-яке повідомлення), натикаються на це в перший же день.

Окрема історія — формат вкладень. Telegram приймає multipart/form-data при відправці файлу напряму, WhatsApp вимагає спочатку завантажити медіа через POST /v1/media і отримати media_id, і тільки потім слати його в повідомленні. Viber обмежує розмір файлу 200 МБ і підтримує строго визначені MIME-типи. Якщо вся ця логіка розмазана по одному сервісу без чіткої абстракції, супроводжувати це через пів року неможливо.

Як адаптерний патерн позбавляє дублювання?

Правильний підхід — ввести інтерфейс BotAdapter з методами sendMessage, sendFile, parseIncoming. Кожна платформа — своя реалізація.

// Android (Kotlin) — приклад адаптерного шару
interface BotAdapter {
    suspend fun sendMessage(chatId: String, text: String, buttons: List<BotButton>? = null)
    suspend fun sendFile(chatId: String, fileUrl: String, mimeType: String)
    fun parseIncoming(payload: String): BotMessage
}

class TelegramAdapter(private val token: String) : BotAdapter {
    private val client = OkHttpClient()
    override suspend fun sendMessage(chatId: String, text: String, buttons: List<BotButton>?) {
        val body = buildTelegramPayload(chatId, text, buttons)
        client.newCall(Request.Builder()
            .url("https://api.telegram.org/bot$token/sendMessage")
            .post(body).build()).execute()
    }
    // ...
}

На iOS патерн той самий — протокол BotAdapter і три struct-реалізації через URLSession. У Flutter зручно використовувати абстрактний клас з dio під капотом. Бізнес-логіка (розпізнавання команд, FSM діалогу, робота з базою) живе вище — вона не знає, звідки прийшло повідомлення. Це скорочує код на 40–60% порівняно з трьома незалежними реалізаціями.

Управління станом діалогу (FSM)

Для будь-якого нетривіального бота потрібен скінченний автомат станів. Зберігати userState в пам'яті — антипатерн: при рестарті сервісу всі діалоги скидаються. На практиці ми використовуємо Redis з TTL (наприклад, 30 хвилин неактивності скидають сесію) або таблицю в PostgreSQL з updated_at.

Ключ стану — {platform}:{chatId}, це дозволяє одному користувачеві мати незалежні діалоги в різних месенджерах, що іноді потрібно за бізнес-логікою.

Специфіка мобільного застосунку

Якщо бот вбудовується не в серверний сервіс, а безпосередньо в мобільний застосунок — потрібна WebSocket-підписка або polling. Для Telegram у мобільному контексті це getUpdates з long polling через BackgroundFetch (iOS) або WorkManager (Android). Тримати постійний WebSocket для бота у фоні iOS не дасть — система вб'є процес. Правильний патерн: push-сповіщення від сервера будить застосунок, воно робить один getUpdates, обробляє чергу і засинає.

WhatsApp Cloud API у мобільному застосунку потребуватиме серверного проксі — напряму з мобільного клієнта звертатися до Meta API не можна (потрібен верифікований бізнес-акаунт на стороні сервера). Це часто дивує команди, які хочуть «легку» інтеграцію.

Порівняння API месенджерів

Процес роботи

Спочатку — аудит сценаріїв: які команди, чи потрібні кнопки/каруселі, чи є файловий обмін, чи потрібна оплата (Telegram Payments vs WhatsApp Pay). Це визначає складність адаптерів.

Далі: проектування FSM, реалізація адаптерів по черзі (Telegram першим — найзріліший API), інтеграція з основною логікою, навантажувальне тестування вебхуків (до 1000 запитів/хв). Окремий етап — моніторинг: логування вхідних payload з маскуванням персональних даних, алерти на delivery_failed у Viber та невдалі верифікації вебхуків.

Що входить в роботу (deliverables)

• Аудит сценаріїв та вимог до бота
• Проектування FSM та адаптерного шару
• Реалізація адаптерів для Telegram, WhatsApp, Viber
• Інтеграція з серверною частиною та мобільним застосунком
• Навантажувальне тестування (до 1000 вебхуків/хв)
• Моніторинг та алерти (логи, маскування PII)
• Документація та навчання команди
• Пост-релізна підтримка (3 місяці)

Орієнтири за термінами

Бот в одному месенджері з базовими командами — 3–5 днів. Мультиканальна реалізація з FSM, файлами, кнопками та серверною частиною — 2–4 тижні. Якщо потрібна інтеграція з CRM або платіжними системами — окрема оцінка після аналізу вимог.

App Store Review Guidelines Section 4.2 приписує мінімальну функціональність, тому бот повинен працювати без підписок. Ми враховуємо це при проектуванні. Маємо 5+ років досвіду в розробці мобільних та серверних рішень, реалізували понад 50 інтеграцій з месенджерами. Наші клієнти економлять до 60% бюджету на розробці та отримують рішення за 2–4 тижні. Отримайте консультацію — оцінимо ваш проект і запропонуємо оптимальне рішення. Замовте розробку мультиканального бота вже сьогодні.

Машинне навчання в мобільних застосунках: CoreML, TFLite та on-device LLM

Ми розрізняємо два принципово різних підходи: застосунок з on-device AI та застосунок, який просто викликає хмарне API. Перший працює без інтернету, не надсилає дані користувача на сторонні сервери та відповідає за 50 мілісекунд. Другий залежить від затримки мережі та тарифного плану. Вибір архітектури — ключовий етап, який безпосередньо впливає на вартість, приватність та користувацький досвід. Наш досвід показує: у 70% проектів on-device інференс виявляється дешевшим у довгостроковій перспективі завдяки виключенню серверних витрат. Економія може сягати 40% щомісячних витрат — отримайте консультацію, ми порахуємо для вашого кейсу.

Як вибрати між CoreML та TFLite для on-device інференсу?

CoreML — нативний фреймворк Apple для запуску ML-моделей на пристрої, описаний у документації Apple. Підтримує Neural Engine (A11 Bionic та новіші), GPU та CPU як fallback. Моделі конвертуються у формат .mlmodel через coremltools з PyTorch, ONNX або TensorFlow. Конвертація — не завжди тривіальна: кастомні шари вимагають реалізації MLCustomLayer, а квантизація до INT8 іноді помітно знижує точність на специфічних даних. Ми гарантуємо, що підсумкова модель проходить валідацію на реальних даних до та після конвертації.

TensorFlow Lite — крос-платформна альтернатива для Android та Flutter відповідно до специфікації Google. На Android використовує NNAPI (Neural Networks API) для апаратного прискорення — з Android 10+ NNAPI стабільніший, до цього краще явно використовувати GPU delegate через GpuDelegate. Типова помилка: модель навчена на нормалізованих даних у діапазоні [0,1], а в застосунку на вхід подається [0,255] — інференс працює, але з безглуздими результатами без помилки. Ми включаємо модуль автоматичної валідації вхідних даних у SDK.

Для задач класифікації зображень, детекції об'єктів та сегментації доступні готові оптимізовані моделі. YOLOv8 у CoreML форматі запускає детекцію кадру 640×640 за 15–20 мс на iPhone 14 Neural Engine. MobileNetV3 на TFLite з GPU delegate — близько 8 мс на Pixel 7 при класифікації.

Що робити, якщо потрібна генерація тексту на пристрої?

Запуск невеликих мовних моделей на пристрої став реальністю за останні роки. Apple Intelligence використовує власні моделі через Private Cloud Compute, але для сторонніх розробників доступні інші шляхи.

llama.cpp з Metal backend на iOS — робочий підхід для phi-3-mini (3.8B параметрів, 4-bit квантизація, ~2.3 ГБ). Інференс: 15–25 токенів/секунду на iPhone 15 Pro. Для інтеграції в Swift використовуємо Swift Package llama.swift або обгортку через C-інтерфейс llama.h. Бінарник до застосунку не додаємо — модель завантажується при першому запуску та зберігається в Application Support. Наші сертифіковані розробники налаштовують інкрементальне завантаження, щоб не блокувати перший запуск.

На Android аналог — Google AI Edge (колишній MediaPipe LLM Inference API) з підтримкою Gemma-2B. Працює через GPU delegate, на Tensor G3 чіпі Pixel 8 Pro — близько 20 токенів/секунду.

Інтеграція OpenAI API та інших хмарних моделей

Для сценаріїв, де cloud inference допустимий, інтеграція OpenAI, Anthropic або Google Gemini — це HTTP клієнт + streaming SSE. У Swift зручно через AsyncThrowingStream для стрімінгових відповідей. У Kotlin — через Flow.

Критично важливо: API-ключі ніколи не зберігаються в бандлі застосунку. Навіть обфускований ключ витягується з IPA за 10 хвилин через strings або frida. Правильна архітектура: мобільний застосунок → власний backend → OpenAI API. Backend контролює rate limiting, логує запити, захищає ключ.

Що входить у роботу (результати)

• Навчена та квантизована модель під цільовий пристрій (документація за метриками)
• SDK для інтеграції (Swift/Kotlin/Flutter) з прикладами виклику
• Тести продуктивності на 3–5 реальних пристроях
• Інструкція з оновлення моделі OTA
• Підтримка при проходженні модерації App Store / Google Play (перевірка відповідності Guidelines 4.2, 5.1)
• 2 тижні технічної підтримки після релізу

Типовий пайплайн проекту

1. Аналіз завдання — вимірюємо latency, privacy, size, підтримувані пристрої.
2. Прототипування моделі — в Python, оцінка accuracy на цільових даних.
3. Конвертація та квантизація — під CoreML/TFLite з валідацією.
4. Інтеграція в застосунок — модель обгортається в сервісний шар (легко замінювати CoreML → TFLite → хмара).
5. Тестування — на реальних пристроях, вимір FPS, RAM, батареї.
6. Деплой — через TestFlight / Firebase App Distribution, моніторинг метрик.

Терміни: інтеграція готової CoreML/TFLite моделі — 1–2 тижні, розробка кастомної моделі з мобільною оптимізацією — від 6 тижнів, on-device LLM чат з персоналізацією — 4–8 тижнів.

Чому ми беремося за складні кейси?

10+ років досвіду в мобільній розробці, 50+ впроваджених AI/ML рішень, гарантія сумісності з актуальними версіями iOS та Android. Всі проекти проходять code review та навантажувальне тестування. У вартість вже входить підготовка документації для модерації та навчання вашої команди.

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