Ne pas créer de boucle de latence : la place des boucles d'agent dans l'IA vocale

On a parfois l’impression qu’il y a chaque semaine un nouveau workflow ou une nouvelle bonne pratique à maîtriser en matière d’IA. «L’ingénierie des boucles» est l’une des dernières en date, mais le principe en lui-même est simple.

Pensez à utiliser un rouleau anti-peluches. Vous passez le rouleau sur votre chemise, vous vérifiez si les peluches ont disparu, puis soit vous arrêtez, soit vous recommencez. Vous décidez également que vous n’allez pas rester là à passer le rouleau indéfiniment.

Une boucle d'agent suit le même schéma. On confie une tâche à l'agent, on définit comment mesurer sa réussite, puis on automatise le cycle consistant à agir, à vérifier et à décider s'il faut continuer. La boucle s'arrête lorsque le résultat satisfait à cette vérification ou lorsque la limite de temps, de coût ou de nombre de tentatives est atteinte.

Cela revêt une importance particulière dans le domaine de l'IA vocale. Une conversation en direct privilégie la rapidité, tandis que l'évaluation et l'amélioration demandent du temps. Comment concilier ces deux aspects lors de la conception ?

Cet article explique comment définir cette limite dans une architecture d'agents vocaux Vonage, en précisant dans quels cas les boucles d'agents sont pertinentes et dans quels cas elles ne le sont pas.

The voice agent responds quickly during the live call, while an offline loop reviews the interaction, verifies proposed changes, and improves future responses.

Pourquoi la voix influence la conception

La latence vocale correspond au délai entre le moment où l'appelant termine son intervention et celui où il entend la réponse de l'agent.

Sur un site web, une opération lente peut s'accompagner d'un indicateur de chargement ou d'une mise à jour d'une partie de la page. Lors d'un appel téléphonique, un temps d'attente est perçu comme un silence. L'appelant ne peut ni parcourir rapidement le contenu, ni changer d'onglet, ni voir que le système est toujours en cours de traitement. Même une brève pause peut être interprétée comme un problème, une coupure de la ligne ou une requête ayant échoué.

Le délai s'accumule également au fur et à mesure. Le système peut être amené à :

1. Comprendre ce que dit la personne qui appelle.

2. Déterminez ce dont ils ont besoin.

3. Appelez tous les systèmes externes nécessaires.

4. Générer et renvoyer une réponse vocale.

Un appel de fonction trop lent, une nouvelle tentative de modélisation ou un retard dans la réponse de la synthèse vocale a des répercussions sur tout ce qui suit.

Les boucles rendent le délai plus difficile à prévoir. Le système ne peut pas savoir à l'avance s'il aura besoin d'un passage, de trois passages ou de plusieurs appels d'outils avant que le résultat puisse être vérifié.

Cela nous amène à la question fondamentale en matière de conception :

Que faut-il faire pendant que l'appelant est en attente, et que peut-on faire par la suite ?

Tracez la ligne de latence

La solution consiste à considérer l'agent vocal comme deux entités fonctionnant selon des horloges différentes.

Le workflow en temps réel gère la conversation en cours. Il reçoit le flux audio de l’appelant, comprend la demande, fait appel à un outil approuvé si nécessaire, puis renvoie une réponse vocale. Chaque étape supplémentaire entraîne un délai ; ce parcours doit donc être simple à expliquer et se dérouler de manière prévisible.

La boucle hors ligne démarre après l’appel. Elle permet d’examiner les éléments de preuve, de rejouer les défaillances, de comparer les informations avec un système source et de proposer une modification. Personne n’est laissé en attente pendant que ce travail est effectué.

The live workflow handles the caller’s request with bounded steps and tested fallbacks, while the offline workflow evaluates results and improves future calls.Limiter le chemin d'accès dynamique

Un workflow en temps réel efficace ne cherche pas à tout résoudre. Il effectue l'action utile la plus sûre dans les limites du temps dont dispose l'appelant.

Trois stratégies permettent de garantir la prévisibilité de ce parcours :

• Limitez le travail. Ne donnez à l’agent accès qu’aux outils nécessaires à la tâche en cours, et limitez la fréquence à laquelle il peut les appeler. Privilégiez une seule requête bien définie plutôt qu’une chaîne de recherches illimitée. Traitez différemment les lectures et les écritures : les lectures peuvent généralement expirer et passer à une solution de repli, tandis que les écritures doivent confirmer l’intention de l’appelant et éviter les nouvelles tentatives à l’aveugle lorsque l’état final n’est pas clair.

• Fixez des délais stricts. Fixez une limite de temps pour chaque appel d'outil et pour l'ensemble du tour de conversation. N'autorisez que les tentatives de reprise prédéfinies en cas d'échecs temporaires, et consignez séparément la transcription, le modèle, l'outil et la durée de la parole afin de pouvoir identifier le véritable goulot d'étranglement.

• Préparez la solution de secours avant le lancement. Si une dépendance est lente ou échoue, utilisez une réponse testée qui dit la vérité et indique à l'appelant la marche à suivre, plutôt que de demander au modèle d'improviser. Par exemple : « Je ne peux pas récupérer cette mise à jour pour le moment. Je peux vous mettre en relation avec le service d'assistance ou vous envoyer un message de suivi. »

Ces règles varient en fonction de la tâche. La consultation du statut d'une commande est une opération de lecture ; l'agent peut donc effectuer une seule consultation et se rabattre sur une solution de secours en cas de délai d'expiration. La modification d'un rendez-vous est une opération d'écriture ; l'agent doit donc confirmer la demande et éviter de déclarer l'opération réussie si l'état final n'est pas clair. Il peut être préférable de traiter un litige de facturation en recueillant les informations pertinentes et en transmettant le dossier à un interlocuteur humain.

L'objectif n'est pas d'atteindre une autonomie maximale. Il s'agit de choisir l'action utile la plus sûre que le système puisse mener à bien dans les délais impartis par l'appelant.

Intégrer les données d'appel dans des boucles hors ligne

Une fois l'appel terminé, les contraintes strictes en matière de latence s'assouplissent. Une boucle hors ligne peut examiner les éléments sans faire attendre l'appelant, mais elle doit aboutir à des conclusions exploitables plutôt que de se contenter de résumer l'appel.

Vonage propose aux développeurs plusieurs moyens de recueillir ces preuves. Une connexion WebSocket permet de transmettre le son en temps réel entre la Voice API et l’agent. Le webhook de réponse renvoie le NCCO qui contrôle l’appel, tandis que le webhook d’événement reçoit les mises à jour d’état et de cycle de vie. Lorsque l’enregistrement est approprié, le NCCO action d’enregistrement peut capturer le son et envoyer les métadonnées d’enregistrement vers une URL d’événement.

Ces données peuvent alimenter plusieurs boucles utiles :

• Boucle de régression. Réexécutez les échecs identifiés lors de la prochaine mise à jour de l'invite, du modèle, des connaissances ou du routage. Cette boucle doit aboutir à un résultat clair (réussite ou échec) et bloquer les régressions avant la mise en production de modifications ayant un impact plus important.

• Cycle de mise à jour. Comparez les réponses ou les entrées de connaissances avec leur source de référence. Si les informations ont évolué, préparez une proposition de mise à jour à valider plutôt que de modifier automatiquement l'environnement de production.

• Boucle de transfert. Passez en revue les transferts et les appels échoués afin d’identifier les questions d’accueil manquantes, les champs obligatoires, les changements d’acheminement ou les tâches qui devraient toujours être confiées à une personne. Le résultat doit être une proposition concrète pour la prochaine version du système.

Les enregistrements d'appels peuvent permettre d'améliorer le système, mais ils peuvent contenir des informations personnelles ou sensibles. Ne conservez que les données nécessaires au processus de vérification, masquez les données sensibles, définissez une durée de conservation, limitez l'accès et réutilisez la transcription en temps réel de la parole en texte transcription lorsque cela est approprié.

Déterminez à quelle catégorie appartient le travail

Use a live workflow when the caller is waiting, an agent loop when the work can wait and be verified, and human review when success cannot be checked reliably.Si l'appelant est en attente, utilisez un workflow délimité. Limitez les appels à l'outil, définissez le délai d'expiration et programmez la solution de secours avant le lancement.

Si le travail peut attendre et que le résultat peut être vérifié, utilisez une boucle. Conservez les traces, vérifiez le résultat de manière indépendante et exigez une validation avant la mise en production des modifications ayant un impact important.

Si personne n'est en mesure de définir ce qu'est la réussite, ne transformez pas cette tâche en boucle autonome. Maintenez un processus de travail fixe ou désignez une personne responsable.

La question essentielle n'est pas de savoir si une tâche peut être automatisée, mais si le système est capable de déterminer quand cette tâche a été correctement effectuée.

Conclusion : une règle à retenir

Ne mettez pas la latence en boucle.

Faites en sorte que le processus orienté vers l'appelant se déroule rapidement. Utilisez les informations issues de cet appel pour alimenter un cycle plus lent permettant d'évaluer, de Verify et d'améliorer les comportements futurs.

Cette séparation vous offre un double avantage : une expérience fluide pour l'appelant et un système qui gagne en fiabilité au fil du temps.

À propos de Vince DiPaola

Vince DiPaola dirige teamvince, un studio spécialisé dans l'intégration de l'IA et le développement de produits, situé à Brooklyn. Il développe des systèmes d'agents pratiques et enseigne aux équipes comment transformer les tâches répétitives en flux de travail basés sur l'IA auxquels elles peuvent se fier.