GitLab における AI モデルバリデーション

市場の動向を監視して評価対象のモデルを把握し、新規モデル評価のオンデマンドリクエストに対応する方法。

はじめに

GitLab の AI モデルバリデーションへのアプローチは、厳格な評価と実用的な効率を組み合わせ、AI を活用した私たちの機能を支えるものです。私たちのフレームワークは、各チームが GitLab の品質およびコンプライアンス基準を維持しつつ最先端の AI 技術を活用できるよう支援します。一貫したバリデーション実践を確立することで、モデルが私たちのパフォーマンス、品質、コンプライアンス要件を満たすことを保証する助けとなります。

オペレーショナル North Star メトリック

私たちのバリデーションシステムの効果性は、主にモデルの提出からバリデーションレポートの提供までの ターンアラウンドタイム で測定されます。なお、ターンアラウンドタイムを測定するのはオープンソース(OSS)モデルの評価のみとします。モデルプロバイダーの応答時間は私たちが制御できないためです。

  • 既存ベンダー(標準的な評価緊急度): 5 営業日
  • 新規ベンダー: 15 営業日(ベストエフォートで達成しますが、ベンダーの応答時間に依存します)
    • 新規ベンダーは、GitLab.com の顧客向け本番製品・機能で利用される前に、GitLab Legal に新しい「サブプロセッサー」として 登録される必要があります。新しいサブプロセッサー(つまり新しいモデルホスト)の登録には 30 日間の通知期間があります。サブプロセッサーから移行するときや関係を終了するときに顧客に通知する必要はありませんが、顧客向けの機能を新しいモデルホストに移す場合には通知が必要です。
    • 新しいサブプロセッサーを提出するには、Legal プロジェクトで general-legal-templateIssue テンプレート を使ってモデルプロバイダーの詳細を含む Legal Issue を新規作成してください。

このターンアラウンドタイムには、運用メトリック(法務およびコンプライアンス要件)、技術メトリック(リソース利用とパフォーマンスベンチマーク)、統合メトリック(デプロイの複雑さと使いやすさ)の評価が含まれます。

モデルの発見と選定戦略

GitLab は、補完的な 2 つのアプローチを通じて、評価対象の AI モデルのアクティブなパイプラインを維持しています。

市場モニタリング

AI Framework チームは、GitLab の機能を強化する可能性のある有望なモデルを特定するため、AI 領域を継続的に調査しています。学術論文、商用リリース、オープンソースプロジェクトをレビューして、GitLab の機能に応用可能なモデルを特定します。また、注目に値するモデルを現在の本番実装と比較ベンチマークし、長期的な実現可能性を測るために市場の採用状況やコミュニティのサポートを評価します。

フィーチャーチームからのリクエスト

フィーチャーチームは、自分たちのプロダクト要件に基づいて評価対象として特定のモデルを直接ノミネートできます。リクエストを提出する際、チームは以下を提供してください。

  • モデル評価の詳細な根拠(想定ユースケースを含む)
  • 自分たちのニーズに最も関連するフィーチャー固有の評価基準
  • 評価の優先度付けに役立つ統合タイムラインの要件

緊急のモデル評価のためのブリッジプロセス

私たちの標準的なバリデーションプロセスはほとんどの状況で包括的な評価を提供しますが、ブリッジプロセス はオープンソース(OSS)モデルにのみ適用され、緊急性の高い状況での迅速な評価パスを提供することで、GitLab が市場の重要な動向に素早く対応できるようにします。

ブリッジプロセスを使うとき

ブリッジプロセスは次の場合に適しています。

  • 新しくリリースされたモデルが大きな競争優位性を示す
  • 迅速な市場ポジショニングのために即時の評価が必要
  • フィーチャーチームが緊急評価を必要とする重要な期限に直面している

ブリッジプロセスのタイムラインと活動

ブリッジプロセスは、私たちの標準的なバリデーションアプローチを 5 日間の合理化されたタイムラインに圧縮します。

  1. 1〜2 日目: 初期評価

    • 事前定義されたプロンプトサブセットを使って基本的な品質チェックを行う
    • 法務・運用上のリスクのため、ベンダーの利用規約をレビューする
      • : フィーチャーチームは、技術評価をパスしてもモデルが Legal によって却下される可能性があるリスクを受け入れます
  2. 3〜4 日目: ディープ評価

    • 既存のベンチマークを使って包括的なテストを実施する
    • スケーラビリティと統合要件を評価する
  3. 5 日目: 最終レビュー

    • 結果をまとめ、所見を文書化し、ステークホルダーレビューを実施する
    • フィーチャーチームに明確な次のステップを提供する

ブリッジプロセスのアウトプット

ブリッジプロセスの成功は次を提供します。

  1. 本番利用に向けたモデルの法務承認状態
  2. 私たちのバリデーション軸に基づく評価レポート
  3. ステークホルダーレビューおよび go/no-go 判断
  4. 承認された場合、モデルデプロイの目標日を含むイテレーション計画

ブリッジプロセス評価のリクエスト

フィーチャーチームは次の手順でブリッジプロセスを開始できます。

  1. Model Validation Rapid Eval Request テンプレートを使って専用 Issue を作成する
  2. 法務レビュー開始のため、付随する Legal インテーク Issue を記入する

AI Framework チームは、すべてのブリッジプロセスリクエストを 1 営業日以内にレビューします。

バリデーションレポートの構成

評価された各モデルについて、私たちは次の内容を含む包括的なバリデーションレポートを生成します。

パフォーマンス評価

  • 現在の本番モデルとの比較レイテンシ分析:

    • 標準入力サイズに対する応答時間ベンチマーク
    • テールレイテンシの比較(p95、p99)
    • Time-to-first-token のパフォーマンス
  • 現在のパフォーマンスベースラインに合わせるためのリソース要件:

    • 必要な GPU/CPU 構成
    • メモリフットプリントの比較
    • インフラストラクチャのスケーリング要件
  • コスト評価:

    • シンプルな 3 段階フレームワークによる相対的なコストポジショニング:
      • 現行ベースラインと同等
      • 中程度のコスト影響(ベースラインの 2〜5 倍)
      • 大幅なコスト差(ベースラインの 5 倍超)
  • パートナーシップステータス:

    • モデルプロバイダーとの現在の関係状況
    • 該当する場合の意思決定への影響

法務ステータス

  • 法務チームの正式承認ステータス(承認/非承認)
  • 承認された場合の条件付き要件や制限

品質評価結果

私たちの品質評価では、モデルの素のパフォーマンスとフィーチャーレベルの実装の両方を検査します。

短期評価メトリック

  • 初期品質評価では GitLab のコア評価スイートに焦点を当て、以下を測定します:
    • Duo Chat のパフォーマンスメトリック(読みやすさ、簡潔さ、正確さ)
    • Code Suggestions の精度
    • RCA の平均正確さスコア
    • Vulnerability Resolution の正確さスコア

長期モニタリングフレームワーク

私たちは以下について継続的なモニタリングを確立しています。

  • インフラの安定性(Apdex スコア)
  • ワークフローおよびツール応答の信頼性
  • 上流サービスの可用性
  • フィーチャー固有の品質メトリック

オーナーシップと責任

Model Validation チームの責任

  • 技術的バリデーション(リソース使用、スケーラビリティ)
  • 市場モニタリングとモデルパイプライン管理
  • プロセスのコーディネーション

フィーチャーチームの責任

  • フィーチャー固有の評価のためのデータセット作成
  • フィーチャー品質のオーナーシップと実装の意思決定

共有責任

  • モデルの選定と優先順位付け
  • 評価基準の策定
  • 結果のレビューと意思決定

関連リソース