LLMOps
LiteLLM 1.98 RC、Auto Routerで先にシャドー評価を実行し、system promptによるコスト誤判定を修正
新バージョンでは、少量の実トラフィックを候補ルーターに複製し、オンラインの結果に影響を与えることなく、ブラインド方式のLLM judgeで応答を比較できる。複雑度分類でも、固定されたエージェントのsystem promptを各リクエストの技術的難易度を示すシグナルとして扱わなくなった。
LiteLLM v1.98.0-rc.1では、Auto Routerにデプロイ前のshadow evaluationが追加された。管理者がAPI key、サンプリング率、judge model、制限時間、最大2,000 turnを指定すると、システムは成功した`/v1/chat/completions`トラフィックからサンプリングし、同一リクエストをdetached taskとして候補ルーターに送信する。元の応答は通常どおり配信され、シャドー応答がユーザーに提供されることはない。2つの回答にはA／Bラベルがランダムに割り当てられ、LLM judgeが比較することで位置バイアスを抑える。
機能そのもの以上に注目すべきなのが、状態管理の設計だ。サンプリングのたびに`LiteLLM_ShadowEvalAttempt`レコードを1件追加するだけで、勝敗、エラー、judgeのコスト、各tierの勝率は読み取り時に集計され、pod間で共有するカウンターは維持しない。ジョブ設定は`stopped_at`を除いて変更不可で、partial unique indexにより各keyでアクティブにできるジョブは1件だけに制限される。シャドー呼び出しとjudge呼び出しは元のリクエストのIDおよび予算を引き継ぐ一方、本番リクエスト数、TPM rate limit、節約額、採用統計からは除外される。ただし、そのコストは引き続き該当keyに計上される。
同じバージョンでは、ComplexityRouter／QualityRouterも修正された。従来、4つのheuristicはsystem promptとユーザーのテキストを連結して評価していた。約1.6KBの一般的なCLIエージェントルールだけで、単語`hi`のスコアがデフォルトの0.15という境界値を超え、Haiku系の低価格tierからSonnet系tierへ誤ってルーティングされる場合があった。新バージョンでは、現在のuser textだけを対象に、code、technical、simple、multi-stepの各シグナルを算出する。
ただし、これは依然としてRCである。shadow evaluationが対象とするのはsingle-turnのChat Completionsのみで、候補モデルの応答が後続の会話をどう変化させるかは測定できない。コンテンツマスキングを使用するリクエストもスキップされる。エンジニアリングチームは、ルーターに本番トラフィックを任せる前に、低いサンプリング率でjudgeのバイアス、バックグラウンドコスト、データ外部送信ポリシーを検証すべきだ。