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 stack d’outils.
Voice 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 aux bons outils au bon moment pour atteindre le bon contexte d’entreprise – ou pour réaliser la bonne action.
La stack d’outils de Glean était déjà éprouvée dans le chat en entreprise, mais la voix a révélé un nouveau niveau d’exigence pour lequel nous n’avions pas entièrement conçu. Les modèles vocaux sont souvent plus petits, leurs fenêtres de contexte sont plus réduites, ils doivent répondre dans un budget de latence strict, et les mauvaises actions sont plus difficiles à corriger. Un mauvais appel d’outil dans un chat texte peut être discrètement corrigé au tour suivant sans que l’utilisateur ne s’en aperçoive. En voix, le modèle est déjà en train de parler — l’utilisateur entend l’écart en temps réel. Il y a moins de marge pour se réajuster sans que l’expérience vocale ne paraisse défaillante.
Cela change où va le travail d’ingénierie. Les plus grands gains sont venus d’une stack 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 la réaliser. Pour chaque demande, 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 donner au modèle une liste énorme d’outils et de lui demander de choisir.
La qualité du retrieval compte plus tôt qu’on ne le pense
Une action complexe comme « planifier une réunion » ressemble à un seul appel d’outil, mais en pratique, cela implique de déterminer qui doit participer, 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 durs tout en outrepassant les conflits souples, é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 reconstituer toute cette logique du monde réel autour d’un outil minimaliste 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 fait alors en deux étapes : d’abord récupérer la bonne compétence depuis un catalogue, puis suivre ses instructions et invoquer ses outils constitutifs.
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 plus limitée et moins d’occasions de se remettre d’erreurs de retrieval. Un modèle vocal à qui l’on présente moins de compétences, plus propres et mieux classées, peut donc surpasser un modèle à plus forte capacité de raisonnement travaillant à partir d’un ensemble plus bruité. C’était l’un des résultats non évidents lorsque nous avons créé Voice. Une grande partie du levier venait de la découverte dynamique des compétences et des outils, en particulier l’entonnoir filtrer-classer-élaguer 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 était que les embeddings denses ne suffisent pas lorsqu’il y a 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 Jira. Une simple pondération lexicale 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 inline
Le chat texte peut absorber plus 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, 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 lacunes, 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 minimiser la surcharge de contexte.
Nous constatons également que les modèles vocaux ont besoin de plus 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 structurés de nouvelle tentative. Si le système indique exactement quel champ est erroné et quel type il attendait, le modèle peut souvent réparer l’appel. S’il reçoit seulement « ça n’a pas marché », le tour est généralement perdu.
La voix tend à se concentrer sur le travail orienté action
Une façon utile de voir la voix est que le travail y est souvent plus orienté action que dans le chat texte. Les gens utilisent la voix pour envoyer des messages, créer des événements ou déposer des tickets pendant qu’ils sont en mouvement, et ce sont des actions 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 contourner. Cela signifie que la stack a besoin de nouvelles tentatives précises, d’un état d’auth explicite et d’une sémantique d’exécution déterministe.
La fiabilité des outils vocaux s’est améliorée lorsque nous avons réduit ces choix à un chemin canonique unique : 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 exposé explicitement. Le modèle pouvait être empêché de prétendre à une réussite avant que le système en aval ne la confirme. Les nouvelles tentatives pouvaient être pilotées par l’état d’exécution plutôt que 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 des problèmes dans les outils et l’infrastructure sous-jacents, moins visibles dans le chat. Un certain nombre d’échecs qui sont d’abord apparus comme des « bugs voix » étaient en réalité des problèmes de retrieval, d’initialisation ou de chemin d’exécution, que le chat pouvait souvent absorber grâce à des nouvelles tentatives, une délibération plus longue ou une UI plus tolérante. La voix a simplement rendu 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 été si importants. Dans les systèmes en temps réel, la rigueur d’infrastructure se traduit directement en qualité produit, et cela a également aidé à améliorer la qualité et la latence des appels d’outils en chat texte.
Le constat plus général
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 retrieval compacte et fiable, un ranker qui comprend la provenance aussi bien 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 rend simplement impossible de l’ignorer.
