適切なエラー回復を提供する
[Microsoft エージェントは Windows 7 の時点で非推奨となり、以降のバージョンの Windows では使用できない場合があります。]
適切に設計されたインターフェイスと同様に、対話型プロセスでは、エラーにつながる状況を最小限に抑える必要があります。 ただし、すべてのエラーを排除することはめったにないため、ユーザーの信頼と関心を維持するために、適切なエラー回復をサポートすることが不可欠です。 一般に、エラーの回復には、エラーの検出、原因の特定、エラーを解決する方法の定義が含まれます。 ユーザーは、タスクを実行するためにユーザーと連携する、協調的なインターフェイスに対してより適切に応答します。
音声エラーの回復の最初の手順は、エラー状態を検出することです。 音声認識は、さまざまなエラーが原因で失敗する可能性があります。 エラー状態は、通常、無効な入力、明示的なユーザー修正またはキャンセル、またはユーザーの繰り返しの結果として検出されます。
拒否エラーは、認識エンジンがユーザーの言ったことと一致しない場合に発生します。 バックグラウンド ノイズや早期開始も認識エラーの一般的な原因であるため、ユーザーにコマンドを繰り返すように求めることは、多くの場合、最初の解決策として適しています。 ただし、フレーズが現在のアクティブな文法の外側にある場合は、ユーザーに要求の言い換えを求めることによって問題が解決する可能性があります。 文言の違いにより、現在の文法の内容と一致する場合があります。 適切な予想される入力オプションを一覧表示または提案することも別の方法です。
拒否エラーの回復に適した戦略は、これらの手法を組み合わせてユーザーを追跡し直し、障害が解決しない場合にますます多くの支援を提供することです。 たとえば、最初の障害に対して、"Huh?" や "What?" などの尋問、または手から耳へのジェスチャを使用して応答できます。 応答が短いと、ユーザーの繰り返しステートメントが失敗しない可能性が高くなります。これは、ユーザーの話し方が早すぎるためです。 失敗が繰り返されると、後続の言い換え要求によって、特定の文法内で何かを照合する可能性が向上します。 ここから、受け入れられたコマンドの明示的なプロンプトを指定すると、一致する可能性がさらに高くなります。 この手法を次の例に示します。
ユーザー: アンチョビが入ったシカゴ風のピザが好きです。
文字: (耳に手) Huh?
ユーザー: アンチョビが入ったシカゴのピザが欲しい。
キャラクター:(頭振り)ご要望を言い換えてください。
ユーザー: 私はアンチョビとシカゴピザを言った。
文字: (シュラッグ) 申し訳ございません。 あなたが望むピザのスタイルを教えてください。
ユーザー: シカゴ(アンチョビあり)。
キャラクター:まだ運がない。 "シカゴ"、"ハワイ"、または "コンボ" と言うことができます。
エラー処理がより自然に感じるようにするには、エラーに応答するときにランダムなバリエーションの程度を指定してください。 さらに、応答を繰り返す要求に対する自然なユーザーの反応は、ステートメントを繰り返すときにボリュームを誇張または増加することです。 誇張や音量の増加により、音声エンジンが単語を認識しにくくなることがありますので、ユーザーに通常かつ明確に話すように通知すると便利な場合があります。
プログレッシブアシスタンスは、ユーザーの注意にエラーをもたらす以上のことを行う必要があります。より有益なメッセージを継続的に提供することで、現在の文法で話すようにユーザーを導く必要があります。 理解しようとしているように見えるインターフェイスは、ユーザーからの高い満足度と許容度を促進します。
音声エンジンが入力を認識し、間違ったコマンドと一致する置換エラーは、音声エンジンが一致する発話を検出するため、解決が困難です。 不一致は、音声エンジンが不要なサウンドを有効な入力 ( 挿入エラーとも呼ばれます) として解釈する場合にも発生する可能性があります。 このような状況では、エラー状態を特定するためにユーザーの支援が必要です。 これを行うには、音声エンジンから返された内容を繰り返し、続行する前にユーザーに確認を求めることができます。
ユーザー: シカゴスタイルのピザが必要です。
キャラクター: 「シカゴ風のピザ」が好きだと言いましたか?
ユーザー: はい。
キャラクター:あなたはそれにどんな追加成分が好きですか?
ユーザー: Anchovies。
文字: "anchovies" と言いましたか?
ユーザー: はい。
ただし、すべての発話に対してこの手法を使用すると、非効率的で面倒になります。 これを処理するには、重大な悪影響を及ぼす状況に確認を制限するか、即時タスクの複雑さを増やします。 ユーザーが簡単に変更を加えたり、元に戻したりできる場合は、選択の確認を要求しないようにすることができます。 同様に、選択を表示する場合は、明示的な修正を行う必要がない場合があります。 たとえば、リストからアイテムを選択しても、ユーザーが結果を表示して簡単に変更できるため、検証が必要ない場合があります。 信頼度スコアと代替スコアを使用して、確認のしきい値を指定することもできます。 しきい値を調整する場合は、特定の状況でユーザーのアクションの履歴を保持し、一貫したユーザー確認に基づいて検証を排除します。 最後に、インターフェイスのマルチモーダルの性質を考慮します。 マウスまたはキーボードからの確認も適切な場合があります。
確認の文言を慎重に選択します。 たとえば、「言いましたか...」や「言ったと思います...」などです。前の語句は、ユーザーが誤って話した可能性があるのではなく、文字のリスニング (認識) の精度が照会されていることを意味するため、"本当にしたいですか...?" よりも優れています。
また、応答の文法も検討してください。 たとえば、否定応答では拒否エラーが発生する可能性が高く、次の例に示すように追加のプロンプトが必要です。
ユーザー: ペパロニが必要です。
キャラクター:あなたは「ハムなし」と言いましたか?
ユーザー: いいえ、私はペパロニと言いました。
文字: Huh?
ユーザー: Pepperoni。
自然な応答のバリエーションを処理するようにプレフィックスを含むように文法を変更すると、特にユーザーが検証プロンプトを確認しない場合に、回復プロセスの効率が向上します。 この例では、"no I said pepperoni"、"I said pepperoni"、および "no pepperoni" も含めることで、"pepperoni" の文法を変更することで、確認を 1 つの手順で処理できました。
音声エンジンから返された代替一致を修正確認として使用して、置換エラーを処理することもできます。
ユーザー: ペパロニが必要です。
キャラクター: (最適な一致として 「ハムなし」、最初の代替手段として 「ペパロニ」と読み上げられます)「ハムなし」と言いましたか?
ユーザー: いいえ、ペパロニ。
キャラクター:(それでも最高のマッチとして「ハムなし」と聞こえますが、今では最初の代替手段を提供しています)"Pepperoni"?
同様に、一般的な置換エラーの履歴を保持できます。特定のエラーが頻繁に発生する場合は、最初に代替を提供します。
認識エラーが発生した場合は、ユーザーを非難しないようにしてください。 文字がユーザーを非難することを示唆したり、意味を示したりした場合や、その文字がエラーに対して無関心と思われる場合、ユーザーは気分を害する可能性があります。 ここでも、責任を明示的に受け入れ、状況に適した言葉を慎重に選択し、多様性を使用してより自然な応答を作成します。 お詫びを述べるときは、ユーザーを非難していると解釈される可能性のある "oops" や "uh-oh" などのあいまいな単語を避けてください。 代わりに、"申し訳ありません" や "自分の間違い" などの語句を使用します。繰り返しまたはより深刻なエラーは、「私はそれについて本当に残念です」のようなより複雑な説明を使用する可能性があります。また、応答の種類を決定する際には、文字の個性も考慮してください。 もう 1 つのオプションは、外部の状況を非難することです。 "Boy, it's noisy out there, take the blame from the user and the character. 相互作用の協調的な性質をユーザーに思い出させるのも役に立つ場合があります。"この作業を行うために何ができるかを見てみましょう" などの語句を検討してください。
Microsoft エージェントでは、認識のための自動フィードバックもサポートされています。 発話が検出されると、リスニング ヒントには、聞き取った最適な一致の音声テキストが表示されます。 定義したコマンドの信頼度設定に基づいて、独自のテキストを表示するように設定できます。
エラーの可能性があるため、重大な悪影響を及ぼし、取り消し不可能な選択肢の確認を常に必要とします。 当然ながら、アクションの結果が破壊的になる可能性がある場合は、確認が必要になります。 ただし、時間の長いプロセスや操作を中止する状況の確認も必要とすることを検討してください。