Amazon Lex est le service d'IA conversationnelle entièrement géré d'AWS. Il est basé sur le moteur NLU d'origine Alexa et prend en charge la construction de chatbots multicanaux pour l'interaction textuelle et vocale.

amazonlex

Paramètres et statistiques de base d'Amazon Lex

Amazon Lex est un service d'IA conversationnelle entièrement géré lancé par AWS. La couche sous-jacente réutilise les moteurs homologues de reconnaissance vocale automatique (ASR) et de compréhension du langage naturel (NLU) d'Amazon Alexa, permettant aux développeurs de créer des robots conversationnels prenant en charge le texte et la voix à des coûts de démarrage extrêmement faibles. Il ne se positionne pas comme un assistant de chat général, mais comme une « couche d'interaction conversationnelle pouvant être intégrée dans les systèmes d'entreprise » - l'objectif est de connecter les portails en langage naturel à la logique back-end, aux bases de connaissances et aux centres de contact.

Projets	Informations publiques
Positionnement officiel	Service d'IA conversationnelle entièrement géré (Conversational AI)
Moteur de base	Amazon Alexa Origine ASR + NLU
Mode d'interaction	Saisie de texte, saisie vocale (qualité téléphonique 8 kHz/large bande 16 kHz), réponse vocale TTS
Formulaire de déploiement	Entièrement géré (AWS Cloud), pas de chemin auto-hébergé
Comment construire	Éditeur de flux de dialogue visuel + programmation SDK/API
Intégration de l'IA générative	Remplacement d'un modèle de langage étendu (remplacement LLM) basé sur Amazon Bedrock
Canaux d'intégration	Amazon Connect, Slack, Twilio SMS/Voice, Facebook Messenger, Genesys Cloud, Chime SDK
Régions disponibles	Plus de 10 régions AWS dans le monde (y compris la région AWS Chine exploitée par Guangyouxin.com)
Dernière version	Lex V2 (SDK 2.0, ~2026-01)
Niveau gratuit	10 000 requêtes SMS + 5 000 requêtes vocales par mois

Différences clés entre Lex V1 et V2 : La V2 met à niveau la construction de conversation du mode assistant de console vers la première définition déclarative du SDK/API, prend en charge un contrôle des autorisations (IAM) plus précis, une stratégie de secours générative (repli de l'IA générative) et la gestion de la copie des robots pour la réplication entre régions. La V1 est entrée dans la période de maintenance et AWS recommande aux nouveaux projets d'utiliser directement la V2.

Lorsque l'IA générative est intégrée : au lieu de remplacer le NLU traditionnel par un seul LLM, la V2 demandera un retour au modèle de base sur Bedrock lorsque NLU ne peut pas analyser l'intention ou les emplacements de l'utilisateur. Cette architecture hybride « NLU-first LLM-complétée » préserve le routage d'intention déterministe à faible latence tout en offrant une flexibilité pour les expressions à longue traîne.

Reconnaissance des utilisateurs et du marché d'Amazon Lex

Sensibilisez progressivement les utilisateurs sur le terrain et les capacités du produit sont utilisées par les créateurs de contenu et les équipes pour améliorer l'efficacité du travail. Les données spécifiques sur l’échelle des utilisateurs et l’adoption par l’industrie sont soumises à la page officielle en temps réel.

Avantages financiers d'Amazon Lex

La structure de coûts de Lex est basée sur « paiement à l'utilisation + démarrage d'un forfait gratuit » et son prix est moyen parmi les plates-formes d'IA conversationnelles entièrement gérées similaires. Cependant, son coût caché le plus important ne réside pas dans Lex lui-même, mais dans la pile de services AWS associée.

Développeurs côté C/individuels : le package gratuit est suffisant pour la vérification du prototype

• Quota gratuit de 10 000 requêtes textuelles + 5 000 requêtes vocales par mois, ce qui est tout à fait suffisant pour un prototype de chatbot de petite à moyenne taille.
• Les requêtes vocales incluent un double traitement ASR (parole en texte) et TTS (texte en parole), et 5 000 fois équivaut approximativement à 100 à 200 minutes de volume de conversation réel.
• Après avoir dépassé le quota gratuit, les requêtes textuelles coûtent 0,75 $/millier de fois et les requêtes vocales sont de 4,00 $/milliers de fois.

API/Développeur : prix unitaire payé à l'utilisation

Éléments de facturation	Prix ​​unitaire standard Lex V2	Quota de forfaits gratuits
Demandes de texte	0,75 $ / 1 000 fois	10 000 fois/mois
Demande vocale (y compris ASR+TTS)	4,00 $ / 1 000 fois	5 000 fois/mois
Repli génératif (Repli LLM)	Facturation supplémentaire basée sur le modèle Bedrock	Pas de quota gratuit
Messages des chaînes (Slack/Facebook, etc.)	Mêmes demandes texte/voix	Calculs combinés

Entreprise/Grand Compte : Le coût total doit être calculé avec 4 couches de superposition

En apparence, le prix unitaire de Lex n'est pas élevé, mais dans un scénario à haute fréquence au niveau de l'entreprise, la facture réelle se compose des quatre niveaux suivants :

1. Frais du moteur Lex : volume de requêtes texte/voix × prix unitaire correspondant, représentant généralement 30 à 50 % de la facture.
2. Frais d'exécution Lambda : la logique backend de chaque intention est exécutée sur Lambda, et les frais dépendent du nombre d'appels et du temps d'exécution. La consommation de temps de Lambda pour des intentions très complexes (telles que les requêtes multi-bases de données) peut dépasser de loin les frais de requête de Lex lui-même.
3. Frais d'appel du modèle Bedrock : Après avoir activé le repli génératif, chaque LLM Fallback est facturé selon le modèle de Bedrock (comme Claude 3 Haiku, environ 0,25 $/million de jetons). Si le taux de repli est supérieur à 30 %, les frais LLM peuvent dépasser les frais du moteur Lex.
4. Frais de stockage et de surveillance des journaux : CloudWatch Logs stocke les journaux de conversation et les données d'analyse. Dans les scénarios à haute fréquence, les frais de journalisation mensuels peuvent atteindre des centaines de dollars.

En termes de coûts cachés, si le scénario commercial nécessite une grande précision NLU (comme la terminologie médicale, les termes juridiques), le modèle général de Lex peut ne pas être en mesure de répondre directement aux exigences, et des processus de confirmation manuels supplémentaires ou des bases de connaissances doivent être conçus (Kendra commence à environ 750 $ par mois), ce qui est souvent un poste budgétaire sous-évalué.

Niveau de coût	Appels mensuels estimés à 500 000 fois (principalement SMS)	Appels mensuels estimés à 2 millions de fois (dont 30% voix)
Frais du moteur Lex	~375$	~2 400 $
Frais d'exécution Lambda	~80-150$	~300-600$
Frais de repli du substrat rocheux	~50-200 $ (selon le taux de repli)	~200-800$
Frais d'exploitation/surveillance	~30-80$	~100-300$
Coût mensuel total (estimation)	~535-805$	~3 000-4 100 $

Ce qui précède est une estimation approximative, et le coût réel dépend fortement de la complexité de la session, du taux de repli et de l'efficacité de l'exécution de Lambda. Il est recommandé d'activer les balises de facturation détaillées (balises d'allocation des coûts) pendant l'étape POC pour une comptabilité précise.

Principales fonctionnalités d'Amazon Lex

La conception fonctionnelle de Lex s'articule autour du lien complet « comprendre l'intention → collecter des informations → effectuer des actions → publier via plusieurs canaux ». Chaque section comporte des outils et des éléments de configuration correspondants.

• Entrée double mode voix et texte : moteur ASR homologue Alexa intégré, prenant en charge deux taux d'échantillonnage de 8 kHz (niveau téléphonique) et 16 kHz (large bande). 8 kHz est optimisé pour les scénarios IVR téléphoniques, et la précision de reconnaissance dans un bruit de fond élevé est nettement meilleure que le schéma ASR général. Le côté TTS prend en charge la prononciation standard et Neural TTS (neural text-to-speech) en intégrant Amazon Polly, et le naturel de la voix est à l'avant-garde parmi les plates-formes cloud grand public.

• Reconnaissance d'intention et remplissage d'emplacements : il s'agit du mécanisme de base de la compréhension du dialogue Lex. Les développeurs définissent les intentions de l'utilisateur (telles que « vérifier le solde » et « transférer vers le manuel »), et chaque intention est accompagnée d'un ensemble d'exemples de phrases (exemples d'énoncés) et d'emplacements obligatoires/facultatifs (emplacements). Le modèle NLU intégré de Lex a une précision d'environ 95 à 97 % dans la classification des intentions dans les scénarios d'anglais général. La prise en charge du chinois a été considérablement améliorée dans la version V2, mais la précision reste inférieure à celle de l'anglais. Le remplissage des emplacements prend en charge l'extraction automatique des paramètres (tels que la date, le montant) des expressions utilisateur, et une vérification personnalisée peut également être effectuée via Lambda.

• Generative AI Fallback : La nouvelle capacité la plus importante de la V2. Lorsque NLU ne peut pas correspondre à l'intention connue avec un niveau de confiance élevé, il ne renvoie pas directement « Désolé, je ne comprends pas ». Au lieu de cela, il transmet la demande à LLM sur Amazon Bedrock (l'utilisateur peut choisir Claude, Llama, etc.) pour une clarification intelligente. LLM peut effectuer des tâches telles que des questions et réponses de connaissances, l'analyse des sentiments, la synthèse automatique, etc. qui ne peuvent pas être couvertes par la NLU traditionnelle. Conseil de mise en œuvre : le taux de repli est un indicateur clé d'exploitation et de maintenance - Si le taux de repli continue de dépasser 40 %, cela signifie que le corpus de formation est insuffisant et l'exemple d'énoncé d'intention doit être ajouté ou le seuil de confiance NLU doit être ajusté.

• Visual Conversation Builder : un outil de conception de processus de dialogue par glisser-déposer qui prend en charge les branches, les sauts conditionnels, les déclencheurs Lambda et les nœuds de gestion des erreurs. Par rapport à l'arborescence de la V1, la maintenabilité de l'éditeur visuel de la V2 dans des scénarios de dialogue complexes (plus de 20 intentions) a été considérablement améliorée. Cependant, il est toujours recommandé de contrôler le nombre d'intentions d'un seul Bot dans la limite de 50. S'il dépasse, envisagez de le diviser en plusieurs Bots et d'utiliser le Bot principal pour le routage.

• Publication multicanal en un clic : une fois votre bot intégré dans la console Lex, publiez directement sur Amazon Connect, Slack, Twilio SMS/Voice, Facebook Messenger et Web UI. L'adaptation du format de message pour chaque canal (comme le modèle de bouton de Facebook Messenger et le Block Kit de Slack) est automatiquement gérée par Lex sans développement supplémentaire.

• Test Workbench : l'outil de test de la V2 permet aux développeurs de créer des ensembles de tests automatisés et d'utiliser la lecture des données de conversation historiques pour vérifier les changements dans la précision du NLU. Chaque fois que vous modifiez l'intention ou l'emplacement, exécutez l'ensemble de tests pour quantifier l'amélioration de la précision et éviter les régressions. Il s'agit d'une fonctionnalité utile pour les équipes où plusieurs personnes collaborent pour gérer les Bots.

Liste de contrôle d'acceptation des fonctions de base :

Dimension de capacité	Points d'acceptation
Reconnaissance d'intention	Après avoir fourni plus de 30 exemples de phrases, indiquez si l'exactitude de la classification des intentions atteint plus de 90 %
Remplissage des fentes	Si les créneaux composés (tels que l'extraction de « départ/arrivée » de « Shanghai à Pékin ») sont analysés correctement
Cohérence multicanal	L’expérience de conversation du même Bot est-elle cohérente sur Slack et Web UI
Stratégie de repli	Si le temps de réponse du repli LLM en cas de concurrence élevée se situe dans une plage acceptable (recommandé <3 s)

Evolution du modèle et de la version d'Amazon Lex

La gamme de versions de Lex n'itère pas aussi fréquemment que le modèle de base, mais évolue le long du chemin « outils de console → interfaces de programmation → intégration d'IA générative ».

Version initiale (~2017-04) : Lex V1

Lex a été officiellement publié autour d'AWS re:Invent en 2017 (la version préliminaire était antérieure) et ses capacités initiales se sont concentrées sur NLU et ASR basées sur le moteur Alexa. L'expérience de construction de la V1 est dominée par les assistants de console : les développeurs définissent les intentions, les emplacements et les réponses en remplissant des formulaires. La quantité de codage est très faible, mais la flexibilité est limitée. Une logique de dialogue complexe nécessite beaucoup de code de colle Lambda.

Mise à niveau de l'architecture (~2021-06) : Lex V2

La V2 est une réécriture complète de l'API vers la console. Les principaux changements incluent :

• Introduction des mécanismes de gestion de versions de Bot (Versioning) et d'alias (Alias) pour prendre en charge la publication à trois niveaux Dev/Staging/Prod.
• Modifiez l'interface de construction de la console d'abord au SDK/API d'abord, et les développeurs peuvent définir de manière déclarative l'intégralité du Bot à l'aide de JSON/YAML.
• La fonctionnalité de réplication de région (réplication de bot) permet au même bot d'être déployé dans les régions AWS pour obtenir une faible latence.
• Prend en charge l'optimisation audio de qualité téléphonique à 8 kHz.
• Augmentation du quota d'intention par bot de 100 dans la V1 à 2 000.

Améliorations de l'IA générative (~ 2024-2026) : évolution continue de la V2

À partir de 2024, AWS injectera intensivement des capacités d'IA générative basées sur la V2 :

• FAQ conversationnelle (~2024) : solution RAG basée sur Bedrock + Kendra, permettant aux robots de répondre directement aux questions courantes de la base de connaissances sans avoir besoin de créer des intentions distinctes pour chaque question/réponse.
• Résolution de slot assistée (~ 2024) : lorsque NLU ne peut pas analyser la valeur du slot, LLM intervient pour extraire les paramètres du slot du texte libre, améliorant ainsi considérablement le taux de résolution des slots composites (tels que "de Pékin à Shanghai").
• Descriptive Bot Builder (~ 2025) : la description en langage naturel génère la référence du Bot - les développeurs décrivent l'objectif du Bot en une phrase (par exemple "Il s'agit d'un robot de service client qui aide les clients à interroger l'état des commandes"), et Lex génère automatiquement des intentions, des créneaux horaires et des brouillons de flux de conversation.
• Génération d'exemples d'énoncés (~ 2025) : LLM développe automatiquement des exemples d'instructions pour chaque intention, réduisant ainsi les coûts d'écriture manuelle.

État actuel (~ 2026-01) : Lex V2 SDK 2.0

La dernière version du SDK 2.0 se concentre sur l'ingénierie de stratégies de repli génératives : contrôle précis des conditions de déclenchement du repli en mode « NLU first », sélection du type de modèle Bedrock et définition d'alarmes de surveillance pour les dialogues de repli. La page du document officiel est continuellement mise à jour et le plan V3 n'a pas encore été annoncé.

Nœud de version	Dates	Changements clés
Version initiale de Lex V1	~2017-04	Les capacités ASR/NLU du moteur Alexa sont migrées vers le cloud et l'assistant de console est créé
Version officielle de Lex V2	~2021-06	Conception des priorités SDK/API, définition déclarative du Bot, réplication inter-régions
FAQ conversationnelle	~2024	Programme LLM + Kendra RAG, couvrant les questions et réponses de connaissances communes
Résolution des emplacements assistée	~2024	LLM facilite la résolution des slots et améliore l'extraction des paramètres composites
Générateur de robots descriptif	~2025	Description en langage naturel → Capacités d'automatisation de base du bot
Lex V2 SDK 2.0	~2026-01	La stratégie de repli générative est profondément conçue et présente des conditions quasi commerciales

Avantages techniques d'Amazon Lex

L'avantage technique de Lex ne vient pas d'une seule percée d'algorithme, mais de l'effet combiné du « moteur sous-jacent éprouvé d'Alexa + infrastructure entièrement gérée AWS + architecture hybride d'IA générative ».

Bonus de migration du moteur Alexa : les moteurs ASR et NLU réutilisés de Lex ont été perfectionnés par les milliards d'interactions de centaines de millions d'utilisateurs d'Alexa chaque jour. Dans les deux dimensions de la reconnaissance vocale au niveau du téléphone (8 kHz) et de la compréhension des intentions multilingues, la précision de Lex a atteint un niveau que seuls les produits grand public à grande échelle peuvent atteindre. Cela signifie que l'équipe de développement n'a pas besoin de former le modèle vocal à partir de zéro : accéder à Lex équivaut à hériter d'une capacité de pré-formation qui a été vérifiée par des données massives.

Mécanisme d'arbitrage hybride NLU + LLM : Lex V2 ne connecte pas simplement LLM à l'entrée de conversation, mais conçoit une architecture de raisonnement à deux niveaux. Le NLU de premier niveau effectue une classification d'intention à grande vitesse (généralement effectuée en 50 à 100 ms), et le deuxième niveau peut éventuellement déclencher un LLM lorsque le niveau de confiance est faible. Cette conception atteint un équilibre technique entre coût et flexibilité : les interactions hautement déterministes (telles que « vérifier le solde » et « transférer vers le manuel ») n'utilisent pas LLM et n'entraînent pas de frais d'appel de modèle supplémentaires ; seules les expressions floues utilisent le LLM, concentrant le coût du raisonnement là où la compréhension sémantique est réellement nécessaire.

Valeur cachée d'une exploitation et d'une maintenance entièrement gérées et sans opération : la charge d'exploitation et de maintenance de la production de robots conversationnels est souvent sous-estimée : le modèle NLU doit surveiller en permanence la dérive d'intention (Intent Drift), gérer de nouvelles techniques vocales et ajuster les règles de créneau. La solution auto-hébergée nécessite une équipe possédant la double capacité d’ingénieurs NLP et de SRE. Le modèle d'hébergement de Lex transfère cette partie de la charge de travail vers le côté AWS, et le côté sortie réduit la fréquence des interventions manuelles via le tableau de bord de précision et l'atelier de test. Le prix est que l'équipe perd tout contrôle sur le modèle NLU et ne peut pas affiner le domaine ni personnaliser le vocabulaire.

Couche d'abstraction d'adaptation de canal : Lex fournit une abstraction d'ingénierie importante au niveau de la version : il encapsule les différences dans le kit de blocs de Slack, le modèle de bouton de Facebook Messenger et le format SMS de Twilio dans une définition de robot unifiée. Les développeurs n'ont besoin d'écrire leur logique conversationnelle qu'une seule fois, et Lex la convertit automatiquement au format du canal cible lors de la publication. Pour les équipes qui doivent lancer simultanément des applications Web, des applications mobiles et des réseaux sociaux, cela peut permettre d'économiser des centaines d'heures de travail d'adaptation des canaux.

Base de sécurité et de conformité : Lex fonctionne dans le cadre de conformité AWS, prenant en charge des certifications telles que HIPAA (soins de santé), PCI DSS (paiements), GDPR (protection des données de l'UE) et SOC 2/3. Les données de conversation sont chiffrées par défaut en transit et au repos, et ne sont pas partagées avec Amazon pour la formation du modèle. Prend en charge l'invocation Lambda dans VPC pour garantir que la logique back-end ne passe pas par le réseau public.

Dimension technique	Implémentation Lex	Implications en matière d'ingénierie
Moteur ASR	Origine Alexa, double taux d'échantillonnage 8 kHz/16 kHz	Aucun réglage supplémentaire requis pour les scénarios IVR téléphoniques
Modèle NLU	Modèle général pré-entraîné, non affiné	La précision du champ vertical doit être améliorée grâce à un corpus d'échantillons
Intégration LLM	Modèle de substrat rocheux (Claude/Lama, etc.)	Scénarios de repli flexibles mais les coûts doivent être pris en compte
Adaptation des canaux	Définition de robot unifiée → Conversion automatique de format	Compresser le lancement cross-canal de quelques semaines à quelques jours
Certification de conformité	HIPAA/PCI/RGPD/SOC	Peut être directement adopté par les secteurs financier et médical

Comment utiliser Amazon Lex

Les chemins d'accès de Lex sont divisés en deux lignes principales : « construction de console low-code » et « construction de programmation SDK/API ». Les équipes peuvent choisir en fonction de leurs capacités techniques.

Chemin 1 : Construction visuelle de la console AWS (recommandé pour les équipes non techniques)

1. Créer un bot : Connectez-vous à la console AWS → Ouvrez Amazon Lex V2 → Cliquez sur « Créer un bot ». Sélectionnez « Créer un bot vierge » ou utilisez Démarrer avec une description (Descriptive Bot Builder génère automatiquement une référence).
2. Définir l'intention : ajoutez l'intention dans l'éditeur visuel, remplissez le nom de l'intention, des exemples d'instructions (au moins 10 à 15), la liste des emplacements (obligatoire/facultatif) et la réponse post-déclenchement ou le rappel Lambda.
3. Configuration de repli : activez le repli de l'IA générative dans les paramètres du Bot, sélectionnez le modèle et la base de connaissances déployés sur Bedrock (tels que Kendra Index).
4. Test : utilisez la fenêtre de test intégrée pour saisir des instructions de dialogue afin de vérifier les résultats de la classification NLU et l'effet de remplissage des emplacements en temps réel. Utilisez Test Workbench pour créer des ensembles de tests automatisés pour la vérification de la régression.
5. Publier : créez une version et un alias de Bot (tels que « Prod »), sélectionnez le canal cible (Connect/Slack/Twilio, etc.) et déployez-le en un seul clic. Chaque alias peut être associé à différentes versions, prenant en charge les versions bleues et vertes.

Chemin 2 : construction de la programmation SDK/API (intégration CI/CD recommandée)

Amazon Lex V2 fournit les points de terminaison SDK et API suivants :

• API au moment de la construction (plan de contrôle) : création de bot, définition d'intention, gestion des emplacements, gestion des versions, appelée via CLI/SDK.
• API d'exécution (plan de données) : RecognizeText (dialogue textuel), RecognizeUtterance (dialogue vocal), pour l'accès aux applications de l'utilisateur final.

Exemple de code Python (demande de texte) :

importer boto3

client = boto3.client('lexv2-runtime')

réponse = client.recognize_text(
    botId='<VOTRE_ID_BOT>',
    botAliasId='<VOTRE_ALIAS_ID>',
    localeId='en_US',
    sessionId='session-001',
    text='Je souhaite vérifier le solde de mon compte'
)

# Afficher le nom de l'intention, la valeur de l'emplacement, la confiance et le texte de réponse
print(response['sessionState']['intent']['name'])
print(réponse['messages'][0]['contenu'])

En utilisation réelle, quatre champs doivent être remplacés :

• botId : Obtenu à partir de la page de détails du Bot de la console Lex.
• botAliasId : Obtenu à partir de la liste des alias (Alias) du Bot.
• localeId : en_US, zh_CN, etc., selon la configuration linguistique du Bot.
• sessionId : un identifiant de session unique généré par l'appelant qui maintient le contexte tout au long de la conversation.

Intégration de plateformes tierces

Plateforme	Méthode d'intégration	Conditions préalables
Amazon Connecter	Association en un clic de la console	Nécessite l'exécution d'une instance Amazon Connect
Mou	Console Lex → Chaînes → Slack	Application Slack + Jeton OAuth du Bot
SMS Twilio	Console Lex → Chaînes → Twilio SMS	Numéro de téléphone Twilio + SID du compte
Facebook Messager	Console Lex → Chaînes → Facebook	Page Facebook + secret de l'application
Nuage Genesys	Guide d'intégration Genesys de la documentation Lex	Organisation Genesys Cloud + informations d'identification OAuth
Interface utilisateur Web personnalisée	Composant d'interface utilisateur Web Chat géré par AWS Amplify	Aucune exigence particulière

Recommandation d'exploitation et de maintenance : créez des alias de robot indépendants pour chaque contexte de déploiement (Dev/Staging/Prod) et définissez des alarmes de taux de réussite de conversation pour chaque alias dans CloudWatch. Il est recommandé d'activer le journal des conversations et de définir une période de stockage de 90 jours pour les nouveaux tests de précision NLU et l'analyse de régression ultérieurs.

Prix des produits pour Amazon Lex

Lex adopte un modèle de tarification à trois niveaux : « paiement à l'utilisation + niveau gratuit + contrat d'entreprise », qui est cohérent avec la logique de tarification de la plupart des services d'hébergement AWS.

Niveau gratuit : 10 000 demandes de SMS + 5 000 demandes vocales par mois, pour toujours (non limité aux 12 premiers mois). Convient à la vérification de prototypes et aux scénarios de trafic réduit.

Prix standard basé sur le volume :

Type de facturation	Prix ​​​​standard Lex V2	Exemple de prix unitaire après limite gratuite
Demandes de texte	0,75 $ / 1 000 fois	50 000 fois par mois → 30 $ ; 500 000 fois par mois → 360 $
Requêtes vocales (y compris ASR + TTS)	4,00 $ / 1 000 fois	10 000 fois par mois → 40 $ ; 100 000 fois par mois → 400 $
Repli génératif	Facturation supplémentaire, pas de niveau gratuit	Tarification basée sur le modèle Bedrock, Claude 3 Haiku ~ 0,25 $/million de jetons

Remarque : Les frais de secours génératifs sont facturés séparément en fonction des appels réels du modèle Bedrock et ne sont pas indiqués dans les factures Lex. Si le générateur de bot descriptif ou la génération d'exemples d'énoncés (pour la phase de construction) sont activés dans le bot, les appels LLM dans ces phases de construction entraîneront également des frais Bedrock, qui peuvent facilement être ignorés.

Contrat Entreprise : les scénarios avec une consommation mensuelle supérieure à 5 000 $ peuvent demander des remises de réservation (généralement de 15 à 30 % de réduction) et une assistance dédiée via le contrat AWS Enterprise. Il n'existe pas de forfait public fixe, vous devez contacter le côté commercial AWS pour obtenir un devis personnalisé.

Référence des frais de service associés :

Services associés	Coûts mensuels typiques (bot moyen)	Descriptif
AWS Lambda	50-200 $	Exécution de logique personnalisée derrière chaque intention
Amazone Kendra	750 $+ (à partir de la version développeur)	Index de la base de connaissances (obligatoire pour le scénario FAQ uniquement)
Substrat amazonien	50-500 $ (selon le taux de repli)	Frais d’appel de secours LLM
Amazon CloudWatch	30-100 $	Stockage et surveillance des journaux
Amazon Polly (TTS)	Inclus dans les demandes vocales

Scénarios d'application Amazon Lex

Les meilleurs scénarios applicables pour Lex se concentrent dans la zone d'intersection du « dialogue structuré + distribution multicanal ». Il ne convient pas au chat en domaine ouvert, mais il fonctionne bien dans les quatre types de scénarios suivants.

• Cloud Contact Center Intelligent IVR (intégration Amazon Connect) : il s'agit du scénario le plus abouti et le plus largement adopté de Lex. Les entreprises remplacent les SVI à clavier traditionnels (« Appuyez sur 1 pour vérifier le solde, appuyez sur 2 pour appeler un humain ») par des menus vocaux basés sur le langage naturel. L'utilisateur dit directement « Je souhaite vérifier la facture de la carte de crédit » ou « Me rediriger vers le service des réclamations ». Une fois que Lex a reconnu l'intention de classification vocale NLU via ASR, il est automatiquement acheminé vers le processus correspondant ou transféré vers un agent humain. Dans le cadre d'un déploiement réel, la première couche d'intentions couvre généralement 5 à 15 intentions à haute fréquence pour résoudre 60 à 80 % des besoins d'appels entrants. Objectif d'acceptation : si la précision de la reconnaissance de la voix chinoise sur les lignes téléphoniques à 8 kHz atteint un niveau acceptable pour l'entreprise (recommandé ≥ 85 %).

• Assistant de questions et réponses interne à l'entreprise (intégration Kendra) : avec Amazon Kendra (service de recherche d'entreprise), Lex peut créer un chatbot pour des scénarios internes tels que les requêtes de politique RH, le support informatique, l'approbation financière, etc. Les employés posent des questions en langage naturel via Slack ou l'interface utilisateur Web (comme « Quelle est la politique de congés annuels de notre entreprise ? »), Lex recherche les documents indexés via Kendra et utilise la solution de secours LLM pour générer une réponse en langage naturel. Problèmes d'acceptation : Fréquence de mise à jour de la base de connaissances - Si la fréquence de mise à jour hebdomadaire des documents est élevée, le délai de synchronisation de l'index Kendra (généralement 24h+) deviendra un goulot d'étranglement dans la rapidité des réponses.

• Assistant vocal intégré aux applications mobiles : intégrez des portails de dialogue vocal pour les applications orientées consommateur telles que les banques, les assurances, les hôtels et les compagnies aériennes. Les utilisateurs peuvent compléter des demandes de renseignements, des réservations, des plaintes ou des modifications de commande via des commandes vocales. La capacité de publication multicanal de Lex permet au même robot de servir simultanément l'application iOS, l'application Android et le Web, maintenant ainsi une expérience de conversation cohérente. Problèmes d'acceptation : Le délai de demande vocale du côté de l'application - le lien ASR → NLU → réponse complet doit être dans les 2 secondes. Le délai d'attente doit être confirmé, qu'il s'agisse du délai de traitement ASR ou du délai Lambda du backend.

• Bot de service client sur les réseaux sociaux : déployez un robot de service client via les canaux Facebook Messenger ou Slack pour gérer les demandes courantes avant-vente (informations sur les produits, demandes d'inventaire, état de livraison) et les problèmes après-vente (politiques de retour et d'échange, saisie des réclamations). La couche d'adaptation des canaux Lex gère automatiquement les différences de format des messages et les équipes du service client peuvent gérer de manière centralisée les conversations multicanaux dans la console Lex. Problèmes d'acceptation : délai de retour des messages des canaux de médias sociaux - Les canaux Slack répondent généralement dans un délai de 1 à 2 secondes, mais il n'est pas exclu que des délais d'attente puissent survenir en raison de la limitation du courant de l'API dans des cas extrêmes.

Scénario	Formulaire de chaîne	Objectifs typiques	Avantages Lex	Limites
Centre de contact SVI	Voix téléphonique	Réduction des coûts : remplacez 60 % de l'IVR Touch-Touch	Intégration native ASR + Connect 8 kHz	La précision de la parole en chinois est inférieure à celle de l'anglais
Questions et réponses sur les connaissances de l'entreprise	Messagerie instantanée/Web interne	Amélioration de l'efficacité : requêtes en libre-service des employés 7×24h	Intégration Kendra + repli LLM	Délai de synchronisation de la base de connaissances
Assistant intégré à l'application	Application mobile	Expérience : entrée directe par fonction vocale	Expérience cohérente sur plusieurs plateformes	Sensible à la latence (nécessite <2 s)
Service client social	Facebook/Slack	Couverture : exploitation unifiée de plusieurs canaux	Couche d'abstraction d'adaptation de canal	Limite actuelle de l'API de canal

Qui est éligible à Amazon Lex ?

Lex s'adresse aux équipes qui « ont besoin d'une interface conversationnelle mais ne souhaitent pas créer leur propre infrastructure ASR/NLU ». Il ne convient pas aux chercheurs en reconnaissance vocale ou aux équipes PNL avancées qui ont besoin d’un contrôle total sur le pipeline NLU.

• Équipes de développement d'entreprise au sein de l'écosystème AWS : les équipes qui utilisent déjà des services AWS tels qu'Amazon Connect, Lambda, Kendra, etc. peuvent bénéficier des meilleurs avantages d'intégration de Lex - le lien complet création de Bot → configuration de Lambda → publication sur Connect peut être exécuté en quelques heures. Ces équipes disposent généralement d'architectes AWS et de personnel chargé des opérations cloud capables de gérer les problèmes d'ingénierie tels que les autorisations IAM, la configuration VPC et le déploiement interrégional. Prérequis : l'équipe doit disposer de capacités de rédaction de politiques AWS IAM et d'une expérience de base en développement Lambda.

• Opérations et administrateurs du centre de contact : Visual Conversation Builder de Lex permet aux administrateurs du centre de contact ayant une formation non technique d'ajuster les processus IVR par glisser-déposer. Lorsque le service commercial a besoin d'ajouter de nouvelles promotions ou de modifier le processus du service client, il n'est pas nécessaire d'attendre que l'équipe de développement planifie, l'administrateur peut le compléter directement dans la console. Limite inadéquate : si la logique de dialogue dépasse 30 intentions ou implique plusieurs cycles de raisonnement approfondis, la maintenabilité de l'éditeur visuel diminuera fortement et les développeurs devront intervenir pour le définir dans le code.

• Startups/Indies : profitez de l'offre gratuite pour lancer un MVP conversationnel et intégrer Lex Bot dans une application Web ou mobile pour une preuve de concept. Pour les équipes sans expérience en ingénierie PNL, Lex est un choix logique pour démarrer rapidement. Limite inadéquate : lorsque la scène de conversation implique un grand nombre de termes de domaine vertical (tels que le diagnostic médical, l'analyse de clauses juridiques) et nécessite une classification d'intention de haute précision, le modèle NLU général de Lex peut ne pas suffire. Dans ce cas, Rasa ou un modèle de réglage fin dédié doit être envisagé.

• Personnes inappropriées : équipes qui doivent personnaliser en profondeur les modèles NLU (comme l'ajout de modèles de reconnaissance d'entités personnalisés, la reconnaissance vocale hybride multilingue) ; scénarios qui ont des exigences extrêmes en matière de latence de réponse du Bot (<100 ms) ; des déploiements à grande échelle avec des budgets extrêmement sensibles et des appels mensuels dépassant 1 million de fois (dans ce cas, les solutions auto-hébergées présentent plus d'avantages en termes de coûts à long terme).

Rôle de la foule	Adaptabilité	Avantages de base	Conditions préalables
Développeur d'entreprise AWS	★★★★★	Intégration écologique, fonctionnement et sans entretien	Capacités de l'infrastructure AWS
Administrateur de centre de contact	★★★★☆	Édition visuelle, réglage indépendant	Expérience de conception de processus de dialogue
Développeur indépendant	★★★★☆	MVP rapide, package gratuit	Capacités d'appel API de base
Équipe senior PNL	★☆☆☆☆	Ne convient pas (contrôle insuffisant)	Solution auto-hébergée requise

Résumé et perspectives d'Amazon Lex

Résumé des valeurs fondamentales : Amazon Lex est le produit le plus étroitement lié à l'écosystème cloud parmi les services d'IA conversationnelle entièrement gérés. Son principal obstacle concurrentiel n'est pas un seul indicateur technique (tel que la précision ASR ou la précision NLU), mais une combinaison de « moteur Alexa × cadre de conformité AWS × couche d'adaptation multicanal × architecture hybride d'IA générative ». Pour les organisations qui ont migré ou envisagent de migrer leurs architectures de centre de contact, de recherche d'entreprise et de microservices vers AWS, Lex offre le chemin le plus court entre l'entrée de la conversation et l'exécution back-end.

Limites et incertitudes actuelles :

• Les modèles NLU sont toujours des boîtes noires : ils ne peuvent pas être ajustés, ne peuvent pas être exportés et ne peuvent pas obtenir une décomposition de confiance fine. La capacité à identifier les termes du domaine vertical dépend entièrement de la qualité et de la quantité du corpus échantillonné, et manque de moyens d'ingénierie adaptatifs au domaine.
• Bien que la capacité de repli génératif ait été implémentée, les outils de réglage de la logique de déclenchement du repli (seuils de confiance, itinéraires de sélection de modèle) sont encore relativement rudimentaires et de nombreux coûts d'essais et d'erreurs sont nécessaires dans les environnements de production.
• Les performances de la reconnaissance vocale chinoise (ASR) sont en retard par rapport à l'anglais, et l'écart de précision est encore plus évident sur les lignes téléphoniques. Pour les projets ciblant le marché chinois, il est recommandé de développer au préalable un POC vocal chinois suffisant.
• La transparence de la facturation de Lex n'est pas assez intuitive dans les scénarios à haute fréquence : plus de 60 % des coûts peuvent provenir de services associés tels que Lambda, Bedrock et CloudWatch, et un seul prix unitaire Lex ne peut pas être utilisé comme base pour l'évaluation des coûts.

Évaluation des risques d'approvisionnement/d'adoption :

1. Risque de verrouillage : Élevé. La définition des robots et la logique de dialogue sont profondément liées au schéma de Lex V2, et la migration vers d'autres plateformes (telles que Google Dialogflow ou Rasa) nécessite une reconstruction complète. Il est recommandé d'ajouter une abstraction de couche d'adaptation entre la couche logique Bot et l'interface Lex pour conserver la faisabilité d'une migration future.
2. Risque de coût : moyen. Le modèle de paiement à l'utilisation a des coûts contrôlables lorsque le trafic augmente de manière linéaire, mais lorsque des pics de trafic (telles que des promotions majeures, des activités marketing) se produisent et que LLM est activé, les factures mensuelles peuvent fluctuer de 2 à 3 fois. Il est recommandé de fixer des limites budgétaires (Budgets) et de détection des anomalies (Anomaly Detection) pour la production.
3. Risque de non-conformité : Faible. La certification HIPAA/PCI/GDPR/SOC de Lex couvre les principales exigences de conformité du secteur, et les données de conversation ne sont pas utilisées pour la formation des modèles Amazon. Cependant, veuillez noter que dans le scénario de secours génératif, les données seront transférées à Bedrock et vous devrez confirmer si les conditions de traitement des données de Bedrock répondent aux exigences de conformité internes.
4. Risque technique : moyen. Les limites de personnalisation de Lex sont en grande partie fixées dans la V2, et il est peu probable que les capacités de réglage fin de NLU soient ouvertes à court terme. Si le projet nécessite à l’avenir une personnalisation approfondie de la classification des intentions, l’architecture actuelle devra peut-être être réévaluée.

Dans l'ensemble, Lex convient particulièrement aux équipes disposant d'une « entrée de dialogue simple mais de canaux diversifiés et privilégiant la vitesse en ligne plutôt que la profondeur NLU ». Pour les scénarios dans lesquels la précision NLU est la principale compétitivité (comme les questions et réponses juridiques, le pré-diagnostic médical), il est recommandé d'utiliser Lex uniquement comme interface vocale et couche de distribution de canaux, acheminant l'intention vers le serveur personnalisé pour exécuter un pipeline NLU plus complexe.

Outils associés : , ChatGPT

Comment utiliser Amazon Lex

• Client Web : Vous pouvez l'utiliser en visitant le site officiel et en créant un compte. La plupart des fonctions ne nécessitent pas d'installation.
• Accès API : fournit une API RESTful, les développeurs peuvent obtenir la clé API et l'intégrer dans leurs propres applications.

Informations de version

• AmazonLex V2 ：Améliorez la stratégie de repli de l'IA générative, améliorez la précision des modèles NLU multilingues et mettez à niveau l'éditeur visuel de flux de conversation. （~2026-01）
• AmazonLex V1 ：La version initiale fournit des fonctionnalités NLU et ASR basées sur le moteur Alexa. （~2017-04）