論文紹介 ”Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG”

https://genai-users.connpass.com/event/341391/

大規模言語モデル（LLM）は、外部の知識源を利用することで、より強力な応答を生成できるようになります（これをRetrieval-Augmented Generation: RAGと呼びます）。LLMが処理できる入力テキストの長さが長くなるにつれて、より多くの関連情報をRAGで与えられるようになり、生成される回答の質が向上することが期待されます。一般的には、取得する情報が多いほど関連情報（高い再現率）も増え、結果として性能が向上すると考えられます。

しかし、長文処理LLMにおけるRAGの性能が、取得する情報が増えすぎると逆に低下する現象を明らかにし、その原因が「ハードネガティブ」な情報にあることを示しました。そして、その問題を解決するために、効果的な学習不要および学習を伴うアプローチを提案しています。

Transcript

1. 論文紹介 ”Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG” @日本生成AIユーザ会 Copyright © 3-shake, Inc. All Rights Reserved. 2025年01月21日 株式会社スリーシェイク 小渕 周 Shu Kobuchi 1
2. 自己紹介 • 小渕 周（Shu Kobuchi）こぶシュー • https://x.com/shu_kob @shu_kob • システムエンジニア → ブロックチェーン業界 • 2023年12月スリーシェイク入社 ◦ Sreake 事業部 ◦ アプリケーション開発支援チーム エンジニア ◦ 生成 AI アプリケーション開発等 ◦ Gemini、Google Cloudを使用 ◦ 2025年1月 マネージャー 2
3. 会社概要 Copyright © 3-shake, Inc. All Rights Reserved. 3
4. 会社情報 会社名 株式会社スリーシェイク 設立日 2015/1/15 Mission: インフラをシンプルにして イノベーションが起こりやすい世界を作る Vision: 労苦〈Toil〉を無くすサービスを適正な価格で提供し続ける Value: エンジニアリングレイヤーに横たわる人、手法、ツールが サイロ化されて労苦が発生しているプロセスをシンプルにし サービス機能開発に集中できるソリューション （SRE、DevSecOps、DataOps、HROps）を提供する 2015 2016 2017 2018 2019 2020 2021 2022 0 50 100 従業員: 200名over Engineer 60% 所在地 東京都新宿区大京町22-1 グランファースト新宿御苑3F・4F　 代表者 代表取締役社長　吉田 拓真 Google Cloud、AWSの両方に強みを持ち SREを軸にご支援 4
5. SREを主軸にクラウドネイティブ化/エンジニアリング内製化を支援 SRE/DevOps SecOps BizOps HR ・SRE総合支援からセキュリティ対 策を全方位支援 ・生成AIの活用支援 ・ワンストップで脆弱性診断を行う セキュリティ対策SaaS ・クラウド型ETL/データパイプ ラインSaaSの決定版 ・あらゆるSaaSをノーコードで連携 ・ハイスキルフリーランスエンジニ ア紹介エージェント IT内製化 / 高度化 クラウドネイティブ化 モダナイゼーション ITアジリティ向上 5
6. Sreakeのご紹介 Copyright © 3-shake, Inc. All Rights Reserved. 6
7. Sreakeの概要 1. SREの考え方を軸にした全方位型のご支援 クラウドネイティブインフラ・セキュリティ支援 クラウドネイティブアプリケーション開発支援 生成AIアプリケーション開発構築支援 ・コンテナ化、コンテナ運用ご支援 　（Kubernetesに強み） ・CI/CD環境構築支援 ・クラウドセキュリティ設計・運用支援 ・Observability設計・運用支援 データモダナイゼーション支援 ・コンテナ化対応などクラウドネイティブ対応に関す るアプリケーション開発のご支援 ・アプリケーションモダナイゼーション支援 ・バックエンド開発支援（Go, Python, TypeScript） ・フロントエンド開発支援（Vue, React） ・Big Query/Dataplex データ基盤構築支援 ・BI（Looker）構築をフルスタックで支援 ・Snowflakeメインのデータ基盤構築支援 ・DBRE支援（Spanner/AlloyDB） ・NewSQL（TiDB, YugabyteDB）支援 ・生成AIアプリ開発運用支援 ・社内情報検索のためのデータ設定支援 ・SREの考え方を元に開発後の運用支援 ・内製化のための生成AIワークショップ／ハンズ オン開催 • 高度な技術力と幅広い領域の経験を持つエンジニアが多数在籍しており、伴走型でお客様に最適なクラウドネイティブ対応の ご支援を行います。 • インフラ・アプリケーション・セキュリティなど含め全方位型で対応可能です。 SREの考え方を元に運用まで見据えたご支援を行います。 7
8. Sreakeの概要 3. 高度な技術力と自走できるメンバー • 生成AIやクラウドネイティブ技術は変化が激しく常に最新の技術領域に対して習得が必要です。Sreakeのエンジニアはこれら最新の 技術領域に対するインプットとアウトプットを高速で行いながら、お客様のニーズに対して最適な提案ができるように取り組んでい ます。 <弊社で監訳した書籍> <最新技術の調査・検証結果のアウトプット> <各分野の有識者によるアウトプット> • 弊社メンバーが自走しながらお客様に対して提案型でのご支援をさせて頂いております。 • 技術のみであれば業務委託などのご支援で良いケースもありますが、提案型でのご支援という点もお客様の評価を頂いております。 8
9. 背景知識 Copyright © 3-shake, Inc. All Rights Reserved. 9
10. RAG (Retrieval Augmented Generation) • LLM (Large Language Model：大規模言語モデル)が知らない情報を外部から与えてあげて拡張 する手法 • 生成AI PoCの第一歩になることが多い - 質問に関連する情報をプロンプトに含める - 情報をベクトル化して蓄えておく Gemini Agent Builder Cloud Storage など Vertex AI ベクトル化 社内情報など ベクトル検索で より欲しい情報にアクセスでき るように 質問 回答 10
11. グラフイメージ 11 性能 検索された文章数 文量がある程度多くなると、 「ハードネガティブ」 が原因で性能低下
12. Hard Negatives（ハードネガティブ） • モデルが誤って正例と判断しやすい負例 ◦ 正例と非常に似ているため、モデルが誤って分類しやすいデータ 例1：感情分析 • 正例: 「この映画は最高だった！」 • ハードネガティブ: 「この映画は最高だったけど、結末が少し残念だった。」 ◦ このハードネガティブは、全体的には肯定的な意見ですが、否定的な要素も含まれており、 モデルが誤ってポジティブと判断してしまう可能性があります。 例2：質問応答 • 質問: 「東京のタワーは何？」 • 正解: 「東京タワーです。」 • ハードネガティブ: 「東京の塔はスカイツリーもあります。」 ◦ このハードネガティブは、質問に対する答えとは異なる情報を含んでいますが、質問と文脈 的に関連しており、モデルが誤って正解と判断してしまう可能性があります。 12
13. Hard Negatives（ハードネガティブ） 例3：スパムメール分類 • スパム: 「【緊急】あなたのアカウントが停止されます。今すぐこちらをクリック！」 • ハードネガティブ: 「【お知らせ】お客様のアカウントのセキュリティ強化のため、パスワードの 変更をお願いいたします。」 ◦ このハードネガティブは、スパムメールと似たような文言やフォーマットを使用しており、 モデルが誤ってスパムと判断してしまう可能性があります。 なぜハードネガティブが重要なのか？ • モデルの性能向上: ハードネガティブを学習データに含めることで、モデルはより複雑なパターン を学習し、正例と負例をより正確に区別できるようになります。 • 過学習の防止: ハードネガティブを適切に扱うことで、モデルが特定のデータに過度に適合してし まう（過学習）のを防ぐことができます。 13
14. Generalization（汎化） • 簡単に言うと、「学習した知識を、未知の状況にも応用できる力」 • 例えば、 ◦ 学習データで「猫はかわいい」と学習したモデルが、「犬はかわいい」という新しい文に対 しても、「かわいい」という感情を正しく理解可能 ◦ 学習データで「東京」という地名に関する情報を学習したモデルが、「大阪」という新しい 地名に関しても、場所に関する情報を推測可能 • このような能力が generalization （汎化） • なぜ重要なのか？ ◦ 現実世界は多様で、学習データに含まれる情報だけではカバーしきれないため ◦ モデルが現実世界の様々な状況に対応できるよう、汎化能力は不可欠 14
15. Retriever（検索器） • Retrieverの役割 ◦ 生成AIは、与えられた情報をもとに文章を生成。Retrieverは、この生成AIに渡す情報を、 膨大なデータの中から探し出す役割を担当。例えば、あなたが「最近のAI技術について教え て」と質問した場合、Retrieverは、この質問に関連する最新の論文やニュース記事などを 探し出し、生成AIに提供。 • Retrieverの仕組み ◦ Retrieverは、様々な方法で情報を検索 ◦ キーワード検索: 質問文に含まれるキーワードと、データベース内の文章を照合し、一致す るものを検索 ◦ ベクトル検索: 文章を数値ベクトルに変換し、質問文のベクトルと最も近いベクトルを持つ 文章を検索 ◦ ニューラルネットワーク: 深層学習を用いて、質問文と文章の類似度を計算し、関連性の高 い文章を検索 15
16. 長文コンテキストLLMとRAG： RAGにおける長文入力の課題克服 Copyright © 3-shake, Inc. All Rights Reserved. 16
17. 要旨 • RAG (Retrieval-Augmented Generation) の重要性: ◦ LLMが外部知識を利用する重要性 ◦ 知識集約型タスクでのLLMの精度向上 ◦ 事実誤認やハルシネーションの軽減 • 本研究のモチベーション: ◦ LLMのコンテキスト長が拡大する中で、RAGシステムを最適に設計する方法が未開拓 ◦ 長いコンテキストを持つLLMを効果的に使用するためには、標準的なRAG設計の再評価が必 要 • 本研究の目的: ◦ 長いコンテキストを持つLLMをRAGシステムで活用する際の課題を特定 ◦ これらの課題に対処するための新しいアプローチを提案 17
18. 1. はじめに • 背景: ◦ RAG (Retrieval-Augmented Generation) の重要性：外部知識を利用してLLMの性能向上 ◦ 長文脈LLMの登場：より多くの情報を処理できる可能性 • 研究の動機: ◦ 直感的な期待：より多くの情報を取得すればRAGの性能が向上するはず ◦ しかし、実際にはそうではないことが判明 ◦ 長文脈LLMにおけるRAGの最適設計に関する未解明な課題 • 研究の目的: ◦ 長文脈LLMにおけるRAGの課題を体系的に分析 ◦ 効果的な解決策を提案し、実証する 18
19. 2. 関連研究 • 既存のRAGシステム: ◦ RetrieverとGenerator（生成AIモデル）の独立した改善 ◦ ハードネガティブに関する研究は少ない • 長コンテキストLLMの研究: ◦ 長コンテキストLLMのベンチマークは、現実のRAGシナリオを反映していない ◦ マルチドキュメント設定では、単一の「正解」ドキュメントとランダムなネガティブを仮定 する傾向 • 本研究の差別化: ◦ RAGにおける長コンテキストLLMの利点と最適化に焦点を当てる ◦ 長いコンテキストを活用したRAGの最適化に関するギャップを埋める 19
20. 3. 長いコンテキストLLMにおけるRAGの課題 • 3.1. コンテキストサイズの影響: ◦ 長いコンテキストが常にパフォーマンス向上につながらないことを示す ◦ 検索されたパッセージ数が増えるにつれてパフォーマンスが低下する「逆U字型」パターン ◦ 強力なretrieverを使用すると、パフォーマンスの低下がより顕著になる 20
21. 3. 長いコンテキストLLMにおけるRAGの課題 • 3.2. Retrieval品質とLLM能力の相互作用: ◦ Recall（関連文書の網羅率）は向上するが、Precision（関連文書の精度）は低下する ◦ 関連文書が含まれていても、LLMが正しい答えを生成できないことがある ◦ 強力なretriever（e5）による「ハードネガティブ」は、弱いretriever（BM25）よりも有 害な場合がある 21
22. 3. 長いコンテキストLLMにおけるRAGの課題 • 3.3. ハードネガティブの重要性: ◦ ハードネガティブとは、関連性が低くLLMを混乱させる可能性のある文書 ◦ 長いコンテキストRAGでは、ハードネガティブが性能に悪影響を与える ◦ 現状のベンチマークは、ハードネガティブを適切に捉えられていない可能性がある ◦ Retrieverの強度がハードネガティブの難易度に影響する ◦ ランダムネガティブは現実世界のRAGを反映していない ▪ ランダムネガティブとは、正の例（正しい答えや関連性の高いデータ）に対してランダ ムに選択された負の例（間違った答えや関連性の低いデータ）のことを指す 22
23. 4. シンプルで効果的な訓練不要のRAG改善 • Retrieval Reordering (検索結果並び替え): ◦ 長コンテキストLLMにおける "Lost-in-the-middle" 現象を利用 ◦ 関連スコアの高いドキュメントを最初と最後に配置 ◦ ハードネガティブの影響を軽減する ◦ 実験的に、大きな検索セットで、Retrieval Reorderingがパフォーマンスを向上させること を実証 ◦ 位置情報の操作が有効であることを示す 23
24. 4. シンプルで効果的な訓練不要のRAG改善 • 24
25. 5. データ拡張型Fine-tuningによるロバスト性の向上 • 5.1. ファインチューニングによるLLMのロバスト性（外乱に強い）の暗黙的な向上: ◦ ハードネガティブに対するLLMのロバスト性を暗黙的に向上させる ◦ RAGに特化したデータでLLMをFine-tuning（再学習）する ◦ 複数のRetrievalコンテキストを提示し、ノイズ下での関連情報の識別能力を向上させる ◦ 実験結果： ▪ RAG FT (Fine-tuning) は、RetrievalありのチャットモデルやSFTを上回る ▪ RAG FTのカーブはより平坦で、ハードネガティブに強いことを示す ▪ RAG FTは知識抽出能力も向上させる ◦ ※ 暗黙的なファインチューニングとは、直接的に教え込まなくても、学習を通じて獲得され る知識や能力のこと。 RAGにおいては、モデルが大量のデータとRAGによる情報検索を通じて、暗黙的に知識を獲 得し、より自然な文章生成を可能に。 25
26. 5. データ拡張型Fine-tuningによるロバスト性の向上 • 26
27. 5. データ拡張型Fine-tuningによるロバスト性の向上 • 5.2. 推論拡張による関連性識別の強化: ◦ 中間推論ステップを追加して、関連文書の識別を明示的に教える ◦ 推論ステップを最初に生成させ、関連文書の識別の構造化されたアプローチを導入 ◦ 実験結果: ▪ 中間推論を取り入れたRAG FTが、暗黙的なRAG FTを上回る ▪ 明示的な関連性トレーニングが、ノイズから重要な情報を識別するLLMの能力を向上さ せる ▪ 構造化された推論が理解を深め、パフォーマンスを向上させる 27
28. 5. データ拡張型Fine-tuningによるロバスト性の向上 • 28
29. 5. データ拡張型Fine-tuningによるロバスト性の向上 • 29
30. 6. Fine-tuningにおけるデータ中心の視点 • データ分布の影響: ◦ 多様なトレーニングデータが、汎化能力を向上させる • Retrieversの選択の影響: ◦ 異なるretrieverからのデータでFine-tuningすると、未知のretrieverに対する汎化能力が 向上する ◦ 特定のretrieverで訓練されたモデルは、類似したretrieverでより汎化する ◦ 「ハードネガティブ」の特徴はretrieverによって異なる • 訓練コンテキスト長の影響: ◦ 最大コンテキスト長でFine-tuningすると、さまざまなRetrievalサイズで最適なパフォーマ ンスが得られる ◦ LLMが様々な量の情報を効果的に処理できるようにする 30
31. 7. 結論 • 主な結論: ◦ 長文脈LLMにおいて、検索結果の増加が必ずしも性能向上に繋がらない ◦ 「ハードネガティブ」が性能低下の主要因であることを特定 ◦ 提案手法（検索結果の並び替え、暗黙的/明示的なファインチューニング）が有効であること を実証 • 今後の展望: ◦ より高度な検索結果並び替え手法の探求 ◦ より詳細で多段階な推論連鎖を用いたLLMのファインチューニング • 研究の意義: ◦ 長文脈LLMを用いたRAGシステム設計の新たな視点を提供 ◦ よりロバストで高性能なRAGシステムの実現に貢献 31
32. ご清聴ありがとうございました Copyright © 3-shake, Inc. All Rights Reserved. 32
33. ご清聴ありがとうございました Gemini君もとてもありがとうございました Copyright © 3-shake, Inc. All Rights Reserved. 33