RAG とは何ですか? なぜ必要ですか? — RAG および AI エージェント

利益:

RAG はモデルの重みを変更せずにコンテキストを挿入し、「オープンブック試験」ロジックで動作することを説明します。
コスト、適時性、使用シナリオに応じた微調整アプローチとロングコンテキストアプローチによる RAG の比較
インデックス作成フェーズとクエリフェーズで構成される一般的な RAG パイプラインのステップのリスト

言語モデル (テキストを理解して生成する人工知能。今後は略してモデルと呼びます) がどれほど強力であっても、会社が昨日署名した契約、社内 Wiki (内部ナレッジベース) ページ、または今朝公開されたリリースノートを認識することはできません。モデルは、トレーニングされた日までの一般的な知識に限定されます。これを「教育の打ち切り日」といいます。 RAG (検索拡張生成) は、まさにこのギャップを埋めます。質問に関連する企業ドキュメントを検索し、それをコンテキスト (つまり、回答を生成するときに読み取られる追加のテキスト) としてモデルに与え、このコンテキストに基づいて回答を生成します。

この単元では、RAG とは何か、どの代替手段よりも RAG が優先されるのか、そして典型的な RAG パイプラインのステップを明確に理解します。後続のユニットはすべて、このマップの部分を 1 つずつ深めていきます。

RAG の基本的な考え方: オープンブック試験

RAG を一文で説明しましょう。「まず関連するドキュメントを検索し、次にモデルにそのドキュメントを読み取らせ、それに応じて答えを出力します。」

最も役立つ例えは次のとおりです。RAG はモデルを「クローズドブック試験」から「オープンブック試験」に移行します。クローズドブック試験では、学生は記憶だけで答えます。覚えていないことをでっち上げる危険性が高くなります。オープンブック試験では、生徒は目の前に置かれた資料を見て解答します。 RAG では、モデルはそれ自体の記憶からではなく、与えられた現在の特定のテキストから応答します。

重要な点: RAG はモデルの重み、つまりモデルが学習した数十億の数値パラメーターを変更しません。モデルを再トレーニングすることはありません。質問ごとに、その質問に関連するテキストのチャンクをプロンプト (モデルに送信される指示テキスト) に挿入します。したがって、ドキュメントが更新されたときにモデルを再トレーニングする必要はありません。検索データベース内の関連レコードを更新するだけです。

ヒント: RAG の品質は 2 つの質問によって決まります: (1) 適切なドキュメントは見つかりましたか? (2) モデルは正しく読み取ったか? 1つ目は「検索品質」、2つ目は「生成品質」です。 2 つは別々に測定および改善されます。

RAG、微調整、それとも長いコンテキスト?

組織の問題の解決策を探すとき、3 つの道が混同されることがよくあります。それらの違いを明確にしてみましょう。微調整とは、モデルの重みをデータで更新し、新しい動作/スタイルを教えることです。長いコンテキストとは、何も選択せずにすべてのドキュメントをプロンプトに直接入力することを意味します。

アプローチ

どういうことですか

いつが適切ですか?

コスト/リスク

ラグ

関連するドキュメントをコンテキストとして挿入します

頻繁に変更される広範かつ具体的な情報

低い;更新が簡単、ソースを引用できる

微調整

新しいデータで重みを更新します

固定されたスタイル/形式/言語指導

高い。アップデートのたびに再トレーニングが必要

長いコンテキストのみ

すべてのドキュメントをプロンプトに入力します

小型の固定ドキュメントセット

トークンコストと「中間部分を失う」リスクが増加

原則として: 微調整はモデルに話し方を教えます。 RAG はモデルに知っておくべきことを伝えます。ほとんどのエンタープライズシナリオでは、安価で更新可能で、答えのソースを示すことができる RAG が最初に試行されます。文書セットが非常に小さく固定されている場合 (例: 20 ページの単一マニュアル)、長いコンテキストは合理的です。しかし、数千ページになるとコストがかかり、モデルでは長いテキストの途中にある情報が失われる可能性があります。

典型的な RAG パイプライン

RAG は、インデックス作成 (準備、1 回または定期的に実行) とクエリ作成 (ユーザーの質問ごとに実行) の 2 つの主なフェーズで構成されます。

ステップバイステップのインデックス作成 (オフライン、ユーザーの待ち時間なし):

収集: ソース (PDF、Wiki、チケットシステム、データベース、電子メール) からドキュメントを取得します。
チャンク化: 長いテキストを、扱いやすい小さな部分に分割します。
埋め込み: 各部分を埋め込み (テキストの意味を伝える数値ベクトル) に変換します。
保存: ベクターをテキストおよびメタデータ (ソース、日付、認証情報) とともにベクターデータベースに書き込みます。

ステップバイステップのクエリ (オンライン、ユーザーが待機している間):

ユーザーの質問を埋め込みに変換します。
ベクトルデータベースから最も類似した部品を取得します。
これらの部分と質問をプロンプトテンプレートに配置します。
モデルから状況に応じた答えとそのソースを取得します。

# 調査フェーズの概念的な概要 (言語には依存しません)question = "年次休暇は何日ですか?"question_vektor = embed(question)parts = vektor_db.search(question_vektor, top_k=4) # 最も類似したpartsprompt = f"""以下の文脈を使用して質問に答えてください。答えが文脈にない場合は、「これに関する情報がありません。」と言ってください。 Fitting.CONTEXT:{parts}QUESTION: {question}"""answer = model.uret(prompt) # 例:モデル: クロード-作品-4-8

このフローは各ステージのマップであり、後続の単元で 1 つずつ紐解いていきます。

弱いプロンプト / 強いプロンプト

同じ RAG コンテキストであっても、プロンプトの品質によって答えが変わります。

弱いプロンプト (モデルフィッティングにオープン、リソースを必要としません):

この情報を使用して、年次休暇: {parts} と入力します。質問: {質問}

強力なプロンプト (グラウンディング + 「わかりません」権限 + リソース要求):

以下の文脈にのみ基づいて回答してください。文脈に明確な答えがない場合は、「これに関する情報がドキュメントで見つかりませんでした」と書きます。推測しないでください。回答の最後に、依存している部分の [Source: file_name] タグを追加します。コンテキスト: {個} 質問: {質問}

ミニケース3個

ケース 1 — 人事アシスタント (人事)。ある企業には 340 ページの人事ハンドブックがあり、従業員は 1 日平均 90 件の質問をします。微調整を試みましたが、マニュアルが毎月更新されるため、その度に再トレーニングが必要でした。その費用は月額数千ドルに達しました。 RAG に切り替えた後、更新は「ドキュメントの再インデックス付け」ステップ (分) に短縮され、手動測定の正答率は 71% から 93% に増加しました。

ケース 2 — カスタマーサポート。サポートチームには 12,000 件の解決済みチケットと 800 件のヘルプ記事があります。担当者が手動で回答を見つけるのに平均 4 分かかります。 RAG アシスタントが最も関連性の高い 5 つの記録を持参し、回答草案を作成したところ、時間は 40 秒に短縮されました。しかしチームは「間違った記事を持ち込むことで自信がないと思われる」リスクを認識し、出典の引用を必須とした。

ケース 3 — 法律。契約チームは「機密保持条項が5年間続くのはどの契約ですか？」と質問した。彼は質問します。長期にわたるトライアルでは、60 件の契約が 1 つのプロンプトに入力されました。モデルは中間の 2 つの契約をスキップしました。 RAGで該当項目のみを導入したところ、トークンコストが80%減少し、欠落していたスキップがリセットされました。

なぜ RAG が必要なのでしょうか?

最新性: トレーニングの締め切り日以降に情報にアクセスします。
特別な情報: 内部文書はモデルのトレーニングには含まれません。あなただけが与えることができます。
検証可能性: 回答の出典を引用することができます (引用)。これは監査と信頼に不可欠です。
幻覚制御: モデルを作成するのではなく、その前に配置されたテキストに依存します。
コスト: 微調整するよりもはるかに安価で迅速に運用を開始できます。

注意: RAG は魔法ではありません。間違った作品を持ち込んだ場合、モデルは「自信がある」ように間違った答えにたどり着きます。「検索品質 = RAG 品質」という言葉を念頭に置いてください。

よくある間違い

RAG を微調整と間違える: RAG は重みを変更しません。コンテキストを追加するだけです。この 2 つを混同すると、間違ったアーキテクチャを選択することになります。
「わかりません」を許可しない: プロンプトでモデルが自由に空欄を埋められる場合は、モデルが補います。
出典を引用しない: 出典のない回答は確認できません。ユーザーは間違いに気づくことができません。
すべてを 1 つのプロンプトに詰め込む: 長いコンテキストは安っぽく見えますが、高価であり、中間の情報が欠落します。
取得を測定せずに生成に行き詰る: 答えが悪い場合は、まず「正しい部品が到着しましたか?」と尋ねます。問われるべきだ。

要約すると

RAG は、質問に関連するドキュメントをコンテキストとしてモデルに挿入するアプローチです。重みは変更されません (「オープンブック試験」)。
微調整はスタイル/フォーマットを教え、RAG は最新の特定の情報を提供します。長いコンテキストは、小さな固定セットに適しています。ほとんどのシナリオでは、RAG が最初に試行されます。
パイプラインには、オフラインインデックス作成 (チャンク + 埋め込み + 保存) とオンラインクエリ (取得 + プロンプト + 生成) の 2 つのフェーズがあります。
RAG は、適時性、具体的な情報、検証可能性、幻覚制御、および低コストを提供します。
システムの品質は検索の品質に直接依存します。間違った部分は間違った答えを意味します。

アプリケーションタスク

自分のチームからの本物の情報源 (手順書や FAQ ページなど) を選択してください。 (1) この情報源に関する事実に関する質問を 5 つ書きます。 (2) 各質問に対する正しい答えが文書のどの部分に含まれているかに注意してください。これが「黄金の答え」リストとなります。 (3) 上記の「強力なプロンプト」テンプレートを使用して、関連するセクションをコンテキストとして手動で貼り付け、モデルに質問します。 (4) モデルによって与えられた答えを黄金の答えと比較し、真/偽としてマークします。これは、将来の単元で自動化する最初の手動バージョンの評価です。

チェックリスト

[ ] RAG は重みを変更せず、コンテキストを追加するだけであることを一文で説明できます。
[ ] 私は、RAG、微調整、長いコンテキストのどれが適切であるかを区別できます。
[ ] インデックス作成 (収集、シュレッド、埋め込み、保存) フェーズとクエリ (埋め込み、フェッチ、プロンプト、生成) フェーズを順番に数えることができます。
[ ] プロンプトに「文脈にない場合は、わからないと言ってください」と「出典を引用してください」という指示を追加した理由がわかりました。
[ ] 「検索品質 = RAG 品質」の原則を自分のケースに適用できます。