Architect でボットを構築するためのベスト プラクティスの推奨事項

ボットテクノロジーの概要

Genesys Dialog Engine Bot Flowsは、他の高度な機械学習ツールと同様に、複数の例から学習し、さらに定義して、これまでに見られなかった類似のケースを分類することで機能します。 ボットは、ルールからではなく、例から学習します。

このアプローチの長所は次のとおりです。

  • 入力言語の柔軟性と目に見えないデータ計算。 ボットは、以前の会話に基づいて推測を行います。
  • ボットの応答が応答でどの程度確実であるかを知るための統計的信頼スコア。
  • 優雅な劣化。これは合格または不合格のアプローチではなく、ノイズの多いデータの確実性が徐々に失われます。

機械学習のアプローチにはコストがかかります。 すべての入力に対して事前に決定された結果が得られない場合があります。 人工知能(AI)の意思決定は、直接のコマンドからではなく、独自の計算と結論に基づいています。 学習例は、エンジンを正しい答えに偏らせますが、常にそれを保証するわけではありません。

この記事では、モデルのバイアスシフト内で低リスクと高リスクのモデル変更の種類に関するガイダンスを提供します。 詳細については、以下を参照してください。 Architect ダイアログ エンジンのボット フローについて.

モデルを設計するときは、次のシステム機能を考慮してください。

  • 転送機能: 必要に応じて、音声、メッセージ、またはチャットのやり取りを受信するようにエージェントの可用性を設定します。
  • 内蔵機能:
    • 仮説を立てて、提案された意図を確認または否定して、不明瞭な発言を確認する。
    • 実行する前に、意図と必要な詳細のためにスロットを充填し、オプションでスロットの確認を行います。 組み込みのスロットには、日付、時刻、通貨、および数値が含まれます。
    • カスタムスロットタイプを使用すると、スロットタイプを定義し、それらを使用してスロットをマップできます。 アーキテクトは、次の3つのカスタムスロットタイプをサポートしています。
      • リスト タイプ
      • 動的リストタイプ
      • 正規表現(regex)タイプ
    • 次のようなフォローアップの質問をすることができます。
      • はい、質問はありません
      • スロットを埋める質問
    • オプションで、挨拶をフィルターできます。
    • 明確にするため、イベント処理の行動をレビューする。 たとえば、エラーイベント、認識失敗、エージェントエスカレーションなどです。

意図を定義する際には、以下のガイドラインを念頭に置いてください。

潜在的な意図に対するアクション項目を定義する

  • ボットにカバーさせたいアクションアイテムのリストを作成します。
  • これらのリクエストと対応する例がボットの適切な候補であるかどうかを評価します。
    • ケースは明確に定義されていますか?
    • 例は、ボットが学習のアンカーとして使用できる語彙を共有していますか?
    • 潜在的なリクエストの例は十分に異なりますか?
    • 十分に明確な例を提供できますか? ベストプラクティスでは、15〜30の例を推奨しています。
  • 既存のデータを確認し、実際のケースとリストを比較して判断します。
  • 定義に明確な境界線があり、重複していないことを確認します。
  • インテントの間にある例がある場合は、それらをどこに配置するかを決定し、それらに対応するためにインテント定義の境界を再描画します。
  • 最初に、より小さく、最も重要なインテントリストを準備します。 将来の反復では、うまく機能する概念実証モデルを拡張できます。

一貫したインテント命名パターンを使用する

  • プロンプト文内で機能するようにインテント名を設定する; 例えば、「[インテントネーム]に興味をお持ちだと思います。」
  • すべてのインテントがパターンに適合していることを確認してください。
  • 可能であれば短い名前を使用してください。 この点は、音声ボットにとって特に重要です。 長いインテント名を含む確認、曖昧性解消、およびプロンプトは、音声ではうまく機能しません。
  • 短い、しかし自然な言葉遣いで、即効的な文法に即応します。
  • ユースケースに基づいて、各目的についてデフォルトプロンプトとカスタムプロンプトのいずれかを選択します。
  • カスタム プロンプトとデフォルト プロンプトが簡潔であることを確認します。

インテントの例を提供するときは、次のベストプラクティスガイドラインを考慮してください。

  • 1つの意図につき、20~30例以上の典型的な例を提供する。
  • 以下のような意図のバリエーションを必ず提供してください。
    • 人々ができる質問や発言の形に、多様性を含める。
    • 目的を表すキーワードを追加します。
    • 短いフレーズと全文を追加します。
    • インテントのアクションの同義語を追加します。たとえば、ホテルを予約し、部屋を予約し、予約します。
    • 同じレキシコンを共有する複数のインテントがある場合は、両側で十分にバランスの取れた例を提供し、2つのインテントを区別するフレーズ例を優先するようにしてください。 例:  「医師にメッセージを残してください」と「医師に相談してください」。 同じ名詞の異なるアクションを区別する動詞を含めると、適切な学習に役立ちます。
  • 埋めるスロットがある場合は、次のことを確認します。
    • スロットおよびスロット タイプを定義します。
    • 複数の値と同義語を含めます。
    • インテントサンプルフレーズでエンティティをマークアップします。
    • 各スロットのデフォルトまたはカスタム プロンプトを選択します。
    • プロンプトで、組み込みのスロット形式の指示または例を入力します。

エンティティを定義するときは、次のガイドラインに留意してください。

  • インテントアクションを実行するため、またはカスタマージャーニーを通知するためにスロットを埋める情報のタイプを定義します。
  • 可能であれば、重複しないスロットクラスを作成し、次の質問をします。
    • この情報は、アクションの実行またはボットのルーティングに必要ですか?
    • この情報は保存され、カスタマージャーニーで使用されますか?
  • 次のように「はい」と答えた場合は、データに別の戦略を選択することを検討してください。
    • この情報を取得するのは難しいですか? 冗長すぎますか、ボットが顧客を正しい方向に導くのを妨げる可能性のある言い回しの選択肢が多すぎますか?
    • ボットがこのデータをキャプチャしない場合、インテント分類は失敗しますか?
  • 別の戦略は、不要なエンティティスロット、存在する場合にのみ選択され、プロンプトが表示されない場合、または別のインテントとしてキャプチャされる場合があります。
  • 予想できないスロット値の範囲が広い一般的なスロットは避けてください。
  • 方法や理由などのオープンな質問は避けてください。 代わりに、限られたオプションに顧客を誘導することに依存してください。
  • 情報収集のためのバイナリ質問を検討してください。たとえば、組み込みの「はい」または「いいえ」の質問を使用してスロットを要求します)。

エンティティの例を提供するときは、次のベストプラクティスガイドラインを考慮してください。

  • インテントトレーニングセットには、少なくとも2つの強調表示されたスロット値の例が必要です。
  • トレーニングセットにスロットの例がある場合は、すべてまたはほとんどのケース、特に一般的な値と同義語を強調するようにしてください。

必ず以下のプロンプトを作成してください。

  • 簡潔で明確である。
  • 潜在的なデフォルト意図またはスロット名挿入の文法にうまく適合します。

ボイスボットに必要なバリエーションと調整を検討します。

  • 意図: 数値形式を変更する必要はありません。 ただし、どの数値形式が音声からテキストへのコンポーネントで返されるかを確認し、その形式を意図して表示するようにしてください。
  • プロンプト: 音声プロンプトは、短く最小限の言葉で作成してください。 テキストメッセージとは異なり、再度確認することはできません。 ベストプラクティスでは、3語未満または3語未満で、繰り返しのない、簡単な短い音声プロンプトを推奨します。

このセクションでは、テストセットの推奨事項、音声ボットテストのガイドライン、およびテキストまたは音声ボットエンジンのテストについて説明します。

テストセットの推奨事項

機械学習に基づくボットは、例を追加し、トレーニングセットのバランスを取り直すことにより、テストと修正を複数回繰り返す必要があります。 ベストプラクティスでは、実際の顧客の発話から意図的なテストセットを作成し、それを反復ごとに再利用して改善を確認することをお勧めします。

最良の結果を得るには、シミュレートされた呼び出しによるエンドツーエンドのボットテストと、事前定義された一連のテスト例に基づくNLUのみのテストの両方が推奨されます。 意図的な頻度情報、またはどのケースがビジネスにとってより中心的またはより重要であるかについてのアイデアがある場合は、テストセットでそれらを適切に表現するようにしてください。

音声ボットのテスト

次のガイドラインは、自動音声認識がパフォーマンスに影響を与えるかどうかを判断するのに役立ちます。 テストプロセス中に、意図の例がさまざまな声と環境で表現されていることを確認してください。

  • 世代別レキシコンの違い
  • 地域方言自動音声認識(ASR)理解
  • 性別表現。 たとえば、ピッチが高い音声は音響範囲が狭く、ASRエンジンが理解しにくい場合があります)
  • 電話、トラフィックのある電話、バックグラウンドでのテレビのノイズなど、ノイズの多い環境テスト。

ボットエンジンのテスト(テキストまたは音声)

  • 目的ごとにバリエーションを使用します。 たとえば、「明日のための部屋が必要です。」または「明日の部屋を予約したい。」
  • 意図が不明な場合の試験。 例えば、境界の問題、意図のあいだの用語の重複、異なる詳細レベルで求められる意図などです。
  • 単一のキーワードまたは短いフレーズの発話を使用してモデルをテストします。
  • 意図(スロットあり/なし)を使用してモデルをテストします。
  • 一般的な言葉が強い偏見を生み出すかどうか確認します。 例えば、「なぜ」または「助けてくれる」という言葉は、別の意図よりも一つの意図を自動的に選択しますか? この場合、推奨される是正措置は、必要に応じて、それらの言葉を他の意図に追加することで、モデルのバランスを取ることです。
  • 共有キーワードが強いバイアスを生み出すかどうかを判断します。 例えば、銀行取引目的における「口座」です。 この場合、推奨される是正措置は、デフォルトを決定し、サブケースを強化することです。

テスト後の分析中に、改善の領域を確認し、モデルテストの成功率を評価し、学習パネルで作業します。

改善のためのレビュー

ボットをトレーニングしてテストした後、改善点を確認します。 インテント分類で信頼情報を使用して、問題を診断し、改善を導きます。

間違った意図が高い信頼性で仮定されている場合:

  • テスト例には、複数の意図を示唆する重要な単語がありますか?
  • インテントの境界を再定義したり、類似しすぎてモデルを混乱させたりするインテントの例をマージまたはクリーンアップする必要がありますか?

間違った意図が低い信頼度で仮定されている場合:

  • この例は「典型的な」ものですか? この記事で前述したガイドラインに従ってください。
  • 例は「限界」ですか? 最初に中心的な例に焦点を当てます。 これらの例を修正した後、意図的な例を使用して境界のケースに対処できます。

中心的な意図の例の信頼度が確認のしきい値を下回っている場合:

  • インテントの定義と関連または類似のインテントを表示します。 定義と語彙の重複が大きすぎませんか? あまりにも類似しているインテント間に潜在的な合併はありますか? 「競合する意図」の例をいくつか削除する必要がありますか?
  • 例は「限界」ですか? インテント定義に存在する例が少ない場合、または他のインテントが同様のケースを共有している場合は、信頼性が低くなることが予想されます。
  • 前のポイントが当てはまらない場合は、確認のしきい値を下方に調整できます。

モデルのテストの全体的な成功を評価する

  • テストケースに対する意図の関連性を評価し、中心的なケースが欠落していないかどうかを調整します。
  • 迷子のコンテンツではなく、キーフレーズに注意を向けてください。 実際のデータを使用する場合は、文の文言を最小限に抑えるなど、テストに関連する変更を加えるかどうかを検討してください。
  • より多くのトレーニング例を含めるかどうかを検討してください。たとえば、構文のバリエーションや同義語。
  • 意図のバランスを取り、共通のフレーズや共有キーワードに既存のバイアスがなくなるようにします。 意図の解消を妨げる強い偏見が例に含まれている場合は、それを取り除きます。

学習パネルを操作する

学習パネルは、モデルの改善に役立つように設計されています。 インテント分類を使用した実際のユースケースを確認し、分類を修正できます。 ただし、モデルは十分にトレーニングされ、バランスが取れている場合に最高のパフォーマンスを発揮することを忘れないでください。 学習パネルのすべてをモデルトレーニングセットに追加しようとする試みに抵抗します。 このステップは、共通の意図に偏る可能性があり、モデルの学習を曇らせるジャンク文を提供する可能性があります。

誤って分類された、または分類の信頼性が低い、中心的で顕著なケースをモデルに追加するのが最善です。

機械学習の統計的性質は、最も一般的なケースの99%をうまくカバーしようとすることを意味します。 あまり一般的ではないケースであるほど、それはカバーされておらず、学習を欠いている可能性が高くなります。 絶対にすべてのケースをモデルに追加しようとすると、最も中心的なケースのパフォーマンスが低下し、ユースケースの全体的なビジネスの成功も低下します。