社内の規程やマニュアルに答えるAIを作ろうとすると、RAGという言葉に行き当たる。仕組みは単純だが、試作では動いたのに本番で答えが外れる、見せてはいけない文書の中身を答えてしまう、という問題もここで起きる。
ここでは、RAGとは何かを、準備と回答の2段階に分けて説明する。そのうえで、ほかの方法との使い分けと、本番で精度と権限を落とさないための設計を整理する。
RAGとは
RAG（Retrieval-Augmented Generation、検索拡張生成）とは、質問に関係する文書を先に検索し、その文書を質問と一緒に生成AIに渡して答えさせる仕組みだ。モデルが学習していない社内の情報でも、渡した文書をもとに答えられるようになる。
この名前は、2020年5月にPatrick Lewisらが発表した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で付けられた。論文はNeurIPS 2020に採択されている。この論文では、文章を生成するモデルに、Wikipediaを検索できる仕組みを組み合わせた。検索を使わずモデルの中の知識だけで答える方式と比べて、より具体的で、多様で、事実に沿った文章を生成したと報告している。
今の生成AIで使われるRAGは、論文の方式そのものではない。私の見方では、「答える前に関係する文書を探して、モデルに読ませる」という考え方を指す総称として使われている。
RAGの仕組み
RAGは、文書を検索できる形にしておく準備と、質問が来たときの回答の2段階で動く。
準備
- 文書を集める。規程、マニュアル、過去の問い合わせ、議事録など
- 文書を小さな単位（チャンク）に分ける。たとえば見出しや段落ごとに切る
- チャンクごとに、意味を数値の並びにしたもの（埋め込み）を作る
- 埋め込みと元の文章を、検索できる場所（ベクトルデータベースや検索エンジン）に入れる
回答
- 質問を受け取り、質問の埋め込みを作る
- 意味が近いチャンクを検索する。キーワードでの検索を組み合わせることもある
- 見つかったチャンクを、質問と一緒にモデルに渡す
- モデルが、渡された文書をもとに答える。どの文書をもとにしたかも示す
モデルに渡す文書は、答えるたびに検索して選ぶ。文書を差し替えれば、モデルを作り直さなくても答えが変わる。RAGの扱いやすさは、ここから来ている。
RAGとほかの方法の使い分け
社内の知識をAIに使わせる方法は、RAGだけではない。次の表は、私の整理だ。
| 方法 | 知識の渡し方 | 向いている場面 | 気をつける点 |
|---|---|---|---|
| 文書をまるごと渡す | 毎回、全部の文書をプロンプトに入れる | 文書が少なく、誰が見てもよい | 文書が増えると費用と応答の時間が増える |
| RAG | 答えるたびに検索した文書だけを渡す | 文書が多い、よく変わる、出典を示したい | 検索で外すと、正しい文書があっても答えを誤る |
| ファインチューニング | 追加のデータでモデル自体を学習し直す | 答え方の型や、専門の言い回しを覚えさせたい | 中身が変わるたびに学習し直しが要る |
1つ目の方法は軽く見られがちだが、試す価値がある。Anthropicは、知識の量が20万トークン（およそ500ページ）より少なければ、検索せずに全部をプロンプトに入れる方法を挙げている。文書の量が多い、更新が多い、人によって見せる文書を変えたい、のどれかに当てはまったときに、RAGを選べばよい。
RAGが本番で外れる3つの理由
試作のRAGは、用意した質問にはよく答える。本番で外れるのは、多くは次の3つのどれかだと私は考えている。
1. 検索で正しい文書を拾えていない
RAGの答えは、検索で拾った文書以上にはならない。拾った文書が外れていれば、モデルはもっともらしい誤りを返す。
原因になりやすいのが、文書の分け方だ。Anthropicは2024年9月19日に公開した「Contextual Retrieval」で、文書をチャンクに分けると、個々のチャンクから文脈が抜け落ちる問題を指摘した。たとえば「前の四半期より3%伸びた」という一文だけを切り出しても、どの会社のどの期の話かが分からない。
Anthropicは、チャンクごとに、文書全体の中での位置づけを短く書き足してから検索の対象にする方法を示した。同社の検証では、上位20件の検索で正しいチャンクを取りこぼす割合が、意味の検索だけに書き足しを入れると35%減り、キーワードの検索（BM25）も組み合わせると49%減った。検索結果を並べ直す処理（リランキング）まで加えると67%減ったと報告している。
数字はAnthropicの検証の条件での結果だ。私の見方では、大事なのは数字そのものより、検索の取りこぼしを測ってから直すという順番だ。質問と正解の文書の組を作り、検索だけの正解率を先に測る。
2. 見せてはいけない文書まで答えに使っている
社内の文書をまとめて検索の対象にすると、人事の評価や経営会議の資料のように、質問した人が読めない文書までモデルに渡ることがある。モデルは渡された文書を区別せずに使う。
防ぐには、検索の段階で、質問した人が読める文書だけに絞る。MicrosoftのAzure AI Searchの文書は、文書ごとに読めるグループやユーザーのIDを持たせ、検索のたびに、質問した人が属するグループのIDで結果を絞る方法を説明している。同じ文書は、このIDは認証の仕組みではなく、絞り込みに使う文字列にすぎないとも書いている。誰がどのグループに属するかは、社内の認証の仕組みから正しく取ってくる必要がある。
3. 文書に紛れた指示に従ってしまう
検索した文書は、モデルにとっては指示と同じ場所に入る。文書の中に「この内容を外部に送れ」のような文が紛れていると、モデルがそれに従うことがある。外部の文書に紛れた指示で操られる攻撃の仕組みと対策はプロンプトインジェクションとはに書いた。
本番で効くRAGの設計
3つの理由を裏返すと、本番に出す前に決めておくことが見えてくる。次の表は、私の考える最低限の設計だ。
| 決めること | 中身 |
|---|---|
| 対象の文書 | どの文書を入れ、どの文書を入れないか。古い版の文書を残さない |
| 文書の分け方 | 見出しや条文の単位で分け、チャンクに文書名と章の名前を書き足す |
| 権限 | 文書ごとに読める人を持たせ、検索の段階で絞る |
| 評価 | 質問と正解の文書と正解の答えの組を作り、検索の正解率と答えの正解率を分けて測る |
| 答え方 | 出典を示す。文書に答えがなければ「わからない」と答えさせる |
| 更新 | 文書が変わったら、検索の対象もいつ作り直すかを決める |
評価と答え方は、RAGだけの話ではない。もっともらしい誤りを減らす設計の全体はハルシネーション対策に、RAGを作る側の職種と必要なスキルはAIエンジニアとはにまとめた。
私の見方では、RAGの品質を決めるのは、モデルの選び方より、文書と権限の整理だ。どの文書が最新で、誰が読めるのかが社内で決まっていなければ、どれだけ良いモデルを使っても答えは安定しない。その整理は、業務を知る人と一緒にしかできない。業務の現場に入ってAIを実装する職種についてはFDEとは？Forward Deployed Engineerの意味と仕事内容に書いた。
社内文書に答えるAIを、本番で使われるところまで持っていく支援の中身は、私たちのサービスで紹介している。