Strands Decider 2Bについて理解する

はじめに

Fusicのレオナです。

Strands Agentsは、AWSが開発し、オープンソースとして公開しているAIエージェント開発用SDKです。LLMに与える指示と利用可能なツールを定義することで、状況に応じてツールを選び、その実行結果を踏まえながら処理を進めるエージェントを構築できます。AWS専用のSDKではなく、Amazon Bedrock以外のモデルAPIやローカルモデルにも対応しています。
今回のブログで取り上げる「Strands Decider 2B」は、Strandsの実験的なプロジェクトを扱うStrands Labsから公開された判断用モデルです。Strands Decider 2Bは、入力で指定した候補を採点し、選択や評価値を返す判断用モデルです。^[1]今回は、GPUサーバーでモデルを動かし、日本語の質問300問を業界別に分類してみました。

Strands Decider 2Bは、Qwen3.5-2B-Baseの学習済みの重みを使い、候補を選ぶために追加学習したモデルです。

本ブログでは、モデルの構造と学習方法を、Qwenとの違いや小売に関する問い合わせの例を使って説明します。後半では、日本語分類の結果、候補順序の影響、Confidenceによる採用件数と正解率の変化を紹介します。対象は2026年10月2日時点のモデルStrandsAgents/strands-decider-2B-hobson-v19です。

Strands Decider 2Bのモデル構造

入力の文章を処理する部分には、Qwen3.5-2B-Baseの学習済みの重みを使います。重みとは、学習によって調整されるモデル内部の数値です。このモデルが計算した特徴から、候補ごとのスコアを出す部分がPointer Headです。^[2]

Qwen3.5-2Bは、質問や指示に対して、文章で回答するモデルです。Qwen3.5-2B-Baseは、入力された文章の続きを予測するように学習したモデルです。Qwen3.5-2Bでは、このBaseに、質問や指示に答えるための学習を加えています。^[3][4]Strands Decider 2Bでは同じBaseに、候補を選ぶための学習を加えています。

両者の構造を比べると、文章を読む部分と、出力を計算する部分に分けて考えられます。出力を計算する部分をHeadと呼びます。

QwenのLM Headは、語彙に含まれるトークンを採点します。トークンとは、モデルが文章を扱う際の文字列の単位です。次のトークンを出力し、その続きを計算する処理を繰り返して、候補名などの回答文を作ります。

Strands Decider 2BのPointer Headは、入力に指定した候補を採点します。候補ごとの確率分布から1つを選ぶため、候補名を1トークンずつ生成する処理はありません。^[2:1]

本体にはLoRAを適用しています。LoRAとは、元の重みを固定したまま、追加する小さな重みを学習する方法です。Strands Decider 2Bでは、LoRAとPointer Headを一緒に学習します。^[5]出力部分に加えて、文章から取り出す特徴も判断タスクに合わせて変わります。

この違いを、小売に関する問い合わせで見ていきます。

Strands Decider 2Bに何を渡し、何が返ってくるか

Allganizeの日本語評価データセット「RAG-Evaluation-Dataset-JA」の質問を例に、入力と出力を説明します。^[6]

同一建物内において酒類売場を設置している階が複数ある場合、どのような対応が必要ですか？

分類の行き先は、金融、情報通信、製造業、公共、流通と小売の5つです。問い合わせへ回答を作る処理とは分けて、どの行き先を選ぶかだけをStrands Decider 2Bに尋ねます。

入力の指定方法

Strands Decider 2Bでは、判断する対象をState、何を判断するかという指示と候補をQuestionとして渡します。この例では、次のように対応します。^[7]

つまり、問い合わせ本文がStateで、分類の指示と候補をまとめたものがQuestionです。以降は「問い合わせ本文」「分類の指示」「候補」と呼び分けます。

Pythonからは、公開パッケージstrands-deciderのload_engineとSystemOneRequestを使って次のように呼び出します。^[8]

from strands_decider.infer import load_engine
from strands_decider.schema import SystemOneRequest, ChoiceQuestion

engine = load_engine(
    "StrandsAgents/strands-decider-2B-hobson-v19",
    device="cuda",
    attn_implementation="sdpa",
)

state = "同一建物内において酒類売場を設置している階が複数ある場合、どのような対応が必要ですか？"

question = ChoiceQuestion(
    instructions="この質問が属すると考えられる業界を、候補から1つ選んでください。",
    criteria={
        "finance": "金融業。銀行、保険、証券など。",
        "it": "情報通信業。ソフトウェア、情報システム、ITサービス、通信など。",
        "manufacturing": "製造業。製品の生産、工場、生産工程など。",
        "public": "公共分野。行政、自治体、公共政策など。",
        "retail": "流通・小売業。店舗運営、商品の販売、売場の在庫管理など。",
    },
)

response = engine.evaluate(
    SystemOneRequest(state=state, questions={"industry": question})
)

answer = response.answers["industry"]
print(answer.choice)         # retail
print(answer.confidence)     # 0.8868
print(answer.probabilities)  # {"finance": 0.0086, "it": 0.0028, ...}

stateが問い合わせ本文、instructionsが分類の指示、criteriaの辞書が候補名と説明です。criteriaの順序がそのまま候補の並び順になります。questionsは辞書なので、同じ問い合わせ本文に複数の判断の指示を渡すこともできます。

実装は、このコードで渡した3つを、問い合わせ本文、分類の指示、候補の順に1つのテキストへ並べ、末尾に判断位置を示す印を置いてから本体に入力します。^[9]この整形は実装の内部で行うので、呼び出し側がプロンプトとして書くことはありません。

特徴ベクトルの計算

本体は、問い合わせ本文から候補までを順に処理します。各トークンの位置には、その位置までの文脈を処理した特徴ベクトルができます。この特徴をHidden Stateと呼びます。

Pointer Headは、その中から2種類の特徴を使います。1つは、各候補行の最後のトークンにある特徴です。例えばretailの行の末尾では、流通と小売の名前と説明を読み終えています。もう1つは、入力末尾の判断位置にある特徴で、問い合わせ本文、分類の指示、すべての候補を読んだ状態です。

Pointer Headは、この判断位置と各候補の特徴を使って、候補ごとのスコアを計算します。候補の特徴にも、それ以前の問い合わせや候補の文脈が含まれます。候補の説明文だけを独立に読み、意味の近さを比べる処理とは異なります。

分類結果

スコアを候補間の確率分布へ変換したあと、choiceでは最も確率が高い候補を選びます。この問い合わせに対して、GPU検証で実際に返った確率は次の通りでした。

最大の候補はretailなので、返された選択結果もretailです。問い合わせ本文と候補を読み、候補ごとに採点し、その分布から行き先を選ぶところまでが、1問の判断になります。

Pointer Headの計算方法

ここからは、先ほどの図にあるベクトルへの変換と、内積による採点を具体的に見ます。

判断位置の特徴を\mathbf h_a、候補iの末尾の特徴を\mathbf h_iとします。どちらも2,048次元です。Pointer Headは、それぞれを256次元へ変換し、2つのベクトルの内積をスコアにします。^[2:2]

\operatorname{LN}はLayer Normalizationで、特徴の値の大きさを整える処理です。判断位置と候補には同じ\operatorname{LN}を使います。W_qは判断位置の特徴を変換する行列、W_kは候補の特徴を変換する行列です。\mathbf b_qと\mathbf b_kも学習する値です。これらの変換を判断タスクで学習し、その結果を使って採点します。

候補ごとのスコアs_iは、Softmaxで確率へ変換します。Softmaxとは、複数のスコアを合計1の確率分布へ変換する処理です。

Kは候補数、Tは分布の集中度を調整するTemperatureです。Temperatureの校正については、後のConfidenceの節で説明します。

候補数と並び順

先ほどの5候補は、今回の入力で指定したものです。finance専用やretail専用の出力パラメータを用意しているわけではありません。候補が5つでも10個でも、同じW_qとW_kで採点します。そのため、候補名や説明を変更しても、候補数に応じてHeadのパラメータを増やす必要はありません。^[10]

これは、クラスごとの出力を学習時に固定する分類モデルとの違いです。また、Qwenに候補名を生成させる場合と比べると、候補名が何トークンに分かれるかにかかわらず、候補末尾の1つの特徴を採点できる違いがあります。

一方で、候補が増えると読む文章も長くなります。各候補の特徴には先行する文脈も含まれるため、候補を並べ替えても同じ結果になるとは限りません。後半では、この順序の影響を実際に確認します。

Qwen3.5-2B-Baseの層構成

候補の採点に使う特徴を計算しているのは、Qwen3.5-2B-Baseのテキスト本体です。Strands Decider 2Bでは、その層数や層の並びを変更せずに使います。

本体は24層で、Gated DeltaNet3層とFull Attention1層の組を6回繰り返す構成です。^[3:1]Gated DeltaNetは、過去の情報を再帰的に更新する状態へまとめます。Full Attentionは、入力内のトークン同士の関係を参照する処理で、QwenのモデルカードではGated Attention（出力ゲート付きのGrouped Query Attention）と呼ばれています。各層には、トークンごとの特徴を変換するFeed Forward Network（以下、FFN）もあります。

この本体で問い合わせ本文や候補の文脈を処理し、先ほどのHidden Stateを作ります。LoRAは、本体のAttention、FFN、Gated DeltaNetにある射影行列へ適用します。^[5:1]

LoRAとPointer Headの学習方法

ここまでの計算は、判断用に学習された重みを使っています。Pointer Headへ切り替えただけで、候補を適切に選べるようになるわけではありません。Strands Decider 2Bでは、正解候補を使ってLoRAとPointer Headを一緒に学習します。

学習データ

学習データは、公開データセットの分類や判断の問題を、本文、判断の指示、候補、正解へ変換して作ります。^[11]トピックや感情の分類、文同士の関係、複数の情報からの判断、段階評価、回答に必要な情報の十分性などを含みます。

いずれも、入力を読んで候補ごとの確率を出す形式へそろえます。学習では、正解候補への確率を高めるCross Entropyという損失を使います。段階評価では、正解段階の確率の一部を隣接する段階へ振り分けて学習します。^[5:2]

候補は学習例ごとにシャッフルし、正解候補の位置も変えます。候補の位置だけを覚える偏りを減らすための処理です。段階評価は段階同士の順序に意味があるため、順序を保ったまま、全体を反転させる場合があります。

学習するパラメータ

本体の元の重みをWとすると、LoRAはその更新分を、小さい2つの行列AとBの積で表します。^[12]

学習ではWを固定してAとBを更新します。rは更新分の行列のRankで、v19では16です。\alphaは更新分の大きさを調整する係数で、32に設定されています。^[5:3]

同時に、Pointer Headの行列とLayer Normalizationのパラメータも更新します。本体から取り出す特徴と、その特徴から候補を採点する処理を、判断タスクに合わせて学習する構成です。

教師モデルの利用

正解候補を使う損失に加え、教師側の確率分布へ近づける損失も使います。教師として使うのは、更新していないBaseモデルと、先行して学習した判断モデルです。

Baseモデルの教師分布は、候補番号のトークンに対するスコアから作ります。候補番号が1トークンになるのは1〜9までなので、この項は候補が9個以下の学習例にだけ適用されます。先行モデルの分布は、複数の情報から判断する学習例に使います。^[13]正解候補の情報と、これらの分布を使って、学習中のモデルの出力を調整します。

出力形式とConfidence

学習したモデルを使うと、候補ごとの確率分布が得られます。ここから返す値の作り方によって、choice、noul、scoreを使い分けます。^[7:1]

小売の例はchoiceでした。noulなら「追加確認が必要ですか。」という指示に対して、trueへ割り当てた確率を返せます。scoreなら、「不満がない」「軽い不満」「強い不満」のような評価段階を用意して使います。

scoreは、段階の番号を0から振り、確率を重みとした平均を返します。例えば3段階なら出力は0〜2の範囲となり、1.4のような値も返せます。候補として指定した段階の期待値なので、任意の数値を直接予測する回帰モデルとは値の意味が異なります。

Confidenceの計算方法

choiceのConfidenceは、最大の候補確率を、候補数で調整した値です。候補数をK、最大の確率をp_{\max}とすると、次の式になります。^[7:2]

一様な分布なら0、1つの候補だけに確率が集中すれば1です。先ほどの小売の例は5候補で、最大の確率が0.9094でした。この分布から計算したConfidenceは約0.8868で、実際の応答にも0.8868が含まれていました。

これは、同じような入力へ88.68%の確率で正解するという意味ではありません。Confidenceは候補分布の集中度から計算するので、その値と正答率の関係は別途評価する必要があります。後半では、Confidenceで採用する結果を絞った場合の件数と正解率を確認します。

モデルは、出力の種類ごとにTemperatureを使って分布を校正しています。スコアをTemperatureで割ることで、確率の集中度を調整する処理です。^[15]読み込んだ設定では、choiceが0.7342、noulが0.9107、scoreが1.3278でした。

同じ正のTemperatureをすべての候補へ適用しても、最大のスコアを持つ候補は変わりません。そのため、校正はchoiceの選択結果を変えずに、分布とConfidenceを調整します。分布の期待値を使うscoreは、返す数値も変わります。scoreのConfidenceは、段階の番号に対する確率分布の標準偏差を正規化した別の計算で、noulには独立したConfidenceの項目がありません。

本文の処理結果の再利用

同じ問い合わせ本文に、複数の判断の指示を与える場合もあります。その場合は、共通する本文の処理結果をキャッシュし、各指示と候補の続きを別々に処理します。^[8:1]

Qwen3.5の本体は、Attentionの過去のKeyとValueを保存するKV Cacheに加え、Gated DeltaNetの状態も再利用します。本文を読む処理を共有できますが、各指示と候補を処理して採点する計算は必要です。

日本語300問の分類検証

ここまでの構造から、実際に使うときの確認事項が2つあります。候補の並び順が判断へどの程度影響するかと、分布の集中度を表すConfidenceで結果を絞ったときに、正解率がどう変わるかです。

日本語300問の分類で、公開済みモデルの結果を確認しました。今回確認したのは日本語の質問文から元データの分野を選ぶ動作であり、追加学習やHead単独の性能比較は行っていません。

検証環境

評価データと出典

評価には、AllganizeがHugging Faceで公開しているRAG-Evaluation-Dataset-JAを使いました。^[6:1]使用したファイルはrag_evaluation_result.csvで、金融、情報通信、製造業、公共、流通と小売の5分野の質問が各60問、計300問含まれます。

このデータセットは、RAGの回答を評価するために公開されたものです。RAGとは、検索した資料を参照して回答を作る方法です。本ブログではその質問文を業界分類に利用しています。先ほどの酒類売場の問い合わせも、このデータに含まれます。

元データからモデルへ渡したのは問い合わせ本文だけです。正解ラベル、参照資料、回答は渡していません。分類の指示と、候補の名前や説明は、小売の入力例と同じものを使いました。

正解には、元データのdomainを使います。このラベルは参照資料の分野なので、質問文から推定した話題と一致しないことがあります。以下の正解率は、その分野と一致した割合です。

候補の説明と順序による精度の変化

候補名と説明を付ける条件を基準に、説明を省く条件、候補を逆順にする条件、分類の指示だけ英語にする条件を評価しました。それぞれ同じ300問を1回ずつ評価しています。

Macro F1は、各クラスの適合率と再現率から求めるF1を、クラス間で平均した値です。全条件で300件の応答が得られ、出力形式の不正はありませんでした。

候補を逆順にした条件では、基準条件から28問で選択結果が変わりました。候補間でPointer Headの重みを共有していても、実際の判断には順序の影響が残りました。

逆順の方が正解数は多いものの、この300問でよかった順序が、別の入力でも最適とは限りません。候補名や説明を指定できる設計なので、業務の入力と候補の組み合わせで確認する必要があります。

Confidenceによる採用件数と正解率

説明あり条件のConfidenceに閾値を設け、その値以上の結果を採用すると仮定しました。以下は同じ300問の集計であり、別の検証データで閾値を最適化した結果ではありません。

このデータでは、閾値を上げると採用件数が減り、採用分の正解率が上がりました。ただし、0.9以上でも164件中18件は、正解ラベルと一致しませんでした。

例えば、小売業者が取引商品の販売業務について応援を要請する質問は、元データではmanufacturingですが、Strands Decider 2BはConfidence 0.9839でretailを選びました。この例には、参照資料の分野と質問の話題の違いもあります。Confidenceで採用を決める前に、質問の話題を分類したいのか、参照資料の分野を当てたいのかをそろえる必要があります。

利用時の制約

入力長の上限

候補の文章も入力へ含まれるため、問い合わせ本文だけで入力上限を考えることはできません。Strands Decider 2Bの公開設定では、本文、分類の指示、候補を4,096トークンへ収めます。^[8:2]

入力長の確認では、同じ前置きを繰り返し、その末尾に小売店舗の棚割りと在庫管理についての問い合わせを置きました。入力が169、969、3,369トークンの条件では、すべてretailを選びました。

前置きを増やすと、整形後の本文は4,825トークンになりました。分類の指示と候補が144トークンなので、本文に使える枠は3,952トークンです。右側からの切り詰めで末尾の「棚割り」が入力へ残らず、選択結果はit、Confidenceは0.317でした。反復文による確認ですが、必要な判断材料がモデルへ届いているかを確認する必要があります。

Qwen3.5-2Bのモデルカードにある本来のContext Lengthは262,144トークンです。^[4:2]本体の構造を引き継いでも、Strands Decider 2Bの公開入力Windowや、判断を評価した範囲まで同じにはなりません。参照学習設定では、学習例の長さは3,072トークン以下とされています。^[5:5]

適切な候補がない場合

choiceは指定された候補の中で確率を正規化し、最大の候補を選びます。適切な候補がなくても、その中から選ぶため、「どれにも当てはまらない」を返したい場合は、その候補を用意するか、別の処理で確認する必要があります。

最後に

Strands Decider 2Bは、Qwenの文章を読む本体から、入力中の候補を採点するモデルへ作り替えたものです。候補末尾と判断位置の特徴をPointer Headで組み合わせ、本体のLoRAとHeadを判断タスクで学習しています。この構造を理解すると、候補を推論時に指定できる理由と、その候補の説明や順序が結果へ影響する理由がつながります。

1. 公開v19のモデルカード ↩︎ ↩︎

2. Pointer Headとモデルの実装 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

3. Qwen3.5-2B-Baseのモデルカード ↩︎ ↩︎

4. Qwen3.5-2Bのモデルカード ↩︎ ↩︎ ↩︎

5. v19の参照学習設定 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

6. Allganize「RAG-Evaluation-Dataset-JA」の使用時点のファイル一覧 ↩︎ ↩︎

7. System One APIの型定義 ↩︎ ↩︎ ↩︎

8. 共通Stateの再利用と入力長の処理 ↩︎ ↩︎ ↩︎

9. StateとQuestionの整形 ↩︎

10. Strands Deciderのアーキテクチャ ↩︎

11. 学習データと変換処理 ↩︎

12. LoRA: Low-Rank Adaptation of Large Language Models ↩︎

13. 追加学習の実装 ↩︎ ↩︎

14. 追加学習の再現手順 ↩︎

15. 評価とTemperatureの校正 ↩︎

Discussion