ナレッジベースからの回答の生成 (RAG の概要) — 部門アプリケーション: 顧客サービスおよび販売

利益:

知識ベース生成 (RAG) のロジックと、それが幻覚を軽減する理由を理解する
提供されたソース文書のみに基づいて、モデルに引用で応答させる機能
質問をでっち上げずに安全に転送することで、ソースにない質問を管理する能力

言語モデルは多くのことを「知っています」が、今日の会社の返品ポリシー、現在の価格表、または昨日変更された配送契約については知りません。さらに悪いことに、彼は知らないとき、それをでっち上げて、非常に自信に満ちた口調で書くことがよくあります。これは顧客サービスにおける致命的な欠陥です。モデルでは「返金は 30 日以内に行われます」と書かれているのに、ポリシーでは 14 日である可能性があります。このギャップを埋めるアプローチは、RAG: Retrieval-Augmented Generation、つまり「検索拡張生産」と呼ばれます。

考え方は単純です。モデルは、記憶ではなく、その時点でモデルの前に置かれている正しいソース文書から質問に答えます。まず、質問に関連するドキュメントの正しい部分が「検索」され、モデルはその部分のみに基づいて回答を「生成」します。この単元では、RAG のロジックを理解し、提供した検証済みのソースのみに固執するようにモデルを制御する方法を学びます。

注: この単元では、RAG の動作ロジックとプロンプト側について説明します。企業規模の自動文書検索システム (ベクターデータベースなど) には技術的なインストールが必要です。ここでの規律は、システムが正しく応答するための基礎です。

RAG が幻覚を軽減するのはなぜですか?

幻覚とは、モデルが非現実的な情報をあたかも現実であるかのように生成することです。モデルは、ギャップを見つけたときに「可能性がある」と思われる応答を生成するようにプログラムされています。それが本当かどうかはわかりません。 RAG はこのギャップを埋めます。質問とともに実際の関連テキストをモデルに与え、「ここからのみ回答してください」と指示します。この方法では、モデルを適合させる「必要」がありません。

次の 3 つのコンポーネントがあります。

知識ベース: FAQ、ポリシー文書、製品マニュアル、価格表などの信頼できるテキスト。
検索: 質問に対する答えが含まれている文書を見つけて、それをモデルに渡します。
限定版: モデルは提供された部品のみに基づいて見積もりを返します。

一歩一歩: 情報源への忠実な対応

ソースを用意します。回答の基礎となるテキスト (ポリシー、FAQ) を明確かつ最新の形式で見つけます。
プロンプトにソースを埋め込みます。 <source> のようなタグにテキストを入れます。
ロイヤルティルールを書きます。「情報源からの情報のみを使用し、情報源から逸脱しないでください。」
引用を必須にします。答えがどのセクションに基づいているかを教えてもらいます。
非リソースの動作を特定します。答えが情報源にない場合は、「この情報は持っていません」と言って、それを伝えましょう。
確認する。答えをもとになった原文と比較して答えを確認します。

コピー可能なプロンプト

基礎となるソースに基づいた応答プロンプト:

役割: あなたはカスタマーサポートアシスタントです。以下の <source> ブロック内の情報のみに基づいて質問に答えてください。ソースにない情報を追加したり、一般知識から推測したり回答したりしないでください。回答の最後に、依存しているセクションを「[出典: ...]」の形式で追加します。答えがソースにない場合は、次のように書いてください: 「この件については決定的な情報がありません。正しい答えを提供できる担当者に転送します。」<source>{{policy_or_faq_text }}</source>質問: {{ customer_question }}

マルチソースの場合、どのドキュメントに基づいているかを示すプロンプトが表示されます。

以下に番号が付けられたリソースが複数あります。質問に答えるときは、[情報源 2] など、使用した情報源の番号を明記してください。複数の情報源が矛盾している場合は、その旨を明確に述べ、どれがより最新であるかを尋ねるべきであると述べてください。<sources>1) {{ source_1 }}2) {{ source_2 }}3) {{ source_3 }}</sources>質問: {{ customer_question }}

ソース以外の質問を安全に管理するプロンプト:

質問に対する答えがソースに部分的に記載されている場合は、ソースでカバーされている部分のみに答え、残りの部分については「この詳細はソースにありません」と述べます。決して推測によって欠落部分を埋めないでください。

応答をクライアント言語に翻訳しますが、ソースに忠実なプロンプト:

ソース内の公式/技術的表現を顧客が理解できる平易な言葉に翻訳します。ただし、意味や数値（日、金額、レート）は変更しないでください。たとえば、「14 暦日」を「約 2 週間」に四捨五入します。完全な価値を維持します。

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

プロンプトが弱い

強力なプロンプト

「返品ポリシーについて教えてください」

ソースを埋め込む + 「ここにのみ返信」 + 見積もりをリクエストする

モデルの記憶による回答（間違っているかもしれません）

現在の文書からの回答

ソースにない場合は彼がでっち上げます

彼は「その情報は持っていません」と言い、それを伝えます。

数値を四捨五入したり歪めたりすることができる

日/金額/レートを正確に維持します

違いは、強力なプロンプトがモデルにアンカー (ソーステキスト) と禁止 (ソースから外れること) を与えることです。モデルはもはや記憶に基づいてではなく、目の前の現実に基づいて話します。

ミニケース3個

ケース 1 — 古いポリシーの罠。ある店舗のボットは、クレジットなしで実行中に「30 日以内であれば返品を受け付けます」と言いました。しかし、同社はその期間を14日間に短縮した。更新されたポリシーテキストが RAG インストールのソースに追加されると、ボットは「14 暦日 [出典: 返品ポリシー、記事 2]」と応答するようになりました。虚偽の約束に起因する返金に関する紛争はリセットされました。

ケース 2 — 矛盾を捉える。お客様から配送料について質問がありました。新旧両方の価格表がソースとしてシステムに入力されました。マルチソースのプロンプトのおかげで、モデルは「2 つのソースで異なる価格 (49 TL と 59 TL) が提示されています。現在の価格を確認する必要があります」と述べ、問題を人間に伝えました。彼は顧客に間違った金額を伝えるのではなく、不確実性を正直に伝えました。

ケース 3 — 部分的な対応の規律。「商品を海外に発送しますか？関税は誰が支払いますか？」質問では、情報筋は出荷が行われたとだけ述べており、誰が税金を支払ったかについては何も語られていない。モデルは「はい、発送は海外で行われます[出典: Cargo FAQ]。ただし、この文書には関税を誰が支払うかについては記載されていません。これを明確にするために担当官に転送します。」と言いました。半分真実、半分でっちあげの答えではなく、正直で自信に満ちた結果が得られました。

ヒント: ナレッジベースの最新かつ唯一の信頼できる情報源のバージョンを保持してください。同じ情報 (返品期間など) が 3 つの別々の文書に異なる方法で記述されていることは、RAG の最大の敵です。モデルはどちらを見ているかに応じて反応が異なります。まずドキュメントの重複を排除してから、ドキュメントを自動化します。

検証: ソースが存在するからといって安心してはいけない

RAG は幻覚を大幅に軽減しますが、幻覚をリセットするわけではありません。モデルは、ソースを誤解して 2 つの文を混同したり、ソースにない「結論」を導き出したりする場合があります。だからこそ、引用要件は重要です。回答の根拠となっているセクションを開いて、実際にそのように述べられているかどうかを確認してください。この制御は、特に数値 (日、金額、率) と条件 (例外、条件) を含む応答では交渉の余地がありません。

注意: ソース自体が間違っているか古い場合、RAG はその間違いを忠実に再現します。「モデルがソースから話している」と言っても、「モデルが正しく話している」という意味ではありません。情報源の最新性と正確性については、お客様が責任を負います。

ナレッジベースを対応できる状態に保つ

RAG の品質は、ソーステキストの書き方に大きく依存します。このモデルは、適切に構造化され、タイトルが付けられた、単一トピックのテキストよりもはるかに正確な応答を返します。実践的なアドバイス: ポリシーは、ネストされた長い段落ではなく、短いタイトルのセクションで作成します。各セクションに 1 つの質問 (「返品期間は何日ですか?」、「返品できない商品はどれですか?」) に答えてもらいます。よくある質問 (FAQ) を一問一答形式で保持すると、モデルが適切な部分を見つけやすくなります。日付、金額、レートなどの値をテキスト内の 1 か所に明確に記載します。同じ数値を異なるセクションに異なる方法で記述すると、モデルが混乱します。

もう 1 つの重要な習慣は、知識ベースを維持することです。ポリシー、価格、プロモーションはさまざまです。ソースが更新されない場合、モデルは古い真実を安全に繰り返し続けます。ポリシーを変更するたびに、ソースを更新し、変更されたトピックに関するいくつかのテスト質問をモデルに再質問して、正しい答えが得られることを確認します。この小規模ではあるが定期的なメンテナンスにより、RAG システムが時間の経過とともに「静かに問題を起こす」ことが防止されます。

よくある間違い

ソースを埋めたり、モデルの暗記に頼ったりせずに、「私たちのポリシーを説明してください」と言う。
「ソースからのみ返信」の境界と非ソース動作を定義していません。
引用/出典参照を要求せず、回答を検証不能のままにします。
ナレッジベース内の複数のドキュメントに同じ情報の矛盾するバージョンを保持する。
モデルが数値を四捨五入/解釈できるようにします。
ソースの更新を忘れたため、モデルは古い情報を忠実に再現します。

要約すると

RAG は、モデルがメモリではなく現在のソースドキュメントから答えを生成することを意味します。
幻覚を減らすための最も現実的な方法は、情報源を隠し、「ここにのみ返信してください」と言い、引用を求めることです。
答えがソースにない場合は、モデルを当てはめるべきではありません。「持っていない」と言って渡すべきです。
競合するソースをモデルに認識させます。数値を正確に保存しました。
RAG の精度は、ソースの適時性によって決まります。必ず見積書を確認してください。

アプリケーションタスク

自分のビジネスから実際のポリシーテキスト (返品、配送、またはメンバーシップ) を取得し、それを上記の基本的な RAG プロンプトにソースとして埋め込みます。次に、3 つの質問をします: (1) 答えがソースで明らかな質問、(2) 答えがソースにまったくない質問、(3) 答えがソースで不完全なだけの質問。モデルが正しく答え、「持っていません」と答え、部分的な答えと欠落しているものをそれぞれ正直にマークしていることを確認します。プロンプト内のロイヤルティと非リソースのルールを強化して、逸脱した動作を修正します。

チェックリスト

[ ] 応答のベースとなる現在のソースをプロンプトに埋め込みました。
[ ] 「送信元からのみ返信し、それを超えない」ルールを追加しました。
[ ] 出典参照・引用の要件を記載しました。
[ ] 答えがソースにない場合の委任の動作を定義しました。
[ ] 数値が正確に保存されることを要求しました。
[ ] 根拠となった原文から回答を確認しました。