разработка

Когда бизнесу нужен AI-ассистент в мобильном приложении

Максим Жуков
Сооснователь ecommerce-агентства KISLOROD
Максим Жуков
Магазин платит за привлечение покупателя, а тот уходит из приложения, не разобравшись в ассортименте. AI-ассистент в приложении может помочь с выбором. Вопрос для бизнеса — сколько дополнительных заказов он принесет и покроет ли их маржа расходы на внедрение и обслуживание.
На примере интернет-магазина разберем, какие задачи поручить AI-ассистенту в мобильном приложении, что потребуется от каталога и ИТ-систем и как оценить результат пилота перед дальнейшими вложениями.

Какие задачи поручать AI-ассистенту

Посмотрите, что покупатели уточняют в поддержке, после каких поисковых запросов уходят и какие товары возвращают из-за ошибки выбора. Выберите для пилота одну повторяющуюся проблему. Оцените, сколько покупателей с ней сталкивается и сколько времени сотрудники тратят на помощь. Если ошибки приводят к возвратам, посчитайте расходы на их обработку.
Ассистент пригодится, когда покупатель может описать свою задачу, но затрудняется выбрать характеристики в фильтре. Например, ищет ноутбук для монтажа видео или картридж по модели принтера. Диалог помогает уточнить требования и подобрать товары из каталога. Для повторной покупки знакомого товара достаточно кнопки в истории заказов. А если поиск не находит точный артикул, сначала нужно исправить сам поиск.
До оценки разработки проверьте, откуда ассистент возьмет сведения. Для подбора картриджа нужна проверенная таблица совместимости, для ответа о доставке — актуальный статус заказа. Если этих данных нет или сотрудники собирают их вручную из нескольких систем, включите в смету их подготовку и обновление. Иначе уже в ходе разработки придется расширять бюджет.
Подбор и сравнение товаров Walmart включил в своего ассистента Sparky, которого представил в июне 2025 года. В мобильном приложении покупатель мог уточнять характеристики, сравнивать варианты и читать сводку отзывов. Эти функции помогали разобраться в ассортименте перед заказом.
Для первой версии удобно сопоставить несколько ситуаций:

Где AI-ассистент берет сведения

Данные о товарах и заказах ассистент получает из систем магазина, к которым его подключили разработчики. Компания определяет источники для каждой задачи: где проверять совместимость, откуда запрашивать цену, по каким документам объяснять условия возврата. Рассмотрим детальнее:
  1. Характеристики и совместимость товаров — из каталога. По запросу покупателя система находит подходящие позиции и передает их данные модели. Для подбора картриджа в каталоге должна храниться связь с конкретными моделями принтеров. Если ее нет, сходство названий не подтвердит совместимость. Сначала сотрудникам магазина нужно собрать и проверить эти сведения.
  2. Инструкции и правила обслуживания — из базы знаний. Источниками могут служить руководства производителей, условия гарантии, правила доставки и возврата. Поиск находит нужные фрагменты и передает их модели вместе с вопросом. Так работает RAG. При изменении правил компания обновляет документы и поисковый индекс; переобучать модель для этого не нужно.
  3. Цены, остатки и статусы заказов — из учетных систем. Эти сведения быстро меняются. Сервер приложения запрашивает их через API — программный интерфейс соответствующей системы — и передает результат ассистенту. Перед добавлением товара в корзину условия проверяют повторно. Если цена изменилась, покупатель должен увидеть ее до подтверждения действия.
Часть сведений сообщает сам пользователь: бюджет, модель устройства, адрес доставки. Приложение также может передать контекст открытого экрана — например, идентификатор товара, о котором спрашивает покупатель. Разработчики настраивают эту передачу отдельно: расположение чата рядом с карточкой еще не дает модели доступа к ее содержимому.
До разработки составьте перечень источников для выбранного сценария. Для каждого укажите, какие данные из него получает ассистент, как часто они обновляются и кто исправляет ошибки. По этому перечню ИТ-команда оценит интеграции, а бизнес увидит, какие сведения нужно подготовить до запуска.

Как ассистент получает право действовать

Для чтения карточки и изменения заказа нужны разные разрешения. На первом этапе можно ограничиться консультацией и передачей выбранного товара в обычный интерфейс оформления. Отмена заказа, изменение адреса или возврат денег требуют отдельной разработки и проверки прав.
Связь модели с бизнес-системами обычно строят через вызов функций. Разработчик описывает доступные операции и их параметры. Модель предлагает, какую функцию вызвать, а приложение проверяет запрос и выполняет ее.
Например, если клиент хочет подобрать картридж:
  1. Приложение передает вопрос, подтвержденную модель принтера и выбранный регион.
  2. Сервер получает допустимые товары из каталога и проверяет текущие условия продажи.
  3. Ассистент объясняет различия между вариантами и показывает карточки.
  4. После выбора пользователя сервер проверяет товар еще раз и добавляет его в корзину. Интерфейс показывает подтвержденный результат операции.
Идентификатор пользователя и права на заказ сервер берет из авторизованной сессии. Номер заказа, написанный в чате, сам по себе доступа не дает. Модель также не должна самостоятельно назначать скидку: доступное предложение рассчитывает соответствующий сервис магазина.
Для операций с последствиями нужен понятный экран подтверждения. Пользователь должен видеть, какой заказ отменяется или на какой адрес меняется доставка. Разрешение связано с конкретной операцией и ее параметрами; после их изменения потребуется новое подтверждение.
Повторная отправка запроса не должна создавать второй заказ или дважды списывать бонусы. Для этого сервер распознает повтор одной операции по ее идентификатору и возвращает уже полученный результат. Это свойство называют идемпотентностью; практический разбор есть в Amazon Builders’ Library. Для мобильного приложения с нестабильной связью такая защита входит в рабочий сценарий.
Отдельная граница проходит между данными и командами. Текст отзыва, описание поставщика или загруженный документ может содержать указания для модели. Их нельзя считать разрешением обратиться к чужому заказу или изменить настройки. Доступ к данным и операциям ограничивают на сервере, а внешние тексты проверяют как недоверенные данные. Anthropic разбирает этот риск на примере внешних инструментов и их ответов.

Как выбирать модель и способ разработки

GPT, Claude, Gemini от Google, DeepSeek или GigaChat рекомендуем сравнивать на одном наборе задач магазина. Для подбора товаров интересны точность извлечения ограничений, работа с артикулами и способность запросить недостающие сведения. Для выполнения действий добавляется корректность вызовов функций. Свободная беседа в браузере этих требований не проверяет.
Тестировать нужно ту версию модели, которая будет доступна через API, с теми же источниками и ограничениями. Удобство приложения известного сервиса, в том числе Алисы, не описывает возможности будущей интеграции. Условия работы с API, обработку данных и ограничения нагрузки проверяют отдельно. Российские модели также требуют такой проверки: название поставщика не определяет архитектуру всего решения.
Разные операции могут обходиться разной вычислительной мощностью. Короткий запрос на поиск не всегда требует самой дорогой модели. Для сложного сравнения она может оказаться оправданной, если сокращает число ошибок и повторных обращений. Экономию от переключения моделей нужно сопоставлять с затратами на дополнительную логику и тестирование.
Размещение модели выбирают с учетом данных, нагрузки и возможностей команды. Внешний API снимает часть инфраструктурной работы, но добавляет зависимость от доступности и условий поставщика. До подключения компания определяет, какие сведения допустимо передавать, и проверяет условия хранения запросов и их использования поставщиком. Собственное размещение потребует вычислительных ресурсов, обновлений и эксплуатации. Цена лицензии или доступность весов, числовых параметров, — только часть этих расходов. Бесплатный пробный доступ также не описывает стоимость обслуживания реального трафика.
Готовую платформу стоит проверять на собственной задаче еще до подписания договора. Если для этого каждый раз требуется доработка поставщика, ее срок и стоимость должны попасть в оценку.
При собственной разработке команда сама выбирает архитектуру и отвечает за поддержку после релиза. Между этими вариантами есть комбинации: готовые модели и поисковые компоненты с собственной логикой интеграции. Смета должна показывать, какие части команда получает готовыми и за что будет отвечать сама.

Как встроить AI-ассистента в мобильное приложение интернет-магазина

Если покупатель открыл помощника из карточки товара, не просите его переписывать артикул в чат. При интеграции разработчики настраивают передачу данных об открытом товаре вместе с вопросом. То же касается обращений по заказу: человек выбирает его в приложении, и помощник получает нужный идентификатор.
После консультации покупателю нужно продолжить покупку. Ассистент подобрал картриджи — приложение показывает их карточки с ценами и кнопками добавления в корзину. Выбранная модификация и количество сохраняются при оформлении. Если же в ответе есть только названия, человеку приходится снова открывать каталог и искать предложенные товары. Эту часть работы тоже нужно включить в оценку разработки.
Камера пригодится, когда проще сфотографировать маркировку, чем набрать ее вручную. Распознанную модель устройства стоит показать покупателю: ошибка в символе меняет результат подбора. Голосовой ввод имеет смысл добавлять, если он помогает в конкретной ситуации, например когда у человека заняты руки. Для первого запуска вполне может хватить текста.
На телефоне нужно учитывать и прерванный диалог. Покупатель свернул приложение, ответил на звонок, потерял связь — после возвращения ему не должно требоваться начинать все заново. Приложение сохраняет переписку и проверяет результат последнего действия. Если запрос на добавление в корзину ушел, а ответ сервера потерялся, сначала нужно выяснить, добавился ли товар. Такие случаи проверяют вместе с основным маршрутом покупки.

Что проверять до реального запуска

Проверочный набор советуем собирать из реальных поисковых запросов и обращений в поддержку, обезличив их. В него должны попасть нормальные рабочие ситуации и случаи, на которых система обязана остановиться: неполная маркировка, противоречие между источниками, отсутствующий товар, попытка открыть чужой заказ.
Для каждого запроса заранее фиксируют допустимый результат. Иногда это конкретные товары, иногда — уточняющий вопрос. При отсутствии подтверждения совместимости корректным результатом будет отказ от уверенной рекомендации. Оценка самой модели «я уверена на 95%» такой проверки не заменяет.
Ошибки нужно разбирать по месту возникновения. Правильный товар не нашелся в поиске — проверяют данные и выдачу. Он был в результатах, но модель предложила другой — разбирают формирование ответа. Товар выбран верно, но не добавился в корзину — проверяют операцию и ее статус. Общая оценка «качество ответа низкое» не подсказывает разработчикам, что исправлять.
Для такого разбора в журналах сохраняют версию модели, найденные источники и результат вызова каждой функции; состав записываемых пользовательских данных ограничивают. После смены модели или правил поиска проверочный набор проходят заново. Обновление, которое улучшило обычные ответы, может иначе сработать на артикулах и исключениях.
Отдельно проверяют время до полезного результата. Первая появившаяся буква еще не означает, что покупатель получил варианты и может действовать. В измерение входят поиск, обращения к системам магазина и подготовка карточек. Помимо типичного времени нужна задержка в медленных случаях — например, p95, порог, в который укладываются 95% измерений.
Проверки на Android и iOS должны включать сворачивание приложения, обрыв связи и старую поддерживаемую версию клиента. При сбое ассистента покупатель сохраняет доступ к поиску, корзине и поддержке. Если вопрос передают оператору, ему нужны исходный запрос, уже найденные материалы и сведения о выполненных действиях.
Краткое резюме модели можно приложить, но сотрудник должен иметь возможность проверить его по истории.

Из чего складывается экономика внедрения

У проекта есть разовые расходы и стоимость дальнейшей работы. В разовую часть входят подготовка данных, интеграции и мобильный интерфейс. Отдельно нужны сценарии ошибок, аналитика и проверочный набор: без них команда выпустит функцию, результат которой трудно оценить и сопровождать.
В эксплуатации оплачиваются запросы к моделям, поиск и инфраструктура. Добавляются разбор ошибок, обновление источников и работа сотрудников со сложными обращениями. Для собственного размещения модели учитывают загрузку оборудования и резерв мощности. На стоимость запроса влияют длина ответа, история диалога и объем найденных материалов. Один вопрос покупателя может потребовать нескольких обращений к модели.
Считать стоит весь законченный сценарий. Если дешевая модель чаще ошибается и переводит покупателя к оператору, расходы на ее API могут снизиться одновременно с ростом общей стоимости обслуживания. Аналогично короткий диалог с неправильным товаром обходится магазину дороже после возврата.

Что зафиксировать в задании на пилот

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

Часто задаваемые вопросы

Можно ли добавить AI-ассистента в уже работающее приложение?
Да. В приложение добавляют интерфейс помощника, а на сервере настраивают его работу с данными и операциями магазина. Перед оценкой разработки нужно проверить доступ к каталогу, корзине и заказам. Если готовых программных интерфейсов нет, их создание тоже войдет в проект.
Сколько стоит AI-ассистент в приложении интернет-магазина?
Для оценки нужны конкретный сценарий и ожидаемая нагрузка. В смете отдельно считают подготовку данных, интеграции, интерфейс и тестирование. Затем — ежемесячные расходы на модели, инфраструктуру и сопровождение. Сравнивать предложения подрядчиков лучше по одному заданию: иначе за похожей ценой могут скрываться разные объемы работ.
От чего зависит срок запуска?
От готовности данных, доступности систем магазина и действий, которые поручают ассистенту. Подбор товаров и изменение оплаченного заказа требуют разного объема разработки и проверок. Попросите подрядчика включить в график работы со стороны заказчика: передачу документации, исправление каталога, согласование правил и приемку. Без них дата релиза мало о чем говорит.
Нужно ли обучать собственную нейросеть?
Для первого запуска обычно можно использовать готовую модель, подключив к ней поиск по данным компании и нужные операции. Новые товары, цены и инструкции тогда поступают из источников магазина. Дообучение имеет смысл обсуждать после проверки готовой модели — когда команда уже понимает, с какими задачами она не справляется.
Можно ли запустить ассистента, если каталог заполнен не полностью?
Можно ограничить пилот категорией, для которой хватает проверенных данных. При этом важен состав полей: для подбора картриджа фотографии и описание не заменят сведения о совместимости. До запуска составьте перечень данных, без которых ассистент не сможет дать обоснованную рекомендацию.
Как снизить риск неверных рекомендаций?
Ограничьте подбор товарами из каталога, а совместимость проверяйте по подтвержденным данным. Цены и наличие передавайте из действующих систем магазина. При нехватке сведений ассистент должен уточнять запрос или передавать вопрос сотруднику. Перед запуском проверьте эти переходы на реальных обращениях, включая ошибки в артикулах и противоречия между источниками.
Куда попадают данные покупателей?
Это зависит от схемы размещения. При работе через внешний API переданные модели сведения обрабатывает поставщик; условия хранения и использования запросов нужно проверить до подключения. При собственном размещении компания управляет инфраструктурой и доступом к ней. В обоих случаях стоит заранее определить, какие данные нужны для задачи: помощнику по совместимости, например, не требуется полный профиль клиента.
Как понять, что ассистент окупается?
Сравните результаты сопоставимых групп пользователей с доступом к ассистенту и без него. Для продаж считайте маржинальный доход с учетом отмен и возвратов, затем вычитайте дополнительные расходы на обслуживание. Для поддержки проверьте, сократились ли повторные обращения и оплачиваемая нагрузка. Число диалогов показывает интерес к функции, но для решения о дальнейших вложениях нужны финансовые результаты.
Получайте полезный контент от KISLOROD в любом из мессенджеров
При переходе в одну из указанных социальных сетей вы автоматически даете согласие на обработку персональных данных и согласие на получение рекламной рассылки. Подробнее об обработке данных в Политике конфиденциальности.

Рекомендованные статьи

Показать ещё
Скачайте 17 точек роста и 100 + чекеров для роста конверсии и прибыли интернет-магазина
При переходе в одну из указанных социальных сетей вы автоматически даете согласие на обработку персональных данных и согласие на получение рекламной рассылки. Подробнее об обработке данных в Политике конфиденциальности.
Мы проанализировали ведущие интернет-магазины, результаты исследований, свой опыт и собрали важные моменты в одно руководство. Делаем e-commerce лучше, поэтому не только пользуемся сами, но и делимся с вами.
Выберите удобный мессенджер и получите чек-лист прямо сейчас: