RAGは Retrieval-Augmented Generation の略です。日本語だと「検索で補強した生成」あたりになります。
やっていることは単純です。AIに質問を投げる前に、答えに必要そうな資料を探してくる。その資料を質問と一緒に渡して、それを見ながら答えさせる。
「社内のマニュアルを読んで答えるAI」の中身は、たいていこれです。
原論文が問題にしていたこと
この考え方をまとめたのは、2020年5月に公開された論文です。Patrick Lewis氏ほかによる Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。
論文が指摘していたのは、パラメータの中にだけ知識を持つモデルの限界でした。知識にアクセスして正確に扱う能力が限られていること。そして、判断の根拠を示すことと、世界についての知識を更新することが難しいこと。
この2つは今でもそのまま残っている問題です。
学習し終わったモデルの中身は固まっています。新しい情報を足したければ、訓練をやり直すしかない。しかも、なぜその答えを出したのかを追えません。
論文が提案したのは、記憶を2種類に分けることでした。学習で身につけたパラメータ側の記憶に加えて、外から引ける記憶を持たせる。実装では、Wikipediaを密ベクトルの索引にして、学習済みの検索器から引くようにしています。
結果として、パラメータだけのモデルより具体的で、多様で、事実に沿った文章を生成したと報告されています。
中身は3つの段階に分かれる
| 段階 | やること |
|---|---|
| 準備（事前） | 資料を適当な長さに切り、それぞれを数値の並びに変換して保存しておく |
| 検索 | 質問も同じ方法で数値に変換し、近いものを保存先から探す |
| 生成 | 探してきた資料と質問をまとめてAIに渡し、それを見て答えさせる |
文章を数値の並びに変える処理をエンベディングと呼びます。意味が近い文章ほど、数値としても近い位置に来るように作られている。だから「有給の申請方法」で検索したとき、「休暇取得の手続きについて」と書かれた文書が引っかかります。
キーワードの一致ではなく、意味の近さで探せる。ここがRAGの肝です。
追加学習との違い
社内の情報をAIに扱わせる方法として、モデルを追加学習させる手もあります。どちらを選ぶかで悩む場面は多いはずです。
| RAG | 追加学習 | |
|---|---|---|
| 資料を足すとき | 索引に入れるだけ | 訓練をやり直す |
| 根拠の提示 | 参照した文書を示せる | 示せない |
| 情報の更新 | その場で反映される | 反映に時間と費用がかかる |
| 向いていること | 事実や手順を答えさせる | 文体や振る舞いを寄せる |
社内規程やマニュアルを扱いたいならRAGです。内容が変わるものを追加学習で覚えさせると、更新のたびに費用がかかります。
一方、返答の口調を自社らしくしたい、特定の書式で必ず出力させたい。こちらは追加学習の領分になります。
作る前に決めておくこと
手を動かす前に決まっていないと後で作り直しになる項目が、いくつかあります。
まず、誰がどの資料を見てよいか。人事情報と全社共有のマニュアルを同じ索引に入れてしまうと、権限のない人に中身が出ます。索引を分けるか、検索の時点で絞り込む仕組みが要る。後から足すのは面倒なので、最初に決めます。
次に、資料が更新されたときの反映です。索引に入れた内容は自動では変わりません。元のファイルが差し替わったら、古い断片を消して入れ直す必要がある。ここを設計しないと、半年後には廃止された規程を根拠に答えるAIができあがります。
3つめが、どこまでを対象にするか。手当たり次第に社内文書を入れると、似た内容の古い版が大量に引っかかって精度が落ちます。数を入れるほど良くなるものではありません。
根拠を出せることの価値
RAGの利点として速度や費用が語られがちですが、実務でいちばん効くのは根拠を示せる点だと思います。
「規程の第12条にこう書かれています」と出典付きで答えられれば、利用者は自分で確かめられます。逆に、出典のない答えは確かめようがない。業務で使うなら、この差は決定的です。
原論文が最初に問題として挙げていたのも、判断の根拠を示せないことでした。性能の話ではなく、そこが出発点だったわけです。
うまくいかないときに疑うところ
RAGを組んで「思ったより使えない」となる場合、原因はたいてい生成ではなく検索の側にあります。
資料の切り方が粗いと、必要な部分が別々の断片に分かれてしまいます。逆に細かく切りすぎると、前後の文脈が失われて意味が取れない。見出しごとに切る、段落の境目で切る、といった調整が要ります。
表やPDFも詰まりやすい箇所です。表を単純にテキスト化すると、行と列の対応が壊れて読めないものになります。
検索が正しい資料を引けているかは、実際に引いた中身を目で見れば分かります。答えの質を議論する前に、そこを確認したほうが早い。
もうひとつ、渡した資料に答えが書かれていないとき、AIが自分の知識で埋めてしまうことがあります。「渡した資料に書かれていなければ、分からないと答えて」と指示に入れておくと、この事故はかなり減ります。
出典
RAGの定義と、論文が指摘した問題点の記述は、下記の原論文に基づきます。実務での位置づけについては、AWSの公式解説もあわせて参照しました。
