ビッグデータにおける、RAGデザインパターン詳解

ビッグデータにおける、RAGデザインパターン詳解

Transcript

1. ビッグデータにおける、RAGデザインパターン詳解 株式会社ulusage 大堀遼介
2. 自己紹介 • 大堀 遼介（36） • Webアプリエンジニア/データサイエンティスト • 理工学部情報理工学科卒 • 経歴概要 • 経歴紹介 • バックエンド中心の開発（ KADOKAWA ） • エンタープライズ向けシステム統合コンサルティング • データパイプライン基盤（TOYOTA, HONDA, ベルフェイス） • コンシューマ向けデータプロバイダー（MaaS関連企業） • 小売・メーカー向け、AIアプリケーション開発（某大手宅配） • データエンジニア、データサイエンティスト（ABEJA, GRID, DATAFLUCT ...etc） • 株式会社ulusage CEO http://PlagIn-AI.com
3. RAGの課題おさらい
4. 今回の発表のスコープ • 話すこと ◦ あくまでRAG関連 ◦ スケーラビリティなベクトル検索エンジン構築手法 ◦ デモコード ◦ 一部エージェント ▪ マルチエージェントなどは次回あれば • 話さないこと ◦ プロンプトエンジニアリング ◦ データパイプライン ◦ LLMOpsの詳細 ▪ 評価までは話します。
5. ビックデータへのRAGの課題【再 掲】 RAGは学習していないデータに対してLLMに知識を付加するのに非常に有効です が、特に、データボリュームが多くなるほど、劇的に性能低下、ハルシネーショ ンが増加してきます。さらにLangChainやLlama-Indexであっても、導入に対する の技術的障壁、性能の壁が存在します。
6. 一般的なRAGプロセス概要 ※ ベクターDBへ「埋め込み」と「検索」イメージ チャンク LLM インデックス 検索 ベクトルDB xxxxxx xxxxxx xxxxxx xxxxxx チャンク & ベクトル埋め込み ドキュメント 0.1,0.3, -0.1.. 0.4,0.2, 0.6.. 検索 埋め込み
7. RAGプロセス 以下のプロセスは、一般的なRAGシステムのプロセスです。 ケースによりますが、このプロセスにて、「データのロード」と「クエリ」を切 り離すだけでも、性能は向上します。今回のデザインパターンは以下のプロセス に従います。 加工 ロード インデッ クス作成 ストア 非同期 クエリ 評価
8. デザインパターン詳解
9. デザインパターン概要 今回は多段インデックスという手法に、フォーカスします。 チャンク 子インデックス LLM 親インデックス ベクトルDB 0.1,0.3, -0.1.. 0.4,0.2, 0.6.. 0.1,0.3, -0.1.. 0.4,0.2, 0.6.. ベクトルDB
10. どういうユースケースに強みがある？ • RAGパイプラインの一部、ベクトル検索のインデックス のスケーリング ここ！
11. デザインパターン詳解 Step 1
12. データの、粒度を決める。 • 特徴の分類を実施する。 • 時系列単位 • コーパス単位 • トピック単位 • 画像の特徴単位 STEP1: データの粒度を決めよう。 特徴の分類 （親インデックス） 特徴のサブ分類 （子インデックス） チャンクの粒度 （検索対象） デー タ セッ ト 分類 ⅰ 分類 ⅱ 分類 ⅲ サブ 分類 ⅰ サブ 分類 ⅱ サブ 分類 ⅱ 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
13. データの粒度を決めよう。 粒度は、データへの特性への知識が必要です。 私自身まずは、通常のAI開発やデータサイエ ンスの重要なプロセス、EDAから入ります。 今回はLiveDoor コーパスデータを使います。 次のようなカテゴリ分類がなされています。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
14. データの粒度を決めよう。 カテゴリまでを、綺麗に分類できたので、次 は、サブ分類です。今回はLDAによって、タ イトルをサブ分類としてそれらしく分かれて いそうなので、こちらを使います。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価 デー タ セッ ト cate gory ⅰ cate gory ⅱ cate gory ⅲ title ⅰ title ⅱ title ⅱ
15. データを埋め込みエンコードしよう。 分類によって、親子間のインデックスが決定 できました。 次は、埋め込みエンコード化しましょう。 いわゆる「embedding」です。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
16. デザインパターン詳解 Step 2
17. 子インデックスを登録しよう。 データの埋め込みが完了したので、いよいよ インデックス化です。 マッピングという、どのフィールドに対して ベクトル検索を行うことを可能にするかを定 義します。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
18. 子インデックスを登録しよう。 マッピングが完了したので、カテゴリごとの インデックスを作成します。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価 インデックスを作成したら、インデックスへ データのロードを実施します。
19. テストクエリ（標準検索）しよう。 データのロードができたので、いよいよ検索 を行ってみましょう！ 以下は一般的な、マッチクエリです。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
20. テストクエリを評価しよう。 検索結果を以下の指標を使い、評価しましし ょう。 検索評価指標は、多様にありますが、標準検 索の場合には以下の指標を利用するといいで しょう。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価 指標 説明 結果 MRR (平均逆順位) 一連のクエリに対する結果の逆順位の平均。値が1.0の場 合、完全な順位を示します。 1.0 Recall@5 上位5件の結果に含まれる関連項目の割合。値が1の場合、 関連する全ての項目が上位5件に含まれることを示しま す。 1
21. デザインパターン詳解 Step 3
22. 親インデックスを登録しよう。 次は親インデックス化です。 マッピングにて、子インデックスのエンドポ イントは カテゴリ名でしたので、フィールドに含めま す。 あとは、子インデックスの概要などの特徴を なるべく詳しく記載し、埋め込みエンコード します。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
23. 親インデックスを登録しよう。 子インデックスに対する、特徴は今回幾つか のサンプルデータの要約に決定します。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
24. 親インデックスを登録しよう。 マッピングが完了したので、カテゴリごとの インデックスを作成します。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
25. テストクエリ（セマンティック検索）しよう。 いよいよ、多段セマンティック検索です！ 評価は、入力と出力のコサイン類似度にて評 価。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
26. テストクエリ（セマンティック検索）しよう。 評価結果としてはまずまずですね！ 今後こちらは、各子インデックスの説明をよ り、簡潔に記載するか、Rerankなどの技術に より精度を高めていくといいです。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
27. デザインパターン詳解 Step 4
28. 検索拡張生成しよう。 いよいよ、LLMに検索エンジンによって知識 会得を実施し、会話をしてみましょう。 検索エンジンへのコネクタはLangchainを使い ます。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
29. 検索拡張生成しよう。 LangChainのAgentとToolsを定義し ますAgentは、ユーザーの指示を 達成するために「思考→行動→ 観察」を行うロボットのような 機能です。入力テキストの内容 に応じて、適切なToolを選択しま す。 Toolには、nameとdescriptionを指 定します。これにより、Agentは どのToolを使うべきかを判断しま す。指定は英語で行う方が誤作 動が少なく、LLMの精度が上がれ ば改善されるかもしれません。 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
30. 検索拡張生成しよう。 LangChainのAgentとToolsをにより、 検索エンジンから知識会得をし、回答 を得ることができました！ 加 工 ロー ド イン デッ クス 作成 スト ア 非同 期 クエ リ 評 価
31. Appendix
32. 今回のソースコード • https://github.com/engkimo/mlops_webiner_code/blob/main/MLOps_41Times_KNN_RAG_by_Uls ageInc.ipynb
33. ありがとうございました！