Михаил Неверов: «Пять тысяч агентов можно собрать за сутки. Но решат ли они реальные проблемы?»
Михаил, где сегодня в X5 проходит граница между экспериментом с ИИ и промышленным продуктом, который реально влияет на бизнес?
Для нас граница проходит не по тому, насколько сложная модель используется, а по тому, встроено ли решение в реальный бизнес-процесс и влияет ли оно на реальные бизнес-метрики.
Когда мы говорим об эксперименте, мы проверяем гипотезу. Может ли это работать? Может ли дать экономический эффект? Может ли агент, модель или аналитический подход улучшить решение, точнее спрогнозировать спрос, ускорить процесс? На первом этапе мы в целом понимаем, есть результат или нет.
Промышленный продукт начинается тогда, когда решение регулярно используется бизнесом и не живет в виде отдельного демо. Оно встроено в процесс, его эффект подтверждается данными, у него есть A/B-тесты, владелец продукта или процесса, SLA, мониторинг качества, поддержка и контроль рисков. Если решение можно масштабировать на большое количество бизнес-единиц и оно соответствует этим критериям, мы считаем, что это продакшен. Для ретейла это особенно важно, потому что бизнес низкомаржинальный, со своей спецификой и не может быть просто витринной технологии. Если решение не влияет на продажи, маржу, доступность товаров, скорость процессов или качество сервиса, то это не продукт, а технологическая возможность.
Искусственный интеллект для нас, как и любая другая технология, измеряется бизнес-результатом и технологическими метриками. Продакшеном он становится тогда, когда постоянно работает, встроен в процесс и напрямую влияет на эти показатели.
ИИ в ретейле во многом вырос из работы с большими данными и продвинутой аналитикой. Как в X5 менялась эта логика и что потребовалось, чтобы перейти от отдельных аналитических моделей к полноценным AI-продуктам, встроенным в бизнес-процессы?
Исторически искусственный интеллект в ретейле действительно вырос из работы с данными, аналитики и продвинутой аналитики. Потом началась эпоха классического машинного обучения. В X5 она стартовала в 2019 году, еще до моего прихода.
Это все, что касается прогнозирования, рекомендаций, логистики, ценообразования, ассортимента. То есть core retail, ядро ретейла, которое напрямую пересчитывается в деньги. Но со временем стало понятно, что модель сама по себе, насколько бы хорошей она ни была, ценность не создает.
Если у вас есть хорошая модель прогнозирования, но ее данными никто не пользуется, метрики у модели могут быть хорошие, а денег не видно. Поэтому мы начали переходить от разрозненных моделей к AI-продуктам. Для этого потребовалось несколько изменений. Сначала — продуктовая трансформация. Мы стали смотреть на модель не как на технический артефакт, а как на часть бизнес-процесса, внутри которого должно появиться явное улучшение. То есть не просто «у нас есть модель», а есть бизнес-задача, есть решение и есть эффект.
Следующий важный шаг связан с платформенностью. У X5 есть своя специфика в организации компании. Бизнес-единицы и торговые сети внутри группы достаточно независимы, поэтому, когда мы создаем платформы, стараемся сразу делать их масштабируемыми на разные активы.
Условно, одна модель для спроса, пополнения или ассортимента с необходимыми доработками должна применяться в разных бизнесах, а не каждый раз превращаться в отдельную кастомную разработку. Поэтому мы изначально развивали общий технологический контур, MLOps, инфраструктуру и все, что с этим связано.
Еще одно изменение касается ролей команд. Мы прошли путь, наверное, как и многие компании, когда Data Science и ML-инженеры были выделенным пулом и работали скорее как сервис по запросу. Сейчас они находятся внутри команд и напрямую взаимодействуют с продуктовыми менеджерами и разработкой. Это позволяет быстрее двигаться от идеи к промышленному решению.
И еще один важный элемент — измеримость. По сути, мы прошли путь от «у нас есть модели и люди, умеющие их строить» к управляемым AI-продуктам, которые встроены в процессы и масштабируются на разные активы через платформы.
У вас большая команда, в которой есть аналитики, дата-сайентисты, инженеры. Как устроено управление таким портфелем проектов?
Здесь, наверное, стоит отметить, что это не всегда проекты. Зачастую это уже продукты. И управление таким портфелем — это баланс между двумя рисками. Первый риск — распылиться на суперкрасивые эксперименты, которые хорошо выглядят в статьях и презентациях. Например: «смотрите, мы сгенерировали упаковку для собственных торговых марок с помощью GenAI». Спойлер: мы это действительно делаем. Но это не должно становиться самоцелью.
Второй риск — наоборот, все супер централизовать, пытаться каждую инициативу сразу оценить в деньги и за счет этого не успевать за скоростью развития технологий.
Поэтому внутри мы используем следующий принцип. Мы централизуем контроль качества, оценку результата и критерии выхода в продакшен, о котором уже говорили. Но при этом децентрализуем идеи.
Инициативы могут приходить из бизнеса, команд разработки, технологических команд, отдельных функций. Дальше они проходят через понятные фильтры. Есть ли бизнес-эффект? Можно ли его измерить? Насколько решение масштабируемо? Какие есть риски по данным, безопасности и качеству? Можно ли переиспользовать его в других сценариях?
Так мы позволяем идеям прорастать снизу. Команда, которая напрямую решает конкретную бизнес-проблему, например в логистике, очевидно, лучше погружена в специфику и, вероятно, может предложить более качественное решение, чем мы как выделенный центр. С одной стороны, мы даем таким инициативам возможность быстро пройти экспериментальный трек. С другой — сохраняем внутренний фокус.
Примерно 70% усилий мы стараемся держать в базовых задачах ретейла, то есть в том, что управляет бизнесом и помогает ему работать лучше. 20% оставляем на change — все, что связано с агентизацией и вещами, которые будут актуальны в этом или следующем году. Еще 10% остается на disrupt, на свободное поле экспериментов.
Например, сейчас в работе есть агентское взаимодействие с поставщиками, тестирование новых моделей и быстрые эксперименты, из которых потом могут вырастать более зрелые решения. Так появилась собственная платформа видеоаналитики. Новые модели сначала прошли через быстрый трек, затем стало понятно, что схема рабочая, и решение перенесено уже в основную часть портфеля. Сейчас платформа видеоаналитики используется в магазинах.
Такое разделение на run, change и disrupt по ключевым функциям и платформам позволяет управлять портфелем и ловить баланс. Важно держаться в пелотоне с точки зрения технологий, но при этом не делать то, что кажется избыточным.
Хороший пример — fine-tuning моделей. Для нас выбор между RAG, fine-tuning и другими подходами — не идеологический. Мы смотрим на качество, стоимость, управляемость и скорость изменений. Если база знаний часто меняется, RAG может быть надежнее и дешевле. Если нужна устойчивая специализация модели в повторяемом сценарии — fine-tuning может быть оправдан.
Когда речь заходит об экономике ИИ, какие показатели для вас являются ключевыми? Как понять, что проект действительно влияет на бизнес, а не просто демонстрирует технологическую возможность?
В идеале мы должны считать не «эффект от модели», а Net AI Value: бизнес-эффект и экономия минус полная стоимость разработки, инфраструктуры, лицензий, эксплуатации и контроля рисков.
Здесь система оценки на самом деле такая же, как с любой другой инициативой. В зависимости от сценария мы смотрим на вклад в EBITDA и маржу, снижение списаний, доступность товара на полке, конверсии по ключевым воронкам, экономию операционных затрат и ручного труда. При этом важно считать не только эффект от AI-продукта, но и полную стоимость его разработки, внедрения и эксплуатации. Внутри мы обсуждаем для этого подход типа net AI value. Смысл в том, чтобы честно понимать, какую ценность дает решение и сколько стоит ее получить.
Другое дело, что AI-эффект не всегда легко отделить от остальных изменений. Технология обычно работает не сама по себе, а вместе с процессами, данными и продуктовой логикой. Поэтому базовая система оценки у нас такая же, как для других бизнес-инициатив.
У нас есть большая собственная платформа A/B-тестирования, которая работает и в офлайне, и в онлайне. Мы ее сами делали. Все, что можно, прогоняем через эксперименты и A/B-тесты. Это наш золотой стандарт.
Есть hard-эффекты, где эксперимент не нужен. Например, раньше денег не было, потом они появились за счет рекламы и поступили на счет. Здесь какой A/B-тест? Мы заработали, что тут тестировать.
С R&D и инвестиционными проектами логика немного другая. Например, мы можем вложиться в платформу видеоаналитики или OCR-платформу для распознавания документов. Но дальше все равно важно понять, как этот эффект проявится в бизнесе, а не только в проксиметриках.
Проксиметрики полезны, если они тоже связаны с экономикой. В каких-то кейсах можно считать что-то вроде token per issue — сколько токенов уходит на решение конкретной задачи. Но в основном все это нужно приводить к деньгам. Иначе потом очень тяжело свести эффекты в единый показатель.
Поэтому экономика ИИ у нас мало отличается от экономики любой другой инициативы. Просто в некоторых случаях выше затраты на R&D.
Что отличает ИИ-пилот, который остается экспериментом, от решения, которое доходит до промышленной эксплуатации и масштабирования внутри компании?
К концу 2025 года мы, наверное, уже хорошо научились отделять рабочие истории от просто интересных экспериментов. Лучше всего себя показывают задачи, где генеративный ИИ усиливает сотрудника, но не требует полной автономности в критическом процессе.
Это разработка кода, подготовка документации, поиск и обобщение информации, тестирование, код-ревью, ускорение прототипирования, поддержка аналитиков и продуктовых команд.
В ряде случаев такие инструменты уже становятся стандартом и буквально входят в рабочие практики. Если ты делаешь прототип руками, а не с помощью ассистента, это уже неправильно. В пайплайне на такую задачу условно заложено два часа, а ты потратил два дня. Значит, процесс работает не так. Разработка для нас стала прямо прорывной зоной. После выхода новых моделей в прошлом году мы увидели значительный эффект. Изменилась скорость написания кода, изменилась сама роль разработчика.
Следующий большой домен — knowledge, все, что связано со знаниями. В 2026 году он будет очень важен. Это юристы, аналитики, работа с данными, структурирование информации. У юристов мы уже видим успешные кейсы.
Если совсем коротко, 2025 год был годом интерфейса и ускорения инструментов. Следующий этап — агентизация. Но там уже возникают свои вопросы: как все это контролировать, как отслеживать работу агентов, где ставить ограничения и как не допустить ошибок. Это отдельная большая тема.
ИИ часто воспринимают как инструмент, который наведет порядок в данных. Но может ли он эффективно работать, если WMS, TMS, ERP и системы магазинов живут в разных логиках и по-разному описывают один и тот же товар, заказ или остаток?
Это хороший вопрос. ИИ не заменяет управление данными. Здесь работает старая шутка «shit in — shit out»: если на входе плохие данные, на выходе тоже будет плохой результат.
Поколение GenAI-моделей меняет требования к данным. Такие модели лучше работают с разрозненными и неструктурированными данными. Если в разных системах по-разному записаны товар, заказ или остаток, модель может сопоставить эти сущности, привести их к единой логике по определенному алгоритму, можно даже написать проверки. Но все равно это стягивание нужно делать. Чем больше мы автоматизируем решения, тем важнее единые справочники, качество мастер-данных и логика систем.
При этом ИИ действительно может быть инструментом наведения порядка. Раньше мы говорили, что на уровне инженеров нужно строить пайплайны. Сейчас появляется агентский слой. Есть компании, которые занимаются тем, что помогают подключать к такому слою почты, описания, справочники, метаданные. Дальше из этих данных строится своего рода карта связей между сущностями, и агенты уже могут выбирать оттуда нужную информацию. На мой взгляд, это следующий этап развития. Компании будут строить такой agentic-ready-слой. Но он не отменяет подготовку данных. Он просто требует другого подхода и может частично помочь в этой работе. Если WMS, TMS, ERP и другие системы живут в разной логике, их все равно нужно приводить к единому знаменателю. Просто с помощью ИИ часть этой работы становится легче.
А насколько вообще реально, если мы говорим о прогнозной аналитике, построить с помощью ИИ предиктивную модель, которая заранее предупредит, где возникнет проблема — пустая полка, излишек или поставка, которая не успеет приехать?
Да, это уже есть, это реальность. Предиктивные модели могут заранее подсвечивать риски out-of-stock, недовоза, излишков. Подходов здесь много: где-то достаточно классических моделей и бизнес-логики, где-то можно подключать GenAI.
Главное, когда вы все это агентизируете, простроить нормальную цепочку. Кто получает сигнал? Какое решение предлагается? Можно ли автоматически изменить заказ? Можно ли скорректировать заказ в машине, которая через пять минут загрузится?
Если система управления складом и логистикой позволяет это делать, тогда от такого прогноза есть польза. Если данные обновляются только раз в сутки, то, каким бы точным ни был прогноз, узкое горлышко у вас в другом месте. Поэтому вопрос не только в том, может ли модель это предсказать. Важнее, как система учится на ошибках и позволяет с этими ошибками работать. Качество моделей для подобных решений уже давно достаточно высокое, и чаще всего здесь работает классический ML.
Самая сложная история — сквозная интеграция магазина, склада, транспорта, коммерции, промо, поставщика. Предиктивная модель здесь далеко не самая трудная часть. Гораздо важнее создать возможность корректировки решения на основе этой модели.
Агенты в таком контуре могут быть полезны как автоматизация сигналов и рутины. Но в итоге мы упираемся не в качество инженерного решения, а в реальный мир.
Где для вас разница между ассистентом и агентом?
Здесь уже есть некоторый стандарт. Подходов, наверное, пять — от Anthropic до китайских исследователей.
Ассистент — это copilot. Он помогает человеку: отвечает на вопросы, ищет информацию, готовит черновики, объясняет данные, предлагает варианты. Но решение и действие остаются за человеком. Это ключевой момент. Ассистент собрал информацию, передал, подсказал, показал, что хорошо и что плохо, и на этом все. Агент получает цель и дальше сам выбирает инструменты, скиллы, обращается к системам, выполняет часть процесса и возвращает результат. Он не просто говорит, что нужно проверить остатки. Он сам запускает проверку, находит отклонения, формирует заявку и говорит: «Смотри, я хочу отправить эту заявку на корректировку в рамках разрешенных правил». Или вообще не уведомляет человека — в зависимости от того, как это настроено.
Автономность агента должна расти постепенно, но это уже правило применения. Ключевое отличие — способность решать задачу end-to-end, самостоятельно выбирать инструменты и дальше по сценарию либо уведомлять человека о решении, либо предупреждать о риске.
Насколько процесс критичен и ограничиваем ли мы действия агента — это уже под капотом. И здесь моя любимая история: количество агентов само по себе не является успехом. Сколько агентов написано внутри компании, вообще ничего не значит. У нас есть свой веб-интерфейс для drag-and-drop создания агентов, и за сутки их можно собрать сколько угодно. Хотите пять тысяч — будет пять тысяч.
Вопрос в том, что они могут не решать никаких проблем, просто висеть в воздухе, красиво работать и отвечать на вопросы. Поэтому успех — это не число агентов, а количество улучшенных процессов и понятный бизнес-эффект. Если мы понимаем, что в какой-то ситуации ассистент для юриста полезнее, потому что cost of risk у полноценного агента слишком высокий, значит, оставляем ассистента. Просто, потому что бизнес уже видит от него понятную пользу.
Если говорить о перспективах X5 на ближайшие два-три года, на что бы вы поставили?
Я бы поставил на три вещи.
Первая — агентизация. Нам нужно перейти, и мы уже переходим, от copilot-сценариев к агентским. Copilot — это когда человек остается значимой частью процесса, но вместо 10 задач начинает делать 100. Этот этап мы прошли, научились, у нас есть кейсы, эффект уже считается в деньгах.
Агентские сценарии позволят сильнее изменить саму организацию работы. Например, маркетолог ставит цель и контролирует этапы, а не руками пишет все тексты, проверяет креативы и передает задачу дизайнеру. Многое из того, что вы видите в социальных сетях или на полке, уже сгенерировано искусственным интеллектом, и это нормально работает. Некоторые такие решения мы делаем внутри, потому что у нас есть свои мощности. Например, дообучаем модели для изображений, используем LoRA, Flux и другие инструменты под наши задачи. В каких-то случаях проще собрать решение внутри, чем зависеть от внешнего сервиса.
Вторая история — разработка. Она уже меняется, причем очень быстро, и это потянет за собой изменения всей компании. Если для решения задачи условно нужно 10 разработчиков вместо 100, возникает вопрос, нужна ли вся прежняя обертка вокруг процесса. Если гипотезу можно проверить за день, нужно ли так же долго и тщательно считать ее сходимость? Не факт. Эти изменения будут протягиваться дальше по организации.
Третья история, в которую я достаточно сильно верю, связана с экономикой AI-решений. Рынок будет гораздо тщательнее считать их стоимость. Просто, потому что стоимость видеокарт растет, стоимость инференса растет, и нам нужно уметь делать из этого положительную экономику. P&L должен быть положительным. Это касается всего — кол-центров, клиентской поддержки, маркетинга, бизнес-функций. Есть популярная шутка, не знаю, насколько это уже шутка, что токены на рядовые задачи с данными могут стоить 3,5 тысячи долларов в месяц, а junior data scientist — 2 тысячи. И тогда хочется сказать: «Джерри, добро пожаловать обратно в команду!».
Такая экономика будет всплывать все чаще и для бизнеса это будут критические вещи. Важно отметить, что агентность нельзя масштабировать быстрее, чем зрелость процессов, данных и контроля. Иначе мы получим не ускорение бизнеса, а ускорение ошибок.
ИИ в ретейле становится продуктом не тогда, когда появляется модель или агент, а тогда, когда меняется бизнес-процесс и это пересчитывается в деньгах, видно в скорости и качестве решений.
Опубликовано 22.05.2026
