Comportamento de busca inesperado: quando 'commands' não encontra '/commands'

Na minha documentação, documentei /commands formatado com formatação de código em backtick. No entanto, se eu pesquisar por “commands”, não há resultado. A pesquisa tem que ser /commands para que o tópico apareça.

Este é um comportamento intencional? Eu não espero que os usuários pesquisem por um comando específico precedendo o / - ambos deveriam encontrar o tópico, na minha opinião.

Edição; a formatação de código não está relacionada, pois simplesmente “/commands” resulta no mesmo problema.

Edição 2; não consigo reproduzir isso com, por exemplo, “.command”, pesquisar por “command” dá o resultado desejado neste caso.

2 curtidas

Bump esperançoso. :smile:

Não consigo reproduzir isso ao pesquisar /commands:

Nós simplesmente não encontramos commands, o que poderíamos argumentar que deveria encontrar, mas não é um bug em si.

Procurei por configurações relacionadas a "pesquisa", mas não encontrei nada óbvio. Alguma dica do que procurar?

Não, eu acho que o comportamento é esperado

Certo, eu não espero que meus usuários saibam de antemão que eles precisam incluir “/” para encontrar isso. Alguma razão pela qual esse comportamento é esperado ou uma possível solução alternativa? Porque isso afeta seriamente a capacidade de busca da minha documentação.

A pesquisa é uma questão complicada :slight_smile: Você quer que isso apareça, mas e se você também tivesse outros documentos diferentes com “comandos” e não quisesse que documentos com “/comandos” aparecessem neste caso?

Um truque que você pode usar é ter palavras-chave em sua postagem:

<small>Palavras-chave: comandos</small>

1 curtida

Concordo que é complicado! Embora /commands seja um exemplo, tenho provavelmente mais de 100 comandos documentados. Portanto, embora o uso de palavras-chave possa ser uma alternativa, não é o ideal.

Se a palavra for encontrada em algum lugar, ela deve aparecer na pesquisa, essa é a minha compreensão. Por exemplo:

/testcommand > query: testcommand > :no_entry_sign:

betacommand! > query: betacommand > :white_check_mark:

!betacommand > query: betacommand > :white_check_mark:

O que torna o / diferente do ! aqui?

Isso se deve à forma como indexamos os dados:

“test /command” → “‘/command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B”
“test !command” → “‘command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B”

Note que perdemos o ! no segundo caso. Decidimos não manter o ! e suspeito que o caractere de pontuação não é considerado relevante na pesquisa.

2 curtidas

Entendo, na minha opinião / também não deveria ser relevante? Não tenho certeza de como a indexação funciona, mas uma configuração para mudar isso me ajudaria muito.

Notei que “somequery” como parte de uma URL retorna o resultado https://domain.com/somequery-article-today se essa URL estiver em algum lugar no fórum. Este é o comportamento esperado - não sei o quão relacionados são, mas achei interessante que, neste caso, o / não é relevante.

Outra coisa que notei depois de investigar um pouco mais a fundo: temos uma string separada por barras: query1/query2.

query1 retorna um resultado, query2 não retorna resultados, você diria que isso também é esperado, porque isso parece mais um bug se você me perguntar… :thinking:

1 curtida

Estou reabrindo este tópico, pois ainda acredito que ele afeta muito a pesquisa… alguns dos aborrecimentos que tenho tido ultimamente:

Links do Github > nem o nome de usuário nem o nome do repositório são pesquisáveis..
Links do X > nomes de usuário não são pesquisáveis

Existem muitos outros exemplos, se você não depende muito da pesquisa, essas coisas podem passar despercebidas, pois não afetam realmente o que você vê na pesquisa, mas o que você não vê. Não devemos ficar pensando constantemente se um tópico precisa ou não de uma palavra-chave para ser encontrado.

Isso vale especialmente para rascunhos/seções de equipe, onde as postagens simplesmente não estão prontas, às vezes ficam lá por anos, ou a comunicação é em formato mais curto/interno. Esta postagem não seria encontrada pelas palavras-chave equipe e interna se eu não as adicionasse… porque o Discourse simplesmente decidiu que elas não são relevantes? Por quê?

Mal posso concordar que isso não seja um bug, mas sim uma abordagem muito incomum para uma decisão de índice de pesquisa.

4 curtidas

Com base em alguns testes que fiz hoje, parece que isso pode ter sido corrigido? Não tenho certeza se foi intencional, mas obrigado!

Editar; esquece.. o comportamento ainda é o mesmo. :frowning:

1 curtida

Observe que esta é, na verdade, a forma como o stemmer/tokenizador do postgres sql funciona, temos algumas soluções alternativas para casos extremos como URLs onde pode ficar confuso, mas, no geral, terceirizamos muitas dessas coisas para o pg.

Curiosamente, tivemos uma solução improvisada há alguns anos para “indexação extra em URLs” que @tgxworld removeu devido ao inchaço do índice.

Acho que o que posso dizer é que sim, estamos pensando nesses tipos de casos extremos em pesquisas, mas leva bastante tempo para que possamos implementar soluções em torno do framework existente no pg fulltext.

1 curtida

Agradeço sua resposta, Sam!
Entendo que esta é uma peça de tecnologia complexa, espero que vocês encontrem uma boa solução alternativa - enquanto isso, me adaptei e estou tentando usar palavras-chave ocultas e maneiras criativas de contornar essa limitação!

1 curtida

Acho interessante que palavras-chave ocultas sejam cidadãos de primeira classe

Foi sugerido neste tópico, na verdade; Unexpected Search Behavior: When 'commands' Doesn't Find '/commands' - #7 by j.jaffeux