Ich habe hier in letzter Zeit viel gelesen und festgestellt, dass ‘Beitrag’ und ‘Antwort’ anscheinend etwas synonym verwendet werden.
Wenn dies der Fall wäre, würde das zu weniger lästigen Fragen führen, wenn jemand bei der Suche vor dem Erstellen eines neuen Themas den falschen der beiden Begriffe verwendet (LOL, mir ist das gerade passiert: ‘Beitrag nach löschen’ ergab nicht dieselben Ergebnisse wie ‘Antwort nach löschen’…)
Daher meine Frage in diesem Thema…
„Antwort
Aber ich würde es vorziehen, das zu finden, wonach ich suche, auch wenn ich die korrekte Fachbezeichnung nicht kenne.
Hätten diejenigen, die sich besser auskennen, nicht immer noch die Möglichkeit, explizite Suchen mit Anführungszeichen um ihren gesuchten Begriff durchzuführen, zum Beispiel „reply
Danke, ich werde das lesen. Aber lesen das viele andere auch, bevor sie hier neue Themen erstellen?
Also, ich habe den „Discourse New User Guide
Eine Antwort ist zwar zwangsläufig ein Beitrag, aber nicht alle Beiträge sind Antworten. Daher sollte die Suche nach ‚Beitrag‘ nicht automatisch den Suchbegriff ‚Antwort‘ hinzufügen.
Wenn deine Präferenz erfüllt wird, wird das andere Benutzer wie mich ärgern, die nur nach Beiträgen und nicht nach Antworten suchen.
Aber du bist offensichtlich ‘eingeweiht’ und würdest wahrscheinlich einfach einen expliziten Suchbegriff verwenden, ohne hier Leute mit einem neuen Thema darüber zu belästigen, warum so viele Suchergebnisse für ‘post’ in deinen ‘reply’-Suchen auftauchen.
Unabhängig von der Semantik von Beitrag/Antwort – das Hinzufügen von Synonymen zur Suche ist im Moment in Discourse nicht konfigurierbar.
Ok, damit bin ich zum Schweigen gebracht 
aber vielleicht sollte es eine Möglichkeit geben, sie hinzuzufügen. Ich vermute, das würde die Belastung für die lieben Leute verringern, die sich in diesem großartigen Forum um Neueinsteiger kümmern 
Tatsächlich führe ich allgemeine Suchen durch und folge dann relevanten Links, die gewisse Überschneidungen mit meiner Suche aufweisen.
Suchmaschinen haben eine Vorstellung davon, welchen Links gefolgt wird. Discourse bietet Ähnliches. Die „Vorgeschlagenen Beiträge
Ich kategorisiere es als #feature um, da die Feature-Anfrage für mich ziemlich klar ist. Es geht darum, in der UX einen Ort zum Definieren benutzerdefinierter Synonyme zu schaffen.
Postgres unterstützt Synonyme technisch, wie hier beschrieben:
Wenn du also richtig loslegen und hochtechnisch vorgehen möchtest, könntest du heute schon etwas implementieren. Ich stimme jedoch zu, dass es in Zukunft interessant sein könnte, eine Benutzeroberfläche hinzuzufügen, die es Moderatoren ermöglicht, dies selbst zu definieren.
Ich setze kein pr-welcome, da dies komplex ist, lange Zeit in Anspruch nehmen würde, um es richtig umzusetzen, und möglicherweise nur begrenzten Nutzen bringt.
Zeitlich würde ich sagen, dass ich nicht damit rechne, das im nächsten Jahr anzugehen, sondern wahrscheinlich innerhalb der nächsten 5 Jahre.
Glückwunsch, 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