GitHubで更新内容を見る

返却形式: {"translated": "翻訳されたHTML"}

TL;DR — 単一ターンの推論パズルから、複数ターンかつツールを拡張したeコマース会話へとRLVEフレームワークを拡張します。EcomRLVE-GYMは、商品発見、置換（代替品）、カート構築、返品、注文追跡、ポリシーQA、バンドル計画、多重インテントの旅（マルチインテントの一連の要求）という8つの検証可能な環境を提供します。いずれも、手続き的な問題生成、12軸の難易度カリキュラム、そしてアルゴリズム的に検証可能な報酬を備えています。私たちは300ステップを超えてDAPOでQwen 3 8Bモデルを学習し、環境スケーリングと適応的な難易度転移が、エージェントによる現実世界のタスク完了へとつながることを示す初期結果を提示します。

このプロジェクトはPytorch OpenEnv Hackathonから始まったもので、現在も進化し続けています。更新情報についてはフォローしてください

買い物エージェントにRLはなぜ必要？

大規模言語モデルは流暢な会話ができますが、それを買い物支援者として実運用すると、解消しきれないギャップが見えてきます：流暢さ ≠ タスク完了。たとえば、顧客が「2日以内に配送され、25ドル未満のUSB-C充電器を探して」と頼んだ場合、必要なのは、適切なカタログ検索を呼び出し、3つの厳密な制約でフィルタリングし、取得していない商品IDを捏造（ハルシネーション）せずに、トップ結果が在庫切れになったときのフォローアップにも対応できるエージェントです。

教師ありファインチューニングは、デモンストレーションから表層的なツール利用を学ばせることはできますが、複雑な制約設定の組み合わせ空間、部分情報しかない対話、そして現実のECが要求する多段の取引ワークフローへはスケールできません。

検証可能な報酬による強化学習（RLVR）は別の選択肢です。エージェントはアウトカムを最適化します。つまり、商品は制約を満たしていたか、カートは正しかったか、正しい注文ラインに対して適切に返品が開始されたか、ということです。課題は、報酬関数を検証可能（LLMを裁定者にする主観性がない）かつ適応的（ポリシーの能力に応じて難易度が上がる）な形で構築することです。

返却形式: {"translated": "翻訳されたHTML"}

RLVE-GymからEcomRLVE-GYMへ

RLVE-Gymは、ソーティング、掛け算、数独、その他のアルゴリズム的推論タスク用に400の環境を提供します。しかし、それらはすべて単一ターンのテキスト入力／テキスト出力のパズルであり、エージェント的領域への拡張は今後の課題として残されていました。

EcomRLVE-GYMは、そのギャップを埋めます。検証可能な領域（ECの成果はアルゴリズム的にチェック可能）にとどまりつつ、複数ターン、ツール拡張、エージェント的な会話へ拡張します。つまり、エージェントが単に推論して（テキスト回答を作る）だけでなく、行動（ツールを呼び出す、世界の状態を変更する）し、探索システムの不足を補う必要がある環境です。

EcomRLVE-GYMは、カスタマーサービスの成果を構造的に検証可能なものへと変換します。

上記のすべての信号は、隠された正解ゴールにアクセスできるプログラムによって評価できます。人手によるアノテーションや「LLMをジャッジ役にする」必要はありません。

---

トレーニング・エピソードがどのようなものか

枠組みを説明する前に、難易度d = 4での単一のEcomRLVEエピソードがどのようなものかを示します。環境は隠されたゴールを生成し、シミュレートされたユーザーがチャットを開き、エージェントはツールを使って要求を満たさなければなりません。すべてのアクションはアルゴリズム的に検証されます——LLMのジャッジは不要です。

報酬はコードによって完全に計算されます。(product, variant, qty)タプルに対するF1、より少ないターンで完了した場合の効率ボーナス、そして、推奨された製品IDが実際に取得されたことを確認する幻覚チェックです。エージェントがUSB-CではなくLightningバリアントを選んだ場合、シミュレートされたユーザーは対話の途中でそれを訂正するはずです——そしてF1は下がります。

8つの環境

各環境は、異なる現実の買い物シナリオをカバーしています。エージェントは、ツール（カタログ検索、カート操作、注文照会、ポリシー問い合わせ）を使ってタスクを完了させ、スコアはプログラムによって与えられます。人間や別のLLMは介しません。

すべての環境で、同じ3つのパートからなる報酬シグナルが使われます：

• タスク報酬 — エージェントは実際にゴールを完了したか？（例：正しい製品が推奨されたか、カートは正しいか、正しい注文が追跡されたか？）
• 効率報酬 — やり取りを無駄にせずに完了したか？ユーザーが引き起こしたターン（フォローアップを求める、アクションを確認する）はエージェントの不利としてカウントしません。エージェントのミスによって生じたターンだけが影響します。
• 幻覚ペナルティ — エージェントは、セッション中に実際に取得した製品だけを推奨したか？一度も参照（取得）されていない製品IDを推奨すると罰せられるため、エージェントは記憶から結果を捏造（作り話）できません。

無効な出力（不正なJSON、違法なツール呼び出し）は即座に失敗スコアを引き起こし、最初のステップから整形式の応答を返す強いインセンティブになります。

適応的難易度カリキュラム

単一の難易度数 d が、タスクの12の独立した側面を同時に制御します。これは重要です。なぜなら、EC（eコマース）の会話は多くの点で同時に難しくなるからです。つまり、単一の次元に沿うだけではありません。

以下に、4つの代表的な難易度軸を示します：

残りの8つの軸は、ターン予算、入力ノイズ（誤字、スラング）、コンテキストスイッチ、検索の深さ、注文履歴のサイズ、ポリシーの複雑さ、ツール予算をカバーします。詳細な内訳は技術レポートにあります。

適応的スケジューリング。 各環境はエージェントの成功率を独立に追跡し、エージェントが現在のレベルを確実に通過できるようになってから、初めてより難しい問題へ進みます。これにより、すべての環境で学習がエージェントの能力の最前線（フロンティア）に保たれ、「“学習しやすすぎる”」と「“進展しすぎて難しすぎる”」の両方を避けられます。

詳細解説：カート構築（E_CART）

カート構築は良いデモンストレーションです。なぜなら、フルの「検索 → 確認 → 明確化 → 実行」ループが必要であり、二値の正解（ground truth）があり、さらに多くのレコメンドベンチマークにはない課題を導入するからです。それが：バリアント選択です。

成功するには、エージェントは5つの異なるスキルを身につける必要があります：

エージェントはこれを達成するために6つのツールを使用します：

問題

ジェネレーターは、1〜5個のターゲット商品をサンプリングします（難易度は d に応じてスケールします）。各ターゲット商品は、特定のバリアント（USB-C 対 Lightning、マット対 光沢）と数量 > 1 を必要とする可能性があります。エージェントは：

1. 各商品を見つけるためにカタログを検索する
2. 利用可能な選択肢を見るために catalog.get_variants を呼び出す
3. カートに正しい (product_id, variant_id, qty) のタプルを追加する
返却形式: {"translated": "翻訳されたHTML"}

バリアントはなぜ重要か

実際のプロダクトカタログでは、バリアントデータがまばらです。多くの製品にはバリアントがなく、あっても通常は色やサイズだけが異なる場合がほとんどです。より豊かな識別タスクを作るために、エピソードの初期化時にバリアントを合成します:

• カテゴリごとの優先度リストが、最も自然に変化させられる属性を選びます（電子機器 → connector_type、衣類 → size、キッチン → material）。
• 対象の各製品について、3つのバリアントを生成します：1つの正解バリアント＋2つのもっともらしい紛らわしいバリアント（distractors）です。例えば「Anker 65W USB-C Charger」は {USB-C, Lightning, HDMI} を生成します。
• 検証器は複合キー (product_id, variant_id) を確認します。正しい製品でも、間違ったバリアントならそのユニットは一致（マッチ）しません。

難易度スケーリング

d = 0では、エージェントはバリアントの複雑さがない単一の製品を追加します。基本的な catalog.search → cart.add のワークフローを学習するだけです。d = 6になると、3つのアイテムを取り扱い、ほぼすべてが特定のバリアントを必要とし、さらに半分は数量が > 1 です。

スコアリング

カートは完全に正確でなければなりません――正しい製品、正しいバリアント、正しい数量です。部分的に正しいカートには部分点を与えますが、満点を取るにはすべてのアイテムが一致している必要があります。エージェントが間違ったバリアントを追加すると、シミュレートされたユーザーが対話の途中でそれを修正します（「それはLightning版だけど、USB-Cが必要なんだ」）。そのため、エピソードが終わる前に、エージェントが自己修正する機会が与えられます。

軌跡：簡単な場合と難しい場合

Qwen 3 8Bエージェントからの、実際のE_CARTエピソードを2つ示します。同じ環境、同じエージェント――違うのは難易度だけで、それによってゲームの性質が変わります。

d=1 では、エージェントが3つのきれいなターンでタスクを解決します。d=8 では、迷走が始まります — 炭ではなく竹を選び、XSではなくXLを選び、ユーザの2回の訂正にもかかわらずエアフライヤーを一度も直さず、その後でバリアントが存在しないと幻覚します。これは、難易度カリキュラムが露出させるまさにこの種のマルチステップのエラー連鎖であり、適応的トレーニングがエージェントに「回復の仕方」を学習させるべきものです。

ユーザーシミュレーション

検証可能な環境には、現実的に振る舞うユーザーシミュレータが必要です。テンプレートのように固定されたメッセージではなく、Qwen3.5（9.7B） を用いて自然で多様なユーザーメッセージを生成します。これにより、タイポが混じった依頼から、会話の途中での話題の切り替えまで、幅広いケースをカバーできます。

トレーニング品質において重要なのは、次の2つの設計上の選択です：

提示された制約との整合。 それぞれのシミュレーションされたユーザには、価格の敏感さ、ブランド志向、配送速度などの「隠れた嗜好の集合」があります。これらは、ユーザが伝えた制約に意図的にバイアスがかかるように設定されています。そのため、ユーザが「25ドル未満」と言ったなら、報酬関数は実際に価格を重視します。これがないと、エージェントがユーザの指示を正しく守ったとしても罰せられる可能性があります。

戦略的な省略。 LLM は、明確化の質問を強制するために、冒頭メッセージから一部の制約を意図的に差し控えます。システムは、何が言及され、何がされなかったのかを正確に追跡するため、エージェントは与えられていない情報について罰を受けることはありません。

環境のスケーリング

RLVE の手法に従い、ネストされた環境コレクションを定義します：

C1 ⊂ C2 ⊂ C4 ⊂ C8

RLVE の知見と整合的に、C8 のエージェントは、たとえその専門タスクであっても、単一環境の専門家を上回ると仮説を立てます。

返却形式: {"translated": "翻訳されたHTML"}

初期結果

最初の実現可能性（viability）調査として、DAPO を用いて C1（Cart Building）上で Qwen 3 8B を 300 ステップ学習させました。

到達した難易度が段階的に増えていくことが確認でき、適応的スケジューリングが、RLVE 論文で予測された飽和（static-low）や飢餓（static-high）のパターンではなく、安定した学習シグナルを生み出すことが示されました。

自分で試す

以下の埋め込みデモを使って、ブラウザ上で直接ライブのエピソードを実行できます。始め方は次のとおりです：

1. 環境を選択：ドロップダウンから選びます（例：カート構築なら E_CART、プロダクト発見なら E_PD）。
2. 難易度を設定 — 0 は単純な単一制約タスクです。6+ では、欠落情報、ノイズのある検索、バリアント選択が導入されます。
3. 「Reset Episode（エピソードをリセット）」をクリック — シミュレートされたユーザーが買い物リクエストから開始します。
4. あなたがエージェントです：ツール呼び出しを行い、出力を分析して、製品 id の最終リストを提出します。
5. 実行の合間に 「Reset Episode（エピソードをリセット）」 をクリックして、まっさらなシナリオから開始します。

リソース

環境、検証器、学習設定はいずれもオープンソースです：

git clone https://github.com/owlgebra-ai/EcomRLVE-Gym
cd EcomRLVE-Gym
pip install -e .

2M 製品のカタログは Hub にあります：

from datasets import load_dataset

catalog = load_dataset("owlgebra-ai/Amazebay-catalog-2M", split="train")
print(f"{len(catalog)} products loaded")

参考文献

1. Zeng, Z., Ivison, H., Wang, Y., et al. (2025). RLVE: Scaling Up Reinforcement Learning for Language Models with Adaptive Verifiable Environments. ICML 2025. arXiv:2511. 07317

2. Yu, Q., Zhang, Z., Zhu, R., et al. (2025). DAPO: スケールでのオープンソースLLM強化学習システム。 arXiv:2503.14476

3. Shao, Z., Wang, P., Zhu, Q., et al. (2024). DeepSeekMath: オープン言語モデルにおける数学的推論の限界を押し広げる。 arXiv:2402.03300

4. DeepSeek-AI. (2025). DeepSeek-R1: 強化学習によってLLMの推論を促す。 Nature.

5. Meta AI. (2024). Llama 3.1: 一般知能のための基盤モデル。 llama.meta.com

6. Qwen Team. (2025). Qwen3 テクニカルレポート。 arXiv:2505.09388

賛成（アップボート）

-

この記事で言及されているデータセット 1

この記事で言及されているコレクション 1