AWSで構築するパターン別RAG構成解説

by つくぼし

Slide 1

Slide 1 text

AWSで構築するパターン別RAG構成解説 2024.7.8 AWS事業本部つくぼし

Slide 2

Slide 2 text

Xへの投稿の際は、ハッシュタグ #cm_odyssey でお願いいたします。 2 お願い

Slide 3

Slide 3 text

⾃⼰紹介 ● ハンドルネーム ○ つくぼし ● 所属 ○ AWS事業本部コンサルティング部 ○ ソリューションアーキテクト ● 最近ハマっているAWSサービス ○ AWS Application Composer ● SNS/ブログ ○ X(@tsukuboshi0755) ○ DevelopersIO(つくぼし) 3

Slide 4

Slide 4 text

⽬次 1. はじめに 2. RAGのおさらい 3. AWSにおけるRAG検索エンジンサービスの⽐較 4. AWSにおけるベクトルデータベースサービスの⽐較 5. AWSでオススメのRAG構成パターン 6. 最後に 4

Slide 5

Slide 5 text

1. はじめに 5

Slide 6

Slide 6 text

社内データをRAGで活⽤する事例が増えてきている 6

Slide 7

Slide 7 text

AWSではどのパターンのRAGを組むと良いのか？ 7

Slide 8

Slide 8 text

RAG含めた生成 AI周りの技術は、アップデート速度が早い傾向があります。今回のセッション内容は、あくまで 2024/7/7までの情報を元にしているためご注意ください。 8 ご注意事項

Slide 9

Slide 9 text

2. RAGのおさらい 9

Slide 10

Slide 10 text

RAG(Retrieval Augmented Generative)とは？ 10 ⽣成AIにデータの検索結果を与える事で、⽣成する回答性能を向上させる⼿法

Slide 11

Slide 11 text

なぜRAGが必要なのか？ 11 ● ⼀般的に、⽣成AIは特定時点までのパブリックデータしか学習していない ● そのため単独では、最新データやプライベートデータ等を⽤いた返答が難しい ● 外部DBに参照データを格納し、DBの検索結果を元に⽣成AIが回答⽣成する事で、上記の弱点を補う事が可能

Slide 12

Slide 12 text

RAGのフェーズ 1. Storeフェーズ 2. Retrievalフェーズ 3. Generationフェーズ 12

Slide 13

Slide 13 text

Storeフェーズ 13 ● 外部データソースから関連情報を収集 ● 収集した情報を分割し、検索エンジンが使⽤するデータベースに保存

Slide 14

Slide 14 text

Retrievalフェーズ 14 ● 検索エンジンを⽤いて、類似ドキュメントの検索を実施 ● 抽出されたドキュメント内容のみを結果として返答

Slide 15

Slide 15 text

Generationフェーズ 15 ● 検索結果の内容を参照先として付与した上で、LLMにプロンプトを渡す ● LLMがドキュメントに基づいて、回答を⽣成

Slide 16

Slide 16 text

RAGを理解する上で重要な概念 16 ● チャンキング ● エンベディング(埋め込み) ● ベクトルデータベース

Slide 17

Slide 17 text

チャンキング 17 ● ⼤きなドキュメントデータを⼩さな断⽚(チャンク)に分割する事を指す ● RAGでは適切なチャンクサイズと分割⽅法を選ぶ事で、検索精度と⽣成品質の向上が期待できる参考：https://ﬁntan.jp/page/10301/

Slide 18

Slide 18 text

エンべディング(埋め込み) 18 ● テキストや画像などのデータを、数値ベクトルに変換する技術を指す ● エンべディングにより、データの意味や関係性を数学的に表現する事で、機械学習モデルによる類似検索が可能になる参考：https://aws.amazon.com/jp/blogs/news/the-role-of-vector-datastores-in-generative-ai-applications/

Slide 19

Slide 19 text

ベクトルデータベース 19 ● 数値ベクトルを効率的に保存し、ベクトル検索を実施するために設計されたデータベースシステムを指す ● ベクトル検索：変換された数値ベクトルの類似度を⽐較し、関連性の⾼いデータを⾒つけ出す検索⽅法参考：https://aws.amazon.com/jp/blogs/news/the-role-of-vector-datastores-in-generative-ai-applications/

Slide 20

Slide 20 text

3. AWSにおける RAG検索エンジンサービス 20

Slide 21

Slide 21 text

RAG検索エンジンサービスの選択肢 ● Amazon Kendra ● Knowledge Bases for Amazon Bedrock 21

Slide 22

Slide 22 text

Amazon Kendra 22 ● AIを活⽤した⾼度なエンタープライズ検索サービス ● データソースのドキュメント情報を抽出し、インデックスとして保存 ● インデックスを検索する事で、関連性の⾼い回答を提供

Slide 23

Slide 23 text

Kendraを⽤いたRAGの実装 23

Slide 24

Slide 24 text

Knowledge Bases for Amazon Bedrock 24 ● 基盤モデルを⽤いてRAGを実現する Amazon Bedrockの⼀機能 ● データソースのドキュメント情報をエンベディングに変換し、ベクトルデータベースに保存 ● ベクトルデータベースを検索する事で、関連性の⾼い回答を提供

Slide 25

Slide 25 text

Knowledge basesを⽤いたRAGの実装 25

Slide 26

Slide 26 text

RAG検索エンジンサービスの⽐較観点 26 I. 使⽤料⾦ II. 対象データソース III. 同期実⾏スケジューリング機能 IV. 検索フィルタリング機能 V. チャンキング戦略

Slide 27

Slide 27 text

Ⅰ. 使⽤料⾦ 27 ● Kendraは料⾦が⾼いので要注意！ ○ 現状Enterprise版の場合、最低インデックス料⾦が 1,008USD/⽉となる ○ Developer版にするとSingle AZとなるが、最低インデックス料⾦が810USD/⽉と安くなる ● Knowledge Basesの料⾦はベクトルデータベースにもよるが、ほとんどの場合Kendraよりは安くなる ○ 基本はベクトルデータベース料⾦ + モデル利⽤料⾦

Slide 28

Slide 28 text

Ⅱ. 対象データソース 28 ● KendraはS3の他に、様々なデータソースを接続可能 ○ AWSであれば、RDSやFSx(Windows/NetApp ONTAP)といったサービスとも接続できる ○ SaaSであれば、SharepointやBox、Google Drive等が利⽤できる ○ Web Crawlerを⽤いて、特定のウェブサイトを参照する事も可能 ● Knowledge BasesはS3のみデータソースとして接続可能 ○ RDSやSaaS等を対象としたい場合、S3へのデータアップロードの仕組みが別途必要

Slide 29

Slide 29 text

Ⅲ. 同期実⾏スケジューリング機能 29 ● Kendraは単体で同期実⾏スケジューリングを設定可能 ○ オンデマンド(⼿動実⾏)またはスケジューリングのいずれかを選択できる ● Knowledge Basesは単体で同期実⾏スケジューリングを設定できない ○ データ同期スケリューリングの仕組み(EventBridge Scheduler + Step Functions等)が別途必要

Slide 30

Slide 30 text

Ⅳ. 検索フィルタリング機能 30 ● Kendraはメタデータによるフィルタリング、CDEによるメタデータ⾃動付与、及びACLによるフィルタリングを実施可能 ○ メタデータをファイル毎に付与する事で、ファイル単位でフィルタリングできる ○ CDE(Contents Data Enrichment)を設定する事で、メタデータの⾃動付与を⽐較的簡単に実現できる ○ ACL(Access Control List)を設定すると、認証サーバと連携し、特定のユーザ‧グループ権限毎にプレフィックス単位でフィルタリングできる ● Knowledge Basesはメタデータによるフィルタリングのみ実施可能 ○ メタデータを⾃動付与したい場合、Lambda等でのメタデータ付与システムの仕組みが別途必要

Slide 31

Slide 31 text

Ⅴ. チャンキング戦略 31 ● Kendraはチャンキング戦略を設定不可 ● Knowledge Basesはチャンキング戦略を、以下から変更可能 ○ デフォルトのチャンキング：各ファイルを300 の最⼤トークン数を持つチャンクに分割し処理する ○ 固定サイズのチャンキング：各ファイルを20 ~ 8192 の間で指定した最⼤トークン数を持つチャンクに分割し処理する ○ チャンキング無し：各ファイルをそのままチャンクとして処理する

Slide 32

Slide 32 text

余談：現時点のIaC化対応状況 32 ● Kendraの場合、新データソース設定である TemplateConﬁgurationが⼀部のIaCで現状未対応のため、事前に対応しているか確認するのが吉 ● Knowledge Basesの場合、ベクトルデータベース内のインデックス作成⽅法を別途考慮する必要あり

Slide 33

Slide 33 text

4. AWSにおけるベクトルデータベースサービスの⽐較 33

Slide 34

Slide 34 text

Knowledge Basesで指定できるベクトルデータベース 34

Slide 35

Slide 35 text

ベクトルデータベースサービスの選択肢 ● OpenSearch Serverless (ベクトル検索) ● Aurora PostgreSQL (pgvector拡張機能) ● サードパーティ 35

Slide 36

Slide 36 text

Amazon OpenSearch Serverless 36 ● ⼤量のデータコレクションを格納し⾼速で検索可能にするサービス ● Serverlessモードで起動する事で、クラスターの管理が不要 ● ベクトル検索を選択する事で、ベクトルデータベースとして使⽤可能

Slide 37

Slide 37 text

Amazon Aurora PostgreSQL 37 ● PostgreSQLと互換性のある、フルマネージドなリレーショナルデータベースサービス ● pgvector拡張機能を⽤いた追加セットアップにより、ベクトルデータベースとして使⽤可能 ● Aurora に対して HTTP 経由でアクセスを⾏うData APIの許可設定が別途必要

Slide 38

Slide 38 text

サードパーティ 38 ● Pinecone ● Redis Enterprise Cloud ● MongoDB Atlas

Slide 39

Slide 39 text

サードパーティ 39 ● Pinecone ● Redis Enterprise Cloud ● MongoDB Atlas

Slide 40

Slide 40 text

ベクトルデータベースの⽐較観点 40 I. 東京リージョン対応 II. 使⽤料⾦ III. ハイブリッド検索 IV. シークレット運⽤ V. ネットワーク運⽤

Slide 41

Slide 41 text

Ⅰ. 東京リージョン対応 41 ● OpenSearch及びAuroraは、東京リージョンに対応済 ○ ただし使⽤できるBedrockモデルには制限があるため注意 ● Pineconeは、現状東京リージョンは未対応 ○ 海外リージョンのKnowledge Bases及びS3を使⽤する必要がある

Slide 42

Slide 42 text

Ⅱ. 使⽤料⾦ 42 ● OpenSearchは、東京リージョンの場合、最低OCU料⾦が 977.952USD(OCU：4)となる ○ アクティブレプリカを無効にする事で、Single AZとなるが最低OCU料⾦は 488.976USD/⽉(OCU：2)となる ● Aurora (Serverless v2)は、東京リージョンの場合、最低ACU料⾦が 73.2USD(ACU：0.5)となる ○ EventBridgeによりDBの起動停⽌スケジュールを設定する事で、RAGを使⽤していない時間の料⾦を削減可能 ● Pinecone (Serverless)は、Standardプランかつバージニアリージョンの場合、最低Units料⾦が10.25USD(Read：1/Write：1)となる ○ VPCに配置してPrivate Link接続したい場合は、Enterpriseプランにする必要があり、最低Units料⾦が20.5USD(Read：1/Write：1)に上がるため注意

Slide 43

Slide 43 text

Ⅲ. ハイブリッド検索 43 ● OpenSearchではハイブリッド検索を使⽤可能 ○ ハイブリッド検索：セマンティック検索と全⽂検索の両⽅を実⾏する検索⽅法。現状Knowledge Bases ではOpenSearchのみ有効化可能。 ○ さらにアナライザー(⼊⼒されたテキストの前処理をするフィルタ機能)として⽇本語対応プラグインを指定する事で、回答精度の向上が⾒込める。 ● Aurora及びPineconeは利⽤不可

Slide 44

Slide 44 text

Ⅳ. シークレット運⽤ 44 ● OpenSearchは、原則シークレットが不要 ○ シークレット運⽤を考慮する必要がない ● Aurora及びPineconeは、事前にSecrets Managerにシークレットの登録が必要 ○ AuroraはDBのユーザー名/パスワード ○ PineconeはAPIキー

Slide 45

Slide 45 text

Ⅴ. ネットワーク運⽤ 45 ● OpenSearch及びPineconeは、VPCの有無を選択可能 ○ VPCなしにする事で、ネットワーク運⽤を考慮する必要がなくなる ○ VPCありにする事で、Private Linkを⽤いたプライベート接続が可能(Pineconeは現状パブリックプレビュー版のため注意) ● Auroraは必ずVPCが必要 ○ Private Linkを⽤いたプライベート接続は可能な⼀⽅で、ネットワーク運⽤の⼿間が必然的に発⽣する

Slide 46

Slide 46 text

5. AWSでオススメの RAG構成パターン 46

Slide 47

Slide 47 text

AWSでRAGを実現する⽅法 47 ● Kendra & Bedrock ● Knowledge Bases for Amazon Bedrock ● 独⾃実装

Slide 48

Slide 48 text

AWSでRAGを実現する⽅法 48 ● Kendra & Bedrock ● Knowledge Bases for Amazon Bedrock ● 独⾃実装

Slide 49

Slide 49 text

オススメのRAG構成パターン別⽐較表 49 比較観点 Kendra & Bedrock Knowledge Bases with OpenSearch Knowledge Bases with Aurora Knowledge Bases with Pinecone 使用料金やや高~高中~やや高やや低~中低対象データソース S3/RDS/FSx(Windows・ONTAP)/ 各種SaaS/Web Crawler S3 S3 S3 同期実行スケジューリング機能ありなしなしなし検索フィルタリング機能メタデータ(自動付与機能あり)/ACL メタデータ(自動付与機能なし) メタデータ(自動付与機能なし) メタデータ(自動付与機能なし) チャンキング戦略なしありありあり東京リージョン対応ありありあり現時点ではなしハイブリッド検索なしありなしなしシークレット運用 S3との接続には不要 RDS/FSx/各種SaaS/Web Crawler との接続には原則必要不要必要必要ネットワーク運用デフォルトは不要デフォルトは不要必要デフォルトは不要

Slide 50

Slide 50 text

パターン1.Kendra + Bedrock 50

Slide 51

Slide 51 text

パターン1がオススメの⽅ 51 ● データソースにS3以外のサービス(RDSやFSx、各種SaaS、Web Crawler)を使⽤したい⽅ ● スケジューリング同期実⾏を簡単に使⽤したい⽅ ● ⾼性能な検索フィルタリング機能を使⽤したい⽅

Slide 52

Slide 52 text

パターン2.Knowledge Bases with OpenSearch 52

Slide 53

Slide 53 text

パターン2がオススメの⽅ 53 ● Kendraよりは料⾦を安く抑えたい⽅ ● チャンキング戦略やハイブリッド検索を使いこなし、回答精度を独⾃に細かく調整したい⽅ ● Secrets‧VPCなしの構成にしたい⽅

Slide 54

Slide 54 text

パターン3.Knowledge Bases with Aurora 54

Slide 55

Slide 55 text

パターン3がオススメの⽅ 55 ● ある程度料⾦を安く抑えたい⽅ ● Secrets‧VPC管理がそこまで⼿間にならない⽅ ● RDBMSを⽤いてベクトルデータベースを運⽤したい⽅

Slide 56

Slide 56 text

パターン4.Knowledge Bases with Pinecone 56

Slide 57

Slide 57 text

パターン4がオススメの⽅ 57 ● 料⾦をとにかく安く抑えたい⽅ ● 参照元データを海外リージョンに配置しても問題ない⽅ ● Secrets管理がそこまで⼿間にならない⽅ ● VPCなしの構成にしたい⽅

Slide 58

Slide 58 text

6. 最後に 58

Slide 59

Slide 59 text

まとめ 59 ● AWSでRAG構成を検討する際は、以下の2点を考慮し、要件に応じて適切な構成を選択すると良い ○ 検索エンジン(Kendra/Knowledge Bases) ○ ベクトルデータベース (OpenSearch/Aurora/Pinecone等) ● RAG周りはアップデートが早いので、引き続き最新情報を追っていくのが吉

Slide 60

Slide 60 text

RAGを制するものは⽣成AIインフラを制す！ 60

Slide 61

Slide 61 text

参考⽂献 61 ● [RAGの性能を改善するための8つの戦略 \| Fintan](https://ﬁntan.jp/page/10301/) ● [⽣成系 AI アプリケーションでベクトルデータストアが果たす役割とは \| Amazon Web Services ブログ](https://aws.amazon.com/jp/blogs/news/the-role-of-vector-datastores-in-generative -ai-applications/) ● [AWS ⼊⾨ブログリレー 2024 〜Amazon Kendra編〜 \| DevelopersIO](https://dev.classmethod.jp/articles/introduction-2024-amazon-kendra/) ● [AWS ⼊⾨ブログリレー 2024 〜Knowledge bases for Amazon Bedrock編〜 \| DevelopersIO](https://dev.classmethod.jp/articles/introduction-2024-knowledge-bases -for-amazon-bedrock/) ● [Amazon Bedrock ⽣成AIアプリ開発⼊⾨ \[AWS深掘りガイド\] \| SBクリエイティブ](https://www.sbcr.jp/product/4815626440/)