Блог

AI-ассистент в ритейле: как построить production-систему, которая окупается

Разбираем на реальном проекте, из чего состоит промышленная AI-платформа для ритейла на LLM, MCP и RAG — что получает покупатель, как это устроено под капотом и как посчитать бюджет, чтобы не переплатить за модель.

Hero-картинка для страницы «AI-ассистент в ритейле: как построить production-систему, которая окупается»

Между демо и production

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

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

Что получает покупатель

Начнём с того, ради чего всё затевается, — с пользы. Ассистент понимает запрос, сформулированный обычными словами, и не заставляет человека угадывать «правильную» формулировку.

Покупатель может написать «ноутбук для работы с графикой до 80 тысяч», «кофемашина с автоматическим капучинатором» или «что есть из Samsung со скидкой» — и получить список подходящих товаров с ценами, фотографиями и статусом наличия в его городе. Если нужной модели нет на складе, бот предложит аналоги. По любому товару он развернёт полное описание и характеристики, а на вопрос «чем Galaxy A54 отличается от A55 и какой лучше для фото» — построит сравнительную таблицу и даст обоснованную рекомендацию.

Дальше — сделка целиком внутри чата. «Повтори мой прошлый заказ» — бот находит предыдущую покупку, проверяет наличие, предлагает замену отсутствующим позициям и оформляет новый заказ. Перед подтверждением он всегда проговаривает итог: «В заказе 3 товара на сумму 45 780 ₽. Доставка в Москву — 390 ₽. Итого 46 170 ₽. Оформляем?» Затем — отслеживание («где мой заказ», «когда приедет», «измени адрес»), работа с оплатой и возвраты без звонка в поддержку: покупатель называет причину, бот проверяет возможность возврата по сроку и категории товара, подтверждает и создаёт обращение.

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

Работает всё это 24/7, отвечает за секунды на простой запрос и до нескольких десятков секунд на сложный — с показом прогресса, а при сбое сервиса честно говорит «сейчас не могу проверить наличие, попробуйте через минуту» или переводит на оператора.

Почему это сложнее, чем «прикрутить GPT»

А теперь — вторая половина, ради которой демо и production отличаются на порядок. Самая распространённая ошибка при внедрении такого ассистента выглядит так: Browser → FastAPI → GPT. Пользователь пишет, backend держит открытое соединение, пока модель генерирует ответ 25 секунд, и всё это время воркер занят. Под нагрузкой такая схема ложится мгновенно. Поэтому в основе нашей платформы лежат несколько жёстких архитектурных принципов.

LLM не является бизнес-логикой. Это ключевое решение всего проекта. Модели запрещено выполнять SQL, обращаться к базе данных напрямую и принимать бизнес-решения. Она делает ровно три вещи: понимает естественный язык, выбирает нужный инструмент из заранее описанного набора и генерирует финальный ответ пользователю. Любая операция с данными идёт по строгой цепочке: MCP → Business API → Service Layer → Repository → Database. Между «умной» моделью и вашими ценами, остатками и заказами всегда стоит детерминированный слой с правами доступа, лимитами и валидацией.

Планирует не модель, а правила. Последовательность вызовов инструментов строит rule-based Planner — детерминированно, на основе распознанного намерения и заранее заданных правил. LLM не «корректирует план» на лету, потому что корректировка плана — это, по сути, и есть бизнес-решение, которое мы модели не доверяем.

Полная асинхронность. Долгих HTTP-запросов в системе нет. Когда покупатель отправляет сообщение, запрос завершается за 20–50 мс: клиент сразу получает task_id, а обработка уходит в очередь RabbitMQ. Дальше её подхватывает Celery-воркер, прогоняет весь AI-конвейер, а прогресс публикуется через Redis Pub/Sub и приходит в браузер потоком по Server-Sent Events. Пользователь видит статусы (SEARCH_PRODUCTS → RERANK → LLM_GENERATION) и получает ответ по мере генерации, а не смотрит в крутящийся спиннер. Такой event-driven подход позволяет независимо масштабировать AI-обработку, поиск и бизнес-сервисы: во время импорта каталога можно поднять 20 воркеров импорта, не трогая AI, а во время акции — добавить воркеров рекомендаций.

Высокоуровневая архитектура AI-платформы: пользователи, API Gateway, очередь задач, AI-оркестратор, MCP, RAG-конвейер, бизнес-сервисы и слой данных
Схема 1 · Высокоуровневая архитектура платформы

Внутри система делится на независимые контуры, каждый со своей зоной ответственности: контур взаимодействия с пользователем (Web, Telegram, мобильное приложение — без бизнес-логики и без обращений к БД), контур AI (понимание запроса, выбор инструментов, генерация ответа), контур бизнес-логики (Catalog, Order, Customer, Payment, Return, Shipment), контур поиска и контур знаний.

Асинхронная обработка запроса: браузер, API Gateway, RabbitMQ, Celery и Redis Pub/Sub со стримингом статусов и токенов по SSE
Схема 2 · Асинхронная обработка запроса (event-driven + SSE)

Контур знаний: где заканчиваются транзакции и начинается RAG

В платформе намеренно разведены два принципиально разных потока информации. Транзакционный контур работает с товарами, ценами, остатками, заказами и платежами — его источник PostgreSQL. А контур знаний работает с PDF, инструкциями, FAQ, руководствами, сертификатами и политиками возврата — и его источником служит RAG (Retrieval-Augmented Generation).

Именно этот контур отвечает за консультации «как опытный продавец». Документы проходят отдельный конвейер индексации: Ingestion → Parsing → Chunking → Embedding → Indexing → Hybrid Search → Reranking. Поиск гибридный — полнотекстовый на Elasticsearch плюс семантический на Qdrant, с последующим reranking через cross-encoder. И, что критично для доверия, ответ всегда опирается на конкретный источник, а не на «фантазию» модели.

RAG-конвейер: индексация документов, индексы Qdrant и Elasticsearch, гибридный поиск, реранкер и ответ со ссылкой на источник
Схема 3 · RAG-конвейер индексации и поиска

Это ровно та задача, которую в Рестарте мы уже решаем отдельным продуктом — Ragify, enterprise-RAG для поиска и ответов по корпоративным документам. Ragify превращает регламенты, базы знаний и проектные материалы в управляемый AI-поиск с ответами по источникам, поддерживает гибридный поиск, загрузку из PDF, DOCX, XLSX, Confluence, 1С-Битрикс и ERP, ролевую модель доступа, аудит запросов и развёртывание on-premise или в частном облаке. В ритейл-платформе контур знаний построен на той же инженерной базе: наработки Ragify по надёжному retrieval и контролю источников переносятся в клиентский сценарий почти без изменений. Это и есть главная выгода продуктового подхода — не собирать RAG заново под каждого заказчика, а приносить проверенное ядро.

Экономика: как посчитать бюджет и не переплатить за модель

Технологии впечатляют, но заказчик задаёт другой вопрос: сколько это стоит и когда окупится. И здесь важно считать честно.

Начнём с порядка цифр. RAG-пилот для одного процесса через внешний API обходится примерно в 1,5–2 млн ₽. Локальная установка того же масштаба — от 3 млн ₽, и это без учёта серверов и эксплуатации. Дальше — арифметика окупаемости, которая отрезвляет. Допустим, направление даёт 100 обращений в месяц, на каждое консультант тратит 7 минут — это около 12 часов в месяц. При ставке 2 500 ₽/час экономия составит порядка 30 000 ₽ в месяц. При стоимости пилота в 1,5 млн ₽ окупаемость растянется больше чем на четыре года — для одного узкого сценария это не проходит.

Вывод не «RAG не окупается», а «нельзя запускать его ради одного тонкого потока». Когда та же платформа закрывает пять сопоставимых процессов, годовой эффект достигает 1,8 млн ₽, а окупаемость сжимается до 10–13 месяцев. Экономика AI-ассистента живёт на масштабе и переиспользовании — ровно поэтому мы строим для ритейлера единую платформу, а не десяток изолированных ботов.

Второй рычаг экономии — правильный выбор модели под цену ошибки. Не нужно ставить самую дорогую модель на все задачи. Рутинные, типовые вопросы отлично закрывают более дешёвые модели; премиальные оправданы там, где нужно сопоставлять несколько источников и цена ошибки высока. В нашей архитектуре это встроено на уровне дизайна: rule-based Planner заранее знает тип запроса, поэтому маршрутизировать простой поиск и сложную мультиисточниковую консультацию на разные модели можно без «догадок» со стороны LLM.

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

Как запускать: пилот, который даёт ответ

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

Что это даёт на практике, показывают уже реализованные проекты. В одном из кейсов Рестарта разработка заняла три месяца, а скорость поиска информации выросла в пять раз — сотрудники находили нужное за секунды вместо часов. Ориентир по потолку внедрения задаёт Morgan Stanley: их внутренний ассистент индексирует около 100 000 документов, и им пользуется более 98% команд финансовых консультантов. Это и есть признак зрелого решения — не разовый вау-эффект, а инструмент, который люди действительно берут в ежедневную работу.

Где это уже работает: не только ритейл

Ритейл — не первый контур, где мы собираем такую систему. Инженерное ядро одно и то же: управляемый retrieval, ответы со ссылкой на источник и строгий слой между моделью и данными. Меняются предметная область, источники знаний и требования регуляторики.

  • AI-платформа и RAG-агенты для банка из топ-5 Узбекистана — корпоративная AI-платформа, где три базы знаний живут в одном контуре. Проект прошёл пилот, получил положительную оценку заказчика и перешёл в сопровождение, развитие и тиражирование.
  • RAG-ассистент по Spina Bifida для фонда — ассистент помогает семьям, пациентам, врачам и сотрудникам фонда быстрее находить проверенную информацию и снижает нагрузку на первичную консультационную поддержку.

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

Что в итоге

AI-ассистент в ритейле — это не «чат-бот поверх GPT», а распределённая production-система, где модель отвечает только за язык, а за данные, деньги и надёжность отвечает строгая инженерия: событийная архитектура, MCP как единый контракт к бизнес-логике, гибридный RAG с ответами по источникам и продуманная экономика на масштабе. Именно такое сочетание — понятная польза для покупателя плюс промышленная надёжность под капотом — превращает эффектное демо в систему, которая окупается.

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

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

Обсудим ваш контур

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

Связаться
AI-помощник
Привет! Я AI-помощник РЕСТАРТ. Помогу найти нужный раздел сайта, ответить по услугам, лицензиям, партнерствам, контактам или сформулировать обращение в отдел продаж.