RAGのアーキテクチャ
背景
- 私のチームではteamsを介して社内情報を参照・活用できるAIエージェントを実装する試みの最中です。
- 機能単位で数個のブロックに分けて開発を行っています。
- そのようなエージェントの機能のうち、RAG部分に焦点を当ててアーキテクチャを検討しました。
対象読者
- RAGを用いて情報参照できるエージェントの、RAG部分の俯瞰像を知りたい人
概念図
RAGを用いた外部知識ソース参照の概念図を以下に示します。
アーキテクチャ
以下が構想です。
LLMはクラウドサービスを利用します。chat appはUIを提供する一方で、llm関連タスクの入り口を担うllm handlerと接続する形を取ります。llm handlerはMCP clientを介してMCPサーバでもある検索エンジン(ベクトル検索、全文検索、構造化データ検索)へ接続します。検索エンジンはwiki記事の格納してあるmongoDBへアクセスしますが、この際にwikiのグループ情報ベースでアクセスコントロールを行い、参照不可ページについてはchat app側へMCP client経由でforbiddenであることを伝えます。
検索系
ベクトル検索、全文検索、構造化データ検索の三種類の手法の特徴を下記表に示します。
それぞれ限界があるので組み合わせて活用を試み、効果的なセッティングを導出する活動が必要と考えています。
複数手法を組み合わせると精度が上がる場合もあるようなので、実際に効果測定を行い、有用なものについては採用したいと考えています。
最初の一歩としては、ベクトル検索のみについて、RAGのシステムを構築したいと考えています。
手法 | 特徴 | 優先順位 |
---|---|---|
全文検索 | 類似した語彙、つづりを持つ文字列を検索できる | 2nd |
ベクトル検索 | 類似した意味を持つ文字列を検索できる | 1st |
グラフ検索 | 関係している、あるいはつながりを持つ文字列を検索できる | 3rd |
アクセスコントロール方式
MCPサーバレベル(採用予定)
- MCPサーバーのDBへのアクセスを制限します。MCPクライアントから渡ってくるユーザー情報をDB側のアクセス許可情報と照らし合わせて、MCPクライアントへ検索結果を渡してよいかどうか判定する構想です。
web appレベル
- web app側でアクセス許可を判別し、検索可否を判定します。
MCPサーバ類
とりあえず当面、最小労力で実装を行って効果を見たいので、vectordbに焦点を絞って実装を行う予定です。
vector DBとしてはQdrantを採用します。比較記事はこちら
言語/フレームワーク類
エージェント管理
プロトタイピングではopenai agent sdkを採用予定です。学習曲線がゆるやかかつ、標準的なpython記法で記述できることが選定理由です。
エージェント管理用のsdkは本番ステージまでに見直す想定です。openai以外のエージェント管理フレームワークが必要になった場合は他に乗り換えることも視野に入れています。
他候補は以下です。
- langgraph
- crew ai
- autogen
データ処理
プロトタイピング段階ではAPI直で書く想定です。本番ステージではlangchainなどのツールを利用し抽象化レイヤを導入したいと考えています。理由としてはLLM類について様々なサービスを利用できる可能性を残しておきたいためです。
MCP
サンプル実装と言語・ライブラリは揃えます。
参考リンク
RAG
クローズドネットワーク上でのRAG採用型LLM構築と、AOAI比較検証
GraphRAG
GraphRAGをわかりやすく解説
GraphRAGを攻略!実装できるRAGのバリエーションを増やしましょう
GraphRAG 第一弾 ~ Azureで動かしてみる ~
MCP
初心者向け Model Context Protocol(MCP)完全ガイド:LLMと外部ツールを繋ぐ標準プロトコル
Model Context Protocol(MCP)とは?生成 AI の可能性を広げる新しい標準
RAG アプリケーションを MCP に対応させる
Discussion