NLPの設定とガイドライン

インテントの命名ガイドライン

タスク（インテント識別子）に名前を付ける際には、以下のガイドラインに従ってください。

動作動詞、目的語、場合によっては修飾語（目的語の前後に配置）を使用します。通常、インテント名は2～4語で構成されます。
タスクの目的が伝わる5語以内の単語を使用します。
動作が似ている場合は、別のタスクで同じ動詞を使用します（例：問題を表示する/問題を表示する代わりにレポートを表示する/レポートを取得する）。
単一語での動作を避けます。
限定詞を避けます（the、a、my、thatなど）。
数字を避けます。無理な場合は必ず数値表記を使用します。
タスク、アラート、アクション、キャンセル、破棄、変更、WebhookなどのKore.aiプラットフォーム用語を避けます。
インテント名に潜在的エンティティを使用するのを避けます（例：今日が潜在的なエンティティである今日の天気を取得します）。
() & / \ $ [ ] + *などの特殊文字を使用しないでください。
– , . ! ? ‘ “などの句読点を使用しないでください。
代名詞を使わないでください（例：私に問題をすべて表示してください）。
Bot名に関連する用語を使用しないでください（例：Asanaタスクを作成する）。
単語を動詞と名詞の両方で使用しないでください（例：問題の更新/更新の取得）。
List of Itemsのエンティティタイプでは、同義語を定義する際に、「()、%、°（30°Cなどの度数記号）」の文字の組み合わせを持たないようにしてください。

オンデマンドタスク（アクション、ダイアログ、情報タスク）には、常に動作動詞、目的語、そして場合によっては修飾語（目的語の前後に配置）が含まれているべきです。ほとんどすべてのアクションを「how + what」の形式にマッピングし、「目標は…」という文を完成させる必要があります。

何かをする
ステータスを取得する
詳細レポートを送信する
重要なレポートをメールで送信する
3日間の予報を取得する

アラートには常に目的語と修飾語（目的語の前後に配置）が含まれているべきです。アラートには動詞を使用しないようにしてください。アラート名に「alert」という単語を使用しないようにしてください。アラートを「what」の形式にマッピングし、「…のアラートを設定する」という文を完成させる必要があります。

何か
ステータスの更新
重要なステータスの更新
変更

パターン

名前に使用される言葉に同義語を使用するのは適切ですが、ユーザーはスラングや比喩などの慣用表現を使用してタスクを参照する場合もあります。

例えば、タスク名が「Get Current Weather」となっているにもかかわらず「What’s happening with today’s rain situation」と入力したとします。このような場合、タスク名に使用されている単語はいずれも使用されていませんが、入力内容は同じことを意味しています。Bot用のNLPインタプリタの精度と認識を最適化するために、パターンを作成することができます。

NLPインタプリタが同義語を1つのタスクまたはフィールドに、パターンを別のタスクまたはフィールドに一致させた場合、認識には同義語の一致よりもパターンの一致が優先されます。

注：パターンはリストされた順に評価されます。そのため、パターンを追加する際には、最も制限の多い順から少ない順に追加するようにしてください。

インテントパターンの作成に関する一般的なガイドラインは以下の通りです。

3語以上の単語を使用します。
単語を正規化形式で使用します（不定詞、単数名詞など）。
単語およびその同義語には小文字を使用します。
米国式スペルの単語を使用します（normalizeではなくnormalizeなど）。
限定詞や代名詞の使用を避けます（the、a、my、thatなど）。
数字の使用を避けます。
タスクパターンの定義にエンティティ値を使用するのを避けます。
省略を使用しないでください（what ’sなど）。
() & / \ $ [ ] + *などの特殊文字を使用しないでください。
– , . ! ? ‘ “などの句読点を使用しないでください。

パターンの使用に関するクイックガイドについては、パターンの使用方法を参照してください。

パターン演算子

AND：( X Y )：単語の順序付けられた関係。これはデフォルト設定で、パターンをcancel orderとして指定した場合、(cancel order)と同じになります。
例：(Cancel Order)は「Cancel my phone order」とは一致しますが、「I have a pending order for an iPhone X, can I cancel.」とは一致しません。Botビルダーツールは、単語間のワイルドカード数が増えるパターンを使用しています（1つのインテントに最大3つ）。そのため、「Cancel Order」というパターンは以下に一致する可能性があります。
- 「cancel order」
- 「cancel my order」
- 「cancel that last order」
- 「cancel last weeks big order」
OR：[X Y Z]：これらのいずれかは、ユーザーの発話で意味の区別なく使用することができます。例：（[get make] me [food drink dessert]）は、以下の発話のいずれかと一致します。
- Get me food
- Make me a drink
- Get me a drink
- Get me a dessert
- Make me some quick food
NOT：!X：インテント一致でユーザーの発話に表示されるべはずのない単語です。例：（!fourecast）は「Get current weather」という名前のインテントのパターンとしてマークされ、Botは「Get 3-day weather forecast」という名前の別のインテントをサポートしています。
- ユーザーの発話：「Planning a trip to California get me the forecast」
  - 「Get current weather」とは一致しません。
  - 「Get 3-day weather forecast」と一致します。
    「!word」は、「これ以降はなし」という意味であることにご注意ください。つまり（!forecast the weather）と（get weather !forecast）は異なります。「get forecast for the weather」という発話は後者には一致しますが、前者には一致しません。
Optional：{X}：例：{phone}ユーザーの発話が「Get me a phone number」あるいは「get me a number」であれば、プラットフォームはそれを平等に扱います。
Enforce Phrase: X_Y：フレーズの出現を、間に単語を挟むことなくユーザーの発話のままに強制します。例：transfer_funds。「transfer funds」または「I want to transfer funds」というユーザーの発話は一致しますが、「Can I transfer some funds」は一致しません。
Concepts：~：プラットフォームには、開発者がパターンを定義するために使用可能な多くの組み込みの概念セットがあります。例：（I [like love] ~world_country）は以下に一致します。
- I like India
- I love traveling to Australia
- I would like to visit an African country
Unordered：<<, >>：任意の順序で単語を見つけるために使用されます。例：<>は「Cancel my phone order」に一致し、「I have pending order for an iPhone X, can I cancel」にも一致します。
Start/End of Statement：<, >：例：（transfer fund >）は「I want to transfer funds」に一致しますが、「transfer funds today」には一致しません。
Quote：‘ –：単語を引用したり、正規表現ではない単語を使用したりした場合、システムはパターンで使用したものに制限されます。例：（like to transfer fund）これは「I would like to ransfer funds from my account」に一致しますがbut not」が「I really liked transfer funds process」には一致しません。

エンティティパターン

上記のように、エンティティを検出するために、開発者はエンティティパターンとNERトレーニングを組み合わせて使用することができます。エンティティパターンは、エンティティの有効な値を探す場所についてKoreに指示を行います。エンティティパターンは文中の様々な場所で見つかる可能性があり、Koreは有効な値を持つ最初のインスタンスから値を抽出します。上記のタスクパターンのガイドラインとは別に、以下のエンティティパターンのガイドラインに従ってください。

エンティティの予想される位置を示す位置のワイルドカード*を含めます（例：「（from * to）」、「（in * >）」）。それがない場合、パターンは無効になります。
パターン内でエンティティの位置の前後に存在すべき単語を使用します。位置のワイルドカードの後の単語は、有効なエンティティ値の検索範囲を区切るのに役立ちます。
文の開始と終了の記号（「<」と「>」）を使用して、位置のワイルドカードを区切りますが、Botビルダーツールはエンティティ値を抽出するために文の境界を越えることはないため、これらは厳密には必要ありません（説明用を除く）。
フィールドパターンに他の位置のワイルドカードを使用しないようにします。すべてのフィールドパターンは同じように処理され、1つを除く他の位置のワイルドカードはすべて無視されます。
パターンでフィールド名またはその同義語を使用しないでください。エンティティパターンは、指定された単語の間に最大2つのワイルドカードの単語のみを考慮します。

例：

以下は、「transfer funds」というインテントに対して「from」と「to」の口座番号を認識するエンティティパターンの例です。
上で定義したパターン演算子は、エンティティパターンにも適用することができます。

パターン：word1 *n – word1の出現後の最大n個の単語。
エンティティToAccountのパターン – to *1。
ToAccount はユーザーの発話「transfer funds to ABC123」から取得したものであり、「transfer funds for ABC123」からではありません。
パターン：word1 * word2またはword1 word2 *n – ユーザーの発話からの複数のエンティティ。
エンティティToAccountのパターン – to * fromおよびfrom to *1。
エンティティFromAccountのパターン – from * toおよびto from *1。
ToAccountとFromAccountは「transfer funds from XYZ321 to ABC123」および「transfer funds to ABC123 from XYZ321」というユーザーの発話から取得したものであり、「transfer funds for ABC123 using XYZ321」からではありません。
注：エンティティに複数のパターンが入力されている場合は、どちらかのパターンが一致します。
パターン：[ word1 word2 ] *n – [ …]内で定義されている任意の1つの単語またはフレーズと一致します。
エンティティToAccountのパターン – to *1。
エンティティFromAccountのパターン – [ using from ] *1。
ToAccountとFromAccountは「transfer funds from XYZ321 to ABC123」および「transfer funds to ABC123 using XYZ321」というユーザーの発話から取得したものであり、「transfer funds for ABC123 using XYZ321」からではありません。
パターン：~concept *n – 概念を使用して構築されたパターン。
エンティティToAccountのパターン – to *1。
エンティティFromAccount のパターン –
~from *1。ここで、fromは（using）（from）という概念です。
ToAccountとFromAccountは「transfer funds from XYZ321 to ABC123」および「transfer funds to ABC123 using XYZ321」というユーザーの発話から取得したものであり、「transfer funds for ABC123 using XYZ321」からではありません。

パターンを追加する方法の詳細については、パターンの管理を参照してください。

ネガティブパターン

ネガティブパターンは、ファンダメンタルミーニングまたは機械学習モデルによって検出されたインテントを排除するために使用することができます。

例えば、ユーザーが「I was trying to Book a Flight when I faced an issue」と言ったとします。機械はインテントを「Book a Flight」として識別しますが、それはユーザーが求めていることではありません。このような場合、「was trying to *」をネガティブパターンとして定義することで、一致したインテントを無視させることができます。

同義語

インテント/エンティティを識別するために使用される単語を同じ意味で使用できる場合には、同義語を使用する必要があります。同義語は、インテントとエンティティの両方に対して定義することができます。

Guided Searchなど、それぞれのインテントには名前があります。ユーザーがこのタスクを開始するために入力しそうな同義語はたくさんあります。例えば、「browse products」、「Show me makeup」、「show me products」などです。

開発者としては、タスクの名前は2～3語に限定すべきです。次にそれぞれの単語の同義語を考えてみましょう。

例：

Browse – Find、Search
Product – Makeup、Goods、Kit

また、以下のようなスペルミスも考慮してください。

makeup – make up

同義語は、タスク名の一部として定義された単語に対してのみ定義されるのが理想的です。Botレベルで追加された同義語は、すべてのタスクに適用可能です。つまり、開発者がタスクAに単語の同義語を追加した場合、それらの同義語はタスク名に同じ単語が含まれている別のタスクにも使用することができます。例えば、「browse」という単語に対してGuided Searchと定義された同義語は、Keyword Searchにも使用することができます。同義語は、インテントを要求するユーザーに期待されるバリエーションの数を増やすために使用することができます。それらは既存のインテント名を代替的な言葉で補足しますが、すべてに一致するほど汎用的ではありません。同義語は一方向にのみ作用するものであるため、foo=barはbar=fooを意味するものではないことにご注意ください。

同義語の一般的なガイドライン：

正規化形式の単語を使用します（不定詞、単数名詞など）。
単語と同義語には小文字を使用します。
同義語のフレーズは5語以内のものにします。
米国式スペルの単語を使用します（例：normalizeではなくnormalizeなど）。
意味よりもインテントを使用します（つまり、動作のコンテキストが「find and display」という意味であれば、「get」は「show」の適切な同義語になります）。
限定詞や代名詞に同義語を追加しないでください（the、a、my、thatなど）。
2つの相反するタスクで一致する可能性のある同義語を使用しないでください。
() & / \ $ [ ] + *などの特殊文字を使用しないでください。
– , . ! ? ‘ “などの句読点を使用しないでください。
複数の単語に同義語を割り当てないでください（例：this is wrong：wrong、bad）。
数字に同義語を追加しないでください。
フレーズ形式を使用しないでください（例：「lookup」を同義語として使用せず、単に「look」を使用してください）。
2文字以下の省略はしないでください。

同義語の操作

ユーザー入力とエンティティ（List of ValuesおよびLookupタイプの場合のみ）IDの同義語間の一致は、以下のいずれかの方法で発生する可能性があります。

部分一致 – これはデフォルトの動作で、入力された1つ以上の単語が、与えられた同義語の1つ以上の単語と一致することを意味します。例えば、「debit card」というユーザーの発話は同義語のcredit cardと一致します。
完全一致 – ここでは、与えられた同義語に対するすべての単語が入力に含まれている必要があります。例えば、「add-on credit card」は「credit card」と一致します。しかし、デビットカードの場合は「credit card」とは一致しません。完全一致をトリガーするには、同義語を二重引用符（”）で囲む必要があります。
全文一致 – 入力全体が与えられた同義語と正確に一致する必要があります。例えば、「credit card」はと一致しますが、「my credit card」はとは一致しません。同様に、「credit card」はとは一致しません。全文一致をトリガーするには、同義語を角括弧（<>）で囲む必要があります。
Canonical form match – これは、ユーザー入力が同義語またはその正規表現と一致するデフォルトの動作です。例えば、「check」は「checking」の正規表現であるため、「check my balance」は同義語である「checking account」と一致します。この動作を無効にするには、同義語の前に「checking」として単一のアポストロフィーを付けます。（バージョン7.1以降）

注：同義語を追加して、エンティティだけでなくインテントを識別することができます。エンティティの識別は、インテントが識別された後にのみトリガーされます。

同義語を追加する方法の詳細については、同義語の管理を参照してください。

概念

概念とは、単一の用語で識別されるグループと見なされる、関連する同義語の集まりです。

認められる概念の命名規則：

接頭語として～が必要です。
概念の名前で使用可能な文字は以下の通りです。
- a〜zおよびA〜Z
- 1～9
- _（アンダースコア）
少なくとも1つのアルファベットが〜の後に続く必要があります。
_（アンダースコア）で始まる、または終わることはできません。
大文字と小文字を区別しません。つまり、~myConceptは~myconceptと同じです。

認められる概念の名前の例：

~my_concept
~Sample
~test123
~my_new_concept

Examples of Invalid concepts names:

~_concept
~concept_
~a-concept
~123test

詳細については、カスタム概念を参照してください。

標準応答

標準応答は、会話中の特定の状況に対応するためにプラットフォームが使用するテンプレートメッセージです。例としては、不明瞭なユーザー入力の解決、承認の要求、確認、一時停止や再開についての通知などがあります。標準応答は以下のように分類されます。

ステートメント
挨拶
クエリ
エラーと警告
質問と選択

プラットフォームには定型の応答が用意されていますが、これらのメッセージをカスタマイズしたり、バリエーションを追加したりすることを開発者にお勧めします。

会話を通してシームレスなエンドユーザー体験を提供するために、開発者はそれぞれの標準応答を見直し、Botの全体的なペルソナ/テーマに適しているかどうかを確認する必要があります。

標準応答は、プレーンテキストメッセージにより、あるいはJavaScriptからの生成により、サポートされているチャネルの動的メッセージおよびテンプレートを作成することができます。該当する場合、標準応答は、開発者がメッセージをカスタマイズするのに役立つコンテキストタグをサポートします。

例えば、ユーザーがBotにできることを要求した場合、Botは「Here are the tasks I can perform for you.」というメッセージで応答します。この例では、開発者はこのメッセージを変更し、適切な場所でタグを再度使用することを選択することができます。これらのタグは、実行時の値を含む会話の中で、実際のテキストコンテキストに置き換えられます。

ナレッジグラフ

実行可能なタスクについては、タスク名（ファンダメンタルミーニングモデルで使用）またはタスクに定義された機械学習の発話に基づいて、インテントが識別されます。このアプローチは、言語意味論や機械学習モデルから得られる統計的確率を用いて、タスクを他のタスクと区別して識別することができる場合に適しています。

FAQの場合、ほとんどのFAQは意味論的バリエーションの点で類似しているため、このアプローチはうまくいかない可能性があります。より適切な回答を見つけるためには、ドメインに関する追加のインテリジェンスが必要になります。

Kore.aiのナレッジグラフベースのモデルは、ユーザーインテント（この場合、最も適切な質問）を識別する際の主要なドメイン用語とそれらの関係の重要性を示すために必要な、追加のインテリジェンスを提供します。

以下の2つの例を使用して、ナレッジグラフの構築に必要なさまざまな設定について説明します。

例A

例B

以下の質問でトレーニングされたBotについて考えてみましょう。

A1: How to apply for a loan?
A2: What is the process to apply for insurance?

以下の質問でトレーニングされたBotについて考えてみましょう。

B1: Can I open a joint account?
B2: How do I add a joint account holder?
B3: How can I apply for a checkbook?

B4: How do I apply for a debit card?

純粋な機械学習と意味規則に基づいた代表的なモデルを用いたインテント認識では、以下のような課題があります。

機械学習に基づいたモデルから得られた結果は、ユーザーの発話に無関係な質問と一致する用語が多い場合、偽陽性の結果に繋がる傾向があります。
Botがドメイン用語や関係性に基づいて理解する必要がある場合、そのモデルは失敗の結果に繋がります。例えば、「What is the process to apply for a loan?」というユーザーの発話は、A1の代わりに誤ってA2を優先的な一致として取得します。A2はA1よりもユーザーの発話と一致する用語が多いため、A2を優先的に取得します。
質問の一部が他の質問と関連して発言されているものの場合、このモデルは正しい応答を取得することができません。例A：「I have applied for a loan, can I get insurance」というユーザーの発話の場合、A1およびA2間のあいまいさが発生します。例B：「I have opened a joint account, can I have a debit card」というユーザーの発話の場合、B4よりもB1と誤って一致します。

Koreのナレッジグラフモデルにおいて、ルートレベルですべての質問を行うことは、用語の頻度と意味規則に基づくモデルを使用することと同じです。

主要なドメイン用語とそれらの関係性

重要な用語やそれらの関係を特定することは、オントロジーを構築する上で重要です。例Aを使用して、これらについて理解を深めましょう。A1とA2はどちらも申請手続きに関するもので、一方はローンの申請について、他方は保険の申請について話しています。そこで、オントロジーを作成する際に、「loan」、「insurance」という2つの子ノードを持つ、「application」という親ノードを作成することができます。その後、A1とA2をそれぞれ「loan」と「insurance」ノードの子ノードとして割り当てることができます。

ナレッジグラフの表示：

例A

同様に、例Bの場合、グラフは以下のようになります。

グラフエンジンの機能

同義語を使用したトレーニングのしやすさ：Kore.aiのナレッジグラフには、グラフノードに対して同義語を関連付ける機能があります。これは質問のバリエーションを把握するのに役立ちます。例：上記の例Aでは、ユーザーは「get」を「apply」の同義語にすることができます。
代替質問によるより広範な適用：ナレッジグラフには、代替の質問を追加する機能があります。これにより、ユーザーが同様の質問をする様々な方法を把握することができます。上記の例Bでは、「How do I add a joint account holder」という質問に対して、「Can I add my wife as a joint account holder」という代替の質問を追加することができます。
精度の向上：オントロジー主導の質問と応答は、偽陽性の可能性を減らします。例えば、「What is the process to apply for SSN」というユーザーの発話に対して、用語頻度に基づいたモデルは、誤ってA2を一致するものとして提案してしまいます。オントロジー主導のモデルには、このような偽陽性を防ぐ機能が備わっています。
クラスを使用したフレーズの重み付け：Kore.aiのグラフエンジンは、無関係な提案をフィルタリングするためのクラスの概念を導入しました。クラスの詳細な説明については、以下のセクションを参照してください。
用語の重要性をマークする機能：Kore.aiのグラフエンジンには、オントロジー用語を重要なものとしてマークする機能があります。例えば、「How to apply for a loan」という質問において「loan」は重要な用語です。「loan」というキーワードがユーザーの発話内に存在しない場合、A1を取得することはほとんど意味がありません。一方で、用語頻度ベースのモデルでは、「How to apply for a」というユーザーの発話は、誤ってA1を取得してしまいます。
関連するノードをグループ化する機能：グラフのサイズが大きくなると、グラフのノードの管理が難しくなる可能性があります。Botの開発者は、オントロジーエンジンの「オーガナイザーノード」を使用することで、ノードの下に関連するノードをグループ化することができます。

ナレッジグラフの特性

注：特性はバージョン6.4以前のクラスに置き換わります。

特性を使用する際には、使用しすぎると偽陰性になる可能性があるため、正しく使用するようにしてください。クラスを使用する場合は、必ず以下のことを満たしてください。

クラスをうまく扱う
クラスが不適切に一般化されないようにする
すべてのFAQが、相互に専用のクラスにタグ付けされるようにする

クラスの仕組みの例を以下に示します。Requestというクラスを作成し、そこにリクエスト関連のフレーズを追加するとします。ユーザーが「I would like to get WebEx」と言い、「I would like to get」がその「Request」クラスに対してトレーニングされている場合、このFAQは、その単語がタグ付けされているナレッジグラフのパス全体でのみ考慮されます。これはポジティブなシナリオです。しかし、ユーザーが「Can you help with getting WebEx」と言い、そのRequestクラスに対して同様の発話がトレーニングされていなかった場合、「None」クラスにタグ付けされ、このFAQは「request」という単語が存在しないパスでのみ使用されます。これにより障害が発生します。

もう 1 つの可能性としては、ユーザーが「I want to request for help fixing WebEx」と言った場合、「I want to request」を含む発話でRequestクラスをトレーニングし、すべてのクラスで行われたトレーニングに基づいて、エンジンがこの機能（I want to requestを含むフレーズ）を一般化してRequestクラスにタグ付けする場合です。この場合、WebExのヘルプパスにRequestクラスが存在しないと、「help」 >「WebEx」に対する入力の識別に失敗します。

クラスが役立つのは、相互に専用のFAQセットがある場合です。例えば、Product issuesに関するFAQセットとProcess for buying a productに関するFAQセットがあったとします。
Process for buying a productに関するFAQ：

How do I buy Microsoft Office online?
What is the process for buying antivirus software

Product issuesに関するFAQ：

I am having issues installing software
How to resolve an issue with antivirus

ユーザーが「What is the process for fixing antivirus when it doesn’t work」と言った場合、エンジンはこの入力がA2とB2の両方に類似することに気付き、両方を提案として提示することがあります。Issueはbuyと相互に独占的であり、この場合、buyに関連するFAQを提示することは意味がありません。その逆（buy関連の質問にIssueのFAQを一致させること）の方が、はるかに大きな問題になる可能性があります。これを解決するために、issue とbuy2つのタイプのクラスを作成します。すべての入力はbuyまたはissueのどちらかに分類され、適切な回答を見つけるために関連する質問のみが使用されます。

On this Page