はじめに
2025/3/6(木)、AWSが主催するオンラインイベント「AWS Innovate Generative AI + Data Edition」が開催されました。本記事では中でも「Amazon Bedrock Knowledge Baseを実装する上の課題と解決手法」に関するセッションのレポートとして記載します。
セッション名
T3-1: RAG の実装で直面する課題とその解決 ～Amazon Bedrock Knowledge Base で加速させるビジネス価値～ (上級セッション - level 300)
発表者
アマゾンウェブサービス ジャパン合同会社 近藤 健二郎さん
セッションの内容
本セッションでは、RAGアプリをアジャイル開発のように構築・改善しながら開発するような流れに沿って、各フェーズにおける具体的な課題と解決策について発表されてました。
Step1. データを準備する
RAGには、ナレッジベースとなるデータを用意する必要がある。
初期段階では、少量のデータからスタートし、徐々にスコープを広げていくのが良い。
Step2. まずは最小構成でRAGアプリを作ってみる
課題：最小構成のRAGを作るには時間がかかる
最小といってもRAGアプリに必要なものって結構ある。全部一から作ってたら時間がかかる...
- フロントエンドUI
- インフラ
- バックエンド
- LLM
- ユーザー管理
- etc...
解決方法：容易されたAWSサービスやツールを活用する
以下のようにRAGを迅速に構築するために用意されたAWSサービスやツールが存在する。これらをうまく活用することが重要。
| No | 概要 |
|---|---|
| Amazon Bedrock Knowledge Base | RAGを構築・運用するためのマネージドサービス |
| GenU (Generative AI Use Cases JP) | 様々なユースケース別に作られた生成AIアプリ集 (RAGアプリもある) |
| Amazon Q Business | エンタープライズ向けにRAGを活用したチャットアプリを提供してくれるサービス |
Step3. 使ってみる、もしくはユーザーに使ってもらう
作ったRAGは、自分や開発陣で使ってみよう。
また実際のユーザーにも使ってもらって、生の声も聴いてみよう。
ユーザー声で聴いて、初めて気づくこともあるかも。
Step4. 改善する
課題①：思い通りの回答がRAGから得られない...
期待通りにナレッジベースの検索にひっからず、間違った情報を答えてくるなどが起こりうる。
(Step3で、実際にユーザーに使ってもらったら、想定外の使い方されて、こういった課題が見えてくるかも)
解決方法： 検索・回答精度の改善(Advanced RAG)を試す
まずは原因の分析から始めるのが重要。
検索が出来ていない? それともLLMの回答が間違ってる? から切り分けるのが良い。
では具体的にどうやって、検索・回答精度の改善を行うか？
Amazon Bedrock Knowledge Basesには、以下のような検索・回答精度の改善が気軽に利用できる要素があるので活用する。
| No | 手法 | 説明 |
|---|---|---|
| 1 | チャンキング設定 | チャンキング = 文章の分割 分割サイズの調整や様々な分割手法を試すことで、精度向上が狙える |
| 2 | モデルの変更 | 適材適所のモデルに切り替えることで精度に影響が出る可能性がある |
| 3 | クエリの分解 | 複雑なクエリを複数のクエリに分割することで、ほしい情報を探しやすくする |
| 4 | リランキング | ユーザーの質問に関連した情報に並び替えることで、質問に関連した情報を見つけやすくする |
課題②：特定のユースケースに対応したいが、RAGアプリのカスタマイズができない
固有の業務や企業によっては、特殊なユースケースが発生する可能性がある。
- 特定のデータフォーマット
- 特定の人の要望 (RAGアプリでXXの情報も見たい)
RAGアプリのカスタマイズができないと対応できない...
解決方法：Amazon Bedrock Knowledge Basesの機能でカスタイズする
Amazon Bedrock Knowledge Basesでは、以下のような機能を提供しているので、うまく活用する。
| No | 方法 | 説明 |
|---|---|---|
| 1 | ドキュメントの前処理をカスタマイズ | 前処理としてLambdaを動かすことが可能 |
| 2 | メタデータをカスタマイズ | ドキュメントに対してメタデータを付与することが可能 |
| 3 | プロンプトのカスタマイズ | RAGのプロンプトを決められた内容でなくカスタム可能 |
課題③：ドキュメントの図や表に関する質問が上手くいかない
例えば、ドキュメントに画像や図が埋め込まれているとき、RAGにそのまま送ると画像や図の情報が失われる... つまり、RAGから期待通りの回答が返ってこない。
マルチモーダルデータ
- 上記ののドキュメントのように、テキスト、画像、図などが埋め込まれているデータを指す
- 画像や図はテキストと違って検索が難しいからRAGで取り扱いにくい
- 生成AIのモデルによっては、マルチモーダルデータに対応しているモデル、対応してないもであるがある
解決方法：をテキストに変換する ⇒ マルチモーダルデータパーサーを使う
RAGに送る前に画像や図をテキストに変換することで解決する。AWSで実現するには、以下の２種類がある。
- Foundation Model Parser
- Amazon Bedrock Data Automeation
- セッション段階では、プレビューで日本語未対応)
Amazon Bedrock Data Automeationが一般提供
本セッションの中では、プレビューだったのですが、その数日前に僅差で一般公開されてたようです。
https://dev.classmethod.jp/articles/amazon-bedrock-data-automation-general-availability-overview/
Foundation Model Parserについて掘り下げ
Foundation Model Parserは、RAGへデータを送る前にLLMを使って画像や図をテキストに変換する機能。元の画像は失われないように、変換後のテキストと紐づけておくことが可能。
Step5. 上記3、4 を繰り返し、改善する
「評価」x 「改善」のサイクルを素早く回すことが、良いアプリにするコツ。
そして評価する方法は、大きく２つある。どちらも一長一短で、これらを行き来して評価する。
- オンライン評価
- 実際にユーザーに使ってもらって評価する
- オフライン評価
- 評価用の
質問と正解回答のデータセットを用意し、期待通りか評価する
- 評価用の
課題①：評価に時間がかかって、サイクルが回せない...
「評価」x 「改善」のサイクルを回したいが、評価に時間がかかる。
解決方法：オフライン評価のLLMを使って自動化する
オフライン評価にLLMを使うことで、評価を自動化し、効率化を図る。
これらの評価にLLMを用いる手法をLLM as a Judgeと呼ぶ
Step6. リリース水準に達したところでリリース。リリース後も改善を続ける。
課題：RAGを様々な観点で評価したいけど、評価観点がわからない
そもそも様々な観点がある中で、網羅的にチェックすること自体が難しい。
解決方法：評価のフレームワークやツールを使う
以下のような評価のフレームワークやツールを使う。
- RAGAS
- RAGChecker
Step5、6の課題をKnowledge Basesの自動評価の機能を使で解決できる
Amazon Bedrock knowledge Basesには、自動評価(LLM as a Judge)を実施できる機能(プレビュー)がある。
事前準備は、質問と模範解答のペアを用意するだけなので、取っつきやすい。
所感
プロジェクトの進め方に沿って説明いただいたので、RAG開発でいつどのような課題が発生するのかイメージしやすかったです。
聞いてると、RAGアプリの初期構築は、比較的ツールやAWSサービスが充実してきているので、ハードルが下がっていると感じました。
そのため、今回のセッションで紹介された実装後の改善手法やTipsは、実践的で大変参考になりました。