AWS、検索エージェントを「多ターン強化学習」で調整　小型モデルで失敗が大幅に減る

米Amazon Web Services (AWS) は10月2日、小型モデルを「多ターン強化学習」で検索エージェントに鍛えた結果を公式ブログの記事で公開した。調整後のモデルは4つの評価データのうち3つで検索の質を6〜24%高め、最も失敗の多かったデータではエラーで失敗する割合を約23%から1%未満に下げた。自社の道具に合わせて小さなモデルを鍛える選択肢を、AWSが数字で示した形だ。ただし、大型モデルと並べた比較の数字はブログにない。

道具の使い方を小型モデルに教える

エージェントが複数の手順をこなした結果全体に点数を付け、モデルを鍛える手法が「多ターン強化学習」(MTRL) だ。1回の出力ごとでなく、一連の手順の全体に点数を与えて、道具の使い方を含む振る舞いを学ばせる。多ターン強化学習の提供開始の告知によると、AWSは6月3日に機械学習基盤「Amazon SageMaker AI」でこの手法の提供を始めた。計算資源を自分で用意する必要はなく、料金は処理したトークンの量で決まる。

SageMaker AIの多ターン強化学習の説明文書によると、対象のモデルは4つある。Nova Lite 2.0、GPT-OSS-20B、Gemma-4-31B-it、Qwen 3.6 27Bだ。米国西部 (オレゴン) では4つすべてを使えるが、米国東部 (バージニア北部) ではNova Lite 2.0とGPT-OSS-20Bに限られる。学習の経過はMLflowで記録でき、点数やpass@kで結果を評価する機能も付く。

ブログは、大型の最先端モデルに指示を出せば多くの場合は動くが、その分、応答の遅さと費用がかさむと書く。小さなモデルに自社の道具と環境を直接教えれば、小型モデルの速さと費用のまま、最先端モデル並みの安定性が得られるというのがAWSの説明だ。

検索の質は4つ中3つで上がった

ブログによると、検証ではQwen3.6-27Bに2種類の検索の道具を持たせた。単語の一致で探す全文検索 (BM25) と、意味の近さで探すベクトル検索だ。学習にはFRAMESやMusiqueなど6つのデータを使い、効果は学習に使っていない4つのデータで測った。

指標は、正解の文書を検索結果の上位10件のどこに並べたかで点数を付ける「nDCG@10」だ。調整後のモデルはBrowseComp-Plusで0.5136から0.6354へ、24%近く上がった。WixQAでは0.5725から0.6781へ18%、Wandsでは0.5762から0.6112へ6%改善している。

一方、FreshStackでは0.4112から0.4089へわずかに下がった。ブログはこの低下の理由を説明していない。つまり、調整の効果は評価のデータによって幅があり、下がる場合もある。

エラーで失敗する割合が大きく減った

ブログは、ターン数やトークンの上限超過などのエラーに当たった質問の割合を「失敗率」として測った。学習では、手順の回数の上限か、1回に生成できるトークンの上限に達した試行に-1の点数を与えている。

調整の結果、BrowseComp-Plusの失敗率は22.89%から0.68%に下がった。WixQAでも0.67%から0.17%に減った。つまり、5問に1問以上がエラーで失敗していたデータで、失敗がほぼなくなった。

1問あたりの手順の数 (ターン数) は、BrowseComp-Plusで7.0から6.3、FreshStackで3.1から2.8に減った。WixQAは4.3から4.5、Wandsは2.2から2.9に増えている。調整によって、手順を省く方向にも、検索を重ねる方向にも振る舞いが変わったことになる。

採点の関数は利用者が書く

エージェントの準備の手順を説明する文書によると、学習中はSageMaker AIが学習データの質問をエージェントに送る。エージェントは学習中のモデルを呼び出しながら道具を使い、作業を終えたら点数を返す。モデルの呼び出しには、米OpenAIのAPIと同じ形式を使う。

エージェントを置く場所は、2つの方法から選べる。Amazon Bedrock AgentCoreに置けば、SageMaker AIが直接呼び出す。Amazon EKSやAmazon EC2など自前の環境に置く場合は、AWS Lambdaの中継用の関数を介してつなぐ。外から呼べる窓口がなければ、Lambdaから待ち行列のAmazon SQSに依頼を置き、エージェントが取りに行く形にもできる。

つまり、利用者が用意するのは、自社の道具を使うエージェントと、結果を採点する関数だ。AWSは今回、小型モデルを自社の道具に合わせて鍛えれば、検索の質と安定性を同時に上げられることを数字で示した。ただし、最先端の大型モデルと同じ条件で並べた数字は、まだ示されていない。

編集部の見方

編集部は、この事例の要点はモデルの小ささより、何を成功とみなすかを点数として書き切った点にあると見る。AWSは検索の質をnDCG@10で測り、上限に達した試行には減点を与えて、失敗率を大きく下げた。小型モデルの調整を考える読者は、自社のエージェントの成功と失敗を数字で判定できるかを先に確かめるとよい。一方、「最先端モデル並みの安定性」という主張には、同じ条件で大型モデルと比べた数字がまだない。FreshStackのように下がった評価もあり、自社のデータで同じ傾向が出るかは測るまで分からない。