Verfeinerungen bei der Suche, die auf Meta getestet werden

[sam (Sam Saffron)]

Kürzlich haben wir uns aufgrund von internem Feedback entschieden, eine Reihe von Verbesserungen an unserem Suchalgorithmus zu priorisieren.

Diese Änderungen wurden nun als Teil von Discourse 3.1.0.beta3 auf allen Websites ausgerollt. Nach dem Update beginnt Ihre Website automatisch damit, alle Ihre Inhalte für die Suche neu zu indizieren.

Als Teil davon gibt es zwei neue Website-Einstellungen, diese wurden jedoch auf Werte gesetzt, die sich hier auf Meta in unseren Tests gut bewährt haben, sodass wir nicht erwarten, dass die meisten Websites Gründe haben werden, diese zu ändern.

Priorisierung der vollständigen Übereinstimmung von Begriffen im Titel gegenüber der Teilübereinstimmung

Discourse führt beim Suchen einen Stamm + Präfix-Übereinstimmung durch. Dies kann manchmal zu sehr überraschenden Ergebnissen führen.

Zum Beispiel: redis wird zu redi gestemmt, sodass eine Suche nach redis alle Wörter finden kann, die mit redi beginnen, wie z. B. redirect und mehr.

Eine neue versteckte Website-Einstellung wurde hinzugefügt: prioritize_exact_search_title_match, die jetzt standardmäßig aktiviert ist.

Vorher:

Nachher:

Das bedeutet, wenn Sie sich an den Titel erinnern und ihn eingeben, ist die Wahrscheinlichkeit, den Titel zu treffen, weitaus höher.

Reduzierte maximale Indexduplizierung

Unser Ranking-Algorithmus bewertet Beiträge, die mehrere Treffer für einen Begriff haben, höher als Beiträge, die den Begriff nur einmal enthalten. Das bedeutet, dass Sie bei der Suche schummeln können, indem Sie einfach ein Wort immer wieder wiederholen. Je öfter Sie das Wort eingeben, desto höher steigt es in der Suche auf.

Eine neue versteckte Website-Einstellung SiteSetting.max_duplicate_search_index_terms, die standardmäßig auf 6 gesetzt ist.

Sobald dies angewendet wird, bedeutet dies, dass, wenn Sie ein Wort wie „Sam“ sechs- oder sechzigmal in einem Beitrag eingeben, es immer noch gleich eingestuft wird. Es setzt eine Obergrenze für den Bonus, den Sie Ergebnissen geben können.

Diese Änderung hat auch positive Auswirkungen auf die Leistung, da der Suchindex etwas kleiner wird.

Verschiedene Fehlerbehebungen

Ein Teil der Arbeit bestand darin, pathologische Suchfälle zu betrachten.

• Zuvor haben wir die Priorität von geschlossenen Themen herabgestuft, aber die archivierten Themen vergessen. Dies ist jetzt behoben.

• Zuvor waren wir zu stark auf Präfix-Übereinstimmungen für “Domain”-Suchen angewiesen. Das bedeutet, dass das Wort happy https://happy.com nicht finden würde, da happy zu happi gestemmt wird und die Präfix-Übereinstimmung fehlschlägt. Dies wurde behoben.

Zukünftige Arbeit

• Wir planen, “Fuzzy”-Suche für die Erwähnungs-Autocomplete zu experimentieren. (z. B. einen Buchstaben überspringen lassen)

• Wir planen, die De-Priorisierung von doppelten Begriffen in Titeln zu untersuchen. Derzeit wird das geschlossene Thema hallo auf wiedersehen hallo höher eingestuft als das offene Thema hallo welt

• PageRank… wir berücksichtigen derzeit nicht die Anzahl der eingehenden, internen Links bei der Bewertung von Ergebnissen. Das bedeutet, dass manchmal unglaublich gut verlinkte Themen niedriger eingestuft werden können als ein seltenes Thema, das von nirgendwo verlinkt ist. Es wäre schön, dies in unserem Ranking-Algorithmus zu berücksichtigen.

• Wir haben eine laufende Initiative, die sich mit KI-Integrationen befasst. Möglicherweise können wir uns von GPT-ähnlichen Tools inspirieren lassen.

Was Sie tun können, um zu helfen?

Bemerken Sie schlechte Ergebnisse auf Meta? Wenn ja, geben Sie bitte den gesuchten Begriff an und erklären Sie, warum die Ergebnisse mangelhaft sind.

Wie fühlen sich die Änderungen für Sie an (neutral/besser/schlechter?)

[Jagster (Jakke Lehtonen)]

Nur um sicherzugehen… Wenn ich mein Setup aktualisiere/upgraden werde, finde ich dann diese beiden Einstellungen? Ich weiß, wie man versteckte findet, das ist kein Problem – aber sind diese im Moment nur für Meta? Für mich ist es einfacher, es in meinen Kreisen zu testen als hier

[sam (Sam Saffron)]

Ja, aber Sie müssen auch rake search:reindex ausführen

[volanar]

Haben Sie darüber nachgedacht, die Suche mit Meilisearch zu verbessern? Dies erfordert nur wenige Ressourcen und kann in den Docker-Build integriert werden.

[Falco]

@Tris20

Das Einzige, was ich gerne verbessert sehen würde, sind häufige Rechtschreibfehler. Einige Suchmaschinen haben mich so verwöhnt, dass ich faul auf die Tasten schlage, bis eine Buchstabenmischung, die dem Originalwort nur vage ähnelt, in der Suchleiste erscheint . Ich erwarte nicht, dass das erreicht wird, aber Verbesserungen in diesem Bereich wären ein großer Schritt nach vorne.

Wir haben in diesem Bereich mit Experimenten begonnen, indem wir

@sam

Wir planen, mit „unscharfer“ Suche für die Erwähnung von Autovervollständigung zu experimentieren. (erlaubt Ihnen zum Beispiel, einen Buchstaben zu überspringen)

Erste Experimente sind auf die Benutzer-/Gruppensuche beschränkt, aber wenn alles gut geht, kann dies weiter ausgebaut werden.

[sam (Sam Saffron)]

@volanar

Haben Sie darüber nachgedacht, die Suche mit Meilisearch zu verbessern?

Wir haben verschiedene Integrationen in Betracht gezogen, darunter Sphinx, Melli, Elastic, Solr/Lucene, aber diese sind mit Kosten verbunden. Das Hosten eines weiteren Prozesses für die Indizierung, das Risiko veralteter Indizes, Komplexität usw. sind allesamt nicht kostenlos.

Ich möchte sehen, wie weit wir mit PG kommen, bevor wir andere Optionen in Betracht ziehen, und diese als letzte Möglichkeit betrachten.

@loginerror

Schnelle Frage zum Obigen. Was ist mit automatisch geschlossenen Themen mit einer Lösung?

Sehr interessantes Problem, ja, sie werden (und waren schon immer) nachrangig behandelt. Ich denke, wir können uns zumindest ansehen, eine Site-Einstellung für discourse-solved hinzuzufügen, damit Administratoren entscheiden können, was in diesen Fällen zu tun ist (priorisieren/nachrangig behandeln/neutral usw.).

[volanar]

@sam

Ich möchte sehen, wie viel wir mit PG erreichen, bevor wir andere Optionen in Betracht ziehen, und diese als letzte Möglichkeit beibehalten.

Leider ist PostgreSQL nicht als Suchmaschine geeignet. Und Meilisearch hat fantastisch geringen Speicherverbrauch und unbegrenzte Suchmöglichkeiten. Der Overhead für den Server im Vergleich zu Ruby wird einfach unsichtbar sein.

[sam (Sam Saffron)]

@volanar

Der Overhead für den Server im Vergleich zu Ruby wird einfach unsichtbar sein.

Das ist kein triviales Problem. Unsere Suche enthält eine riesige Menge an Dimensionen und hat viele Parameter, sie greift direkt auf PostgreSQL-Tabellen zu.

Mit einem externen Suchanbieter müssen wir uns um die „Synchronisierung“ kümmern.

• Ein Thema wird in Discourse geschlossen → Benachrichtige die Engine
• Ein Beitrag wird gelöscht → Benachrichtige die Engine
• Ein Like wird vergeben → Benachrichtige die Engine
• Ein Thema wird geteilt oder zusammengeführt → Benachrichtige die Engine

Die Liste geht weiter, einschließlich des Aufbaus mehrerer Indizes (Benutzer/Beiträge/Themen/Kategorien).

Das heißt, mit der richtigen Investition ist dies nicht unbedingt unüberwindbar, aber es ist eine enorme Aufgabe und es gibt keinen Proof of Concept, der zeigt, wie viel besser es wäre. Es ist schön, dass melli einen Tippfehler-Ranker und viele andere Funktionen hat, keine Frage. Aber die Integration ist überhaupt nicht kostenlos.

Als grobe Schätzung würde ich denken, dass es etwa 3 Monate Arbeit erfordert, um eine enge und robuste Integration in MelliSearch zu entwickeln. Vielleicht sogar 6 Monate, wenn wir Discourse so gestalten würden, dass die Suchmaschine „plug-in-fähig“ ist.

Beachten Sie, dass wir hier die Algolia-Integration unterstützen: https://discourse.algolia.com/ Sie ist noch nicht ganz ausgereift, und Sie können sehen, dass die gesamte erweiterte Suche von der Implementierung weggelassen wird.

[volanar]

@sam

Als grobe Schätzung würde ich denken, dass es etwa 3 Monate Arbeit erfordert, eine enge und robuste Integration in Mellisearch zu schaffen. Vielleicht sogar 6 Monate, wenn wir Discourse so gestalten würden, dass die Suchmaschine „plug-in-fähig“ ist.

Ich wette, dass es mit einer so großen Community von Diskursen wie Discourse viel schneller gehen kann, nicht mehr als drei Monate.

[Jagster (Jakke Lehtonen)]

Nach einiger Zeit fragte ich meine aktivsten Nutzer, was sie über die Suche dachten (dachten ), ich habe nie gesagt, dass sie Steroide bekommen hat.

Alle sagten genau dasselbe; sie hatten nicht darüber nachgedacht, aber weil ich gefragt habe, merkten sie, dass sie jetzt viel einfacher relevante Treffer gefunden haben, in den meisten Fällen sofort.

Ein Teil von Discourse fungiert als Kommentarsystem von WordPress. Nein, ich bekomme nicht mehr Kommentare (nichts ist so überbewertet wie das Kommentieren von Blogs), aber es hat die Existenz (wird das so geschrieben?) des Forums gezeigt. Heutzutage habe ich eine Handvoll Benutzer, die Discourse als Suchmaschine nutzen. Sie kommentieren nicht, aber sie suchen über Discourse-Themen nach dem, was sie in WordPress suchen, und kehren zum Blog zurück. Sicher, das Tag-System hilft auch sehr. Und WordPress fehlt beides: effektive Suche und funktionierendes Tagging.

Ich weiß nicht, ob ich das in Praise posten sollte, aber ich wollte nur sagen, dass ich ziemlich zufrieden bin, wie diese neue und verbesserte Suche funktioniert.

[sam (Sam Saffron)]

@Jagster

Alle sagten genau dasselbe; sie haben nicht darüber nachgedacht, aber weil ich gefragt habe, stellen sie fest, dass sie jetzt viel einfacher relevante Treffer finden, in den meisten Fällen sofort.

Wow, danke, das gibt mir wirklich ein gutes Gefühl! Wir haben gerade einen PR in der Entwicklung und sollten die Änderungen bald weltweit ausrollen.

[mattdm (Matthew Miller)]

@sam

Wir haben gerade einen PR in Arbeit und sollten die Änderungen sehr bald weltweit ausrollen.

Entschuldigung, wenn ich mich dumm anstelle – sollte dies auf gehosteten Websites (mit dem neuesten Deploy) aktiv sein? Die Release-Ankündigung verweist hierher, aber hier wird eine versteckte Einstellung besprochen – ist diese versteckte Einstellung aktiviert?

[mcwumbly (Dave McClure)]

Sie müssen nichts tun:

@sam

@mcdanlj

Es sieht so aus, als ob prioritize_exact_search_title_match immer noch versteckt ist. Ist das etwas, das wir erwarten können zu verwenden? Sollen wir rake search:reindex nach dem Deploy ausführen, wie ich in diesem Kommentar im Thread sehe?

Nein und nein

Wir haben den Standardwert für prioritize_exact_search_title_match auf true geändert.

Wir haben auch unsere Indexversion auf Version 5 hochgestuft.

Das bedeutet, dass alle 2 Stunden 10.000 Themen und 20.000 der neuesten Beiträge mit einer alten Indexversion neu indiziert werden.

Sie können den Prozess beschleunigen, indem Sie rake search:reindex ausführen, aber es ist eigentlich nicht notwendig, er wird sowieso automatisch im Hintergrund erfolgen. (Für die meisten ist er wahrscheinlich schon erfolgt)

Ich werde den ursprünglichen Beitrag mit einer Notiz aktualisieren.

[Luke_Cousins]

Vielen Dank für das fantastische Update. Für uns wäre die Möglichkeit, Suchbegriffe zu definieren, eine enorme Verbesserung Vielen Dank.

[dsims (Daniel)]

Ich bin mir nicht sicher, ob dies schon einmal ein Problem war, aber mir ist aufgefallen, dass viele systemerstellte Beiträge in den Suchergebnissen angezeigt werden. Vielleicht ein Grenzfall, der hier im Meta-Bereich auffälliger ist, aber ich würde nicht erwarten, dass Systemnachrichten für die Suche relevant sind.

Beispielergebnis bei der Suche nach Begriffen wie „automatisch geschlossen“:

[mattdm (Matthew Miller)]

Das kann ich hier nicht reproduzieren.

[Moin]

Ich kann das reproduzieren; wenn Sie sie nach dem neuesten Beitrag statt nach Relevanz sortieren, gibt es viele Systemnachrichten in den Ergebnissen.

[mattdm (Matthew Miller)]

Ah, ja, das sehe ich dann. Es ist nicht alles, aber mehr als angemessen. Es scheint, dass diese Nachrichten von der Suche ausgeschlossen werden sollten.