Logo Zéphyrnet

Intelligence de données générative

AI

Améliorez Amazon Connect et Lex avec des capacités d'IA générative | Services Web Amazon

Republié par Platon
Republié par Platon

Date :

Vues: 83

Des options de libre-service efficaces deviennent de plus en plus essentielles pour les centres de contact, mais leur bonne mise en œuvre présente des défis uniques.

Amazon Lex fournit votre Connexion Amazon centre de contact avec des fonctionnalités de chatbot telles que des capacités de reconnaissance vocale automatique (ASR) et de compréhension du langage naturel (NLU) via des canaux vocaux et textuels. Le robot prend en compte la parole ou la saisie de texte en langage naturel, reconnaît l'intention derrière la saisie et répond à l'intention de l'utilisateur en appelant la réponse appropriée.

Les appelants peuvent avoir des accents, une prononciation et une grammaire différents. Combiné au bruit de fond, cela peut rendre difficile la reconnaissance vocale pour comprendre avec précision les déclarations. Par exemple, « Je souhaite suivre ma commande » peut être confondu avec « Je souhaite transporter mon titulaire par camion ». De telles tentatives qui échouent frustrent les clients qui doivent se répéter, sont mal acheminés ou sont transmis à des agents réels, ce qui coûte plus cher aux entreprises.

Socle amazonien démocratise l'accès au modèle de base (FM) pour permettre aux développeurs de créer et de faire évoluer sans effort des applications génératives basées sur l'IA pour le centre de contact moderne. FM fournis par Amazon Bedrock, tels que Titan d'Amazonie ainsi que Anthropique Claude, sont pré-entraînés sur des ensembles de données à l'échelle Internet, ce qui leur confère de solides capacités NLU telles que la classification des phrases, les questions et réponses et une compréhension sémantique améliorée malgré les erreurs de reconnaissance vocale.

Dans cet article, nous explorons une solution qui utilise les FM fournis par Amazon Bedrock pour améliorer la reconnaissance des intentions d'Amazon Lex intégré à Amazon Connect, offrant ainsi une expérience en libre-service améliorée à vos clients.

Présentation de la solution

La solution utilise Connexion Amazon, Amazon Lex , AWS Lambdaet Socle amazonien dans les étapes suivantes :

  1. Un flux de contacts Amazon Connect s'intègre à un bot Amazon Lex via le GetCustomerInput bloque.
  2. Lorsque le bot ne parvient pas à reconnaître l'intention de l'appelant et utilise par défaut l'intention de secours, une fonction Lambda est déclenchée.
  3. La fonction Lambda prend la transcription de l'énoncé du client et la transmet à un modèle de base dans Amazon Bedrock.
  4. Grâce à ses capacités avancées de langage naturel, le modèle détermine l'intention de l'appelant.
  5. La fonction Lambda demande ensuite au bot d'acheminer l'appel vers la bonne intention d'exécution.

En utilisant les modèles de base Amazon Bedrock, la solution permet au robot Amazon Lex de comprendre les intentions malgré les erreurs de reconnaissance vocale. Cela permet un acheminement et une exécution fluides, évitant ainsi les escalades vers les agents et les répétitions frustrantes pour les appelants.

Le diagramme suivant illustre l'architecture et le flux de travail de la solution.

Dans les sections suivantes, nous examinons plus en détail les composants clés de la solution.

Fonctions Lambda et LangChain Framework

Lorsque le robot Amazon Lex appelle la fonction Lambda, il envoie un message d'événement contenant des informations sur le robot et la transcription de l'énoncé de l'appelant. À l'aide de ce message d'événement, la fonction Lambda récupère dynamiquement les intentions configurées, la description de l'intention et les énoncés d'intention du bot et crée une invite à l'aide de LangChaîne, qui est un framework d'apprentissage automatique (ML) open source qui permet aux développeurs d'intégrer des modèles de langage étendus (LLM), des sources de données et des applications.

Un modèle de fondation Amazon Bedrock est ensuite appelé à l'aide de l'invite et une réponse est reçue avec l'intention et le niveau de confiance prévus. Si le niveau de confiance est supérieur à un seuil défini, par exemple 80 %, la fonction renvoie l'intention identifiée à Amazon Lex avec une action pour déléguer. Si le niveau de confiance est inférieur au seuil, il revient par défaut au niveau par défaut FallbackIntent et une action pour le fermer.

Apprentissage en contexte, ingénierie rapide et appel de modèle

Nous utilisons l'apprentissage en contexte pour pouvoir utiliser un modèle de base pour accomplir cette tâche. L'apprentissage en contexte est la capacité des LLM à apprendre la tâche en utilisant uniquement ce qui est contenu dans l'invite sans être pré-formé ou affiné pour la tâche particulière.

Dans l'invite, nous fournissons d'abord les instructions détaillant ce qui doit être fait. Ensuite, la fonction Lambda récupère et injecte dynamiquement les intentions configurées, les descriptions d'intention et les énoncés d'intention du bot Amazon Lex dans l'invite. Enfin, nous lui fournissons des instructions sur la manière de produire sa réflexion et son résultat final.

Le modèle d'invite suivant a été testé sur les modèles de génération de texte Anthropic Claude Instant v1.2 et Anthropic Claude v2. Nous utilisons des balises XML pour mieux améliorer les performances du modèle. Nous ajoutons également un espace de réflexion au modèle avant d'identifier l'intention finale afin de mieux améliorer son raisonnement pour choisir la bonne intention. Le {intent_block} contient les ID d'intention, les descriptions d'intention et les énoncés d'intention. Le {input} Le bloc contient l’énoncé transcrit de l’appelant. Trois backticks (« `) sont ajoutés à la fin pour aider le modèle à générer un bloc de code de manière plus cohérente. UN <STOP> une séquence est ajoutée pour l’empêcher de générer davantage.

"""
Human: You are a call center agent. You try to understand the intent given an utterance from the caller.

The available intents are as follows, the intent of the caller is highly likely to be one of these.
<intents>
{intents_block} </intents>
The output format is:
<thinking>
</thinking>

<output>
{{
     "intent_id": intent_id,
     "confidence": confidence
}}
</output><STOP>

For the given utterance, you try to categorize the intent of the caller to be one of the intents in <intents></intents> tags.
If it does not match any intents or the utterance is blank, respond with FALLBCKINT and confidence of 1.0.
Respond with the intent name and confidence between 0.0 and 1.0.
Put your thinking in <thinking></thinking> tags before deciding on the intent.

Utterance: {input}

Assistant: ```"""

Une fois le modèle invoqué, nous recevons la réponse suivante du modèle de base :

<thinking>
The given utterance is asking for checking where their shipment is. It matches the intent order status.
</thinking>

{
    "intent": "ORDERSTATUSID",
    "confidence": 1.0
}
```

Filtrer les intentions disponibles en fonction des attributs de session de flux de contacts

Lorsque vous utilisez la solution dans le cadre d'un flux de contacts Amazon Connect, vous pouvez améliorer encore la capacité du LLM à identifier l'intention correcte en spécifiant l'attribut de session. available_intents dans l' "Obtenir l'avis des clients" bloquer avec une liste d’intentions séparées par des virgules, comme indiqué dans la capture d’écran suivante. Ce faisant, la fonction Lambda inclura uniquement ces intentions spécifiées dans le cadre de l'invite du LLM, réduisant ainsi le nombre d'intentions que le LLM doit raisonner. Si la available_intents L'attribut de session n'est pas spécifié, toutes les intentions du bot Amazon Lex seront utilisées par défaut.

Réponse de la fonction Lambda à Amazon Lex

Une fois que le LLM a déterminé l'intention, la fonction Lambda répond dans le message format spécifique requis par Amazon Lex pour traiter la réponse.

Si une intention correspondante est trouvée au-dessus du seuil de confiance, elle renvoie un type d'action de dialogue Delegate pour demander à Amazon Lex d'utiliser l'intention sélectionnée, puis de renvoyer l'intention terminée à Amazon Connect. Le résultat de la réponse est le suivant :

{
    "sessionState": {
        "dialogAction": {
        "type": "Delegate"
        },
        "intent": {
        "name": intent,
        "state": "InProgress",
        }
    }
}

Si le niveau de confiance est inférieur au seuil ou si une intention n'a pas été reconnue, un type d'action de dialogue Fermer est renvoyé pour demander à Amazon Lex de fermer le FallbackIntent, puis restituez le contrôle à Amazon Connect. Le résultat de la réponse est le suivant :

{
    "sessionState": {
        "dialogAction": {
        "type": "Close"
        },
        "intent": {
        "name": intent,
        "state": "Fulfilled",
        }
    }
}

Le code source complet de cet exemple est disponible dans GitHub.

Pré-requis

Avant de commencer, assurez-vous que vous disposez des conditions préalables suivantes:

Mettre en œuvre la solution

Pour implémenter la solution, procédez comme suit:

  1. Cloner le référentiel 
    git clone https://github.com/aws-samples/amazon-connect-with-amazon-lex-genai-capabilities
cd amazon-connect-with-amazon-lex-genai-capabilities

  2. Exécutez la commande suivante pour initialiser l'environnement et créer un Registre des conteneurs élastiques Amazon (Amazon ECR) pour l'image de notre fonction Lambda. Fournissez la région AWS et le nom du référentiel ECR que vous souhaitez créer. 
    bash ./scripts/build.sh region-name repository-name

  3. Mettre à jour le ParameterValue champs dans le scripts/parameters.json fichier:
    • ParameterKey ("AmazonECRImageUri") – Saisissez l'URL du référentiel de l'étape précédente.
    • ParameterKey ("AmazonConnectName") – Saisissez un nom unique.
    • ParameterKey ("AmazonLexBotName") – Saisissez un nom unique.
    • ParameterKey ("AmazonLexBotAliasName") – La valeur par défaut est « prodversion » ; vous pouvez le modifier si nécessaire.
    • ParameterKey ("LoggingLevel") – La valeur par défaut est « INFO » ; vous pouvez le modifier si nécessaire. Les valeurs valides sont DEBUG, WARN et ERROR.
    • ParameterKey ("ModelID") – La valeur par défaut est « anthropic.claude-instant-v1 » ; vous pouvez le modifier si vous devez utiliser un modèle différent.
    • ParameterKey ("AmazonConnectName") – La valeur par défaut est « 0.75 » ; vous pouvez le modifier si vous devez mettre à jour le score de confiance.
  4. Exécutez la commande pour générer la pile CloudFormation et déployer les ressources : 
    bash ./scripts/deploy.sh region cfn-stack-name

Si vous ne souhaitez pas créer le flux de contacts à partir de zéro dans Amazon Connect, vous pouvez importer l'exemple de flux fourni avec ce référentiel. filelocation: /contactflowsample/samplecontactflow.json.

  1. Connectez-vous à votre Instance Amazon Connect. Le compte doit se voir attribuer un profil de sécurité qui inclut des autorisations de modification pour les flux.
  2. Sur la console Amazon Connect, dans le volet de navigation, sous Routage, choisissez Flux de contact.
  3. Créez un nouveau flux du même type que celui que vous importez.
  4. Selectionnez Flux d’enregistrement et d’importation.
  5. Sélectionnez le fichier à importer et choisissez L’.

Lorsque le flux est importé dans un flux existant, le nom du flux existant est également mis à jour.

  1. Examinez et mettez à jour toutes les références résolues ou non résolues si nécessaire.
  2. Pour enregistrer le flux importé, choisissez Épargnez. Pour publier, choisissez Enregistrer et publier.
  3. Après avoir téléchargé le flux de contacts, mettez à jour les configurations suivantes :
    • Mettre à jour le GetCustomerInput blocs avec le nom et la version corrects du robot Amazon Lex.
    • Sous Gérer le numéro de téléphone, mettez à jour le numéro avec le flux de contacts ou l'IVR importé précédemment.

Vérifier la configuration

Vérifiez que la fonction Lambda créée avec la pile CloudFormation dispose d'un rôle IAM avec des autorisations pour récupérer des robots et des informations d'intention à partir d'Amazon Lex (autorisations de liste et de lecture) et des autorisations Amazon Bedrock appropriées (autorisations de liste et de lecture).

Dans votre bot Amazon Lex, pour votre alias et votre langue configurés, vérifiez que la fonction Lambda a été correctement configurée. Pour le FallBackIntent, confirme que Fulfillmentis ajuster à Active pour pouvoir exécuter la fonction chaque fois que le FallBackIntent est déclenché.

À ce stade, votre bot Amazon Lex exécutera automatiquement la fonction Lambda et la solution devrait fonctionner de manière transparente.

Testez la solution

Examinons un exemple de configuration d'intention, de description et d'énoncé dans Amazon Lex et voyons dans quelle mesure le LLM fonctionne avec des exemples d'entrées contenant des fautes de frappe, des erreurs de grammaire et même une langue différente.

La figure suivante montre des captures d'écran de notre exemple. Le côté gauche affiche le nom de l’intention, sa description et un exemple d’énoncé d’un seul mot. Sans beaucoup de configuration sur Amazon Lex, le LLM est capable de prédire l'intention correcte (côté droit). Dans ce test, nous avons un simple message d’accomplissement provenant de l’intention correcte.

Nettoyer

Pour nettoyer vos ressources, exécutez la commande suivante pour supprimer le référentiel ECR et la pile CloudFormation :

bash ./scripts/cleanup.sh region repository-name cfn-stack-name

Conclusion

En utilisant Amazon Lex amélioré avec les LLM fournis par Amazon Bedrock, vous pouvez améliorer les performances de reconnaissance d'intention de vos robots. Cela offre une expérience en libre-service transparente à un ensemble diversifié de clients, comblant le fossé entre les accents et les caractéristiques vocales uniques, et améliorant finalement la satisfaction du client.

Pour approfondir et en savoir plus sur l’IA générative, consultez ces ressources supplémentaires :

Pour plus d'informations sur la façon dont vous pouvez expérimenter la solution libre-service générative basée sur l'IA, voir Déployez des réponses aux questions en libre-service avec la solution QnABot sur AWS optimisée par Amazon Lex avec Amazon Kendra et de grands modèles linguistiques.

À propos des auteurs

Hamza Nadim est un architecte de solutions spécialisé Amazon Connect chez AWS, basé à Toronto. Il travaille avec des clients partout au Canada pour moderniser leurs centres de contact et fournir des solutions à leurs défis uniques en matière d'engagement client et à leurs exigences commerciales. Dans ses temps libres, Hamza aime voyager, jouer au football et essayer de nouvelles recettes avec sa femme.

Parag Srivastava est architecte de solutions chez Amazon Web Services (AWS), aidant les entreprises clientes à adopter et migrer avec succès le cloud. Au cours de son parcours professionnel, il a été largement impliqué dans des projets complexes de transformation numérique. Il est également passionné par la construction de solutions innovantes autour des aspects géospatiaux des adresses.

Ross Hélas est un architecte de solutions chez AWS basé à Toronto, au Canada. Il aide les clients à innover avec des solutions d'IA/ML et d'IA générative qui conduisent à de réels résultats commerciaux. Il a travaillé avec une variété de clients du commerce de détail, des services financiers, de la technologie, de l'industrie pharmaceutique et autres. Dans ses temps libres, il aime le plein air et profiter de la nature avec sa famille.

Sangeetha Kamatkar est architecte de solutions chez Amazon Web Services (AWS), aidant les clients à réussir leur adoption et leur migration vers le cloud. Elle travaille avec les clients pour créer des architectures cloud hautement évolutives, flexibles et résilientes qui répondent aux problèmes commerciaux des clients. Pendant son temps libre, elle écoute de la musique, regarde des films et jardine pendant l’été.

spot_img

Dernières informations

spot_img

Copyright @ 2024 Platon Technologies Inc.