Amazon SageMaker Search Agent、マルチターンRLで改善も、1つのベンチマークでは後退
Amazonは、Amazon SageMakerの検索エージェントが、1回の学習エポック後にあるベンチマークで検索品質を23.7%改善したと報告した。ファインチューニングされたQwen3.6-27Bエージェントは、そのテストにおける失敗率も22.89%から0.68%へ引き下げた。ただし、すべての評価で改善したわけではない。
この複合的な結果は、完璧なスコアよりも重要である。AWSは、企業がフロンティアモデルに繰り返しプロンプトを与える代わりに、より小規模なモデルへ自社の検索ツールの操作を学習させられるかを検証している。成功すれば、エージェント競争の一部はモデル規模から環境固有の学習へ移ることになる。
この実験は、その主張の限界も示している。AWSが比較したのは、調整済みモデルと自社の未調整ベースモデルであり、現行のフロンティアモデルではない。ベンチマークも、実運用のエンタープライズ環境における正確性、レイテンシー、運用コストではなく、制御された環境内での検索行動を測定した。
AWS、マルチターン・エージェント学習の具体的な数値を示す
重要な変化は、SageMakerがモデルをファインチューニングできることではなく、AWSが完全な検索軌跡にわたってエージェントを評価した点にある。
AWSは、SageMaker AIのマルチターン強化学習を開始してから数カ月後の2026年10月2日、この実験を公開した。同社はこのサービスを用い、エンタープライズ型検索向けにQwen3.6-27Bモデルをカスタマイズした。
このエージェントは2つの検索手法を利用できた。語彙検索手法であるBM25は、完全一致の用語と単語頻度のパターンを通じて文書を見つける。ベクトル検索はクエリと文書を数値表現へ変換し、異なる表現で書かれた概念の対応付けを支援する。
これらのツールから選ぶことは、タスクの一部にすぎない。エージェントは弱いクエリを書き換え、取得した資料を確認し、追加検索が有益かを判断し、制限を使い切る前に停止しなければならない。それぞれの選択は、次の行動で利用できるコンテキストを変える。
こうした依存関係があるため、AWSはマルチターン強化学習（MTRL）を用いた。この技術は、各モデル応答を独立したイベントとして扱うのではなく、一連の行動全体にわたる振る舞いを評価する。SageMakerのMTRL documentationでは、その目的を、シーケンス全体での累積報酬を最大化することとしている。
この実験での報酬はnDCG@10だった。順位10における正規化割引累積利得は、関連文書が最初の10件の結果の上位に現れるかを測る。スコア1は理想的なランキング、ゼロはシステムが関連文書をまったく取得できなかったことを示す。
AWSは、エージェントが検索軌跡を完了した後にこのスコアを適用した。また、エージェントがターン上限または1ターンあたりのトークン予算を超えた場合には、マイナス1の報酬を与えた。このペナルティにより、効率的に完了することも学習目標の一部となった。
同社は、FRAMES、BRIGHT、Enterprise RAG、ESCI、Musique、MLQAから学習データを構成した。これらのデータセットは、マルチホップ質問、推論負荷の高い検索、エンタープライズ文書、商品検索、多言語理解を対象としている。
Enterprise RAGベンチマークには、50万件を超える合成企業文書と500件の質問が含まれる。AWSは各学習データセットの5%を検証用に取り置いた。
テストには4つの独立したデータセットを使った。WixQAはWixのドキュメントに基づくサポート質問を対象とする。Wandsは商品検索の関連性を評価し、FreshStackは最近の開発者向け質問に焦点を当てる。BrowseComp-Plusは、約10万件の人手検証済みWeb文書を対象に、難易度の高い調査クエリをテストする。
この分離は、評価が暗記した学習例を単に報いる可能性を低減するため重要だ。すべての形態のベンチマーク汚染や分布の重複を排除するものではない。それでも、ホールドアウトされたデータセットにより、報告された改善は学習スコア単独よりも意味のあるものになる。
AWSがデフォルト値から変更した公開設定は3つだけだった。1エポックを実行し、グローバルバッチサイズを128、同時ロールアウト数を32とした。ロールアウトとは、エージェントがマルチステップタスクを完了するために行う1回のサンプリング試行を指す。
より広範なサービスは、軌跡収集、チェックポイント、モデル更新を管理する。また、マネージドMLflowを通じて報酬とターン単位のトレースを記録する。元のsearch-agent experimentによると、学習報酬と検証報酬は上昇した後、終盤にかけて横ばいになった。
これが見出しの背景にある出来事だ。AWSには現在、マネージドMTRLサービスが、未知のデータセットにわたる検索ランキングと失敗行動の両方を変化させた公開事例がある。より重要な問いは、この結果がエージェント構築の標準戦略をどう変えるかである。
フロンティアモデルをデフォルトとする考え方に圧力
AWSは、信頼性は利用可能な中で最も高性能な汎用モデルを呼び出すことで得なければならない、という前提に異議を唱えている。
フロンティアモデルは、一般的な推論能力と指示追従能力がより高いため、より小規模なモデルより未知のツールを適切に扱えることが多い。この利点により、プロトタイプにとって最も安全な出発点になり得る。同時に、エージェント環境設計の弱点を覆い隠すこともある。
より大規模なモデルであっても、企業の検索インデックス、フィルター、権限、メタデータ、停止ルールを本質的に理解しているわけではない。チームは通常、プロンプトとツールスキーマを通じてこうした詳細を記述する。そして、タスクのたびにモデルがそのガイダンスを解釈するための費用を支払う。
AWSは異なる役割分担を提案する。組織が環境と成功指標を定義し、強化学習が反復的な対話をモデルの振る舞いへ変換する。その結果得られるモデルは、より特化し、大量の実行時指示への依存度を下げる。
このアプローチは、「プロンプトとフロンティアモデル」という経路に圧力をかける。競争は、どのモデルが最も多くを知っているかから、どのシステムがローカルな行動の正しい順序を学ぶかへ移る。エンタープライズ検索では、根底にある質問が多様でも、これらの行動は限定的になり得る。
例えば、サポート検索エージェントは、エラーコードを認識し、まず完全一致を優先し、結果が乏しければクエリを広げ、権威ある手順を見つけた後に停止する必要があるかもしれない。汎用モデルはその方針を推論できる。特化モデルは学習を通じてそれを組み込める。
経済性に関する主張は、この特定の評価で得られた結果ではなく、依然として主張にとどまる。AWSは、小規模な特化モデルがより低いレイテンシーと低い推論コストを実現できるとしている。しかし、公開された表にはレイテンシー測定値、トークン総数、デプロイ費用、フロンティアモデルとの直接比較は含まれていない。
このサービス自体は、2026年6月3日にサーバーレスのSageMakerカスタマイズ機能として一般提供を開始した。AWSによると、このローンチはロールアウトのオーケストレーション、軌跡収集、学習、チェックポイント管理、評価を対象としていた。launch announcementでは、サポート対象のモデルとリージョンとしてQwen3.6-27B、Nova Lite 2.0、GPT-OSS-20B、Gemma-4-31B-itも挙げられている。
サーバーレス学習はインフラ面の障壁を下げるが、アプリケーション側の作業をなくすわけではない。チームには依然として、呼び出し可能なエージェント環境、代表性のあるタスク、信頼できるグラウンドトゥルース、実際の成功を反映する報酬が必要となる。不適切に選ばれた報酬は、ビジネス目標を見失いながらスコアだけを最適化するようモデルに学習させかねない。
この要件は、測定可能なワークフローを持つ組織に有利に働く。チームが関連文書にラベルを付け、ランキング指標を計算できるため、検索品質は適している。顧客サポート、コード実行、構造化された業務も、検証可能な結果を生み出せる。
自由形式の調査はより難しい。もっともらしい回答でも、不完全だったり、根拠を欠いていたり、誤解を招く情報源に基づいていたりする可能性がある。単一の最終スコアでは、こうした違いを捉えられないかもしれない。
したがって実務上の圧力は2つのグループにかかる。モデル提供者は、反復的かつ範囲が限定されたタスクで、より大規模な汎用モデルを使い続ける価値を示さなければならない。エンタープライズAIチームは、自社のワークロードが特化ポリシーの学習を正当化するほど安定しているかを判断しなければならない。
検索可能な社内システムを構築するチームにとって、その判断はモデル選定ではなくデータ品質から始まる。信頼できるengineering knowledge baseには、依然として最新の文書、明確な所有責任、追跡可能な情報源が必要である。検索レイヤーに存在しない情報を、学習によって取り戻すことはできない。
Amazon SageMaker Search Agentが軌跡全体を学習した仕組み
この仕組みが機能するのは、SageMakerが最終的な検索結果に報酬を与えつつ、それを生んだ意思決定の連鎖を保持するためである。
教師ありファインチューニングは、モデルに事例を模倣させる。マルチターン検索エージェントでは、その事例は完全かつ高品質な軌跡を示す必要がある。専門家は、有用なクエリ、適切なツール選択、証拠の確認、弱い結果からの回復、適切な停止点を実演しなければならない。
こうした実演の作成には費用がかかる。また、環境固有でもある。ある文書インデックス向けに作られた軌跡は、メタデータ、検索ツール、アクセス制御が異なる別のシステムには適さない可能性がある。
シングルターン強化学習は実演コストの一部を回避するが、別の不一致を生む。一度に1つの出力を評価しても、数ターン後に初めて価値が明らかになる意思決定を完全には捉えられない。
広範なベクトルクエリは、当初は成果が乏しく見えるかもしれない。しかしその結果から、次のBM25クエリを成功させる正確な製品識別子が得られる可能性がある。最初の行動を独立して評価すれば、完了した検索への寄与を見落とすことになる。
MTRLはこの関係を維持する。エージェントは環境と対話し、検索結果を受け取り、コンテキストを更新し、次の行動を選択する。SageMakerは得られた軌跡を収集し、最終報酬を用いて、その意思決定の背後にあるポリシーを調整する。
AWSの報酬設計は、検索品質と明示的な失敗回避を組み合わせた。nDCG@10は最終文書セットのランキングを評価した。負の報酬は、許容されたターン数またはトークン数を超える軌跡を抑制した。
この組み合わせは、最大の信頼性に関する結果の中心にあるようだ。BrowseComp-Plusでは、ベースエージェントは830件の質問のうち22.89%で失敗した。ファインチューニング版の失敗率は0.68%だった。
この結果は、モデルがより良いランキングを取得する方法だけでなく、いつ完了すべきかも学習したことを示唆する。同ベンチマークにおける平均ターン数も、7.0から6.3へ減少した。ターン数の減少は効率向上を示す可能性があるが、公開された評価では、この削減をレイテンシーやコストに換算していない。
同じパターンがすべてのケースで見られたわけではない。WixQAでは平均ターン数が4.3から4.5へ増加した。Wandsは2.2から2.9へ増えた。FreshStackは3.1から2.8へ減少した。
こうした違いは、「ターン数が少ない」ことがより良いエージェント行動の普遍的な尺度ではない理由を示す。追加のクエリは証拠の網羅性を高められる一方、早期停止は弱い回答を生む可能性がある。適切な尺度は、ターン数を検索品質およびタスク完了と結び付けなければならない。
SageMakerは、ロールアウトと勾配更新を非同期で実行する。境界付きオフポリシー・ステイルネスにより、学習事例が現在最適化中のモデルバージョンからどれほど乖離できるかを制限する。このプラットフォームは、複数のアドバンテージ推定器とともに、PPO、CISPO、重要度サンプリング損失もサポートしている。
AWSはこの実験で、それらの選択をデフォルト設定のままにしている。そのためセットアップは再現しやすくなる一方、どのアルゴリズム上の選択が改善をもたらしたのかは見えにくい。ユーザーに提供されるのは管理された実行経路であり、各トレーニング要素を詳細に切り分けたアブレーション分析ではない。
根底にある方向性は、この単一のブログ記事を超える裏付けを持つ。Amazonおよび学術機関の研究者らが執筆した査読済みのWebAgent-R1論文では、エンドツーエンドのマルチターン対話を通じてエージェントを学習させている。
WebArena-Liteでは、この研究によりQwen2.5-3Bのタスク成功率は6.1%から33.9%へ上昇した。Llama-3.1-8Bは8.5%から44.8%へ引き上げられた。著者らは、行動クローニングによるウォームアップも結果に影響したことを確認しており、強化学習だけでエージェント学習を解決できるという主張を複雑にしている。
SageMakerの実験はWebAgent-R1より範囲が限定的だ。変化するWebサイト上での行動ではなく、文書検索に焦点を当てている。それでも両者は同じメカニズムを示唆する。すなわち、行動、観測、遅延した結果の相互作用を保ったまま学習すると、モデルは改善する。
信頼性の向上は、あらゆる検索での改善を意味しなかった
最も強い証拠が示すのは専門化の改善であり、マルチターンRLがすべての検索タスクを向上させるという包括的な主張ではない。
調整済みモデルは、4つのホールドアウトベンチマークのうち3つでnDCG@10を改善した。BrowseComp-Plusは0.5136から0.6354へ上昇し、相対的に23.7%の改善となった。WixQAは0.5725から0.6781へ増加し、18.4%の改善だった。
Wandsは0.5762から0.6112へ移行し、6%改善した。一方、FreshStackは逆方向に動き、0.4112から0.4089へわずかに低下した。
この後退は小さいが、分析上は重要である。この実験が「学習により検索は改善する」という単純な結論を裏付けることを防いでいる。モデルは、ドメイン間で不均一に転移する方策を学習した。
FreshStackには、Stack Overflowと技術文書に由来する最新の開発者向け質問が含まれる。こうしたクエリは、バージョン固有の用語や急速に変化する事実に依存する可能性がある。より広範な検索データセットで学習した方策は、この分布を改善しないかもしれない。
AWSは、この後退を説明するエラー分析を公開していない。問題がツール選択、クエリ書き換え、古いソース資料、報酬の整合性、あるいは通常の評価変動のどれに由来するのかは不明なままだ。
4つのテストは規模も大きく異なっていた。Wandsは147問、WixQAは400問、FreshStackは672問、BrowseComp-Plusは830問で構成される。AWSは信頼区間や統計的有意性を報告していない。
この欠落は測定結果を無効にするものではない。ただし、特にWandsでの6%の改善やFreshStackでのわずかな低下といった小さな差を、読者がどこまで一般化できるかには制約が生じる。
この評価では、失敗したタスクにnDCG@10のスコア0を割り当てることで、タスク失敗と検索品質も組み合わせている。失敗したエージェントは有用な順位付き出力を生成しないため、この扱いには妥当性がある。ただし、BrowseComp-Plusのスコア上昇の一部は、失敗を防いだことによるものだ。
この区別は購入者にとって重要である。成功した検索で文書の順位付けが同程度であっても、クラッシュしなくなるシステムは明らかに有用だ。しかし、信頼性の改善と関連性の改善は、異なるエンジニアリング上の成果を表す。
独立した第三者は、これらのSageMakerの結果を正確には再現していない。AWSがセットアップを設計し、評価を実行し、分析を公開した。レポートは詳細なベンチマーク値を提示しているが、完全な監査に必要なすべてのトレーニング成果物や軌跡を公開しているわけではない。
教師ありファインチューニング、プロンプトで制御したフロンティアモデル、または別の管理型MTRLプラットフォームとの比較もない。Qwen3.6-27Bのベースエージェントが唯一の直接的なベースラインである。そのため、フロンティア級の信頼性に関するAWSのより広範な主張は、ここでは検証されていない。
関連するAmazon研究は、一般的なアプローチを支持する証拠をさらに提供するが、独立した確認には当たらない。別の一連の実験では、Amazonの研究者らは、強化学習によりQwen2.5-32Bのパーソナルアシスタントエージェントのタスク完了率が39.20%から72%に上昇したと報告した。
同じエージェントカスタマイズ研究では、Natural QuestionsとMusiqueにおける小型検索モデルの改善も報告されている。これらの結果は、環境との相互作用がエージェントを改善し得るという根拠を強める。それでもAmazon関連の研究によるものであり、異なるモデル、データ、タスクを用いている。
セキュリティとガバナンスも別の不確実性を生む。学習中、エージェントは実際またはシミュレートされたツールを繰り返し呼び出す。隔離が不十分な環境では、機密データが露出したり、意図しない操作が実行されたり、本番環境では受け入れられない近道が報酬として強化されたりする可能性がある。
検索システムも変化する。文書は追加され、ランキングサービスは更新され、ツールスキーマは進化する。ある環境向けに調整された方策は、モデルのチェックポイントが変わらなくても、こうした変更後には精度を失う可能性がある。
組織は、完全なエージェントシステムに対する回帰テストを必要とする。モデル評価だけでは、変更されたインデックス、権限ルール、ツール応答によって生じるすべての障害を検出できない。
したがって、この証拠が裏付ける結論は限定的だ。マルチターンRLは、AWSの評価において、このエージェントの信頼性と大半の検索スコアを改善した。ただし、普遍的な転移、フロンティアモデルとの同等性、あるいは確実なコスト削減を立証したわけではない。
エージェント競争は環境と報酬へ向かっている
戦略的な資産は、タスク全体が成功したかどうかをエージェントに伝えられる学習環境になりつつある。
基盤モデルは、初期ロールアウトの品質を決めるため、依然として重要である。弱いベースモデルでは、強化学習によって強化できるほど十分な成功軌跡を発見できない可能性がある。
AWS自身の研究もこの効果を指摘している。能力の高いベースモデルは、より良い候補行動を生成でき、より強い学習シグナルを生み出す。専門化によって、汎用的なモデル能力の価値がなくなるわけではない。
しかし、モデル単体でエンタープライズエージェントが定義されるわけではない。システムには、ツール、インデックス、権限、状態、タスク制約、評価ルールも含まれる。MTRLは、こうした周辺コンポーネントを学習ループの一部にする。
この転換は、企業が防御可能な性能を構築できる場所を変える。2つの組織が同じオープンモデルから始めても、それぞれの環境と報酬関数が異なる運用知識を符号化するため、異なるエージェントを生み出せる。
検索は特に適した実証の場である。関連性の判断は測定可能なフィードバックを提供し、取得した文書は既知の回答と比較できる。検索では、エージェントは完全一致、意味検索、クエリ再構成、停止判断のバランスも取らなければならない。
他のワークフローはそれほど協力的ではない。営業調査には複数の許容可能な出力がある場合がある。調査では、ベンチマークに含まれていなかった有効な証拠が見つかることもある。ナレッジワークでは、タスク完了と並んで新規性、ニュアンス、来歴が重視されることが多い。
単一の終端報酬では、こうした性質を過度に圧縮してしまう可能性がある。チームには、証拠の品質、引用の正確性、ポリシー準拠、行動効率を個別に測定する複合評価が必要になるかもしれない。
そのため、インフラ競争は管理型学習だけにとどまらない。ベンダーは、顧客が安全な環境を構築し、軌跡をデバッグし、チェックポイントを比較し、報酬ハッキングを検出できるよう支援する必要がある。
SageMakerのMLflow統合は、ターン単位のトレースと報酬を可視化することで、そのニーズの一部に対応する。再開可能なジョブも役立つ。マルチターンのロールアウトは従来のファインチューニングより時間がかかる可能性があるためだ。AWSによれば、デフォルトのジョブ制限は24時間だが、ユーザーは調整でき、チェックポイントから再開できる。
モデルのサポートとリージョンでの提供状況は引き続き制約となる。実験時点では、Qwen3.6-27Bは米国西部のオレゴンリージョンでMTRLに対応していた。データ所在地の要件を持つ企業や、非対応モデルを利用する企業には、別のデプロイ計画が必要になる可能性がある。
サーバーレスのインターフェースは、プラットフォームへの依存も生む。AWSは、セルフホスト型チームであれば自身で制御するロールアウトのオーケストレーションや最適化の詳細を管理する。このトレードオフによりデプロイは加速し得る一方、低レベルの実験は難しくなる。
オープン研究は代替手法の開発を続けている。WebAgent-R1のようなフレームワークは、並列ロールアウトやコンテキスト圧縮を含む学習設計をより多く公開している。管理型サービスは、分散強化学習インフラを運用したくない組織向けに、似た考え方をパッケージ化している。
おそらく、絶対的な意味で管理型かオープンかという二分法にはならない。企業は、ワークロードの機密性、モデル要件、エンジニアリング能力、各学習コンポーネントを制御する価値に基づいて選択するだろう。
AWSの強みは統合にある。チームは複数のAWSサービスを通じてホストされたエージェントを接続し、SageMakerで学習し、トレースを調査し、得られたモデルをSageMakerエンドポイントまたはAmazon Bedrockへデプロイできる。
残る課題は実証だ。購入者には、管理型の経路が自社のタスクで再現性のある改善を生み、環境変化後も安定するという証拠が必要である。
AWSの小型エージェント仮説を検証する3つのシグナル
次の段階は、外部での再現、実運用の経済性、環境横断での安定性によって評価されるべきだ。
第1のシグナルは独立した再現である。別のチームが、公開されたデータセット、比較可能なQwen3.6-27Bベースライン、同じタスク制約を用いて検索の改善を再現する必要がある。BrowseComp-Plusの信頼性に関する結果を一致させられれば、AWSの中心的な主張は強化される。
再現実験では、ランキング改善と失敗回避を分けて分析するべきだ。さらに、不確実性の推定と反復実行も含める必要がある。こうした統制の下で改善が消えるなら、現在の結果はAWSの評価セットアップにより固有のものに見えるだろう。
第2のシグナルは、フロンティアモデルとの直接的な本番比較である。チームは、同一のワークロードで回答品質、検索関連性、エンドツーエンドのレイテンシ、消費トークン数、介入率を測定すべきだ。推論時の挙動とあわせて、学習費用も含める必要がある。
専門化したモデルが、デプロイ時により少ないリソースを使いながら大型モデルに匹敵するなら、経済的な論拠は具体的になる。チームが頻繁に再学習したり、複雑な報酬インフラを維持したりしなければならない場合、想定される削減分の一部はスタックの別の場所へ移ることになる。
第3のシグナルは、環境変更後の性能である。有用なテストとしては、文書コーパスの変更、ツールスキーマの更新、新しい検索フィルターの導入が考えられる。その後、評価者はエージェントがプロンプトによって適応できるのか、それとも別の学習サイクルを必要とするのかを測定できる。
安定した性能は、MTRLが転移可能な検索行動を教えるというAWSの主張を支持する。急激な低下があれば、モデルが元の環境に強く結びついた狭いインターフェース方策を学習したことが示される。
開発者はFreshStackの後退にも注目すべきだ。今後の実験では、3つのデータセットに有効だった方策が、なぜこのデータセットではわずかに悪化させたのかを説明する必要がある。対象を絞ったエラー分析により、最新性、技術用語、クエリ戦略のどれが差を生んだのかが明らかになるだろう。
エンタープライズの購入者は、すべてのタスクでフロンティアモデルと専門化エージェントのどちらか一方を選ぶ必要はない。実用的なアーキテクチャでは、一般的で測定可能な検索を調整済みモデルにルーティングし、未知の作業はより広範なモデルへエスカレーションできる。
このハイブリッドアプローチは、専門化が信頼できる削減効果を生むかを検証しながら、柔軟性を維持する。また、あらゆる情報ニーズに単一の方策を強制するリスクも抑えられる。
Amazon SageMakerの検索エージェントの結果は、この実験を実施する価値があることを示している。失敗の測定可能な減少と、大半のホールドアウトテストにおけるランキング改善が確認された。一方で、各組織が自社の文書とワークフローで評価する必要があるほどの不確実性も残している。
このアプローチを検討するチームにとって、次に取るべき行動は即時導入ではありません。まず代表性のあるテストセットを構築し、失敗を明確に定義したうえで、チューニング済みエージェントを既存の最も強力なベースラインと比較してください。次に、その改善が新たな文書、変更されたツール、そして難しいエッジケースにおいても維持されるかを検証します。
