La recherche vocale du point de vue des algorithmes

La première tâche qu’un assistant vocal va devoir réaliser, c’est de transformer la parole de l’utilisateur en texte, on appelle cela le speech-to-text (pas de surprise ici). Le speech-to-text est une discipline déjà ancienne en informatique. Depuis les années 1990 de nombreux progrès ont été réalisés : de 40% d’erreurs on est rapidement passé à 20% dans les années 2000, et plus récemment l’état de l’art est à 5% (chiffres annoncés par Microsoft), c’est-à-dire à peu près au même niveau que l’homme sur des benchmarks très normés.

Bien évidemment, entre les benchmarks en environnement contrôlé (phrases pré-choisies, micro audio de grande qualité, etc.) et la réalité (micro d’un vieil iphone utilisé sous la pluie dans une rue parisienne), il y a une grande différence et l’homme reste encore largement supérieur à la machine, notamment car l’être humain peut comprendre une phrase sans tout entendre grâce à sa connaissance fine du contexte.

Ceci étant, les performances sont devenues suffisantes pour qu’il soit possible d'exploiter commercialement des assistants vocaux, au prix d’une adaptation par l’être humain dans sa manière de s’exprimer. Un exemple tout bête de cette adaptation : lorsque l’on s’adresse à un assistant, on commence par l’interpeller sinon il ne comprend pas forcément qu’on s’adresse à lui, et on va utiliser une élocution plus claire et lente, et faire des phrases plus courtes et plus “actives” (dans le sens de plus directives).

Bref, sur la partie speech-to-text, on peut dire qu'il s'agit d'un domaine assez bordé avec des algorithmes qui marchent déjà bien, même s'il existe des attaques contre les meilleurs, ceux basés sur le deep-learning (voir l’étonnante référence [2] où les auteurs expliquent qu’en rajoutant un bruit presque inaudible à une phrase prononcée par un humain, ils peuvent faire comprendre une autre phrase à la machine).

Passer de l’oral à l’écrit, le vrai enjeu pour l’opérateur technique

La plus grosse difficulté actuelle pour l’assistant vocal est de faire la correspondance entre une requête parlée (et toutes ses variantes) et une requête textuelle associée. Pourquoi procéder ainsi ? Parce que la quasi totalité des algorithmes sont basés sur la correspondance entre une requête textuelle et un corpus textuel. Il faut bien avoir conscience que la langue parlée et la langue écrite sont deux versions d’une même langue avec des différences qui font qu’on ne peut pas utiliser l’une à la place de l’autre au niveau des routines de base du moteur.

La référence [3] (par des chercheurs de Google), présente des expériences qui ont permis de guider le design du préprocesseur de requête pour leur service de recherche vocale. Ils ont adopté une approche inverse : la transformation de requêtes textuelles en requêtes vocales. Un exemple typique est sur l’heure “10:30 pm” peut se dire de plusieurs manières “dix heures et demi du soir”, “dix heures trente du soir”, ou encore “vingt-deux heures trente”. On voit directement sur cet exemple que la troisième possibilité n’a aucun rapport avec l’écriture textuelle du même besoin informationnel. C’est pour cela qu’il est nécessaire pour un assistant vocal de le calibrer avec des données humaines.

Dans le processus de calibrage, on va donc faire un appel massif à des humains. Typiquement on va leur donner des couples de questions - réponses, et on va leur demander d’écrire des variantes des uns et des autres.

Prenons un exemple, le couple “quel est le nom du chien d’Obélix ?” et la réponse “Idéfix”. On va demander à des humains d’écrire toutes les variantes auxquelles ils peuvent penser. “Comment s’appelle le chien d’Obélix”, “Obélix a un chien, quel est son nom”, “nom du chien d’Obélix”, “dis moi comme s’appelle le chien d’obélix”, “sais tu quel est le nom du chien d’Obélix” seront des questions possibles. Pour les réponses on aura du “Obélix a un chien qui s’appelle Idéfix”, “son nom est Idéfix”, “le chien d’Obélix s’appelle Idéfix”, etc. Toutes ces variantes seront interchangeables, et permettent de créer une base de reconnaissance fiable donnant de bons résultats. Bien sûr, on voit toute de suite que l’approche est besogneuse, et elle ne peut être efficace que sur les questions qui sont très fréquentes, et dont les réponses sont très claires : les requêtes purement informationnelles.

Pour automatiser ensuite les choses, on va pouvoir utiliser ce que le moteur sait déjà faire : renvoyer des sites pertinents pour des requêtes. Imaginons que deux requêtes renvoient au niveau du moteur les mêmes SERP, alors il est quasiment certain que les deux requêtes expriment le même besoin informationnel. On va donc regrouper les requêtes selon les positionnements générés, et il suffira alors à un humain de donner une réponse canonique qui servira pour toutes ces requêtes d’un seul coup.

Détecter l’intention, un moyen de renvoyer rapidement vers un type de réponse

Il existe une infinité possible de requêtes vocales, mais seulement un petit nombre de types de requêtes : recherche d’information, volonté navigationnelle, intention commerciale, etc.

Pour certaines requêtes, il est facile de répondre avec des patrons de réponses et des bases de connaissances comme le Knowledge Graph (ou de la data de type schema.org ou encore “position zéro”), il s’agit notamment des requêtes informationnelles.

Il s’agit des principales requêtes qui sont faites à un assistant vocal. On retrouve des questions du type “qu’est- ce qui passe à la télé ce soir”, “quel temps fera-t-il aujourd’hui” ou encore “est-ce que la pizza roberto est ouverte ce soir’. L’avantage de ces questions est qu’elles suivent des patrons formels très stricts et que donc on peut les re-interpréter facilement. Prenons l’exemple de “qu’est- ce qui passe à la télé ce soir” :

1. Première chose, on va utiliser du part-of-speech pour trouver les verbes, les noms, etc.
   Avec cela, on va déterminer que la question contient les contraintes suivantes : passage à la télévision + date du jour + soir dans le jour.
2. On va rechercher le besoin canonique de “passage à la télévision”, qui est sans doute une reformulation déjà proposée par un être humain. On aura donc programme TV + date du jour + soir dans le jour.
3. On instancie les éléments qu’on connait, on obtient : programme TV + 2 février 2018 + 20h30

Avec cette reformulation, le moteur peut facilement fournir l’information répondant à la question, qui devra cependant être oralisée, ce qui n’est pas nécessairement simple.

Pour d’autres types de requête à un assistant, on sort assez vite de ce qu’un moteur sait faire, et on rentre alors dans des scénarios qui sont conçus à l’avance pour répondre à des besoins spécifiques. C’est typiquement ce qui se passe avec Amazon Alexa qui permet aux développeurs de créer des skills en utilisant le Skills Kit. L’idée est judicieuse : si une entreprise ou une personne veut qu’un service soit accessible via Amazon Alexa, il lui suffit de développer le skill qui gère son service. Ainsi Amazon se déleste du coût du développement spécifique concernant le service sur le fournisseur du service. Dans une logique commerciale cela a du sens (les exemples sont souvent de ce type, comme commander un Uber, jouer de la musique sur un service tiers bien choisi, etc.), mais pour un accès à des réponses d’un moteur de recherche, la démarche est plus complexe.

Quel média pour la réponse ? Voice search n’est pas antonyme de résultat visuel

Un autre point très important concernant la recherche vocale est celui de la modalité de restitution. Très clairement c’est l’appareil utilisé qui est structurant pour l’usage et la restitution.

Si on parle d’un assistant (Google Home ou Amazon Alexa par exemple), alors bien évidemment la seule restitution possible est orale et il faut forcément avoir des traitements de l’information complexes (c’est la voie utilisée par Google) ou alors faire travailler les développeurs (la voie choisie par Amazon). En revanche, dans le cadre de l’appareil évident - à savoir le smartphone - la modalité de restitution est plus facile à gérer puisqu’on peut toujours renvoyer l’utilisateur vers un site web via le navigateur intégré.

Pour les entreprises qui créent ces systèmes de recherche vocale, le choix de l’appareil est d’ailleurs extrêmement structurant et l’artifice de l’appareil assistant dédié n’est justement rien de plus qu’un artifice la plupart du temps puisqu’il ne sert qu’à faire micro/enceinte alors que tout se passe sur des serveurs à l’autre bout du monde. De ce point de vue là, la plupart des gens possèdent déjà des appareils connectés qui font cela : smartphones, télévisions, etc. L’appareil spécifique ne sert qu’à focaliser l’attention et à donner une réalité physique au service, ce qui in fine sera totalement inutile une fois le principe accepté par les gens (ce qui est loin d’être acquis pour l’instant).

Et le SEO/webmaster dans tout ça ?

Vous l’aurez peut-être compris, il n’y a actuellement pas beaucoup de rocket science dans la recherche vocale (sauf pour le speech-to-text et text-to-speech, c’est-à-dire l’interface), en revanche, on peut identifier du travail sur les données en elle-même pour les rendre compatibles avec les modalités d’entrée et sortie.

D’un point de vue SEO/webmaster, il y a donc sans doute à gagner en créant des skills chez Amazon pour vendre ses produits, mais aussi à faciliter ce processing en rajoutant dans ses contenus des phrases qui sont bonnes candidates à être des requêtes vocales. Il s’agira typiquement de variations autour des mots-clés visés, avec une longueur généralement substantiellement plus grande.

Un bel artifice serait peut-être de mettre des morceaux de dialogue dans vos contenus, en mode storytelling. L’exemple typique : au lieu de “programme TV” vous écrirez “quoi regarder à la télé ce soir ?”.

Vous pouvez également abuser de pages FAQs qui permettent de mettre explicitement les questions et les réponses. Si en plus vos pages sont structurés avec des markups sémantiques, vous augmenterez vos chances que vos contenus soient retenus pour servir de réponse à un assistant vocal.

Bien sûr, tout ceci est largement prospectif, car pour l’instant il n’y a pas grand chose de fait, mais les GAFA progressent vite, il ne faudra pas prendre le train en retard !

Références

[1] https://searchengineland.com/google-reveals-20-percent-queries-voice-queries-249917

[2] Audio Adversarial Examples: Targeted Attacks on Speech-to-Text. Nicholas Carlini et David Wagner.
https://www.arxiv-vanity.com/papers/1801.01944/

[3]  CHELBA, Ciprian, SCHALKWYK, Johan, BRANTS, Thorsten, et al. Query language modeling for voice search. In : Spoken Language Technology Workshop (SLT), 2010 IEEE. IEEE, 2010. p. 127-132.
https://pdfs.semanticscholar.org/efd4/e54249cebdcc13af8a81b788bb0ea4f9a763.pdf