Heartbeat Thinking : les agents vocaux travaillent pendant que vous parlez encore, latence −36,4%

Les agents vocaux dotés d'outils se comportent presque tous de la même façon : l'utilisateur finit sa phrase, et ce n'est qu'ensuite que la pause commence. Le modèle assemble les arguments, appelle l'API, attend la réponse et formule sa réplique. Heartbeat Thinking, un nouveau travail publié sur Hugging Face Daily Papers, cherche à récupérer ce temps perdu. Sur le benchmark FDBench v3, l'approche augmente la couverture des outils de 16 points de pourcentage et réduit de 36,4% la latence moyenne de la réponse finale, par rapport à une base de référence de type SHANKS.

Pourquoi le lancement spéculatif plante en pleine phrase

L'idée de commencer le travail avant la fin de la réplique n'est pas nouvelle. Si les premiers mots montrent déjà qu'il faut chercher un vol ou vérifier une commande, l'agent peut démarrer à l'avance. Le problème tient à la conception de ces systèmes. En général, la parole est découpée en fenêtres ou en chunks, et la génération est interrompue à chaque mise à jour de la transcription. Résultat : un appel d'outil peut être coupé alors que ses arguments ne sont pas encore réunis. Le temps de calcul se retrouve calé sur le rythme de la reconnaissance vocale, et le travail utile effectué en amont est moindre qu'il pourrait l'être.

Prenons la requête : « Trouve-moi un vol pour Istanbul vendredi… et vérifie au passage si j'ai besoin d'un visa ». La ville et la date sont énoncées dans la première moitié de la phrase. Une fenêtre qui redémarre à chaque nouveau mot risque d'abandonner un appel déjà lancé, alors que l'information nécessaire était disponible.

Comment fonctionne le « battement de cœur »

Les auteurs changent la logique de traitement des mises à jour. Un nouveau fragment de parole n'annule plus le travail en cours : il déclenche un appel Thinker distinct. Les appels déjà en cours et les outils déjà envoyés vont tranquillement jusqu'au bout. Thinker démarre périodiquement, comme un pouls, d'où le nom du schéma. Chaque lancement lit deux sources : la transcription partielle la plus récente et un registre commun des raisonnements terminés et des résultats d'outils.

Ce registre commun remplit deux fonctions. D'abord, il permet de reconstituer les arguments manquants : si l'on a déjà établi que l'utilisateur parle d'un vol précis, l'appel suivant ne repart pas de zéro. Ensuite, il permet de lancer des appels dépendants, c'est-à-dire ceux qui ont besoin du résultat d'un outil précédent. La préparation avance d'une mise à jour de la parole à l'autre et n'est pas réinitialisée à chaque fois.

Ce que montrent les tests

Le système a été comparé à des fenêtres de type SHANKS sur trois jeux de données : SpeechFCEval, FDBench v3 et AudioCRAG. Les métriques diffèrent. Pour les tâches d'appel de fonctions, les auteurs mesurent la couverture spéculative des outils. Pour AudioCRAG, où la recherche compte, ils mesurent la réutilisation des éléments trouvés.

• La méthode augmente la couverture agrégée des outils ou la réutilisation du retrieval par rapport à la base de référence à fenêtres.
• FDBench v3 : couverture des outils +16 points de pourcentage.
• FDBench v3 : latence moyenne de la réponse finale −36,4%.
• L'effet sur la qualité finale de la tâche dépend du benchmark : le gain n'est pas identique partout.

Le dernier point est important. Les auteurs ne prétendent pas que le schéma améliore toujours les réponses. Le principal gain porte sur la vitesse et sur la part du travail accomplie avant la fin de la réplique. La qualité n'en souffre globalement pas, même si l'ampleur de l'effet varie selon les jeux de données.

Que changer en production pour les agents vocaux

Pour les équipes qui développent des assistants vocaux pour des centres d'appels, des voitures ou des enceintes connectées, la conclusion est pratique. La latence après la fin de la phrase résulte le plus souvent d'étapes séquentielles, et une part importante peut être déplacée au moment où la personne parle encore. Cela suppose trois éléments : une lecture continue de la transcription partielle, une mémoire commune des résultats intermédiaires et l'interdiction d'annuler les appels déjà lancés sans raison sérieuse.

Il y a aussi un coût. Les lancements spéculatifs consomment plus de tokens et sollicitent davantage d'outils, et une partie de ce travail sera inutile si l'utilisateur change d'avis au milieu de sa phrase. Pour les outils à effets de bord, comme un paiement ou l'envoi d'un message, il faudra restreindre ce schéma aux seuls appels sûrs, en lecture. En revanche, si l'agent cherche surtout des données et recoupe des faits, l'écoute cesse d'être un temps mort et devient une préparation de la réponse.