はじめに

AWS re:Invent 2024にてAmazon Kendra GenAI Indexが発表されました。
そこで発表内容と試してみたことを元に、期待や課題をまとめてみることにしました。

Kendra GenAI Indexとは何者なのか？

Amazon Q BusinessのNative Retrieverとして利用可能な検索エンジンを単体で利用可能なサービスとしたものです。
Amazon Q Businessでは、Retriever（検索エンジン）としてNativeとKendraが選択可能となっています。
またAmazon Q Businessでのみ使用可能なNative RetrieverはRAG用途に最適化されていました。
このNative RetrieverをKendraのサービスとして切り出して利用できるようにしたのが、Kendra GenAI Indexにあたります。

Kendra GenAI Indexで何が変わるのか？

従来のKendraに比べると、Kendra GenAI Indexでサポートされたのは以下の点に集約されます。

• ベクトル検索をサポート
• Amazon Bedrock Knowledge Basesと連携可能となった

これらによって、具体的にどのような効果が期待されるのかを書いていきます。

ベクトル検索：RAG精度向上の期待

これまでもKendraはRAG用途にRetrieve APIが提供されていましたが、正直こちらはあまりRAGに向かないものでした。
なぜなら従来のKendraはベクトル検索に対応しておらず、キーワードが含まれるかどうかで検索結果が大きく変わるためです。
GenUではRAGの前にLLMでクエリ生成を行うなどの工夫もされていましたが、 ヒットするキーワードがうまく生成されるかどうかに大きく依存してしまうため、Kendraは検索精度の安定感に課題がありました。

ベクトル検索をサポートすると、単語が一致していなくても意味的に類似していれば検索結果に現れるようになります。
そのため、今後はKendraを用いたRAGでも安定感のある回答が期待できそうです。

ベクトル検索：ハイブリッド検索への期待

これまでAWSのサービスでは限られた形でしかハイブリッド検索をサポートしていませんでした。
Knowledge Bases + OpenSearch Serverlessではハイブリッド検索をサポートしていますが、これはKnowledge Basesとしての機能であり、 OpenSearch Serverless単体ではキーワード検索もしくはベクトル検索しかサポートしていません。

基本的に複数の方式を組み合わせたほうが、検索精度の安定・向上が期待されます。
Kendra GenAI Indexは純粋な検索エンジンとしても、ハイブリッド検索による検索精度に期待できそうです。

Knowledge Basesとの連携：RAG用途のインタフェース互換性が向上

今後はKnowledge Basesのデータベースとして、Kendra GenAI Indexを使えるようになります。
これまでKnowledge Basesを構成する際にはチャンク等の設定が必要で、定期的なSyncの実行機能などもできませんでした。
しかし今後はKendraを用いればマネージドなKnowledge Basesの実装として利用できるようになります。

Knowledge Basesとして呼び出せるようになることには、アプリ側に大きなメリットがあります。
今後、アプリ側ではRAG用途でKendraのRetrieve APIを使う理由は低くなるでしょう。
というのも、Knowledge BasesにはRetrieve APIやRetrieveAndGenerate APIが用意されているためです。
アプリからRAGを呼び出す場合にはKnowledge Basesのインタフェースを利用しておけば、アプリ側を変更しなくてもKnowledge BasesをKendraでもOpenSearch Serverlessでも容易に差し替えられるようになります。

そしてKnowledge Basesとして扱えるということは、Amazon Bedrock Agentsから呼び出せるということでもあります。
これまでAgentsからKendraのデータにアクセスするのは大変¹でしたが、今後は容易に連携できるようになります。

Knowledge Basesとの連携：S3データソースのメタデータ互換性問題も解決

ちなみにKnowledge Basesに接続できるようになったことで、もう一つ問題が解決しています。
その問題とはKnowledge BasesのmetadataとKendraのmetadataに互換性がなかったことです。

Knowledge BasesとKendraはいずれもS3をデータソースとする際、JSON形式でメタデータを配置することができます。
そしてこのメタデータは目的やファイル名こそ似通っていますがスキーマは一致しておらず、互換性はありませんでした。
そのため同一のコンテンツをKendraとKnowledge Basesの双方で扱いたい場合には、「Kendra用のS3」と「Knowledge Bases用のS3」を作成し、異なるメタデータ形式でそれぞれ配置する必要がありました。

しかしKendraをKnowledge Basesにそのまま接続できるようになったことで、Knowledge Bases用のS3は必要なくなりました。
Kendra用のS3とメタデータだけを用意してSyncが完了すれば、そのままKnowledge Basesで活用できるようになったのです。
Knowledge BasesのAPIからRAGを実行したときは、きちんとKendraのメタデータ情報を付与して返してくれるようです。

Kendra GenAI Indexの課題

期待できる面は多くありましたが、従来のKendraの完全上位互換ではなさそうです。

ストレージあたりの単価が高く設定されている

最低料金が低くなった事が話題になっていますが、しかしストレージ単価で見るとGenAIはかなり高めに設定されています。
料金はこちらに記載があり、それに基づくと以下のようになります。

• Basic Enterprise Edition
  • 最低料金：1008 USD/月
  • 10万ファイル or 30GBごとに +504 USD/月
• GenAI Enterprise Edition
  • 最低料金：260.4 USD/月
  • 2万ファイル or 200MBごとに +180 USD/月

10万ドキュメントまでは GenAI < Basicですが、10万ドキュメントを超えるとGenAI > Basicになります。
そして特に厳しいのがサイズで、1GBまではGenAI < Basicですが、1GBを超えると GenAI > Basicになります。
いろいろなドキュメントを入れれば、1GBは容易に超えることが想像できます。
AzureAI Searchなどと比べると、どうしてもストレージ面は見劣りする感があります。

ちなみにBasic Enterprise EditionとGenAI Enterprise Editionで、インデックスサイズ自体に大きな差異はなさそうでした。
同一のファイルを用いれば、どちらのEditionでも同等のサイズとなりそうです。

まだ日本語・日本リージョンはサポートしていない

日本語はまだサポートしておらず、日本のリージョンでも利用できません。
Amazon Q Businessが日本語・日本リージョンをサポートするのとほぼ同時期 or 少し遅れて、Kendra GenAI Indexも日本語・日本リージョンをサポートするのではないでしょうか。

その他、細かな制限事項あり

他にも古いデータソースコネクタ非対応、トークンベースのアクセス制御は非対応などの制限があります。
詳細はこちらに記載があります。

まとめ

RAG用途でマネージドな検索エンジンを使いたいのであれば、Kendra GenAI Indexは有力な選択肢になりそうです。
Knowledge Basesのデータベースとして連携できるようになったため、Agentからも容易に呼び出せるようになりましたし、S3データソースのメタデータ問題も解決しました。
しかしストレージ料金は従来より高くなるため、ユースケースや予算的に適合するかどうか注意が必要です。
もしコストが見合わない場合は、従来のKendraやKnowledge Basesをうまく活用していくしかなさそうです。

---

1. 例えば、Agents側でアクショングループを定義し、その中でKendraのRetrieve APIを呼び出す ↩︎