RAGとは？意味と仕組み、ハルシネーションを減らせる理由をわかりやすく解説

AIを問い合わせ対応に取り入れたものの、AIが誤った内容を自信ありげに答えて困った経験はないでしょうか。たとえば「返金は購入から7日以内」と案内すべき場面で、まったく違う期限を伝えてしまうケースです。更新したはずのFAQが、AIの回答に反映されないこともあります。

こうした誤回答を減らす仕組みとして注目されているのが、RAG（検索拡張生成）です。RAGを使うと、AIは登録された社内の文書を根拠に回答を作るため、事実と異なる回答を抑えやすくなります。

本記事では、RAGの意味と仕組み、ファインチューニングとの違い、導入で変わることと課題までを、AIを顧客対応に使う立場から解説します。AIの導入を検討しているカスタマーサポートの責任者・マネージャーの方は、ぜひ参考にしてください。

生成AIはなぜ誤った回答をするのか

生成AIが誤った回答をするのは、正確な事実よりも「もっともらしい文章」を作るように動く仕組みだからです。加えて、学習した時点より後の情報や、自社の社内情報を知りません。

この章では、AIの誤回答が起きる2つの理由を解説します。

ハルシネーションとは？

ハルシネーションとは、AIが事実と異なる内容を、正しい情報のように自信を持って答えてしまう現象のことです。OpenAIは、ハルシネーションを「もっともらしく聞こえるが正しくない発言」と説明しています。

生成AIは大量の文章を学習し、次に来る可能性が高い言葉を予測しながら文章を組み立てます。そのため自然な文章を作るのは得意ですが、内容が事実かどうかを確かめながら書いているわけではありません。

たとえば「返金の申請は何日以内ですか？」と聞かれ、自社の規定とは違う日数を答えてしまうのがハルシネーションです。

顧客対応でこうした誤りがそのまま伝わると、顧客の信頼を損ねるだけでなく、返金をめぐるトラブルにもつながります。

学習後の新しい情報と社内の情報は知らない

生成AIが誤るもう1つの理由は、学習したデータの範囲と時点に限りがあることです。

一般的な生成AIは、ある時点までに公開されていたデータで学習しています。そのため、その後に変わった規約や新しく追加したFAQ、自社サービスの変更点は知りません。

さらに、社内のマニュアルや運用ルールのような非公開の情報は、もともと学習の対象に入っていません。

まとめると、一般的な生成AIには次の2つの限界があります。

• 情報の時点の限界：学習が終わった後の新しい情報を反映できない

• 情報の範囲の限界：自社だけが持つ社内の情報を知らない

この2つが、企業がAIを顧客対応に使うときの大きな壁です。次の章では、RAGがこの限界をどう補うのかを見ていきます。

参考：言語モデルでハルシネーションがおきる理由（OpenAI）

RAGとは？意味と生まれた背景

RAG（Retrieval-Augmented Generation、検索拡張生成）とは、AIが回答を作る前に、社内の文書やFAQなどから関連する情報を検索し、その内容を根拠に回答を生成する仕組みです。

この章では、RAGの意味と由来、一般的な生成AIとの違いを解説します。

RAG（検索拡張生成）の意味

RAGは「Retrieval（検索）」「Augmented（拡張）」「Generation（生成）」の頭文字を取った言葉です。日本語では「検索拡張生成」と訳されます。

一般的な生成AIは、学習済みの知識だけを頼りに回答します。

一方でRAGは、回答を作る直前に必要な情報を探しに行きます。試験にたとえると、記憶だけで答える試験ではなく、資料を見ながら答えてよい「オープンブックの試験」に近いイメージです。

この仕組みにより、学習時点より新しい情報や社内の文書も、回答に反映できるようになります。

RAGはどこから生まれた？

RAGは、2020年にPatrick Lewis氏らが発表した論文で提案された仕組みです。

論文のタイトルは「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で、AI分野の国際会議NeurIPS 2020で発表されました。

論文では、AIが学習で覚えた知識だけでは、回答の根拠を示すことや知識を新しくすることが難しいという課題が挙げられていました。

そこで、外部の文書を検索して参照する仕組みを組み合わせたのがRAGです。

参考：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（NeurIPS 2020）

一般的な生成AIとRAGの違いは？

両者のいちばん大きな違いは、回答の根拠をどこから持ってくるかです。

一般的な生成AIは学習したデータの中だけで答えを作りますが、RAGは登録された文書を検索し、その内容を根拠に答えます。

このように、RAGは一般的な生成AIの弱点を補う仕組みです。正確な案内が求められる顧客対応でRAGが重視されているのは、このためです。

RAGの仕組み：回答までの3ステップ

RAGは「検索」「文脈の追加」「回答の生成」という3つのステップで回答を作ります。

この章では、各ステップで何が起きているのかを、問い合わせ対応の流れに沿って解説します。

ステップ1：検索（Retrieval）

最初のステップでは、顧客の質問に関係する情報を探します。このとき中心的な役割を担うのが、ベクトルデータベースです。

ベクトルデータベースとは、文章などのデータを数値の並び（ベクトル）に変換して保存し、意味が近い情報をすばやく探せるようにしたデータベースのことです。

キーワードが一致する文書を探す一般的な検索と違い、言葉が違っても意味の近い文書を見つけられます。たとえば顧客が「返金したい」と入力した場合でも、「返品ポリシー」の文書を探し出せます。

社内の文書やFAQはあらかじめこの形で保存しておき、質問が届くたびに関連の深い情報を検索します。

ステップ2：文脈の追加（Augmentation）

次のステップでは、検索で見つかった文書を、顧客の質問と一緒にAIへ渡します。これが文脈の追加です。

AIは質問だけでなく、「この質問に関係する資料はこれです」という参考資料も受け取ったうえで回答を考えます。

オペレーターが問い合わせに答える前に、関連するマニュアルを手元に開いておく状況に近いといえるでしょう。

この段階があるため、AIは学習していない内容についても答えられるようになります。

ステップ3：回答の生成（Generation）

最後に、AIは渡された資料をもとに回答を生成します。

検索した文書を根拠にするため、事実に基づかない内容が混ざりにくくなります。

また、どの文書を参照したのかをたどれるので、回答に誤りがあったときも原因を確かめやすくなります。

3つのステップをまとめると、次のとおりです。

1. 検索（Retrieval）：顧客の質問に関係する文書を探す

2. 文脈の追加（Augmentation）：見つけた文書を質問と一緒にAIへ渡す

3. 回答の生成（Generation）：AIが文書を根拠に回答を作り、顧客に返す

参考：Azure AI 検索でのレトリーバル拡張生成（RAG）（Microsoft Learn）

ファインチューニングとの違い

RAGとよく比べられるのが、ファインチューニング（追加学習）です。

ファインチューニングがAIのモデル自体を作り変えるのに対し、RAGはモデルを変えずに、回答のたびに文書を参照します。

この章では、2つの違いと使い分けの考え方を解説します。

ファインチューニングとは？

ファインチューニングとは、学習済みのAIモデルに追加のデータを学習させ、モデルそのものを調整する方法のことです。

特定の言い回しや、専門分野の文章に慣れさせたい場合に使われます。

ただし、覚えさせた情報はモデルの中に組み込まれるため、内容を変えたいときは学習をやり直さなければなりません。

料金や規約、キャンペーンのように変更の多い情報を扱う場合、そのたびに学習し直すのは現実的ではないでしょう。

RAGとファインチューニングはどう使い分ける？

変更の多い情報を正しく案内したいならRAG、AIの話し方や専門分野への対応力を変えたいならファインチューニングが向いています。

顧客対応では、返品の条件や配送日数、キャンペーンの内容などが頻繁に変わります。

そのため、問い合わせへの回答を正確に保つことが目的なら、まずRAGを検討するのが現実的です。

RAGを導入すると何が変わる？

RAGを導入すると、AIの誤回答が減り、文書を更新するだけで回答を新しい内容に保てるようになります。

この章では、顧客対応で起きる2つの変化と、業種別の活用例を紹介します。

誤回答が減り、回答の根拠をたどれる

RAGでは、AIが回答の前に関係する文書を検索し、その内容を根拠に回答を作ります。

そのため、根拠のない内容が混ざる可能性を下げられます。返金の条件や配送のルール、利用規約のように、正確さが求められる内容ほど効果を実感しやすいでしょう。

また、AIがどの文書を参照したかを確認できるため、誤った回答が見つかったときも原因の文書を特定して直せます。

「AIが何を根拠に答えたのかわからない」状態を避けられることは、運用を任されるマネージャーにとって大きな安心材料です。

ただし、RAGを使っても誤回答がゼロになるわけではありません。その理由は、後半の「RAGの課題と運用のポイント」で解説します。

文書を更新すれば回答に反映される

RAGのもう1つの利点は、情報の更新が簡単なことです。

ファインチューニングでは、新しい情報を反映するたびにモデルの学習をやり直す必要があります。一方でRAGは、登録された文書を回答のたびに検索します。

規約が変わったときやFAQを追加したときも、文書を直すだけで回答に反映されます。

季節ごとのキャンペーンや変更された返品の条件、新しく始めたサービスの案内なども同じです。担当者が文書を書き換えるだけでAIの回答を新しくできるため、変更の多い業種ほど助かる仕組みといえます。

RAGはどの業種で使われている？

RAGは、正確な情報を伝えることが重要な業種で活用されています。

どの業種にも共通するのは、正確な案内が必要で、規定やルールが頻繁に変わることです。こうした条件がそろう業種ほど、RAGの効果は大きくなります。

RAGの課題と運用のポイント

RAGは誤回答を減らせる仕組みですが、誤回答がゼロになるわけではありません。

回答の質は、検索の精度と参照する文書の質に大きく左右されます。

OpenAIも、検索の仕組みを備えたモデルであっても、すべての質問に正しく答えられるわけではないと説明しています。

この章では、RAGを顧客対応に使うときに押さえておきたい4つの課題を解説します。

関係の薄い文書を拾うと回答も外れる

RAGの回答は、検索で見つけた文書をもとに作られます。そのため、質問と関係の薄い文書を拾ってしまうと、回答も的外れなものになりかねません。

特に、顧客が使う言葉と文書の言葉が違う場合や、1つの質問に複数の条件が含まれる場合は、必要な情報を取りこぼしがちです。

文書には見出しを付け、1つの見出しには1つの話題だけを書くようにすると、検索で目的の情報が見つかりやすくなります。

古い文書や矛盾した文書もそのまま答えてしまう

RAGは、参照した文書が正しいことを前提に回答を作ります。古い規約が残っていたり、文書どうしで書いてあることが食い違っていたりすると、AIはその内容のまま答えてしまいます。

たとえば、旧料金のページと新料金のページが両方登録されていると、AIがどちらを根拠にするかは検索の結果次第です。

不要になった文書を参照の対象から外すことも、文書を追加するのと同じくらい重要です。

文書の整備と更新を続ける必要がある

RAGは、文書を用意すれば終わりではありません。商品や規約が変わるたびに、文書も更新し続ける必要があります。

誰がどの文書を管理し、いつ見直すのかを決めておかないと、文書は少しずつ古くなっていきます。問い合わせの傾向を見ながら、AIが答えられなかった質問をFAQに追加していく運用も欠かせません。

誰にどの情報を見せるかを決めておく

RAGで参照する文書の中に、社内向けの情報が混ざっていないかにも注意が必要です。社内向けのマニュアルや対応メモを顧客向けのAIが参照すると、本来は伝えるべきでない情報を回答に含めてしまうおそれがあります。

社内向けの文書と顧客向けの文書を分け、顧客対応のAIには顧客に見せてよい文書だけを参照させるように設計しておきましょう。Microsoftの技術文書でも、RAGの課題の1つとして、承認された情報だけを取得させるアクセス制御を挙げています。

なお、複数の条件を含む質問で情報を取りこぼす課題に対しては、AIが検索と検証を繰り返す「Agentic Search」という発展形の仕組みも登場しています。詳しくは「RAGはもう古い？Agentic Searchの仕組み・メリットと活用事例」で解説しています。

参考：

• Azure AI 検索でのレトリーバル拡張生成（RAG）（Microsoft Learn）

• 言語モデルでハルシネーションがおきる理由（OpenAI）

チャネルトークのALFはRAGをどう使う？

ここまで見てきたように、RAGで誤回答を減らせるかどうかは、AIが参照する文書の整え方と、誰にどの情報を見せるかの設計にかかっています。

とはいえ、こうした仕組みを自社で一から作るには、検索の仕組みづくりやアクセス制御の設計といった専門的な開発が必要です。RAGを組み込んだ顧客対応ツールを使えば、開発の手間をかけずに、文書の登録と運用に集中できるのが利点です。

ここでは、顧客理解のためのAIエージェント「チャネルトーク」の「ALF」を例に、参照する情報の登録方法と、状況に応じて参照先を切り替える方法を紹介します。

ALFは、登録された「ナレッジ」を検索し、その内容をもとに回答を作るRAGの仕組みで問い合わせに対応します。

さらに、検索と検証を繰り返すAgentic Searchも取り入れており、複数の条件を含む問い合わせに対応しやすい点が特徴です。

自然言語を的確に理解するALF - チャネルトーク

AIエージェント ALFはオペレーターの代わりに顧客からのお問い合わせに対応します。

Channel.io

ナレッジに社内の資料をまとめる

ALFが回答の根拠にする資料は、「ナレッジ」にまとめて管理します。ナレッジには、記事やFAQのほか、ExcelファイルやPDFファイル、Webサイトなど、さまざまな形式の資料を登録できます。

ドキュメントで作成した記事やFAQは、公開中のものがナレッジに追加され、ALFの参照先になる仕組みです。

ドキュメントの記事を書き換えれば、AIに学習させ直す作業をしなくても、ALFの回答に反映されます。

フィルタリング条件とルールで参照先を切り替える

ナレッジでは、フォルダーごとにフィルタリング条件を設定できます。顧客情報や問い合わせ情報をもとに条件を決めておけば、条件に合う顧客の問い合わせにだけ、そのフォルダーの資料が参照される仕組みです。

たとえば会員ランクによって特典が違う場合も、ランク別にフォルダーを分けておけば、顧客に合った資料を根拠に案内できます。前の章で触れた「誰にどの情報を見せるか」も、この設定で管理しやすくなるでしょう。

あわせて「ルール」を使うと、ALFの対応方針を状況ごとに指示できます。ルールとは、ALFが状況に合わせて問い合わせを進められるように、あらかじめ作成しておく指示文のことです。クレームへの対応方法や障害発生時の案内など、問い合わせの種類や顧客情報に応じて異なるルールを適用できます。

ルールにはプレビュー機能があり、どのルールが回答に適用されたかを、顧客に公開する前に確認できます。AIの回答を確かめてから本番に出せるため、初めてAIを導入するチームでも運用を始めやすいでしょう。

Webサイトを登録してナレッジにする

自社サイトに商品情報や利用ガイドがそろっている場合は、ナレッジにWebサイトを登録する方法が便利です。URLを登録すると、ALFがそのページと下層のページの情報を自動で取得し、ナレッジとして参照します。

自社のホームページや商品詳細ページ、利用ガイド、利用規約など、Webで公開しているページをそのまま活用できます。回答用の文書を一から作り直す手間を減らせる点が、大きな利点です。

ただし、Webサイトの情報は登録した時点の内容が反映されます。

サイトの内容を更新したときは、ナレッジで「再インポート」を実行して、変更後の内容を取り込みます。

まとめ

RAG（検索拡張生成）とは、AIが回答を作る前に社内の文書やFAQなどを検索し、その内容を根拠に回答を生成する仕組みです。生成AIが誤回答する原因である「新しい情報や社内の情報を知らない」という限界を、文書を参照することで補います。

本記事のポイントは次のとおりです。

• RAGの仕組み：検索・文脈の追加・回答の生成の3ステップで回答を作る

• ファインチューニングとの違い：モデルを作り変えず、文書を更新すれば回答に反映される

• 導入で変わること：誤回答が減り、回答の根拠をたどれるようになる

• RAGの課題：検索の精度と文書の質に左右されるため、文書の整備と更新を続ける運用が欠かせない

RAGを使っても、誤回答がゼロになるわけではありません。

だからこそ、AIが参照する文書をどう整え、誰に何を見せるかを設計することが、AIを顧客対応に生かす鍵になります。

チャネルトークのALFなら、ナレッジ・フィルタリング条件・ルールを組み合わせて、参照する情報を状況に合わせて管理できます。AIの導入を検討している方は、まず自社の問い合わせでよく使う文書の棚卸しから始めてみてください。