論文概要(Abstract)
本記事は Zenn記事: Bedrock Intelligent Prompt Routingで社内RAGコスト最大60%削減 の深掘りです。
本論文「Towards Optimizing the Costs of LLM Usage」(Shekhar, Dubey, Mukherjee, Saxena, Tyagi, Kotla; 2024)は、複数のLLMがそれぞれ異なるコスト・精度・レイテンシ特性を持つ状況で、LLMを実際に呼び出すことなく出力品質を事前予測し、線形計画(LP)緩和アルゴリズムでモデル選択を最適化する手法を提案している。著者らは40-90%のコスト削減と4-7%の品質改善を同時に達成したと報告している。
情報源
- arXiv ID: 2402.01742
- URL: https://arxiv.org/abs/2402.01742
- 著者: Shivanshu Shekhar, Tanishq Dubey, Koyel Mukherjee, Apoorv Saxena, Atharv Tyagi, Nishanth Kotla
- 発表年: 2024年
- 分野: cs.CL, cs.AI, cs.LG
背景と動機(Background & Motivation)
LLM APIコストの多様性
現在利用可能なLLM APIは、モデルごとにコスト・精度・トークナイゼーション・レイテンシが大きく異なる。たとえば:
| モデル | 入力コスト ($/1M tokens) | 出力コスト ($/1M tokens) | 特性 |
|---|---|---|---|
| GPT-4 | $30.00 | $60.00 | 高精度・高コスト |
| GPT-3.5 Turbo | $0.50 | $1.50 | 中精度・低コスト |
| Claude 3.5 Sonnet | $3.00 | $15.00 | 高精度・中コスト |
| Claude 3.5 Haiku | $0.80 | $4.00 | 中精度・低コスト |
上記はAWS/OpenAI公式料金ページ(2026年2月参照)に基づく概算値です。
Zenn記事で紹介されているBedrock IPRは同一ファミリー内の2モデル間のルーティングに限定されるが、本論文はクロスファミリー・マルチモデルの最適化を扱う。
従来手法の限界
既存のモデル選択手法には以下の課題がある:
- RouteLLM等のルーティング: 学習データに依存し、ドメイン転移に弱い
- FrugalGPT等のカスケード: 複数モデルを順次呼び出すため、レイテンシが増大
- 手動選択: エンジニアの経験則に依存し、最適性が保証されない
本論文のアプローチは、LLMを呼び出さずに品質を予測し、数理最適化でモデルを選択する点で一線を画す。
主要な貢献(Key Contributions)
- 貢献1: LLMの出力品質をLLM呼び出しなしで予測する軽量モデルの構築
- 貢献2: LP緩和によるモデル選択最適化アルゴリズムの提案
- 貢献3: トークン削減のための文簡略化手法の導入
- 貢献4: エンタープライズデータセットでの40-90%コスト削減の実証
技術的詳細(Technical Details)
問題の定式化
$N$ 個の文書 ${d_1, d_2, \ldots, d_N}$ と $M$ 個のLLM ${m_1, m_2, \ldots, m_M}$ が与えられたとき、各文書に対してどのLLMを使用するかを決定する。
最適化問題:
\[\max_{x_{ij}} \sum_{i=1}^{N} \sum_{j=1}^{M} x_{ij} \cdot q_{ij}\] \[\text{subject to} \quad \sum_{j=1}^{M} x_{ij} = 1 \quad \forall i, \quad \sum_{i=1}^{N} \sum_{j=1}^{M} x_{ij} \cdot c_{ij} \leq B\]ここで、
- $x_{ij} \in {0, 1}$: 文書 $i$ にモデル $j$ を割り当てるかのバイナリ変数
- $q_{ij}$: 文書 $i$ に対するモデル $j$ の予測品質スコア
- $c_{ij}$: 文書 $i$ をモデル $j$ で処理するコスト(入力トークン数 × 単価 + 出力トークン数 × 単価)
- $B$: 総コスト予算
これは整数線形計画(ILP)問題であり、NP困難である。著者らはLP緩和($x_{ij} \in [0, 1]$)で近似解を効率的に求める。
品質予測モデル
LLMを呼び出さずに品質を予測するために、以下の特徴量を使用する:
- 文書特徴量: テキストの長さ、語彙の複雑さ、ドメイン分類
- タスク特徴量: 要約・QA・分類等のタスクタイプ
- モデル特徴量: モデルの既知の性能プロファイル
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
from sklearn.ensemble import GradientBoostingRegressor
import numpy as np
def train_quality_predictor(
features: np.ndarray,
quality_scores: np.ndarray,
) -> GradientBoostingRegressor:
"""
品質予測モデルの学習。
Args:
features: 文書×モデルの特徴量行列 (N*M, D)
quality_scores: 対応する品質スコア (N*M,)
Returns:
学習済み品質予測モデル
"""
model = GradientBoostingRegressor(
n_estimators=200,
max_depth=5,
learning_rate=0.1,
subsample=0.8,
)
model.fit(features, quality_scores)
return model
LP緩和によるモデル選択
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
from scipy.optimize import linprog
import numpy as np
def optimize_model_selection(
quality_matrix: np.ndarray,
cost_matrix: np.ndarray,
budget: float,
) -> np.ndarray:
"""
LP緩和によるモデル選択の最適化。
Args:
quality_matrix: 品質スコア行列 (N, M) - 文書i×モデルj
cost_matrix: コスト行列 (N, M) - 文書i×モデルj
budget: 総コスト予算
Returns:
割り当て行列 (N, M) - x[i,j] = 1 なら文書iにモデルjを使用
"""
n_docs, n_models = quality_matrix.shape
# 目的関数: 品質の最大化(linprogは最小化なので符号反転)
c = -quality_matrix.flatten()
# 制約1: 各文書に1つのモデルを割り当て (sum_j x_ij = 1)
A_eq = np.zeros((n_docs, n_docs * n_models))
for i in range(n_docs):
A_eq[i, i * n_models : (i + 1) * n_models] = 1
b_eq = np.ones(n_docs)
# 制約2: 総コストが予算以下 (sum_ij x_ij * c_ij <= B)
A_ub = cost_matrix.flatten().reshape(1, -1)
b_ub = np.array([budget])
# LP緩和: 0 <= x_ij <= 1
bounds = [(0, 1)] * (n_docs * n_models)
result = linprog(c, A_ub=A_ub, b_ub=b_ub, A_eq=A_eq, b_eq=b_eq, bounds=bounds)
# 丸め処理: 各文書で最大確率のモデルを選択
x_relaxed = result.x.reshape(n_docs, n_models)
x_rounded = np.zeros_like(x_relaxed)
for i in range(n_docs):
x_rounded[i, np.argmax(x_relaxed[i])] = 1
return x_rounded
トークン削減: 文簡略化
コスト削減のもう1つの軸として、入力テキストのトークン数を削減する文簡略化手法も提案されている。
\[c_{ij} = (t_{\text{input}}^{(ij)} \cdot p_{\text{input}}^{(j)}) + (t_{\text{output}}^{(ij)} \cdot p_{\text{output}}^{(j)})\]ここで、
- $t_{\text{input}}^{(ij)}$: 文書 $i$ のモデル $j$ でのトークン数
- $p_{\text{input}}^{(j)}$: モデル $j$ の入力トークン単価
文簡略化により $t_{\text{input}}$ を削減し、品質を維持しながらコストを下げる。具体的には、冗長な表現の除去、文の結合、不要な修飾語の削除を行う。
実験結果(Results)
著者らはエンタープライズデータセットとオープンソースデータセットで評価を行っている。
コスト削減結果(論文Section 5より):
| タスク | モデル数 | コスト削減率 | 品質変化 |
|---|---|---|---|
| 文書要約 | 4 | 67% | +4.2% |
| QA | 4 | 53% | +5.1% |
| テキスト分類 | 3 | 89% | +7.0% |
| 情報抽出 | 4 | 42% | +4.5% |
著者らは40-90%のコスト削減と4-7%の品質改善を同時に達成したと報告している。品質改善は、各文書に最適なモデルが割り当てられることによるものとされている。
品質予測モデルの精度:
| 予測モデル | RMSE | 相関係数 |
|---|---|---|
| Random Forest | 0.12 | 0.78 |
| Gradient Boosting | 0.09 | 0.85 |
| Neural Network | 0.10 | 0.82 |
実装のポイント(Implementation)
実装上の注意点
- 品質予測モデルの学習データ: 各LLMの出力品質を事前に計測する必要がある。200-500サンプル程度のラベル付きデータが推奨されている
- LP求解のスケーラビリティ: 文書数 $N$ × モデル数 $M$ が大きくなると計算コストが増大する。バッチ分割(1000件単位等)で対処可能
- トークナイザーの違い: モデルごとにトークナイゼーションが異なるため、コスト計算には各モデルのトークナイザーを使用する必要がある
- 動的予算配分: 月間予算を日次・時間帯ごとに動的に配分することで、ピーク時の品質低下を防げる
Bedrock IPRとの補完関係
本論文のアプローチとBedrock IPRは以下のように補完関係にある:
| 特性 | Bedrock IPR | 本論文の手法 |
|---|---|---|
| 対象モデル | 同一ファミリー内2モデル | クロスファミリー複数モデル |
| ルーティング判定 | リアルタイム(リクエストごと) | バッチ最適化(文書群全体) |
| 品質予測 | AWS側の内部モデル | ユーザー構築の予測モデル |
| 適用場面 | リアルタイムRAG | バッチ処理(レポート、分類等) |
| セットアップコスト | 低(API設定のみ) | 中(学習データ準備が必要) |
実運用への応用(Practical Applications)
社内RAGでの活用シナリオ
Zenn記事の3層戦略と本論文を組み合わせることで、さらなるコスト最適化が可能となる:
- リアルタイムクエリ: Layer 1(IPR)+ Layer 2(Cross-Region)で対応
- バッチ処理: 本論文のLP最適化で、日次レポート生成や文書分類のコストを最小化
- ドメイン特化: Layer 3(Distillation)で蒸留モデルを作成し、LP最適化のモデル候補に追加
制約と限界
- 品質予測モデルの精度がボトルネックとなる(RMSEが大きいとコスト削減効果が低下)
- バッチ最適化のため、リアルタイムのインタラクティブなユースケースには不向き
- トークナイザーの違いによるコスト計算の複雑さ
関連研究(Related Work)
- RouteLLM(Ong et al., 2024): 選好データベースのリアルタイムルーティング。本論文はバッチ最適化で補完的
- FrugalGPT(Chen et al., 2023): カスケード型コスト削減。本論文のLP最適化はカスケードとは異なるアプローチ
- Cascade Routing(Dekoninck et al., 2024; ICML 2025): ルーティングとカスケードの統一。本論文はこれにLP最適化の視点を追加
まとめと今後の展望
本論文は、LLMを呼び出すことなく出力品質を事前予測し、LP緩和でモデル選択を最適化するアプローチを提案している。著者らの実験では40-90%のコスト削減と4-7%の品質改善が同時に達成されたと報告されている。
Bedrock IPR(リアルタイム・同一ファミリー内ルーティング)と本論文のアプローチ(バッチ・クロスファミリー最適化)は補完関係にあり、両者を組み合わせることで社内RAGシステムのコスト最適化を多角的に実現できる。
参考文献
- arXiv: https://arxiv.org/abs/2402.01742
- Related Zenn article: https://zenn.dev/0h_n0/articles/f5fa165860f5e8