基本的なRAGと進化したRAGの違いは何ですか

基本的なRAGはベクトル検索で関連文書を取得してLLMに渡す構成です。進化版ではキーワード検索との組み合わせ（ハイブリッド検索）、取得した文書の順位再計算（リランキング）、文書間の関係性を活用するグラフRAGなどが加わり、従来の手法では見つけられなかった関連情報を取得できます。

グラフRAGはどのようなケースで効果がありますか

複数の文書にまたがる関係性を辿る必要がある質問に効果があります。たとえば「AプロジェクトとBプロジェクトで共通している課題は何か」のような質問は、ベクトル検索だけでは文書間の関係を把握しきれませんが、グラフ構造で文書間のつながりを事前に構築しておくことで精度が上がります。

社内ナレッジにRAGを導入する際の費用感はどのくらいですか

クラウドサービスを使う場合、文書のベクトル化（エンベディング）費用とベクトルDBのストレージ費用が主なコストです。文書数万件規模であれば月数千〜数万円程度とされますが、LLMのAPIコール数や文書のサイズによって大きく変わります。最新の料金は各サービスの公式ページで確認してほしい。

RAGで精度が上がらない場合、まず確認すべき点は何ですか

まずチャンク分割の方法を確認してください。文書を細かく切りすぎると文脈が失われ、大きすぎると無関係な情報が混入します。次に検索クエリと文書の表現のズレ（専門用語の違い等）を確認し、ハイブリッド検索やリランキングの導入を検討してください。

RAGの進化と社内ナレッジ活用の最新手法

RAGの基本は「検索して渡す」だが、それだけでは精度に限界がある

RAGの基本的な構成は「質問に関連する文書をベクトルDBから取得し、LLMに文脈として渡して回答させる」というものだ。この構成は社内文書検索の用途に広く使われているが、実装してみると「欲しい情報が取得できない」「関係ない文書が混入する」という問題に直面することが多い。

RAGとは何かで基本概念を押さえたうえで、本記事ではその先の精度改善アプローチを解説する。

基本RAGの3つの限界

限界1: ベクトル検索の意味的なズレ

ベクトル検索は意味的な類似度で文書を取得するが、表現の差異による検索漏れが起きやすい。「売上高」と「収益」、「NDA」と「秘密保持契約」のように、同じ意味でも単語が違う場合に関連文書を見逃す。

限界2: 文書のチャンク分割による文脈の断絶

長い文書を一定サイズで分割してベクトル化する際、論理的な区切りと無関係な位置で切ると文脈が失われる。「この施策の背景は〜」という記述が前のチャンクに、「結果は〜」という記述が後のチャンクに分かれた場合、どちらを取得しても情報が不完全になる。

限界3: 複数文書にわたる情報の統合が苦手

「プロジェクトAの課題とプロジェクトBの共通点は何か」のような質問は、複数文書の横断的な読み込みが必要だ。ベクトル検索で上位文書を取得するだけでは、文書間の関係性が見えない。

精度を高める5つのアプローチ

1. ハイブリッド検索

ベクトル検索とキーワード検索（BM25等）を組み合わせる手法だ。ベクトル検索は意味的な類似度に強く、キーワード検索は固有名詞・略語・型番など完全一致の語に強い。両方の結果を組み合わせることで、どちらか一方だけでは漏れる情報をカバーできる。

Elasticsearch、Azure AI Search、Weaviateなど主要なベクトルDB・検索エンジンはハイブリッド検索に対応しており、追加の開発コストは比較的小さい。最新の対応状況は各ツールの公式ドキュメントで確認してほしい。

2. リランキング

初期検索で取得した文書群を、より精度の高いモデルで再スコアリングする手法だ。ベクトル検索は高速だが粗く、リランキングモデルは低速だが精度が高い。粗い検索で候補を絞り、リランキングで順位を整理するという2段階構成により、精度と速度を両立させる。

CohereのRerank、BGM-Rerankerなどが実際に使われているモデルだが、最新の選択肢と性能は公式情報で確認してほしい。

3. グラフRAG

文書間の関係をグラフ構造として事前に構築し、検索時に関係性を辿る手法だ。Microsoftが2024年に発表した手法として注目を集めた。「AドキュメントとBドキュメントを橋渡しするCドキュメント」というような間接的な関連を取得できるのが特徴だ。

構築コストが高く、文書が頻繁に更新される環境では運用が複雑になる。大量の非構造化文書から横断的な知識を引き出す用途（技術文書・研究レポートの横断検索等）に効果が出やすいとされている。

4. 改良されたチャンク戦略

固定サイズではなく、以下のような意味的・構造的な区切りでチャンクを作ることで文脈の断絶を減らせる。

セクション単位: 見出し・段落の区切りを優先する
Parentチャンク: 検索は小さいチャンクで行い、取得後に前後のコンテキストも含めて大きい単位でLLMに渡す
文書メタデータの付与: 作成日・部門・文書種類をチャンクに付けておき、フィルタリングで絞り込めるようにする

5. クエリの前処理・拡張

入力質問をそのまま検索クエリにするのではなく、LLMを使って質問を検索しやすい形に言い換える手法だ。

HyDE（Hypothetical Document Embeddings）: 仮の回答文を生成し、その回答をクエリとして検索する
クエリ分解: 複雑な質問を単純な複数クエリに分解して並列検索し、結果を統合する
同義語展開: 業界用語・略語の表現ゆれを吸収してから検索する

社内ナレッジ活用に向いているアプローチの選び方

状況	推奨アプローチ
まず試してみたい	基本RAG + ハイブリッド検索
固有名詞・型番が多い	ハイブリッド検索を優先
文書間の横断検索が必要	グラフRAG（構築コスト要確認）
検索精度が低くて困っている	リランキング導入
質問の表現ゆれが多い	クエリ前処理 + ハイブリッド検索

導入コスト感

RAGシステムの費用は主に以下の要素で構成される。

エンベディング費用: 文書をベクトルに変換する際の費用。OpenAIのtext-embedding-3-smallは1,000トークンあたり$0.00002とされているが、最新の料金は公式ページで確認してほしい。文書数万件規模では初回のベクトル化は数千円〜数万円程度と試算されることが多い。

ベクトルDB費用: Pinecone、Weaviate、Qdrantなどはホスティングサービスを提供しており、小規模なら無料枠の範囲で試せる。本番規模になると月数千円〜数十万円とサービスや規模によって大きく差がある。

LLMのAPIコール費用: ユーザーが質問するたびにLLMのAPIを呼ぶため、利用量に比例してコストが増える。

開発・運用コスト: グラフRAGやリランキングの実装は追加の開発工数が必要だ。既製品のソリューションを使う場合はベンダー費用がかかる。

社内文書を検索できるAIツールでは、すぐに使えるサービス選定の観点をまとめている。

まとめ

基本的なRAGは社内文書検索の起点として有効だが、精度の限界に直面することが多い。ハイブリッド検索・リランキング・改良されたチャンク戦略は、既存のRAGに追加する形で精度を改善できる現実的な手段だ。

グラフRAGやAgentic RAGは効果が大きい反面、構築コストと運用複雑度が上がるため、規模と要件に合わせた段階的な導入が現実的だ。まずハイブリッド検索とリランキングで精度を改善し、それでも解決しない問題に対してより高度な手法を検討するというアプローチが多くの現場で取られている。

RAGの進化と社内ナレッジ活用の最新手法

RAGの基本は「検索して渡す」だが、それだけでは精度に限界がある