Classer les résultats de recherche

Cette page explique comment classer les résultats de recherche pour des recherches en texte intégral dans Spanner.

Spanner permet de calculer un score de thématique, qui fournit un pour créer des fonctions de classement sophistiquées. Ces scores calculer la pertinence d'un résultat par rapport à une requête, en fonction du terme de requête la fréquence de diffusion et d'autres options personnalisables.

L'exemple suivant illustre une recherche classée:

SELECT AlbumId
FROM Albums
WHERE SEARCH(AlbumTitle_Tokens, "fifth symphony")
ORDER BY SCORE(AlbumTitle_Tokens, "fifth symphony") DESC

Évaluer les termes de requête avec la fonction SCORE

SCORE calcule un score pour chaque terme de requête, puis combine scores. Le score par trimestre est approximativement basé sur la fréquence du terme – document inverse. (TF/IDF). Le score est de un élément de l'ordre final d'un enregistrement. La requête l'associe d'autres signaux, comme la fraîcheur modulant le score de thématique.

Dans l'implémentation actuelle, la partie IDF de TF/IDF n'est disponible que lorsque enhance_query=>true est utilisé. Il calcule la fréquence relative des mots basé sur l'ensemble du corpus Web utilisé par la recherche Google, un index de recherche spécifique. Si l'amélioration de la requête r n'est pas activée, l'évaluation n'utilise que la composante fréquence des termes (TF) (c'est-à-dire que le terme IDF est défini sur 1).

La fonction SCORE renvoie des valeurs qui servent de scores de pertinence que Spanner utilise pour établir un ordre de tri. Elles n'ont aucune signification autonome. Plus le score est élevé, plus la correspondance est bonne.

Habituellement, les arguments tels que query et enhance_query sont identiques dans les deux SEARCH et SCORE pour assurer la cohérence de la récupération et du classement.

Pour ce faire, il est recommandé d'utiliser ces arguments avec des paramètres de requête plutôt que des littéraux de chaîne. et spécifier les mêmes paramètres de requête dans les fonctions SEARCH et SCORE.

Évaluer plusieurs colonnes

Spanner utilise la fonction SCORE pour évaluer chaque champ individuellement. La requête combine ensuite ces des scores individuels. Une façon courante de le faire est de résumer les des scores individuels, puis les booster selon la pondération des champs fournie par l'utilisateur (fournies à l'aide de paramètres de requête SQL).

Par exemple, la requête suivante combine le résultat de deux fonctions SCORE:

SELECT AlbumId
FROM Albums
WHERE SEARCH(Title_Tokens, @p1) AND SEARCH(Studio_Tokens, @p2)
ORDER BY SCORE(Title_Tokens, @p1) * @titleweight + SCORE(Studio_Tokens, @p2) * @studioweight
LIMIT 25

L'exemple suivant ajoute deux paramètres d'optimisation:

  • Le niveau d'actualisation (FreshnessBoost) augmente le score avec (1 + @freshnessweight * GREATEST(0, 30 - DaysOld) / 30)
  • La popularité(PopularityBoost) augmente le score en le multipliant par facteur (1 + IF(HasGrammy, @grammyweight, 0).

Pour plus de lisibilité, la requête utilise l'opérateur WITH.

SELECT AlbumId
FROM Albums
WHERE SEARCH(Title_Tokens, @p1) AND SEARCH(Studio_Tokens, @p2)
ORDER BY WITH(
  TitleScore AS SCORE(Title_Tokens, @p1) * @titleweight,
  StudioScore AS SCORE(Studio_Tokens, @p2) * @studioweight,
  DaysOld AS (UNIX_MICROS(CURRENT_TIMESTAMP()) - ReleaseTimestamp) / 8.64e+10,
  FreshnessBoost AS (1 + @freshnessweight * GREATEST(0, 30 - DaysOld) / 30),
  PopularityBoost AS (1 + IF(HasGrammy, @grammyweight, 0)),
  (TitleScore + StudioScore) * FreshnessBoost * PopularityBoost)
LIMIT 25

TOKENLIST_CONCAT peut également être utilisé à la fois pour la recherche et l'évaluation pour simplifier les requêtes, le cas échéant:

SELECT AlbumId
FROM Albums
WHERE SEARCH(TOKENLIST_CONCAT([Title_Tokens, Studio_Tokens]), @p)
ORDER BY SCORE(TOKENLIST_CONCAT([Title_Tokens, Studio_Tokens]), @p)
LIMIT 25

Booster les correspondances d'ordre de requête

Vous pouvez appliquer un boost multiplicatif au score de pertinence pour les valeurs qui contiennent les termes de requête dans le même ordre qu'ils apparaissent dans la requête. Il y Il existe deux versions de ce boost: la correspondance partielle et la correspondance exacte. Un boost de correspondance partielle est appliqué lorsque :

  1. TOKENLIST contient tous les termes d'origine de la requête.
  2. Les jetons sont adjacents les uns aux autres et dans le même ordre qu'ils apparaissent dans la requête.

Il existe certaines règles spéciales pour les conjonctions, les négations et les expressions :

  • Une requête contenant une négation ne peut pas bénéficier d'un boost de correspondance partielle.
  • Une requête avec une conjonction reçoit un coup de pouce si une partie de la conjonction apparaît aux endroits appropriés.
  • Une requête contenant une expression est améliorée si l'expression apparaît dans TOKENLIST, et que le terme situé à gauche de l'expression dans la requête apparaît à gauche de l'expression dans TOKENLIST. Il en va de même pour le terme situé à droite de l'expression.

Spanner applique un boost de correspondance exacte lorsque toutes les règles précédentes sont vraies. Les premiers et derniers jetons de la requête sont les premiers et derniers jetons du document.

Exemple de document: Pont sur des eaux difficiles

Requête Boost appliqué
Problème lié au pont aucun boost
Pont surplombant un autre cours d'eau aucun boost
Pont (sur ou en panne) sur l'eau aucun boost
Pont amplification partielle
Pont (eau trouble ou en crue) amplification partielle
Pont au-dessus d'une eau trouble boost exact
Bridge "Over Troubled" Eau boost exact
Eau du pont ("En difficulté" OR missingterm) boost exact

Limiter la profondeur de récupération

Les index de recherche contiennent souvent des millions de documents. Pour les requêtes dont les prédicats ont une faible sélectivité, il est peu pratique de classer tous les résultats. Les requêtes d'évaluation ont généralement deux limites :

  1. Limite de profondeur de récupération : nombre maximal de lignes à évaluer.
  2. Result set size limit (Limite de taille de l'ensemble de résultats) : nombre maximal de lignes que la requête doit respecter renvoyé (généralement la taille de la page).

Les requêtes peuvent limiter la profondeur de récupération avec des sous-requêtes SQL:

SELECT *
FROM (
  SELECT AlbumId
  FROM Albums
  WHERE SEARCH(Title_Tokens, @p1)
  ORDER BY ReleaseTimestamp DESC
  LIMIT @retrieval_limit
)
ORDER BY SCORE(Title_Tokens, @p1)
LIMIT @page_size

Cela fonctionne particulièrement bien si Spanner utilise pour trier l'index.

Étape suivante