次の方法で共有


インテリジェントなアプリケーションワークロードのための意図認識とエンティティ抽出オプション

意図認識とエンティティ抽出は、自然言語理解 の重要なコンポーネントです。

意図認識には、ユーザーの入力の背後にある目標や目的を識別することが含まれます。 たとえば、ユーザーが「フライトを予約したい」と言った場合、その意図はフライトを予約することです。 意図認識は、ユーザーの要求に基づいて副操縦士がどのようなアクションを取る必要があるかを理解するのに役立ちます。

エンティティ抽出では、ユーザーの入力から特定の情報を識別して抽出します。 エンティティには、日付、名前、場所、その他の関連データなどが含まれます。 たとえば、「9月15日にニューヨーク行きのフライトを予約する」という文では、「ニューヨーク」と「9月15日」がエンティティです。

副操縦士は、インテントを使用してユーザーの目標を理解し、エンティティを使用して タスク を完了するために必要な具体的な詳細を識別します。 したがって、意図認識とエンティティ抽出により、コパイロットはユーザーのクエリに対して正確かつ効率的な応答を提供できるようになります。

インテリジェント アプリケーション ワークロードを設計するときは、インテリジェント アプリケーション ワークロードが肯定的なユーザー エクスペリエンスを提供できるように、意図認識とエンティティ抽出に最適なオプションを選択する必要があります。

定義

任期 Definition
NLU 自然言語理解 は、機械の読解に重点を置いたAIにおける自然言語処理のサブセットです。
CLUB 会話型言語理解は、カスタムNLUモデルの作成を可能にするAzure AIの機能です。
法学修士 大規模な 言語モデル は、人間の言語を理解して生成するように設計されたAIモデルの一種です。
GPT 生成的事前トレーニング済みトランスフォーマーとは、トランスフォーマー アーキテクチャを使用して人間のようなテキストを理解し、生成する大規模な言語モデルのファミリを指します。
動的チェーン 動的チェーン は、生成アクションのトリガーを自動化する方法です。 あらゆる可能性のある トピック または トリガー フレーズ, トリガー を手動で定義する代わりに、会話のコンテキストに基づいて、どのトピックまたはプラグイン アクションを呼び出す必要があるかをAIが判断できるようになります。

インテリジェント アプリケーション ワークロードで意図認識とエンティティ抽出の適切なオプションを選択するには、いくつかの重要な考慮事項があります。

  • 事前構築済みエンティティとカスタム エンティティ: によって提供される事前構築済みエンティティがニーズを満たすかどうかを評価します。 Copilot Studio 事前に構築されたエンティティは、日付、数値、名前などの一般的な情報タイプをカバーします。 アプリケーションにドメイン固有の知識が必要な場合は、カスタム エンティティを作成する必要があります。

  • ユーザー入力の複雑さ: ユーザー入力の複雑さと変動性を考慮します。 単純なシナリオの場合、事前に構築されたエンティティで十分な場合があります。 より複雑なインタラクションには、カスタム エンティティや正規表現 (regex) などの高度な構成が必要になる場合があります。

  • スロット フィリング: アプリケーションでプロアクティブなスロット フィリングが必要かどうかを決定します。プロアクティブなスロット フィリングでは、副操縦士がユーザー入力から不足している情報を積極的に探し出して入力します。 スロットを埋めることで、フォローアップの質問の必要性が減り、ユーザー エクスペリエンスが向上します。

  • パフォーマンスとスケーラビリティ: 選択した方法のパフォーマンスとスケーラビリティを評価します。 カスタム エンティティと複雑な構成では、多くの場合、より多くの処理能力が必要となり、応答 時間に影響する可能性があります。

  • メンテナンス の容易さ: エンティティの保守と更新の容易さを考慮してください。 事前に構築されたエンティティは管理が容易ですが、カスタム エンティティはアプリケーションの進化に合わせて継続的に調整する必要があります。

標準のNLU、Azure CLU、または 動的チェーン から選択します。

Copilot Studioでは、トピック またはアクション トリガーは、標準のNLUモデルを使用するか、それをカスタムAzure CLUモデルと組み合わせるかオーバーライドするか、またはNLUモデルをGPT大規模言語モデル ベースのモデルである 動的チェーン に完全に置き換えることによって実現できます。

標準NLUモデル カスタムAzure CLUモデル 動的チェーン
プロ 多数の定義済みエンティティ タイプを備えた、事前トレーニング済みのデフォルトのすぐに使用できるモデルです。

構成は、完了 で、トリガー フレーズとカスタム エンティティ (値と同義語を含む閉じたリスト、または正規表現) を追加することで行われます。
ネイティブ モデルを使用して、より多くの言語をサポートします。

意図をより適切に認識するため、または特定の業界の要件に対応するために、意図トリガー モデルのカスタマイズをサポートします。

複雑なエンティティの抽出 (たとえば、同じタイプ) が可能になります。

エンティティ抽出では、 Copilot Studio 標準のNLUも使用できます。
GPTの大きな 言語モデル を使用し、より広範囲のデータで事前トレーニングされています。

複数のインテントを処理し、トピックやプラグインをチェーンできます。

入力されていない質問を自動的に生成し、会話のコンテキストから複雑なエンティティと質問に回答します。

構成は、トピック、プラグインのアクション、入力、および出力を記述することによって 完了 になります。
欠点 クエリごとに単一の意図認識。

延長できません。 モデルの動作を変更したり、モデルを微調整したりすることはできません。 現状のまま提供されます。

同じクエリで同じタイプの複数のエンティティをスロットに埋め込むには、それぞれについて曖昧さを解消する必要があります (たとえば、送信元都市と送信先都市)。
クエリごとに単一の意図認識。

構成はAzureで 完了 となり、追加料金がかかります。

評価する必要がある独自のサービス制限があります。

Azure CLUインテントと Copilot Studio トピックは注意深く同期させておく必要があります。
これは生成AI機能であるため、メッセージのライセンス消費率は通常の トピック トリガーよりも高くなります。

トリガー フレーズとスロットの充填

インテリジェントなアプリケーション ワークロードを開発する場合は、ネイティブ機能を使用して意図認識を強化し、会話を効率化します。 まず、既存のFAQデータベースとチャットのトランスクリプトから トピック トリガー フレーズを特定し、予想されるフレーズが関連性があり正確であることを確認します。 エンティティの使用方法を検討します。たとえば、注文IDの検索に正規表現を使用するか、電子メールの事前構築済みエンティティを使用するか、同義語を含む操作タイプのクローズド リストを使用するかなどです。 また、サンプル フレーズを使用して トピック トリガーをテストし、意図認識とエンティティ抽出プロセスの精度を検証および改善する方法も計画します。 詳細はこちら 展開とテストに関する考慮事項

トリガー フレーズ

トリガー フレーズは副操縦士のNLUモデルをトレーニングします。 特定のトピックに関する特定のフレーズを定義することで、副操縦士がユーザーの発話を正確に認識して応答するのに役立ちます。 これらの トリガー フレーズを適切に構成すると、副操縦士がユーザーの意図を正しく識別し、適切に応答できるようになります。 副操縦士がどの トピック を トリガー に使用するか不明な場合は、最大3つの潜在的な トピック 候補 (複数のトピックが一致 システム トピック) を提案するか、トピック が識別されない場合はデフォルトの 応答 にフォールバックすることができます。 このメカニズムは会話の流れを維持し、副操縦士が幅広いユーザー入力を効果的に処理できるようにします。

エンティティの抽出とスロットの埋め込み

エンティティの抽出とスロットの埋め込みは、効果的な副操縦士を育成する上で重要な要素です。 これらのプロセスにより、副操縦士はユーザーのクエリから関連する詳細を識別して抽出し、情報を効率的に取得して使用できるようになります。

エンティティ抽出 ユーザーの入力を解析して特定の情報部分を識別することが含まれます。 たとえば、「大きいサイズの青いTシャツを3枚注文したい」というクエリでは、副操縦士のNLUモデルは次のエンティティを抽出する必要があります。

  • 数量: 3
  • 色: ブルー
  • サイズ: L
  • アイテムタイプ: Tシャツ

スロット フィリング とは、抽出されたエンティティを使用して、特定の タスク に必要な情報を入力するプロセスです。 この例では、副操縦士は トピック を注文として認識し、抽出されたエンティティで必要なスロットを埋めます。 副操縦士は、さらに質問することなくユーザーの要求を理解することができ、対話が効率化されます。

エンティティの抽出とスロットの埋め込みにより、コパイロットは複雑なクエリをより効率的に処理できるようになり、正確でコンテキストに適した応答が提供され、ユーザー エクスペリエンスが向上します。

詳細情報:

Azure CLUとの統合 Microsoft Copilot Studio

CLUモデルを副操縦士と統合すると、副操縦士の機能が大幅に強化されます。 Copilot Studio この統合には、マッピングAzure CLUインテントがトピックに関係し、コパイロットがユーザーのインテントをより正確に理解して応答できるようになります。 Copilot Studio さらに、 Copilot Studio 事前構築されたエンティティをAzure CLUエンティティと一緒に使用できるため、エンティティ抽出のための堅牢なフレームワークが提供されます。

この統合を検討する際には、インテリジェント アプリケーション ワークロードにAzure CLUが必要かどうかを評価することが重要です。 たとえば、Azure CLUは、アプリケーションに不可欠な可能性のある、より多くの言語、業界固有の辞書、複雑なエンティティ抽出をサポートしています。 Azure CLUを使用したカスタム エンティティ抽出では、サイレントまたは「ラッキー」なスロット フィリングも有効にできるため、副操縦士は、フォローアップの質問をせずに、単一のフレーズで送信元都市と送信先都市の両方を識別するなどのシナリオを処理できます。

もう1つの重要な側面は、Azure CLUサービスのクォータと制限 位置を合わせる が副操縦士の使用状況に適合していることを確認することです。 たとえば、意図認識を必要とする通話が1分あたり1,000件未満であると予想される場合は、S層を使用してAzure CLUを設定できます。 この構成により、副操縦士はサービス制限を超えたり、予期しないコストが発生したりすることなく、予想されるワークロードを処理できるようになります。

詳細情報:

トピック 構造に関する考慮事項

自然でシームレスな会話を作成するには、トピックを効果的に構成することが重要です。 トピックは個別の会話パスであり、これらを組み合わせることで、ユーザーは副操縦士とスムーズに対話できるようになります。 トピック 構造を設計する際の重要な考慮事項を次に示します。

  • トリガーベースのトピック: これらのトピックは、ユーザーの発話に基づいてアクティブ化され、エントリ ポイントとして機能します。 これらのトピックについて明確な トリガー フレーズを定義します。 トリガー フレーズが複数のトピックにまたがって重複している場合は、明確な質問をした後に適切な トピック にリダイレクトできる包括的な トピック を実装することを検討してください。 エンティティの抽出とスロットの入力により、必要な情報がすでに提供されている場合は、これらの説明を求める質問をスキップできます。

  • リダイレクトベースのトピック: これらのトピックは、リダイレクト アクション、アクティビティ、またはイベントによってトリガーされ、他の複数のトピックから呼び出すことができます。 さまざまな会話パスへのシームレスな統合を容易にするために、入力変数と出力変数を使用して、再利用可能でモジュール化されるように設計する必要があります。

  • デュアルトリガートピック: 一部のトピックは、意図認識または明示的なリダイレクトによってトリガーできます。 この柔軟性により、より動的で応答性の高い会話が可能になります。

  • 会話のブーストとフォールバック: ユーザーのクエリによって一致する トピック がトリガーされない状況に備えて、フォールバック トピックを作成します。 これらのトピックは、一般的な応答を提供したり、会話の流れを維持するために関連するトピックを提案したりできます。

設計アプローチ:

  • 主要なシナリオのカスタム トピック: 関連する トリガー フレーズとリダイレクトを使用して、主要なシナリオのカスタム トピックをいくつか開発します。 複雑な相互作用を管理するには、親子の トピック 構造を使用します。 認識されないインテントについては、生成的な回答とフォールバック メカニズムを実装します。

  • 曖昧さ回避トピック: 質問を明確にする必要がある操作では、曖昧さ回避トピックを使用するように計画します。 たとえば、ユーザー アカウント操作では、操作の種類 (作成、ロック解除、一時停止など) と関連するシステム (SAP、 ServiceNow、 Microsoft など) を明確にする必要がある場合があります。

  • 重複の回避: コンテンツの重複を回避するには、繰り返す必要があるダイアログ パスに再利用可能なトピックを作成します。 これらの再利用可能なトピックは 親 トピック によって呼び出すことができ、完了すると、会話は 親 トピック'sロジックを再開できます。

詳細情報:

認識されないインテントの処理

認識されないインテントを効果的に管理することで、スムーズなユーザー エクスペリエンスが保証されます。 認識されないインテントは、副操縦士がユーザーの発話を理解せず、既存の トピック を トリガー するのに十分な自信がない場合に発生します。 これらのシナリオに対処するための提案をいくつか示します。

  • 認識されないインテントの管理: 最初に、認識されないインテントを会話ブースティング システム トピック に誘導します。これは、公開Webサイトや SharePoint サイトなどの企業リソースで回答を検索します。 関連する情報が見つからない場合、システムはAzure OpenAI GPT-4モデルを使用したカスタム システム プロンプトを使用して、ChatGPTのようなエクスペリエンスにフォールバックできます。 このアプローチにより、クエリが計画外の場合でも、ユーザーは役立つ回答を受け取ることができます。

  • 外部システムとの統合: フォールバック戦略の一環として外部システムと統合するかどうかを検討します。 たとえば、HTTPリクエストを使用してAzure OpenAI GPT-4モデルと統合し、準拠したChatGPTのようなエクスペリエンスを提供します。

  • フォールバックの使用状況の監視: フォールバックが発生する会話の割合を定期的に確認します。 これらの洞察を使用して既存のトピックを充実させたり、新しいトピックを作成したりすることで、副操縦士の理解と 応答 機能が継続的に向上します。

  • フォールバック トピック と生成的回答: 一致する トピック が識別されない場合、 フォールバック システム トピック がトリガーされます。 生成的回答 が有効になっている場合、会話ブースティング トピック が最初に不明なインテント イベントでトリガーされ、必要に応じて フォールバック トピック がトリガーされます。 この階層化されたアプローチは、認識されない意図を効果的に管理するのに役立ちます。

  • 会話ブースティングとフォールバックを使用する: Generative Answers を使用して、さまざまなデータ ソースを検索したり、Azure Cognitive Service for Languageなどの他のシステムと統合したりします。 このサービスは、大量の質問と回答のペアを処理でき、ランダムな質問に対する雑談モデルも含まれています。

  • コア シナリオとカスタム トピック: コア シナリオとトピックが適切に定義され、カスタム トピックを通じて処理されることを確認します。 構造化された効率的な会話の流れを維持するために、これらのトピックの結果を明確に定義します。

ローカリゼーションと言語

副操縦士を構築するときは、インテリジェント アプリケーションのワークロードがサポートする必要がある言語と市場を考慮してください。 ローカリゼーションと言語サポートは、インテリジェント アプリケーションのワークロードが多様なユーザー ベースのニーズを満たすために重要な要素です。 以下にいくつかの推奨アプローチを示します。

  • 言語ごとに1人の副操縦士: このアプローチでは、言語ごとに個別の副操縦士を作成します。 これにより、各副操縦士が特定の言語に対して完全に最適化されることが保証されますが、複数の副操縦士を維持するには多くのリソースが必要になる場合があります。

  • 複数の言語に対応する1人の副操縦士 (構成された翻訳): このアプローチでは、1人の副操縦士が複数の言語をサポートし、翻訳は副操縦士の構成の一部として提供されます。 このアプローチでは、副操縦士が更新されるたび、または新しいコンテンツが追加されるたびに、翻訳を更新する必要があります。 リソース効率と言語サポートのバランスが取れていますが、翻訳の更新を慎重に管理する必要があります。

  • 複数の言語に1つの副操縦士 (リアルタイム翻訳): この方法では、リレー副操縦士を使用して実行時にリアルタイム翻訳を提供します。 これにより、より多くの言語を迅速に導入できるようになり、頻繁な翻訳更新の必要性が軽減されます。 ただし、リレー コパイロットと、Azure Service CopilotやAzure Cognitive Services Translatorなどのリアルタイム翻訳 レイヤー への依存関係が導入されます。

重要な考慮事項:

  • 言語と市場: 副操縦士がサポートする必要がある言語と市場は、ローカリゼーション戦略に影響します。

  • 単一言語副操縦士と複数言語副操縦士: 複数の言語をサポートする単一の副操縦士を開発するか、言語ごとに別々の副操縦士を開発するかを決定します。 この決定は、リソースの可用性、メンテナンス 機能、関連する言語の複雑さなどの要因によって異なります。

  • 翻訳のタイミング: 翻訳を構成フェーズ中に設定するか、実行時にリアルタイムで提供するかを検討します。 構成された翻訳は安定性と制御を提供し、リアルタイム翻訳は柔軟性と迅速な展開を提供します。

詳細情報: