Zenn
🐙

Amazon BedrockのKnowledge Baseを活用したRAG構築

2025/01/06に公開
RAG
tech

はじめに

AWSが提供するマネージド型生成AIサービスである Amazon Bedrock は、複数の高品質なファウンデーションモデル(Foundation Models, FMs)にシンプルなAPIでアクセス可能なエコシステムを提供します。さらに近年、Amazon Bedrock Agents という機能が導入され、エンタープライズ環境やプライベートなドキュメントストアに対するアクセス性を高めています。

このBedrock Agentsは、Knowledge Base（エージェントが利用する外部情報源）を定義することで、LLMが最新の企業内ナレッジやドキュメント、データベース情報などに基づいて回答を生成できるようになります。これにより、Retrieval Augmented Generation (RAG)アーキテクチャをより簡潔かつ強力に実装することが可能になります。

本記事では、BedrockのKnowledge Baseを活用してRAGを構築する流れについて、コンセプトの説明からアーキテクチャ、実装例、運用上の考慮点までを詳しく解説します。

RAG (Retrieval Augmented Generation)の基礎

RAGとは

RAGは、LLMへの入力（プロンプト）を生成する際に、外部システムから関連情報を取得し、そのコンテキストを用いてLLMが回答を生成する手法です。RAGは基本的に2つの段階から成ります。

  1. Retriever段階：
    質問を受け取り、Knowledge Base（ドキュメントストア、データベース、社内Wiki、S3上のファイル群など）から関連する情報を検索・抽出します。

  2. Generator段階：
    抽出した情報をLLMのプロンプト（入力）として渡し、コンテキストに基づいた回答を生成します。

この手法は、LLM自体が学習済みモデルに含まない最新・社内固有情報にも対応するため、動的かつ拡張性の高い回答生成が可能になります。

Amazon Bedrock AgentsとKnowledge Baseの概要

Amazon Bedrock Agents は、Bedrock上で動作する「エージェント」機能で、LLMと外部のKnowledge BaseやAPIエンドポイント、システムコマンドなどを統合する仕組みです。このエージェントは、ユーザからの問い合わせを受け取ると、定義されたプラグイン（外部ソースへのアクセス定義）を通じて必要な情報を取得し、その情報をもとにLLMの回答を生成します。

Knowledge Baseとは

Bedrock Agentsには「Knowledge Base」を定義する機能があります。Knowledge Baseとは、RAGにおけるRetriever部分をBedrockエージェント内で抽象化・自動化する仕組みです。具体的には以下のような特徴があります：

  • 統合された外部データアクセス：
    Knowledge BaseとしてS3に格納されたドキュメント群や、Amazon RDS、Amazon DynamoDB、カスタムAPI等を接続できます。
    これにより、エージェントがユーザ問い合わせ時に自動的に関連情報をKnowledge Baseから検索・取得可能になります。

  • メタデータ・スキーマ定義：
    ドキュメントのメタデータやスキーマを定義することで、より精密な検索やフィルタリングが可能です。

  • モデルとの密接な統合：
    Knowledge Baseで取得した情報は、Bedrock内のLLMへスムーズに渡され、LLMはそのコンテキストを活用して回答を生成します。

RAG × Bedrock Agentsで得られるメリット

  • シンプルなアーキテクチャ：
    従来はRAGを構築する際、LLM推論と外部検索基盤（Kendra、OpenSearch、ベクターデータベースなど）をアプリケーションロジック内で統合する必要がありましたが、Bedrock AgentsとKnowledge Baseを用いることで、これらの操作をBedrockプラットフォーム内で一元的に扱えます。

  • 拡張性と保守性：
    Knowledge Baseを変更・追加することで、対応可能な情報源を柔軟に拡張できます。また、新たなデータソースやインデックス更新などもエージェント定義の変更で管理しやすくなります。

典型的なRAGアーキテクチャ（Knowledge Base統合版）

以下は、Bedrock Knowledge Baseを用いたRAGアーキテクチャの典型的なフローです。

  1. データ登録：
    社内ドキュメントやFAQ、マニュアル、最新リリースノートなどをS3に配置するか、社内DBに格納します。この情報源をKnowledge BaseとしてBedrock Agentに登録・構成します。

  2. 問い合わせ処理 (ユーザ質問)：
    ユーザがアプリ（Web UI、APIエンドポイント、Slack Bot等）から自然言語で質問します。

  3. エージェントによるRetriever動作：
    Bedrock Agentが内部的にKnowledge Baseへアクセスし、関連性の高いドキュメントやレコードを検索・抽出します。この部分はBedrockが管理するため、開発者は特定のAPIコールを明示的に実装する必要がありません。

  4. LLMへのプロンプト生成と回答生成：
    Agentは取得したドキュメントをLLMへのコンテキストとして渡し、回答を生成します。

  5. ユーザへの応答返却：
    生成された回答はAgent経由でユーザに返却されます。

実装例の流れ

以下に疑似的なコードフローと設定イメージを示します。
（※2023年末時点、Bedrock Agentsは限定プレビュー段階であり、実際のAPI仕様や設定は変わる可能性があります。あくまで参考例です。）

事前準備

  1. データの準備：

    • 企業内部門向けのQ&Aドキュメント（PDF、Markdown、HTMLなど）をS3バケットに格納します。
    • FAQなどをCSVやJSONで管理している場合はそのままKnowledge Baseで参照可能にします。

  2. Knowledge Base設定：

    • BedrockコンソールまたはCLIでKnowledge Baseを作成し、S3やDBへの接続情報を定義します。
    • メタデータスキーマ(タイトル、タグ、更新日時など)を設定することで、検索最適化が可能です。

  3. Agent作成：

    • Bedrockコンソール上でAgentを作成し、先ほど定義したKnowledge Baseを関連付けます。
    • Agentには利用するFoundation Model（例：Anthropic Claude、Amazon Titan）や、プロンプトテンプレートを設定できます。

Pythonサンプルコード（概念的な例）

import boto3
import json

# エージェントと対話するためのBedrockクライアント(仮)
bedrock = boto3.client(
    "bedrock-runtime",
    region_name="us-east-1",
    # エンドポイントや認証情報は適宜設定
    endpoint_url="https://<your-bedrock-endpoint>"
)

# Agent IDは事前にコンソールで作成・取得したものを利用
AGENT_ID = "<Your-Agent-ID>"

def ask_agent(query: str) -> str:
    """
    Agentに自然言語質問を投げて回答を得る関数 (仮実装)
    Agentは内部でKnowledge Baseを用いて情報取得し、LLMで回答を生成する
    """
    # 送信ペイロード
    request_body = {
        "agentId": AGENT_ID,
        "inputMessage": query
    }

    response = bedrock.invoke_model(
        modelId="agent-invoke",  # Agent呼び出し用モデルID（仮）
        accept='application/json',
        contentType='application/json',
        body=json.dumps(request_body)
    )

    result = json.loads(response['body'].read().decode('utf-8'))
    # ここでresult["answer"]などで回答を取り出すイメージ
    answer = result.get("answer", "")
    return answer.strip()

if __name__ == "__main__":
    user_query = "最新の製品アップデート情報を教えてください。"
    answer = ask_agent(user_query)
    print("回答:", answer)

ポイント：
• ask_agent関数内では、ユーザ質問（query）をエージェントに渡しています。
• エージェントは内部でKnowledge Base検索を行い、その結果をLLMに渡して最終回答を生成します。
• 開発者はRetriever段階とGenerator段階の統合を意識する必要がなく、シンプルな関数コールで回答を得ることが可能になります。

運用上の考慮
• Knowledge Base更新：
新しいドキュメントがS3に追加された場合、Knowledge Baseのクロール・インデックス更新が必要です。これにより、Agentは最新情報を取得できるようになります。
• アクセス制御・セキュリティ：
IAMロールやKMS暗号化、VPCエンドポイントの利用によって、機密性の高いドキュメントへのアクセスを制御します。
• メタ情報活用：
Knowledge Base内のメタデータ（著者、日付、タグ）を利用した検索で、回答精度向上が期待できます。
• モデル・Agent設定の継続的調整：
利用するモデルの選定やプロンプトテンプレートのチューニングを行い、回答品質を改善します。

まとめ

本記事では、Amazon BedrockのKnowledge Base を活用してRAGを構築する手法を紹介しました。Bedrock AgentsとKnowledge Baseを用いることで、RetrieverとGeneratorを統合的に扱い、外部データへのアクセスや検索処理をBedrockプラットフォーム内で完結できます。

これにより、複雑なアプリケーションロジックや外部検索基盤の統合が容易になり、メンテナンス性・拡張性が大幅に向上します。また、社内ドキュメントへの動的なアクセスや最新情報への対応を実現できるため、顧客サポート、自動レポーティング、社内ナレッジナビゲーションなど、幅広いビジネスユースケースでの活用が期待できます。

ぜひこのガイドを参考に、Bedrock AgentsとKnowledge Baseを用いた次世代のRAGアーキテクチャを検討してみてください。

Discussion