LUIS アプリの計画

  • [アーティクル]

重要

LUIS は 2025 年 10 月 1 日に廃止され、2023 年 4 月 1 日から新しい LUIS リソースを作成できなくなります。 継続的な製品サポートと多言語機能のベネフィットを得るために、LUIS アプリケーションを会話言語理解に移行することをお勧めします。

Language Understanding (LUIS) アプリ スキーマには、サブジェクト ドメインに関連する意図とエンティティが含まれています。 意図はユーザーの発話を分類し、エンティティはユーザー発話からデータを抽出します。 サブジェクト ドメインに関連する意図とエンティティ。 意図により、ユーザーの発話が分類されます。

LUIS アプリは、反復的に開発すると、最も効率的に学習して実行します。 次に、一般的な反復サイクルを示します。

  1. 新しいバージョンを作成する
  2. LUIS アプリ スキーマを編集する。 これには次のものが含まれます
    • 発話の例が含まれる意図
    • エンティティ
    • 特徴
  3. トレーニング、テスト、公開
  4. 予測エンドポイントに送信された発話を確認して、アクティブ ラーニングをテストします。
  5. エンドポイント クエリからデータを収集する

作成サイクルを示すスクリーンショット

ドメインの特定

LUIS アプリはサブジェクト ドメインが中心です。 たとえば、チケット、フライト、ホテル、およびレンタカーの予約を処理する旅行アプリがあります。 また、エクササイズ、フィットネスの努力の追跡、目標設定に関連するコンテンツを提供するアプリなどもあります。 ドメインを特定することで、ドメインに関連する単語やフレーズを見つけやすくなります。

ヒント

LUIS には、多くの一般的なシナリオに対応する事前構築済みのドメインが用意されています。 事前構築されたドメインをベースに、ご自身のアプリを作成できるかどうかを検討してください。

意図の特定

ご自身のアプリケーションのタスクにとって重要な意図について考えます。

たとえば、フライトを予約し、目的地の天気を確認する機能を備えた旅行アプリの例で見てみましょう。 これらのアクションに対して BookFlight と GetWeather の 2 つの意図を定義できます。

さらに多くの機能を備えたより複雑なアプリでは、意図がさらに多くなる可能性が高いため、意図を定義するときは、細かくなりすぎないように気を付ける必要があります。 たとえば、BookFlight と BookHotel はそれぞれ別の意図にする必要があると思われますが、BookInternationalFlight と BookDomesticFlight は非常に似ています。

注意

使用する意図の数は、ご自身のアプリで実行する必要がある機能の数に合わせることをお勧めします。 定義する意図が多すぎると、LUIS で発話を正しく分類するのが難しくなります。 少なすぎると、一般的になりすぎて、重複する可能性があります。

全体的なユーザーの意図を特定する必要がない場合は、すべてのユーザーの発話例を None の意図に追加します。 アプリで必要な意図が増えた場合は、後で作成できます。

各意図の発話の例の作成

最初は、意図ごとに発話を作成し過ぎないようにします。 アプリで必要な意図を特定したら、意図ごとに 15 個から 30 個の発話の例を作成します。 各発話は、以前に提供された発話とは異なる必要があります。 さまざまな単語数、単語の選択、動詞の時制、句読点を含めます。

詳細については、LUIS アプリに適した発話の概要に関する記事を参照してください。

エンティティの特定

発話の例では、抽出するエンティティを特定します。 フライトを予約するには、目的地、日付、航空会社、チケットの種類、搭乗クラスなどの情報が必要です。 これらのデータ型のエンティティを作成し、発話例のエンティティをマークします。 意図を達成するにはエンティティが重要です。

どのエンティティをアプリで使用するかを判断するときは、オブジェクトの種類の間の関係を把握するための多種多様なエンティティがあることに留意してください。 さまざまな種類の詳細については、「LUIS のエンティティ」を参照してください。

ヒント

LUIS には、一般的な会話ユーザーのシナリオに合わせて構築済みのエンティティが用意されています。 アプリケーション開発の出発点として、構築済みのエンティティを使用することを検討してください。

意図とエンティティ

意図は、発話 全体 の目的とする結果であり、エンティティは発話から抽出されたデータの一部です。 通常、意図はクライアント アプリケーションで実行する必要があるアクションに関連付けられています。 エンティティは、このアクションを実行するために必要な情報です。 プログラミングの観点からは、意図によってメソッドの呼び出しがトリガーされ、そのエンティティがメソッド呼び出しのパラメーターとして使用されます。

この発話は、意図を持つ 必要があり、多くのエンティティを持つ 場合があります。

"シアトルからカイロの航空券を購入する"

この発話には 1 つの意図があります。

  • 航空券の購入

この発話にはいくつかのエンティティがある 場合があります。

  • シアトル (出発地) とカイロ (目的先) の場所
  • 1 つのチケットの枚数

複数の機能または意図を持つ発話の解決

多くの場合、特に自然な会話を操作するときには、ユーザーは複数の機能 (つまり、意図) を含む可能性がある発話を提供します。 これに対処するための一般的な方法は、出力を意図とエンティティの両方で表すことができることを理解することです。 この表現は、クライアント アプリケーションのアクションにマッピングできる必要があり、意図に限定される必要はありません。

Int-ent-ties は、アクション (通常は意図として理解される) が、アプリの出力でエンティティとしてもキャプチャされ、特定のアクションにマップされるという概念です。 "たとえば、否定は、一般的に"、完全な抽出のために意図とエンティティに依存します。 次の 2 つの発話について考えてみます。非常によく似た単語の選択ですが、結果は異なります。

  • "カイロからシアトルへのフライトをスケジュールしてください"
  • "カイロからシアトルへのフライトをキャンセルしてください"

2 つの別々の意図を使用する代わりに、FlightAction 機械学習エンティティを使用して 1 つの意図を作成する必要があります。 この機械学習エンティティでは、スケジュールおよびキャンセルの両方の要求に対するアクションの詳細と、出発地または到着地のどちらかを抽出する必要があります。

この FlightAction エンティティは、次の最上位機械学習エンティティとサブエンティティで構成されます。

  • FlightAction
    • アクション
    • 出発地
    • 到着地

抽出に役立つように、サブエンティティに特徴を追加します。 ユーザーの発話で予想されるボキャブラリと、予測応答で返す必要がある値に基づいて、特徴を選択します。

ベスト プラクティス

スキーマを計画する

アプリのスキーマを作成し始める前に、このアプリを使用する方法と場所を特定する必要があります。 詳細かつ具体的な計画を立てると、アプリの品質が向上します。

  • 対象ユーザーを調査する
  • アプリを表すエンドツーエンドのペルソナ - 音声、アバター、問題処理 (プロアクティブ、リアクティブ) - を定義する
  • ユーザー操作のチャネル (テキスト、音声など)、既存のソリューションに送るか、それともこのアプリのために新しいソリューションを作成するかを識別する
  • エンドツーエンドのユーザー体験
    • このアプリは何をする/しないことが予想されますか。 実行すべき動作の優先順位は何ですか。
    • 主なユース ケース
  • データの収集 - データの収集と準備について学習する

やってはいけないこと: すべての発話の例でトレーニングして公開する

10 ～ 15 個の発話を追加したら、トレーニングして公開します。 これにより、予測精度への影響を確認することができます。 1 つの発話を追加しても、スコアに目に見える影響は出ない可能性があります。

やってはいけないこと: LUIS をトレーニング プラットフォームとして使用する

LUIS は、言語モデルのドメインに固有です。 一般的な自然言語トレーニング プラットフォームとして動作するようには作られていません。

バージョンを使用してアプリを反復的にビルドする

各作成サイクルは、既存のバージョンから複製された新しいバージョン内に含める必要があります。

やってはいけないこと: 公開を急ぎすぎる

適切な計画を立てずにアプリの公開を急ぎすぎると、次のようないくつかの問題が発生する可能性があります。

  • 実際のシナリオでは、許容されるパフォーマンス レベルでアプリが動作しない。
  • スキーマ (意図とエンティティ) が不適切。そのスキーマに従ってクライアント アプリのロジックを開発していた場合、やり直しが必要になる可能性があります。 これは、作業中のプロジェクトの予期しない遅延や、余計なコストにつながる恐れがあります。
  • モデルに追加した発話が、サンプル発話に対する偏りの原因となり、デバッグや識別が困難になる。 このことが原因で、特定のスキーマにコミットすると、あいまいさを排除することが困難になる場合もあります。

すべきこと: ご自身のアプリのパフォーマンスを監視する

バッチ テスト セットを使用して予測精度を監視します。

発話の例またはエンドポイント発話として使用されていない発話のセットを個別に保持します。 ご自身のテスト セット用のアプリは改善し続けてください。 実際のユーザーの発話が反映されるようにテスト セットを調整します。 このテスト セットを使用して、アプリの各イテレーションまたはバージョンを評価します。

考えられるすべての値を含むフレーズ リストを作成しない

フレーズ リストには数個の例を提供します。すべての単語またはフレーズではありません。 LUIS で汎用化が行われ、コンテキストが考慮されます。

次の手順

意図