学習
検索拡張世代（RAG）101

検索拡張ジェネレーション（RAG）でAIアプリを構築する

Jan 08, 20241 分で読めます

RAG（Retrieval Augmented Generation）の定義、ワークフロー、利点、使用例、課題を含む包括的なガイド。

シリーズ全体を読む

RAG（Retrieval-Augmented Retrieval）とは？

では、RAG（Retrieval Augmented Generation）とは何か？まず、大規模言語モデル（LLM）が得意とすること、つまり自然言語処理（NLP）を通じてコンテンツを生成することを念頭に置いておこう。ラージ・ランゲージ・モデルが遭遇したことのないデータ（おそらく、あなただけが知っているもの、ドメイン固有の情報、あるいはLLMがまだトレーニングを受けていない最新の情報）に対する応答を生成するようラージ・ランゲージ・モデルに求めた場合、この関連情報についての知識がないため、正確な答えを生成することはできません。

検索拡張生成に入る

検索拡張生成は、ラージ・ランゲージ・モデルが応答を生成する際に、正確で関連性のある情報を提供するためのフレームワークとして機能する。RAG "を説明するために、まず "G "を見てみよう。RAG "の "G "は、LLMがプロンプトと呼ばれるユーザークエリに応答してテキストを生成するところである。残念ながら、時々、モデルはあまり望ましくない応答を生成する。

例えば

**質問人類が初めて火星に降り立ったのは何年？

不正解（幻覚）：人類が初めて火星に降り立ったのは2025年。

この例では、2024年現在、人類は火星に着陸していないため、言語モデルは架空の答えを提供しています！モデルは学習データから学習したパターンに基づいて回答を生成することができる。起きていない出来事に関する質問に遭遇した場合、モデルはまだ答えを提供しようとするかもしれない。

この答えにも出典が記載されていなければ、この答えがどこから来たのかあまり信用できない。加えて、回答が古いことも多い。私たちの場合、LLMは、NASAが火星に人類を送り込む準備について発表した最近の公開データについて訓練を受けていない。いずれにせよ、言語モデルに情報を依存する際には、このような問題を認識し、対処することが極めて重要である。

以下は、私たちが生成された回答で直面している問題の一部である：

出典が記載されていないため、この回答がどこから来たのか確信が持てない。
古い情報
答えは、LLMが訓練したデータに基づいて作り上げることができる。私たちはこれをAIの幻覚と呼ぶ。
ほとんどのLLMが学習データを入手する公共のインターネット上では、コンテンツは利用できない。

NASAのサイトで火星探査機に関する情報を調べると、NASAが火星探査のためにどのような準備をしているのか、多くの情報を見ることができる。さらにNASAのサイトを見ると、2023年6月にミッションが開始され、378日間の火星表面シミュレーションが始まることがわかる。いずれこのミッションは終了するので、火星での人類に関する情報はどんどん変わっていくだろう。これによって、私は自分の答えをより信憑性のあるものにすることができた。ソース（NASAのウェブサイト）があり、LLMのように幻覚で答えを導き出したわけではない。

では、LLMを使う意味があるのだろうか？そこで、"RAG "の "RA "の部分が登場する。Retrieval Augmentedとは、LLMが訓練されたものに頼るのではなく、LLMの訓練データに正解と出典を添えて提供し、要約を生成して出典を列挙してもらうことを意味する。こうすることで、LLMが答えを幻覚してしまうのを防ぐことができる。

私たちは、コンテンツ（文書、PDFなど）をベクトル・データベースのような構造化されたデータに格納することでこれを行います。この場合、LLMを直接使うのではなく、チャットボットのインターフェイスを作成します。そして、コンテンツのベクトル埋め込みを作成し、ベクトルデータベースに格納します。ユーザーが私たちのチャットボットのインターフェースに質問をすると、私たちはLLMにクエリの内容に関連する情報を取得するように指示します。LLMは質問をベクトル埋め込みに変換し、ベクトルデータベースに格納されたデータを使って意味的類似性検索を行います。一旦、検索-拡張された回答で武装すると、私たちのチャットボットアプリは、これとソースをLLMに送信し、ユーザーの質問、提供されたデータ、および指示通りに実行した証拠を含む要約を生成するように依頼することができます。

RAGがLLMが上記の課題を克服するのに役立つことがお分かりいただけると思います。まず、不正確なデータについては、正しいデータを持つデータストアを提供し、そこからアプリケーションは情報を取得し、そのデータと元の質問を使って回答を作成することだけを厳密に指示してLLMに送信することができます。第二に、私たちはLLMに、証拠を提供するためにデータソースに注意を払うよう指示することができます。さらに一歩進んで、ベクターDBに保存されているデータに基づいて確実に答えられない質問に対しては、「わかりません」と答えるようLLMに要求することもできる。

RAGはどのように機能するのか？

RAGの仕組み](https://assets.zilliz.com/Retrieval_Augmented_Generation_RAG_Chatbot_20240104_111353_cfd173b608.png)

RAG(Retrieval-augmented generation)は、文脈に関連した結果を提供するために、RAGアプリケーションに使用するデータソースを選択することから始まります。これらのデータソースには、検索したい情報の性質に応じて、テキスト文書やデータベースからマルチメディアファイルまで、あらゆるものが含まれる。これらのデータソースのコンテンツは、データの数値表現であるベクトル埋め込みに変換される。この変換は、選択された機械学習モデル（多くの場合、データの意味的な意味を捉えることができる事前に訓練されたモデル）を用いて達成される。生成されたベクトル埋め込みは、ベクトルDBに格納される。ベクトルDBは、高次元ベクトルを扱うために最適化された特殊なデータベースであり、効率的な類似性検索を可能にする。

アプリケーションは、チャットボットに投げかけられた質問のようなクエリを受け取ると、vector db内のセマンティック検索をトリガーする。このクエリはまず、データベースに保存されているデータと同様のベクトル埋め込みに変換され、キーワードの完全一致ではなく、意味的類似性に基づく比較が可能になる。次にベクトルdbは、ベクトル空間におけるこれらの埋め込みデータの近接性に基づいて、最も関連性の高い文書やデータポイントを特定するための検索を行う。検索結果は、文脈に関連した文書やデータのスニペットであり、最初のクエリやプロンプトと組み合わされ、大規模言語モデル（LLM）に送られる包括的な入力を形成する。

LLMはこの入力を使って、文脈を理解し、ユーザーの元のクエリに関連した応答を生成する。このプロセスは、生成された情報が信頼できるデータソースに基づくものであることを保証するだけでなく、複雑なクエリを高い精度で解釈し応答するために機械学習の力を活用します。ベクトル・データベースとLLMを統合することで、RAGシステムはよりニュアンスに富んだ正確な情報検索を提供することができ、高度で文脈を考慮した応答を必要とするアプリケーションに理想的なものとなる。

RAG vs. モデルの微調整

RAG(Retrieval-Augmented Generation)で始めることは、多くの場合、効果的なエントリーポイントであり、多くのアプリケーションに対して、簡単でありながら強力な方法を提供する。RAGは、外部データソースを活用することによって大規模言語モデル（LLM）のパフォーマンスを向上させることができ、基礎となるモデルを深く修正することなく応答品質を向上させたいと考えている開発者にとって利用しやすいオプションです。適切に設計されたプロンプトを組み込むことで、回答をさらに洗練させ、意図されたユースケースにより近づけることができます。

一方、モデルのファインチューニングは、特に言語モデル自体の動作を調整したり、特殊な「言語」またはドメインを理解するために適応させる必要がある場合に、特定の目的に役立つより的を絞ったアプローチです。ファインチューニングは、法律文書、医療レポート、その他の専門的なコンテンツなど、特定の分野に非常に特化した出力を生成する必要がある場合に有効です。ファインチューニングを行うことで、モデル固有の機能を変更し、アプリケーションの固有の要件により合致させることができます。

RAGとファインチューニングを相互に排他的なものとして捉えるのではなく、補完的な戦略として捉えた方が有利な場合が多い。包括的なアプローチには、LLMを微調整してドメイン固有の言語に対する理解を向上させ、アプリケーションの特定のニーズを満たす出力を確実に生成することが含まれる。同時に、RAGを使用することで、外部ソースから引き出された最新の適切な情報をモデルに提供し、回答の質と関連性をさらに高めることができます。この組み合わせ戦略により、両方の技術の長所を生かすことができ、一般的な要件と特殊な要件の両方を満たす、より堅牢で効果的なソリューションが実現します。

RAGの課題に正面から取り組む

あなたのデータを闇に葬る**LLMs

従来の大規模言語モデル（LLM）の重大な限界の一つは、静的なデータセットに依存していることです。これらのモデルは膨大な量のデータで学習されますが、その知識は本質的に学習カットオフ点までの情報によって制限されます。この限界は、新しい開発、新たなトレンド、または元の学習データに含まれていないドメイン固有の知識を含むクエリに直面したとき、LLMが古く、しばしば不正確な回答、あるいは無関係な回答を提供する可能性があることを意味する。このようなモデルの静的な性質は、最新の情報を維持したり、変化に動的に適応したりする能力を制限し、最新の情報を必要とするアプリケーションの信頼性を低下させる。

AIアプリケーションは、有効性のためにカスタムデータを要求する**。

LLMの可能性を真に活用するためには、特に専門的な分野では、組織はLLMモデルがその分野に特化したデータにアクセスし、理解できるようにしなければならない。事前に訓練された一般的なモデルに頼るだけでは、正確で文脈に沿った正確な回答を必要とするユースケースには対応できません。例えば、カスタマーサポートのボットは、企業の製品、サービス、ポリシーに合わせた回答を提供する必要がある。同様に、社内のQ&Aボットは、現在の慣行やプロトコルに沿った詳細な企業固有の情報を提供できなければならない。このレベルの具体性を実現するために、企業は独自のデータセットをLLMと統合する必要があり、これによってモデルは、関連性があるだけでなく、組織の進化するニーズに沿った回答を生成できるようになる。このアプローチは、大規模な再トレーニングの必要性を減らし、AIアプリケーションを正確かつ効果的に維持するための、より効率的なソリューションとなる。

業界標準としての検索機能拡張

検索補強世代（RAG）は、従来の大規模言語モデル（LLM）の本質的な限界を克服する価値を実証し、さまざまな業界で標準的なプラクティスとして登場しました。従来のLLMは強力ですが、学習データが静的なため、リアルタイムに更新されず、学習後に新しい情報を取り込むことができないという制約がありました。この静的な性質は、特に動きの速い業界や最新のデータを必要とするシナリオにおいて、正確で最新のレスポンスを提供する能力に制限を与えます。

RAGは、LLMとリアルタイムのデータ検索システムを動的に接続することで、この課題に対処します。関連する最新のデータをLLMに提供されるプロンプトに直接統合することにより、RAGは静的な知識ベースとリアルタイムの情報とのギャップを効果的に埋めます。このプロセスにより、生成される回答は文脈に関連するだけでなく、最新であることが保証され、組織は最も正確でタイムリーな情報を必要とするタスクにAIを活用することができます。その結果、RAGは、意思決定プロセス、顧客との対話、全体的な業務効率を向上させるためにAIに依存している業界にとって、急速に重要なツールとなりました。

検索拡張世代の使用例

以下は、最も人気のあるRAGの使用例です：

1.質問と回答のチャットボット: 会社のドキュメントやナレッジベースから正確な回答を導き出すことで、カスタマーサポートや解決済みの問い合わせを自動化。

2.**LLMが生成した回答で検索エンジンを強化することで、情報クエリのレスポンスを改善し、情報検索を容易にします。

3.社内クエリのための知識エンジン：従業員が人事や財務の方針やコンプライアンス文書など、会社のデータについて質問できるようにする。

RAG** のメリット

1.最新かつ正確な回答：* RAGは、LLMの回答が最新の外部データソースに基づいていることを保証し、静的なトレーニングデータへの依存を軽減します。

2.不正確さと幻覚の減少： LLMの出力を関連する外部知識に基づくものとすることで、RAGは検証可能な引用を伴う出力を提供し、不正確な情報や捏造された情報を提供するリスクを最小限に抑えます。

3.ドメインに特化した、関連性のある回答： RAGを活用することで、LLMは組織の専有データやドメインに特化したデータに合わせた、コンテキストに関連性のある回答を提供することができます。

4.効率的で費用対効果に優れている： RAGは、他のカスタマイズ手法と比較してシンプルで費用対効果に優れているため、組織は大規模なモデルのカスタマイズを行うことなく導入することができます。

RAG アプリケーションのリファレンスアーキテクチャ

(LLM RAGアーキテクチャとしても知られる）

外部データ**の準備

検索拡張世代（[RAG]）アプリケーション](https://zilliz.com/blog/advanced-rag-apps-with-llamaindex)を構築する最初のステップでは、選択したデータソースからコンテンツを収集します。このコンテンツは、アプリケーションで使用可能な形式であることを保証するために前処理されなければならない。チャンキング戦略](https://zilliz.com/blog/experimenting-with-different-chunking-strategies-via-langchain)に応じて、データを適切な長さに分割し、検索と処理の効率を最適化します。続いて、選択した下流のLLMアプリケーションに合わせた埋め込みモデルを使用して、データをベクトル埋め込みに変換します。このステップは、後のプロセスで正確かつ効率的なデータ検索を行うための土台を作る。

インデックス関連情報

データの処理と埋め込みが完了したら、次のステップはこの新しいデータにインデックスを付け、素早く関連性のある検索を容易にすることです。ドキュメントの埋め込みが生成され、このデータを使ってVector Searchインデックスが作成される。Vector dbsは、これらのインデックスの作成を自動化し、インデックスされたコンテンツの整理、検索、更新を合理化する様々なデータ管理機能を提供します。

コンテキスト検索(関連データ)

RAGシステム](https://zilliz.com/blog/infrastructure-challenges-in-scaling-rag-with-custom-ai-models)の中核機能は、ユーザーのクエリに最も関連性の高いデータを検索する機能である。ユーザーのクエリーが行われると、ベクトルDBはセマンティック検索を行い、関連するデータを取得し、LLMの要約と生成処理に使用されるプロンプトに組み込む。これにより、LLMは最も関連性の高い文脈にアクセスできるようになり、より正確で文脈に適した応答を生成できるようになる。

AIアプリケーションの構築

検索システムと問い合わせメカニズムを確立したら、次のステップは、これらのコンポーネントを機能的なAIアプリケーションに統合することである。これには、LLMクエリ・コンポーネントとともに、関連コンテンツで補強されたプロンプトをエンドポイントにラッピングすることが含まれる。このエンドポイントは、REST APIを介して、Q&Aチャットボットなどの様々なアプリケーションに公開することができ、ユーザーとRAG搭載システムとのシームレスなインタラクションを可能にする。

評価

RAGシステムの継続的な有効性と信頼性を確保するためには、定期的な評価が不可欠である。これには、ユーザーからの問い合わせに対してLLMが生成する応答の品質を評価することが含まれる。RAG Triadのようなメトリクスは、ユーザーのクエリ、検索されたコンテキスト、LLMの関連するレスポンス間の関連性を評価します。さらに、親しみやすさ、有害性、簡潔性といった特定のLLM応答メトリクスは、システムの出力を微調整し最適化するために使用される。この一貫した評価プロセスは、RAGアプリケーションのパフォーマンスを長期にわたって維持・改善するために極めて重要である。

RAG アーキテクチャの主要要素

ベクトルデータベース

ベクトル・データベースは、高速で効率的な類似検索を可能にすることで、RAG（Retrieval Augmented Generation）アーキテクチャにおいて中心的な役割を果たす。これらのベクトル・データベースは、AIアプリケーションが最も関連性の高いデータと最新の独自ビジネス・データに確実にアクセスできるようにするために不可欠であり、より正確で文脈に応じた適切な回答のためのキーワード検索を可能にする。

プロンプトエンジニアリング**](https://zilliz.com/glossary/prompt-as-code-(prompt-engineering appendix))

これは、LLM](https://zilliz.com/blog/a-beginners-guide-to-using-llama-3-with-ollama-milvus-langchain)が提供された内容のみに基づいて応答を生成するように誘導する洗練された正確な指示を作成することを含む。効果的なプロンプトエンジニアリングは、特に複雑なクエリやドメイン固有のクエリを扱うときに、応答の関連性と正確性を維持するのに適している。

ETLパイプライン

ETL（Extract、Transform、Load）パイプラインは、データの取り込みを処理するために必要である。ETLパイプラインは、重複データの排除、アップサートの処理、テキスト分割やメタデータ抽出のような必要な変換の実行などのタスクを管理し、処理されたデータをベクターDBに格納します。このステップにより、データがきれいに整理され、効率的な検索に対応できるようになる。

LLM

オープンソースおよびプロプライエタリなオプションを含め、さまざまな LLM が利用可能です。LLMの選択は、ドメイン固有の知識、言語サポート、応答精度の必要性など、計算コストや金銭的コストなど、アプリケーションの特定の要件に依存する。

セマンティックキャッシュ**](https://zilliz.com/glossary/semantic-cache)

GPTキャッシュ](https://zilliz.com/what-is-gptcache)のようなセマンティックキャッシュは、LLMによって生成された応答を保存する。このキャッシュメカニズムは、同様のクエリに対して以前に生成されたレスポンスを再利用することで、冗長な計算の必要性を最小限に抑え、運用コストを削減し、パフォーマンスを向上させるのに有益です。

RAGツール

LangChain、LLamaIndex、Semantic Kernelのようなサードパーティツールは、検索拡張生成システムを構築する上で非常に貴重である。これらのツールは多くの場合LLMにとらわれず、異なるLLMを統合する柔軟性を提供し、開発者が堅牢で適応性の高いRAGシステムを構築することを可能にする。

評価ツールと評価基準

検索拡張世代アプリケーションの品質と有効性を保証するためには、評価ツールと評価基準を採用することが重要である。TruLens、DeepEval、LangSmith、Phoenix のようなツールは、LLMs and RAG システムのパフォーマンスを評価するのに役立ち、改善すべき領域に関する洞察を提供し、生成された出力が望ましい基準を満たしていることを保証します。

ガバナンスとセキュリティ

強力なガバナンスとセキュリティ対策を導入することは、Retrieval Augmented Generationシステムの完全性を維持するために不可欠である。これには、機密データの保護、規制要件の遵守の確保、RAGインフラストラクチャへのアクセスを管理・監視するためのプロトコルの確立などが含まれます。

RAGアーキテクチャのナビゲート

AIにおいて、企業はRAGが単なるツールではなく、ゲームチェンジャーであることを理解している。LLMとベクトルDBをシームレスに融合させ、最新の情報を取得し、正確で最新の業界に特化した回答を提供する。検索拡張世代は、正確さと柔軟性が融合し、今日の言語モデルが明日のスマートな会話者となる未来へとAIを導く。特にGenerative AIアプリケーションを本番稼動させるために取り組む中で、検索拡張生成がどのように機能するかについて学ぶことは多い。

旅は始まったばかりであり、RAGが舵を取れば、現代の情報検索システムの可能性は無限に広がる。

RAGアプリケーション構築のためのリソース

RAG アプリケーションの最適化：信頼性向上のための方法論、評価基準、評価ツールのガイド](https://zilliz.com/blog/how-to-evaluate-retrieval-augmented-generation-rag-applications)
検索拡張世代の評価](https://zilliz.com/blog/evaluations-for-retrieval-augmented-generation-trulens-milvus)
"Building an Open Source Chatbot Using LangChain and Milvus in Under 5 Minutes] "
ZillizクラウドRAGソリューション概要](https://zilliz.com/learn/Retrieval-Augmented-Generation)

article.updateAt

Chris Churilo
Chris Churilo is the VP of Marketing & Community at Zilliz where she leads all community, developer relations, and marketing efforts. Prior to Zilliz, Chris was a founding member of the InfluxData’s go to market efforts and helped propel the time series database platform to dominance in the market. In earlier roles she defined and designed a SaaS monitoring solution at Centroid, and prior to that she was the VP of product management at iPass and was the LOB for several cloud services that required her to track the business and operational metrics and analytics to help identify and resolve issues.