Problema da descoberta. Tipos de sistemas de recomendação.
User-based vs Item-based. A matriz usuário × item pela coluna.
Similaridade, adjusted cosine, predição ponderada.
Amazon 2003. Avaliação. RM-ODP. Artefato. Mão na massa.
🎯 Objetivo da aula: ao final, você deve saber por que Item-based venceu na Amazon, como calcular similaridade entre itens e como transformar isso em recomendação para o projeto do módulo.
Sistemas de recomendação não são um "extra bacana". São o mecanismo principal de distribuição em plataformas de catálogo infinito. A engenharia por trás deles é crítica como a de banco de dados ou autenticação.
🎯 Por que a colaborativa? Ela escala com uso da plataforma, não com curadoria humana. Amazon, Netflix, YouTube e Spotify usam variações dela como motor principal. É onde a nossa aula vai focar.
"O que todo mundo está vendo"
"Similar ao que você curtiu"
"Gente como você também gostou"
"Combinação inteligente"
🎯 Por que colaborativa? Não exige descrever o conteúdo manualmente. Escala com quantidade de dados de uso, não com curadoria humana. Essa é a razão econômica pela qual Amazon e Netflix apostam pesado nela.
Procura usuários com gosto similar ao seu. Recomenda o que eles gostaram e você ainda não viu.
Procura itens com padrão de consumo similar. Recomenda os mais próximos aos que você já consumiu.
🔑 O giro de perspectiva — trocamos a pergunta "quem se parece comigo?" por "o que se parece com o que eu gosto?". Isso parece trivial, mas é uma decisão arquitetural que muda custo computacional, estabilidade, explicabilidade e cold start. Essa foi a inovação da Amazon em 2001-2003.
Cada item i vira um vetor de dimensão n (nº de usuários). A similaridade entre dois itens é a similaridade entre seus vetores-coluna.
Matrizes reais têm >99% de células vazias. Netflix: ~1 bilhão de ratings em uma matriz de ~500M×17k. Tudo que você vai calcular precisa lidar com isso.
Prós: simples, rápido.
Contras: ignora que cada usuário tem sua própria escala (quem dá só 3-5 vs quem dá 1-5).
Sarwar et al. 2001. Corrige viés de escala. Padrão em item-based.
Quando não há rating numérico (só compra/não-compra, clique/não-clique). Mede sobreposição de audiências.
🧪 Na prática: comece com adjusted cosine se seus dados têm ratings numéricos. Use Jaccard se só tem interações binárias. Cosseno puro só se os usuários tiverem escalas comparáveis.
Matrix (5,4) e Inception (4,5) "apontam" na mesma direção — ângulo pequeno (~8°) → cos(θ) ≈ 0.99.
Mesmo que Matrix seja um vetor "mais longo" que Titanic, o que importa é o ângulo. Dois vetores curtinhos podem ser "mais parecidos" que um curto e um longo na mesma direção? Não — porque o cosseno ignora o comprimento.
Matrix + Inception formam um cluster "sci-fi/ação". Titanic + Amelie formam outro cluster "romance". O algoritmo descobre esses grupos sem conhecer os gêneros.
🎯 A mágica do "adjusted": antes, todos os vetores apontavam para o mesmo quadrante positivo (porque todos os ratings são >0) — tudo parecia similar. Depois, subtrair a média do usuário (R̄u) revela o gosto real: acima da média = positivo, abaixo = negativo. Vetores opostos agora significam "gostos opostos" com cos ≈ −1.
O valor ≈ +0.92 confirma o que vimos geometricamente: Matrix e Inception estão em posições quase paralelas após o ajuste — usuários que gostam de um tendem a gostar do outro, acima da média pessoal.
A similaridade entre dois itens muda pouco ao longo do tempo (gostos de gênero são relativamente fixos). Já similaridade entre usuários muda rápido. Por isso item-item é cacheável.
"Você viu Matrix, então recomendamos Inception porque são similares (sim=0.92)." — Item-based é naturalmente auditável.
O rating previsto é uma média dos ratings que o usuário deu a itens parecidos, com peso igual à similaridade. Itens muito parecidos puxam mais; pouco parecidos contribuem pouco.
Na prática, não usamos todos os itens — só os k mais similares (tipicamente k=20 a 50). Melhora qualidade e custo.
Para recomendar, calculamos P(u,i) para todos os itens não consumidos e devolvemos os N de maior score. Tipicamente N=10 ou 20.
Davi já avaliou: Matrix (5), Titanic (1), Amelie (3).
Queremos prever: P(Davi, Interstellar).
Similaridades de Interstellar com os itens que Davi avaliou (da matriz S):
+0.88−0.72+0.22Rating alto + similaridade forte com Matrix (que ele amou) → recomenda com confiança. Titanic (que ele odiou) reforça no sentido oposto, e isso é coerente.
Essa frase é a UX direta do item-based. Ela se tornou o padrão visual da recomendação online. Hoje aparece em Amazon, MercadoLivre, Shopee, Steam, AppStore.
O widget "Customers who bought this also bought" é apontado como responsável por uma fatia relevante das 35% de vendas que a Amazon atribui ao sistema de recomendação.
Item novo sem ratings não tem vetor-coluna → não pode ser comparado a nada.
Mitigação: híbrido com content-based nos primeiros dias.
Itens muito populares acumulam mais similaridades e dominam top-N.
Mitigação: penalização logarítmica, re-ranking por diversidade.
Se poucos usuários avaliaram ambos os itens, sim(i,j) é instável.
Mitigação: threshold mínimo de sobreposição; shrinkage.
Recomendações tendem ao "mais do mesmo" — reduz descoberta.
Mitigação: introduzir serendipity/diversity no ranqueamento.
🧭 Princípio de engenharia: em sistemas de recomendação, nunca basta melhorar a métrica offline. A experiência real do usuário depende de diversidade, novidade e explicabilidade. Monitore isso em produção com A/B tests.
Dos k itens que recomendei, quantos eram realmente relevantes?
Dos itens relevantes para o usuário, quantos apareceram no meu top-k?
Média da precisão em cada posição onde há um item relevante. Sensível à ordem.
Dá peso maior para acertos no topo da lista. Padrão em sistemas ranqueados.
Em produção, use A/B tests com métricas de negócio (CTR, conversão, tempo de sessão). Offline ≠ online.
Biblioteca oficial de machine learning da Microsoft, 100% nativa do .NET. Roda em CPU, sem Python, sem Docker, integrando direto em APIs ASP.NET Core.
ML.NET resolve colaborativa via Matrix Factorization (LIBMF): aprende vetores latentes de dimensão k para cada user e cada item.
u · i (produto escalar dos vetores)cos(i₁, i₂) dos vetores aprendidosIDataViewMatrixFactorizationTrainerIDs arbitrários (strings ou ints esparsos) viram chaves contíguas. É requisito do LIBMF.
Quantos fatores latentes (k). 8–32 cobre a maioria dos casos. Mais rank = mais capacidade + risco de overfit.
Passos de SGD. Use model.Evaluate() num holdout para ajustar. Típico: 15–40.
Passo do SGD. 0.05 é default seguro. Se RMSE estagna alto, aumente; se oscila, diminua.
💡 Dica arquitetural: o PredictionEngine não é thread-safe. Em APIs ASP.NET Core, use PredictionEnginePool (pacote Microsoft.Extensions.ML) para injeção de dependência e escala. Modelo pode ser salvo com ctx.Model.Save(model, schema, "model.zip") e recarregado sem retreinar.
POST /ratingsGET /recommendations/:userId?k=10/recommendations/ratingsuser, item, ratingitem_similarity(user_id, item_id)Aula 1 (hoje): item-based · fundamento matemático. Aula 2: visão geral de filtragem colaborativa (user-based + item-based). Aula 3: SOA e requisitos não funcionais. Aula 4: Stored Procedures e Functions. Aulas 5+: implementação (Transactions, MVVM, TDD, testes, boas práticas, monitoramento).
Minimundo, atores, objetivo de negócio e escopo. Quem usa, por que, e o que está fora desta sprint.
Requisitos funcionais priorizados + RNF por eixo (ISO/IEC 25010) + regras de negócio numeradas.
Modelo de dados inicial + dataset de usuários/itens/ratings capaz de alimentar o algoritmo item-based.
Repositório com template aplicado, issues, branches, board da sprint e rotina de reuniões definida.
✅ Critérios transversais: rastreabilidade RF → RN → RNF sem lacunas · decisões técnicas documentadas no repositório · conventional commits + Merge Requests obrigatórios · todos os membros com ao menos 1 contribuição visível no board.
Releia o TAPI do parceiro em grupo. Marque trechos ambíguos, decisões não justificadas e lacunas técnicas.
Liste dúvidas que surgiram no exercício de item-based. O que vocês precisam confirmar com o parceiro para modelar o domínio?
Prefira perguntas abertas e específicas a perguntas sim/não. Cada pergunta deve justificar por que importa para o projeto.
Adicione as perguntas no Google Sheets da sala. Antes de escrever: leia todas as perguntas existentes.