RAG プロジェクトを成功させる方法 #2 ~ 失敗から始まりベクトル検索をやめた理由 ~

連載第一回 では、まず評価データを 20 件ほど作成し、プロンプトレベルで実現性を評価しようということをお伝えしました。今回もそのように進めたいと思います。

Amazon Bedrock を利用する開発者がしそうな質問と回答のペアを 18 件手で作成しました。今回作成した質問は全てドキュメントに答えが載っており回答できるものになっています。また、余談ですが QA の自動作成も試みましたが、今回は諦めました。ドキュメントは 2024 年 12 月 12 日時点のドキュメントを使用しています。

質問例 1 :

Bedrockガードレールではどのようなフィルタリングができますか？

解答例 1 :

Amazon Bedrock Guardrailsでは、以下の6種類のフィルタリングが可能です：
コンテンツフィルター - 有害なコンテンツ(憎悪、侮辱、性的、暴力、不正行為など)の検出
拒否トピック - アプリケーションで望ましくないトピックのブロック
単語フィルター - 不適切な単語、フレーズ、冒涜的な表現のブロック
機密情報フィルター - PII(個人識別情報)などの機密情報のブロックまたはマスク
文脈的な根拠チェック - モデルの回答における幻覚の検出とフィルタリング
画像コンテンツフィルター - 不適切または有害な画像コンテンツの検出とフィルタリング

質問例 2 :

Titan Embedding v2 モデルは日本語に対応していますか？

解答例 2 :

はい、対応しています。

質問例 3 : 

Claude 3.5 sonnetでクロスリージョン推論を使う方法は？

解答例 3 :

クロスリージョン推論プロファイルの選択:
US Anthropic Claude 3.5 Sonnet (ID: us.anthropic.claude-3-5-sonnet-20240620-v1:0) が利用可能です
以下のリージョンをカバーしています:
us-east-1
us-east-2
us-west-2
us-gov-east-1
使用方法:
APIを使用する場合:
InvokeModelやInvokeModelWithResponseStreamのAPIコールで、modelIdパラメータにクロスリージョン推論プロファイルのARNを指定します
コンソールを使用する場合:
テキスト生成プレイグラウンドで、モデル選択時にThroughputとして"Cross region inference"を選択します

評価データが作成できたら、質問と正しい参考情報を LLM に渡して正解の回答を作成できるかを検証してみましょう。
参考情報はピンポイントの部分だけでなく、関連するドキュメントを数ページ分渡しています。利用モデルは、Claude 3.5 Sonnet V2 です。

18 件程度なので、全部目で見てチェックしてもいいのですが、今後のことを考えて、LLM によって自動評価させました。質問、正解の文章、LLM の回答の 3 つを LLM に渡して、3 段階で評価させています。何度か試して目で見て確認することで、概ね正しい評価ができていることが確認できました。少し意図と違う評価結果になってしまったものについては後述します。

評価基準はこちらです。

[評価基準]
2点: 正解の文章に含まれる重要な事実を全て正確にカバーしている
1点: 正解の文章の一部の事実は正確に含んでいるが、重要な情報の欠落や誤りがある
0点: 正解の文章の事実と大きく異なる、または完全な誤りを含む

完全正答率 100%

正しい参考情報を渡した場合、全ての質問に回答できることがわかりました。つまり、今回の RAG のポイントは “正しい情報を取ってこれるか” にかかっているということがわかりました。

RAG の改善をするための最初のステップは結果を分析することです。

RAG の改善手法は巷にあふれていますが、むやみにいろいろな手法を試すことは効率が悪いです。まず結果を分析しましょう。18 件程度であれば分析も楽です。RAG に必要な要素として正答率以外にレイテンシーやソースを引用できているかのような観点もありますが、今回はいったん無視して正答率の改善にフォーカスします。

うまく回答できていない質問は以下の 5 つです。

Bedrockガードレールではどのようなフィルタリングができますか ?

Claude 3.5 Haikuが使えるリージョンはどこですか ?

Knowledge Base のソースファイルのサイズ制限はありますか ?

Claude 3.5 sonnetでクロスリージョン推論を使う方法は ?

Claude 3 sonnetでクロスリージョン推論を使う方法は ?

より詳細に見ていきます。

• LLM の回答 : (長いので省略しますが、5 つのフィルターが挙げられていました)
• 正解の回答 : (長いので省略しますが、 6 つのフィルターを挙げる必要があります)

ドキュメントのあるページに 6 種類のフィルタリング機能がまとまっていて、これを答えてほしいのですが、そのページを拾ってくることができていませんでした。

ドキュメントのあるページに 6 種類のフィルタリング機能がまとまっていて、これを答えてほしいのですが、そのページを拾ってくることができていませんでした。

LLM の回答 : 「検索結果から、Claude 3 Haikuは us-east-1 (米国東部/バージニア北部) リージョンで使用可能であることが確認できます。」

正解の回答 : 「us-east-1, us-east-2, us-west-2 で利用でき、us-east-1, us-east-2 ではクリスクロスリージョン推論でのみ利用できます」

モデルとリージョンの対応表のページを取ってきて欲しいのですが、そこをとってくることができていません。別の部分の情報から us-east-1 が使えることはわかるため、そのことだけを回答しています。

• LLM の回答 : 「はい、Knowledge Base のソースファイルには以下のサイズ制限があります：コンソールを使用する場合は最大 200MB、それ以外の場合は最大 500MB までのファイルサイズが許可されています。画像ファイルの場合は、別途以下の制限があります：最大ファイルサイズ：5MB, 最大解像度：8k」

• 正解の回答 : 「各ファイルのサイズは 50MB を超えてはいけません。また、JPEG と PNG の最大サイズは 3.75MB です。」

しかし、検索で Bedrock Data Automation という機能のクオータのページを持ってきてしまったことにより、間違えた回答をしてしまっています。

※これは回答のプロンプトが悪い側面もあります。確実な情報が取得できていない場合には、「わかりません」と回答させるべきです。ただし、どちらにしろ正答できていないことには変わりません。

他 2 件も同様なので省略します

検索失敗のパターンとして、以下の 2 つがありそうだということが見えてきました。

検索すべき箇所は概ね合っているが、ピンポイントで必要な場所を取ってこれていないパターン (#1) 検索すべき箇所が全く的外れのパターン (#2、#3)

結果の分析をもとに改善案を考えます。5 件の回答がうまくいっていない原因は、端的に言えば検索がうまくいっておらず、とってきてほしい情報をとってこれていないことでした。これに対して改善案とその所感を挙げます。

• ハイブリッド検索を用いる
  → 検索結果を見ていると、キーワード検索を足すことでうまくいくケースではなさそうです。
• チャンキングを工夫する
  → やってみないとわからないですが、あまり関係ないように見えます。
• 検索数を増やす
  → 検索で得られている情報がそもそも少ないです。現在検索取得数を最大 5 件に設定していますが、ほとんどのケースで検索で得られる情報が 5 よりも少なかったので、効果はなさそうです。
  ※ 検索エンジンごと変えればこの性質が変わる可能性はありますが、少し面倒です。
• メタデータフィルタリング
  → 検索数が多ければフィルタリングが効きますが、そもそもが少ないので効果はなさそうです。
• 質問文からクエリを生成する部分を工夫する
  → うまくいくかもしれないですが、未知数です。どのようにクエリ生成させればいいかのアイデアがありません。
• Agentic RAG を導入する
  → うまくいくかもしれないですが、未知数です。複雑度が上がるので、もう少しシンプルなソリューションから考えたいです。

いくつか候補はありますが、これという解決方法ではありません。

ここで、人間が情報を探すときと同様に、2 ステップで探すのはどうだろうかというアイデアを思いつきました。

1. まず目次から関連しそうな場所を見つける
2. 目次の中から正確な関連情報を見つける

これを RAG に置き換えると、このようになります

1. 目次を LLM に渡して関連しそうなページ番号を推測させる
2. そのページの中身全部 LLM に渡して回答を作成してもらう

最近の LLM はかなり長い文章を入力することができますし、その中から必要な情報だけを抽出する能力も非常に高いです。そこで、関連しそうな文章を全部 LLM に入れて答えを探させてしまうという方法がうまくいくのではないかと考えました。

ここで、RAG の最も典型的な手法として知られている「文章を小さく分割 (チャンキング) して、検索エンジンで検索して、LLM に渡す」という手法の懸念点を考えてみます。

1. 「文脈を喪失する」

例えば、次のような文章を考えてみましょう。この文章は、ある会社の有給休暇の規定に関する文章です。正社員の場合と、非正規雇用社員の場合で、場合分けして記述されています。

A社の有給休暇の規定に関する文章

1. 正社員の場合

....

**付与日数**
- 入社後6ヶ月継続勤務し、全労働日の8割以上出勤した場合、10日の年次有給休暇を付与します。

....

2. 非正規雇用社員の場合

**対象者**
パートタイム社員、契約社員、アルバイト等の非正規雇用社員も、法令に基づき年次有給休暇を取得できます。

....

**付与日数**
週所定労働日数または年間所定労働日数に応じて、以下のとおり付与します。
.....

この文章をチャンキングしようとすると次のようになる可能性があります。このようになった場合、「付与日数」の情報はチャンク2とチャンク4に入っていますが、どちらが正社員の情報かわからなくなってしまいます。

チャンク 1

1. 正社員の場合

....

チャンク 2

....
**付与日数**
- 入社後6ヶ月継続勤務し、全労働日の8割以上出勤した場合、10日の年次有給休暇を付与します。
....

チャンク 3

2. 非正規雇用社員の場合

**対象者**
パートタイム社員、契約社員、アルバイト等の非正規雇用社員も、法令に基づき年次有給休暇を取得できます。

....

チャンク 4

....
**付与日数**
週所定労働日数または年間所定労働日数に応じて、以下のとおり付与します。
.....

2. 網羅するタスクに弱い

例えば「Amazon Bedrock で使える Claude のモデルを全て挙げてください」というタスクを今回の RAG に依頼することを考えます。検索エンジンはこの質問に関連する情報を取ってきて LLM が回答するでしょうが、その情報で全てのモデルが網羅されているかどうかはわかりません。実際、結果の分析ステップで見たうまくいっていない回答の #1 と #2 は、一部の情報は答えられているが、網羅できていない回答になってしまいました。

このようなタスクにはチャンクを検索するという手法は合わないことがありそうです。