Mineração de Dados no Governo Federal

Mineração de Dados no Governo Federal

apresentação no Meetup do Neo4j em 2016-10-04

51535f9347da7e003f77d31c4e0b5cec?s=128

Thiago Marzagão

October 04, 2016
Tweet

Transcript

  1. mineração de dados no Ÿ p/ que serve? Ÿ quais

    as ferramentas? Ÿ quais os desafios? Thiago Marzagão
  2. p/ que serve?

  3. principal uso: encontrar ralos de $ público ¤  Mau uso

    do dinheiro público: ¤  fraudes diversas em licitações (ex.: prefeito que contrata própria empresa); ¤  fraudes diversas envolvido $ público (ex.: prefeito que recebe bolsa-família); ¤  fraudes tributárias (sonegação, compensações indevidas); ¤  cartel; ¤  …outros.
  4. detecção de cartel

  5. Bajari & Ye (2003)

  6. Bajari & Ye (2003)

  7. Bajari & Ye (2003) ¤  Informalmente: ¤  Os lances precisam

    ser independentes entre si. O lance da empresa A não pode nos ajudar a prever o lance da empresa B. O lance da empresa A não pode depender de quais são as outras empresas na licitação. ¤  Se esse requerimento é violado, temos uma suspeita de cartel. ¤  Catch: não dá p/ testar uma licitação individualmente. A lógica do teste é baseada num conjunto de licitações.
  8. Bajari & Ye (2003) teste de Kolmogorov-Smirnoff (distribuição esperada vs

    distribuição observada)
  9. CÉREBRO

  10. CÉREBRO ¤  Interface gráfica p/ as ferramentas de mineração de

    dados. ¤  Idéia é democratizar o acesso a ferramentas de mineração de dados e assim “empoderar” investigadores/analistas. ¤  Roda na intranet do CADE. ¤  Desenvolvido in-house.
  11. CÉREBRO

  12. Banco de Preços

  13. Banco de Preços

  14. Banco de Preços ¤  Idéia é permitir ao gestor saber

    se o preço está razoável (muito alto? muito baixo?). ¤  Remoção de outliers, faixas de preço. ¤  Disponível p/ todo mundo (http://bancopreco.cgu.gov.br/consultarPreco/ index.jsf). ¤  Back-end desenvolvido in-house, front-end desenvolvido por empresa terceirizada. ¤  Nova versão em desenvolvimento (back to basics).
  15. lição ¤  Nem tudo em mineração de dados é regressão/classificação/clusterização.

  16. outros projetos da CGU ¤  Análise de Risco de Corrupção

    de Servidores Federais ¤  Análise Preventiva de Contratos ¤  Triagem automática de denúncias ¤  Triagem automática de pedidos LAI
  17. outras iniciativas

  18. fracionamento de compras ¤  Lei 8.666/93 ¤  Compras públicas geralmente

    requerem licitação. ¤  Mas apenas p/ compras acima de R$ 8 mil. ¤  “Jeitinho”: dividir compra em lotes inferiores a R$ 8 mil cada. ¤  É crime! ¤  Como identificar? CGU: redes bayesianas.
  19. fracionamento de compras

  20. irregularidades em convênios ¤  SICONV ¤  Governo federal transfere $

    p/ estados e municípios, via convênios (obras públicas, etc). ¤  Esse $ freqüentemente é usado de forma irregular: contratação de empresa do próprio prefeito/governador, contratação de empresa inidônea, etc. ¤  Tudo isso é crime! ¤  Como identificar? TCU: árvores de decisão.
  21. irregularidades em convênios

  22. carta marcada na licitação ¤  Se: ¤  … a licitação

    é feita de forma pouco transparente ¤  … aditivos aumentam o valor inicial do contrato ¤  ... funcionários do órgão já trabalham p/ o fornecedor ¤  A probabilidade de corrupção é maior. ¤  Como identificar? TCU: Naïve Bayes.
  23. carta marcada na licitação

  24. fraudes c/ crédito tributário ¤  Às vezes o contribuinte paga

    imposto a mais. ¤  Nesses casos pode-se pedir compensação. ¤  Mas nem sempre a compensação é devida. ¤  Como identificar? Receita Federal: regressão logística, Naïve Bayes, árvores de decisão.
  25. fraudes c/ crédito tributário

  26. ferramentas

  27. Python ¤  Versátil: web, mineração, tudo. ¤  Dá pra ir

    “de 0 a 100” em pouco tempo. ¤  Open source.
  28. pandas ¤  Excelente p/ manipulação de dados. ¤  Reshaping, joins,

    etc. ¤  Estatísticas descritivas. ¤  Estatística básica. ¤  Conversões de formatos.
  29. scikit-learn ¤  Tem o feijão-com-arroz todo: (regressão, classificação, clusterização) e

    mais um pouco. ¤  API similar nos vários modelos (= fácil de aprender).
  30. R & rpy2 ¤  R ou Python? Ora, pq não

    ambos?
  31. Neo4j ¤  P/ dados em grafos. ¤  Open source! ¤ 

    Comunidade ótima: sempre responde perguntas no StackOverflow, geralmente em minutos.
  32. Neo4j ¤  Todos os sócios, diretos e indiretos, da empresa

    X? ¤  Qual a participação total da empresa X na empresa Y, incluindo participações diretas (X→Y) e indiretas (X → Z → Y)? ¤  Quais as pessoas a quem a pessoa X está vinculada (via emprego ou sociedade) c/ até 3 graus de separação? ¤  Neo4j é mais rápido que SQL Server p/ esse tipo de consulta. E as queries são mais simples de escrever.
  33. Neo4j MATCH (n)-[r*1..3]-(m) WHERE (n.CPF IN ['01234567890']) RETURN r

  34. IPython (agora Jupyter) ¤  P/ análises exploratórias. ¤  Agora suporta

    várias linguagens (projeto Jupyter), não apenas Python.
  35. Flask ¤  Framework web minimalista e fácil de aprender.

  36. gunicorn ¤  App no ar com apenas uma linha de

    comando!
  37. vis.js

  38. vis.js

  39. pq open source? ¤  $$$$$$$$ ¤  “E se adicionássemos tal

    ou qual funcionalidade?” ¤  “Ok, mas temos licenças adicionais?” ¤  Pouca flexibilidade.
  40. quais os desafios?

  41. #1 obter os dados

  42. #1 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?”
  43. #2 entender os dados

  44. #2 entender os dados ¤  Principal base do governo federal

    – ComprasNet – não tem documentação. ¤  Mito: “ciência de dados é 80% pré-processamento e 20% modelagem”. ¤  Realidade: ciência de dados é 80% tentando entender que diabo cada atributo é e 20% pré-processamento e modelagem. ¤  “Quem tinha essa documentação era o Zé das Couves mas ele se aposentou...”
  45. #3 limpar os dados

  46. #3 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) ¤  ... e assim por diante
  47. #4 esforços duplicados

  48. #4 esforços duplicados ¤  Vários órgãos carregando, entendendo e limpando

    as mesmas bases, over and over... ¤  Falta uma data agency.
  49. #5 open office layout

  50. #5 open office layout ¤  É péssimo p/ a produtividade

    mas é a norma no governo federal. ¤  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/
  51. #6 liberdade p/ experimentar

  52. #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
  53. #7 ouvir o usuário

  54. #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ó 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??”
  55. #8 recrutamento

  56. #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
  57. vale a pena! ¤  A causa do $ público é

    nobre. ¤  Às vezes um algoritmo bobo pode resultar numa economia de milhões… ¤  ... ou mandar vários larápios p/ a cadeia. ¤  Há muita gente boa e empolgada fazendo mineração de dados no governo federal. ¤  Apoio institucional tem crescido.
  58. rumo aos finalmentes

  59. resumindo ¤  Há espaço p/ inovação no governo federal. Nem

    tudo são carimbos e papelório. ¤  Áreas do governo federal que fazem mineração de dados: CGU, TCU, Receita Federal, CADE, Polícia Federal, (outros?). ¤  http://www.brasildigital.gov.br/ ¤  É preciso expandir p/ áreas não-punitivas: saúde, educação, meio- ambiente... ¤  Você pode contribuir: dados.gov.br
  60. sobre ¤  Cientista de dados. ¤  Atualmente no Observatório da

    Despesa Pública da CGU. ¤  Professor de estatística e mineração de dados (thiagomarzagao.com/teaching). ¤  Pesquisador (thiagomarzagao.com/papers). ¤  Entusiasta de LEGO Mindstorms (github.com/thiagomarzagao/ev3py). ¤  EPPGG, Ex-Ohio State University. ¤  marzagao.1@osu.edu, @tmarzagao