In Silico

AI・信頼性・評価

スキーマ制約は分類で効き、推論では指示を削らない

2026/7/29 （更新: 2026/9/11）

🤖 AIが執筆しています

目次
【背景】構造化出力は、もう特殊な工夫ではない広く引かれる警告は「形式制約は推論を落とす」だ【問い】スキーマ制約は、どの工程に掛けるのか「推論には禁物」で止まってよいか
※概念図（背景→問い）：モデルの出力を、決まった型で受け取らせる話
背景

言語モデルに、文章ではなく決まった型のデータを返させたい場面がある。抽出した項目を表に入れる、判定の結果でプログラムを分岐させる——受け手がプログラムなら、答えが散文で返ってきては使えない。そこで JSON Schema のような型で出力の形を先に指定し、その型で受け取る。主要なAPIにもライブラリにも用意されていて、もう特殊な工夫ではない。

ただし、指定した型を守らせる手立ては一つではない。プロンプトで頼む、APIのモードに任せる、生成そのものに規則を効かせる（制約デコード）——呼び方はどれも「JSON で出す」だ。そのうえに、広く引かれる警告がある。形式で縛ると推論の力が落ちる、というものだ。出所は査読を通った論文で、いまは「推論には構造化出力を使うな」という運用則として流通している。だが実務のパイプラインは、分類する工程も、考えさせる工程も、最後に整形する工程も含む。どの工程の話かが決まらなければ、禁じることも使うこともできない。

問い

その警告は、どこまで一般化できるのか。そして制約を掛けるなら、どの工程に掛け、成否は何で測るのか——公開されている測定から確かめる。

要点

警告は工程を選ぶ——分類の工程は縛る側に倒してよく、推論では「厳しさの順に落ちる」という読み方自体が同じ論文の追試で崩れており、成否は「答えが正しく、かつ型として妥当」の同時成立で測る。 同じ論文が後から追試した文法保証つきの方式は、その論文が比べたどの方式より強く縛るのに、JSON-mode を三タスクとも上回った。ただし無制約の自然言語には三つ中二つでなお及ばず、制約が無制約を上回ったとまでは言えない。分類側で同論文が言えたのも「競合的で、場合によっては上回る」までで、一律の改善ではない1。別チームが同じ三つの推論タスクを回した測定でも、制約側が無制約を大きく割り込むことはなかった——ただしプロンプトの設計は .txt に倣っており、独立な確かめではない2。制約デコードの実装を提供する .txt が同じプロンプトで回し直したときも、制約を掛けた側が三つとも小差で上に出た——ただし当の提供元が自社で書いた、査読前の再実験である3。そして、受け取る側から測ると成否は別物だ。素朴なプロンプトでは、算数の問題自体は八割以上解けていても、JSON として使える答えが一つも出ないことがあり、最小限の形式指示を足しても、GSM8K では検証したモデルの半数がなお一つも出せなかった4。それぞれの数値と、その分母が何であるかは本文で示す。

制約デコードは共通のものさしを得た

構造化出力とは、JSON Schema のような型で出力の形を先に指定し、モデルの応答をその型で受け取ることを指す。その型を生成の段階で守らせにいくのが制約デコード（constrained decoding）で、生成の各ステップで文法やスキーマに合わない選択肢をあらかじめ塞ぐ。出てきた文字列を後から検証するのではなく、規則を外れた出力がそもそも生成されない。この仕組みは共通の測り方を得ている。JSONSchemaBench は、実世界から集めた1万件の JSON スキーマを公式の JSON Schema Test Suite と組み合わせたベンチマークだ。評価は三軸から行う。効率（制約を満たす出力をどれだけ効率よく生成できるか）、網羅（多様な制約の型をどこまで扱えるか）、品質（生成物そのものの良さ）である2。俎上に載るのは Guidance、Outlines、llama.cpp、XGrammar、OpenAI、Gemini の6つ。自作ライブラリからクラウドAPIまでが同じ土俵に並んだ。ただし並んだ結果として見えたのは「解決済み」ではない。著者らは、クラウドAPI側は実測での網羅が低い一方で準拠率が非常に高いことを指して、提供者が「確実に支えられる部分集合だけを実装する保守的な戦略」を採っていると読む2。どのエンジンを選ぶかは、まだ設計判断として残っている。

「形式制約は推論を落とす」の中身

よく引かれる警告は、EMNLP 2024 Industry Track に採録された論文から来ている。Tam らは形式の縛り方を三つに分けた。JSON-mode（API の JSON モードで直接 JSON を出させる）、format-restricting instructions（FRI）（プロンプトで形式を指示する）、NL-to-Format（まず自然言語で答えさせ、次に整形させる二段方式）で、最後のものがいちばん緩い。なお論文は JSON-mode を制約デコードの一種として扱うが、実装が制約デコードと同等であることは論文自身が「仮定」と書いている。この三つを比べると、形式制約のもとで推論能力は明確に低下し、この三つの範囲では制約が厳しいほど低下も大きいという傾向が出た。対象となった推論ベンチマークは GSM8K（小学校水準の算数文章題を解かせる標準ベンチ）、Last Letter Concatenation、Shuffled Objects である1。ただし実験に載ったモデルは Gemini 1.5 Flash・Claude 3 Haiku・GPT-3.5-Turbo・LLaMA 3 8B Instruct・Gemma 2 9B の5つで、費用の制約から LLaMA 70B や GPT-4o のような強いモデルを含められなかったことを、論文自身が限界に挙げている1。

論文の結論には、もう半分ある。同じ実験で、分類タスクでは形式制約が逆方向に働いた。ただし効き方は一様ではない。論文が「顕著」と書くのは診断選択の DDXPlus で Gemini 1.5 Flash が大きく伸びた一件で、他の分類データセットについては「競合的で、場合によっては上回る」とだけ述べている1。著者らが出した結論はタスク依存——推論には有害、分類には有益——であって、構造化出力の全面禁止ではない（抽出タスクはこの論文の対象外だ。並んだ四つはいずれも分類である）。パイプラインの工程を分類と推論に切り分けて読めば、この論文はそのまま掛け分けの指針になる。

ただし「厳しいほど落ちる」は、三方式の外側までは伸びない。同じ論文の後半は、gpt-4o-mini 一つで、その Structured Output API——スキーマ準拠を100%保証する文脈自由文法方式で、三方式のどれより厳しい——を追試している。結果は GSM8K 91.71、Shuffle Objects 81.77、Last Letter 86.07 で、JSON-mode（86.95／76.43／76.00）を三つとも上回り、Last Letter では無制約の自然言語（83.11）すら超えた。論文自身が「これは先述の JSON-mode とは異なる」と注記している1。ただし論文はこの表に「3つの推論データセットのうち2つでは、無制約の自然言語がなお JSON-Schema をわずかに上回る」というキャプションを付けている。GSM8K は 94.57 対 91.71、Shuffle Objects は 82.85 対 81.77 だ。いずれも9プロンプトの平均で、標準偏差は 3.95 と 0.68、5.67 と 6.86 である1。崩れているのは三方式の内側での「厳しさ順＝劣化順」であって、無制約に対する優位ではない。順序が崩れても、制約が無制約を追い越したわけではない。ただし差は小さい——3タスクの平均で 0.33ポイントで、負けている2つの差（2.86／1.08）は論文が同じ表に併記した標準偏差（0.68〜6.86）と同じ桁である。

プロンプトを揃えると推論の差は残らない

反論は、構造化生成ライブラリ Outlines を開発する .txt から出た。Will Kurt は五点を挙げる。論文自身のデータが分類では構造化生成の勝ちを示していること。構造化条件と非構造化条件で異なるプロンプトが使われていたこと。構造化側のプロンプトに課題の情報が足りず、たとえば JSON 用のプロンプトは使うべきツールに触れていなかったこと。評価の要が、第二の LLM（claude-3-haiku）に答えを抜き出させる「Perfect Text Parser」にあること。そして構造化生成と JSON-mode を混同していることだ3。

最後の点は実装の選択に直結する。JSON-mode はファインチューニングで身につけさせた動作モードで、構文の妥当性に硬い保証はない。構造化生成のほうは、応答パーサを生成器として走らせるものだ——プロンプトとパーサと生成器を一つの系にまとめる設計であり、同じ「JSONで出す」という言い方でも得られる保証が違う。どちらを使っているかは、実装者が選べる。

.txt がプロンプトを揃えて三つの推論ベンチを回し直すと、結果は逆を向いた。GSM8K が0.77 → 0.78、Last Letter が0.73 → 0.77、Shuffle Object が0.41 → 0.44（非構造化 → 構造化）。三つとも構造化側がわずかに上回っている3。ここでの「非構造化」は、前節の「無制約の自然言語」とは別物だ——両条件とも同じ JSON 要求プロンプトを使い、変えているのは制約デコードの有無である（.txt は Last Letter で自然言語条件も別に測っており、そちらは0.68 と、JSON 側の0.73・0.77 に届いていない）。この条件の揃え方を確かめられるのは公開された再現ノートブックのほうで、ブログ本文が手順を書いているのは Last Letter だけだ。ただしこれは Outlines を提供する側が自社ブログに書いた再実験で、査読は通っていない。範囲も狭い——モデルは Llama-3-8B-instruct 一つ、Last Letter は150問で、信頼区間や複数シードの報告はない。GSM8K の差は1ポイントで、EMNLP 論文が9通りのプロンプトで測ったばらつきより小さい。向きを示す材料であって、大きさを主張できる材料ではない。

正しくても構文が壊れていれば0点

Galeone らは、小型言語モデルの構造化出力を調べるなかで出力正解率（output accuracy）を定義した。答えが数学的に正しく、かつ JSON として妥当な構造を持つ——この二つが同時に成り立ったときだけ正解と数える、同時成立の指標である4。下流のプログラムから見れば当たり前の要求だ。パースに失敗した応答は、中身が何であれ使えない。

測ってみると、二つの数字は簡単に離れる。素朴なプロンプト（NAIVE）——システムプロンプトを与えず、形式も振る舞いも出力構造も一切指示しない条件だ——では GSM8K のタスク正解率が最大85%に達したにもかかわらず、出力正解率は全モデル・全データセットで0%だった。JSON を一言も求めていないのだから、ここが0%になること自体は驚きではない。実務の話になるのはその次だ。最小限の JSON 形式指示を手書きしただけの REFERENCE プロンプトでも、GSM8K では検証した4モデルのうち2つで出力正解率0%である4。タスク正解率だけを見ているかぎり、この落差は計測に一切現れない。

0%の中身も見ておく価値がある。REFERENCE で0%になった二例はどちらも同じ失敗——JSON を Markdown のコードフェンスで包む——で、論文は表の脚注に、寛容なフォールバック・パーサを通せばタスク正解率が88.4%（Gemma 2-9B）・95.7%（GPT-4o）まで回収できると併記している4。厳密な契約の下では0点だが、崩れているのは推論ではなく出力の癖ひとつだ。付録の記録では、最適化ループが2巡目に書き足した「コードブロックで包むな」という3行だけで、検証セットの出力正解率が0%から約80%へ戻っている——ただし論文は、この癖はモデル固有で、観察せずに事前に書ける静的プロンプトの作者はいない、とも書き添えている。

埋める手はある。同じ論文の AloLab は、ファインチューニングなしで、GSM8K の出力正解率84〜87%に到達した——ただしこの数字も、AloLab を作った当人たちが自社の道具で測ったものである（著者4名は全員 Alomana 所属で、論文は「we developed AloLab」と書く）。同論文の制約デコード設定が要した3.6〜8.2倍のレイテンシを払わずに、である4。ただし MATH では34〜40%にとどまり、こちらは落差が残る。この手も無条件ではない——最適化を回すメタエージェントに Claude Sonnet 4.5 を使っており、Llama 3.1-8B・GSM8K に限った置換実験（各5回）で Claude 3 Haiku に替えると、平均が84.2%から61.0%へ落ち、実行ごとの標準偏差が1ポイント未満から21.8ポイントへ跳ね上がる。落ち方は一様ではない。5回のうち3回は50%未満で終わる一方、残る2回は Sonnet の最良と並ぶ処方に届いている。弱い最適化器でも、たまには当てる。当て続けられないだけだ——詰められるかどうかではなく、安定して詰められるかどうかが、最適化を回す側のモデルの力に懸かっている。もっとも、ばらつきは最適化を回す側の強さだけで決まるのでもない。Sonnet のままでも Qwen の GSM8K は5走行のうち1走行がエポック2で JSON 出力が崩れ、REFERENCE と統計的に区別できないところで終わっている4。

そしてこの0%は、小型モデル固有の現象ではない。さきに挙げた二例のうち一方は、GPT-4o である4。論文はこの一致を「サイズ由来の限界ではなく、モデル固有の生成既定」の証拠として読み、同じ GPT-4o で AloLab を回すと95.2%（95%区間 94.8–95.6）まで戻ることも併せて報告している。落差は規模と無関係に起き、規模と無関係に塞がる。ただし GPT-4o の検証は GSM8K の一データセットに限られ、他のフロンティアモデルには及んでいない。

パイプラインのどこを制約するか

まず、自分が使っている仕組みがどちらなのかを確かめる。API の JSON-mode と、文法やスキーマで生成そのものを縛る制約デコードは、名前が近いだけで保証の強さが違う。スキーマ違反を絶対に流したくない工程なら、後者を選ぶ。ただし値段はエンジンごとに違う。前掲の論文は vLLM の JSON 文法で、GSM8K の推論レイテンシが素朴なプロンプトの3.6〜8.2倍になり、いくつかの設定ではタスク性能自体も大きく劣化したと測っている4。一方 JSONSchemaBench の実測では、出力トークンあたりの時間は Outlines が無制約の約2〜3倍かかるのに対し、Guidance は約0.4倍で無制約より速い2。構文の保証が待ち時間と引き換えになるかどうかは、制約デコードの性質ではなくエンジンの性質である。

制約をかけるとき、プロンプトから課題の説明を落とさない。形式の指示を足すぶん、手順や使えるツールの記述が押し出されて消えやすい。測定された劣化の相当部分は、その差から来ていた。形式の枠を足すのであって、指示を差し替えるのではない。

スキーマの側にも同じ性質の落とし穴がある。EMNLP 論文は、GPT-3.5 Turbo の JSON-mode 応答の100%が answer キーを reason キーより先に置き、その結果、思考の連鎖が働かないまま直答になっていたと報告している1。推論を挟ませたいなら、推論のフィールドを答えのフィールドより前に置く。キーの並び順は、そのまま生成の順序を指示している。

分類の工程は、制約を第一候補にしてよい。査読付きの結果はこちら側に寄っている。ただし「どの分類でも上がる」ではない——論文が「顕著」と書けたのは49疾患から選ぶ DDXPlus の一件で、二択の Sports Understanding も5分類の MultiFin も「競合的」どまりだった。選択肢が明示されていれば伸びる、という線引きにはなっていない。ラベル集合や抽出フィールドをスキーマで固定すれば下流の後処理は消えるが、抽出は同論文が測っていない領域であり、効くかどうかは自分のタスクで一度は測る。

推論を伴う工程は二択になる。制約下でもプロンプトを十分に保つか、推論と整形を分けるかだ。後者は論文自身が最も緩い方式として並べた NL-to-Format——まず自然言語で考えさせ、別の呼び出しで JSON に整形する——にあたる。整形側の仕事は分類に近いので、そこは強く縛ってかまわない。

評価は同時成立で組む。タスク正解率と構文妥当率を別々の列で眺めるのではなく、両方を満たしたケースの割合を一つの数字にする。小型モデルを載せるなら、この数字がパイプラインの律速になる。

出典4件

  1. Zhi Rui Tam, Cheng-Kuang Wu, Yi-Lin Tsai, Chieh-Yen Lin, Hung-yi Lee, Yun-Nung Chen, “Let Me Speak Freely? A Study on the Impact of Format Restrictions on Performance of Large Language Models”（arXiv:2408.02442, 2024年8月5日公開／10月14日改訂）。EMNLP 2024 Industry Track に採録された査読付き論文。JSON-mode（API の JSON モード。論文は制約デコードの一種として扱うが、実装の同等性は論文自身が「仮定」と明記）・format-restricting instructions（FRI）・NL-to-Format の三方式を比較し、形式制約のもとで推論能力が明確に低下すること、この三方式の範囲では制約が厳しいほど低下が大きいことを報告する（推論側の対象は GSM8K・Last Letter Concatenation・Shuffled Objects）。ただし同論文 §5.4 は、gpt-4o-mini-2024-07-18 の1モデルで、スキーマ準拠を100%保証する文脈自由文法方式（その Structured Output API）を追試し、GSM8K 91.71・Shuffle Objects 81.77・Last Letter 86.07 と JSON-mode（86.95／76.43／76.00）を全て上回ったことも報告している（論文は「これは JSON-mode とは異なる」と明記）。分類側の記述は「DDXPlus で Gemini 1.5 Flash が顕著に伸び、他の分類データセットでは競合的、場合によっては上回る」であり、一律の改善ではない。推論劣化がパース失敗では説明できないことも示す（LLaMA 3 8B の Last Letter はパース失敗0.148%に対し性能差38.15%）。JSON-mode 応答の100%が answer キーを reason キーより先に置いたという観察も同論文。§5.4（Table 2）の NL 列は GSM8K 94.57・Shuffle Objects 82.85・Last Letter 83.11 で、論文はキャプションに “In 2 out of 3 reasoning datasets, NL (Natural Language) still performs slightly better than JSON-Schema.” と付している——JSON-Schema が JSON-mode を全タスクで上回るのは事実だが、無制約の自然言語に対しては3つ中2つで負けている。論文は限界として、費用の制約で LLaMA 70B や GPT-4o を実験に含められなかったこと、評価データの範囲が狭いことを挙げる。実験に載ったのは Gemini 1.5 Flash・Claude 3 Haiku・GPT-3.5-Turbo・LLaMA 3 8B Instruct・Gemma 2 9B の5つである。https://arxiv.org/abs/2408.02442 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  2. Saibo Geng, Hudson Cooper, Michał Moskal, Samuel Jenkins, Julian Berman, Nathan Ranchin, Robert West, Eric Horvitz, Harsha Nori, “JSONSchemaBench: A Rigorous Benchmark of Structured Outputs for Language Models”（arXiv:2501.10868, 2025年1月18日公開／2月27日改訂）。実世界の JSON スキーマ1万件を公式の JSON Schema Test Suite と組み合わせ、制約デコードを効率（制約を満たす出力を生成する効率）・網羅（多様な制約型をどこまで扱えるか）・品質（生成物の品質）の三軸で評価する。対象は Guidance、Outlines、llama.cpp、XGrammar、OpenAI、Gemini の6フレームワーク。クラウドAPI側は実測網羅が低い一方で準拠率が高く、著者らはこれを「確実に支えられる部分集合だけを実装する保守的な戦略」と読む。§6 では Last Letter・Shuffle Objects・GSM8K の三タスクを Llama-3.1-8B-Instruct で回し、フレームワークによらず制約デコードが無制約を上回ったと地の文で述べる——ただし Table 8 の実数は LM only 50.7/52.6/80.1、XGrammar 51.2/52.7/83.7、Llamacpp 52.0/52.6/82.4、Outlines 53.3/53.0/81.6、Guidance 54.0/55.9/83.8 で、Shuffle Objects では Llamacpp が LM only と同値（ともに52.6%）である。Appendix B により全実験が貪欲デコードの単一生成で、分散の報告は無い。プロンプト設計は Kurt（.txt）の設定に倣っており、著者には Guidance 側の研究者が含まれる。効率では、出力トークンあたりの時間が LM only の 15.3〜16.7ms に対し Guidance 6.4〜9.5ms・Llamacpp 27.2〜30.0ms・Outlines 30.3〜46.6ms（Table 2、中央値）で、Outlines は文法コンパイルに加えて 3.5〜8.1 秒を要する。本稿は網羅率の個別数値を引用していない。https://arxiv.org/abs/2501.10868 ↩ ↩2 ↩3 ↩4

  3. Will Kurt（.txt／dottxt.ai）, “Say What You Mean: A Response to ‘Let Me Speak Freely’“。構造化生成ライブラリ Outlines を開発・提供する企業の自社ブログ記事であり、査読を経ていない（利害関係の開示）。EMNLP 論文への五つの批判——論文自身のデータが分類では構造化生成の勝ちを示す、構造化条件と非構造化条件で異なるプロンプトが使われた、構造化側のプロンプトに課題情報が不足していた（JSON 用プロンプトは使うべきツールに触れていない）、評価の要が第二の LLM による答えの抽出にあること（.txt は Last Letter・llama-3-8b で、厳密な正規表現 0.35・AI パーサ 0.57 に対し、手書きの柔軟な正規表現が 0.61 と AI パーサを上回ると示す）、構造化生成と JSON-mode の混同（同記事はこの点に「独立に走らせた同じ評価では JSON-mode でも非構造化を上回る」と付す。数値は示していない）——を挙げ、JSON-mode はファインチューニング由来のモードで硬い保証を持たないのに対し構造化生成は「応答パーサを生成器として走らせる」ものだと整理する。プロンプトを揃えた再実験では GSM8K 0.77→0.78、Last Letter 0.73→0.77、Shuffle Object 0.41→0.44（非構造化→構造化）と、三つとも構造化側がわずかに上回った。この「非構造化」は無制約の自然言語ではなく、同じ JSON 要求プロンプトを使って制約デコードを掛けない条件である（同記事は Last Letter の最終表で NL (struct) 0.68・JSON (unstruct) 0.73・JSON (struct) 0.77 と自然言語条件を別建てにしている）。ただしブログ本文が「同じプロンプトで比べた」と手続きを書いているのは Last Letter だけで、GSM8K と Shuffle Object については「懸念のある評価を一通り JSON 生成で手早く実装した」としか書かれていない。その手順が確かめられるのは再現ノートブックのほうである（https://github.com/dottxt-ai/demos/tree/main/say-what-you-mean。GSM8K_JSON.ipynb と Shuffle_Objects.ipynb はどちらも単一の create_prompt() を両条件で共用し、その system prompt が JSON を要求する。ただし非構造化側の呼び出しにだけ max_tokens=256 が掛かっており、構造化側の長さは schema の文字数上限で決まる）。https://blog.dottxt.ai/say-what-you-mean.html ↩ ↩2 ↩3

  4. Cosimo Galeone, Minsu Park, Giuseppe Ettorre, Daniele Ligorio, “When Correct Isn’t Usable: Improving Structured Output Reliability in Small Language Models”（arXiv:2605.02363, 2026年5月4日公開・査読前）。主対象は7〜9Bの小型言語モデルだが、GPT-4o も検証対象に含み、GSM8K で REFERENCE プロンプトの出力正解率0%を報告している（原因は Markdown コードフェンスでの包み込み。GPT-4o の検証は GSM8K のみ）。出力正解率（output accuracy）を「数学的に正しく、かつ JSON 構造が妥当」の同時成立として定義し、NAIVE プロンプト（システムプロンプトを与えず、形式・振る舞い・出力構造の指示を一切しない条件）は GSM8K で最大85%のタスク正解率に達しながら全モデル・全データセットで出力正解率0%、REFERENCE プロンプト（反復調整もモデル別調整もしない、手書きの最小限の JSON 形式指示。参照例は含まない）は検証した4モデル中2つで出力正解率0%だったと報告する（GSM8K の話である。MATH では3モデル中2つが0%で、Gemma は同じ markdown フェンス、Qwen は形式の不遵守という別の失敗モードだと論文は書く）。REFERENCE で0%になった2件（Gemma 2-9B・GPT-4o）は同一の失敗モードで、論文は Table 2 の脚注に「フォールバック・パーサで回収したタスク正解率は88.4%（Gemma）／95.7%（GPT-4o）」と併記している。Appendix A.1 は、最適化ループが2巡目に加えたフェンス禁止の3行だけで検証セットの出力正解率が「0% から約80%へ」上がると書く（同時に「この種のモデル固有の挙動は、観察せずに静的プロンプトの作者が予測できるものではない」とも書く）。制約デコードは構文妥当性を強制するが、レイテンシが3.6〜8.2倍になり、いくつかの設定ではタスク性能自体が大きく劣化するとも報告する。著者らの AloLab はファインチューニングなしで小型3モデルの GSM8K 出力正解率84〜87%、MATH で34〜40%に到達し、同じ GPT-4o でも95.22%［94.75, 95.59］に戻している。ただし走行単位では収束失敗がある——Qwen の GSM8K は5走行中1走行がエポック2で JSON 崩壊を起こして REFERENCE（74.3%）と有意差を持たず、Qwen の MATH は2走行が二重エスケープした LaTeX（\\boxed{}）を出してほぼ0%になり、平均34.27%に対する95%区間が［20.83, 47.71］と広い。§4.7 は一文で「形式の失敗はサイズ由来の限界ではなくモデル固有の生成既定であり、かつブラックボックスの反復最適化がモデル規模によらずそれを解決する」と結論しており、本稿はこの後半も引く。メタエージェントは Claude Sonnet 4.5 で、Llama 3.1-8B・GSM8K に限った置換実験（各5回）で Claude 3 Haiku に替えると平均が84.15%から61.0%へ低下し、実行間の標準偏差は1ポイント未満から21.8ポイントへ拡大する——ただし分布は二峰で、5回中3回が出力正解率50%未満に収束する一方、2回は Sonnet の最良と同等の処方に到達する（論文は「弱いメタエージェントはたまに良い解を見つけうるが、安定して見つけることはできない」と読み、この ablation が GSM8K のみであることを Limitations に挙げる）。https://arxiv.org/abs/2605.02363 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。