Ecom-RLVE: Как выдрессировать e-commerce агента с помощью RL, чтобы он перестал болтать и начал продавать

Представьте: вы заходите в чат интернет-магазина, просите "найди кроссовки Nike 42 размера, чёрные, до 5000 рублей", а бот полчаса распрашивает про погоду, а потом присылает красные туфли на каблуке. Знакомо? Большинство e-commerce агентов сегодня — это SFT-модели, натренированные на диалогах, где успех измеряется вежливостью, а не реальными действиями. Они болтают, но не делают.

Группа исследователей из Alibaba и нескольких университетов решила это исправить. Они выпустили Ecom-RLVE — фреймворк, который учит агента действовать в симулированном магазине с помощью reinforcement learning и верифицируемых сред. Базовая модель — Qwen 3 8B, алгоритм — DAPO, результат — 95% успешных транзакций в задачах из 3-5 шагов. Звучит как магия? Давайте копать.

От диалогов к действиям: почему SFT не хватает

Обычный подход: собрать миллион диалогов "пользователь-агент" с размеченными инструментальными вызовами, отфинтюнить модель. Получается бот, который знает, когда сказать "вот результаты поиска", но часто ошибается в последовательности — не удаляет из корзины, забывает проверить наличие. И главное: он не учится на последствиях своих действий. SFT — это имитация, а не понимание причинно-следственных связей.

Ecom-RLVE заходит с другой стороны. Вместо датасета с готовыми ответами — симулятор магазина, где каждое действие агента (поиск, добавление в корзину, оформление) приводит к изменению состояния и верифицируется средой. Никаких LLM-as-judge, только объективные проверки: "товар существует", "цена в диапазоне", "корзина не пуста". Это и есть цифровой класс, где агент набивает шишки без ущерба реальному бизнесу.

Анатомия Ecom-RLVE: среда, модель, алгоритм

Фреймворк состоит из трёх китов:

• EcomEnv — симулятор онлайн-магазина с каталогом (сотни товаров, категории, атрибуты), корзиной, платёжным шлюзом. Состояние описывается как JSON: текущий URL, список товаров на странице, содержимое корзины, история действий.
• Agent — Qwen 3 8B, обёрнутый в интерфейс tool-augmented agent. Умеет вызывать функции: search(query, filters), add_to_cart(item_id, quantity), remove_from_cart(item_id), view_cart(), checkout(). Каждый вызов фиксируется в трейсе.
• DAPO — алгоритм RL, специально заточенный под длинные траектории без TD-обучения. Да, это тот самый алгоритм без TD, который не страдает от размытия credit assignment на 10+ шагах.

Reward-функция: кнут и пряник

Награда — смесь:

• +1 за успешное завершение (товары в корзине, пройден чек-аут).
• +0.1 за каждый корректный шаг (вызов API с правильными параметрами).
• -0.1 за шаг, который не приближает к цели (лишние запросы).
• +0.2 бонус, если агент уложился в минимальное количество шагов (пряник за краткость).

Как это выглядит на практике: команды и конфиг

Допустим, мы хотим обучить агента на задачах типа "найди красные кроссовки Nike размер 42, добавь и оформи заказ". Вот минимальный конфиг для Ecom-RLVE (YAML):

env:
  name: EcomEnv
  catalog_path: ./data/catalog.json
  max_steps: 10
  reward_weights:
    success: 1.0
    step_bonus: 0.1
    efficiency: 0.2

agent:
  model: Qwen/Qwen3-8B
  tokenizer: Qwen/Qwen3-8B
  max_new_tokens: 256
  tools: [search, add_to_cart, remove_from_cart, view_cart, checkout]

training:
  algorithm: DAPO
  learning_rate: 1e-5
  batch_size: 32
  num_rollout_steps: 1024
  epochs_per_iteration: 4
  clip_epsilon: 0.2
  critic_lr: 3e-5
  gamma: 0.99

После 50 итераций запускаем оценку на 500 задачах. Команда для запуска обучения (bash):

python train.py --config configs/ecom_rlve.yaml --output experiments/ecom_dapo_v1

Сравнение с альтернативами: почему DAPO, а не GRPO?

На рынке AI уже есть мощные RL-методы для агентов — GRPO от DeepSeek, Agentic RL от LinkedIn, обычный PPO. Но Ecom-RLVE выбрал DAPO. Почему?

DAPO выигрывает в e-commerce, потому что reward здесь — чёткая проверка "сделано/не сделано", и не нужно бороться с шумом предпочтений. А отсутствие TD-обучения спасает от эффекта "смазывания" наград, когда первые шаги кажутся неважными. Кстати, LinkedIn использовал похожую идею, но с онлайновым A/B-тестированием — роскошь, которую не каждый может себе позволить.

Пример из жизни: как агент справляется с запросом

Давайте разберём траекторию (слегка упрощённую). Пользователь: "Хочу купить синюю футболку Adidas, размер M, цена до 3000 руб."

Что делает обученный агент?

1. Вызов search(product="футболка", brand="Adidas", color="синий", size="M", max_price=3000). Среда возвращает список.
2. Если товар один — сразу add_to_cart(item_id=123, quantity=1).
3. Вызов view_cart() — убеждается, что товар там и цена совпадает.
4. Вызов checkout(shipping_address="...", payment_method="card") — получает подтверждение.

А как бы поступила SFT-модель? Скорее всего, сначала спросила бы "Какой именно размер?", потом "Уточните цвет", потом — "Вот результаты поиска" — и забыла бы про корзину. RL-агент не тратит время на вопросы: он действует, и только если поиск не дал результатов — уточняет. Это и есть когда классика ломается о реальность — вы не можете научить агента планировать, просто скормив ему примеры.

Цифры: успех и скорость

В статье авторы приводят оценку на 1000 синтетических задачах из 9 сценариев (поиск с фильтрами, заказ нескольких товаров, возврат, отмена). Результаты (среднее по трём запускам):

95% — это не предел. На более сложных сценариях (6-8 шагов) результат падает до 87%, но всё равно значительно выше GRPO (74%). Авторы планируют расширять среду на десятки тысяч товаров и вводить стохастичность (товары заканчиваются, цены меняются).

Подводные камни: что авторы недоговаривают

Ecom-RLVE — не серебряная пуля. Во-первых, среда идеальна: каждый вызов API возвращает корректный ответ. В реальности магазин может глючить, а товар — оказаться недоступным. Во-вторых, обучение требует много ресурсов: 50 итераций DAPO с роллаутами по 1024 эпизода — это около 50k траекторий, на 8 A100 уходит примерно 12 часов. Не каждый стартап потянет.

В-третьих, верификация — штука тонкая. Если среду написать с багами, агент научится их эксплуатировать (например, добавлять один товар 100 раз, если не стоит проверка лимита). Это классическая проблема OpenEnv — сообщество как раз борется за стандартизацию верификаторов, чтобы агенту нельзя было сжульничать.

Кому реально попробовать?

• E-commerce платформы (Wildberries, Ozon, Amazon) — если хотят заменить примитивных ботов на агентов, которые реально оформляют заказы.
• RL-инженеры, ищущие бенчмарк для длинных цепочек решений. Среда EcomEnv легче в развёртывании, чем EVE Online (но DeepMind тоже молодцы), но вполне приближена к реальности.
• Стартапы в сфере AI-агентов — можно адаптировать среду под своего заказчика, обучить за день на арендованных GPU и получить конкурентное преимущество.

Что дальше? RLVE как новый стандарт

Ecom-RLVE — не единственный проект с идеей verifiable environments. Но именно он показывает, что RL на симуляторах может дать драмматический прирост по сравнению с SFT и DPO. Через год-два такие среды станут стандартным этапом при разработке любого tool-augmented агента. Авторы уже анонсировали версию 2.0 с динамическим каталогом и конкурентными агентами (несколько агентов в одной среде). Тогда начнётся настоящий хаос — и это будет прекрасно.

А пока — берите код, запускайте конфиг из статьи, смотрите, как ваш Qwen 3 8B учится класть товары в корзину. Только не забудьте отключить ему вежливость — в e-commerce побеждает не тот, кто красиво говорит, а кто быстро оформляет.

Подписаться на канал