Інтеграція AI у мобільний застосунок: де ламається на старті
Упровадження AI у продукт ламається не на моделі, а на межах: що команда вважає якістю, де фізично проходить запит і чому те саме питання дає різну відповідь на різних пристроях.
За оцінками Gartner, більшість пілотів не доходить до промислової експлуатації — і причина майже завжди інженерна, а не у можливостях моделі.
Перший збій — розмиті критерії приймання. Поки якість описано як «відповіді виглядають адекватно», роботу не можна ні прийняти, ні помітити погіршення після зміни моделі.
Робоча заміна — розмічений набір реальних запитів і метрики: частка коректних відповідей, частка відмов, час до першої відповіді, поведінка на питаннях поза темою продукту.
Другий — розходження платформ. Хмарна модель і модель на пристрої — різні конфігурації, і без єдиної архітектури AI-функції вони відповідають по-різному: на частині пристроїв функція недоступна, за слабкої мережі відповідь приходить інакше, контекст діалогу губиться. Користувач бачить нестабільність, підтримка — потік звернень без пояснюваної причини.
Третій — непрозора обробка даних: що йде на сервер, що залишається на пристрої, де зберігається історія й логи, як відкликається згода. Поки це не описано, реліз не проходить погодження, а пілот AI-функції залишається у внутрішній збірці.
Розбираємо, як це закривається: критерії якості, єдина архітектура AI-функції та правила обробки даних — усе, що визначає інтеграцію AI у мобільний застосунок до першого рядка коду.
Вимірюваний ефект: що змінюється в метриках після впровадження
Метрики знімаємо двічі: на поточній версії застосунку і через 2–4 тижні після ввімкнення нової логіки на частині аудиторії. Інакше ефект від упровадження AI нічим підтвердити — продукт «здається розумнішим», а частка відмов і час відгуку залишаються тими самими. Нижче — напрями, де зсув видно в цифрах продукту, а не у звіті.
Частка помилкових спрацювань і точність відповідей
Контрольна вибірка з реальних звернень проганяється через стару й нову логіку паралельно — розбіжності розбираються вручну. Модель відповідає лише за впевненості, вищої за налаштований поріг, решта йде за детермінованим сценарієм.
Так точність відповідей зростає без «впевненої нісенітниці», а частка помилкових спрацювань знижується передбачувано й оборотно.
Час відгуку
Дивимося не середнє, а хвіст розподілу: важливо, скільки запитів виходить за поріг, за якого користувач помічає паузу. На пристрої запит обробляють платформенні засоби на кшталт Core ML, хмара підключається лише там, де локальної моделі не вистачає. Легкі сценарії закриваються миттєво, важкі — з передбачуваною затримкою.
Поведінка без мережі
Застосунок має деградувати, а не відмовляти: базові сценарії, кеш останніх відповідей і локальна модель працюють за нульового сигналу. Частка операцій, доступних офлайн, фіксується окремо — це те, що найчастіше обвалює утримання в мобільних продуктах.
Частка ручних операцій
Рахуємо звернення, закриті без участі людини, і частку ескалацій на підтримку. Зазвичай із команди знімається рутинна частина — типові відповіді й розбір вхідних, — а складні випадки приходять уже з контекстом діалогу.
Кожну метрику фіксуємо до запуску, щоб через місяць говорити про результат, а не про враження.
Хмара, пристрій чи гібрид: порівняння режимів роботи
Режим розміщення обчислень визначають три властивості задачі: наскільки чутливі дані, яка затримка відповіді ще сприймається як миттєва і чи має користувач стабільний канал. Звідси три робочі схеми — хмарний AI, AI на пристрої та гібридна схема.
Вибирати між ними за звичкою («у нас усе в хмарі») — найпоширеніше джерело переробок, коли сценарій уже пішов у реліз.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмарний AI | Складні сценарії з довгим контекстом і великим обсягом знань, аналітика по всій базі користувачів, оновлення моделі без випуску нової версії застосунку | Залежність від мережі, затримка на передавання даних, навантаження й трафік зростають лінійно з кількістю звернень, потрібна згода на обробку даних поза пристроєм |
| AI на пристрої | Миттєвий відгук, робота без мережі, чутливі дані — здоров’я, фінанси, листування, прості та середні моделі | Обмежений запас пам’яті й обчислень, вага моделі збільшує застосунок, оновлення лише разом із релізом, якість падає на нестандартних запитах |
| Гібридна схема | Часті сценарії закриваються на пристрої, рідкісні та складні йдуть у хмару; потрібен баланс відгуку, якості й приватності | Дорожче в розробці: два контури, правила маршрутизації запитів, розходження відповідей між режимами, потрібні метрики для обох шляхів |
Порівняння режимів роботи має сенс закінчувати заміром, а не спором на нараді. Збираємо прототип на реальному наборі запитів і дивимося, яку частку сценаріїв модель на пристрої закриває без втрати якості, — далі ця цифра й визначає, що відправляти в хмару.
Заодно видно, як схема поводиться за слабкої мережі та на недорогих пристроях: те, що зазвичай спливає вже в користувачів.
Як проходить інтеграція: етапи інженерної роботи
Упровадження йде етапами, і в кожного — своя точка приймання: замовник бачить артефакт і вирішує, рухатися далі чи коригувати курс. Це прибирає головний ризик AI-проєктів — довгу роботу без проміжного результату, коли про якість стає відомо лише в самому кінці.
- Аудит даних і сценаріїв. Розбираємо, які дані є, у якому вони стані й чи достатньо їх для потрібної якості. Підсумок — перелік сценаріїв, де модель дасть ефект уже зараз, і чесна оцінка тих, де поки не дасть.
- Проєктування схеми. Вирішуємо, що обчислюється на пристрої, а що в хмарі, як функція поводиться без мережі та як оновлюються моделі без випуску нової збірки застосунку. Тут же фіксуємо метрики якості, за якими потім ухвалюватимемо роботу.
- Складання. Інтеграція в наявний застосунок: інтерфейс, зберігання даних, обробка черг запитів, поведінка за нестачі ресурсів і на слабких пристроях. Кожен вузол закривається тестами в міру готовності.
- Перевірка на реальних сценаріях. Прогін на живих даних і типових діях користувача, а не на відібраних прикладах. Окремо дивимося рідкісні та межові випадки — саме там AI-функції ламаються найчастіше.
- Приймання AI-функції. Звіряємо результат із метриками, про які домовилися на старті, і перевіряємо поведінку за відмов: що бачить користувач, якщо модель помилилася або недоступна. Замовник приймає функцію за зрозумілим критерієм, а не «на дотик».
- Передавання рішення. Віддаємо документацію, конфігурації, доступи й регламент оновлення моделей. Команда замовника може розвивати функцію далі своїми силами — або з нашою підтримкою на обумовлених умовах.
Артефакти й документація: що передаємо команді замовника
Рішення не йде «чорною скринькою»: усе, що стосується AI-частини, лежить у репозиторії замовника й описано так, щоб інженер без нас міг зібрати збірку, розгорнути оновлення й повернутися до попередньої версії. Нижче — комплект, який передаємо команді разом із кодом.
- Документація щодо AI-функції — що робить модель, які дані приймає, де межа між обробкою на пристрої та в хмарі й що відбувається без мережі.
- Схеми взаємодії — застосунок, сервіс моделей, кеш і черги: точки відмови, тайм-аути, поведінка за деградації.
- Конфігурації — параметри запитів, пороги впевненості, правила вибору моделі, окремо для збірок на пристрої та в хмарі.
- Регламент оновлення — як розгортається нова версія моделі або інструкцій без випуску оновлення застосунку, хто і за яким сигналом це запускає.
- Політики доступу — де зберігаються ключі, як ротуються, що свідомо не потрапляє в клієнтський код, хто бачить журнали звернень.
- Сценарії перевірки — еталонні запити з очікуваними відповідями, негативні випадки й поріг, нижче якого збірка не йде далі.
- Інструкція з відкату — покрокове повернення до попередньої версії за один прохід і метрики, що підтверджують, що він спрацював.
Сенс у тому, що через місяць після здавання будь-яка зміна AI-частини робиться силами вашої команди, а ми підключаємося там, де потрібен новий сценарій або перегляд архітектури.
Кейс: як скоротили затримку відповіді й прибрали клас відмов
Проєкт — мобільний клієнт із розпізнаванням за зображенням і підказками. Спочатку кожен запит ішов у хмару повністю: застосунок чекав відповіді й залежав від якості зв’язку.
На піках відгук розтягувався в рази, а найдорожче коштував клас відмов «немає відповіді» — користувач бачив індикатор очікування й закривав екран.
Схему розвели на два контури. Легка версія моделі збирається в один формат через ONNX Runtime і виконується прямо на пристрої — вона закриває типові запити без мережі. Важка залишилася в хмарі для рідкісних складних випадків, і туди йде обрізаний фрагмент, а не вихідний файл.
Додали локальне сховище результатів, повтор запиту з наростаючою паузою й попереднє завантаження ваг під час старту застосунку.
За метриками: близько восьми запитів із десяти закриваються на пристрої, відгук на типовому сценарії скоротився втричі, а за слабкої мережі замість десятків секунд очікування приходить локальна відповідь.
Клас відмов «немає відповіді при обриві зв’язку» перестав виникати: задача або вирішується на місці, або йде у відкладене надсилання.
Якість при цьому не просіла — розходження локальної та хмарної відповіді уклалося в частки відсотка, його ми перевіряємо на еталонному наборі в кожному релізі.
Звідси робоче правило: спочатку ділимо запити за ціною помилки й потрібною точністю, потім вирішуємо, що обчислювати на пристрої. Тоді зниження затримки йде не від тюнінгу мережі, а від того, що частина роботи взагалі перестає її торкатися.
Що робити, якщо рішення вже зібрано на готовому сервісі?
Готовий зовнішній сервіс — не борг, а робоча точка входу. Спочатку рахуємо, де саме проходить межа залежності: скільки викликів іде назовні, які сценарії вони обслуговують і що бачить користувач, коли сервіс відповідає повільно або недоступний.
Далі розмічаємо сценарії за критичністю. Зазвичай основне навантаження зосереджене в одному-двох місцях, а решта — рідкісні допоміжні виклики. Паралельно дивимося на деградацію: чи має функція зрозумілий резервний шлях, чи відмова зовнішнього сервісу повністю зупиняє сценарій.
Допоміжні та низькочастотні сценарії можна залишити як є — робота з готовим сервісом там дешевша, ніж переведення на власну схему.
Власна AI-функція потрібна там, де через зовнішній сервіс проходять користувацькі дані, де важлива передбачувана затримка і де навантаження зростає разом із кількістю викликів.
Порядок переведення такий: спочатку власну функцію перевіряють на тому самому потоці запитів, що й зовнішній сервіс, і розбирають розходження; потім перемикають неосновні сценарії; і лише після стабільної якості — головний, а зовнішній сервіс залишається резервом.
Окремо перевірте, як влаштований код. Якщо виклики розкидані по десятках місць, заміна зовнішнього сервісу розтягнеться. Коли всі звернення зібрані в один шар, зміна джерела — правка в одному місці, а не переписування застосунку.
Технічні сумніви: точність, приватність, автономність
Сумніви щодо AI-функції майже завжди лежать в одній площині: де живуть дані, хто відповідає за якість відповідей і що відбувається, коли зв’язку немає.
Нижче — п’ять заперечень, які найчастіше спливають на погодженні архітектури, і те, як ми їх закриваємо на рівні проєктних рішень.
Ці питання ми розбираємо до старту розробки, а не за фактом інциденту. Рішення щодо зберігання, деградації та версіонування моделі фіксуються в документації й потрапляють у перевірки на стенді.
Де зберігаються дані, які обробляє модель?
Залежить від вибраного контуру. За локального інференсу запит і результат не покидають пристрій — у хмару йде лише телеметрія без вмісту.
Якщо частину обчислень винесено на сервер, дані йдуть захищеним каналом, не зберігаються в логах і видаляються одразу після відповіді; строк зберігання задається політикою під вимоги замовника.
Як зрозуміти, що якість відповідей достатня до релізу?
Ми збираємо регресійний набір із розмічених прикладів на реальних даних і проганяємо його на кожній збірці. Рахуємо точність і повноту за класами, а не одне усереднене число: усереднена метрика приховує провали на рідкісних сценаріях. Реліз проходить, лише якщо нова версія не гірша за попередню на еталонній вибірці.
Що з приватністю: користувач може відмовитися від обробки?
Так. Дозволи запитуються явно й за призначенням, а обробка чутливих полів вимикається налаштуванням без втрати решти функціональності. Модель, що працює на пристрої, фізично не може надіслати користувацькі дані назовні — це архітектурна гарантія, а не обіцянка.
Як функція працює без мережі?
Модель постачається всередині застосунку, тому базові сценарії доступні офлайн. У разі втрати зв’язку відповіді йдуть у чергу й досилаються після відновлення каналу, а поки з’єднання немає — працює спрощена логіка. Користувач бачить зрозумілий статус, а не завислий екран.
Наскільки це навантажує пристрій і що при оновленні моделі?
Навантаження ми вимірюємо на слабких пристроях: час відгуку, витрату батареї й нагрівання за тривалої роботи. Важкі сценарії виносимо в хмару, залишаючи на пристрої легку гілку.
Оновлення моделі версіонується, розкочується поетапно й відкочується на попередню версію без випуску нового застосунку.
Обговоримо задачу: з чого почнемо і що потрібно з вашого боку
Щоб оцінка проєкту спиралася на факти, а не на здогади, нам потрібен короткий набір вхідних. Ось що варто підготувати з вашого боку і в якому порядку підуть перші кроки.
- Сценарії, які потрібно закрити: де саме в застосунку очікуєте ефект — розпізнавання, підказки, пошук за власними даними, генерація тексту.
- Обмеження пристроїв і мережі: які моделі телефонів у пріоритеті, чи потрібна робота без інтернету, чи є вимоги до витрати батареї.
- Дані: що вже накопичено, у якому вигляді, чи є розмітка і хто відповідає за права на їх використання.
- Метрики успіху: частка коректних відповідей, час відгуку, скільки ручних операцій має піти.
- Поточний стек і доступи: мобільна платформа, серверна частина, тестові збірки й облікові записи для перевірки.
- Команда з вашого боку: хто вирішує щодо продукту і хто приймає результати етапів.
З цього збираємо схему рішення: що обчислюємо на пристрої, що віддаємо в хмару, як влаштовані оновлення моделі та відкат до попередньої версії. Потім — оцінка проєкту за етапами й план упровадження з точками приймання, щоб результат було видно на кожному кроці, а не лише в кінці. Опишіть задачу — повернемося з оцінкою та планом.
