大規模言語モデル（LLM）は、幅広いトピックについて驚くほど豊富な知識を持っていることがよくありますが、トレーニングに使用されたデータのみに制限されています。つまり、プライベートまたは専有のビジネス情報でLLMを使用しようとしている組織は、質問に答えたり、通信文を作成したりするためにLLMを「そのまま」使用することができません。
検索拡張生成（RAG）は、モデルのトレーニング・データの一部ではなかった専門的または独自のトピックについて、基盤モデルが事実に基づいた正しい出力を生成できるようにするアーキテクチャー・パターンです。RAGは、外部データ・ソースから取得した関連データを使用してユーザーの質問とプロンプトを拡張することにより、モデルに応答の基となる（モデルにとって）「新しい」事実と詳細を提供します。
概念アーキテクチャー
- 検索拡張生成
- エージェント・アシストとの対話
- 生成検索
- エージェント型AI
- 文書の要約
- モダナイゼーションとコードの生成
- Ansible向けコード生成
- Z向けコード生成
- エージェントを活用したAI拡張型ソフトウェア開発
下の図に示すRAGパターンは、ビルド時のデータ埋め込みと実行時のユーザー・プロンプト（または検索結果の返送）の2つの部分で構成されています。
AIエンジニアは、データ前処理中にクライアント・データ（手順マニュアル、製品ドキュメント、ヘルプ・デスク・チケットなど）を準備します。クライアント・データは、モデル拡張に適したものになるように変換や強化が行われます。変換には、PDFドキュメントをテキストに変換するなどの単純な形式変換から、複雑なテーブル構造をif-thenタイプのステートメントに変換するなどのより複雑な変換までさまざまな種類があります。エンリッチメントには、一般的な略語の拡張、通貨情報などのメタデータの追加、検索結果の関連性を向上させるためのその他の追加が含まれる場合があります。
埋め込みモデルは、ソース・データを、顧客データ内の単語を表す一連のベクトルに変換するために使用されます。埋め込みにより、単語を表すスパース・ベクトルなどの大きな入力に対して機械学習を実行することが容易になります。埋め込みは、顧客データのパッセージ（チャンク）として保存され、サブセクションまたは段落として考えられ、情報を見つけやすくなります。
生成された埋め込みはベクトル・データベースに保存されます。watsonx Discoveryなど、関連性に基づいて結果を返す「ファジー」クエリーをサポートするデータ・ソースはどれもRAGアーキテクチャーで使用できますが、最も一般的な導入では、Milvus、FAISS、Chromaなどのベクター・データベースが使用されます。
これで、エンドユーザーがシステムを使用できるようになりました。
エンドユーザーは生成AI対応アプリケーションとやり取りしながら、クエリーを入力します。
生成AIアプリケーションはクエリーを受け取り、ベクター・データベースで検索を実行して、ユーザーのクエリーに最も近い上位（上位K個）の情報を取得します。例えば、ユーザーのクエリーが「MaxSaversアカウントの1日の引き出し限度額はいくらですか」である場合、検索では「MaxSaversアカウントは…」、「1日の引き出し限度額は…」「…アカウントの限度額…」などの文章が返されるかもしれません。
上位の文章は、特定のアプリケーション向けに厳選されたプロンプトとともに、LLMに送信されます。
LLMは、エンドユーザーに提示されるユーザーのクエリー、プロンプト、およびコンテキスト情報に基づいて、人間のような応答を返します。
IBM Watsonおよびwatsonx製品ファミリーのRAGパターンへのマッピングは、上図に示されています。
watsonx Discoveryは、パターンの前処理、埋め込み生成、関連性の保存および検索機能を実行します。特定の種類のソリューションでは、watsonx Discoveryをユーザー向けのフロントエンド生成AIアプリケーションとして使用することもできます。watsonx Discoveryは、単にベクター・データベースを置き換えるだけでなく、エンティティー抽出、感情分析、感情分析、キーワード抽出、カテゴリー分類、概念タグ付けなど、すぐに使用できるNLPエンリッチメントを提供します。
チャット・ソリューションの場合、watsonx Assistantはユーザー・インターフェースだけではなく、先に送信されたクエリーの内容を記憶するなどの会話機能も提供します。例えば、ユーザーが「Toast-o-maticトースターについて教えてください」と質問し、次に「いくらですか」と質問したとします。watsonx Assistantは、最後のクエリーの「it」が最初のクエリーのトースターを指していることを認識します。
最後に、watsonx.aiは、クラウド・ホスティング環境でお客様が選択できる大規模言語モデルの選択肢を提供します。watsonx.aiを使用すると、お客様は基盤モデル、生成AI、機械学習機能の学習、検証、調整、導入が容易になり、わずかなデータを使用して短時間でAIアプリケーションを開発できます。
お客様によっては、ローカル・リージョンでwatsonx.aiを利用できないか、セキュリティー上の懸念や規制上の要件により、watsonx.ai SaaSソリューションを使用できない場合があります。このようなお客様には、お客様のデータセンター内、クラウド・サービス・プロバイダーのインフラストラクチャー上の仮想プライベートクラウド（VPC）で実行されるRed Hat Openshiftにデプロイできるコンテナ化サービス・セットとしてwatsonx.aiを提供します。
LLMの大半は、他の言語、多くの場合、西ヨーロッパ言語のテキストがわずかに含まれる、英語が主言語のテキストでトレーニングを受けています。多言語またはローカライズされた言語サポートを必要とするアプリケーションでは、クエリー前およびクエリー後の翻訳ステップを実行して、入力を前処理済みドキュメントの「ベース」言語（英語など）に翻訳し、モデル出力をターゲット言語（スペイン語など）に翻訳することができます。このアプローチを以下の図に示します。
このアプローチでは、基本RAGパターンを次のように変更します（埋め込み生成手順は除きます）。
ユーザーは、前処理されたドキュメントの主要言語とは異なる言語でクエリーを入力します。例えば、スペイン語でのクエリーと英語が主となるドキュメント・ベースなどです。
生成AIアプリケーションは、大規模な言語モデルにユーザー・クエリーをドキュメントベースの言語に翻訳するよう促します。この例ではスペイン語から英語に翻訳しています。
翻訳されたクエリーは、ユーザーのクエリーに最も関連性の高い情報の上位K個のパッセージを取得するために使用されます。
翻訳されたクエリーと取得されたコンテキストはLLMに送信され、応答が生成されます。
生成AIアプリケーションは、大規模な言語モデルを使用して、生成された応答をユーザーのターゲット言語に翻訳します。この例ではスペイン語から英語に翻訳しています。
スペイン語に翻訳された応答がエンドユーザーに表示されます。
経験上、このアプローチを使用すると、送信されるクエリーのコンテキストとタイプに応じて、非基本言語の結果で80％以上の精度を達成できることがわかっています。さまざまな言語のより大きな割合でトレーニングされた新しい多言語モデルは、さらに高い精度を達成することが期待されています。
RAGは、ユーザーが信頼できる回答を提供するために参照する必要がある大量のドキュメントとビジネス・ルールがあるあらゆるビジネス・シナリオの候補ソリューションです。また、LLMベースのチャットボットに独自の知識やドメイン固有の知識を注入し、ハルシネーションを防ぐための強力なソリューションでもあります。
次のようなユースケースがあります。
保険引受および保険金請求の審査。RAGは保険業界において多くの潜在的な用途を持っています。引受人やブローカーには、何百もの保険商品の契約条件を網羅した何千ページもの文書に関する深い知識が必要です。同様に、請求審査官には、同じ文書だけでなく、優先条項や個々の顧客に固有の追加条件を含む契約に関する深い知識が求められる場合があります。RAGアーキテクチャー・パターンは、引受人、ブローカー、査定人が製品や契約文書を照会して顧客の問い合わせに適切に対応し、プロセスの生産性を向上させるのを支援するソリューションのアーキテクチャー「バックボーン」として機能します。
コールセンターのエージェント・サポート。コールセンターのエージェントには、数百に及ぶ可能性のある製品やサービス、およびよく発生する製品の問題とその解決策に関する深い知識が必要です。RAGパターンは、エージェントが顧客の要求に対する回答を迅速に見つけられるように支援するソリューションを作成するための強力なアーキテクチャー基盤です。
カスタマー・サービス用チャットボットRAGは、質問に答えるカスタマー・サービス用チャットボットを作成するための強力なソリューションです。大規模言語モデルの自然言語機能とRAGの企業固有の応答を組み合わせることで、対話をベースにした魅力的な顧客体験を提供できます。RAG自体は質問と回答の機能のみを提供し、「処理」、つまり企業システムと対話して情報を取得したり、レコードを更新したりします。ユーザーの意図を特定し、エンタープライズ・システムと対話するには、追加のコンポーネントを追加する必要があります。
サポート／ヘルプデスクコールセンター・エージェントと同様に、IT運用およびサポート担当者には、複雑なシステム・デプロイメントの構成に関する深い知識と、一般的な問題や過去に発生した問題とその解決策に関する知識が必要です。RAGパターンは、サポート担当者が報告された問題や観察された問題に対する適切な回答を迅速に見つけられるように支援するソリューションを作成するための強力なアーキテクチャー基盤です。
アーキテクチャーの決定と考慮事項
プロジェクトに適したモデルを選択するには、多くの要素を考慮する必要があります。
モデルのライセンスによって、その使用方法が制限される場合があります。例えば、モデルのライセンスによって、商用アプリケーションの一部として使用できない場合があります。
モデル・トレーニングに使用されるデータ・セットは、特定のアプリケーションでモデルがどの程度適切に機能するかに直接影響し、モデルが意味をなさない、不快な、または単に望ましくない応答を生成するリスクに大きく影響します。同様に、著作権で保護されたデータやプライベート・データでトレーニングされたモデルは、ユーザーが法的責任を負う可能性があります。IBMは、トレーニング・データの完全な透明性と、モデルに起因する法的請求に対する補償を提供します。
モデルのサイズ、トレーニングに使用したパラメーターの数、コンテキスト・ウィンドウのサイズ（モデルが受け入れ可能なテキストの長さ）は、モデルのパフォーマンス、リソース要件、スループットに影響します。「大きいほど良い」という考え方に従って200億個のパラメーターを擁するモデルを選択することは素晴らしいことかもしれません、リソース要件と精度の向上（これがある場合）を考えると、それが正当化されない可能性があります。最近の研究では、一部のソリューションでは、小さいモデルの方が大きいモデルよりもむしろ大幅に優れていることが示されています。
モデルにファイン・チューニングを加えると、タスクへの適合性に影響する可能性があります。例えば、IBMはGraniteモデルの2つのバージョンを提供しています。1つは一般的なチャット・アプリケーション用に調整されたもので、もう1つは指示に従うように調整されたものです。
モデルを選択する際のその他の考慮事項は次のとおりです。
モデル・パラメーターの選択（例：モデルの温度）により、人間のようなテキストと事実に基づく応答の作成のバランスが取れます。モデルの温度を高い値に設定すると、一貫性はあるものの、面白みに欠ける、または簡潔すぎる応答が生成される可能性があります。一方、温度を低い値に設定すると、応答に多様性がもたらされますが、応答の長さと内容が予測不可能になります。
効果のない結果や不快な結果を防ぐためのモデル・ガードレールの選択と実装。
モデルの選択は、アプリケーション、データの種類、言語サポートの要件によって異なります。業界やお客様固有の用語や頭字語を正確にエンコードして検索するには、埋め込みモデルを拡張する必要がある場合があります。
ベクトル・データベースは、埋め込みデータ・ストアを実装するための1つのオプションにすぎません。Watson Discoveryは、RAGソリューションのパフォーマンスと精度を向上できる追加のツールと機能を提供します。また、一部の「従来の」データベースは、RAGソリューションをサポートするベクトルの保存や検索、類似性検索を提供します。
ベクター・データベースにも多数のオプションがあります。生成AIアプリケーションに直接埋め込まれたシンプルなメモリー内データベースは、優れた実行時パフォーマンスを提供しますが、大規模なデータセットに適切に拡張できない可能性があり、最新の状態を維持したり、マルチサーバー構成に拡張したりする際に大きな運用上の課題が生じる可能性があります。中央サーバー・アーキテクチャーを使用する他のデータベースは、操作と拡張が容易ですが、特定のソリューションのパフォーマンス・ニーズを満たさない可能性があります。
検索モデルと生成モデルを統合する方法はいくつかあります。上位K個の文章を取得し、それを使用してユーザー・クエリーを拡張するのは簡単で便利ですが、複雑な質問に答えるために必要なニュアンスが欠けている可能性があります。キーワードによる単純な検索でも満足のいく結果が得られる場合があります。
より複雑なソリューションでは、LLMを使用してユーザーの元のクエリーから複数のクエリーを生成し、それらを使用してより大きな文章セットを取得する場合があります。取得した文章をさらに並べ替えて、関連性が最も高いものを選択するための追加ロジックを追加できます。
RAGシステムにデータを入力する前にデータを前処理することは、入力データがモデルに適した形式であることを確認するための重要なステップです。単純な方法では、入力データを重複する固定サイズのチャンクに分割します。例えば、チャンクの最後の10文字は次のチャンクの最初の10文字と同じですが、これでは入力データのニュアンスが失われる可能性があります。
より高度な前処理では、入力テキストを操作して一般的な単語の末尾を削除できます。例えば、stopper、stopping、stoppedはすべて「stop」になります。また、the、as、isなどの情報提供に役立たない「stop」に関連する単語を削除するなど、その他の処理も行われます。これらにより、取得した情報の関連性が大幅に向上しますが、データの埋め込みとユーザー・プロンプトの両方のフェーズが複雑になります。
さらに高度な技術では、テキスト内の意味を可能な限り維持するために、完全な文に対して操作が行われる場合があります。
RAGシステムのパフォーマンスを評価することは、タスクの性質が複雑なため困難な場合があります。一般的な評価指標には、困惑度、流暢さ、関連性、一貫性、およびBLU指標とROUGE指標などがあります。タスクの特定の目標と望ましい結果に一致する指標を選択することが重要です。
RAGにはプレーン・テキストが必要で、変換方法の選択はデータの品質に大きな影響を与えます。例えば、PDFファイルを変換する場合、表、画像、その他のメタデータ要素はどのように処理されるでしょうか。
LLMが人間のような応答を生成するには、かなりの計算リソースが必要であり、モデルのサイズ、ユーザー・クエリーの複雑さ、モデルに渡される拡張情報の量に応じて、数秒かかることがよくあります。大規模なユーザー・グループにサービスを提供する必要があるソリューションや、迅速な応答時間を必要とするソリューションでは、頻繁に発生するクエリーに対するモデル応答をキャッシュするメカニズムを実装する必要がある場合があります。
独自の情報、潜在的に機密情報、および潜在的に個人を特定できる情報をLLMプロンプトに埋め込むことは、RAGパターンの中核であるだけではなく、必須です。ホスト型モデル・プラットフォームを使用する組織は、プロンプト・データ保持や使用ポリシーなどのプロバイダー・ポリシーに注意する必要があります（例：プロバイダーはプロンプト・データを取得し、それをモデルの再トレーニングに使用しますか。プロンプト・データが他のユーザーなどに「漏洩」するのを防ぐための対策を講じ、これを自社の情報セキュリティー・ポリシーおよび対策とすり合わせます。
一部の独自情報の送信は避けられませんが、組織は処理されたデータに最も機密性の高い情報へのドキュメントまたはURL参照のみを含めることで、情報の漏洩を制限することができます。例えば、価格割引表をRAGデータに埋め込むのではなく、コンテンツには表の説明と、内部ドキュメントまたはWebサイトへの参照またはリンクのみを含めます。
ゾーン間通信における単純なトランスポート・レベル・セキュリティー（TLS）は、データ・セキュリティー要件を満たすのに十分である可能性がありますが、設計者は、ゾーン境界を越えて渡す前にプロンプトと応答を暗号化および復号化するコンポーネントを追加して、追加の保護を提供することを検討する必要がある場合があります。
デプロイメント・ゾーン間の接続の種類は、いくつかの機能以外の要件に影響を与えます。パブリック・インターネット経由で仮想プライベート・ネットワーク（VPN）接続を使用することは低コストのオプションですが、セキュリティー上の懸念が完全に解消されない可能性があり、ソリューションの応答時間やスループットの要件を満たすことができない可能性があります。モデル・ホスティング環境へのプライベート・ネットワーク接続はコストはかなり高くなりますが、セキュリティーが大幅に向上し、アーキテクトはネットワークの遅延と帯域幅を制御できるようになります。