Condividi tramite

Ricerca fuzzy per correggere errori di ortografia e di digitazione

  • Articolo

Azure AI Search supporta la ricerca fuzzy, un tipo di query che compensa gli errori di digitazione e i termini con errori di ortografia nella stringa di input. La ricerca fuzzy cerca termini con una composizione simile. Espandere la ricerca per rilevare anche le corrispondenze simili corregge automaticamente un errore di digitazione quando la discrepanza è di solo pochi caratteri digitati in modo sbagliato.

Si tratta di un esercizio di espansione della query che produce una corrispondenza fra termini con una composizione simile. Quando viene specificata una ricerca fuzzy, il motore di ricerca compila un grafico (basato sulla teoria dell'automa a stati finiti deterministico) di termini composti in modo analogo, per tutti i termini interi nella query. Ad esempio, se la query include tre termini "university of washington", viene creato un grafico per ogni termine nella query search=university~ of~ washington~ (non esiste alcuna rimozione di parole non significative nella ricerca fuzzy, quindi "of" ottiene un grafico).

Il grafico è costituito da un massimo di 50 espansioni, o permutazioni, di ogni termine, e acquisisce sia varianti corrette che non corrette nel processo. Il motore restituisce quindi le corrispondenze più rilevanti nella risposta.

Per un termine come "università", il grafico potrebbe avere "unversty, universty, university, universe, inverse". Tutti i documenti che corrispondono a quelli nel grafico sono inclusi nei risultati. A differenza di altre query che analizzano il testo per gestire forme diverse della stessa parola ("topi" e "topo"), i confronti in una query fuzzy vengono eseguiti a valore nominale senza alcuna analisi linguistica sul testo. "Universo" e "inverso", che sono semanticamente diversi, corrisponderanno perché le discrepanze sintattiche sono piccole.

Una corrispondenza ha esito positivo se le discrepanze sono limitate a due o meno modifiche, in cui una modifica è un carattere inserito, eliminato, sostituito o trasposto. L'algoritmo di correzione stringa che specifica il differenziale è la metrica di distanza Damerau-Levenshtein. Viene descritto come il "numero minimo di operazioni (inserimenti, eliminazioni, sostituzioni o scambi di due caratteri adiacenti) necessari per modificare una parola nell'altra".

In Azure AI Search:

  • La query fuzzy si applica a termini interi. Le frasi non sono supportate direttamente, ma è possibile specificare una corrispondenza fuzzy per ogni termine di una frase in più parti tramite le costruzioni AND. Ad esempio: search=dr~ AND cleanin~. Questa espressione di query trova corrispondenze per "lavaggio a secco".

  • La distanza predefinita di modifica è 2. Un valore di ~0 indica nessuna espansione (solo il termine esatto è considerato una corrispondenza), ma è possibile specificare ~1 per un grado di differenza o una modifica.

  • Una query fuzzy può espandere un termine fino a 50 permutazioni. Questo limite non è configurabile, ma è possibile ridurre efficacemente il numero di espansioni riducendo la distanza di modifica a 1.

  • Le risposte sono costituite da documenti contenenti una corrispondenza pertinente (fino a 50).

Durante l'elaborazione delle query, le query fuzzy non vengono sottoposte a analisi lessicali. L'input della query viene aggiunto direttamente all'albero delle query ed espanso per creare un grafico di termini. L'unica trasformazione eseguita è la combinazione di maiuscole e minuscole.

Collettivamente, i grafici vengono inviati come criteri di corrispondenza rispetto ai token nell'indice. Come si può immaginare, la ricerca fuzzy è intrinsecamente più lenta rispetto ad altri moduli di query. Le dimensioni e la complessità dell'indice possono determinare se i vantaggi sono sufficienti per compensare la latenza della risposta.

Nota

Poiché la ricerca fuzzy tende a essere lenta, potrebbe essere utile esaminare alternative come l'indicizzazione n-gramma, con la sua progressione di sequenze di caratteri brevi (due e tre sequenze di caratteri per token bigramma e trigramma). A seconda del linguaggio e della superficie di query, n-gramma potrebbe offrire prestazioni migliori. Il compromesso è che l'indicizzazione n-gramma è molto intensivo di archiviazione e genera indici molto più grandi.

Un'altra alternativa, che è possibile considerare se si vuole gestire solo i casi più egregio, sarebbe una mappa di sinonimi. Ad esempio, il mapping di "search" a "serach, serch, sarch" o "retrieve" in "retreive".

I campi stringa attribuiti come "ricercabili" sono candidati per la ricerca fuzzy.

Gli analizzatori non vengono usati per creare un grafico di espansione, ma ciò non significa che devono essere ignorati in scenari di ricerca fuzzy. Gli analizzatori sono importanti per la tokenizzazione durante l'indicizzazione, in cui i token negli indici invertiti vengono usati per la corrispondenza con il grafico.

Come sempre, se le query di test non producono le corrispondenze previste, sperimentare con analizzatori di indicizzazione diversi. Ad esempio, provare un analizzatore del linguaggio per verificare se si ottengono risultati migliori. Alcuni linguaggi, in particolare quelli con mutazioni vocaliche, possono trarre vantaggio dalle forme flesse e dalle forme irregolari delle parole generate dai processori del linguaggio naturale Microsoft. In alcuni casi, l'uso dell'analizzatore del linguaggio corretto può fare la differenza se un termine viene tokenizzato in modo compatibile con il valore fornito dall'utente.

Le query fuzzy vengono costruite usando la sintassi di query Lucene completa, richiamando il parser di query Lucene completo e aggiungendo un carattere tilde ~ dopo ogni termine intero immesso dall'utente.

Di seguito è riportato un esempio di richiesta di query che richiama la ricerca fuzzy. Include quattro termini, due dei quali sono digitati in modo non corretto:

POST https://[service name].search.windows.net/indexes/hotels-sample-index/docs/search?api-version=2024-07-01
{
    "search": "seatle~ waterfront~ view~ hotle~",
    "queryType": "full",
    "searchMode": "any",
    "searchFields": "HotelName, Description",
    "select": "HotelName, Description, Address/City,",
    "count": "true"
}

  1. Impostare il tipo di query sulla sintassi Lucene completa (queryType=full).

  2. Specificare la stringa di query in cui ogni termine è seguito da un operatore tilde (~) alla fine di ogni termine intero (search=<string>~). Viene creato un grafico di espansione per ogni termine nell'input della query.

    Includere un parametro facoltativo, un numero compreso tra 0 e 2 (impostazione predefinita), se si desidera specificare la distanza di modifica (~1). Ad esempio, "blue~" o "blue~1" restituirà "blue", "blues" e "glue".

Facoltativamente, è possibile migliorare le prestazioni delle query definendo l'ambito della richiesta a campi specifici. Usare il parametro searchFields per specificare i campi da cercare. È anche possibile usare la select proprietà per specificare i campi restituiti nella risposta alla query.

Per eseguire test semplici, è consigliabile esplora ricerche o un client REST per eseguire l'iterazione su un'espressione di query. Entrambi gli strumenti sono interattivi, il che significa che è possibile eseguire rapidamente più varianti di un termine e valutare le risposte che tornano.

Quando i risultati sono ambigui, l'evidenziazione dei risultati consente di identificare la corrispondenza nella risposta.

Nota

L'uso dell'evidenziazione dei risultati per identificare le corrispondenze fuzzy presenta limitazioni e funziona solo per la ricerca fuzzy di base. Se l'indice ha profili di punteggio o se si esegue il layer della query con una maggiore sintassi, l'evidenziazione dei risultati potrebbe non riuscire a identificare la corrispondenza.

Esempio 1: ricerca fuzzy con il termine esatto

Si supponga che la stringa seguente esista in un campo "Description" di un documento di ricerca: "Test queries with special characters, plus strings for MSFT, SQL and Java."

Iniziare con una ricerca fuzzy per "speciale" e aggiungere l'evidenziazione dei risultati al campo Descrizione:

search=special~&highlight=Description

Nella risposta, poiché è stata aggiunta l'evidenziazione dei risultati, la formattazione viene applicata a "speciale" come termine corrispondente.

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]
}

Riprovare la richiesta, digitando "speciale" in modo sbagliato ("pe"):

search=scial~&highlight=Description

Finora, nessuna modifica alla risposta. Dato il valore predefinito di 2 gradi di distanza, la rimozione di due caratteri "pe" da "speciale" consente comunque una corrispondenza con esito positivo su tale termine.

"@search.highlights": {
    "Description": [
        "Test queries with <em>special</em> characters, plus strings for MSFT, SQL and Java."
    ]
}

Provando un'altra richiesta, modificare ulteriormente il termine di ricerca rimuovendo un ultimo carattere per un totale di tre eliminazioni (da "speciale" a "scal"):

search=scal~&highlight=Description

Si noti che viene restituita la stessa risposta, ma ora anziché la corrispondenza per "speciale", la corrispondenza fuzzy è per "SQL".

"@search.score": 0.4232868,
"@search.highlights": {
    "Description": [
        "Mix of special characters, plus strings for MSFT, <em>SQL</em>, 2019, Linux, Java."
    ]
}

Il punto di questo esempio espanso consiste nell'illustrare la chiarezza che l'evidenziazione dei risultati può portare a risultati ambigui. In tutti i casi, viene restituito lo stesso documento. Se si è basato sugli ID documento per verificare una corrispondenza, è possibile che si sia perso il passaggio da "speciale" a "SQL".

Vedi anche