社内の手順や自社の事実をAIに尋ねたら、それらしいのに間違った答えが返ってきた。こうした、AIが事実でない内容をもっともらしく作ってしまう現象を、ハルシネーションと呼びます。業務で使おうとするほど、この「平気で嘘をつく」性質が気になってきます。
なぜ嘘が生まれるのかはなぜAIは嘘をつくのかで整理しました。この記事は、その先の「では、どう減らすか」です。代表的な一手が、AIに答えさせる前に手元の資料を読ませる、RAGという仕組みです。仕組みまで踏み込んで解説します。
AIが嘘をつくのは、知らないことも「それっぽく」埋めるから
AIは、事実を調べてから話しているわけではなく、文脈に続く可能性の高い言葉を予測しながら文章を作っています。そのため、知らないことや手元にない情報でも、空欄にせず、もっともらしく埋めてしまいます。とくに、自社固有の情報、最新の事実、細かい数値などは、学習した知識だけでは持っていないため、当てずっぽうが混ざりやすくなります。
裏を返せば、答えるための材料をあらかじめ渡しておけば、当てずっぽうの余地は小さくなります。これがRAGの出発点です。
RAGとは、答える前に「手元の資料を読ませる」仕組み
RAGは、AIがもともと持っている知識だけで答えるのではなく、質問のたびに関連する資料を検索し、その中身を回答の材料としてAIに渡してから答えさせる仕組みです。名前の由来もそのままで、検索(Retrieval)して、材料を足して(Augmented)、答えを作る(Generation)、の頭文字です。
記憶だけで即答する人と、手元の資料を確認してから答える人の違いに近いものです。前者は知らないことも勢いで答えてしまいますが、後者は資料に沿って答え、書いていないことは保留できます。RAGは、AIを後者に近づける仕組みだと考えると分かりやすいです。
RAGの仕組みを分解する
「資料を読ませる」と一言で言っても、AIに関係する資料だけをどうやって渡しているのか。ここが分かると、RAGの効き目と限界の両方が見えてきます。順番に分解します。なお、資料の探し方にはキーワード検索やそれらを組み合わせる方法もありますが、ここでは現在よく使われている、文章をベクトル化して検索するタイプを例に説明します。
1. 資料を「意味の数値(ベクトル)」に変換して保存する
まず、手元の資料(マニュアル、規程、FAQなど)を、AIが扱える数値の列に変換します。これを埋め込み(ベクトル化)と呼びます。文章を、意味を表す座標のようなものに置き換える処理だと考えてください。
このとき重要なのは、意味の近い文章どうしは、近い座標に配置されるという点です。たとえば「返品の期限」と「いつまでに返せるか」は、言葉は違っても意味が近いので、座標も近くなります。変換した資料は、こうした近さを高速に探せる保管庫(ベクトルデータベース)にためておきます。
2. なぜキーワード一致でなく「意味」で探すのか
キーワード検索は、基本的に入力した単語と文書中の言葉の一致を手がかりに探します。そのため、「返品できますか」と聞いても、資料に「ご返送の受付」としか書いていなければ拾いにくいことがあります。
ベクトルで探すと、単語が一致しなくても意味が近ければ拾えます。利用者が入れる質問は言い回しがばらばらなので、この「意味で探せる」ことが、社内の資料検索では大きく効きます。
3. 長い文書は、小さく区切って保存する(チャンク)
マニュアル1冊をまるごと1つの座標にすると、内容が混ざって「近さ」がぼやけます。そこで、段落や見出しなど小さな単位に区切ってから、それぞれをベクトル化します。この区切りをチャンクと呼びます。
チャンクの切り方は、RAGの精度を左右する地味に重要な設計点です。大きすぎると関係ない話まで混ざり、小さすぎると文脈が切れて意味が取れなくなります。
4. 質問を同じ空間に置いて、近い資料を取り出す
利用者が質問すると、その質問も同じやり方でベクトルに変換します。そして、質問のベクトルと、保管庫にある資料のベクトルの近さを計算し、意味の近いチャンクを上位から数件取り出します。これが検索(Retrieval)の部分です。
ここで「上位何件を取り出すか」も設計しだいです。少なすぎると必要な資料を取りこぼし、多すぎると関係の薄い資料まで紛れ込みます。
5. 取り出した資料を質問に足して、AIに答えさせる
最後に、取り出したチャンクを、利用者の質問と一緒に、AIへの入力(プロンプト)へ入れて渡します。これが材料を足す(Augmented)部分です。AIは、その資料を手元に置いた状態で答えを作ります(Generation)。
つまりRAGは、質問に関係する資料を探し出し、それを質問に添えてから答えさせる一連の流れです。ここで説明したベクトル検索は、その代表的な探し方の一つです。AIの記憶だけに頼らせないための、外付けの参照棚だと捉えると分かりやすいです。
なぜ嘘が減るのか
この流れを挟むと、AIの答えの根拠が、渡した資料の側に寄ります。学習した曖昧な記憶ではなく、目の前のチャンクを材料にするため、自社固有の情報や最新の事実でも、事実に沿った答えを返しやすくなります。
加えて、参照した資料やチャンクを回答と紐づける設計にすれば、答えの出どころを人が確認できます。資料に書かれていないことは「分かりません」と返すように設計することもでき、無理に埋めて嘘になる場面を減らせます。
それでも嘘は消えない──精度を左右する要素
大事な前提として、RAGはハルシネーションを減らす一手であって、ゼロにする魔法ではありません。仕組みを分解すると、どこで間違いが残るかも見えてきます。
- 検索がずれる：質問のベクトルと近い資料が、必ずしも「正解の資料」とは限らない。関係の薄いチャンクを拾うことがある。
- チャンクの切り方が悪い：文脈が切れて、肝心の条件が別のチャンクに残ってしまう。
- 資料そのものが古い・誤っている：参照棚の中身が間違っていれば、答えも間違う。
- 資料に答えが無い：それでもAIが埋めてしまうことがある。
つまり、渡す資料の質、チャンクの設計、取り出す件数、埋め込みの精度で、効き目は大きく変わります。RAGを入れたから安心ではなく、精度を上げるための土台を、設計して初めて効く一手です。
RAGには、別の落とし穴もある
RAGは、外部や社内のデータをAIに読ませる仕組みです。この「読ませる」経路は、便利さと同時にリスクにもなります。
たとえば、誰でも書き込めるデータ(レビューや問い合わせなど)を無防備に参照棚へ入れると、そこに仕込まれた命令をAIが指示として受け取り、回答内容を操られる間接プロンプトインジェクションの入口になり得ます。まず起きるのは、誤った情報を答える、機密を回答に混ぜる、といった回答への影響です。どのデータをどの信頼度で扱うかはRAGに信頼できないデータを混ぜる危険で、守り方全体は騙されても被害が出ないAIの設計で整理しています。
さらに、AIに資料だけでなく操作する機能まで持たせている場合は、不正な送信やデータ操作といった実際の被害につながる可能性があります。ここまで来るとAIに渡す権限をどこまで絞るかもセットで考える必要があります。また、利用者ごとの閲覧権限を検索の段階で反映しなければ、本来その人が見られない資料が回答に混ざるおそれもあります。誰が何を取り出せるかを検索時に制御することも、企業でのRAGでは欠かせません。精度を上げる設計と、安全に運用する設計は、両輪で進めるものです。
今日試せる、小さな入口
いきなり本格的なRAGの仕組みを組まなくても、考え方だけは今日から試せます。
- AIによく尋ねることを1つ選ぶ(社内手順、製品仕様など)。
- その正しい情報を、短い資料としてまとめておく。
- 質問するとき、その資料の内容を先に渡してから尋ねる。
- 記憶だけで答えさせたときと、資料を渡したときで、答えの正確さを見比べる。
この「資料を先に渡すと精度が変わる」という手応えが、RAGが自動でやっていることの縮図です。手応えがつかめたら、都度検索して自動で資料を渡すRAGの仕組みへ進む、という順序が現実的です。
まとめ
- AIが嘘をつくのは、知らないことも確率で埋めるから。答える材料を渡せば、当てずっぽうは減る。
- RAGは、資料を意味の座標(ベクトル)に変換して保管し、質問に意味が近いチャンクを取り出して、質問に添えてから答えさせる仕組み。
- 根拠が資料に寄るため、自社固有・最新の情報でも事実に沿いやすく、出どころを示す仕組みも作れる。
- ただし、検索のずれ・チャンクの設計・資料の誤り・件数などで嘘は残る。減らす一手であり、設計して初めて効く。
- RAGは外部データを読ませる仕組みでもあるため、間接プロンプトインジェクションなどのセキュリティ設計とセットで進める。
