DoorDash : un système d'IA vocale alimenté par Claude gère des centaines de milliers d'appels de Dashers par jour

• Building a Generative AI Contact Center Solution for DoorDash Using Amazon Bedrock, Amazon Connect, and Anthropic's Claude — AWS (case study)
• DoorDash successfully leverages Claude in Amazon Bedrock (one-sheeter) — Anthropic
• Deploy generative AI agents in your contact center for voice and chat using Amazon Connect, Amazon Lex, and Amazon Bedrock Knowledge Bases — AWS Machine Learning Blog

Contexte

DoorDash est la plus grande plateforme de commerce local et de livraison aux États-Unis, fondée en 2013. À la fin de 2023, le service comptait plus de 37 millions de consommateurs actifs mensuels et plus de 2 millions de Dashers actifs mensuels — les coursiers qui effectuent les livraisons. Les Dashers sont les principaux clients du centre de contact : ils ont besoin d'aide en cours de livraison, quand une question surgit à propos d'une commande, une adresse, une inscription, ou la rémunération.

Ce public a une contrainte majeure qui a façonné l'ensemble du projet : les Dashers sont au volant. Ils préfèrent l'appel au chat — et ils ne peuvent pas attendre. Chaque seconde de délai de réponse est un coursier debout à la porte d'un restaurant ou garé sur le bord d'une rue. La latence de réponse sur le canal vocal ici n'est pas une « mesure de qualité » mais du temps physique soustrait des gains d'une personne.

Le centre de contact de DoorDash fonctionne sur Amazon Connect — la plateforme cloud d'AWS — et gère un volume collectif de centaines de milliers d'appels par jour. Une nuance importante de ce cas que les racontages perdent souvent : au moment du lancement de l'IA générative, DoorDash avait déjà une automatisation vocale avancée sur Amazon Connect et Amazon Lex, et elle donnait des résultats mesurables. La tâche n'était pas de « remplacer un menu à tonalité » mais de franchir le plafond de ce qu'un bot NLU classique peut faire — sans dégrader la vitesse à laquelle les Dashers étaient habitués.

Problème

La base de référence de DoorDash était solide — ce qui rend ce cas plus honnête que la plupart. L'IVR en libre-service existant sur Amazon Connect et Amazon Lex avait déjà réduit les transferts d'agents de 49 %, généré une augmentation de 12 % de la résolution au premier contact, et économisait 3 millions de dollars en économies d'exploitation annuelles. Ce sont les résultats de l'automatisation classique, pré-générative — les attribuer correctement importe.

Le problème était le plafond : malgré ces résultats, la plupart des appels ont été redirigés vers des agents en direct. Un bot NLU classique guide confidemment les utilisateurs à travers des flux prédéfinis mais ne peut pas répondre à des questions variées « avec ses propres mots » à partir d'une base de connaissances : tout ce qui se trouve en dehors du flux va à un humain. À des centaines de milliers d'appels par jour, chaque point de pourcentage d'escalades signifie des dizaines d'agents en ligne.

L'IA générative a promis de combler exactement cette lacune, mais a imposé trois exigences strictes. Premièrement, la latence : un dialogue vocal s'effondre si le modèle réfléchit pendant cinq secondes — doublement inacceptable pour les conducteurs sur la route. Deuxièmement, la fiabilité : un modèle répondant aux coursiers à propos de la rémunération ne doit pas halluciner, doit résister à l'injection de prompts, et doit détecter les contenus abusifs. Troisièmement, les tests à grande échelle : avant le projet, l'équipe devait retirer des agents en direct des files d'attente d'aide pour exécuter une poignée de cas de test manuels par heure — aucun moyen de valider une IA vocale qui fait face à des centaines de milliers d'appels.

Solution

DoorDash a construit la solution avec le Centre d'innovation de l'IA générative d'AWS (GenAIIC) — un programme associant des experts AWS à l'équipe du client. En 8 semaines, les équipes ont conçu, construit et mis la solution à la disponibilité des tests A/B en production ; selon l'étude de cas, Bedrock en tant que plateforme gérée a réduit de moitié le temps de développement des applications d'IA générative.

La base est les modèles Claude d'Anthropic dans Amazon Bedrock. L'étude de cas explique le choix de Claude par trois propriétés critiques pour le support vocal : la capacité à atténuer les hallucinations, la résistance à l'injection de prompts, et la détection du langage abusif. Et avec la sortie de Claude 3 Haiku — le modèle le plus léger et le plus rapide de la famille — DoorDash a obtenu le mélange de précision et de vitesse dont il avait besoin : une latence de réponse de 2,5 secondes ou moins. Le choix lui-même est révélateur : pour le canal vocal, l'entreprise a pris non pas le modèle le plus puissant mais le plus rapide suffisamment précis.

La connaissance du système suit un schéma RAG : le centre d'aide public de Dasher de DoorDash sert de source, tandis que Knowledge Bases pour Amazon Bedrock — un service géré qui a épargné à l'équipe les intégrations personnalisées — gère l'indexation et l'ensemble du pipeline « récupération → augmentation de prompts ». Une contrainte de sécurité clé : aucune information d'identification personnelle n'est transmise à la boucle générative ; les données sont chiffrées et isolées dans l'application DoorDash. « L'utilisation de réponses générées par l'IA pour le support téléphonique a présenté des défis uniques qui ont exigé des stratégies innovantes pour améliorer les temps de réponse et la qualité des réponses. Amazon Bedrock s'est avéré être un ajustement parfait pour nos exigences, nous permettant de nous concentrer sur l'affinement des détails de la solution », déclare Vraj Shah, ingénieur principal de projet chez DoorDash.

La partie invisible mais décisive du projet est la boucle de test. Sur Amazon SageMaker, l'équipe a construit un cadre de test et d'évaluation automatisé : des milliers de tests automatisés par heure — une augmentation de capacité de test de 50x par rapport aux exécutions manuelles — avec une évaluation sémantique des réponses par rapport aux données de vérité de base. Cette boucle a permis d'exécuter des tests A/B sur le trafic en direct et de prouver la qualité avant le déploiement complet. Sans elle, faire passer une IA vocale de la conception à la production en 8 semaines aurait été impossible.

Architecturalement, la solution est intégrée dans la pile Amazon Connect existante : la couche générative augmente le IVR fonctionnant plutôt que de remplacer le canal — les cas complexes et non-routiniers vont toujours aux agents en direct.

Résultat

Après des tests réussis au début de 2024, DoorDash a déployé les nouvelles options en libre-service à tous les Dashers. L'IA vocale traite des centaines de milliers d'appels de Dashers quotidiennement avec une latence de réponse de 2,5 secondes ou moins. Selon les termes de l'étude de cas, la solution a entraîné des « réductions importantes et substantielles » dans les volumes d'appels pour les demandes d'assistance liées aux Dashers, a réduit les escalades vers les agents en direct de milliers par jour, et a réduit le nombre de tâches que les agents effectuent pour résoudre les demandes. L'IA ferme les questions routinières, libérant les agents pour les cas complexes qui ont besoin d'un humain.

Il est important de maintenir le cadre d'attribution — et de corriger une retransmission généralisée de ce cas (y compris notre version antérieure) : les chiffres « −49 % transferts, +12 % résolution au premier contact, 3 millions de dollars d'économies annuelles » appartiennent à la génération d'automatisation précédente de DoorDash sur Amazon Connect et Amazon Lex — la base sur laquelle la couche générative a été construite. Pour la solution Claude elle-même, AWS et DoorDash publient des métriques de vitesse et d'échelle (2,5 s ; des centaines de milliers d'appels par jour ; capacité de test de 50x ; -50 % temps de développement) et des déclarations d'impact qualitatif (« des milliers d'escalades par jour »), mais pas de pourcentages ni de dollars. C'est une pratique typique et honnête pour un nouveau déploiement — les effets financiers précis prennent un an d'observation.

L'équipe a déjà annoncé l'étape suivante : élargir les bases de connaissances et intégrer le service de flux de travail logistique événementiel de DoorDash afin que l'assistant non seulement réponde aux questions mais prenne également des mesures au nom de l'utilisateur. « Grâce à AWS et Claude d'Anthropic, nous avons construit une solution qui donne aux Dashers un accès fiable et facile à comprendre aux informations dont ils ont besoin, quand ils en ont besoin. Cela a des impacts positifs en cascade sur nos utilisateurs et la plateforme dans son ensemble », déclare Chaitanya Hari, Responsable de produit du centre de contact chez DoorDash.

À notre avis, il y a trois leçons transférables. Premièrement : pour l'IA vocale, la vitesse est l'exigence produit numéro un, et choisir un modèle léger (Haiku) plutôt que le vaisseau amiral est une économie d'ingénierie solide applicable à tout scénario en temps réel. Deuxièmement : l'infrastructure de test importe plus que l'« intelligence » du modèle — l'augmentation de la capacité de test de 50x est la raison pour laquelle le projet a atteint la production en 8 semaines. Troisièmement : construisez la couche générative au-dessus de l'automatisation fonctionnelle, pas à la place de celle-ci — DoorDash a augmenté une base de référence IVR solide, ce qui est exactement pourquoi elle pouvait honnêtement mesurer la valeur ajoutée par les tests A/B.

Leçons

1. Pour les scénarios vocaux, la vitesse est une exigence produit : DoorDash a choisi un modèle léger (Claude 3 Haiku) pour une latence ≤2,5 s plutôt que le plus puissant de la gamme.
2. Attribuez les métriques honnêtement : les célèbres « −49 % transferts et 3 millions de dollars d'économies » sont le résultat du IVR Connect/Lex pré-génératif ; la valeur de la couche Claude est mesurée séparément, au-dessus de cette base de référence.
3. Une boucle de test automatisée est la pièce invisible mais critique : une capacité de test de 50x (des milliers d'exécutions par heure avec évaluation sémantique) est ce qui a rendu la production possible en 8 semaines.
4. La couche générative augmente l'automatisation fonctionnelle au lieu de remplacer le canal : les cas complexes vont toujours aux humains, et la valeur ajoutée peut être honnêtement mesurée via les tests A/B.
5. La sécurité est conçue dans l'architecture : aucune information d'identification personnelle n'entre dans la boucle générative, et le modèle a été choisi en partie pour sa résistance à l'injection de prompts et sa détection du langage abusif.
6. Le premier public est les coursiers, pas les clients : un public interne donne un cycle de rétroaction rapide à un risque réputationnel plus faible.
7. Une plateforme gérée (Bedrock + Knowledge Bases) a réduit de moitié le temps de développement — au départ, la vitesse d'itération importe plus que l'affinement de votre propre infrastructure.

Questions fréquentes