RAGPerf: An End-to-End Benchmarking Framework for Retrieval-Augmented Generation Systems

本論文では、RAG パイプラインの各コンポーネントをモジュール化し、実世界のワークロードをシミュレートしながら、パフォーマンスと精度を包括的に評価できるエンドツーエンドのベンチマークフレームワーク「RAGPerf」の設計と実装を提案しています。

要約

🍔 例え話：AI 助手は「天才シェフ」と「図書館」のチーム

まず、この論文で扱っている「RAG（検索拡張生成）」という技術が何なのかを理解しましょう。

• AI（LLM）＝ 天才シェフ
  • 何でも知っているすごいシェフですが、「昨日のニュース」や「会社の機密データ」は持っていません。 記憶力に限界があるからです。
• RAG（検索機能）＝ 助手と図書館
  • ユーザーが「昨日の株価は？」と聞くと、シェフは自分で答えられません。代わりに、助手が図書館（データベース）に行って、必要な本（情報）を探し出し、シェフに渡します。
  • シェフは渡された本を見て、「はい、答えはこれです！」と料理（回答）を完成させます。

この「シェフ＋助手＋図書館」のチームワークが、今の AI 応用の核心です。

---

🚧 問題点：なぜ「RAGPerf」が必要なのか？

このチームを運用する際、開発者たちはいつも**「どこがボトルネック（渋滞）になっているのか？」**で悩んでいます。

• 「図書館の検索が遅いのか？」
• 「シェフの料理（回答生成）が遅いのか？」
• 「本を整理する（インデックス作成）のに時間がかかりすぎているのか？」
• 「メモリーが足りなくて、シェフが倒れそうなのか？」

これまでのツールは、「シェフの料理の味（正解率）」だけをチェックしたり、「図書館の検索速度」だけを別々に測ったりしていました。しかし、「チーム全体がどう動いているか」を一度に、細かく測る道具が不足していたのです。

そこで登場するのが、RAGPerfです。

---

🛠️ RAGPerf の正体：AI 性能の「黒い箱」を開ける計測器

RAGPerf は、この AI チームの動きを**「分解して、一つ一つを精密に計測する」**ためのツールです。

1. 部品をバラバラに分解できる（モジュール化）

RAGPerf は、AI の仕組みを以下のように 5 つのパーツに分解して測ります。

• 📚 本をまとめる（チャンキング）： 長い文章を小分けにする作業。
• 🧠 意味を翻訳する（埋め込み）： 文章を AI が理解できる「数字の羅列（ベクトル）」に変える作業。
• 📖 本棚に並べる（インデックス）： 検索しやすいように本を整理する作業。
• 🔍 本を探す（検索）： ユーザーの質問に合う本を見つける作業。
• 🍳 料理を作る（生成）： シェフが本を見て回答を作る作業。

これらを組み合わせて、**「どのパーツが時間を食っているのか？」**を正確に突き止めます。

2. 現実と同じ「忙しい状況」をシミュレーションする（ワークロード生成）

RAGPerf は、ただ静かに測るだけではありません。

• 「本が次々と追加される」（新しいニュースが流れてくる）
• 「本の内容が書き換えられる」（情報が更新される）
• 「古い本が捨てられる」（古い情報が消える）

といった、**現実世界の「忙しい図書館」**をシミュレートします。これにより、「情報が更新された瞬間に、検索が遅くなったり、間違った答えが出たりしないか？」をテストできます。

3. 味（精度）とスピード（性能）の両方を測る

• 性能メトリクス： 「どれくらい速い？」「メモリ（冷蔵庫）をどれだけ使っている？」「CPU（調理台）はフル回転？」
• 品質メトリクス： 「答えは正しい？」「嘘をついていない？（ハルシネーション）」「必要な情報を使えている？」

この 2 つを同時に測ることで、**「速いけど嘘をつく AI」か「正しいけど遅すぎる AI」か、あるいは「バランスの良い AI」**かを判断できます。

---

🔬 論文が見つけた「意外な事実」

RAGPerf で実際に測ってみたところ、こんな面白いことがわかりました。

• 「検索」より「料理」の方が遅い：
  多くの場合、図書館から本を探す速度は速いですが、シェフが本を読んで回答を作る（生成）方が圧倒的に時間がかかります。つまり、**「検索エンジン（図書館）をいくら速くしても、シェフの腕前（AI モデル）が遅ければ全体は速くならない」**ことがわかりました。
• 「メモリー」が最大の壁：
  本を整理する場所（メモリー）が足りないと、システム全体が極端に遅くなります。特に、最新の巨大な AI モデルを使う場合、メモリー不足が最大のボトルネックになります。
• 「更新」はコストがかかる：
  新しい情報を追加するたびに、図書館の整理（インデックス再構築）が必要になると、検索速度がガクンと落ちることがあります。「最新情報」を即座に反映させるには、コストとのトレードオフ（交換条件）があることがわかりました。

---

🌟 まとめ：RAGPerf がもたらすもの

RAGPerf は、**「AI システムの設計図」**のようなものです。

開発者はこれを使うことで、

• 「あ、この設定だとメモリーが足りなくて遅いんだな」
• 「この AI モデルに変えれば、精度は上がるけど、速度は半分になるな」
• 「本棚の整理方法を変えれば、検索が 2 倍速くなる！」

といった**「データに基づいた賢い判断」**ができるようになります。

一言で言えば：

「AI 助手をより速く、より正確に、そして安く動かすための、究極の『性能計測器』」

これが RAGPerf です。開発者だけでなく、AI を使いたい企業やユーザーにとっても、「どの AI が本当に優秀か」を見極めるための重要なツールになるでしょう。

技術概要

RAGPerf: 検索拡張生成（RAG）システムのためのエンドツーエンドベンチマークフレームワーク

本論文は、検索拡張生成（RAG）パイプラインのシステム動作を特徴づけるための、新しいエンドツーエンドのベンチマークフレームワーク「RAGPerf」の設計と実装を提案しています。以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

1. 問題定義

大規模言語モデル（LLM）の進歩は AI 応用を革新しましたが、ドメイン固有の知識やプライベートデータを必要とするシナリオでは限界があります。RAG は外部知識ベースを LLM に付加することでこの課題を解決しますが、実環境でのデプロイには以下の課題が存在します。

• 複雑なシステム構成: RAG パイプラインは、埋め込み（Embedding）、インデックス作成、検索、再ランク付け、生成という複数のコンポーネントから構成され、それらの相互作用が最適構成の決定を困難にしています。
• 既存ベンチマークの限界: 既存の RAG ベンチマークの多くは、特定のアプリケーションに対する意味論的指標（精度やハルシネーション率など）に焦点を当てており、エンドツーエンドのシステムパフォーマンス（レイテンシ、スループット、リソース競合）や、リアルタイムなデータ更新を含む動的な動作を評価する機能に欠けています。
• リソース制約とトレードオフ: ドキュメントの形式（テキスト、PDF、コード、音声など）やモデルサイズ、ハードウェアリソース（CPU、GPU メモリ、ホストメモリ）の組み合わせがパフォーマンスに与える影響を定量的に評価する手段が不足しています。

2. 手法とアーキテクチャ

RAGPerf は、YCSB や OLTP-bench などのクラウドサービス向けベンチマークの考え方を RAG に適用し、モジュール化された拡張可能なフレームワークとして設計されています。

主要コンポーネント

1. ワークロードジェネレーター:

   • 現実のシナリオを模倣するため、テキスト、PDF、コード、音声など多様なデータセットをサポートします。
   • 動的な更新シミュレーション: 挿入（Insert）、更新（Update）、削除（Remove）、クエリ（Query）の混合ワークロードを生成します。特に「更新」操作については、LLM を利用してドキュメントの事実を変更し、対応する正解（Ground Truth）を動的に生成する仕組みを導入しており、知識の鮮度と検索精度の関係を評価可能にしています。
   • アクセスパターンとして、均一分布やZipf分布（特定のドキュメントへのアクセスが集中するホットスポット）をサポートします。

2. 構成可能な RAG パイプライン:

   • パイプラインを独立したモジュール（埋め込み、インデックス、検索、再ランク付け、生成）に分解し、YAML 設定ファイルを通じて各コンポーネントのパラメータを柔軟に設定できます。
   • 対応技術: 複数の埋め込みモデル、再ランクモデル、生成モデル（LLM）、および LanceDB、Milvus、Qdrant、Chroma、Elasticsearch などの主要なベクターデータベースをネイティブにサポートします。
   • マルチモーダル対応：OCR によるテキスト抽出や、ColPali などのマルチモーダル埋め込みモデルによる直接処理、Whisper による音声認識など、多様な入力形式に対応したパイプラインを構築可能です。

3. プロファイリングとメトリクス収集:

   • パフォーマンスメトリクス: エンドツーエンドのクエリスループット、レイテンシ、CPU/GPU利用率、メモリフットプリント、I/O スループットなどを細粒度で収集します。
   • 精度メトリクス: Ragas フレームワークを統合し、コンテキストリコール、事実一貫性、クエリ精度を評価します。
   • 低オーバーヘッド: プロファイラーは RAG パイプラインから独立した低優先度デーモンとして動作し、収集したメトリクスは非同期で保存されるため、システムへの影響は最小限（0.26% 未満の CPU 使用率）に抑えられています。

3. 主要な貢献

1. 初の実用的な RAG エンドツーエンドベンチマーク: 既存のベンチマークが欠如していた「システムパフォーマンス」と「検索・生成品質」の両方を統合的に評価するフレームワークを提供します。
2. 動的なデータ更新のシミュレーション: 静的なデータセットだけでなく、リアルタイムなドキュメント更新（追加、修正、削除）を含むワークロードを生成・評価する機能を実装し、インデックス再構築のオーバーヘッドと検索遅延のトレードオフを可視化しました。
3. 多様なモダリティと構成のサポート: テキスト、PDF、音声など多様なデータ形式と、複数のベクターデータベース、モデルサイズ、ハードウェア構成（CPU コア数、メモリ容量など）を自由に組み合わせることで、広範な設計トレードオフの分析を可能にします。
4. オープンソース化: GitHub でコードを公開し、開発者が容易に利用・拡張できるモジュラー設計を採用しています。

4. 評価結果

広範な実験を通じて、RAGPerf の能力と RAG システムの特性を明らかにしました。

• ボトルネックの特定:
  • テキストクエリパイプラインでは、LLM 生成が全体のレイテンシの大部分（75%〜91%）を占め、ベクターデータベースの選択はエンドツーエンド性能にほとんど影響しないことが示されました。
  • 一方、PDF/画像パイプラインでは、OCR 変換や再ランク付けが主要なボトルネックとなり、特に Chroma などのデータベースは高並列検索においてスケーラビリティの限界を示しました。
• リソース利用の分析:
  • GPU メモリ: 生成モデルの KV キャッシュやモデル重みにより、GPU メモリが主要なボトルネックとなります。
  • ホストメモリ: ベクターインデックスの構築や検索中にホストメモリが大量に消費され、メモリ不足はディスクベースのインデックスを強制し、スループットを劇的に低下させます。
  • CPU: 検索（Retrieval）やインデックス構築（Indexing）の段階で CPU 利用率が飽和することが確認されました。
• 更新操作の影響: 一時的なフラットインデックスを使用すると、更新されたデータが即座に検索可能になり精度は向上しますが、フラットインデックスが成長するにつれて検索レイテンシが増加し、再構築時に急激に低下するトレードオフが確認されました。
• リソース制約の影響: CPU コア数の増加はスループットにほとんど影響しませんが、ホストメモリや GPU メモリの不足は深刻なパフォーマンス低下を招きます。また、バッチサイズを増大させるとスループットは向上しますが、KV キャッシュに必要な GPU メモリが不足すると逆に低下することが示されました。
• オーバーヘッド: プロファイリングによるオーバーヘッドは無視できるレベル（単一イテレーション時間の 0.11% 増加）であり、実運用環境での利用に適しています。

5. 意義

RAGPerf は、RAG システムの開発者や研究者にとって不可欠なツールです。

• データ駆動型の意思決定: 特定のユースケースやハードウェア環境において、どのモデル、データベース、構成パラメータが最適かを定量的に判断する根拠を提供します。
• システム最適化の指針: リソース競合やボトルネックを特定することで、効率的なシステム設計（例：GPU メモリの動的割り当て、インデックス戦略の選択）を導きます。
• 将来の拡張性: モジュラー設計により、新しい検索手法（GraphRAG など）や推論メカニズムの統合が容易であり、RAG 技術の進化に伴って継続的に利用可能です。

総じて、RAGPerf は RAG システムの複雑な挙動を解明し、実世界での信頼性の高いデプロイを支援する重要な基盤技術として位置づけられます。