- Benchling は複数のリージョンと環境でクラウドインフラを運用している。
- Terraform Cloud で 16 万個以上のリソースを管理しており、1か月あたり約 50 人のエンジニアがインフラ変更をリリースしている。
- 20 ページ分の膨大な FAQ ドキュメントと Slack スレッド履歴があるが、「検索の非効率性」が問題だった。
- これを解決するため、RAG LLM を活用した Slackbot を構築した。
構築目標
- Terraform Cloud 関連の質問をリアルタイムで解決する社内 Slackbotの開発。
- 社内外のデータソースを結合し、ユーザーに使いやすい Slack インターフェースを通じて回答を提供。
- 活用可能なケース:
- HR 質問への回答
- 顧客の問題解決事例の検索
- ソフトウェアエラーコードの説明
動作原理
- ユーザークエリ分析: データベースから関連情報を検索。
- LLM プロンプト構成: 検索結果とガイドラインを含めて回答を生成。
技術スタック
- RAG モデル: Amazon Bedrock を使用。
- OpenSearch Serverless データベースで構成された知識ベースを設定。
- Claude 3.5 Sonnet v2 モデルで回答を生成。
データソース
- Confluence: Terraform Cloud FAQ（PDF として保存後、S3 にアップロード）。
- Web: HashiCorp の Terraform Cloud と言語ドキュメント。
- Slack: 解決済みの Terraform Cloud のイシューを含むスレッド（POC は手作業で収集）。
- データはベクトルデータベースに保存され、クエリ時に検索可能。
実装アーキテクチャ
- 構成要素:
- Slack アプリ
- AWS API Gateway
- AWS Lambda（Python を使用）
- AWS Bedrock
- OpenSearch Serverless（ベクトルデータベース）
- モデル利用:
- Amazon Titan Text Embeddings v2（埋め込み生成）
- Claude 3.5 Sonnet v2（回答生成）
制約事項と今後の改善点
制約事項
- 画像処理不可: 画像ベースのアーキテクチャ図やスクリーンショットは含まれない。
- Terraform のサポート不足: 現在、Terraform AWS Provider は Bedrock リソースをサポートしていない。
今後の改善点
- 参照リンクの追加: Slack の返信にドキュメントの出典を含める。
- Slack スレッドの自動保存: 「@help-terraform-cloud remember」コマンドでデータベース更新。
- データ同期の自動化: CloudWatch イベントを使用して週次同期。
- Confluence API の活用: 現在の手動 PDF アップロードを API 連携へ移行。
- マルチターン対話のサポート: ユーザーとの継続的な会話コンテキスト維持。
構築過程で得た知見
- データチャンク戦略:
- 当初 300 トークン（約1段落）サイズを使用したが、長い回答が途切れないよう 1500 トークン（約5段落）へ調整。
- PDF パースの効率:
- 画像を除けば、テキストベースのデータは安定して抽出できた。
- ナレッジベース構築の容易さ:
- Amazon Bedrock を活用すると、数分で構築可能。
ユースケース
- FAQ およびエラーコード の参照。
- 反復的な質問の自動応答。
- チーム別のカスタムデータセット活用:
セキュリティ上の考慮
- データ機密性と不正確な結果のリスクを評価。
- 組織で承認されたモデルを確認。
結論
- LLM を活用した Slackbot は迅速なプロトタイプ開発の可能性を実証した。
- 新しい技術実験を通じて、効率性と生産性の向上が見込まれる。
- この事例を基に、皆さんも LLM ベースのツールを構築してみてください！
まだコメントはありません。