RAGとLLMの基本を理解しよう：どのように連携し、何ができるのか？
Retrieval-Augmented Generation（RAG）は、
言語モデルが生成する回答に外部の知識ベースから検索した情報を組み合わせる手法です。
ユーザーからの質問に対してまず関連ドキュメントをベクトルストアなどから取得し、
その結果をプロンプトに注入して言語モデルに与えることで、
学習データだけに依存しない最新かつ正確な回答を得られます。
これにより、
ファインチューニングでは困難な頻繁な情報更新や、
特定ドメインの深い知識要求にも柔軟に対応可能になります。
2026年5月時点では、
OpenAIのFile SearchやRetrieval APIがベクトルストア上でsemantic searchとkeyword searchを組み合わせたハイブリッド検索を提供し、
query rewriting、
attribute filtering、
ranking options、
max_num_resultsの指定が行えます。
ベクトルストアへのファイル追加時には自動でchunking、
embedding、
indexingが行われ、
デフォルトのチャンクサイズは800トークン、
オーバーラップは400トークンです。
これにより長いドキュメントでも適切な単位でベクトル化され、
検索精度と効率のバランスが取れます。
また、
OpenAIのエンベディングモデルとしてtext-embedding-3-small（1536次元）およびtext-embedding-3-large（3072次元）が主流です。
多言語性能とコスト効率が改善されており、
dimensionsパラメータでベクトル次元の調整も可能です。
たとえば、
日本語ドキュメント中心でも1536次元で十分な表現力が得られ、
コストを抑えたい場合は小さな次元に設定できます。
cosine similarityが推奨される距離関数となっています。
AnthropicのContextual Retrievalではドキュメント回答でcitationsを有効化することで回答の根拠となる文書の場所を示すことができますが、
structured outputsとは同時に使用できません。
これは、
引用情報を含む出力構造がAPI側でサポートされていないためです。
Vertex AI RAG Engineはingestion→transformation→embedding→corpus indexing→retrieval→generationの流れがあり、
プライベートデータを追加コンテキストとして渡すことでgrounded responseを得る考え方が重要です。
これにより、
機密文書や社内限定ナレッジを安全に活用しながら、
言語モデルの生成品質を向上させることができます。
実践：RAGを使った質問応答システムの構築手順
まずは対象とするユースケースを明確にし、
ナレッジソースを選定します。
たとえば社内FAQ、
製品マニュアル、
規程集など、
質問が繰り返し発生し回答の正確性が重要なドキュメントから始めると効果が見えやすいです。
ドキュメント収集後はPDFやWordから本文テキストを抽出し、
重複除去、
ヘッダー・フッター削除、
目次やページ番号などの意味の薄い定型文の除去といった前処理を行います。
この段階でメタデータとして文書種別、
部門、
更新日、
バージョン番号、
公開範囲などを付与しておくと、
後から属性フィルタリングで検索結果を絞り込む際に役立ちます。
次にチャンク設計を行います。
見出し単位や段落単位を基本とし、
文書構造に合わせて400〜800トークン程度から試して必要に応じてオーバーラップを調整します。
たとえばマニュアルの場合は見出しごとにチャンクを分け、
FAQ形式のドキュメントはQ&Aペアごとにチャンクすると検索精度が向上します。
OpenAI File Searchを利用する場合はこのチャンク作業を自動化できますが、
カスタムベクトルDBを使用する場合は自前で実装する必要があります。
メタデータは各チャンクに付与し、
たとえば「部門=営業」や「製品ライン=Xシリーズ」といったフィルタリング条件を検索時に指定できるようにします。
埋め込み生成とインデックス登録では、
選んだエンベディングモデルで各チャンクのベクトルを計算し、
ベクトルストアに登録します。
OpenAIのtext-embedding-3-smallや-largeをAPI経由で呼び出すと、
バッチ処理により効率的にエンベディングを取得できます。
ベクトルストアにはFAISS、
Milvus、
Pinecone、
OpenAIのベクトルストアなどがあり、
インデックスの作成と更新を適切に管理します。
検索フェーズではユーザークエリを同じエンベディングモデルでベクトル化し、
トップK件の類似チャンクを取得します。
ここでquery rewritingにより曖昧なクエリをより具体的な検索クエリに変換し、
attribute filteringでメタデータ条件を適用し、
ranking optionsでスコア調整を行います。
必要に応じて再ランキング（rerank）ステップを追加し、
Cross-Encoderなどで関連度精度をさらに向上させます。
最後に取得したチャンクをプロンプトに組み込み、
言語モデルに与えて回答を生成します。
LLMの性能を引き出すRAG活用のコツと注意点
RAGの効果を最大限に引き出すためには、
検索品質と生成品質の両方をバランスよく最適化することが重要です。
検索側ではHit RateやMRR（Mean Reciprocal Rank）などの指標を定期的に測定し、
チャンクサイズやオーバーラップ、
埋め込みモデルの選択を見直します。
たとえばチャンクが大きすぎるとノイズが増え、
小さすぎると文脈が切れてしまうため、
実データでの評価に基づいて調整します。
また、
metadata filteringを活用してユーザーの役割や部門に応じて検索対象を動的に変更することで、
関連しない情報の混入を防ぎます。
生成側ではプロンプト設計が鍵となります。
検索結果をどのように言語モデルに渡すかは、
回答の正確性と根拠の明示に直結します。
たとえば「以下の文書に基づいて質問に答えてください。
文書：
{チャンク1}\n{チャンク2}\n…」という形式で明確に区切りを入れると、
モデルが参照すべき範囲を理解しやすくなります。
また、
Anthropicのcitationsを有効にすると回答の最後に自動的に参照文書の情報が付与され、
ユーザーが出典を確認しやすくなりますが、
structured outputsとは同時に使用できない点に注意が必要です。
このため、
出力形式が厳格に決まっているケースではcitationsをオフにし、
代わりに回答中に参照文書のタイトルや改訂日を明示する工夫が求められます。
評価と改善のループを回すことも欠かせません。
オフラインでは事前に用意した質問と回答のペアセットでExact MatchやCitation Recallなどの指標を測定し、
オンラインでは実際のユーザーからのフィードバックや修正ログを収集します。
たとえばサポートチャットではエージェントがAIの回答を編集した履歴を分析し、
どの種類の質問で修正が多いかを特定します。
このフィードバックをもとにナレッジベースの更新優先順位を決めたり、
チャンク設計や再ランキングのパラメータを調整したりします。
さらに、
権限管理も運用段階では重要です。
特に財務データや個人情報を含む文書については、
ユーザーの役割に応じて検索結果をフィルタリングする仕組みが必須で、
属性フィルタリングやアクセス制御ポリシーを適切に設定します。
AI開発を楽しむために：トラブルシューティングと継続的な改善
実際の運用では予期しない問題が発生することがありますが、
体系的に切り分けて対処することで安定したサービスを維持できます。
まずはレイテンシが高い場合のチェックポイントです。
埋め込み生成の遅延、
ベクトルストアの検索時間、
プロンプト組み立てとLLM呼び出しの応答時間、
それぞれを個別に測定してボトルネックを特定します。
たとえばベクトルストアの検索が遅い場合はインデックスの再構築や、
適切なパーティショニング、
ハードウェアリソースの見直しを検討します。
また、
よく使われるクエリの結果をキャッシュする戦略（プロンプトキャッシュや検索結果キャッシュ）を導入すれば、
繰り返し同じ質問が飛んでくるサポートデスクでの応答速度を大幅に改善できます。
次に回答の品質が低下している場合の調査方法です。
まずは検索結果が関連しているかを確認します。
Hit Rateが低下しているなら、
チャンクサイズやオーバーラップ、
クエリ書き換えロジック、
または埋め込みモデル自体の見直しが必要です。
逆に検索結果は良いが回答が間違っているケースでは、
プロンプト設計や言語モデルのパラメータ（temperatureやtop_pなど）を調整します。
また、
hallucination（幻覚）が目立つ場合は、
検索結果の長さを制限し、
ノイズの少ないチャンクを優先的に渡すようにプロンプトを工夫します。
Anthropicのcitationsを活用すれば、
回答の根拠がどこにあるかを明示できるため、
ユーザー自身が情報の正当性を判断しやすくなります。
最後に継続的な改善サイクルを回すための仕組み作りが重要です。
定期的に（たとえば週次または月次）ナレッジベースの品質監査を行い、
古い情報や重複ファイル、
フォーマットのばらつきをチェックします。
また、
ドキュメント追加や更新の手順をマニュアル化し、
担当者間で共有することで属人化を防ぎます。
さらに、
利用ログから検索クエリのトレンドを分析し、
新たに追加すべきナレッジや既存ドキュメントの改訂ポイントを可視化します。
このように「検索→生成→フィードバック→改善」のループを回すことで、
RAGシステムは時間とともに精度と使いやすさを向上させていきます。
ぜひ貴社の開発現場でも、
小さなパイロットから始めて、
少しずつ改善を重ねてみてください。
詳しくはこちら お問い合わせ
まとめ
RAGとLLMの設計では、
検索品質・プロンプト設計・評価運用を一体で見直すことが成功の近道です。
小さなPoCから始め、
ログとフィードバックを使って継続改善することで、
実務で使える精度へ育てられます。
詳しくはこちら お問い合わせ をご活用ください。
