Sarebbe davvero fantastico se i temi suggeriti prendessero in considerazione sia i titoli che il contenuto dei temi. Ad esempio, se si sta leggendo un tema relativo all’argomento ‘analisi’, i temi con contenuti simili potrebbero essere mescolati tra i risultati suggeriti attuali.
Se ciò potesse essere realizzato in modo efficiente, sono certo che sarebbe una vittoria sicura per aumentare il coinvolgimento sia dei nuovi visitatori che degli utenti attivi. Anche se questi suggerimenti utilizzassero solo i titoli dei temi (invece di titolo + contenuto).
Questa è una funzionalità molto complessa da costruire in modo efficiente e la tana del coniglio è enorme. A un certo punto si inizia a considerare l’apprendimento automatico, e la tana del coniglio diventa sempre più profonda.
Vedo il fascino dell’utilizzo dell’IA per determinare contenuti correlati; questo può essere molto utile per gli argomenti #supporto, che possono quasi essere resi “self-service”. Si pubblica una domanda, il ML seleziona 10 candidati e li pubblica semplicemente come risposta che si può accettare o eliminare. Allo stesso modo, quando un utente anonimo cerca assistenza, è utile mostrare contenuti correlati.
Detto questo… è un compito gigantesco e enorme. Non è nella nostra roadmap per il prossimo anno. Ma @eviltrout è entusiasta di sperimentare con l’IA/ML in qualche momento, e questo è il tipo di progetto che potrebbe essere correlato.
@codinghorror rimane un grande fan di DJ random, perché crede che possa superare molti algoritmi sofisticati (e spesso lo fa).
Sono nuovo qui, quindi scusa se sto martellando un cavallo morto.
Concordo con @sam sul fatto che ci sia un burrone, ma d’altro canto la tecnologia di topic modeling è ormai piuttosto matura e esistono strumenti pronti all’uso molto efficaci. Un mio recente progetto ha analizzato circa 5 milioni di titoli e abstract di brevetti; analizzare un ordine di grandezza di migliaia di argomenti sul mio splendido nuovo sito Discourse sito sarebbe un gioco da ragazzi. Inoltre, la mia comunità potrebbe avere l’energia per renderlo possibile.
Dagli esperti: vorrei un consiglio su se dovrei pensare a progettare un plugin o se dovrei intervenire direttamente sul codice sorgente di Discourse (che ho scaricato da GitHub).
Ho trovato questo riguardo all’estrazione di argomenti da un forum Discourse con Python, ma non sono ancora riuscito a farlo funzionare. Una soluzione simile dovrebbe permettermi di estrarre i dati offline, costruire il modello e renderlo caricabile per successive query.
La maggior parte degli strumenti migliori è in Python, a titolo di informazione…
Ti consiglio vivamente di optare per un plugin piuttosto che modificare il codice sorgente. È estremamente improbabile che potremmo includere qualcosa del genere nel core, poiché sarebbe necessaria una dipendenza Python massiccia e un’enorme interfaccia utente per l’addestramento e altro ancora.
C’è molto lavoro da fare riguardo ai meccanismi di addestramento e simili. Potresti fornire una panoramica dei meccanismi con cui intendi eseguire l’addestramento? Quali modelli esatti consiglieresti di utilizzare? Cosa succede quando un argomento ha 100 post? 1000 post?
Cosa useresti come segnale e che peso assegneresti a ciascun elemento (visualizzazioni, categoria, tag e così via)?
Sono estremamente entusiasta di questo progetto, ma ritengo che si tratti di un compito piuttosto enorme.
C’è molto lavoro da fare sui meccanismi di addestramento e così via. Avresti una panoramica dei meccanismi con cui eseguiresti l’addestramento? Quali modelli esatti consiglieresti di utilizzare?
Gli strumenti attuali che il mio team utilizza provengono da gensim. Dispone di un’interfaccia standard modulo Python. È stato testato in modo abbastanza approfondito per molti anni.
La configurazione che mi viene in mente sarebbe la seguente:
Prima: scegliere l’insieme di documenti: potrebbero essere tutte le radici degli argomenti o tutti i post.
Di tanto in tanto (ad esempio una volta a settimana? una volta al mese? a seconda del traffico del forum), costruire il modello doc2vec:
raccogliere i topic di Discourse in un file (o più file) di testo markdown, titolo + corpo del topic. Ora considerare ogni topic come un documento, o “document” per gli algoritmi di Gensim
eseguire strumenti NLP standard per elaborare i documenti, eseguire lo stemming delle parole, ecc.
utilizzare doc2vec (dall’implementazione di Gensim) per costruire un modello che mappa ogni documento in un vettore in uno spazio a d dimensioni. Devi scegliere il parametro meta d attraverso esperimenti; Google utilizza d=40 per i suoi modelli di brevetti; non sono sicuro di quale valore di d utilizzi Google Scholar. Io uso tipicamente d=200. Ogni dimensione dello spazio può essere pensata come una “caratteristica” legata al contenuto semantico.
(FYI: l’algoritmo doc2vec costruisce lo spazio delle caratteristiche addestrando una rete neurale mirata a imparare sequenze di parole; la rete neurale ha uno strato nascosto a d dimensioni; le uscite dello strato nascosto formano lo spazio latente delle caratteristiche)
La costruzione del modello è il compito più pesante, a seconda di quanti documenti hai. 38 anni di brevetti = 5 milioni di documenti; il modello doc2vec richiede una notte su una macchina un po’ datata con 8 core.
Ulteriore compito opzionale interessante: raggruppare la nuvola di documenti nello spazio delle caratteristiche a d dimensioni.
si possono utilizzare strumenti pronti all’uso per il clustering, ad esempio dalla libreria Python sklearn.
il clustering fornisce una classificazione emergente; domande di ricerca interessanti includono come queste classificazioni si sovrappongano alle categorie basate su parole chiave (o tag di Discourse).
Questo avverrebbe offline. Poi online:
Il modello verrebbe caricato.
Una volta caricato il modello, un compito piuttosto leggero è analizzare un nuovo documento e interrogare il modello per determinarne la posizione nello spazio delle caratteristiche a d dimensioni.
nota che questo nuovo documento non attiverebbe una ricostruzione del modello. Il modello rimarrebbe statico per le interrogazioni online. Il nuovo documento verrebbe incorporato nella prossima (ad esempio settimanale) costruzione del modello
Infine, l’ultimo compito leggero è chiedere quali sono i documenti vicini nello spazio delle caratteristiche. Ci sono strumenti Gensim per ottenere un elenco di documenti vicini, ma puoi anche utilizzare direttamente numpy per caricare tutti i vettori dei documenti in una struttura come un albero kd che consente interrogazioni rapide sui punti vicini.
{output}
Cosa succede quando un topic ha 100 post? 1000 post?
La parte offline scala più o meno linearmente con il numero di documenti, ma dovrebbe essere molto gestibile per 10k-100k documenti. Anche 1 milione di documenti va bene per un batch settimanale.
Cosa useresti come segnale e quale forza attribuiresti a ogni elemento (visualizzazioni/categoria/tag e così via)
In questo contesto, la “forza del segnale” per un nuovo topic è interpretata direttamente come la distanza (inversa) dall’embedding vettoriale del nuovo topic ai vettori dei documenti esistenti. Si potrebbe arricchire questo segnale con altre considerazioni (mi piace, visualizzazioni, ecc.), ma questi sono ornamenti aggiuntivi rispetto all’algoritmo di base che sto descrivendo.
Una volta che io (o qualcuno) riuscirò a far funzionare il scraping, la parte offline descritta sopra è piuttosto semplice e meccanica.
La parte difficile (per me) sarebbe quella online, che richiederebbe un’interfaccia tra Rails di Discourse e alcune chiamate Python (ad esempio agli strumenti Gensim). Qualsiasi esempio di questo tipo di interfaccia mi sarebbe utile da esaminare.
La parte delicata delle prestazioni è il meccanismo RPC qui. Non si desidera avviare un nuovo processo Python per ogni singola visualizzazione di un argomento.
Anche una chiamata HTTP potrebbe essere troppo lenta.
Forse… popolare una tabella related_topics(topic_id, related_topic_id, rank)? Potresti quindi affidarti ai WebHook per aggiornare rapidamente la tabella quando gli utenti pubblicano nuovi argomenti, senza che Ruby debba chiamare Python.
L’implementazione lato Discourse sarebbe piuttosto semplice: dovresti semplicemente riscrivere questo metodo per cercare le informazioni nella tua nuova tabella related_topics.
Il vecchio metodo non ha funzionato, quindi l’ho sostituito con Google Ads. I temi suggeriti da Google sono molto intelligenti.
Per quanto riguarda il vecchio metodo, ho disattivato il suggerimento predefinito e lo ho sostituito con uno snippet JS che chiama /search e restituisce quindi un elenco di argomenti.
Grazie per il riferimento all’implementazione della tabella. Non sono sicuro che l’approccio basato su tabelle sia scalabile, però. Per N argomenti, è necessaria una tabella di dimensioni N^2. Quindi, per 10^4 argomenti, la tabella avrebbe 10^8 voci.
Non vedo come evitare la necessità di una chiamata Python per analizzare un nuovo argomento, incorporarlo e trovare i vicini più prossimi. In passato ho costruito un’interfaccia web, ma in questo caso sarei probabilmente tentato di eseguire semplicemente un processo Python in parallelo e comunicare con Discourse tramite socket o pipe, in modo più o meno simile alla lettura e scrittura su un file piuttosto che a una vera e propria chiamata Python. (Dopotutto, tutto gira sul mio server…)
N argomenti = N punti nella rappresentazione dello spazio vettoriale.
La matrice delle distanze tra ogni punto è di dimensioni N^2 (la matrice è simmetrica, quindi ci sono N*(N-1)/2 valori indipendenti). Questo è il N^2 a cui mi riferivo.
Tuttavia, strutture dati intelligenti (ad esempio, l’albero kd) permettono di trovare i vicini più prossimi senza una ricerca esaustiva della tabella N^2 delle differenze.
Comunque, so come fare tutto questo in Python, restituendo la piccola tabella a cui ti riferisci, N x 5 per i 5 argomenti più vicini.
Quindi, se esegui questo script ogni giorno in Python, puoi semplicemente collegare Python direttamente al database di Discourse e farlo generare questa tabella di cache.
La parte relativa al plugin di Discourse è quindi piuttosto semplice. Invece di selezionare dalla posizione X, si seleziona dalla posizione Y (una tabella diversa).
Non dovrai più gestire pipeline che devono attraversare due linguaggi di programmazione diversi per una singola richiesta.
L’approccio AI che è stato suggerito qui sembra interessante e potrebbe essere la soluzione ideale.
Mi chiedo se varrebbe la pena esplorare un approccio meno tecnico: la sezione Argomenti suggeriti potrebbe contenere un pulsante “Suggerisci argomento”. Fare clic sul pulsante consentirebbe agli utenti di pubblicare un link a un altro argomento sul sito e una breve descrizione del motivo per cui i due argomenti sono correlati.
Non è un mockup completo, ma per assicurarci di essere sulla stessa pagina, intendo qualcosa di simile a questo:
Come contesto, sono interessato a suggerire argomenti che supportano e contrastano le opinioni espresse in un particolare argomento. Ad esempio, se qualcuno crea un argomento che afferma che il cambiamento climatico non è un grosso problema, vorrei che gli utenti del sito potessero suggerire argomenti correlati che contrastano o supportano tale argomento.
Potrebbe anche essere utile per argomenti meno controversi. Quando rispondo a un argomento qui, spesso utilizzo la funzionalità di ricerca del sito per vedere se ci sono argomenti correlati. I risultati di tale sforzo potrebbero essere preservati consentendo agli utenti di suggerire argomenti correlati. Ad esempio, leggere questo argomento mi ha fatto pensare al recente utilizzo dell’AI da parte di Discourse qui: Discourse Disorder. Mi sembrerebbe pertinente che quell’argomento appaia nell’elenco degli argomenti suggeriti di questo argomento, con una nota che menziona che Discourse sembra stia esplorando modi per integrare i forum con l’AI.
