【要約】Amazon S3 Vectors で「月額ほぼゼロの RAG」を作ってみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が社内ナレッジ検索の PoC を行う際、検証を行わない時間帯のインフラコストが課題となる。
- ・OpenSearch Serverless 等の一般的な構成では、最小構成でも月額数百ドルの常時課金が発生する。
- ・低頻度アクセスの検証において、このアイドルコストは予算を圧迫する要因となる。
- ・既存のベクトルストアは検索エンジンを常時起動させる必要があり、コスト効率に課題がある。
- ・検証を中断してもコストが流れる構成は、迅速な試行錯誤を妨げる。
// Approach
開発者はコスト最小化のため、ストレージとクエリの従量課金のみで動作する Amazon S3 Vectors を採用した。
- ・Bedrock Knowledge Bases のストレージとして S3 Vectors を指定する。
- ・CDK では未実装のコンストラクトを
CfnResourceで直接定義する。 - ・メタデータ容量制限を回避するため、
AMAZON_BEDROCK_TEXTを「フィルタ不可」として宣言する。 - ・Embedding モデルの次元数とインデックスの Dimension を一致させる。
- ・IAM ロールの権限は
inline_policiesを用いて作成時に確定させる。
// Result
開発者は、検証を中断してもコストが流れない、PoC に最適な RAG 基盤を構築できた。
- ・数百ドキュメント規模の差分同期は 1 分程度で完了する。
- ・検索レイテンシは 100ms 級であり、LLM の生成時間を考慮すると対話 UI 上で許容可能である。
- ・将来的な OpenSearch への移行を見据え、検索インターフェースを抽象化して構築した。
- ・これにより、検索品質の低下が発生した際も、構成の差し替えが容易な設計を実現した。
Senior Engineer Insight
> 本構成は、コストに極めてシビアな PoC フェーズにおいて合理的な選択である。アイドルコストを排除できる点は、検証の試行回数を増やす上で大きな利点となる。ただし、ハイブリッド検索の欠如による検索精度の低下や、メタデータ容量の制約には注意が必要だ。実戦投入時には、検索インターフェースを抽象化し、要件に応じて OpenSearch Serverless 等へ容易に切り替えられる設計を徹底すべきである。