【Amazon Bedrock】半年間RAGを使ってみて見つけた課題とアプローチ

はじめに

RAG（検索拡張生成）は、社内データ活用や専門領域でのLLM応用において、ハルシネーション抑制と専門的な情報提供の両立を可能にする強力なアプローチとして注目を集めています。

私たちInsurTech研究所のチームも、半年間RAGを活用し、その可能性を追求してきました。AWS Bedrock上のClaude 3.5を主力に据え、日々その精度向上に取り組んでいます。

しかし、進めていく中で、期待通りの精度が得られない、ハルシネーションが完全に抑制できない、特定の質問にうまく答えられないといった課題に直面することも少なくありませんでした。「RAGを使ってみたけどうまくいかない」「RAGに興味はあるけれど、実際に運用できるか不安」と感じている方もいるのではないでしょうか。

本記事では、私たちのチームが直面した具体的な課題と、それを「分析と仮説立て」というアプローチでどのように解決していったのか、そのナレッジを共有します。特に、複雑な表データの取り扱いや効果的なチャンク戦略、そしてAIが正確に情報を読み取るためのプロンプトの工夫といった実践的な側面について深く掘り下げます。

RAGの導入を検討している方、すでにRAGを運用中で課題を感じているエンジニアやプロダクト作成者の皆さんの、活用・実験の機会を増やす一助となれば幸いです。

直面した課題：なぜ「うまくいかない」と感じるのか？

RAGシステムは、大きく分けて「検索（Retrieval）」と「生成（Generation）」の二つのフェーズから構成されます。ユーザーのクエリに基づいて関連情報をデータベースから検索し、その情報を元にLLMが回答を生成するという流れです。このシンプルな仕組みの裏には、様々な要因が絡み合い、精度低下や予期せぬ挙動を引き起こす可能性があります。

私たちが直面した主な課題は以下の通りでした。

• ハルシネーションの発生: 検索結果が不適切だったり、LLMが検索結果以外の情報を補完しようとしたりすることで、誤った情報が生成される

• 回答の精度不足: 関連する情報が検索されない、あるいは検索されてもLLMがうまく活用しきれないため、期待する回答が得られない。
• 文脈の欠落: 長いドキュメントを分割（チャンキング）する際に、意味的なまとまりが失われ、重要な文脈が欠落してしまう。

• 特定の質問への対応困難: 質問の意図が複雑な場合や、複数の情報源を横断する必要がある場合に、適切な回答ができない。

これらの課題は、単一の原因で発生するわけではありません。多くの場合、データの品質、チャンク戦略、埋め込みモデルの選択、プロンプト設計、検索ロジックなどが複合的に影響し合っています。そのため、闇雲に改善策を試しても、根本的な解決には至りません。

解決の鍵は「分析と仮説立て」にあり

RAGシステムの課題解決において、私たちが最も重要だと実感したのが「分析と仮説立て」です。これは、データ分析やソフトウェア開発の現場で用いられるアプローチと共通する部分が多くあります。

• データ分析・ソフトウェア開発における仮説検証

データ分析では、膨大なデータの中から意味のある洞察を得るために、「仮説を立て、それをデータで検証する」というプロセスが不可欠です。まず考えられる原因を洗い出し、それが適切かをチェックし、仮説を立て、優先順位をつけて検証します。このプロセスにより、効率的に問題の根本原因にたどり着き、最適な施策を導き出すことができます。

ソフトウェア開発においても、新規事業開発やプロダクト改善のフェーズでは「仮説検証」が中心となります。MVP（Minimum Viable Product）を開発し、顧客の課題を明確にし、解決策の仮説を立て、最小限のコストで検証を繰り返すことで、市場に受け入れられるプロダクトを効率的に作り上げていきます。

• RAGシステムにおける「分析と仮説立て」の実践

RAGシステムにおける「分析と仮説立て」も、これらのアプローチと同様に、問題の根本原因を特定し、効率的な改善サイクルを回すために不可欠です。

私たちのチームでは、RAGシステムで課題が発生した際に、以下のような手順で「分析と仮説立て」を行いました。

1. 問題箇所の特定と状況整理:
   • 「どのような質問で、どのような問題（ハルシネーション、低精度など）が発生したのか？」
   • 「その際に、どのような情報が検索され、LLMに渡されたのか？」
   • 「問題の発生頻度や、特定のドキュメント、質問形式に偏りはないか？」
2. 原因の深掘りと仮説の立案:
   特定した問題箇所から、考えられる原因を具体的に洗い出します。そして、それぞれの原因に対して「〜ではないか？」という仮説を立てます。
3. RAGにおける仮説の例:
   • データ品質/前処理: 「特定のドキュメントのテキスト抽出が不完全なため、重要な情報が欠落しているのではないか？」
   • チャンク戦略: 「チャンクサイズが大きすぎるために、関連性の低い情報が混入し、ノイズになっているのではないか？」「チャンクサイズが小さすぎるために、表が途切れているのではないか？」「チャンク間のオーバーラップが不足しているため、文脈が途切れているのではないか？」
   • 埋め込みモデル: 「選択している埋め込みモデルが、ドメイン固有の専門用語を十分に理解できていないのではないか？」
   • 検索ロジック: 「類似度検索だけでは、特定の質問の意図を捉えきれていないのではないか？」「メタデータフィルタリングが適切に機能していないのではないか？」
   • プロンプト設計: 「プロンプトがLLMに与える指示が曖昧なため、検索結果をうまく活用できていないのではないか？」
4. 検証計画の策定と実行:
   立てた仮説を検証するための具体的な方法を計画し、実行します。例えば、「チャンクサイズが大きすぎる」という仮説であれば、複数のチャンクサイズで実験を行い、評価指標の変化を比較します。この際、MVPの考え方と同様に、最小限の変更で効果を検証できる方法を選択し、迅速にPDCAサイクルを回すことが重要です。

具体的な解決策：試行錯誤から生まれたナレッジ

「分析と仮説立て」のサイクルを回すことで、私たちはRAGシステムを段階的に改善していきました。ここでは、特に効果的だった具体的な解決策と、それらを導き出した分析・仮説の例をいくつかご紹介します。

1. 複雑な表データの取り込みとチャンク戦略の最適化

• 課題: 保険契約の条件や料金表など、複雑な表形式のドキュメントを取り込んだ際、表の構造が崩れたり、誤読が多くなったりして、正確な情報が取得できないことが頻繁に発生していました。特に、**「1チャンクあたりのトークン数は、表全体のトークン数を意識しないと、途切れてしまって欲しい情報を取ってこれなくなる」**という問題は深刻でした。
• 分析と仮説: 表を単純にテキストとして抽出・チャンク化すると、表の行と列の関係性やセル内の情報が分断され、意味的なまとまりが失われているのではないか？また、表全体が1チャンクに収まらない場合に、途中で情報が途切れてしまうことが原因ではないか？
  • 解決策:表の構造を維持したテキスト化: 表データを単なるテキストではなく、Markdown形式のテーブルとしてテキスト化する前処理を導入しました。これにより、表のセル間の関係性をLLMが認識しやすくなります。
    • チャンク戦略の表特化:*「表全体を1チャンクとする」**アプローチを優先的に試行しました。これにより、表内の情報が途切れることなくLLMに渡されます。
  • 評価と微調整: 特定の表に関する質問を用意し、回答の正確性を検証することで、最適なチャンク戦略を見つけ出しました。この評価は「特定ケースにおいて正確な回答が返せること」という私たちの目標達成に直結しました。

2. AIが読めるプロンプトの工夫

• 課題:分析と仮説: 人間が自然に読む文章と、LLMが情報を正確に解釈しやすい文章には違いがあるのではないか？特に、情報抽出や特定の指示を出す際に、句読点や括弧の位置、スペースの有無などがLLMの解釈に影響を与えているのではないか？
• 解決策:「明確性」と「一貫性」を追求したプロンプト設計:句読点と区切り: 重要な指示や情報を区切る際には、。 や 、 だけでなく、: や -、または改行や箇条書き（例：* や -）を積極的に用いて、視覚的にも情報のまとまりを明確にしました。
• 括弧の使い方: LLMに特定の情報を「抽出」させたい場合や、注意を促したい場合は、【】 や <> など、LLMが解釈しやすい特殊な括弧を特定の意味合いで一貫して使用するルールを設けました。例えば、「以下の情報から**【回答に必要な情報】**を抽出してください。」のように指示します。
• 実例ベースのプロンプトテスト: 実際の質問と期待する回答、そして問題が発生した際のプロンプトと生成結果を比較し、プロンプトの修正を繰り返しました。このプロセスは、AIが**「どのように情報を解釈し、どこで躓いているか」**を理解するための重要な学びとなりました。

3. 検索ロジックの改善とメタデータの活用

• 課題: 関連性の低い情報が検索結果に含まれる、あるいは重要な情報が見過ごされる。
• 分析と仮説: キーワードベースの検索だけでは、質問の意図や文脈を正確に捉えきれていないのではないか？ドキュメントに付与された情報が検索に活用されていないのではないか？
  • メタデータによるフィルタリング: ドキュメントのカテゴリなどのメタデータを事前に付与し、ユーザーのクエリに応じてこれらのメタデータでソースの情報を絞り込む機能を活用しました。これにより、「特定のカテゴリの情報」をより精度の高い検索が可能になりました。

まとめと今後の展望

半年間のRAG運用を通じて、私たちはRAGシステム開発が「分析と仮説立て」の継続的なサイクルであることを痛感しました。闇雲な試行錯誤ではなく、問題の根本原因を特定し、仮説を立て、それを検証するというアプローチを徹底することで、複雑な表データの取り扱いやプロンプトの微細な調整といった、RAGシステムの精度と安定性を着実に向上させることができました。特にAWS Bedrock上のClaude 3.5と向き合う中で、AIの「読み方」を理解することの重要性を深く学びました。

RAGはまだ発展途上の技術であり、日々新しい研究や手法が生まれています。GraphRAGのような新しいアプローチや、エージェントベースのRAGなど、試すべきことは尽きません。今後も私たちは「分析と仮説立て」を羅針盤として、新たな技術の探求と実践を通じて、RAGの可能性を最大限に引き出し、より価値のあるプロダクト開発に貢献していきます。

皆さんのRAGシステム運用においても、この「分析と仮説立て」の考え方が、課題解決の一助となれば幸いです。ぜひ、自社のRAGシステムで実践してみてください。