I have been reading a lot here lately and see that ‘post’ and ‘reply’ seem to be used somewhat interchangeably.
If this were done, it would result in fewer bothersome questions when someone uses the wrong one of the two for their searching before they ask a question with a new topic (LOL it just happened to me, ‘delete post after’ did not produce the same results as ‘delete reply after’…)
Hence my topic question…
Reply and post are not 100% interchangeable. In most usage we see here on Meta they are, but not always.
I’d suggest reviewing Discourse New User Guide, which describes what a post is. A reply is any post that is not the OP.
But I would rather find what I am searching for even if I do not know the correct terminology.
For those more ‘in the know’, would they not still have the option of doing explicit searches with quotes around their explicit term of interest, for example “reply” 
Thanks, I will read that but do many other people read that before they make new topics here?
So, I read the ‘Discourse New User Guide’ and I am unable to find any explicit definition of ‘reply’.
But as I have quoted you above, a ‘reply’ is necessarily a ‘post’, so when someone searches for ‘post’ all ‘reply’ matches should also be presented…
Whether, a search for ‘reply’ should bring up all ‘post’ entries is also unknown after reading that guide.
So, I would still like to have the request of this topics’ title, acted upon. (but again, that is only my opinion)
A reply is necessarily a post but some posts are not replies so searching on post should not automatically add the reply search term.
If your preference is satisfied then it will annoy other users like myself who are only searching for post and not reply.
But you are obviously ‘in the know’ and would likely just use an explicit search term without bothering people here with a new topic about why so many search results for ‘post’ are showing up in your ‘reply’ searches.
Regardless of the semantics of post/reply — adding synonyms to search isn’t something that can be configured in Discourse at the moment.
Ok, that shuts me up 
but perhaps there should be a way to add them, I predict it could lessen the burden on the good people who respond to newbies on this great forum 
Actually, I do general searches and then follow relevant links that have some overlap with what I’m searching for.
Search engines have an idea of which links are followed. Discourse has something similar. “Suggested messages” at the end of the topic are a fruitful source of relevant topics not directly related to the specific search terms.
I am recategorizing it as feature the feature request is pretty clear to me. It is asking for a place in the UX to define custom synonyms.
Postgres technically supports synonyms per:
So if you wanted to get your gloves off and be mega technical you could wire something today, but I agree that some time in the future adding a UI to allow mods to define this may be interesting.
Not putting a pr-welcome on this cause it is complicated and would take quite a while to get right with possible limited benefit.
Timeframe wise I would say this is something I expect not to get to in the next year and probably to get to within the next 5 years.
Congratulations Dale 
Nous avons mis à jour notre terminologie (Utilisateur est maintenant « Membre ») et nous avons mis à jour notre documentation en conséquence, mais j’aimerais que toute personne qui recherche Utilisateur voie automatiquement les résultats mentionnant « Membre ». Avez-vous des idées sur une méthode simple pour y parvenir ?
CC : @michellefs
C’est un travail raisonnablement difficile, nous pourrions potentiellement créer un plugin qui injecte des synonymes dans les données indexées - mais nous parlerions de 1 jour à 5 jours de travail.
Je suppose que la grande question ici est de savoir à quel point c’est important pour vous ? C’est faisable mais cela nécessiterait une consultation personnalisée de notre part.
Je ne sais rien, mais n’est-ce pas juste une question de changer les textes du côté de la personnalisation ? Ou est-ce que je comprends encore tout de travers, comme d’habitude ?
Je pense que l’espoir est d’avoir la possibilité d’influencer l’algorithme de recherche indirectement par le biais d’un outil tel que synonymes de balises. Mais pour tous les mots-clés dans un message (ou le message original, du moins).
Un exemple de cas d’utilisation serait pour les membres de la communauté/les visiteurs du site qui recherchent leurs expressions familières plutôt que du jargon de marque similaire. L’algorithme de recherche privilégiait des sujets très différents. Un exemple sur notre site serait la recherche de sujets « application de bureau » par rapport à « client natif ».
Je suis curieux de savoir si les points de vue sur les fautes de frappe ont changé au fil des ans :
Dans Discourse-AI, nous avons commencé à expérimenter la recherche sémantique. Nous en sommes encore aux débuts et explorons ces systèmes.
L’utilisation des LLM pour améliorer les invites de recherche est également une approche possible (bien que lente aujourd’hui) :
Cette technique est mentionnée ici : GitHub - texttron/hyde: HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels
Outre les approches 100 % automatisées
Notre stratégie générale ici est d’itérer. Nous avons déjà des « mots surveillés » dans le produit, une fonctionnalité qui ajouterait des « synonymes de recherche » où vous spécifiez les fautes de frappe courantes et les phrases courantes que vous souhaitez « bourrer » ne me déplairait pas. Ce n’est pas un travail prévu, mais c’est certainement quelque chose que vous pourriez envisager de sponsoriser.
Il existe un précédent pour cette fonctionnalité exacte dans Postgres, conformément à : https://www.postgresql.org/docs/current/textsearch-dictionaries.html#TEXTSEARCH-SYNONYM-DICTIONARY
L’autre domaine que je suis prêt à explorer (bien que je n’y sois que tièdement favorable) est de permettre un espace « métadonnées » caché sur les publications, où les administrateurs peuvent ajouter des termes de recherche. C’est très, très invisible et en général, je recommande de « correctement » bourrer les œuvres afin que les choses ne soient pas cachées, par exemple :
sémantique, connexe, amélioration
C’est une idée de pur génie, elle résout le problème principal de la recherche basée sur les embeddings : les mauvaises entrées utilisateur.
Et cela nécessite des changements minimes par rapport à notre configuration actuelle, car il suffit d’ajouter une petite étape “d’enrichissement” de la requête de recherche 
Sur ce sujet, quelque chose que nous pouvons également faire est d’effectuer une recherche hybride :
Nous fournissons déjà un réordonnanceur très performant dans notre API d’embeddings existante sous un point de terminaison séparé, cela contient toutes les pièces nécessaires pour que cela se produise.
Exemple ici :
https://github.com/pgvector/pgvector-python/blob/master/examples/hybrid_search.py#L67-L70
