インテリジェントなモデル選択

属性

背景

管理者とグループオーナーは、すでにモデル選択を通じて各 GitLab Duo 機能が使用するモデルを選択できます。この選択は固定的であり、その機能が行うすべてのリクエストを選択されたモデルが処理します。Duo Agent Platform のようなエージェント型の機能には、これは適していません。1 つのフローには単純なステップ（ファイルの読み取り、簡単な検索）と複雑な複数ステップの推論が混在していますが、現在は各ステップが実際に何を必要としているかに関係なく、同じ大規模モデルがすべてを処理しています。

インテリジェントなモデル選択により、GitLab はタスクごとに最適なモデルを選択できます。単純なタスクはより小さく高速なモデルに、複雑なタスクはより大きなモデルに振り分けます。エンドユーザーはモデル選択について考えることなく適切なデフォルトを利用でき、複雑な作業の品質を維持しながらコストとレイテンシーを削減できます。GitHub Copilot の自動モデル選択が、この動作に最も近い業界の参考例です。

目標

単一のフローでルーティングすることが目標ではありません。目指すのは、すべての Duo 機能が実行中のタスクに最適なモデルを選択することです。安全に実現するには、まず対象範囲を明確に絞った 1 つのフローで仕組みを実証する必要があるため、作業は 2 つのフェーズで計画しています。

1. 基盤整備。 既存の「GitLab default model」オプションを、モデルではなくポリシーとして位置付け直します。デフォルトモデルの管理、負荷分散、インテリジェントなモデルルーティングなど、GitLab が顧客に代わって最適化するすべてを、1 つの「GitLab managed」設定でカバーします。Duo Developer フローを独立した機能設定に分離し、専用のモデルセレクターを設けることで、ルーティングの作業を検証する対象を小さく明確な範囲に絞ります（フェーズ 1 のエピック、機密）。
2. Duo Developer 向けの小規模モデルと大規模モデル間のルーティング。 代表的な Duo Developer タスク群を用いて評価を実行し、候補となる小規模モデルと大規模モデルの品質、レイテンシー、コストのベースラインを確立したうえで、それらのベースラインに基づくルーティングを実装します（フェーズ 2 のエピック、機密）。ルーティング層の設計はアーキテクチャ決定記録に記録されています。ルーティングは「GitLab managed」設定を対象とするフィーチャーフラグの背後でリリースするため、結果が悪化した場合は迅速にロールバックできます。

終了基準

1. 「GitLab default model」オプションが「GitLab managed」ポリシー設定として位置付け直され、Duo Developer に専用のモデルセレクターを備えた独立した機能設定があること（フェーズ 1）。
2. 代表的な Duo Developer タスク群について、候補となる小規模モデルと大規模モデルの評価ベースラインが存在し、候補の変更時に評価を再実行できること（フェーズ 2）。
3. Duo Developer 向けの小規模モデルと大規模モデル間のルーティングがフィーチャーフラグの背後で利用可能であり、評価した品質が大規模モデルのベースラインと同等で、コスト削減が測定されていること（フェーズ 2）。

長期的なビジョン

私たちは、将来的にさらに最適化したい項目があると考えています。このタスクグループが実施を約束するものではないため、上記のフェーズではなく、ここに記録します。

• Duo Developer で実証した評価とリリースのプロセスを再利用し、残りの Duo 機能にもインテリジェントなモデル選択を拡張すること。
• グループオーナーと管理者がルーティングで選択可能なモデル群を制限できる、モデルの許可リストを設けること。
• ヒューリスティックなルーティングをタスクの難易度を分類するモデルに置き換える、LLM ベースのルーター。
• エンドユーザーにモデル選択をどのように表示するかについて、UI をさらにカスタマイズすること。

役割と責任

ページのソースコードを見る - ページの編集 - please contribute.