Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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
ありがとうございました!