次の方法で共有


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

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

インテント認識には、入力の背後にあるユーザーの目標や目的を特定することが含まれます。 たとえば、ユーザーが「フライトを予約したい」と言った場合、その意図はフライトを予約することです。 意図認識は、エージェントがユーザーのリクエストに基づいてどのようなアクションを実行する必要があるかを理解する際に役立ちます。

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

エージェントは、意図を使用してユーザーの目標を理解し、エンティティを使用してタスクを完了するために必要な特定の詳細を特定します。 したがって、意図認識とエンティティ抽出により、エージェントはユーザーのクエリに正確かつ効率的に応答できます。

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

定義

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

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

  • 事前構築済みエンティティとユーザー定義エンティティ: Microsoft 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
  • : ブルー
  • サイズ: ラージ
  • アイテム タイプ: Tシャツ

スロット フィリング は、これらの抽出されたエンティティを使用して、特定のタスクに必要な情報を完成させるプロセスです。 この例では、エージェント はトピックを注文として認識し、抽出されたエンティティを必要なスロットに入力します。 エージェントは、それ以上の質問をすることなくユーザーの要求を理解できるため、インタラクションが合理化されます。

エンティティ抽出とスロット フィリングにより、エージェントは複雑なクエリをより効果的に処理し、正確でコンテキストに関連する応答を提供し、ユーザー エクスペリエンスを向上させることができます。

詳細情報:

Azure CLU と Microsoft Copilot Studio を統合する

CLU モデルを Copilot Studio エージェント と統合すると、エージェントの機能を大幅に強化できます。 この統合では、Azure CLU の意図を Copilot Studio トピックにマッピングし、エージェントがユーザーの意図をより正確に理解し、対応できるようにします。 さらに、Copilot Studio の事前構築済みエンティティは Azure CLU エンティティと共に使用でき、エンティティ抽出のための堅牢なフレームワークを提供します。

この統合を検討するときは、インテリジェント アプリケーションのワークロードに Azure CLU が必要かどうかを評価することが重要です。 たとえば、Azure CLU では、より多くの言語、業界固有の辞書、複雑なエンティティ抽出がサポートされており、これらはアプリケーションにとって不可欠な場合があります。 Azure CLU を使用したカスタム エンティティ抽出では、サイレントまたは「ラッキー」スロット フィリングも可能になり、これにより、エージェントは、追加の質問をすることなく、単一のフレーズで出発地と目的地の両方の都市を特定するといったシナリオに対応できるようになります。

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

詳細情報:

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

トピックを効果的に構成することは、自然でシームレスな会話を生み出すために重要です。 トピックは個別の会話パスであり、組み合わせることでユーザーは エージェント とスムーズに対話できます。 トピックの構造を設計する際の重要な考慮事項を次に示します。

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

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

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

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

設計のアプローチ:

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

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

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

詳細情報:

認識されない意図の処理

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

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

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

  • フォールバックの使用状況の監視: フォールバックにヒットした会話の割合を定期的に確認します。 これらの分析情報を使用して、既存のトピックを充実させたり、新しいトピックを作成したりして、エージェントの理解と応答能力を継続的に向上させます。

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

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

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

ローカライズと言語

エージェントを構築する際は、インテリジェント アプリケーション ワークロードがサポートする必要がある言語と市場を検討してください。 ローカライズと言語サポートは、インテリジェントなアプリケーション ワークロードが多様なユーザー ベースのニーズを確実に満たすための重要な要素です。 ここでは、推奨されるアプローチをいくつか紹介します。

  • 言語ごとに 1 つのエージェント: このアプローチでは、言語ごとに個別のエージェントを作成します。 これにより、各エージェントが特定の言語に完全に最適化されます。ただし、複数のエージェントを維持する際にはリソースを大量に消費する可能性があります。

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

  • 複数の言語に対して 1 つの エージェント (リアルタイム翻訳): この方法では、リレー エージェントを使用して、実行時にリアルタイムの翻訳を提供します。 これにより、より多くの言語を迅速に展開でき、頻繁に翻訳を更新する必要性が軽減されます。 ただし、リレー エージェント と、Azure Service Copilot や Azure Cognitive Services Translator などのリアルタイム変換レイヤーへの依存関係が追加されます。

重要な検討事項:

  • 言語と市場: エージェントがサポートしなければならない言語と市場は、ローカライゼーション戦略に影響を与えます。

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

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

詳細情報: