He estado leyendo mucho aquí últimamente y veo que ‘publicación’ y ‘respuesta’ parecen usarse de manera algo intercambiable.
Si esto se hiciera, se reducirían las preguntas molestas cuando alguien usa la incorrecta de las dos para su búsqueda antes de hacer una pregunta con un nuevo tema (LOL, ¡acaba de pasarme a mí, ‘eliminar publicación después’ no produjo los mismos resultados que ‘eliminar respuesta después’…)
De ahí mi pregunta en este tema…
Responder y publicar no son 100% intercambiables. En la mayoría de los usos que vemos aquí en Meta, sí lo son, pero no siempre.
Te sugiero revisar Understanding Discourse for new users, que describe qué es una publicación. Una respuesta es cualquier publicación que no sea el mensaje original.
Pero preferiría encontrar lo que busco, incluso si no conozco el término correcto.
¿No seguirían teniendo la opción de realizar búsquedas explícitas con comillas alrededor del término de interés, por ejemplo “reply” 
?
Gracias, lo leeré, pero ¿muchas otras personas lo leen antes de crear nuevos temas aquí?
Así que leí la ‘Guía para nuevos usuarios de Discourse’ y no pude encontrar ninguna definición explícita de ‘respuesta’.
Pero como te he citado arriba, una ‘respuesta’ es necesariamente una ‘publicación’, por lo que cuando alguien busca ‘publicación’, también deberían mostrarse todas las coincidencias de ‘respuesta’…
Tampoco está claro, tras leer esa guía, si una búsqueda de ‘respuesta’ debería mostrar todas las entradas de ‘publicación’.
Por lo tanto, seguiría solicitando que se actuara sobre la petición del título de este tema (pero, de nuevo, eso es solo mi opinión).
Una respuesta es necesariamente una publicación, pero algunas publicaciones no son respuestas, por lo que buscar en publicaciones no debería agregar automáticamente el término de búsqueda de respuestas.
Si tu preferencia se satisface, entonces molestará a otros usuarios como yo, que solo estamos buscando publicaciones y no respuestas.
Pero tú obviamente estás ‘al tanto’ y probablemente usarías un término de búsqueda explícito sin molestar a la gente aquí con un nuevo tema sobre por qué aparecen tantos resultados de búsqueda para ‘post’ en tus búsquedas de ‘respuesta’.
Independientemente de la semántica de publicación/responder, agregar sinónimos a la búsqueda no es algo que se pueda configurar en Discourse en este momento.
Vale, eso me calla 
pero quizás debería haber una manera de añadirlos; predigo que podría aliviar la carga de las buenas personas que responden a los novatos en este gran foro 
En realidad, realizo búsquedas generales y luego sigo los enlaces relevantes que tienen cierta superposición con lo que estoy buscando.
Los motores de búsqueda tienen una idea de qué enlaces se siguen. Discourse tiene algo similar. Los “mensajes sugeridos” al final del tema son una fuente fructífera de temas relevantes no directamente relacionados con los términos de búsqueda específicos.
Lo estoy recategorizando como #feature; la solicitud de función es bastante clara para mí. Se pide un lugar en la UX para definir sinónimos personalizados.
Postgres técnicamente soporta sinónimos según:
Así que, si quisieras meterte en harina y ser súper técnico, podrías implementar algo hoy mismo, pero coincido en que en algún momento futuro añadir una interfaz de usuario para permitir que los moderadores definan esto podría ser interesante.
No estoy añadiendo la etiqueta pr-welcome porque es complicado y llevaría bastante tiempo hacerlo correctamente, con posibles beneficios limitados.
En cuanto al plazo, diría que es algo que no espero abordar en el próximo año y probablemente lo haré dentro de los próximos 5 años.
¡Felicidades, Dale! 
Hemos actualizado nuestra terminología (Usuario ahora es “Miembro”) y hemos actualizado nuestra documentación en consecuencia, pero me gustaría poder hacer que cualquiera que busque Usuario vea automáticamente los resultados que mencionan “Miembro”. ¿Alguna idea sobre un método sencillo para lograr esto?
CC: @michellefs
Es una tarea bastante difícil, podríamos crear un plugin que inyecte sinónimos en los datos indexados, pero estaríamos hablando de entre 1 y 5 días de trabajo.
Supongo que la gran pregunta aquí es, ¿qué importancia tiene esto para usted? Es factible, pero requeriría una consultoría personalizada por nuestra parte.
No sé nada, pero ¿no es solo cuestión de cambiar textos desde el lado de personalización? ¿O ahora, como de costumbre, entiendo totalmente mal?
Creo que la esperanza es tener la capacidad de impactar el algoritmo de búsqueda indirectamente a través de una herramienta como sinónimos de etiquetas. Pero para cualquier palabra clave dentro de una publicación (o la publicación original, al menos).
Un ejemplo de caso de uso sería para los miembros de la comunidad/visitantes del sitio que buscan sus frases coloquiales en lugar de jerga de marca similar. El algoritmo de búsqueda priorizó temas muy diferentes. Un ejemplo en nuestro sitio sería buscar temas de “aplicación de escritorio” frente a “cliente nativo”.
Tengo curiosidad por saber si los puntos de vista sobre los errores tipográficos han cambiado con los años:
En Discourse-AI comenzamos a experimentar con la búsqueda semántica. Todavía estamos en las primeras etapas y explorando estos sistemas.
Usar LLMs para mejorar el prompt de búsqueda también es un enfoque posible (aunque lento hoy en día):
Esta técnica se menciona aquí: GitHub - texttron/hyde: HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels
Además de los enfoques 100% automatizados
Nuestra estrategia general aquí es iterar. Ya tenemos “palabras vigiladas” en el producto, no me importaría una función que agregue “Sinónimos de búsqueda” donde especifiques errores tipográficos comunes y frases comunes que desees “rellenar”. No es un trabajo programado, pero ciertamente es algo que podrías considerar patrocinar.
Existe un precedente para esta función exacta en Postgres según: https://www.postgresql.org/docs/current/textsearch-dictionaries.html#TEXTSEARCH-SYNONYM-DICTIONARY
La otra área que estoy abierto a explorar (aunque solo estoy tibio en esto) es permitir un lugar de “metadatos” oculto en las publicaciones, donde los administradores puedan rellenar términos de búsqueda. Es muy, muy invisible y, en general, recomiendo simplemente “rellenar” las obras adecuadamente para que las cosas no queden ocultas, por ejemplo:
semántica, relacionada, mejorando
Esa es una idea de genio puro, resuelve el principal problema de la búsqueda basada en embeddings: la mala entrada del usuario.
Y requiere cambios mínimos en nuestra configuración existente, ya que solo necesita agregar un pequeño paso de “enriquecimiento” de la consulta de búsqueda 
Sobre este tema, algo que también podemos hacer es una búsqueda híbrida:
Ya enviamos un reordenador súper capaz en nuestra API de embeddings existente bajo un punto final separado, esto tiene todas las piezas necesarias listas para suceder.
Ejemplo aquí:
https://github.com/pgvector/pgvector-python/blob/master/examples/hybrid_search.py#L67-L70
