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

Transcript

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

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

3. ⾃⼰紹介 • ハンドルネーム ◦ つくぼし • 所属 ◦ AWS事業本部コンサルティング部 ◦

   ソリューションアーキテクト • 最近ハマっているAWSサービス ◦ AWS Application Composer • SNS/ブログ ◦ X(@tsukuboshi0755) ◦ DevelopersIO(つくぼし) 3

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

   AWSでオススメのRAG構成パターン 6. 最後に 4

5. 1. はじめに 5

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

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

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

9. 2. RAGのおさらい 9

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

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

    成AIが回答⽣成する事で、上記の弱点を補う事が可能

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

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

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

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

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

17. チャンキング 17 • ⼤きなドキュメントデー タを⼩さな断⽚(チャン ク)に分割する事を指す • RAGでは適切なチャンク サイズと分割⽅法を選ぶ 事で、検索精度と⽣成品

    質の向上が期待できる 参考：https://fintan.jp/page/10301/

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

19. ベクトルデータベース 19 • 数値ベクトルを効率的に保存し、ベ クトル検索を実施するために設計さ れたデータベースシステムを指す • ベクトル検索：変換された数値ベク トルの類似度を⽐較し、関連性の⾼ いデータを⾒つけ出す検索⽅法

    参考：https://aws.amazon.com/jp/blogs/news/the-role-of-vector-datastores-in-generative-ai-applications/

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

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

    21

22. Amazon Kendra 22 • AIを活⽤した⾼度なエンタープライ ズ検索サービス • データソースのドキュメント情報を 抽出し、インデックスとして保存 •

    インデックスを検索する事で、関連 性の⾼い回答を提供

23. Kendraを⽤いたRAGの実装 23

24. Knowledge Bases for Amazon Bedrock 24 • 基盤モデルを⽤いてRAGを実現する Amazon Bedrockの⼀機能

    • データソースのドキュメント情報をエ ンベディングに変換し、ベクトルデー タベースに保存 • ベクトルデータベースを検索する事 で、関連性の⾼い回答を提供

25. Knowledge basesを⽤いたRAGの実装 25

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

    V. チャンキング戦略

27. Ⅰ. 使⽤料⾦ 27 • Kendraは料⾦が⾼いので要注意！ ◦ 現状Enterprise版の場合、最低インデックス料⾦が 1,008USD/⽉となる ◦ Developer版にするとSingle

    AZとなるが、最低イン デックス料⾦が810USD/⽉と安くなる • Knowledge Basesの料⾦はベクトルデータベースにもよ るが、ほとんどの場合Kendraよりは安くなる ◦ 基本はベクトルデータベース料⾦ + モデル利⽤料⾦

28. Ⅱ. 対象データソース 28 • KendraはS3の他に、様々なデータソースを接続可能 ◦ AWSであれば、RDSやFSx(Windows/NetApp ONTAP)といった サービスとも接続できる ◦

    SaaSであれば、SharepointやBox、Google Drive等が利⽤できる ◦ Web Crawlerを⽤いて、特定のウェブサイトを参照する事も可能 • Knowledge BasesはS3のみデータソースとして接続可能 ◦ RDSやSaaS等を対象としたい場合、S3へのデータアップロードの 仕組みが別途必要

29. Ⅲ. 同期実⾏スケジューリング機能 29 • Kendraは単体で同期実⾏スケジューリングを設定可能 ◦ オンデマンド(⼿動実⾏)またはスケジューリングのい ずれかを選択できる • Knowledge

    Basesは単体で同期実⾏スケジューリングを 設定できない ◦ データ同期スケリューリングの仕組み(EventBridge Scheduler + Step Functions等)が別途必要

30. Ⅳ. 検索フィルタリング機能 30 • Kendraはメタデータによるフィルタリング、CDEによるメタデータ⾃動付与、 及びACLによるフィルタリングを実施可能 ◦ メタデータをファイル毎に付与する事で、ファイル単位でフィルタリング できる ◦

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

31. Ⅴ. チャンキング戦略 31 • Kendraはチャンキング戦略を設定不可 • Knowledge Basesはチャンキング戦略を、以下から変更可能 ◦ デフォルトのチャンキング：各ファイルを300

    の最⼤トークン数 を持つチャンクに分割し処理する ◦ 固定サイズのチャンキング：各ファイルを20 ~ 8192 の間で指定 した最⼤トークン数を持つチャンクに分割し処理する ◦ チャンキング無し：各ファイルをそのままチャンクとして処理す る

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

    り

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

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

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

    サードパーティ 35

36. Amazon OpenSearch Serverless 36 • ⼤量のデータコレクションを格納し⾼速で検 索可能にするサービス • Serverlessモードで起動する事で、クラス ターの管理が不要

    • ベクトル検索を選択する事で、ベクトルデー タベースとして使⽤可能

37. Amazon Aurora PostgreSQL 37 • PostgreSQLと互換性のある、フルマネージ ドなリレーショナルデータベースサービス • pgvector拡張機能を⽤いた追加セットアッ プにより、ベクトルデータベースとして使⽤

    可能 • Aurora に対して HTTP 経由でアクセスを⾏ うData APIの許可設定が別途必要

38. サードパーティ 38 • Pinecone • Redis Enterprise Cloud • MongoDB

    Atlas

39. サードパーティ 39 • Pinecone • Redis Enterprise Cloud • MongoDB

    Atlas

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

    V. ネットワーク運⽤

41. Ⅰ. 東京リージョン対応 41 • OpenSearch及びAuroraは、東京リージョンに対応 済 ◦ ただし使⽤できるBedrockモデルには制限があ るため注意 •

    Pineconeは、現状東京リージョンは未対応 ◦ 海外リージョンのKnowledge Bases及びS3を使 ⽤する必要がある

42. Ⅱ. 使⽤料⾦ 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)に上がるため注意

43. Ⅲ. ハイブリッド検索 43 • OpenSearchではハイブリッド検索を使⽤可能 ◦ ハイブリッド検索 ：セマンティック検索と全⽂検索 の両⽅を実⾏する検索⽅法。現状Knowledge Bases

    ではOpenSearchのみ有効化可能。 ◦ さらにアナライザー(⼊⼒されたテキストの前処理を するフィルタ機能)として⽇本語対応プラグインを指 定する事で、回答精度の向上が⾒込める。 • Aurora及びPineconeは利⽤不可

44. Ⅳ. シークレット運⽤ 44 • OpenSearchは、原則シークレットが不要 ◦ シークレット運⽤を考慮する必要がない • Aurora及びPineconeは、事前にSecrets Managerにシークレットの登録が必要

    ◦ AuroraはDBのユーザー名/パスワード ◦ PineconeはAPIキー

45. Ⅴ. ネットワーク運⽤ 45 • OpenSearch及びPineconeは、VPCの有無を選択可能 ◦ VPCなしにする事で、ネットワーク運⽤を考慮する必要がなくな る ◦ VPCありにする事で、Private

    Linkを⽤いたプライベート接続が可 能(Pineconeは現状パブリックプレビュー版のため注意) • Auroraは必ずVPCが必要 ◦ Private Linkを⽤いたプライベート接続は可能な⼀⽅で、ネット ワーク運⽤の⼿間��必然的に発⽣する

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

47. AWSでRAGを実現する⽅法 47 • Kendra & Bedrock • Knowledge Bases for

    Amazon Bedrock • 独⾃実装

48. AWSでRAGを実現する⽅法 48 • Kendra & Bedrock • Knowledge Bases for

    Amazon Bedrock • 独⾃実装

49. オススメの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 との接続には原則必要 不要 必要 必要 ネットワーク運用 デフォルトは不要 デフォルトは不要 必要 デフォルトは不要

50. パターン1.Kendra + Bedrock 50

51. パターン1がオススメの⽅ 51 • データソースにS3以外のサービス(RDSやFSx、 各種SaaS、Web Crawler)を使⽤したい⽅ • スケジューリング同期実⾏を簡単に使⽤したい ⽅ •

    ⾼性能な検索フィルタリング機能を使⽤したい ⽅

52. パターン2.Knowledge Bases with OpenSearch 52

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

54. パターン3.Knowledge Bases with Aurora 54

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

56. パターン4.Knowledge Bases with Pinecone 56

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

    VPCなしの構成にしたい⽅

58. 6. 最後に 58

59. まとめ 59 • AWSでRAG構成を検討する際は、以下の2点を考慮 し、要件に応じて適切な構成を選択すると良い ◦ 検索エンジン(Kendra/Knowledge Bases) ◦ ベクトルデータベース

    (OpenSearch/Aurora/Pinecone等) • RAG周りはアップデートが早いので、引き続き最新 情報を追っていくのが吉

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

61. 参考⽂献 61 • [RAGの性能を改善するための8つの戦略 \| Fintan](https://fintan.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/)
62. None

63. 63