Amazon Bedrockの導入効果をレビューでご紹介(kzk-maeda-atama plus株式会社)

導入背景

導入前は、LangChainを利用してツール内でOpenAI APIを実行していましたが、OpenAI APIを実行するためのクレデンシャル管理やコスト管理が個別に必要であることや、OpenAIの障害時に正常に実行できないという課題がありました。
そこで、よりメンテナンスコストが低い状態で内製の開発支援ツールの運用が叶うツールへの代替を検討するに至りました。

選定理由

1. 比較した軸・比較する際に重要視していた点

　- 管理のしやすさ（クレデンシャル、コスト、ログなど）
　- セキュリティ（プロンプトデータが学習に再利用されないか）
　- LLMの精度（OpenAI APIと比較して明らかに精度が落ちないか）

2. 決め手となったポイント

　- 実行基盤をAWS上に構築しているので、権限やコスト管理をAWS内で完結させられる点
　- トラフィックがAWS内ネットワークで完結する点

導入の成果

クレデンシャル管理やコスト管理の課題が解決できた

導入に向けた社内への説明

よく使う機能

アーキテクチャ

アーキテクチャの意図・工夫

元々OpenAI APIで実装していた部分をBedrockに置き換えたものではありますが、下記のような処理を実行しています

• 日次で実行されるIndexerレイヤで、Github Issuesに起票された既知バグをIndex化してPineconeに格納
  
• Slackからの要求に応えるAppレイヤで、エラーメッセージからDatadogのエラーログを検索
  
• Pineconeに格納されている既知のバグリストから類似のものを検索してきて、Slackに返却
  
  工夫点は下記3点になります
  
• リソースはserverless frameworkで管理されたlambdaで実装することで、必要な時のみコストがかかる構成
  
• BedrockはLambdaでの実行とも相性が良く（権限をIAM Roleから付与できること、ログを一元管理できること）、今回の構成にもマッチしている
  
• RAGアプリケーション一般で課題になるIndexの更新は日次で実行されるLambdaで実現

ツールの良い点

ツールの課題点

ツールを検討されている方へ

• 選定するモデルに制約がなく（マルチモーダル必須等）、実行環境をAWSで完結させたい場合においては、初手での検討をお勧めします
  
• LLMはまだ進化が早く、モデル毎にできることや特性が大きく変わるので、Bedrockが対応しているモデルで要件を満たせるか、十分に検証してから運用するのが良いと思います