見出し画像

なぜRAGは役に立たないのか?

こんにちは。

生成AIの知識拡張技術の1つであるRAGですが、いまいち役に立たないと感じてる人も多いのではないでしょうか?


ちまたでは、頑張ってチューニングしても精度は70%前後という噂もあります。

何も考えずにドキュメントを放り込んで70%だったら、まぁまぁ役に立つとは思いますが、何か月も泥臭いチューニングをたっぷりやって70%だと、

「そこまでやる必要あるのかなー」

という気もしますよね。

しかも永遠にそのデータが変わらないのであれば、チューニングし甲斐もありますが、たいていは日々状況は変化してドキュメントも陳腐化していきます。

最新情報が変化するということは、正解も変わってくるので時間がたてばたつほど、精度は悪くなっていくのです。

「生成AIとRAGを使って80%業務効率化できました!」


という眉唾な記事をよく見かけるようになりましたが、果たしてそこまでに費やしたコストと比較して効率化できているのでしょうか?

「とにかく定量的な成果をアピールしないといけないから、『効率化できました!』 ありきで報告しよう」

という事情はよくわかります。


とはいえ、データを日々最新化、精度の評価などの運用を考えなければならないので、そのあたりのコストと比較してどうでしょうか?


と疑問に思ったので、改めてRAGについて考えてみました。



RAGが役に立たない理由

1. 正解が欲しい人向けに提供してしまう


たとえば利用者が「正解が欲しい」あるいは「利用者自身、AIからの回答が嘘か本当か見分けがつかない」場合は活用シーンが間違っている可能性が高いです。

ヘルプデスクへの問い合わせする場合を考えてみましょう。

問い合わせする利用者は、わからないことに対して正解を求めて利用しているのに、「回答内容が本当か嘘かわからない」状態だとどうでしょうか?

仮に70%は正しい回答だったとしても、問い合わせする人にとっては見分けがつかないので、回答内容は100%正しい答えとして受け止めてしまいます。

間違った回答に誘導されて、そのとおりと思い込んだ人がいた場合、大事故につながる場合はとても使えないと思います。
なぜなら回答精度が70%だとすると30%も大事故を引き起こしてしまうことになります。

大事故につながらなくても、間違った回答を鵜呑みにしてしまって、何か違った操作をしてしまうとか少なくとも悪影響はあるでしょう。

なので、そもそも「正解を求めている人」に対してRAGを活用したヘルプデスクを提供するのはとても難しいのです。

反面、ヘルプデスクの中の人が活用するにはRAGは有効な手段です。

ヘルプデスクの中の人であれば、RAGの回答が正解かどうかはすぐにわかると思いますので、「検索」代わりに使うのは有効です。

正解だと思ったらそのまま生成AIの回答をカスタマーに返答できます。
もし間違いだと思ったら、再度検索するかあきらめて自分で返答文章を作ることもできるでしょう。

なので、「必ずしも正解を求めていない」人向けに提供するのはRAGはとてもコスパがよい検索システムになりえます。


2. 意見や見解を求める

RAGの仕組みとしては、検索によって文章を抽出して、その抽出した文章を組み合わせて、最後にLLMが回答文を作っています。

つまり、検索した結果がベースになるので、RAGに放り込んだドキュメント全体に対して生成AIが回答しているわけではありません。

ベクトル検索した結果で、上位10件の文章を引っ張ってきたとしても、その10件は全体の文章のうち、どれくらいの割合なのでしょうか?

大量のドキュメントをベクトル化すればするほど、検索した結果の10件の割合は少なくなってしまいます。

例えば全体で1000件のチャンクの文章があったとして、10件だと何%でしょうか? 1%の文章だけなのです。

人間でもそうですが、断片的な情報しかないのに最適な回答が得られる可能性はとても低いです。

そもそも1%の情報しか渡してないのに、AIがまともな見解を回答できるはずがないのです。

「RAGは回答精度が悪い」といわれても、生成AIからすると、

「そもそも1%しか情報もらってないのに文句言うな!」

と、きっと思ってるでしょう。笑


ではどうすればいいのか?

残念ながら今のところ、生成AIが事前学習以外の独自データを扱う場合、しばらくはRAGがファーストチョイスです。

他の技術としては、ファインチューニングがありますが、手間暇かかりすぎるのと、トライ&エラーによる検証も時間がかかりすぎます。


ドキュメントが1つくらいであれば、最近のLLMモデルでは多少長いトークンも対応していますので、プロンプトに原文そのまま貼り付けるという手法もあります。
ただし、そこそこの文章のドキュメントを複数プロンプトに貼り付けるのは限界があります。

生成AIで独自データを活用するには、現状RAG以外に有効な技術が見当たらないため、みんなRAGの精度改善に深入りせざるをえない状況かと思います。

RAGに代わる技術が出てこないかなー、と動向をウォッチしていますが当面はRAG一択が続きそうです。

Agentic RAGといった、AIエージェントとRAGを組み合わせる手法もありますが、RAGの枠から超えることは無いでしょう。


精度向上のために、ハイブリッド検索やGraphRAGの活用も流行っていますが、ドキュメント次第で良し悪しが変わってくるので、特定の領域では精度が上がったけど、不得意な領域では逆に精度が悪くなるといったことが多々あります。

たいてい、これらの新しい技術を評価する人は、うまくいった結果だけ報告しがちなので、最初はみんな「これはすごい! ぜひとりいれよう!」となりますが、実用段階で、「あんまり変わって無くない?」と残念な結果になることが多いのです。

検索技術やテクニックに時間かけるより、地道にドキュメントのデータクレンジングなどを泥臭くやったほうがよっぽど精度が上がるでしょう。

従来型のRAGに対して、「Advanced RAG」という言葉も出てきていますがまずは、データの質を高めることがRAG精度向上の近道だと思います。



まとめ

RAGは軽く使う程度であれば、手軽に外部データを生成AIで活用することができる素晴らしい技術です。
ただ、むきになって精度向上をねらっても骨折り損になる可能性が高いです。

RAGは、低コストでそこそこの精度を発揮できるもので、高精度な回答を期待するものではないと割り切って活用するのが一番よいでしょう。

そのうち、LLMに代わるいろんなタイプのSLM(Small Language Model)が登場して、ファインチューニングももっと手軽にできるようになったら、RAGは不要になってくるかもしれません。

RAGはほどほどにして、生成AIの活用方法を考えるほうに時間をかけるほうが有意義です。

とはいえ、
「RAGの精度向上が至上命題となっているので、やらねばならない」
という人もいると思います。

そんなときは、「Advanced RAG」の中から良さそうな技術を取り入れていくのがよいと思います。

Advanced RAGの例














いいなと思ったら応援しよう!