🤖 AI

Format Sensitivity Index: Token-Controlled Prompt Wrapper Robustness and Schema Compliance in LLM Benchmarking

本論文は、プロンプトのラッパーにおける些細なフォーマットの違いが、モデル依存的に大幅なスコアの変動やコンプライアンスの失敗を引き起こすことを示すために、フォーマット感度指数（FSI）および解析可能性感度指数（PSI）を導入し、この分散を考慮せずにベンチマークの正確性を評価することは統計的に脆弱であると論じている。

原著者： Deep Pankajbhai Mehta

公開日 2026-07-14

📖 1 分で読めます☕ さくっと読める

CC0 1.0

原著者： Deep Pankajbhai Mehta

原論文は CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/) のもとパブリックドメインに提供されています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

あなたは、あるオーディション番組の審査員になったと想像してください。ただし、あなたは歌手の声を聞くのではなく、歌詞だけを読むことが許されています。さらに、ある歌手には普通の紙に歌詞を書くよう指示され、別の歌手には豪華で硬いJSONボックスの中に書くことを強制され、また別の歌手には「BEGIN/END」という特定のサンドイッチで言葉を包むように命じられたとします。

歌詞の書き方が変わったからといって、歌手の才能が変わることはないはずですよね？紙の種類が変わっても、歌の内容は変わらないはずです。しかし、AdobeのDeep Pankajbhai Mehtaによるこの研究によれば、AIモデルではまさにそのことが起こります。「紙」（プロンプトのラッパー）の影響があまりにも大きいため、リーダーボード（順位表）が完全にひっくり返り、天才が初心者に見え、初心者が天才に見えてしまうことさえあるのです。

フォーマットによる大激変
研究者たちは大規模な実験を行い、4つの異なるAIモデル（70億から720億の「脳細胞」を持つもの）を用いて、7つの異なる質問回答タスクから14万個の回答を生成しました。彼らは5つの異なる「ラッパー」スタイルをテストしました：

プレーン（Plain）: 回答のみ。
JSON: 厳格なコンピュータコード形式。
構造化（Structured）: キーと値のペア。
デリミタ付き構造化（Structured with Delimiters）: <BEGIN ANSWER> のような特殊なタグが付いたキーと値のペア。
デリバレート（Deliberate）: 回答の前に思考プロセス（スクラッチパッド）を置く形式。

結果として、モデルはこれらのフォーマット規則に対して非常に敏感であることが分かりました。あるモデル、Phi-4は、ラッパーを変えるだけで精度が0.763も跳ね上がるという、極めてドラマチックな動きを見せました。対照的に、巨大なQwen-2.5-72Bは、変動幅がわずか0.024という、落ち着いたロックスターのような安定感を見せました。

「これ、読めるの？」問題
なぜスコアが変わったのでしょうか？論文は、AIが突然賢くなったり愚かになったりしたわけではないと示唆しています。それは主にコンプライアンス（遵守）の問題でした。

これは、コインしか受け付けない自動販売機のようなものです。もしあなたが（たとえそれが有効な1ドル札であっても）1ドル札を投入しようとしたら、機械はそれを拒否します。この研究では、AIが厳格なJSONルールに従おうとした際、誤ってマークダウンのコードフェンス（``` のような記号）を付けてしまった場合、機械（回答抽出器）がそれを読み取ることができませんでした。その回答は「解析不能（unparseable）」と判定され、不正解としてカウントされました。

データは強い相関を示しています。AIが「解析可能（parseable）」でなくなったとき、その精度はしばしばゼロ近くまで急落しました。厳格なJSONラッパーを使用した場合のPhi-4モデルは、生成された回答の85.3%がマークダウンのコードフェンスで始まっており、その結果、解析可能性はわずか2.8%、精度は**0.7%となりました。研究者たちは、「解析可能性」が成功の強力な予測因子であることを発見し、モデルやタスクによる差異を考慮した後でも、スコアの残りの差の約82%**を説明できることを明らかにしました。

これが将来に意味すること
この論文は、AIの単一の精度数値を報告することは、華氏か摂氏かを言わずに気温だけを報告するようなものであり、誤解を招くと主張しています。ラッパーの選択によってスコアが0.76も変わるのであれば、その単一の数値は「統計的に脆弱」です。

著者らは、AIをテストする際、一つのラッパーを選んであとは祈る、というようなやり方をしてはいけないと提案しています。代わりに、以下のことを行うべきです：

スコアの範囲を報告すること（「感度指数」のように）。
回答が実際に解析可能であるかを確認すること。
実世界のアプリケーションで厳格なフォーマットを使用する場合は、プロンプトによってではなく、デコーダー（テキストを生成する部分）によってAIがルールに従うよう強制されているか注意すること。

結論
この研究は、AIが壊れていると言っているのではなく、私たちの「物差し」がグラグラしていると言っているのです。「フォーマット感度指数（FSI）」と「解析可能性感度指数（PSI）」は、モデルのスコアがラッパーにどれほど依存しているかを測定するための新しいツールです。研究結果は、一部のモデルにとって、ラッパーの選択はモデル自身の知能よりも重要であることを示唆しています。これを修正しない限り、リーダーボード上の「最高の」AIとは、単にテストを作成した人が作った特定のフォーマットスタイルを、たまたま好んでいただけのAIになってしまうかもしれません。

技術要約：フォーマット感度指数とトークン制御プロンプト・ラッパー

問題提起

大規模言語モデル（LLM）のベンチマークは、出力構造化のためにデリミタ、JSON指示、またはステップ・バイ・ステップのフォーマットを含むプロンプト・ラッパー（テンプレート）への依存を強めている。これらは意味論的には無関係である意図で用いられるが、研究論文、ツールキット、またはベンダー間で標準化されていることは稀である。この標準化の欠如は、手法上の失敗モードを生み出す。すなわち、モデルの報告された性能が、基礎的な能力ではなく、単にラッパーの選択によって大きく変動してしまうという問題である。

核心となる問題は、多くのベンチマーク・パイプラインが、モデルごとのタスクに対する単一の精度スコアを報告しており、実世界のデプロイメントで支配的となる構造化出力の失敗モード（例：スキーマ遵守、ツール呼び出し）を無視している点にある。モデルがベンチマークの抽出器（例：マークダウンのコードフェンスや欠落したJSONキーによるもの）に従って出力を解析できなかった場合、その実行は「不正解」としてスコア化される。この「コンプライアンス問題」により、厳格なJSONラッパーの下ではモデルがランダムに近い性能に見える一方で、デリミタベースのラッパーの下では良好に動作する場合があり、結果としてリーダーボードの結論が逆転する可能性がある。

手法

著者らは、プロンプトの長さとトークン数の違いによる交絡を制御するために、ラッパーのフォーマットに起因する分散を分離するトークン制御プロトコルを提案している。

実験設定

モデル: OpenRouter経由でアクセスされた、パラメータ数7Bから72Bにわたる4つのインストラクト・チューニング済みモデル：Mistral-7B-Instruct-v0.3、Gemma-2-9B-IT、Phi-4、および Qwen-2.5-72B-Instruct。
タスク: 幅広く使用されている7つのQA形式ベンチマーク（BoolQ, PIQA, ARC-Challenge, HellaSwag, WinoGrande, CommonsenseQA, GSM8K）を用い、各タスクにつき200個の例をサンプリング。
ラッパー・ファミリー: 以下の5つの異なるラッパー・タイプを評価：
1. Plain (プレーン): 最小限の指示。
2. JSON: answerフィールドを持つ厳格なJSON。
3. Structured (構造化): キー値ペア。
4. Structured Delim (構造化デリミタ): 明示的なデリミタ・トークン（<BEGIN ANSWER>）を伴うキー値ペア。
5. Deliberate (意図的): 推論のためのスクラッチパッド（思考プロセス）に続いて、最終回答フィールドが続く形式。
トークン制御: プロンプトの長さの違いによる混乱を軽減するため、プロンプトはタスクごとに固定の文字予算に合わせてパディングされた。実現されたトークン数はログに記録され、相対的なトークン拡散指標（ $\Delta_{tok}$ ）が計算された。結果は全データセット、および $\Delta_{tok} \le 5\%$ でフィルタリングされた一致サブセットの両方で報告された。
生成: 合計140,000回の生成が行われた（4モデル $\times$ 7タスク $\times$ 5ラッパー $\times$ 200例 $\times$ 5シード）。

指標

論文では、2つの主要な感度指標を導入している：

フォーマット感度指数 (Format Sensitivity Index: FSI): 特定のモデルとタスクにおける、ラッパー選択によって誘発される精度の範囲（ $FSI = \max_f A_{m,t,f} - \min_f A_{m,t,f}$ ）。
解析可能性感度指数 (Parseability Sensitivity Index: PSI): 対応する回答の解析可能性の範囲（ $PSI = \max_f P_{m,t,f} - \min_f P_{m,t,f}$ ）。

範囲統計のノイズ感度に対処するため、著者らは**正規化FSI (nFSI)**とブートストラップ信頼区間も報告している。

主な結果

1. モデル間における極端な分散

フォーマット感度はモデル間で鋭く変化する。

Qwen-2.5-72Bは、平均FSI 0.024（95% CI [0.014, 0.035]）を示し、フォーマット不変性に近かった。
Phi-4は高い感度を示し、平均FSI 0.763（95% CI [0.607, 0.872]）であった。
平均FSIは、テストされたモデル間で30倍以上の差があった。
正規化感度（nFSI）はこの対比を強調しており、Phi-4のnFSIは2.37であり、ラッパーの選択が平均スコアを支配し得ることを示している。

2. 主要な駆動要因としての解析可能性

精度と解析可能性は強く相関している（ $r = 0.825$ ）。固定効果回帰分析（ $A_{m,t,f} = \beta P_{m,t,f} + \alpha_m + \gamma_t + \delta_f + \epsilon$ ）により、解析可能性が精度の強力な予測因子であることが明らかになった（ $\hat{\beta} = 0.819$ ）。これは残差分散の大部分（ $R^2 = 0.82$ ）を説明している。

ケーススタディ: 厳格なJSONラッパーの下で、Phi-4は生成の85.3%においてマークダウンのコードフェンスを出力し、その結果、解析可能性は2.8%、精度は0.7%となった。
これは、多くのラッパー起因のスコア変化が、推論能力の欠如ではなく、出力が機械処理可能（解析可能）であるかどうかに起因することを示唆している。

3. ラッパーのパフォーマンス分布

普遍的に最適な単一のラッパーは存在しない。デリミタベースの構造化ラッパーが最も頻繁に勝利したが（28のモデル・タスクの組み合わせのうち12）、"deliberate" および "structured" ラッパーも無視できない頻度で勝利した。これは、単一の「最良」の形式を選択するのではなく、スコアの分布を報告すべきであるという主張を支持している。

4. トークン制御の安定性

トークン・パディング・プロトコルは、トークン拡散を減少させたが、完全には排除できなかった。中央値の相対トークン拡散は4.1%であった。決定的なことに、低トークン拡散（ $\Delta_{tok} \le 5\%$ ）でフィルタリングしても結論は安定しており、平均FSIは0.391から0.394へとわずかに変化したのみであった。

意義と推奨事項

本論文は、ラッパーの分散とコンプライアンスを考慮せずに精度を報告することは、統計的に脆弱であると主張している。著者らは以下の推奨事項を提示している：

ベンチマークに向けて: 論文やリーダーボードは以下を報告すべきである：
1. 使用された特定のラッパー・ファミリー。
2. プロンプトのトークン数。
3. 解析可能性の割合。
4. 不確実性を考慮した感度指標（例：FSIと信頼区間）、または精度の区間 $[\min_f A, \max_f A]$ 。
構造化出力のデプロイメントに向けて: プロンプティングだけでは、厳格なスキーマに対して不十分な場合が多い。ダウンストリームの消費者が脆弱な場合、解析可能性の崩壊が測定された精度を支配する可能性がある。著者らは、FSIとPSIを診断として使用し、デコーダー時の制約（例：グラマー、スキーマ制約付きデコーディング、またはベンダーの構造化出力モード）が必要かどうかを判断することを提案している。

限界

著者らはいくつかの限界を認めている：

FSIは範囲統計量であり外れ値の影響を受けやすいが、ブートストラップ法によって緩和されている。
トークン制御は、厳密なトークン等価化ではなく、文字パディングによって達成された。
モデルセットは小さく、スケールが混在しているため、堅牢性はアーキテクチャだけでなくモデルサイズを反映している可能性がある。
本研究はシングルターンのQAに焦に特化しており、マルチターンでのツール利用やコード生成では異なるダイナミクスを示す可能性がある。
パーサーの厳格さは様々である。本研究は厳格および正規化された抽出について報告しているが、デコーディング時の強制モードを直接ベンチマークしたものではない。

結論として、本論文は、信頼できるベンチマークと構造化出力システムには、プロンプト・ラッパーを重要な、かつ報告不足の交絡因子として扱い、フォーマット感度を測定し、しばしば低減させることが必要であると断じている。