Questões que eu elaborei antes da entrevista após assistir o vídeo Nubank Data Science team and career e ler o blog do Nubank.
Veja as Informações Importantes para ajudar com as respostas.
1. Como você criaria um modelo para decidir quem deve receber cartão de crédito (e quem não deve receber)?
Perguntas para iniciar a conversa (entender o problema e definir o escopo do design):
- Onde modelo será usado?
- como ferramenta de auxílio a um analista;
- num processo semi-automatizado de aprovação em que acima de um limiar é aprovado e abaixo vai para análise humana;
- Qual o objetivo de negócio quero otimizar?
- aumentar o número de pessoas aprovadas sem aumentar o risco de não-pagamento;
- Qual a expectativa de latência (tempo de resposta) e de acessos concorrentes (throughput)?
- 50000 novas aplicações por dia; ~35 por minuto
- Consigo realizar o objetivo sem um modelo de ML?
- posso aplicar regras de renda mínima, score mínimo, máximo de dívidas;
- Quais os dados que tenho disponível?
- ex: histórico de perfis aprovados e reprovados;
- informações de renda e score do cliente;
- Quem são os usuários?
- analistas do Nubank e os clientes do Nubank;
- Como eles irão acessar o sistema?
- analista acessa através de uma aplicação web; cliente acessa através do smartphone;
- Quais componentes do sistema devem ter o maior foco de discussão?
- ex: pipeline de dados;
Solução de Alto-Nível:
- Tipo de Modelo: Classificação Binária (1 - deve receber cartão; 0 - não deve receber cartão)
- Avaliação Offline:
- target: 1 (cliente aprovado e bom pagador); 0 (cliente reprovado ou cliente aprovado e mau-pagador)
- precision (prioriza não aprovar maus pagadores a custa de reprovar bons pagadores)
- recall (prioriza não reprovar bons pagadores, a custa de aprovar alguns maus pagadores)
- f-score (faz um balanço entre precision e recall)
- dificuldade: falta de informação de falsos negativos (clientes que seriam bons pagadores e foram reprovados)
- dificuldade: se dados históricos foram obtidos com um modelo, os labels vão possuir o viés daquele modelo
- Avaliação Online:
- Taxa de Maus Pagadores Aprovados em 1, 3, 6 meses;
- Média de Gastos dos Clientes Aprovados em 1, 3, 6 meses;
- Ganho com Clientes Aprovados (dá pra medir isto?);
- Métricas de Software: % de erros, tempo de resposta (atraso), throughput
Componentes da Arquitetura:
- Tipo de Modelo em Produção: Predição em Batch. Infraestrutura necessária:
- Message Broker
- Por que um Message Broker? Para permitir comunicação entre micro-serviços; Permite processamento assíncrono; permite distribuir processamento se necessário; melhor escalabilidade; permite "filtrar" pelas mensages de interesse;
- ex: Kafka, Amazon SQS
- Aplicação Mobile para Realizar os Pedidos
- Backend da Aplicação Mobile
- Data Warehouse para Organização dos Dados para App Mobile
- Fila para receber os pedidos para receber cartão (producer: backend mobile; consumers: jobs de "enriquecimento de dados" + predição, data lake, aplicações dashboard;)
- Por que uma fila? Permite processamento assíncrono; permite distribuir processamento se necessário; permite "filtrar" pelas mensagens de interesse;
- ex: RabbitMQ, Apache Kafka; Amazon SQS
- Data Pipeline para executar a Busca de Dados + Predição em Batch
- Por que predição em batch? A resposta do usuário não precisa ser instantânea; Predição em batch é mais eficiente;
- Dificuldades: precisa de dados confiáveis, então não deve consultar os dados "raw" do Data Lake;
- Exemplos: Kubeflow Pipelines, Airflow; Google DataProc;
- Data Lake c/informações sobre o cliente e com histórico de outros clientes aprovados/reprovados/não-pagadores
- Por que um Data Lake? estabelece um local unificado de acesso aos dados; dá flexibilidade sobre a estrutura/qualidade dos dados;
- ex: HDFS (+Spark); S3 + Athena;
- Aplicação de Suporte ao Analista Humano
- Data Warehouse para Aplicação de Suporte
- Serviço que Notifica Clientes da Aprovação/Reprovação
- Feature Factory que Busca Dados do Data Lake e Prepara para Feature Store
- restrição de acesso apenas aos dados estritamente necessários
- ex: Python, SQL/Spark
- FeatureStore c/ dados limpos e preparados
- ex: cassandra, redis (cache caso precise de um atraso ainda menor)
- Treinamento do Classificador Binário
- ex: regressão logísitica, random forest, redes neurais, SVM...
- Storage de Modelos/Metadados
- ex: S3, MinIO, MLFlow, HDFS.
- Gateway para permitir Testes A/B
- ex: Istio (Kubernetes)
- Serviço de Inferência em Lote com Classificador Binário A
- Job para executar a Busca de Dados de Clientes Aprovados (1, 3, 6 meses) + Join com informações de Pagamento (SQL + Spark + Python)
- Data Warehouse para uso da Ferramenta de BI/Analytics
- Ferramenta de BI/Analytics para Explorar métricas online
- Por que uma ferramenta de BI? para informar visualmente, para prover uma interface "no code" para analistas;
O que pode dar errado?
- TODO
Como posso iterar neste modelo/experimento/problema?
- TODO
2. Como abordar o problema para decidir o limite de crédito dado a um cliente? E para decidir uma solicitação de aumento de crédito?
Algumas ideias são deste post: https://blog.nubank.com.br/limite-cartao-nubank/
Objetivos de negócio:
- diminuir o risco de default (não-pagamento)
- aumentar a média de gastos por mês
- aumentar o número de produtos que o cliente utiliza
- aumentar o NPS (net promoter score)
- TODO
Dados necessários:
- Renda do cliente
- Perfil de uso do cartão (ex: média de gastos nos últimos 1, 3, 6 , 12 meses...)
- Score do cliente (Serasa)
- Histórico de atrasos e não-pagamentos
- Dados de Open-Banking/Compartilhados entre instituições financeiras
- Histórico de Parcelamentos de Fatura
- TODO
Testes e experimentos:
- TODO
Sugestão de algoritmo/pipeline de ML:
- TODO
Métricas de negócio:
- TODO
Métricas de ML:
- TODO
O que pode dar errado?
- TODO
Como posso iterar neste modelo/experimento/problema?
- TODO
3. Dado um dataset de informações de compra com cartão de crédito, com cada amostra rotulada como fraude/não-fraude, como construir um algoritmo de detecção de fraude?
Objetivos de negócio:
- TODO
Dados necessários:
- TODO
Testes e experimentos:
- TODO
Sugestão de algoritmo/pipeline de ML:
- TODO
Métricas de negócio:
- TODO
Métricas de ML:
- TODO
O que pode dar errado?
- TODO
Como posso iterar neste modelo/experimento/problema?
- TODO
Objetivos de negócio:
- Diminuir o risco de não-pagamento
- Usar uma estratégia mais efetiva de cobrança
- TODO
Dados necessários:
- como ela gasta dentro e fora do país
- TODO
Testes e experimentos:
- TODO
Sugestão de algoritmo/pipeline de ML:
- TODO
Métricas de negócio:
- TODO
Métricas de ML:
- TODO
O que pode dar errado?
- TODO
Como posso iterar neste modelo/experimento/problema?
- TODO
Algumas ideias são deste vídeo: Classificação de textos com Redes Neurais Convolucionais | Nubank ML Meetup
Objetivos de negócio:
- Aumentar eficiência das operações e manter um alto nível de satisfação do cliente
- Tempo para primeira resposta
- Tempo do primeiro contato até a solução do problema
- TODO
Dados necessários:
- Histórico de Mensagens (de Email/Chat) de Usuários e Respostas
- É possível usar informação contextual. Ex: reissue-error, card-delivered, delivery error.
- Modelos de Língua Pré-Treinados (Ou dados utilizados para treiná-los)
- TODO
Testes e experimentos:
- TODO
Sugestão de algoritmo/pipeline de ML:
- Posso utilizar embeddings pré-treinados + modelo de classificação.
- *Pode ser necessário aplicar regras junto com ML (ex: cliente em atraso não recebe resposta)
- TODO
Métricas de negócio:
- TODO
Métricas de ML:
- TODO
O que pode dar errado?
- dados sem rótulo;
Como posso iterar neste modelo/experimento/problema?
- Aumentar o número de tópicos que consigo responder
Objetivos de negócio:
- TODO
Dados necessários:
- TODO
Testes e experimentos:
- TODO
Sugestão de algoritmo/pipeline de ML:
- TODO
Métricas de negócio:
- TODO
Métricas de ML:
- TODO
O que pode dar errado?
- TODO
Como posso iterar neste modelo/experimento/problema?
- TODO
7. Imagine que uma empresa de telecomunicações entra em contato com você comentando que gostaria de saber a quais clientes deveria de ofertar um serviço adicional de internet. Você sabe que eles possuem uma base com um teste feito no passado para uma base aleatória de quais clientes receberam essa proposta e o resultado obtido do mesmo. Como você abordaria esse problema?
Objetivos de negócio:
- TODO
Dados necessários:
- TODO
Testes e experimentos:
- TODO
Sugestão de algoritmo/pipeline de ML:
- TODO
Métricas de negócio:
- TODO
Métricas de ML:
- TODO
O que pode dar errado?
- TODO
Como posso iterar neste modelo/experimento/problema?
- TODO
- Blog do Nubank
- Nubank Data Science team and career | Nubank ML Meetup
- What's a useful model? Insights from a customer service perspective | Nubank Machine Learning Meetup
- Quando não usar modelos de ML?
- Quando quiser minimizar erros custosos. ex: não deixar um modelo de nlp encerrar contas do Nubank).
- Quando tiver que manter transparência máxima sobre as decisões.
- O que faz um bom produto de ML?
- Ver People + AI Guidebook do Google
- Deixa claro o que é capaz de fazer (segue os modelos mentais dos clientes)
- Deixa claro porque fez (explicabilidade, leva em conta viéses sociais)
- Dá feedback, permite controle pelos usuários, aprende com comportamento do usuário
- Lida com falhas/erros gracefully
- Quando não usar modelos de ML?
- Datasets financeiros tem muita influência do tempo (ex: feriados, final de ano, eleições...)
Nas provas de conceito:
- Criar hipóteses de negócio (qual o impacto do modelo)
- Estipular quais dados serão necessários (e como coletá-los, se necessário)
- Definir testes e experimentos
- Versionamento de código
- Criar pipelines de CI/CD
- Criar Testes Unitários:
- testar corretude dos algoritmos, ex: overfitting de poucas amostras
- sanity-test: 1 predict com amostra aleatória ou pré-definida
- testar se há variações significativas em métricas (comparado com versões anteriores do código)
- dever ser rápidos, e execução pode estar atrelada a um commit/push/pull-request
- compatibilidade de versões de bibliotecas
- Training/Serving skews (Schema Skews)
- Criar Testes de Integração (Rodar Pipeline fim-a-fim com um subconjunto de dados). Geralmente é demorado. Pode rodar periodicamente (ex: 1 vez ao dia).
- Realizar várias execuções e tirar a média dos resultados
- Tracking
- parâmetros/hiperparâmetros/features
- métricas e gráficos
- dependências de software
- training/validation/test sets
- estatísticas/importância relativa de cada feature
- quem treinou o modelo/motivação
- Storage de modelos
- Construir um modelo baseline: data prep., algoritmos, arquiteturas, optimizer, regularization, batch size, avaliação offline/online...
- Sugerir como utilizar o modelo em produção (Batch Job/Real Time? Shadow Mode/AB Testing...)
- Por quanto tempo validar o modelo?
- Gerar hipóteses do que pode dar errado (problemas com qualidade de dados, data e concept drift, ...)
- Decidir como monitorar o modelo em produção (métricas de negócio, de ML, de Software...)
- Como eu posso iterar nesse modelo e na concepção do problema/hipóteses? Preciso capturar mais dados? (ex: no problema de chat foi necessário capturar feedback explícito se o usuário ficou satisfeito)
- Como eu posso usar os dados que coletei nos testes. Existem problemas de feedback loop? (resposta do modelo em operação enviesa futuros modelos?)
Quando o modelo estiver em produção:
- Minimizar riscos de execução.
- O modelo está funcionando direito? Tem alguma regra que está atrapalhando as coisas?
- O dado está sendo ingerido no lake/warehouse?
- Tem alguma informação faltando?
- O modelo está gerando scores adequadamente?
- Está rodando rápido o suficiente?
- Se não for possível estimar um ganho com um modelo, sugerir caminhos para melhorar a estimativa de valor entregue pelo modelo: fazer pesquisas, rankear qual projeto é o mais importante;
- Qual o valor ganhado por atualizar o modelo (com mais dados, mais features)
- Logging
- Como lidar com indisponibilidade
- Alertar quando há problemas
- Servir dados para modelos em realtime: batch compute + cache (cassandra/redis);
Arquitetura:
- Data pipeline
- Data Lake (mantém dados brutos, recebe eventos/logs o tempo todo). Vantagens: qualquer tipo de dado, mais barato. Alternativas: S3, GCS, Hadoop
- Data Warehouse (re). Vantagens: qualidade de dados, schema, velocidade. Desvantagens: apenas dados estruturados. Alternativas: Big Query, Redshift, DynamoDB, Cassandra.
- Data/Feature "factory" (by query).
- Model management
- Model/Experiment tracking
- Data leak
- Tuning de hiperparâmetros
- Validação de modelo (corretude do algoritmo)
- Model Deployment (strategy)
- Model deploy
- Real-Time. Vantagens: alta disponibilidade, pode até rodar embarcado (sem rede). Desvantagens: necessita de uma camada de cache para dados, maior preço, maior complexidade, exige monitoramento, failover.
- Batch/Job. Vantagens: menor custo, pode usar uma solução mais tradicional/barata de BD. Desvantagens: demora.
- Podem acontecer por webservice ou trigger
- Logs: Data Lake ->
Casos de estudo retirados do Machine Learning Systems Design.
1. Duolingo is a platform for language learning. When a student is learning a new language, Duolingo wants to recommend increasingly difficult stories to read.
How would you measure the difficulty level of a story? Given a story, how would you edit it to make it easier or more difficult?