RAG(検索拡張生成)とは?
RAGとは、質問に関連する文書を検索(Retrieval)して取り出し、それをLLMに渡して回答を生成(Generation)させる仕組みのこと。社内文書やマニュアルなど、AIが学習していない情報に基づいて答えさせる標準的な手法です。
実務での使い方
「社内規定について答えるチャットボット」「製品マニュアルQ&A」など、企業のAI活用で最も多い構成の一つです。モデル自体を再学習(ファインチューニング)するより低コストで、情報の更新も元文書の差し替えだけで済みます。
品質を左右するのは生成よりも検索側です。文書の分割方法、検索の精度、関連文書が見つからなかったときの挙動(「わからない」と答えさせる)の設計が重要で、ハルシネーション対策としても「出典の文書を一緒に表示する」ことが信頼性を高めます。
エンベディング(埋め込み)とは?RAGの検索を支える仕組み
エンベディング(埋め込み)とは、文章や画像の意味を数百〜数千個の数値の並び(ベクトル)に変換する技術です。「意味が近いデータはベクトルも近くなる」性質を持ち、RAGの検索部分はこの性質の上に成り立っています。
社内文書をあらかじめエンベディング化して保存しておき、質問文も同じくベクトル化して「意味が近い文書」を探します。キーワードが一致しなくても「解約」と「契約終了」を近い意味として扱えるのが、従来の全文検索との違いです。
実務では専用のエンベディングモデル(API)を使い、料金は文章生成よりも大幅に安価です。ただしモデルによって日本語の精度に差があるため、RAGの検索品質が悪いときは、文書の分割方法とあわせてエンベディングモデルの見直しも検討ポイントになります。
ベクトルデータベースは何をしているのか
ベクトルデータベースとは、エンベディング化したデータ(ベクトル)を保存し、意味の近さで高速に検索できるデータベースです。RAG構築の中核部品にあたります。
RAG構築の流れは、①文書を適切な長さに分割②エンベディング化してベクトルDBに格納③質問と意味が近い文書を取り出してLLMに渡す、の3段階で、ベクトルDBは②③を担います。専用サービスのほか、PostgreSQLの拡張(pgvector)など既存データベースのベクトル検索対応も進んでいます。
数百件程度の文書なら専用のベクトルDBを立てるまでもないことも多く、規模と更新頻度で選定します。また検索精度はデータベース自体よりも、文書の分割(チャンク)設計とエンベディングモデルの質に左右されるため、精度改善はまずそちらから着手するのが定石です。
RAG構築の流れ。品質を左右するのは生成よりも検索側で、精度改善はまず文書の分割設計とエンベディングモデルから着手する。
ファインチューニングとは?RAGとの違い
ファインチューニングとは、既存のLLMに自社のデータを追加学習させ、特定の用途・文体・形式に合わせて調整すること。モデルの振る舞い自体を変える手法で、知識の追加にはRAG、振る舞いの調整にはファインチューニングが向くとされます。
向いているのは「出力形式や文体を一貫させたい」「特定タスクの精度を上げたい」場合です。一方、「最新の社内情報に基づいて答えさせたい」だけならRAGの方が低コストで、情報更新のたびに再学習が必要になるファインチューニングは不利です。
実務では、まずプロンプトの工夫→次にRAG→それでも足りなければファインチューニング、の順で検討するのが定石です。多くの業務用途はプロンプトとRAGで十分な品質に達するため、ファインチューニングが必要なケースは実際には限られます。