「RAG」が注目されている理由
生成AIに対する期待は大きいが同時に課題も多いことはこれまで見てきたとおりだ。AIガバナンスとして、回答の透明性や、ハルシネーションへの対応、プロンプトに社内情報をアップロードしてしまう情報漏洩などのセキュリティ課題、またトレーニングにおけるコンテンツの所有権の問題などがあげられる。さらにLLMは確率的生成を要素としているため、同じ内容のプロンプト問い合わせに対しても異なる回答が返ってくるが、同じ質問に対しては同じ回答が求められるケースもあるだろう。たとえば、医療関係や法律関係、教育現場、または顧客や利用者からの問い合わせを受けた企業の回答など、内容の正確度を重視し、回答の自由度に制限を設けたい場合だ。実際に業務で利用する際にハルシネーションをふりまくわけにもいかず、確度の高い回答が求められる。
こうしてみると、生成AIにおけるガバナンスには、利用者からみた視点とインフラプラットフォームを通じて生成AIを提供する側からのガバナンス視点があることが明らかだ。
提供する側の視点としてガバナンスを実現する観点では、生成AIの構築・運用において求められるスキルセットをもつ人材の確保や、ガバナンスレベルを保つサステナビリティ面からAIインフラへの投資コストの抑制という現実的な課題も存在する。
運用フェーズにおいてもガバナンスの課題はある。トレーニング済みのLLMモデルは、トレーニング以降の最新データについては回答できず、またトレーニングデータとして入手できない専門的な情報も学習できない。そのうえ、企業や組織固有といった機密度の高い情報も公開されていないのでLLMモデルにはトレーニングされない。新しい情報を取り込むための手法としてファインチューニングがあるが、トレーニング用のデータを用意する工数やファインチューニングを行うためのスキルセットは決して低くはない。ファンデーションモデルの開発ほどではなくともある程度のAIインフラへの投資が必要となるうえ、更新のたびにファインチューニングを行うのは現実的ではないと言える。
そこで、特に2023年後半からよく取り上げられるようになったアーキテクトとして、RAG（Retrieval Augmented Generation：検索拡張生成）がある。
RAGは一言でいうと、プロンプトへの回答に対しLLMモデルが知らない情報をLLMモデルとは別に用意したデータベース（主にVector-DBが選択される）に格納し、そのデータベースへの検索結果を加えてLLMからの回答を生成することでシステム全体の回答性能を向上させる生成AIのフレームワークである。
たとえば、顧客からの問い合わせ対応として、製品仕様は変更がなくとも納期状況は逐一変動する。納期状況が変わるたびに、LLMモデル自体をファインチューニングして反映するわけにもいかない。インターネット上に公開できない情報もあるが、社内データベースでは管理しているケースも多い。このような場合、RAG利用が有効である。
また、更新頻度が低く社内に限定された情報を扱うケースでも有効だ。ヘルプデスのスタッフは顧客の対応履歴データベースの情報をもとに過去の背景を理解し、現在起きている問い合わせに対しRAGが利用できる。
RAGの具体的な運用イメージとしては、たとえば社内特有の情報が記載されているPDFをデータベースに格納し既存のLLMと連携することで、汎用的な情報でトレーニングされたLLMモデルに個別の情報を加えることができるようになる。個別データをもとにLLMモデルと連携するため、通常のLLMモデルのようにはその回答内容はぶれない。
さらに、組織内固有データのため一般には公開されていない情報や専門性の高い情報も管理下のデータベースであれば格納できるし、格納データに機密度のレベルをセットすることもできる。頻繁に更新される情報もファインチューニングなしでセキュアにLLMの回答に加えることができる。
思い返せば、社内には既に多くのデータが存在する。
- 営業・マーケティング資料
- CRPおよびERPデータ
- 顧客からの問い合わせ履歴
- サプライチェーン状況
- 専門性が高い固有情報であるR&D結果
- 社内システムの 各種ログファイル
これらを取捨選択しながらデータベースに取り込むことでLLM回答に加えることができる。どのデータが根拠となっているか明示でき、ハルシネーションも防げる。ファインチューニングでもハルシネーションの低減は可能だが、大量のトレーニングデータの準備と時間、多くのAIインフラが必要となる。
