Ordem Crescente De Relevância

Ordenando resultados por relevância crescente

A maioria das ferramentas e consultas que eu já vi configuram a ordenação como "mais relevante primeiro". Isso faz sentido intuitivo, mas existem cenários bem específicos onde você precisa do oposto: ordem crescente de relevância. Vamos falar de como isso funciona na prática, não na teoria.

O que é ordem crescente de relevância

Em termos simples, é um método de classificação que coloca os resultados menos relevantes no topo e os mais relevantes na base. O inverso do padrão que você vê em buscas do Google ou em sistemas de recomendação. A lógica por trás disso é diferente — em vez de mostrar o que provavelmente interessa primeiro, você mostra o que precisa ser eliminado ou revisado com mais atenção. No SQL, por exemplo, isso se traduz em usar ORDER BY com uma função de pontuação de relevância seguida de ASC, quando o padrão seria DESC. No WordPress, você modifica o query com orderby e meta_value ou relevance de forma ascendente. A diferença é puramente na direção da classificação.

Configurando isso no WordPress

Eu já precisei fazer isso para um plugin de comparação de produtos onde o cliente queria que os itens com menor score de compatibilidade aparecessem primeiro, assim ele podia revisar e ajustar manualmente antes de publicar. O comportamento padrão do WP_Query ordena por data ou relevance decrescente, então eu precisei sobrescrever. O código que eu usei ficou assim:

$query->set( 'orderby', 'relevance' );
$query->set( 'order', 'ASC' ); Só que aí veio o problema. O parâmetro orderby relevance só funciona com a taxonomy query ou quando se usa search posts com o parâmetro s. Se você está usando meta query com um campo numérico de score, o WordPress ignora o orderby relevance e cai na ordenação padrão por ID. Eu gastei umas duas horas testando isso antes de descobrir que precisava forçar um orderby personalizado via clause filtrando pelo campo meta.

A solução que funcionou foi interceptar a query com o filtro pre_get_posts e adicionar um orderby customizado via SQL direto: add_filter( 'pre_get_posts', function( $query ) {
    if ( ! $query->is_main_query() ) return $query;
    $query->set( 'orderby', 'meta_value_num' );
    $query->set( 'meta_key', 'product_relevance_score' );
    $query->set( 'order', 'ASC' );
} );

Isso resolveu porque meta_value_num ordena numericamente, e como o score ia de 0 a 100, os menores vinham primeiro. Simples, mas o fato de o orderby relevance não funcionar com meta queries é algo que a documentação do WordPress não deixa claro.

Ordem crescente de relevância em consultas SQL

Em bancos como PostgreSQL ou MySQL, a abordagem é mais transparente. Você calcula um score de relevância usando funções como MATCH...AGAINST, ts_rank, ou até mesmo operações de string similarity, e depois ordena por esse score de forma ascendente. Um exemplo prático com PostgreSQL:

SELECT *, ts_rank(to_tsvector('simple', content), plainto_tsquery('simple', 'busca')) AS relevance_score
FROM posts
ORDER BY relevance_score ASC
LIMIT 50; O problema aqui é que a função ts_rank retorna zero para documentos que não têm nenhuma ocorrência da busca. Isso significa que todos os posts irrelevantes vão empacotados juntos no topo com score zero, e você não consegue diferenciá-los. Se você precisa separar conteúdo completamente irrelevante do conteúdo apenas pouco relevante, essa abordagem não serve.

A solução que eu encontrei foi usar o operador de similaridade de strings da extensão pg_trgm, que retorna um valor entre 0 e 1 mesmo para coincidências parciais: SELECT *, similarity(content, 'busca') AS relevance_score
FROM posts
WHERE similarity(content, 'busca') > 0
ORDER BY relevance_score ASC;

Com isso, resultados com relevância zero nem entram no set, e os que estão no topo são realmente os menos parecidos com a busca. A desvantagem é que pg_trgm exige indexação explícita comGiST ou GIN para performance aceitável. Sem índice, uma tabela com mais de 100 mil linhas começa a ficar lenta rapidamente.

Quando isso não funciona bem

Eu vi dois casos onde a ordenação crescente por relevância causou problemas sérios. O primeiro foi num sistema de triagem de tickets onde agentes precisavam revisar mensagens em ordem de pior correspondência com a categoria atribuída. A ideia era boa, mas na prática os tickets com score zero (totalmente fora da categoria) ficavam misturados com os de score muito baixo (quase dentro da categoria). O agente não conseguia priorizar porque a diferença entre um e outro era invisível na interface. A solução foi adicionar uma coluna de flag manual e usar uma ordenação composta: primeiro por flag, depois por relevância ascendente. O segundo caso foi num script de limpeza de dados onde eu precisava identificar registros duplicados por similaridade de texto. Ordenar por relevância crescente deveria mostrar primeiro os menos similares, mas como a maioria dos registros realmente não tinha similaridade nenhuma, o top da lista era apenas ruído. Eu precisei inverter a lógica: em vez de ordenar por relevância crescente e filtrar manualmente, ordenei por relevância decrescente e peguei os top 10% como candidatos a duplicatas, deixando o resto para análise posterior. Isso cortou o tempo de processamento de cerca de 45 minutos para 8 minutos num dataset de 50 mil registros.

Cuidados com a implementação de ordem crescente de relevância

Se você for implementar isso, preste atenção em três coisas que normalmente passam despercebidas. A primeira é que a maioria dos sistemas de busca retorna relevância como um score absoluto, não relativo. Um score de 0.3 para uma busca pode ser alto em um contexto e ridículo em outro. Normalizar os scores antes de ordenar é quase sempre necessário. A segunda é cache. Se você está ordenando por relevância em tempo real, cada query vai recalcular scores. Em sistemas com muito tráfego, isso significa carga extra no banco o tempo todo. Armazenar o score calculado em uma coluna da tabela e atualizá-lo periodicamente resolve, mas aí você perde a dinamicidade. O trade-off é real e depende do volume.

A terceira, e mais importante, é que ordem crescente de relevância raramente é a melhor opção para interfaces finais. Usuários esperam ver o mais relevante primeiro. Usar a ordem crescente em telas voltadas ao público geralmente gera fricção e reclamações. Reserve esse padrão para ferramentas internas, processos de revisão, debugging ou qualquer situação em que o objetivo seja identificar exceções, não entregar conteúdo. Se a sua necessidade é realmente analisar outliers ou preparar dados para processamento posterior, considere também ferramentas como scripts Python com scikit-learn para calcular similaridade e exportar resultados já ordenados, evitando sobrecarga no banco de dados. Às vezes a solução mais eficiente não é ajustar a query, mas sair dela.