RAG を使わないという選択肢

白金鉱業 Meetup Vol.24 で発表したLT資料です！

10万字級のインタビュー文字起こしをもとに回答生成する実案件で、最初はRAG構成を検討しつつも、検索精度・情報の点在・文脈幅の課題から、Window走査と質問別集約の構成へ切り替えた経験をまとめました。

RAGを否定する話ではなく、速度・コスト・検索の難しさ・必要な文脈幅を見ながら、長文回答生成の構成をどう選ぶかを考えるための資料です！

Transcript

1. 白金鉱業 Meetup Vol.24 長文回答生成で、RAG を前提にしない設計の話 RAG を使わないという選択肢 1
2. 実務とAIコンペの経験をもとに共有します。 本堂 貴也 NTT東日本株式会社 データサイエンティスト(3年目) 自己紹介 好きなこと AIコンペ参加 3D系画像が好きです（動画, MRI画像など） AI コンペ実績 Kaggle Expert Signate GM 資格 統計検定準一級 E資格 AWS 9冠 など CERT 業務 SaaS開発 社内データ活用施策の推進 など WORK 2
3. 実案件をもとに、長文ドキュメントの情報抽出では、RAGが常に最適とは限らない話を します 今日お話しすること 01 案件設定と自分の前提知識 10万字級Transcript×複数質問。最 初は自然にRAGを想定 4-5p 02 衝突した課題 検索精度・文脈幅・情報点在で、根拠取 得が不安定に 6p 03 要件の見直しと非RAG構成の実現 要件に立ち返り、Window走査＋質問別集約 へ 7-11p 3
4. 長文回答生成で、要件を見る前に RAG を第一候補にしがちではありませんか？ 長文ドキュメント 10 万字級の文章 ナレッジ chunk 01 chunk 02 chunk 03 chunk ... embedding metadata index 検索対象として保存 フロント ユーザーの質問 長文が題材だと つい RAG を選びがち チャンク化 検索 関連チャンク 4
5. 案件の要件：顧客ヒアリングの会話内容から、要件整理に必要な情報を質問形式で取り 出す／バッチ処理でOK／とにかく精度向上で稼働を削減したい 実案件においても私の最初の発想は RAG 5 会話内容をナレッジとして、質問を キーとしたRAG構成がよさそうだ な 困りごとに関してヒアリング 10万字の文字起こし 会話内容に関する複数質問 RAG構成を検討 問題設定 顧客が一番困っていること ? 手間や属人化がある箇所 ? 導入時に守るべき制約 ? 次に確認すべき宿題 ?
6. 実装してみると、欲しい根拠を安定して取れませんでした… 検索改善を試す うまくいかない理由 根拠が安定しない 試したこと クエリ拡張 質問を言い換え、検索クエリを増やす 狙い：表現ゆれを吸収する HyDE 仮の回答文を作り、その文で検索する 狙い：質問意図に近い表現で探す 親子チャンク 小チャンクで検索し、親チャンクも参照 する 狙い：検索粒度と文脈を両立する 文脈理解の壁 1 会話の文字数 ひとつの話題が数千字におよび、 チャンクサイズに収まらない。 → 局所チャンクだけでは意味を捉えにくい 2 質問に関する情報が点在 関連情報が会話内に散らばってい たり、少し前のトピックを引用した 会話では、曖昧な主語・目的語の表 現になる。 → キーワード一致だけでは拾いにくい 結果 検索精度は少し上がるが、根拠取得 は安定せず… 検索精度の壁にぶつかった 検索そのものがボトルネックと して残ってしまった 6
7. 要件に立ち返ると、RAG の強みが刺さる案件ではありませんでした 区分 観点 RAG の強み 今回の案件 ユーザー要望 速度 即時回答が必要な場面に強い 回答時間に余裕があった コスト 入力量を強く抑えたい 多少の入力コストは許容 最終回答の 精度 検索結果の範囲で十分 取りこぼしを減らしたい 文章の性質 検索の難し さ 質問と根拠箇所が対応しやすい （例：章で内容が分かれてる規約資料など） 根拠箇所が曖昧・広範囲 （例：ヒアリングの会話内容など） 必要な文脈 幅 局所的な根拠で答えられる （例：章で内容が分かれてる規約資料など） 会話全体や複数箇所の統合が重 要 （例：ヒアリングの会話内容など） RAG は、チャットBotで社内規定を検索するような「まとまった情報をリアルタイムに拾う」場面で強い。今回 は、会話を対象とするので、より広い文脈理解が重要でした。 本当に RAG が必須なのか？ 7
8. 検索自体が、最終的な回答を出力するのに必要な情報を 削ってしまうボトルネック工程になってしまう ⇒検索そのものを無くせないか 🤔 8
9. 各質問に対して全文脈を渡し、検索せずに質問別で集約する構成を実装 Windowごとに全質問をLLMへ入力 トランスクリプト （10万字） 重なりありで 1万字ずつ分割 Window 1 / Window 2 / Window 3 Window 1 1万字程度 Q1 困りごと Q2 現行運用 Q3 導入条件 Q1 月末作業が集中 Q2 Excel転記が多い Q3 情報なし Window 2 1万字程度 Q1 困りごと Q2 現行運用 Q3 導入条件 Q1 確認漏れが発生 Q2 判断が担当者依存 Q3 CRM連携が必要 Window 3 1万字程度 Q1 困りごと Q2 現行運用 Q3 導入条件 Q1 情報なし Q2 履歴が残らない Q3 権限設定が必要 質問ごとに集約 → 最終出力 Q1 困りごと W1: 月末集中 W2: 確認漏れ W3: 情報なし Q1 月末集中と確認漏 れが主課題 Q2 現行運用 W1: Excel転記 W2: 担当者依存 W3: 履歴なし Q2 転記削減と運用標 準化が必要 Q3 導入条件 W1: 情報なし W2: CRM連携 W3: 権限設定 Q3 CRM連携と権限 設計が条件 考案したソリューションの全体像 9 LLMで 情報抽出 LLMで 情報抽出 LLMで 情報抽出 Qごとに集約 LLMで要約 LLMで要約 LLMで要約
10. 話題が戻る会話でも、前に出た内容を踏まえて読める幅にしたかった 会話の流れ A 困りごとの話 （数千字） B 運用・制約の話 （数千字） A 同じ困りごとに戻る （数千字） （主語や目的語があいまいになりがち） 後に出てくるAを理解するためには、先に出てきたAが前提情報となる。 ⇒両方を一つのWindowに入れてLLMで情報を抽出したい。 1万字 = 1つのトピックに対して網羅的に情報を拾える範囲 かつ、ハルシネーションが起こりにくい文字数 （この時はClaude Sonnet 4.5を使用） なぜ1万字のWindow分割にしたのか？ 10
11. 要件に合わせて構成を変えたことで、かなり出力の品質と納得感が上がった！ 要望元からのコメント （RAG構成から切り替えて） かなりいい出力になったと 感じます！ 全文脈を活用 検索をなくし、会話全体から根拠を拾えた。 取りこぼし低減 根拠候補を広く拾え、出力品質が向上。 構成を選ぶ判断軸 ユーザーの要望 速度 RAG向き 即時回答が必要 今回 バッチでOK コスト RAG向き 入力を抑えたい 今回 コスト許容 最終回答の精度 RAG向き 検索範囲で十分 今回 取りこぼし低減 対象とする文章の性質 検索の難しさ RAG向き 根拠が対応しやすい 今回 根拠が曖昧 必要な文脈幅 RAG向き 局所根拠で回答 今回 全体を統合 今回考案した手法は遅いしコストがかかる。ただ、トランスクリプトの情報を網羅的に使えるので、出力の品質はかなり高い。 RAG は有力だけど、速度・コスト・検索難易度・文脈幅で、案件に合う構成を選ぶことが大事だと案件を通して学びました。 結果とまとめ 11
12. 発表内容やコンペの話など、ぜひ気軽にお声がけいただけると嬉しいです！ X X (Twitter) tatsutaka @Ka2vt0w4rQtN3jA https://x.com/Ka2vt0w4rQtN3jA k Kaggle tatsutaka kaggle.com/tatsutaka https://www.kaggle.com/tatsutaka ご清聴ありがとうございました！ 12