Partager via

Quand utiliser les applications de flux de travail de compréhension du langage courant ou d’orchestration

  • Article

Lorsque vous créez des applications conséquentes, vous devez déterminer si votre cas d’usage est mieux servi par une seule application conversationnelle (architecture plate) ou par plusieurs applications orchestrées.

Vue d’ensemble de l’orchestration

Le workflow d’orchestration est une fonctionnalité qui vous permet de connecter différents projets de LUIS, de compréhension du langage courant et de réponses aux questions personnalisées dans un projet. Vous pouvez ensuite utiliser ce projet pour les prédictions avec un seul point de terminaison. Le projet d'orchestration prédit quel projet enfant doit être appelé, achemine automatiquement la demande et renvoie sa réponse.

L’orchestration implique deux étapes :

  1. Prédiction du projet enfant à appeler.
  2. Acheminement de l’énoncé vers l’application enfant de destination et retour de la réponse de l’application enfant.

Avantages de l’orchestration

  • Décomposition claire et développement plus rapide :

    • Si votre schéma global comporte un nombre important de domaines, l’approche d’orchestration peut vous aider à décomposer votre application en plusieurs applications enfants (chacune servant un domaine spécifique). Par exemple, une application de conversation dans le secteur automobile peut avoir un domaine de navigation ou un domaine multimédia.
    • Le développement de chaque application de domaine en parallèle est plus facile. Personnes et les équipes ayant une expertise spécifique dans un domaine peuvent travailler sur des applications individuelles en collaboration et en parallèle.
    • Parce que chaque application de domaine est plus petite, le cycle de développement devient plus rapide. Les applications de domaine plus petites prennent beaucoup moins de temps à être entraînées qu’une seule application conséquente.

  • Seuils de score de confiance plus flexibles :

    • Parce qu’il existe des applications enfants distinctes qui servent chaque domaine, il est facile de définir des seuils distincts pour les différentes applications enfants.

  • Améliorations de la qualité de l’IA, le cas échéant :

    • Certaines applications exigent que certaines entités soient limitées au domaine. L’orchestration facilite la réalisation de cette tâche. Une fois que le projet d’orchestration prédit quelle application enfant doit être appelée, les autres applications enfants ne sont pas appelées.

      Par exemple, si votre application contient une entité prédéfinie Person.Name, considérez l’énoncé « Comment utiliser un cric ? » dans le contexte d’une question sur les voitures. Dans ce contexte, cric est un outil faisant partie d’une voiture, et ne doit pas être reconnu comme le nom d’une personne. Lorsque vous utilisez l’orchestration, cet énoncé peut être redirigé vers une application enfant créée pour répondre à ce type de question, qui n’a pas d’entité Person.Name.

Inconvénients de l’orchestration

  • Entités redondantes dans les applications enfants :

    • Si vous avez besoin qu’une entité prédéfinie particulière soit retournée dans tous les énoncés, quel que soit le domaine, par exemple Quantity.Number ou Geography.Location, il n’existe aucun moyen d’ajouter une entité à l’application d’orchestration (il s’agit d’un modèle d’intention uniquement). Vous devez l’ajouter à toutes les applications enfants individuelles.

  • Efficiency:

    • Les applications d’orchestration prennent deux inférences de modèle. Une pour prédire l’application enfant à appeler, et une autre pour la prédiction dans l’application enfant. Les temps d’inférence sont généralement plus lents que les applications uniques avec une architecture plate.

  • Effectuer l’apprentissage/tester le fractionnement pour l’orchestrateur :

    • L’entraînement d’une application d’orchestration ne vous permet pas de répartir avec précision les données entre les jeux de test et les jeux d’entraînement. Par exemple, vous ne pouvez pas entraîner une répartition 90-10 pour l’application enfant A, puis une répartition 80-20 pour l’application enfant B. Cette limitation peut paraître mineure, mais il vaut mieux la garder à l’esprit.

Vue d’ensemble de l’architecture plate

L’architecture plate est l’autre méthode de développement d’applications conversationnelles. Au lieu d’utiliser une application d’orchestration pour envoyer des énoncés à l’une des applications enfants multiples, vous développez une application unique (ou plate) pour gérer les énoncés.

Avantages de l’architecture plate

  • Simplicité :

    • Pour les applications ou les domaines de petite taille, l’approche d’orchestrateur peut être trop complexe.
    • Parce que toutes les intentions et entités se trouvent au même niveau d’application, il peut être plus facile d’apporter des modifications à toutes ensemble.

  • Il est plus facile d’ajouter des entités qui doivent toujours être retournées :

    • Si vous souhaitez que certaines entités prédéfinies ou de liste soient retournées pour tous les énoncés, vous avez juste à les ajouter avec d’autres entités dans une seule application. Si vous utilisez l’orchestration, comme mentionné, vous devez l’ajouter à chaque application enfant.

Inconvénients de l’architecture plate

  • Peu complexe pour les applications volumineuses :

    • Pour les applications conséquentes (par exemple, plus de 50 intentions ou entités), il peut devenir difficile de suivre les schémas et jeux de données en constante évolution. Cette difficulté est évidente dans les cas où l’application doit servir plusieurs domaines. Par exemple, une application de conversation dans le secteur automobile peut avoir un domaine de navigation ou un domaine multimédia.

  • Un contrôle limité sur les correspondances d’entité :

    • Dans une architecture plate, il n’existe aucun moyen de limiter les entités à retourner uniquement dans certains cas. Lorsque vous utilisez l’orchestration, vous pouvez affecter ces entités spécifiques à des applications enfants spécifiques.

Contenu connexe