Classer les résultats de recherche

Remarque : Cette fonctionnalité est disponible dans les éditions Spanner Enterprise et Enterprise Plus. Pour en savoir plus, consultez la présentation des éditions Spanner.

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

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

L'exemple suivant montre comment effectuer une recherche classée à l'aide de la fonction SCORE :

GoogleSQL

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

PostgreSQL

Cet exemple utilise spanner.search avec spanner.score.

SELECT albumid
FROM albums
WHERE spanner.search(albumtitle_tokens, 'fifth symphony')
ORDER BY spanner.score(albumtitle_tokens, 'fifth symphony') DESC

Attribuer un score aux termes de requête avec la fonction SCORE

La fonction SCORE calcule un score pour chaque terme de requête, puis combine les scores. Le score par terme est basé approximativement sur la fréquence du terme – fréquence inverse des documents (TF/IDF). Le score est l'un des éléments de l'ordre final d'un enregistrement. La requête le combine à d'autres signaux, tels que la fraîcheur qui module le score de pertinence thématique.

Dans l'implémentation actuelle, la partie IDF de TF/IDF n'est disponible que lorsque enhance_query=>true est utilisé. Elle calcule la fréquence relative des mots en fonction du corpus Web complet utilisé par la recherche Google, plutôt que d'un index de recherche spécifique. Si l'amélioration de la requête n'est pas activée, la notation n'utilise que le composant de fréquence des termes (TF, term frequency), c'est-à-dire que le terme IDF (inverse document frequency) 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 pas de signification autonome. Plus le score est élevé, plus la réponse correspond à la requête.

En général, les arguments tels que query et enhance_query sont les mêmes dans les fonctions SEARCH et SCORE pour assurer la cohérence de la récupération et du classement.

La méthode recommandée consiste à 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 attribuer un score à chaque champ individuellement. La requête combine ensuite ces scores individuels. Pour ce faire, il est courant d'additionner les scores individuels, puis de les booster en fonction des pondérations de champ fournies par l'utilisateur (à l'aide des paramètres de requête SQL).

Par exemple, la requête suivante combine la sortie de deux fonctions SCORE :

GoogleSQL

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

PostgreSQL

Cet exemple utilise les paramètres de requête $1 et $2, qui sont respectivement liés à "cinquième symphonie" et "blue note".

SELECT albumid
FROM albums
WHERE spanner.search(title_tokens, $1) AND spanner.search(studio_tokens, $2)
ORDER BY spanner.score(title_tokens, $1) * $titleweight
        + spanner.score(studio_tokens, $2) * $studioweight
LIMIT 25

L'exemple suivant ajoute deux paramètres de boost :

• La fraîcheur (FreshnessBoost) augmente le score de (1 + @freshnessweight * GREATEST(0, 30 - DaysOld) / 30).
• La popularité(PopularityBoost) augmente le score en le multipliant par le facteur (1 + IF(HasGrammy, @grammyweight, 0).

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

GoogleSQL

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

PostgreSQL

Cet exemple utilise les paramètres de requête $1, $2, $3, $4, $5 et $6, qui sont liés aux valeurs spécifiées pour titlequery, studioquery, titleweight, studioweight, grammyweight et freshnessweight, respectivement.

SELECT albumid
FROM
  (
    SELECT
      albumid,
      spanner.score(title_tokens, $1) * $3 AS titlescore,
      spanner.score(studio_tokens, $2) * $4 AS studioscore,
      (extract(epoch FROM current_timestamp) * 10e+6 - releasetimestamp) / 8.64e+10 AS daysold,
      (1 + CASE WHEN hasgrammy THEN $5 ELSE 0 END) AS popularityboost
    FROM albums
    WHERE spanner.search(title_tokens, $1) AND spanner.search(studio_tokens, $2)
  ) AS subquery
ORDER BY (subquery.TitleScore + subquery.studioscore)
  * (1 + $6 * greatest(0, 30 - subquery.daysold) / 30) * subquery.popularityboost
LIMIT 25

TOKENLIST_CONCAT peut également être utilisé dans la recherche et la notation pour simplifier les requêtes, le cas échéant.

GoogleSQL

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

PostgreSQL

Cet exemple utilise spanner.tokenlist_concat. Le paramètre de requête $1 est lié à "blue note".

SELECT albumid
FROM albums
WHERE spanner.search(spanner.tokenlist_concat(ARRAY[title_tokens, studio_tokens]), $1)
ORDER BY spanner.score(spanner.tokenlist_concat(ARRAY[title_tokens, studio_tokens]), $1)
LIMIT 25

Booster les correspondances de l'ordre des requêtes

Spanner applique un boost multiplicatif à la sortie de la fonction SCORE pour les valeurs qui contiennent les termes de la requête dans le même ordre que celui dans lequel ils apparaissent dans la requête. 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 et dans le même ordre que dans la requête.

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

• Une requête avec une négation ne peut pas bénéficier d'un boost de correspondance partielle.
• Une requête comportant une conjonction reçoit un boost si une partie de la conjonction apparaît aux emplacements appropriés.
• Une requête contenant une expression reçoit un boost si l'expression apparaît dans TOKENLIST, et si le terme à gauche de l'expression dans la requête apparaît à gauche de l'expression dans TOKENLIST, et inversement pour le terme à droite de l'expression.

Spanner applique un boost de correspondance exacte lorsque toutes les règles précédentes sont respectées et que les premier et dernier jetons de la requête sont les premier et dernier jetons du document.

Exemple de document : Bridge Over Troubled Water

Requête	Boost appliqué
Bridge Troubled	aucune amélioration.
Pont au-dessus d'une autre étendue d'eau	aucune amélioration.
Bridge (Over OR Troubled) Water	aucune amélioration.
Bridge Over	optimisation partielle
Bridge Over (Troubled OR Water)	optimisation partielle
Bridge Over Troubled Water	boost exact
Bridge "Over Troubled" Water	boost exact
Pont ("Over Troubled" OR missingterm) Water	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 n'est pas pratique de classer tous les résultats. Les requêtes de scoring sont généralement soumises à deux limites :

1. Limite de profondeur de récupération : nombre maximal de lignes à évaluer.
2. Limite de taille de l'ensemble de résultats : nombre maximal de lignes que la requête doit renvoyer (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 :

GoogleSQL

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

PostgreSQL

Cet exemple utilise les paramètres de requête $1, $2 et $3, qui sont liés aux valeurs spécifiées pour title_query, retrieval_limit et page_size, respectivement.

SELECT *
FROM (
  SELECT albumid, title_tokens
  FROM albums
  WHERE spanner.search(title_tokens, $1)
  ORDER BY releasetimestamp DESC
  LIMIT $2
) AS subquery
ORDER BY spanner.score(subquery.title_tokens, $1)
LIMIT $3

Cette approche est particulièrement efficace si Spanner utilise le signal de classement le plus important pour trier l'index.

Étapes suivantes

• En savoir plus sur les requêtes de recherche en texte intégral
• Découvrez comment effectuer une recherche de sous-chaîne.
• Découvrez comment paginer les résultats de recherche.
• Découvrez comment combiner des requêtes en texte intégral et non textuelles.
• Découvrez comment effectuer des recherches dans plusieurs colonnes.