会話言語理解アプリまたはオーケストレーション ワークフロー アプリを使用する場合

  • [アーティクル]

大規模なアプリケーションを作成する場合、該当のユース ケースに対して最適にサービスを提供するのは、1 つの会話アプリ (フラット アーキテクチャ) か、または調整された複数のアプリかどうかを検討する必要があります。

オーケストレーションの概要

オーケストレーション ワークフローは、LUIS、会話言語理解、カスタム質問応答などのさまざまなプロジェクトを 1 つのプロジェクト内に接続できる機能です。 その後、1 つのエンドポイントを使用して、このプロジェクトを予測に使用できます。 オーケストレーション プロジェクトは、どの子プロジェクトを呼び出す必要があるかを予測し、要求を自動的にルーティングして、応答を返します。

オーケストレーションには、次の 2 つの手順が含まれます。

  1. どの子プロジェクトを呼び出すかを予測する。
  2. 発話を目的の子アプリにルーティングし、子アプリの応答を返す。

オーケストレーションの利点

  • 明解な分解と開発の高速化:

    • スキーマ全体にかなりの数のドメインがある場合、オーケストレーションというアプローチは、アプリケーションを複数の子アプリ (それぞれが特定のドメインに対応) に分解するのに役立ちます。 たとえば、自動車の会話アプリには、"ナビゲーション ドメイン"、"メディア ドメイン" などが含まれる場合があります。
    • 各ドメイン アプリの並列での開発が容易になります。 特定の分野の専門知識を持つ担当者とチームが、個々のアプリを共同で並行して作業できます。
    • 各ドメイン アプリがより小さくなるため、開発サイクルがより速くなります。 複数のより小規模なドメイン アプリは、1 つの大規模なアプリよりもトレーニングにかかる時間がはるかに短くなります。

  • より柔軟な信頼度スコアのしきい値:

    • 各ドメインに個別の子アプリがサービスを提供するため、別々の子アプリに別々のしきい値を簡単に設定できます。

  • 必要に応じた AI 品質の改善:

    • 一部のアプリケーションでは、特定のエンティティをドメインに制限する必要があります。 オーケストレーションを使用すると、このタスクを簡単に実現できます。 オーケストレーション プロジェクトが呼び出す必要のある子アプリを予測した後、他の子アプリは呼び出されません。

      たとえば、アプリに事前構築済みのエンティティ Person.Name が含まれている場合に、車に関する質問のコンテキストにおける "ジャッキ (Jack) はどう使うのですか?" という発話を考えてみましょう。 このコンテキストにおいては、"ジャッキ (Jack)" は自動車の工具であり、人の名前 (ジャック) として認識されるべきではありません。 オーケストレーションを使用すると、このような質問に答えるために作成された (Person.Name エンティティを持たない) 子アプリに、この発話をリダイレクトできます。

オーケストレーションの欠点

  • 子アプリの冗長エンティティ:

    • ドメインに関係なく、すべての発話で特定の事前構築済みエンティティ (たとえば Quantity.Number や Geography.Location) を返す必要がある場合、オーケストレーション アプリ (意図のみのモデルです) にエンティティを追加する方法はありません。 個々の子アプリすべてに追加する必要があります。

  • 「効率性:

    • オーケストレーション アプリは、2 つのモデル推論を受け取ります。 1 つは、どの子アプリを呼び出すかを予測するためのもので、もう 1 つは子アプリ内で予測するためです。 推論時間は、通常、フラット アーキテクチャを使用した 1 つのアプリよりも遅くなります。

  • オーケストレーターのトレーニングとテストの分割:

    • オーケストレーション アプリのトレーニングでは、テストとトレーニングのセット間でデータを細かく分割することはできません。 たとえば、子アプリ A に 90 対 10 の分割でトレーニングしてから、子アプリ B に 80 対 20 の分割でトレーニングすることはできません。この制限は些細なものかもしれませんが、覚えておく価値はあります。

フラット アーキテクチャの概要

フラット アーキテクチャは、会話アプリを開発するもう 1 つの方法です。 オーケストレーション アプリを使用して複数の子アプリのいずれかに発話を送信するのではなく、発話を処理する単一の (またはフラットな) アプリを開発します。

フラット アーキテクチャの利点

  • シンプルさ:

    • 小さいサイズのアプリまたはドメインの場合、オーケストレーターのアプローチは過度に複雑になる場合があります。
    • すべての意図とエンティティが同じアプリ レベルにあるため、それらすべてにまとめて変更を加えることが簡単になる場合があります。

  • 常に返される必要があるエンティティを追加することが簡単になります。

    • すべての発話に対して特定の事前構築済みまたはリストのエンティティを返す場合は、それを 1 つのアプリ内に、他のエンティティと共に追加するだけで済みます。 前述のようにオーケストレーションを使用する場合は、それをすべての子アプリに追加する必要があります。

フラット アーキテクチャの欠点

  • 大規模なアプリでは扱いにくい:

    • 大規模なアプリ (50 を超える意図またはエンティティがある、など) の場合、スキーマとデータセットの発展を追跡することが困難になる場合があります。 この困難さは、アプリが複数のドメインにサービスを提供する必要がある場合に明らかになります。 たとえば、自動車の会話アプリには、"ナビゲーション ドメイン"、"メディア ドメイン" などが含まれる場合があります。

  • エンティティの一致に対する制限された制御:

    • フラット アーキテクチャでは、特定の場合にのみエンティティを返すように制限する方法はありません。 オーケストレーションを使用する場合は、それらの特定のエンティティを特定の子アプリに割り当てることができます。

関連するコンテンツ