RAG構築の必要機能や標準機能の一覧について

RAG（検索拡張生成）の構築を検討し始めると、まず直面するのが「どんな機能が必要なのか」「標準機能として何を備えておくべきか」という疑問です。RAGは社内文書を検索し、その内容を踏まえて生成AIに回答させる仕組みですが、その実態は単一の機能ではなく、複数の処理機能が連なったパイプラインです。インデックス化、検索、リランキング、生成、評価といった要素がそれぞれ役割を持ち、どれか一つが欠けても回答精度は伸び悩みます。そのため、機能の全体像を体系的に理解することが、構築を成功させる前提となります。

本記事では、RAG構築に必要な機能や標準機能の一覧について、パイプラインの流れに沿って体系的に解説します。チャンキング戦略や検索アルゴリズムの選定、リランキングの要否といった技術要素を、どの選択肢があり、なぜ必要なのかという観点で掘り下げます。機能を選ぶ前に全体の構造を整理したい方は、あわせてRAG構築の完全ガイドもご覧ください。本記事は、その完全ガイドよりも一歩踏み込み、各機能の選定基準を実証データとともに具体的に整理する内容です。

▼全体ガイドの記事
・RAG構築の完全ガイド

インデックス化フェーズの必要機能

RAGパイプラインは「インデックス化」「検索」「生成」という3つの大きなフェーズで構成されます。その起点となるのがインデックス化フェーズで、社内文書を検索可能な状態へ整える前処理を担います。ここでの設計が後続の検索精度を左右するため、地味ながら最も重要な工程の一つです。インデックス化フェーズに必要な機能を、文書の分割から保存基盤まで順に解説します。

インデックス化フェーズの起点となるのが、文書を適切な単位に分割するチャンキング機能です。長い文書をそのまま扱っても、質問に対応する箇所だけを正確に取り出すことはできません。意味のまとまりごとに文書を分割し、検索しやすい単位へ整える処理が、回答精度の土台になります。チャンキングは単なる前処理ではなく、RAG全体の精度を決める戦略的な機能として位置づけられます。

分割の単位（チャンクサイズ）が大きすぎると、無関係な情報が同じチャンクに混ざり、検索のノイズになります。逆に小さすぎると、前後の文脈が失われ、断片的な情報しか取り出せません。この課題に対しては、チャンク同士を一部重複させるオーバーラップという手法や、見出しや段落といった文書構造に沿って分割する手法が用いられます。固定長で機械的に区切るのか、構造を尊重して区切るのかは、扱う文書の性質に応じて選び分ける必要があります。

マニュアルのように構造が明確な文書と、議事録のように文脈が連続する文書とでは、最適な分割方針が異なります。文書の種類ごとにチャンキングの戦略を変えられる柔軟性が、精度を底上げする隠れた要素となります。チャンキングは一度設定すれば終わりではなく、検索精度を見ながら継続的に調整していく対象です。構築の初期段階で完璧な設定を目指すよりも、調整しやすい構成を選んでおくことが現実的です。

分割した文書は、埋め込み生成（Embedding）という処理によって、意味を数値で表現したベクトルへ変換されます。この埋め込みベクトルこそが、後続の検索で「意味の近さ」を計算するための鍵となります。埋め込みモデルにはさまざまな種類があり、扱う言語や文書のドメインに合ったモデルを選ぶことが、検索精度の出発点になります。日本語文書を扱う場合は、日本語に対応した埋め込みモデルを選定することが前提です。

生成したベクトルを保存し、高速に検索できるようにする基盤がベクトルデータベースです。代表的な選択肢として、専用サービスのPinecone、オープンソースのWeaviate、PostgreSQLの拡張機能であるpgvectorなどがあります。これらはRAGの「知識の保管庫」に相当し、ユーザーの質問に近い意味を持つ文書を瞬時に取り出す役割を担います。

ベクトルデータベースの選定は、扱うデータ量と運用体制によって変わります。すでにPostgreSQLを運用している組織であれば、pgvectorを使うことで既存の基盤を活かしながら導入でき、運用負荷を抑えられます。一方、大規模なデータを高速に扱いたい場合や、運用をマネージドサービスに任せたい場合は、PineconeやWeaviateが選択肢となります。インデックス化の機能は地味な存在ですが、ここでの設計が検索の速度と精度を左右するため、文書量の増加を見越した拡張性を備えているかを確認しておくことが重要です。

検索フェーズの中核機能と検索アルゴリズムの選定

検索フェーズは、RAGの回答精度を最も大きく左右する中核工程です。ユーザーの質問に対して、インデックス化した文書群から関連性の高い箇所を取り出す処理であり、ここで的確な文書を取得できなければ、後続の生成フェーズがどれだけ優秀でも正しい回答は得られません。検索フェーズに必要な機能と、検索アルゴリズムの選定基準を解説します。

検索アルゴリズムには大きく分けて、意味の近さで探すベクトル検索と、語の一致で探すキーワード検索があります。ベクトル検索は「同じ意味だが言い回しが異なる」質問に強く、言葉の表現の揺れを吸収できる点が利点です。一方で、固有名詞や型番、製品コードのように、文字列の一致が重要な質問には弱いという課題を抱えています。意味だけを頼りにすると、特定の単語を含む文書を取りこぼすことがあるのです。

この弱点を補うのが、キーワード検索とベクトル検索を組み合わせたハイブリッド検索です。語の一致と意味の近さの両面から候補を取得することで、固有名詞にも言い回しの揺れにも対応できます。実証データでは、ベクトル検索のみのF1スコアが56%だったのに対し、ハイブリッド検索にリランキングを加えた構成ではF1スコアが85%まで向上し、約52%の改善が確認されています。高い回答精度を求めるなら、ハイブリッド検索は標準機能として備えるべき要素です。

検索フェーズでは、取得する候補件数を示すTop-Kというパラメータも重要な調整項目です。Top-Kを小さくすると関連文書を取りこぼすリスクがあり、大きくすると関連性の低い文書まで含まれてノイズが増えます。どの値が最適かは文書量や質問の性質によって変わるため、検索結果を確認しながら調整できる構成にしておくことが望ましいといえます。

リランキングは、検索で取得した候補を再評価し、本当に関連性の高い文書を上位へ並べ替える機能です。前述のとおり、検索の取得件数（Top-K）を増やすと関連文書を取りこぼしにくくなる一方で、無関係な文書というノイズも混ざります。このノイズをそのまま生成AIへ渡すと、回答の精度が下がる原因になります。リランキングは、取得した候補のなかから質の高いものだけを選り分ける「ふるい」の役割を果たします。

リランキングを担う機能としては、Cohere Rerankのような専用のリランキングサービスや、Cross-Encoderと呼ばれるモデルが代表的です。最初の検索では質問と文書を別々にベクトル化して大まかに候補を絞り、リランキングの段階でCross-Encoderが質問と各候補を一組ずつ突き合わせて精緻に評価します。この二段構えにより、検索の速度と精度を両立させられます。まず広めに取得し、次に厳密に絞り込むという流れが、リランキングを組み込んだ検索の基本形です。

リランキングは必須ではないものの、高精度を求める場合はハイブリッド検索とセットで導入を検討すべき機能です。前述のF1スコア85%という結果も、ハイブリッド検索とリランキングを組み合わせて得られたものでした。Top-Kを増やしてノイズが気になる場面では、リランキングの追加が精度改善の有力な選択肢になります。検索の質を一段引き上げたいときに効く機能だと理解しておくとよいでしょう。

生成フェーズの機能とプロンプト構築

検索フェーズで関連文書を取得したら、いよいよ生成フェーズに移ります。生成フェーズは、取得した文書とユーザーの質問を組み合わせて、生成AIに回答を作らせる工程です。ここで必要になるのが、プロンプト構築機能と、回答を生成する大規模言語モデル（LLM）の基盤です。検索で良い文書を取れていても、その渡し方を誤れば回答の質は下がります。生成フェーズの機能を解説します。

プロンプト構築機能は、検索で取得した文書（コンテキスト）と、ユーザーの質問を一つの指示文へまとめる機能です。生成AIに対して「以下の参考文書だけを根拠に回答してください」といった指示を添えることで、文書に基づいた回答へ誘導します。この指示の組み立て方によって、回答が参考文書に忠実になるか、AIの一般知識に流れてしまうかが変わります。プロンプトの設計は、ハルシネーション（事実と異なる生成）を抑えるための重要な制御点です。

プロンプトに含める文書量にも配慮が必要です。多くの文書を詰め込めば情報量は増えますが、LLMが一度に処理できるトークン数には上限があり、無関係な情報が多いと回答がぼやけます。リランキングで絞り込んだ質の高い文書を、過不足なく渡す設計が望まれます。出典を提示したい場合は、どの文書から回答を生成したかをプロンプトの構造に組み込んでおくと、回答に根拠リンクを添えられます。

回答を生成するLLMの基盤としては、Azure OpenAI ServiceやAWS Bedrockといったクラウドプラットフォームが代表的な選択肢です。Azure OpenAI Serviceは、Microsoftのクラウド環境上でOpenAIのモデルを利用できる基盤で、既存のAzure資産と連携しやすい点が特長です。AWS Bedrockは、複数のモデル提供元のLLMを共通のインターフェースで扱える基盤で、用途に応じてモデルを切り替えやすい構成を取れます。

基盤選定の観点は、扱うデータの機密性、既存のクラウド環境、そして必要なモデルの種類です。社内文書を扱うRAGでは、データが外部の汎用サービスへ送られない構成が求められる場面が多く、その点でAzure OpenAI ServiceやAWS Bedrockのようにクローズドな環境でLLMを利用できる基盤が選ばれます。自社のセキュリティ要件と既存基盤に合わせて、生成フェーズのプラットフォームを選ぶことが重要です。

ワークフロー設計と評価フェーズの機能

ここまで解説したインデックス化・検索・生成の各機能は、それぞれを連結したパイプラインとして動かす必要があります。その連結を担うのがワークフロー設計の機能です。また、構築したRAGがどの程度の精度で動いているかを測る評価フェーズも、品質を担保するうえで欠かせません。RAGを支えるワークフロー設計と評価の機能を解説します。

RAGの各処理を視覚的につなぎ合わせるツールとして、Difyのようなワークフロー設計プラットフォームが活用されます。Difyでは、5つの主要ノードを組み合わせてワークフローを設計します。具体的には、処理の入口となる「開始」ノード、回答を生成する「LLM」ノード、条件によって処理を分岐させる「IF/ELSE」ノード、独自処理を記述する「コード」ノード、そして結果を返す「終了」ノードです。これらをつなぐことで、検索から生成までの流れを構築できます。

ノードベースのワークフロー設計の利点は、各処理の役割が視覚的に把握できる点にあります。IF/ELSEノードを使えば、質問の種類に応じて検索方法を変えるといった分岐処理を組めますし、コードノードを使えば標準機能では足りない独自の前処理や後処理を差し込めます。RAGの構成要素をプログラムとして一から書くのではなく、ノードの組み合わせとして設計できるため、構築と調整の見通しが立てやすくなります。

RAGは構築して終わりではなく、回答の質を継続的に測定し、改善していく対象です。その測定を担うのが評価フェーズの機能で、RagasやDeepEvalといった評価フレームワークが用いられます。これらは、RAGの回答精度を定量的な指標で可視化し、どの工程に課題があるかを切り分けるための機能を提供します。感覚ではなく数値で品質を捉えられる点が、評価フェーズの価値です。

評価指標の代表例として、Ragasが提供するContext PrecisionとFaithfulnessがあります。Context Precisionは、検索フェーズで取得した文書が、質問に対してどれだけ的確だったかを測る指標です。一方Faithfulnessは、生成された回答が、参考にした文書の内容にどれだけ忠実かを測る指標で、ハルシネーションの抑制度合いを把握するのに役立ちます。前者は検索の質を、後者は生成の質を映し出すため、二つを併せて見ることでパイプラインのどこに課題があるかを特定できます。

たとえばFaithfulnessは高いのにContext Precisionが低い場合は、生成は忠実だが検索が的を外しているとわかり、チャンキングや検索アルゴリズムの見直しに着手できます。逆にContext Precisionが高いのにFaithfulnessが低ければ、検索は良いがプロンプト構築や生成側に課題があると判断できます。評価機能は、RAGの改善サイクルを回すための羅針盤であり、構築の初期段階から組み込んでおくことが望まれます。

まとめ

本記事では、RAG構築に必要な機能・標準機能を、パイプラインの流れに沿って一覧的に整理しました。インデックス化フェーズではチャンキング戦略と埋め込み生成、ベクトルデータベース（Pinecone・Weaviate・pgvector）が、検索フェーズではベクトル検索・ハイブリッド検索・リランキング（Cohere Rerank・Cross-Encoder）が中核機能となります。生成フェーズではプロンプト構築と生成LLMの基盤（Azure OpenAI Service・AWS Bedrock）が、そしてこれらを束ねるワークフロー設計（Dify）と評価フェーズ（Ragas・DeepEval）が品質を支えます。

機能選定の指針として押さえておきたいのは、検索精度がRAG全体の品質を大きく左右するという点です。実証データが示すように、ベクトル検索のみのF1スコア56%から、ハイブリッド検索とリランキングを加えた構成では85%へと約52%改善しました。回答精度に課題を感じたら、まず検索フェーズの機能構成を見直すのが定石といえます。

機能を選ぶ際に大切なのは、すべての機能を最初から盛り込むことではなく、自社の文書量や精度要件、既存のクラウド環境に照らして必要な機能を見極めることです。そのうえで、評価フェーズの指標（Context Precision・Faithfulness）を使って継続的に精度を測り、チャンキングや検索の設定を調整しながら育てていく構成を選ぶことをお勧めします。本記事で整理した機能の全体像を地図として、自社のRAGに必要な要素を取捨選択していただければ幸いです。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。