概要
今回はDifyのチャットフローを使って、弊社プロダクトのヘルプセンターサイトにチャットボットを搭載した際の話を紹介します。
背景
背景については、弊社プロダクトサポートが書いてくれた記事を参照いただきたいのですが、簡潔に説明すると、ヘルプセンターサイトにはお客様の課題を解決できる豊富な記事があるものの、記事を見つけるのが難しいという課題があり、チャットボットで解消できないかという話から、このプロジェクトは始まりました。
何でチャットボットを実装するか
最初に何を使ってチャットボットを実装するかを検討しました。
プロダクトに搭載するものではなく、ヘルプセンターサイトに実装するもののため、できる限り自前でコードを書かずに実装できるメンテコストが低いものが良いだろうという観点で実装アプローチを探していたところ、ちょうどその頃に弊社でDifyを社内で利用し始めたこともあって、Difyを使ってみようという話になりました。
SaaS版 vs OSS版
運用負荷も最小限に抑えるため、最初はSaas版のDifyを検討しました。
しかし、ナレッジのドキュメント数の制限が非常に厳しく、検討当時の最上位プランでもドキュメント数の上限が1000でした。弊社のヘルプセンターサイトの記事は2000程度あったため、必然的にOSS版を選ばざるを得ませんでした。
OSS版を採用することになりましたが、構築の手間もなるべく減らそうということで、Difyをまるっと構築できるTerraformのコードを探しました。運用負荷を減らすために可能な限りマネージドサービスをフル活用したものを条件にして探したところ、DeNA社がDifyのTerraformのコードを公開してくださっていたため、こちらを利用させていただくことになりました。（DeNA社には感謝申し上げます。）
一点注意点としては、こちらのコードでDify環境を構築する場合、弊社の場合ですと約12万円/月ほどかかっていますので、決して安価で構築できるわけではありません。具体的には、Filestoreのコストが高いです。そのため、予算と相談しながら実装していただければと思います。
個人的には、コストをかけてでもなるべくマネージドサービスをフル活用して運用負荷を減らすのであれば、簡単にDify環境も構築できるので、とても良い選択肢だと思います。
ナレッジへのデータ挿入
チャットフローの処理を組んでいく前に、ナレッジへデータを挿入する必要があります。
弊社のヘルプセンターサイトはZendeskで稼働させているため、Zendeskから記事を全て取得し、Difyのナレッジにドキュメントを挿入するCloud Functionを用意しました。毎日定期的にCloud Functionを動かして、継続的にデータをナレッジに挿入しています。
全てのヘルプセンターの記事がチャットボットの回答で必要なわけではありませんので、Difyのナレッジに挿入する記事のカテゴリーと、挿入しない記事のカテゴリーを分けておく必要があります。不要な記事をナレッジに挿入しないことで、検索精度にも良い影響があります。
チャットフローの処理の組み方
ここからはDifyのチャットフローで、チャットボット機能の組み方についてお話ししていきます。
条件分岐
まずは条件分岐です。
- 会話の上限数に達した場合
- 会話の上限に達した旨のメッセージを回答して、会話のリセットを促します。
- 解決した場合
- 他に質問があるかを質問します。
- 解決しなかった場合
- サポートに問い合わせるか質問します。
- サポートに問い合わせる場合
- 上記の質問でサポートに問い合わせるか質問をして、サポートに問い合わせるとユーザーが回答した場合に、サポートへの問い合わせリンクを回答します。
- その他
- ここからがメインの処理です。
メインの処理
まずは会話変数が空かどうかによって分岐します。会話変数とは、対話状況を保存・管理するためのDifyの機能です。過去の会話履歴を保存しておくために利用します。
会話変数が空の場合には、初回質問の処理に入ります。知識取得を使ってナレッジを検索します。検索結果が空の場合には、検索にヒットするものがなかった旨、回答します。
もし検索にヒットするものがあった場合には、LLMに参考情報として検索結果を渡して、質問に回答をさせます。
最後に会話変数に質問と回答の履歴を挿入しておきます。
追加質問の場合も上記の流れと基本的には同じですが、ナレッジを検索する前に過去の会話履歴と追加質問から最適な検索クエリを生成する処理を行なって、追加質問用に最適化された検索クエリでナレッジを検索する処理を入れる必要があります。
Tips: 会話に往復上限を設けるべきか
結論からお伝えすると、会話の往復上限は設けるべきだと思います。
同じセッションで何十往復も会話をしてくると、追加質問と無関係な会話が入りやすく、過去の会話履歴と追加質問から最適な検索クエリを生成することができず、追加質問とマッチしたドキュメントがヒットしにくくなります。
そのため、一つのセッションで行う会話の往復には上限を設けて、新しいセッションで会話を始めていただく方が検索精度は良くなります。
見た目を整える
チャットフローの処理の流れができた後は、チャットフローを埋め込む際のアイコンやタイトル、色、言語の設定を行って、最後にヘルプセンターに埋め込みを行いました。
なお、チャットのダイアログを閉じる際の閉じるボタンを分かりやすくしたり、またスクロールした時に追従させるために一部コードは自前で追記しました。それでも、一から自前で実装するよりはメンテコストは低く抑えられると思います。
Difyの弱点
ここまでチャットフローの組み方について説明してきましたが、Difyのチャットフローにも弱点があります。
実装当時の時点では、回答の参考情報のドキュメントにリンクを付与することができず、回答の参考情報からヘルプセンター上の記事に飛ぶことができませんでした。ここは今後のアップデートで対応されることを願っています。
まとめ
今回はDifyのチャットフローを使って、ヘルプセンターにチャットボット機能を搭載した話を紹介しました。短期間でチャットボット機能を導入できるため、もしチャットボット機能を自社が運営するサイトに搭載したい場合には、Difyは良い選択肢の一つだと思います。
Discussion