soporte Contactar con Soporte | Estadoestado del sistema del sistema
Contenido de la página

    Arquitectura de búsqueda

    En este tema, aprenderá acerca de la arquitectura de la tecnología de búsqueda de catálogo utilizada tanto para CMS como para las API de reproducción.

    Resumen

    A partir de abril de 2019, la funcionalidad de búsqueda en catálogo se actualizó a Elasticsearch. Esta actualización proporciona una serie de beneficios, entre los que destacan la mejora de la relevancia y precisión, y el rendimiento considerablemente mejorado: el tiempo de respuesta es mucho más consistente y, por lo general, el doble de rápido. Esta nueva funcionalidad afectará a la API de CMS, a la API de reproducción, a la búsqueda interactiva de Studio y a los métodos de búsqueda del catálogo.

    Aunque Brightcove ha invertido una cantidad sustancial de esfuerzo en lograr que los resultados de Elasticsearch sean coherentes, existen diferencias, y hay algunas pequeñas posibilidades de que si ha codificado dependencias específicas de los resultados de búsqueda, su integración no se comporte como se esperaba.

    Diferencias e impacto en los resultados de búsqueda

    Al estudiar el impacto potencial, Brightcove ha descubierto que más del 90% de las búsquedas devuelven resultados que coinciden con el número de resultados devueltos. Este es un indicador de que los resultados esperados no deberían ser lo suficientemente diferentes como para causar problemas con las integraciones de API.

    comparación

    Este gráfico muestra el número de resultados de búsqueda que coinciden exactamente con el número de resultados entre los dos sistemas en azul, y los que difieren en número en rojo.

    Como parte de nuestro despliegue, todas las búsquedas predeterminadas, aquellas búsquedas en la cadena vacía, ya han sido proporcionadas por Elasticsearch desde hace varios meses, por lo que los usuarios ya están viendo y utilizando los resultados de Elasticsearch sin problemas.

    Sin embargo, hay limitaciones a lo que podemos aprender de este tipo de comparación. En el mejor de los casos, solo podemos inferir la intención de una búsqueda en particular, y los datos del catálogo son fluidos.

    Diferencias conocidas

    Las diferencias a continuación son en gran medida fundamentales, o el resultado de las decisiones adoptadas después de un amplio análisis de los resultados de la búsqueda — son imposibles de eliminar por completo.

    Staming

    El tallo es el proceso de reducir las palabras inflexionadas (o a veces derivadas) a su raíz de palabras, base o forma raíz — generalmente una forma de palabra escrita.

    Un stemmer para Inglés que opera en el gato tallo debe identificar tales cuerdas como gatos , catlike y catty. Un algoritmo de derivación también podría reducir las palabras pescar , pescado y pescador al tallo pez. El tallo no tiene por qué ser una palabra, por ejemplo, el algoritmo Porter reduce argumentar, argumentar, argumentar, argumentar y argus al argu tallo.

    Nuestra búsqueda existente utiliza el stemmer Lancaster (Paice/cáscara), este algoritmo generalmente se considera demasiado agresivo — esto resulta en una falta de distinción, por ejemplo, más ligero y ligero se consideraría como el mismo término bajo Lancaster.

    Elasticsearch utiliza un algoritmo más reciente y mucho menos agresivo (Porter2) que ha ganado una amplia adopción en la industria y generalmente se considera una mejora significativa (Lancaster es ahora raro). El cambio de stemmer potencialmente impacta una proporción significativa (~ 35%) de búsquedas: eso no quiere decir que los resultados sean diferentes, solo que puedan ser diferentes, pero en general esto debería ser para mejor: dicho esto, algún subconjunto de clientes puede depender del comportamiento anterior.

    Relevancia

    Nuestra búsqueda existente parece tener una normalización de TF más estricta. Esto provoca una clasificación de relevancia diferente para términos que se encuentran en campos más grandes (es decir, existente considera que la coincidencia es menos relevante ya que da menos peso al término, ya que es más pequeño en relación con la longitud del documento).

    Caracteres Especiales

    Los caracteres especiales se eliminan dentro de nuestra búsqueda existente, esto equivale más o menos a quitar signos de puntuación y caracteres relacionados — en lugar de eliminarlos, generalmente los escapamos en Elasticsearch, por lo que existe la posibilidad de que una búsqueda los tenga en cuenta.

    Manejo de términos

    Las consultas de búsqueda existentes realizan `suavizado de terminos` mientras que en Elasticsearch soltamos términos mal formados, considere esta búsqueda con un término vacío:tags:q=tags: state:ACTIVE

    • Existente: — busca vídeos con una etiquetatags:state:ACTIVEstate:ACTIVE
    • Elasticsearch: state:ACTIVE— suelta el término vacío

    Hay una serie de casos de borde sutiles relacionados con el manejo de puntuaciones colgantes y consultas que generalmente están mal formadas, intentamos producir lo que pensamos que la consulta estaba destinada a ser, pero en estos casos lamentablemente estamos adivinando lo que un usuario podría haber intentado (cuando realmente deberíamos haber devuelto un error permitiéndoles refinar su búsqueda)

    Sólo jugable

    Existen dos mecanismos para restringir una búsqueda a vídeos que se pueden reproducir actualmente: la consulta puede incluir un indicador, o la propia consulta puede requerir algún aspecto de la jugabilidad.

    • Existente: se consulta en función del valor de un campo que se actualiza
    • Elasticsearch: esto se consulta en función de rangos de fechas calculados

    Elasticsearch debería ser generalmente más preciso y producir mejores resultados (hay un retraso asociado con el mecanismo existente, y el mecanismo de mantenimiento de la bandera no es del todo confiable).

    Precisión del índice

    El índice de Elasticsearch es 'más fresco' que el índice existente y tiende a reflejar las actualizaciones más rápido; este no siempre es el caso, pero en general la experiencia con Elasticsearch es que los resultados reflejarán con mayor precisión el estado de los datos del catálogo subyacentes. Tanto los existentes como Elasticsearch son sistemas distribuidos y, por lo tanto, no del todo consistentes en los resultados que devuelven: una consulta repetida contra cualquiera de los sistemas puede potencialmente devolver resultados diferentes (especialmente en el caso de que haya una serie de operaciones de eliminación en ejecución simultánea).

    Los resultados de búsqueda existentes cambian en función del estado del fragmento al que se asigna una cuenta: el estado global de un fragmento en particular puede (y lo hace) afectar a los resultados de una consulta en particular: Elasticsearch no tiene esta deficiencia.

    Ejemplos

    Ejemplo 1

    Supongamos que hay dos videos con los siguientes títulos:

          Video#1: has the title “Don’t look into the light”
          Video#2: has the title “Using a lighter to make a campfire”

    El usuario desea devolver todos los vídeos que deben tener la palabra «luz». Usando la API de CMS, la consulta tendría el siguiente aspecto:

          q=%2Blight or q=+light

    Con la búsqueda existente, esto devolverá los dos vídeos en el orden:

          Video#2 - “Using a lighter to make a campfire”
          Video#1 - “Don’t look into the light”

    Hay dos problemas con esto:

    • Relevancia: El pedido es incorrecto. «No mires a la luz» (Video #2) debería aparecer antes de «Usar un encendedor para hacer una fogata» (Video #1)
    • Precisión: «Usar un encendedor para hacer una fogata» ni siquiera debería aparecer en el conjunto de resultados, ya que la palabra «luz» no aparece en absoluto en el título del vídeo.

    Con Elasticsearch, esto solo devolverá el vídeo uno:

          Video#1 - “Don’t look into the light”

    Esto es una mejora porque:

    • Relevancia: La orden es correcta.
    • Precisión: Sólo vídeo uno se devuelve ya que es el único vídeo con la palabra «luz» en el título.

    Ejemplo 2

    Como se describe en nuestra documentación de la API de CMS para la derivación, se admite el stemming, pero no las búsquedas parciales de palabras. Así que digamos que hay 5 videos con los siguientes títulos:

          Video#1 - "Parking Ban Announced"
          Video#2 - "Parking to be Banned"
          Video#3 - "City Banning Parking"
          Video#4 - "Bank Holiday"
          Video#5 - "Bandit Captured"

    El usuario desea devolver todos los vídeos que deben tener la palabra prohibición en el campo nombre. Usando la API de CMS, la consulta tendría el siguiente aspecto:

          q=%2Bname%3Aban or q=+name:ban

    La expectativa es que «Ban», «Banning» y «Prohibido» producirían resultados de búsqueda, ya que «Ban» es un vástago de los tres.

    Sin embargo, con el sistema de búsqueda actual, esto devolverá los cinco vídeos en este orden:

          Video#2 - "Parking to be Banned"
          Video#3 - "City Banning Parking"
          Video#1 - "Parking Ban Announced"
          Video#4 - "Bank Holiday"
          Video#5 - "Bandit Captured"

    Nuevamente, hay dos problemas con esto:

    • Relevancia: El pedido es incorrecto. «Estacionamiento Ban Anunciado» debe ser el primer video devuelto ya que tiene la palabra «Ban» en él.
    • Precisión: «Bandit Holiday» y «Bandit Capturado» no deben devolverse en absoluto, ya que «Ban» no es parte de la palabra «Banco» o «Bandido».

    Con Elasticsearch, los resultados se ven así:

          Video#1 - "Parking Ban Announced"
          Video#2 - "Parking to be Banned"
          Video#3 - "City Banning Parking"

    Esto es una mejora porque:

    • Relevancia: La orden es correcta.
    • Precisión: Solo se devuelven vídeos con los tallos de la palabra «Ban» («Ban», «Banning» y «Prohibido»).

    Última actualización de la página el 29-09-2020