生成AI/RAGシステム業務実装の勘所～AIハッカソンのグランプリ受賞作から紐解く～

2022年にOpenAI社が大規模言語モデル(Large Language Model, 以下LLM)のGPT-3.5およびChatGPTを発表して以来、企業のAI利活用のあり方は大きく変容した。LLMは事前学習により一般的な知識を獲得している一方、各社固有の情報や業務用語は学習しておらず、業務活用に適した状態であるとは言いにくい。LLMに各社固有の業務用語や情報を与える仕組みの一つに Retrieval-Augmented Generation (検索拡張生成、以下RAG)があり、このRAGシステムを業務に合わせてチューニング・実装し、活用することが重要である。

アビームコンサルティングは、RAGシステム実装についての実践的な技術の向上を目的として、2024年6月11～12日に日本マイクロソフト・角川アスキー総合研究所共催 AIハッカソン「第2回AI Challenge DAY」に参加し、参加10社中1位のグランプリを獲得した。これまでの豊富なLLM/RAGシステムの業務活用支援における知見をフル活用して体現したアプリが高く評価されたと考えている。

本インサイトでは、本イベントへの参加を通じて体現することができた、生成AI/RAGシステムの業務実装に向けた勘所について解説する。

写真：グランプリを受賞したアビームコンサルティングのチームメンバー

イベント開催概要・RAGシステムの概要

はじめに本イベントの開催概要およびRAGシステムとは何かについて説明する。

イベント開催概要

本イベントは RAG システムの実装を題材とした日本マイクロソフト・角川アスキー総合研究所が共催するハッカソン^※1である。10社の参加チームは6月11～12日の2日間で主催者から与えられたテーマとデータに合わせてRAGシステムを構築し、審査員による評価を受ける。今回のテーマは「世界遺産トラベルアシスタント」で、日本国内にある世界遺産を紹介するトラベルアシスタントを構築するというもの。世界遺産に対するユーザーの質問を文章だけでなく、「この写真の寺社はどこですか？」のような添付された写真データに基づく質問にも答えることが求められる。
学習対象データおよびRAGシステムの精度を測定するための評価データは主催者から提供され、審査対象はRAGシステムの精度のみならず、どのようなユーザーにどのような体験を提供するアプリとするのかといったカスタマーストーリーやエンタープライズグレードでの実装観点も含まれている。

図1 RAGシステムの構築テーマ（イベント主催者提供）

※1 ハッカソンとは一般的に、プログラミング技術者やクリエイターが集まって、決められたテーマや制限時間の中で、アイデアを出し合いながらソフトウェアやサービスの開発に挑戦するイベントを指す。

一般的なRAGシステムの概要

RAGシステムは、LLMが学習していない業務用語・ドキュメントなどの外部ナレッジを、ベクトルデータベースと呼ばれる検索データベースと組み合わせることで回答生成を補完する方法である。
ファインチューニングと呼ばれる、LLMそのものに外部ナレッジを与え追加学習させる方法と比べ、構築コストを抑えてユーザーが求める回答生成精度を得られやすいことや、何を参照して回答を生成したのかを明示でき、事実に基づかない情報を生成してしまう現象（ハルシネーション）を抑制できることから、LLMの業務活用の第一選択肢となっている。

図2で、代表的なRAGシステムによる質問応答の処理フローを説明する。ここでは前提として外部ナレッジが全て、LLMが扱いやすい形式であるテキストデータであると仮定する。
ユーザーの質問（図2では「当社の23年3月期の営業利益は？」）は、明らかにLLMが学習していない個社に関する質問である。この質問に回答するためには事前に外部データである個社情報を文章ベクトル化^※2し、ベクトルデータベースに格納しておく必要がある。個社情報に紐づく文章ベクトルをベクトルデータベースに格納することで、膨大な個社情報の中からユーザーの質問文と類似性が高い情報を検索し回答として生成することができるようになる。

このRAGシステムの利用開始前に、個社情報を含む外部ナレッジをLLMが扱いやすいテキスト形式に変換し、ベクトルデータベースに登録することを、本インサイトではRAGシステムにおける「データの前処理」と呼ぶ。

上記の説明では、外部ナレッジが全て、LLMが扱いやすいテキストデータであることを前提とした。本イベントのテーマのように画像データなどが検索対象に含まれる場合には、追加の前処理やアーキテクチャを構築する必要がある。本イベントで構築したRAGアーキテクチャは後掲の勘所３で説明する。

図2　RAGシステムの代表的な処理フロー

以降では、本イベントでの我々のチームの取り組み内容や成果物を中心に、RAGシステム構築の勘所を説明する。

※2 文章ベクトル（エンベディング）とは、文章や文書の内容を数値ベクトルに変換することで、意味が近い文章同士が近くなるように配置する技術である。

勘所1. RAGシステムの構築・検証プロセス

RAGシステムの業務実装プロセスは、「1. 活用可能性ディスカッション・ユースケース検討」「2. PoCによる技術検証・アジャイルな改善」「3. 本格展開」の三段階あるが、実装面では2点目の進め方がポイントとなる（図3）。

「1. 活用可能性ディスカッション・ユースケース検討」は、ディスカッションを通じてターゲットユーザーや解決すべき課題、導入目的、ユースケースを洗い出し、先行事例などを基にRAGシステムの機能・UI概要を検討する段階であり、本イベントでは「カスタマーストーリーの検討」という形で実施している。詳細は勘所2で説明する。

アプリの機能・UI概要の検討後、「2. PoCによる技術検証・アジャイルな改善」を行う。RAGシステムはユースケースや扱うデータによって適切なデータの前処理方法、検索方法が異なる。画一的な構築手法が確立しにくいことから、初期構築を迅速に実施し精度評価とチューニングを繰り返すことで、機能を改善していくアプローチが有効である。

図3 本イベントにおけるRAGシステムの開発プロセス

本イベントにおいてRAGシステムの初期構築を行う際、我々がこれまでさまざまなプロジェクトで蓄積した構築ノウハウを活用し、RAGシステムのコア技術やMVPアプリ^※3を短期間で実装した（図4）。これによりRAGシステムのアジャイルな精度改善プロセスを早期に開始し、アプリの改善に多くの時間を充てることが出来た。
一般的なRAGシステム構築においても、このようなアジャイル的なアプローチを前提にRAGシステムのMVPを早期に実装し、精度改善と業務課題の解決性の両面からアプリを最適化していくことが重要である。

図4 MVPアプリのRAGアーキテクチャ

本イベントで初期に構築したMVPアプリで回答精度を評価したところ、改善に向けて３点の課題が明確になり、対応を行っている。

課題①　ユーザーからの画像添付を想定した質問への対応が不十分である
課題②　PDF・Word・PowerPoint・CSVデータの前処理が想定通りに行えていない
課題③　精度評価に時間を要してしまい精度改善サイクルが遅い

回答精度の低下要因として特に課題①・②の影響が大きく、チューニングに多くの時間を要した。画像を添付した質問への対応や、PDF・Word・PowerPoint・CSVなどのデータの前処理のチューニングは一般的なRAGシステム実装でもしばしば対応に時間を要するポイントである。詳細や対応方法は後掲の勘所3で説明する。

また課題③に示した精度改善サイクルの効率が悪い点も一般的なRAGシステム実装でボトルネックとなり得る。これはLLM (RAG)システムが自然文で結果を出力するため、質問意図や回答内容の文脈を考慮する必要があり、正誤の評価に時間を要する点に起因している。詳細や対応方法は後掲の勘所４で説明する。

※3 MVPとはMinimum Viable Productの略で、本インサイトでは要件を満たす最小限の機能を持つアプリを指す。

勘所2. 業務に即したRAGシステム活用イメージの検討

RAGシステムの業務定着を図るには、ターゲットユーザー、解決すべき課題と導入目的、ユースケースを想定し、業務に即した構想策定を行うことが重要である。ユーザーが業務のどの場面でRAGシステムを必要としているかによって、提供すべきアプリの機能やユーザーインターフェース(以下UI)が異なるからである。
本来であれば、業務をよく知る業務部門の担当者や責任者などへのヒアリングやワークショップなどを通して明らかにしていくのだが、本イベントでは評価用のデータからそれらの想定を置き、今回2つのアプリを企画・構築することとした。

本イベントで主催者から配布されたRAGシステムの評価データは、ユーザーからの想定質問とその対となる正解回答データから構成されている。
質問の内容は、本イベントのテーマに沿って世界遺産の概要や歴史に関連するものが多く見られた。こうした学習に関連するような質問やその回答を必要とする対象者を検討し、ターゲットユーザーを「修学旅行に向かう中高生」とした。

次に検討を行うのがターゲットユーザーの抱える課題とアプリの利用目的やUIである。修学旅行は一般に、学生が見学ルートの企画と事前学習を行い、現地で世界遺産などに対する見識を深める学習機会である。一方で、事前企画における情報収集や学生自身で深く学びを得るための準備、そして現地でのガイド不足などの問題点があり、質の高い学習機会を設けるには一定のハードルが存在すると考えた（図5）。

図5 ターゲットユーザーの課題とアプリの解決方針

そうした課題を解決するためには、“企画・情報収集の支援”、“学びの質の向上”、“見学中の遺産への理解促進”に寄与する手段が必要であり、我々のチームは(1)事前のルート企画アプリと(2)現地での質問応答アプリの2つのアプリを企画した。

(1) 事前のルート企画アプリ（図6）は、RAGシステムを通じて、学生が設定するテーマに応じた世界遺産の学習ポイントや見学ルートを企画するものである。学生が希望する学習テーマを入力するとテーマに沿った見学ルートを作成し一覧として出力する機能や、見学ルートの地図表示やしおりの出力機能を有している。このアプリではユーザーが効率的にルートを企画するという利用目的を考慮し、チャットUIではなく、表形式などで視覚的に情報を提示するUIを採用した。

(2) 現地での質問応答アプリ（図7）は、RAGシステムを通じて、ユーザーがまさに見学中の世界遺産に関する疑問を解消する機能にフォーカスしている。ユーザーである中高生の質問にテンポよく回答し、現地での学習効果を高めるためにリアルタイムでの応答が求められる。チャット型UIはユーザーとのインタラクティブなやり取りに適しており、現地での使用シナリオにおいて効果的である。

このように、アプリの構想策定において、RAGシステムのターゲットユーザー、解決すべき課題と導入目的、ユースケースに応じて最適な機能やUIを設計することが肝要である。

図6 (1)ルート企画アプリの動作イメージ（学習テーマを入力することで、関連する遺産と学習ポイントを提示。チャット型UIが必ずしも適していない例）

図7 (2)質問応答アプリの動作イメージ（チャット型UIが適している例。アプリの背景は生成AIを活用して作成）

勘所3. 多様な入力データへの対応

業務で取り扱うデータはテキストデータのみならず、画像、PDFなど多種多様なソースファイルが利用されており、RAGシステムの検索対象となり得る。
本イベントにおいても業務活用を意識して、画像、PDF、Word、PowerPoint、CSVといった多様なファイル形式のデータが検索対象として与えられた。LLMはテキストデータしか読み込むことが出来ないため、これらのファイルを前処理してテキスト抽出する必要がある。

本イベントで我々のチームは当初、OSSライブラリを用いてPDFなどのファイルに格納されているテキストを抽出する手法を試みた。この手法は、テキストデータがPDFなどのファイル中に格納されている場合に有効である。しかし、本イベントのPDFなどのデータは、例えばWebページの画像が埋め込まれており、テキスト情報そのものが格納されていないなどの理由から、この方法ではテキストの抽出が困難であった。そのため各ファイルを画像化し、AI-OCR API^※4を活用しテキスト抽出を行うことで対応することとした。

CSVファイルはカンマ区切りで数値などのデータが格納されていることが多い。そのままではキーワードに乏しく検索結果に挙がりにくいため、前処理にてChatGPTを用いて表の説明文を作成して検索対象とした。こうすることで、必要な場面で表データが検索上位に挙がりやすくなる効果が期待できる。

また前述の「イベント開催概要」の通り、本イベントが想定するユーザーの質問には、写真データが添付された質問（例えば「この写真の寺社はどこですか？」）が含まれている。この質問では、写真の被写体を特定した上で質問に回答する必要がある。そこでユーザーが入力した画像をベクトル化し、事前に登録した画像のベクトルと比較する手法を採用した。これにより、ユーザーが添付した写真の被写体を特定し、質問に回答することが可能となった。

これらのチューニングによって、テキスト、画像、PDF、Word、PowerPoint、CSVを含む合計600個、200MBを超えるファイル群を、RAGシステム上で統合的に検索することが可能となった。チューニング対応後のRAGアーキテクチャの前処理フローを図8、質問回答フローを図9に示す。
このようにRAGシステムの実装においては検索対象データの形式や種類を見極め、それぞれ適切な方法で検索可能にすることが求められる。

図8 チューニング実施後の前処理フロー

図9 チューニング実施後の質問回答フロー

※4 APIとはApplication Programming Interfaceの略で、Webアプリケーションなどが他のサービスやアプリケーションと通信し機能を利用するための仕組みを指す。

勘所4. 精度検証プロセスの自動化

LLMを活用したRAGシステムを業務に適用するには、その精度を検証するプロセスが必要不可欠となる。一方で、一般的なAIシステムと異なり、自然文で結果を出力するLLM/RAGシステムは質問意図や回答内容の文脈を読んで正誤判定をする必要があるため機械的な評価が難しく、人手を介して評価することが多い。しかし評価用の大量の文章を1つ1つ確認して正誤を検証するのは工数がかかるうえ、担当者によって評価のばらつきが出るなどの課題が残る。

そうした課題解決の一助となるのが、近年発展途上の、「LLMにLLMの出力を評価させる」手法である。具体的には、理想の正解データと、RAGシステムによる出力、評価用のプロンプトを合わせて評価用LLMに入力し、評価点を出力させることで、機械的に定量的な評価結果を得るというものだ。
例えば、Microsoft社が開発したOSSライブラリ「prompt flow」で採用されている、LLMベースの評価方法の例を図10に掲載する。総合的な回答品質や回答の一貫性、根拠に基づいた回答であるかなどを評価する方法が確立されている。

図10 「prompt flow」で採用されている、LLMベースの自動評価メトリック

本イベントにおいてはイベント主催者から評価用のプロンプトが配布され、参加チームが一律の基準で評価を行うことができた。ただし、評価結果もLLMの出力であるため、ある程度ばらつきがあり、絶対的な評価でない点に注意する必要がある（実際に本イベントにおいても、同じ入力内容であっても試行によって採点結果が異なるケースが散見された）。実際の業務では、担当者の目視での評価と組み合わせて利用することで、効率的に精度検証を進めることが可能と考えられる。

また、LLMの出力処理を自動化し、上記のLLMの自動評価と組み合わせることで、RAGシステムの精度向上サイクルを効率的に繰り返すことが可能となる。LLMモデルの更新が発生した際や、データの追加時、検索処理の変更時などにLLM/RAGの出力から評価までを一通り実行し改善する「LLMOps」と呼ばれる仕組みを構築することで、継続的なシステム評価や改善を図ることが可能である。

本イベントではLLMの出力処理を自動化・高速化することで、1.5日間という短い構築期間の中でも8回の試行・改善サイクルを実施することができた。こうした精度改善に向けた一連の処理の効率化が、本イベントでの最終的な高精度（参加10社中上位2位の回答精度）につながったと考えられる。また実務では、ユーザーによる回答へのフィードバックをRAGシステムの精度改善に用いるhuman-in-the-loop (HITL)とよばれる手法も頻繁に採られる。

このように、定量的な評価が難しいRAGシステムにおいて、評価の半自動化・高速化手法を取り入れ、ユーザー評価を活用することで効率的な精度改善や精度監視を行うことが重要である。

勘所5. セキュアなクラウドインフラの構築

ChatGPTなどのAIサービスが企業の事業価値創出や生産性向上に有用であることに疑いはないが、企業が従業員に対して必要なAIサービスを提供できていないことで、従業員自身がAIサービスを持ち込んで利用する「Bring Your Own AI」（BYOAI, 私的AI利用）が徐々に広がりを見せている。企業がルールや利用状況を管理していない、無許可のBYOAIの場合は営業上の機微情報漏洩リスクや個人情報漏洩リスクがともない、企業統治上も問題がある。マイクロソフト社とLinkedIn社が2024年6月6日に発表した「2024 Work Trend Index」の調査によると、国内のAIユーザーの約80%が私的なAIツールを職場に持ち込んでいるとされる。企業データをセキュアに扱うことのできるAI環境の整備は急務であり、守りのDXの観点からも重要である。

こうした背景において、RAGシステムを含めてセキュアなAI環境の構築が求められる。RAGシステムの実装においては、クラウドインフラを活用することが多い。LLMは利用に膨大な計算リソースを必要とするため、オンプレミスでの環境構築に適していないことが主な理由である。クラウドインフラを活用する際には、クラウド環境の強固なセキュリティ対策を適切に活用することが重要である。

例えば、検索対象データを格納するベクトルデータベースにおいては、外部からの不正アクセスやデータ漏洩を防ぐために、限られたWebアプリ及び開発メンバーのみがアクセス可能となるように認証管理を行う必要がある。また、インターネットからの接続を遮断した閉域網を構築し、閉域網内でWebアプリからベクトルデータベースにアクセスすることが推奨される。なお、データベースに保存する全てのコンテンツに対してデータ暗号化を適用する必要がある。

次に、Webアプリに対しても同様の対策を講じる必要がある。外部からのAPIアクセスによるデータ漏洩を防ぐために、限られた開発メンバーやグループのみがアクセス可能となるように設定し、関連するストレージに対してはデフォルトの暗号化キーを使用する。

Webアプリケーションから接続するLLMなどのAPIサービスにおいても、同様のアクセス制御などを適用する必要がある。また、送信したプロンプトや出力データを監査などの目的で一定期間保存する場合には、機微な情報が利用ログに残らないように配慮する必要がある。APIアクセスの認証キーの管理は安全なストレージから取得する形とし、ソースコードに直接埋め込まない設定が一般的である。

さらに、セキュリティ対策として、不正アクセスの検出やセキュリティ基準によるリソース設定状態のチェックを行う専用のセキュリティツールを使用する必要がある。また、インシデント発生時には自動的に通知が行われるシステムを構築し、迅速な対応ができる体制を整えることが重要である。

これらのセキュリティ対策を実施することで、クラウドインフラ上でのRAGシステムの運用においてエンタープライズグレードのセキュリティを確保し、安全に企業データを扱うことが可能となる。
本イベントではこうしたセキュリティ対策を取りまとめて示し、審査員から一定の評価を得ている。

導入効果の高い生成AI/RAGシステムをセキュア・迅速に構築する

本イベントでは、アビームコンサルティングの豊富なRAGシステム構築実績・知見に基づいて、世界遺産のトラベルアシスタントアプリを迅速かつ高精度に構築することができた。
本インサイトで示した勘所を通じて、企業の生成AI/RAGシステム構築の一助となれば幸いである。

アビームコンサルティングでは、本イベントで体現した、社内データを活用したRAGシステムの構築サービス（ABeam LLM Partner）を提供している。株式会社マクニカとのRAGシステム構築事例もご確認いただきたい。

併せてRAGシステム構築の関連サービスとして、東京大学名誉教授の畑村洋太郎先生と共同で失敗学のデータをインプットしたLLMシステム「失敗学コンサルタント」、ワークショップの開催による業務価値・顧客体験の創出支援、生成AIを活用したナレッジマネジメント高度化支援サービスを提供している。
これらも参考にしていただけると幸いである。

末筆ながら、本イベントを企画・主催し、快く参加をサポートしていただいた日本マイクロソフト、角川アスキー総合研究所に御礼を申し上げたい。

インサイトTOP

生成AI/RAGシステム業務実装の勘所 ～AIハッカソンのグランプリ受賞作から紐解く～