BLOGAzureブログ

皆さまこんにちは、SB C&Sの八釼です。
生成AI (LLM) 界隈ではごく当たり前に使用される言葉となったRAGをご存じでしょうか？細いことは後述しますが、簡単に言うと外部から情報を取得して回答を生成する概念です。

実は過去の記事でも抽象的に表現したり、最近の記事では簡単にRAGについて触れていました。以前はまだ世間での認知度が低かったのであまり踏み込まなかったのですが、私の業務においても社内外の関係者と会話する際に頻繁にRAGという単語が飛び交うようになり、そろそろ機は熟したということで取り上げることにしました。現在ではこの界隈に関わるのであれば、この言葉とざっくりとでも内容を理解しておくことは不可欠とも言えます。

【関連記事】AzureにおけるAI関連のサービスの大枠を知っておこう

ということで、このような背景から今回はRAGについての概要をご紹介します。Azure OpenAI Service (AOAI) の活用を考える際にもかなりの確率で関係してくる概念ですので、ぜひ最後までお付き合いいただけますと幸いです。

• 目次
• 1.RAGとは
• 2.RAGが推奨される理由
• 3.RAGシステムの要素
• 4.最後に

RAGとは

Retrieval Augmented Generativeの略であり、検索拡張生成と訳される手法であり概念です。ここで最も重要な単語は 『 Retrieval (検索) 』 です。何らかの検索の仕組みが必ず必要です。RAGアプリケーションの例としてはCopilot (旧Bing Chat)です。アプリから何かについて質問をすると情報ソースとなるウェブサイトの情報と共に回答をくれますよね。Copilotは裏側でBing検索をしているわけです。

RAGが推奨される理由

まず大前提に知っておかなければならないこととして、機械学習を経てモデルとして提供されるということです。一般のユーザーはこの工程に関わるわけではないので忘れがちですが、当然ながら色々と学んだ結果タスク(推論)を行うことができるモデルとしてデプロイされるわけです。つまり学んだ以後に更新された情報のことは知りませんし、学んでいないことは分かりません。そこで厄介なのがハルシネーション(幻覚)です。知らないなら知らないと回答してくれれば良いのですが、いわゆる知ったかぶりをしたりします。

では、知らないことは追加で教えてあげればよいのでは？と思われるかもしれません。ファインチューニング(微調整)と呼ばれる方法があり確かに実現可能です。ただ時は常に流れ情報は更新され知識が古くなるため日々このような学習を行う必要がありますし、学習用データを準備するのもそう簡単なことではありません。というか(細かなことは省略しますが)あくまで微調整ですので、例えば自組織の独自データや世界中の公開データを日々学習させ有用なものにするというアプローチは言葉的にもよろしくない気がしてきますよね？

単純に言語モデルが知らないことを加味して推論結果を得たいというだけであればCopilotのように検索させる方が、最新かつ信頼性のある情報からユーザーにより良いアウトプットを提供できる確率が上がりますし、何よりシステム/アプリケーションを提供する立場から見ても格段にコストが小さいです。

RAGシステムの要素

では、こういったRAGのシステムを構成する必須の要素はどのようなものがあるのでしょうか？

それは

• 検索システム
• オーケストレータ
• LLM

の三つです。LLMは説明不要ですね。

検索システム

Bingのようなインターネット検索エンジンやSQLのデータベースがわかりやすくイメージしやすいと思います。ただ、これだけだと恐らく皆様の検索させたい情報としては要件が満たせない場合があるのではないでしょうか？

そう、自組織のPDFなどのドキュメントファイルです。例えば会社の規定などのドキュメントや社内Wikiなどの独自情報の内容を検索させたい場合が多いと思いますが、当然ながらインターネット上に公開されてはいませんしリレーショナルデータベースに格納できるデータではありません。

いやでも、ドキュメント検索のシステムは他のものと比べてハードル高くない？と思われた方もいるかもしれませんが、その場合にはぜひ Azure AI Search をご活用ください。というか、AzureでRAGシステムを組むなら避けては通れないと考えていただいて差し支えありません。詳細については以下の公式ドキュメントをご確認していただければと思いますが、高度な全文検索が可能なPaaS型サービスです。ドキュメントの内容を事前にインデックスとして登録しておき、検索時にはインデックスからドキュメントを引き当てることができるため、高速に検索を行うことができます。
公式ドキュメント | Azure AI Search とは

オーケストレータ

オーケストレータについては、少々イメージしにくいかもしれませんが最も重要な要素です。これはユーザーの質問を受けて関連するドキュメントを検索したり、LLMに回答生成の指示を行ったりするするモジュールです。RAG全体の処理やプロンプトを定義し、検索システムやLLMとの仲介を行います。

つまりは、ユーザーに対する窓口業務を行う存在といった感じで、

• 1. ユーザーからの質問に基づいて、関連するドキュメントを検索
• 2. 検索結果の中から関連性の高いドキュメントを選定
• 3. 検索結果をプロンプトに埋め込み、LLMから回答を取得
• 4. 取得した回答をユーザーに提供

といったような処理を行うわけです。

Azureで実装する場合には大きく以下の種類の方法があります。

• Azure OpenAI On Your Data(ノーコード)
• Azure Machine Learningプロンプトフロー(ローコード)
• フルスクラッチ(自前で実装)

下に行くほど実装難易度が上がりますが、その分カスタマイズ性も高くなります。On Your DataであればAzure OpenAI Studio (Web UI) を使用して簡単に実装ができますので、まずは試してみたいという場合にはおすすめです。プロンプトのチューニングをしてよりしっかりオーケストレータを作成したい、でもなるべく簡単に実装したいのであればプロンプトフローが良いでしょう。

フルスクラッチ(自前で実装)と聞くと一気にハードルがものすごく高くなった気がしますが、基本的にはLangchainやSemantic Kernelなどの便利なライブラリを使ってプログラミング言語で実装すると考えて頂ければ差し支えないです。

ちなみに、On Your Dataやプロンプトフローが提供されはじめたのは比較的最近です。それまではスクラッチが当たり前でしたので、それ以前からLLMアプリケーション開発をされている方にとってはこういったノーコード・ローコードの方法は逆にしっくりこないかもしれません。

最後に

今回はRAGについてや、そういったシステムやアプリケーションをどのように実装/開発することになるかを簡単にご紹介させていただきました。Azure OpenAI Service(AOAI)のモデルだけでは大して有用なものは開発できませんが、RAGアプリケーションにすればだいぶ話は変わってきますね。さらに高度で有用なアプリケーション開発も可能ですので、ぜひAOAIを組み込んで創っていただけますと幸いです。

しかしながら、前述したとおり実際にアプリケーションやシステムを開発する場合にはさまざまな技術選択や考慮が必要になりますのでいろいろとお困りごとがでてくることもあるかもしれません。その際にはぜひとも法人でのAzure導入前の相談窓口であるAzure相談センターまでお気軽にお問い合わせいただけますと幸いです。弊社ではユーザー様のご状況やご要望を踏まえて最適な形でのAzureの導入のご支援を提供しております。