RAG開発とは、RAG（Retrieval-Augmented Generation：検索拡張生成）という仕組みを利用して、外部の情報を検索しながら生成AIに回答させるシステムを開発することです。
ChatGPTをはじめとする大規模言語モデル（LLM）は幅広い知識を持っていますが、企業独自の資料や最新の社内情報など、モデルが学習していない情報について正確に回答することはできません。
RAGでは、質問に関連する情報を文書やデータベースから検索し、その情報をLLMに与えて回答を生成します。そのため、社内ナレッジ検索やFAQシステム、カスタマーサポートなど、独自データを活用した生成AIシステムで利用されています。
RAGとは
RAGは「Retrieval-Augmented Generation」の略称で、日本語では「検索拡張生成」などと訳されます。
一般的な生成AIでは、ユーザーから質問を受け取ると、LLMが自身の持つ情報を利用して回答を生成します。
一方、RAGでは回答を生成する前に、外部の情報源から質問に関連する情報を検索します。
基本的な処理の流れは次のようになります。
- ユーザーが質問する
- 質問に関連する情報を検索する
- 検索した情報をLLMに渡す
- LLMが検索結果を参考に回答を生成する
つまり、LLMの内部知識だけに依存するのではなく、必要な情報をその都度取得して回答に利用する仕組みです。
RAG開発とは
RAG開発とは、このRAGの仕組みを利用したアプリケーションやシステムを構築することを指します。
代表的な例として、企業が保有するマニュアルやFAQ、業務資料などを検索対象とした社内向けAIチャットがあります。
たとえば社員が、
「経費精算の申請期限はいつですか？」
と質問した場合、RAGシステムは社内規程や経費精算マニュアルから関連箇所を検索します。
その検索結果をLLMへ渡し、LLMが資料の内容をもとに回答を生成します。
この方法であれば、LLMがもともと知らない企業独自のルールについても回答できるようになります。
RAGの基本的な仕組み
RAGシステムは、大きく分けて「データの準備」と「質問への回答」という2つの処理で構成されます。
文書を収集する
最初に、AIに参照させたい情報を用意します。
対象となるデータには、次のようなものがあります。
- Word文書
- Webページ
- FAQ
- 社内Wiki
- 製品マニュアル
- データベース
- テキストファイル
RAGでは、こうした情報を検索可能な状態にする必要があります。
文書を分割する
長い文書をそのまま検索対象にするのではなく、一定の単位に分割することが一般的です。
この処理を「Chunking（チャンキング）」と呼びます。
たとえば数十ページあるマニュアルを、段落や数百文字程度のまとまりに分割します。
文書の分割方法は検索精度に大きく影響します。細かく分割しすぎると文脈が失われる場合があり、大きすぎると必要な情報を正確に検索しにくくなるため、データの性質に応じた設計が必要です。
Embeddingを生成する
文書を検索しやすくするために、文章を数値の集合で表現することがあります。
この処理を「Embedding（埋め込み）」と呼びます。
Embeddingを利用すると、単純に同じ単語が含まれているかどうかだけではなく、文章の意味的な近さを利用した検索が可能になります。
ベクトルデータベースへ保存する
生成したEmbeddingは、ベクトル検索に対応したデータベースなどへ保存します。
RAGシステムでは、PostgreSQLのpgvector拡張やElasticsearch、Pinecone、Qdrantなどが利用される場合があります。
システムの規模や既存環境によって適切な保存方法は異なります。
ユーザーの質問を検索する
ユーザーから質問を受け取ると、その質問と関連性の高い情報を検索します。
Embeddingを使用する場合は質問もベクトル化し、文書のベクトルと比較して意味的に近い情報を取得します。
実際のRAGでは、ベクトル検索だけでなくキーワード検索を組み合わせる方法もあります。
検索結果をLLMに渡す
検索によって取得した情報をユーザーの質問と一緒にLLMへ渡します。
LLMは提供された情報をコンテキストとして利用し、回答を生成します。
RAGの品質を高めるためには、LLMそのものの性能だけでなく、適切な情報を検索して渡せるかどうかが重要になります。
RAG開発で使われる主な技術
RAG開発では複数の技術を組み合わせてシステムを構築します。
LLM
ユーザーへの回答を生成するAIモデルです。
RAGでは、検索した情報を理解して自然な文章へまとめる役割を担います。
Embeddingモデル
文章をベクトルへ変換するためのモデルです。
文章同士の意味的な類似度を計算する検索などに利用されます。
ベクトル検索
Embeddingによって生成されたベクトルを比較して、質問に関連する文章を探す方法です。
キーワードが完全に一致していなくても、意味が近い情報を検索できることが特徴です。
ベクトルデータベース
大量のベクトルを保存し、高速に検索するための仕組みです。
RAGでは専用のベクトルデータベースだけでなく、ベクトル検索機能を備えた既存のデータベースを利用することもあります。
RAG開発フレームワーク
RAGシステムを構築するためのライブラリやフレームワークも存在します。
代表例としてLangChainやLlamaIndexなどがあります。
文書の読み込み、検索、LLMとの連携など、RAGで必要になる処理を実装するための機能が提供されています。
RAG開発のメリット
RAGには、通常の生成AIだけを利用する場合とは異なるメリットがあります。
独自データをAIに利用できる
RAGの大きなメリットは、LLMが事前に学習していない情報を回答に利用できることです。
企業の社内規程や製品資料、業務マニュアルなどを検索対象にすることで、自社専用の生成AIシステムを構築できます。
LLMを再学習しなくても情報を追加できる
新しい情報を利用するために、毎回LLM自体を再学習する必要はありません。
検索対象となるデータを追加・更新することで、新しい情報を回答に利用できるようにすることができます。
ただし、更新したデータを検索システムへ反映するための処理は必要です。
回答の根拠を提示しやすい
RAGでは回答を生成するときに参照した文書を特定できるため、回答と一緒に出典を表示するシステムを構築できます。
利用者が元の資料を確認できるようにすることで、回答内容を検証しやすくなります。
ハルシネーション対策に利用できる
生成AIでは、事実とは異なる内容をもっともらしく生成する「ハルシネーション」が発生する場合があります。
RAGによって信頼できる資料をLLMへ提供し、その情報に基づいて回答するよう制御することで、ハルシネーションを抑制することが期待できます。
ただし、RAGを導入すれば誤回答が完全になくなるわけではありません。検索結果が間違っていた場合や、LLMが検索結果を誤って解釈した場合などには、不正確な回答が生成される可能性があります。
RAG開発で重要なポイント
RAGシステムの精度は、LLMの性能だけで決まりません。
特に重要なのが検索部分の設計です。
Chunkingの設計
文書をどの単位で分割するかによって検索結果が変わります。
文章の意味が途中で分断されないよう、段落や見出しなど文書構造を考慮して分割することが重要です。
メタデータの設計
文書にカテゴリー、作成日、製品名、部署、文書種別などの情報を付与しておくと、検索範囲を絞り込むことができます。
特に大量の社内データを扱う場合、メタデータ設計は検索精度や権限管理にも関係します。
ハイブリッド検索
ベクトル検索には意味が近い文章を探せるメリットがありますが、製品番号や固有名詞など、完全一致に近い検索が必要な場合もあります。
そのため、ベクトル検索とキーワード検索を組み合わせる「ハイブリッド検索」が採用されることがあります。
リランキング
最初の検索結果から候補文書を取得したあと、質問との関連性を再評価して並び替える処理を「リランキング」と呼びます。
適切な文書をLLMへ渡すための方法の一つです。
権限管理
社内向けRAGでは、利用者が閲覧権限を持っていない文書をAI経由で取得できないようにする必要があります。
部署やユーザーごとのアクセス権限を検索段階で反映するなど、セキュリティを考慮した設計が必要です。
評価の仕組み
RAGシステムは、完成後も継続的に精度を評価する必要があります。
評価するポイントには、質問に対して正しい文書を検索できたか、必要な情報が検索結果に含まれていたか、検索結果をもとに正確な回答を生成できたか、といった項目があります。
検索と回答生成を分けて評価することが重要です。
RAGとファインチューニングの違い
RAGと比較されることが多い技術に「ファインチューニング」があります。
ファインチューニングは、追加データを利用してモデルの挙動や出力傾向を調整する方法です。
一方、RAGでは基本的にLLM自体を追加学習するのではなく、回答時に外部情報を検索して提供します。
そのため、頻繁に更新される情報や、大量の文書を参照して回答するシステムではRAGが適している場合があります。
一方で、特定の出力形式や応答スタイルをモデルに学習させたい場合などは、ファインチューニングが適していることがあります。
RAGとファインチューニングは排他的な技術ではなく、目的に応じて組み合わせることも可能です。
RAG開発の活用例
RAGはさまざまな分野で利用できます。
代表的な用途には次のようなものがあります。
社内ナレッジ検索
社内規程、業務マニュアル、議事録、技術資料などを検索対象にし、社員の質問にAIが回答するシステムです。
カスタマーサポート
製品マニュアルやFAQ、サポート情報を利用して、顧客からの問い合わせに回答する仕組みを構築できます。
製品マニュアル検索
大量のマニュアルから質問に関連する箇所を検索し、その内容をわかりやすく説明できます。
契約書・文書検索
大量の文書から特定の条件や条項を検索するための支援システムとして利用できます。
ただし、法律上の判断そのものをAIだけに任せるのではなく、専門家による確認が必要です。
研究・技術情報検索
論文や技術文書を検索対象にして、関連情報を探したり内容を整理したりする用途にも利用できます。
RAG開発の課題
RAGは便利な技術ですが、導入するだけで高精度なAIシステムになるわけではありません。
特に問題になりやすいのが、検索対象となるデータの品質です。
古い情報、重複した情報、矛盾した情報が大量に存在すると、検索結果にも影響します。そのため、データの整理や更新ルールもRAG開発の重要な要素です。
また、検索対象が増えるほど、検索速度、コスト、アクセス権限、更新処理なども考慮する必要があります。
LLMへ渡せる情報量にも制約があるため、単純に大量の検索結果を渡すのではなく、質問に必要な情報を適切に選択する設計が求められます。
RAG開発では検索精度が重要
RAGという名称からもわかるように、検索はシステムの中心となる処理です。
どれだけ高性能なLLMを利用していても、質問に必要な情報を検索できなければ、正しい回答を生成することは困難です。
そのためRAG開発では、
「必要な文書を検索できているか」
「検索した文書に回答に必要な情報が含まれているか」
「LLMがその情報を正しく利用できているか」
という観点からシステム全体を評価する必要があります。
LLMの選定だけではなく、データ整備、Chunking、検索方式、リランキング、プロンプト、権限管理、評価方法まで含めて設計することがRAG開発では重要です。
まとめ
RAG開発とは、外部データを検索し、その情報をLLMへ提供して回答を生成する「検索拡張生成」の仕組みを利用したシステム開発です。
企業独自のマニュアルや社内資料、FAQ、Webページなどを生成AIの回答に利用できるため、社内検索、カスタマーサポート、製品情報検索など幅広い用途があります。
RAGではLLMの性能だけでなく、質問に適した情報を正確に取得する検索処理がシステム全体の品質を大きく左右します。
そのため、実際のRAG開発では、文書の分割、Embedding、ベクトル検索、キーワード検索、リランキング、メタデータ、権限管理、回答評価などを総合的に設計することが重要です。
コメント