Raffinamenti alla ricerca testati su meta

[sam (Sam Saffron)]

Recentemente, a seguito di feedback interni, abbiamo deciso di dare priorità a una serie di miglioramenti al nostro algoritmo di ricerca.

Queste modifiche sono ora state distribuite su tutti i siti come parte di Discourse 3.1.0.beta3. Dopo l’aggiornamento, il tuo sito inizierà automaticamente a reindicizzare tutti i tuoi contenuti per la ricerca.

Ci sono due nuove impostazioni del sito come parte di questo, ma sono state impostate su valori che abbiamo riscontrato funzionare bene nei nostri test qui su meta, quindi non ci aspettiamo che la maggior parte dei siti abbia alcun motivo per cambiarle.

Dare priorità alla corrispondenza esatta del termine nel titolo rispetto alla corrispondenza parziale

Discourse esegue uno stem + corrispondenza prefisso durante la ricerca. Questo a volte può portare a risultati molto sorprendenti.

Ad esempio: redis viene ridotto a redi, quindi una ricerca per redis può trovare tutte le parole che iniziano con redi, come redirect e altro ancora.
Una nuova impostazione nascosta del sito è stata aggiunta: prioritize_exact_search_title_match che ora è abilitata per impostazione predefinita.

Prima:

Dopo:

Ciò significa che se ricordi il titolo e lo digiti, è molto più probabile che tu trovi il titolo.

Ridotta la duplicazione massima dell’indice

Il nostro algoritmo di ranking classifica i post che hanno più corrispondenze con un termine più in alto rispetto ai post che contengono il termine solo una volta. Ciò significa che puoi “barare” nella ricerca semplicemente ripetendo una parola un sacco di volte. Più digiti la parola, più in alto sale in cima alla ricerca.
Una nuova impostazione nascosta del sito SiteSetting.max_duplicate_search_index_terms che per impostazione predefinita è 6.

Una volta applicato, significa che se digiti “sam” 6 volte o 60 volte in un post, verrà comunque classificato allo stesso modo. Mette un tetto al bonus che puoi dare ai risultati.
Questa modifica ha anche un impatto positivo sulle prestazioni, dato che l’indice di ricerca diventa un po’ più piccolo.

Correzioni di bug varie

Parte del lavoro è stato esaminare casi di ricerca patologici.

• In precedenza abbiamo abbassato la priorità degli argomenti chiusi, ma abbiamo dimenticato gli argomenti archiviati. Questo è ora corretto.
• In precedenza ci siamo affidati troppo alle corrispondenze di prefisso per le ricerche di “dominio”. Ciò significa che la parola happy non trovava https://happy.com poiché happy viene ridotto a happi e la corrispondenza del prefisso fallisce. Questo è stato corretto.

Lavori futuri

• Abbiamo in programma di sperimentare la ricerca “fuzzy” per l’autocompletamento delle menzioni. (consentire di saltare una lettera, ad esempio)
• Abbiamo in programma di indagare sulla de-prioritizzazione dei termini duplicati nei titoli. Attualmente l’argomento chiuso ciao arrivederci ciao è classificato più in alto dell’argomento aperto ciao mondo
• PageRank… attualmente non teniamo conto del numero di link interni in entrata quando classifichiamo i risultati. Ciò significa che a volte argomenti incredibilmente ben collegati possono classificarsi più in basso di un argomento raro che non è collegato da nessuna parte. Sarebbe bello tenerne conto nel nostro algoritmo di ranking.
• Abbiamo un’iniziativa aperta che esamina le integrazioni AI, potremmo trarre ispirazione da strumenti simili a GPT.

Cosa puoi fare per aiutare?

Stai notando risultati negativi su meta? In tal caso, includi il termine che hai cercato spiegando perché i risultati sono scadenti.
Come ti sembrano i cambiamenti (neutrali/migliori/peggiori?)

[Jagster (Jakke Lehtonen)]

Per sicurezza… Se aggiorno/aggiorno la mia configurazione troverò quelle due impostazioni? So come trovare quelle nascoste, non è un problema, ma al momento sono solo per Meta? Per me è più facile testarlo sui miei cerchi che qui

[sam (Sam Saffron)]

Sì, ma devi anche eseguire rake search:reindex

[volanar]

Hai pensato di migliorare la ricerca usando meilisearch? Richiede pochissime risorse e può essere incluso nella build di docker.

[Falco]

@Tris20

L’unica cosa su cui mi piacerebbe vedere un po’ di miglioramento sono gli errori di ortografia comuni. Alcuni motori di ricerca mi hanno viziato al punto che batterò pigramente i tasti finché una miscela di lettere che assomiglia solo vagamente alla parola originale non sarà nella barra di ricerca . Non mi aspetto che venga eguagliato, ma miglioramenti in quell’area sarebbero un grande passo avanti.

Abbiamo iniziato esperimenti in quest’area da

@sam

Abbiamo in programma di sperimentare la ricerca “fuzzy” per il completamento automatico delle menzioni. (ti permette di saltare una lettera, ad esempio)

I primi esperimenti sono limitati alla ricerca di utenti/gruppi, ma se tutto andrà bene potranno essere ampliati ulteriormente.

[sam (Sam Saffron)]

@volanar

Hai pensato di migliorare la ricerca usando meilisearch?

Abbiamo considerato varie integrazioni tra cui sphinx, melli, elastic, solr/lucene ma hanno un costo. Ospitare un altro processo per eseguire l’indicizzazione, rischiare indici non aggiornati, complessità… ecc. non sono gratuiti.

Vorrei vedere quanta strada facciamo con PG prima di esplorare altre opzioni e tenerle come ultima risorsa.

@loginerror

Domanda veloce riguardo a quanto sopra. Che dire degli argomenti chiusi automaticamente con una soluzione?

Problema molto interessante, sì, sono (e sono sempre stati) de-prioritizzati. Penso che come minimo possiamo considerare l’aggiunta di un’impostazione del sito a discourse-solved per consentire agli amministratori di decidere cosa fare in questi casi (prioritizzare/deprioritizzare/neutro ecc.).

[volanar]

@sam

Vorrei vedere quanti chilometri otteniamo da PG prima di esplorare altre opzioni e tenerli come ultima risorsa.

Sfortunatamente, postgres non è adatto come motore di ricerca. E meilisearch ha un consumo di memoria incredibilmente basso e possibilità di ricerca illimitate. L’overhead per il server rispetto a ruby sarà semplicemente invisibile.

[sam (Sam Saffron)]

@volanar

L’overhead per il server rispetto a Ruby sarà semplicemente invisibile.

Questo non è un problema banale. La nostra ricerca contiene un’enorme quantità di dimensioni e ha molti parametri, si collega direttamente alle tabelle postgres.

Con un provider di ricerca esterno dobbiamo preoccuparci della “sincronizzazione”.

• Un argomento viene chiuso su Discourse → notifica il motore
• Un post viene eliminato → notifica il motore
• Viene aggiunto un like → notifica il motore
• Un argomento viene diviso o unito → notifica il motore

L’elenco continua, inclusa la creazione di più indici (utenti/post/argomenti/categorie)

Detto questo, dato il giusto investimento questo non è necessariamente insormontabile, ma è un compito enorme e non esiste una prova di concetto che mostri quanto sarebbe migliore. È bello che melli abbia un classificatore di errori di battitura e molte altre funzionalità, non c’è discussione. Ma integrarlo non è affatto gratuito.

Come stima approssimativa, penserei che ci siano circa 3 mesi di lavoro per costruire un’integrazione stretta e robusta in mellisearch. Forse anche 6 mesi se dovessimo progettare Discourse in modo tale che il motore di ricerca sia “collegabile”.

Nota che supportiamo l’integrazione di Algolia qui: https://discourse.algolia.com/ non è del tutto solida e puoi vedere che l’intera ricerca avanzata è omessa dall’implementazione.

[volanar]

@sam

Come stima approssimativa, penserei che ci vogliano circa 3 mesi di lavoro per creare un’integrazione solida e robusta in mellisearch. Forse anche 6 mesi se dovessimo progettare Discourse in modo tale che il motore di ricerca sia “collegabile”.

Scommetto che con una comunità di discourse così vasta come discourse, può essere molto più veloce, non più di tre mesi.

[Jagster (Jakke Lehtonen)]

Dopo un po’ di tempo ho chiesto ai miei utenti più attivi cosa ne pensassero (pensassero ) della ricerca — non ho mai detto che avesse ricevuto degli steroidi.

Tutti hanno detto esattamente la stessa cosa; non ci avevano pensato ma poiché ho chiesto si sono resi conto che ora trovano risultati pertinenti molto più facilmente, nella maggior parte dei casi subito.

Una parte di Discourse funge da sistema di commenti di WordPress. No, non ricevo più commenti (niente è così sopravvalutato come i commenti dei blog) ma ha mostrato l’esistenza (si scrive così?) del forum. Al giorno d’oggi ho una manciata di utenti che usano Discourse come motore di ricerca. Non commentano ma cercano ciò che cercano da WordPress tramite gli argomenti di Discourse e tornano al blog. Certo, anche il sistema di tag aiuta molto. E a WordPress mancano entrambi: una ricerca efficace e un sistema di tagging funzionante.

Non so se dovrei pubblicarlo in Praise, ma volevo solo dire che sono piuttosto contento di come funziona questa nuova e migliorata ricerca.

[sam (Sam Saffron)]

@Jagster

Tutti hanno detto esattamente la stessa cosa; non ci avevano pensato ma poiché ho chiesto si sono resi conto che ora trovano risultati pertinenti molto più facilmente, nella maggior parte dei casi subito.

Wow grazie, questo mi fa sentire davvero bene! Abbiamo una PR in lavorazione e dovremmo implementare le modifiche a livello globale molto presto.

[mattdm (Matthew Miller)]

@sam

Abbiamo una PR in lavorazione e dovremmo implementare le modifiche a livello globale molto presto.

Mi scusi se sono ottuso: dovrebbe essere attivo sui siti ospitati (con l’ultimo deploy)? L’annuncio di rilascio punta qui, ma questo parla di un’impostazione nascosta: quell’impostazione nascosta è attiva?

[mcwumbly (Dave McClure)]

Non è necessario fare nulla:

@sam

@mcdanlj

sembra che prioritize_exact_search_title_match sia ancora nascosto. È qualcosa che dovremmo aspettarci di usare? Dovremmo eseguire rake search:reindex dopo il deploy come vedo in questo commento nella discussione?

No e no

Abbiamo modificato il valore predefinito prioritize_exact_search_title_match ora è true per impostazione predefinita.

Abbiamo anche aumentato la nostra versione dell’indice alla versione 5.

Ciò significa che ogni 2 ore verranno reindicizzati 10.000 argomenti e 20.000 dei post più recenti con una vecchia versione dell’indice.

Puoi accelerare il processo eseguendo rake search:reindex ma non è davvero necessario, si verificherà comunque automaticamente in background. (probabilmente è già successo per la maggior parte)

Aggiornerò il post originale con una nota.

[Luke_Cousins]

Grazie per il fantastico aggiornamento. Per noi, la possibilità di definire sinonimi di ricerca sarebbe un enorme miglioramento Grazie.

[dsims (Daniel)]

Non sono sicuro se questo fosse un problema in precedenza, ma ho notato molti post creati dal sistema che compaiono nei risultati di ricerca. Forse un caso limite più evidente qui su meta, ma non mi aspetterei che i messaggi di sistema siano rilevanti per la ricerca.

Risultato di esempio quando si cercano termini come “chiuso automaticamente”:

[mattdm (Matthew Miller)]

Non riesco a riprodurlo qui.

[Moin]

Posso riprodurlo; se li ordini per ultimo post invece che per pertinenza, ci sono molti messaggi di sistema nei risultati.

[mattdm (Matthew Miller)]

Ah, sì, lo vedo. Non è tutto, ma più che ragionevole. Sembra che questi messaggi debbano essere esclusi dalla ricerca.