生産性のためのハンズオンRAG (Japanese Edition)

第4章 RAGの本番環境へのデプロイ

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

RAGパイプラインの基本的な構成要素から高度な要素までを理解した今、かなり良い概念実証（POC）を簡単に構築できる。最初のPOCでは、組織にとって大きな価値があり、かつ初期投資が比較的少ないユースケースを選ぶのが一般的だ。そうすることで、実際にどのように機能するかを学び、RAGの仕組みを直接理解することができる。

RAGの概念実証を立ち上げて稼働させるのは、非常に楽しい作業だ。強力な大規模言語モデルを用意し、文書やデータに適用し、ベクトルデータベース内でクエリとチャンク埋め込みベクトルの間でのベクトル類似性を実装すれば、あっという間に、文書のコンテンツに基づいて質問をし、実際の回答を得られるようになる。

これをサイドプロジェクトとして行う場合、必要な時間と労力はそれほど多くない。しかし、拡張性があり、セキュリティが確保されており、高速で、自社にミッションクリティカルなサービスを提供する本番環境レベルのRAGアプリケーションを構築することが目標であるなら、話は全く別物だ。

RAGアプリケーションをPOCから本番環境へデプロイする際、企業は技術、運用、組織の各ドメインにまたがる多くの課題に直面する。RAGアプリケーションをスケールアップするにつれ、遅延のボトルネック、ベンダ統合の複雑さ、データセキュリティ要件、そして分野横断的な専門知識の不足といった問題にしばしば直面することになる。

本章では、こうした課題のいくつかをさらに深く掘り下げ、可能な限り、それらに対処したり、悪影響を最小限に抑えたりするための戦略について論じる。本章にはいくつかのコードスニペットが含まれるが、本番用RAGパイプラインのための完全なエンドツーエンドのコードベースは提供しない。 真の本番環境向けRAGアーキテクチャが単一のスクリプトやノートブックに収まることは稀だ。それは、コードとしてのインフラ、複雑なオーケストレーション、そして本章では網羅しきれないほど広範かつ環境固有のエンタープライズ向け統合パターンに大きく依存する分散システムである。

RAGを本番環境に移行するために必要な「重労働」の多くは、RAG固有のロジックというよりは、標準的で厳格なソフトウェアエンジニアリングやDevOpsの実践に関わるものだ。高可用性、負荷分散、コンテナ化（Docker/Kubernetes）、 のシークレット管理、 、CI/CDパイプラインといった概念は、ミッションクリティカルなエンタープライズアプリケーションにとって普遍的な要件である。¹

したがって、本章では主にシステム設計、アーキテクチャ、戦略、およびPOCから本番環境への移行方法に焦点を当てる。

本番環境におけるRAGの課題

スケーラブルで本番環境向けのRAGスタックを構築するのは、一見したよりも難しい。レスポンスの品質、遅延、セキュリティ、サポート、コストなど、多くのハードルが存在する。

レスポンスの品質とハルシネーションの低減

RAG を使用して AI アシスタントを構築する場合でも、質問応答や RFP（提案依頼書）への自動応答のためのアプリケーションを構築する場合でも、あるいはその他のユースケースであっても、RAG パイプラインからのレスポンスの品質は、多くの場合、最も重視すべき重要な機能である。

ユーザは信頼できないアプリケーションから離れていく傾向があるため、レスポンスの多くが不正確であったり、ハルシネーションを含んでいたりすると、そのアプリケーションに対するユーザの信頼は劇的に低下し、実質的に使用不能になってしまう。 ...