mineração de dados

auditório da FACE/UnB, 2018-03-15, 19:00-21:00

Transcript

1. mineração de dados  o que dá p/ fazer?  quais os desafios?  como começar? Thiago Marzagão
2. o que dá p/ fazer?
4.  como funciona?  modelo é treinado com base em casos passados:  servidores que já foram expulsos + servidores que não foram expulsos
5.  alguns preditores:  como entrou no governo? (concurso? indicação política?)  é sócio de empresa?  já foi punido antes?  cargo?  filiado a partido político?  ... centenas de outros preditores
7.  como funciona?  modelo é treinado com base em casos passados:  fornecedores que já foram punidos pelo governo federal + fornecedores que não foram punidos
8.  alguns preditores:  doação de campanha?  quantos funcionários?  existe há quanto tempo?  quantos lances?  escopo de atividades?  ... centenas de outros preditores
9.  versão atual: rede neural, em colaboração c/ Rutgers University  p/ o futuro: objetivo é plugar nos sistemas de compra de governo
11.  fontes dos dados:  ComprasNet  Google Street View  preditores:  pixels!
14.  SISAM: app da Receita que encontra erros em declarações de importação  redes bayesianas  aprende c/ poucos exemplos  fácil de retreinar  gera automaticamente textos que explicam os problemas encontrados
15. http://www.brasildigital.gov.br/brasil-digital/o-evento-1/o-evento/
16. quais os desafios?
17. #1 o que fazer com as previsões?
18. #1 o que fazer com as previsões?  o que fazer com as previsões?  demite servidor? desqualifica licitante?  a tecnologia avança mais rápido que a legislação  problema relacionado: grande qtde. de previsões; é impossível dar vazão a tudo
19. #2 obter os dados
20. #2 obter os dados  órgãos não compartilham dados entre si  nem mesmo quando os dados são públicos (!)  “ok, mas só se firmarmos um convênio”  “ok, mas a extração custa R$ 39.844.095.098.490.802.984.309.582.304”  “como assim você queria os dados atualizados?”  “como assim você queria todos os dados?”
21. #3 entender os dados
22. #3 entender os dados  principal base do governo federal – ComprasNet – não tem documentação  “quem tinha essa documentação era o Zé das Couves mas ele se aposentou...”  mito: “ciência de dados é 80% pré-processamento e 20% modelagem”  realidade: ciência de dados é 80% entender os dados e 20% pré- processamento e modelagem
23. #4 limpar os dados
24. #4 limpar os dados  salários como string  CPF/CNPJ como float  DD/MM/AA, MM/DD/AA, AA/MM/DD na mesma coluna  -9, -1, -999, etc, como missing data (acaba entrando no cálculo das médias)  valores absurdos (ex.: contrato de TI de US$ 1 quatrilhão)
25. #5 esforços duplicados
26. #5 esforços duplicados  vários órgãos carregando, entendendo e limpando as mesmas bases, over and over...  falta uma data agency
27. #6 liberdade p/ experimentar
28. #6 liberdade p/ experimentar  às vezes um trabalho de semanas não dá em nada  muitos falsos positivos, muitos falsos negativos, o problema deixou de ser relevante, etc  é difícil estimar prazos (finais ou intermediários)  chefia precisa estar ok com isso  mas mais importante: é preciso poder errar perante os colegas  “psychological safety”  http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its- quest-to-build-the-perfect-team.html
29. #7 ouvir o usuário
30. #7 ouvir o usuário  quem é o usuário? outros órgãos? cidadão?  usuário não está pagando pelo serviço, então tem menos propensão a dar feedback  não dá pra ouvir o usuário só no final, depois que o app levou meses p/ ser desenvolvido e o órgão gastou $$$$$  difícil lição: data product bacana != data product útil  “fator uau” não prediz sucesso de funcionalidade  CÉREBRO: grafo gravitacional na visualização de redes societárias  usuário: “pq essas bolinhas ficam dançando na minha frente??”
31. #8 recrutamento
32. #8 recrutamento  difícil achar pessoal c/ a qualificação necessária  estatística/mineração & desenvolvimento de software & domínio do negócio  recrutamento é engessado no serviço público  salários não são negociáveis  concurso premia quem decora leis  paliativos:  negociar fringe benefits (horário flexível, trabalho remoto, capacitação)  PNUD  terceirização
33. #9 open office layout
34. #9 open office layout  é péssimo p/ a produtividade mas é a norma  especialmente p/ quem escreve código:  leva ~25 minutos p/ retomar a produtividade após uma interrupção  http://thetomorrowlab.com/2015/01/why-developers-hate-being-interrupted/  http://swizec.com/blog/why-programmers-work-at-night/swizec/3198  http://paulgraham.com/head.html  http://tosbourn.com/a-pragmatic-approach-to-dealing-with-interruption-whilst- you-are-developing/  http://blog.ninlabs.com/2013/01/programmer-interrupted/  http://blog.fogcreek.com/protecting-developer-time-with-cases-not-chat/
35. como começar?
36. treinamento  https://www.coursera.org/learn/machine-learning  https://br.udacity.com/course/intro-to-computer-science--cs101/  mais sugestões em http://thiagomarzagao.com/resources/  chefia precisa tratar horas de capacitação como horas de trabalho  não tem atalho! quem não sabe fazer não sabe delegar
38. open source
39. como NÃO começar?
41.  não é possível fazer ciência de dados sem:  saber programar  conhecer os algoritmos usados “por dentro”  se você programa e conhece os algoritmos, não precisa do SAS
42. sobre  cientista de dados  atualmente no Observatório da Despesa Pública da CGU  professor de estatística e machine learning (thiagomarzagao.com/teaching)  pesquisador (thiagomarzagao.com/papers)  entusiasta de LEGO Mindstorms (github.com/thiagomarzagao/ev3py)  Ohio State University  marzagao.1@osu.edu, @tmarzagao