LLMの事前評価のシステムアーキテクチャを紹介します
この記事の概要
こんにちは。PharmaX でエンジニアをしている諸岡(@hakoten)です。
この記事では、「YOJO事業部のプロダクト内で使用されているLLM(Large Language Models)の機能の性能を事前評価するための仕組み」について、システムのアーキテクチャをご紹介しています。
LLMを用いて実現している具体的な機能については詳しく触れていませんので、その点ご理解ください。
LLMにおける事前評価とは何か
まず、プロダクトにおけるLLM(Large Language Models)機能の評価がどのようなものかについて簡単に説明します。
LLMの特徴の一つとして、「出力が確率的である(毎回異なる)」という点があります。そのため、LLMで生成された文章や出力に対しては、出力結果の良し悪しを定量的に計測する方法が必要になります。
弊社における定量的な計測は、大きく次の2つの工程に分類されます。
評価の種類 | 説明 |
---|---|
事前評価 | プロンプトを変更した際に事前に準備したデータセットに対して機能の結果出力を行い、それを評価する。「オフライン評価」と呼ばれることもある。 |
事後評価 | LLM機能が実際に稼働した後、その結果を評価する。「オンライン評価」と呼ばれることもある。 |
この記事では、この「事前評価」について、どのようにアプリケーション上で構築しているかを主題として扱っています。
もう少し詳細なLLMの評価方法について知りたい場合は、当社の上野が書いた以下の記事、スライドをぜひご一読ください。
YOJOにおけるLLMの機能(チャットのサジェスト)と評価の手法
事前評価の具体例として、YOJOにおけるLLM機能の一つ「チャットのサジェスト機能」がどのように評価されているかを説明します。
YOJOは、オンラインで薬剤師に相談し、医薬品を購入できるtoC(顧客向け)サービスです。
このサービスの1機能として、薬剤師から患者へのメッセージ生成を支援する「チャットのサジェスト機能」を開発しています。この機能ではLLMを使用して、チャットシステム内で薬剤師のメッセージをサジェスト生成します。
例: 開発環境でチャットのサジェスト文を表示している図
この「チャットのサジェスト機能」は、事前評価と事後評価を通じて定量的に性能評価されます。生成されたメッセージは、以下のような基準で性能を評価されます。
- 質問内容が適切かどうか
- 文章作成マニュアルに従っているか
- メッセージに対する共感度が基準に満たしているかどうか
- etc
評価方法には、LLMによるスコアベースの評価と、受け入れ率などを測るアルゴリズムベースの評価の二種類があります。
事前評価のシステムフローとアーキテクチャ
これまでに説明した事前評価のワークフローを実行するためのシステムアーキテクチャは次のようになっています。
YOJOサービスは主にGCPで構築されており、事前評価も同様にGCP上に構築されています。
YOJOのLLM事前評価のシステム全体図
評価用アプリケーションの実行
YOJOの事前評価は、主にプロンプトエンジニアが管理者用アプリケーションから実行します。APIサーバーを介してリクエストを受け取った後、事前評価用のアプリケーションがCloudRunジョブとして起動され、評価が行われます。
事前評価は複数のLLMを何度も実行するため、非常に時間がかかることから、リソースはCloudRunジョブで分離され、YOJOアプリケーションに影響を与えないようにしています。
評価の実行と結果の保存
事前評価アプリケーションでは、実際の機能と同等の処理フローから結果を生成します。例えば、チャットサジェスト機能では、次のような組み合わせで評価が行われます。
【評価対象】
チャットのサジェストLLMで生成されたメッセージ
【評価項目】
- 質問内容の適切さ
- 文章作成マニュアルへの準拠度
- メッセージへの共感度
- etc
事前評価のインプットとなるテストデータセットは、Firestoreに保存されているものを使用します。こちらはプロンプトエンジニアが事前に用意する運用となっています。
生成した結果は、CSV形式でGoogle Cloud Storageに保存しています。
チャットサジェスト機能の場合、結果CSVには次のような項目が含まれます。
カラム名 | 説明 |
---|---|
dataset_id | データセットのID |
scored_request_id | 評価対象のPromptLayerの管理ID |
scored_prompt_name | 評価対象のプロンプトの名前 |
scored_prompt_version | 評価対象のプロンプトのバージョン |
empathy_request_id | 共感値スコア計測LLMのPromptLayerの管理ID |
empathy_prompt_version | 共感値スコア計測LLMのプロンプトバージョン |
empathy_score | 共感値スコア |
crated_at | 評価実行日付 |
YOJOのLLM結果及びプロンプトは、PromptLayerで管理しているため、結果CSVにはPromptLayerのトラッキングID(request_id)とバージョンをスコアとセットにして、出力しています。
評価の結果差分をSlackへ通知
評価を実行したら、結果のサマリーをSlackのチャンネルに投稿しています。
前回の結果があれば、今回の評価結果との差分を算出しそれらも投稿されるようになっています。
分析用のデータ同期
Google Cloud Storageに保存された結果CSVのデータは、データ転送(Data Transfer Service)を用いて、定期的にBigQueryに同期しています。
BigQueryのデータは、エンジニアによる分析やlookerによるデータのダッシュボード化に使用されます。
終わりに
以上、YOJOにおけるLLMのデータセットアーキテクチャについて、ご紹介させていただきました。
LLMプロダクトを開発している方に少しでも参考になれば幸いです。
PharmaX では、様々なバックグラウンドを持つエンジニアの採用をお待ちしております。
LLM関連の開発に興味がある方もぜひ気軽にお声がけください。
もし、興味をお持ちの場合は、私の X アカウント(@hakoten)や記事のコメントにお気軽にメッセージいただけますと幸いです。まずはカジュアルにお話できれば嬉しいです!
PharmaXエンジニアチームのテックブログです。エンジニアメンバーが、PharmaXの事業を通じて得た技術的な知見や、チームマネジメントについての知見を共有します。 PharmaXエンジニアチームやメンバーの雰囲気が分かるような記事は、note(note.com/pharmax)もご覧ください。
Discussion