RAGとは？RAGは「Retrieval-Augmented Generation（検索で強化された生成）」の略で、AIが回答を生成する際に、外部の知識やデータを参照しながら応答する仕組みです。なぜRAGが必要なのか？従来の生成AI（LLM）には3つの主な課題がありました：学習済みの古い情報しか知らない特定の分野の専門的な情報が不足時々、誤った情報を生成（ハルシネーション）これらの課題からビジネスの現場で一般的な生成AIアプリ、例えばChatgpt等を活用するには限界がありました。そこでRAGはこれらの課題を解決するために開発されました。RAGは信頼できるデータベースから正しい情報を検索（Retrieval）し、AIが検索された情報を理解しながら質問に対する適切な回答を生成（Generation）することが可能です。2024年現在、特定の製品や専門知識について議論できる、信頼性の高い AI システムを構築するための、最も一般的な方法となっています。しかしながら誤った方法でRAGを構築してしまうとRAGプロジェクトは失敗に終わってしまいます。そこで本記事ではhomulaが過去PoCを突破し本番環境で運用可能なRAGを実装した経験から学んだRAG構築のベストプラクティスをご紹介いたします。1. データソースを慎重に選別する「ガベージ・イン、ガベージ・アウト」という古いプログラミングの格言は、RAGシステムに特に当てはまります。 RAGシステムの品質は、データソースの質に密接に関わります。多くのチームがよく陥る間違いは、ナレッジベース全体（例：過去10年分のすべてのSlackメッセージ、サポートチケット、ドキュメントなど）を無差別にRAGシステムに投入してしまうことです。「データが多ければ多いほど良い結果が得られる」と考えがちですが、実際にはそうではありません。むしろ、重要度の高いコアコンテンツから始めることをお勧めします。例えば技術・製品にまつわる専門的なAI アシスタントを構築したい場合、以下のような一次ソースから着手するのが効果的です：技術文書および API リファレンス製品アップデートとリリースノート検証済みのサポートソリューションナレッジベースの記事一次ソースの整備が完了したら、Slackチャンネル、フォーラムでの議論、サポートチケットなどの二次ソースへと範囲を広げていくことができます。ただし、その際も選択的なアプローチを取るべきです。例えば、最新性（直近1年以内の投稿のみを対象とする）や信頼性（認証済みコミュニティメンバーからの回答のみを採用する）といった基準でフィルタリングを行います。実装方法については、いくつかの選択肢があります。LangChainのようなオープンソースツールを使用すれば、Slackを含む様々なデータソースに対する情報検索コネクタを利用できます。一方、コードを書かずに実装したい場合は、ビルド済みのフィルターやデータコネクターを提供するようなソリューションも選択肢となります。どちらのアプローチを選ぶにせよ、重要なのは「どのデータを含めるか」「どのようにフィルタリングするか」を慎重に検討することです。もう一つ重要な検討事項として、パブリックな知識ソースとプライベートなデータを分離することが挙げられます。具体的には、公開文書などの外部データと、機密性の高い企業データや社内文書を別々に管理することです。このような分離により、セキュリティが強化され、アクセス制御の管理も容易になります。2. 堅牢な更新パイプラインの実装AIエージェントのデータソースは決して静的なものではありません。多くの企業ではドキュメントリポジトリが1日に何十回も更新されています。RAGシステムは、その基盤となる知識ベースを常に最新の状態に保つため、このような更新頻度に対応できる必要があります。これが適切に実装されていない場合、AIが古い情報に基づいた回答をしてしまったり、重要な更新を見落としたり、さらには古い情報と新しい情報が混在して混乱を招いたりする可能性があります。しかし、多くのチームがRAGの知識ベースを一度構築したら終わりというような扱い方をしているのが現状です。実用的なシステムには、自動更新パイプラインが不可欠です。ただし、ここで重要なポイントがあります。毎回すべてのインデックスを再構築するのは、コストがかかる上に非効率的です。代わりに、Gitの差分管理のような仕組みを導入し、変更があった部分のみを更新する方法が効果的です。いわば、AIの知識に対する継続的デプロイメントのような仕組みです。主要なパイプラインのコンポーネントとして、以下の要素を考慮する必要があります：ドキュメントの更新を検知する変更監視システムレイアウトの変更を検出するコンテンツ検証機能差分更新による処理の効率化変更履歴を管理するバージョン管理品質低下を防ぐモニタリング機能社内での構築を検討している技術チームのために、具体的なアプローチを紹介します：コンテンツの変更を定期的にチェックするcronジョブの設定更新処理にはRabbitMQなどのメッセージキューを活用インデックス作成前の検証チェックの実施更新パフォーマンスを追跡するモニタリングの導入このアプローチは確実に機能しますが、構築と維持に相当なエンジニアリングリソースが必要となります。そのため、弊社homulaでは自動コンテンツ更新機能を開発・提供しております。当社のプラットフォームは、知識ベースを最新の状態に保つための複雑な処理をすべて自動的に行います。結論として、自社での構築を選択する場合でも、当社のような会社に依頼する場合でも、RAGシステムを知識ソースと常に同期させ、最新の状態に保つことが極めて重要です。なぜなら、AIアシスタントの性能は、アクセスできる情報の質と鮮度に大きく依存するからです。3. 総合的な評価システムの構築多くのチームが直面する課題は、厳密な評価の仕組みが不足していることです。RAGアプリケーションの構築では、文書の分割サイズ、埋め込みモデル、文脈の範囲、引用方法など、数多くのパラメータを調整する必要があります。これらの設定は相互に影響し合い、最適化の過程は迷路のように複雑になっていきます。最新のRAGアーキテクチャは、単純な埋め込みと検索の段階を大きく超えて進化しています。例えば、Perplexityはクエリの分解などの技術を先駆的に導入し、他社もクロスエンコーダーによる再ランク付けやハイブリッド検索などの手法で新境地を開拓しています。しかし、ここで重要なのは、測定できないものは最適化できないという点です。PoCやプロトタイプ段階では、「この回答は正しそうだ」という感覚的な判断でも十分かもしれません。システムにテスト用の質問をいくつか投げかけ、回答を目視で確認して完了、という手順は誰もが経験があるでしょう。ただし、本番環境での運用には、より厳密な評価が必要になります。評価の枠組みには、主に2つの選択肢があります：Ragasなどのオープンソースツールを使用し、回答の正確性、文脈の関連性、誤情報の検出などの指標を即座に得る方法特定のユースケースに合わせて構築したカスタム評価の仕組みRagasのようなツールは良い出発点となりますが、実際のビジネスニーズに対応するには、大幅な拡張が必要になることが多いです。評価の仕組みには、以下の要素が含まれるべきです：質問の理解度引用と情報源の追跡回答の完全性誤情報の検出重要なのは、用途に応じた適切な評価基準を設計することです。例えば、営業部門向けのAIアシスタントを開発する場合、その評価基準はカスタマーサポートや法務文書分析用のシステムとは大きく異なります。汎用的なソリューションを目指すのではなく、実際の利用パターンと顧客からのフィードバックに基づいた評価の仕組みの開発が重要です。学術的な指標や一般的な評価ツールだけでは不十分で、実際のユーザーニーズを反映した評価が必要だということを経験から学んでいます。重要な原則として、RAGシステムのあらゆる改善は、厳密なテストによって検証されるべきです。これは、改善が単なる数値上の向上ではなく、実際にユーザー体験の改善につながることを確認する唯一の方法です。4. ユースケースに合わせたプロンプトの最適化本番環境のRAGシステムにおいて、プロンプト戦略は極めて重要です。単に一般的に良しとされているプロンプトを作成するだけでなく、特定のユースケースに適合した包括的な戦略を構築する必要があります。これまでのRAG実装経験を通じて得られた重要な原則を紹介します：回答の根拠を明確にする：RAGシステムの第一原則は、AIに事実でないことを言わせないことです。プロンプト戦略では、以下の2点を明示的にモデルに指示する必要があります： (1) 提供されたコンテキストのみを使用すること (2) 主張には明確な出典を含めること「わからない」と言える判断力を持たせる：当たり前のように思えるかもしれませんが、AIに自身の限界を認識させることは極めて重要です。優れたRAGシステムには、以下の3つの能力が必要です： (1) 十分な情報がない場合にそれを認識すること (2) 可能な場合は代替となる情報源を提案すること (3) 推測や誤った情報の生成を決して行わないこと話題の範囲を適切に保つ：本番環境のRAGシステムには明確な境界線が必要です。プロンプトを通じて、AIに以下の3点を徹底させる必要があります： (1) 与えられた知識領域の範囲内で回答すること (2) 関連性のない内容についての質問には回答を控えること (3) 一貫した話調とフォーマットを維持すること複数の情報源を適切に扱う：プロンプト戦略では、異なる情報源からの情報を効果的に処理する必要があります。具体的には以下の4点が重要です： (1) 複数の文書からの情報を適切に統合すること (2) バージョン固有の情報を正しく処理すること (3) 矛盾する情報を適切に管理すること (4) 関連する文脈を適切に提供すること。これらの原則は相互に関連しています。例えば、複数の情報源を扱う際、新しいバージョンの製品については「分かりません」と応答する必要があるかもしれません。また、回答の根拠を示す際には、情報源間で矛盾がある場合はその事実を明確に伝える必要があります。5. セキュリティのベストプラクティスを導入する本番環境のRAGシステムにおいて、セキュリティを後回しにすることはできません。RAGシステムには、特に注意すべき2つの主要なリスク要因があります：プロンプトハイジャック（ユーザーがシステムの動作を操作するような入力を作成すること）と、前述したような誤った情報や機密情報を生成してしまうハルシネーションです。顧客データや社内文書を扱う場合、これらのリスクはより深刻なものとなります。しかし、本番システムでは対策が不十分になりがちな、さまざまな付随的なリスクが存在します。ここではそれらについて説明していきます。個人情報の検出とマスキング：RAG システムは、機密情報を慎重に扱う必要があります。 エラーメッセージの API キー、メールアドレス、またはサポートチケットの顧客情報などです。ボット対策とレート制限：パブリックなRAGシステムをデプロイする場合、それは攻撃の標的となる可能性があります。保護されていないエンドポイントに対して1分間に数千件のリクエストが殺到し、コストの増大だけでなく、機密情報の流出の可能性も引き起こすケースがあります。レート制限、reCAPTCHAの統合、リクエストの検証といった保護対策は不可欠です。これらの課題に対応する最新のソリューションも登場しています。最近、CloudflareがAI用ファイアウォールをリリースしましたが、これは大規模なAIシステムを保護するための業界の進化を示しています。アクセス制御：すべての情報をすべての人が見られるようにすべきではありません。適切なアクセス制御がないと、社内文書や顧客データが部門の境界を越えて漏洩する可能性があります。ロールベースのアクセス制御により、ナレッジベースは適切なユーザーにのみアクセス可能な状態を保ちながら、セキュアに保たれます。さらに重要なのは、誰が何にアクセスしているかを追跡できることです。重要なのは、インシデント発生後ではなく、デプロイ前にこれらの保護対策を実装することです。6. 結論 RAGプロジェクトを成功させるためにこれまでの弊社の実装経験から、成功するRAG実装プロジェクトに共通する要素は以下の通りです：小規模に始めて、しっかりと構築するRAG構築を始めるにあたって重要なポイント：厳選された高品質なドキュメント1〜2個の明確に定義されたユースケース明確な評価指標基本的なセキュリティ対策避けるべき一般的な落とし穴急いで大量のデータを追加することリフレッシュパイプラインを軽視すること手動テストに依存することセキュリティを後回しにすることPoCの際にも、これらの原則を見据えておくことが重要です。本番環境で運用する際に重要なのは、RAGシステムを実験的なアドオンではなく、中核インフラとして扱うことです。RAGのPoCや導入にご興味がある場合、こちらから株式会社homulaに是非お問い合わせください。