一般的な AI アシスタントに会社の返金ポリシーについて尋ねても、推測することしかできません。あなたの文書を見たことがありません。 RAG (検索拡張生成の略) は、適切な情報を検索し、それを質問とともにモデルに渡すことで、この問題を解決します。

このガイドでは、各段階を平易な言葉で説明し、Python の標準ライブラリのみを使用して小さなバージョンを構築します。そのコードを Python 3.13 で実行し、表示されたスコアはその実行から得られたものです。言語モデルを使用していないため、検索とプロンプト構築を示しており、最終的な回答ステップはテストしませんでした。

RAGとは何ですか？

検索拡張生成は、検索ステップと言語モデルを組み合わせた手法です。質問が到着すると、システムは知識ソースを検索し、最適な結果をプロンプトに追加し、モデルにその資料に基づいて回答するよう求めます。

オープンブック試験を考えてみましょう。本を閉じた生徒は記憶に頼っており、自信を持って間違って覚えている可能性があります。本を開いた生徒は、まず適切なページを調べることができます。 RAG はモデルにその本を与え、またモデルがどのページを使用したかをポイントさせます。

RAG が解決する問題

言語モデル自体には、ビジネスで使用する場合に次の 3 つの制限があります。

• それはあなたの個人データを知りません。あなたのポリシー、チケット、契約はそのトレーニングの一部ではありませんでした。
• その知識には限界があります。今朝変更された価格については知ることができません。
• 答えを発明する可能性があります。確信が持てない場合、もっともらしいが間違っているものを生み出す可能性があります。

RAG は 3 つすべてに対応しているため、何も再トレーニングする必要はありません。ドキュメントを更新し、インデックスを再作成すると、次の回答でそのドキュメントを使用できるようになります。

RAG の仕組み (ステップバイステップ)

RAG システムには 2 つのパイプラインがあります。 1 つは事前にデータを準備し、もう 1 つは質問ごとに実行します。

インデックス作成: データの準備

1. ロード: PDF、Wiki、データベース、またはチケットからコンテンツを収集します。
2. クリーンとチャンク: ジャンクを削除し、ドキュメントを小さな部分に分割します。
3. 埋め込み: 各パッセージを、その意味を捉える数値のリスト (埋め込みと呼ばれる) に変換します。
4. ストア: エンベディングを検索可能なインデックス (通常は ベクター データベース) に保存します。

クエリ：質問に答えること

1. 取得: 質問を埋め込み、意味が最も近い文章を見つけます。
2. 拡張: これらの文章をプロンプトに挿入します。
3. 生成: モデルはそのコンテキストを使用して回答を書き込みます。

検索にはベクトルを使用する必要はありません。キーワード検索でも SQL クエリでも、データに適した情報を見つけることができます。

小さな実際の例

可動部分をはっきりと見るために、ライブラリを持たない小さなレトリバーをここに示します。これはテキストを単語数として表し、実際の埋め込みのより単純な代用であり、コサイン測定を使用して類似性をスコア付けします。

import math, re
from collections import Counter

DOCS = {
    "refunds": "Refunds are paid within 7 days to the original payment method.",
    "shipping": "Standard shipping takes 3 to 5 working days across India.",
    "warranty": "All keyboards include a 2 year warranty against defects.",
}

def vectorize(text):
    return Counter(re.findall(r"[a-z0-9]+", text.lower()))

def similarity(a, b):
    dot = sum(a[word] * b[word] for word in a)
    size = math.sqrt(sum(v * v for v in a.values()))
    size *= math.sqrt(sum(v * v for v in b.values()))
    return dot / size if size else 0

def retrieve(question, k=1):
    q = vectorize(question)
    scored = [(similarity(q, vectorize(t)), name) for name, t in DOCS.items()]
    return sorted(scored, reverse=True)[:k]

def build_prompt(question):
    (score, name), = retrieve(question)
    return (
        "Answer using only the context. If it is not there, say you do not know.\n"
        f"Context: {DOCS[name]}\n"
        f"Question: {question}"
    )

払い戻しについて尋ねると、適切な一節が見つかり、次のプロンプトが作成されます。

print(retrieve("How many days until refunds are paid?"))
# [(0.4558..., 'refunds')]

print(build_prompt("How many days until refunds are paid?"))
# Answer using only the context. If it is not there, say you do not know.
# Context: Refunds are paid within 7 days to the original payment method.
# Question: How many days until refunds are paid?

完全なシステムでは、そのプロンプトを言語モデルに送信します。重要な詳細は、答えが見つからない場合にそれを認める指示です。これについては、プロンプト エンジニアリングのガイドで詳しく学ぶことができます。

この例に欠けているもの

次に、同じことを意味しますが、異なる単語を使用する質問を試してください。

print(retrieve("When can I get my money back?", k=3))
# [(0.0, 'warranty'), (0.0, 'shipping'), (0.0, 'refunds')]

質問はどの文書とも単語を共有しないため、すべてのスコアはゼロです。 「返金」とは人間への返金を意味しますが、文字数だけではわかりません。この 1 つの出力は、実際のシステムが エンベディング を使用する理由を説明しています。エンベディングは、共通する単語がなくても、同様の意味を持つテキストが同様の番号になるように設計されています。

ただし、埋め込みによってすべてが解決されるとは考えないでください。製品コードやエラー番号などの正確な用語に苦戦することがありますが、キーワード検索は非常にうまく処理されます。このため、多くの実稼働システムでは 2 つのアプローチを組み合わせた ハイブリッド検索 が使用されます。

チャンキング: 人々が過小評価しているステップ

ファイル全体が長すぎて取得するには不正確であるため、ドキュメントはいくつかのチャンクに分割されます。選択するサイズには実際のトレードオフが関係します。

チャンク間に重複がある数百の単語が一般的な開始点ですが、それをテストするための最初の推測として扱います。可能な場合は、見出しなどの自然な境界線に沿って分割します。また、ドキュメントのタイトル、日付、部門などのメタデータを添付すると、結果をフィルタリングしたり、出典を引用したりできます。

検索の改善

答えが芳しくない場合、最も試す価値のあるアップグレードは、おおよそ次の順序です。

• データをクリーンアップします。 まず、古いドキュメントや重複したドキュメントを削除します。矛盾したソースを修正するアルゴリズムはありません。
• ハイブリッド検索を使用します。 意味ベースの結果とキーワードの結果を組み合わせます。
• 再ランカーを追加します。 さらに多くの候補を取得し、特殊なモデルを使用して関連性によって候補を並べ替えます。
• メタデータでフィルタリングします。 検索前に製品、地域、または日付ごとに結果を制限します。
• クエリを書き直します。 「2 つ目はどうですか?」のようなあいまいなフォローアップにします。完全な質問になります。

RAG と微調整

これらは相互に排他的ではありません。 RAG、ファインチューニング、プロンプト エンジニアリングの比較では、選択方法をさらに詳しく説明しています。

RAG システムをテストする方法

RAG はソフトウェアであるため、他のソフトウェアと同様にテストが必要です。期待する文章と答えとともに実際の質問のセットを作成し、2 つの段階を個別に測定します。

データに回答がない質問、異なる表現を使用している質問、ソースが矛盾している質問など、厄介なケースも含めてください。 回帰スイートと同様に、チャンキング、モデル、プロンプトを変更するたびにこのセットを再実行します。 pytest チュートリアル では、1 つのテストで多くの入力を実行する方法を示しています。

RAG システムが失敗する理由

• 答えはデータの中にありません。 モデルはまだ答えを試みるかもしれないので、断る方法を教えてください。
• 正しいチャンクが取得されませんでした。 これは多くの場合、チャンクまたは検索の問題です。
• 文脈が多すぎます。 無関係な文章はモデルの注意をそらし、コストを増加させる可能性があります。
• 古いドキュメント。 古いポリシーも、現在のポリシーと同じくらい確実に取得できます。
• 表と PDF の解析が不十分です。 抽出によってテキストがスクランブルされると、取得は回復できません。
• デモの質問のみを使用してテストします。 実際のユーザーは、物事の表現方法がまったく異なります。

セキュリティと権限

RAG には、見落としがちな 2 つのリスクがあります。まず、アクセス制御です。インデックスに HR ファイルが含まれている場合、若手従業員の質問によってそれらのファイルを取得してはなりません。秘密を保持するようにモデルに指示することは信頼できる安全策ではないため、取得中に各ユーザーの権限を適用します。

2 つ目は、即時注入です。取得された Web ページまたはドキュメントには、「指示を無視してください」などのテキストが含まれている可能性があります。取得したコンテンツを信頼できないデータとして扱い、モデルが実行できるアクションを制限し、機密性の高いアクションの承認を人間に要求します。

まとめ

RAG は、多くの実用的な詳細を備えたシンプルなアイデアです。適切な情報を見つけて、モデルにそれを使用するよう依頼します。小さくてきれいな文書セットと約 20 の実際の質問から始めます。通常、良好なデータを含む控えめなパイプラインは、不良データを含む高度なパイプラインよりも優れているため、複雑さを加える前に取得を十分に機能させてください。

よくある質問

学び続ける