Présentation
QNabot sur AWS est une solution d’intelligence artificielle générative (IA) qui répond aux demandes des clients dans plusieurs langues et plateformes et offre la possibilité d’entretenir des conversations via le chat, la voix, les SMS et Amazon Alexa. Cet assistant polyvalent permet aux organisations d’améliorer le service client grâce à des réponses instantanées et cohérentes sur divers canaux de communication, sans codage requis.
Avantages
Fournir des tutoriels personnalisés et une assistance sous forme de questions et réponses avec une interaction intelligente en plusieurs parties. Importez et exportez facilement des questions depuis votre configuration QNabot.
Utilisez les capacités de traitement du langage naturel (NLP) d'Amazon Kendra pour mieux comprendre les questions humaines. Créez des applications conversationnelles à l'aide d'Amazon Bedrock, un service géré proposant des modèles de base performants.
Automatiser les flux d'assistance à la clientèle. Réalisez des économies et offrez un meilleur service à vos clients afin qu'ils puissent obtenir des réponses précises et de l'aide rapidement.
Utilisez la correspondance des intentions et des créneaux pour divers flux de questions-réponses. Tirez parti de la compréhension du langage naturel, de la gestion du contexte et des dialogues à tours multiples grâce à de grands modèles de langage (LLM) et à la génération à enrichissement contextuel (RAG).
Détails techniques
Vous pouvez déployer automatiquement cette architecture à l'aide du guide d'implémentation et du modèle AWS CloudFormation approprié. Si vous souhaitez déployer à l'aide d'un VPC, déployez d'abord un VPC avec deux sous-réseaux privés et deux sous-réseaux publics répartis sur deux zones de disponibilité, puis utilisez le modèle QNabot VPC AWS CloudFormation. Sinon, utilisez le modèle QNabot Main AWS CloudFormation.
Étape 1
L'administrateur déploie la solution dans son compte AWS, ouvre l'interface utilisateur (IU) du concepteur de contenu ou le client Web Amazon Lex et utilise Amazon Cognito pour s'authentifier.
Étape 2
Après l'authentification, Amazon API Gateway et Amazon Simple Storage Service (Amazon S3) délivrent le contenu de l'interface utilisateur du concepteur de contenu.
Étape 3
L'administrateur configure les questions et les réponses dans le concepteur de contenu et l'interface utilisateur envoie des requêtes à la passerelle API pour enregistrer les questions et les réponses.
Étape 4
La fonction Concepteur de contenu d’AWS Lambda enregistre l’entrée dans Amazon OpenSearch Service dans un index de banque de questions. Si vous utilisez des intégrations de texte, ces demandes passent par des LLM hébergés sur Amazon SageMaker ou Amazon Bedrock pour générer des intégrations avant d’être enregistrées dans la banque de questions sur le service OpenSearch.
En outre, le concepteur de contenu enregistre les paramètres de configuration par défaut et personnalisés dans la base de données Amazon Dynamo.
Étape 5
Les utilisateurs de l’assistant interagissent avec Amazon Lex via l’interface utilisateur du client Web, Amazon Alexa, ou Amazon Connect.
Étape 6
Amazon Lex transmet les demandes à la fonction Bot Fulfillment de Lambda. Les utilisateurs peuvent également envoyer des demandes à cette fonction Lambda via les appareils Amazon Alexa.
REMARQUE : lorsque le streaming est activé, le client de chat utilise l’identifiant de session Amazon Lex (SessionID) pour établir des connexions WebSocket via API Gateway V2.
Étape 7
Les informations relatives à l’utilisateur et au chat sont stockées dans DynamoDB afin de désambiguïser les questions de suivi par rapport à la question précédente et au contexte de la réponse.
Étape 8
La fonction Bot Fulfillment de Lambda utilise Amazon Comprehend et, si nécessaire, Amazon Translate pour traduire les demandes dans une langue non native dans la langue maternelle sélectionnée par l’utilisateur lors du déploiement. La fonction interroge ensuite le service OpenSearch pour récupérer la réponse appropriée.
Étape 9
Si vous utilisez des fonctionnalités de grands modèles de langage (LLM) tels que la génération de texte et l’intégration de texte, ces demandes sont d’abord transmises par différents modèles fondamentaux hébergés sur Amazon Bedrock. Cela génère la requête de recherche et les intégrations, qui sont ensuite comparées à celles enregistrées dans la banque de questions du service OpenSearch.
Étape 9A
Si les barrières de protection de prétraitement sont activées, elles scannent et bloquent les entrées utilisateur potentiellement dangereuses avant qu’elles n’atteignent l’application QNabot. Cela constitue la première ligne de défense pour empêcher le traitement de requêtes malveillantes ou inappropriées.
Étape 9B
L’utilisation des barrières de protection Amazon Bedrock pour les LLM ou les bases de connaissances Amazon Bedrock peut conduire à l’utilisation des contrôles de sécurité et de protection contextuels lors de l’inférence LLM afin de garantir la génération de réponses appropriées.
Étape 9C
Si les barrières de protection de post-traitement sont activées, elles scannent, masquent ou bloquent le contenu potentiellement dangereux dans les réponses finales avant qu’elles ne soient envoyées au client via le module de traitement Lambda. Il s’agit de la dernière ligne de défense pour garantir que les informations sensibles, telles que les données d’identification personnelle (PII), sont correctement masquées et que le contenu inapproprié est bloqué.
Étape 10
Si aucune correspondance n’est renvoyée par la banque de questions des services OpenSearch ou les passages de texte, la fonction Bot Fulfillment de Lambda transmet la demande comme suit :
Étape 10A
Si un index Amazon Kendra est configuré pour le repli, la fonction Bot Fulfillment de Lambda transmet la demande à Amazon Kendra si aucune correspondance n’a été renvoyée par la banque de questions du service OpenSearch. La génération de texte LLM peut également être utilisée pour créer la requête de recherche et pour synthétiser une réponse à partir des extraits du document renvoyé.
Étape 10B
Si un identifiant de base de connaissances pour Amazon Bedrock est configuré, la fonction Bot Fulfillment de Lambda transmet la demande à la base de connaissances pour Amazon Bedrock. La fonction Bot Fulfillment de Lambda utilise ensuite les API RetrieveAndGenerate ou RetrieveAndGenerateStream pour récupérer les résultats pertinents pour la requête utilisateur, augmenter l’invite du modèle de base et renvoyer la réponse.
Étape 11
Lorsque le streaming est activé, les réponses LLM provenant de passages de texte ou de sources de données externes sont améliorées par Retrieval-Augmented Generation (RAG). Les réponses sont diffusées via des connexions WebSocket en utilisant le même identifiant de session Amazon Lex, tandis que la réponse finale est traitée via la fonction de traitement Lambda.
Étape 12
Les interactions des utilisateurs avec la fonction Bot Fulfillment sont enregistrées et les données de métriques qui en résultent sont envoyées à Amazon Data Firehose, puis transmises à Amazon S3 pour une analyse ultérieure des données.
Étape 13
Les tableaux de bord OpenSearch peuvent être utilisés pour afficher une multitude d’analyses, y compris l’historique d’utilisation, les énoncés enregistrés, les énoncés sans accès, les commentaires positifs et négatifs des utilisateurs, et offrent également la possibilité de créer des rapports personnalisés.
Étape 14
À l’aide d’Amazon CloudWatch, les administrateurs peuvent surveiller les journaux de service et utiliser le tableau de bord CloudWatch créé par QnABot pour surveiller l’état opérationnel du déploiement.
Rubriques connexes
- Date de publication