Recherche de catalogue Architecture

Aperçu

En avril 2019, la fonctionnalité de recherche de catalogue a été mise à niveau vers Elasticsearch. Cette mise à niveau présente de nombreux avantages, notamment une pertinence et une précision accrues, ainsi que des performances considérablement améliorées : le temps de réponse est beaucoup plus constant et généralement deux fois plus rapide. Cette nouvelle fonctionnalité affectera l'API CMS, l'API Playback, la recherche interactive Studio et les méthodes de recherche dans le catalogue.

Bien que Brightcove ait investi beaucoup d'efforts pour rendre les résultats Elasticsearch cohérents, il existe des différences, et il existe une petite possibilité que si vous avez codé des dépendances spécifiques aux résultats de recherche, votre intégration ne se comporte pas comme prévu.

Différences et impact des résultats de recherche

En étudiant l'impact potentiel, Brightcove a découvert que plus de 90 % des recherches renvoient des résultats qui correspondent en termes de nombre de résultats renvoyés. Il s'agit d'un indicateur que les résultats attendus ne devraient pas être suffisamment différents pour causer des problèmes avec les intégrations d'API.

Ce graphique montre le nombre de résultats de recherche qui correspondent exactement au nombre de résultats entre les deux systèmes en bleu, et ceux qui diffèrent en nombre en rouge.

Dans le cadre de notre déploiement, toutes les recherches par défaut, ces recherches sur la chaîne vide, sont déjà fournies par Elasticsearch depuis plusieurs mois maintenant. Les utilisateurs voient et utilisent donc déjà les résultats d'Elasticsearch sans problème.

Il y a cependant des limites à ce que nous pouvons apprendre de ce type de comparaison. Au mieux, nous ne pouvons que déduire l'intention d'une recherche particulière, et les données du catalogue sont fluides.

Différences connues

Les différences ci-dessous sont en grande partie fondamentales ou résultent de décisions prises après une analyse approfondie des résultats de recherche. Elles sont impossibles à éliminer complètement.

Racisme

La mise en racine est le processus qui consiste à réduire les mots fléchis (ou parfois dérivés) à leur forme de racine, de base ou de racine, généralement une forme écrite.

Un stemmer, en anglais, opérant sur la tige du chat doit identifier des ficelles telles que « chats », « catlike » et « catty». Un algorithme de découpage pourrait également réduire les mots « pêche », « pêché » et « pêcheur » à « poisson à tige». La racine n'a pas besoin d'être un mot, par exemple l'algorithme de Porter réduit argumenter , argumenté , argumente , argumentant et Argus à la tige discuter.

Notre recherche actuelle utilise le stemmer Lancaster (Paice/Husk). Cet algorithme est généralement considéré comme trop agressif, ce qui entraîne un manque de distinction. Par exemple, plus léger et plus léger seraient considérés comme le même terme sous Lancaster.

Elasticsearch utilise un algorithme plus récent et beaucoup moins agressif (Porter2) qui a été largement adopté dans l'industrie et est généralement considéré comme une amélioration significative (Lancaster est maintenant rare). Le changement de source peut avoir un impact sur une proportion significative (environ 35 %) des recherches : cela ne veut pas dire que les résultats seront différents, mais simplement qu'ils peuvent être différents, mais en général, cela devrait être une bonne chose : cela dit, certains sous-groupes de clients peuvent dépendre de l'ancien comportement.

Pertinence

Notre recherche existante semble avoir une normalisation TF plus stricte. Cela entraîne un tri de pertinence différent pour les termes qui se trouvent dans des champs plus grands (c'est-à-dire qu'existant considère la correspondance moins pertinente car elle donne moins de poids au terme car il est plus petit par rapport à la longueur du document).

Caractères spéciaux

Les caractères spéciaux sont supprimés dans notre recherche existante, ce qui revient à supprimer la ponctuation et les caractères associés. Au lieu de les supprimer, nous les effaçons généralement dans Elasticsearch. Il est donc possible qu'une recherche les prenne en compte.

Traitement des termes

Les requêtes de recherche existantes effectuent un « lissage de termes » alors que dans Elasticsearch, nous supprimons les termes mal formés. Considérez cette recherche avec un tags: terme vide : q=tags: state:ACTIVE

• Existante : tags:state:ACTIVE— recherche des vidéos avec le tag de state:ACTIVE
• Elasticsearch : state:ACTIVE— supprime le terme vide

Il existe un certain nombre de cas subtils liés à la gestion des ponctuations pendantes et des requêtes qui sont généralement mal formées. Nous essayons de produire ce que nous pensons que la requête était censée être, mais dans ces cas, nous sommes malheureusement en train de deviner ce que l'utilisateur a pu vouloir (alors que nous aurions vraiment dû renvoyer une erreur lui permettant d'affiner sa recherche)

Jouable uniquement

Il existe deux mécanismes pour restreindre une recherche aux vidéos actuellement lisibles : la requête peut inclure un indicateur, ou la requête elle-même peut nécessiter un certain aspect de la jouabilité.

• Existant : cette question est posée en fonction de la valeur d'un champ mis à jour
• Elasticsearch : cette requête est basée sur des plages de dates calculées

Elasticsearch devrait généralement être plus précis et produire de meilleurs résultats (il y a un décalage associé au mécanisme existant, et le mécanisme de maintenance des indicateurs n'est pas entièrement fiable).

Précision de l'index

L'index Elasticsearch est « plus récent » que l'index existant et tend à refléter les mises à jour plus rapidement. Ce n'est pas toujours le cas, mais en général, l'expérience avec Elasticsearch montre que les résultats reflètent plus précisément l'état des données du catalogue sous-jacent. Les systèmes existants et Elasticsearch sont des systèmes distribués et ne sont donc pas entièrement cohérents dans les résultats qu'ils renvoient : une requête répétée sur l'un ou l'autre système peut potentiellement renvoyer des résultats différents (en particulier dans le cas où plusieurs opérations de suppression s'exécutent simultanément).

Les résultats de recherche existants changent en fonction de l'état de la partition à laquelle un compte est attribué — l'état global d'une partition particulière peut (et a) un impact sur les résultats d'une requête particulière : Elasticsearch n'a pas cette lacune.

Exemples

Exemple 1

Disons qu'il existe deux vidéos avec les titres suivants :

      Video#1: has the title “Don’t look into the light”
      Video#2: has the title “Using a lighter to make a campfire”

L'utilisateur souhaite renvoyer toutes les vidéos qui doivent contenir le mot « light ». À l'aide de l'API CMS, la requête ressemblerait à :

      q=%2Blight or q=+light

Avec la recherche existante, les deux vidéos seront renvoyées dans l'ordre suivant :

      Video#2 - “Using a lighter to make a campfire”
      Video#1 - “Don’t look into the light”

Cela pose deux problèmes :

• Pertinence: La commande est incorrecte. « Ne regardez pas dans la lumière » (Vidéo n°2) devrait apparaître avant « Utiliser un briquet pour faire un feu de camp » (Vidéo n°1)
• Précision: « Utiliser un briquet pour faire un feu de camp » ne devrait même pas apparaître dans le jeu de résultats, car le mot « lumière » n'apparaît pas du tout dans le titre de la vidéo.

Avec Elasticsearch, cela ne renverra qu'une seule vidéo :

      Video#1 - “Don’t look into the light”

Il s'agit d'une amélioration car :

• Pertinence : La commande est correcte.
• Précision : Seule la première vidéo est renvoyée car c'est la seule vidéo dont le titre contient le mot « light ».

Exemple 2

Comme décrit dans la documentation de notre API CMS pour le référencement, le référencement est pris en charge, mais pas les recherches partielles par mots. Disons qu'il y a 5 vidéos avec les titres suivants :

      Video#1 - "Parking Ban Announced"
      Video#2 - "Parking to be Banned"
      Video#3 - "City Banning Parking"
      Video#4 - "Bank Holiday"
      Video#5 - "Bandit Captured"

L'utilisateur souhaite renvoyer toutes les vidéos qui doivent avoir le mot interdire dans le champ du nom. À l'aide de l'API CMS, la requête ressemblerait à :

      q=%2Bname%3Aban or q=+name:ban

On s'attend à ce que « Ban », « Bannir » et « Bannir » produisent des résultats de recherche, car « Ban » est une racine des trois.

Cependant, avec le système de recherche actuel, les cinq vidéos seront affichées dans cet ordre :

      Video#2 - "Parking to be Banned"
      Video#3 - "City Banning Parking"
      Video#1 - "Parking Ban Announced"
      Video#4 - "Bank Holiday"
      Video#5 - "Bandit Captured"

Encore une fois, cela pose deux problèmes :

• Pertinence : La commande est incorrecte. « Interdiction de stationnement annoncée » devrait être la première vidéo renvoyée car elle contient le mot « interdiction ».
• Précision : « Bank Holiday » et « Bandit Captured » ne doivent pas être renvoyés du tout car « Ban » ne fait pas partie du mot « Bank » ou « Bandit ».

Avec Elasticsearch, les résultats se présentent comme suit :

      Video#1 - "Parking Ban Announced"
      Video#2 - "Parking to be Banned"
      Video#3 - "City Banning Parking"

Il s'agit d'une amélioration car :

• Pertinence : La commande est correcte.
• Précision : Seules les vidéos contenant les racines du mot « Ban » (« Ban », « Bannir » et « Interdit ») sont renvoyées.