技術

RAGとは

Q: RAGにはファインチューニングが必要？

不要。 一般に、既製の凍結されたLLMと検索パイプラインの組み合わせで機能する。

検索拡張生成 / Retrieval-Augmented Generation

検索(Retrieval)と生成モデルを組み合わせ、外部知識に基づいて出力を根拠づける手法

NLP 検索 LLM

ひとことで言うと

AIが答える前に、関連する文書を検索してから回答を作る仕組み。最新情報や社内資料をもとに答えられるようになる。

概要

検索拡張生成(RAG)は、外部知識源(社内文書・Webページ・データベース等)から質問に関連する文書をあらかじめ検索し、その検索結果をプロンプトのコンテキストとしてLLMに与えたうえで回答を生成させる手法。 LLM単体では学習時点の知識しか持たず、企業固有の情報や学習後に発生した最新情報には対応できないが、RAGは推論のたびに外部データベースを参照するため、モデル自体を再学習せずに知識を常に最新化できる。文書をベクトル化して類似度検索する「ベクトル検索型」が主流だが、キーワード検索や構造化データへのクエリと組み合わせるハイブリッド構成も広く使われる。生成結果に出典を明示しやすく、ハルシネーション対策としても有効なため、企業向けチャットボットやドキュメント検索アシスタントの標準的な実装パターンになっている。

背景

RAGはLLMが持つ静的な知識とハルシネーションの限界に対処する。推論時に最新または領域固有の外部データを参照させることで解決する。

歴史

2020年: Lewis らが知識集約型NLPタスク向けにRAGを提案。 2023-2024年: ベクトルデータベースを介したRAGがエンタープライズLLMアプリの標準パターンに。

アーキテクチャ

クエリエンコーダ → インデックス化された文書ストアに対するベクトル類似度検索 → 検索されたパッセージをLLMプロンプトへ挿入 → 生成。

ワークフロー

文書の取り込み → チャンク分割と埋め込み → ベクトルインデックスへの格納 → クエリ時にtop-kチャンクを検索 → 検索結果を条件として回答生成。

コード例

基本的なRAG検索ステップ

results = vector_store.similarity_search(query, k=4)
context = "\n".join(r.page_content for r in results)
prompt = f"Answer using this context:\n{context}\n\nQuestion: {query}"

利点

検索した根拠に基づくことでハルシネーションを低減
モデルを再学習せずに知識を更新できる
出典の提示に対応できる

欠点

検索精度が回答品質全体のボトルネックになる
ベクトルDB・インデックス構築など追加のインフラと遅延が発生する

比較

ファインチューニング — RAGは推論時に知識を注入する。ファインチューニングは知識をモデル重みに焼き込む
ハルシネーション — RAGは検索結果に基づいて回答を根拠づけることで、ハルシネーションを低減する手法として使われる
コンテキストウィンドウ — RAGはコンテキストウィンドウに収まる範囲だけを都度検索して補うことで、上限を超える知識にも対応する
ベクトルデータベース — RAGでは、関連文書を検索する基盤としてベクトルデータベースがよく使われる
チャンキング — チャンキングの質は、RAGの検索精度に直接影響する
ハイブリッド検索 — ハイブリッド検索は、RAGの検索精度を高める代表的な手法の1つ
リランカー — RAGパイプラインでは、初期検索の結果をリランカーで並べ替え精度を高めることがある
エージェントメモリ — 長期記憶の実装は、必要な情報を検索して取り出すという点でRAGと共通の技術基盤を使うことが多い
LangChain — LangChainは、RAGパイプラインを構築するための代表的なフレームワークの1つ
Haystack — Haystackは、RAGパイプラインを構築するための代表的なフレームワークの1つ

よくある質問

RAGにはファインチューニングが必要？

不要。一般に、既製の凍結されたLLMと検索パイプラインの組み合わせで機能する。

参考文献

Research PaperRetrieval-Augmented Generation for Knowledge-Intensive NLP Tasks