概要
検索拡張生成 (RAG) は、大規模言語モデル (LLM) を外部リソースにリンクさせて生成 AI アプリケーションからの回答精度を高める手法です。
検索拡張生成とは
RAG により、LLM 内に存在するデータを任意の外部知識ソース (データリポジトリ、テキストのコレクション、既存のドキュメントなど) で補完することができます。これらのリソースはセグメント化され、ベクトルデータベースでインデックス付けされ、より正確な回答を提供するための参考資料として使用されます。
RAG は、任意の信頼できるソース (複数の場合もある) から特定のリアルタイム情報を取得するように LLM に指示するので有用です。モデルのトレーニングやファインチューニングにコストをかけなくても、カスタムエクスペリエンスが得られるため、費用を節約できます。また、LLM にクエリを実行する際に、(長い文書ではなく) 最も関連性の高い情報のみを送信するため、リソースを節約することもできます。
RAG 出力と通常の LLM 出力の違い
LLM は、機械学習と自然言語処理 (NLP) の技術を使用して人間の言語を理解し、生成します。LLM は通信とデータ処理において非常に役立つものですが、欠点もあります。
- LLM は一般的に利用できるデータを使用してトレーニングされますが、組織の内部データセットなど、参照させたい特定の情報が含まれていない場合があります。
- LLM の知識には期限があります。つまり、LLM のトレーニングに使用された情報はアップデートを継続的に収集しません。結果としてそのソース資料が古くなり、関連性が失われることがあります。
- LLM は回答を生成するために誤情報や古い情報を提示することがあります。これは「ハルシネーション」とも呼ばれます。
RAG アーキテクチャを LLM ベースの質問応答システムに組み込むと、LLM と任意の追加の知識ソースとの間で情報をやり取りできるようになります。LLM は内部知識を相互参照して補足することができるため、クエリを作成するユーザーに対する出力の信頼性と精度が向上します。
RAG のメリットとは
RAG アーキテクチャに組み込まれた検索メカニズムにより、LLM の一般的なトレーニング以外にも追加のデータソースを利用することができます。RAG を介して LLM が外部の検証可能な一連の事実に基づくようにすることで、以下のような有益な目標をサポートできます。
精度
RAG は LLM に引用できるソースを提供するため、ユーザーはその主張を検証できます。また、質問が知識の範囲外である場合には「わかりません」と答えるように、RAG アーキテクチャを設計することもできます。概して、RAG は LLM が誤情報や誤解を招く情報を出力として共有する可能性を減らすため、ユーザーの信頼を高めることができます。
費用対効果
LLM の再トレーニングとファインチューニングには、ドメイン固有の情報を使用して基盤モデル (チャットボットなどを構築するための) をゼロから作成するのと同様に、コストと時間がかかります。RAG を使用すると、ドキュメントやファイルをアップロードするだけで、LLM への新しいデータの導入や情報ソースの交換または更新を行うことができます。
RAG は推論コストも削減できます。LLM クエリのコストは高く、ローカルモデルを実行する場合は独自のハードウェアが必要になり、アプリケーション・プログラミング・インタフェース (API) を通じて外部サービスを利用する場合は使った分だけ料金がかかります。RAG は、参照ドキュメント全体を一度に LLM に送信するのではなく、その資料の最も関連性の高いチャンクのみを送信できるため、クエリのサイズが削減され、効率が向上します。
開発者の制御
RAG では、従来のファインチューニング手法よりも利用しやすく簡単な方法で、フィードバックの取得、トラブルシューティング、アプリケーション修正を行うことができます。開発者にとって、RAG アーキテクチャの最大のメリットは、ドメイン固有の最新情報のストリームを利用できることです。
データ主権とプライバシー
LLM はトレーニングデータから情報を漏らす場合があるため、機密情報を使用した LLM ツールのファインチューニングには、これまではリスクが伴いました。RAG は、機密データをオンプレミスで保持しながらローカル LLM や信頼できる外部 LLM への情報提供に使用できるようにすることで、こうしたプライバシーの懸念に対する解決策をもたらします。RAG アーキテクチャの設定によって、機密情報の取得をさまざまな認可レベルに制限することもできます。つまり、セキュリティ・クリアランス・レベルに基づいて特定のユーザーが特定の情報にアクセスすることができます。
RAG の仕組み
RAG アーキテクチャは、外部ソースからデータを取得し、それを LLM のコンテキストに処理し、融合したソースに基づいて回答を生成することによって機能します。このプロセスには、データの準備、検索、生成という 3 つの主要な段階があります。
ステップ 1：データの準備 (検索用)
- ドキュメントの調達とロード：LLM と共有するソースドキュメントを特定して取得し、LLM が理解できる形式 (テキストファイル、データベーステーブル、PDF など) であることを確認します。ソース形式に関係なく、各ドキュメントをベクトルデータベースに埋め込む前にテキストファイルに変換する必要があります。このプロセスは ETL ステージ (抽出、変換、ロード) とも呼ばれます。ETL は生データをクリーニングおよび整理して、保存、分析、機械学習に備えます。
変換：「テキスト分割」または「チャンク化」により、ドキュメントを検索用に準備します。つまり、更新されたドキュメントを解析し、個別の特性に基づいて関連する「チャンク」にカタログ化します。たとえば、段落ごとにフォーマットされたドキュメントの方が、表や図で構造化されたドキュメントよりも、モデルにとって検索と取得が容易な場合があります。
チャンク化は、セマンティクス、文、トークン、フォーマット、HTML 文字、コードタイプなどの要素に基づいて行うことができます。多くのオープンソース・フレームワークがドキュメントの取り込みのプロセスを支援しています。LlamaIndex や LangChain はその一部です。
埋め込み：埋め込みでは、特殊な機械学習モデル (ベクトル埋め込みモデル) を使用してデータを数値ベクトルに変換し、数学的演算を適用してデータ間の類似点と相違点を評価できるようにします。埋め込みを使用すると、テキスト (または画像) を、関連性のない詳細情報を破棄しながらコンテンツの中心的な意味を捉えるベクトルに変換できます。埋め込みのプロセスでは、データのチャンクに数値 ([1.2, -0.9, 0.3] など) を割り当て、ベクトルデータベースと呼ばれるより大きなシステム内でインデックス付けを行うことがあります。
ベクトルデータベース内で、この数値は RAG アーキテクチャがコンテンツのチャンク間の関連性を示し、そのデータを整理して検索を最適化するために役立ちます。このインデックス付けの目的は、類似の概念が隣接する座標に格納されるようにベクトルを構造化することです。たとえば、「コーヒー」と「お茶」は近くに配置されるでしょう。「温かい飲み物」もそうでしょう。「携帯電話」や「テレビ」など、関連性のない概念は遠く離れたところに配置されるでしょう。2 つのベクトル点の間の距離または近さによって、モデルはどの情報を取得してユーザークエリに対する出力に含めるかを決定します。
- 保存：複数のソース (任意の外部ドキュメントと LLM) から結合されたデータは、中央リポジトリに保存されます。
ステップ 2：検索
データがベクトルデータベースにカタログ化されると、アルゴリズムがユーザーのプロンプトやクエリに関連する情報の断片を検索して取得します。LangChain のようなフレームワークは、セマンティクス、メタデータ、親ドキュメントなどのデータの類似性に基づく検索など、さまざまな検索アルゴリズムをサポートしています。
オープンドメインのコンシューマー設定では、情報ソースの API を介してアクセスされる、インターネット上のインデックス付きドキュメントから情報が取得されます。情報を非公開にして外部ソースから保護する必要があるクローズドドメインのエンタープライズ設定では、RAG アーキテクチャを介した取得をローカルで行うことでセキュリティを強化できます。
そして、取得したデータがプロンプトに挿入され、LLM に送信されて処理されます。
ステップ 3：生成
- 出力：ユーザーに回答が提示されます。RAG が意図したとおりに機能する場合、ユーザーは提供された知識ソースに基づく正確な答えを得ます。
RAG のベストプラクティスと検討事項
機械学習モデルを構築する場合、出力の品質は入力したデータによって決まるため、高品質のソースドキュメントを見つけることが重要です。歪曲した結果や偏った結果を生み出すシステムは、AI を使用するあらゆる組織にとって重大な懸念事項です。したがって、ソースドキュメントに偏った情報、つまり、特権のあるグループを系統的に有利にし、特権のないグループを系統的に不利にするバイアスが含まれないよう注意を払うことが、出力のバイアスを軽減するために不可欠です。
RAG アーキテクチャのデータを取得する場合は、ソースドキュメントに含めるデータが正確に引用されていること、最新のものであることを確認してください。さらに、人間の専門家は、モデルをより広範な利用者に対して展開する前に出力に関する評価が行われるよう支援し、モデルがプロダクション用にデプロイされた後も結果の品質を継続的に評価する必要があります。
RAG と他のデータトレーニングおよび処理方法との違い
データトレーニング手法と RAG アーキテクチャの違いを理解すると、ニーズに応じてどの AI リソースをデプロイするべきかについての戦略的な意思決定に役立ちます。また、一度に複数の手法を使用することも可能です。データを扱うための一般的な手法とプロセスをいくつかご紹介し、RAG との違いを説明します。
RAG とプロンプトエンジニアリング
プロンプトエンジニアリングは、LLM を操作するための最も基本的で、最も技術的知識を必要としない方法です。プロンプトエンジニアリングでは、ユーザーがクエリを作成したときに望ましい出力を生成するためにモデルが従うべき一連の命令を記述する必要があります。RAG と比較した場合、プロンプトエンジニアリングは必要なデータが少なく (モデルの事前トレーニングに使ったもののみを使用)、低コスト (既存のツールとモデルのみを使用) ですが、最新情報や変化する情報に基づいて出力を作成することはできません。さらに、出力の品質はプロンプトの表現に依存するため、応答が一貫しない場合があります。
多くの詳細情報を必要としない一般的なトピックに関する情報を抽出するための、ユーザーにとって使いやすく費用対効果の高い方法を探している場合は、RAG ではなくプロンプトエンジニアリングの使用を選択することもできます。
RAG とセマンティック検索
セマンティクスとは、単語の意味に関する研究のことです。セマンティック検索は、検索クエリの背後にある意図と文脈を考慮した方法でデータを解析するための技術です。
セマンティック検索は NLP と機械学習を使用してクエリを解読し、単純なキーワード一致よりも有意義で正確な応答を提供するために使用できるデータを見つけます。つまり、セマンティック検索によって、ユーザーがクエリとして入力した内容と、結果の生成に使用されるデータとの間のギャップを解消することができます。
たとえば「夢の休暇」に関するクエリを入力した場合、セマンティック検索によって、モデルはユーザーが「理想的な」休暇に関する情報を必要としている可能性が高いことを理解できます。夢についての回答ではなく、ビーチで休暇を過ごすためのホリデーパッケージなど、よりユーザーの意図に則した回答を提供します。
セマンティック検索は RAG の要素であり、RAG はベクトルデータベースの取得のステップでセマンティック検索を使用して、文脈的に正確で最新の結果を生成します。
RAG と事前トレーニング
事前トレーニングは、LLM が大規模データセットから学習することで言語を幅広く把握できるようトレーニングする最初のフェーズです。人間の脳が物事を学習するときに神経経路を構築するのと同様に、事前トレーニングでは、データを使用してトレーニングされる LLM 内にニューラルネットワークを構築します。
RAG と比較した場合、LLM の事前トレーニングにはより多くのコストと時間がかかり、より多くの計算リソース (数千もの GPU など) が必要になることがあります。広範なデータセット (トレーニングされるモデルに大きな影響を与えるのに十分な量) にアクセスでき、LLM に特定のトピックや概念の基礎を理解させたい場合は、RAG ではなく事前トレーニングの使用を選択することもできます。
RAG とファインチューニング
RAG アーキテクチャが LLM が認識すべきことを定義するのに対し、ファインチューニングはモデルがどのように動作すべきかを定義します。ファインチューニングは、事前トレーニング済みの LLM を取得し、より小規模でよりターゲットを絞ったデータセットを使用してさらにトレーニングするプロセスです。モデルは、経時的に変化しない一般的なパターンを学習できます。
表面上は、RAG とファインチューニングは似ているように見えますが、違いがあります。たとえば、ファインチューニングではモデルの作成に大量のデータと相当な量の計算リソースが必要ですが、RAG は 1 つのドキュメントから情報を取得でき、必要な計算リソースははるかに少なくなります。さらに、RAG がハルシネーションを効果的に軽減することは実証済みですが、ハルシネーションを軽減するために LLM をファインチューニングするのにはかなりの時間がかかり、そのプロセスも困難です。
多くの場合、モデルにとってはファインチューニングと RAG アーキテクチャの併用が有効です。しかし、大量のデータとリソースにアクセスでき、そのデータが比較的変化しない場合、または、RAG が専門とする質問と回答の形式よりもさらにカスタマイズされた分析を必要とする特殊なタスクに取り組んでいる場合は、RAG ではなくファインチューニングの使用を選択することもできます。
RAG のユースケース
RAG アーキテクチャには、多くの潜在的なユースケースがあります。最も一般的なユースケースの一部を以下に示します。
カスタマーサービス：特定のドキュメントが提供する洞察に基づいて顧客のクエリに応答するようにチャットボットをプログラミングすることで、解決時間を短縮し、より効果的なカスタマーサポートシステムを実現できます。
洞察の生成：RAG は、既存のドキュメントからの学習を支援します。RAG アーキテクチャを使用して、年次報告書、マーケティング文書、ソーシャルメディアのコメント、カスタマーレビュー、アンケート結果、研究文書などの資料に LLM をリンクさせ、リソースをより深く理解するために役立つ回答を見つけることができます。RAG を使用すると、ソーシャルメディアフィード、Web サイトなど、頻繁に更新されるソースのライブデータソースに直接接続できるため、有用な回答をリアルタイムで生成できます。
医療情報システム：RAG アーキテクチャは、医療情報やアドバイスを提供するシステムを改善できます。RAG によって個人の病歴、予約スケジュールサービス、最新の医学研究やガイドラインなどの要素を確認できるため、患者を彼らが必要とするサポートやサービスにつなげることができます。
Red Hat のサポート内容
Red Hat® OpenShift® AI は、AI 対応アプリケーションを構築、デプロイ、管理するツールを備えた柔軟でスケーラブルな機械学習運用 (MLOps) プラットフォームです。オープンソース・テクノロジーを使用して構築されており、実験、モデル提供、革新的なアプリケーションの提供のための、信頼性と一貫性に優れた運用機能を提供します。
OpenShift AI を使用すると、ベクトルデータベースへのアクセス、埋め込みを作成するための LLM、出力の生成に必要な検索メカニズムなど、基盤となるワークロード・インフラストラクチャを提供することで、RAG アーキテクチャを大規模言語モデル運用 (LLMOps) プロセスに実装できます。
Red Hat コンサルティングは、お客様が Red Hat OpenShift AI の使用を開始し、既存のエンタープライズ・サービスと統合できるよう支援するために、Red Hat OpenShift AI Pilot を開発しました。一元的プラットフォームにより、ユーザーは標準化されたライブラリやツールにアクセスできるようになり、すべてのユーザーにとってコンピューティングの可用性が向上し、データサイエンティストやその他のユーザーのオンボーディングが改善されます。このエンゲージメントを通じて、Red Hat のエキスパートがお客様のチームに加わり、現在の環境とアプローチの評価や、将来の要件の特定を行います。エキスパートは Red Hat OpenShift AI のデプロイと管理だけでなく、それをお客様の環境にある他のデータサイエンス・ツールと統合してテクノロジーを最大限に活用できるよう支援します。このパイロットでは、機能する ML モデルを持っている必要はありません。Red Hat はお客様がデータサイエンスのどの段階にあっても、喜んでお手伝いします。
モデルの実験から、モデルをプロダクションにデプロイする戦略の策定に進みたいとお考えの場合、Red Hat コンサルティングサービスが次のステップをお手伝いします。MLOps Foundation のエンゲージメントは、組織がデータサイエンスの機能と作業方法を改善して ML 戦略を推進し、プロダクション対応の推論サービス向けの再利用可能なパターンを作成し、クラウドネイティブのツールとアーキテクチャを使用して ML モデルのライフサイクル全体を自動化できるよう支援します。
