GitLab における AI モデル検証

市場のモデルを評価するための監視方法と、新しいモデル評価のオンデマンドリクエストへの対応方法。

はじめに

GitLab の AI モデル検証アプローチは、AI を活用した機能をサポートするために、厳格な評価と実用的な効率性を組み合わせています。私たちのフレームワークは、GitLab の品質とコンプライアンス基準を維持しながら、最先端の AI 技術を活用できるよう各チームを支援します。一貫した検証プラクティスを確立することで、モデルがパフォーマンス、品質、コンプライアンスの要件を満たすことを確保します。

運用上のノーススターメトリクス

検証システムの有効性は、主にモデル提出から検証レポート配信までのターンアラウンドタイムで測定されます。オープンソース（OSS）モデルの評価についてのみターンアラウンドタイムを測定します。モデルプロバイダーの応答時間はコントロールできないためです。

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

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

モデルの発見と選択戦略

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

市場モニタリング

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

フィーチャーチームによるリクエスト

フィーチャーチームは製品要件に基づいて特定のモデルを評価のために直接推薦できます。リクエストを提出する際、チームは以下を提供してください。

意図されたユースケースを含む、モデル評価の詳細な根拠
ニーズに最も関連するフィーチャー固有の評価基準
評価の優先順位付けを助けるための統合タイムライン要件

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

私たちの標準的な検証プロセスがほとんどの状況に対して包括的な評価を提供しますが、ブリッジプロセスはオープンソース（OSS）モデルのみに適用され、重要な市場発展に迅速に対応できるよう高緊急度の状況に向けた迅速な評価パスを提供します。

ブリッジプロセスの使用タイミング

ブリッジプロセスが適切な場合:

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

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

ブリッジプロセスは標準的な検証アプローチを効率化された 5 日間のタイムラインに圧縮します。

1〜2 日目: 初期評価
- 基本的な品質チェックのために事前定義されたプロンプトのサブセットを使用する
- 法的および運用上のリスクについてベンダーの利用規約をレビューする
  - 注意: モデルが技術的な評価をパスしたとしても、Legal が拒否する可能性があるリスクをフィーチャーチームが受け入れることになります
3〜4 日目: 詳細評価
- 既存のベンチマークを使用した包括的なテストを実施する
- スケーラビリティと統合要件を評価する
5 日目: 最終レビュー
- 結果をまとめ、調査結果を文書化し、ステークホルダーレビューを実施する
- フィーチャーチームへの明確な次のステップを提供する

ブリッジプロセスの成果物

ブリッジプロセスが成功すると以下が提供されます。

本番使用向けのモデルの法的承認ステータス
検証ディメンションに基づく評価レポート
ステークホルダーレビューと Go/No-Go の決定
承認された場合、モデルデプロイメントの目標日を含むイテレーションプラン

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

フィーチャーチームは以下の方法でブリッジプロセスを開始できます。

Model Validation Rapid Eval Request テンプレートを使用して専用の Issue を作成する
法的レビューを開始するためのコンパニオン Legal インテーク Issue に記入する

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

検証レポートの構造

評価された各モデルについて、以下を含む包括的な検証レポートを生成します。

パフォーマンス評価

現在の本番モデルとの比較レイテンシ分析:
- 標準的な入力サイズのレスポンスタイムベンチマーク
- テールレイテンシ比較（p95、p99）
- Time-to-first-token のパフォーマンス
現在のパフォーマンスベースラインに合致するためのリソース要件:
- 必要な GPU/CPU 設定
- メモリフットプリントの比較
- インフラストラクチャスケーリング要件
コスト評価:
- シンプルな 3 段階フレームワークを使用した相対的なコストポジショニング:
  - 現在のベースラインと同等
  - 中程度の高コスト影響（ベースラインの 2〜5 倍）
  - 大幅なコスト差（ベースラインの 5 倍超）
パートナーシップステータス:
- モデルプロバイダーとの現在の関係ステータス
- 関連する場合の意思決定への影響

法的ステータス

法務チームの正式な承認ステータス（承認済み/未承認）
承認が与えられた場合の条件付き要件または制限

品質評価結果

品質評価は、モデルの生の性能とフィーチャーレベルの実装の両方を検討します。

短期評価メトリクス

初期品質評価は GitLab のコア評価スイートに焦点を当て、以下を測定します。
- Duo Chat のパフォーマンスメトリクス（可読性、簡潔さ、正確さ）
- コードサジェスト精度
- RCA 平均正確率スコア
- 脆弱性解決正確率スコア

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

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

インフラストラクチャの安定性（Apdex スコア）
ワークフローとツールのレスポンス信頼性
アップストリームサービスの可用性
フィーチャー固有の品質メトリクス

オーナーシップと責任

モデル検証チームの責任

技術的検証（リソース使用量、スケーラビリティ）
市場モニタリングとモデルパイプライン管理
プロセス調整

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

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

共有責任

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