AWS生成AIで実現する低コストRAG構築の全体像

AWS Knowledge Bases for Amazon BedrockとS3 Vectorsを活用した低コストRAG環境は、検索基盤をフルマネージドで維持しながら、初期実装と運用負荷を抑えたい中級者に適した構成です。RAG構築では、文書保管、ベクトル化、検索、LLMによる応答生成を分離して設計することが重要です。特にAWSの生成AI基盤では、Knowledge Bases for Amazon Bedrockがデータ接続と検索オーケストレーションを担うため、アプリケーション側はプロンプト設計、権限制御、回答品質の検証に集中しやすくなります。

import boto3
import json

bedrock_agent_runtime = boto3.client("bedrock-agent-runtime", region_name="ap-northeast-1")

response = bedrock_agent_runtime.retrieve(
    knowledgeBaseId="kb-xxxxxxxxxx",
    retrievalQuery={
        "text": "勤怠申請の締め日はいつですか？"
    },
    retrievalConfiguration={
        "vectorSearchConfiguration": {
            "numberOfResults": 3
        }
    }
)

for i, result in enumerate(response.get("retrievalResults", []), 1):
    print(f"[{i}] score={result.get('score')}")
    print(result["content"]["text"][:300])
    print(result.get("location", {}))

このように、まずは「検索で根拠文書を安定して取得できるか」をコードレベルで確認しておくと、PoC段階での評価が進めやすくなります。

Knowledge Bases for Amazon Bedrockの役割と、低コスト構成で押さえるべき設計ポイント

Knowledge Bases for Amazon Bedrockは、S3上の文書取り込み、分割、埋め込み生成、検索連携を一貫して扱える点が強みです。低コスト化の要点は、更新頻度の低い文書を対象にすること、チャンクサイズを過度に細かくしないこと、検索対象を業務ドメイン単位で分離することです。たとえば、社内規程や製品マニュアルのような静的データでは、再インデックス頻度を抑えやすく、PoCでも費用対効果を確認しやすくなります。

また、S3に投入する前の前処理も重要です。PDFをそのまま投入するより、見出しや箇条書きを維持したテキストやMarkdownに整形したほうが、チャンク分割後の意味の一貫性を保ちやすくなります。たとえば、簡易的にテキストファイルをS3へアップロードする処理は以下のように書けます。

import boto3

s3 = boto3.client("s3", region_name="ap-northeast-1")

bucket_name = "example-rag-docs"
object_key = "hr/rules/attendance-policy.md"

body = """
# 勤怠申請ルール

## 締め日
勤怠申請の締め日は毎月末日です。

## 修正申請
締め日を過ぎた場合は所属長の承認が必要です。
"""

s3.put_object(
    Bucket=bucket_name,
    Key=object_key,
    Body=body.encode("utf-8"),
    ContentType="text/markdown"
)

このように、文書の配置ルールを「部門/カテゴリ/文書名」のように統一しておくと、後続のメタデータ設計やアクセス制御にもつなげやすくなります。

Knowledge Bases for Amazon BedrockとS3 Vectorsの実践的な使いどころ

S3 Vectorsは、オブジェクトストレージ由来のコスト優位性を活かしつつ、ベクトル検索基盤をAWS内で完結させたいケースに向いています。専用検索エンジンほど多機能ではない一方、文書検索を主目的としたRAG構築では十分に有力な選択肢です。特に、問い合わせ件数がまだ読めない新規プロジェクトや、まずはAWS標準サービスで構成を固めたいチームに適しています。

実際のアプリケーションでは、検索結果をそのままユーザーに返すのではなく、取得した文脈をLLMに渡して回答を生成します。以下は、検索結果をプロンプトに埋め込み、Bedrock Runtimeで回答を生成するシンプルな例です。

import boto3
import json

bedrock_runtime = boto3.client("bedrock-runtime", region_name="ap-northeast-1")

context = """
[文書1]
勤怠申請の締め日は毎月末日です。
締め日後の修正には所属長の承認が必要です。
"""

prompt = f"""
あなたは社内ヘルプデスク担当です。
以下の参考情報だけを根拠に回答してください。
根拠が不足している場合は、不明と回答してください。

参考情報:
{context}

質問:
勤怠申請の締め日はいつですか？
"""

response = bedrock_runtime.invoke_model(
    modelId="amazon.nova-lite-v1:0",
    body=json.dumps({
        "messages": [
            {
                "role": "user",
                "content": [
                    {"text": prompt}
                ]
            }
        ]
    })
)

print(response["body"].read().decode("utf-8"))

この構成であれば、検索と生成の責務が分離されるため、検索精度の改善とプロンプト改善を個別に進めやすくなります。

S3 Vectorsをベクトルストアとして使うメリット・制約・適用シナリオ

最大のメリットは、ストレージ中心のコスト感で小さく始めやすいことです。加えて、IAM、S3、Bedrock周辺の設計思想と親和性が高く、権限管理や監査ログの統一もしやすくなります。一方で、複雑なハイブリッド検索や高度なランキング調整が必要な場合は制約になり得ます。そのため、FAQ検索、技術文書参照、社内ナレッジ検索のように、検索要件が比較的明確なシナリオで特に効果を発揮します。

たとえば、検索対象を部門ごとに分けたい場合は、S3のプレフィックスやメタデータで範囲を整理しておくと、Knowledge Baseの運用もシンプルになります。文書配置の例としては、s3://example-rag-docs/hr/、s3://example-rag-docs/legal/、s3://example-rag-docs/product/のように分ける方法が分かりやすく、将来的な権限分離にも対応しやすくなります。

Knowledge Base連携時のデータ投入、検索精度、運用負荷の考え方

実運用では、投入データの前処理が検索精度を大きく左右します。見出し構造の欠けたPDFや表主体の文書は、そのままでは文脈が崩れやすいため、Markdownや整形済みテキストへの変換が有効です。また、1チャンクに複数トピックを混在させると検索ノイズが増えます。運用面では、更新バッチの実行時間を固定し、メタデータ設計と評価用クエリセットを継続的に管理することで、少人数でも品質を維持しやすくなります。

たとえば、評価用クエリをJSONで持っておくと、検索精度の回帰確認を自動化しやすくなります。

[
  {
    "question": "勤怠申請の締め日はいつですか？",
    "expected_keywords": ["毎月末日", "締め日"]
  },
  {
    "question": "締め日後の修正申請には何が必要ですか？",
    "expected_keywords": ["所属長の承認"]
  }
]

このような評価セットを使って、文書更新後に上位3件の検索結果へ期待キーワードが含まれるかを確認するだけでも、PoCから本番への移行判断がしやすくなります。

低コストRAG環境をAWSで選定・運用する際の判断基準

選定時は、単純な月額比較だけでなく、データ量・更新頻度・要求精度・運用体制の4軸で判断するべきです。たとえば、数十万文書規模で高度な検索制御が必要なら専用ベクトルDBも候補になりますが、数千〜数万文書で検索要件が標準的であれば、Knowledge Bases for Amazon BedrockとS3 Vectorsの組み合わせは十分に現実的です。AWSの生成AI基盤に寄せることで、学習コストと構成の複雑性も抑えられます。

また、アプリケーション側では、検索結果が0件だった場合のフォールバックも実装しておくと運用が安定します。以下は簡易的な分岐例です。

results = response.get("retrievalResults", [])

if not results:
    answer = "関連文書が見つからないため、担当部門へ確認してください。"
else:
    top_context = "nn".join(
        r["content"]["text"] for r in results[:3]
    )
    answer = f"参考文書をもとに回答します。n{top_context}"

このような最低限の例外処理を入れておくだけでも、「答えられない質問に無理に答える」挙動を抑制しやすくなります。

PoCから本番までのRAG構築で見る、コスト最適化とサービス選定の勘所

PoCでは、まず対象文書を限定し、正答率そのものよりも検索で根拠文書を安定取得できるかを確認することが重要です。本番移行時は、アクセス増加よりも、データ更新運用、権限分離、回答監査の仕組みが支配的な課題になりやすい傾向があります。つまり、初期はS3 Vectorsで低コストに始め、検索要件が高度化した段階で上位サービスを再評価する進め方が合理的です。小さく始めて評価指標を蓄積することが、失敗しにくいRAG構築の基本戦略です。

特に実務では、最初から完璧な検索基盤を目指すよりも、少数の代表文書で検索・回答・評価のループを回すことが重要です。コードで検索結果を確認し、期待した根拠が取れているかを見ながらチャンク設計や文書整形を調整していく進め方が、最も低コストで再現性の高いアプローチといえます。