It's Not the Size: Harness Design Determines Operational Stability in Small Language Models

本論文は、小規模言語モデル（20 億〜30 億パラメータ）において、構造化された 4 段階のハーネスパイプラインが、運用の安定性とタスクの成否において、生のプロンプトや最小限のラッパーを大幅に凌駕することを示すとともに、不十分な足場付けが特定のモデルにおいて構造的な形式崩壊を招きうることを明らかにする。

要約

非常に賢いものの、少しぼんやりしたアシスタントがいると想像してください。このアシスタントは小さく（「2B」または「3B」の脳サイズしか持っていません。AI 用語では「Small Language Models（小規模言語モデル）」を意味します）、レポート作成、ウェブ検索、多段階の指示の遂行など、一連の複雑な仕事をこなしてほしいと願っています。

この論文が問いかけるのは単純です：このアシスタントに指示を与える方法が、アシスタントの「賢さ」よりも重要でしょうか？

答えは明確な**「はい」**です。著者たちは、指示を与える方法を「ハーネス（馬具）」と呼びます。馬に装着する道具を想像してください。速い馬であっても、手綱と口輪（ハーネス）を与えなければ、その馬は円を描いて走り回ったり、疲れ果てたり、命令を無視したりするかもしれません。

以下は、日常の比喩を用いた彼らの実験と発見の概要です：

1. 指示を与える 3 つの方法（ハーネス）

研究者たちは、これらの AI アシスタントに話しかける 3 つの異なる方法をテストしました：

• 「生プロンプト（モデルのみ）」：これは、アシスタントが昼食を食べている間に、「ねえ、レポートを書いて！」と任務を叫ぶようなものです。構造もルールもなく、生々しい要求だけです。
• 「最小限のシェル（ラッパータグ）」：これは、タスクを「TASK START」と「TASK END」と書かれたラベル付きの高級な箱に入れるようなものです。整然として見えますが、実際にはアシスタントが手順を考え抜くのを助けるわけではありません。
• 「4 段階パイプライン（完全なハーネス）」：これは、アシスタントに詳細なチェックリストを与えるようなものです：
  1. 計画（Plan）：「まず、何をする必要があるか考えなさい。」
  2. 実行（Execute）：「さあ、作業を遂行しなさい。」
  3. 検証（Verify）：「作業を確認しなさい。間違いはありましたか？」
  4. 回復（Recover）：「間違いがあれば、修正して再挑戦しなさい。」

2. 大きな驚き：「より多くの助け」が時に「より少ない助け」になる

研究者たちは、奇妙で直感に反する発見をしました。

2 つのモデルにおいて、「最小限のシェル」（高級な箱）は、実際には「生プロンプト」よりもアシスタントのパフォーマンスを低下させました。

• 比喩：友人にケーキを焼いてほしいと頼む状況を想像してください。「ケーキを焼いて」と言うだけであれば、それなりに良い出来になるかもしれません。しかし、小麦粉を混ぜる前に埋めるべきボックスがある、硬直して混乱するフォームを彼らに手渡せば、彼らは圧倒され、レシピを忘れ、ケーキを焦がしてしまうかもしれません。
• 結果：追加の「ラッパータグ」は、小さなモデルを混乱させる精神的な雑音（認知的負荷）を加え、単純な命令を与えられた場合よりも、タイムアウトしたり失敗したりする頻度を高めました。

3. 「足場崩壊（Scaffold Collapse）」（アシスタントが形式を放棄する時）

最も興味深い発見の一つは、LLaMA 3.2モデルに関わるものでした。

• 状況：特定の形式（JSON リストなど）でレポートを書くよう求められた際、このモデルはしばしば混乱し、ルールを無視して通常の段落を書いてしまいました。
• 用語：著者たちはこれを**「足場崩壊（Scaffold Collapse）」**と呼びます。
• 比喩：レンガを積むこと（コンテンツ生成）は得意だが、設計図（形式）を使うことを忘れ続ける建設作業員を想像してください。彼らの頭上で「設計図を確認しなさい、間違って建てているぞ」と言う監督者（ハーネス）がいなければ、彼らは自分の気分次第で何でも建ててしまいます。ハーネスはレンガを積む技術を向上させたわけではありません。彼らを設計図に従わせるだけだったのです。

4. なぜ「4 段階パイプライン」が勝ったのか

完全なパイプライン（計画→実行→検証→回復）は、特に複雑なタスクにおいて明確な勝者でした。

• 計画：これは「精神的な錨」として機能しました。モデルが書き始める前に、「計画」ステップは制約（例：「200 文字以内に収める」など）を思い出すようモデルに強制しました。このステップがなければ、モデルは制限を忘れ、長編小説を書いてしまいます。
• 回復：これは安全網でした。モデルが詰まったり、タイムアウトしたりした場合、「回復」ステップが再挑戦を可能にしました。
• 結果：完全なパイプラインを使用することで、モデルはほぼ完璧な成功率（95% 以上）を達成しましたが、それなしでは大幅に苦労しました。

5. 「検証」の落とし穴

研究者たちはまた、「検証」ステップがどれほど頻繁に間違いを捕捉したかも測定しました。

• 統計：システムは約**62.5%**の誤りを捕捉し、修正しました。
• 落とし穴：時として、「検証」ステップはだまされました。例えば、モデルに文字数を数えるよう求められた場合、モデルは間違った数を推測し、検証者もまた間違った数を推測して、作業が完了したと誤って判断することがありました。

6. 「ツール」の問題（実験の欠陥）

この論文には、AI がウェブを検索するタスクが含まれていました。

• 問題点：「生（Raw）」および「最小限（Minimal）」バージョンの AI は、検索ツールへのアクセスが全くなく、自動的に失敗しました。「パイプライン」バージョンはツールを持っていましたが、検索エンジン（DuckDuckGo）が質問を速すぎるとしてブロックしたため、失敗しました。
• 教訓：著者たちは、このテストの一部が欠陥があったと認めています。なぜなら、彼らは「良いハーネス」対「悪いハーネス」を比較するのではなく、「ツールを持っている」対「持っていない」を比較していたからです。

まとめ：これは何を意味するか

主な教訓は単純です：小規模な AI モデルにとって、タスクをどのように構成するかは、モデルのサイズよりも重要です。

• 過度に複雑にしないこと：高級なラベル（最小限のシェル）を追加することは、助けるどころか、小さなモデルをより混乱させることがあります。
• 構造が鍵：タスクを「計画、実行、確認、修正」に分解することで、「小さな」脳であっても複雑な仕事を確実にこなすことができます。
• ハーネスが主役：「ハーネス（指示のシステム）」は、間違いを修正する安全網として、そして間違いを未然に防ぐガイドとして機能します。

この論文は結論として、小規模で効率的な AI モデルを実世界でうまく機能させたいのであれば、どのモデルを選ぶかを心配するよりも、より多くの時間を「ハーネス（ワークフロー）」の設計に費やす必要があると述べています。

技術概要

技術的概要：ハブネス設計が小規模言語モデルの運用安定性を決定する

問題提起

小規模言語モデル（SLM、20 億〜30 億パラメータ）は、エッジやオンプレミス環境での展開において大規模モデルに代わる費用対効果の高い選択肢を提供するが、多段階タスクにおけるその運用安定性については未だ十分に研究されていない。既存の文献は静的なベンチマーク精度（例：MMLU、HumanEval）に大きく焦点を当てており、実世界のシナリオにおける実行構造が出力の完全性や形式遵守にどのように影響するかという理解にギャップが存在する。さらに、Reflexion や ReAct などのフレームワークは実行フローが重要であることを示唆しているが、特に 20 億〜30 億パラメータのモデルに対するそのような構造の有効性に関する体系的な証拠は乏しい。

手法

著者らは、3 つの SLM（Gemma4 E2B（20 億）、Qwen3.5:2B（20 億）、LLaMA 3.2（30 億））において、「ハブネスエンジニアリング」（実行構造）の 3 つのレベルを比較する実験分析を実施した。本研究では、構造化された知識抽出、検索とグラウンディング、ワークフロー完了、制約に敏感なタスクを含む 6 種類の 24 のタスクを利用した。

ハブネス条件:

1. モデルのみのみ: タスク記述のみを含む生プロンプト。
2. ミニマルシェル: 実行フローのロジックなしに構造的タグ（[TASK START]、[OUTPUT]）でタスクをラップしたもの。
3. 4 ステージパイプライン: 計画 → 実行 → 検証 → 回復からなる構造化されたワークフロー。回復段階では、検証失敗またはタイムアウト時に最大 2 回のリトライとエラーフィードバックを許可する。

評価指標:

• タスク成功率（TSR）: 完全な成功（スコア=2）を達成したタスクの割合。
• 有効 TSR（VTSR）: 少なくとも部分的な成功（スコア≥1）を達成したタスクの割合。
• 検証検出率（VCR）: 検証段階で検出され、その後リトライされた欠陥の比率。
• 閾値: 運用安定性は、TSR ≥ 0.65 かつ VTSR ≥ 0.80 を満たすこととして定義された。

アブレーション研究:
本研究では、パフォーマンス向上への個々の寄与を定量化するために、パイプラインの特定のコンポーネント（計画、検証＋回復、回復）を分離した。

主要な知見と結果

1. ハブネス設計による運用安定性

本研究は、SLM が制約されたタスク範囲内で運用閾値を満たすことができることを示しているが、成功はパラメータ数だけでなく、ハブネス設計に大きく依存している。

• Gemma4 E2B: 4 ステージパイプライン下で TSR=0.952、VTSR=1.000 を達成し、モデルのみのベースライン（TSR=0.762）を大幅に上回った。
• LLaMA 3.2（30 億）: モデルのみの条件では、複雑な形式要件下でモデルが JSON 構造を放棄する「足場崩壊（scaffold collapse）」により、安定性閾値を満たせなかった（TSR=0.429）。パイプラインハブネスは安定性を回復させたが、Gemma に比べると絶対的な改善幅は小さかった。

2. 非単調性の効果

重要な発見として、Gemma4 と Qwen3.5 の両方において、ミニマルシェル条件がモデルのみ条件よりも低い TSR を生み出すという非単調現象が確認された。

• 観察: Gemma においてミニマルシェル TSR（0.714）< モデルのみ TSR（0.762）；Qwen においてミニマルシェル（0.857）< モデルのみ（0.952）。
• 仮説: 著者らは、ラッパータグが複雑なワークフローにおいて認知的負荷を増大させ、追加のタイムアウトを引き起こす可能性を指摘しているが、因果関係を証明するにはさらに制御された実験が必要である。

3. コンポーネントの寄与（アブレーション）

• 計画: 定量的制約に対する「形式のアンカー」として機能する。計画段階を除去すると TSR が低下し、特に文字数制限のあるタスク（例：T1-04）において、明示的な分解なしにモデルが制限を守れなかった。
• 回復: 回復メカニズムはパフォーマンス向上の主要な貢献者であり、総改善の約**24.7%**を占めた。これはタイムアウト失敗と形式違反を成功に転換することに成功した。
• 検証: すべてのパイプライン実行における検証検出率（VCR）は0.625であった。注目すべきは、LLaMA 3.2 は VCR が 1.000（すべての欠陥を検出）であったが、常に修正できなかったのに対し、Qwen の VCR は 0.000（欠陥を検出できなかった）であったことである。

4. 失敗モードの分類

本論文は、ハブネスによる修正可能性に基づいて失敗モードを分類している。

• 修正可能（反応的）: タイムアウトやルール検出可能な制約（例：禁止語）は、回復リトライを通じて成功裡に処理される。
• 修正可能（予防的）: 「足場崩壊（形式の放棄）」は、計画段階とプロンプト構造化段階によって処理される。
• 修正不可能: 定量的制約（例：正確な文字数）は、LLM 固有の計数制限によりしばしば失敗し、ハルシネーションはハブネス修正の範囲外に留まる。

意義と主張

本論文は、ハブネス設計が SLM の運用安定性を決定する要因であり、しばしば生モデルサイズの利点を上回ると主張している。

• 足場 vs リトライ: 著者らは、2 つの独立したハブネス機能、すなわち反応的回復（発生後のエラー修正）と予防的足場（プロンプトと実行フローを構造化することでエラーを未然に防ぐ）を区別する。本研究は、これらの役割は明確に異なり、互いに交換不可能であると論じている。
• 「少なければ多い」への警告: 非単調な結果は、ハブネス設計における「中途半端な措置」（例：完全なパイプラインなしにタグを追加すること）が、生プロンプトと比較してパフォーマンスを低下させる可能性があることを示唆している。
• 限界: 著者らは、タスクセットの小ささ（24 タスク）、バリエーション推定の欠如（単一実行）、およびツール装備条件とツール非装備条件を比較し、オーケストレーションの質を比較しなかった Web 検索タスク（T6）における特定の設計上の欠陥など、限界を謙虚に認めている。

結論として、本論文は SLM を運用環境で信頼性高く展開するためには、モデルの選択自体と同様に、実行ハブネスのエンジニアリングが極めて重要であると提唱している。今後の研究としては、検出率を向上させるためのルールベースの検証に焦点を当て、ツールアクセスからオーケストレーション効果を分離するためにタスクを再設計することが提案されている。