Recherche de catalogue Architecture

Aperçu

En avril 2019, la fonctionnalité de recherche de catalogue a été mise à niveau vers Elasticsearch. Cette mise à niveau offre un certain nombre d'avantages, dont les principaux sont une pertinence et une précision améliorées et des performances considérablement améliorées - le temps de réponse est beaucoup plus cohérent 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 le résultat de décisions prises après une analyse approfondie des résultats de recherche - elles sont impossibles à éliminer complètement.

Racisme

Racisme est le processus de réduction des mots infléchis (ou parfois dérivés) à leur tige de mot , base ou racine forme — généralement une forme écrite.

Une tige pour l'anglais fonctionnant sur la tige chat devrait identifier ces cordes comme chats , félin et méchant. Un algorithme de dérivation pourrait également réduire les mots pêche , pêché et pêcheur à la tige poisson. La racine n'a pas besoin d'être un mot, par exemple l'algorithme de Porter réduit se disputer , argumenté , fait valoir , argumentant et Argus à la tige argu.

Notre recherche existante utilise le stemmer Lancaster (Paice / Husk), cet algorithme est généralement considéré comme trop agressif - cela entraîne un manque de distinction, par exemple plus léger et lumière serait considéré 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 stemmer impacte potentiellement une proportion significative (~35%) des recherches : cela ne veut pas dire que les résultats volonté être différent, juste qu'ils force être différent - mais en général, cela devrait être pour le mieux : cela dit, certains sous-ensembles 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, cela équivaut à peu près à supprimer la ponctuation et les caractères associés - au lieu de les supprimer, nous les échappons 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 « smooshing de termes » alors que dans Elasticsearch, nous supprimons les termes malformés, considérez cette recherche avec un champ vide tags: terme: q=tags: state:ACTIVE

• Existant : tags:state:ACTIVE — rechercher des vidéos avec une balise de state:ACTIVE
• Recherche élastique : state:ACTIVE - laisser tomber le terme vide

Il existe un certain nombre de cas limites subtils liés à la gestion de la ponctuation pendante 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 devinons malheureusement ce qu'un utilisateur aurait pu vouloir ( alors qu'en réalité on aurait dû retourner une erreur leur permettant d'affiner leur 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 : ceci est interrogé en fonction de la valeur d'un champ qui est 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 a tendance à refléter les mises à jour plus rapidement — ce n'est pas toujours le cas, mais en général, l'expérience avec Elasticsearch est que les résultats refléteront 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 y a 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, cela renverra les deux vidéos dans l'ordre:

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

Il y a deux problèmes avec ceci:

• 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 vidéo 1 est renvoyée car il s'agit de la seule vidéo avec le mot « lumière » dans le titre.

Exemple 2

Comme décrit dans notre Documentation de l'API CMS pour le stemming , la recherche de radical est prise en charge, mais pas les recherches de mots partielles. 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 renvoyé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 ressemblent à:

  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.