Customer Service& Support BlogRAG型AIチャットボットとは｜カスタマーサポートでの仕組みと導入方法
記事概要：RAG型AIチャットボットの質問、検索、抽出、生成、引用という処理を、カスタマーサポート用途に沿って解説します。文書選定、分割、メタデータ、権限、更新、検索評価の実務と、PoCから本番監視までの導入方法を示します。
本記事の目次
RAG カスタマーサポートは、LLMが記憶している一般知識だけで答えず、企業が指定したFAQや規程を検索し、その結果を根拠に回答を生成する構成です。RAGを入れるだけで正確になるわけではなく、検索で正しい文書を取り出せることが前提になります。
RAG型チャットボットの処理
利用者の質問を受けると、システムは検索しやすい表現へ整え、ベクトル検索やキーワード検索で関連文書片を取得します。必要に応じて順位を付け直し、取得した範囲と指示をLLMへ渡し、回答と引用を生成します。最後に禁止語、個人情報、回答範囲を検査して表示します。問題は生成だけでなく、質問変換、検索、抽出、生成、出力制御のどこでも起きるため、エラーを一括して『AI精度』と扱いません。
投入文書を回答単位へ整える
PDF、Web、FAQ、マニュアルをそのまま大量投入すると、ヘッダーや旧版、別商品の条件が混ざります。一つの文書片に、結論、適用条件、例外、更新日、根拠URLが入るよう分割し、商品、契約、地域、公開範囲をメタデータにします。表や画像だけに重要条件がある文書は、構造を保持して解析できるか確認します。重複する旧版は削除せず無効化理由と期限を残し、参照対象から外します。
| 層 | 主な失敗 | 確認方法 |
| 質問処理 | 意図・商品条件の取り違え | 原質問と検索式を保存 |
| 検索 | 正解文書が上位にない | Recall@k、順位、権限テスト |
| 抽出 | 表・例外条件が欠落 | 取得文書片を目視 |
| 生成 | 根拠外の補完、引用不一致 | 必須要素と忠実性評価 |
| 出力制御 | 禁止領域へ回答 | 拒否・有人誘導テスト |
アクセス権と更新を検索へ反映する
社内手順、代理店向け資料、顧客公開FAQを同じ索引に入れる場合、質問者の権限で検索結果を絞れなければ情報漏えいにつながります。文書の閲覧権を検索時に適用し、LLMへ渡した後で隠す設計は避けます。料金改定や障害案内は反映遅延が問題になるため、公開から索引更新までの所要時間、失敗通知、旧キャッシュの消去を運用要件にします。緊急文書は通常同期を待たず優先反映できると安全です。
実際にUdeskの大規模言語モデル対応ナレッジベースを導入した大手ガス会社では、部門をまたいだ知識の共有と再利用を進めるため、ナレッジの作成から更新までの運用を整備しました。その結果、ナレッジ更新に要する時間を24時間未満まで短縮し、ボットによる問い合わせ対応のカバー率も40％から80％へ向上しています。RAGを顧客対応へ利用する場合も、検索精度だけを見るのではなく、正しい情報をどの程度早く更新し、実際の回答へ反映できるかまで含めて設計する必要があります。
検索と回答を分けて評価する
テスト質問ごとに正解文書と必須回答要素を定めます。検索評価はRecall@k＝正解文書が上位k件に含まれた質問数÷全質問数、順位、不要文書の混入で測ります。回答評価は事実正確性、完全性、引用一致、回答拒否、読みやすさです。検索で正解が取れていないのにプロンプトだけを直しても改善しません。AWSのRAG評価でも検索とエンドツーエンド生成を分け、関連性、対象範囲、正確性、忠実性などを扱っています。
導入は限定公開から本番監視へ
最初は一製品、一言語、頻出かつ低リスクの用件に絞り、正解付き質問を頻出、曖昧、例外、禁止領域へ分けます。社内利用で回答と引用を担当者が確認し、合格後に顧客向けへ広げます。本番では未回答、低評価、有人転送、引用クリック、再問い合わせを監視し、文書更新と設定変更を区別して記録します。モデル更新時も同じ質問セットを実行し、精度差と応答時間、利用費を比較します。
検索設計を改善する順序
検索結果が悪い場合は、最初に正解文書が索引へ入っているか、権限で除外されていないか、最新版が有効かを確認します。次に、質問と文書の用語差を同義語やクエリ拡張で補い、回答単位を壊している分割を修正します。それでも上位に不要文書が多ければ、キーワードとベクトルの重み、メタデータ絞り込み、再順位付けを比較します。一度にすべて変えると原因が分からないため、変更一つにつき固定質問セットを再実行します。PoCの評価用質問を設定改善へ使い続けると過適合するので、本番から新しい質問を定期追加し、未使用の最終セットを保持します。日本語では表記揺れ、略称、数字と単位、丁寧語を含む検索テストを用意します。
応答性能とコスト
検索候補を増やすほど網羅性は上がる一方、LLM入力が長くなり、遅延と費用、不要情報の混入が増えます。Top-k、再順位付け、文書片の長さを変え、正答率だけでなく95パーセンタイル応答時間と一回答当たり費用を比較します。電話やライブチャットでは数秒の遅延も会話を妨げるため、チャネル別に上限を置きます。
RAG受入チェック
| 確認項目 | 合格条件 |
| 検索 | 正解文書が上位k件へ入り、権限外文書は候補にも出ない |
| 生成 | 結論、条件、例外が取得文書に忠実で、引用が回答を支える |
| 更新 | 公開・失効が定めた時間内に索引へ反映し、失敗を通知する |
| 運用 | 未回答、低評価、転送、再問い合わせから改善対象を特定できる |
検証から本番運用をUdeskでつなぐ
RAGを問い合わせ対応へ定着させるには、文書管理、回答生成、有人転送、本番ログを別々にせず、誤りの発生箇所を追えることが有効です。UdeskはLLMナレッジベースをAIチャットボット、ライブチャット、チケット管理へ接続し、引用可能な回答と有人引き継ぎ、利用ログに基づくナレッジ改善を同じ運用にまとめられます。
FAQ
Q．RAGならハルシネーションはなくなりますか？
A．なくなりません。検索漏れや古い文書、生成時の根拠外補完があるため、引用、拒否、評価を組み合わせます。
Q．PDFをそのまま登録できますか？
A．登録できる製品は多いものの、表、画像、旧版、長い章を正しく分割できるか事前確認が必要です。
Q．検索精度と回答精度は同じですか？
A．異なります。正しい文書を取得できたかと、取得文書に忠実で十分な回答を作れたかを分けて測ります。
》》Udesk AI チャットボットの無料トライアルを開始するにはクリックし、メリットを実際にご体験ください
本記事はUdeskのオリジナルであり、転載する際は出典を明記してください：https://www.udesk.jp/blog/news/guide/6521/
