«Серебряной пули не существует»: как RWB строит промышленный ИИ
Десятки экспериментов, open-source, который нужно дорабатывать, и непредсказуемое поведение GPU. Как Wildberries на масштабе миллионов заказов делает ИИ полезным, а не просто модным.
На митапе Inside AI Meetup команда RWB (Wildberries & Russ) и приглашенные эксперты из MWS, Avito, VK, МФТИ, M2, Сбера, red_mad_robot и Альфа-Банка честно разобрали, что на самом деле стоит за красивыми словами «мы внедряем ИИ». Спойлер: ИИ это не магия, а десятки неудачных экспериментов, open-source грабли и железо, которое ведет себя не так, как вы ожидаете.
Не магическая кнопка, а десятки экспериментов
Павел Раваев, директор по данным RWB, сразу же в начале митапа отсекает главный миф об искусственном интеллекте.
«ИИ — это не какая-то магическая кнопка, на которую ты нажимаешь, и всё становится красиво и хорошо».
За каждым запуском стоят данные, сотни экспериментов и огромная инженерная работа.
Масштаб Wildberries заставляет относиться к ИИ без иллюзий. Миллионы пользователей, десятки миллионов заказов в день — улучшение какого-то процесса даже на пару процентов превращается в сложнейшую инженерную задачу. Поэтому главный принцип компании звучит максимально прагматично: «Мы не внедряем ИИ только ради ИИ. Сначала проблема, потом гипотеза, потом десятки экспериментов. Часть взлетает, часть откатываем».
И этот подход работает. ИИ в Wildberries уже давно вышел за рамки чат-ботов и модерации. Поиск и рекомендации превратились в сложные системы, учитывающие не только предпочтения пользователя, но и наличие товара на ближайшем складе, чтобы снизить логистические издержки.
Прогнозирование спроса и управление складскими операциями — то, что пользователь никогда не увидит, — экономят компании колоссальные деньги. Для селлеров работают инструменты генерации карточек товаров по фотографии и автоответы на отзывы. Только задумайтесь: ежедневно на WB оставляют около четырех миллионов отзывов и задают триста тысяч вопросов. Вручную это обрабатывать невозможно.
А еще Wildberries запускает автопереводы карточек товаров для других стран — руками это сделать невозможно из-за объемов.
Внутри компании ИИ тоже активно используется. У Wildberries есть, например, AI-агент DPO, который проверяет, что лежит в больших хранилищах данных. «Он заменил целый пласт ручной работы с разметкой. Мы его сделали, попробовали, отдали безопасникам — и теперь это работает в зоне их ответственности», — рассказывает Павел. А еще есть собственные кодинг-ассистенты, инструмент для автоматического ревью кода (им пользуются около 200 команд).
«Колесо сансары замкнулось — программисты разрабатывали ИИ, и он начал их заменять», — смеется Юрий Софронов, руководитель направления моделей и сервисов для ИИ-ассистентов в RWB.
Главный вывод, который делает Раваев, звучит так: ИИ в крупной компании нужен не ради инноваций. Он помогает выстроить интеграцию в тысячи уже работающих процессов и нагрузку, которую не выдержит ни один коробочный фреймворк.
Где заканчивается магия и начинается автоматизация
Первый технический блок митапа начался с неожиданного признания. Руководитель ML-платформы Даниил Понизов и MLOps-инженер Роман Лазовский из RWB рассказывали о внедрении AIOps-практик, но их главный вывод звучал почти издевательски: AI в AIOps-платформе оказался практически бесполезен.
Как это вообще могло случиться?
Проблема, которую они решали, знакома многим. В корпоративный чат падают тысячи алертов о недоутилизации ресурсов. Дежурные разбирают их вручную, но через неделю те же проблемы возвращаются. Кто-то берет десять GPU для обучения модели на десяти строчках данных, и никто не может этого предотвратить. В масштабах Wildberries с его тысячами ML-сервисов и сотнями владельцев ручные методы просто перестают работать.
Команда выбрала KeepHQ — единственную на тот момент open-source AIOps-платформу. Развернули, настроили интеграцию с Grafana, сделали бота в мессенджере, который ведет диалог с владельцами сервисов. Система дедуплицирует алерты (из почти 400 тысяч событий схлопывается 99%), обогащает их контекстом и автоматизирует рутину. Результат впечатляет: на одном из кластеров утилизация GPU выросла на 62%.
Ирония, которая стоит особняком
Когда платформа называется AIOps, ожидаешь, что искусственный интеллект будет играть в ней ключевую роль. На практике выяснилось, что в open-source версии KeepHQ AI-функции крайне ограничены. Встроенный LLM-провайдер из коробки не заработал — пришлось патчить ролевую модель. AI-ассистент для построения воркфлоу помогает генерировать YAML, но это просто ускоритель, а не интеллект.
«AIOps в нашем случае — это автоматизация мелких ручных действий, — резюмирует Даниил. — AI-фичи, доступные из коробки, нам пока не помогли. Мы уже разрабатываем отдельного AI-агента, который будет мониторить алерты из KeepHQ, а также обогащать их контекстом из других инструментов, чтобы автоматически заводить инциденты и открывать мердж-реквесты с предложениями по оптимизации ресурсов в сервисах».
Вывод, который стоит вынести из этого опыта: open-source решения для AIOps удобны, но будьте готовы патчить всё — от Python-степов до LLM-провайдеров. И главное — не ждите, что AI решит ваши проблемы с утилизацией. Сначала выстройте прозрачный процесс, а потом уже его автоматизируйте.
Хорошая модель не спасет: данные, код и железо решают всё
Юрий Софронов, руководитель направления моделей и сервисов для ИИ-ассистентов в RWB, разобрал самый опасный стереотип: заказчики думают, что если дать им «хорошую модель», всё заработает само. На самом деле LLM-продукт — это сложная система. Юрий выделяет как минимум три слоя: данные, код и железо, и без проработки каждого модель бесполезна.
«Никому не нужен чат-бот, который думает по 20 минут, — объясняет Юрий. — Модель без дополнительного контекста — это просто очень сложный вычислительный инструмент, который умеет генерировать токены и ничего не знает про ваш бизнес и вашего пользователя. Чтобы появился LLM-продукт, нужно воспринимать его как атомарную, неделимую сущность. Это огромный каскад и технических, и продуктовых решений».
Слой данных
История, которой Юрий поделился, наглядно иллюстрирует проблему. Задача: автоматически отвечать на вопросы покупателей. Источников информации много: описание товара, предыдущие вопросы к селлеру, тысячи отзывов. На некоторые товары на Wildberries их оставлено больше сотни тысяч. Даже в современную модель с контекстом на 120-250 тысяч токенов всё это не помещается.
Команда пробовала стандартные подходы. Добавлять все отзывы в контекст — не лезет. Векторный поиск — нет хороших датасетов и эмбеддеров, нерелевантные примеры убивают качество.
Сработал агент под названием «Водолаз». Он раз в сутки анализирует весь контент карточки — вопросы, отзывы, обсуждения — и извлекает из него факты, которых нет в официальном описании товара. «Подошва не скользит зимой», «хорошо держит тепло» — такие факты складываются в понятную для LLM key-value структуру и индексируются.
В результате удалось закрыть пять процентов вопросов, на которые раньше ответить не могли. Цифра кажется небольшой, но в масштабе WB это десятки тысяч автоматических ответов в день.
Вывод прост: не пытайтесь скормить LLM сырой контекст. Приведите данные в порядок до того, как отдадите их модели. LLM не чинит данные — она только усиливает существующий хаос.
Слой кода
Здесь Юрий был категоричен. Low-code инструменты типа LangChain — это зло для продакшна.
«Благодаря своей универсальности эти инструменты не оптимизированы. Разбирая реализацию LangChain, ты попадаешь в пять-семь слоев абстракций, неэффективно реализованные компоненты».
Где их можно использовать? Для прототипов, демо заказчику, тестирования на малой группе пользователей. Но определенно не в продакшне.
«Если кто-то в WB собирается запускать клиентские продукты на таких технологиях, как LangChain, я сильно протестую и готов всеми силами это остановить».
Альтернатива, по мнению Юрия, — разделить систему на прозрачные слои: API, роутер сценариев, сборщики контекста, саму LLM, пост-процессинг. И использовать vLLM или Triton вместо нативного PyTorch. Базовая интеграция без оптимизаций дает буст в 10–15 раз по сравнению с Transformers.
Живой пример из практики Wildberries: готовая к запуску продовая инфра с 48 GPU на end-to-end тестировании функционала в приложении показывает такие же метрики производительности, что и на 4 GPU. Производительность идентична, хотя разница в ресурсах в 12 раз! Причина оказалась не в GPU и не в модели, а в ingress-слое — стояли дефолтные лимиты на количество соединений, которые буферизовали ответы. Кодовая инфраструктура заруинила отличную GPU-инфраструктуру.
Слой железа
Самая недооцененная часть LLM-продуктов. Классический L7-балансировщик балансирует сетевой трафик, но сетевой запрос не равен нагрузке на GPU. Две одинаковые ноды с одной моделью могут отвечать с совершенно разной скоростью, одна может работать в штатном режиме, другая — зациклиться в генерациях или повлечь за собой ошибку на уровне железа. Что работает вместо этого:
- Token-aware routing — оцениваем количество токенов, не отправляем тяжелый запрос на загруженную ноду.
- KV-cache routing — используем уже посчитанный кэш на той же ноде, где он был. Трехкратный выигрыш по latency.
- Спекулятивный роутинг — кидаем запрос на две-три ноды, берем самый быстрый ответ. Ускоряет ответ на 15–25%, снижает 95-й перцентиль latency на 15%.
Когда ИИ — это переплата, а когда — полезный помощник
На панельной дискуссии встретились представители Альфа-Банка, Сбера, RWB, red_mad_robot.
Где ИИ не нужен
Самый частый ответ: если проблема решается эвристиками или регулярными выражениями, не нужно тащить LLM. В задачах кибербезопасности, например, многие пытаются применять большие языковые модели для фильтрации спама или борьбы с мошенничеством, но обычные классификаторы справляются с большинством задач намного лучше.
Красные флаги, которые заставляют команды отказываться от ИИ-решений, тоже довольно очевидны. Когда:
- заказчик требует стопроцентного качества — ИИ никогда его не даст.
- у заказчика нет понимания, как решать задачу, и он думает, что ИИ — это серебряная пуля, которая всё исправит.
- экономика не сходится — если стоимость защиты на базе ИИ выше, чем стоимость атаки и потенциального ущерба, смысла в таком решении нет.
Что важнее — модель или обвязка?
Последние полгода мировая тенденция, которую подтвердили все участники дискуссии, — переход от промпт-инжиниринга к систем-инжинирингу. Важно не то, как вы запросили модель, а какой контекст в нее попадает, как описаны инструменты, как работает оркестрация агента.
Агентные системы ценны не своей автономностью, а тем, что человек может их контролировать через бизнес-правила. Например, если вы даете агенту задание посчитать выручку за прошлую неделю, а в хранилище данных пять разных таблиц с выручкой и у каждой свой способ расчета, никакая модель не разберется без правильной обвязки и контекста, который раньше жил только в головах аналитиков.
Про деньги и веру
Честный разговор об экономике получился, пожалуй, самым интересным. Экономика LLM-проектов часто не сходится. Но есть нюансы.
Первый: стоимость инференса токенов падает с каждым месяцем. То, что не окупается сегодня, может окупиться через полгода или год. Второй, и, возможно, более важный: стоимость неделания часто выше, чем стоимость эксперимента.
«Когда вы начинаете делать пилот, вы выясняете кучу вещей, не связанных напрямую с ИИ. У вас могут быть не настроены права доступа или не готово DWH. Вы узнаете инсайты, которые можно применить и без ИИ. Компетенции дороже, чем небольшая переплата за видеокарты».
И еще один важный тезис, прозвучавший в дискуссии: немодные ниши часто приносят больше денег, чем хайповые продукты. Из неочевидных примеров — 1С. Огромное количество предприятий в России работают на этой платформе, но LLM плохо обучены ее коду. Анализ тендеров — огромные объемы текста, высокая цена ошибки, государственные закупки. Также есть множество недооцифрованных ниш: строительство, добыча ресурсов, промышленные заводы и машиностроение, где ИИ имеет еще низкое проникновение и потенциально высокий абсолютный экономический эффект. Даже единицы процентов повышения эффективности в таких нишах в абсолютном значении выражаются в десятках и сотнях миллионов рублей позитивного экономического эффекта.
Серебряной пули действительно не существует
Не существует «магической кнопки», на которую можно нажать, чтобы всё заработало. Не существует платформы, которая решит инфраструктурные проблемы своим AI. Как не существует и модели, которая исправит хаос в данных или плохую архитектуру.
Всё, что работает в промышленном ИИ, работает потому, что за этим стоит тяжелая, нехайповая инженерная работа. И в этом, наверное, главный урок Inside AI Meetup для тех, кто собирается внедрять ИИ завтра.
ИИ — это инструмент, а не религия. Он все еще не может заменить вкус, душу и человеческое понимание контекста.
«Я недавно читал статью в Vogue "Can AI Ever Crack Taste?", — вспоминает Юрий Софронов. — Единственное, чего сейчас нет у ИИ — это вкуса. Я иногда смотрю на сгенерированный текст или картинку и чувствую, что что-то не так. Человек здесь по-прежнему далеко впереди».
Возможно, через пять лет мы будем вспоминать эти слова с улыбкой. А возможно с благодарностью за то, что кто-то вовремя сказал правду.
