Uso de Bing Spell Check API
Advertencia
El 30 de octubre de 2020, las API de Bing Search se trasladaron de los servicios de Azure AI a los servicios de Bing Search. Esta documentación se proporciona solo como referencia. Para obtener documentación actualizada, consulte la documentación de Bing Search API. Para obtener instrucciones sobre cómo crear nuevos recursos de Azure para Bing Search, consulte el artículo sobre la creación de un recurso de Bing Search a través de Azure Marketplace.
En este artículo puede aprender sobre el uso de Bing Spell Check API para realizar la revisión ortográfica y gramatical contextual. Aunque la mayoría de los correctores ortográficos dependen de conjuntos de reglas basadas en diccionario, el corrector ortográfico de Bing aprovecha el aprendizaje automático y la traducción automática estadística para proporcionar correcciones precisas y contextuales.
Modos de comprobación ortográfica
La API admite dos modos de corrección, Proof y Spell. Vea los ejemplos aquí.
Proof: para documentos
El modo predeterminado es Proof. El modo de corrección ortográfica Proof es el que proporciona las comprobaciones más completas, agrega el uso de mayúsculas, la puntuación básica y otras características para facilitar la creación de documentos. Pero está disponible solo en los mercados de en-US (inglés de Estados Unidos), es-ES (español) y pt-BR (portugués) (Nota: en el caso de español y portugués solo en versión beta). Para los restantes mercados, establezca el parámetro de consulta de modo en Ortografía.
Nota:
Si el texto de la consulta tiene más de 4096 caracteres, se truncará a 4096 y luego se procesará.
Spell: para consultas y búsquedas web
Spell es más agresivo para devolver mejores resultados de búsqueda. El modo Spell busca la mayoría de los errores ortográficos, pero no encuentra algunos de los errores gramaticales que Proof detecta, por ejemplo, las palabras repetidas o los errores de mayúsculas y minúsculas.
Nota:
- La longitud máxima de consulta admitida es inferior. Si la consulta supera la longitud máxima, ni la consulta ni sus resultados se modificarán.
- 130 caracteres para los códigos de idioma siguientes: en, de, es, fr, pl, pt, sv, ru, nl, nb, tr-tr, it, zh y ko.
- 65 caracteres para los demás.
- El modo de corrección ortográfica no admite caracteres de corchetes (
[y]) en las consultas y puede causar resultados incoherentes. Se recomienda eliminarlos de las consultas cuando se usa el modo de corrección ortográfica.
Configuración del mercado
Un código de mercado se debe especificar con el parámetro de consulta mkt en la solicitud. De lo contrario, la API usará un mercado predeterminado en función de la dirección IP de la solicitud.
Compatibilidad con HTTP POST y GET
La API admite de HTTP POST o HTTP GET. Lo que se usa depende de la longitud del texto que se va a revisar. Si todas las cadenas tienen menos de 1500 caracteres, usaría una operación GET. Pero si desea admitir cadenas de hasta 10 000 caracteres, usaría POST. La cadena de texto puede incluir cualquier carácter UTF-8 válido.
El ejemplo siguiente muestra una solicitud POST para comprobar la ortografía y la gramática de una cadena de texto. El ejemplo incluye el parámetro de consulta mode por razones de integridad (se podría se han omitido, ya que el valor predeterminado de mode es Proof). El parámetro de consulta text contiene la cadena que deben revisar.
POST https://api.cognitive.microsoft.com/bing/v7.0/spellcheck?mode=proof&mkt=en-us HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 47
Ocp-Apim-Subscription-Key: 123456789ABCDE
X-MSEdge-ClientIP: 999.999.999.999
X-Search-Location: lat:47.60357;long:-122.3295;re:100
X-MSEdge-ClientID: <blobFromPriorResponseGoesHere>
Host: api.cognitive.microsoft.com
text=when+its+your+turn+turn,+john,+come+runing
Si utiliza HTTP GET, incluiría el parámetro de consulta text en la cadena de consulta de la dirección URL
A continuación se muestra la respuesta a la solicitud anterior. La respuesta contiene un objeto SpellCheck.
{
"_type" : "SpellCheck",
"flaggedTokens" : [{
"offset" : 5,
"token" : "its",
"type" : "UnknownToken",
"suggestions" : [{
"suggestion" : "it's",
"score" : 1
}]
},
{
"offset" : 25,
"token" : "john",
"type" : "UnknownToken",
"suggestions" : [{
"suggestion" : "John",
"score" : 1
}]
},
{
"offset" : 19,
"token" : "turn",
"type" : "RepeatedToken",
"suggestions" : [{
"suggestion" : "",
"score" : 1
}]
},
{
"offset" : 35,
"token" : "runing",
"type" : "UnknownToken",
"suggestions" : [{
"suggestion" : "running",
"score" : 1
}]
}]
}
El campo flaggedTokens enumera los errores de ortografía y gramática que la API encontró en la cadena text. El campo token contiene la palabra que se va a reemplazar. Usaría el desplazamiento de base cero en el campo offset para buscar el token en la cadena text. Luego, reemplazaría la palabra de dicha ubicación por la palabra del campo suggestion.
Si el campo type es RepeatedToken, puede reemplazar el token por suggestion, pero es probable que también necesite quitar el espacio final.
Solicitudes de limitación
El servicio y el tipo de suscripción determinan el número de consultas que puede realizar por segundo (QPS). Asegúrese de que la aplicación incluye la lógica necesaria para mantenerse dentro de su cuota. Si se alcanza el límite de consultas por segundo, o se supera, se produce un error en la solicitud y se devolverá el código de estado HTTP 429. La respuesta incluye el encabezado Retry-After, que indica cuánto tiempo debe esperar antes de enviar otra solicitud.
Denegación de servicio frente a Limitación
El servicio diferencia entre un ataque de denegación de servicio (DoS) y una infracción de las consultas por segundo. Si el servicio sospecha de un ataque de denegación de servicio, la solicitud se realiza correctamente (código de estado HTTP 200 OK). Sin embargo, el cuerpo de la respuesta está vacío.