LLMによる非同期文章レビュー基盤アーキテクチャ

アーキテクチャ選択の背景や意図

今回のアーキテクチャ設計では、主に3つの課題を考慮しました。

LLMの不確実性

LLMはAPIのRate Limitやレイテンシが不安定であり、システムの安定稼働において大きな懸念点でした。

組織間の連携

プロダクト組織とデータ組織が関わるため、両者の責任境界を明確にする必要がありました。

マルチクラウド環境

プロダクト組織がAWS、データ組織がGoogle Cloudを利用しており、セキュアな通信を確立する必要がありました。

これらの課題に対応するため、以下の設計方針を採用しました。

まず、LLMの不確実性に対しては、処理の失敗を前提としたリトライ（再試行）機能を持つ非同期処理を基本としました。

次に、組織間の連携については、それぞれが独立して開発・運用できるよう疎結合な構成を目指しました。

そして、AWSとGoogle Cloud間の認証については、通信の向きをAWSからGoogle Cloudへ一方向に統一し、Workload Identityを利用することで、サービスアカウントキーなどを直接管理しないセキュアな連携を実現しています。

現在の課題と今後の改善予定

現在の主な課題は、「実験→デプロイ→モニタリング→改善」という一連のサイクルを支える基盤機能が不足している点です。

例えば、データサイエンティストが考案したプロンプトやアルゴリズムを、容易に実験・デプロイできる仕組みが整っていません。
また、システムのインターフェースがCloud TasksとPub/Subに分かれており、構成が複雑になっている点も改善したいと考えています。

これらの課題を踏まえ、今後の改善項目として以下を計画しています。

インターフェースの統一

現在2つに分かれているインターフェースを、gRPCまたはREST APIに統一し、よりシンプルで管理しやすい構成を目指します。

アーキテクチャの最適化

複数のLLMを効率的に利用できるよう、アーキテクチャの最適化を進めます。

LLMOpsの導入

実験環境と本番環境をシームレスに連携させるLLMOpsの仕組みを導入し、開発サイクルの高速化を図ります。

Observabilityの向上

分散トレーシングなどを導入し、システムの可観測性を高めることで、問題発生時の迅速な原因究明を可能にします。

◆執筆：斎藤知之　@tomoppi_31