Продуктовые команды приходят к ИИ иначе, чем поддержка. В поддержке ИИ стоит сбоку: есть поток обращений, его частично закрывает ассистент. В продукте ИИ находится внутри — пользователь трогает его каждый день, наравне с кнопкой «Создать» и лентой. Если ассистент в поддержке ошибся, клиент раздражённо позовёт оператора. Если ошиблась ИИ-функция в приложении, пользователь напишет отзыв в сторе, и этот отзыв прочитают тысячи.
Отсюда весь список отличий: другая экономика, другие требования к качеству, другой набор рисков и совсем другой процесс запуска — с ревью в App Store и Google Play, с политикой приватности и с возрастным рейтингом.
Разберём по шагам: какие ИИ-функции в мобильном продукте реально окупаются, как устроена архитектура, почему стоимость на пользователя надо считать до запуска фичи, что спрашивают сторы и где проходит граница ответственности системы.
Почему «сделаем на коленке» здесь не работает
Соблазн понятный. Есть API модели, есть мобильный разработчик, есть неделя спринта. Прикручиваем поле ввода, отправляем запрос, показываем ответ. Демо на планёрке выглядит впечатляюще.
Дальше начинается продакшн, и вылезает четыре вещи подряд.
Галлюцинации на реальных вопросах. В демо задают три подготовленных вопроса. В проде спрашивают про функцию, которой в продукте нет, — и модель уверенно рассказывает, как ей пользоваться. Пользователь ищет кнопку, не находит, пишет в поддержку и в отзывы.
Счёт за модель. В поддержке нагрузка ограничена числом обращений — это тысячи в месяц. В продукте нагрузка растёт линейно с числом активных пользователей: если фича полезная, ей пользуются каждый день, и десятки тысяч DAU превращаются в сотни тысяч вызовов. Счёт приходит через месяц и вызывает нездоровые эмоции.
Ревью в сторе. Фичу заворачивают: не раскрыто, что контент генерируется ИИ; нет модерации пользовательского ввода; возрастной рейтинг не соответствует тому, что теперь может показать приложение. Релиз сдвигается на две недели.
Приватность. Юрист спрашивает, что именно уходит в модель, где это хранится, есть ли согласие пользователя и что написано в политике конфиденциальности. Ответов нет, потому что этот вопрос не задавали на этапе проектирования.
Какие ИИ-функции в приложении окупаются
Не всякая ИИ-фича стоит своих денег. Практика такая: окупаются те, что снимают трение в уже существующем сценарии, а не те, что добавляют новый.
| Функция | Что реально даёт | Сложность | Когда окупается |
|---|---|---|---|
| Умный поиск по контенту | Находит по смыслу, а не по совпадению слов | Средняя | Много контента, поиск используется часто |
| Ассистент внутри приложения | Отвечает «как сделать X» без ухода в справку | Средняя | Продукт со сложным интерфейсом |
| Помощь в онбординге | Ведёт нового пользователя по первому сценарию | Низкая | Высокий отвал на первых шагах |
| Персональные подсказки | Предлагает следующее действие по контексту | Высокая | Есть история действий пользователя |
| Саммари длинного контента | Сжимает переписку, документ, отчёт | Низкая | Пользователь читает много текста |
| Генерация черновиков | Заполняет заготовку вместо пустого поля | Средняя | Пустое поле — точка отвала |
| Разбор фото и документов | Извлекает данные вместо ручного ввода | Высокая | Ручной ввод — основное трение |
Самая недооценённая позиция в этом списке — онбординг. Она же самая дешёвая в разработке. Новый пользователь открывает приложение, не понимает, с чего начать, и уходит. Классическое решение — тур по интерфейсу со всплывающими подсказками, который все пролистывают. ИИ-помощник в онбординге работает иначе: спрашивает, зачем пользователь пришёл, и ведёт его к первому полезному результату по его сценарию, а не по общему.
Самая переоценённая — персональные подсказки. Звучит красиво, требует хорошей истории действий, качественной разметки и постоянной калибровки. Без этого превращается в раздражающие уведомления, которые отключают в первую неделю.
функций из таблицы выше запускаются без ML-инженера в штате
растёт стоимость вызовов модели вместе с числом активных пользователей
момент, когда надо посчитать стоимость на пользователя
Архитектура: что на клиенте, что на сервере
Первая развилка, которую команды проходят неправильно, — попытка ходить в модель прямо из приложения. Так делать нельзя, и причин несколько.
Ключ провайдера в приложении — это ключ, извлекаемый из бинарника. Его найдут, и счёт вы получите чужой. Логика промпта в клиенте — это логика, которую нельзя починить без релиза и прохождения ревью. Лимиты на стороне клиента — это лимиты, которые обходятся подменой запроса.
Рабочая схема выглядит так:
Мобильное приложение
│ запрос пользователя + токен сессии
▼
Ваш backend (шлюз ИИ-функций)
├─ аутентификация и лимиты по пользователю
├─ кэш ответов ──────────→ повторяющиеся запросы
├─ поиск по контенту (RAG) → база знаний продукта
├─ маршрутизация модели ──→ дешёвая / дорогая по задаче
├─ модерация ввода и вывода
└─ логи, метрики, стоимость на пользователя
│
▼ ответ + источники + флаг уверенности
Мобильное приложениеНа клиенте остаётся интерфейс: поле ввода, состояние загрузки, отображение источника ответа, кнопка «сообщить об ошибке», механика отката. Плюс лёгкая локальная логика — например, не отправлять запрос, если он короче трёх символов.
На сервере живёт всё остальное: ключи, промпты, выбор модели, кэш, лимиты, модерация, логирование. Это даёт главное преимущество — вы правите поведение ИИ-функции без релиза. Промпт оказался слишком многословным, модель начала выдумывать, надо ужесточить рамки — деплой бэкенда, а не двухнедельное ожидание ревью.
Отдельно про офлайн и задержки. Мобильный пользователь бывает в метро. ИИ-функция обязана деградировать корректно: показывать понятное состояние, не блокировать остальной интерфейс, не терять введённый текст. Ответ, который идёт четыре секунды, воспринимается как зависание, если не показать стриминг по мере генерации.
Экономика вызовов: считать до, а не после
Это главный сюжет и главное отличие продуктовых ИИ-фич от сервисных.
В поддержке объём ограничен потоком обращений и почти не растёт от роста базы. В продукте всё наоборот: чем успешнее фича, тем дороже она обходится. Успех — это счёт. Поэтому стоимость на активного пользователя считается до запуска, на этапе проектирования, а не по факту первого счёта.
Модельный расчёт. Возьмём приложение с 30 000 активных пользователей в месяц. Допустим, ИИ-функцией пользуется 40% из них — 12 000 человек. Каждый делает в среднем 8 обращений в месяц. Итого 96 000 вызовов.
Шаг 1. Средний размер вызова. Запрос пользователя короткий, но к нему добавляется контекст: найденные фрагменты базы знаний, системный промпт, история диалога. Реалистично — около 2 500 входных токенов и 400 выходных на вызов.
Шаг 2. Кэш. Значительная часть вопросов повторяется: «как экспортировать», «как сменить тариф», «что означает этот статус». В продуктовых ассистентах доля повторяющихся запросов обычно высокая. Заложим осторожно: кэш снимает 35% вызовов. Остаётся около 62 000 платных вызовов.
Шаг 3. Маршрутизация модели. Не каждой задаче нужна дорогая модель. Классификация запроса, короткое саммари, подсказка в онбординге — это работа для лёгкой модели. Сложный многошаговый ответ по контексту продукта — для дорогой. При разумной маршрутизации 70% вызовов уходит на дешёвую модель.
Шаг 4. Стоимость на пользователя. Смысл всей арифметики — получить одну цифру: сколько ИИ-функция стоит в расчёте на одного активного пользователя в месяц. Дальше она сравнивается с вашим ARPU. Если ИИ-функция съедает заметную долю выручки с пользователя, её либо перепроектируют, либо выносят в платный тариф, либо ограничивают лимитом.
Три рычага, которые реально снижают счёт.
Кэширование. Работает на двух уровнях. Точный кэш — одинаковый запрос отдаётся из хранилища. Семантический — близкие по смыслу вопросы («как отменить подписку» и «где отключить оплату») схлопываются в один ответ. Второй даёт больший эффект, но требует аккуратности: слишком широкий порог схожести начнёт отдавать не тот ответ.
Лимиты. Обязательны, и не только ради денег. Лимит на пользователя в сутки защищает от автоматизированного злоупотребления и от сценария, когда один энтузиаст генерирует счёт за сотню обычных. Лимит должен быть виден в интерфейсе заранее, а не всплывать сообщением «вы исчерпали квоту» посреди работы.
Выбор модели под задачу. Самая недооценённая мера. Команды по инерции ставят топовую модель на всё, включая задачи вида «определи, к какой категории относится вопрос». Разделение потока по сложности даёт кратную экономию без заметной потери качества — при условии, что вы измеряете качество, а не полагаетесь на ощущение.
Требования сторов: где заворачивают релизы
Это часть, о которой продуктовые команды вспоминают на этапе сабмита, а надо — на этапе проектирования. И App Store, и Google Play предъявляют к приложениям с генеративным ИИ отдельные требования. Формулировки меняются, но суть держится вокруг четырёх пунктов.
Раскрытие того, что контент сгенерирован ИИ. Пользователь должен понимать, что перед ним ответ модели, а не выверенная справка и не сообщение сотрудника. Практически это означает пометку у ответа, оговорку в интерфейсе и упоминание в описании приложения. Скрытая ИИ-функция, которая выдаёт себя за человека, — прямой путь к отклонению.
Модерация пользовательского ввода. Если приложение принимает свободный текст и отдаёт его в модель, ревьюер проверит, что произойдёт при вводе заведомо неприемлемого запроса. Ответ «модель сама откажется» ревью не устраивает: нужна ваша фильтрация на входе и на выходе, плюс механизм жалобы на сгенерированный контент.
Возрастной рейтинг. Приложение, которое умеет генерировать произвольный текст, отвечает на анкету рейтинга иначе, чем приложение со статичным контентом. Занижение рейтинга — частая причина отклонения. Рейтинг пересматривается при добавлении ИИ-функции, даже если сам продукт не менялся.
Прозрачность сбора данных. Карточка приложения содержит декларацию о данных. Если запросы пользователя уходят на сторонний сервис, это отражается в декларации и в политике конфиденциальности. Расхождение между тем, что заявлено, и тем, что реально уходит по сети, ревьюер способен обнаружить.
| Требование стора | Что делаем в продукте | Кто отвечает |
|---|---|---|
| Пометка ИИ-контента | Бейдж у ответа, оговорка в интерфейсе, текст в описании | Дизайн + мобильная команда |
| Модерация ввода | Фильтр на бэкенде до вызова модели | Бэкенд |
| Модерация вывода | Проверка ответа перед показом | Бэкенд |
| Жалоба на контент | Кнопка «сообщить о проблеме» у каждого ответа | Мобильная команда |
| Возрастной рейтинг | Пересмотр анкеты под новую функциональность | Владелец аккаунта в сторе |
| Декларация данных | Обновление карточки и политики | Продукт + юрист |
| Работа без интернета | Корректная деградация вместо пустого экрана | Мобильная команда |
Практический вывод: закладывайте на ревью запас. Первый сабмит ИИ-функции проходит с замечаниями чаще, чем обычный релиз, и полезно иметь готовые ответы ревьюеру — как именно работает модерация, куда уходят данные, где пользователь видит пометку об ИИ.
Приватность: что уходит в модель, а что нет
Второй вопрос, который дешевле решить на проектировании, чем на юридической проверке.
Разделите данные на три корзины. Первая — то, что уходит в модель всегда: сам запрос пользователя и релевантные фрагменты вашей публичной базы знаний. Вторая — то, что уходит только с явного согласия и только при необходимости: содержимое документов пользователя, история его действий, персональные данные. Третья — то, что не уходит никогда: платёжные данные, пароли, документы, удостоверяющие личность, любые категории чувствительных данных, которые вы не готовы защищать по соответствующему регламенту.
Минимизация вместо анонимизации. Соблазн отправить весь контекст «на всякий случай» велик: качество ответа растёт. Но правильный порядок обратный — сначала определите минимальный набор данных, при котором функция работает, и отправляйте только его. Обезличивание помогает, но не заменяет минимизацию: по совокупности признаков анонимизированные данные часто восстанавливаются.
Согласие получают в контексте. Не одним чекбоксом при регистрации, а в момент, когда функция впервые используется, с понятным объяснением: какие данные уходят, зачем и что будет, если отказаться. Отказ должен оставлять продукт работоспособным — ИИ-функция отключается, остальное живёт.
В политике конфиденциальности появляется отдельный раздел. В нём фиксируется: какие данные обрабатываются ИИ-функцией, передаются ли они третьим сторонам, хранятся ли запросы и сколько, используются ли для обучения моделей, как пользователь может удалить свою историю. Последний пункт особенно важен: если вы храните диалоги, вы обязаны уметь их удалять по запросу.
Логи — отдельная зона риска. Команда включает подробное логирование, чтобы отлаживать качество ответов, и через месяц в логах лежат тысячи пользовательских запросов с персональными данными, доступные всей команде разработки. Логи ИИ-функций требуют той же дисциплины, что и продуктовая база: ограниченный доступ, срок хранения, обезличивание.
Границы: что система не делает
Честность про ограничения здесь не вежливость, а часть проектирования интерфейса.
| Что берём на себя | Что остаётся продуктовой команде |
|---|---|
| Архитектура шлюза, промпты, маршрутизация моделей | Решение, какие функции вообще нужны продукту |
| Поиск по контенту и база знаний продукта | Содержание базы: что считается правильным ответом |
| Кэш, лимиты, учёт стоимости на пользователя | Тарифная политика и место ИИ-функций в ней |
| Модерация ввода и вывода | Определение, что для вашего продукта неприемлемо |
| Метрики качества и панель разбора ответов | Продуктовые решения по результатам метрик |
| Подготовка к ревью стора со стороны техники | Аккаунт в сторе, анкеты, коммуникация с ревьюером |
| Документация и передача кода | Развитие функции после запуска |
Два пункта стоит проговорить отдельно.
Система не заменяет продуктовые решения. ИИ не определит за вас, какая функция нужна пользователям, каким должен быть тон продукта и что считать успехом. Он исполняет решение, а не принимает его. Команды, которые ждут от ИИ-внедрения ответа на вопрос «куда развивать продукт», получают разочарование.
Система не гарантирует отсутствие ошибок в ответах. Это не оговорка мелким шрифтом, а факт, вокруг которого строится интерфейс. Если модель может ошибиться — а она может, — интерфейс обязан это учитывать:
- показывать источник — не просто ответ, а ссылку на раздел справки или элемент продукта, откуда он взялся;
- давать откат — любое действие, которое ИИ совершает или предлагает, отменяется в один шаг;
- не выдавать действие за факт — «похоже, вам нужен раздел X» читается иначе, чем «раздел X»;
- признавать незнание — «не нашёл ответа, вот справка / вот поддержка» лучше правдоподобной выдумки;
- давать канал жалобы — кнопка у каждого ответа, а жалобы попадают в разбор, а не в пустоту.
Интерфейс, который притворяется всезнающим, ломается на первой же ошибке и забирает с собой доверие ко всему продукту. Интерфейс, который честно показывает степень уверенности, переживает ошибку без потерь.
Метрики: продуктовые, а не технические
Соблазн мерить ИИ-функцию техническими метриками — задержка, доля успешных вызовов, оценка ответа — велик, потому что они легко снимаются. Но решение о судьбе фичи принимается по продуктовым.
| Метрика | Что показывает | Тревожный сигнал |
|---|---|---|
| Activation: доля дошедших до первого результата | Работает ли ИИ в онбординге | Не растёт после запуска помощника |
| Retention D7 / D30 у пользователей фичи | Влияние на удержание | Не отличается от контрольной группы |
| Доля пользователей, вернувшихся к фиче | Реальная полезность | Высокий первый заход, низкий повтор |
| Обращений в поддержку по теме фичи | Понятность интерфейса | Растёт — люди не понимают, что происходит |
| Доля жалоб на ответ | Качество генерации | Больше нескольких процентов — разбор |
| Доля ответов «не знаю» | Слепые зоны базы знаний | Растёт — база отстала от релизов |
| Стоимость на активного пользователя | Экономика фичи | Растёт быстрее выручки с пользователя |
| Доля попаданий в кэш | Эффективность оптимизации | Падает — вопросы изменились |
Главное правило: сравнивайте с контрольной группой. Retention вырос на 4% — это заслуга ИИ-функции или сезонности, нового онбординга и трёх других релизов того же месяца? Без контрольной группы ответа нет, а есть только удобная интерпретация. Поэтому раскатка идёт через флаг на часть аудитории, а не на всех сразу.
Второе правило: стоимость на пользователя — такая же продуктовая метрика, как retention, и смотреть её надо на том же дашборде. Иначе она всплывает раз в месяц вместе со счётом и вызывает панические решения.
Третье: доля повторного использования важнее первого захода. Новую фичу открывают из любопытства почти все. Возвращаются только те, кому она помогла. Разрыв между этими двумя цифрами — самая честная оценка полезности.
Как это внедряется по этапам
- 3–5 дней
Продуктовый аудит и выбор функции
Смотрим воронку, точки отвала, обращения в поддержку и структуру контента продукта. Выбираем одну функцию с наибольшим отношением эффекта к сложности — обычно это поиск или помощь в онбординге. Считаем предварительную экономику вызовов на ваших цифрах DAU.
- 1–2 недели
Прототип на бэкенде
Собираем шлюз: поиск по контенту продукта, промпты, маршрутизацию моделей, модерацию, лимиты и учёт стоимости. Прогоняем на реальных запросах из поддержки и логов поиска. На этом этапе фичи в приложении ещё нет — проверяется качество ответов, а не интерфейс.
- 1 неделя
Интеграция в приложение
Подключаем клиент: интерфейс с показом источника, стримингом ответа, состояниями офлайна и ошибки, кнопкой жалобы. Закрываем требования сторов — пометка ИИ-контента, обновление политики и декларации данных, пересмотр возрастного рейтинга.
- 2 недели
Раскатка по флагу и калибровка
Запускаем на 10–20% аудитории с контрольной группой. Разбираем логи ответов, добиваем слепые зоны базы знаний, настраиваем пороги кэша и лимиты по фактической нагрузке. Смотрим activation и стоимость на пользователя на реальных данных.
- далее
Полный запуск и передача
Раскатываем на всю аудиторию, передаём код, документацию, дашборд качества и стоимости. Дальше функция развивается вашей командой — база знаний обновляется вместе с релизами продукта.
От старта до фичи в проде — примерно полтора месяца, из которых почти половина уходит на калибровку и раскатку. Сократить можно, но за счёт именно тех этапов, которые защищают от плохих отзывов.
Риски и что с ними делать
«Модель начнёт выдумывать функции продукта». Главный риск, и он снимается архитектурно: ответ строится только по вашей базе знаний и данным продукта, при низкой уверенности — честное «не нашёл» со ссылкой на справку. Плюс дашборд, где видно, где система отвечала неуверенно.
«База знаний отстанет от релизов». Отстанет обязательно, если не встроить обновление в процесс релиза. Продукт меняется каждые две недели, ответы ассистента — нет, и через квартал он рассказывает про интерфейс прошлой версии. Лечится регламентом: изменение продукта — обновление базы, в том же тикете.
«Счёт вырастет вместе с ростом продукта». Поэтому стоимость на пользователя выводится на дашборд с первого дня, а лимиты и кэш ставятся до запуска, а не после первого неприятного счёта.
«Фичу завернут в сторе». Снимается подготовкой: пометки, модерация, рейтинг и декларация данных делаются до сабмита, а не в ответ на отклонение. Плюс заранее подготовленное описание работы функции для ревьюера.
«Пользователи не станут этим пользоваться». Реальный и частый риск. Поэтому раскатка идёт по флагу с контрольной группой: за две недели видно и долю повторного использования, и влияние на activation. Решение о полном запуске принимается на цифрах.
«Мы попадём в зависимость от подрядчика». Код, промпты, документация и дашборды передаются вам. Архитектура строится так, чтобы модель можно было заменить без переписывания продукта: слой генерации отделён от логики.
Частые вопросы
Нужен ли нам ML-инженер в штате? Для функций из верхней части таблицы — нет. Умный поиск, ассистент по продукту, помощь в онбординге, саммари строятся на готовых моделях и инженерии вокруг них: поиск по контенту, промпты, кэш, маршрутизация, метрики. Это работа бэкенд-разработчика, понимающего специфику. ML-инженер нужен там, где вы обучаете или дообучаете собственную модель, — а это существенно более поздняя стадия, к которой большинство продуктов не приходит и не должно.
Можно ли обойтись без своего бэкенда и ходить в модель из приложения? Технически можно, практически — не стоит. Ключ в бинарнике извлекается, промпт в клиенте не правится без релиза, лимиты обходятся, а логика ИИ-функции оказывается зашита в версию, которая полгода живёт у части пользователей. Шлюз на бэкенде — это возможность чинить поведение без прохождения ревью.
Как понять, что ИИ-функция окупилась? Через сравнение с контрольной группой по двум осям: продуктовой (activation, retention, конверсия в платный тариф) и денежной (стоимость на активного пользователя против прироста выручки). Если фича не двигает ни одну продуктовую метрику относительно контроля — она стоит своих денег зря, и лучше узнать об этом на 15% аудитории, чем на 100%.
Что делать, если у продукта нет нормальной документации? Обычная ситуация. Источником базы знаний становятся: существующая справка какой есть, тексты интерфейса, обращения в поддержку, ответы команды в чатах пользователей. Практика показывает, что материала обычно достаточно, он просто не собран. Побочный эффект аудита — вы получаете нормальную структурированную справку, которой не было.
Насколько заметна задержка ответа для пользователя? Заметна, если не проектировать её. Ответ модели идёт секунды, и без стриминга это читается как зависание. Рабочие приёмы: стриминг по мере генерации, мгновенная реакция интерфейса на нажатие, предзагрузка вероятного контекста и лёгкая модель на быстрых задачах. Цель — чтобы пользователь видел движение с первой секунды.
Можно ли начать с одной небольшой функции? Нужно. Заход «встроим ИИ во весь продукт» даёт полгода разработки и неопределённый результат. Заход «одна функция, часть аудитории, контрольная группа, две недели наблюдения» даёт данные, на которых принимается следующее решение. Инфраструктура при этом строится общая: шлюз, кэш, метрики и модерация пригодятся для второй и третьей функции.
Что происходит, когда выходит новая модель? Меняется слой генерации, остальное остаётся. Именно поэтому маршрутизация моделей выносится в конфигурацию бэкенда: переключение делается без релиза приложения и проверяется на подмножестве трафика. Обычно новая модель означает либо лучшее качество за те же деньги, либо то же качество дешевле — и то и другое стоит проверять регулярно.
Что понадобится от вас
Чтобы оценка была расчётом, а не гаданием:
- цифры продукта: DAU/MAU, воронка активации, точки отвала на первых сессиях;
- материалы для базы знаний: справка, тексты интерфейса, обращения в поддержку;
- понимание, где в продукте пользователи чаще всего застревают;
- доступ к аккаунту в сторе или человек, который им управляет;
- один человек со стороны продукта, который принимает решение «правильный ответ — вот такой».
Этого достаточно, чтобы за несколько дней получить не презентацию, а две конкретные цифры: какая функция даёт наибольший эффект на вашей воронке и сколько она будет стоить в расчёте на активного пользователя.