Qwen3に9例を渡すと分類はどう変わる？ 正解9/18でも13件の判定が変わった

プロンプトの設計と、出力を正解・誤答と判定するルール

この記事では、事前学習済みの小型言語モデル「Qwen/Qwen3-0.6B」を使い、教材作成者が用意した架空の日本語問い合わせ文を3つのクラスに分類します。データセットは学習用45件、調整用9件、各クラス6件ずつ計18件の比較用データで構成され、送り手が「いま解決したいこと」を正解基準としています。分類番号の対応は次の通りです。

0 = 料金・請求
1 = ログイン・認証
2 = 操作・不具合

クラスごとの確率を数値で出す分類器とは異なり、言語モデル（LLM）は入力に続く文字列（トークン）を生成します。自由な文章で答えさせると「ログインの件ですが請求も関係します」のように解釈が分かれる出力が混じるため、プロンプトで「いま解決したいこと」を基準に選び、対応する数字1文字だけを返すよう指示しました。

出力の採点ルールも固定しています。生成された文字列から前後の空白や改行を除き、0・1・2 のいずれか1文字だけであれば有効な予測として扱い、余計な説明文や複数の数字が含まれる出力はすべて誤答と判定します。

実験では、モデルの重み（パラメータ）を再学習せず、プロンプトだけを変えた2つの条件を比べます。

1つ目は指示文と判定対象の問い合わせ文だけを渡す「LLM（例なし）」、2つ目は学習用データから各クラス3件ずつ、固定して選んだ9件の問い合わせ文と正解番号の組を見本としてプロンプトに添える「LLM（9例を提示）」です。

どちらの条件でも、比較用18件の問い合わせ文は1件ずつ独立してモデルへ入力します。見本には固定した学習用9件だけを使い、比較用データの正解や他の比較文は一切渡していません。下の図は、2つの条件でモデルに渡すプロンプトの構成です。

どちらも正解は9/18、それでも18件中13件で予測が変わった内訳

2026年10月10日の保存出力（10月12日集計）では、比較18件の正解数は「LLM（例なし）」が9/18件、「LLM（9例を提示）」も9/18件でした。全体の正解数だけを見ると、9件の見本を添えても結果が変わらなかったように見えます。

ところが、18件の予測を1件ずつ突き合わせると、18件中13件で予測先のクラスが変わっていました。

内訳を見ると、例なしの誤答から9例提示で正答に変わった「改善」が5件、例なしの正答から9例提示で誤答に変わった「悪化」が5件です。残る8件は、両方正解が4件、両方誤答が4件でした。両方誤答の4件のうち3件は、誤答から別の誤答へ予測先が変わっています。つまり、予測先が変わった13件は「改善5件・悪化5件・誤答から別の誤答3件」で構成されています。

改善5件と悪化5件がちょうど打ち消し合ったため、合計の正解数だけが9/18で並んでいました。下の図は、例なしから9例提示への18件の判定の移り変わりです。

実際の問い合わせ文で、判定が変わった文と誤答が続いた文を確認します。

たとえば「ログインは成功しましたが、一覧画面が空白です」は、ログイン自体は完了しており、いま解決したいことは画面表示の異常なので、正解は「2＝操作・不具合」です。この文は例なしでは誤答でしたが、9例提示では「操作・不具合」と正解できました。

逆に「二回お金が引き落とされているので返してほしい」は、正解が「0＝料金・請求」で、例なしでは「0」と正解しましたが、9例提示では「2＝操作・不具合」と誤答しました。見本を加えれば、すべての文の判定が良くなるわけではありません。

「ログインは問題ありませんが、請求の金額がおかしいです」（正解は「0＝料金・請求」）は、例なしでも9例提示でも「ログイン・認証」と誤分類されました。プロンプトに9件の見本を添えても、前半で別の話題を否定して後半で本題を述べる文をすべて正しく分類できるわけではありません。

なぜ5件が改善し、同時に5件が悪化したのかを調べるため、18件に対する予測先の件数を集計すると強い偏りが見えてきます。

「LLM（例なし）」の予測数は［料金・請求: 3、ログイン・認証: 14、操作・不具合: 1］でした。正解クラス別の内訳は、正解が「料金・請求」の6件に［2, 4, 0］、「ログイン・認証」の6件に［0, 6, 0］、「操作・不具合」の6件に［1, 4, 1］と、18件中14件を「ログイン・認証」と予測しています。

対して「LLM（9例を提示）」の予測数は［料金・請求: 0、ログイン・認証: 4、操作・不具合: 14］へ大きく移りました。正解が「料金・請求」の6件に［0, 1, 5］、「ログイン・認証」の6件に［0, 3, 3］、「操作・不具合」の6件に［0, 0, 6］となり、「料金・請求」を一度も選ばず、18件中14件を「操作・不具合」と予測しています。下の図と表は、予測数とクラス別の正解数です。

表の通り、合計は同じ9/18でも、クラス別の正解数は例なしの［2/6, 6/6, 1/6］から、9例提示では［0/6, 3/6, 6/6］へと逆転しています。「操作・不具合」の正解が1件から6件へ増えた（改善）一方で、「料金・請求」が2件から0件、「ログイン・認証」が6件から3件へ減った（悪化）ことが、5件の改善と5件の悪化の正体です。

なお、9例提示で「操作・不具合」へ14件も偏った理由としては、9例の並べる順序、例文の選び方、0・1・2 の番号の割り当てなどが原因候補に挙げられますが、今回の記録では条件を1つずつ変えた対照実験をしていないため、原因は切り分けていません。

サーバーCPUでのメモリ制限による停止と、推論時間の実測

CPUでの最初の実行は、モデルを読み込むデータ型とメモリ制限のために途中で止まりました。

初回は32ビット浮動小数点数（float32）で読み込もうとしたため、環境の約3GBのメモリ制限に達して停止しています。そこでCPUでの読み込み形式を16ビットの bfloat16 に変更したところ、メモリ内に収まり完走しました。

このサーバーCPU環境（bfloat16、2スレッド）で比較18件の分類にかかった推論時間は、「LLM（例なし）」が約135秒、「LLM（9例を提示）」が約300秒でした。モデルの取得やメモリへの読み込み時間は除いた記録です。

9例提示では、18件を1件ずつ判定するたびに9件分の見本文もプロンプトとして入力するため、入力トークン数が長くなり推論時間も増えています。下の図は、このCPU環境での18件の推論時間の記録です。

重みを学ぶ学習と、プロンプトに例を添える推論の違い

ここで、モデルの重みを更新する「学習」と、今回行った「プロンプトに例を添える推論」の違いを整理します。

言語モデルの事前学習やファインチューニング（追加学習）は、データを使ってモデル内部の重みを書き換える工程です。一方、今回の「9例を提示」は入力文字列の中に見本を並べただけで、Qwen/Qwen3-0.6B の重みは一切変更していません。プロンプトの文脈を参照しながら次に続くもっともらしいトークンを予測する仕組みを利用し、0・1・2 の数字1文字を生成させています。

今回のような分類では、合計の正解数に加えて、予測先ごとの件数と、同じ文の判定がどう変わったかを保存すると点検しやすくなります。正解が多かったクラスも、ほかのクラスを誤って引き受けていないか確認します。

記録には入力文、正解番号、プロンプト、生成された文字列、採点後の番号を残しています。判定が変わった文を探し、その文に渡したプロンプトと生出力を照らし合わせられる形です。

また、検証に使うデータの役割も分けて考える必要があります。今回比較した18件は教材作成者が内容を確認して用意した少数の固定データであり、盲検の未知データや実務での精度を示すものではありません。

比較用18件の誤答を見ながらプロンプトの文言や9例の選び方を何度も作り直すと、その18件だけに合わせた調整になります。データセットに調整用9件が用意されているのはこのためで、プロンプトや見本の試行錯誤は調整用データで行い、なぜ特定のクラスへ偏ったのかを調べる際は、例文の順序・番号・選び方を1つずつ変えてクラス別の予測数を確認する必要があります。

例の並びを変えて確かめる

共通ノートブックでは、①ライブラリ → ②共通設定（RUN_LLM=True） → ③データ → ④ルール → ⑧Qwen3 → ⑨保存の順に実行します。④には共通の評価関数があるため、LLMでも必要です。⑤〜⑦は飛ばせます。

初回はHugging Faceから約1.5GBのモデルファイルを取得します。有料APIキーは使いません。PyTorchがない環境では別途準備してください。保存時はtorch 2.8.0+cpuでした。

次に試すなら、9例の文面と分類番号を固定して、並べる順序だけを変えます。今回の予測の偏りが、順序・番号・例の選び方のどれによるかは切り分けていません。