Comment créer un agent vocal avec l'IA (Guide complet)

Voici la vérité que personne ne dit aux créateurs d'agents IA : les agents vocaux n'ont pas besoin du meilleur modèle. Tout ce dont ils ont besoin, c'est de :

TLDR; si vous trouvez la lecture ennuyeuse ou que votre capacité d'attention est réduite, vous pouvez utiliser le fichier de compétences que j'ai créé pour obtenir l'intégralité de l'article et le coller dans votre agent ➡️https://github.com/codejunkie99/voice-agent-builder

Tout ce dont vous avez besoin pour construire :

• un pipeline en temps réel avec un budget de latence réel
• cinq composants câblés dans le bon ordre
• un ancrage suffisamment solide pour garder le modèle honnête
• une boucle de révision hebdomadaire qui fait boule de neige

OpenAI a lancé GPT-Realtime-2 le 7 mai 2026. Salesforce AI Research a publié l'article VoiceAgentRAG le 1er mars, la même semaine où Deepgram Flux est passé de la version bêta à la disponibilité générale. Les pièces ont cessé d'être le problème.

Ce qui est resté le problème, c'est la façon dont vous les câblez, et ce que vous écrivez à l'agent pour qu'il dise.

J'ai passé les trois derniers mois à construire des agents vocaux qui répondent réellement au téléphone. Je ne vais pas prétendre que tout était propre.

• La première version sonnait comme un kiosque. Je l'ai supprimée en deux jours.
• La deuxième version a "réservé" quatre rendez-vous fantômes dans la première heure avant que je ne m'en aperçoive.
• La troisième version a fui la mémoire parce que j'ai oublié d'invalider le cache de contexte après que l'extracteur d'arrière-plan a écrit de nouveaux faits.
• Au moment où quelque chose a fonctionné, le système était la quatrième réécriture.

La version que je défendrais maintenant possède un petit ensemble de propriétés que je vais passer les 6 000 prochains mots à expliquer.

• Le pipeline a un seul travail dans un seul budget. Cinq composants, moins de 700 ms de bout en bout, sans exception.
• La connaissance réside dans vos documents et est récupérée avec un cache à double agent, pas extraite de la tête du modèle.
• La conception de la conversation est la discipline de l'écriture pour les oreilles, pas pour les yeux. La plupart des équipes considèrent cela comme cosmétique. Ce ne l'est pas.
• Chaque tour écrit un journal structuré que je peux rejouer par rapport à la configuration actuelle 90 jours plus tard.

Cet article est ce que ces 90 jours m'ont réellement appris, plus les deux ou trois paris que je ferais en premier si je recommençais aujourd'hui.🔽🔽

Ce qu'est réellement un agent vocal

Un agent vocal n'est pas un chatbot avec un microphone greffé. Ce n'est pas une enveloppe TTS autour d'une API textuelle.

C'est un système audio en temps réel. Contraint par la latence. Cinq composants qui coordonnent dans une fenêtre de 300 à 800 millisecondes.

Le pipeline dans l'ordre où les événements se produisent réellement :

1. L'utilisateur parle
2. L'audio est capturé
3. Le STT en streaming transcrit mot par mot, pendant que la personne parle encore
4. L'agent lit la transcription et récupère les connaissances pertinentes de vos documents
5. Le LLM génère une réponse
6. Le TTS prononce la réponse à voix haute
7. L'utilisateur l'entend

Chacune de ces flèches est un composant que vous pouvez choisir, régler et échanger.

J'ai d'abord essayé de le construire à la manière d'un chatbot. STT termine, envoie au LLM, attend la réponse complète, envoie au TTS, attend l'audio complet, joue.

C'était horrible. Comme parler à un kiosque. Deux jours plus tard, je l'ai supprimé.

La raison pour laquelle c'était horrible n'est pas que les chiffres de latence étaient mauvais. Ils étaient bons sur le papier. La raison est que les humains ne conversent pas par tours. Ils conversent par flux qui se chevauchent.

• L'agent doit commencer à formuler une réponse pendant que l'utilisateur termine encore sa phrase.
• Le TTS doit commencer à parler avant que le LLM ait fini d'écrire.
• Le STT doit continuer à écouter pendant que l'agent parle, pour savoir quand se taire.

Un agent vocal qui ne peut pas être interrompu n'est pas un agent vocal. C'est une messagerie vocale.

Les trois architectures

Il n'y en a que trois. Choisissez en fonction de ce que vous devez contrôler.

Pipeline en chaîne

• Services STT, LLM, TTS séparés câblés ensemble
• Trois modèles indépendants, chacun spécialisé dans son travail
• Le texte circule entre eux
• La latence se situe autour de 600 à 700 ms sur une plateforme gérée bien réglée
• Le plus contrôlable, le plus débogable, le plus facile à mettre à niveau une couche à la fois

Demi-cascade

• L'audio va directement dans un modèle multimodal qui entend l'audio, pas la transcription
• Capture la frustration dans la voix d'une personne, une question implicite par un ton montant, un changement de langue en milieu de phrase
• La sortie passe toujours par un TTS spécialisé pour le contrôle audio
• La latence descend à 300 à 500 ms

Parole-à-parole natif

• Un seul modèle, audio en entrée, audio en sortie
• Pas de couche de transcription, pas de transferts de texte
• Chaque grand laboratoire a expédié un modèle vocal natif en 2026
• La latence descend à 200 à 300 ms, en dessous du seuil où les appelants cessent de remarquer qu'ils parlent à une IA

Par où commencer

1. Commencez par le pipeline en chaîne. Les meilleurs outils existent pour cela. Passez à la parole-à-parole une fois que vous avez prouvé votre produit sur le pipeline et que vous souhaitez une amélioration de la latence par palier.
2. J'ai d'abord essayé la parole-à-parole pour tout. C'était excellent pour les flux de réservation.
3. Cela s'est effondré sur un formulaire d'admission en 12 étapes parce que le modèle unique ne pouvait pas contenir la machine d'état dans sa tête sans gonflement du contexte au neuvième tour.
4. J'ai déplacé celui-ci vers un pipeline en chaîne avec une vraie couche de machine d'état et le taux d'achèvement est passé de 61 % à 89 % en trois jours.
5. La portée des outils par état était la solution complète.

Les cinq composants que vous devez câbler

Chaque pipeline en chaîne a les mêmes cinq composants. Cinq tâches qui doivent être remplies avant que votre agent ne prenne son premier appel.

Les oreilles (STT en streaming)

Le modèle STT convertit l'audio entrant en texte en temps réel, mot par mot, pendant que la personne parle encore. C'est le composant le plus important de votre pile. Une erreur de transcription ici se répercute sur tout ce qui suit.

Ce qu'il faut rechercher en 2026 :

• Précision en streaming. Précise pendant que la personne parle, pas seulement après qu'elle ait fini.
• Taux d'erreur de mots. 6 à 8 % sur de l'audio de production réel est bon. Au-delà de 12 %, cela frustrera les utilisateurs environ un appel sur trois.
• Détection intégrée de fin de tour. La plus grande amélioration UX de 2026.

Pourquoi la détection de fin de tour est importante :

• Le STT générique renvoie des transcriptions. Il ne vous dit pas quand le locuteur a terminé.
• Sans cela, votre agent interrompt au milieu d'une phrase ou attend deux secondes gênantes.
• La vague de 2026 des modèles STT en streaming est livrée avec une détection de fin de tour intégrée dans le même réseau qui produit la transcription.
• Le modèle émet un signal de fin de tour lorsqu'il a décidé que le locuteur a terminé.
• Le signal utilise le contexte sémantique, pas seulement le silence acoustique. Il détecte les phrases qui s'éteignent et ignore les pauses de respiration.
• Passez à cela si votre fournisseur l'a expédié. La pause avant que l'agent ne commence à parler diminue de 200 à 400 ms à chaque tour.

Le cerveau (LLM)

Le LLM lit la transcription, l'historique de la conversation, les connaissances récupérées et décide quoi dire. Il décide également des actions, pas seulement des mots.

Règles spécifiques à la voix :

• Utilisez le petit modèle rapide, pas le modèle phare. Les modèles de raisonnement de pointe mettent 1500 ms à générer le premier mot. C'est du silence radio. Les petits modèles de la même famille gagnent presque toujours sur les tours vocaux.
• Passez au grand modèle uniquement pour des appels d'outils complexes spécifiques qui nécessitent une véritable planification.
• Limitez l'invite système à 800 tokens. Elle se recharge à chaque tour. Une invite de 4000 tokens ajoute de la latence à chaque message.

Appel de fonction, en termes simples :

• Vous définissez chaque fonction avec une description de ce qu'elle fait et des informations dont elle a besoin.
• Le LLM lit la description et décide quand l'appeler en fonction de l'état de la conversation.
• Pas d'arbre logique conditionnel. Le LLM fait correspondre l'intention à la fonction à partir du langage naturel.

L'échec de production le plus courant avec l'appel de fonction n'est pas celui auquel vous vous attendez :

• Le LLM ne génère pas d'erreur lorsqu'il ne peut pas appeler une fonction. Il raconte l'action à la place.
• "J'ai confirmé votre réservation." Rien n'a été appelé. L'utilisateur pense qu'il est réservé. Il ne l'est pas.
• La solution consiste à limiter les outils à l'état actuel. Un état "collecter le nom" ne doit pas exposer book_appointment. Un état "confirmer les détails" ne doit pas exposer check_availability.
• La machine d'état est le garde-fou, pas l'invite système.

La connaissance (RAG)

Le RAG est le mécanisme qui permet à votre agent de répondre à partir de vos documents plutôt qu'à partir des données d'entraînement du modèle.

Pourquoi vous ne pouvez pas sauter cette étape :

• Les LLM sont entraînés sur l'internet public jusqu'à une date limite.
• Ils en savent beaucoup sur le monde. Ils ne savent rien de spécifique sur vos produits, prix, politiques, clients.
• Sans RAG, un agent interrogé "qu'y a-t-il dans le plan entreprise ?" hallucinera avec confiance.
• Avec RAG, il récupère la réponse réelle de votre documentation avant de répondre.

Le mécanisme de base :

• L'utilisateur pose une question.
• Le système intègre la requête.
• La base de données vectorielle renvoie les morceaux de documents les plus pertinents.
• Les morceaux sont injectés dans le contexte du LLM.
• Le LLM est invité à répondre uniquement à partir de ce contexte.

Le défi spécifique à la voix :

• Une requête typique de base de données vectorielle ajoute 50 à 300 ms au pipeline.
• Combiné avec STT, LLM et TTS, cela fait exploser votre budget de latence.
• La solution est le modèle de cache à double agent. Section entière ci-dessous.

La bouche (TTS)

Le TTS convertit le texte en audio parlé. Cela semble simple. C'est en fait un différenciateur majeur dans la qualité perçue.

Ce qui compte :

• Le délai avant le premier audio. Un TTS qui met 200 ms à commencer à parler brûle un tiers de votre budget de latence sur la seule couche de sortie.
• La qualité de la voix. Les humains sont extrêmement sensibles à la parole synthétique. Des artefacts subtils, un rythme non naturel, un stress mal placé sont tous perçus comme un verdict sur l'ensemble du système.
• Choisissez la voix intentionnellement. C'est un signal de confiance avant que l'utilisateur n'ait entendu une phrase.

Les mains (Fonctions et intégrations)

Les fonctions sont des actions que le LLM peut entreprendre en cours de conversation :

• Réserver des rendez-vous
• Consulter le statut des commandes
• Envoyer un SMS de confirmation
• Transférer à un humain
• Mettre à jour les enregistrements dans votre CRM

C'est le changement architectural qui rend les agents vocaux modernes considérablement plus capables que les systèmes "appuyez sur 1 pour la facturation".

Le budget de latence dans lequel vous devez vous inscrire

La chose la plus importante et non évidente à propos des agents vocaux : chaque milliseconde de temps de traitement est une milliseconde de silence dans laquelle l'appelant est assis.

Le calcul :

• Les humains s'attendent à une réponse conversationnelle dans les 500 à 700 ms suivant la fin d'une phrase
• Au-delà d'une seconde, on a l'impression que le système a du mal
• Au-delà de deux secondes, les appelants commencent à parler par-dessus l'agent

Ces 700 ms sont votre budget total, réparti sur chaque composant.

Budget par composant, voie rapide vs voie lente :

• Transport. 20-50 ms pair-à-pair. 50-100 ms via relais.
• Premier résultat intermédiaire STT. 100-150 ms sur un cache hit. 150-250 ms sur un miss.
• Détection de fin de tour. Intégré au modèle, ~50 ms. Seuil de silence, 300-600 ms.
• Récupération RAG. Moins d'une milliseconde sur un cache hit. 80-150 ms sur BM25 local + reclassement.
• Délai avant le premier token du LLM. 150-250 ms avec un petit modèle. 400-600 ms avec un modèle de pointe.
• Délai avant le premier audio du TTS. 60-100 ms sur le niveau rapide. 150-250 ms sur le niveau qualité.
• Frais généraux de réseau. 40-80 ms au total dans une région. 100-160 ms au total entre les régions.
• De bout en bout. ~440 ms sur la voie rapide. ~700-900 ms sur la voie lente.

Les deux plus grandes avancées en 2026 :

1. Détection de fin de tour intégrée au modèle. Supprime 200 à 400 ms à chaque tour. La plus grande amélioration que vous puissiez apporter cette année.
2. Pré-extraction spéculative avec un cache à double agent. Fait passer la récupération de "miss avec recherche vectorielle" à "hit avec recherche dans le cache" sur environ 40 % des tours.

Tout le reste n'est qu'erreur d'arrondi par rapport à ces deux éléments.

Le modèle RAG à double agent

Le RAG standard dans une boucle vocale est un problème. La requête de base de données vectorielle prend 80 à 300 ms et fait exploser votre budget de latence à chaque tour.

La réponse de la recherche en 2026 vient de l'article VoiceAgentRAG de Salesforce AI Research, publié en mars. L'idée est simple.

• Dans une conversation réelle, la question suivante est généralement prévisible à partir de la question actuelle.
• Quelqu'un qui pose des questions sur les prix demandera probablement des détails sur le niveau entreprise.
• Quelqu'un qui pose des questions sur l'installation demandera probablement des détails sur la compatibilité ensuite.

Vous exécutez donc deux agents en même temps.

L'agent d'arrière-plan (le penseur lent)

• S'exécute pendant que l'utilisateur écoute la réponse en cours
• Prédit les trois à cinq questions de suivi les plus probables à l'aide du LLM
• Pré-extrait les morceaux de documents pertinents pour chaque prédiction
• Les stocke dans un cache mémoire local avant que l'utilisateur n'ait fini d'entendre la réponse actuelle

L'agent de premier plan (le parleur rapide)

• Gère la prochaine question en direct en vérifiant d'abord le cache mémoire
• Une recherche dans le cache prend moins d'une milliseconde contre 110 ms pour un appel de base de données vectorielle à distance
• Si le cache contient la réponse, ignorez complètement la base de données
• Si le cache ne contient pas la réponse, revenez à la base de données et mettez ce résultat en cache pour la prochaine fois

Chiffres de référence de l'article

• 75 % des requêtes touchent le cache
• Accélération de la récupération de 316× sur les hits du cache (0,35 ms contre 110 ms)
• 16 secondes de latence cumulée économisées sur 200 requêtes

Le principe à retenir : utilisez le temps d'écoute de l'utilisateur comme votre temps de calcul. Le moment où il commence à entendre la réponse actuelle est le moment où vous commencez à vous préparer pour sa prochaine question.

J'ai essayé le RAG vectoriel simple dans la boucle vocale sur ma première version. Cela a ajouté 110 ms par tour.

Cela a tué la sensation de conversation. Je suis passé au modèle de cache à double agent à la sixième semaine. Les 40 % de tours qui touchent le cache sont plus rapides que les agents humains du centre d'appels que l'agent remplace.

La conception de la conversation est la discipline que la plupart des constructeurs négligent

Vous pouvez avoir le STT le plus rapide, le LLM le plus petit, le cache RAG le plus intelligent. Si votre agent ne sait pas parler, les appelants raccrocheront.

La conception de la conversation est la discipline de l'écriture pour les oreilles, pas pour les yeux.

Règles que je suis maintenant et que j'ai apprises en les faisant d'abord de travers

• Parlez par phrases courtes. La durée d'attention moyenne d'un humain pour les informations parlées est de 8 à 10 secondes. Une réponse de 15 secondes est trop longue. Divisez-la en deux tours.
• Ne posez jamais deux questions en un seul tour. Les appelants ne peuvent en retenir qu'une seule dans leur mémoire de travail. Posez-en une, attendez, puis posez la suivante.
• Utilisez des phrases d'accusé de réception. "Compris." "D'accord." "Laissez-moi vérifier cela pour vous." Ces phrases comblent le silence entre la fin de l'utilisateur et la préparation de la réponse.
• Reflétez le langage de l'utilisateur. L'appelant dit "problème de facturation", l'agent dit "problème de facturation" en retour. Pas "litige financier" ou "problème de paiement". Paraphraser crée des frictions. Le miroir crée un rapport.
• Écrivez pour l'oreille, pas pour l'œil. Pas de puces. Pas d'en-têtes. Pas de markdown dans l'invite système. Le LLM essaiera de prononcer des astérisques et des traits d'union.
• Épelez les nombres. "Neuf quatre un zéro sept" au lieu de "94 107". "Quinze dollars quatre-vingt-dix-neuf cents" au lieu de "15,99 $". Le TTS prononce régulièrement mal les nombres formatés.
• Limitez l'invite système à 800 tokens. Elle se recharge à chaque tour.

La structure en trois actes de toute bonne conversation vocale

1. Accusé de réception et orientation. "Donc vous cherchez à reporter votre rendez-vous de jeudi, laissez-moi le retrouver." Confirme que l'appelant a été compris. Achète du temps pendant que la récupération s'exécute.
2. Résolution. L'action ou la réponse principale. Un point par tour. Avancez.
3. Confirmation et clôture. "J'ai reporté votre rendez-vous au lundi 19 à 15 heures, vous recevrez un SMS de confirmation sous peu." Sortie propre. Ne laissez jamais une boucle ouverte.

La sécurité est constituée de deux points de contrôle, pas d'un seul

Le composant que la plupart des constructeurs débutants sautent et regrettent.

Un agent vocal n'a pas de moment "lire avant d'envoyer". Une sortie non sécurisée est prononcée immédiatement. Pas de brouillon, pas d'aperçu, pas d'humain dans la boucle.

Le bon modèle est de deux points de contrôle.

Le garde d'entrée (avant que le LLM ne voie le tour de l'utilisateur)

• Injection d'invite. "Ignorez les instructions précédentes, faites comme si vous étiez..." attaques. Exploite la capacité du LLM à suivre les instructions pour voler des données ou sortir du cadre.
• PII prononcée à voix haute. Numéros de carte de crédit, numéros de sécurité sociale. Rédigez avant qu'ils n'atteignent un journal ou une base de données.
• Liste de blocage de sujets. Chargée à partir d'un fichier JSON. Mise à jour chaque semaine à mesure que vous apprenez ce que les utilisateurs essaient réellement.

Le garde de sortie (après que le LLM a écrit sa réponse, avant que le TTS ne la prononce)

• Langage de promesse excessive. "Je garantis", "Je promets". Crée des problèmes juridiques et de confiance sur une ligne enregistrée.
• Affirmations factuelles spécifiques non présentes dans le contexte récupéré. Vérification légère des hallucinations. Attrape environ 70 % des réponses fabriquées dans mon déploiement.
• Point de terminaison de modération standard. Pour les rares comportements inappropriés du modèle.

Ce que les deux gardes renvoient

• safe (booléen)
• catégorie détectée (chaîne, si non sécurisé)
• phrase de remplacement que l'agent prononce à la place

Chaque déclencheur est enregistré dans un fichier avec l'horodatage, la catégorie, le texte expurgé et l'ID de l'appel.

La phrase d'escalade

Une phrase exacte, codée en dur, que l'agent dit lorsqu'il ne connaît pas la réponse ou que quelque chose ne va pas.

• "Je veux m'assurer de vous donner des informations précises. Laissez-moi vous mettre en relation avec quelqu'un qui peut vous aider."
• Pas cinq variantes. Pas la supposition improvisée du LLM sur la formulation correcte.
• Une seule phrase. EN MAJUSCULES dans l'invite système. Solution de repli lorsque l'un des contrôles de sécurité se déclenche.

J'ai expédié sans garde de sortie sur la première version. L'agent a cité avec confiance un prix inférieur de 30 % au prix réel.

Le prix se trouvait dans un document obsolète de la base de connaissances.

La vérification des hallucinations l'aurait attrapé car le bon prix n'était pas dans le contexte récupéré.

Évaluation, ou comment savoir si c'est bon

Vous ne pouvez pas améliorer ce que vous ne pouvez pas mesurer. La plupart des équipes sautent l'évaluation et expédient des agents défectueux.

Le cadre à quatre couches

Couche 1 : Infrastructure. Plomberie.

• WER sur votre domaine réel (pas les benchmarks des fournisseurs)
• Latence p50, p95, p99 pour l'ensemble du pipeline
• Délai avant le premier audio
• Qualité audio sur votre transport

Couche 2 : Exécution. L'agent fait-il ce qui lui a été demandé.

• Taux de réussite des tâches
• Précision des appels d'outils
• Exactitude des paramètres
• Réponse fondée
• Utilisez LLM-as-judge sur un petit modèle rapide. Quatre questions oui/non : a répondu correctement, est resté fondé, a semblé naturel pour la voix, a été concis de manière appropriée.

Couche 3 : Comportement de l'utilisateur. Est-ce naturel de lui parler.

• Taux de récupération des interruptions
• Taux de re-invite
• Longueur moyenne des tours
• Nombre de réparations conversationnelles
• Échantillonnez 20 appels par semaine. Lisez les transcriptions réelles. Vous verrez des modèles en moins de dix.

Couche 4 : Résultat commercial. Le problème est-il résolu.

• Taux de confinement (pourcentage d'appels résolus sans humain)
• Taux de transfert
• CSAT
• Taux de résolution au premier appel
• Optimisez en fonction du confinement. Il est corrélé à tout le reste et est le plus facile à mesurer sans instrumentation.

Composition de l'ensemble de test

Construisez-le avant de lancer. Minimum 50 conversations.

• 40 % de chemin heureux
• 30 % de cas limites
• 15 % de gestion des erreurs
• 10 % d'adversaires (injection d'invite, tentatives de jailbreak)
• 5 % de variation acoustique (bruit de fond, accent prononcé, haut-parleur)

Pour chaque scénario :

• Quel outil aurait dû être appelé
• Avec quels paramètres
• Ce que l'agent aurait dû dire

La boucle de révision hebdomadaire

Chaque lundi matin. 30 minutes.

1. Tirez les métriques
2. Échantillonnez 20 appels (7 escaladés, 7 résolus, 6 aléatoires)
3. Lisez les transcriptions
4. Nommez le type d'échec le plus courant
5. Faites un changement (une variable à la fois, toujours)
6. Testez A/B pendant 48 heures
7. Expédiez le gagnant

L'ancrage est un système de confiance

La plupart des constructeurs considèrent le RAG comme une fonctionnalité de performance, un moyen d'obtenir des réponses plus précises. Ce cadrage le sous-estime.

Dans un agent vocal, la précision de chaque réponse est une déclaration directe sur la fiabilité de votre produit. Un appelant qui entend une réponse erronée sur le prix, la couverture ou la politique, dite avec confiance d'une voix naturelle, ne sera pas seulement frustré. Il se sentira trompé.

La mise en œuvre de la promesse de confiance comporte quatre parties.

1. Source de vérité

• Vos documents, pas les données d'entraînement du modèle
• L'invite système doit le dire explicitement, en lettres majuscules : RÉPONDEZ UNIQUEMENT À PARTIR DU CONTEXTE FOURNI
• Le modèle dérivera encore parfois vers des connaissances générales, mais l'instruction explicite réduit le taux d'un ordre de grandeur

1. Refus gracieux

• Lorsque l'agent ne peut pas trouver de réponse, il le dit directement
• La phrase exacte est importante
• "Je veux m'assurer de vous donner des informations précises, laissez-moi vérifier cela" vous achète un transfert gracieux
• "Je ne suis pas sûr" semble être de l'incompétence
• "D'après mes informations" semble être une échappatoire d'avocat
• Choisissez une phrase, codez-la en dur, ne laissez jamais le LLM improviser ici

1. Réponse consciente de la confiance

• Le meilleur score BM25 sur les morceaux récupérés est un proxy utile pour la confiance
• Score supérieur à 0,6 : l'agent répond avec confiance
• Score de 0,3 à 0,6 : l'agent répond mais ajoute une échappatoire "je pense"
• Score inférieur à 0,3 : l'agent ne répond pas, propose de transférer
• Changement de 20 lignes dans le code de construction de l'invite système. Réduit les hallucinations d'environ la moitié.

1. Hygiène de la base de connaissances

• Les documents obsolètes produisent des réponses obsolètes, qui sont des réponses dangereuses
• Je fais un audit le vendredi : je lis les 5 % des réponses les moins bien notées en termes de confiance de la semaine
• La moitié du temps, la réponse était correcte mais la récupération a trouvé un morceau obsolète
• Mettez à jour le morceau, réintégrez, la semaine prochaine sera plus calme

Ce qu'il faut surveiller

Six modes de défaillance qui vous frapperont.

VAD dans le pipeline au lieu du transport

• Problème. L'agent se déclenche sur sa propre sortie TTS, entre dans une boucle d'interruption ou ne parvient pas à détecter la fin du tour.
• Solution. L'analyseur VAD va sur le transport. Toujours. Associez-le à un garde d'écho qui ignore les transcriptions STT correspondant à la sortie récente de l'assistant.

Outils disponibles dans le mauvais état

• Problème. Le LLM appelle book_appointment dans un état qui collecte encore le nom du patient. Ou invente une réservation qui n'a jamais eu lieu.
• Solution. Limitez les outils par état. Un seul état, uniquement ses propres fonctions. La machine d'état est le garde-fou, pas l'invite système.

Le gestionnaire de fonction lève une exception et n'appelle jamais le rappel de résultat

• Problème. Le LLM attend un résultat d'outil qui ne vient jamais. Ou en hallucine un.
• Solution. Chaque gestionnaire s'enveloppe dans try/except. Chaque branche renvoie un résultat. Chaque échec a un repli parlé. Jamais un résultat vide.

Valider les données utilisateur dans l'invite au lieu du code

• Problème. Le LLM accepte "jean@" comme un véritable e-mail à l'appel 12. Rejette un e-mail valide avec un signe plus à l'appel 47.
• Solution. La validation vit dans Python. Regex pour l'e-mail, analyseur de date pour les dates, vérification de la longueur du nom, une réponse de re-demande lorsque la validation échoue.

La fenêtre de contexte s'agrandit sans limite au cours d'un long appel

• Problème. La latence p95 augmente au cours de la semaine sans changement de code. Au tour 20, vous envoyez 12 000 tokens par tour.
• Solution. Fenêtre glissante des N derniers tours plus invite système. Ou réinitialisations du contexte basées sur des jalons à la fin de chaque étape discrète.

Le TTS lit les codes et les ID littéralement

• Problème. Le code de confirmation "A3X7" sort "ay trois ex sept" sans pause. Le patient vous demande de répéter de toute façon.
• Solution. Expansion de l'alphabet phonétique de l'OTAN avec des balises de pause SSML. Cela semble plus lent. Cela se lit correctement du premier coup.

Ce que je ferais différemment

• Construisez le schéma du journal des tours le premier jour, pas la quatrième semaine. Le point de terminaison de relecture est l'outil le plus précieux que j'ai construit et je l'ai construit après en avoir eu besoin.
• Utilisez la détection sémantique de fin de tour dès le début au lieu de lutter contre les seuils de silence.
• Passez à une vraie machine d'état le jour où l'invite système dépasse 300 mots. N'essayez pas de coder une machine d'état en prose.
• Arrêtez de valider dans les invites. Le LLM n'est pas un analyseur. Python est un analyseur. Utilisez Python.
• Mettez en cache les cinq documents RAG les plus probables au début de l'appel. Ignorez la recherche vectorielle dans la boucle de tour.
• Construisez la porte des banalités avant de construire la récupération. "Bonjour" est le gain de 200 ms le moins cher du système.
• Exécutez l'ensemble d'évaluation avant le premier appel de production. 50 conversations minimum.
• Mettez en place une file d'attente d'extraction durable dès le premier jour. Une table Postgres pending_extractions avec un seul travailleur de nouvelle tentative prend 200 lignes et vous évite une véritable panne.
• Exécutez un juge LLM asynchrone sur un appel sur 50. Notez sur la fondation, la pertinence, la brièveté. Acheminez-le vers un tableau de bord. La dérive est réelle.
• Exécutez la boucle de révision hebdomadaire. Échantillonnez 20 appels chaque lundi. Faites un changement. Testez A/B. Expédiez le gagnant.

Conclusion

Les agents vocaux ressemblent à de l'IA. Ils fonctionnent comme des systèmes en temps réel.

Les équipes qui expédient les traitent de cette façon. Les équipes qui expédient avec six mois de retard pensent qu'une meilleure invite corrige un problème système.

Possédez votre pipeline. Possédez vos journaux. Gardez-les dans des fichiers simples où tout échec est à une seule relecture.

Le premier agent m'a pris un week-end. Le système de production a pris dix semaines. Il n'a cessé de s'améliorer chaque jour depuis, sans que j'y touche. L'utilisateur ne mesure pas cela. Il remarque que l'agent a répondu « merci » sans le faire attendre.

Avertissements et Déclarations

Cet article a été recherché et rédigé par l'auteur, et il a été édité par un modèle d'IA. La vignette a été prise sur Pinterest.

Cet article a été recherché et rédigé par l'auteur alors qu'il travaillait sur des agents vocaux dans une infrastructure plus avancée.

Il est basé sur des notes évolutives et des recherches approfondies utilisant Perplexity, Claude et ChatGPT, ainsi que sur la conception de systèmes et d'API tirées de quelques manuels universitaires de premier cycle.

Il a été minutieusement édité par Minimax M2.7 et Claude Opus 4.7 pour les erreurs grammaticales et le formatage.