Slide 1

Slide 1 text

ビッグデータにおけるRAG性能向上戦略 株式会社ulusage 大堀遼介

Slide 2

Slide 2 text

自己紹介 • 大堀 遼介 • Webアプリエンジニア • データサイエンティスト • 経歴概要 • 理工学部 情報理工学科卒 • 経歴紹介 • バックエンド中心の開発( KADOKAWA ) • エンタープライズ向けシステム統合コンサルティング • データパイプライン基盤(TOYOTA, HONDA, ベルフェイス) • コンシューマ向けデータプロバイダー(MaaS関連企業) • 小売・メーカー向け、AIアプリケーション開発(某大手宅配) • データエンジニア、データサイエンティスト(ABEJA, GRID, DATAFLUCT ...etc) • 株式会社ulusage CEO • ミッション: MLDashBoardのSaaSの提供・DX支援・直近では生成AIプ ロダクトをローンチしました。http://PragIn-AI.com

Slide 3

Slide 3 text

RAGおさらい RAGとは? 検索拡張生成 (RAG: Retrieval Augmented Generation) は、検索ベースの技術と 生成ベースのAIモデルを統合することで機能。検索ベースのモデルは、新聞記事、 データベース、ブログ、Wikipediaや社内データベースといったその他ナレッジ リポジトリなど、既存のオンラインソースから情報を抽出し、LLMが学習してい ない知識を付加して、関連した情報を生成させる技術です。

Slide 4

Slide 4 text

RAGおさらい 構成としてはよく見るデザインパターンは以下のようなものが一般的。 LLM User RDB NoSQL..etc 非構造化 データ 構造化 データ ベクトルDB Web API 加工

Slide 5

Slide 5 text

GTPsやAssistantsなどで、OpenAIでもRAGが簡単に実装が可能です。 OpenAIの管理画面から、データをアップロードし、チャットを開始することが 素早くできます。 OpenAIでの、RAG ◻◻◻◻◻◻のデータ で〜教えて? このデータに基 づいて〜です 独自データ LLM 自社データ

Slide 6

Slide 6 text

RAGを実現するOSSライブラリ OpenAIではなく、その他のLLMモデルや独自にRAGシステムの構築をする場合、 多くは次のような、langchainやlangchain-hub、llama-index、LangRoidなどのラ イブラリを利用することになります。近頃はAutoGPTやDifyなどのツールが増え、 RAG構築に対するハードルは落ちてきたと思います。 これらのライブラリでもユースケースを満たせないケースも多々あります。

Slide 7

Slide 7 text

ビックデータへのRAGの課題 RAGは学習していないデータに対してLLMに知識を付加するのに非常に有効です が、特に、データボリュームが多くなるほど、劇的に性能低下、ハルシネーショ ンが増加してきます。さらにLangChainやLlama-Indexであっても、導入に対する の技術的障壁、性能の壁が存在します。

Slide 8

Slide 8 text

前述のとおり、データの種類や、データのボリュームで、性能(レスポンス速 度)と、精度(出力の信憑性)のバランスを取るのが困難です。 RAGは、性能と精度のバランスを取ることが重要 性能 精度

Slide 9

Slide 9 text

ビッグデータへのRAGアプローチ キーワードは、「インデックス」と「チャンク」! インデックスとチャンクと聞くと、RDBや分散システムを思い浮かべる人も多い と思います。なにやら当たり前の響きですが。。特に重要なのはインデックスで す。 キーワード 概要 インデックス 目的のレコードを効率よく取得するための「索引」 チャンク データを分割して制御情報を付加したひとまとまりの断片

Slide 10

Slide 10 text

ビッグデータへのRAGアプローチ ※インデックスとチャンクのイメージ チャンク インデックス LLM

Slide 11

Slide 11 text

ビッグデータへのRAGアプローチ つまりは、インデックスを効率的に作成することが重要! 効果的な、インデックスの例 ● BM25 ● ベクトルインデックス ● ハイブリッド ● …など

Slide 12

Slide 12 text

ビッグデータへのRAGアプローチ ● BM25 ○ テキスト検索において広く使用されるスコアリング。ドキュメントの関連性を計算し、検索結 果をランキング ● ベクトルインデックス ○ 類似性検索(画像検索や埋め込みベクトルの検索)に使用される手法。FAISS(Facebook AI Similarity Search)やChromaなどが人気。 ● ハイブリッド ○ BM25のような伝統的なインデックスと、ベクトルインデックスを組み合わせる手法。キーワー ド検索と意味(セマンティクス)的な類似検索の両方を使用可。 ● …など これらのインデックス手法を実現するには?

Slide 13

Slide 13 text

ビッグデータへの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..

Slide 14

Slide 14 text

ビッグデータへのRAGアプローチ それってRAGのアーキティクチャにおいては当たり前では? このアーキティクチャがポイントです! いくつか、紹介していきたいと思います。

Slide 15

Slide 15 text

ビッグデータのRAGプロセス その前に、以下のプロセスを見てください。 一般的なRAGシステムのプロセスです。 加工 ロード インデッ クス作成 ストア クエリ 評価

Slide 16

Slide 16 text

ビッグデータのRAGプロセス このプロセスを、データのロードとクエリを切り離せたら、性能はそれだけでも 向上します。 加工 ロード インデッ クス作成 ストア 非同期 クエリ 評価

Slide 17

Slide 17 text

ビッグデータの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..

Slide 18

Slide 18 text

ビッグデータのRAGデザインパターン① 多段インデックスのメリット・デメリット メリット ● とにかく速い ● コストも安い ● 小さなチャンクに対してのLLM理解が深め デメリット ● 全体のデータを俯瞰できない。 ● 構築の工数がかかる

Slide 19

Slide 19 text

ビッグデータのRAGデザインパターン② クエリ拡張 検索 ベクトルDB 拡張検索 プロンプト 検索検索が多段に並列実行

Slide 20

Slide 20 text

ビッグデータのRAGデザインパターン② ● 拡張検索(クエリ) ○ LLM(大規模言語モデル)を使用して、最初のクエリに基づいて複数のクエリを生成します。 生成されたクエリには、最初のクエリの複数の視点が含まれている必要があります。 ○ 埋め込み空間のカバレッジ: ■ これらのクエリは、埋め込まれると、埋め込み空間のさまざまな領域にヒットします。 ■ それらのクエリは依然として最初の質問に関連しているため、より広範な関連情報を取得 できます。 ○ ゼロショットプロンプト: ■ クエリ拡張を行うために、詳細なゼロショットプロンプトを使用します。 ■ ゼロショットプロンプトを用いることで、特定のトレーニングを経ずに、初めてのクエリ に対しても拡張が可能となります。

Slide 21

Slide 21 text

ビッグデータのRAGデザインパターン② クエリ拡張 抽象的なPydanticモデルを定 義する: プロンプトをカプセル化 するために使用 クエリ拡張プロンプトを定義する •プロンプトをLangChainの PromptTemplateクラスでラッ プする

Slide 22

Slide 22 text

ビッグデータのRAGデザインパターン② 拡張のメリット・デメリット メリット • 複数の視点を取り入れることで、埋め込み空間のより広い範囲をカバーし、 関連情報の取得が向上できる。カバレッジ • 拡張されたクエリにより、取得されたコンテキストの関連性が高上 デメリット ● レスポンスが遅め ● 実装難易度高め(並列処理など)

Slide 23

Slide 23 text

ビッグデータのRAGデザインパターン③ ● 無関係なチャンクの取得: ○ ビックデータだと、取得されたコンテキストに無関係なチャンクが含まれることがあり、ノイ ズが追加される可能性があります。 ○ プロンプトが大きくなるとコストが増し、LLMは通常コンテキストの最初と最後の部分のみを 見る傾向があるため、本質的な情報を見逃す可能性があります。 ○ 埋め込みモデルが特定の質問に合わせて調整されていないため、質問に100%関連しない高い類 似性スコアが生成される可能性があります。

Slide 24

Slide 24 text

ビッグデータのRAGデザインパターン③ 取得後の最適化 - Rerank 2 4 3 6 5 1 ベクトルDB 1 2 3 4 5 6 クエリ拡張 プロンプト Rerank 結果 結果 出力

Slide 25

Slide 25 text

ビッグデータのRAGデザインパターン③ Rerank •Rerankプロンプトテンプレー ト Rerankする質問とチャンクを渡 す •プロンプトテンプレートとGPT-4 を使用してチェインを構築する PromptTemplateを作成す る •チェインを呼び出し、レスポンス を返す

Slide 26

Slide 26 text

ビッグデータのRAGデザインパターン③ Rerankにて、リトリーバに出力させる •取得されたチャンク(「ヒット」)のリストを 引数に取得 •ヒットを単一の文字列に連結する •Rerankチェインを呼び出す

Slide 27

Slide 27 text

ビッグデータのRAGデザインパターン② Rerankのメリット・デメリット メリット ● ノイズの除去 ● 精度の向上 ● 情報の提供の多様化 デメリット ● レスポンスが遅め ○ 計算コストの増加 ● 実装難易度高め

Slide 28

Slide 28 text

まとめ ● OpenAIのツールを利用すれば、RAGの実装が簡単。 ● データ量増加に伴う性能低下とハルシネーションの増加。 ● 性能と精度のバランスが困難。 ○ ビッグデータに対するRAGのアプローチは、性能と精度のバランスを取ることが重要。 ● 効果的なインデックス作成とデザインパターンの選択がカギ。 ● ベクトル検索エンジンの選定も慎重に HyDEという手法もあり、こちらは試したことないですが、時間あったら実践して みたいです。

Slide 29

Slide 29 text

参考文献 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

Slide 30

Slide 30 text

ありがとうございました!