デジタルイノベーション部IoT/AIソリューション3課の樋山です。
最近のAI技術の進歩は凄まじく、LLMを活用したサービスの開発がこの1年で急増しています。
LLMにはOpenAIのGPTシリーズ、AnthropicのClaudeなど様々なモデルがあり、どれも素晴らしい回答精度です。
時にはAIということを忘れるような回答が返ってくることも多々あります。
しかし一方で、質問に対して意図にそぐわない回答や、ハルシネーション（事実と異なる情報の生成）を引き起こす可能性など、課題も存在します。
特にtoCサービスでは、AIが誤った回答を提供することで、企業のブランドイメージが損なわれるなどのリスクが高まるため、慎重な運用が求められます。
そこで重要なのがLLMの回答精度を正しく検証することです。
本記事では、LLMを使用したサービス全般に適用できる回答精度の評価方法について実際に私たちが行った方法を詳しく解説します。
今回参考にしたのは以下のドキュメントです。
Claudeユーザーガイド
初めてLLMを活用したサービスを開発している人、そのようなサービス開発に興味がある人。
以下のような機能をイメージしながらこの後の話を読み進めていただければと思います。
回答にはRAGを使用して、必ず事前に与えたドキュメントを元に回答を生成する仕組みとなっています。
LLMの評価方法にはさまざまなアプローチがあります。
今回は、想定質問と想定回答を用意し、その想定質問に対するLLMの回答が、どれだけ想定回答と一致しているかを評価し、最終的な正答率を求めるという方法を採用しました。
次に具体的な評価方法を解説していきます。
想定質問に対する回答は以下の指標を用いて評価します。
評価指標はGoogleの検索品質評価ガイドライン「General Guidelines」を参考にしました。
General Guideline
Google検索が今回のシステムの仕様と近く、参考になると考えました。
具体的に、評価指標の命名以外に参考にしたポイントは主に以下の点です。
LLMの採点方法についてClaudeユーザーガイドでは以下の3つの方法を挙げています。
コードベースの採点
文字列の一致などで機械的に判定する方法。
最も速く、最も信頼性が高く、非常にスケーラブルだが、複雑な判断を必要とする場合には微妙なニュアンスに欠ける。
人間による採点
人間が採点する方法。
最も柔軟性があり、高品質だが、遅く、コストがかかるため可能な限り避けるように言及されている。
LLMベースの採点
LLMに採点させる方法。
高速で柔軟性があり、スケーラブルで複雑な判断にも適している。
今回は1と2を組み合わせて実施しました。
機械的に判定できる部分は機械的に判定して作業を削減しつつ、企業のサービスとしてリリースするため、最終的には人間の確認が必要だと判断しました。
まずは想定質問とそれに対する想定回答を作成します。
※想定回答は1つの想定質問に対して1つ作成します。
想定質問を用意するポイントは実際の質問になるべく近づけることです。
我々開発者はどうしてもシステムの知識がある分、UIやシステムの仕様に沿った聞き方をしてしまいます。
しかし実際のユーザーはシステムのことを当然知らないため、こちら側が全く想定できないような聞き方を平気で投げかけてきます。
そのため、想定質問は以下の優先順位で作成します。
1があれば理想ですが、新規サービスなどで難しい場合も、2は行いたいところです。
弊社は企業様に依頼を受けて開発する立場ですので、ドメインの知識があるのは絶対に我々よりも企業の方々です。
意味あるテストデータにするためにもここは協力いただくようにします。
また一方で質だけでなく量の担保も必要で、実際にClaudeのユーザーガイドにも質よりも量を優先する旨の記述があります。
そのため1,2だけで量の担保が難しい場合は、3や4で量を担保することを検討しましょう。
またいずれの方法でも以下のようなデータは開発者側で補完する必要があるでしょう（エッジケースなど）。
我々は想定質問が入力されたCSVを読み込ませると自動で〇✕の評価を行い、評価結果と回答内容を出力するツールを作成しました。
〇✕の評価は文字列のマッチングで機械的に評価します。
(=コードベースの採点)
なるべく自動化できるところは自動化するのが大切です。
読み込ませた想定質問に対しての回答が、想定回答と一致するか機械的に判定し、暫定の結果を出力します。
出力されたテスト結果をもとに、機械的なプロンプトでは判断できない部分を人間の目で評価していきます。
高い精度が求められる場合や厳格なシステムでは必ず必要なステップですが、一方でコストのかかる作業でもあるため、可能な限り自動化し、必要な部分のみを採点するようにします。
基本的にはコードベースで出力された結果から、以下の2つを洗い出します。
これらは単純な正誤ではないため人間の目での評価が不可欠です。
この際にできれば評価者は複数人、最低でも2~3人で行うことで評価の妥当性が高まります。
想定の回答ではないが、会話が不自然でなければ正解と評価します。
例えば「大谷選手のすごいところを教えて」と言われて、「バッティングがすごいです」という想定回答があったとします。
この時にLLMが「ピッチングがすごいです」と答えた場合、単純な〇✕の評価では✕となります。
しかし現実は160km/hを超える豪速球を武器にメジャーリーグでも投手としても大活躍していますから、回答としては正解といえます。
上記は極端な例ですが、このような場合はLLMの精度的には問題ないため、UIやロジックでの工夫が必要になります。
質問自体が曖昧な場合はたとえ人間でも回答できないと思います。
例えば「すごいバッターを教えて」と聞かれても、大谷選手と答える人もいればイチロー選手と答える人もいるし、中には野球経験者で、自分のチームメイトの名前を答える人なんかもいるでしょう。
この場合もAIの精度が良い悪いではなく、UIやロジックなど他の箇所で一工夫必要です。
LLMに質問が曖昧であるか自体を判定させても良いでしょう。
※その場合は、想定回答が「曖昧であると判定」になります
分からないことは正直に分からないと言う、人間と同じで大切なことです。
それならそもそも、曖昧な質問を想定質問自体から削除しても良いのではと感じますが、そういったエッジケースも含めてテストすることが大切です。
Fully Meets（〇）にHighly Meets（▲）を加えたものが正答数。
質問全体からAmbiguous Questionを差し引いたものが、回答すべき質問数となります。
これらを計算したものが正答率となります。
正答率を出せるようになりましたが、では一体何%を目指せば良いのでしょうか？
他のLLMを使用したサービスを多数調査したところ、一般的には80%から90%の精度が求められていることが多いようです。
多くのサービスでは、単純に正答率のみを発表し、具体的な評価方法が公開されておらず、正確な比較は困難です。
そのためあくまで目安の数字にはなりますが、１つの基準にはなるかと思います。
基準がなくて困っている場合は80%を基準にしてみてはいかがでしょうか。
※ただし中には以下のように90%以上でも利用を断念したという事例もありますので、作成するサービスの仕様やユースケースなどによって大きく左右されます。
回答精度を評価して終わりではなくしっかりと改善を行うことが大切です。
ただし、どれほど社内で改善を繰り返しリリース前の正答率を100%にしたとしても、リリース後も回答精度が100%になることは難しいです。
我々の予期せぬ質問や挙動は絶対に発生すると考えます。
そのため、評価以上に以下の2点が大切だと考えます。
実際にリリースし、運用しながら継続的に改善を行っていく
回答精度が100％でないことを許容できる仕組みを作る
以上の手順を通じて、LLMの回答精度を効果的に評価することができます。
LLMは今非常にホットな分野で、これからもますますLLMを用いたサービスの開発は加速していくと思います。
どうやって回答精度を評価すべきか迷った際は、本記事の内容をぜひ参考にしてみてください。