Tenho lido bastante por aqui ultimamente e vejo que ‘postar’ e ‘responder’ parecem ser usados de forma um pouco intercambiável.
Se isso fosse feito, resultaria em menos perguntas incômodas quando alguém usar o termo errado entre os dois ao pesquisar antes de fazer uma pergunta com um novo tópico (LOL, isso acabou de acontecer comigo: ‘excluir post após’ não produziu os mesmos resultados que ‘excluir resposta após’…)
Daí minha pergunta sobre o tópico…
Responder e postar não são 100% intercambiáveis. Na maioria dos usos que vemos aqui no Meta, eles são, mas nem sempre.
Sugiro revisar Understanding Discourse for new users, que descreve o que é um post. Uma resposta é qualquer post que não seja a OP.
Mas eu preferiria encontrar o que estou procurando, mesmo sem conhecer a terminologia correta.
Para aqueles que estão mais ‘por dentro’, não teriam eles ainda a opção de fazer buscas explícitas colocando aspas ao redor do termo de interesse, por exemplo “resposta” 
Obrigado, vou ler isso, mas muitas outras pessoas leem isso antes de criar novos tópicos aqui?
Então, li o ‘Guia para Novos Usuários do Discourse’ e não consegui encontrar nenhuma definição explícita de ‘resposta’.
Mas, como citei você acima, uma ‘resposta’ é necessariamente uma ‘postagem’, então quando alguém busca por ‘postagem’, todas as correspondências de ‘resposta’ também deveriam ser exibidas…
Se uma busca por ‘resposta’ deveria trazer todas as entradas de ‘postagem’, isso também não fica claro após ler esse guia.
Portanto, gostaria que a solicitação do título deste tópico fosse atendida. (mas, novamente, isso é apenas minha opinião)
Uma resposta é necessariamente um post, mas alguns posts não são respostas, então buscar por ‘post’ não deve adicionar automaticamente o termo de busca ‘resposta’.
Se sua preferência for satisfeita, isso irá incomodar outros usuários como eu, que estão buscando apenas por ‘post’ e não por ‘resposta’.
Mas você obviamente está ‘por dentro’ e provavelmente usaria um termo de busca explícito, sem incomodar as pessoas aqui com um novo tópico sobre por que tantos resultados de busca para ‘post’ aparecem nas suas buscas por ‘resposta’.
Independentemente da semântica de post/reply — adicionar sinônimos à pesquisa não é algo que possa ser configurado no Discourse no momento.
Ok, isso me cala 
mas talvez deveria haver uma maneira de adicioná-los. Prevejo que isso poderia aliviar a carga das pessoas gentis que respondem aos iniciantes neste ótimo fórum 
Na verdade, eu faço buscas gerais e depois sigo links relevantes que tenham alguma sobreposição com o que estou procurando.
Os mecanismos de busca têm uma ideia de quais links são seguidos. O Discourse tem algo semelhante. As “mensagens sugeridas” no final do tópico são uma fonte proveitosa de tópicos relevantes não diretamente relacionados aos termos de busca específicos.
Estou recategorizando como #feature, pois a solicitação de recurso é bastante clara para mim. Ela pede um local na UX para definir sinônimos personalizados.
O Postgres tecnicamente suporta sinônimos, conforme:
Então, se você quiser colocar a mão na massa e ser bem técnico, poderia implementar algo hoje mesmo. Mas concordo que, em algum momento no futuro, adicionar uma interface para permitir que moderadores definam isso pode ser interessante.
Não estou adicionando a tag pr-welcome a isso, pois é complicado e levaria bastante tempo para ser feito corretamente, com benefícios possivelmente limitados.
Em termos de cronograma, diria que isso é algo que não espero realizar no próximo ano, mas provavelmente farei dentro dos próximos 5 anos.
Parabéns, Dale 
Fizemos uma atualização em nossa terminologia (Usuário agora é “Membro”) e atualizamos nossa documentação de acordo, mas eu gostaria de poder fazer com que qualquer pessoa que pesquise por Usuário veja automaticamente os resultados mencionando “Membro”. Alguma ideia de um método fácil para realizar isso?
CC: @michellefs
É um desafio razoavelmente difícil, poderíamos potencialmente criar um plugin que injete sinônimos nos dados indexados - mas estaríamos falando de algo entre 1 dia a 5 dias de trabalho.
Acho que a grande questão aqui é o quão importante isso é para você? É possível, mas exigiria alguma consultoria personalizada de nossa parte.
Eu não sei nada, mas isso não é apenas uma questão de mudar textos do lado de personalização? Ou eu, como de costume, estou entendendo tudo errado?
Acredito que a esperança seja ter a capacidade de impactar o algoritmo de busca indiretamente por meio de uma ferramenta como sinônimos de tags. Mas para quaisquer palavras-chave dentro de uma postagem (ou pelo menos na postagem original).
Um exemplo de caso de uso seria para membros da comunidade/visitantes do site que pesquisam suas frases coloquiais em vez de jargões de marca semelhantes. O algoritmo de busca priorizou tópicos muito diferentes. Um exemplo em nosso site seria pesquisar por "aplicativo de desktop" versus tópicos de "cliente nativo".
Curioso para saber se os pontos de vista sobre erros de digitação mudaram ao longo dos anos:
No Discourse-AI, começamos a experimentar a busca semântica. Ainda são os primórdios e ainda estamos explorando esses sistemas.
Usar LLMs para melhorar o prompt de busca também é uma abordagem possível (embora lenta hoje em dia):
Essa técnica é mencionada aqui: GitHub - texttron/hyde: HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels
Além das abordagens 100% automatizadas
Nossa estratégia geral aqui é iterar. Já temos “palavras observadas” no produto, eu não me importaria com um recurso que adicionasse “Sinônimos de Busca” onde você especifica erros de digitação comuns e frases comuns que deseja “preencher”. Não é um trabalho agendado, mas certamente algo que você poderia considerar patrocinar.
Há precedentes para este recurso exato no Postgres em: https://www.postgresql.org/docs/current/textsearch-dictionaries.html#TEXTSEARCH-SYNONYM-DICTIONARY
A outra área que estou aberto a explorar (embora esteja apenas morno quanto a isso) é permitir um local “metadado” oculto nas postagens, onde os administradores podem inserir termos de busca. É muito, muito invisível e, geralmente, recomendo apenas “preencher adequadamente” os trabalhos para que nada seja oculto, por exemplo:
semântica, relacionada, melhorando
Essa é uma ideia de puro gênio, resolve o principal problema da busca baseada em embeddings: a má entrada do usuário.
E requer mudanças mínimas em nossa configuração existente, pois você só precisa adicionar uma pequena etapa de “enriquecimento” da consulta de busca 
Neste tópico, algo que também podemos fazer é uma busca híbrida:
Já fornecemos um reclassificador super capaz em nossa API de embeddings existente sob um endpoint separado, isso tem todas as peças necessárias prontas para acontecer.
Exemplo aqui:
https://github.com/pgvector/pgvector-python/blob/master/examples/hybrid_search.py#L67-L70
