Identificação
Resumo
A aula 2 amplia o que foi visto na aula 1 e apresenta uma visão unificada de filtragem colaborativa. Comparamos lado a lado user-based e item-based em um mesmo pipeline, exploramos os problemas estruturais comuns (sparsity da matriz, cold start de usuário/item, escala) e introduzimos abordagens híbridas que combinam CF com conteúdo.
O fechamento traz como avaliar um recomendador em produção (offline vs. online, A/B test, métricas de negócio) — preparando a equipe para definir a métrica de sucesso do MVP do projeto.
Objetivos de aprendizagem
- OA-1Comparar user-based e item-based em um mesmo pipeline, identificando trade-offs.
- OA-2Explicar sparsity e cold start, propondo mitigações.
- OA-3Esboçar uma abordagem híbrida combinando CF com sinais de conteúdo.
- OA-4Distinguir avaliação offline (precision@k, NDCG) de online (CTR, retenção, A/B).
- OA-5Definir a métrica de sucesso do MVP da equipe e justificar a escolha.
- OA-6Implementar pipeline mínimo que computa recomendações para um conjunto de usuários reais do parceiro.
Pré-requisitos
- Aula 1 concluída: protótipo de similaridade rodando em Python.
- Workshop com o parceiro feito; perguntas-chave respondidas e documentadas.
- Domínio de "item" e "rating" mapeado em
docs/recomendador/dominio.md.
Cronograma do dia
📚 Bloco 1 · Autoestudo
10h00 — 12h00Estudo individual orientado pelo material da aula 2.
- Leitura completa do Material da Aula 2 (visão unificada de CF).
- Identificar 3 limitações reais que o item-based puro tem no domínio do parceiro.
- Pesquisar 1 caso público em que A/B test mudou a decisão de algoritmo (ex.: Netflix Prize).
- Caderno de bordo: anotar dúvidas concretas sobre cold start.
📚 Leituras sugeridas:
- Cold start (recommender systems) — Mark Milankovic · Medium
- What Content-Based Filtering is and Why You Should Use It — Upwork
- Building a Content-Based Book Recommendation Engine — KDnuggets
- Recommender Systems: Behind the Scenes of ML-Based Personalization — AltexSoft
🎓 Bloco 2 · Instrução PE — Aula em metodologia ativa
14h00 — 16h00Encontro síncrono com o professor especialista.
- 14h00 — 14h15 · Daily.
- 14h15 — 16h00 · Pipeline unificado, sparsity/cold start, híbrido, avaliação on/off.
🍴 Intervalo · Almoço
12h00 — 14h00Janela livre.
🛠️ Bloco 3 · Desenvolvimento do projeto
16h00 — 18h00Janela de trabalho da equipe.
- Implementar pipeline mínimo (Python) que recebe matriz e devolve top-k recomendações.
- Definir e justificar a métrica de sucesso do MVP em
docs/recomendador/metrica.md. - Esboçar plano de mitigação de cold start (ex.: itens populares para usuário novo).
- Abrir Merge Request
feat(reco): pipeline e métrica.
Detalhamento da instrução PE (14h00 — 16h00)
14h15
DailyDaily de abertura
Cada aluno apresenta em 1 minuto: 1 limitação que vi no item-based / 1 caso público de A/B test / dúvida concreta sobre cold start.
14h35
TalkPipeline unificado · User × Item
Exposição (15 min) com diagrama do pipeline (input → similaridade → vizinhança → predição → top-k). Mesmo pipeline acomoda user-based e item-based; muda apenas o eixo da matriz.
14h55
CodingPipeline em Python — top-k
Live coding: função top_k_recommend(user, k) usando o protótipo da aula 1 como base. Pares replicam para o domínio do parceiro.
15h15
AtivaSparsity e cold start — debate
Em duplas: a equipe recebe um cenário (usuário novo, item novo, matriz com 95% de células vazias) e propõe mitigação. Apresentação de 3 duplas, debate sobre custo vs. valor.
15h30
TalkHíbrido · CF + conteúdo
Por que combinar: CF acerta gosto, conteúdo cobre cold start. 3 estilos de combinação (weighted, switching, mixed) com exemplos reais.
15h50
AtivaAvaliação · offline vs. online
Cada equipe recebe a pergunta "como provo que meu recomendador é melhor que o atual?". Discussão dirigida sobre limites do offline (NDCG bom ≠ usuário feliz) e papel do A/B test.
16h00
AtivaMétrica do MVP · síntese
Cada equipe define em uma frase a métrica de sucesso do MVP (ex.: "% de cliques em recomendados na home"). Cada aluno escreve "a aula 2 me ensinou que...". Anuncia-se a entrega da tarde.
Estratégias de metodologia ativa
- Pipeline como referência única — discutimos arquitetura uma vez e variamos parâmetros, evitando confundir conceito e implementação.
- Cold start como problema concreto — equipes recebem cenário real e precisam decidir mitigação antes de teorizar.
- Métrica como contrato — a equipe sai com uma métrica única que vai julgar todos os experimentos das próximas sprints.
Recomendador sem métrica de sucesso é arte — não engenharia. Sem como medir, qualquer mudança é aposta.
Recursos e ferramentas
| Categoria | Recurso | Uso |
|---|---|---|
| Slides | slides/slide-lesson-2.html | Exposição na instrução PE |
| Material | materials/lesson-2-material.html | Autoestudo |
| Linguagem | Python 3 + NumPy/Pandas | Pipeline unificado |
| Bibliotecas | scikit-learn (KNN, métricas) | Apoio à prototipação |
| Documento | docs/recomendador/metrica.md | Métrica única do MVP |
Verificação de aprendizagem
- CR-1Comparou em par user-based e item-based usando o pipeline único como referência.
- CR-2Propôs em pares uma mitigação concreta para cold start no domínio do parceiro.
- CR-3Esboçou abordagem híbrida (CF + conteúdo) viável para o projeto.
- CR-4Definiu a métrica de sucesso do MVP em uma frase com critério mensurável.
- CR-5Abriu Merge Request
feat(reco): pipeline e métricacom top-k funcional + métrica até as 18h00.
Aluno que sair às 18h sem pipeline top-k rodando + métrica definida está em débito técnico para a aula 3 (SOA).
Conexão com a aula 3
A aula 3 sobe um nível: do algoritmo para a arquitetura. SOA, requisitos não-funcionais e como o pipeline de hoje vira um conjunto de serviços expostos via API.
- O top-k do pipeline será o coração de um recommendation service.
- A métrica definida hoje vira RNF mensurável (latência da resposta, p99 etc.).
Antes das 10h: ler material da aula 3, listar 5 RNFs reais do MVP do parceiro e estudar os 8 eixos de RNF do Inteli.
