Refinamientos en la búsqueda que se están probando en meta

[sam (Sam Saffron)]

Recientemente, debido a comentarios internos, decidimos priorizar una ronda de mejoras en nuestro algoritmo de búsqueda.

Estos cambios ahora se han implementado en todos los sitios como parte de Discourse 3.1.0.beta3. Después de actualizar, su sitio comenzará automáticamente a reindexar todo su contenido para la búsqueda.

Hay dos nuevas configuraciones de sitio como parte de esto, pero se han establecido en valores que hemos encontrado que funcionan bien en nuestras pruebas aquí en meta, por lo que no esperamos que la mayoría de los sitios tengan ninguna razón para cambiarlas.

Priorizar la coincidencia de término completo en el título sobre la coincidencia parcial

Discourse realiza un stem + coincidencia de prefijo al buscar. Esto a veces puede llevar a resultados muy sorprendentes.

Por ejemplo: redis se deriva a redi, por lo que una búsqueda de redis puede encontrar todas las palabras que comienzan con redi, como redirect y más.

Se agregó una nueva configuración de sitio oculta: prioritize_exact_search_title_match, que ahora está habilitada por defecto.

Antes:

Después:

Esto significa que si recuerdas el título y lo escribes, es mucho más probable que encuentres el título.

Reducción de la duplicación máxima del índice

Nuestro algoritmo de clasificación clasifica las publicaciones que tienen múltiples coincidencias con un término más alto que las publicaciones que solo contienen el término una vez. Esto significa que puedes “hacer trampa” en la búsqueda simplemente repitiendo una palabra muchas veces. Cuanto más escribas la palabra, más alto flotará en la parte superior de la búsqueda.

Se agregó una nueva configuración de sitio oculta SiteSetting.max_duplicate_search_index_terms, que por defecto es 6.

Una vez que esto se aplique, significa que si escribes sam, 6 veces o 60 veces en una publicación, seguirá clasificándose igual. Pone un límite a la bonificación que puedes dar a los resultados.

Este cambio también tiene un impacto positivo en el rendimiento, dado que el índice de búsqueda se vuelve un poco más pequeño.

Correcciones de errores varios

Parte del trabajo consistió en examinar casos de búsqueda patológicos.

• Anteriormente, reducíamos la prioridad de los temas cerrados, pero olvidamos los temas archivados. Esto ahora está corregido.

• Anteriormente, dependíamos demasiado de las coincidencias de prefijo para las búsquedas de “dominio”. Lo que significa que la palabra happy no encontraría https://happy.com ya que happy se deriva a happi y la coincidencia de prefijo falla. Esto fue corregido.

Trabajo futuro

• Planeamos experimentar con la búsqueda “difusa” para la autocompletación de menciones. (permitir omitir una letra, por ejemplo)

• Planeamos investigar la despriorización de términos duplicados en los títulos. Actualmente, el tema cerrado hola adiós hola se clasifica más alto que el tema abierto hola mundo

• PageRank… actualmente no tomamos en cuenta el número de enlaces entrantes e internos al clasificar los resultados. Esto significa que a veces temas increíblemente bien enlazados pueden clasificarse más bajo que un tema raro que no está enlazado desde ningún lado. Sería bueno tener esto en cuenta en nuestro algoritmo de clasificación.

• Tenemos una iniciativa abierta que investiga las integraciones de IA, es posible que podamos obtener inspiración de herramientas similares a GPT.

¿Qué puedes hacer para ayudar?

¿Estás notando algún mal resultado en meta? Si es así, por favor incluye el término que buscaste explicando por qué los resultados son deficientes.

¿Cómo te parecen los cambios (neutral/mejor/peor)?

[Jagster (Jakke Lehtonen)]

Solo para estar seguro… Si actualizo/mejora mi configuración, ¿encontraré esas dos configuraciones? Sé cómo encontrar las ocultas, eso no es un problema, pero ¿son solo de Meta en este momento? Para mí es más fácil probarlo en mis círculos que aquí

[sam (Sam Saffron)]

Sí, pero también necesitas ejecutar rake search:reindex

[volanar]

¿Has pensado en mejorar la búsqueda usando meilisearch? Esto requiere muy pocos recursos y se puede incluir en la compilación de docker.

[Falco]

@Tris20

Lo único que me gustaría ver un poco mejorado son los errores ortográficos comunes. Algunos motores de búsqueda me han malacostumbrado hasta el punto de que golpeo perezosamente las teclas hasta que una mezcla de letras que solo se parecen vagamente a la palabra original está en la barra de búsqueda . No espero que se iguale eso, pero las mejoras en esa área serían un gran paso adelante.

Hemos comenzado experimentos en esta área por

@sam

Planeamos experimentar con la búsqueda “difusa” para la autocompletación de menciones. (permitirte omitir una letra, por ejemplo)

Los primeros experimentos se limitan a la búsqueda de usuarios/grupos, pero si todo va bien, se puede ampliar aún más.

[sam (Sam Saffron)]

@volanar

¿Has pensado en mejorar la búsqueda usando meilisearch?

Hemos considerado varias integraciones, incluidas sphinx, melli, elastic, solr/lucene, pero tienen un costo. Alojar otro proceso para ejecutar la indexación, arriesgarse a tener índices desactualizados, la complejidad… etc., nada de eso es gratis.

Me gustaría ver cuántos resultados obtenemos de PG antes de explorar otras opciones y mantenerlas como último recurso.

@loginerror

Pregunta rápida sobre lo anterior. ¿Qué pasa con los temas cerrados automáticamente con una solución?

Problema muy interesante, sí, están (y siempre han estado) despriorizados. Creo que como mínimo podemos considerar agregar una configuración del sitio a discourse-solved para permitir a los administradores decidir qué hacer en estos casos (priorizar/despriorizar/neutral, etc.).

[volanar]

@sam

Me gustaría ver cuánta distancia obtenemos de PG antes de explorar cualquier otra opción y mantenerlos como último recurso.

Desafortunadamente, postgres no está adaptado como motor de búsqueda. Y meilisearch tiene un consumo de memoria fantásticamente bajo y posibilidades de búsqueda ilimitadas. La sobrecarga para el servidor en comparación con ruby será simplemente invisible.

[sam (Sam Saffron)]

@volanar

La sobrecarga del servidor en comparación con Ruby será simplemente invisible.

Este no es un problema trivial. Nuestra búsqueda contiene una enorme cantidad de dimensiones y tiene muchos parámetros, se une directamente a las tablas de postgres.

Con un proveedor de búsqueda externo, debemos preocuparnos por la “sincronización”.

• Un tema se cierra en Discourse → notificar al motor
• Se elimina una publicación → notificar al motor
• Se da un “me gusta” → notificar al motor
• Un tema se divide o se fusiona → notificar al motor

La lista continúa, incluida la creación de múltiples índices (usuarios/publicaciones/temas/categorías)

Dicho esto, dada la inversión adecuada, esto no es necesariamente insuperable, pero es una tarea enorme y no hay una prueba de concepto que muestre cuán mejor sería. Es bueno que melli tenga un clasificador de errores tipográficos y muchas otras características, no hay discusión al respecto. Pero integrarlo no es gratis en absoluto.

Como estimación aproximada, creo que hay alrededor de 3 meses de trabajo para construir una integración sólida y robusta en mellisearch. Quizás incluso 6 meses si diseñáramos Discourse de tal manera que el motor de búsqueda sea “enchufable”.

Tenga en cuenta que sí admitimos la integración de Algolia aquí: https://discourse.algolia.com/ no es exactamente sólido como una roca, y puede ver que toda la búsqueda avanzada se omite de la implementación.

[volanar]

@sam

Como una estimación aproximada, pensaría que hay alrededor de 3 meses de trabajo para construir una integración sólida y robusta en mellisearch. Quizás incluso 6 meses si diseñáramos Discourse de tal manera que el motor de búsqueda sea “enchufable”.

Apuesto a que con una comunidad tan grande de discursos como discourse, puede ser mucho más rápido, no más de tres meses.

[Jagster (Jakke Lehtonen)]

Después de un tiempo, pregunté qué pensaban mis usuarios más activos (pensaron ) sobre la búsqueda; nunca dije que tuviera algunos esteroides.

Todos dijeron exactamente lo mismo; no lo habían pensado, pero como pregunté, se dieron cuenta de que ahora encontraban resultados relevantes mucho más fácilmente, en la mayoría de los casos de inmediato.

Una parte de Discourse actúa como sistema de comentarios de WordPress. No, no recibo más comentarios (nada está tan sobrevalorado como los comentarios de blogs), pero ha mostrado la existencia (¿se escribe así?) del foro. Hoy en día tengo un puñado de usuarios que usan Discourse como motor de búsqueda. No comentan, pero buscan lo que buscan en WordPress a través de los temas de Discourse y vuelven al blog. Claro, el sistema de etiquetas también ayuda mucho. Y a WordPress le faltan ambas cosas: búsqueda efectiva y etiquetado funcional.

No sé si debería publicar esto en Praise, pero solo quería decir que estoy bastante satisfecho con cómo funciona esta nueva y mejorada búsqueda.

[sam (Sam Saffron)]

@Jagster

Todos dijeron exactamente lo mismo; no lo habían pensado pero como pregunté se dan cuenta de que ahora encuentran resultados relevantes mucho más fácil, en la mayoría de los casos de inmediato.

¡Vaya, gracias, esto ciertamente me hace sentir muy bien! Tenemos una solicitud de extracción en proceso y deberíamos implementar los cambios a nivel mundial muy pronto.

[mattdm (Matthew Miller)]

@sam

Tenemos una PR en proceso y deberíamos implementar los cambios a nivel mundial muy pronto.

Disculpen si soy obtuso: ¿debería esto estar activo en sitios alojados (con el último despliegue)? El anuncio de lanzamiento apunta aquí, pero esto habla de una configuración oculta. ¿Está activada esa configuración oculta?

[mcwumbly (Dave McClure)]

No necesitas hacer nada:

@sam

@mcdanlj

parece que prioritize_exact_search_title_match todavía está oculto. ¿Es algo que deberíamos esperar usar? ¿Se supone que debemos ejecutar rake search:reindex después de desplegar como veo en este comentario en el hilo?

No y no

Modificamos el valor predeterminado prioritize_exact_search_title_match que ahora es verdadero por defecto.

También aumentamos nuestra versión de índice a la versión 5.

Esto significa que cada 2 horas se reindexarán 10.000 temas y 20.000 de las publicaciones más recientes con una versión de índice antigua.

Puedes acelerar el proceso ejecutando rake search:reindex, pero realmente no es necesario, de todos modos sucederá automáticamente en segundo plano. (probablemente ya lo hizo para la mayoría)

Actualizaré la publicación original con una nota.

[Luke_Cousins]

Gracias por la fantástica actualización. Para nosotros, poder definir sinónimos de búsqueda sería una gran mejora Gracias.

[dsims (Daniel)]

No estoy seguro de si este fue un problema antes, pero noté que muchas publicaciones creadas por el sistema aparecen en los resultados de búsqueda. Quizás un caso extremo más notable aquí en meta, pero no esperaría que los mensajes del sistema fueran relevantes para la búsqueda.

Resultado de ejemplo al buscar términos como “cerrado automáticamente”:

[mattdm (Matthew Miller)]

No puedo reproducirlo aquí.

[Moin]

Puedo reproducir eso; si los ordenas por la última publicación en lugar de por relevancia, hay muchos mensajes del sistema en los resultados.

[mattdm (Matthew Miller)]

Ah, sí, lo veo entonces. No es todo, pero es más que razonable. Parece que estos mensajes deberían excluirse de la búsqueda.