RAGの評価：評価の必要性と問題点

本ブログはこんな人におすすめ

RAG (Retrieval Augmented Generation)を使ったアプリケーションを開発しているけど評価に関心のある人
LLM (Large Language Model)やRAGのハルシネーションをどう評価するのかに関心のある人
Ragas (RAGの評価ライブラリ：Retrieval augmented generation assessment)の挙動に興味がある人

こんにちは。私はBeatrustのML周辺のお手伝いをしている鈴木宏和と申します。今回はこれから3つのパートに分けて紹介させていただきますが、LLMの応用として特に注目を集めているRAG (Retrieval Augmented Generation)について、RAGの評価の必要性とアプローチ方法について考察しつつ、RAGに特化した評価ライブラリであるRagasの有用性に関する実験を行いました。

実験では、私が評価用のデータをすべてマニュアルで作成し、自分の感覚値とRagasの評価値の相関を取ることで、Ragasの有用性を評価しました。このブログでは以下に分けて、説明させていきます。

RAGの評価：評価の必要性と問題点 (本パート)
RAGの評価：RAGの計算指標とRagasでの計算方法
RAGの評価：Ragasの有用性の評価

それら一連の実験を通して、RagasはGeneration部分とRetrival部分を分けて評価できるのでRAG評価に適していると感じた一方、期待ほど高い評価精度は得られなかったとの結果が得られました。

なお、本ブログの執筆と実験はBeatrustのMLエンジニアであるファンヨンテさんの元で行われました。

RAGとは

ChatGPTを含めた一般的なLLMは、学習データに含まれていない最新情報や会社内部の機密情報などを知らないため、少し古かったり、一般的であったりする回答のみが生成されてしまいます。自分専用のLLMアプリケーションを作ろうとする場合、LLMモデル自体を自分専用にチューニングする方法が考えられますが、コストが非常にかかってしまうだけでなく、チューニングによって綺麗なバランスで成り立っていたLLMモデルの精度を劣化させてしまうかもしれないという懸念があります。

そこで、LLMに参考情報を与えて回答させるRAG (Retrieval Augmented Generation)という方法があります。こちらは、コスト効率の観点から優れているため、自身のカスタムLLMアプリ作成にはRAGが主流になりつつあります。応用範囲が非常に広いため、顧客サポート用のチャットボット、社内文章のFAQ、大規模データを基にしたリサーチといった多くの実用例が出てきています。McKinseyのLilliやMoody'sのMoody's Research Assistantといった民間企業をはじめ、英国政府のGOV.UK Chatのように行政での導入も始まってます。

RAGはLLMに検索・取得技術を組合した物で、回答を生成する際に、外部のデータベースから関連する情報を取得（Retrieval）し、この情報を基に回答を生成（Generation）していきます。図表１−１は代表的なRAGの例を図示したものです。

図表１−１は以下のような要素により構成されます。

データベース構築部分
1. 資料から文を抽出
2. 文を適定の長さに分割
3. 分割された文をベクトル化
4. ベクトル化したものをデータベースに保管
生成部分
1. 質問をベクトル化
2. ベクトル化した質問に関連する情報をベクトルデータベースから取得
3. 関連情報とクエリをLLMに入力
4. LLMが回答を生成

RAG普及の障壁

LLMが生成する文章は非常に滑らかで人間が作成しているのかと錯覚するほど高性能です。しかし、生成された文章が正確である保証はされてなく、"間違った答えさえも合っているように回答する可能性"があります。これまでのチャットボットでの不適切な回答は、内容が全く違うなど、明らかに間違いと判別できるものでしたが、LLMでは間違った内容さえも合っているかのように自然に回答するのでユーザーが間違った情報を正しいものと誤解してしまう可能性があります。

最近の講演資料はこんな感じ https://t.co/KO0XgAq0bP pic.twitter.com/JZbhvw0OP3
— ところてん (@tokoroten) March 28, 2024

このような現象はハルシネーション(Hallucination)と呼ばれ、LLM普及における大きな懸念となっており、その普及に当たっての越えるべき課題の1つになっています。なお、RAGを用いることでハルシネーションを緩少させられる可能性があるという意見もありますが、定量的な評価はされておらず、実運用に耐えられるかどうかが評価できません。

RAG評価の必要性

このハルシネーションの問題を対策し、実運用に耐えられるようにするためには、RAGの回答の客観的かつ定量的な評価が肝となると考えています。その理由として、RAGの回答の正確性を定量的に評価できれば、それを指標にしながらモデルの改善をすることができるためです。

LLMの評価自体は最先端の研究として注目されていますが、RAGの評価となると執筆時（2024年初旬）になってようやく色々なブログ記事やサーベイで取り上げられ始めたという印象です。これは、RAGでは検索と生成の2つの技術を組合しているため、精度の客観的評価が難しいためです。

このため、現在のRAGの改善では人が目検で結果を目視で確認し評価するような定性的な評価に基づいて行われている印象があります。以下は、RAGのパフォーマンスを向上させるために考慮すべき主なポイントを紹介していますので、ご関心がある方はご覧ください。

RAGの改善ポイント

Dataのフォーマットや質
従来の機械学習での教師あり学習と同様に、RAGのパフォーマンスは検索の基となるドキュメントデータに大きく依存します。ドキュメントの内容が不正確もしくは偏っている場合、RAGでの回答は不正確なものになってしまうのは当然です。また、ドキュメントデータのフォーマット、抽出方法、前処理も大きな影響を与える可能性があります。

Chunking
Chunkingとは生のドキュメントから読み込んだテキストデータをチャンク（データの塊）ごとに分割していく作業です。300や500といったあらかじめ設定したトークン数ごとに区切っていくことが多いですが、分割するトークンサイズが小さすぎるとドキュメントのコンテキストを適切に反映させられない一方、トークンサイズが多すぎるとクエリに関係のないコンテキストを多く含んでしまうため、綺麗なバランスが求められます。
また、重複をどこまで許容するかも大切なポイントになってきます。ここでの重複とは隣接するチャンクでのトークンを意図的に重複させることを指し、例えば、100トークンの重複を設定する場合、とあるチャンクの最初の50トークンと前の50トークンが同じに、最後の50トークンと次の50トークンと同じになります。
あまり意識されることのないChunkingですが、以下で述べるEmbeddingよりもパフォーマンスに与える影響が大きいとの調査もなされており、しっかりと検討すべきポイントの一つになります。

Embedding Model
Embeddingとはテキストをベクトル表現に変換する作業を指します。RAGでは、ベクトル変換されたテキストデータに対して、同じくベクトル変換された入力したクエリを用いて検索を行うことになるため、どのEmbedding Modelを使うかは非常に重要なポイントになります。

Embedding ModelにはOpenAI text-embedding-ada-002のような大規模なものから、特定の領域に特化したものまで様々あります。大規模モデルはあらゆるケースに想定されて開発されており使い勝手は良いのですが、RAGが対象とする領域が狭まっている場合は特定ドメインに特化したモデルの方がパフォーマンスがよくなるとの調査報告もなされています。特定モデルの場合は、大規模モデルに比べてコストが低いこともあるため、Embedding Modelの選択は用途に合わせて慎重に検討していった方がいいと言えるでしょう。

Vector Search
一般的に、RAGではベクトル検索を用いてデータベースから情報を取得します。例えば、LangChainでは、検索アルゴリズムとしてコサイン類似度のほかMMRなどが実装されており、両者での挙動は大きく異なってきます。また、検索で取得した情報のうち、いくつをLLMの回答の生成に使用するのかもRAGのパフォーマンスへの影響を与えます。また、RAGが対象とするドメインによっては、BM25のような用語ベースの検索手法と併せたハイブリッドな取得方法も考えられるため、RAGのドメインやデータの特性を踏まえた戦略をとる必要があります。

LLM Model
当然ですが、LLMのモデルも重要なポイントになってきます。特にLLMについては、精度だけではなく、応答時間やコストといった側面も見極めに際して大切になってきますので、RAGの設計に合わせた選択をする必要があります。

Model architecture
SimpleなVector Search だけでは精度が出ないことは周知されており、RAGのフロー全体の工夫も盛んに行われています。この記事では、Vector SearchとSQLによるデータ取得を組み合わせたフローの提案をしています。このようなフローにすることにより、回答までの速度や精度の向上が見込まれます

しかし定性的な評価では限界があります。特に人間が確認する場合は、数に限界がありますし、良い結果だけを見てしまいがちというバイアスの問題もあります。また、RAGを用いたプロダクトやサービスをリリースした後に、カスタマー等から様々な要望が寄せられることがありますが、客観的評価を整備しておくことで、適切に改善していくというステップを踏むこともできるようになります。

RAGの定量評価

RAGの定量評価では、

人間による評価
LLMによる直接的な評価（GPT4等）
RAGに特化した評価（Ragas等）

等が考えられます。どのような特性があるかそれぞれメリット・デメリットを挙げていきつつ、考察していきます。

1. 人間による評価

RAGの回答に対して、多くの人を動員し、すべて目検で正確性を確認していく方法です。

メリット
- 資金を投入すれば実現可能です。人間による評価になりますので、実際のユーザーの感覚を最も反映しているため、プロダクトやサービスへのUX改善にも直結しているといったメリットがあります。
デメリット
- 多くの人員を動員するためコストがかかり過ぎるほか、特定の分野での専門的知識が求められる場合の動員が難しいことも想定されます。また、人間が評価できるスピードは機械に比べかなり遅くなります。更に、疲れなどにより評価基準が一定しないという問題も挙げられます。

2. LLMによる直接的な評価（GPT4等）

RAGの回答に対して、ChatGPTなどのLLMに以下のようなプロンプトを与えることでLLMに直接評価してもらう方法です。ここでは評価の高いLLMであるGPT4で直接評価する場合を想定しています。

あなたは、回答を定量的に評価するスペシャリストです。以下の回答の正確性について、0～100の点数で評価してください。

# 質問
<質問を代入>

# 回答
<回答を代入>

# 回答に用いた参照文章
<回答に用いた参照文章を代入>

メリット
- GPT4が自動的にに評価を行いますので、大量の処理が可能であるほか、人間のように疲れや怠れ等で評価基準が変化することもありません。
デメリット
- バイアス : GPTは自ら生成した回答が好きだという問題があります。いわゆる自己強化バイアスです。私の所感でも、評価LLM（GPT4）に"GPT4が生成した間違った回答とGround Truthを比較させたところ、"Ground Truthは根拠がなく間違っており、GPTの回答が正しいです"と答えられたことが度々あり、これは完全にナンセンスです。このほかのバイアスでは冗長バイアスという長めの回答を好むことなども指摘されています。
- プロンプトチューニング：GPTによる直接評価ではプロンプトに対してセンシティブであり、タスクに応じてプロンプトを作り替えていくコストも無視できるものではありません。
- 相対的な評価の困難さ : 更にGPT4はタスク内での相対的な評価を苦手としています。例えばプロンプトが「この文章の健全さを0〜100で評価して下さい」という場合、GPT4にはそのデータだけが与えられており、他のデータたちの得点を得点をもとに評価できないので、毎回80、正確でなければ毎回20点のような当たり障りのない回答をすることがあります。文章Aが50点だったから、文章Bは60点というような相対的な評価を行うことが難しいのです。

このようなデメリットが挙げられるため、様々な手法が開発されています。例えば、SelfCheckGPTでは事実の回答は架空の回答よりも安定していると考え、GPT4による回答を得た後、追加で複数のサンプルを生成、回答とサンプルの一致度合いを測定していきます。また、回答を比較するという文脈では、gpt-prompt-engineerは2つの回答を比較することでよいプロンプトを検索するようになっています。

3. RAGに特化した評価（Ragas等）

これまで人間とLLMによる評価を見てきましたが、いずれもEnd-to-Endでの評価に留まっているという問題点があり、検索と生成の2つの技術を併せたRAGでの評価には必ずしも適切ではないという見方もできます。例えば、生成部分が完璧であったとしても検索部分が良くないとハルシネーションを引き起こす可能性は高くなりますし、逆に検索部分が完璧であったとしても生成部分が良くないと適切な回答を生成できない可能性が高くなります。このため、RAGに特化した評価方法としては、RagasやAnyscaleの2段階アプローチなどが提唱されています。いずれも検索・取得の評価（図１−２の青色部分）と生成での評価（図１−２のオレンジ色部分）を分けて考えているのが特徴になります。