RAG プロジェクトを成功させる方法 #1 ~ あるいは早く失敗しておく方法 ~

RAG をやる際、エンジニアの方は「腕が鳴るぜ !」と言わんばかりにデータべースを立ててドキュメントを突っ込んで LLM を呼び始めたくなります (私はそっちの方の人間です）。しかし、AI/ML 案件全般に言えることですがまずは一歩立ち止まり、なぜ RAG を入れるのか、RAG を入れると業務がどう楽になるのか、業務コンサルタント的な思考で RAG 案件をドライブさせていきましょう。

よくある失敗は、

「1 日で DB に社内ドキュメントぶちこんで RAG のシステム立ち上げたぜ ! ｵﾚｽｹﾞｰｰｰｰｯ !」

からの1週間後

「嘘回答ばっかりこんなもん使えん ! と言われたでござる…」

みたいな話です。ここから改善活動がうまく行けばいいのですが、初っ端の精度が悪いと誰も使ってくれないシステムになってしまうことも多く、AWS としても利用料が増え… (ｹﾞﾌﾝｹﾞﾌﾝ

さて、そうならないためにもまず、

「誰がどんなふうに使ってこんな効果を出すためにはどれくらいの精度が必要なのか」

を明らかにしましょう。

例えば我々エンジニアが RAG を使いたいときはどんな時でしょうか。私は AWS の人間なので、AWS のドキュメントをよく読みますが、本当はドキュメントを読みたいわけではなくやりたいことを実現するためにドキュメントを仕方なく読まざるを得ない時があります。

具体例を上げると、「Amazon Elastic Compute Cloud (Amazon EC2) のインスタンスから閉域で Bedrock のエンドポイントにリクエストするにはどうすればいいのか ?」を知りたい場合、Amazon EC2 や Amazon Bedrock のドキュメントを読みたいわけではなく、ただそのやり方を知りたいだけです (できれば読みたくありません。技術的な仕組みの理解はあったたほうがいいですが）。もしその知識がなかったら、「EC2 Bedrock 閉域」とかで検索し、Amazon VPC Endpoint のドキュメントに行き着き、VPC Endpoint を作成して VPC Endpoint 経由でアクセスする方法を調べるはずです。

ここで仮に理想的な RAG があった場合を想定しましょう。「Amazon Elastic Compute Cloud (Amazon EC2) のインスタンスから閉域で Amazon Bedrock のエンドポイントにリクエストするにはどうすればいいのか ?」という問い合わせに対して、VPC エンドポイントのドキュメントを引っ張ってきて、Amazon Bedrock の VPC エンドポイント作成方法及び、作成する boto3 のコード、ないしは AWS CDK のコードまで出してきてくれてそれがそのまま動けば最高でしょう。

一方失敗するケースを想像してみましょう。ないとは思いますが Amazon.com に対して閉域でアクセスする方法を回答しようとしてしまうかもしれません。そのとき回答は Amazon.com のデータセンターを突き止めて、LAN ケーブルを挿しアクセスしろ、と回答するかもしれません (絶対にやめてください）。さて、そんなときはその回答を使うことはできません。質問の仕方を変えるか、あるいは自力で調べる必要が出てくるでしょう。

我々は RAG が正解するときも誤答するときも、病めるときも健やかなときも、富めるときも貧しき時も RAG を愛し敬い慈しむことを誓っているわけですが、実際の業務で使うとなると、精度というのを意識する必要があります。仮に 10000 回やって 1 回しか正解を返さないとしたら文字通り万が一で、AI の大喜利には付き合いきれません。

しかし、生成 AI で 100% の精度というのはありえません。

間違ったことを言ってしまう可能性がある中、どこまでなら許容できるのか、人間の大きさを見せつけるわけではないですが、誤りの発生をどこまで許容できるかで RAG とのお付き合いできるか否かが決まります。先の例の場合、仮に Amazon.com に対してデータセンターに LAN ケーブルを挿す指示が出ていたら、ハイパーハイスペック人間の G さんじゃなくても AI が何もかも間違っていることに容易に気づくことができるでしょう。あるいはもっともらしい嘘を並べられても、エンジニアであれば実際に実装してテストしたときに誤りに気づくことができるでしょう。つまり嘘をつかれることが問題なのではなく、どれだけ実装工数を削減できるかにフォーカスされます。簡単に数式化するのであれば、

削減工数 (コスト) - 嘘に振り回される工数 (コスト) > システム構築費用 + 運用費用

を満たせば RAG を導入でき、それが精度によって決まると言えます (それとは別に皆さんに使ってもらうための RAG 啓蒙活動 ≒ 布教活動が必要ですが、それはまた別の機会に)。

さて、 エンジニアの例は誤りを許容しやすい例として上げました。「いやいや、うちの業界は誤りなど許されないから導入できん」といった声が聞こえてきそうですし、私も実際に耳にしたことがあります。

しかし、果たしてそうなのでしょうか。

よくあるケースだと企業がエンドユーザーに対する問い合わせでコールセンターが担っていた問い合わせを RAG に代替することでコスト削減する、といったものです。EC サイトだと例えば「購入した商品の返品の条件と方法」などの問い合わせは日常茶飯事です。もちろん同じ問い合わせであれば固定の回答を用意すればよいのですが、少しだけ違う時などは RAG で置き換えることが可能でしょう。

しかし RAG を使う以上、そのときは精度 100% はありえません。では仮に誤った情報を RAG が提供してしまった場合どうなるでしょうか。エンドユーザーは返品しないといけないので、間違った方法を案内 (例えばできない手続きをガイド) されたら試して不可能と判断したら直接連絡してくるでしょう。であれば、顧客満足度を多少犠牲にせざるを得ませんが、誤った時用のコールセンターの口を用意すれば RAG を導入できるはずです。あとはどこまでの顧客満足度低下を許容できるかの精度の問題に出来るはずです。

しかし、ここでも 1 つ議題に上げていただきたいところがあります。「コールセンターで行われるガイドに一切間違いはないか ?」というところです。このような議論をする時、人間神話とも言える「人間が実施すれば間違えない」という前提が出てきますが、どれだけ細かく対応ガイドラインを用意したとしても、お客様から寄せられる様々な質問に対して間違いなく答えることは実際には非常に難しい事です。かく言う私も Solutions Architect というロールで AWS のサービスを様々なシーンでお客様に紹介しており、最善の努力はいたしていますが、知らないうちに入っていたアップデートなどで古新聞をお客様にガイドしてしまうこともあります。

そんな時は

「本来できるはずなのだ…… ! 本当にすまないという気持ちで……… 胸がいっぱいなら…… ! どこであれ土下座ができる…… ! たとえそれが…… 肉 焦がし……骨 焼く………鉄板の上でもっ…………… !」

という気持ち (これは謝らせる側の気持ちですが) で、謝ればたいていのことは許されます (たぶん)。

RAG とは関係ない話ではありますが、一般に精度が求められる医療の現場でもそれは同じです。
様々な病気において検査方法が確立されていますが、どれも精度 100% の検査など基本的にありません。だからこそ、各病気の症状が出ている人に対してしか検査をしないことで少しでも精度を上げ、それでも誤ってしまった場合は治療の中で改善しないことをトリガーに検査を疑うアプローチです。
場合によっては人の命が懸かる現場でも精度 100% は不可能なのですから、たいていの場合において精度 100% を求めるのはナンセンスではないでしょうか。そうではなく、あくまで誤ったときの損失より RAG を入れるときの便益を上回るか (と誤ったときのワークアラウンドを作れるか) どうかだけで判断するのが良いように感じています。

「これは AI が間違うことが許されないケースだ」と最初から断定して諦めるのではなく、どうすれば人間が楽になるのか (その結果コールセンターだったら離職率の低減を狙えるかもしれません)、あるいは、どうすれば自社プロダクトの価値が向上するのかのような観点からスタートするとよいのではないでしょうか。

演算において人間は機械にもはや構わないでしょう。Excel で 100 万行を一瞬で解くコンピューターに勝てる人間はいません。そして、人間の価値は演算では解けない部分にシフトしてきました。人間の認知能力はなかなか高いもので、猫を猫と認識したりするのは長らく人間の特権でした。しかし、2015 年 2 月に様相が変わります。Microsoft Research が出した論文の Delving Deep into Rectifiers: Surpassing Human-Level Performance on ImageNet Classification において ImageNet という画像認識モデルが人間の精度を超えました。このタスクはそもそも難しく、人は 5.1 % の割合で誤ってしまうのに対し、ImageNet は 4.9% しか間違えなかったそうです (そもそも正解データを 5.1% 間違える人間が作る意味はさておき)。つまり演算で解けるような精度が出せるようになってしまったのです。

よく機械が誤るデータ例 : 手書き数字で有名なデータセットの mnist には人間だろうと機械だろうと判別し難いものがあり、これはもはや書いた人間が悪いレベルです (4 なのか 9 なのか判別できません。小学校のテストだったらどっちだろうとバツをくらってしまいそうです)。

今から 10 年前に画像認識で人間はコンピューターに負けているのですから、RAG の回答と人間の回答がどちらが高いのか、もちろんワークロードに依りますが、人間が負けることもあることを前提に検討してもいい時期に来たと考えてよいはずです。

ここまでポエムをいろいろ書きましたがここからは RAG システムを開発するぜ !! と決まった後の話をしていきましょう。

満たすべき精度が決まったとしたら、精度を計測する必要があります。そのためには、質問と回答そして回答を導くためのドキュメントのセットが必要でしょう。

RAG においてはよく Data Leakage が発生します。ここで言う Data Leakage とは RAG システムを構築する際に使用したデータセット (= それを用いてチューニング) を用いて精度を計測してしまうことで、Data Leakage を起こすとそのデータセットに適合して汎化性能が失われてしまう可能性があります。しかし、ここでは Data Leakage の話は一旦考慮せずに、用意した問題をそもそも生成 AI が解くことができるのか、にフォーカスします。

なぜそんなことをするのかというと用意した典型問題が解けなければそもそも RAG システムが成り立たないためです。

その問題、生成 AI で本当に解ける ? これは本稿のメインメッセージでありすべてです。

機械学習でもそうなのですが、トレーニングデータを解けなければ汎化性能の話をする以前の問題です。数学で例題が解けなければ同種の問題を解けないのと一緒です。よくある RAG システムに対する問い合わせに対して、プロンプトに正解のドキュメントのみを挿入し (= 検索精度は 100% の前提）、求める回答を得られるのか、のチェックをすることは早い段階で RAG システムを (いい意味で) 早めに見切りをつけることができます。

逆に典型問題でいい回答が得られたら検索の話に進んでよいでしょう。

典型問題、と言いましたが、具体的にどんなデータを用意すればよいでしょうか。

allganize/RAG-Evaluation-Dataset-JA のような RAG 用の日本語データセットもありますが、これらは幅が広過ぎて(1 行目の火災保険の問い合わせに対して、「そうそうこんな質問よくやるわ !!」ってなる人は火災保険業界の人だけでしょう)、LLM の一般的な評価には良いですが自社 RAG の参考にはなりません。

私見ですが、自社の利用を想定したデータセットを最低 20 件用意することから初めて見るのはどうでしょうか。なぜ 20 件か、精度を % にしたときの妥当性と用意の手間の天秤です。例えば、「3 件用意して 3 件正解でした ! なので精度 100% です !」と言われても、データが少なすぎて心もとないですし、これが 「2 問正解で 66.7% !」 と言われてもホンマかいな、以外の感想はありません。かといって 100 件用意するのも大変です (データセットをちゃんと作ろうとすると 1 時間で 2 件くらい作るのが限界です)。20 件あれば、 1 件の正誤が追加になっても最大で 4.1 % (最小で 0.2%) しか変わらないので信頼感が多少あります。

• 情シスが AWS のドキュメントからコードを生成する例

• 調達部門が BOM を参照して必要な部品を取得する例

• カスタマーサポートが製品の不具合に対して解決方法を示す例

使用部門がバラバラですね。ここで申し上げたいのは、本来これらの RAG ロジックはできるなら別に用意すべき、ということです。情シス、調達部門、カスタマーサポートが同じ検索基盤を使って retrieve をしようとすると用語の混同などが容易に発生します。例えば「コードを生成」は新部品の部品コードの生成と取られる可能性がありますし、情シス部門での「BOM」は Bill of Material ではなく Byte Order Mark と取るでしょう。製品の不具合については、カスタマーサポート、情シス、調達部門でそれぞれ意味合いが全く異なりますし、それぞれがお互いの情報を見る必要が全くありません。これらを混同した RAG システムを構築する意味はなく、精度劣化を防ぐために技術的に難しいこと (e.g. エージェントによる質問意図理解など) に挑戦する必要が出てくるかもしれません。

RAG ロジックの分離はいくつかやりかたがあります。1/ そもそも画面を別にして完全に別物として作る、2/ ログインしたユーザーの認証によって使用する RAG の API をルーティングする、3/ 検索基盤側でメタデータフィルタリングを使う、あたりでしょうか。技術的難易度は 1 < 2 < 3 の順で難しくなり、コスト (AWS の費用) は 1 > 2 > 3 の順で高くなる傾向があるので、ちょうどよいところを探しましょう。

話が長くなりましたが、3 つの RAG の問い合わせ及び正解の回答例を紹介します。

さて、この 3 問については回答できました。サンプルのデータセットの件数を増やしたり、あるいは部署ごとに RAG を分けるなどの対応は行いたいところですが、一旦これでヨシとしたとします。今後何をすべきか、ですがここから検索用の DB などを立てていく・・・のもよいのですが、もう少しこの段階でやれることもいくつかあります。

今回は使用する生成 AI に Claude 3.5 Haiku というモデルを使用しました。このモデルは比較的安価ではありますが、さらなる安価なものを試していけるかをチェックしても良いでしょう。

また、今後 Vector DB で検索する場合は Chunking という文書を分割する処理を行うでしょう。どれくらいのサイズが良いのか、という当たりをつけるため、Bedrock の入力トークン数を計測しておいてもよいでしょう（boto3 の converse API の Doc はやや長めの chunk にしないと使い物にならなさそうです)。

そもそも正解の回答を生成できなかった場合は例えば以下のアプローチを考える必要があります。

• ドキュメントを直す
  ドキュメントと質問が遠すぎるなどで回答を得られなかった可能性があります。いくつかのパターンがありますが、入力した情報が多すぎて必要な情報が埋もれてしまう (Lost in the middle の問題) 場合や、質問に対してドキュメントから回答を生成するには論理的な思考が必要な場合は、質問に対して直接的な表現にドキュメントを修正すると効果が出るでしょう。ただし、ドキュメントに修正を入れる場合は様々な質問に対応する必要があるため、修正範囲が膨大になるかもしれませんので、生成 AI に手伝ってもらう、などの工夫が必要になるかもしれません。
  また、BOM のケースでは、RAG ではなく Agent アプローチで、BOM が格納されている DB に対して SQL を発行してもらうような仕組みのほうがフィットするケースもあるでしょう。他にも BOM の例では csv をデータとして渡していましたが、LLM はマークダウン形式の表の解釈が苦手なこともあり、元データが csv ではなくマークダウンだった場合は csv への変換などの処理が必要なケースもあります。

• プロンプトに工夫を入れる
  今回はあらかじめ Chain of Thought の手法 (思考過程を出力させてから回答を生成させる) を入れたり、確定的な情報しか出すな、などのプロンプトを入れています。しかし、ワークロードによってはプロンプトの工夫の余地があるはずです。ただし、Specific なプロンプトにすればするほど汎化性能 (特定の問題は解けるようになるけれども他の問題が解けなくいなっていく) は落ちていく傾向にありますので、注意が必要です。

これらをまずやることで、RAG プロジェクトが成功する確率は爆上がり、あるいは初期に諦めることも容易になることでしょう。

「いきなり RAG を組むな、まずはプロンプトから試せ」が本稿のメッセージです。

また、本稿の蛇足ですが、わざわざ検索しなくても人間が決め打ちで入力したいドキュメントが確定している場合（e.g. 前回の議事録など)は、検索基盤を作る前からユースケースビルダーを使えば検索精度 100% の手動 RAG がすでに出来上がっていることにお気づきでしょうか。RAG 開発をしながら、手動 RAG を使うことで現在の業務改善(実際に RAG 開発前に手動でドキュメントをつっこんで使っていらっしゃるお客様も本当にいます)に加えてこれから行う RAG 開発のインスピレーションを得るのもよいでしょう。May the GenU be with you. すぐにでも使うことができます。