費用対効果に優れた生成AIアプリケーションを構築した方法

How we built a cost-effective Generative AI applicationの日本語訳です。

CodeRabbitは提供開始以来、開発者と組織からなるユーザー基盤を着実に拡大してきました。数千のリポジトリにインストールされ、毎日数千件のプルリクエスト（PR）をレビューしています。OpenAIのレート制限に対処するため、クライアント側でリクエストの優先順位を決める革新的な手法を使用していることは、以前の記事で紹介しました。この記事では、オープンソースプロジェクトへ充実した無料プランを提供しながら、継続的で詳細なコード分析を費用対効果の高い方法で実現する仕組みを紹介します。

CodeRabbitの製品構成とLLMの使用量

CodeRabbitは、さまざまな機能にGPT APIを使用するAIファーストのPRレビューツールです。CodeRabbitは次のサービスプランを提供しています。

• CodeRabbit Pro： プライベートリポジトリへ詳細なコードレビューを提供する有料サービスです。開発者数に応じた料金体系で、全機能を利用できる7日間の無料トライアルから始められます。

• CodeRabbit for Open Source： オープンソース（公開）リポジトリへ詳細なコードレビューを提供する無料サービスです。

• CodeRabbit Free： プライベートリポジトリ向けの無料プランで、PR内のコード変更を要約します。

私たちのビジョンは、あらゆる規模の開発者と組織へ手頃な価格のAIコードレビューサービスを提供しながら、オープンソースコミュニティを支援することです。特にオープンソースプロジェクトを重視し、コミュニティからの貢献をレビューする際の課題を理解しています。レビュープロセスが始まる前に提出内容の品質を高め、オープンソースメンテナーのコードレビュー負担を減らすことが目標です。

GitHubまたはGitLabでPRが開かれると、CodeRabbitのレビュープロセスが自動的に開始されます。各レビューでは、コンテキストを構築し、大規模言語モデル（LLM）を使って各ファイルをレビューする複雑なワークフローを実行します。コードレビューは、変更内容と既存のコードベースを深く理解する必要がある複雑な作業です。高品質なレビューコメントには、GPT-4などの最先端の言語モデルが必要です。しかし、GPT-3.5 TurboとGPT-4モデルの価格差が10〜30倍であることからわかるように、これらのモデルはよりシンプルなモデルよりも大幅に高価です。

GPT-4モデルはGPT-3.5 Turboモデルより10〜30倍高価です。

主なコスト要因は、OpenAI APIを使用したコードレビューコメントの生成です。以降のセクションでは、コスト最適化の戦略を紹介します。こうした最適化がなければ、オープンソースプロジェクトへの無料提供は実現できません。

コストを最適化し、ユーザー体験を改善するうえで役立った戦略を見ていきましょう。

1. デュアルモデル：よりシンプルなモデルで要約とトリアージ

コード差分の要約など、複雑さの低い作業には、GPT-3.5 Turboのようなシンプルなモデルで十分です。最初の最適化として、以前の記事で詳しく説明したように、複数のモデルを組み合わせて使用しています。GPT-3.5 Turboで大規模なコード差分を簡潔な要約へ圧縮し、それをGPT-4が処理して各ファイルをレビューします。このデュアルモデル方式はコストを大幅に削減し、レビュー品質を高めるため、多数のファイルと広範なコード差分を含むPRを処理できます。

さらに、些細な変更をレビュープロセスから除外するトリアージロジックを実装しました。コード差分の要約に使用するものと同じプロンプトの一部として、よりシンプルなモデルを使い、各差分を些細または複雑のどちらかに分類します。これにより、ドキュメントの更新や変数名の変更など、リスクの低い変更は詳細なレビュープロセスから除外されます。よりシンプルなモデルは些細な変更を正確に特定できるため、この戦略は効果的であることがわかりました。

要約にこのデュアルモデル方式を使用し、些細な変更を除外することで、コストを約50%削減しています。

2. レート制限：公平な利用を徹底

オープンソースプロジェクト向けの無料サービスを開始すると、一部の開発者が継続的なフィードバックを得るために数百件の小さなコミットを作成し、コーディングコパイロットとして利用していることがわかりました。CodeRabbitはGitHub Copilotのようなツールとは異なり、詳細なコードレビュー向けに設計されているため、この方法で利用すると高いコストが発生します。そこで、ユーザー体験を損なわずに過剰な利用を抑えるため、ユーザーごとに1時間あたりにレビューするファイル数とコミット数のレート制限を実装しました。これらの制限は製品プランによって異なります。たとえば、トライアルユーザーや有料ユーザーに比べ、オープンソースユーザーにはより厳しい制限を設定しています。

これらのレート制限を実装するため、サーバーレス環境向けのさまざまな選択肢を評価しました。シンプルさとポリシーの高度さから、FluxNinja Apertureを選びました。すでにOpenAIのレート制限の管理にApertureを使用していたため、今回のレート制限にも自然な選択肢でした。

FluxNinja Apertureでは、ラベルによってポリシーをアプリケーションロジックから分離し、アプリケーションコードを変更せずに新しいポリシーを追加できます。FluxNinja Apertureでラベルを適用し、SDKでレビューのワークロードをラップして、そのラベルに制限を課すポリシーを記述します。たとえば、以下のスクリーンショットに示すように、オープンソースユーザーには1時間あたり3件（20分ごとに1件）のレビュー制限を適用し、2件のレビューを連続して実行できるバーストを許可しています。

FluxNinja Aperture SDKとの統合

オープンソースユーザーに対する1時間あたりのコミット数制限

コメントでユーザーへ待ち時間を通知

GPT-4などの最先端モデルには高いコストと容量の制約があるため、レート制限はあらゆるAIアプリケーションに欠かせない要件です。公平利用のレート制限を実装することで、コストを約20%削減しています。

オープンソースユーザーのレート制限指標

3. キャッシング：類似するレビューコメントの再生成を回避

AIを使う習慣を形成するには、既存のワークフローをシームレスに強化することが必要だと考えています。そのため、AIコードレビューは継続的でなければなりません。PRが開かれるとすぐに開始し、コミットが追加されるたびに要約を段階的に更新してレビューコメントを生成する必要があります。

しかし、この方式ではコミットごとに類似するレビューコメントを再生成するため、コストが高くなり、フィードバックも繰り返しになる可能性があります。小さな追加コミットの多くは、最初の実装に対する軽微な調整やバグ修正であることがわかりました。そこで、小さな追加コミットに対して類似するレビューコメントを再生成しないよう、キャッシングレイヤーを実装しました。

幸い、Apertureは、レート制限を実装したものと同じAPI呼び出しを使い、以前のコミットの要約を保存するシンプルなキャッシング機構も提供しています。小さな追加レビューのたびに、よりシンプルなモデルを使い、両方の要約に記述されたコード変更を意味的に比較します。変更が類似している場合は、そのファイルのレビューを省略し、類似するレビューコメントが再生成されないようにします。この方法では要約の比較にLLMを使うため、ベクトル類似度に基づくキャッシング手法とは異なります。このケースでは意味的な比較が必要なため、ベクトル類似度に基づく方式は有効ではありません。コード差分の要約とトリアージに使用するものと同じプロンプトへ、この方法を統合しました。

より高価なGPT-4モデルを同じファイルへ呼び出す前に、費用対効果の高いGPT-3.5 Turboモデルを高度な類似度フィルターとして使用することで、類似するレビューコメントの生成を避け、コストを約20%削減しました。

まとめ

この記事では、GPT-4などの最先端LLMを本番環境で使用すると高額になる可能性を簡単に説明しました。また、よりシンプルなモデル、レート制限、キャッシングを組み合わせて運用コストを最適化する戦略も紹介しました。私たちの経験が、他のAIスタートアップによるコスト最適化と、費用対効果に優れたAIアプリケーションの開発に役立つことを願っています。