基盤モデルを適切に評価し、選定するためのプロセスとは
GenAIOpsの1つめのフェーズは「モデル選定フェーズ」である。生成AIの基盤モデルを評価し、使用するモデルを決定する段階だ。まず廣瀬氏は、モデル選定時に発生するトレードオフについて説明した。
「モデルごとに、性能とコストとパフォーマンスがトレードオフの関係になっていて、一般的には性能が高ければ高コスト、高レイテンシの傾向がありますが、長期的にはコストが下がる傾向にあります。そこで、ユースケースに応じて優先事項を決定します」
今回はユースケースを踏まえて性能を優先した。データベースのレビューの頻度は高くないため、1回あたりのコストに寛容で、高速な応答も求められないためだ。性能は、ベンチマークスコアを参考にして評価した。
ただし、モデル選定時にはジレンマも感じたそうだ。
まずは、チューニングの前後で性能が異なる点である。生成 AIアプリの性能は、基盤モデルの性能とプロンプトチューニングで決まってくるが、このプロンプトチューニングは基盤モデルごとに方針が異なる。例えば、ChatGPTはMarkdown形式、ClaudeはXML形式といった具合だ。そのため、同一プロンプトで各モデルの性能を評価できず、チューニング次第では順位が逆転する可能性もある。また、各モデル用にチューニングしたプロンプトで評価すると、チューニング工数が必要以上に肥大してしまうだろう。
「私たちは、ベンチマークスコアのいいモデルに、粗いプロンプトを組み合わせて確認して、いけそうと思えたら次のフェーズへ移ることにしました。そして、AWS上での開発のしやすさから、Bedrockで利用可能なモデルのうち、性能を重視してClaude 3.5 Sonnetを採用しました」
生成AIの応答を適切に評価し、チューニングするには
GenAIOpsの2つめのフェーズは「アプリケーション開発フェーズ」。アプリケーションの出力となる生成AIの応答を評価し、チューニングしていく段階だ。
ここで廣瀬氏は、Anthropic社の「Create strong empirical evaluations」というドキュメントを紹介し、磨かれたプロンプトをデプロイするためには、テスト用のデータセットを作成して評価とプロンプトチューニングを繰り返すことが重要だと説明した。その際に「推論結果が期待にどれだけ近いか」などの評価観点を「何らかの方法で算出したスコア」として定義して「最良のスコアを得たプロンプト」を採用するという。「ポイントは定量化すること。チューニング前後の比較の曖昧さを排除できるからです」と廣瀬氏は言う。
では、どのように定量化すればいいのだろうか。生成AIの評価観点をブレイクダウンする方法としては諸説あるが、調べた中で1番わかりやすかったのは、クオリティとコンプライアンスからなるものだという。これら観点は、さらに真実性・安全性・公平性・堅牢性に分類できる。
ただし、同じ観点であってもアプリケーションの特性に応じて正解率の算出方法を選ぶ必要があるという。例えば、Amazon Bedrockでも、テキスト生成ではRWKスコア、要約ではBERTスコアという具合に、タスクごとに正解率の算出方法に異なる指標を採用している。
評価観点のスコア化には3つの方法があり、コードベース・人間によるもの・モデルベースに大別できる。それぞれの方法にメリットとデメリットがあるので、評価の観点に応じて適材適所で選択していく必要がある。
まずクオリティの観点では、スコア算出にコードベースのアプローチを選択した。正解のテーブル定義（DDL）と完全一致をベストスコアにしつつ、類似度を定量化できるからだ。算出ロジックには、テキスト間の距離を計測する手法の1つである「レーベンシュタイン距離」を採用した。この手法では、完全一致で距離「0」、値が大きいほど類似度が低いとみなす。ただし、「DDLにおける類似度」を完全に表す指標ではないため、基本的には全データセットで0スコアを目指し、非0スコアのデータセットに対してプロンプトチューニングを行う方針とした。
続いて、コンプライアンスの観点は、社内向けアプリケーションであることや、プロンプトに埋め込むユーザー入力をテーブル定義に限定する実装になっていることから、今回は対応不要と判断した。
ただし、ユーザー向けチャットアプリのようにユーザーに公開するアプリケーションなどではコンプライアンスの観点での評価も必要になる。その場合は「クラウドベンダー提供のガードレール機能が便利だろう」と加えた。
評価の実装は、Python向けWebフレームワークであるStreamlitでおこなった。ここでは、jsonl（JSON Lines）形式のデータセットを与えて、ガイドラインとテーブル定義（DDL）をプロンプトに埋め込み、Amazon Bedrock で処理し、スコア値が最小になるまでプロンプトのチューニングを繰り返している。
「結果として、プロンプトの品質を、デプロイ可能と判断できるまで上げることができました。60個のデータセットほぼ全てにおいて、0スコアという最良の結果を達成しました。これは、専用アプリの開発により、チューニングと自動評価の高速ループが可能になったことが大きかったと思います」
廣瀬氏は、プロンプトのチューニングについても簡単に説明した。今回は、Claudeのベストプラクティスに則ったプロンプトチューニングを実施したという。中でも、プロンプトをChainさせる手法が有効だったと廣瀬氏は言う。例えば、チェックすべきガイドラインの項目が多数あった場合に、1回で全ガイドラインをチェックすると、数が増えるほどプロンプトが複雑化し、LLMによるチェック漏れや精度低下の懸念が高まるという。そこで、1回のプロンプト実行でチェックさせる項目を1つに限定し、推論により得た「修正後のDDL」を次のプロンプトへの入力として渡し（Chain）、それを繰り返し処理して最終的なDDLを得る仕組みを構築した。
「この手法は、プロンプトが短くタスクが1つに絞られるので精度が向上する、ガイドライン追加時は新規プロンプトを作成すればいいので既存プロンプトの精度に影響がないといったメリットがあります。一方で、LLMのInvoke（呼び出し）回数が増えるため、応答時間と金銭的コストは増加するというデメリットもあります」
