Búsqueda aproximada para corregir errores ortográficos y tipográficos

  • Artículo

Azure AI Search admite la búsqueda aproximada, un tipo de consulta que compensa los errores tipográficos y los términos mal escritos en la cadena de entrada. La búsqueda aproximada examina los términos que tienen una composición similar. La expansión de la búsqueda para que incluya coincidencias aproximadas tiene el efecto de corregir automáticamente un error tipográfico si la discrepancia se limita solo a algunos caracteres mal colocados.

Las búsquedas aproximadas son ejercicios de expansión de consultas que generan coincidencias entre términos que presentan una composición similar. Cuando se especifica una búsqueda aproximada, el motor de búsqueda genera, para cada uno de los términos completos incluidos en la consulta, un grafo (basado en la teoría del autómata finito determinista) de términos compuestos de forma similar a estos. Por ejemplo, si la consulta incluye tres términos "university of washington", se crea un grafo para cada término de la consulta search=university~ of~ washington~ (en las búsquedas aproximadas no se eliminan las palabras no significativas, así que "of" obtiene un grafo).

El grafo consta de hasta 50 expansiones, o permutaciones, de cada término, que capturan las variantes correctas e incorrectas en el proceso. A continuación, el motor devuelve las coincidencias más significativas en la respuesta.

Para un término como "university", es posible que el grafo tenga "unversty, universty, university, universe, inverse". Los documentos que coinciden con los del grafo se incluirán en los resultados. A diferencia de otras consultas que analizan el texto para controlar diferentes formas de la misma palabra ("mice" y "mouse"), las comparaciones de una consulta aproximada se toman al pie de la letra sin ningún análisis lingüístico del texto. "Universo" e "inverso", que son semánticamente diferentes, coincidirán porque las discrepancias sintácticas son pequeñas.

Una coincidencia se realiza correctamente si las discrepancias se limitan a dos o menos ediciones. Una edición es un carácter insertado, eliminado, sustituido o transpuesto. El algoritmo de corrección de cadenas que especifica el factor diferencial es la métrica de distancia de Damerau-Levenshtein. Este algoritmo puede describirse como el "número mínimo de operaciones (inserciones, eliminaciones, sustituciones o transposiciones de dos caracteres adyacentes) que se requieren para cambiar a una palabra por la otra".

En Azure AI Search:

  • La consulta aproximada se aplica a términos completos. Las frases no se admiten directamente, pero puede especificar una coincidencia aproximada en cada término de una frase de varias partes mediante construcciones AND. Por ejemplo, search=dr~ AND cleanin~. Esta expresión de consulta busca coincidencias en "dry cleaning".

  • La distancia predeterminada de una edición es 2. Un valor de ~0 significa que no hay ninguna expansión (solo el término exacto se considera una coincidencia), pero puede especificar ~1 para un grado de diferencia o una edición.

  • En una consulta aproximada, es posible expandir un término hasta un máximo de 50 permutaciones. Aunque este límite no se puede configurar, sí que se puede reducir el número de expansiones de forma eficaz si se reduce el valor de la distancia de edición a 1.

  • Las respuestas se componen de documentos que contienen una coincidencia pertinente (con un máximo de 50).

Durante el procesamiento de consultas, las consultas aproximadas no se someten a un análisis léxico. La entrada de la consulta se agrega directamente al árbol de consultas y se expande para crear un grafo de términos. La única transformación realizada es la conversión a minúsculas.

Colectivamente, los grafos se envían como criterios de coincidencia en los tokens del índice. Como puede imaginar, la búsqueda aproximada es intrínsecamente más lenta que otros formularios de consulta. El tamaño y la complejidad del índice pueden determinar si las ventajas son suficientes para compensar la latencia de la respuesta.

Nota:

Dado que la búsqueda aproximada tiende a ser lenta, puede que merezca la pena investigar alternativas como la indexación de n-gramas, con su progresión de secuencias cortas de caracteres (dos y tres secuencias de caracteres para los tokens bigrama y trigrama). En función del lenguaje y la superficie de la consulta, la opción con n-gramas podría proporcionarle un mejor rendimiento. La desventaja es que la indexación de n-gramas tiene un uso intensivo del almacenamiento y genera índices mucho mayores.

Otra alternativa, que podría tener en cuenta si desea administrar solo los casos más notorios, sería un mapa de sinónimos. Por ejemplo, asigne "búsqueda" a "búsquerda, búsquda, bsqueda" o "recuperar" a "reucperar".

Los campos de cadena que tengan el atributo "searchable" son candidatos para la búsqueda aproximada.

Aunque los analizadores no se usan para crear grafos de expansión, esto no quiere decir que deban omitirse en los escenarios de búsqueda aproximada. Los analizadores son elementos importantes de cara al proceso de tokenización que ocurre durante la indexación, en el que los tokens de los índices invertidos se usan para buscar coincidencias con los grafos.

Como siempre, si las consultas de prueba no generan coincidencias esperadas, pruebe con diferentes analizadores de indexación. Por ejemplo, pruebe un analizador de lenguaje para ver si obtiene mejores resultados. Algunos idiomas, especialmente los que tienen mutaciones vocálicas, pueden beneficiarse de las formas declinadas y de palabras irregulares generadas por los procesadores de lenguaje natural de Microsoft. En algunos casos, el uso del analizador de idioma adecuado puede suponer una diferencia entre si un término se tokeniza de forma que sea compatible con el valor proporcionado por el usuario.

Para construir las consultas aproximadas se usa la sintaxis de consulta completa de Lucene, se invoca el analizador de consultas de Lucene completo y se anexa un carácter de tilde ~ después de cada término entero que especifique el usuario.

Este es un ejemplo de una solicitud de consulta que invoca la búsqueda aproximada. Incluye cuatro términos, dos de los cuales están mal escritos:

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. Establezca la sintaxis completa de Lucene como el valor del tipo de consulta (queryType=full).

  2. Especifique la cadena de consulta en la que cada término va seguido de un operador tilde (~) al final de cada término entero (search=<string>~). A continuación, se crea un grafo de expansión para cada término que se haya incluido en la entrada de consulta.

    Incluya un parámetro opcional, un número entre 0 y 2 (valor predeterminado), si desea especificar la distancia de edición (~1). Por ejemplo, "blue~" o "blue~1" devolvería "blue", "blues" y "glue".

Si lo desea, puede mejorar el rendimiento de las consultas. Para ello, debe establecer el ámbito de la solicitud a campos concretos. Use el parámetro searchFields para especificar los campos que se van a buscar. También puede usar la propiedad select para especificar qué campos se devuelven en la respuesta de la consulta.

Para realizar pruebas sencillas, se recomienda el Explorador de búsqueda o cliente REST para recorrer en iteración una expresión de consulta. Ambas herramientas son interactivas, lo que significa que puede recorrer rápidamente varias variantes de un término y evaluar las respuestas que se devuelven.

Cuando los resultados son ambiguos, el resaltado de referencias puede ayudarle a identificar la coincidencia en la respuesta.

Nota:

El uso del resaltado de referencias para identificar coincidencias aproximadas tiene limitaciones y solo funciona para la búsqueda aproximada básica. Si el índice usa perfiles de puntuación, o si formula la consulta por niveles mediante sintaxis adicional, es posible que el resaltado de referencias no logre identificar la coincidencia.

Ejemplo 1: búsqueda aproximada con el término exacto

Suponga que existe la siguiente cadena en un campo "Description" de un documento de búsqueda: "Test queries with special characters, plus strings for MSFT, SQL and Java."

Comience con una búsqueda aproximada de "especial" y agregue el resaltado de referencias al campo de descripción:

search=special~&highlight=Description

En la respuesta, como ha agregado el resaltado de referencias, el formato se aplica a "especial" como término coincidente.

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

Vuelva a intentar la solicitud, escribiendo incorrectamente "special" quitando varias letras ("pe"):

search=scial~&highlight=Description

Hasta el momento, no hay ningún cambio en la respuesta. Si se usa el valor predeterminado de 2 grados de distancia, la eliminación de dos caracteres "pe" de "special" sigue permitiendo una coincidencia correcta en ese término.

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

Vuelta a intentar otra solicitud, modificando aún más el término de búsqueda quitando un último carácter hasta un total de tres eliminaciones (de "special" a "scal"):

search=scal~&highlight=Description

Observe que se devuelve la misma respuesta, pero ahora, en lugar de buscar coincidencias de "especial", la coincidencia aproximada es para "SQL".

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

El objetivo de este ejemplo expandido es ilustrar la claridad que el resaltado de referencias puede aportar a resultados ambiguos. En todos los casos, se devuelve el mismo documento. Si hubiera confiado en los identificadores de documento para comprobar una coincidencia, podría haberse perdido el cambio de "especial" a "SQL".

Consulte también