
Partager:
Benjamin Aronov est un défenseur des développeurs chez Vonage. C'est un bâtisseur de communauté qui a fait ses preuves, avec une formation en Ruby on Rails. Benjamin apprécie les plages de Tel Aviv, où il vit. Sa base à Tel Aviv lui permet de rencontrer et d'apprendre de certains des meilleurs fondateurs de startups du monde. En dehors de la technologie, Benjamin aime voyager à travers le monde à la recherche du parfait pain au chocolat.
Comment construire une hiérarchie de classification des intentions
Temps de lecture : 11 minutes
Les agents conversationnels d'IA sont un excellent moyen d'économiser la ressource la plus importante de votre entreprise : le temps de vos employés ! Les agents sont comme des FAQ interactives, mais ils sont beaucoup plus flexibles. Lorsqu'ils sont conçus correctement, ils peuvent contribuer à améliorer considérablement l'expérience de vos clients. Mais la question est de savoir comment les concevoir correctement.
Heureusement, l'équipe d'AI Studio a fait le travail pour vous ! Nous avons été en mesure d'améliorer considérablement les performances des agents d'IA de grande taille (plus de 50 intentions). Ces techniques ont permis à certains agents d'augmenter de 55 % le nombre d'appels réussis et de réduire de 83 % le nombre de demandes adressées à des agents humains.
Ce billet explique comment construire une hiérarchie dans la Classification des intentions afin d'améliorer les performances de vos agents en acheminant les utilisateurs vers la bonne intention. Les sujets abordés incluront les meilleures pratiques NLU générales, des exemples de construction d'une classification hiérarchique et des conseils sur la conception de votre agent d'IA conversationnelle dans AI Studio.
Bonnes pratiques NLU
Qu'est-ce que le NLU ? La compréhension du langage naturelou NLU, est le processus qui permet à un ordinateur de comprendre l'intention d'un texte. La compréhension du langage naturel est la manière dont un ordinateur comprend ce que l'utilisateur veut dire lorsqu'il parle avec l'ordinateur. Le logiciel y parvient grâce à la classification de l'intention et à l'extraction d'entités.
Chevauchement et ambiguïté des intentions
La classification des intentions semble assez simple, n'est-ce pas ? L'agent se contente de décomposer les données fournies par l'utilisateur et de les faire correspondre aux intentions définies. Mais dans la pratique, il est très facile de confondre le modèle.
Considérons le scénario d'un agent conçu pour une institution financière telle qu'une banque. Dans ce contexte, les clients peuvent initier diverses interactions liées aux prêts, telles qu'une demande de prêt, la vérification de l'état du prêt ou la recherche d'informations générales sur le prêt.
Le problème se pose lorsque des termes tels que "prêt" ou "hypothèque" sont employés dans divers contextes, par exemple dans des expressions telles que "parler avec un représentant hypothécaire" ou "obtenir une offre d'hypothèque". Cette utilisation généralisée des mêmes mots clés au sein d'un seul nœud de classification peut potentiellement entraîner une classification erronée par le modèle.
Pour atténuer ce problème, nous proposons de mettre en œuvre une structure hiérarchique à deux niveaux, comprenant essentiellement deux nœuds de classification. La première couche se concentrerait sur la classification du concept de base, tel que "prêt" ou "hypothèque", tandis que la deuxième couche se spécialiserait dans le discernement de l'action ou de l'intention spécifique associée à la requête de l'utilisateur (demande, statut, représentant, etc.). Cette approche hiérarchique vise à améliorer la précision du modèle et à réduire la probabilité d'une classification erronée d'intentions similaires mais contextuellement distinctes.
Intent Overlap & Ambiguity
Cohérence de l'ensemble d'entraînement
En outre, étant donné que les ensembles de formation qui composent chaque intention auront des expressions très similaires, nous devons être extrêmement cohérents. L'ajout de mots ambigus dans vos ensembles de formation peut entraîner un comportement inattendu s'il est appliqué de manière incohérente.
Imaginons par exemple que votre intention de demande (de prêt) contienne l'expression "Je veux demander un prêt". Un utilisateur demande alors à votre agent "Je veux demander l'état d'un prêt", ce qui devrait l'amener à l'intention (Prêt) État. À moins que votre ensemble de données d'apprentissage pour Status ne comprenne une expression contenant les mots "I want to" et "loan", il y a une très forte probabilité qu'il soit routé de manière incorrecte vers Request. Pour résoudre ce problème, vos données d'apprentissage doivent être extrêmement cohérentes en ce qui concerne les mots de remplissage/de soutien ambigus. Il faut donc soit les ajouter partout, soit les supprimer partout. Il est souvent plus facile de l'omettre.
Training Set Consistency
Étude de cas sur les ensembles de formation : Ventes et assistance à la clientèle
Imaginons maintenant que nous voulions ajouter deux nouvelles intentions à notre agent bancaire : Call Back et Sales. Call Back est destiné aux utilisateurs qui souhaitent qu'un représentant du service clientèle les rappelle et Sales est destiné aux utilisateurs qui souhaitent qu'un représentant du service commercial les rappelle.
Inconsistent Training Example
Nous nous attendons à ce que tous les éléments suivants soient classés comme "ventes" :
Je souhaite parler à un représentant commercial
vous souhaitez parler à un représentant commercial
avec un représentant commercial
représentant des ventes
Cependant, comme nous le voyons dans le diagramme, les deux premières entrées d'utilisateur qui contiennent "vouloir parler avec" finissent par être classées comme "rappel". Cela s'explique par le fait que les mots "parler avec" sont plus proches du rappel que de la vente.
La solution consiste à ajouter des données de formation à notre intention de "vente" qui contient "vouloir parler avec". Ces données doivent être dans la même proportion que les données d'entraînement pour des données d'entraînement similaires dans l'ensemble d'entraînement "call back".
Dans un agent plus complexe, ces deux intentions peuvent sembler très similaires par rapport à d'autres intentions. Nous verrons bientôt comment la classification hiérarchique aidera notre agent à faire cette distinction plus granulaire.
Qu'est-ce que la classification hiérarchique ?
Assainir nos intentions pour éviter les chevauchements d'intentions et s'assurer que nos ensembles de formation sont cohérents est un bon début pour améliorer la classification, mais lorsque nous commencerons à avoir des agents avec beaucoup d'intentions, cela ne suffira pas car le monde est plein de chevauchements inévitables. Et ces satanés utilisateurs ne se comportent jamais comme nous le souhaitons !
La classification hiérarchique est utile pour ces agents à grande échelle, car elle crée des niveaux de classification pour concentrer la classification sur une seule variable ou un seul sujet à la fois. La classification par étapes permet à l'agent d'être plus efficace en classant les intentions dans des groupes en fonction de leurs principaux facteurs de différenciation. Le regroupement en fonction de la plus grande différenciation permet d'éliminer les chevauchements et les ambiguïtés.
Comment regrouper les intentions dans une classification hiérarchique ?
La décomposition de notre classification en étapes peut sembler simple, mais nous constatons rapidement qu'il existe différentes façons de regrouper les intentions. Nous pouvons les regrouper soit par leurs noms, soit par leurs verbes.
Les noms sont les éléments de votre agent sur lesquels un utilisateur peut se renseigner. Il s'agit de l'objet direct de sa demande. Il s'agit le plus souvent des produits ou des services proposés par votre entreprise. Voici quelques exemples de noms : "départ tardif", "forfait anniversaire" et "consultation 1:1".
Les verbes, quant à eux, représentent l'action que quelqu'un veut entreprendre sur le nom. Considérez les différences entre les demandes des clients "RÉSERVER une réservation", "ANNULER une réservation" et "MODIFIER une réservation".
Étude de cas : Regroupement par nom ou par verbe
Imaginons que nous élargissions le scénario de notre banque. Au lieu de proposer uniquement des prêts, nous voulons commencer à proposer des assurances. Pour l'assurance, nous donnons également à l'utilisateur la possibilité de demander une assurance, de vérifier le statut de l'assurance et d'obtenir des informations générales sur l'assurance. Notre classificateur doit maintenant comparer les données de l'utilisateur avec de nombreuses données d'apprentissage qui, par nature, commenceront à se chevaucher.
C'est précisément dans ce scénario que la hiérarchie améliorera les performances de notre agent. La première étape consiste à regrouper nos sujets. Dans cet exemple, nous avons plusieurs façons de regrouper les sujets. Nous pouvons les regrouper par produit ou par service.
Ce diagramme illustre la manière dont nous pouvons regrouper les verbes :
Hierarchy Grouped By Verbs
Bien que les groupes soient logiques et que nous puissions passer le classificateur initial avec des résultats élevés, que se passera-t-il lors de la deuxième étape de la classification ? Comme nous l'avons vu précédemment, le classificateur rencontrera des difficultés lors de la deuxième étape, car une grande ambiguïté est probable lorsqu'il s'agit de comparer des entrées utilisateur telles que des instructions de prêt et des instructions d'assurance. Dans ces cas, les ensembles de formation se chevaucheront fortement et nous devrons être très méticuleux pour maintenir la cohérence des données.
Essayons maintenant de voir ce qui se passe lorsque nous regroupons les intentions par noms :
Hierarchy Grouped By Nouns
Ce que nous voyons ici, c'est que non seulement nous supprimons une couche de complexité en différenciant immédiatement le support et les ventes, mais plus important encore, nous créons des groupements dans le deuxième tour qui sont beaucoup plus faciles à classer. Dans chaque groupe de prêts et d'assurances, chaque intention peut être réduite de manière à ce qu'il y ait très peu de chevauchements, comme nous l'avons fait précédemment.
Comment créer une classification hiérarchique
Maintenant que vous avez compris la théorie, passons à la pratique.
Étape 1 : Rassembler ou créer un ensemble de formation idéalisé
Si vous disposez de données réelles, vous avez une longueur d'avance ! Passez à l'étape 2, vous pouvez vous concentrer sur les données d'entraînement de base et laisser de côté les données aberrantes pour l'instant.
Sinon, imaginez que vos utilisateurs parlent sans utiliser de mots de remplissage ou de mots supplémentaires inutiles. Écrivez maintenant toutes les expressions d'utilisateurs auxquelles vous pouvez penser. Il s'agit de votre ensemble d'entraînement idéalisé.
Imaginez tous les synonymes possibles pour vos produits/offres.
Exemple : chambre/réservation/réservation/séjour
Étape 2 : Organiser vos données idéalisées en grands groupes
Tout comme nous avons organisé les thèmes de la Banque en grands groupes autour des noms, vous devez également regrouper vos thèmes en grandes catégories de noms/phrases nominales. À ce stade, vous pouvez commencer à identifier les verbes/verbes d'accompagnement.
Dans le monde réel, les utilisateurs se comportent un peu comme des hommes des cavernes. Très souvent, ils répondent par des mots isolés, beaucoup plus souvent des noms que des verbes. Le regroupement autour des noms permet d'obtenir de bien meilleures performances.
Où se trouve le plus grand potentiel d'ambiguïté ? Pour les cas très ambigus, ajoutez des données de formation afin de normaliser et de créer des phrases uniformes dans les différents groupes. Tout comme dans l'exemple des intentions de vente et de rappel ci-dessus, normalisez les données de formation pour les groupes à forte ambiguïté.
Étape 3 : Traiter les valeurs aberrantes
Après avoir résolu la plupart des cas d'utilisation, il se peut que vous ayez encore des intentions qui n'entrent pas dans le cadre de vos thèmes généraux. Où devez-vous les Account ?
Vous devez ajouter ces intentions au moment où elles ont le plus de chances d'être annulées par votre modèle. Supposons que vous ayez un agent pour un nutritionniste et que l'une de vos intentions soit d'acheter des aliments sains. Cependant, un utilisateur demande : "Puis-je commander une pizza ?". Le modèle poussera probablement l'utilisateur vers l'intention "Aliments sains", même si une pizza ne devrait pas s'y trouver. Voir le diagramme :
Classification Hierarchy: Nutritionist Example
Notre solution consiste à créer une nouvelle intention "négative" pour capturer le comportement par défaut et l'acheminer en conséquence. Nous créons donc une intention "Aliments malsains" qui capturera ces cas "négatifs" et les dirigera vers le bon flux. Notre classification mise à jour :
Classification Negative Intent Example
Considérations relatives à la conception dans AI Studio
Utilisation des sous-flux dans AI Studio
AI Studio permet de démarrer rapidement et de commencer à construire des agents avec des nœuds par glisser-déposer. Toutefois, lorsque votre agent commence à prendre de l'ampleur, il devient très difficile de suivre des dizaines ou des centaines de nœuds. Non seulement l'organisation des agents deviendra ingérable, mais le Studio commencera à devenir lent dans la fenêtre du navigateur, en chargeant un grand nombre de nœuds.
Il est préférable d'anticiper ces problèmes en planifiant votre agent à l'avance et en utilisant la fonction Fonctionnalité de sous-débit. Pour les meilleures pratiques, chaque intention devrait avoir son propre sous-flux. Chacun de ces sous-flux se rejoindra au niveau d'un groupe de sujets. Chacun de ces groupes remontera ensuite à un niveau principal. La création d'une classification hiérarchique avant de commencer à travailler facilite l'organisation des sous-flux et permet d'éviter de créer une dette technique future.
Répétition des intentions dans plusieurs flux
Après avoir créé la première version de votre agent, vous pouvez constater que votre hiérarchie présente des "fuites". Un petit nombre d'utilisateurs peut se retrouver accidentellement dans le mauvais flux. Au lieu de vous casser la tête à repenser le modèle hiérarchique parfait, il suffit de "suivre le courant".
Prenons l'exemple d'un hôtel qui propose un restaurant haut de gamme appelé "Eagles Nest". Les utilisateurs demanderont "offre premium pour l'hôtel" ou utiliseront une autre terminologie parce qu'ils ne savent pas qu'il s'agit du "Nid d'aigle". Il existait un classificateur de haut niveau pour l'hôtel et un classificateur de haut niveau pour le "Nid d'aigle". Il y avait tellement de données d'entraînement pour l'hôtel que les demandes des utilisateurs aboutissaient souvent à l'hôtel au lieu du nid d'aigle. Ainsi, au lieu de reconcevoir l'ensemble de l'agent, nous pouvons ajouter un sous-flux dans l'hôtel, qui renvoie ensuite au nid d'aigle. Dans l'agent final, ce sous-flux peut se trouver à 3 ou 4 endroits différents, car tout dépend de la manière dont l'utilisateur le demande.
Traitement des requêtes larges
Outre le fait que les utilisateurs donnent des informations trop simplistes, il arrive souvent qu'ils indiquent le sujet de leur question plutôt qu'une question détaillée. Un bon moyen de gérer cette situation et d'améliorer l'expérience de l'utilisateur est de créer une intention "attrape" à votre niveau de classification le plus élevé.
Par exemple, au lieu de dire "Je veux prendre rendez-vous avec le Dr Smith pour une intervention chirurgicale", ils diront "Question sur le rendez-vous" ou "Question sur l'intervention chirurgicale".
Question Deflection Example
Nous avons constaté que l'ajout de ce simple fourre-tout pour les entrées relatives aux questions a contribué à donner confiance aux utilisateurs dans la capacité de l'agent virtuel à les aider.
Conclusion
Maintenant que vous avez vu la puissance de la hiérarchie de classification dans les agents d'IA conversationnelle, vous pouvez faire en sorte que vos agents répondent beaucoup mieux à vos utilisateurs ! Souvenez-vous de ces étapes et vous serez le héros de votre entreprise :
Examiner les données de formation
Organiser les données, identifier les zones à fort potentiel d'ambiguïté
Créer une classification hiérarchique
Agent de développement
Test, test, test
Si vous avez apprécié cet article, faites-le nous savoir sur Vonage Developer Communauté Slack. Cet article a été inspiré par une question d'un membre de la communauté ! Vous pouvez également nous suivre sur X, anciennement connu sous le nom de Twitterpour connaître les dernières nouvelles concernant l'API de Vonage.
Ressources complémentaires
Partager:
Benjamin Aronov est un défenseur des développeurs chez Vonage. C'est un bâtisseur de communauté qui a fait ses preuves, avec une formation en Ruby on Rails. Benjamin apprécie les plages de Tel Aviv, où il vit. Sa base à Tel Aviv lui permet de rencontrer et d'apprendre de certains des meilleurs fondateurs de startups du monde. En dehors de la technologie, Benjamin aime voyager à travers le monde à la recherche du parfait pain au chocolat.