RAGにより企業ノウハウを活用する！

RAG（Retrieval Augmented Generation）は、生成AIの可能性を広げる画期的な技術だ。RAGを活用することで、企業内の膨大な知見を生成AIに活用させることが可能となる。社内規程やマニュアル、過去の稟議書など、これまで活用しきれていなかった情報を、生成AIの力で有効活用できるようになるのである。

しかし、RAGを導入するためには、適切な情報の収集・蓄積、高度な検索技術、コスト管理など、いくつかの課題をクリアする必要がある。本稿では、RAGの基本的な仕組みから、実際の活用事例、そして導入における課題と注意点まで、RAGについて包括的に解説する。生成AIの可能性を最大限に引き出すためのヒントが、ここにある。

はじめに

RAGとは

企業における生成AI活用が進む中、「RAG（Retrieval Augmented Generation）」という技術が注目を集めている。RAGを端的に言うと、「LLM単体では知らないことを答えさせるための仕組み」である。

LLM（大規模言語モデル）は世界中にある様々な情報を学習し、質問に対して回答したり、文章の要約、小説の生成など、高度かつ汎用的な文章生成能力を持っている。しかし、最新のニュースや企業内の情報を参照した内容を生成することはできないこといった課題がある。実際の現場活用においては、「最新のニュースを踏まえた回答をしてくれないか？」「社内のドキュメント（例えば、社内規程や打ち合わせ議事録）を踏まえた回答をしてくれないか？」というニーズが出てくると思う。そんなとき、関連ドキュメントを参照して答えてくれるのがRAGという仕組みである。

RAGが注目される背景

ChatGPTやCopilotの個人レベルでの活用は進んできた感があるが、実際の業務に組み込もうと思った際には、企業ならではの文脈が必要となる。社内規程はもちろんのこと、社内稟議書を作るのであれば社内の稟議フォーマット、営業先企業に対し次回のアポイントメールを作るのであれば、前回の商談状況など、社内情報の活用が必要不可欠になる。このような企業特有のニーズに応えるために、RAGが注目されている。

RAGを実現する4つのステップ

RAGを実現するには、4つのステップが必要になる。全体の流れを一言で説明すると、「ユーザーのプロンプト（質問文）に対して、事前に蓄えておいた情報（Store）から、適切な情報を探索・抽出し（Retrieve）、見つかった情報を適切な形でプロンプトに組み込み（Augment）、それを踏まえてLLMに回答を生成させる（Generate）」という手順が必要となる。これら、文章中に記載したStore、Retrieve、Augument、GenerateがRAGに必要なステップとなる。この全体の構成を図示したものを下記に示す。

以下、それぞれのステップについて詳しく解説していこう。

RAGを実現する4つのステップ①　～Store（情報蓄積）〜

参照ドキュメントを探索可能にするためには、対象となる文字列中心のドキュメント（Word、Excel、CSVなど）を、LLMが取り扱いやすい単位（チャンク）に分割し、入力されたプロンプトとの関連度合いを計算できるよう、あらかじめチャンク単位での文章特徴量（ベクトル情報）を計算しデータベースに蓄積しておくことが必要になる。これを本稿ではStore（情報蓄積）のステップと呼ぶことにする。

高精度な情報探索を行うためには、そもそもこの情報蓄積を効果的に行う必要があり、チャンク分割の方法や、ベクトル情報の計算方法には様々な手法が提案されている。また、参照させたいドキュメントに画像や音声データが含まれる場合には、事前に画像や音声データを文字情報に変換した上で、文章特徴量を計算しStoreに追加して扱うような仕組みも構築可能である（マルチモーダルRAGと呼ばれる）。

RAGを実現する4つのステップ②　～Retrieve（情報抽出）〜

次にRAGにおいてもっとも重要であると言っても過言ではないRetrieve（情報抽出）のステップについて説明する。入力されたプロンプト、例えば「結婚した時に使える福利厚生について教えて」といったプロンプトに対し、参考ドキュメントのうち関連する箇所を抽出してくるステップになる。

ここでポイントとなるのは、Storeのステップで関連ドキュメントを文章特徴量として保存していることである。Retrieveステップにおいては、入力されたプロンプトのベクトル特徴を計算し、これを使うことで蓄積情報の中から関連情報を抽出（Retrieve）するわけである。

事前に用意したドキュメントの中に正しい情報が含まれていたとしても、その情報を適切に抽出できなければLLMは正しい回答をすることができない。逆に、最終的な生成過程において正しくない情報を参照してしまい、LLMがその情報を強引に解釈してしまうことで、意図した回答が出ないどころか、正しくない情報（文章）を生成してしまう場合もあるので注意が必要である。

RAGを実現する4つのステップ③　～Augment（文脈拡張）〜

入力されたプロンプトに対して、参照すべき情報が抽出できたあとに必要なのがAugment（文脈拡張）と呼ばれるステップである。

「参照させたい情報を抽出できたところで、どうやってそれを踏まえた回答をLLMにさせるのか？」という疑問に答えるのがこのステップであるが、意外にやっていることは簡単で、LLMに文章を生成させるプロンプトにおいて、Retrieveステップで抽出した情報を適切な形式で組み込むだけである。

このような形でLLMに対してRetrieveステップで抽出した正しい情報を提示することで、最後の文章生成（Generate）において、高度な知性を持つLLMが適切な文章生成を行うことができるというわけだ。

繰り返しになるが、適切な情報を参照させることがRAGにおける最も重要な考え方であるため、RetrieveとAugmentのステップの作り込みが非常に重要になる。Retrieveステップにおいて、適切な情報をピンポイントで抽出できれば問題ないが、探索対象がある程度大きい場合に探索の精度を担保するのは中々難しい、ある程度大雑把に広めの情報を抽出して複数の除法をプロンプトに含めることで、情報の取捨選択を後段の文章生成（Generate）でLLMに任せてしまうという考え方もある。

RAGを実現する4つのステップ④　～Generate（文章生成）〜

Augmentステップにおいて生成したプロンプトをLLMにインプットすることで、適切な回答をすることができる。ここから先は、みなさんがChatGPTを使って回答を生成させる場合と同じ要領である。

冒頭に掲載した全体像の図を再掲する。少々技術的に難しいところもあって理解しづらいところもあるかもしれないが、4つのステップの概要を理解した上でこの図をみながら「ユーザーのプロンプト（質問文）に対して、事前に蓄えておいた情報（Store）から、適切な情報を探索・抽出し（Retrieve）、見つかった情報を適切な形でプロンプトに組み込み（Augment）、それを踏まえてLLMに回答を生成させる（Generate）」という流れを順を追ってみていただけると理解が深まるのではないかと思う。

RAGの活用事例

各種規程やマニュアルなど行内情報の照会（横浜銀行様の例）

ここまで説明したRAGを実際に活用した事例として、横浜銀行様の取り組みを紹介する。

「ChatGPT」は、自然言語処理技術を用いて対話をおこなうことができるシステムで、利用者は文章の要約やメール文案の作成などに活用することができます。株式会社ラックから導入支援を受け、構築した本システムは、一般的な「ChatGPT」の機能に加え、当行における各種規程やマニュアルなど行内情報の照会に対応できる機能を備えています。また、本システムの管理業務は外部委託せずに行内のクラウド環境内で従業員がおこなうため、高い水準のセキュリティを確保しています。従業員は文書作成などの業務の効率化（※）をはかりながら、より高度な業務や新たな業務に集中することができます。

「行内ChatGPT」導入について～自動生成AIを活用し、従業員の生産性を向上させます～（2023年11月27日）https://ssl4.eir-parts.net/doc/7186/ir_material33/218330/00.pdf

上記は、横浜銀行様のプレスリリースを引用させていただいたものである。ここまで述べてきたように、実際にこのシステムを構築する場合には、この「当行における各種規程やマニュアルなど行内情報の照会に対応できる機能」の部分が肝になるし難しいというところであり、おそらく相当な試行錯誤を行った上で実際に使えるレベルにまで仕上げていっているのではないかと推察される。

【図6】横浜銀行様システムイメージ （引用先：「行内ChatGPT」導入について～自動生成AIを活用し、従業員の生産性を向上させます～（2023年11月27日）） 

RAG構築における課題と注意点

最後に、RAG構築における課題と注意点についていくつか述べておきたい。

Store（情報蓄積）における課題

まず、Storeの難しさとして、実現したいユースケースに対して必要な関連情報がドキュメント化されているか、という課題が出てくるケースが多くある。

先程紹介した横浜銀行様の事例であれば社内規定や既存のマニュアルなど、すでにあるドキュメントを参照する形をとっていた。ただ、「資料レビューにおいて社内説明に必要な構成要素を踏まえて資料を生成し、会議でよく指摘される観点でのチェックを事前に行いたい」といったユースケースであれば、「社内の資料フォーマットってどれが最新？そもそもある？」ということがあったり、後者のレビュー観点などそもそも言語化もされていないようなケースもある。

ここまで述べてきたようなRAG特有の課題以前の問題として参照するドキュメントの整備や作成が必要になるケースもあるという点はぜひご認識いただきたい。余談ではあるが、事業計画フォーマットの作成や、会議における必要観点の言語化は、将来的な稼働削減や企画品質の底上げに確実につながるものであるので、こういった機会に行なっていくことをお勧めする。

Retrieve（情報抽出）における課題

次に、Retrieveの難しさとして、先の説明では「いかにして、適切に情報を持ってくるか？」という観点を中心に述べたが、他にも情報統制といった観点も課題に挙げられる。例えば、高度な経営判断を求められた際に生成ＡＩに助言を求めると言ったユースケースにおいては、秘匿性の高い経営情報（未公表の売上情報や、研究開発部門が生み出した特許性の高い新技術など）を参考ドキュメントにしたいというニーズは存在するが、「学習に使われないとはいえOpenAI社のサーバーで動くLLMに情報を与えて良いのか？」といった課題や、「業務活用とはいえアクセスできる情報については役職等によりコントロールしたい」というように複雑な仕様が求められるケースも出てくるだろう。

Generate（文章生成）における課題

最後に、Generateステップにおけるコストの肥大化の問題も顕在化しつつある。

RAGにおいては、Augmentのステップにおいて参考ドキュメントから引用した情報をプロンプトに付与する形でLLMを使うことになるため、生成に必要なプロンプトが長くなる傾向にあり、結果としてGPTなどを使うためのAPIコストに跳ね返る形になる。

この対策として、利用シーンに応じてLLMのモデルを切り替えることでコストを最適化する（簡単なタスクにおいてはGPT3.5を使い、より高難度なタスクにおいてGPT4を使うなど）といった方法や、ローカルLLMと呼ばれる、自社ないしデータセンターに保有するコンピューターリソースを用いてLLMを動かしコストコントロールをする方法が考えられる。

後者で紹介したローカルLLMを用いた方法については、LLMでの文章生成自体を自社ネットワーク内に閉じることができRetrieveの課題として挙げたセキュリティ的なリスクがほぼ払拭されるなどの副次的なメリットもある一方で、大多数の利用者が同時に利用した場合には、自社で確保したサーバーのキャパシティがボトルネックとなり生成に多くの時間がかかりユーザー体験が劣化するというデメリットもあるのでユースケースを見極めた上での導入検討が必要である。

結びに

以上、本記事ではRAGについて概説をしてきた。

筆者が関わるプロジェクトにおいても、Store、Retrieveの部分は、事前の設計での試行錯誤はもちろんだが、実際にシステムを仮運用させてみる中で、トライアンドエラーしているところだ。RAGは、基礎技術的にも発展途上なところがあり、実装におけるベストプラクティスが確立されているものではないため、実現したいユースケースや活用したいデータを踏まえ、個別ケース向けに試行錯誤しながら構築していくことが求められる状況だ。

逆説的であるが、RAGの仕組みと注意点をしっかり理解し、適切な形でシステム化し業務実装を進めていくは真の競争力強化につながる生成AI活用のカタチといえるであろうし、先行投資を含め各社積極的に取り組み始めている状況である点、読者の皆様にご理解いただければ幸いである。

製薬業界で生成AIを活用する「ラクヤクAI」
このように今後の活用が期待される生成AIですが、中でも注目を集めるのが製薬分野です。

「ラクヤクAI」は、治験関係書類や添付文書といった社内外の膨大なデータを活用し
製薬事業のあらゆるシーンを効率化する専門文書AIサービスです。
基礎研究から製造販売後調査まで、多岐に渡る製薬業務の中で取り扱われる
様々な文書の作成・チェック作業を自動化し、圧倒的な業務スピード改善を実現します。

「ラクヤクAI」ご活用シーン(例)：
■ 治験関連文書やプロモーション資料の自動生成
■ 作成資料のクオリティチェックや、資料間の整合性チェック
■ 講演内容(資料・音声)の適用外表現モニタリング
■ 薬剤情報やナレッジの検索・調査
その他、個別カスタマイズが可能な生成AI環境で、
社内の知見を統合的に分析・集約したアウトプットをセキュアな環境をご提供します。