RAG プロジェクトを成功させる方法 #1

弊社の公式メッセージから引用すると、以下の通りです。

検索拡張生成 (RAG) は、大規模な言語モデルの出力を最適化するプロセスです。そのため、応答を生成する前に、トレーニングデータソース以外の信頼できる知識ベースを参照します。大規模言語モデル (LLM) は、膨大な量のデータに基づいてトレーニングされ、何十億ものパラメーターを使用して、質問への回答、言語の翻訳、文章の完成などのタスクのためのオリジナルの出力を生成します。RAG は、LLM の既に強力な機能を、モデルを再トレーニングすることなく、特定の分野や組織の内部ナレッジベースに拡張します。LLM のアウトプットを改善するための費用対効果の高いアプローチであるため、さまざまな状況で関連性、正確性、有用性を維持できます。

正しいことを言っていますが、エンジニアからの「結局何なの ?」という端的な質問に答えるとするならば、

1. ユーザーの質問に答えるためのドキュメントを検索して
2. 生成 AI にドキュメントとユーザーの質問をつっこんで回答させる

という 2 つのステップがメインで、昨今の RAG 界隈はこの 2 つのステップに様々なステップやいろいろな分岐処理、ループ処理などを混ぜ混ぜしてワッショイワッショイと技術のお祭り騒ぎをしていると捉えていただくと迷子にならずに済みます。

例えば、GraphRAG が流行っていますが、GraphRAG は 1 の検索するための Database(DB) に GraphDB (AWS であれば Amazon Neptune という Graph Database があります) を採用し、 GraphDB にドキュメントを突っ込んで検索結果を取ってくるものです。なぜ GraphDB がいいかというと、従来のドキュメント検索 (キーワード検索やベクトル検索) だと、キーワードが含まれているか、意味が近いか、だけしか評価されず (※) に、主語・述語・目的語といった文脈が失われやすいので、GraphDB を使って主語・述語・目的語を意識した検索をできるようにしよう、といった流れを汲んでいるわけです。

※ 例えばユーザーが「小学生でも作れるカレーの作り方は ?」というクエリを投げたとき、キーワードだと「小学生にバカ受け !人気　カレーレシピ 3 選」のような親が作るレシピを引っ掛けたり、ベクトルだと「8/1 小学 6 年生になったので、そろそろ料理の 1 つでも出来ないといけないかと思い、親と一緒にカレーを作りました。…」みたいな夏休みの絵日記を引っ掛けるかもしれません (絵日記にはもしかしたらレシピが載っているかもしれませんが）。そうではなく、GraphDB に「小学生が (主語) 作れる (述語) カレーの作り方 (目的語)」でインデックスしておくとストレートな検索が出来るかもしれません。 

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% 間違える人間が作る意味はさておき)。つまり演算で解けるような精度が出せるようになってしまったのです。

今から 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 の問い合わせ及び正解の回答例を紹介します。

情シスが社内システム開発を想定してコードを生成する例です。

BOM の話をするといろんな BOM プロフェッショナルからそうじゃない、といった恐怖のツッコミが多々来そうで戦々恐々ですが、ここでは Bill of Material をただの部品表と捉えて (この時点ですでに怖い)、生成 AI で作ったグランドピアノの部品表の csv 形式を渡して、そこから使用している部品の数を聞いてみます (内容が合っているかは知りませんが、白鍵 52 + 黒鍵 36 鍵 = 88 鍵あるので良いことにしました)。

ここでは、Amazon の echo の Alexa がリクエストを理解しない、または応答しない というページのドキュメントを食わせ、回答を生成させてみます。

さてここから作ったデータセットで回答を生成できるか試しましょう。

RAG のドキュメントを injection して回答を生成するためのプロンプトテンプレートとしてユースケースビルダーを使用できます。ユースケースビルダーを詳しく説明したブログ記事は こちら ですのでぜひご参照ください。

さて、この 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. すぐにでも使うことができます。

RAG に使用できる Database は多種あり、もちろん AWS で使用できる Database のラインナップも豊富です。AWS で RAG の検索基盤として使用できる ベクトル DB 及び GraphDB の Amazon Neptune を紹介しつつ、RAG でどのように Database を扱っていくか、について紹介します。
乞うご期待 !!