assistance Contacter le support | Étatétat du système du système
Contenu de la page

    Architecture de recherche de catalogue

    Dans cette rubrique, vous découvrirez l'architecture de la technologie de recherche de catalogue utilisée pour les API CMS et Lecture.

    Présentation

    Depuis 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 l'amélioration de la pertinence et de la précision, et les 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 de lecture, la recherche interactive Studio et les méthodes de recherche de catalogue.

    Bien que Brightcove ait investi beaucoup d'efforts pour rendre les résultats d'Elasticsearch cohérents, il existe des différences, et il est peu probable 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 constaté que plus de 90 % des recherches renvoient des résultats correspondant en termes de nombre de résultats renvoyés. Il s'agit d'un indicateur que les résultats attendus ne doivent pas être suffisamment différents pour causer des problèmes avec les intégrations d'API.

    comparaison

    Ce graphique montre le nombre de résultats de recherche correspondant exactement au nombre de résultats entre les deux systèmes en bleu et ceux dont le nombre diffère en rouge.

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

    Cependant, il y a des limites à ce que nous pouvons apprendre de ce genre 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 sont le résultat de décisions prises après une analyse approfondie des résultats de recherche — il est impossible de les éliminer complètement.

    Stronçage

    L'endiguer est le processus qui consiste à réduire les mots infléchis (ou parfois dérivés) à leur forme de tige , de base ou de racine de mots — généralement une forme de mot écrite.

    Un pied pour l'anglais opérant sur le chat de tige devrait identifier des cordes telles que les chats , catlike et catty. 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 actuelle utilise le dériveur 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 léger serait considéré comme le même terme sous Lancaster.

    Elasticsearch utilise un algorithme plus récent et beaucoup moins agressif (Porter2) qui a acquis une large adoption dans l'industrie et est généralement considéré comme une amélioration significative (Lancaster est maintenant rare). Le changement de Stemmer affecte potentiellement une proportion significative (~ 35%) des recherches : cela ne veut pas dire que les résultats seront différents, juste qu'ils peuvent être différents — mais en général cela devrait être pour le mieux : cela dit, un sous-ensemble de les clients peuvent dépendre de l'ancien comportement.

    Pertinence

    Notre recherche existante semble avoir une normalisation TF plus stricte. Il en résulte un tri différent de la pertinence des termes qui se trouvent dans des champs plus grands (c'est-à-dire qu'il considère que la correspondance est moins pertinente, car elle donne moins de poids au terme puisqu'il est plus petit par rapport à la longueur du document).

    Caractères spéciaux

    Les caractères spéciaux sont dépouillés dans notre recherche existante, ce qui équivaut à peu près à la ponctuation de décapage et aux caractères associés — au lieu de les décaper, nous les échappons généralement dans Elasticsearch, donc il y a une chance qu'une recherche les prenne en compte à la place.

    Traitement des termes

    Les requêtes de recherche existantes effectuent `term smooshing` alors que dans Elasticsearch nous laissons tomber les termes mal formés, considérons cette recherche avec un tags: terme vide : q=tags: state:ACTIVE

    • Existant : tags:state:ACTIVE— recherche de vidéos avec une balise de state:ACTIVE
    • Elasticsearch : state:ACTIVE— supprimer le terme vide

    Il y a un certain nombre de cas de bord subtils liés à la gestion de la ponctuation pendante et des requêtes qui sont généralement mal formés, 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 (quand vraiment nous aurions 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 jouables : la requête peut inclure un drapeau, 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 mis à jour
    • Elasticsearch : interrogé en fonction 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 retard associé au mécanisme existant, et le mécanisme de maintenance du drapeau n'est pas entièrement fiable).

    précision de l'index

    L'index Elasticsearch est « plus frais » 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éteront plus précisément l'état des données sous-jacentes du catalogue. Les deux 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 (surtout dans le cas où un certain nombre d'opérations de suppression sont exécutées simultanément).

    Les résultats de recherche existants changent en fonction de l'état du shard à lequel un compte est alloué — l'état global d'un shard particulier 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 retourner toutes les vidéos qui doivent avoir le mot « light ». En utilisant l'API CMS, la requête ressemblerait à :

          q=%2Blight or q=+light

    Avec la recherche existante, cela retournera 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 #2) devrait apparaître avant « Utiliser un briquet pour faire un feu de camp » (Vidéo #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 « light » n'apparaît pas du tout dans le titre de la vidéo.

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

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

    Il s'agit là d'une amélioration parce que :

    • Pertinence : La commande est correcte.
    • Précision : Seule Video one est renvoyée car c'est la seule vidéo avec le mot « light » dans le titre.

    Exemple 2

    Comme décrit dans notre documentation API CMS pour le découpage, le stemming est pris 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 ban dans le champ nom. En utilisant l'API CMS, la requête ressemblerait à :

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

    On s'attend à ce que les mots « Interdiction », « Interdiction » et « Interdiction » produisent des résultats de recherche car « Interdiction » est une tige des trois.

    Cependant, avec le système de recherche actuel, cela retournera les cinq vidéos 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, il y a deux problèmes avec ceci :

    • Pertinence : La commande est incorrecte. « Interdiction de stationnement annoncée » devrait être la première vidéo retournée car elle contient le mot « Ban ».
    • Précision : « Jour férié » et « Bandit Capturé » ne doivent pas être retournés du tout, car « Ban » ne fait pas partie des mots « 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 là d'une amélioration parce que :

    • Pertinence : La commande est correcte.
    • Précision : Seules les vidéos avec les tiges du mot « Ban » (« Ban », « Banning » et « Banned ») sont retournées.