mineração de dados

mineração de dados

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

51535f9347da7e003f77d31c4e0b5cec?s=128

Thiago Marzagão

March 15, 2018
Tweet

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?

  3. None
  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
  6. None
  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
  10. None
  11.  fontes dos dados:  ComprasNet  Google Street View

     preditores:  pixels!
  12. None
  13. None
  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
  37. None
  38. open source

  39. como NÃO começar?

  40. None
  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