今回は、クオカードデジタルイノベーションラボ（以下ラボ）のインフラチームがRAG（Retrieval-Augmented Generation）を用いた社内情報検索システムを構築した話をご紹介します。

まだ構築したばかりで、これから本格的な効果測定を行う段階ですが、今回の記事が、これから社内RAGシステムの構築を考えている方の参考になれば幸いです。

RAGとは

RAG（Retrieval-Augmented Generation）は、大規模言語モデル（LLM）の弱点を補う技術です。LLMは汎用的な知識は豊富ですが、社内の特定情報や最新情報にアクセスすることはできません。そこで、RAGは以下の2つのステップで、より正確な回答を生成します。

これにより、LLMの持つ高度な文章生成能力と、社内ナレッジを組み合わせ、より正確で信頼性の高い回答を得られるようになります。

なぜRAGが必要だったのか？

ラボでは、作業手順や技術的な知見がBacklogのWikiに集約されています。

しかし、知りたい情報がどこにあるのかを探すのに時間がかかったり、そもそも「その情報があること」を知らなかったりすることが課題でした。また入力したキーワード次第で欲しい情報にhitしないという問題がありました。

そこで、自然言語で質問するだけで、関連情報を素早く教えてくれる仕組みがあれば、業務がもっと円滑に進むと考え、RAGの構築に着手しました。

このプロジェクトのゴールは、社内ナレッジの検索効率を上げ、メンバーの生産性を向上させることです。実用に耐えるものが構築できるか不明だった為、何よりもスピード感を重視し、「まずは動くものを作り検証する」ことを最優先に進めました。スピード感を出すために、以下の前提を設けました。

構築は以下の4つのステップで進めました。基本的にTerraformで構築し、一部手作業が必要な部分は手順書を作成することで、属人化を防ぎました。またセキュリティ面を考慮し、IAMロールなどに設定する権限は必要最小限に抑えました。

1. Backlog WikiデータのS3への配置

2. RAGシステムのコア部分構築

作業期間：3日
構成：Amazon Bedrock Knowledge BaseとOpenSearch Serverlessを組み合わせました。この構成を選んだ理由は、以下の通りです。

　　* 構築の手間が少ない： Bedrock Knowledge Baseは、S3のデータを指定するだけで自動的に埋め込み（Embedding）を生成し、ベクトルデータベースに格納してくれます。

　　* 運用が楽：OpenSearch Serverlessも同様に、インフラ管理の手間が少ないマネージドサービスです。コストが安いAurora(+pgvector)を使う方法も検討しましたが、構築・運用の手間を考慮し、OpenSearch Serverlessに軍配が上がりました。

　　* 高い親和性：AWSのサービスで統一することで、連携がスムーズになります。

　　* ハイブリッド検索に対応：Bedrockが自動でベクトル検索とキーワード検索を組み合わせたハイブリッド検索を行うことで、検索精度向上が期待できます。

3. データの定期更新仕組みの構築

作業期間：1日
内容：Backlogの更新分を定期的に取得し、S3にアップロードしKnowledge Baseにデータ同期する仕組みを構築しました。これにより、RAGの知識も常に最新の状態に保たれます。
ポイント：Amazon EventBridge Schedulerを利用して、Lambdaの実行とKnowledge Baseの同期を自動化しています。

4. Slack連携

作業期間：2日
内容：特定のプライベートチャンネルでRAGへの質問を受け付け、回答を返す仕組みを実装しました。これにより、質問のハードルが下がり、ラボメンバーが気軽に使えるようになりました。
ポイント：https://docs.aws.amazon.com/chatbot/latest/adminguide/connect-bedrock-agents.html のBedrock AgentとAmazon Q Developerを利用する方法で、ノーコードで構築できました。
余談：スレッド内で会話を続けようとするとBedrock Agentから反応がなかったのですが、AWSサポートに問い合わせて、チャンネルへの投稿を選択せずに「@Amazon Q」をメンションすることで会話を続けられることが分かりました。

試算すると月額約$380（約57,000円）でした。これは主にOpenSearch Serverlessの利用料です。構築後に実際に発生したコストを見た感じでは、試算を超えることはなさそうでした。

運用開始から2週間で、39件のやり取りがありました。いくつかの事例をご紹介します。

1.「SESのバウンス率増加時の対応」：

Backlogの検索では「バウンス率増加」で0件、「バウンス率」で10件ヒットしました。

RAGに質問したところ、関連するWikiページを即座に提示してくれたため、必要な情報にたどり着くまでの時間を大幅に短縮できました。

2.特定の電文種別に関する処理：

Backlogで「IF XXX（該当のI/F名）」を検索すると14件ヒットし、目的の情報を見つけるまでに時間を要しました。

RAGに質問した結果、求めていた処理内容を直接教えてもらい、スムーズに作業を進めることができました。

これらの事例から、質問内容によっては、RAGが情報検索の効率を大幅に向上させる場合があることが確認できました。

今回の構築で、「小さく始めて、素早く検証する」ことの重要性を再認識しました。

短期間で動くRAGシステムを構築できたことで、今後の改善や拡張に向けた良いスタートを切ることができました。

今後は、以下の点を検討していく予定です。

精度調整：より正確な回答ができるよう、チューニングを進めます。Knowledge BaseやBedrock Agentの設定など深く考えられていないので、改善の余地は多いと思っています。
他データソースへの拡張：必要に応じて、Backlog Wikiだけでなく、Google Driveなど、他のナレッジソースも取り込むことを検討します。
社内への展開：今のところラボメンバーのみを対象としていますが、ラボ内で効果があれば、社内全体に展開し、組織全体の効率化に貢献したいと考えています。