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 :
TOKENLIST
contient tous les termes d'origine de la requête.- 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 dansTOKENLIST
. 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 :
- Limite de profondeur de récupération : nombre maximal de lignes à évaluer.
- 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
- 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 de texte complet et non textuelles.
- Découvrez comment effectuer une recherche dans plusieurs colonnes.