ИИ в ритейле и интернет-магазине работает, когда задача повторяется сотни раз в день, у неё есть история в 1С или на сайте и ошибку легко поймать. К таким задачам относятся прогноз спроса и закупок, заполнение карточек товаров из файлов поставщиков, поиск по каталогу и ответы на типовые вопросы покупателей. Не работает он там, где истории нет, где данные в разных системах не стыкуются и где решение нельзя проверить на отложенном периоде.
Ниже карта задач, разбор каждой группы и способ проверки пользы до того, как вы платите за масштабирование. Описание услуги с составом работ — на странице «ИИ для ритейла и e-commerce», здесь только то, где ИИ даёт результат, а где нет.
Карта задач: где работает, где нет
Ритейл — это много мелких решений: сколько заказать, что написать в карточке, куда направить обращение. ИИ годится для массовых решений с проверяемым результатом. Таблица ниже — ориентир для разговора, на ваших данных строки будут другими.
| Задача | Работает, когда | Не работает, когда | Как проверить |
|---|---|---|---|
| Прогноз спроса и закупок | Есть история продаж по дням и позициям хотя бы за сезон, остатки учитываются без дыр | Новый ассортимент без истории; дефицит искажает продажи; акции нигде не записаны | На периоде, который модель не видела, против простого среднего |
| Заполнение карточек товаров | Есть файл поставщика с характеристиками, нужно привести их к формату вашей витрины | Источник данных пуст, и модель «дописывает» свойства по догадке | Выборка карточек: сверка каждого атрибута с исходным файлом |
| Сопоставление товаров | Один и тот же товар называется у поставщиков по-разному, есть артикулы и штрихкоды | Нет ни артикулов, ни штрихкодов, а различие в мелочах: цвет, размер, комплектация | Размеченная выборка пар: ошибки «склеили разное» и «не склеили одинаковое» |
| Поиск по каталогу | Покупатели вводят описания обычными словами, ассортимент большой | Каталог небольшой и поиск по названию уже находит всё нужное | Журнал запросов с пустой выдачей до и после |
| Рекомендации | Много покупок и просмотров на посетителя, большой каталог | Мало трафика, холодный старт у каждого второго посетителя | Сравнение с простым правилом «покупают вместе» на отложенной выборке |
| Ответы покупателям | Типовые вопросы про статус, доставку, возврат; бот видит заказ в учёте | Бот не подключён к заказам и отвечает общими фразами | Выборка прошлых обращений: доля решённых без человека и ошибки |
| Рекомендации по цене | Цена менялась достаточно часто, чтобы по продажам было видно реакцию | Цена почти не менялась; конкуренты и промо не учтены | Только как подсказка менеджеру, решение остаётся за ним |
Прогноз спроса и закупки: самая окупаемая задача и самая капризная
Закупщик помнит свои позиции, но не весь ассортимент. На длинном хвосте заказ делается по последней партии, и рядом оказываются дефицит и замороженные деньги в излишках. Прогноз по истории продаж здесь работает лучше всего, но только после того, как исправлена сама история.
- Спрос не равен продажам. Если товара не было на складе, продаж нет, и пустой день выглядит как нулевой спрос. Такие дни помечают, иначе модель научится заказывать мало.
- Акции и распродажи записаны отдельно. Иначе после акции прогноз принимает всплеск за новый уровень спроса.
- Возвраты и отмены не смешаны с продажами. Для интернет-магазина это особенно важно, а в 1С они лежат отдельными документами.
- Начинаем с простого. Скользящее среднее с сезонностью — базовая модель. Любая сложная обязана обыграть её на периоде, которого не видела. Если не обыгрывает, остаётся простая.
Результат — рекомендация закупщику и черновик заказа в 1С, а не автоматический заказ. Подробно о методе, данных и страховом запасе: страница «Прогнозирование спроса» и статья «Как прогнозировать спрос на складе».
Карточки и каталог: где модель экономит время и где выдумывает
Языковая модель умеет приводить характеристики из файла поставщика к единому виду, писать описание по списку свойств и распределять товары по рубрикам. Её слабость в ритейле известна: если исходных данных нет, она дописывает правдоподобное. Покупатель получает карточку с мощностью или материалом, которых у товара нет.
Правила, которые отделяют пользу от риска
- Источник для каждого поля. Атрибут попадает в карточку только если он есть во входных данных. Если его нет, поле остаётся пустым и уходит редактору.
- Числа и единицы не пишет модель. Размер, вес, мощность переносятся программой из исходного файла, а модель составляет только текст вокруг них.
- Сверка с исходником автоматически. Каждое число и каждый бренд в тексте проверяются на наличие в исходных данных, расхождение блокирует публикацию.
- Выборочный просмотр человеком. Редактор смотрит часть карточек и записывает, какие ошибки нашёл. По этому журналу решается, расширять ли автоматическую публикацию.
Сопоставление одного товара у разных поставщиков и на маркетплейсах — отдельная и более полезная задача. Модель сравнивает названия и характеристики и предлагает пары, а артикулы и штрихкоды остаются главным признаком. Как учёт и площадки расходятся по остаткам, разобрано в статье «Остатки в 1С и на маркетплейсе не совпадают».
Поиск, рекомендации и персонализация: нужен ли трафик
Здесь чаще всего покупают сложное там, где хватило бы простого. Решение зависит от объёма каталога и числа посетителей, а не от модности метода.
| Что нужно | Достаточно простого | Нужна модель | Что проверить до выбора |
|---|---|---|---|
| Поиск по каталогу | Поиск по названию и артикулу с учётом опечаток и синонимов, если каталог небольшой | Покупатели описывают товар своими словами: «чехол для телефона чтобы не скользил» | Какую долю запросов сейчас заканчивается пустой выдачей |
| Похожие и сопутствующие товары | Статистика совместных покупок и общая рубрика | Большой каталог, много просмотров на посетителя, нужна выдача под конкретный сеанс | Хватает ли данных, чтобы модель обыграла статистику |
| Персональные подборки | Списки популярного по рубрике, недавно просмотренное | Значительная доля вернувшихся покупателей с историей заказов | Сколько покупателей возвращается и как часто |
| Сегментация клиентов | Правила по давности и сумме покупок | Много признаков и нужно выявить группы, которые правилами не видны | Что вы будете делать по-разному для групп |
Рекомендация без эксперимента остаётся мнением. Показываем новую выдачу части посетителей, остальным оставляем прежнюю и сравниваем конверсию и сумму заказа на одном периоде. Если трафика мало, чтобы заметить разницу за разумный срок, лучше потратить деньги на данные и поиск.
Поддержка покупателей: бот полезен, пока видит заказ
Типовые вопросы в магазине повторяются: где заказ, как вернуть, когда придут деньги, какой размер. Бот отвечает на них без человека, если он подключён к заказам и знает правила возврата. Без этого он пересказывает общие фразы, и покупатель всё равно ждёт оператора.
- Чтение заказа. Бот получает статус, трек-номер и состав заказа из учётной системы. Данные берутся по подтверждённому номеру телефона или адресу, а не по любому названному номеру заказа.
- Действия отдельно. Ответ на вопрос и оформление возврата — разные уровни риска. Возврат оформляет человек или бот по жёсткому сценарию с подтверждением.
- Передача оператору. Если бот не уверен или покупатель раздражён, диалог передаётся человеку вместе с уже собранными данными.
- Проверка на реальных обращениях. Берём выборку прошлых диалогов и считаем, на каких вопросах бот ошибся или ответил там, где надо было передать.
Про поддержку в целом — на странице «ИИ для технической поддержки», про каналы и подключение к CRM — на странице «Чат-бот для бизнеса».
Где ИИ в ритейле не работает
Три группы причин, из-за которых проект застревает на пилоте. Они не про модель, а про условия.
- Нет данных или они не стыкуются. Товар называется по-разному в 1С, на сайте и у маркетплейса, остатки считаются тремя способами. Модель учится на этой разнице и воспроизводит её. Сначала порядок в справочниках, потом ИИ. Как подготовить данные, — в статье «Как подготовить данные для ИИ-пилота».
- Ошибку дорого поймать. Автоматическая публикация цен или массовое обновление остатков без проверки человеком превращают одну ошибку в сотни неверных карточек за час. Здесь модель даёт рекомендацию, публикует программа по правилам.
- Нет владельца результата. Прогноз готов, но закупщик продолжает заказывать по привычке, потому что никто не отвечает за то, чтобы им пользовались. Пилот не доходит до эксплуатации, и причины описаны в статье «Почему ИИ-пилоты не доходят до продакшена».
Часто оказывается, что нужна не модель, а обычная автоматизация: правила пересчёта остатков, шаблоны ответов, нормальный обмен 1С с сайтом и площадками. Тогда так и скажем: интеграция сайта с 1С и обмен с маркетплейсами дешевле и надёжнее модели.
Как проверить пользу до масштабирования
У любого результата в ритейле должна быть проверка, которую не придумали после того, как стали известны цифры. Правило простое: метрика, базовый уровень и срок записываются до начала.
| Задача | Что сравниваем | С чем сравниваем | Когда принимаем |
|---|---|---|---|
| Прогноз спроса | Ошибка прогноза по позициям на периоде, которого модель не видела | Простое среднее и прогноз закупщика | Модель обыгрывает оба на большинстве ключевых позиций, а не на нескольких |
| Карточки товаров | Доля карточек без ошибок после сверки с исходником | Заполнение вручную: время и ошибки | Ошибок в фактах нет, редактор тратит заметно меньше времени |
| Поиск | Доля запросов с пустой выдачей и конверсия из поиска | Прежний поиск на том же трафике | Конверсия не ниже прежней, пустых выдач меньше |
| Бот поддержки | Доля обращений, закрытых без человека, и повторные обращения | Выборка прошлых диалогов | Бот не решает за человека то, что нельзя решать, повторных обращений не больше |
Считать экономику лучше после этой проверки, а не до неё: до неё есть только гипотеза. Как перевести результат в деньги и учесть расходы на сопровождение, разобрано в статье «Как посчитать ROI от ИИ».
Где обрабатывать данные покупателей и заказов
В розничных данных есть персональные данные покупателей: телефоны, адреса доставки, история заказов. Персональные данные граждан России обычно должны храниться на серверах в России. Для данных ограниченного доступа внешний программный интерфейс облачной модели чаще не подходит по требованиям заказчика, поэтому обработку заказов и обращений разумно держать на вашем сервере.
Для задач без персональных данных, например описания товаров по открытым характеристикам, внешний интерфейс может быть разумным выбором. Сравнение вариантов — в статье «Своя модель или ChatGPT API». Решение принимаете вы вместе со службой безопасности и юристом: мы юридических консультаций не даём.
Что делаем мы и с чего начать
Начинаем с обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели, если задействованы учёт, сайт и площадки. На выходе карта задач с оценкой данных, выбранный первый сценарий, критерий приёмки и вилка бюджета. Обследование вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться и без нас.
Дальше лёгкий пилот на ваших данных: 150 000–400 000 ₽ за 2–8 недель. Вывод в эксплуатацию — от 1 500 000 ₽ этапами по 300 000–700 000 ₽, сопровождение — от 20 000 ₽ в месяц. На любой ступени можно остановиться, исходники лежат в вашем репозитории с первого коммита. Мы не строим маркетплейсы и не дежурим круглосуточно. Подробнее — на странице «ИИ для ритейла и e-commerce», все цены и сроки — на странице «Тарифы».
Частые вопросы
С какой задачи начать внедрение ИИ в интернет-магазине?
С той, где есть история в учёте и результат легко проверить: прогноз закупок, заполнение карточек из файла поставщика или ответы по статусу заказа. Выбор определяют данные, а не желание «сделать как у других».
Сколько нужно данных для прогноза спроса?
Для устойчивой работы нужна история продаж по дням и позициям хотя бы за сезон и учёт остатков без пропусков. Для редких позиций прогноз ненадёжен, и там лучше работает простое правило и решение закупщика.
Может ли нейросеть сама писать карточки товаров?
Текст вокруг характеристик может, но числа, бренды и свойства должны переноситься из исходных данных программой и проверяться на совпадение. Если характеристики в источнике нет, поле остаётся пустым и уходит редактору.
Нужен ли чат-бот интернет-магазину?
Нужен, если типовых вопросов много и бот видит заказ в учёте. Без доступа к заказам он только пересказывает общие правила. Действия вроде возврата оформляются человеком или по жёсткому сценарию.
Подходят ли рекомендации для небольшого магазина?
Чаще всего хватает простых правил: сопутствующие товары, популярное в рубрике, недавно просмотренное. Модель имеет смысл при большом каталоге и заметном трафике, и проверять её нужно экспериментом на части посетителей.
Можно ли использовать облачные модели для данных покупателей?
Для данных ограниченного доступа, включая персональные данные покупателей, облачные модели чаще не подходят по требованиям заказчика. Для открытых данных, например описаний товаров, внешний интерфейс может быть разумным. Решение принимает ваша служба безопасности.
Сколько стоит внедрение ИИ в ритейле?
Обследование — 200 000 ₽ (350 000 ₽, если задействовано несколько систем), лёгкий пилот — 150 000–400 000 ₽, тяжёлый — 400 000–1 200 000 ₽, вывод в эксплуатацию — от 1 500 000 ₽ этапами по 300 000–700 000 ₽, сопровождение — от 20 000 ₽ в месяц. Точная цена называется после обследования.
Вы делаете маркетплейсы и мобильные приложения?
Нет. Мы подключаем ИИ к вашему учёту, сайту и обмену с площадками, делаем кабинеты и веб-сервисы. Разработку маркетплейса и мобильного приложения мы не берём.