Amazon Kendra と Amazon Bedrock で構成した RAG システムに対する Advanced RAG 手法の精度寄与検証

By Kazuki Motohashi, Ph.D., Partner Solutions Architect, AI/ML – AWS Japan
By Kazuhito Go, Sr. AI/ML Specialist Solutions Architect – AWS Japan
By Kenjiro Kondo, TELCO Solutions Architect – AWS Japan

生成 AI は会話、ストーリー、画像、動画、音楽などの新しいコンテンツやアイデアを作成できる AI の一種です。生成 AI によりアプリケーションが再発明され、新しいカスタマーエクスペリエンスが提供されます。Goldman Sachs によると、生成 AI は世界の国内総生産 (GDP) を 7％ (約 7 兆 USD) 増加させる可能性があると言われています。また、これにより 10 年間で生産性が 1.5% 上昇すると予想しています。

幅広い領域で利用可能な生成 AI の有力なユースケースとして検索拡張生成 (Retrieval Augmented Generation; RAG) が知られています。生成 AI 単体では一般的でない特殊な専門知識を必要とするタスクを解くのが難しいことや、ハルシネーションの発生といった課題がありますが、RAG はこれらの課題を低減する技術として期待されています。

RAG では、その名の通り、初めにユーザーが知りたい内容に対して情報検索を行い、得られた検索結果を元に生成 AI を用いた回答を返します。例えば生成 AI モデルが知らない社内の規約といった情報についても、あらかじめ検索用のインデックスを作成し、ユーザーからの質問を起点として動的に検索を実行することで回答を生成することが可能となります。

一方で、単純に検索結果を生成 AI に与えるプロンプトに入れ込んで回答を生成するというアプローチでは、ユーザーが期待する品質を持った回答が得られないケースがあることもわかっています。RAG のパフォーマンスを改善するための手法は多くの研究者によって考案されており、例えば “Retrieval-Augmented Generation for Large Language Models: A Survey” [Yunfan Gao et al. (2023)] といったサーベイ論文にまとめられています。こちらの論文では、上記の単純なアプローチを Naive RAG と呼び、追加の工夫を加えた Advanced RAG (論文中にはさらに Modular RAG という分類もある) と区別しています。

図1: Naive RAG と Advanced RAG の模式図。[Yunfan Gao et al. (2023)] を元に日本語化。

RAG を改善するアプローチとしては大きく分けてふたつあります。検索を適切に行って回答に必要な情報を十分に得ることと、検索で得られたドキュメント群のどの情報を用いて回答するべきかを生成 AI に伝えることです。Advanced RAG の枠組みでは、 検索前処理 (pre-retrieval) と 検索後処理 (post-retrieval) としてさまざまな工夫が考案されています。検索前処理では、インデックス構造の最適化やクエリの改善を行います。検索後処理では、検索結果のランク付けや情報の圧縮を行い、大規模言語モデル (LLM) への入力を最適化します。これにより、よりコンパクトで的確な追加情報を LLM に提供し、応答品質の向上を図ります。

本記事では Advanced RAG に分類される手法のうち、特に LLM を用いたクエリ拡張 (query expansion) と、検索結果の関連度評価という手法による回答品質への影響を簡易的に評価した結果を紹介します。あくまで今回の実験設定における定性的な評価であり、定量的な評価まで踏み込んでいない点には留意してください。

Advanced RAG 評価の実験設定

全体のアーキテクチャーと構成要素

今回の検証で用いる RAG システムのアーキテクチャーは以下の図のように構成しています。実線が Naive RAG のフローを表し、点線は今回検証する Advanced RAG 手法を追加した場合のフローを表します。

図2: 今回の検証で用いる RAG システムのアーキテクチャー

通常の Naive RAG では、ユーザーの質問に対して (1) の Amazon Kendra で検索を行い、その結果を元に (2) の Amazon Bedrock で回答を生成します。今回は検索の前後に (a) のクエリ拡張と (b) の検索結果の関連度評価のステップを加え、それぞれのテクニックのある場合とない場合で生成 AI による回答がどう変わるかを確認します。具体的には、以下の4つの場合分けで生成 AI による回答を評価します。

Naive RAG: (1) → (2)
+ クエリ拡張: (a) → (1) → (2)
+ 関連度評価: (1) → (b) → (2)
+ クエリ拡張 & 関連度評価: (a) → (1) → (b) → (2)

1. Retriever: Amazon Kendra

本実験では retriever (検索器) として AWS のインテリジェント検索サービスである Amazon Kendra を利用します。

Kendra は、機械学習を活用してユーザーの検索意図を理解し、関連性の高い結果を高速に返す検索エンジンとしての機能を持っています。それだけでなく、どのユーザーがどのドキュメントにアクセスできるかという権限管理を行うこともできるエンタープライズ向けのサービスです。また、Amazon Simple Storage Service (Amazon S3)、Microsoft SharePoint、Salesforce など、多様なデータソースに接続するコネクターが提供されており、企業内の複数のデータソースに分散するドキュメントを自然言語で横断的に検索できます。検索可能なドキュメントの形式も豊富であり、CSV や JSON、XML のような構造化データに加えて、PDF、HTML、Microsoft Word、Microsoft PowerPoint などの一般的なオフィスドキュメントをサポートします。他にも多数の機能を備えていますが、詳しくはブログ記事「ML 駆動の検索エンジンで企業の情報管理を革新！Amazon Kendra をグラレコで解説」をご覧ください。

Kendra でドキュメントを検索するには Query API と Retrieve API のふたつの方法があります。今回は、RAG との親和性が高い Retrieve API を用いることで、データソースの中のドキュメントから、ユーザーの質問内容に関連する抜粋部分を抽出し、生成 AI への入力としていきます。なお、Retrieve API では PageSize (デフォルト値は10件) を超える抜粋部分が抽出された際、レスポンスがページングされ、追加の PageSize 分ごとに結果を再取得していく必要があります。今回の検証では、最初の10件の抜粋のみを後続の処理に渡していくように実装しています。

2. Generator: Claude 3 Haiku on Amazon Bedrock

RAG システムにおける generator (生成器) としては、AWS の生成 AI サービスである Amazon Bedrock で提供されている Anthropic 社の Claude 3 Haiku を利用します。

Amazon Bedrock は、Amazon をはじめ、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI といった代表的な AI 関連企業が提供する高性能な基盤モデルを単一の API 経由で操作可能なフルマネージド生成 AI サービスです。特に Anthropic が提供するマルチモーダルな Claude 3 シリーズは日本語を含めた言語理解・言語生成能力が高く、多くのユーザーに利用されています。Claude 3 には Opus / Sonnet / Haiku の三種類があり、最も軽量な Haiku は日本語性能が高くレスポンスも高速に返すのが特徴です。RAG システムとしてユーザーに素早くレスポンスを返すことがユーザー体験に大きく影響することを鑑みて今回は Claude 3 Haiku を generator に選定しました。Amazon Bedrock について詳しく知りたい場合はブログ記事「生成 AI アプリケーション開発をもっと身近に、簡単に！Amazon Bedrock をグラレコで解説」をご覧ください。

以下は RAG により回答を生成するためのプロンプトテンプレートです。Amazon Kendra による検索で得られたドキュメントの抜粋部分は動的に {context} に格納され、ユーザーからの質問は {question} に格納されます。ひと工夫として、できるだけハルシネーションを抑えるため、まず検索結果を用いて十分な回答ができるかを Claude3 Haiku に考えさせてから回答を生成するようにしています。

なお、今回はプロンプト内で <excertps> (抜粋) タグや <question> (質問) タグといった XML 形式のタグを利用しています。Claude を利用する際は XML タグを用いてプロンプトを構造化することで、Claude にコンテキストをより深く理解させ、応答をコントロールすることができます。詳しくは、Claude のプロンプトエンジニアリングガイドも参照してください。

あなたは親切で知識豊富なチャットアシスタントです。
<excerpts>タグには、ユーザーが知りたい情報に関連する複数のドキュメントの抜粋が含まれています。

<excerpts>{context}</excerpts>

これらの情報をもとに、<question>タグ内のユーザーの質問に対する回答を提供してください。

<question>{question}</question>

まず、質問に対して<excerpts>タグ内にある情報で答えられるかを考え、<related>true</related>、もしくは、<related>false</related>の形式で答えてください。

質問に答えるための情報がない場合は、「情報が不十分で回答できません」と答えてください。
また、質問への回答は以下の点に留意してください:

- <excerpts>タグの内容を参考にするが、回答に<excerpts>タグを含めないこと。
- 簡潔に3つ以内のセンテンスで回答すること。
- 日本語で回答すること。
- 質問への回答は<answer></answer>タグに含めること。

3. Pre-Retrieval: クエリ拡張 with Claude 3 Haiku on Amazon Bedrock

クエリ拡張は、単一のクエリを複数のクエリに拡張することで多様な検索結果を取得し、生成される回答の適合性を高めるための手法です。クエリ拡張にも、単純に複数の異なるクエリを作成するマルチクエリ (multi query) や、元の質問を分解して個々の質問に答えるためのクエリを作成するサブクエリ (sub query) などさまざまなアプローチがありますが、今回はシンプルなマルチクエリのアプローチを採用しています。LLM は generator と同様に Claude 3 Haiku を用いてクエリを拡張します。

必ずしもユーザーのクエリとソースドキュメントの表現が一致しているわけではありません。「ナレッジベース」と「Knowledge Bases」等、日本語と英語との表記揺れや、類義語、タイポなど、さまざまな要因で初期のクエリでは回答に必要な情報が十分に取得できないことがあります。クエリを拡張し、類似するキーワードを複数用いることで、キーワード検索とベクトル検索のハイブリッド検索のような、確実性と曖昧性を兼ね備えた検索が実現されることが期待されます。

具体的には以下のようなプロンプトテンプレートを用いています。いくつのクエリを作成するかは {n_queries} で動的に指定できるようにしています (今回は n_queries=3 として実験しています)。どのようにクエリを拡張して欲しいかは <example> タグ内に例を記載しました。ここでは、ひとつの質問と3つの拡張クエリの例のみを渡していますが、よくある質問のトピックや文章スタイルに合わせて複数の例を示すことで、意図した通りの出力を得る確率が上がることが期待されます。フォーマットとユーザーからの質問はそれぞれ {output_format} と {question} に入れるようにしました。

検索エンジンに入力するクエリを最適化し、様々な角度から検索を行うことで、より適切で幅広い検索結果が得られるようにします。 
具体的には、類義語や日本語と英語の表記揺れを考慮し、多角的な視点からクエリを生成します。

以下の<question>タグ内にはユーザーの入力した質問文が入ります。
この質問文に基づいて、{n_queries}個の検索用クエリを生成してください。
各クエリは30トークン以内とし、日本語と英語を適切に混ぜて使用することで、広範囲の文書が取得できるようにしてください。

生成されたクエリは、<format>タグ内のフォーマットに従って出力してください。

<example>
question: Knowledge Bases for Amazon Bedrock ではどのベクトルデータベースを使えますか？
query 1: Knowledge Bases for Amazon Bedrock vector databases engine DB 
query 2: Amazon Bedrock ナレッジベース ベクトルエンジン vector databases DB
query 3: Amazon Bedrock RAG 検索拡張生成 埋め込みベクトル データベース エンジン
</example>

<format>
{output_format}
</format> 

<question>
{question}
</question>

今回の実験でクエリを拡張する際は、元のクエリ (question) と拡張したクエリ (query 1/2/3) の計4回独立に検索します。実装の際には Kendra へのクエリは非同期処理として並行して実行することで、クエリ拡張によるレイテンシーのオーバーヘッドを最小限に抑えることができるでしょう。Kendra のエンタープライズエディションでは1日あたりの最大クエリ件数が8,000件となっており、それを超えると追加の料金がかかることには注意が必要です。Advanced RAG の手法を追加する際には、追加のレイテンシー、料金、サービスクォータなどへの影響を評価することも忘れないようにしましょう。

4. Post-Retrieval: 検索結果の関連度評価 with Claude 3 Haiku on Amazon Bedrock

このステップでは検索結果が、元のユーザーからの質問に関連したものになっているかを評価します。検索で得られたドキュメントの抜粋 (チャンク) というのは必ずしも質問に回答するための情報を含んでいるとは限らず、誤った回答を誘発するような内容も含んでしまっていることがあります。例えば、“Corrective Retrieval Augmented Generation” [Shi-Qi Yan et al. (2024)] の論文で提案されている手法 (Corrective RAG; CRAG) では、検索結果の関連度を評価し、その評価結果をもとに最終回答を生成します。CRAG ではドキュメントの抜粋をそれぞれ Correct (正確) / Ambiguous (曖昧) / Incorrect (不正確) のカテゴリに分類しますが、今回は簡単のために関連しているか否かの yes / no の二値に分類します。LLM は他のステップと同様に Claude 3 Haiku を用います。

具体的なプロンプトテンプレートは以下の通りです。{context} にそれぞれのドキュメントの抜粋が格納され、{question} にユーザーの質問が格納されます。評価結果 (yes / no) を後の処理で利用するため、回答に前置き等の余計な文章が入らないよう {format_instructions} で指定しています。

あなたは、ユーザーからの質問と検索で得られたドキュメントの関連度を評価する専門家です。
<excerpt>タグ内は、検索により取得したドキュメントの抜粋です。

<excerpt>{context}</excerpt>

<question>タグ内は、ユーザーからの質問です。

<question>{question}</question>
  
このドキュメントの抜粋は、ユーザーの質問に回答するための正確な情報を含んでいるかを慎重に判断してください。
正確な情報を含んでいる場合は 'yes'、含んでいない場合は 'no' のバイナリスコアを返してください。
  
{format_instructions}

今回の実験では、Kendra の Retrieve API で得られたドキュメントの抜粋ひとつひとつに対して関連度評価を行っています。クエリ拡張と組み合わせた場合は、4クエリ×10抜粋=40抜粋分、Claude 3 Haiku を呼び出すことになります。1抜粋当たり、プロンプト全体で800トークン前後になるため、一回の検索における関連度評価だけで30,000トークン程度消費するケースがあることになります。レイテンシーの影響も最小限に抑えるため、クエリ拡張と同様に非同期処理として実行するのが望ましいですが、運用の際には RPM (Requests processed per minute) や TPM (Tokens processed per minute) のクォータには注意してください。

評価用データセットと検索用のデータソース

Advanced RAG の評価のため、通常の Naive RAG だけでは適切に回答することが難しい質問を準備します。今回は Kendra および Amazon Bedrock について、LLM 自身が持っている知識だけで回答するのは難しい、比較的詳細な質問と回答のセットを用意しました。以下は今回の評価で用いた質問のリストです。

Amazon Kendra を使って Web サイトのコンテンツを検索可能にしたいと考えています。クロールの対象とする URL を制限する方法はありますか?
Knowledge Bases for Amazon Bedrock ではどういったベクトルデータベースを利用できますか？
Kendra で使用できるデータソースを全部教えて
Amazon Kendra がサポートしているユーザーアクセス制御の方法は？
Amazon Kendra の検索分析のメトリクスには何がありますか？
Amazon Bedrock で Claude 3 Sonnet の基盤モデルに関する情報を取得する Python コードを教えて
ナレッジベースでの embedding モデルの選択肢は？
Bedrock の agent 機能は東京リージョンでは使えますか？
Amazon Kendraで検索結果のランキングロジックをカスタマイズできますか？
Amazon Bedrock でモデルにアクセスするには何が必要ですか？

あらかじめ retriever としての Kendra には、Kendra の開発者ドキュメントと Amazon Bedrock の開発者ドキュメントの各ページの HTML ファイルをデータソースとして取り込んでいます。また、やや問題設定の難易度を上げるため、内容的に近しいが直接関連しないドキュメントとして、AWS の自然言語処理サービスである Amazon Comprehend の開発者ドキュメントも追加しています。

実験結果

以下の表は、それぞれの RAG の構成で質問に対する回答が正確だったか、一部正確だが情報不足か、不正確かの件数をまとめたものです。

表1: 質問に対する RAG システムによる回答の正確性の統計
	正確	一部正確 (情報不足)	不正確
Naive RAG	3	5	2
+ クエリ拡張	6	4	0
+ 関連度評価	1	5	4
+ クエリ拡張 & 関連度評価	5	5	0

今回の実験結果では Naive RAG では不正確な回答が複数見られましたが、クエリ拡張の手法を用いることで回答の正確性が向上していることがわかります。単一のクエリを用いた検索によって得られる10件のドキュメントの抜粋だけではうまく回答が生成できないものの、クエリ拡張を行うことで幅広い抜粋を収集でき、正しい回答を行うための情報が得られるようになったのが要因かと思われます。

関連度評価に関してはむしろ正確性を下げてしまう結果となりました。今回用いた Claude 3 Haiku では、情報ソースとなるドキュメント内にノイズとなるような無関係な情報が含まれていても、必要な情報を適切に選別して回答を生成できており、事前に関連度評価をする必要はないのではないかと考えられます。むしろ関連度評価の誤判断による悪影響の方が大きいかもしれません。元々、Claude 3 は (RAG の構成を取らず) 数百ページの開発ドキュメント全体を直接インプットとしても回答を得られることがわかっています。Claude 3 が膨大な情報から再現率高く情報抽出できることは “Needle in a Haystack” 評価の結果からもわかります。

ただし、LLM の推論パラメータで temperature=0 として回答のランダム性を抑えるようにはしていますが、試行のたびに多少回答が変化することには注意してください。本結果はあくまで一度の試行におけるスナップショットであり、表内の統計値は誤差を含むものとして認識してください。

クエリ拡張の影響

以下の表では、質問、Naive RAG による回答、クエリ拡張を加えた場合の回答のうち、特にクエリ拡張による影響が大きいものをまとめています。なお、全体として、クエリ拡張により回答の質が向上することはあれど、悪化するケースは観測されませんでした。

「ナレッジベースでの embedding モデルの選択肢は？」という質問に対して、執筆時点では Amazon Titan Embeddings G1 – Text、Cohere Embed English、Cohere Embed Multilingual を答えに含めるのが適切です。しかし、Naive RAG では CohereEmbed には言及しているものの、Amazon Titan Embedding G1 – Text や、Cohere Embed には二種類あることには言及していません。一方で、クエリ拡張を行った場合は適切に回答できています。なお、クエリ拡張により元のクエリは「knowledge base embedding model options choices selection」、「ナレッジベース埋め込みモデル選択肢オプション」、「knowledge base ナレッジベース embedding 埋め込み model 選択選択肢」といった複数のクエリに変換されました。今回の検索対象のソースドキュメントでは「embedding」よりも「埋め込み」のように日本語で表現されていることが多く、類義語を用いた検索を行うことでより適切なドキュメントを抽出できたのが精度向上の要因かと考えられます。

また、「Amazon Kendra で検索結果のランキングロジックをカスタマイズできますか？」という質問に対して、Naive RAG では Kendra のリランキング機能を Amazon OpenSearch Service 等の外部サービス用に切り出した、インテリジェントランキング (Rescore API) について回答してしまっています。ややクエリの日本語が曖昧ではありますが、質問の意図としては、Kendra 自体の検索結果の並び順を調整できるかを知りたいのであり、Rescore API について回答するのは誤りです。一方、クエリ拡張により、「Amazon Kendra search results ranking logic customize personalize relevance」、「Amazon Kendra 検索結果ランキングロジックカスタマイズ個別化関連性」、「Amazon Kendra search ranking algorithm customization personalization relevance tuning」といった複数のクエリを並行して検索することで、より広範なドキュメントの抜粋を取得できています。特に「関連性」というワードを追加できていることにより、Kendra の関連性チューニングや、属性やフィールドによる検索結果のソートの機能について正確に回答することができました。これはシンプルに Retrieve API の PageSize を調整してより多くの抜粋を得るだけでは得られない効果かと思われます。

表2: クエリ拡張の有無による RAG システムによる回答の変化
質問	Naive RAG	+ クエリ拡張	コメント
ナレッジベースでの embedding モデルの選択肢は？	ナレッジベースでのembeddingモデルの選択肢については、以下のようなことが考えられます: Amazon Bedrock では、CohereEmbedモデルを使用してテキストのエンベディングを生成することができます。このモデルは、テキストを高次元のベクトル表現に変換し、類似したテキストを近接させることができます。これにより、ナレッジベース内の情報を効率的に検索したり、関連性の高い情報を見つけたりすることができます。その他にも、用途に応じて適切なembeddingモデルを選択することが重要です。例えば、特定のドメインに特化したカスタムモデルを使用するなど、ユースケースに合わせた最適なモデルを選択する必要があります。	ナレッジベースでは、Amazon Titan Embeddings G1 – Text、CohereEmbed(英語)、CohereEmbed(多言語)の3つのembeddingモデルが使用できます。これらのモデルを使用して、データソースをベクターストアに埋め込むことができます。	クエリ拡張により正確なモデルの選択肢を提供できている。
Amazon Kendra で検索結果のランキングロジックをカスタマイズできますか？	はい、Amazon Kendraでは検索結果のランキングをカスタマイズできます。 Amazon Kendraのインテリジェント・ランキング機能を使うと、検索サービスの結果をセマンティックに再ランク付けできます。これにより、単純なキーワードマッチングを改善し、検索クエリのコンテキストと検索ドキュメントの内容を考慮したランキングが可能になります。また、Amazon Kendraの Rescore API を使って、外部の検索サービス(OpenSearchなど)からの検索結果をセマンティックに再ランク付けすることもできます。	はい、Amazon Kendraでは検索結果のランキングロジックをカスタマイズできます。 Amazon Kendraのインテリジェントランキング機能を使うと、検索クエリのコンテキストと検索サービスのドキュメントから得られる情報を考慮して、検索結果をセマンティックに再ランク付けできます。また、インデックス内の個々のフィールドの関連性をチューニングすることで、クエリの結果に影響を与えることもできます。さらに、検索結果を特定の属性やフィールドでソートすることも可能です。これにより、ユーザーのニーズに合わせて検索結果を最適化できます。	関連性チューニングや属性によるソートなど、質問の意図通りの回答ができている。

検索結果の関連度評価の影響

一方で、検索結果の関連度評価による好ましい影響は小さく、場合によっては悪影響を及ぼし得るという観測結果となりました。

例えば、「ナレッジベースでの embedding モデルの選択肢は？」という質問に対して、関連度評価によりドキュメントの抜粋を選別した後では、Amazon Titan モデルや AI21 Labs の Jurassic-2 モデルのような、関係のないテキスト生成の話を追加してしまっています。「Amazon Kendra がサポートしているユーザーアクセス制御の方法は？」という質問に対しては、Naive RAG では正しく詳細な回答ができているものの、関連度評価を行った後では概要を述べるに留まってしまっています。

これらが関連度評価によってソースドキュメントの量が減ったことによる悪影響なのか、単なる LLM の回答のばらつきなのかは慎重に判断すべきです。ただし、少なくとも今回の実験では関連度評価により回答の質が向上したケースは観測されず、ほとんどの場合は「Amazon Kendra で検索結果のランキングロジックをカスタマイズできますか？」の質問に対する回答のように、Naive RAG の回答から大きな変化はありませんでした。

表3: 関連度評価の有無による RAG システムによる回答の変化
質問	Naive RAG	+ 関連度評価	コメント
ナレッジベースでの embedding モデルの選択肢は？	ナレッジベースでのembeddingモデルの選択肢については、以下のようなことが考えられます: Amazon Bedrock では、CohereEmbedモデルを使用してテキストのエンベディングを生成することができます。このモデルは、テキストを高次元のベクトル表現に変換し、類似したテキストを近接させることができます。これにより、ナレッジベース内の情報を効率的に検索したり、関連性の高い情報を見つけたりすることができます。その他にも、用途に応じて適切なembeddingモデルを選択することが重要です。例えば、特定のドメインに特化したカスタムモデルを使用するなど、ユースケースに合わせた最適なモデルを選択する必要があります。	ナレッジベースでのembeddingモデルの選択肢としては以下のようなものが考えられます: CohereEmbedモデルは、テキストデータからベクトル表現を生成するためのモデルです。このモデルを使用すれば、テキストデータを数値化し、類似性の計算などに活用できます。また、Amazon Bedrockでは、TitanモデルやAI21 Labsのジュラシックモデルなども利用可能です。これらのモデルを使えば、テキストの分類や質問応答、要約などの自然言語処理タスクを実行できます。ただし、具体的にどのモデルが最適かは、ナレッジベースの内容や目的によって異なります。適切なモデルを選択するためには、各モデルの特徴を理解し、ニーズに合わせて検討する必要があります。	embedding の話をするべきなのに別のテキスト生成モデルの話をしている。
Amazon Kendra がサポートしているユーザーアクセス制御の方法は？	Amazon Kendra は、ユーザーとグループに基づくアクセス制御リスト (ACL) とトークンベースのアクセス制御をサポしています。ACL 情報をコネクタから取り込むことで、ユーザーまたはグループのドキュメントへのアクセス権に基づいて検索結果をフィルタリングできます。また、オープン ID、共有シークレット付き JWT、パブリックキー付き JWT などのトークンを使用したトークンベースのアクセス制御もサポートしています。	Amazon Kendra は、次の3つのユーザーアクセス制御方式をサポートしています。 1. トークンベースのアクセス制御: ユーザーまたはグループに応じて、特定のドキュメントへのアクセスを制限できます。 2. アクセス制御リスト(ACL)の活用: ドキュメントのACL情報をクロールし、ユーザーやグループのアクセス権に基づいて検索結果をフィルタリングできます。 3. ユーザーコンテキストフィルタリング: ユーザーやグループの属性に基づいて、検索結果をフィルタリングできます。	概要を述べるに留まってしまっている。
Amazon Kendra で検索結果のランキングロジックをカスタマイズできますか？	はい、Amazon Kendraでは検索結果のランキングをカスタマイズできます。 Amazon Kendraのインテリジェント・ランキング機能を使うと、検索サービスの結果をセマンティックに再ランク付けできます。これにより、単純なキーワードマッチングを改善し、検索クエリのコンテキストと検索ドキュメントの内容を考慮したランキングが可能になります。また、Amazon Kendraの Rescore API を使って、外部の検索サービス(OpenSearchなど)からの検索結果をセマンティックに再ランク付けすることもできます。	はい、Amazon Kendraでは検索結果のランキングをカスタマイズできます。 Amazon Kendraのインテリジェント・ランキング機能を使うと、検索クエリのコンテキストと検索ドキュメントの情報を考慮して、検索結果をセマンティックにランク付けし直すことができます。これにより、単純なキーワードマッチングを改善し、より関連性の高い結果を表示することができます。また、Amazon Kendraの Rescore API を使って、OpenSearchなどの検索サービスからの検索結果を再ランク付けすることも可能です。	関連度評価後も回答にほぼ変化なし。

まとめと展望

本記事では Advanced RAG と呼ばれる RAG の精度を向上させるテクニックのうち、クエリ拡張と検索結果の関連度評価が与える回答品質への影響を検証しました。今回用意した RAG システム、質問回答集、ソースドキュメント、LLM、プロンプトなどの組み合わせでは、クエリ拡張は回答の質の向上に寄与し、関連度評価は寄与しないという結果になりました。クエリ拡張によって、より幅の広いドキュメントの抜粋が取得できることで、回答に必要な情報源が網羅的に得られたことが要因かと思われます。一方、Claude 3 Haiku のようなモデルは大量のドキュメントの中から必要な情報を見つける能力に長けており、今回の実験の範囲内では関連度評価によるドキュメントの選別による回答品質の向上は観測されませんでした。

ただし、Advanced RAG の手法による回答品質への影響は、背後で用いられている検索エンジンの仕組みや LLM の特性、ユーザーペルソナの多様性などにより異なり得ることには注意してください。ユーザーのクエリに十分な情報が含まれているのであれば、キーワード検索とベクトル検索のハイブリッドを採用することで、今回のクエリ拡張のような幅広いドキュメントを取得するという目的は達成できるかもしれません。一方で、ユーザーのクエリは単一の単語のみで構成されていたり、多様な分布を持つこともあり得ます。そういったケースを救うためには、クエリ拡張などの技術を用いることで、検索される回答ソースのドキュメント抜粋を増やすことが有益でしょう。

また、今回は関連度評価の仕組みをそれ単体で利用しましたが、本来の Corrective RAG の論文で提案されているのは、検索エンジンで質問に関連するドキュメントが得られなかった場合はウェブ検索を行って情報を補完することである点にも注意が必要です。現在すでに構築している RAG システムがあり、その精度を向上させたいのであれば、どういったケースでうまく回答できていないのか、何が原因なのかを精査することが重要です。検索システムのデータソースにない情報を回答しているのであれば、それを抑制するためのプロンプトエンジニアリングが必要ですし、うまくクエリが書けていないのであればクエリ拡張を用いるか、そもそもユーザーガイドを充実させることも有効かもしれません。

RAG システムの評価のためには目視評価だけでなく、LLM を使った自動評価などの仕組みを導入することも検討すべきでしょう。RAG ないし生成 AI システムのアーキテクチャーや性能を向上させるテクニックはまだまだ発展途上で今後も研究が進んでいく領域です。ぜひ AWS のソリューションアーキテクトなどのメンバーにご相談いただき、よりよいユーザー体験の提供をご支援させていただければ幸いです。

著者について

本橋和貴 (Kazuki Motohashi / @kmotohas) は、AWS Japan の機械学習パートナーソリューションアーキテクトです。AWS 上で機械学習関連のソフトウェアを開発しているパートナー企業の技術支援を担当をしています。好きなサービスは Amazon SageMaker です。週末は昔の RPG のリメイクゲームの攻略に勤しんでいます。博士 (理学)。

呉和仁 (Go Kazuhito / @kazuneet) はアマゾンウェブサービスジャパン合同会社の機械学習ソリューションアーキテクトです。IoT の DWH 開発、データサイエンティスト兼業務コンサルタントを経て現職。プログラマの三大美徳である怠惰だけを極めてしまい、モデル構築を怠けられる AWS の AI サービスをこよなく愛す。

近藤健二郎 (Kenjiro Kondo) は、AWS Japan 合同会社のソリューションアーキテクトです。エンタープライズ企業の技術支援を担当しながら、機械学習関連のソリューションについても取り組んでいます。好きなサービスは Amazon Personalize です。

Amazon Web Services ブログ