Aprimoramentos na pesquisa sendo testados no meta

[sam (Sam Saffron)]

Recentemente, devido a feedback interno, decidimos priorizar uma rodada de melhorias em nosso algoritmo de busca.

Essas alterações foram implementadas em todos os sites como parte do Discourse 3.1.0.beta3. Após a atualização, seu site começará automaticamente a reindexar todo o seu conteúdo para busca.

Existem duas novas configurações de site como parte disso, mas elas foram definidas para valores que descobrimos que funcionam bem em nossos testes aqui no meta, então não esperamos que a maioria dos sites tenha qualquer motivo para alterá-las.

Priorizando a correspondência exata do termo no título em vez da correspondência parcial

O Discourse realiza um stem + correspondência de prefixo ao pesquisar. Isso às vezes pode levar a resultados muito surpreendentes.

Por exemplo: redis gera o radical redi, então uma pesquisa por redis pode encontrar todas as palavras que começam com redi, como redirect e outras.
Uma nova configuração de site oculta foi adicionada: prioritize_exact_search_title_match, que agora está habilitada por padrão.

Antes:

Depois:

Isso significa que, se você se lembrar do título e digitá-lo, terá muito mais chances de encontrar o título.

Redução da duplicação máxima de índice

Nosso algoritmo de classificação classifica as postagens que têm vários acertos para um termo mais alto do que as postagens que contêm o termo apenas uma vez. Isso significa que você pode “trapacear” na pesquisa simplesmente repetindo uma palavra várias vezes. Quanto mais você digitar a palavra, mais ela subirá para o topo da pesquisa.
Uma nova configuração de site oculta SiteSetting.max_duplicate_search_index_terms foi adicionada, que tem o valor padrão de 6.

Uma vez aplicado, isso significa que se você digitar “sam” 6 vezes ou 60 vezes em uma postagem, ela ainda será classificada da mesma forma. Isso coloca um limite no bônus que você pode dar aos resultados.

Essa mudança também tem um impacto positivo no desempenho, dado que o índice de busca se torna um pouco menor.

Correções de bugs diversos

Parte do trabalho envolveu a análise de casos de busca patológicos.

• Anteriormente, diminuíamos a prioridade de tópicos fechados, mas esquecemos dos tópicos arquivados. Isso foi corrigido agora.

• Anteriormente, dependíamos excessivamente de correspondências de prefixo para pesquisas de “domínio”. Isso significa que a palavra happy não encontraria https://happy.com, pois happy gera o radical happi e a correspondência de prefixo falha. Isso foi corrigido.

Trabalho futuro

• Planejamos experimentar a pesquisa “difusa” para autocompletar menções. (permitir que você pule uma letra, por exemplo)

• Planejamos investigar a despriorização de termos duplicados em títulos. Atualmente, o tópico fechado olá adeus olá é classificado mais alto do que o tópico aberto olá mundo

• PageRank… atualmente não levamos em consideração o número de links internos recebidos ao classificar os resultados. Isso significa que, às vezes, tópicos incrivelmente bem linkados podem ter uma classificação mais baixa do que um tópico raro que não é vinculado de lugar nenhum. Seria bom levar isso em consideração em nosso algoritmo de classificação.

• Temos uma iniciativa em andamento analisando integrações de IA, podemos obter alguma inspiração de ferramentas como o GPT.

O que você pode fazer para ajudar?

Você está notando algum resultado ruim no meta? Se sim, por favor, inclua o termo que você pesquisou, explicando por que os resultados são insatisfatórios.

Como as mudanças estão parecendo para você (neutras/melhores/piores?)

[Jagster (Jakke Lehtonen)]

Só para ter certeza… Se eu atualizar/fazer upgrade da minha configuração, encontrarei essas duas configurações? Eu sei como encontrar as ocultas, isso não é um problema — mas elas são apenas para Meta neste momento? Para mim é mais fácil testar nos meus círculos do que aqui

[sam (Sam Saffron)]

Sim, mas você também precisa executar rake search:reindex

[volanar]

Você já pensou em melhorar a busca usando meilisearch? Isso requer poucos recursos e pode ser incluído na build do docker.

[Falco]

@Tris20

A única coisa que eu gostaria de ver um pouco de melhoria são erros comuns de ortografia. Alguns motores de busca me estragaram a ponto de eu preguiçosamente bater nas teclas até que uma mistura de letras que apenas vagamente se assemelham à palavra original esteja na barra de pesquisa . Eu não espero que isso seja igualado, mas melhorias nessa área seriam um grande passo à frente.

Começamos experimentos nesta área por

@sam

Planejamos experimentar a busca “difusa” para autocompletar menções. (permitir que você pule uma letra, por exemplo)

Os primeiros experimentos são limitados à pesquisa de usuários/grupos, mas se tudo correr bem, podem ser expandidos ainda mais.

[sam (Sam Saffron)]

@volanar

Você pensou em melhorar a busca usando meilisearch?

Consideramos várias integrações, incluindo sphinx, melli, elastic, solr/lucene, mas elas têm um custo. Hospedar outro processo para executar a indexação, o risco de índices desatualizados, a complexidade… etc, nada disso é de graça.

Gostaria de ver quanta utilidade obtemos do PG antes de explorar outras opções e mantê-las como último recurso.

@loginerror

Pergunta rápida sobre o acima. E quanto aos tópicos fechados automaticamente com uma solução?

Problema muito interessante, sim, eles são (e sempre foram) despriorizados. Acho que, no mínimo, podemos considerar adicionar uma configuração de site ao discourse-solved para permitir que os administradores decidam o que fazer nesses casos (priorizar/despriorizar/neutro etc.).

[volanar]

@sam

Eu gostaria de ver quanta quilometragem obtemos do PG antes de explorar quaisquer outras opções e mantê-los como último recurso.

Infelizmente, o postgres não é adaptado como um motor de busca. E o meilisearch tem um consumo de memória fantasticamente baixo e possibilidades de busca ilimitadas. O overhead para o servidor em comparação com o ruby será simplesmente invisível.

[sam (Sam Saffron)]

@volanar

A sobrecarga para o servidor em comparação com o Ruby será simplesmente invisível.

Este não é um problema trivial. Nossa busca contém enormes quantidades de dimensões e tem muitos parâmetros, ela se junta diretamente às tabelas do PostgreSQL.

Com um provedor de busca externo, precisamos nos preocupar com a “sincronização”.

• Um tópico é fechado no Discourse → notificar o motor
• Uma postagem é excluída → notificar o motor
• Uma curtida é feita → notificar o motor
• Um tópico é dividido ou mesclado → notificar o motor

A lista continua, incluindo a construção de vários índices (usuários/posts/tópicos/categorias)

Dito isso, com o investimento certo, isso não é necessariamente intransponível, mas é uma tarefa enorme e não há prova de conceito por aí mostrando o quão melhor seria. É bom que o melli tenha um classificador de erros de digitação e muitos outros recursos, sem discussão. Mas integrá-lo não é de graça.

Como uma estimativa aproximada, eu pensaria que há cerca de 3 meses de trabalho construindo uma integração apertada e robusta no mellisearch. Talvez até 6 meses se fôssemos projetar o Discourse de forma que o motor de busca seja “plugável”.

Note que suportamos a integração com o Algolia aqui: https://discourse.algolia.com/ ele não é exatamente sólido como rocha, e você pode ver que toda a busca avançada é omitida da implementação.

[volanar]

@sam

Como uma estimativa aproximada, eu pensaria que há cerca de 3 meses de trabalho para construir uma integração rigorosa e robusta no mellisearch. Talvez até 6 meses se projetássemos o Discourse de tal forma que o mecanismo de busca fosse “plugável”.

Estou disposto a apostar que com uma comunidade tão grande de discursos como o discourse, pode ser muito mais rápido, não mais que três meses.

[Jagster (Jakke Lehtonen)]

Depois de algum tempo, perguntei o que meus usuários mais ativos achavam (pensavam ) sobre a busca — nunca disse que ela ganhou alguns esteroides.

Todos disseram exatamente a mesma coisa; eles não tinham pensado nisso, mas como eu perguntei, eles perceberam que agora encontram resultados relevantes com muito mais facilidade, na maioria dos casos imediatamente.

Uma parte do Discourse atua como sistema de comentários do WordPress. Não, eu não recebo mais comentários (nada é tão superestimado quanto comentar em blogs), mas mostrou a existência (está escrito assim?) do fórum. Hoje em dia, tenho um punhado de usuários que usam o Discourse como um motor de busca. Eles não comentam, mas procuram o que procuram no WordPress através dos tópicos do Discourse e voltam para o blog. Claro, o sistema de tags também ajuda muito. E o WordPress sente falta de ambos: busca eficaz e marcação funcional.

Não sei se devo postar isso em Praise, mas eu só queria dizer que estou bastante satisfeito com o funcionamento desta nova e aprimorada busca.

[sam (Sam Saffron)]

@Jagster

Todos disseram exatamente a mesma coisa; eles não pensaram nisso, mas como eu perguntei, eles percebem que agora encontram resultados relevantes com muito mais facilidade, na maioria dos casos imediatamente.

Uau, obrigado, isso certamente me faz sentir muito bem! Temos um PR no forno agora e devemos implementar as mudanças globalmente muito em breve.

[mattdm (Matthew Miller)]

@sam

Temos um PR no forno agora e devemos implementar as mudanças globalmente muito em breve.

Desculpe se estou sendo obtuso — isso deve estar ativo em sites hospedados (com a última implantação)? O anúncio de lançamento aponta para cá, mas isso fala sobre uma configuração oculta — essa configuração oculta está ativada?

[mcwumbly (Dave McClure)]

Você não precisa fazer nada:

@sam

@mcdanlj

parece que prioritize_exact_search_title_match ainda está oculto. É algo que devemos esperar usar? Deveríamos executar rake search:reindex após a implantação, como vejo neste comentário na thread?

Não e não

Alteramos o padrão prioritize_exact_search_title_match para ser verdadeiro por padrão.

Também aumentamos nossa versão de índice para a versão 5.

Isso significa que a cada 2 horas, 10.000 tópicos e 20.000 das postagens mais recentes com uma versão de índice antiga serão reindexados.

Você pode acelerar o processo executando rake search:reindex, mas realmente não há necessidade, ele acontecerá automaticamente em segundo plano de qualquer maneira. (provavelmente já aconteceu para a maioria)

Atualizarei a postagem original com uma nota.

[Luke_Cousins]

Obrigado pela fantástica atualização. Para nós, poder definir sinônimos de pesquisa seria uma grande melhoria Obrigado.

[dsims (Daniel)]

Não tenho certeza se isso era um problema antes, mas notei que muitas postagens criadas pelo sistema aparecem nos resultados de pesquisa. Talvez um caso extremo mais perceptível aqui no meta, mas eu não esperaria que mensagens do sistema fossem relevantes para a pesquisa.

Exemplo de resultado ao pesquisar por termos como “fechado automaticamente”:

[mattdm (Matthew Miller)]

Não consigo reproduzir isso aqui.

[Moin]

Consigo reproduzir isso; se você os ordenar pela postagem mais recente em vez de relevância, haverá muitas mensagens do sistema nos resultados.

[mattdm (Matthew Miller)]

Ah, sim, eu vejo isso então. Não é tudo, mas é mais do que razoável. Parece que essas mensagens devem ser excluídas da pesquisa.