カスタマーサポートチャットボット

背景

ある SaaS 企業が、カスタマーサポートのチャットを自動化したいと考えています。 現在はサポートチームがすべての会話に応答しており、チケットシステムには何年分もの解決済みチケットが蓄積されています。 ボットは会社の名前で顧客に話すことになるため、悪い回答は 1 件の会話にとどまらない損害を与えます。顧客はサポート全体への信頼を失うからです。

このリスクがあるため、いきなり顧客向けにリリースする選択肢はありません。 代わりに、3 つのフェーズに分けて展開し、それぞれのフェーズで次に進むための確信を積み上げます。

この段階的なアプローチによって、多くのリスクを抑えながら、本番のシグナルを早い段階で得られます。

フェーズ 1: 最初のエージェントを作る

サポートチームに社内向けエージェントを実際に使ってもらうには、最初のバージョンの時点で彼らにとって有用である必要があります。 そこに到達するために、すでに手元にある解決済みチケットの豊富な過去データを活用できます。合成データの生成は不要です。

サポートチケットシステムの過去データにどんなパターンがあるかを AI で把握し、繰り返し現れる挙動ごとにいくつかのデータセットへまとめられます。

ここから、各バージョンをこれらのデータセットに対して実行しながら プロンプトを反復し、サポートチームが実際に有用だと感じる水準に下書きが届くまで進めます。 各実行は次の方法で採点します。

ここでトーンを自動で判定していないことに注目してください。 これは意図的です。下書きの語り口が許容範囲かどうかは、いくつかの 手動チェック で十分確認でき、トーンを完全に合わせ込むのはフェーズ 2 で行うからです。

評価器のスコアが十分に良く、手動レビューの結果も良ければ、エージェントをサポートチケットシステムに載せます。

次のセクションに進む前に、このときのトレースがどう見えるかを示します。

フェーズ 2: 社内展開

このフェーズでは、届いたチケットごとにエージェントが返信を下書きし、サポートチームのメンバーがそれを使い、送信前に編集できます。 エージェントの下書きと、メンバーが実際に送信した内容の差分は、非常に信頼できる ユーザーシグナル として使えます。

もう 1 つ、より明示的なユーザーシグナルとして、下書きに対する良い・悪いのボタンがあります。チームはそこに書き込みのフィードバックを残すこともできます。

どちらのシグナルも、下書きの トレース に スコア として記録されます。

スコアの悪いトレースは、その後に確認し、改善し、まだカバーされていなければデータセットに追加できます。 その進め方の 1 つが エラー分析 のプロセスです。

ループを 1 周する例はこうなります。 モニタリング で、troubleshooting カテゴリの corrected 下書きが急増していることが見えます。 トレースを見ると、ヘルプ記事のインデックスが古いために、エージェントが古いエクスポートダイアログを参照し続けていると分かります。 インデックスを更新し、troubleshooting データセットを回し直して修正を確認すると、corrected 下書きの割合が下がります。 ここから新しい評価器は生まれません。インデックスが古いことは 一度きりの修正 であって、追跡し続ける失敗モードではないからです。

編集される下書きの割合は、時間とともに下がっていくはずです。 すべてのチケットカテゴリで下書きがほぼ手を入れられずに送られるようになれば、エージェントは顧客に向き合う準備ができています。

フェーズ 3: 顧客向けの展開

ボットが顧客に直接応答するようになると、フェーズ 2 を駆動していたシグナルは消えます。顧客が見る前に誰も返信を編集しないからです。 代わりに、学習と改善を続けるための暗黙的なユーザーシグナルをいくつか導入します。

顧客がサポートチャットを評価してくれることはまれなので、主眼は暗黙的なユーザーシグナルを集めることに置きます。

人手がループから外れたので、評判を損ないうる挙動がないかをすべての返信について監視します。 この 2 つの評価器は、観測された失敗ではなく 絶対条件 から来ています。どちらも一度も検知したことがありませんが、初日から存在します。 これらは何かをブロックするものではありません。送信済みの返信に印を付け、チームが顧客へすばやくフォローアップできるようにするものです。

これらのシグナルがそろえば、エージェントを継続的に改善する良い体制になります。 良くなかった会話が表に出て、改善され、データセットアイテムになり、構造的にテストできるようになります。 チームはこの体制を使って、より新しい/安い/速いモデルを安全に試し、デプロイするかどうかを根拠を持って判断することもできます。

まとめ

顧客に直接向き合う自動化は、リスクの高さゆえに立ち上がらないことがよくあります。 この例は、それを現実的に実現するためのベストプラクティスを、継続的な学習と改善を前提に整理したものです。

他の例 や Academy も参照してみてください。