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 
Wir haben unsere Terminologie aktualisiert (Benutzer ist jetzt „Mitglied“) und unsere Dokumentation entsprechend angepasst. Ich möchte jedoch, dass jeder, der nach Benutzer sucht, automatisch Ergebnisse sieht, die „Mitglied“ erwähnen. Haben Sie Vorschläge für eine einfache Methode, dies zu erreichen?
CC: @michellefs
Es ist eine ziemlich schwierige Aufgabe, wir könnten potenziell ein Plugin entwickeln, das Synonyme in die indizierten Daten einspeist – aber wir sprechen hier von einem Arbeitsaufwand zwischen 1 Tag und 5 Tagen.
Ich schätze, die große Frage hier ist, wie wichtig Ihnen das ist. Es ist machbar, würde aber einige kundenspezifische Beratung unsererseits erfordern.
Ich weiß nichts, aber ist das nicht einfach eine Frage der Textänderung auf der Anpassungsseite? Oder verstehe ich es mal wieder völlig falsch?
Ich denke, die Hoffnung ist, die Möglichkeit zu haben, den Suchalgorithmus indirekt durch ein Werkzeug wie Tag-Synonyme zu beeinflussen. Aber für alle Schlüsselwörter innerhalb eines Beitrags (oder zumindest des ursprünglichen Beitrags).
Ein Beispiel für einen Anwendungsfall wären Community-Mitglieder/Seitenbesucher, die nach ihren umgangssprachlichen Ausdrücken und nicht nach ähnlichen Markenfachbegriffen suchen. Der Suchalgorithmus priorisierte sehr unterschiedliche Themen. Ein Beispiel auf unserer Website wäre die Suche nach „Desktop-App“ im Gegensatz zu „Native Client“-Themen.
Ich bin neugierig, ob sich die Ansichten zu Tippfehlern im Laufe der Jahre geändert haben:
In Discourse-AI haben wir begonnen, mit semantischer Suche zu experimentieren. Das steckt noch in den Kinderschuhen und wir erforschen diese Systeme noch.
Mithilfe von LLMs zur Verbesserung der Suchanfrage ist ebenfalls ein möglicher (wenn auch heute langsamer) Ansatz:
Diese Technik wird hier erwähnt: GitHub - texttron/hyde: HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels
Neben den 100 % automatisierten Ansätzen
Unsere allgemeine Strategie hier ist es, zu iterieren. Wir haben bereits „überwachte Wörter“ im Produkt, mir würde eine Funktion gefallen, die „Suchsynonyme“ hinzufügt, bei der Sie häufige Tippfehler und gebräuchliche Phrasen angeben, die Sie „stopfen“ möchten. Es handelt sich nicht um geplante Arbeiten, aber sicherlich um etwas, das Sie sponsern könnten.
Es gibt Präzedenzfälle für genau diese Funktion in Postgres unter: https://www.postgresql.org/docs/current/textsearch-dictionaries.html#TEXTSEARCH-SYNONYM-DICTIONARY
Der andere Bereich, den ich zu erkunden bereit bin (ich bin dem gegenüber jedoch nur lauwarm eingestellt), ist die Ermöglichung eines versteckten „Metadaten“-Bereichs für Beiträge, in dem Administratoren Suchbegriffe einfügen können. Es ist sehr, sehr unsichtbar und im Allgemeinen empfehle ich, die Dinge einfach „richtig“ zu stopfen, damit nichts versteckt wird, z. B.:
semantisch, verwandt, verbessern
Das ist eine reine Genialität, es löst das Hauptproblem der auf Embeddings basierenden Suche: schlechte Benutzereingaben.
Und es erfordert nur minimale Änderungen an unserer bestehenden Einrichtung, da Sie nur einen kleinen Schritt hinzufügen müssen, um die Suchanfrage zu “anreichern” 
Zu diesem Thema können wir auch eine hybride Suche durchführen:
Wir liefern bereits einen super leistungsfähigen Re-Ranker in unserer bestehenden Embeddings-API unter einem separaten Endpunkt, dieser hat alle notwendigen Teile bereit, um dies zu ermöglichen.
Beispiel hier:
https://github.com/pgvector/pgvector-python/blob/master/examples/hybrid_search.py#L67-L70