La principale leçon tirée de la construction de Glean Voice est que le goulot d’étranglement n’est généralement pas le modèle. C’est la pile d’outils.
La voix répond aux questions à partir des connaissances de votre entreprise, à voix haute et en temps réel. Cela signifie que chaque réponse dépend de l’appel au bon outil, au bon moment, pour accéder au bon contexte entreprise — ou pour déclencher la bonne action.
La pile d’outils de Glean était déjà éprouvée dans le chat en entreprise, mais la voix a fait apparaître un nouveau niveau d’exigence auquel nous n’avions pas entièrement conçu. Les modèles vocaux sont souvent plus petits, leurs fenêtres de contexte sont plus étroites, ils doivent répondre dans un budget de latence strict, et les mauvaises actions sont plus difficiles à annuler. Un mauvais appel d’outil dans un chat texte peut être discrètement corrigé au tour suivant sans que l’utilisateur s’en aperçoive. En voix, le modèle est déjà en train de parler — l’utilisateur perçoit l’écart en temps réel. Il y a moins de marge pour corriger sans que l’expérience vocale paraisse cassée.
Cela change là 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 : meilleur filtrage, meilleur classement, davantage de détails sur les outils exposés dès le départ, et un seul chemin d’exécution canonique. Nous regroupons les outils en compétences, en associant les outils nécessaires à une tâche avec des instructions détaillées pour l’exécuter. Pour chaque requête, nous effectuons une recherche et un classement en direct dans le catalogue afin de récupérer la meilleure compétence pour la tâche et l’utilisateur, plutôt que de donner au modèle une énorme liste d’outils et de lui demander de choisir.
La qualité de la récupération compte plus tôt qu’on ne le pense
Une action complexe comme « planifier une réunion » ressemble à un simple appel d’outil, mais en pratique, elle implique d’identifier les participants, de résoudre l’identité de chaque personne, de réconcilier les calendriers entre fuseaux horaires, de trouver un créneau qui évite les conflits bloquants tout en outrepassant les conflits souples, éventuellement de réserver une salle, puis seulement 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 outil brut est exigeant et peu fiable. À la place, nous encapsulons 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 à partir d’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 déterminante pour la qualité, car les modèles vocaux disposent souvent d’une capacité de raisonnement moindre et de moins d’occasions de se remettre d’erreurs de récupération. Un modèle vocal exposé à moins de compétences, plus propres et mieux classées, peut donc surpasser un modèle au raisonnement plus puissant qui travaille à partir d’un ensemble plus bruité. C’était l’un des résultats non évidents lorsque nous avons construit Voice. Une grande partie du levier est venue de la découverte dynamique des compétences et des outils, en particulier du funnel filtrage-classement-restriction en amont de l’exécution : d’abord pour les compétences éligibles, puis pour les outils à l’intérieur de la compétence sélectionnée.
L’autre enseignement est que les embeddings denses ne suffisent pas lorsqu’il existe une courte liste d’outils répétitifs. Beaucoup d’entrées partagent les mêmes verbes : envoyer, créer, mettre à jour. Le signal utile est souvent le jeton rare qui permet de distinguer Slack de Gmail ou de Jira. Une pondération lexicale simple a davantage aidé que prévu, car elle préservait ces distinctions au lieu de les diluer.
La voix a besoin du contrat d’outil en ligne
Le chat texte peut absorber davantage d’intermédiation. Un modèle de chat peut suivre des liens, inspecter les schémas plus tard ou se remettre d’une erreur de validation vague. La voix, généralement, ne le peut pas.
Pour la voix, une plus grande partie du contrat d’outil doit être présente dès le départ : noms canoniques, identité du serveur, noms des arguments et suffisamment de détails de schéma pour effectuer un premier appel correct. Sinon, le modèle comble les blancs, et ces suppositions sont souvent suffisamment plausibles pour être dangereuses. Cette approche diffère de celle que nous adoptons avec les modèles texte, où nous utilisons une divulgation progressive des outils afin de réduire au minimum la surcharge de contexte.
Nous constatons aussi que les modèles vocaux ont besoin de davantage de contexte autour des erreurs. Dans le chat, un échec de validation générique peut encore être récupérable. En voix, les erreurs de validation doivent fonctionner comme des signaux de relance structurés. Si le système indique exactement quel champ est incorrect et quel type il attendait, le modèle peut souvent corriger l’appel. S’il reçoit seulement « cela n’a pas fonctionné », le tour est généralement perdu.
La voix concentre souvent le travail orienté action
Une manière utile de penser la voix est que le travail tend souvent à être plus orienté action que dans le chat texte. Les gens utilisent la voix pour envoyer des messages, créer des événements ou ouvrir des tickets lorsqu’ils sont en déplacement, et ces actions sont moins faciles à corriger que, par exemple, des résultats de recherche. Ces actions ne sont pas propres à la voix, mais la voix laisse moins de marge pour les encadrer. Cela signifie que la pile doit prévoir des relances exactes, un état d’authentification explicite et une sémantique d’exécution déterministe.
La fiabilité des outils vocaux s’est améliorée lorsque nous avons regroupé ces choix dans un chemin canonique unique : trouver la compétence, résoudre l’outil autorisé, valider l’appel, exécuter, puis confirmer le résultat. Le système est ainsi devenu plus prévisible. L’état d’autorisation pouvait être exposé explicitement. Le modèle pouvait être empêché de revendiquer le succès avant que le système en aval ne le confirme. Les relances pouvaient être pilotées par l’état d’exécution plutôt que bricolées en langage naturel.
La voix révèle des problèmes qui existaient déjà
Un effet secondaire utile de la voix est qu’elle met en évidence des problèmes des outils et de l’infrastructure sous-jacents, moins visibles dans le chat. Un certain nombre d’échecs qui ont d’abord été perçus comme des « bugs de voix » étaient en réalité des problèmes de récupération, d’initialisation ou de chemin d’exécution que le chat pouvait souvent absorber grâce aux relances, à 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 retirer la configuration du chemin de requête ont autant compté. Dans les systèmes temps réel, la rigueur de l’infrastructure se traduit directement par la qualité du produit, et cela a aussi aidé à améliorer la qualité et la latence des appels d’outils dans le chat texte.
La leçon 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 fiable, un ranker qui comprend aussi bien la provenance que la pertinence, suffisamment de détails de schéma exposés tôt pour éviter les suppositions, 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 rend simplement impossible de l’ignorer.
