Oracle Digital Assistantでは、標準インテントとアンサー・インテントの2つのタイプのインテントがサポートされています。両方のインテント・タイプで同じNLPモデルが使用されます。これは、本番前テストおよび本番環境でTrainer Tmに設定する必要があります。

2つのインテント・タイプの違いは、アンサー・インテントは、インテントがユーザー・メッセージから解決されるたびに表示される事前定義済メッセージに関連付けられるのに対し、通常のインテントは解決されると、ダイアログ・フローで定義されたユーザー- ボットの会話につながります。

ボットの回答インテントを使用して、常に単一の回答を生成するよくある質問に応答します。通常のインテントは、トランザクション・タスクの完了、バックエンド・システムの問合せ、または回答の提供時に時間、日付、場所などの外部依存関係を考慮する必要があるよくある質問への回答を提供する、より長いユーザーボットの対話を開始するために使用されます。

スキルの開発と維持をより効率的にするために、特定のインテントが何を意味するのかをすぐに理解し、インテントを検索するときにフィルタ・オプションを使用できるように、インテントの命名規則を策定する必要があります。

たとえば、名前の一部は、アンサー・インテントと通常のインテント(および、直接回答を返すことができるが、アタッチメントやリモート・サービスへの問合せに基づくなど、より複雑な処理を行うために必要な通常のインテント)を区別する必要があります。そのため、次のようなスキームから始めることができます。

• 通常のインテント: reg.<name_of_intent>

• 回答インテント: ans.<name_of_intent>

• 正解である通常のインテント: reg.ans.<name_of_intent>

分類可能な関連タスクをスキルが処理する場合、インテント・ネーミングでもこれを使用できます。オーダーを作成し、オーダーを取り消す目的があるとします。この2つのユースケースを使用すると、命名規則は次のようになります。

• 通常のインテント: create.reg.<name_of_intent>、cancel.reg.<name_of_intent>

• 回答インテント: create.ans.<name_of_intent>、cancel.ans.<name_of_intent>

• 正解である通常のインテント: create.reg.ans.<name_of_intent>、cancel.reg.ans.<name_of_intent>

ドット表記法、アンダースコアまたは独自のドット表記法のいずれを使用するかに関する厳密な規則はありません。ただし、Oracle Digital Assistantインテント・エディタ・パネルで切り捨てられないように、名前を十分に短くしてください。

すべてのインテントには、「会話名」フィールドもあります。会話名は、ユーザー・メッセージが複数のインテントに解決される場合に、デジタル・アシスタントまたはスキルによって自動的に作成される曖昧さ回避ダイアログで使用されます。

各インテントには「説明」フィールドがあり、このフィールドでは、スキルを維持している他のユーザーが推測せずに理解できるように、インテントの目的を簡単に説明する必要があります。

インテントの範囲指定が狭すぎる例は、スキルで処理する製品ごとに個別のインテントを定義することです。既存の保険契約の延長を例に考えてみましょう。ポリシーごとにインテントを定義した場合、「妻を健康保険に追加したい」というメッセージは、「妻を自動車保険に追加したい」とはあまり変わりません。なぜなら、この2つの区別は1つの単語であるためです。別の否定的な例として、Oracleで顧客が製品サポートをリクエストするためのデジタル・アシスタントを作成し、製品ごとに同じインテントとトレーニング発話を持つ個別のスキルを作成したとします。

幼い子供として、ボトル、紙、おもちゃ、枕、バッグを握るための別のスキルを身につけていなかったでしょう。むしろ、物事をどう受け止めればいいのかを学びました。ボットのインテントの作成にも同じ原則が適用されます。

インテントの解決後にユーザーが希望する内容がまだ表示されない場合は、インテントのスコープが広すぎます。たとえば、「handleExpenses」という名前のインテントを作成し、次の発話と多数のバリエーションでトレーニングしたとします。

• 「新規経費精算書を作成します。」

• "最近の経費精算書を確認したい"

• "最近の経費精算書の取消"

• 「最近のレポートには修正が必要です」

これにより、経費精算書を作成、更新、削除または検索する必要があるかどうかを理解するために、さらに処理が必要になります。ダイアログ・フローの複雑なコードを回避し、エラー・サーフェイスを減らすために、範囲が広すぎるインテントを設計しないでください。

機械学習はあなたの友人であり、モデル設計により、Oracle Digital Assistantの会話型AIの親友になる必要があることを常に覚えておいてください。

また、エンティティによって提供される機能も増えており、エンティティと一緒に収集できる情報の識別に時間を費やす価値があります。

たとえば、ユーザーが購入日を求められたときに「I bought this item on June 12、 2021 and July 2、 2021」というメッセージを入力した場合はどうなりますか。この場合、エンティティは、共通レスポンス・コンポーネントまたはエンティティの解決コンポーネントとともに使用すると、ユーザーがデータ入力として単一の値を選択するためのあいまい性解消ダイアログを自動生成します。人が文や順序を曖昧にしないよう別の人に依頼する場合と同様に、エンティティも同じことを行います。また、ユースケースで複数の値を受け入れるようにエンティティを構成することもできます。

また、「共通レスポンス」または「エンティティの解決」コンポーネントをカスタム・エンティティとともに使用する場合、ユーザーに表示されるプロンプトをエンティティに定義して、以前に失敗したデータ入力に対して再度プロンプトが表示されたときにユーザーが代替プロンプトを表示できるようにします。プロンプト・メッセージが呼出し間で変化すると、ボットはロボットが少なくなり、会話性が向上します。また、代替プロンプトを使用して、ユーザーが正しい入力を提供できるように、より詳細な情報を段階的に表示することもできます。

一般的には、エンティティを使用してユーザー入力検証を実行し、検証エラー・メッセージを表示したり、プロンプトやあいまい性解消ダイアログを表示することをお薦めします。

インテントと同様に、エンティティ名を作成する際に従う命名規則をお薦めします。まず、エンティティの名前にエンティティ・タイプを含めると、一目でわかりやすくなり、エンティティのリストを簡単にフィルタできます。たとえば、次のスキームを使用できます。

• 値リスト・エンティティ: list.<name_of_entity>

• 正規表現エンティティ: reg.<name_of_entity>

• 導出エンティティ: der.<name_of_entity>またはder.DATE.<name_of_entity>

• コンポジット・バッグ・エンティティ: cbe.<name_of_entity>

• 機械学習エンティティ: ml.<name_of_entity>

上の例のようにドット表記法を使用するか、アンダースコアを使用するか、独自の表記法を使用するかは任意です。それ以外は、名前を短くしておくことをお勧めします。

各エンティティには「説明」フィールドがあり、エンティティの目的を簡単に説明する必要があります。入力できる文字数はフィールドに制限されているため、簡潔にしてください。

インテントの発話を作成する場合は、ほとんどの発話をインテントのトレーニング・データとして使用しますが、作成したモデルをテストするためにいくつかの発話も確保する必要があります。80/20のデータ分割は、トレーニング用に作成する発話とテスト用に作成する発話の比率について、会話型AIで共通しています。

機械学習について読む際のもう1つの比率は、70/15/15の分割です。70/15/15分割とは、発話の70%がインテントをトレーニングするために使用され、15%が開発中にインテントをテストするために使用され、その他の15%が本番に移行する前にテストに使用されることを意味します。インテント・トレーニングのよい例えは、学校試験です。70%は、教師があなたに話題を教えているものです。最初の15%は、勉強中に受けるテストです。その後、試験を書くことになると、これまで見たことのない15%の試験を受けることになります。

70/15/15は魅力的ですが、Oracle Digital Assistantインテントのトレーニングには80/20スプリットを使用することをお薦めします。このガイドの後半で説明するように、デジタル・アシスタント(ネイバー・テスト)のコンテキストで、クロステストの発話からテスト用の追加データを取得します。したがって、このガイドの推奨事項に従うと、(70/15/15の分割になっていない場合でも)モデルが機能するようにテストするための十分なデータが収集されます。そして、これらのテストを繰り返し実行して、時間の経過とともに改善または回帰のアイデアを得ることができます。

会話型AIに関して、ゴミが入ることはありません。モデルのトレーニングに使用するデータの品質は、ボットの理解と情報を抽出する能力に直接影響します。

発話を定義する目的は、インテント・モデルを混乱させない、偏りのないバランスのとれたトレーニング・データとテスト・データのセットを作成することです。そのために、ここではあなたがそれに従うためのいくつかのルールがあります、私たちの経験の中で、良い結果を与える

• 生成ツールを使用して発話を作成しないでください。チャンスは、わずかなバリエーションで多くの発話を得るでしょう。

• 「パスワードをリセットしたい」と「電子メールにログインできない」など、インテントをトリガーする様々なアプローチを検討します。

• マシン・モデルが学習できるコンテキストがないため、単一の単語で構成される発話を使用しないでください。

• 発話のセマンティックな意味にあまり貢献しない「please」、「thank you」などの単語は避けてください。

• エンティティ値の代表的なセットを使用しますが、すべてではありません。

• エンティティの配置を変更します。エンティティは、発話の先頭、中央および末尾に配置できます。

• インテント間の発話数のバランスを保ちます(たとえば、あるインテントの場合は300、別のインテントの場合は15を避けてください)。

• 意味的および構文的に完全な文に努めます。

• 正しいスペルを使用してください。例外によってのみ、発話にいくつかの非常に可能性の高いスペルミスや誤字を追加します。モデルは、通常、スペルミスや誤字を自分で処理できます。

• 国固有のバリエーション(ゴミ箱とゴミ箱、おむつとナッピーなど)を追加します。

• 文構造を変更します(例: 「私はピザを注文したい」、「私はピザが欲しい、私は注文することができます)。

• 個人代名詞を変更します(例:I、 we are、 we are、 I would、 I would、 we、 you、 your、 we)。

• 動詞には異なる用語を使用します(例: order、get、ask、want、like、want)。

• 名詞に異なる用語(ピザ、カルゾーン、ハワイ語など)を使用します。

• 様々な長さ(短い文、中文および長い文)の発話を作成します。

• 複数形化を検討します(例: 「ピザを注文したい」、「ピザを注文できますか?」)。

• 異なる動詞形式とドイツ語を使用することを検討してください(「釣りは許されます」、「釣りたい、これを行うことができます。」)。

• 場合によっては句読点を使用し、他の場合は省略します。

• 代表的な用語を使用します(たとえば、ソフトウェアがコンシューマによって使用されている場合、技術的な用語が多すぎないようにします)。

発話は、コマンドライン引数やリスト・キーワードと同じように定義しないでください。定義するすべての発話に、それらに対する「会話」の概念があることを確認します。キーワードのみがリストされている発話の作成にはコンテキストがないか、機械学習モデルから学習するには短すぎます。

理想的には、優れた発話は実際のデータからキュレーションされます。開始する既存の会話ログがない場合は、単にそれらを合成するのではなく、クラウドソーシングの発話を検討してください。それらを合成することはあなたの最後の手段でなければなりません。

クラウド・ソースの発話の場合、ボットの対象オーディエンスを表す方法を表す方法またはわかっている人をEメールで送信します。さらに、Oracle Digital Assistantのデータ製造機能を使用して、発話の(クラウドソーシング)提案を収集するための自動プロセスを設定できます。この自動プロセスは、発話が適切になるためのルールに準拠するようにキュレートすることをお薦めします。

サンプル発話を要求する人は、非現実的なニッチ・ケースや、文章をキュレートする必要がある言語の過剰な芸術的使用につながる可能性がある、非常に良い例を考え出すことが難しいと感じる場合があります。

また、サンプル発話のキュレーションには、クラウドソーシングを通じて収集した個々のサンプルの複数のバリエーションの作成も含まれることに注意してください。

発話の質は量よりも重要である。いくつかの適切な発話は、設計が不十分なutterances.Ourの推奨事項よりも優れているのは、開発の目的ごとに20-30の適切な発話から開始し、最終的にインテントの深刻なテストのためにその数を80-100に増やすことです。時間の経過とともに、ボットが実際のユーザーでテストされると、追加の発話を収集して、インテント・モデルのトレーニングに使用します。

インテントの重要性とユース・ケースによっては、インテントごとに定義される発話の数が100から数百(および、まれに数千)になる場合があります。ただし、前述したように、インテントごとの発話の差異は極端ではありません。

機械学習モデルでは、ユーザー・メッセージが評価され、最上位レベル・ラベル(意図)およびランナー・アップについて信頼度スコアが返されます。会話型AIでは、最上位レベルのラベルが会話を開始する目的として解決されます。

したがって、モデル・トレーニングとユーザー・メッセージに基づいて、インテントAが良好な一致であるという80%の信頼度、インテントBに対する60%の信頼度、インテントCに対する45%の信頼度がモデルにあるとします。この場合は、ユーザーがインテントAを必要としていることに非常に満足している可能性があります。

しかし、最も高いスコアリング・ラベルに、これがユーザーの望むものであるという信頼度が30%しかないとしたらどうでしょうか。このインテントに従うリスクをモデルに負わせますか。それとも、モデルがユーザーの希望を予測できず、リクエストを再フレーズするメッセージをユーザーに表示できないと想定しますか。

インテント・モデルがユーザー発話との照合を検討するインテントを決定できるように、会話型AIは信頼度しきい値と呼ばれる設定を使用します。インテント・モデルは、すべてのインテントに対してユーザー発話を評価し、各インテントの信頼度スコアを割り当てます。信頼度しきい値は、行をマークする可能性のある信頼度スコアの範囲内の値です:

• 下記に掲げる事項に該当しないものとする。

• その上で、インテントは会話を開始する候補インテントとみなされます。

Oracle Digital Assistantでは、スキルの設定でスキルの信頼度しきい値が定義され、デフォルト値は0.7です。

0.7の設定は、トレーニングされたインテント・モデルから開始してテストするのに適した値です。テストでユーザー・メッセージの正しいインテントが0.7を上回るほど解決される場合、十分にトレーニングされたモデルがあります。

0.7 の設定で良好な結果が得られる場合は、0.8を試してください。信頼度が高いほど、インテント・モデルからノイズを除去する可能性が高くなります。これは、モデルがユースケースの解決に関連しないユーザー・メッセージ内の単語に応答しないことを意味します。

ただし、信頼度しきい値が高いほど、全体的な理解が低下する可能性が高くなります(つまり、多くの実行可能な発話が一致しない可能性があります)。これは必要なものではありません。言い換えれば、100%の「理解」(または信頼レベルとして1.0)は現実的な目標ではないかもしれません。

会話型AIとは、ユーザーが何を望んでいるかを理解することです。ただし、多くの異なる方法でそのことを表すことができます。たとえば、ピザ・ボットの場合、ユーザーは「ピザを注文したい」や「お腹がすいている」などのフレーズでピザを注文できる必要があります。