企業がRAGを使う際の高いハードル
生成AIの活用を考えると結果的にコストと技術的な手間がかかり、それが企業にとって大きな障壁となる。こうした課題の現実的な解決策が「RAG（Retrieval-Augmented Generation）」だ。
RAGは、大規模言語モデル（LLM）の生成能力と、信頼できる知識を格納した“外部知識ソース”の信頼性を組み合わせ、より質の高い文章生成や回答を実現するためのフレームワークだ。大規模な外部コーパスから関連情報を抽出し、それをLLMに取り込み出力を拡張する。コーパスとは、自然言語の文章や使い方を大規模に収集し、コンピュータで検索できるよう整理されたデータベースを指す。
たとえば、OpenAIのGPT-4など汎用的なLLMは、膨大なデータを学習することで豊富な知識を蓄えている。しかしながら、汎用的な質問に回答はできても、企業独自のルールや特定領域の質問には答えられない。LLMの訓練データに含まれる知識には制限があるため、扱えるトピックは限られる。また、生成される回答が正確かつ信頼できるとも限らない。
先述したように、RAGにはLLMと外部知識ソースが必要だ。加えて、外部知識ソースから質問や指示に関連する情報を抽出するための検索エンジンも欠かせない。RAGではユーザーが入力した質問や指示に基づき、検索エンジンを用いて外部知識ソースから関連情報を検索し、その結果からLLMが回答を生成するために役立つ情報を抽出する。LLMはプロンプトと共に抽出された情報を受け取り、それらを自身の持つ情報と組み合わせることで質問や指示に沿った回答を生成できる。
ChatGPTなどへの評価が終わった今、生成AIを業務活用しようとする企業が増えているが、社内ドキュメントなどをRAGで活用しようとして立ち往生しているケースは少なくない。そう指摘するのは、日本オラクル 執行役員 事業戦略統括の首藤聡一郎氏だ。RAGの活用を進められない理由の1つが、「アクセスコントロール」を実現することの難しさにある。
たとえば、Microsoft 365にはSharePointがあり、アクセスコントロールを含むOfficeドキュメントなどの管理が容易に実現できるだろう。しかし、SharePointの外にある情報を安全に生成AIに渡し、回答を得ることは簡単ではない。企業には権限や役職により閲覧・参照できない情報もあるため、「RAGを使う際、閲覧させたくないデータのアクセスコントロールを厳密に行うにはどうするのか。そうした課題から、なかなか活用が進まないとの話はよく耳にします」と首藤氏。
もう1つの課題が質問したい事項に対して、関連性の高いデータを効率的に抽出することが容易でないことだ。たとえば、1つのドキュメントが数百ページに及ぶ場合に「すべてのドキュメントを読み込んだ上で適切に抽出することが技術的に難しく、関連のあるデータがほとんどヒットしないこともあります」と首藤氏は指摘する。
ドキュメントあるいは画像などのデータから関連情報や類似情報を検索するには、「ベクトルデータベース」を使うことが一般的だ。ベクトルデータベースでは、テキストなどのデータをベクトル変換し格納する。ベクトルとはデータ間の類似性を表す数値の集合体で、それを用いることで従来のデータベースよりも効率的に関連情報や類似性の高いデータを検索可能だ。
なお、ベクトル化する際には、文章をトークンと呼ばれる小さなピースに分割する。たとえば「コストと技術的な手間は、多くの企業にとって大きな障壁となる」という文章であれば、以下のように分けられる。
- コスト（名詞）
- と（助詞）
- 技術的な（形容詞）
- 手間（名詞）
- は（助詞）
- 多く（副詞）
- の（助詞）
- 企業（名詞）
- にとって（助詞）
- 大きな（形容詞）
- 障壁（名詞）
- となる（動詞）
この短い文章でも12のトークンになる。つまり数100ページに及ぶような文章ならば、膨大なトークン数だ。その場合に「ベクトルデータ化の処理では数100トークンしか使用せず、後は切り捨てるために文章の冒頭部分しかベクトル化されないものもあります」と首藤氏。この課題を解決できないと、企業に蓄積されているドキュメントにRAGを用いた形で生成AIを活用できない。
また、ベクトル化が上手くいって関連情報をLLMに渡せたとしても、「回答させてみないと、結果が適切かはわかりません」とも言う。納得できる回答でなければ、求める回答が得られるまで試行錯誤する必要がある。このときにも性能の高いベクトルデータベースがなければ、大きな手間と時間を必要としてしまう。
