うちもRAGをやりたい！　どうやって進めればいいか詳しく教えて：生成AIお悩み相談室（1）（2/2 ページ）

　一般的に言われる、それぞれのメリットとデメリットは下の通りです。あくまでも一般的に言われていることであり、利用するモデルなどによって異なる場合があります。

　比較表を見るとローカル型に引かれる方も多いかと思いますが、個人的には最初はクラウド型の利用をお勧めします。クラウド型はトップクラスに精度が高いモデルが多いので、効果や結果が分かりやすく、検討が進めやすいためです。

　クラウド型で効果が見えた段階で、ローカル型に切り替えて検証・評価すると効率的に検討が進むかと思います。

　また、RAGはデータベースから取得した情報とユーザーの質問を合わせてLLMに問い合わせる仕組みであるため、データベースに登録した情報やユーザーの入力が外部に流れていきます。

　クラウド型モデルを利用できるサービスでは、「問い合わせた内容をモデルの学習に利用しない」というポリシーのものもあります。しかし社外に情報が送られるのは事実であるため、「極秘情報は入力しない」といった社内利用ポリシーの整理もしておくとよいでしょう。

　RAGについては自社で用意する案と、他社サービスを利用する案があります。

　他社サービスの場合、これまで運用してきたノウハウから取り入れた工夫や豊富な機能が提供されており、最初から精度が出やすい一方、利用料がかかります。

　一方、自社で進める場合はノウハウがない状態からのスタートとなりますが、利用料は抑えることができるかと思います。

3.ユーザーと意識合わせをする

　仕様検討フェーズで、ユーザーとも意識合わせをしておきましょう。

　意識を合わせる項目としては、ユーザー評価の事前依頼や、想定しているユースケース／効果／精度の目標設定などが挙げられます。

　開発担当チーム内で行う評価フェーズの妥当性を上げるため、可能ならユースケースの実例データや現在の運用で使っている情報や値を共有してもらえると、よりよいでしょう。

　ユーザー側の要望を取り込むことが重要ですが、希望が出てこないこともあります。そのため、「ユーザーから希望を引き出す」「ユーザーと議論する」という気概を持って説明や意識合わせに臨むといいかと思います。

　こうした意識合わせにより、施策効果の妥当性を上げながら、手戻りやユーザー評価時の不満・反発の予防にも繋げることができます。

　これらの活動を経て、ユースケースや目標を整理し、効果を出せる見込みが立ったら次のフェーズである実装に進みます。

2.RAGの実装

　前フェーズで決めたユースケースや仕様を踏まえ、これを実現する機能を自分たちで用意するか、他社サービスのトライアル／評価をするか、いずれかに向けて調整や推進を行いましょう。

　自分たちの手でRAG環境を用意する場合、「Dify」（ディフィー）と呼ばれるツールを利用するのがお勧めです。

　基本的な機能はグラフィカルインタフェース（GUI）上の操作で実現可能です。狭い範囲での利用や検証であれば無料版でも十分に活用できるかと思います。

参考：
「生成AI」×ノーコードツール「Dify」で学ぶ、チャットbot構築のいろは

　こだわりたい場合には、「LangChain」や「LlamaIndex」と呼ばれるフレームワークで実装するのが一般的ですが、プログラミングが必要となるため、感覚をつかむ上でもまずはDifyで試してみるのがいいかと考えます。

3.実装の評価

　本フェーズでは、ユースケースに応じたデータを使って評価を行います。

　「RAGAS」などのRAG評価用フレームワークもありますが、数値的には良い値でも、人が見るとギャップを感じる場合があります。最終的に使うのは人であるため、人が回答を見たときにどう評価するのかといった観点が重要です。

　また、正答率のような定量的な評価・分析だけでなく、「どのような質問にうまく回答できている傾向があるか」や「どういう誤りが多いのか」といった定性的な評価・分析も実施しましょう。

　この結果が、次のフェーズである「改善」につながります。

　なお、評価した結果、ユースケース自体が実はLLMやRAGに向いていなかったと判明することもあります。その場合は「仕様検討フェーズ」からまた考えましょう。

4.実装の改善

　本フェーズでは評価結果を見て、正答率を上げるためにはどうすればよいのかを検討します。

　改善の対象としては、RAG自体の処理の流れや仕組み、データベースに登録するドキュメント、データベースに登録する情報の前処理などが挙げられます。

　また、特定の質問方法（プロンプト）だと正答率が上がる傾向が見えた場合、ユーザーにその知見を共有し、活用してもらうといった、利用方法の改善もあり得ます。

　なお、RAGの処理改善については本連載で今後公開予定ですので、ご期待ください。改善案が整理できたら、それを実現するための仕様検討、実装、評価を行い、効果を確認します。

　このように、改善を繰り返していきましょう。

ユーザーによる評価

　成果物が一定の精度に到達したら、ユーザーに使ってもらって評価を行います。

　仕様検討フェーズでユーザーとユースケースや使い方を整理したとしても、細かい点でズレが生じる可能性はあります。また、正答率が事前に整理した値を満たしていても、実際に試してみると「役に立てづらい」と判断されることがあります。

　このため、ユーザー評価は最終段階で最低1回は実施する必要があります。可能なら複数回トライするのが理想的です。

　また、ユーザー評価は実行数を増やすため、期間を長めにとれるとよいでしょう。

　この際、「極秘資料は登録しない」などの利用ポリシーや利用マニュアルを、評価実施前にユーザー側へ共有できるとスムーズです。

　評価中や評価後は、可能な範囲で実際に試したデータをユーザーから共有してもらい、検討担当者も評価を行えることが望ましいです。相互の評価や意見を突合し、今後どのようにするか整理を行います。

導入の拡大に向けて

　ユーザー評価を経て現場での利用が決定し、さらに評価してくれたユーザーとは異なる部署や利用者にも拡大して導入する場合には、改めて利用ポリシーや利用をする際のリテラシー、精度の目安、上手く使うためのノウハウなどを説明することをお勧めします。

　似た業務やユースケースでも、部署によって扱いが違うことがあるため、導入前にユースケース特性の見直しやチェックをしましょう。

　また、導入後も、継続的な改善やメンテナンス（例えば社内ルールが変わった場合、古いドキュメントはデータベースに登録しっぱなしにせず削除するなど）を行うのが良いと思います。

おわりに

　本記事ではRAG導入の進め方を紹介してきました。

　実際の検討は限られた期間内で行うケースが多いと思いますが、最終的な精度はどれだけ多くのサイクルを回せたかにも依存します。このため、効率的に進めることもポイントとなりますので、必要に応じて上述の手法を取り入れてみてください。

　皆さんのRAGの導入や利用がうまく進むことを願っています。

筆者紹介

山口佳輝

NTTテクノクロス株式会社

フューチャーネットワーク事業部

第一ビジネスユニット

ネットワーク分野のシステム検討や開発業務に携わる。特に近年ではNTT版LLMである「tsuzumi」を含むLLMに関連した業務や、次世代通信・情報処理 基盤構想であるIOWNに関するプロジェクトに取り組む。

また、同社ブログ「情報畑でつかまえて」や技術書典での発信活動、社内での研修なども行っている。