検索補強世代（RAG）の評価：知っておくべきことすべて
#はじめに
検索拡張ジェネレーション(RAG)は、大規模言語モデル(LLM)を搭載したジェネレーティブAIアプリケーションを実装するために広く採用されている。外部の知識ソースを統合することで、RAGは特定のクエリに対してより正確で文脈に関連した応答を提供するモデルの能力を強化する。その可能性にもかかわらず、RAGが生成する回答は、常に完全に正確であったり、検索された知識と一致しているわけではない。
最近のウェビナーでは、Zillizのデベロッパー・アドボケイトであるStefan Webbが、LLMのパフォーマンスを評価する方法に焦点を当て、この分野における現在の課題と限界に取り組みながら、RAGアプリケーションの評価戦略について探求した。
このブログでは、様々なRAGパイプライン・アーキテクチャの概要、検索と評価のフレームワーク、LLMにおけるバイアスと失敗の例など、Stefanの重要な洞察を振り返る。RAG アーキテクチャ
Stefan氏はまず、RAGアプリケーションの重要な要素であるセマンティック検索の基礎概念を紹介した。セマンティック検索は、ベクトル埋め込みの知識ベース記憶システムとして、MilvusやZillizのようなベクトルデータベースを活用する。これらのデータベースは、非構造化データを効率的に検索し、ユーザのクエリに関連する意味的に類似したコンテキストを取り出すことを可能にする。この機能はRAGシステムのバックボーンを形成し、検索された知識が入力された質問と密接に一致することを保証し、それによって生成された応答の質を高める。
以下の図1は、基本的で素朴なRAGアーキテクチャを示している。このセットアップでは、システムはユーザーの質問に対する意味的類似性に基づいて最も関連性の高い文書を検索する。そして、検索された情報は、指示とともに構造化されたプロンプトにフォーマットされ、LLMに渡される。LLMはこの文脈を利用して、十分な情報に基づいた応答を生成する。
図1：ナイーブRAG](https://assets.zilliz.com/RAG_architecture_a4710eb118.png)
図1：ナイーブRAG
基本的なRAGパイプラインは関連文書を検索し、応答を生成することができるが、その性能は常に最適というわけではない。一部の出力は正確さや関連性に欠ける可能性がある。このような課題に対処するため、RAGパイプラインを構築するモジュール式アプローチにより、各段階で段階的な改善を行うことができます。
以下に（図2に示すように）パイプラインの有効性を高める主なテクニックを示す。
図2：RAGモジュラーアーキテクチャ](https://assets.zilliz.com/Figure_2_RAG_Modular_Architecture_44f466b986.png)
図2：RAGモジュラー・アーキテクチャー(Source)_。
クエリ翻訳
このステップでは、ユーザーのクエリがシステムによって適切に理解されるようにすることに重点を置く。クエリを、基本的な検索メカニズムに沿った形式または表現に変換します。
マルチクエリーメインクエリを複数のサブクエリに分割し、多様でありながら関連性の高い情報を取得する。
ステップバック検索結果が不十分な場合、パイプラインの前のステップを再検討し、より良い検索のためにクエリを改良します。
RAGフュージョン**：複数のクエリからの結果を統合し、LLMにまとまりのある包括的なコンテキストを提供する。
仮説文書（HyDE）**](https://zilliz.com/learn/improve-rag-and-information-retrieval-with-hyde-hypothetical-document-embeddings)：知識ベースから意味的に類似した文書を検索する際に役立つ合成文書や仮想コンテキストを生成することで、抽象的なクエリや枠組みが不十分なクエリの検索を改善する。
クエリルーティング
クエリルーティングアプローチは、クエリを最適な検索メカニズムまたは知識ソースに誘導する。
論理ルーティングメタデータやドメインによるフィルタリングなど、事前に定義されたルールや論理演算子に基づいてクエリをルーティングします。
セマンティックルーティングセマンティックルーティング**：クエリーのセマンティック特性に基づいて、クエリーを処理するのに最適なデータベースやシステムにクエリーを誘導します。
クエリの構築
クエリ構築は、基礎となるデータベースの構造に合わせて、クエリの策定方法を改良します。
リレーショナル DB**：伝統的なリレーショナル・データベース用の SQL ライクなクエリを構築します。
グラフ DB：グラフ DB: グラフデータベースのノードとリレーションシップを探索するために、グラフ走査 Cypher クエリを使用する。
ベクトルDB**](https://zilliz.com/glossary/ai-database)：意味的類似性](https://zilliz.com/glossary/semantic-similarity)検索のためのベクトル化されたクエリを作成するために埋め込みを活用する。
インデックス作成
索引付けは、知識ベースの構成とアクセシビリティを向上させます。
チャンク最適化**](https://zilliz.com/learn/guide-to-chunking-strategies-for-rag)：コンテキストを保持しながら、ドキュメントを意味のある、検索可能なチャンクに分割する。
複数の表現によるインデックス作成**：多様な検索ニーズのために、データの複数の表現（例えば、意味的、構文的）を作成する。
特殊化** エンベッディング：専門性の高い情報や技術的な情報の検索を強化するために、ドメイン固有の埋め込みを使用する。
階層的インデックス**：インデックスを階層的に構造化し、より高速で正確な検索を実現。
検索
高度な技術を使用して、与えられたクエリに対して最も関連性の高いドキュメントやコンテキストを検索します。
ランキング：検索されたドキュメントを関連性に基づいてスコアリングし、最適なマッチが優先されるようにします。
修正RAG**：フィードバックや追加基準に基づいてランキングを調整し、結果を動的に改善します。
再検索**：最初の結果が期待される品質を満たしていない場合、許容できる結果が見つかるまでプロセスを改良しながら、文書を繰り返し検索する。
RAGパイプラインを構築するためのこのモジュラーアプローチは、各コンポーネントを独立して微調整します。各段階で特定の課題に対処することで、パイプラインはより堅牢で、正確で、適応性が高くなり、最終的に生成されるアウトプットの品質が向上する。
基礎モデルの評価
素朴なRAGアプローチであれ高度なRAGアプローチであれ、各RAGアプリケーションのパフォーマンスを評価することは不可欠である。この評価により、長所と短所を特定し、システムの信頼性と妥当性を確保することができる。すべてのLLMは、その精巧さにかかわらず、潜在的な限界、偏り、不正確さに対処するための厳格な性能評価が必要である。
パフォーマンス評価
しかし、どのようにしてモデルの性能を測定し、評価するのでしょうか？RAGアプリケーションのパフォーマンスを測定するには、パイプラインのさまざまな側面を評価する必要があるため、微妙なアプローチが必要です。以下は、効果的なパフォーマンス測定のための主な検討事項と方法である：
タスクに対する評価とそれ自体に対する評価。
タスク評価：タスク評価：あらかじめ定義された一連のタスクに対するモデルのパフォーマンスを測定する。このタスクには、マルチターン（例：MT-Bench）またはマルチタスク（例：MMLU）シナリオが含まれることが多い。各タスクには、特定のグランド・トゥルース質問と参照解答が関連付けられている。
自己評価：自己評価：実用的なユースケースに必ずしも結びつけることなく、モデルがいかに効率的に情報を検索し、処理するかといった内部的なパフォーマンス測定基準に焦点を当てる。これはパイプラインのパフォーマンスを診断するのに役立ちます。
グランドトゥルースとコンテキストの答えを比較する。
グランドトゥルース比較**：生成された回答が事前に定義された正確な回答（ground truth）にどれだけ近いかを評価します。このアプローチは事実に基づいたクエリのような客観的なタスクに効果的です。
コンテキスト比較**：検索されたドキュメントによって提供されたコンテキストに、レスポンスがどれだけ合致しているかを検証する。これは、グランドトゥルースが利用できないタスクや主観的なタスクでは特に重要で、一貫性と関連性を重視します。
検索結果の評価とLLM出力の評価の比較
検索評価**：パイプラインによって検索された文書の品質に焦点を当てる。指標としては、検索された文書とクエリとの間の再現率や精度などがある。
LLM出力評価**：言語モデルによって生成された最終的な出力の品質を調べ、事実の一貫性、クエリや検索されたコンテキストとの関連性などの要素を考慮する。
**ゴールドスタンダードとしての人間による評価
- 人間の評価は、特に主観的または複雑なタスクのパフォーマンスを評価するための最も信頼できる方法です。人間は、論理的一貫性、トーン、創造性などのニュアンス的な側面を評価することができる。しかし、このアプローチは時間とリソースを必要とするため、うまくスケールしません。
LLMを使ってLLMを評価する（LLM-as-a-Judge）*。
- より高度で効率的なLLM（LLM-as-a-Judge）は、他のLLMの出力を評価するために採用することができます。これらのモデルは、関連性や正しさのような事前に定義された基準に基づいて応答をスコアリングすることができ、人間の評価に代わるスケーラブルな代替手段を提供する。しかし、評価モデル自身からバイアスが入らないように注意しなければならない。
Stefan氏は、タスクベースの評価と自己評価という2つの評価アプローチを取り上げ、議論を続けた。タスクベースの評価は、一般に公開されているベンチマークに依存するのに対し、自己評価は、生成された回答の品質や検索された情報の関連性を調べるなど、内部的な尺度や内省に重点を置く。
タスクベースの評価：ベンチマーク・アプローチ
タスクベースの評価は、さまざまなタスクにわたってモデルのパフォーマンスを評価する、標準的で一般に公開されているベンチマークを使用することに基づいています。これらのベンチマークは、多くの場合、知識、質問応答能力、会話スキルなど、さまざまな領域をカバーしています。例えば、以下のようなものがあります：
知識ベースのベンチマーク**：これらのベンチマークは、一般的な知識と事実に基づいた質問回答に重点を置いています。
MMLU](https://zilliz.com/glossary/mmlu-benchmark)：数学、科学、歴史など、様々な分野の言語モデルをテストするベンチマーク。
HellaSwag：常識的な推論を測定するために設計されたベンチマーク。
ARC：推論機能を備えた質問応答ベンチマーク。
Instruction Following Benchmarks：これらのベンチマークは、モデルの指示に従って適切な応答を生成する能力を評価します。
Flan：LLMの指示に従う能力を評価する一連のタスク。
自己指示：LLMが自分で作成した指示に従う能力を評価する。
NaturalInstructions：自然言語の指示に従うモデルの能力に焦点を当てた大規模ベンチマーク。
会話ベンチマーク**：これらのベンチマークは、モデルが首尾一貫した適切な対話を行う能力を評価します。
CoQA：会話型質問応答データセットで、複数ターンの対話でモデルをテストします。
MMDialog：様々なシナリオにおける対話の品質に焦点を当てた会話ベンチマーク。
OpenAssistant: 会話AIベンチマークで、モデルの自然な会話能力を評価します。
ベンチマークは標準化された評価基準を提供しますが、感情的な知性、会話の流れ、文脈の敏感さなど、人間の対話のニュアンスを捉えられないことがよくあります。例えば、ベンチマークによれば事実上正しい応答であっても、人間が実世界の会話で重視する重要な要素である自然さや共感性という点では不十分な場合があります。さらに、ベンチマークは、文脈、ユーザーの意図、感情的なトーンによって変化する人間の好みの複雑さを必ずしも反映しているとは限りません。 ベンチマークが見落としがちな人間の嗜好を考慮するため、人間による評価が会話AIを評価する際の「ゴールドスタンダード」であり続ける理由はここにある。しかし、人間による評価にはコストとリソースを要するという性質があるため、よりスケーラブルな選択肢として、イントロスペクションに基づく評価などの代替方法を検討することができます。
内観ベースの評価
イントロスペクションベースの評価は、モデルによって生成されたレスポンスの品質とコンテキストとの整合性を評価することに重点を置き、モデルのアウトプットが入力によって設定された期待にどれだけ忠実であるかを測定することを目的としています。このタイプの評価は、2つの主要なカテゴリーに分けることができます：生成ベースの評価と検索ベースの評価です。以下は、関連する評価指標の例です：
**世代ベースの評価
忠実度（Groundedness）**：このメトリクスは、与えられたコンテキストに対する生成された答えの事実上の一貫性を測定します。モデルが検索されたコンテキストによってサポートされない主張を生成した場合、それらの主張はペナルティを受けます。忠実度は、モデルの出力が一貫しており、かつ提供された情報に根拠があることを保証します。
回答の妥当性**：この指標は、回答がユーザーの質問や与えられたコンテキストにどれだけ直接対応しているかを評価する。関連性の高い回答は、正確であると同時に文脈に適しており、クエリに対して最も有用な回答を提供します。
**検索ベースの評価
コンテキストの関連性：検索されたドキュメントまたはコンテキストが、クエリにどれだけ関連しているかを測定する。理想的には、検索されたコンテキストは質問に答えるために必要な情報だけを含むべきである。無関係な情報や余計な情報は、生成されたレスポンスの質を低下させる可能性がある。
コンテキスト・リコール：このメトリックは、検索されたコンテキストが、グランドトゥルースとどの程度一致しているかを評価します。これは、関連するドキュメントが最初に検索されたかどうかを評価するのに役立ち、モデルが意味のあるレスポンスを生成するのに十分な情報を持っていることを保証します。
忠実性、解答の関連性、文脈の関連性のメトリクスでは、グランドトゥルースの欠如が直接的な評価の課題となる。しかし、グランドトゥルースがない場合、LLM-as-a-Judgeを採用する方法があります。強力なLLMは、回答の一貫性、関連性、事実の根拠を分析することで、これらの側面を採点するために使用することができます。生成された回答を、文脈と関連性に関する独自の理解と比較することで、モデルは自動化された評価を提供することができる。
審査員としてのLLMの課題と限界
LLM-as-a-Judgeを使用することは、グランド・トゥルースが利用できない場合にメトリクスを評価するための有用な代替手段となり得ますが、このアプローチは、対処しなければならない特定の課題と限界をもたらします。評価モデル自体がバイアスをもたらす可能性があり、それが評価の質と公平性に影響を与える可能性があります。以下に、考慮すべき一般的なバイアスと課題を示します。
ポジション・バイアス
順位バイアスとは、評価モデルがランキングの順位や表示順に基づいて回答を優遇する傾向を指します。多くの場合、モデルは実際の品質に関係なく、1位または上位の回答がより適切または正確であると仮定することがあります。これは、特に上位の順位にモデルが偏るため、正しい答えが下位にランクされるような場合、不正確な評価につながる可能性があります。
図3: 順位バイアス](https://assets.zilliz.com/Figure_3_Position_Bias_a0413c0090.png)
図3：ポジションの偏り(Source)_。
動詞度バイアス
冗長性バイアスは、評価モデルがより長く、より詳細な回答を好む傾向がある場合に発生します。場合によっては、モデルが冗長性と品質を誤って同一視し、不必要な情報を含む長い回答に高いスコアを割り当ててしまうことがあります。これは、特に簡潔で明確な回答がより望ましい状況において、評価プロセスを歪める可能性があります。
図4：冗長性バイアス](https://assets.zilliz.com/Figure_4_Verbosity_Bias_b1a51bf8f5.png)
図4：冗長性バイアス(Source)_。
誤った判断
もう一つの限界は、誤った判断の可能性である。LLM-as-a-Judgeは、他のモデルと同様に、回答の質や関連性を評価する際に間違いを犯す可能性があります。例えば、文脈を誤解したり、微妙な詳細を見落としたり、回答のニュアンスを認識できなかったりして、誤った評価結果や誤解を招く可能性があります。
図5: 誤った判断](https://assets.zilliz.com/Figure_5_Wrong_Judgement_deaf609b07.png)
図5: 誤った判断 (ソース)_)
思考の連鎖による誤った判断
LLMベースの評価におけるChain-of-Thought (CoT) 推論は、評価精度を著しく損なう複雑なエラー伝播メカニズムを導入する。各中間的な推論ステップは潜在的な障害点として機能し、些細な解釈の誤りや論理的矛盾であっても、最終的な判断における重大なエラーへと連鎖する可能性がある。例えば、推論チェーンの初期段階が、重要な文脈的ニュアンスを誤解していたり、回答の特定の側面に誤った重み付けをしていたりすると、後続の推論ステップは、この欠陥のある土台の上に構築され、最初のエラーを指数関数的に増幅することになる。
図6：思考の連鎖による誤った判断](https://assets.zilliz.com/Figure_6_Wrong_Judgement_with_Chain_of_thought_6e5f684ed4.png)
図6：思考の連鎖による誤った判断 (Source)_。
これらのバイアスは、LLM-as-a-Judgeアプローチの限界に対処する評価戦略を採用することの重要性を浮き彫りにしている。1つの解決策は、GroundedAIやFlow-Judge-v0.1のような、評価目的のために特別に微調整されたLLMモデルを使用することである。もう一つの戦略は、可能な限りLLM-as-a-Judgeによる評価を人間の評価と組み合わせることである。人間の評価者は、自動化されたモデルには欠けているかもしれない、微妙な理解と文脈認識をもたらす。バイアスを最小化し、信頼性を高めるためには、モデルを評価するための定期的な監査と反復的な改善も不可欠です。
オープンソース評価フレームワーク
LLM-as-a-Judge技術に加えて、いくつかのオープンソースの評価フレームワークが、RAGアプリケーションを評価するために市場で広く使用されている。これらのフレームワークは、検索と生成のパフォーマンスを効果的に評価するための構造化された方法論とツールを提供します：
ragas**](https://zilliz.com/blog/rag-evaluation-using-ragas)：RAGアプリケーションに合わせたメトリクスでRAGシステムを評価するためのフレームワーク。
DeepEval：複数の評価メトリクスでRAGシステムやファインチューニングシステムを評価するための柔軟で堅牢なツール。
ARES**：RAGモデルの評価のために設計され、文脈の関連性、答えの忠実性、答えの関連性に重点を置いている。
HuggingFace Lighteval**：複数のバックエンド（例えば、transformers、tgi、vllm、nanotron）にまたがるRAGアプリケーションを評価するための軽量で拡張可能なツールを提供。
これらのフレームワークは、評価プロセスを簡素化し、異なるシステム間のパフォーマンスメトリクスの標準化を支援し、比較可能性と改善を促進します。
結論
検索補強型生成（RAG）は、大規模言語モデル（LLM）の能力を強化するための革新的なアプローチである。しかし、その成功は強固な評価と継続的な改良に依存している。Stefanがウェビナーで強調したように、RAGパイプラインは複雑で、クエリの翻訳から最終的な応答生成まで複数の段階を含んでいます。LLM-as-a-Judgeの評価におけるバイアスの軽減から、正確な検索とユーザーの期待に応えるレスポンスの生成まで、課題は多岐にわたります。
重要なことは、RAG評価には万能のソリューションはないということです。成功を収めるには、タスクベースのベンチマーク、内省的メトリクス、オープンソースの評価フレームワーク、そして可能であれば人間による評価など、多様な評価手法を組み合わせた、ニュアンスの異なる多面的なアプローチが必要です。RAGAS、DeepEval、ARESのようなツールは貴重なサポートを提供するが、決定的な答えではない。むしろ、進化し続けるジェネレーティブAIの状況において、進化するツールなのだ。
今後、RAGの未来は、その適応性と継続的な改良にある。AIシステムがより洗練されていくにつれ、そのパフォーマンスを評価し、向上させる能力は、その潜在能力を最大限に引き出すために不可欠となるだろう。現在の限界に対処し、革新的な評価方法を取り入れることで、RAGアプリケーションは、正確で、文脈に関連した、信頼できる情報を一貫して提供することができ、AI分野の進歩を促進する。
続きを読む
高度なRAG技術：テキストとビジュアルの橋渡し ](https://zilliz.com/blog/advanced-rag-techniques-bridging-text-and-visuals-for-accurate-responses)
vLLMとMilvusによるマルチモーダルRAGシステムの展開 ](https://zilliz.com/blog/deploy-multimodal-rag-using-vllm-and-milvus)
PII MaskerとMilvusによる安全なRAGの構築](https://zilliz.com/blog/safe-rag-with-hydrox-ai-and-zilliz-pii-masking-for-responsible-genai)
GraphRAGとは何か 知識グラフによるRAGの拡張 ](https://zilliz.com/blog/graphrag-explained-enhance-rag-with-knowledge-graphs)
Trulensを使ったマルチモーダルRAGの評価](https://zilliz.com/blog/evaluating-multimodal-rags-in-practice-trulens)
HyDE - Hypothetical Document EmbeddingsによるRAGの改善](https://zilliz.com/learn/improve-rag-and-information-retrieval-with-hyde-hypothetical-document-embeddings)
ColPali: 視覚言語モデルによる効率的な文書検索](https://arxiv.org/html/2407.01449v2)
GenAIエコシステムの展望：LLMとベクトルデータベースを超えて](https://zilliz.com/blog/landscape-of-gen-ai-ecosystem-beyond-llms-and-vector-databases)
あなたのGenAIアプリのためのトップパフォーマンスAIモデル｜Zilliz](https://zilliz.com/ai-models)
MilvusでAIアプリを作る：チュートリアル＆ノートブック](https://zilliz.com/learn/milvus-notebooks)
Benito MartinFreelance Technical Writer
読み続けて
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.
AI Integration in the Legal Industry: Revolutionizing Legal Practice with Data-Driven Solutions
Discover how AI and vector databases are revolutionizing legal work through advanced document processing, semantic search, and contract analysis capabilities.