Trovare corrispondenze approssimative con la ricerca parziale

In questa pagina viene descritto come utilizzare una ricerca parziale nell'ambito di una ricerca a testo intero.

Oltre a eseguire ricerche di token esatte utilizzando SEARCH e SEARCH_SUBSTRING funzioni, Spanner supporta anche le app approssimative (o fuzzy). Le ricerche fuzzy trovano documenti corrispondenti nonostante piccole differenze tra la query e il documento.

Spanner supporta i seguenti tipi di ricerca parziale:

  • Ricerca approssimativa basata su n-grammi
  • Ricerca fonetica utilizzando Soundex

La ricerca fuzzy basata su n grammi si basa sullo stesso la tokenizzazione di una sottostringa ricerca di sottostringhe richiede. La configurazione del tokenizzatore è importante in quanto influisce la qualità e le prestazioni delle ricerche. L'esempio seguente mostra come creare un query con errori ortografici o parole con ortografia diversa per trovare corrispondenze approssimative nell'indice di ricerca.

Schema

CREATE TABLE Albums (
  AlbumId STRING(MAX) NOT NULL,
  AlbumTitle STRING(MAX),
  AlbumTitle_Tokens TOKENLIST AS (
    TOKENIZE_SUBSTRING(AlbumTitle, ngram_size_min=>2, ngram_size_max=>3,
                       relative_search_types=>["word_prefix", "word_suffix"])) HIDDEN
) PRIMARY KEY(AlbumId);

CREATE SEARCH INDEX AlbumsIndex
ON Albums(AlbumTitle_Tokens)
STORING (AlbumTitle);

Query

La seguente query trova gli album con i titoli più vicini a "L'odio Kaliphorn", ad esempio "Hotel California".

SELECT AlbumId
FROM Albums
WHERE SEARCH_NGRAMS(AlbumTitle_Tokens, "Hatel Kaliphorn")
ORDER BY SCORE_NGRAMS(AlbumTitle_Tokens, "Hatel Kaliphorn") DESC
LIMIT 10

Ottimizza il rendimento e il richiamo per una ricerca approssimativa basata su n-grammi

La query di esempio nella sezione precedente esegue ricerche in due fasi, utilizzando due funzioni diverse:

  1. SEARCH_NGRAMS trova tutti gli album candidati che hanno condiviso n-grammi con la query di ricerca. Ad esempio, n-grammi di tre caratteri per "California" includi [cal, ali, lif, ifo, for, orn, rni, nia] e per "Kaliphorn" includi [kal, ali, lip, iph, pho, hor, orn]. Gli n-grammi condivisi in questi set di dati sono [ali, orn]. Per impostazione predefinita, SEARCH_NGRAMS corrisponde a tutti documenti con almeno due n-grammi condivisi, pertanto "Kaliphorn" corrisponde a "California".
  2. SCORE_NGRAMS classifica le corrispondenze in base alla somiglianza. La somiglianza tra due stringhe viene definita come rapporto tra n-grammi condivisi distinti e n-grammi distinti non condivisi:
$$ \frac{shared\_ngrams}{total\_ngrams_{index} + total\_ngrams_{query} - shared\_ngrams} $$

Spanner ha tre argomenti di configurazione che possono essere utilizzati con SEARCH_NGRAMS:

  1. Le dimensioni minime e massime degli n-gram specificati in TOKENIZE_SUBSTRING o TOKENIZE_NGRAMS. Sconsigliamo di usare un solo n-grammi di carattere perché corrispondono a un intervallo numero di documenti. D'altra parte, gli n-grammi lunghi causano SEARCH_NGRAMS a mancare le parole brevi con errori di ortografia.
  2. Numero minimo di n-grammi che SEARCH_NGRAMS deve corrispondere (impostato con gli argomenti min_ngrams e min_ngrams_percent in SEARCH_NGRAMS). Numeri più alti in genere rendono la query più veloce, ma riducono richiamo.

Per ottenere un buon equilibrio tra prestazioni e richiamo, questi argomenti possono essere configurati in base alla query e al carico di lavoro specifici.

Ti consigliamo inoltre di includere un LIMIT interno per evitare di creare query molto costose quando viene rilevata una combinazione di n-gram popolari:

SELECT AlbumId
FROM (
  SELECT AlbumId,
         SCORE_NGRAMS(AlbumTitle_Tokens, @p) AS score
  FROM Albums
  WHERE SEARCH_NGRAMS(AlbumTitle_Tokens, @p)
  LIMIT 10000  # inner limit
)
ORDER BY score DESC
LIMIT 10  # outer limit

Ricerca parziale basata su n-grammi e modalità di query avanzata

Oltre alla ricerca fuzzy basata su n-grammi, modalità di query avanzata gestisce anche alcune parole con errori ortografici. Pertanto, esiste una certa sovrapposizione tra i due le funzionalità di machine learning. La seguente tabella riassume le differenze:

ricerca parziale basata su n-grammi Modalità di query avanzata
Costo Richiede una tokenizzazione di sottostringhe più costosa basata su n-grams Richiede una tokenizzazione del testo completo meno costosa
Tipi di query di ricerca Funziona bene con documenti brevi che contengono poche parole, ad esempio il nome di una persona, di città o di prodotto Funziona altrettanto bene con documenti di qualsiasi dimensione e con query di ricerca di qualsiasi dimensione.
Ricerca di parole parziali Esegue una ricerca di sottostringhe che consente errori ortografici Supporta solo la ricerca di parole intere (SEARCH_SUBSTRING non supporta l'argomento enhance_query)
Parole con errori ortografici Supporta parole con errori ortografici nell'indice o nella query Supporta solo le parole con errori ortografici nella query
Correzioni Trova le corrispondenze con errori ortografici, anche se non sono una parola reale Corregge gli errori ortografici di parole comuni e note

Eseguire una ricerca fonetica con Soundex

Spanner fornisce la funzione SOUNDEX per trovare parole che hanno una grafia diversa, ma che suonano allo stesso modo. Ad esempio, SOUNDEX("steven"), SOUNDEX("stephen") eSOUNDEX("stefan") sono tutti "s315", mentre SOUNDEX("stella") è "s340". SOUNDEX è sensibile alle maiuscole e funziona solo per gli alfabeti latini.

La ricerca fonetica con SOUNDEX può essere implementata con una colonna generata e un come mostrato nell'esempio seguente:

CREATE TABLE Singers (
  SingerId INT64,
  Name STRING(MAX),
  Name_Soundex STRING(MAX) AS (LOWER(SOUNDEX(name)))
) PRIMARY KEY(SingerId);

CREATE INDEX SingersPhoneticIndex ON Singers(Name_Soundex);

La seguente query corrisponde a "stefan" a "Steven":

SELECT SingerId
FROM Singers
WHERE Name_Soundex = LOWER(SOUNDEX("stefan"))

Passaggi successivi