Cloud и On-Device AI для мобильных приложений: полный цикл интеграции

Интеграция AI в мобильное приложение: где ломается на старте

Внедрение AI в продукт ломается не на модели, а на границах: что команда считает качеством, где физически проходит запрос и почему один и тот же вопрос даёт разный ответ на разных устройствах. По оценкам Gartner, большая часть пилотов не доходит до промышленной эксплуатации — и причина почти всегда инженерная, а не в возможностях модели.

Первый сбой — размытые критерии приёмки. Пока качество описано как «ответы выглядят адекватно», работу нельзя ни принять, ни заметить ухудшение после смены модели. Рабочая замена — размеченный набор реальных запросов и метрики: доля корректных ответов, доля отказов, время до первого ответа, поведение на вопросах вне темы продукта.

Второй — расхождение платформ. Облачная модель и модель на устройстве — разные конфигурации, и без единой архитектуры AI-функции они отвечают по-разному: на части устройств функция недоступна, при слабой сети ответ приходит иначе, контекст диалога теряется. Пользователь видит нестабильность, поддержка — поток обращений без объяснимой причины.

Третий — непрозрачная обработка данных: что уходит на сервер, что остаётся на устройстве, где хранится история и логи, как отзывается согласие. Пока это не описано, релиз не проходит согласование, а пилот AI-функции остаётся во внутренней сборке.

Разбираем, как это закрывается: критерии качества, единая архитектура AI-функции и правила обработки данных — всё, что определяет интеграцию AI в мобильное приложение до первой строки кода.

Измеримый эффект: что меняется в метриках после внедрения

Метрики снимаем дважды: на текущей версии приложения и через 2–4 недели после включения новой логики на части аудитории. Иначе эффект от внедрения AI нечем подтвердить — продукт «кажется умнее», а доля отказов и время отклика остаются прежними. Ниже направления, где сдвиг виден в цифрах продукта, а не в отчёте.

Доля ошибочных срабатываний и точность ответов

Контрольная выборка из реальных обращений прогоняется через старую и новую логику параллельно — расхождения разбираются вручную. Модель отвечает только при уверенности выше настроенного порога, остальное уходит по детерминированному сценарию. Так точность ответов растёт без «уверенной чепухи», а доля ошибочных срабатываний снижается предсказуемо и обратимо.

Время отклика

Смотрим не среднее, а хвост распределения: важно, сколько запросов выходит за порог, при котором пользователь замечает паузу. На устройстве запрос обрабатывают платформенные средства вроде Core ML, облако подключается только там, где локальной модели не хватает. Лёгкие сценарии закрываются мгновенно, тяжёлые — с предсказуемой задержкой.

Поведение без сети

Приложение должно деградировать, а не отказывать: базовые сценарии, кеш последних ответов и локальная модель работают при нулевом сигнале. Доля операций, доступных офлайн, фиксируется отдельно — это то, что чаще всего роняет удержание в мобильных продуктах.

Доля ручных операций

Считаем обращения, закрытые без участия человека, и долю эскалаций на поддержку. Обычно с команды снимается рутинная часть — типовые ответы и разбор входящих, — а сложные случаи приходят уже с контекстом диалога.

Каждую метрику фиксируем до запуска, чтобы через месяц говорить о результате, а не о впечатлениях.

Облако, устройство или гибрид: сравнение режимов работы

Режим размещения вычислений определяют три свойства задачи: насколько чувствительны данные, какая задержка ответа ещё воспринимается как мгновенная и есть ли у пользователя стабильный канал. Отсюда три рабочие схемы — облачный AI, AI на устройстве и гибридная схема. Выбирать между ними по привычке («у нас всё в облаке») — самый частый источник переделок, когда сценарий уже ушёл в релиз.

Сравнение режимов работы имеет смысл заканчивать замером, а не спором на совещании. Собираем прототип на реальном наборе запросов и смотрим, какую долю сценариев модель на устройстве закрывает без потери качества, — дальше эта цифра и определяет, что отправлять в облако. Заодно видно, как схема ведёт себя при слабой сети и на недорогих устройствах: то, что обычно всплывает уже у пользователей.

Как проходит интеграция: этапы инженерной работы

Внедрение идёт этапами, и у каждого — своя точка приёмки: заказчик видит артефакт и решает, двигаться дальше или корректировать курс. Это убирает главный риск AI-проектов — длинную работу без промежуточного результата, когда о качестве становится известно только в самом конце.

1. Аудит данных и сценариев. Разбираем, какие данные есть, в каком они состоянии и достаточно ли их для нужного качества. Итог — перечень сценариев, где модель даст эффект уже сейчас, и честная оценка тех, где пока не даст.
2. Проектирование схемы. Решаем, что считается на устройстве, а что в облаке, как функция ведёт себя без сети и как обновляются модели без выпуска новой сборки приложения. Здесь же фиксируем метрики качества, по которым потом будем принимать работу.
3. Сборка. Интеграция в существующее приложение: интерфейс, хранение данных, обработка очередей запросов, поведение при нехватке ресурсов и на слабых устройствах. Каждый узел закрывается тестами по мере готовности.
4. Проверка на реальных сценариях. Прогон на живых данных и типичных действиях пользователя, а не на отобранных примерах. Отдельно смотрим редкие и пограничные случаи — именно там AI-функции ломаются чаще всего.
5. Приёмка AI-функции. Сверяем результат с метриками, о которых договорились на старте, и проверяем поведение при отказах: что видит пользователь, если модель ошиблась или недоступна. Заказчик принимает функцию по понятному критерию, а не «на ощупь».
6. Передача решения. Отдаём документацию, конфигурации, доступы и регламент обновления моделей. Команда заказчика может развивать функцию дальше своими силами — или с нашей поддержкой на оговорённых условиях.

Артефакты и документация: что передаём команде заказчика

Решение не уходит «чёрным ящиком»: всё, что относится к AI-части, лежит в репозитории заказчика и описано так, чтобы инженер без нас мог собрать сборку, выкатить обновление и вернуться к предыдущей версии. Ниже — комплект, который передаём команде вместе с кодом.

• Документация по AI-функции — что делает модель, какие данные принимает, где граница между обработкой на устройстве и в облаке и что происходит без сети.
• Схемы взаимодействия — приложение, сервис моделей, кэш и очереди: точки отказа, таймауты, поведение при деградации.
• Конфигурации — параметры запросов, пороги уверенности, правила выбора модели, раздельно для сборок на устройстве и в облаке.
• Регламент обновления — как выкатывается новая версия модели или инструкций без выпуска обновления приложения, кто и по какому сигналу это запускает.
• Политики доступа — где хранятся ключи, как ротируются, что осознанно не попадает в клиентский код, кто видит журналы обращений.
• Сценарии проверки — эталонные запросы с ожидаемыми ответами, негативные случаи и порог, ниже которого сборка не идёт дальше.
• Инструкция по откату — пошаговый возврат к предыдущей версии за один проход и метрики, подтверждающие, что он сработал.

Смысл в том, что через месяц после сдачи любое изменение AI-части делается силами вашей команды, а мы подключаемся там, где нужен новый сценарий или пересмотр архитектуры.

Кейс: как сократили задержку ответа и убрали класс отказов

Проект — мобильный клиент с распознаванием по изображению и подсказками. Изначально каждый запрос уходил в облако целиком: приложение ждало ответа и зависело от качества связи. На пиках отклик растягивался в разы, а дороже всего обходился класс отказов «нет ответа» — пользователь видел индикатор ожидания и закрывал экран.

Схему развели на два контура. Лёгкая версия модели собирается в один формат через ONNX Runtime и исполняется прямо на устройстве — она закрывает типовые запросы без сети. Тяжёлая осталась в облаке для редких сложных случаев, и туда уходит обрезанный фрагмент, а не исходный файл. Добавили локальное хранилище результатов, повтор запроса с нарастающей паузой и предзагрузку весов при старте приложения.

По метрикам: около восьми запросов из десяти закрываются на устройстве, отклик на типовом сценарии сократился втрое, а на слабой сети вместо десятков секунд ожидания приходит локальный ответ. Класс отказов «нет ответа при обрыве связи» перестал возникать: задача либо решается на месте, либо уходит в отложенную отправку. Качество при этом не просело — расхождение локального и облачного ответа уложилось в доли процента, его мы перепроверяем на эталонном наборе в каждом релизе.

Отсюда рабочее правило: сначала делим запросы по цене ошибки и требуемой точности, потом решаем, что считать на устройстве. Тогда снижение задержки идёт не от тюнинга сети, а от того, что часть работы вообще перестаёт её касаться.

Что делать, если решение уже собрано на готовом сервисе?

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

Дальше размечаем сценарии по критичности. Обычно основная нагрузка сосредоточена в одном-двух местах, а остальное — редкие вспомогательные вызовы. Параллельно смотрим на деградацию: есть ли у функции понятный резервный путь, или отказ внешнего сервиса полностью останавливает сценарий.

Вспомогательные и низкочастотные сценарии можно оставить как есть — работа с готовым сервисом там дешевле, чем перевод на свою схему. Своя AI-функция нужна там, где через внешний сервис проходят пользовательские данные, где важна предсказуемая задержка и где нагрузка растёт вместе с числом вызовов.

Порядок перевода такой: сначала свою функцию проверяют на том же потоке запросов, что и внешний сервис, и разбирают расхождения; затем переключают неосновные сценарии; и только после стабильного качества — главный, а внешний сервис остаётся резервом.

Отдельно проверьте, как устроен код. Если вызовы разбросаны по десяткам мест, замена внешнего сервиса растянется. Когда все обращения собраны в один слой, смена источника — правка в одном месте, а не переписывание приложения.

Технические сомнения: точность, приватность, автономность

Сомнения по AI-функции почти всегда лежат в одной плоскости: где живут данные, кто отвечает за качество ответов и что происходит, когда связи нет. Ниже — пять возражений, которые чаще всего всплывают на согласовании архитектуры, и то, как мы их закрываем на уровне проектных решений.

Эти вопросы мы разбираем до старта разработки, а не по факту инцидента. Решения по хранению, деградации и версионированию модели фиксируются в документации и попадают в проверки на стенде.

Как понять, что качество ответов достаточное до релиза?

Мы собираем регрессионный набор из размеченных примеров на реальных данных и прогоняем его на каждой сборке. Считаем точность и полноту по классам, а не одно усреднённое число: усреднённая метрика скрывает провалы на редких сценариях. Релиз проходит, только если новая версия не хуже предыдущей на эталонной выборке.

Что с приватностью: пользователь может отказаться от обработки?

Да. Разрешения запрашиваются явно и по назначению, а обработка чувствительных полей выключается настройкой без потери остальной функциональности. Модель, работающая на устройстве, физически не может отправить пользовательские данные наружу — это архитектурная гарантия, а не обещание.

Как функция работает без сети?

Модель поставляется внутри приложения, поэтому базовые сценарии доступны офлайн. При потере связи ответы уходят в очередь и досылаются при восстановлении канала, а пока соединения нет — работает упрощённая логика. Пользователь видит понятный статус, а не зависший экран.

Насколько это нагружает устройство и что при обновлении модели?

Нагрузку мы измеряем на слабых устройствах: время отклика, расход батареи и нагрев при длительной работе. Тяжёлые сценарии выносим в облако, оставляя на устройстве лёгкую ветку. Обновление модели версионируется, раскатывается поэтапно и откатывается на предыдущую версию без выпуска нового приложения.

Обсудим задачу: с чего начнём и что нужно с вашей стороны

Чтобы оценка проекта опиралась на факты, а не на догадки, нам нужен короткий набор вводных. Вот что стоит подготовить с вашей стороны и в каком порядке пойдут первые шаги.

• Сценарии, которые нужно закрыть: где именно в приложении ждёте эффект — распознавание, подсказки, поиск по своим данным, генерация текста.
• Ограничения устройств и сети: какие модели телефонов в приоритете, нужна ли работа без интернета, есть ли требования к расходу батареи.
• Данные: что уже накоплено, в каком виде, есть ли разметка и кто отвечает за права на их использование.
• Метрики успеха: доля корректных ответов, время отклика, сколько ручных операций должно уйти.
• Текущий стек и доступы: мобильная платформа, серверная часть, тестовые сборки и учётные записи для проверки.
• Команда с вашей стороны: кто решает по продукту и кто принимает результаты этапов.

Из этого собираем схему решения: что считаем на устройстве, что отдаём в облако, как устроены обновление модели и откат к прежней версии. Затем — оценка проекта по этапам и план внедрения с точками приёмки, чтобы результат был виден на каждом шаге, а не только в конце. Опишите задачу — вернёмся с оценкой и планом.

Распределение работ по этапам:

Порядок и длительность этапов уточняются после разбора задачи: у части проектов подготовка данных занимает больше времени, чем сама сборка решения.