生成系AIは、ソフトウェア開発業界における重要な変化であり、ソフトウェアの開発、保護、および運用を容易にします。この新しいブログシリーズでは、GitLabの製品チームとエンジニアリングチームが、必要なAI機能をエンタープライズ全体に統合し、どのように作成、テスト、デプロイするかをご紹介します。GitLab Duoの新機能によってDevSecOpsチームがお客様にどんな価値をもたらせるようになるか、見ていきましょう！
GitLabは、お客様からの信頼を大切にしています。信頼を維持するためには、GitLab Duo AI機能をどのように構築し、評価し、高品質を確保しているかについて透明性を持つことが重要です。GitLab Duo機能は多様なモデルセットを備えており、それによって幅広いユースケースをサポートし、顧客に柔軟性を提供しています。GitLabはデフォルトで、単一のモデルプロバイダのみに依存していません。現在、GoogleおよびAnthropicの基盤モデルを使用していますが、GitLab Duoのユースケースに適したモデルを継続的に評価しています。このブログでは、AIモデルの検証プロセスを詳しくご紹介します。
ライブデモ開催！ GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を体験しませんか。【今すぐ登録する】
LLMを理解する
大規模言語モデル（LLM）は、プラットフォーム全体の多くのAI機能を強化する生成系AIモデルです。膨大なデータセットで訓練されたLLMは、直前の文脈に基づいて一連の流れの中で次の単語を予測します。入力プロンプトが与えられると、プロンプトに条件付けられた単語の確率分布からサンプリングすることで、人間が書いたようなテキストを生成します。
LLMは、インテリジェントなコード提案、会話型チャットボット、コード説明、脆弱性分析などを可能にします。特定のプロンプトに対して多様な出力を生成する能力があるため、標準化された品質評価が困難です。LLMはさまざまな特性に合わせて最適化できるので、多くのAIモデルが積極的に開発されています。
大規模なテスト
インプットとアウトプットがより簡単に定義され、テストできる従来のソフトウェアシステムとは異なり、LLMは、微妙で、また多様でもあり、文脈に依存するアウトプットをよく生成します。これらのモデルをテストするには、品質が主観的で変わりやすいことや、アウトプットがの確率的に変動することを考慮した包括的な戦略が必要です。したがって、LLMのアウトプットの質を個別にまたは経験に基づいて判断するのではなく、LLMの全体的な動作パターンを調べる必要があります。これらのパターンを理解するには、大規模なテストが必要です。大規模なテストとは、膨大で多様なデータセットやユースケースにわたるシステムやアプリケーションのパフォーマンス、信頼性、堅牢性を評価するプロセスを指します。当社の集中評価フレームワーク（CEF）は、数十のユースケースに結びついた何千ものプロンプトを利用することで、重要なパターンを特定し、基礎となるLLMとそれらが統合されているGitLab Duo機能の全体的な動作を評価できます。
大規模なテストによって、次のような効果があります。
- 品質を確保する： 大規模なテストを行うことで、さまざまなシナリオやインプットでこれらのモデルの品質と信頼性を評価できます。大規模にモデルの出力を検証することにより、パターンを特定し、体系的なバイアス、異常、不正確さなどの潜在的な問題を軽減できます。
- パフォーマンスの最適化： テストをスケールアップすることで、GitLabは実際の条件下でLLMのパフォーマンスと効率を評価できます。これは、アウトプット品質、レイテンシー、コストなどの要因を評価し、GitLab Duo機能に組み込まれたこれらのモデルを最良の状態に保つ作業を指します。
- リスクを軽減する： LLMを大規模にテストすれば、重要なアプリケーションにLLMをデプロイする際のリスクを軽減できます。さまざまなデータセットやユースケースで徹底的なテストを実施することで、潜在的な故障モード、セキュリティの脆弱性、倫理的懸念を特定し、顧客に影響を与える前に対処できます。
GitLabプラットフォーム内でのデプロイの信頼性と堅牢性を確保するには、LLMの大規模なテストが不可欠です。GitLabは、さまざまなデータセット、ユースケース、シナリオを含む包括的なテスト戦略に投資することにより、潜在的なリスクを軽減しながら、AIを活用したワークフローの可能性を最大限引き出すようにに取り組んでいます。
大規模にテストする方法
LLMを大規模にテストする手順は次のとおりです。
ステップ1 ：本番環境用プロキシとしてプロンプトライブラリを作成する
現在、他社はAIをトレーニングするために顧客データを表示して使用していますが、GitLabは使用していません。 その結果、本番環境での規模でさまざまな操作ーを模倣する包括的なプロンプトライブラリーを開発する必要がありました。
このプロンプトライブラリは質問と回答で構成されています。質問は本番環境で実際にあるようなクエリやインプットで、回答はグラウンドトゥルース（理想的な回答の基準）を表します。このグラウンドトゥルースは、目標とする回答として考えることができます。質問も回答も人間が生成した可能性がありますが、必ずしもそうではありません。このような質問と回答の組み合わせから、比較基準や参照フレームができあがり、モデルや機能間の違いを明らかにできます。複数のモデルが同じ質問を受け、異なる回答を生成する場合、グラウンドトゥルースを使用して、実際の回答に最も近いものを提供したモデルを決定し、それに応じてスコアを付けることができます。
ここでも、包括的なプロンプトライブラリーの重要な要素は、必ず本番環境で実際ありうるインプットに最も近いものとなるということです。私たちは、基盤となるモデルが特定のユースケースにどの程度適合していて、また自分たちの機能がどの程度うまく機能しているかを知りたいのです。多数のベンチマークプロンプトデータセットがありますが、これらのデータセットは、GitLabにある機能のユースケースを反映していない可能性があります。当社のプロンプトライブラリは、GitLabの機能やユースケースを対象に設計されています。
ステップ2 ：ベースラインモデルのパフォーマンス
本番環境のアクティビティーを正確に反映するプロンプトライブラリを作成したら、これらの質問をさまざまなモデルに入力して、顧客のニーズをどの程度満たしているかをテストします。
各回答をグラウンドトゥルースと比較し、以下のような一連のメトリクスに基づくランキングを提供します：コサイン類似度スコア、クロス類似度スコア、LLMジャッジ、LLMジャッジによるコンセンサスフィルタリング。この最初のイテレーションは、各モデルがどの程度うまく機能しているかのベースラインを提供し、機能の基盤となるモデルの選択の指針となります。簡潔に説明するため、ここでは詳細に触れませんが、メトリクスの詳細についてはこちらをご覧ください。これはまだ解決された問題ではないのでご注意ください。広範囲にわたるAI業界は、新しい技術の研究と開発を積極的に行っています。GitLabのモデル検証チームは、業界の動向を把握し、GitLab Duoが使用するLLM測定やススコアリング方法を継続的に改善しています。
ステップ3 ：機能開発
選択したモデルのパフォーマンスのベースラインができたので、自信を持って機能を開発できます。プロンプトエンジニアリングは多くの話題を呼びますが、検証を行わずにプロンプト（またはその他の手法）を介してモデルの動作を変更することだけに焦点を当てると、暗闇の中で作業しているようなものとなり、プロンプトを過剰適合させる可能性が非常に高くなります。1つの問題を解決することはできても、それ以上の問題を引き起こしてしまいます。何が起こるかは分かりません。モデルのパフォーマンスのベースラインを作成することで、必要なすべてのユースケースで時間の経過とともにどのように行動が変化しているかを追跡できます。GitLabでは、アクティブな開発中に機能のパフォーマンスを日々再検証し、すべての変更が全体的な機能性を確実に向上させるようにしています。
ステップ4 ：何度も繰り返す
ここでは、実験的イテレーションの仕組みを説明します。各サイクルで、大規模なテストのスコアを調べてパターンを特定します。
- 最も弱い分野の共通点は何ですか？
- 特定のメトリクスや特定のユースケースに基づいた機能でパフォーマンスが低下していますか？
- 特定の種類の質問に対して一貫したエラーが表示されていますか？
大規模なテストを行ってこそ、このようなパターンが浮き彫りになり、実験に集中できるようになります。これらのパターンに基づいて、特定の分野や特定のメトリクスでパフォーマンスを向上させるさまざまな実験やアプローチを提案します。
しかし、大規模なテストは高価で時間がかかります。より高速で低コストのイテレーションを可能にするために、ミニプロキシとして機能する小規模なデータセットを作成します。焦点を絞ったサブセットには、改善したいと考えている質問と回答の組み合わせが含まれるように重み付けをします。一方、より広範なサブセットには、変更が機能全般に悪影響を及ぼしていないかを確認するために、他のすべてのユースケースとスコアのサンプリングも含まれます。変更を加えて、焦点を絞ったデータのサブセットに対して実行します。新しい回答はベースラインと比較してどうでしょう？グラウンドトゥルースと比較するとどうでしょうか？
焦点を絞ったサブセットで取り組んでいる特定のユースケースに対応するプロンプトが見つかったら、機能の他の分野に悪影響を与えないようにするために、より広範なデータのサブセットに対してそのプロンプトを検証します。新しいプロンプトが検証メトリクスによりターゲット領域でのパフォーマンスを向上させ、それ以外の領域でのパフォーマンスを低下させないと確信した場合にのみ、その変更を本番環境にプッシュします。
集中評価フレームワーク（CEF）全体が新しいプロンプトに対して実行され、前日のベースラインと比べて機能全体のパフォーマンスが向上したかを検証します。このようにして、GitLabは常にイテレーションを行い、GitLabエコシステム全体でAIを使用した機能の最新かつ最高のパフォーマンスを確保しています。これにより、より迅速に、協力ながら作業を続けられます。
GitLab Duoをさらに優れたものにするために
GitLab Duoの機能開発にどのくらい責任を持って取り組んでいるのかご理解いただいていると幸いです。このプロセスは、GitLab Duoコード提案とGitLab Duoチャットを一般提供したことにより開発されました。また、GitLab Duoの機能をイテレーションする際に、この検証プロセスを開発プロセスに統合しました。さまざまな試行錯誤があり、1つを修正したと思えば別の3つで問題が発生するというようなことがよくありました。しかし、そのような影響についてデータに基づいたインサイトがあり、GitLab Duoが常に改良されているという確信材料となっています。
監修：大井 雄介 （GitLab合同会社 ソリューションアーキテクト本部 本部長）
今すぐ【GitLab Duoの無料トライアル】を始めましょう。
GitLab 17で利用可能な新しいAIインパクト分析ダッシュボードをご紹介する「GitLab Duo開発の現場から」シリーズもぜひお読みください。（随時和訳を公開中）
