Вернуться к блогу
Hola, Amigos! На связи команда Amiga. В этой статье разберем, как добавить ИИ в мобильное приложение: какие AI-функции полезны бизнесу, как выбрать между облачным API, RAG, моделью на устройстве и собственной ML-моделью, из каких этапов состоит интеграция и что влияет на стоимость внедрения ИИ.
Мобильные приложения с искусственным интеллектом умеют ускорять поиск, распознавать объекты, работать с голосом, документами и рекомендациями. Но проект начинается не с выбора модели, а с одного пользовательского сценария, данных и измеримого результата. Покажем, как провести аудит готового приложения, собрать прототип, проверить безопасность и экономику, а также разберем реальные кейсы Amiga.
ИИ в mobile – не обязательно чат на главном экране. Он может работать внутри обычного сценария: понять запрос, распознать объект в камере, сократить документ или подобрать релевантный товар. Пользователю не нужно знать, какая модель стоит внутри. Ему важно, чтобы задача решалась быстро и понятно.
Чаще всего бизнес рассматривает такие сценарии:
Если нужен более широкий обзор технологий и бизнес-сценариев, они собраны в статье об ИИ в мобильных и веб-приложениях. Здесь фокус уже: как превратить выбранный сценарий в часть работающего продукта.
Где ИИ полезен в мобильном приложении
Архитектурно «добавить ИИ» можно по-разному. Одна функция обращается к готовому облачному API. Другая ищет ответ в базе знаний компании. Третья распознает кадр прямо на смартфоне. Поэтому оценивать нужно не абстрактный AI-модуль, а конкретную схему.
Это базовый вариант для текста, голоса, классификации или распознавания, когда подходящая модель уже существует. Мобильное приложение не должно хранить секретный ключ поставщика в клиентском коде: запрос обычно идет через backend продукта. Там можно проверить права доступа, ограничить частоту запросов, убрать лишние данные и собрать метрики.
Плюс такой схемы – быстрый старт без обучения модели с нуля. Минус – зависимость от внешнего сервиса, интернета, его тарифов и ограничений. Это подходит для пилота и многих серийных сценариев, если ограничения по данным и задержке заранее понятны.
Если ассистент должен отвечать по каталогу, регламентам или документам бизнеса, одной модели мало. Нужен контур, который найдет подходящие фрагменты, передаст их модели и вернет ответ со ссылкой на источник. Такую схему часто называют RAG. Она не делает ответы безошибочными, но помогает ограничить контекст проверяемыми материалами.
Большие языковые модели работают с текстом и естественным языком. Если нужно разобраться в терминах до обсуждения архитектуры, начните с отдельного разбора «Что такое LLM». Для оценки проекта важно другое: какие документы можно использовать, как часто они обновляются и как проверять ответ.
Часть ML-задач можно выполнять прямо на смартфоне. Это полезно, когда функция должна работать без сети, быстро обрабатывать поток с камеры или не отправлять исходные данные на внешний сервер. Но модель и связанные с ней файлы должны укладываться в ограничения устройства — по объему встроенного хранилища и оперативной памяти, расходу батареи и производительности. Размер модели и кэша важно контролировать, чтобы приложение не занимало слишком много места даже на смартфонах с небольшим объемом свободной памяти.
Обработка на устройстве снижает зависимость от сети и не создает тариф за каждый удаленный вызов. Зато может увеличить срок интеграции и объем тестирования. На практике выбор часто зависит не от «моды на on-device», а от целевых устройств, требуемой скорости и правил работы с данными.
Такой путь нужен, когда готовый сервис не решает узкую задачу с нужным качеством. К мобильной разработке добавляются сбор и разметка данных, эксперименты, обучение, оценка качества, версионирование модели и мониторинг после релиза. Самое дорогое здесь нередко не обучение как таковое, а пригодные данные и повторяемая проверка результата.
Выбирать этот вариант только ради слова «собственная» не стоит. Если готовое API закрывает задачу, дает приемлемую экономику и проходит по требованиям к данным, это зрелое решение. Своя модель оправдана, когда без нее нельзя получить нужное качество, скорость или контроль.
Да, но начинать нужно с аудита. В готовом продукте на оценку влияет не только AI-сценарий, но и состояние текущей системы. Если у приложения нет стабильного API, права доступа размыты, а данные хранятся в нескольких несогласованных форматах, модель не скроет эту проблему. Наоборот, она станет еще одним потребителем нестабильной архитектуры.
До оценки команда проверяет:
После аудита становится понятно, можно ли добавить функцию отдельным модулем или сначала придется доработать backend, сбор событий или доступ к данным. Для нового продукта эти вопросы закладываются в аналитику и архитектуру. Весь путь от идеи до публикации показан в гайде о том, как создать мобильное приложение в 2026 году.
В проекте с ИИ нельзя сначала собрать функцию, а потом решить, как понять, хорошо ли она работает. Критерии нужны до первого прототипа. Для поиска это может быть доля успешных запросов. Для распознавания – точность на типовых и сложных примерах. Для ассистента – доля ответов с подходящим источником и частота опасных ошибок.
Разработка приложений с искусственным интеллектом отличается от обычной мобильной разработки дополнительным циклом проверки данных и качества модели. Поэтому прототип, пилот и мониторинг после релиза здесь обязательны.
Как AI-функция проходит путь до релиза
Сильный бриф на AI-функцию не начинается с названия модели. Он начинается с описания работы, которую сейчас делает пользователь или сотрудник. Если подрядчик сразу продает конкретную нейросеть без вопросов о сценарии, данных и цене ошибки, оценка пока стоит на слабом фундаменте.
До разговора о сроке и бюджете подготовьте семь ответов:
Универсальной цены у интеграции ИИ нет. Один проект подключает готовую модель к одному сценарию. Другому нужны база знаний, сложные права доступа и интеграция с CRM. Третьему – сбор данных, своя ML-модель и оптимизация под разные телефоны. Сравнивать их по одной ставке бесполезно.
Бюджет состоит из двух частей:
На стоимость создания сильнее всего влияют состояние исходного приложения, готовность данных, число интеграций, выбор между готовой и своей моделью, число платформ и устройств, а также цена ошибки. Чем выше риск, тем больше проверок, защитных сценариев и ручного контроля попадает в оценку. И это не бюрократия, а стоимость управляемого результата.
Если нужен ориентир для нового продукта целиком, Amiga публикует такие диапазоны: прототип – 300–900 тыс. руб., MVP – 1,5–3,5 млн руб., приложение среднего уровня – 4–8 млн руб., сложная платформа – 10–15 млн руб. и выше. Это ориентиры для всего мобильного продукта, а не отдельный прайс на AI-функцию. Подробнее диапазоны и состав работ разобраны в статье о стоимости мобильного приложения.
Для оценки AI-модуля к этим блокам нужно добавить пять величин: объем подготовки данных, интеграцию с моделью, контур безопасности, дополнительный QA и месячную эксплуатацию. Точная смета появляется после аудита и технического пилота, когда видно не только идею, но и качество, скорость и цену одного реального сценария.
Даже если тариф поставщика известен, бюджет нельзя считать по одному «среднему запросу». Короткая классификация текста и диалог с длинной историей расходуют ресурсы по-разному. Обработка изображений или аудио тоже имеет другую экономику. Поэтому перед оценкой нужен образец реальной нагрузки.
Базовая формула выглядит так:
месячная эксплуатация = вызовы модели + backend и хранение + поиск или векторная база + мониторинг + поддержка.
Для пилота берут ожидаемое число активных пользователей, умножают на среднее число целевых действий и стоимость одного сценария. Затем добавляют пики, повторы, ошибки, тестовый трафик и резерв. После пилота прогноз заменяют фактическими данными. Так тариф поставщика превращается в управляемую экономику, а не в сюрприз после релиза.
Соблазн отправить в модель все, чтобы она «лучше поняла контекст», понятен. Но так в запрос легко попадают персональные данные, внутренние документы и поля, без которых модель может решить задачу. Поэтому перед интеграцией нужен аудит потока данных: что уходит с устройства, куда, на какой срок и кто имеет доступ.
Минимальный контур включает:
Отдельно нужно зафиксировать, что ИИ имеет право делать. Модель может подсказать товар, но не обязана сама оформлять заказ. Может подготовить черновик ответа, но не выносить решение в медицинском или финансовом сценарии. Чем выше цена ошибки, тем раньше в цепочке должен появиться человек.
На схеме все выглядит аккуратно: камера, модель, ответ. На практике к этому добавляются целевые устройства, освещение, качество кадра, задержка, интеграция с Flutter и нативными частями. Два опубликованных кейса показывают, почему AI-функция – это продуктовая и инженерная работа, а не только вызов API.
В приложении с ML-интеграцией пользователь фотографирует детали конструктора, а система считает их и предлагает, что можно собрать. Amiga разработала mobile-часть на Flutter и интегрировала ML-модель. На Android взаимодействие с TensorFlow было реализовано через нативную часть на Kotlin и Flutter Channels. Приложение с нуля было создано за четыре месяца.
Ценность кейса для оценки не в сроке самом по себе. Он показывает состав работ: mobile-интерфейс, сценарий камеры, нейросеть, API, нативная интеграция, анимации и тестирование. Одна фраза «распознать детали» скрывает целую цепочку продуктовых и технических решений.
В кейсе «Магазин на диване» пользователь наводит камеру на экран. Система определяет фрагмент видео и показывает товары из кадра. Для этого команда собрала пайплайн из детекции монитора, преобразования кадра в численный вектор, поиска совпадения и подбора товаров.
На старте обработка одного кадра на iOS занимала шесть секунд. После оптимизации в опубликованном кейсе указаны 100 миллисекунд. За два месяца Amiga и коллеги из AGIMA AI создали MVP на Flutter с ML-моделью. Здесь цена функции напрямую связана с мобильной производительностью: работающая, но медленная демонстрация не стала бы готовым пользовательским сценарием.
Больше проектов с описанием задач, хода работ и результатов есть в разделе кейсов Amiga. А если нужна команда, которая свяжет мобильный интерфейс, backend, интеграции, QA и публикацию, эти работы собраны в услуге мобильной разработки.
Технология не окупится только потому, что сценарий выглядит эффектно на демо. Если пользователь не понимает, зачем нажимать на AI-кнопку, стало медленнее или ответ приходится часто переделывать, новая функция удлинила путь. Еще хуже, если команда видит ошибки, но не может откатить сценарий к обычной логике.
Красные флаги до старта:
Иногда лучшее решение пилота – отказаться от ИИ и сделать понятный алгоритм. Это не провал, а экономия бюджета до дорогой разработки. Пилот нужен именно для того, чтобы такой вывод обошелся дешевле полного релиза.
Добавить ИИ в мобильное приложение можно без полной пересборки продукта, если его архитектура, API и данные к этому готовы. Но процесс все равно начинается не с API-ключа, а с одного сценария и измеримого результата. Без них команда может быстро собрать демо, но не сможет обосновать релиз.
Зрелый план состоит из пяти шагов: выбрать задачу, проверить данные, собрать технический пилот, провести ограниченный запуск и только затем масштабировать. Смету нужно считать в двух горизонтах: разовое создание и ежемесячная эксплуатация. Иначе дешевый пилот может превратиться в дорогую серийную функцию.
Мы в Amiga проектируем и развиваем мобильные продукты: связываем пользовательский сценарий, Flutter- и нативную разработку, backend, ML-интеграции, QA и публикацию. В проектах с распознаванием деталей конструктора и поиском товаров в видеопотоке наша задача была не просто подключить модель, а сделать ее быстрой, стабильной и понятной пользователю частью приложения.
Если у вас уже есть приложение, для первичной оценки подготовьте схему архитектуры, описание API, примеры данных, целевые устройства и один приоритетный сценарий. Если продукт пока на уровне идеи, достаточно описать задачу бизнеса, пользователя и результат, который хотите измерить. Команда мобильной разработки Amiga поможет разложить идею на пилот, mobile-часть, backend, данные, QA и эксплуатацию, чтобы оценка показывала реальный объем работ.
Да. Если архитектура, backend и API готовы, AI-функцию можно добавить отдельным модулем. Если данные неполны, а интеграции нестабильны, сначала придется доработать фундамент.
Не обязательно. Для текста, голоса, распознавания и классификации часто достаточно готовой модели или API. Своя модель нужна, если готовые сервисы не дают нужного качества, скорости, контроля или режима работы.
Облако обычно дает быстрый старт и более тяжелые модели, но зависит от интернета и создает расход на вызовы. On-device может работать офлайн и без оплаты за каждый удаленный вызов, но ограничен ресурсами телефона. Выбор зависит от данных, задержки, парка устройств и требуемого качества.
Да, если подходящая модель запускается на устройстве. Так работают некоторые функции распознавания, классификации и обработки текста. Нужно заранее проверить модель на целевых iOS- и Android-устройствах.
От сценария, готовности данных, состояния мобильной и backend-частей, числа интеграций, способа размещения модели, цены ошибки и объема тестирования. После релиза добавляются вызовы модели, инфраструктура, хранение, мониторинг и поддержка.
Без аудита и выбора сценария срок называть некорректно. Подключение готового API к одному сценарию и создание своей ML-модели с нуля – разные по масштабу задачи. Рабочий срок появляется после прототипа и декомпозиции работ.
