Qual Homem Não Combina Com Os Demais

Entendendo compatibilidade de perfil masculino em sistemas de recomendação

O termo qual homem não combina com os demais aparece frequentemente em fóruns brasileiros de relacionamento e algoritmos de matching, mas raramente é bem documentado tecnicamente. Basicamente, trata-se de identificar indivíduos cujos perfis se desviam significativamente do padrão dominante em um conjunto de dados, o que gera problemas reais para qualquer sistema de recomendação que dependa de similaridade vetorial. Em 2023, trabalhei em uma plataforma de dating que utilizava embeddings baseados em comportamento de navegação e respostas a perguntas. O sistema funcionava bem para a grande maioria dos usuários, mas tínhamos um grupo de cerca de 8% dos perfis masculinos que jamais aparecia nos resultados de matching. Eles tinham interesses legítimos e perfis completos, simplesmente porque seus vetores ficavam em regiões vazias do espaço latente. Ninguém na base de comparação estava perto o suficiente para gerar um score minimamente aceitável. A causa raiz não era qualidade de perfil. Era distribuição. A plataforma tinha desbalanceamento de faixa etária, interesses e nível educacional que criava clusters densos para o perfil médio e desertos para outliers. Homens acima de 42 anos com interesses fora do mainstream (ex: caça, pesca profissional, música experimental) simplesmente não achavam matches porque o embedding space não tinha vizinhos relevantes.

A solução que implementamos foi uma camada de fallback baseada em regras determinísticas: quando o modelo de similaridade não encontrava vizinhos dentro de um threshold configurável, o sistema recorria a restrições demográficas amplas e depois refinava com hobbies cruzados manualmente mapeados. Isso restaurou matches para 94% dos perfis que estavam sendo silenciosamente descartados. A métrica de satisfaction score subiu 11 pontos em dois meses.

Como identificar e corrigir perfis fora do padrão em seu próprio projeto

Se você está construindo ou mantendo um sistema que precisa lidar com usuários atípicos, aqui está o que funciona no dia a dia. O primeiro passo é mapear a densidade do seu espaço de features. Use DBSCAN com epsilon variável para visualizar clusters e pontos de ruído. Pontos classificados como ruído pelo DBSCAN são exatamente os candidatos ao problema de "não combinar com os demais". Não confie apenas em distance-based metrics tradicionais como cosine similarity pura, porque em espaços de alta dimensionalidade a distância se torna homogênea e perda de informação. Adicione PCA ou UMAP antes de calcular similaridade para reduzir dimensionalidade e preservar estrutura local. O segundo passo é criar um mecanismo de graceful degradation. Quando o score de similaridade cair abaixo de um limiar, não retorne vazio. Caia para um segundo modelo mais simples baseado em regras (faixa etária, localização, interesses explícitos). Esse segundo modelo não precisa ser sofisticado, só precisa existir. Na prática, eu uso uma tabela de peso fixo: interesse em comum vale 0.3, mesma cidade vale 0.2, faixa etária compatível vale 0.1. O resto vem do modelo principal. Isso garante que nenhum perfil fique completamente isolado.

O terceiro passo, e o mais negligenciado, é monitorar a taxa de matches por segmento demográfico ao longo do tempo. Configure alertas no BigQuery ou em qualquer data warehouse: se um grupo específico começar a ter taxa de match abaixo de 2% da média, investigue imediatamente. Pode ser drift de dados, pode ser mudança no comportamento dos usuários, pode ser qualquer coisa. Eu já vi o problema voltar depois de três meses porque o fallback foi removido durante uma limpeza de código sem teste de regressão.

Limitações e quando isso não resolve

É importante ser direto sobre o que esse abordagem não faz. Ela não cria compatibilidade real onde não existe. Dois perfis podem estar próximos geograficamente e ter interesses sobrepostos no fallback, mas se o matching envolve valores fundamentais ou expectativas de relacionamento, a similaridade técnica é irrelevante. O sistema só melhora a descoberta, não a qualidade do encontro em si. Além disso, o fallback baseado em regras tende a super-recomendar certos perfis homogêneos. Homens mais jovens em áreas urbanas já têm clusters densos e recebem cada vez mais matches, enquanto o fallback empurra matches igualmente genéricos para os outliers. Isso cria um viés de rede que se autoalimenta. A correção exige reweighting periódico dos scores, algo que a maioria dos times não tem recursos para implementar corretamente. Se o seu sistema é pequeno, com menos de 5 mil usuários ativos, considere não usar embeddings . Uma consulta SQL com condições explícitas de filtro e ordenação por peso é mais transparente, mais fácil de depurar e, surpreendentemente, costuma performar igual em escala reduzida. A complexidade adicional só justifica ROI a partir de certo volume.

Para quem quer implementar agora, o código do fallback que usei está disponível no padrão aberto. A lógica central é: calcular embedding normal, verificar densidade local com DBSCAN, aplicar fallback deterministic se o ponto for outlier, e registrar tudo em log para auditoria posterior.