AI システムの効率化では、計算量、モデルの精度、学習量、コンテキスト長など、利用できる資源に上限を置く場面が多い。推論コストを下げるために小さなモデルへ切り替える、量子化によって重みの表現精度を下げる、長い履歴を圧縮してコンテキストを短くするといった操作は、いずれも総資源量を減らす方法である。しかし同じ削減率でも、どの部分から資源を削ったかによって性能への影響は変わる。
その理由は、AI システムの性能が全状態から均等に生じているとは限らないからである。ある処理では通常の判断を安価なモデルで処理できても、曖昧な状態では高性能なモデルが必要になる。量子化されたモデルでは短い応答を維持できても、長い生成の途中で生じた小さな誤差が累積し、推論軌跡全体が崩れることがある。長時間動作するエージェントでも、過去のすべての情報が現在の判断へ同じ程度に寄与するわけではない。
この偏りを観測できるなら、効率化の設計単位は総量から配置へ移る。問いは「どれだけ減らせるか」だけではなく、「性能を維持するためにどこへ資源を残す必要があるか」になる。計算、学習信号、コンテキストという異なる資源についても、性能への寄与が集中する場所を識別できれば、一律削減とは異なる設計が成立する。
1. 資源を減らすときに全体を均等に削る必要はない
有限な計算資源を扱うとき、削減率だけを先に決めると、性能を支えている部分まで同じ割合で削ることになる。たとえば推論コストを半分にする場合、すべての処理を半分の計算予算で実行する方法と、通常の判断を安価な処理へ移し、判断が難しい状態だけ高価なモデルへ残す方法では、同じ総コストでも性能の残り方が異なる。
後者では、資源量の削減に加えて状態の識別が必要になる。まず、どの状態なら安価な処理でも結果が変わらないかを見分ける。次に、誤判定の影響が大きい状態だけを高性能な処理へ送る。この二つが成立すれば、高価な計算を全入力へ均等に使う必要がなくなり、同じ性能目標に対して必要な総計算量を下げられる可能性が生じる。
量子化でも、同じ構造が別の形で現れる。重みを低ビット表現へ移すと、元の値が持っていた細かな差の一部が失われる。しかし各重みや各状態が出力へ与える影響は一様ではない。性能への寄与が大きい部分と小さい部分を区別できれば、限られた表現精度を重要な部分へ残すという設計が可能になる。ここでは削減対象が計算回数から数値表現へ変わっているが、資源を均等に配るか、寄与の大きい場所へ集中するかという判断は共通している。
コンテキスト管理では、資源は現在の推論へ持ち込める情報量になる。長時間の作業では、過去の指示、観測結果、失敗履歴、途中生成物が蓄積する。そのすべてを保持すればコンテキストは増え続け、推論コストも増える。一方で、削減時に現在の作業へ必要な状態まで失えば、短くなったコンテキストの中で判断材料そのものが欠ける。どの情報を残すかという選択が、単純な文字数削減とは別の性能要因になる。
| 観点 | 一律に削減する設計 | 選択的に残す設計 | 選択を誤った場合の影響 |
|---|---|---|---|
| 計算 | すべての判断を同じ計算予算で処理する。 | 判断状態に応じて高価なモデルを呼び分ける。 | 難しい状態を安価な処理へ送ると、削減した計算量以上に判断精度が低下する。 |
| 学習 | あらかじめ用意した系列へ均等に教師信号を与える。 | 実際にモデルが到達する状態へ教師信号を配置する。 | 学習時に現れない失敗状態へ推論時に入ると、誤差から回復する能力を学べない。 |
| コンテキスト | 過去情報を同じ方針で圧縮または保持する。 | 現在の作業に必要な情報を優先して保持する。 | 必要な状態を削ると、短いコンテキストになっても判断に必要な根拠が失われる。 |
三つの対象では、削減するものも失敗の仕方も異なる。計算では高価な推論をどの状態へ使うか、学習では教師信号をどの軌跡へ与えるか、コンテキストではどの過去情報を現在へ残すかが判断対象になる。それでも、性能への寄与が場所によって異なるという条件が成立すれば、共通して削減位置を設計変数として扱える。
この構造では、効率化の評価も削減率だけでは完結しない。高価な資源を減らした割合に加えて、削減後にどの能力が残ったか、どの状態で性能が崩れたか、必要な状態を事前または実行中に識別できたかを見る必要がある。資源を減らす技術と、残す場所を見極める技術は別の役割を持ち、後者の精度が前者の実用上の限界を決める。
2. 性能を守るには失敗が起きる場所を見つける必要がある
選択的な資源配置が成立するためには、まず性能低下がどこで起きるかを識別できる必要がある。高価な処理を一部の状態へ限定しても、その状態選択が正しければ性能を維持できる。一方で、識別を誤って重要な状態まで安価な処理へ送ると、削減した資源量以上の性能低下が生じる。資源量を減らすこと自体より、削減可能な状態と保護すべき状態を分けられるかが効率化の上限を決める。
その判断には、失敗の位置と原因を分けて観測する必要がある。ある処理で性能が低下したとしても、直接の原因が計算不足とは限らない。学習時には現れなかった状態へ実行時に入ったためかもしれず、長い履歴の圧縮によって必要な情報が欠けたためかもしれない。失敗箇所だけを見て資源を増やしても、原因と投入する資源の種類が対応していなければ性能は回復しない。
選択的な資源配置は、三つの工程に分けると構造が明確になる。最初に、どの状態、生成軌跡、履歴条件で性能が崩れるかを観測する。次に、その崩れが計算不足、学習時と実行時の状態分布のずれ、情報欠落のどれに由来するかを識別する。そのうえで、原因に対応する計算、教師信号、コンテキスト容量を必要な場所へ戻す。
| 工程 | 確認する対象 | 判断を誤った場合の影響 |
|---|---|---|
| 失敗位置の観測 | どの状態、生成軌跡、履歴条件で性能が低下するかを特定する。 | 性能低下を平均値だけで見ると、局所的に崩れている状態を見落とす。 |
| 原因の識別 | 計算不足、状態分布のずれ、情報欠落のどれが失敗へつながったかを分ける。 | 原因と異なる資源を追加すると、コストだけが増えて性能が回復しない。 |
| 資源の再配置 | 失敗原因に対応する計算、教師信号、コンテキスト容量を必要な場所へ戻す。 | 投入範囲を広げすぎると、一律に高価な処理を使う構成へ近づき、削減効果が失われる。 |
この三段階には、選択機構そのもののコストも加わる。状態を分類するモデル、信頼度を推定する処理、失敗位置を追跡する評価系が高価であれば、選択によって節約した資源がその管理コストで相殺される。さらに選択精度が低ければ、必要な場所へ資源を戻せず、性能低下も残る。選択的配置が有効になるのは、失敗位置を十分な精度で識別でき、その識別コストが削減効果を下回る範囲である。
この構造から、効率化の評価軸も変わる。総計算量やコンテキスト長を何割減らしたかだけでは、設計上の違いを十分に表せない。どの能力を維持するのか、その能力がどの状態で崩れるのか、その状態をどの程度識別できるのか、必要な資源を戻したときに性能がどこまで回復するのかまで見る必要がある。削減率は最終結果の一つであり、その前段にある失敗位置の識別精度が、削減可能な範囲を決める。
3. 高価な判断はすべての状態で必要ではない
REFLEX は、計算資源の選択的配置をエージェントの判断処理へ適用した研究である。すべての判断を高性能な生成 LLM に任せる代わりに、Jev を高速な型付き判断層として置き、信頼度が十分な状態ではその結果を使い、信頼度が低い場合や自由生成が必要な場合だけ強い LLM へ処理を移す。100 タスクの固定ベンチマークでは、強いモデルだけを使う構成と比べて強いモデルの呼び出しを 72.7% 減らしながら、95% の成功率を記録した[1]。
この構成では、高性能モデルを呼ぶかどうかを入力単位で決めるだけではない。エージェントが行動を進める途中で生じる個々の判断について、型付き判断で処理できる状態と、生成モデルへ委ねる状態を分ける。高価な計算を削減できる理由は、すべての判断が同じ種類の推論を必要とするわけではなく、候補選択や信頼度評価のように、限定された出力空間だけで処理できる状態が含まれるためである。
Jev は、この限定された判断を扱う役割を持つ。自由文を逐次生成するのではなく、あらかじめ定義された候補からの選択やスコアのような型付き出力を返す。既稿では、Jev が返す確率や信頼度を通常の条件分岐へ接続する方法と、RLCD について公開情報から確認できる範囲を整理した[2]。REFLEX では、その局所的な判断能力をエージェント全体の制御へ組み込み、どの状態で高性能モデルへ処理を引き渡すかというルーティングに利用している。
| 判断対象 | 安価な処理で扱える状態 | 高性能モデルへ移す状態 | 誤判定した場合の影響 |
|---|---|---|---|
| 候補選択 | 選択肢が明確で、型付き判断の信頼度が十分に高い。 | 候補間の差が小さく、信頼度が低い。 | 不適切な候補を確定すると、その後の処理全体が誤った経路へ進む。 |
| 行動可否 | 必要な情報と権限が揃い、実行条件が明確である。 | 情報不足、権限制約、状態解釈が関係する。 | 実行すべきでない操作を進めるか、必要な操作を止める。 |
| 自由生成 | 定義済みの候補や型だけで応答を決められる。 | 説明、計画、文章生成など、開いた出力空間が必要になる。 | 型付き判断だけでは必要な出力を表現できない。 |
強いモデルと弱いモデルを問い合わせごとに振り分ける発想には先行研究がある。RouteLLM は、性能とコストの異なる LLM の間を動的に選択するルーターを学習し、推論費用と応答品質の均衡を取る方法を示した[3]。FrugalGPT も、複数の LLM を段階的に呼び出すカスケードによって、必要に応じて高価なモデルへ処理を進める構成を扱っている[4]。これらでは、問い合わせ全体をどのモデルへ送るかが主要な制御単位になる。
REFLEX がさらに細かく見ているのは、問い合わせを処理する途中の判断状態である。論文では、候補から適切な関数を選ぶ能力と、その関数を現在の状態で実行してよいかを判断する能力を分けて検証している。前者では候補集合の識別精度が中心になるが、後者では情報不足や権限制約を含む現在状態の解釈が必要になる。同じ「ツール利用」でも、どのツールを選ぶかと、そのツールを今使うべきかでは失敗条件が異なる。
この差を測るために使われる BFCL は、関数呼び出しの正確性だけでなく、呼び出しを控える判断や、状態を引き継ぐ複数段階の処理まで評価対象に含む[5]。REFLEX の評価でも、関数そのものを選ぶ能力と、行動へ進んでよいかを判断する能力には差が見られた。ここから、選択的制御では「正しい道具を知っていること」と「その道具を使う条件を判断できること」を別の能力として扱う必要が生じる。
この分離は資源配置にも直接影響する。候補選択が十分に容易なら、高性能モデルを呼ばずに処理を完了できる状態を増やせる。一方で、行動可否の判断が難しい状態まで安価な処理へ任せると、誤った操作へ進む危険が増える。高価なモデルを残す場所は、単に「難しい質問」ではなく、誤判定の影響が大きく、型付き判断だけでは状態を十分に識別できない部分になる。
REFLEX の外部評価では、この選択機構自体にも限界が確認されている。通常のルーティングがすでに高精度な条件では、安価な生成モデルを使うカスケードに対する優位は限定的だった[1]。高性能モデルの呼び出し回数を減らせても、そのために追加した判断層が同等以上の費用や誤判定を生めば、システム全体の利得は小さくなる。
REFLEX が示すのは、高価な判断を一律に削る方法ではなく、高価な判断が必要になる状態を識別して残す方法である。成立条件は、安価な判断で処理できる状態が十分に存在し、その状態を高い精度で識別でき、ルーティング自体のコストが節約量を下回ることである。選択的な計算資源の配置では、モデルの価格差よりも、どの判断境界まで安価な処理へ委ねられるかが削減可能量を決める。
4. 正解系列だけで学習すると実行時の失敗状態を学べない
同じ資源配置の問題は、学習時にも現れる。低ビット量子化では、短い質問応答の性能をある程度維持できても、長い数学推論やコード生成では途中の小さな誤差が後続トークンの条件となり、その誤差を含んだ状態からさらに生成を続けることになる。誤差が一度生じるだけなら局所的な性能低下で済むが、その状態を起点として次の予測を重ねると、反復や推論軌跡全体の崩壊へつながる。Train Where the Quantized Model Goes は、この現象を、学習時と推論時の状態分布のずれが量子化によって増幅されたものと捉え、量子化モデル自身が実際に進んだ生成軌跡へ教師信号を与える On-Policy Distillation、OPD を提案した[6]。
量子化では、元の多数の値を限られた表現へ写すため、重みや活性値が持っていた細かな差の一部が失われる。既稿では、ビット数を減らしたときに代表値の数が減り、元の値との差として量子化誤差が生じる関係を整理した[7]。ニューラルネットワークでは、この誤差を推論時に突然受け入れるのではなく、学習段階から量子化された値を使うことで性能低下を抑える方法が研究されてきた。Jacob らは、学習時に量子化の影響を組み込み、整数演算だけで推論できる構成を示している[8]。
LLM では、学習済みモデルを後処理で低ビット化する方法も発展した。GPTQ は、重みを 3 ビットや 4 ビットへ量子化しながら出力誤差を抑える後処理型の手法を示し、大規模モデルの保存量と推論負荷を下げる経路を広げた[9]。AWQ は、重みの重要度が均一ではないことを利用し、活性値から影響の大きい重みチャネルを推定して、それらの量子化誤差を優先的に抑える[10]。ここでは、限られた表現精度をすべての重みへ均等に使うのではなく、出力への寄与が大きい部分へ残すという選択が行われている。
| 手法 | 主な対象 | 性能低下への対処 | 資源配置として見た意味 |
|---|---|---|---|
| 量子化対応学習 | 学習中の重みや活性値 | 量子化誤差を学習段階からモデルへ経験させる。 | 低精度表現を前提としたパラメーターへ適応させる。 |
| GPTQ | 学習済みモデルの重み | 後処理で量子化しながら出力誤差を抑える。 | 限られたビット幅の中で重み表現を調整する。 |
| AWQ | 影響の大きい重みチャネル | 活性値を使って重要な重みを識別し、量子化誤差を抑える。 | 表現精度を寄与の大きい部分へ重点的に残す。 |
| OPD | 量子化モデル自身が訪れる生成状態 | 実際の生成軌跡上で教師モデルから学習する。 | 教師信号を実行時に現れる失敗状態へ配置する。 |
OPD が追加しているのは、重みの量子化方法よりも、どの状態で学習するかという問題である。通常の教師強制では、各時点で正しい過去トークンを与え、その続きとなる正解を学習する。この方法では、学習中のモデルは常に正しい履歴の近くに置かれる。しかし推論時には、自分自身が生成したトークンが次の入力になる。途中で誤りが生じると、それ以降は学習時にほとんど経験していない状態から予測を続けることになる。
この学習時と推論時の状態分布のずれは、系列生成で以前から扱われてきた。Scheduled Sampling は、訓練中にもモデル自身の出力を入力へ混ぜ、正解履歴だけに依存した学習を緩和する方法を提案した[11]。模倣学習の DAgger も、現在の方策を実際に実行して訪れた状態を収集し、その状態で専門家の行動を教師信号として追加する[12]。両者に共通するのは、理想的な軌跡だけを学習対象にするのではなく、実際の方策が到達する状態分布へ学習を近づける考え方である。
量子化モデルでは、このずれが長い生成で拡大しやすい。量子化による小さな予測差があるトークンの選択を変えると、そのトークンを含む履歴が次の予測条件になる。次の予測でも差が生じれば、元の高精度モデルが進む軌跡からさらに離れる。教師強制で正解系列だけを学習しても、こうして生じた量子化モデル固有の状態で、どの方向へ戻ればよいかを直接学ぶ機会は少ない。
OPD は、量子化モデルを実運用と同じ低ビット経路で生成させ、そのモデル自身が到達した途中状態に対して高精度の教師モデルから指導を与える。この変更によって、教師信号の量を単純に増やすのではなく、教師信号を与える場所を変える。論文では、4 モデル、2.79 ビットと 1.88 ビットの条件で、MATH-500 の BF16 性能保持率が平均 35% から 70%、HumanEval が 66% から 91% へ上昇した[6]。
この結果が示すのは、低ビットモデルの性能回復が、正解データを追加する量だけでは決まらないということである。量子化モデルが実際には訪れない正解系列上へ教師信号を増やしても、実行時に崩れる状態を直接訓練したことにはならない。量子化モデル自身の軌跡を学習対象にすることで、限られた教師計算を、誤差が累積する可能性のある状態へ配置できる。学習時の資源配置では、何件の教師データを与えたかと同じ程度に、どの状態へ教師信号を置いたかが性能を左右する。
5. 長いコンテキストでは残す量と残した情報の忠実度を分ける
長時間動作するエージェントでは、計算量や教師信号に加えて、過去のどの情報を現在のコンテキストへ残すかが資源配置の対象になる。作業が長引けば、ユーザーからの指示、ツールの実行結果、変更したファイル、失敗した試行、途中で得た制約が蓄積する。それらをすべて現在のコンテキストへ残せば入力トークン数と推論コストが増え、圧縮しすぎれば後続の判断に必要な状態が失われる。CliffCompaction は、この蓄積を処理するとき、過去の圧縮結果をさらに要約し直す方法を避け、元の履歴から情報をそのまま残すか削除する方式を採る。著者らは、有限のコンテキスト長の下で最大 50% のコスト削減を報告し、Terminal-Bench と KernelBench では条件によって性能を維持または改善したとしている[13]。
長時間のエージェント作業では、生成能力と状態保持能力が別々に結果へ影響する。モデルが次の操作を正しく生成できる能力を持っていても、数十ステップ前に確定した制約や直前の失敗理由が現在のコンテキストから消えていれば、その能力を適切な状態で使えない。既稿では、生成能力だけで仕事の完了能力を説明せず、観測結果、実行状態、権限、外部ツールとの接続をモデル外部の設計対象として整理した[14]。CliffCompaction が直接扱うのは、そのうち時間とともに増える状態履歴をどの形で現在へ持ち越すかという部分である。
コンテキスト長を増やせば、過去情報を物理的には多く収容できる。しかし、収容した情報が推論時に同じ確率で利用されるとは限らない。Lost in the Middle は、同じ関連情報でもコンテキスト内の配置によって利用性能が変わり、重要な情報が長い文脈の中間に置かれた条件で性能が低下する傾向を示した[15]。入力可能なトークン数と、実際の判断に利用できる情報量には差がある。履歴を長く保持するだけでは、必要な状態を確実に参照できるとは限らない。
この制約に対して、既存研究は異なる方法でコンテキスト量を管理してきた。LLMLingua は、入力中のトークンを選択的に削減し、意味をできるだけ保持しながらプロンプトを圧縮する。論文では、条件によって最大 20 倍の圧縮でも性能低下を抑えられることを報告した[16]。LongLLMLingua は長文脈へ対象を広げ、質問との関連性や情報の位置を考慮して保持対象を選び、NaturalQuestions では約 4 分の 1 のトークン数で性能が最大 21.4% 改善したと報告している[17]。ここでは、どの入力トークンを現在の推論へ残すかという選択が計算量と性能を左右する。
MemGPT は別の方向から有限コンテキストを扱う。現在のコンテキストだけですべてを保持せず、複数の記憶階層を用意して、必要な情報をコンテキストの内外へ移動させる仮想コンテキスト管理を提案した[18]。情報を捨てる代わりに外部へ保持し、必要になった時点で取り戻せる構造を作る方法である。
| 方式 | 情報量を減らす方法 | 保持する情報の扱い | 主な失敗条件 |
|---|---|---|---|
| LLMLingua | 入力中の重要度が低いトークンを選択的に削減する。 | 意味を保持しながら短い入力へ再構成する。 | 必要な情報まで削減すると、圧縮率を高めても回答性能が低下する。 |
| LongLLMLingua | 質問との関連性や長文中の情報配置を使って保持対象を選ぶ。 | 長い入力の中から現在の問い合わせに有用な部分を優先する。 | 関連性の推定が外れると、後続推論に必要な情報を失う。 |
| MemGPT | 現在のコンテキスト外へ情報を移動する。 | 外部記憶へ保持し、必要に応じて再取得する。 | 必要な情報を適切な時点で再取得できなければ、保持していても利用できない。 |
| CliffCompaction | 古い履歴を切り詰めるか削除する。 | 残す部分は元の記述を維持し、圧縮結果の再要約を避ける。 | 削除対象の選択を誤ると、忠実な情報だけが残っていても必要な事実そのものが欠ける。 |
CliffCompaction がこれらと異なるのは、圧縮率だけでなく、圧縮を繰り返したときの情報変形を設計対象にしている点である。要約は長い履歴を短くできるが、要約文をさらに要約すると、元の発言や実行結果から一段ずつ離れていく。最初の要約で省略された条件は次の要約では復元できず、表現の変更によって制約の強さや因果関係が変われば、その変化も後続の圧縮へ引き継がれる。圧縮を重ねるほど、現在保持されている文章と元の履歴との距離が広がる可能性がある。
CliffCompaction は、この累積的な変形を避けるため、過去の圧縮結果を新しい要約の入力として再圧縮しない。保持する情報については元の記述を残し、コンテキスト容量を超える部分は切り詰める。この設計では、過去を広く残す想起率よりも、現在残っている情報が元の内容と一致している忠実度を優先する。大量の過去情報を曖昧な形で残すのではなく、利用可能な容量の範囲で原情報を保持する選択である。
この違いは、長時間タスクで評価する必要がある。CliffCompaction が使う Terminal-Bench 2.0 は、コマンドライン上で複数の操作を進める 89 の難しいタスクから構成され、公開時点の先端モデルとエージェントはいずれも 65% 未満の成功率だった[19]。KernelBench は、PyTorch の処理に対応する正しく高速な GPU カーネルを生成できるかを 250 のワークロードで評価する[20]。どちらも一度の回答で完結する課題より実行履歴が長く、途中で得た結果や失敗を後続の操作へ引き継ぐ必要がある。そのため、コンテキスト圧縮によって何が残り、何が失われたかが最終的な成功率へ反映されやすい。
コンテキスト管理では、保持量と忠実度は別の評価軸になる。多くの情報を残せば過去を参照できる範囲は広がるが、再要約を重ねれば個々の事実が元の記述から変形する可能性が増える。原文だけを残せば保持した情報の忠実度は高くなるが、容量を超えた過去は参照できなくなる。CliffCompaction は後者を選び、有限容量の中で「どれだけ多く覚えるか」より「覚えている内容がどこまで元の状態を保っているか」を優先した。
ここでも資源配置の焦点は総量から位置へ移る。長いコンテキストを短くすること自体が性能を生むのではなく、現在の判断に必要な情報を識別し、その情報を変形させずに残せる範囲で圧縮することが性能維持につながる。計算資源や教師信号の場合と同じく、削減可能量は、どの情報を捨てても現在の作業が成立するかを識別できる精度によって決まる。
6. 三つの研究は異なる資源を異なる場所へ配置している
REFLEX、OPD、CliffCompaction は、対象も手法も異なる。REFLEX が制御するのは実行時に使う高性能モデルの計算資源であり、OPD が制御するのは学習時に与える教師信号であり、CliffCompaction が制御するのは長時間作業で保持するコンテキストである。それぞれ別の問題を解いているが、資源が有限なときに「どこへ残すか」を選ぶ点では同じ構造を持つ。
REFLEX では、すべての判断へ高性能 LLM を使う構成から、判断状態ごとに必要な計算量を変える構成へ移る。型付き判断で処理できる状態では安価な処理を使い、信頼度が低い状態や自由生成が必要な状態だけ高性能モデルへ送る。ここで選択されるのは入力そのものではなく、エージェントが処理途中で到達した判断状態である。
OPD では、選択対象が計算から教師信号へ変わる。量子化モデルに正解系列だけを学ばせると、実行時に自分自身の誤差から到達した状態を十分に経験できない。そこで量子化モデル自身を生成させ、その実際の軌跡上へ教師信号を置く。学習量を増やすことより、どの状態で学習させるかを変えることで、長い生成で生じる誤差累積へ対応する。
CliffCompaction では、現在の推論へ持ち込める情報量が制約される。長い履歴をすべて保持する代わりに、現在残す情報を選び、保持する部分については元の記述を維持する。ここではコンテキスト容量を広く薄く使うより、限られた容量を現在の作業に必要な原情報へ使うことが優先される。
| 研究 | 制約される資源 | 選択する単位 | 資源を残す場所 | 選択を誤った場合の影響 |
|---|---|---|---|---|
| REFLEX | 高性能 LLM の呼び出しに必要な計算量と費用が制約される。 | エージェント実行中の判断状態を選ぶ。 | 信頼度が低い状態や自由生成が必要な状態へ高価な計算を残す。 | 難しい状態を安価な判断へ任せると、後続の操作まで誤った経路へ進む。 |
| OPD | 低ビット化によって表現精度と長い生成の安定性が制約される。 | 教師信号を与える生成状態を選ぶ。 | 量子化モデル自身が実行時に訪れる軌跡へ教師信号を置く。 | 正解系列だけを学習すると、誤差後の状態から回復する経験が不足する。 |
| CliffCompaction | 長時間作業で利用できるコンテキスト長と入力コストが制約される。 | 現在の文脈へ残す過去情報を選ぶ。 | 現在の作業に必要な情報を元の記述のまま保持する。 | 必要な履歴を削除すると、残った情報の忠実度が高くても判断材料が不足する。 |
三つを比較すると、資源制約が性能へ影響する経路も異なる。REFLEX では、安価な判断層が高性能モデルを呼ぶべき状態を識別できるかが性能を左右する。OPD では、量子化モデルが実際に訪れる状態と教師信号を与える状態が一致するかが長い生成の安定性へ影響する。CliffCompaction では、現在の判断に必要な情報と削除する情報を分離できるかが、圧縮後の作業継続能力を決める。
この違いを残したまま一段抽象化すると、三つに共通する条件が見える。第一に、性能への寄与が状態や情報ごとに偏っている。第二に、その偏りを何らかの方法で識別できる。第三に、識別結果に応じて計算、教師信号、コンテキスト容量の投入先を変更できる。この三つが揃うと、全体へ均等に資源を配る構成より、必要な場所へ集中する構成を選べる。
資源配置という見方では、削減率は設計の出発点ではなく結果になる。REFLEX で強いモデルの呼び出しを減らせるのは、安価な判断で処理できる状態を分離できた結果である。OPD で低ビットモデルの性能が回復するのは、教師信号を実際の生成状態へ移した結果である。CliffCompaction でコンテキストを短くできるのは、現在残す情報と削除する情報を分けた結果である。いずれも先に削減量を決めたのではなく、性能への寄与が高い場所を識別した後に削減可能量が決まる。
この共通構造は、三つの論文が共同で提示した理論ではない。各研究の実験条件、評価指標、失敗条件は独立しており、REFLEX の結果から OPD の有効性を保証したり、CliffCompaction の結果からモデルルーティング一般の優位性を導いたりすることはできない。比較から得られるのは、AI システムの実行、学習、状態保持という異なる階層で、資源の総量より配置場所が性能を左右する事例がそれぞれ確認できるという範囲である。
この範囲に限定すれば、三つの研究を一つの設計原則で読むことができる。有限な資源を扱うとき、性能を維持するための中心課題は、全体をどこまで縮小できるかではなく、性能低下が集中する場所をどこまで正確に識別できるかにある。選択精度が高いほど削減可能な領域は広がり、選択精度が低いほど安全に残せる資源削減幅は小さくなる。
7. 選択的配置にも削れない境界がある
選択的な資源配置は、重要な場所を識別できる範囲で成立する。削減対象を細かく選べても、識別精度、選択に必要な計算、残すべき最低資源には限界がある。資源を減らすほど効率が上がり続けるわけではなく、ある境界を越えると、削減による利得より誤判定や情報欠落による性能低下が大きくなる。
REFLEX では、この境界がルーティングの価値として現れる。安価な判断層が、高性能モデルを必要とする状態と不要な状態を十分に分離できれば、強いモデルの呼び出し回数を減らせる。一方で、通常のルーティングがすでに高精度な条件では、安価な生成モデルを使うカスケードとの差は小さくなる。追加した判断層にも推論コストがあり、誤って高性能モデルへの引き渡しを省略すれば、その後の処理全体へ影響する。選択層を追加する価値は、削減したモデル呼び出し量から、その判断に必要な費用と誤判定による損失を差し引いて評価する必要がある。
OPD では、境界は低ビット化によって失われた能力の回復幅として現れる。量子化モデル自身が訪れる軌跡へ教師信号を置くことで、正解系列だけを使う追加学習より長い推論を回復できる条件が示されている。しかし教師信号の配置を変えても、低ビット化によって失われた表現能力そのものが消えるわけではない。モデル規模、ビット幅、量子化方式、課題の長さが変われば、誤差の生じ方も異なるため、同じ学習方法で同じ回復幅が得られるとは限らない。
CliffCompaction では、削減限界がより直接的に現れる。原文を維持して再要約による変形を避けても、保持できる容量を下げ続ければ、現在の作業に必要な過去情報まで削除される。忠実度の高い少量の情報を残す設計は、保持した事実の変形を抑えられる一方、削除された事実を後から参照することはできない。圧縮率を高めるほど、情報の忠実度よりも想起可能な範囲の不足が支配的になる地点が現れる。
| 研究 | 削減できる条件 | 削減限界を決める要因 | 境界を越えた場合の影響 |
|---|---|---|---|
| REFLEX | 高性能モデルが不要な判断状態を高い精度で識別できる。 | ルーティング精度、判断層の計算コスト、誤判定時の影響が限界を決める。 | 必要な状態まで安価な処理へ送ると、モデル呼び出し削減以上の性能低下が生じる。 |
| OPD | 量子化モデルが実際に訪れる失敗状態へ教師信号を配置できる。 | ビット幅、モデル規模、課題の長さ、量子化後に残る表現能力が限界を決める。 | 教師信号の配置を改善しても、低ビット表現で失われた能力を十分に回復できない条件が残る。 |
| CliffCompaction | 現在の作業に不要な履歴を識別し、必要な原情報を残せる。 | 保持容量、削除判断の精度、後から必要になる情報の範囲が限界を決める。 | 必要な履歴まで削除すると、残存情報の忠実度が高くても作業継続に必要な状態が不足する。 |
三つに共通するのは、選択機構にも資源と誤差が存在することである。何を削るか判断するには、その前段で状態を観測し、重要度を推定し、削減後の性能を確認する必要がある。この処理が高価になれば、選択によって節約した資源との差は縮まる。さらに識別精度が下がれば、削減量を増やすほど保護すべき部分まで削る確率が高くなる。
選択的配置が成立する条件は四つに整理できる。性能への寄与が場所によって偏っていること、その偏りを十分な精度で識別できること、選択に必要なコストが削減効果を下回ること、性能維持に必要な最低資源を確保することである。これらの条件が揃う範囲では総資源量を減らしながら性能を維持できる余地が生まれ、いずれかが崩れる地点が削減可能量の境界になる。
この境界を考慮すると、選択的配置の評価は最大削減率だけでは決められない。削減率を上げたときに、どの能力が最初に崩れるか、その失敗をどの程度予測できるか、失敗回避のために必要な追加資源がどれだけあるかまで見る必要がある。実用上の上限は、削れる量そのものより、性能を守るための識別と最低資源をどこまで維持できるかによって決まる。
8. 効率化は削減率ではなく性能を守る場所で決まる
AI システムの効率を削減率だけで比較すると、同じ 30% や 50% の削減でも、何を失った結果なのかが見えなくなる。高性能モデルの呼び出し回数を減らしても、権限判断や行動可否のような誤判定の影響が大きい状態で失敗すれば、エージェント全体の成功率は維持できない。量子化によって短い質問への正答率が残っていても、長い生成で誤差が累積し反復へ入れば、推論能力を保持したとは評価しにくい。コンテキストを半分にできても、現在の作業に必要な制約や実行結果が失われれば、その削減は後続処理の失敗へ転換される。
三つの例では、削減対象も性能低下の現れ方も異なる。REFLEX では高性能 LLM の呼び出し回数、OPD では低ビットモデルへ与える教師信号、CliffCompaction では現在のコンテキストへ残す履歴が制約対象になる。それでも評価の順序は共通している。最初に守る能力を定め、その能力がどの状態で崩れるかを観測し、その状態を識別できるかを確認し、必要な資源をそこへ残したときの回復量を見る。その結果として、どこまで総資源量を減らせるかが決まる。
| 評価段階 | 確認すること | 三つの研究で対応する例 |
|---|---|---|
| 守る能力 | 削減後も維持すべき性能を先に定める。 | REFLEX ではタスク成功、OPD では長い推論、CliffCompaction では長時間作業の継続が対象になる。 |
| 失敗位置 | 性能低下がどの状態、軌跡、履歴条件で生じるかを特定する。 | 判断境界、量子化モデル固有の生成状態、現在の作業に必要な過去情報として現れる。 |
| 識別可能性 | 資源を残すべき場所を実行前または実行中に判別できるかを確認する。 | ルーティング、モデル自身が実際に訪れる軌跡、履歴の選別が対応する。 |
| 局所投入の効果 | 必要な場所へ資源を戻したとき、性能がどこまで回復するかを見る。 | 強い LLM へのフォールバック、教師モデルからの指導、原情報の保持によって測られる。 |
| 削減可能量 | 性能維持条件を満たした後に、削減できた総量を評価する。 | モデル呼び出し回数、低ビット化後の性能保持、コンテキスト削減量として現れる。 |
この順序を逆にして削減率から設計すると、性能を守るための最低資源を見誤りやすい。先に「半分にする」と決めれば、REFLEX では高性能モデルが必要な判断まで安価な処理へ流す可能性があり、OPD では表現精度だけを下げて実際の失敗軌跡を学習できず、CliffCompaction では必要な履歴まで容量制約に合わせて削ることになる。削減率を制約として先に固定する方法と、性能維持条件から削減可能量を導く方法では、同じ効率化でも設計の順序が異なる。
REFLEX が示したのは、高価なモデルを呼ぶ回数そのものより、高価な判断が必要になる状態を分離できるかが削減量を決めるという構造である。OPD では、追加する教師信号の総量より、量子化モデル自身が実際に到達する状態へ教師信号を置けるかが長い推論の回復へ影響した。CliffCompaction では、コンテキストをどこまで短くできるかより、現在の作業に必要な情報を原文のまま残せる範囲が圧縮限界を決める。それぞれの結果は独立しているが、資源量より先に資源の投入位置を決めている点は共通している。
有限な資源の下では、すべての処理、状態、情報を同じ精度で維持する必要はない。その代わり、性能への寄与が集中する場所を識別する能力が必要になる。識別精度が高ければ、不要な計算、学習、履歴を削れる領域が広がる。識別精度が低ければ、安全に削減できる範囲は狭まり、高価な資源を広く残す必要が生じる。効率化の限界は、利用可能な資源量だけでなく、資源を残すべき場所をどこまで正確に見つけられるかによって決まる。
REFLEX、OPD、CliffCompaction を同じ観点から読むと、AI の効率化は「少ない資源で動かす技術」から「性能を左右する場所へ有限の資源を配置する技術」として捉え直せる。削減率はその配置が適切だった結果として得られる数値である。先に設計すべきなのは、何を削るかではなく、どの判断、どの生成状態、どの過去情報を削ってはいけないかという境界である。
参考文献
- Tiantong Wu, Wei Yang Bryan Lim, REFLEX with Jev for Efficient Selective Control in LLM Agents (2026-09-22). https://arxiv.org/abs/2609.26532v1
- id774, Jev の RLCD と RLHF の違いを報酬と確率から考える (2026-09-19). https://blog.id774.net/entry/2026/09/19/5693/
- Isaac Ong et al., RouteLLM: Learning to Route LLMs with Preference Data (2024-06-26). https://arxiv.org/abs/2406.18665
- Lingjiao Chen, Matei Zaharia, James Zou, FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance (2023-05-09). https://arxiv.org/abs/2305.05176
- Shishir G. Patil et al., The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models (2025-07). https://proceedings.mlr.press/v267/patil25a.html
- Yuanteng Chen et al., Train Where the Quantized Model Goes: On-Policy Distillation for Low-Bit Reasoning (2026-09-22). https://arxiv.org/abs/2609.26708v1
- id774, 量子化について詳しく解説する (2026-08-07). https://blog.id774.net/entry/2026/08/07/5472/
- Benoit Jacob et al., Quantization and Training of Neural Networks for Efficient Integer-Arithmetic-Only Inference (2017-12-15). https://arxiv.org/abs/1712.05877
- Elias Frantar, Saleh Ashkboos, Torsten Hoefler, Dan Alistarh, GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers (2022-10-31). https://arxiv.org/abs/2210.17323
- Ji Lin et al., AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration (2023-06-01). https://arxiv.org/abs/2306.00978
- Samy Bengio, Oriol Vinyals, Navdeep Jaitly, Noam Shazeer, Scheduled Sampling for Sequence Prediction with Recurrent Neural Networks (2015). https://proceedings.neurips.cc/paper/2015/hash/e995f98d56967d946471af29d7bf99f1-Abstract.html
- Stéphane Ross, Geoffrey J. Gordon, J. Andrew Bagnell, A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning (2011-04). https://proceedings.mlr.press/v15/ross11a.html
- Trang Nguyen, Eulrang Cho, Bingqing Chen, Tim Dettmers, CliffCompaction: Cost-Efficient Compaction for Long-Horizon Coding Agents (2026-09-22). https://arxiv.org/abs/2609.26779v1
- id774, AI に仕事を任せるには、モデルの外側を設計する (2026-08-21). https://blog.id774.net/entry/2026/08/21/5544/
- Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts (2023-07-06). https://arxiv.org/abs/2307.03172
- Huiqiang Jiang, Qianhui Wu, Chin-Yew Lin, Yuqing Yang, Lili Qiu, LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models (2023-10-09). https://arxiv.org/abs/2310.05736
- Huiqiang Jiang et al., LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression (2023-10-10). https://arxiv.org/abs/2310.06839
- Charles Packer et al., MemGPT: Towards LLMs as Operating Systems (2023-10-12). https://arxiv.org/abs/2310.08560
- Mike A. Merrill et al., Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces (2026-01-17). https://arxiv.org/abs/2601.11868
- Anne Ouyang et al., KernelBench: Can LLMs Write Efficient GPU Kernels? (2025-02-14). https://arxiv.org/abs/2502.10517