Skip to content

context-optimization-framework.md

Latest commit

 

History

History
220 lines (154 loc) · 8.62 KB

context-optimization-framework.md

File metadata and controls

220 lines (154 loc) · 8.62 KB

コンテキスト最適化フレームワーク

この文書は、LLM のタスク実行で発生するコンテキスト消費を、品質条件を守りながら最小化するための定式化と運用方針を示す。

1. 目的

対象となるタスク集合 $T$ に対して、同じ品質を維持しながら、
可能なら品質を上げて、LLM の総コンテキスト消費を最小化する。

意図は次の3点で見る。

  • 高頻度タスクほど、1回あたりの削減量が同じでも全体への影響が大きい
  • 1回あたりの消費が大きいタスクほど、圧縮して得られる効果が大きい
  • 品質違反リスクが高い改善は、品質制約を満たす場合にのみ採択する

以下の数式では、まず第2節で記号を定義し、それを第3・4節で使って評価・最適化を構成する。

2. 記号定義

  • $T$ : 対象タスクの集合
  • $i \in T$ : タスクID
  • $v$ : タスク $i$ の候補改善案（この文書ではバリアントと呼ぶ）
  • $f_i$ : タスク $i$ の観測窓（例えば1週間）あたりの呼び出し回数
  • $u_i$ : タスク $i$ の改善前、1回あたりコンテキスト消費（平均）
  • $r_i(v)$ : 候補改善案 $v$ を入れたときの、理想的な1回あたり削減見込み（平均）
  • $s_i(v)$ : 候補改善案 $v$ の成功率（$0 \le s_i(v) \le 1$）
  • $q_i(v)$ : 候補改善案 $v$ の品質違反率（$0 \le q_i(v) \le 1$, $q=0$ が理想）
  • $e_i(v)$ : 候補改善案 $v$ の導入工数コスト（相対値）
  • $B$ : 全体で使える導入工数予算
  • $C_0$ : 最適化前の全体コンテキスト推定値
  • $C_i(v)$ : タスク $i$ に改善案 $v$ を適用した場合の観測窓あたり期待コンテキスト
  • $gain_i(v)$ : タスク $i$ の改善案 $v$ による1回あたり期待削減量
  • $V_i(v)$ : タスク $i$ の理想的圧縮価値（frequency × 削減見込み）
  • $V_i^{safe}(v)$ : 品質を考慮した圧縮価値
  • $score_i(v)$ : 候補改善案 $v$ の工数効率指標

3. ベースライン計算

各タスクの観測窓あたりの最適化前消費を足し合わせる。
この窓は実運用で決める（例: 1日、1週間など）。
$f_i$ は「窓内での回数」、$u_i$ は「1回あたりコスト」であり、
全体コストは「回数 × 1回あたり」を総和して計算する。

最適化前の想定コストは次式で表す。

$$ C_0 = \sum_{i \in T} f_i u_i $$

タスク $i$ の基準計画（最適化なし）の消費量は

$$ C_i^{(0)} = f_i,u_i $$

タスク $i$ に改善案 $v$ を適用した場合の、観測窓あたり消費量は以下。

$$ \tilde C_i(v)= \begin{cases} f_i\left(u_i-r_i(v)\right), & r_i(v)\le u_i\\ 0, & r_i(v)>u_i \end{cases} $$

ここで $\tilde C_i(v)$ は「タスク $i$ に改善案 $v$ を入れた場合の観測窓あたり期待消費量（下限0で切り詰め）」を表す。

4. タスク1回あたりの期待削減

まず1回あたりの削減を定義する。
$r_i(v)$ は理想削減量なので、失敗時・品質違反時のリスクを反映するために
成功率 $s_i(v)$ と品質安全率 $(1-q_i(v))$ を掛けて、実効期待削減量 $gain_i(v)$ を作る。

$$ gain_i(v)=r_i(v),s_i(v),(1-q_i(v)) $$

ここで $gain_i(v)$ は「1回あたりの期待削減量」。
観測窓内合計は以下。

$$ f_i \cdot gain_i(v) $$

この量を圧縮価値として

$$ V_i(v)=f_i \cdot r_i(v),\quad V_i^{safe}(v)=f_i \cdot gain_i(v)=f_i \cdot r_i(v),s_i(v),(1-q_i(v)) $$

と定義する。
すなわち $V_i(v)$ は理想的価値、$V_i^{safe}(v)$ は品質条件を反映した実用価値である。

4.1 品質安全率の直感的意味合い

$s_i(v)\in[0,1]$ は成功率、$q_i(v)\in[0,1]$ は品質違反率で、
$(1-q_i(v))$ は「この改善案で品質条件を満たす確率（安全率）」を表す。
直感的には次の意味になる。

  • $r_i(v)$ が実際の削減を示しても、リソース不足や入力分布ズレで品質が下がると、
    実際の有効な削減は $s_i(v)$（成功）で一度フィルタされる。
  • さらに品質違反が起きる確率が $q_i(v)$ だけあるなら、
    1 - q_i(v) 分だけのみ目標品質を満たし、圧縮価値が残る。
  • どちらか一方が小さいと、積の値も小さくなり、採用候補の優先度も下がる。

このため、$gain_i(v)=r_i(v),s_i(v),(1-q_i(v))$ は 「品質要件を同時に満たす確率を考慮した1回あたり期待削減量」と読む。

4.2 バリアントの評価スコアと採択

$$ \text{score}_i(v)=\frac{V_i^{safe}(v)}{e_i(v)} $$

ここで $V_i^{safe}(v)$ は「1観測窓あたりの期待削減（トークン）」で、$e_i(v)$ は「導入工数（相対値）」なので、
score の単位は トークン/工数（例: tokens/人時）。

score が高いほど、1単位の工数あたりで見込める実質節約が大きい、という「効率」比較になる。

一方で「このタスクを触るべきか」は、同じタスク内の比較だけでなく「未採用」と比較する必要がある。
そのため実運用では、各タスクの候補集合に「未採用（$v=\varnothing$）」を入れ、

$$ \Delta C_i^{safe}(v_i)= \begin{cases} 0, & v_i=\varnothing\\ V_i^{safe}(v_i), & \text{otherwise} \end{cases} $$

で寄与を定義して最適化する。
このとき score は効率、$ΔC_i^{safe}$ は採否の土台、という役割分担になる。

5. 最適化問題

本節の最適化手順は、タスク集合ごとに実行する「選定アルゴリズム」として実装される。
実装名では selectVariants と呼ぶ。

この問題は、「限られた導入予算内で、採用すると良い改善をどのタスクに何個入れるか」　を決める、「予算付きの選択問題」と見なせる。

  • 各タスクは 1 つしか採用しない（または未採用）
  • 予算を超えないようにする
  • 品質条件を破らないようにする

数式で書くと次のとおり。

各タスク $i\in T$ に対して、候補改善案 $v_i$ を「未採用（$v_i=\varnothing$）」含めて1つ選ぶ。 目標は、未採用含めた全タスクの「品質を考慮した期待削減量」を最大化すること。

$$ \max \sum_{i \in T}\Delta C_i^{safe}(v_i) $$

制約は次の3つ。

  • $\sum_{i\in T}e_i(v_i) \le B$
    • 直感的な意味: 選ぶ提案の導入工数の総和が、全体予算 $B$ を超えない。
  • 各 $i$ に対して、採用候補は 高々1つ（または未採用）
    • 直感的な意味: 同じタスクで2案を同時に併用しない。
  • $q_i(v_i)\le \bar q_i$（または運用上の閾値）
    • 直感的な意味: 品質違反率が許容上限を超えない（採用価値が高くても除外）。

初版実装では、各タスクの最良スコア候補を算出し、全体を総合比較して選定する貪欲近似を採用している。 このとき数式は、

  • 「各タスクは未採用 or 1案だけ」
  • 「そのうちにどれを入れるか」
    の制約を守りつつ、「単位予算当たりの実効削減量」だけでなく、 「絶対的に効き目の大きい改善」も一度比較する ために使っている。

6. 多段更新（再最適化）

出力品質・運用環境は時間で変わるため、$f_i$, $u_i$, $s_i$, $q_i$ は固定しない。
再計測ループを回して更新する。

  1. 週次またはイベント時に最新ログを収集
  2. 選定アルゴリズム（selectVariants）の再実行
  3. 選定差分を反映
  4. 失敗率が悪化したらロールバック

7. 出力コントラクト

本フレームワークの最適化対象は、自由文より 構造化出力 を前提とする。
少なくとも以下が必要。

  • 形式固定（JSON または同等の schema 検証）
  • 成否判定フィールド
  • スキル使用有無
  • エビデンス要約
  • 次アクション（例: retry / done / send_reminder）

この前提がないと、評価関数の再現性が崩れ最適化が成立しない。

8. Discord MCP 適用時の初期重み（推奨）

  • qualityGate は厳密寄り（0.95〜0.98）
  • 失敗が高コストなら $q_i(v)$ を重く扱う
  • 成功率計測は3回以上、理想は5回以上で実施

9. このドキュメントの範囲

本書は「タスク選定と評価ロジック」に対してのみ構造化した記述を与える。
実装詳細は src/core、運用手順は docs/usage.md を参照。