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つの単語であるためです。もう1つの否定的な例として、Oracleでお客様が製品サポートをリクエストするためのデジタル・アシスタントを作成した場合、製品ごとに同じインテントとトレーニング発話を持つ個別のスキルを作成したとします。

幼い子供として、ボトル、紙片、おもちゃ、枕、バッグを保持するための個別のスキルを開発しなかったでしょう。むしろ、あなたは物事をどう捉えるかを学びました。ボットのインテントの作成にも同じ原則が適用されます。

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

• "新規経費精算書を作成します"

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

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

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

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

機械学習は親しみやすく、モデル設計によってOracle Digital Assistantの会話型AIの友人になれることを常に忘れないでください。

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

たとえば、ユーザーが購入日を求められたときに「2021年6月12日と2021年7月2日にこのアイテムを購入しました」というメッセージを入力するとどうなりますか。この場合、エンティティが共通レスポンス・コンポーネントまたはエンティティの解決コンポーネントとともに使用されると、ユーザーがデータ入力として単一の値を選択するための曖昧さ回避ダイアログが自動生成されます。人が別の人に声明や命令の曖昧さを解消するよう求める人間の会話と同様に、エンティティもあなたのために同じことをします。また、ユースケースがサポートする場合は、複数の値を受け入れるようにエンティティを構成することもできます。

また、カスタム・エンティティとともに「Common Response」または「Resolve Entities」コンポーネントを使用する場合、ユーザーに表示されるプロンプトをエンティティに定義して、以前に失敗したデータ入力に対して再度プロンプトを表示したときに代替プロンプトが表示されるようにすることもできます。起動間でプロンプト・メッセージが変化すると、ボットがロボットにならず、会話も多くなります。また、代替プロンプトを使用して、ユーザーが正しい入力を提供できるように、情報を段階的に表示することもできます。

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

インテントと同様に、エンティティ名を作成する際に従う命名規則をお薦めします。初期設定では、エンティティの名前にエンティティ・タイプを含めると、エンティティのリストを簡単にフィルタできます。たとえば、次のスキームを使用できます。

• 値リスト・エンティティ: 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、sk、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は、ユーザーが何を求めているかを理解することです。ただし、様々な方法で表現できる場合もあります。たとえば、ピザボットのケースでは、ユーザーは「ピザを注文したい」や「お腹が空いている」などのフレーズでピザを注文できる必要があります。