Seria bastante fantástico se os tópicos sugeridos levassem em conta os títulos e o conteúdo dos tópicos. Por exemplo: ao ler um tópico sobre o assunto ‘análise’, tópicos que contenham conteúdo semelhante poderiam ser mesclados nos resultados sugeridos atuais.
Se isso pudesse ser feito de forma eficiente, tenho certeza de que seria uma vitória certa para aumentar o engajamento tanto de novos visitantes quanto de usuários ativos. Mesmo que essas sugestões usassem apenas os títulos dos tópicos (em vez de título + conteúdo).
Essa é uma funcionalidade muito complexa de construir de forma eficiente, e o buraco é mais embaixo. Em algum momento, você começa a considerar aprendizado de máquina, e o buraco fica cada vez mais profundo.
Vejo o apelo de usar IA para determinar conteúdo relacionado; isso pode ser muito útil em tópicos de #suporte, que podem quase se tornar “autoatendimento”. Você posta uma pergunta, o ML seleciona 10 candidatos e os publica como uma resposta que você pode aceitar ou excluir. Da mesma forma, quando um anônimo acessa algo para suporte, é útil mostrar conteúdo relacionado.
Dito isso… é uma tarefa gigantesca e enorme. Não está no nosso roteiro para o próximo ano. Mas @eviltrout está interessado em experimentar IA/ML em algum momento, e esse é o tipo de projeto que poderia se relacionar.
@codinghorror continua sendo um grande fã do DJ aleatório, pois ele acredita que ele pode superar muitos algoritmos sofisticados (e muitas vezes o faz).
Sou novo por aqui, então desculpe se estou batendo em porta fechada.
Concordo com @sam de que há um caminho sem saída, mas, por outro lado, a tecnologia de modelagem de tópicos está bastante madura hoje em dia, e existem ferramentas prontas muito boas. Um projeto recente meu analisou cerca de 5 milhões de títulos e resumos de patentes; analisar ordens de milhares de tópicos no meu novo e brilhante site Discourse site seria um bolo de chocolate. Além disso, minha comunidade pode ter energia para fazer isso acontecer.
Dos especialistas: Gostaria de conselhos sobre se devo pensar em projetar um plugin ou se devo pensar em mexer no código-fonte do Discourse (que baixei do GitHub)?
Encontrei isso sobre raspagem de tópicos do Discourse com Python, mas ainda não consegui fazer funcionar. Algo assim permitiria que eu baixasse os dados offline, construísse o modelo e o carregasse para consultas posteriores.
A maioria das boas ferramentas está em Python, só para constar…
Eu certamente recomendaria um plugin aqui em vez de modificar o código-fonte. As chances de podermos lançar algo assim no núcleo são extremamente baixas, pois seria necessária uma dependência massiva de Python e uma infinidade de interface de usuário para treinamento e assim por diante.
Há muito trabalho envolvendo os mecanismos de treinamento e outros aspectos. Você teria um resumo dos mecanismos pelos quais realizaria o treinamento? Quais modelos exatos você recomendaria usar? O que acontece quando um tópico tem 100 postagens? 1000 postagens?
O que você usaria como sinal e qual força você atribuiria a cada elemento (visualizações/categoria/tag e assim por diante)?
Sou extremamente entusiasta deste projeto, mas sinto que é uma tarefa bastante grande.
Há muito trabalho envolvido nos mecanismos de treinamento e assim por diante. Você teria um resumo dos mecanismos pelos quais realizaria o treinamento? Quais modelos exatos você recomendaria usar?
As ferramentas atuais que minha equipe utiliza vêm do gensim. Ele possui uma interface padrão de módulo Python. Tem sido bastante testado ao longo de muitos anos.
A configuração que me vem à mente seria:
Primeiro: escolher o conjunto de documentos: poderia ser todas as raízes de tópicos, ou todos os posts.
De tempos em tempos (por exemplo, uma vez por semana? uma vez por mês? dependendo do tráfego do fórum), construir o modelo doc2vec:
raspar os tópicos do Discourse para um arquivo (ou arquivos) de texto em md, com título + corpo do tópico. Agora, pensando em cada tópico como um documento, ou “documento” para os algoritmos do gensim
executar ferramentas padrão de PLN para processar os documentos, lematizar palavras, etc.
usar doc2vec (da implementação do gensim) para construir um modelo que mapeia cada documento em um vetor em um espaço de dimensão d. Você precisa escolher o parâmetro meta d por meio de experimentos; o Google usa d=40 para seus modelos de patentes; não tenho certeza qual valor de d é usado pelo Google Scholar. Eu normalmente uso d=200. Cada dimensão do espaço pode ser pensada como uma “característica” relacionada ao conteúdo semântico.
(FYI: o algoritmo doc2vec constrói o espaço de características treinando uma rede neural com o objetivo de aprender sequências de palavras; a rede neural possui uma camada oculta de dimensão d; as saídas da camada oculta formam o espaço latente de características)
A construção do modelo é a tarefa mais pesada, dependendo de quantos documentos você tem. 38 anos de patentes = 5 milhões de documentos; o modelo doc2vec leva a noite inteira em uma máquina um pouco antiga com 8 núcleos.
Tarefa opcional interessante adicional: agrupar a nuvem de documentos no espaço de características de d dimensões.
ferramentas prontas para agrupamento, por exemplo, da biblioteca sklearn do Python, podem ser usadas.
o agrupamento fornece uma classificação emergente; questões de pesquisa interessantes incluem como essas classificações se sobrepõem às categorias de palavras-chave (ou tags do Discourse).
Isso ocorreria offline. Então, online:
O modelo seria carregado.
Uma vez que o modelo esteja carregado, uma tarefa bastante leve é analisar um novo documento e consultar o modelo para obter sua localização no espaço de características de d dimensões.
observe que este novo documento não acionaria uma reconstrução do modelo. O modelo permaneceria estático para as consultas online. O novo documento seria incorporado na próxima construção (por exemplo, semanal) do modelo
A última tarefa leve é perguntar quais são os documentos próximos no espaço de características. Existem ferramentas do gensim para obter uma lista de documentos próximos, mas você também pode usar o numpy diretamente para carregar todos os vetores de documento em uma estrutura como uma árvore kd que permite consultas rápidas de pontos próximos diretamente.
O que acontece quando um tópico tem 100 posts? 1000 posts?
A parte offline escala mais ou menos linearmente com o número de documentos, mas deve ser muito gerenciável para 10 mil a 100 mil documentos. Mesmo 1 milhão de documentos é aceitável para um lote semanal.
O que você usaria como sinal e que força daria a cada coisa (visualizações/categoria/tag e assim por diante)
Neste contexto, a “força do sinal” para um novo tópico é interpretada diretamente como a distância (inversa) entre a incorporação do novo tópico no espaço vetorial e os vetores de documentos existentes. Poderia-se adornar esse sinal com outras considerações (curtidas, visualizações, etc.), mas essas são adições extras ao algoritmo básico que estou descrevendo.
Uma vez que eu (ou alguém) faça a raspagem funcionar, a parte offline descrita acima é bastante fácil e mecânica.
A parte difícil (para mim) seria a parte online, que exigiria uma interface entre o Rails do Discourse e algumas chamadas em Python (por exemplo, para as ferramentas do gensim). Qualquer exemplo desse tipo de interface seria útil para eu analisar.
A parte complicada de desempenho aqui é o mecanismo RPC. Você não quer iniciar um novo processo Python para cada visualização de tópico.
Até mesmo uma chamada HTTP pode ser muito lenta.
Talvez… preencher uma tabela related_topics(topic_id, related_topic_id, rank)? Assim, você poderia usar WebHooks para atualizar a tabela rapidamente quando novas pessoas publicarem tópicos, e o Ruby não precisaria chamar o Python.
Do lado da implementação no Discourse, seria bastante simples; você simplesmente reescreveria este método para buscar as informações na sua nova tabela related_topics.
A maneira antiga não funcionou, então a substituí por anúncios do Google. Os tópicos sugeridos pelo Google são muito inteligentes.
Quanto à maneira antiga de fazer as coisas, desativei a sugestão padrão e a substituí por um snippet de JS que chama /search e, em seguida, retorna uma lista de tópicos.
Obrigado pela dica sobre a implementação da tabela. No entanto, não tenho certeza de que a abordagem com tabela seja escalável. Para N tópicos, precisamos de uma tabela de tamanho N^2. Assim, para 10^4 tópicos, a tabela teria 10^8 entradas.
Não vejo como evitar a necessidade de uma chamada Python para analisar um novo tópico, incorporá-lo e encontrar os vizinhos mais próximos. No passado, já construí uma interface web, mas aqui provavelmente ficaria tentado a apenas executar um processo Python em segundo plano e me comunicar com o Discourse por meio de um socket ou pipe, funcionando mais ou menos como leitura e escrita em um arquivo, em vez de uma chamada Python real. (Afinal, tudo está rodando no meu servidor…)
N tópicos = N pontos na representação do espaço vetorial.
A matriz de distâncias entre cada ponto é N². (a matriz é simétrica, portanto há N*(N-1)/2 valores independentes). Este é o N² ao qual me referia.
No entanto, estruturas de dados inteligentes (por exemplo, kd-tree) permitem encontrar os vizinhos mais próximos sem uma busca exaustiva na tabela N² de diferenças.
De qualquer forma, sei como fazer tudo isso em Python, retornando a pequena tabela a que você se refere, N x 5 para os 5 tópicos mais próximos.
Então, se você executar isso diariamente em Python, poderá simplesmente conectar o Python diretamente ao banco de dados do Discourse e fazê-lo gerar essa tabela de cache.
A parte do plugin do Discourse, nesse caso, é meio que trivial. Em vez de selecionar a partir da localização X, ele seleciona a partir da localização Y (uma tabela diferente).
Você não precisará mais lidar com pipelines que precisam transitar entre duas linguagens de programação para uma única solicitação.
A abordagem de IA que foi sugerida aqui parece interessante e pode ser a solução ideal.
Estou me perguntando se valeria a pena investigar uma abordagem menos técnica - a seção Tópicos Sugeridos poderia conter um botão “Sugerir Tópico”. Clicar no botão permitiria aos usuários postar um link para outro tópico no site e uma breve descrição de por que os dois tópicos estão relacionados.
Não é um protótipo adequado, mas para garantir que estamos na mesma página, quero dizer algo como isto:
Para contexto, estou interessado em sugerir tópicos que apoiem e contrariem as visões expressas em um tópico específico. Por exemplo, se alguém criar um tópico alegando que as mudanças climáticas não são um grande problema, eu gostaria que os usuários do site pudessem sugerir tópicos relacionados que refutem ou apoiem esse argumento.
Também pode ser útil para tópicos menos controversos. Ao responder a um tópico aqui, muitas vezes utilizo a funcionalidade de pesquisa do site para ver se há tópicos relacionados. Os resultados desse esforço poderiam ser preservados permitindo que os usuários sugiram tópicos relacionados. Como exemplo, a leitura deste tópico me fez pensar sobre o uso recente de IA pelo Discourse aqui: Discourse Disorder. Pareceria relevante para mim ter esse tópico aparecer na lista de tópicos sugeridos deste tópico, com uma nota mencionando que o Discourse parece estar investigando maneiras de integrar fóruns com IA.
