[社内勉強会] Retrieval-Augmented Generation for LLMs A Survey

Transcript

1. Retrieval-Augmented Generation for Large Language Models: A Survey 株式会社inSane 齋藤⼤地 Yunfan Gao1, Yun Xiong2, Xinyu Gao2, Kangxiang Jia2, Jinliu Pan2, Yuxi Bic3, Yi Dai1, Jiawei Sun1, Meng Wang3, and Haofen Wang1,3 (1Shanghai Research Institute for Intelligent Autonomous Systems, Tongji University, 2Shanghai Key Laboratory of Data Science, School of Computer Science, Fudan University, 3College of Design and Innovation, Tongji University) Gao, Yunfan, et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv preprint arXiv:2312.10997 (2023).
2. 概要 2 n RAGは外部DBの情報を取り込むことで以下をはじめとする問題を解決 • ハルシネーション，古い情報，不透明性，推論プロセスの説明性 Ø継続的な知識の更新とドメイン固有の情報の統合が可能に n RAGフレームワークの3つの基盤 • 検索（Retrieval），⽣成（Generation），拡張（Augmentation） n There is no one-size-fits-all answer to “which embedding model to use” • それぞれのユースケースに合ったモデル・⼿法を選択する必要
3. 背景：ハルシネーションに対する解決策としてRAGに注⽬ 3 n LLMはドメイン固有の情報，専⾨的な知識，最新の情報を持っていない • 事実に基づかない情報を⽣成（＝ハルシネーション） n RAG（Retrieval-Augmented Genration） • LLMによるテキスト⽣成＋外部情報の検索 Ø正確でより関連性の⾼い回答を⽣成 Q. LLMの⼊⼒可能token数が増えるとRAGは必要ない？ A. （現時点では）No • コンテキスト⻑が⻑くなるほど、LLMの精度が下がる [Levy+, 24]
4. 背景：ハルシネーションに対する解決策としてRAGに注⽬ 4 n LLMはドメイン固有の情報，専⾨的な知識，最新の情報を持っていない • 事実に基づかない情報を⽣成（＝ハルシネーション） n RAG（Retrieval-Augmented Genration） • LLMによるテキスト⽣成＋外部情報の検索 Ø正確でより関連性の⾼い回答を⽣成 Q. LLMの⼊⼒可能token数が増えるとRAGは必要ない？ A. （現時点では）No • コンテキスト⻑が⻑くなるほど、LLMの精度が下がる [Levy+, 24] • Chain-of-Though (CoT) Prompting [Jason+, NeurIPS22] ü 中間的な推論ステップを介して複雑な推論が可能に ü few-shot promptingと組み合わせるとbetter
5. RAGフレームワーク：Indexing, Retrieval, Generation 5
6. RAGフレームワーク：Indexing, Retrieval, Generation 6 ①Indexing • ドキュメントをアクセス可能な形式にするプロセス (PDF/HTML/Word/Markdown→textへの変換) • chunking (分割)＆embedding (埋め込み)
7. RAGフレームワーク：Indexing, Retrieval, Generation 7 ②Retrieval • userのqueryとchunkとの類似度を 計算し上位K個を取得
8. RAGフレームワーク：Indexing, Retrieval, Generation 8 ②Generation • Queryと選んだdocumentを promptに組み合わせる
9. 検索ソースの最適化 9 n 検索ソースのデータ形式は主に3種類 • Unstructured Data：最も⼀般的な通常のテキスト • Semi-structured Data：textと表を含む (ex. PDF) • text分割のプロセスにおいて表が途中で分割される可能性 • Structured Data：ナレッジグラフのように構造化されたデータ • エンティティ間の関係や属性を利⽤し情報をグラフ上で効率的に検索 • Langchainのサイトでコード公開
10. 検索単位の粒度：関連性とノイズはトレードオフの関係 10 n 検索単位の粒度：token, phrase, sentence, proposition, chunks, document • 粗い検索単位: 理論上関連性の⾼い情報を提供↔冗⻑で検索精度が低下 • 細かい検索単位: ノイズが少ない↔意味的な統合を保証しない n Dense X [Chen+, 23] • 検索単位として，proposition（命題）を提案 • Ex. 「猫が道路を横切ったが，誰も気づかなかった」 ① 猫が道路を横切った ② 猫に誰も気づかなかった • Wikipediaのデータで，propositionによる検索が他の⼿法を上回る結果
11. Indexing：固定サイズchunk以外の⽅法にも注⽬ 11 n Chunking: 主流は固定トークン数による分割 (100, 256, 512) • Small2Big [重要度★] • 検索単位はsmallに，LLMに投げるときは周りの情報も付与してBigに • Sliding window [重要度★] • Overlapを持たせて少しずつズラしていく n メタデータ [重要度★]: ページ数/ファイル名/著者名/カテゴリ/タイムスタンプなど • メタデータによるフィルターを⽤いることで検索範囲を制限できる • Ex. Time-aware RAG：古いデータを避けることが可能
12. Indexing：固定サイズchunk以外の⽅法にも注⽬ 12 n Chunking: 主流は固定トークン数による分割 (100, 256, 512) • Small2Big [重要度★] • 検索単位はsmallに，LLMに投げるときは周りの情報も付与してBigに • Sliding window [重要度★] • Overlapを持たせて少しずつズラしていく n メタデータ [重要度★]: ページ数/ファイル名/著者名/カテゴリ/タイムスタンプなど • メタデータによるフィルターを⽤いることで検索範囲を制限できる • Ex. Time-aware RAG：古いデータを避けることが可能
13. クエリの最適化①: クエリ拡張，クエリ変換 13 n Query拡張 • RAG-Fusion [重要度★★★]: 類似queryを追加しそれらを並列に処理 n Query変換←userのqueryが常にRAGに適しているとは限らない • Rewriting [重要度★★]: LLMによりクエリを最適化 (特にweb検索に有⽤？) • Rewriting⽤のSmall Language Model (SLM)：RRR, BEQUE, GMV • Hypothetical Document Expansion (HyDE) [重要度★★]: • Queryから仮のanswerを⽣成しそれをもとに検索 • Step-back prompting [Zheng+, ICRA24] [重要度★★] • ⼀段抽象化した質問内容(ステップバック質問)を⽣成し， ⼊⼒クエリとステップバック質問それぞれで検索
14. クエリの最適化①: クエリ拡張，クエリ変換 14 n Query拡張 • RAG-Fusion [重要度★★★]: 類似queryを追加しそれらを並列に処理 n Query変換←userのqueryが常にRAGに適しているとは限らない • Rewriting [重要度★★]: LLMによりクエリを最適化 (特にweb検索に有⽤？) • Rewriting⽤のSmall Language Model (SLM)：RRR, BEQUE, GMV • Hypothetical Document Expansion (HyDE) [重要度★★]: • Queryから仮のanswerを⽣成しそれをもとに検索 • Step-back prompting [Zheng+, ICRA24] [重要度★★] • ⼀段抽象化した質問内容(ステップバック質問)を⽣成し， ⼊⼒クエリとステップバック質問それぞれで検索
15. クエリの最適化①: クエリ拡張，クエリ変換 15 n Query拡張 • RAG-Fusion [重要度★★★]: 類似queryを追加しそれらを並列に処理 n Query変換←userのqueryが常にRAGに適しているとは限らない • Rewriting [重要度★★]: LLMによりクエリを最適化 (特にweb検索に有⽤？) • Rewriting⽤のSmall Language Model (SLM)：RRR, BEQUE, GMV • Hypothetical Document Expansion (HyDE) [重要度★★]: • Queryから仮のanswerを⽣成しそれをもとに検索 • Step-back prompting [Zheng+, ICRA24] [重要度★★] • ⼀段抽象化した質問内容(ステップバック質問)を⽣成し， ⼊⼒クエリとステップバック質問それぞれで検索
16. クエリの最適化①: クエリ拡張，クエリ変換 16 n Query拡張 • RAG-Fusion [重要度★★★]: 類似queryを追加しそれらを並列に処理 n Query変換←userのqueryが常にRAGに適しているとは限らない • Rewriting [重要度★★]: LLMによりクエリを最適化 (特にweb検索に有⽤？) • Rewriting⽤のSmall Language Model (SLM)：RRR, BEQUE, GMV • Hypothetical Document Expansion (HyDE) [重要度★★]: • Queryから仮のanswerを⽣成しそれをもとに検索 • Step-back prompting [Zheng+, ICRA24] [重要度★★] • ⼀段抽象化した質問内容(ステップバック質問)を⽣成し， ⼊⼒クエリとステップバック質問それぞれで検索 ⼊⼒クエリ: 美味しいものが⾷べたい Retrieveしたい⽂章: 〜というレストランは，… 本当に類似度だけで検索可能…？ ⼊⼒クエリを拡張し，仮のanswerを作成！ Ex. 「近くに〇〇というレストランがあります」
17. クエリの最適化①: クエリ拡張，クエリ変換 17 n Query拡張 • RAG-Fusion [重要度★★★]: 類似queryを追加しそれらを並列に処理 n Query変換←userのqueryが常にRAGに適しているとは限らない • Rewriting [重要度★★]: LLMによりクエリを最適化 (特にweb検索に有⽤？) • Rewriting⽤のSmall Language Model (SLM)：RRR, BEQUE, GMV • Hypothetical Document Expansion (HyDE) [重要度★★]: • Queryから仮のanswerを⽣成しそれをもとに検索 • Step-back prompting [Zheng+, ICRA24] [重要度★★] • ⼀段抽象化した質問内容(ステップバック質問)を⽣成し， ⼊⼒クエリとステップバック質問それぞれで検索 ⼊⼒クエリ: 理想気体の圧⼒Pについて、 温度が2倍に増加し、体積が8倍に増加し た場合、圧⼒Pはどう変化しますか？ ステップバック質問: この質問の背後にあ る物理学の原理は何ですか？
18. Queryの最適化②: ルーティング 18 n ルーティング (経路設定) [重要度★★] • 複数のデータストアにまたがって検索したい場合に有⽤ • ex. ベクトル検索，Web検索，Relational DB，外部DBを⽤いない…など • ルーティング⽅法 ① Metadata Router • メタデータにより分類（Userによるモード分けもこれに該当） ② Semantic Router (https://github.com/aurelio-labs/semantic-router) • LLMなどを⽤いてクエリの意味を理解し分類
19. Embedding: Hybridサーチにより性能が向上 19 n Hybrid検索: 性質の異なる複数の検索⽅式を組み合わせる [重要度★★★] • 主流: BERTなどのベクトル検索＆BM25などのキーワードベースの検索 • BM25 • ⽂脈や⽂章構造は無視．単語を全てバラバラに分割し，各単語の 出現頻度と⽂書間におけるレア度を考慮した特徴量を算出 n Embeddingモデルのランキング: https://huggingface.co/spaces/mteb/leaderboard text-embedding-3-large by OpenAI
20. Generationにおける最適化 20 n Lost in the middle問題 • LLMはpromptの最初と最後に注⽬しがち (=中間の情報を忘れがち) →検索した情報をきちんと処理してLLMに渡すことが重要 n Reranking [重要度★★★] • 検索で取得したチャンクをクエリとの類似度が⾼い順に並び変え （+上位N個のチャンクのみ使⽤） • Cohereのrerankerモデルを使うのが良さそう • Q. 2度もランク付けするのはなぜか？ • Rerankerモデルは計算コストが⾼く，DB全体に対して適⽤不可 →ベクトル検索である程度絞って，その後精度の⾼いモデルでRerank
21. ここ最近の主流: マルチステップ検索 21 n 従来のRAG: 1回の検索で⼗分な情報を取得するのは困難 n 最近の流れ: 再帰的・反復的に検索を⾏うことで検索性能が向上
22. 反復検索により検索結果を洗練 22 n Iterative/Recursive Retrieval (反復・再起検索) [重要度★★] • 「検索→⽣成→評価」を繰り返すことにより性能向上 • ITERRETGEN [Shao+, EMNLP23] • ⼀つ前の検索結果を活⽤して再度検索 • 反復回数が多いほど性能向上
23. Adaptive Retrieval: LLMが能動的に検索を制御 23 n Adaptive Retrieval (適応型検索) [重要度★★★] • LLMが⾃律的に検索の必要性とタイミングを判断 • Flare [Jiang+, EMNLP23] • ⽣成プロセスの尤度が⼀定の閾値を下回ったときに検索 • Self-RAG [Asai+, ICLR24] ① クエリからLLMが検索の必要性を判断 ② 検索で取得した複数の⽂書を基に， それぞれ回答⽣成 ③ 回答を評価し最も良いものを選択
24. Adaptive Retrieval: LLMが能動的に検索を制御 24 n Adaptive Retrieval (適応型検索) [重要度★★★] • LLMが⾃律的に検索の必要性とタイミングを判断 • Flare [Jiang+, EMNLP23] • ⽣成プロセスの尤度が⼀定の閾値を下回ったときに検索 • Self-RAG [Asai+, ICLR24] ① クエリからLLMが検索の必要性を判断 ② 検索で取得した複数の⽂書を基に， それぞれ回答⽣成 ③ 回答を評価し最も良いものを選択
25. Adaptive Retrieval: LLMが能動的に検索を制御 25 n Adaptive Retrieval (適応型検索) [重要度★★★] • LLMが⾃律的に検索の必要性とタイミングを判断 • Flare [Jiang+, EMNLP23] • ⽣成プロセスの尤度が⼀定の閾値を下回ったときに検索 • Self-RAG [Asai+, ICLR24] ① クエリからLLMが検索の必要性を判断 ② 検索で取得した複数の⽂書を基に， それぞれ回答⽣成 ③ 回答を評価し最も良いものを選択
26. RAG⼿法のsummary 26 n 検索単位・検索回数なども⼿法によって かなり⾊々あるので，⾃分達のタスクに 合った⼿法を選択することが重要
27. 今後の展望: マルチモーダルRAG 27 n クエリを⾔語に限定せず，画像・動画・⾳声のクエリにも対応 • Transform-Retrieve-Generate [Gao+, CVPR22]
28. まとめ 28 n Indexing • Small2Big, Sliding window, メタデータ n クエリ最適化 • RAF-Fusion, Rewriting, HyDE, Step-back-prompting • Metadate Router, Semantic Router • Hybrid検索 n Generation • Reranking n フレームワーク • Iterative Retrieval, Recursive Retrieval, Adaptive Retrieval
29. 今回省略した内容 29 n RAG評価のためのベンチマーク・データセット • RAGの性能を評価するためのデータセットは無数にあるので活⽤したい n ModelのFine-tuning • RAGでは，LLMにより⾃動でデータを作成可能なので，他のタスクほどfine- tuningは難しくないかも • ただし，over-fittingしてしまう可能性があるため注意 • 今後chatbotでuserのクエリデータが集まればそれを元にfine-tuningしてみたい