EcomRLVE-GYM erweitert das RLVE-Framework von Single-Turn-Reasoning-Aufgaben auf Multi-Turn-, Tool-gestützte E-Commerce-Gespräche. Statt nur Textantworten zu erzeugen, müssen Agenten in diesen Umgebungen handeln, also Werkzeuge aufrufen, Zustände verändern und Anfragen in realitätsnahen Einkaufsszenarien abschließen. Die Autoren beschreiben acht verifizierbare Umgebungen: Produktsuche, Substitution, Warenkorbaufbau, Retouren, Sendungsverfolgung, Policy-QA, Bundle-Planung und Multi-Intent-Journeys.
Das zentrale Ziel ist, Gesprächsflüssigkeit von tatsächlicher Aufgabenerfüllung zu trennen. In E-Commerce-Szenarien reicht es nicht, plausibel zu formulieren; der Agent muss etwa Katalogsuchen korrekt ausführen, mehrere Nebenbedingungen einhalten, keine nicht abgerufenen Produkt-IDs erfinden und auf Rückfragen oder geänderte Verfügbarkeiten reagieren. Als Alternative zu Supervised Fine-Tuning setzt das Projekt auf Reinforcement Learning with verifiable rewards, bei dem Ergebnisse statt Formulierungen optimiert werden.
Die Belohnung wird vollständig algorithmisch berechnet und benötigt weder menschliche Annotation noch ein LLM als Richter. In allen Umgebungen besteht sie aus drei Teilen: Task Reward für die tatsächliche Zielerreichung, Efficiency Reward für eine Lösung mit möglichst wenigen vom Agenten verursachten Zügen und einer Hallucination Penalty, wenn empfohlene Produkt-IDs im Verlauf der Sitzung nie abgerufen wurden. Ungültige Ausgaben wie fehlerhaftes JSON oder unzulässige Tool-Aufrufe führen unmittelbar zu einem Fehlschlag.
Ein einzelner Schwierigkeitswert d steuert 12 unabhängige Aspekte einer Aufgabe gleichzeitig. Genannt werden unter anderem Zugbudget, Eingaberauschen durch Tippfehler oder Slang, Kontextwechsel, Retrieval-Tiefe, Größe der Bestellhistorie, Policy-Komplexität und Tool-Budget. Das adaptive Scheduling verfolgt die Erfolgsrate je Umgebung getrennt und erhöht den Schwierigkeitsgrad erst dann, wenn das aktuelle Niveau zuverlässig gelöst wird.
Als Beispiel heben die Autoren die Warenkorb-Umgebung hervor, weil sie die vollständige Folge aus Suche, Inspektion, Klärung und Aktion erfordert und zusätzlich Variantenauswahl einführt. Der Generator erstellt 1 bis 5 Zielprodukte, je nach Schwierigkeit, mit möglichen Variantenanforderungen wie USB-C statt Lightning oder Matte statt Glossy sowie Mengen größer als 1. Der Agent muss Produkte suchen, mit catalog.get_variants die verfügbaren Varianten prüfen und die korrekten (product_id, variant_id, qty)-Tupel in den Warenkorb legen. Um die Aufgabe anspruchsvoller zu machen, werden Varianten bei der Episodeninitialisierung synthetisch ergänzt; geprüft werden zusammengesetzte Schlüssel aus Produkt und Variante, sodass ein richtiges Produkt mit falscher Variante nicht als Treffer zählt.
Bei niedriger Schwierigkeit umfasst die Aufgabe ein einzelnes Produkt ohne Variantenkomplexität. Bei höherer Schwierigkeit muss der Agent mehrere Artikel mit spezifischen Varianten und teils höheren Stückzahlen bearbeiten. Teilweise korrekte Warenkörbe erhalten Teilpunkte, eine volle Bewertung setzt aber voraus, dass Produkt, Variante und Menge vollständig übereinstimmen. Wenn der Agent eine falsche Variante wählt, kann der simulierte Nutzer dies im Dialog korrigieren, wodurch eine Selbstkorrektur vor Episodenende möglich bleibt.
Für die Nutzersimulation wird Qwen3.5 mit 9,7 Milliarden Parametern eingesetzt, um natürliche und variierte Nachrichten statt starrer Vorlagen zu erzeugen. Zwei Designentscheidungen sollen die Trainingsqualität stützen: Verborgene Nutzerpräferenzen werden an die geäußerten Nebenbedingungen angepasst, damit der Reward nicht gegen korrekt befolgte Instruktionen arbeitet, und ein Teil der Anforderungen wird zu Beginn bewusst ausgelassen, damit der Agent Rückfragen stellen muss. Das System verfolgt dabei, welche Informationen genannt wurden und welche nicht, damit keine Strafen für nie gegebene Informationen entstehen.
In Anlehnung an RLVE definieren die Autoren verschachtelte Umgebungssammlungen von C1 bis C8 und stellen die Hypothese auf, dass auf C8 trainierte Agenten auch auf Einzelaufgaben besser abschneiden können als Spezialisten für nur eine Umgebung. Als erste Machbarkeitsstudie wurde Qwen 3 8B mit DAPO über 300 Schritte auf C1, also Cart Building, trainiert. Laut Beitrag stieg die erreichte Schwierigkeit im Verlauf an, was als Hinweis gewertet wird, dass adaptives Scheduling ein kontinuierliches Lernsignal liefert.
Das Projekt entstand im Pytorch OpenEnv Hackathon und wird weiterentwickelt. Umgebungen, Verifier und Trainingskonfigurationen sind als Open Source auf GitHub verfügbar. Zusätzlich verweisen die Autoren auf einen Katalog mit 2 Millionen Produkten auf dem Hub.
