RAGとは?社内データを活用したAI検索の仕組みと導入方法
BlueAI編集部
著者
BlueAI編集部
監修
この記事は以下のまとめ記事の一部です
AI開発会社の選び方|依頼前に確認すべき5つのポイントRAGとは?社内データを活用したAI検索の仕組みと導入方法
ChatGPTなどの大規模言語モデル(LLM)は非常に強力ですが、「自社固有の情報に基づいた回答」はできません。LLMが持つ知識は学習データに基づいた一般的な情報であり、御社の社内規定、製品マニュアル、過去の提案書などは含まれていないからです。
この課題を解決するのが**RAG(Retrieval-Augmented Generation、検索拡張生成)**です。本記事では、RAGの仕組みから導入方法、費用まで、実践的な知見をもとに解説します。
RAGとは
RAGとは、LLMに外部のナレッジソース(社内ドキュメントやデータベース)から検索した情報を渡し、その情報に基づいて回答を生成する技術です。
通常のLLMとRAGの違いを簡単に示すと、以下のようになります。
通常のLLM:
- ユーザーの質問 → LLMが学習済みの知識から回答
RAGを導入したLLM:
- ユーザーの質問 → 関連する社内ドキュメントを検索 → 検索結果をLLMに渡す → 社内データに基づいた回答を生成
RAGの主なメリット
- 最新情報への対応: LLMの学習データのカットオフに関係なく、最新のドキュメントに基づいた回答が可能
- ハルシネーションの抑制: ソースとなるドキュメントが存在するため、AIの「嘘」を減らせる
- カスタマイズの容易さ: Fine-tuning(追加学習)と比較して、低コスト・短期間で導入可能
- データの管理性: ナレッジソースを更新するだけでAIの知識を更新できる
RAGの仕組み
RAGシステムは大きく3つのフェーズで構成されます。
フェーズ1:インデキシング(前処理)
社内ドキュメントをAIが検索しやすい形に変換する工程です。
1. ドキュメント分割(チャンキング)
長文のドキュメントを適切なサイズのチャンク(断片)に分割します。チャンクのサイズは500〜1,000トークン程度が一般的ですが、ドキュメントの特性に応じて調整が必要です。
2. ベクトル化(エンベディング)
各チャンクをベクトル(数値の配列)に変換します。これにより、テキストの意味的な類似度を数値で計算できるようになります。OpenAIのtext-embedding-3-smallやCohereのEmbed v3などのモデルが使われます。
3. ベクトルデータベースへの格納
変換したベクトルをベクトルデータベースに格納します。Pinecone、Weaviate、Qdrant、pgvector(PostgreSQL拡張)などが代表的です。
フェーズ2:検索(リトリーバル)
ユーザーの質問に関連するドキュメントチャンクを検索する工程です。
1. クエリのベクトル化
ユーザーの質問をベクトルに変換します(インデキシングと同じエンベディングモデルを使用)。
2. 類似度検索
質問ベクトルとドキュメントベクトルのコサイン類似度を計算し、最も関連性の高いチャンクを取得します。
3. リランキング(任意)
検索結果の精度を高めるために、クロスエンコーダモデルで再順位付けを行います。
フェーズ3:生成
検索結果をLLMに渡して回答を生成する工程です。
プロンプト例:
以下のコンテキスト情報をもとに、ユーザーの質問に回答してください。
コンテキストに情報がない場合は「情報が見つかりませんでした」と回答してください。
[コンテキスト]
{検索で取得したドキュメントチャンク}
[質問]
{ユーザーの質問}
RAG導入の具体的なステップ
Step 1:対象ドキュメントの整理
まず、AIに活用したい社内ドキュメントを整理します。
- 社内規定・マニュアル
- 製品ドキュメント
- FAQ・Q&A集
- 過去の提案書・レポート
- 議事録
重要なポイント: ドキュメントの品質がRAGの精度を直接左右します。古い情報、矛盾する情報、フォーマットの不統一は、検索精度を下げる原因になります。
Step 2:チャンキング戦略の設計
ドキュメントの特性に応じた分割方法を選択します。
- 固定サイズ分割: 一定のトークン数で機械的に分割。シンプルだが意味の切れ目を考慮しない
- 意味ベース分割: 段落や章の区切りで分割。ドキュメントの構造を活かせる
- 再帰的分割: 段落→文→単語の順で適切なサイズになるまで再帰的に分割
Step 3:ベクトルデータベースの選定
| データベース | 特徴 | 適したケース | |-------------|------|-------------| | Pinecone | フルマネージド、スケーラビリティ高 | 大規模な本番環境 | | Weaviate | オープンソース、ハイブリッド検索 | 柔軟なカスタマイズが必要な場合 | | Qdrant | 高速、オープンソース | パフォーマンス重視 | | pgvector | PostgreSQL拡張、既存DBとの統合 | 既存のPostgreSQL環境がある場合 |
Step 4:評価と改善
RAGシステムの品質を評価するためには、以下の指標を使います。
- 検索精度(Retrieval Precision): 関連するドキュメントが正しく取得されているか
- 回答の正確性(Answer Accuracy): 生成された回答が正しいか
- 網羅性(Coverage): 質問に対して必要な情報が漏れなく含まれているか
- ハルシネーション率: ソースに基づかない情報がどの程度含まれるか
RAG導入の費用感
初期構築費用
| 規模 | 費用目安 | 期間 | |------|---------|------| | PoC(100文書程度) | 100万〜200万円 | 2〜4週間 | | 中規模(1,000文書) | 300万〜800万円 | 2〜4ヶ月 | | 大規模(10,000文書以上) | 800万〜2,000万円 | 4〜8ヶ月 |
月額運用費用の目安
- LLM API費用: 3万〜30万円(利用量により変動)
- ベクトルDB費用: 1万〜10万円
- インフラ費用: 2万〜20万円
- 保守・改善: 10万〜50万円
BlueAIのRAG構築実績
BlueAIでは、自社プロダクト「マルナゲシリーズ」においてRAGシステムを活用しています。
- マルナゲCRM: 過去の商談履歴や顧客情報をRAGで検索し、営業担当者への提案支援を実現
- 社内ナレッジ検索: 社内ドキュメント(規定、マニュアル、議事録)を横断検索するAI検索システム
これらの自社運用経験から、チャンキング戦略の最適化、検索精度の改善、コスト最適化のノウハウを蓄積しています。
RAG導入時のよくある課題と対策
課題1:検索精度が低い
原因: チャンクサイズが不適切、エンベディングモデルの選定ミス 対策: チャンクサイズの調整、ハイブリッド検索(ベクトル検索+キーワード検索)の導入、リランキングの追加
課題2:ハルシネーションが発生する
原因: プロンプト設計の問題、コンテキスト情報の不足 対策: プロンプトで「ソースに基づいて回答すること」を明示、引用元の表示、コンフィデンススコアの活用
課題3:ドキュメントの更新が追いつかない
原因: 手動更新に依存している 対策: ドキュメント更新時に自動でインデキシングが走るパイプラインの構築
まとめ
RAGは、LLMに「自社の知識」を持たせるための最も実用的なアプローチです。Fine-tuningと比較して低コスト・短期間で導入でき、ドキュメントを更新するだけでAIの知識を最新に保てるという大きなメリットがあります。
導入を成功させるポイントは以下の3つです。
- ドキュメントの品質を確保する: ゴミを入れればゴミが出る。データ整備が最重要
- 段階的に導入する: PoCで効果を検証し、段階的に拡大する
- 継続的に改善する: 検索精度と回答品質のモニタリング・改善サイクルを回す
RAG導入に関するご相談は、お気軽にお問い合わせください。BlueAIが、PoCから本番導入まで一貫してサポートいたします。