ビックデータにおける、RAG性能向上戦略

自己紹介
大堀遼介：Webアプリエンジニア、データサイエンティスト
経歴：KADOKAWA、TOYOTA、HONDA、ABEJAなどでデータパイプラインやAIアプリ開発に従事
株式会社ulusage CEO：MLDashboardのSaaS提供、生成AIプロダクトのローンチ
RAGおさらい
RAG（検索拡張生成）：検索ベースの技術と生成ベースのAIモデルを統合し、LLMが学習していない知識を付加
構成要素：LLM、RDB、NoSQL、非構造化データ、ベクトルDB、Web API
RAGを実現するOSSライブラリ
代表的なライブラリ：langchain、llama-index、AutoGPT、Dify
ビッグデータへのRAGの課題
性能低下とハルシネーションの増加：データボリュームが大きくなるほど性能低下が顕著
性能と精度のバランス：レスポンス速度と出力の信憑性の調整が難しい
ビッグデータへのRAGアプローチ
キーワード：「インデックス」と「チャンク」
効果的なインデックス作成：BM25、ベクトルインデックス、ハイブリッド
ベクトル検索エンジン：Elastic Search、Apache Solr、FAISS、Chroma、Pinecone、Qdrant
ビッグデータのRAGデザインパターン
多段インデックス：高速かつコストが安いが、データの全体俯瞰が難しい
クエリ拡張：複数の視点からの検索が可能だが、レスポンスが遅く、実装難易度が高い
Rerank：ノイズの除去と精度向上が可能だが、レスポンスが遅く、計算コストが高い
まとめ
OpenAIのツールでRAG実装が容易
性能低下とハルシネーションへの対策が必要
インデックス作成とデザインパターン選択が重要
ベクトル検索エンジンの選定も慎重に
参考文献
複数のQiita記事で詳細な実装例や理論を紹介

Transcript

1. ビッグデータにおけるRAG性能向上戦略 株式会社ulusage 大堀遼介
2. 自己紹介 • 大堀 遼介 • Webアプリエンジニア • データサイエンティスト • 経歴概要 • 理工学部 情報理工学科卒 • 経歴紹介 • バックエンド中心の開発（ KADOKAWA ） • エンタープライズ向けシステム統合コンサルティング • データパイプライン基盤（TOYOTA, HONDA, ベルフェイス） • コンシューマ向けデータプロバイダー（MaaS関連企業） • 小売・メーカー向け、AIアプリケーション開発（某大手宅配） • データエンジニア、データサイエンティスト（ABEJA, GRID, DATAFLUCT ...etc） • 株式会社ulusage CEO • ミッション: MLDashBoardのSaaSの提供・DX支援・直近では生成AIプ ロダクトをローンチしました。http://PragIn-AI.com
3. RAGおさらい RAGとは？ 検索拡張生成 (RAG: Retrieval Augmented Generation) は、検索ベースの技術と 生成ベースのAIモデルを統合することで機能。検索ベースのモデルは、新聞記事、 データベース、ブログ、Wikipediaや社内データベースといったその他ナレッジ リポジトリなど、既存のオンラインソースから情報を抽出し、LLMが学習してい ない知識を付加して、関連した情報を生成させる技術です。
4. RAGおさらい 構成としてはよく見るデザインパターンは以下のようなものが一般的。 LLM User RDB NoSQL..etc 非構造化 データ 構造化 データ ベクトルDB Web API 加工
5. GTPsやAssistantsなどで、OpenAIでもRAGが簡単に実装が可能です。 OpenAIの管理画面から、データをアップロードし、チャットを開始することが 素早くできます。 OpenAIでの、RAG ◻◻◻◻◻◻のデータ で〜教えて？ このデータに基 づいて〜です 独自データ LLM 自社データ
6. RAGを実現するOSSライブラリ OpenAIではなく、その他のLLMモデルや独自にRAGシステムの構築をする場合、 多くは次のような、langchainやlangchain-hub、llama-index、LangRoidなどのラ イブラリを利用することになります。近頃はAutoGPTやDifyなどのツールが増え、 RAG構築に対するハードルは落ちてきたと思います。 これらのライブラリでもユースケースを満たせないケースも多々あります。
7. ビックデータへのRAGの課題 RAGは学習していないデータに対してLLMに知識を付加するのに非常に有効です が、特に、データボリュームが多くなるほど、劇的に性能低下、ハルシネーショ ンが増加してきます。さらにLangChainやLlama-Indexであっても、導入に対する の技術的障壁、性能の壁が存在します。
8. 前述のとおり、データの種類や、データのボリュームで、性能（レスポンス速 度）と、精度（出力の信憑性）のバランスを取るのが困難です。 RAGは、性能と精度のバランスを取ることが重要 性能 精度
9. ビッグデータへのRAGアプローチ キーワードは、「インデックス」と「チャンク」！ インデックスとチャンクと聞くと、RDBや分散システムを思い浮かべる人も多い と思います。なにやら当たり前の響きですが。。特に重要なのはインデックスで す。 キーワード 概要 インデックス 目的のレコードを効率よく取得するための「索引」 チャンク データを分割して制御情報を付加したひとまとまりの断片
10. ビッグデータへのRAGアプローチ ※インデックスとチャンクのイメージ チャンク インデックス LLM
11. ビッグデータへのRAGアプローチ つまりは、インデックスを効率的に作成することが重要！ 効果的な、インデックスの例 • BM25 • ベクトルインデックス • ハイブリッド • …など
12. ビッグデータへのRAGアプローチ • BM25 ◦ テキスト検索において広く使用されるスコアリング。ドキュメントの関連性を計算し、検索結 果をランキング • ベクトルインデックス ◦ 類似性検索（画像検索や埋め込みベクトルの検索）に使用される手法。FAISS（Facebook AI Similarity Search）やChromaなどが人気。 • ハイブリッド ◦ BM25のような伝統的なインデックスと、ベクトルインデックスを組み合わせる手法。キーワー ド検索と意味（セマンティクス）的な類似検索の両方を使用可。 • …など これらのインデックス手法を実現するには？
13. ビッグデータへのRAGアプローチ ベクトル検索エンジン！ • Elastic Search • Apache Solr • FAISS • Chroma • Pinecone • Qdrant • …まだまだあります。 ◦ https://note.com/ippei_suzuki_us/n/nf43f9622eee9 右図のように、検索とベクトルDBが、基本的に検索エンジン内に内包されます。 検索 ベクトルDB xxxxxx xxxxxx xxxxxx xxxxxx チャンク & ベクトル埋め込み ドキュメント 0.1,0.3, -0.1.. 0.4,0.2, 0.6..
14. ビッグデータへのRAGアプローチ それってRAGのアーキティクチャにおいては当たり前では？ このアーキティクチャがポイントです！ いくつか、紹介していきたいと思います。
15. ビッグデータのRAGプロセス その前に、以下のプロセスを見てください。 一般的なRAGシステムのプロセスです。 加工 ロード インデッ クス作成 ストア クエリ 評価
16. ビッグデータのRAGプロセス このプロセスを、データのロードとクエリを切り離せたら、性能はそれだけでも 向上します。 加工 ロード インデッ クス作成 ストア 非同期 クエリ 評価
17. ビッグデータのRAGデザインパターン① チャンク インデックス 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..
18. ビッグデータのRAGデザインパターン① 多段インデックスのメリット・デメリット メリット • とにかく速い • コストも安い • 小さなチャンクに対してのLLM理解が深め デメリット • 全体のデータを俯瞰できない。 • 構築の工数がかかる
19. ビッグデータのRAGデザインパターン② クエリ拡張 検索 ベクトルDB 拡張検索 プロンプト 検索検索が多段に並列実行
20. ビッグデータのRAGデザインパターン② • 拡張検索（クエリ） ◦ LLM（大規模言語モデル）を使用して、最初のクエリに基づいて複数のクエリを生成します。 生成されたクエリには、最初のクエリの複数の視点が含まれている必要があります。 ◦ 埋め込み空間のカバレッジ: ▪ これらのクエリは、埋め込まれると、埋め込み空間のさまざまな領域にヒットします。 ▪ それらのクエリは依然として最初の質問に関連しているため、より広範な関連情報を取得 できます。 ◦ ゼロショットプロンプト: ▪ クエリ拡張を行うために、詳細なゼロショットプロンプトを使用します。 ▪ ゼロショットプロンプトを用いることで、特定のトレーニングを経ずに、初めてのクエリ に対しても拡張が可能となります。
21. ビッグデータのRAGデザインパターン② クエリ拡張 抽象的なPydanticモデルを定 義する: プロンプトをカプセル化 するために使用 クエリ拡張プロンプトを定義する •プロンプトをLangChainの PromptTemplateクラスでラッ プする
22. ビッグデータのRAGデザインパターン② 拡張のメリット・デメリット メリット • 複数の視点を取り入れることで、埋め込み空間のより広い範囲をカバーし、 関連情報の取得が向上できる。カバレッジ • 拡張されたクエリにより、取得されたコンテキストの関連性が高上 デメリット • レスポンスが遅め • 実装難易度高め（並列処理など）
23. ビッグデータのRAGデザインパターン③ • 無関係なチャンクの取得: ◦ ビックデータだと、取得されたコンテキストに無関係なチャンクが含まれることがあり、ノイ ズが追加される可能性があります。 ◦ プロンプトが大きくなるとコストが増し、LLMは通常コンテキストの最初と最後の部分のみを 見る傾向があるため、本質的な情報を見逃す可能性があります。 ◦ 埋め込みモデルが特定の質問に合わせて調整されていないため、質問に100%関連しない高い類 似性スコアが生成される可能性があります。
24. ビッグデータのRAGデザインパターン③ 取得後の最適化 - Rerank 2 4 3 6 5 1 ベクトルDB １ ２ 3 ４ 5 ６ クエリ拡張 プロンプト Rerank 結果 結果 出力
25. ビッグデータのRAGデザインパターン③ Rerank •Rerankプロンプトテンプレー ト Rerankする質問とチャンクを渡 す •プロンプトテンプレートとGPT-4 を使用してチェインを構築する PromptTemplateを作成す る •チェインを呼び出し、レスポンス を返す
26. ビッグデータのRAGデザインパターン③ Rerankにて、リトリーバに出力させる •取得されたチャンク（「ヒット」）のリストを 引数に取得 •ヒットを単一の文字列に連結する •Rerankチェインを呼び出す
27. ビッグデータのRAGデザインパターン② Rerankのメリット・デメリット メリット • ノイズの除去 • 精度の向上 • 情報の提供の多様化 デメリット • レスポンスが遅め ◦ 計算コストの増加 • 実装難易度高め
28. まとめ • OpenAIのツールを利用すれば、RAGの実装が簡単。 • データ量増加に伴う性能低下とハルシネーションの増加。 • 性能と精度のバランスが困難。 ◦ ビッグデータに対するRAGのアプローチは、性能と精度のバランスを取ることが重要。 • 効果的なインデックス作成とデザインパターンの選択がカギ。 • ベクトル検索エンジンの選定も慎重に HyDEという手法もあり、こちらは試したことないですが、時間あったら実践して みたいです。
29. 参考文献 RAG • https://qiita.com/yk__/items/d466698be59a16d75a49 • https://qiita.com/xxyc/items/9f05241e5add3b005b91 • https://qiita.com/ps010/items/cdb75f3cad5c97f85de8#%E4%BB%8A%E5%9B %9E%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%8B%E3%81%A3%E3%81% 9F%E3%81%93%E3%81%A8 • https://qiita.com/isanakamishiro2/items/ee08de16906fd90a6589
30. ありがとうございました！