Чому бот-асистент — не просто чат?
Ми розробляємо діалогові інтерфейси для мобільних застосунків, які автоматизують приймання замовлень. Це не чат з оператором: кожна дія — створення, зміна, скасування — атомарна та відкочувана. Користувач може передумати на будь-якому кроці, а бот зберігає контекст.
У нашій практиці понад 50 проєктів з інтеграції ботів з OMS. Наприклад, для мережі кав'ярень ми реалізували бота, який обробляє 300+ замовлень на день. Середній час оформлення — 30 секунд, що вдвічі швидше за лінійні скрипти. Такі рішення скорочують навантаження на підтримку на 40% та економлять до 500 000 ₴ на рік для мережі з 20 точок. Оцініть потенціал під ваш кейс — зв'яжіться з нами.
Як state machine запобігає втраті даних?
Оформлення замовлення через бота — форма з кількома кроками, розтягнута в часі. Між репліками користувач може згорнути застосунок, переключитися в інший, повернутися через 10 хвилин. Стан має зберігатися. Ми використовуємо state machine на Redis: кожен крок — скінченний автомат з явними переходами. Wikipedia - Finite-state machine
Структура слотів для діалогу замовлення:
{
"session_id": "uuid",
"step": "confirm_address",
"order_draft": {
"items": [
{"sku": "ITEM-123", "qty": 2, "price": 1500}
],
"delivery_address": null,
"payment_method": "card",
"promo_code": null
},
"expires_at": "2025-01-15T14:30:00Z"
}
Стан зберігається на сервері (Redis з TTL 30–60 хвилин). Мобільний застосунок передає лише session_id з кожним повідомленням.
Критичний момент: кожен крок діалогу має підтримувати команди «назад» та «скасувати». Якщо користувач на кроці підтвердження адреси напише «змінити товар», бот має повернутися до кроку вибору складу, не обнуляючи вже введені дані.
State machine дає в 2–3 рази менше багів, ніж кастомні обробники діалогів — це доведено на десятках проєктів. Бот з state machine обробляє замовлення вдвічі швидше за звичайні скрипти.
Як ми інтегруємо бота з бекендом замовлень?
Бот не має містити бізнес-логіку. Він викликає методи API:
-
POST /orders/draft — створити чернетку
-
PUT /orders/draft/{id}/items — змінити склад
-
POST /orders/draft/{id}/submit — оформити
-
DELETE /orders/{id} — скасувати
Типова проблема: бот дозволяє користувачеві додати товар, якого немає в наявності, і про це дізнається лише при фінальному submit. Це поганий UX. Перевірку наявності треба робити при додаванні позиції в чернетку.
Якщо використовується LLM для обробки повідомлень — function calling робить інтеграцію чистішою: модель викликає add_to_cart, remove_from_cart, apply_promo_code як інструменти, а не намагається розібрати намір через регулярки. Це дає вдвічі менше помилок розпізнавання та скорочує кількість покинутих кошиків на 25%.
UI на мобільному клієнті
Крім текстового чату, бот часто використовує структуровані елементи:
Quick reply кнопки — після питання «Спосіб оплати?» показуємо варіанти як тапабельні чипи, не змушуємо користувача друкувати.
Картки товарів — при підтвердженні складу замовлення показуємо міні-картки із зображенням, назвою, ціною. На Android це RecyclerView горизонтальної прокрутки всередині bubble повідомлення, на iOS — UICollectionView з horizontalScrollDirection.
Резюме замовлення — фінальний екран перед підтвердженням окремим компонентом, не plain text. Користувач бачить повний список, суму, адресу та кнопку «Оформити». Завдяки такому UI конверсія зростає на 15%.
| Компонент |
iOS (SwiftUI) |
Android (Jetpack Compose) |
| Quick reply |
HStack з чипами |
Row з Surface |
| Картка товару |
LazyHStack з AsyncImage |
LazyRow з AsyncImage |
| Резюме замовлення |
List з Section |
Column з Card |
Сповіщення про статус
Після оформлення замовлення бот продовжує роботу через push-сповіщення: «Замовлення прийнято», «Кур'єр виїхав», «Доставлено». На iOS — APNs через Firebase Cloud Messaging, на Android — FCM напряму.
Сповіщення містить deep_link з параметрами, які відкривають чат з історією цього замовлення, а не головний екран застосунку.
Процес роботи
- Проектування сценаріїв: звичайне замовлення, зміна, скасування, повторне замовлення, промокод.
- Розробка state machine на сервері + інтеграція з API замовлень.
- Мобільний UI: bubble layout, quick replies, картки товарів, резюме.
- Тестування нестандартних шляхів: переривання в середині, суперечливі команди, сесія, що закінчилася.
Технічні деталі state machine: на сервері state machine реалізована на Python з бібліотекою transitions. Стани та переходи описані в YAML-конфізі, що дозволяє змінювати сценарії без перескладання. Кожен стан має таймаут TTL — якщо користувач бездіє 30 хвилин, сесія завершується.
Що входить у результат
- Вихідний код сервера та мобільного клієнта
- Документація з API та сценаріїв
- Налаштування push-сповіщень та deep linking
- Тестування на реальних пристроях (iOS/Android)
- Інструкція з деплою в App Store та Google Play
- Гарантія 6 місяців на баги
На iOS використовуємо StoreKit 2 для in-app purchases та TestFlight для бета-тестування. Бот обробки замовлень на базі state machine підходить для складних сценаріїв.
| Етап |
Тривалість |
| Проектування сценаріїв |
1–2 дні |
| Розробка state machine |
2–4 дні |
| Інтеграція з OMS |
2–3 дні |
| Мобільний UI |
3–5 днів |
| Тестування та налагодження |
2–3 дні |
Орієнтири за термінами
Бот з лінійним сценарієм (вибір → адреса → оплата → підтвердження) + мобільний клієнт — 1–1,5 тижні. З нелінійними сценаріями, інтеграцією з системою лояльності, історією замовлень та push-сповіщеннями — 3–4 тижні.
Наша команда має 8-річний досвід у мобільній розробці. Замовте аудит — ми запропонуємо оптимальне рішення. Отримайте консультацію — розповімо, як бот підходить вашому бізнесу.
Машинне навчання в мобільних застосунках: 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 при класифікації.
| Параметр |
CoreML |
TFLite |
| Платформи |
iOS, macOS, watchOS |
Android, iOS, Linux, embedded |
| Апаратне прискорення |
Neural Engine, GPU, CPU |
NNAPI, GPU (OpenCL/OpenGL), CPU |
| Підтримка квантизації |
FP16, INT8 (з coremltools) |
FP16, INT8, dynamic range |
| Кастомні операції |
Через MLCustomLayer (Swift) |
Через делегати (Java/Kotlin) |
| Розмір бандла моделі |
~3–5 МБ (MobileNetV2 quantized) |
~2–4 МБ |
Що робити, якщо потрібна генерація тексту на пристрої?
Запуск невеликих мовних моделей на пристрої став реальністю за останні роки. 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 токенів/секунду.
Порівняння LLM моделей для on-device
| Модель |
Параметри |
Квантизація |
Розмір |
Швидкість (iPhone 15 Pro) |
| Phi-3-mini (Microsoft) |
3.8B |
4-bit |
~2.3 ГБ |
15-25 токенів/с |
| Gemma-2B (Google) |
2B |
4-bit |
~1.2 ГБ |
30-40 токенів/с |
| TinyLlama |
1.1B |
4-bit |
~0.7 ГБ |
60+ токенів/с |
Обмеження реальні: моделі більше 4B параметрів на мобільних пристроях все ще повільні. Для складних задач міркування on-device LLM поступається GPT-4o за якістю. Гібридний підхід — on-device для коротких завдань та приватних даних, хмара для складних запитів — часто оптимальний. Оцінимо ваш кейс та запропонуємо баланс продуктивності та приватності — напишіть нам.
Інтеграція 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 тижні технічної підтримки після релізу
Типовий пайплайн проекту
-
Аналіз завдання — вимірюємо latency, privacy, size, підтримувані пристрої.
-
Прототипування моделі — в Python, оцінка accuracy на цільових даних.
-
Конвертація та квантизація — під CoreML/TFLite з валідацією.
-
Інтеграція в застосунок — модель обгортається в сервісний шар (легко замінювати CoreML → TFLite → хмара).
-
Тестування — на реальних пристроях, вимір FPS, RAM, батареї.
-
Деплой — через TestFlight / Firebase App Distribution, моніторинг метрик.
Терміни: інтеграція готової CoreML/TFLite моделі — 1–2 тижні, розробка кастомної моделі з мобільною оптимізацією — від 6 тижнів, on-device LLM чат з персоналізацією — 4–8 тижнів.
Чому ми беремося за складні кейси?
10+ років досвіду в мобільній розробці, 50+ впроваджених AI/ML рішень, гарантія сумісності з актуальними версіями iOS та Android. Всі проекти проходять code review та навантажувальне тестування. У вартість вже входить підготовка документації для модерації та навчання вашої команди.
Зв'яжіться з нами — ми допоможемо вибрати архітектуру та впровадити ML у ваш застосунок під ключ. Замовте аудит наявного рішення — безкоштовно оцінимо потенціал економії серверних витрат. Отримайте консультацію експерта — напишіть нам сьогодні.