GPT-Live révolutionne l'IA vocale avec une réactivité sans précédent

Un défi complexe pour l'IA vocale

Dans le domaine de l'intelligence artificielle vocale, déterminer le moment idéal pour intervenir dans une conversation est une tâche plus complexe qu'il n'y paraît. Les humains passent naturellement la parole en une fraction de seconde, mais les systèmes d'IA vocale traditionnels ont longtemps peiné à suivre ce rythme. Ces systèmes reposaient sur des architectures basées sur des tours, utilisant de petits modèles appelés détecteurs de tour pour décider du moment opportun pour répondre. Une décision prématurée pouvait interrompre l'utilisateur, tandis qu'une réponse tardive donnait une impression de lenteur. Ce n'est qu'après que le détecteur de tour ait pris sa décision que le modèle de langage (LLM) plus volumineux pouvait commencer son traitement.

GPT-Live, notre système vocal de troisième génération, a été conçu pour surmonter ces limitations. En supprimant le détecteur de tour, le modèle vocal devient duplex intégral, capable d'écouter et de parler simultanément. Cela élimine le besoin d'un détecteur séparé, rendant les conversations plus immédiates et naturelles. Pour des tâches nécessitant un raisonnement plus approfondi ou l'utilisation d'outils, GPT-Live peut également consulter des modèles avancés comme GPT-5.5, sans interrompre le flux de la conversation. Cette combinaison offre à GPT-Live une réactivité et une intelligence conversationnelle inégalées.

Une architecture optimisée pour la latence

Pour offrir cette expérience à grande échelle, une nouvelle architecture système a été développée, optimisée pour une latence faible. Contrairement à l'inférence traditionnelle de type demande-réponse, notre système diffuse l'audio entrant vers le modèle vocal et l'audio sortant vers l'utilisateur, tout en gérant la délégation sur un chemin asynchrone distinct. Au cours des six derniers mois, nous avons retravaillé l'inférence de modèle, la gestion du contexte et le transport multimédia pour maintenir un flux de parole fluide de bout en bout.

Cette architecture crée également une distinction claire entre le chemin vocal central et la logique d'application, facilitant ainsi la personnalisation du comportement de l'application sans affecter la réactivité. Cette base alimente une gamme croissante de capacités dans ChatGPT Voice, y compris la nouvelle fonctionnalité permettant de contrôler votre ordinateur et de coordonner vos agents dans l'application de bureau ChatGPT.

De la prise de tour au streaming continu

Les architectures vocales antérieures étaient héritées des LLM textuels, chaque tour étant représenté par un blob audio discret plutôt que du texte. Dans ces systèmes en cascade, la conversion de la parole en texte, le LLM et la conversion de texte en parole fonctionnaient en série, ajoutant de la latence et ignorant des indices tels que le ton et le rythme.

Les modèles de parole à parole ont amélioré cette approche en traitant directement l'audio. En formant le modèle à comprendre et générer nativement la parole, il a été possible de préserver des détails perdus lors de la transcription et de répondre plus rapidement. Cependant, le système dépendait toujours du détecteur de tour pour décider quand l'inférence pouvait commencer. Bien que le modèle gère plus d'interactions, celles-ci restaient basées sur des tours.

GPT-Live place le modèle vocal au cœur de la conversation : l'audio entre et sort du modèle, tandis que le raisonnement plus profond et l'utilisation d'outils se produisent de manière asynchrone. Le principal défi du système est de maintenir une boucle multimédia ininterrompue. D'autres tâches, telles que l'invocation de modèles avancés et la persistance de la conversation, se déroulent en dehors du chemin en direct.

Assurer une inférence continue

Maintenir cette boucle multimédia ininterrompue n'est pas toujours simple. Tout retard dans le transport, le traitement ou l'inférence peut se traduire par une pause ou un artefact audible. Un système basé sur des tours pouvait tolérer certaines variations dans le moment où un blob audio arrivait. Cependant, un système multimédia en direct doit livrer chaque trame audio à l'heure.

Les travaux antérieurs sur ChatGPT Voice et l'API en temps réel ont fourni une base importante. Nous avions déjà reconstruit notre infrastructure vocale pour diffuser de l'audio et de la vidéo directement dans et hors de nos systèmes avec une latence plus faible et plus prévisible. GPT-Live a poussé ce design plus loin, diffusant les médias jusqu'au modèle via un nouveau système d'inférence étatful conçu pour une conversation continue.

L'inférence en streaming n'était qu'une partie de la solution. Pour bien fonctionner en production, nous devions également garantir une livraison audio fiable du client à la pile d'inférence et faire face aux défis de l'étatful.

Accélérer le flux multimédia

Une décision précoce que nous avons prise était de séparer spécifiquement le flux multimédia de la logique d'application et commerciale. L'audio circule entre le client et le modèle vocal sur un chemin rapide dédié. La délégation, l'utilisation d'outils et d'autres travaux d'application se déroulent derrière une frontière RPC asynchrone. Un appel d'outil lent ou un service backend peut retarder son propre résultat, mais ne peut pas bloquer le flux multimédia.

Cette séparation donne également au système une frontière claire pour la personnalisation. Les applications peuvent changer leurs outils, politiques et comportements backend sans affecter le frontend multimédia responsable du maintien du mouvement audio. Le chemin en direct reste petit, prévisible et concentré sur le travail qui doit se faire en temps réel.

Nous avons écrit le frontend multimédia et la logique d'inférence en Go, remplaçant une précédente implémentation en Python asyncio. Cela a considérablement amélioré la fluidité de la livraison des trames, le nouveau système ayant un p95 correspondant au p50 de l'ancien système.

WebRTC fournit la base de transport. Il est conçu pour les médias à faible latence et peut continuer à fonctionner en cas de perte de paquets, de dérive d'horloge et de changements de connexion client. Si des paquets arrivent en retard, WebRTC peut subtilement étirer l'audio pour éviter les lacunes, puis accélérer brièvement la lecture pour rattraper le temps réel.

En minimisant le buffering et le blocking dans tout le système, nous pouvons offrir la réactivité inférieure à une seconde que les humains attendent d'une conversation.

Maintenir la conversation (étatful)

L'inférence étatful a ses propres compromis opérationnels. Une session vocale peut rester active longtemps, mais son contexte croît continuellement, et les instances de modèle se mettent en marche et s'arrêtent en fonction de la demande.

Pour répondre à ces préoccupations, nous avons construit un mécanisme de transfert sans couture entre les instances de modèle. Lorsqu'une transition est nécessaire, nous pouvons préchauffer une instance de modèle de remplacement aux côtés de l'existante, la pré-remplir avec le contexte de session actuel, exécuter l'inférence sur les deux en parallèle, et basculer lorsque la nouvelle instance est entièrement prête.

Le même mécanisme de base prend également en charge la compaction dynamique du contexte. Au fur et à mesure qu'une conversation avance, son contexte accumulé peut finalement dépasser la limite de contexte du modèle. La compaction peut réduire la taille du contexte pour qu'elle soit dans la limite, mais l'opération prend du temps. Et parce qu'elle modifie le contexte passé, elle invalide également le cache de clés-valeurs (KV) du modèle, qui stocke les clés d'attention et les valeurs des tokens précédemment traités. Reconstruire cet état nécessite un nouveau pré-remplissage, introduisant un délai supplémentaire.

Au lieu de cela, nous traitons la compaction comme une autre transition gérée. Pendant que l'instance de modèle d'origine continue de discuter, le système compacte le contexte et prépare une instance de modèle de remplacement avec le nouveau contexte. Une fois que cette instance est prête, nous pouvons basculer sans interruption multimédia. Cela permet au système de prendre en charge des appels de longue durée, en compactant chaque fois que nécessaire.

Le travail lourd reste en dehors du chemin en direct, donc même pendant un transfert, la conversation ne manque jamais un battement.

Délégation sans bloquer la conversation

La capacité de GPT-Live à invoquer des modèles avancés existants lui confère beaucoup de puissance, déconnectant effectivement le « parler » d'un « penser » plus profond. Mais faire en sorte que cette architecture à deux modèles se ressente comme un seul système nécessitait de résoudre deux problèmes d'ingénierie connexes.

Tout d'abord, les résultats doivent revenir suffisamment rapidement pour être utiles dans l'échange en cours, donc nous devions minimiser la latence sur tout le chemin de délégation, du routage et du traitement des prompts à l'inférence et aux appels d'outils. En même temps, les systèmes ailleurs dans le produit ont toujours besoin de messages discrets, donc nous devions représenter la conversation en cours sous une forme qu'ils pouvaient comprendre.

Rendre la délégation suffisamment rapide pour sembler naturelle

Lorsqu'une délégation est envoyée, nous optimisons le temps jusqu'à ce que le modèle avancé produise quelque chose d'utile pour la conversation. Le modèle vocal peut brièvement maintenir l'échange en mouvement pendant qu'un modèle avancé raisonne ou utilise des outils, mais il ne peut pas masquer une réponse arbitrairement lente. Nous avons donc traité l'ensemble de la boucle de délégation — routage, traitement des prompts, inférence et appels d'outils — comme faisant partie du budget de réactivité.

La première optimisation consiste à configurer le modèle avancé et tous les outils dont il a besoin avant que la délégation ne soit demandée. Lorsque la session vocale commence, le serveur d'application crée une session d'inférence pour le modèle avancé et la pré-remplit avec le contexte de conversation initial, garantissant que le prompt a été entièrement traité avant la première demande déléguée.

Nous maintenons ensuite cette session d'inférence disponible pendant la durée de la conversation vocale et utilisons une affinité de session stable pour les demandes successives. Associées à la mise en cache des prompts, ces techniques améliorent la latence tout en permettant une récupération facile en cas de défaillance d'un travailleur.

L'effort de raisonnement, les limites de sortie, les schémas d'outils et les allers-retours modèle-outil affectent également le moment où la conversation reçoit un résultat utile, et nous avons ajusté ces leviers pour obtenir des réponses plus rapides. En minimisant le travail nécessaire sur le chemin de délégation, nous avons permis au modèle vocal d'incorporer rapidement les résultats de nos modèles avancés.

Dériver des tours discrets à partir de la parole continue

Bien que le modèle vocal fonctionne sur des flux continus de parole, de nombreux systèmes qui l'entourent fonctionnent encore sur des tours d'utilisateur et d'assistant, y compris l'interface de conversation de ChatGPT et certaines parties de notre infrastructure d'analyse et de sécurité. Ainsi, le serveur d'application sépare la conversation qui se chevauche, parfois ambiguë, en messages discrets.

À mesure que l'audio arrive, le serveur utilise des transcriptions partielles et des signaux de synchronisation pour déduire quel locuteur a la parole et construire une file d'attente de messages.