Oracle Cloud Infrastructureドキュメント

会話の設計ですべきこととしなくてよいこと

スキルをうまく機能させるための堅牢なインテント・セットを作成するには、十分な注意が必要です。次に、注意が必要なベスト・プラクティスを示します。

インテントの設計とトレーニング

やるべきこと しない
期待する結果が得られるまで発話を追加するように計画します。一般に、追加する質の高いトレーニング発話が多いほどモデルのパフォーマンスは向上します。必要な発話の数は、モデル、トレーニング・データおよびモデルにとって現実的な精度に応じて異なります。 個々のインテントを過剰にトレーニングしないようにします。インテントを完璧に機能させるために過剰なトレーニング・データを追加することはやめてください。インテント解決が期待したとおりに動作しない場合は、インテント構造にインテントの重複がないかを評価します。インテント解決は決して100%正確にはなりません。
実際のデータを使用します。スキルが遭遇する可能性の最も高い実際の言語を使用することが重要です。創作された発話のみではできることに限界があり、スキルを実際にうまく機能するように準備できません。 トレーニング・データでキーワードのみを使用しないようにします。トレーニングに単一の語句や短いフレーズを使用することは可能ですが、トレーニング・データはユーザーの入力と同じ構造にする必要があります。発話に含まれる単語が少ないほど、分類に失敗しやすくなります。
完全な文全体を使用してインテントをトレーニングします。短いトレーニング発話を使用しても問題ありませんが、ユーザーの会話形式にできるかぎり近づけるようにしてください。 インテントが不注意に偏らないようにします。具体的な意味を加えない単語(たとえば、「どうぞ」、「よろしく」)や発話内のエンティティ値は、あるインテントでは頻繁に使用され別のインテントでは使用されていない場合に、インテント解決が不注意に偏ってしまう可能性があるため、注意してください。
インテントごとに同程度の数の発話を使用します。インテント(たとえば、「こんにちは」、「さようなら」)によっては、トレーニング・セット内の発話が少ないことがあります。しかし、モデルにバイアスがかかることを避けるため、主要なインテントには同程度の数の発話を用意するようにしてください。 インテント解決のみに依存しないようにします。エンティティを使用して共通インテントのあいまい性を解消します。インテント間で言葉の重複がある場合は、エンティティを使用してユーザーの意図(および対応する一意の会話パス)のあいまい性を解消することを検討してください。
世間話を処理します。ユーザーが冗談や天気予報などスキルの目的に関連しないリクエストをすることがあります。また、スキルが人間であるかどうかを尋ねるようなこともします。世間話対策を用意し、さらに、会話フローのすべてのステップでスキルがどのように応答するかを積極的にテストするようにします。 unresolvedIntentを過剰に使用しないでください。(今後そのスキルで可能にするかどうかが)不明なことがわかっている事柄については、スコープ外インテントを作成します。
単一の使用例に対し複数のインテントを検討します。顧客は同じ要求を複数の言い方で表すことができます。たとえば、彼らが求める解決法と言ったり、彼らの問題の症状と言うことができます。すべてが同じ「回答」に解決される複数のインテントを使用します。 口汚いやり取りを無視しないようにします。世間話と同様に、口汚い言葉に対する計画を立てておきます。この計画には、即時エスカレーションの準備のみでなく、ユーザーから入力された口汚い言葉をスキルがそのまま返さないようにするための手段を含める必要があります。

会話ユーザー・エクスペリエンス

やるべきこと しない
最も可能性が高いレスポンスを示唆します(ヘルプおよび終了を含む)。たとえば、「こんにちは、ボットのBobです。X、YまたはZについてお尋ねください。問題が発生した場合は、「ヘルプ」と入力してください。」 会話の設計をプロジェクトの後半まで遅らせないようにします。最も単純なスキルを除くすべてのスキルについて、会話の設計に他の開発作業と同じ優先度および緊急度を与える必要があります。これは、早期に開始し、他のタスクと並行して進める必要があります。
ボットのパーソナリティを考慮します。ボットのパーソナリティと口調を考慮する必要があります。ただし、人間のような対話をしすぎないように注意し(ボットのユーモアや思いやりはうまく伝わらないことが多い)、ユーザーに人とやり取りしていると思い込ませないようにしてください。 スキルが「学習中」であることを伝えないようにします。よかれと思ってしたことでも、このよからぬ習慣は、スキルがまだタスクを実行できる状態になっていないことを(意識的にせよ無意識にせよ)ユーザーに知らせてしまいます。
想定される内容に基づいてユーザーを誘導します。スキルでユーザーを適切なレスポンスに誘導し、質問を自由回答形式のままにしないようにします。自由回答形式の質問にすると、ユーザーがハッピー・パスから外れる可能性が高くなります。 気の利いたレスポンスや場つなぎ的なレスポンスを使用しないようにします。想定される内容に基づいてユーザーを誘導しますを参照してください。
長いレスポンスは個別のチャット・バブルに分割したり、改行を使用するようにします。視覚的に区切りのない大きなテキストのかたまりは読みにくく、混乱を招く可能性があります。 「すみません、わかりません。質問を言い換えてください」と言わないようにします。このような怠惰なエラー処理アプローチは、大抵の場合間違っています。ユーザーがスコープ外の質問を何度言い換えても、スキルが何か知的なことを言うことはありません。
-- 確認フレーズを使いすぎないようにします。確認フレーズにはこれを使用すべき場所というものがあります。ただし、過度に使用しないでください。ユーザーに確認を求める前に、信頼度レベルを考慮できるダイアログ・フローを検討します。

テスト戦略

やるべきこと しない
発話を循環的に開発します。堅牢なトレーニング・コーパスの開発には、何回もの反復とテスト・サイクルおよび継続的なモニタリングとチューニングが必要です。「作成、テスト、デプロイ、モニター、更新」の循環アプローチを使用してください。 パフォーマンス測定および改善計画の必要性を無視しないようにします。スキルを測定して改善するための計画がないと、実際に機能しているかどうかを知るすべがありません。
80/20ルールを使用して発話をテストします。常に複数の80/20テストを実施して、インテントの堅牢性を相互にテストします。このテストでは、新たに収集された発話の80%をモデルのトレーニングに使用し、20%をテスト・データに追加します。 ハッピー・パスのみをテストしないようにします。「適切に動作させること」は作業の20%に相当します。残りの80%は、不正確な入力およびユーザー・アクションにスキルがどのように応答するかをテストして調整することです。
スキルの失敗をテストします。積極的にスキルに失敗させ、どうなるかを確認します。自信のあるテストのみに頼らないようにしてください。 順不同のメッセージの処理を無視しないようにします。ユーザーは会話履歴をスクロール・バックして、前に表示されたボタンをクリックすることがあります。結果のテストは、(ハッピー・パスのみをテストしないようにしますに示すように) 80%の作業に含める必要があります。
-- インテントを更新したら再テストすることを忘れないようにします。トレーニング・データをさらに追加する場合(たとえば、より実際に近い使用方法をボットが取得するとき)や、新しい使用例のために新しいインテントを追加する場合は、モデルを再テストすることを忘れないでください。

プロジェクトに関する考慮事項

やるべきこと しない
会話UI (CUI)によって拡張される使用例を選択します。(スキルおよびデジタル・アシスタントを介して)会話UIを有効化することには労力が必要です。CUIを追加して使用例が本当に拡張されることを確認してください。 エスカレーション・パスを忘れずに用意します。人間へのエスカレーションを可能にすることを予定していない場合でも、スキルが役立たないやり取りの際の戦略が必要です。
初日は最悪の日であることを予想しておきます。最適にテストされたスキルおよびデジタル・アシスタントであっても、1日目にはチューニングが必要です。 開始後すぐにプロジェクト・チームを解散しないようにします。スキル・プロジェクトのスケジュールを立てる際には、十分なチューニングおよび最終的に知識の伝達に十分な期間が過ぎるまで、スキルの作成者(会話デザイナ、プロジェクト・マネージャ、技術リーダーなど)をプロジェクトに留めるようにしてください。