はじめに

はじめまして、Orbitics株式会社データサイエンス部の石原です。

以前、弊社の上野が公開した記事「RAGの基礎を理解する Part1~3」では網羅的にRAGに関する基礎情報を公開しています。
本記事は、その中でも「RAGの基礎を理解する Part2」で紹介した【品質評価の重要性および手動評価の役割と具体的な評価指標】に関して、RAGシステムの品質を担保し、実務レベルに引き上げるため、実際に現場で運用した具体的な評価方法と改善サイクルについて解説しようと思います。

RAGシステム開発後の導入において、信頼できる回答をユーザーに提供することは最重要課題です。その信頼性を確保するためには、定量的かつ多角的な評価が不可欠となりますので、本記事の内容が一助になれば幸いです。

品質評価の重要性と手動評価の役割（振り返り）

品質評価の重要性

RAGシステム開発時の最大の課題の一つは、ハルシネーションによる誤った回答を生み出してしまうことです。開発から導入へ移行する際には、回答の品質を客観的に測定し、導入に足る精度が確認できるまで改善するサイクルに乗せることが重要です。

手動評価を主軸とする理由

初めてRAGシステムを開発して導入する際の評価方法として、自動評価よりも手動評価の手法を取ることによるメリットは以下になります。

①事業適用への説得力: 実際の業務担当者やエンドユーザーに近い視点での評価は、システムを実運用へ移す際に強力な根拠となります。

②具体的な指摘内容に基づく改善: 評価者が具体的な問題点や違和感をコメントとして残すことで、改善策の立案（例：プロンプト修正、インプット資料の修正）が容易になります。

具体的な評価方法：手動評価のフロー

手動評価を実施するにあたり、以下のフローで作業を進めていきます。

手順	概要
1	評価項目・内容の設定
2	各項目に対する評価スコアの定義と合否基準の策定
3	実運用を想定した複数の質問と正しい回答の準備
4	RAGシステムで生成した回答に対し、複数人でスコアリング
5	評価者のコメントも踏まえ、最終的な合否判定の実施

それぞれの手順に沿って、具体的に実施内容を確認していきましょう。

1.評価項目・内容の設定

生成される回答に対し、網羅的な評価を実施するため、今回は7つの項目を準備しました。

評価項目	評価内容
正確性	出力が参照元の情報・事実と矛盾がない
関連性	出力が質問の意図・要求を満たし、関連する情報を含む
具体性	出力が操作手順等の具体性を持っている内容である
流暢性	出力がテキスト文として自然で読みやすい内容である
簡潔性	出力が冗長ではない文章で提供されている
包括性	出力が質問の意図・要求を網羅的に満たしてる
有用性	出力が質問者のペインポイントを解消し、後続作業に繋がる

2.各項目に対する評価スコアの定義と合否基準の策定

次に各評価項目に対し、評価スコアを定義していきます。
また、合わせて各評価項目の合格閾値を定めます。

以下、「関連性」を一例にした評価スコアの定義です。

スコア	定義	合否
5	質問の意図を完全に理解し、求められている情報のみを適切に提供しており、不要な情報が一切ない	合格
4	質問の意図を理解しており、関連性の高い情報を提供しているが、ごくわずかに不要な情報や関連性の低い情報が含まれる	合格
3	質問の意図を部分的にしか理解しておらず、主題に対する重要な情報が欠落している	不合格
2	質問の意図を十分に理解しておらず、提供された情報の大部分が質問と関連性が低い	不合格
1	質問と全く関連性のない回答である	不合格

この際、品質担保と開発スピードのバランスを取るポイントとなるのが、評価項目の重要度別に合格閾値を細かく重み付けを設定することです。

例えば、「正確性」は非常にクリティカルな項目なので、少しでも矛盾が発生している場合は不合格とするような厳しい閾値を設定しつつ、「流暢性」は不自然な言い回しが多少あったとしても内容の理解を妨げるほどではない場合には合格とする等の重み付けをします。

3.実運用を想定した複数の質問と正しい回答の準備

評価にあたり、実運用上で発生しうる質問・正解データとなる回答を準備します。ドメイン知識が必要とされることが多く、必要に応じてユーザー部署も巻き込みながら実施すると良いでしょう。

4.RAGシステムで生成した回答に対し、複数人でスコアリング

前述の手順で用意した想定質問をRAGチャットボットに入力し、出力回答を取得して回答精度を評価します。
手動評価のメリットとしてスコア付けとあわせて、定性コメントを残すことで課題点を明確にする点があります。

また、評価者・人数については下記のように評価項目の観点に沿ってアサインを工夫することが有効になります。

「正確性」・「関連性」： ハルシネーションに気づけることが最重要観点になるため、ドメイン知識をもった有識者（複数名）の評価が必須と考えます
上記以外の項目： ドメイン知識の少ないユーザーを想定して評価する観点が重要になるため、有識者以外のメンバーでも、できるだけ多くの人（少なくとも5~10名）に協力をしてもらえると事前の検証として十分な量のフィードバックが得られると考えます

5.評価者のコメントも踏まえ、最終的な合否判定の実施

最後にいよいよ導入の最終判断材料となる合否を判定します。
今回複数人で評価を実施しましたが、最終判断の軸として評価者全員のスコアの平均値を算出し、各観点に設定された合格閾値（クライテリア）を満たしているかを確認し、想定質問ごとの合否を判定しました。

合格閾値に満たない場合の改善サイクル

特に初めてのユースケースに対してRAGを用いたサービスを構築するとき、評価が合格閾値を満たさないことも多いと思います。私たちも評価をして始めて気づくような課題がいくつか発生しました。その際、私たちは主に以下の観点から改善策を検討し、評価→改善→再評価のサイクルを回しました。

RAGにインプットしている資料の再確認
「正確性」が致命的に低い、例えばIPアドレス等の固有値の回答が異なってしまう場合は、そもそも参照元データ（インプット資料）に問題のある可能性が高いです。

対応例:
複数の資料間に存在する表記揺れや矛盾を統一し、インプットデータの品質を向上させる。
類似ファイルが存在する場合、参照するべきファイルをシステムが検索しやすいようにタグ付けなどのメタデータを追加する。

システムに組み込むプロンプトの見直し
「具体性」や「流暢性」など、文章のスタイルに関するスコアが低い場合、システム側に組み込むプロンプトの見直し（プロンプトエンジニアリング）が有効です。

対応例:
「作業手順を箇条書きを用いて回答してください」「専門用語には可能な限り補足説明を加えてください」といった指示をシステムプロンプトに追加する。

このとおり、手動評価で実施して得られる具体的な課題を改善策に紐づけて修正し、再評価を行うことがリリース前の段階からRAGの品質を向上させる鍵となります。

実際の開発の中での事例

実際に私たちがRAGチャットボットを開発して評価した際に、正確性に関わる問題をいくつか見つけることができ、品質の改善に繋がりました。

具体的な例をあげますと、データに関するテーブル定義書等の情報をインプットしているチャットボットを開発していました。そして、その評価中に存在しない近しい名称のテーブル名を答える問題が発生しました。

事象だけでは原因追及から対応策の検討まで難しかったため、一つずつ可能性を潰していきました。その中で徐々に事象の原因が明確になっていき、

インプット資料の型をExcelからjsonに変更する
RAGの検索精度を上げるため、Geminiで要約したテーブルの特徴をプロンプトに組み込む

という対策をすることでハルシネーションの問題を解消できたことがありました。

まとめ

RAGを用いたサービスを開発から実務で使える精度へと昇華させるためには、定量的で客観的な品質評価が不可欠です。

私たちの実践では、以下の改善サイクルを回すことで、RAGシステムの精度向上を実現しました。

評価観点の明確化:　ハルシネーション対策となる正確性・関連性を最重要項目とし、具体性・包括性・有用性・流暢性・簡潔性を含めた7つの多角的な評価観点と、重要性に応じた重み付けをした合格閾値を設定しました
手動評価の実施:　実務適用に耐えうる信頼性を担保するため、複数人による手動でのスコアリングを主軸としました
改善サイクルの確立:　不合格となった回答については、プロンプトやインプット資料の再考という観点から原因を特定し、対策を講じた上で、必ず再評価を実施しました

この地道な「評価→改善→再評価」のプロセスを通じて、私たちはユーザーが安心して利用できる、信頼性の高いRAGシステムを構築することができました。

本記事の内容が、RAG開発を進める方々の参考になれば嬉しく思います。
最後までお読みいただいた皆さま、ありがとうございました。