La principale leçon tirée de la création de Glean Voice, c'est que le goulot d'étranglement n'est généralement pas le modèle. C'est la pile d'outils.
Voice répond à des questions issues des connaissances de votre entreprise, à voix haute et en temps réel. Cela signifie que chaque réponse dépend de la capacité à appeler les bons outils au bon moment pour accéder au bon contexte d'entreprise – ou pour effectuer la bonne action.
La pile d'outils de Glean avait déjà fait ses preuves dans le chat d'entreprise, mais la voix a révélé un nouveau niveau d'exigence que nous n'avions pas totalement anticipé. Les modèles vocaux sont souvent plus petits, leurs fenêtres de contexte plus limitées, ils doivent répondre dans un budget de latence strict, et les mauvaises actions sont plus difficiles à rattraper. Un mauvais appel d'outil dans un chat textuel peut être discrètement corrigé au tour suivant sans que l'utilisateur ne s'en aperçoive. En vocal, le modèle est déjà en train de parler — l'utilisateur entend le blanc en temps réel. Il y a moins de marge pour se corriger sans que l'expérience vocale ne paraisse défaillante.
Cela change l'endroit où se concentre le travail d'ingénierie. Les gains les plus importants sont venus d'une pile d'outils plus propre et plus stricte : un meilleur filtrage, un meilleur classement, davantage de détails sur les outils présentés en amont et un unique chemin d'exécution canonique. Nous intégrons les outils dans des compétences, associant les outils nécessaires à une tâche à des instructions détaillées pour l'accomplir. Pour chaque requête, nous effectuons une recherche et un classement en direct sur le catalogue afin de récupérer la meilleure compétence pour la tâche et l'utilisateur, plutôt que de présenter au modèle une immense liste d'outils en lui demandant de choisir.
La qualité de la récupération compte plus tôt qu'on ne le pense
Une action complexe comme « organiser une réunion » semble correspondre à un seul appel d'outil, mais en pratique, elle implique de déterminer qui doit y assister, de résoudre l'identité de chaque personne, de concilier les calendriers à travers les fuseaux horaires, de trouver un créneau qui évite les conflits incontournables tout en passant outre ceux qui sont négociables, éventuellement de réserver une salle, et seulement ensuite de créer l'événement dans le format propre à chaque fournisseur.
Demander au modèle de reconstruire toute cette logique du monde réel autour d'un simple outil est exigeant et peu fiable. À la place, nous intégrons un ou plusieurs outils et leurs instructions détaillées dans une compétence. L'exécution se déroule alors en deux étapes : d'abord récupérer la bonne compétence dans un catalogue, puis suivre ses instructions et invoquer les outils qui la composent.
Pour la voix en particulier, la qualité des compétences et des outils récupérés est primordiale pour la qualité, car les modèles vocaux ont souvent une capacité de raisonnement moindre et moins d'occasions de se remettre des erreurs de récupération. Un modèle vocal auquel on présente des compétences moins nombreuses, plus propres et mieux classées peut ainsi surpasser un modèle au raisonnement plus poussé travaillant à partir d'un ensemble plus bruité. C'est l'un des résultats non évidents que nous avons constatés en construisant Voice. Une grande partie de l'effet de levier provenait de la découverte dynamique des compétences et des outils, en particulier de l'entonnoir filtrer-classer-réduire en amont de l'exécution : d'abord pour les compétences éligibles, puis pour les outils au sein de la compétence sélectionnée.
L'autre leçon, c'est que les embeddings denses ne suffisent pas lorsqu'il existe une courte liste d'outils répétitifs. De nombreuses entrées partagent les mêmes verbes : envoyer, créer, mettre à jour. Le signal utile est souvent le token rare qui permet de distinguer Slack de Gmail ou de Jira. Une simple pondération lexicale a aidé plus que prévu, car elle préservait ces distinctions au lieu de les estomper.
La voix a besoin du contrat d'outil en ligne
Le chat textuel peut absorber davantage d'indirection. Un modèle de chat peut suivre des liens, inspecter des schémas plus tard, ou se remettre d'une erreur de validation vague. La voix, elle, ne le peut généralement pas.
Pour la voix, une plus grande partie du contrat d'outil doit être présente en amont : noms canoniques, identité du serveur, noms d'arguments et suffisamment de détails de schéma pour effectuer un premier appel correct. Sinon, le modèle comble les lacunes, et ces suppositions sont souvent suffisamment plausibles pour être dangereuses. Cette approche diffère de celle que nous adoptons avec les modèles textuels, où nous recourons à une divulgation progressive des outils afin de minimiser la surcharge de contexte.
Nous constatons également que les modèles vocaux ont besoin de plus de contexte autour des erreurs. Dans un chat, un échec de validation générique peut tout de même être rattrapable. En vocal, les erreurs de validation doivent fonctionner comme des signaux de nouvelle tentative structurés. Si le système indique précisément quel champ est incorrect et quel type il attendait, le modèle peut souvent réparer l'appel. S'il reçoit simplement « ça n'a pas fonctionné », le tour est généralement perdu.
La voix tend à privilégier les tâches orientées action
Une façon utile d'envisager la voix est que le travail penche souvent davantage vers l'action que dans un chat textuel. Les gens utilisent la voix pour envoyer des messages, créer des événements ou ouvrir des tickets alors qu'ils sont en déplacement, et ces actions sont moins corrigeables que, disons, des résultats de recherche. Ces actions ne sont pas propres à la voix, mais la voix laisse moins de marge pour les tempérer. Cela signifie que la pile a besoin de nouvelles tentatives exactes, d'un état d'authentification explicite et d'une sémantique d'exécution déterministe.
La fiabilité des outils vocaux s'est améliorée lorsque nous avons ramené ces choix à un unique chemin canonique : trouver la compétence, résoudre l'outil autorisé, valider l'appel, exécuter et confirmer le résultat. Cela a rendu le système plus prévisible. L'état d'autorisation pouvait être rendu explicite. On pouvait empêcher le modèle de déclarer un succès avant que le système en aval ne l'ait confirmé. Les nouvelles tentatives pouvaient être pilotées par l'état d'exécution plutôt qu'improvisées dans le langage.
La voix révèle des problèmes qui existaient déjà
Un effet secondaire utile de la voix est qu'elle révèle, dans les outils et l'infrastructure sous-jacents, des problèmes moins visibles dans le chat. Un certain nombre de défaillances qui apparaissaient d'abord comme des « bugs vocaux » étaient en réalité des problèmes de récupération, d'initialisation ou de chemin d'exécution que le chat parvenait souvent à absorber via des nouvelles tentatives, une délibération plus longue ou une interface plus indulgente. La voix n'a fait que rendre ces faiblesses visibles.
C'est pourquoi des travaux comme la mise en cache, le pooling et le fait de sortir la configuration du chemin de requête ont autant compté. Dans les systèmes en temps réel, la discipline d'infrastructure se traduit directement par la qualité du produit, et cela a aussi contribué à améliorer la qualité et la latence des appels d'outils dans le chat textuel.
L'enseignement plus large
La voix n'a pas seulement besoin de meilleurs prompts. Elle a besoin d'un contrat plus strict avec les outils.
Cela signifie une couche de récupération compacte et digne de confiance, un composant de classement qui comprend aussi bien la provenance que la pertinence, suffisamment de détails de schéma exposés tôt pour éviter de deviner, et un chemin d'exécution qui traite les actions externes comme des engagements plutôt que comme des suggestions.
Cette leçon n'est pas propre à la voix. La voix la rend simplement impossible à ignorer.
