Comment nous enseignons à Yandex à répondre aux questions et à économiser 20 000 heures par jour aux utilisateurs

Lorsque nous saisissons une requête dans la barre de recherche, nous recherchons des informations, pas des liens. De plus, nous avons souvent besoin d'une courte phrase ou d'un fait bien connu. Par exemple, [la formule du volume de la pyramide tronquée ] est la même sur tous les sites - les liens ne sont pas nécessaires, il suffit de donner une réponse.

Personne ne peut surprendre qui que ce soit avec des réponses factuelles (informatives), mais peu de gens savent comment ils sont formés, comment ils diffèrent et ce qui s'est passé dans ce domaine récemment. Je m'appelle Anton Ivanov. Aujourd'hui, avec mon collègue Mikhail Ageevdminernous allons raconter l'histoire des réponses dans la recherche et partager certains des détails dont nous n'avons pas parlé auparavant. J'espère que ce sera utile.

L'histoire d'Internet est l'histoire de la simplification de la recherche d'informations. Il était une fois, les gens visitaient les catalogues en ligne pour trouver des réponses où les liens vers les sites étaient regroupés par sujet. Au fil du temps, les moteurs de recherche sont apparus, ils ont appris à rechercher des sites par mots clés. La demande d'une recherche rapide d'informations a stimulé le développement de la technologie: une recherche de mots a progressivement évolué vers une recherche de sens, lorsque la réponse pouvait être trouvée sur une page sans intersection par mots-clés. Mais même dans ce cas, j'ai dû cliquer sur les liens. Les gens ont toujours rêvé de plus.

Premiers faits

Maintenant, il est difficile de se rappeler comment les réponses factuelles de Yandex ont commencé. Nous pouvons dire que la solution était un format spécial du sorcier, qui suppose une réponse textuelle courte sans interactivité (par opposition à répondre aux demandes [ mon adresse IP ] ou [ aqua color ]). Comme vous le savez, l'implémentation d'un tel format n'est pas difficile. La question principale est différente: où trouver les réponses?



Nous avons commencé par la méthode technique la plus simple. Des personnes spéciales (évaluateurs) ont analysé les requêtes les plus populaires, ont choisi celles pour lesquelles vous pouvez trouver une réponse courte. Un exemple classique d'une telle requête est [ combien de pattes a une mouche ].



De cette façon, il était possible de couvrir uniquement les requêtes les plus populaires, et la longue queue des autres requêtes était ignorée. En partie, nous avons résolu ce problème à l'aide du crowdsourcing.

Il y a quelques années, les tolokers ont commencé à nous aider à reconstituer la base de données des réponses factuelles. Des requêtes fréquentes ont été téléchargées sur la plateforme, les tolokers ont vu la tâche: «Est-il vrai que vous pouvez donner une réponse exhaustive à cette requête? Et si c'est vrai, alors donnez-le. " Bien sûr, d'autres tolokers ont vérifié l'adéquation des réponses et nous avons détecté les erreurs avec l'aide d'un garde de recherche . Soit dit en passant, les tolokers nous ont également aidés à découvrir que les réponses réelles avec une image sont généralement appréciées par les utilisateurs plus qu'un simple texte.

L'aide des tolokers est importante, mais même elle n'aidera pas à couvrir la longue queue des requêtes basse fréquence. Il y a simplement trop de demandes de ce type pour un balisage manuel: il n'y en a pas des dizaines de milliers, mais des millions! Pour résoudre ce problème, l'expérience de classement de la recherche nous a été utile.

Extrait de faits

Lorsque vous recherchez quelque chose dans la recherche Yandex, vous voyez non seulement 10 liens, mais aussi un titre, une description, une icône et d'autres données.

Nous nous concentrons sur la description. Notre recherche le crée automatiquement. Pour mettre en évidence le meilleur fragment de texte, le modèle léger CatBoost est utilisé, qui estime la proximité d'un fragment de texte et d'une requête. Il s'avère que les descriptions de liens contiennent parfois déjà des réponses factuelles. Il serait étrange de ne pas en profiter - mais pas si simple.

Il peut sembler que la tâche se résume à choisir la description «la plus factuelle» parmi toutes les descriptions des pages trouvées sur demande, mais cette approche ne fonctionnera pas bien. La raison en est que la description informative de la page ne coïncide pas toujours avec une bonne réponse à la question directe d'une personne. Par conséquent, notre technologie Fact Snippet construit des faits en parallèle avec les descriptions de page, mais en fonction d'autres paramètres afin que le résultat soit similaire à la réponse. Et maintenant, parmi eux, vous devez choisir la réponse la plus haute qualité.

Nous avons déjà ditsur Habré sur les algorithmes de recherche "Palekh", "Korolev" et sur l'approche DSSM. La tâche s'est alors résumée à trouver des textes proches dans le classement des pages. En fait, nous avons comparé deux vecteurs: le vecteur de requête et le vecteur de texte du document. Plus ces vecteurs sont proches dans un espace multidimensionnel, plus les significations des textes sont proches. Pour choisir les meilleurs faits de qualité, nous avons fait de même. Notre modèle de réseau de neurones, formé sur les réponses que nous connaissons déjà, construit des vecteurs de réponse pour les pages trouvées dans la recherche et les compare avec le vecteur de requête. Nous obtenons donc la meilleure réponse.

Il est clair que répondre à toutes les demandes de cette manière ne vaut pas la peine: la plupart des demandes ne nécessitent pas de réponse factuelle. Par conséquent, nous utilisons un autre modèle pour supprimer les demandes «non factuelles».

Extrait de faits 2.0

Tout ce dont nous avons parlé ci-dessus concernait des réponses factuelles «classiques»: courtes, complètes, comme dans l'encyclopédie. Cette direction est depuis longtemps la seule. Mais plus loin, plus nous avons vu que la division sur la base de l'existence d'une réponse exhaustive, d'une part, est très fragile, et d'autre part - opaque pour l'utilisateur: il lui suffit de résoudre son problème plus rapidement. Il m'a fallu aller au-delà des faits habituels. Le projet est donc apparu Fact Snippet 2.0.



Pour simplifier les choses, Fact Snippet 2.0 est le même Fact Snippet, mais sans l'exigence de trouver une «réponse complète». En fait, tout est un peu plus compliqué.

Permettez-moi de vous rappeler que Fact Snippet fonctionne en deux étapes. Dans un premier temps, à l'aide d'un modèle simple, nous évaluons la «nature factuelle» de la demande: s'agit-il ou non d'une réponse factuelle? Si oui, à la deuxième étape, nous recherchons une réponse, elle apparaît dans les résultats de la recherche. Pour Fact Snippet 2.0, nous avons adapté les deux étapes pour trouver des réponses à un plus large éventail de questions. Ces réponses ne prétendent pas être encyclopédiques dans leur intégralité, mais sont toujours utiles.

Il est possible, mais pas toujours nécessaire, de sélectionner un paragraphe de texte pour toute demande. Parfois, les textes trouvés ne sont pas suffisamment pertinents pour la requête. Parfois, nous avons déjà de bonnes réponses d'autres sources - et nous devons décider laquelle choisir. Par exemple, pourquoi proposer l'adresse de l'organisation sous forme de texte si vous pouvez afficher une carte interactive, un numéro de téléphone et des avis. Nous résolvons ce problème à l'aide d'un classificateur de mélangeur, avec lequel Andrei Styskin connaissait déjà les lecteurs de Habr . Et la réponse ne doit pas être grossière, insultante. Presque toutes ces restrictions raisonnables ont leur propre classificateur, et le faire fonctionner en runtime en une fraction de seconde est une autre quête.

Reformulations des requêtes

Ils couvraient une autre partie de la longue queue, mais de nombreuses demandes «uniques» restaient en suspens. Une proportion importante d'entre eux sont d'autres formulations de requêtes que nous connaissons déjà. Par exemple, [ quand un brochet change de dent ] et [à quelle heure le brochet change de dent ] sont presque la même chose.



Pour résoudre ce problème, nous avons trouvé un mécanisme qui comprend à la volée que la demande entrante est un alias (signifie la même chose) d'une autre demande, la réponse à laquelle nous avons déjà. C'est plus facile et plus rapide que de générer indépendamment deux réponses factuelles.

Nous prenons toutes les requêtes pour lesquelles il y a des réponses, les convertissons en vecteurs et les mettons dans l'index k-NN (plus précisément, dans sa version optimisée de HNSWqui vous permet de rechercher beaucoup plus rapidement). Ensuite, nous construisons des vecteurs de requête pour lesquels il n'y a pas de réponse par coïncidence directe, et recherchons les N requêtes les plus similaires dans notre k-NN.

Ensuite, nous passons par ce sommet et parcourons le classificateur katbust du triple:

- demande de l'utilisateur;
- demande de k-NN;
- réponse à une demande de k-NN.

Si le vérificateur vérificateur est positif, la demande est considérée comme un alias de la demande de k-NN, on peut retourner la réponse déjà connue.

La partie créative principale de cette conception est d'écrire des facteurs pour le classificateur. Ici, nous avons essayé beaucoup d'idées différentes. Parmi les facteurs les plus forts:

- vecteurs de requête;
- distances Levenshtein;
- encastrements mot à mot;
- facteurs basés sur une variété de sorciers pour chacune des demandes;
- distance entre les mots de requête.

Séparément, je parlerai d'une astuce utilisant le réseau neuronal BERT. Nous avons des restrictions assez strictes sur le temps de recherche d'un alias: un maximum de quelques millisecondes. Il est impossible d'effectuer BERT dans un tel temps avec une charge de plusieurs milliers de RPS sur les ressources actuelles. Par conséquent, avec notre modèle BERT, nous avons collecté un grand nombre (des centaines de millions) d'estimations artificielles et formé sur eux un réseau neuronal DSSM plus simple, qui fonctionne très rapidement lors de l'exécution. En conséquence, avec une certaine perte de précision, un facteur fort a été obtenu.

En fait, on peut déterminer la proximité sémantique des demandes par d'autres moyens. Par exemple, si deux requêtes diffèrent l'une de l'autre en un seul mot - vérifiez en quoi les résultats de recherche de ces requêtes diffèrent (regardez le nombre de liens correspondants en haut). Si vous répétez cela plusieurs millions de fois et faites la moyenne des résultats, vous obtenez une assez bonne estimation de la façon dont la signification de la requête change si vous changez un mot pour un autre. Après cela, vous pouvez ajouter toutes les données dans une structure (par exemple, trie) et calculer la mesure de la proximité des requêtes à travers la distance de Levenshtein généralisée. Vous pouvez étendre cette approche et considérer non seulement les mots, mais aussi les paires de mots (mais le trie est obtenu beaucoup plus en raison de la croissance exponentielle des données).

Et après

Selon nos estimations, grâce aux réponses factuelles / informatives, nous économisons 20 000 heures par jour aux utilisateurs, car ils n'ont pas à parcourir les liens dans les résultats de recherche (et cela ne compte pas le temps qu'ils auraient consacré à trouver la réponse sur les sites). C'est bien, mais il y a toujours de la place pour grandir. Par exemple, nous utilisons maintenant le texte que nous trouvons sur Internet pour les réponses, mais le texte fini ne peut pas toujours être trouvé au même endroit ou sous la bonne forme. Avec l'aide de réseaux de neurones, ce problème peut être résolu: générer une réponse pour qu'elle corresponde à la demande et ne contienne pas de contenu inutile. Il s'agit de notre projet de recherche de neurosummarisation, dont j'espère que nous parlerons la prochaine fois.