はじめに
e-dash でバックエンドエンジニアをしている ikeda です。
こちらはe-dash advent calendar 2024の 18 日目の記事にあたります。
前回の記事では、社内のナレッジを探す時間を減らすためのRAGを活用したSlack Botの構築方法を紹介しました。（DifyとAWSで作る！RAGを活用したSlack Botの構築ガイド）
今回は、このRAGをバージョンアップした内容についてお話しします。以下の3点にフォーカスして解説します。
- DifyをAWSサーバにデプロイした経緯と手法
- 回答の信頼性を向上させるために講じた工夫
- RAGを導入した目的に対する現状の評価
最後に、今後の展望にも触れていきます。
DifyをAWSサーバにデプロイ
前回の記事では、Difyのクラウド版を使用しましたが、今回はAWSのEC2上にセルフホスティングする構成を採用しました。
セルフホスティングを選んだ理由
Difyのクラウド版は簡便で便利ですが、以下のような制限や要件がありました。
- ユーザー数やストレージ容量に制限がある。
- 自社のセキュリティ要件を満たすための柔軟なカスタマイズをしたい。
これに対し、セルフホスティングは初期コストや運用負担が発生しますが、長期的にはコスト削減や柔軟性の向上が期待できます。また、機密情報を扱う環境ではセキュリティ要件を満たすことが最優先です。
構成概要
以下の構成でDifyをAWSにデプロイしました。
- プライベートサブネットに配置したEC2インスタンス: 機密情報の安全性を確保。
- ALB (Application Load Balancer): HTTPS通信を終端し、内部通信をHTTPで処理。
- NAT Gateway: EC2インスタンスが必要なAPI通信やダウンロードを可能に。
- スケジュール機能: Bot利用時間に合わせてEC2インスタンスの起動・停止を自動化。
セキュリティ対策として、SSL/TLSを用いた暗号化通信を採用し、データの盗聴や改ざんリスクを低減しました。
また、Slack Botの挙動としては以下のように設定しました。
- SlackメッセージをAPI Gateway経由で受信。
- Lambda関数を利用して質問に対する回答を生成し、Slackのメッセージに返信。
回答の信頼性を高めるための工夫
ナレッジの作り込み
Slackのチャット履歴および社内情報を蓄積しているNotionのページをナレッジソースとして活用しました。Slack APIやNotion APIを用いて、以下の工夫を行いました。
- 指定チャンネルやページからデータを取得し、Difyに登録。
- メッセージやページのURLを保存し、回答時に参照可能に。
なお、Notionの連携機能ではURLが保持されないため、Notion APIを自身で実行してデータ取得する方法で対応しました。
Embedding
RAGではデータをチャンクと呼ばれる情報ブロックに分け、ベクトル形式で保管します。チャンクの設定値が小さいと文章が細切れに保存され、適切な情報を取得できないことがあるため、Embeddingの際に、チャンクの設定を以下のように調整しました。
- 大きめのチャンクを設定して関連性の高い情報を取得可能に。
- .envファイルの
INDEXING_MAX_SEGMENTATION_TOKENS_LENGTHを変更し、再度ビルド（今回は5,000を試しました。）
これにより、細切れのデータによる検索結果の質の低下を防ぎました。
プロンプトの設定
生成AIのハルシネーションを抑えるため、以下の施策を講じました。
- 回答に参考情報の出典を必ず含める。これにより、SlackのメッセージやNotionのページを参照することができ、質問者が得たい情報を確認するためのサポートができるようにした。
- ナレッジ検索結果に閾値を設定し、関連性が低い結果を排除することで、誤った回答を行うことを低減した。
- 有用なナレッジが検索されなかった場合は無理に回答させず、"わからない"と明確に回答するように指示しておくことで、誤った回答を避けるようにした。
これらにより、回答の信頼性を高めるとともに、利用者が回答の妥当性を確認できるようにしました。
今後の展望
- GraphRAGの検討: 現状のチャンク単位の検索を改善し、分散した情報を結びつけられる仕組みを模索。
- 定量評価の導入: チャンクサイズや検索閾値が回答精度に与える影響を定量的に評価し、最適化。
- テストの自動化: パラメータ調整時のテスト負担を軽減し、効率的な改善を目指す。
- ナレッジの自動更新: APIやスクリプトを活用して最新情報を自動でナレッジに反映。
- マルチモーダルに対応: テキスト以外の情報源を組み込み、より多様な情報源からの検索を可能に。
ここでは、一部を紹介しましたが、検討事項はもっともっとたくさんあります。言語モデルの選択、プロンプトの設定、ナレッジの作成、文書検索アルゴリズム、不適切な入出力の制御など、検討すべきパラメータは多岐にわたります。
一つ一つ丁寧に検討し、改善を重ねていくことで、より高度なナレッジ検索を実現していきたいと考えています。
RAGを作る動機に対して目的は達成されたのか？
RAGを活用したSlack Botの導入目的は、ナレッジ検索時間の短縮でした。残念ながら、現状では目的を達成できたとは言えず、以下の課題があります。
- ナレッジの蓄積がまだ十分ではない。
- 回答精度が不十分で、期待通りの結果が得られない。
これらの課題解決には、継続的なナレッジの作り込みと精度向上が必要です。ただし、徐々に目的に近づいている手応えはあるため、引き続き改善に取り組みたいと思います。
おわりに
この取り組みを社内のエンジニアチーム以外のグループにも紹介した結果、Slack Botの運用が開始されました。自分のために始めたプロジェクトが会社全体の生産性向上に貢献しつつあることに、大きなやりがいを感じています。
使っていただいたフィードバックをいただいており、それを元に今後もさらなる改善を重ね、より多くの課題解決に貢献できるよう努力していきます。
Discussion