A comunidade pergunta, a gente responde: Decisões técnicas na Serenata de Amor

O contribuidor do Catarse, Thiago Ribeiro, ao requisitar sua consultoria técnica nos enviou perguntas que ajudariam a pautar a consultoria de alguma forma. Então decidimos aproveitar a oportunidade de falar um pouco mais sobre as decisões técnicas que tomamos para o desenvolvimento da Operação Serenata de Amor.

SERENATA-TOOLBOX

O Serenata-Toolbox é um pacote criado para facilitar o desenvolvimento da Rosie e do projeto Serenata de Amor.

  • Porque optou-se pelo Amazon AWS e não outra ferramenta de armazenamento disponível?
    A Amazon oferece um ótimo serviço para armazenamento de dados, na época da escolha essa opção foi sugerida pelo nosso líder técnico e ninguém levantou pontos contra a utilização do mesmo.
  • Com que frequência os dados da CEAP são disponibilizados?
    Os dados da CEAP são atualizados a cada dois dias, mas a frequência com que versionamos e subimos um dataset deles para nosso servidor é bem menor. Até hoje tivemos cerca de 5 versões do dataset lá. Esses datasets são usados mais para exploração, já que sempre que a Rosie roda ela pega os dados novos direto da Câmara — por isso não nos preocupamos tanto com a frequência de atualização dos datasets da toolbox.
  • Foi permitido pegar tudo o que existia lá desde o início? Se não, qual foi a data inicial?
    Sim, os dados estão disponíveis segundo a Lei de Acesso à Informação.

ROSIE

A Rosie é a nossa robô responsável pela avaliação dos reembolsos, usando inteligência artificial, ela olha reembolso por reembolso procurando por irregularidades.

  • Qual método de aprendizado foi o mais eficiente para este projeto?
    Até agora o método mais eficiente para o projeto é o de detecção de valores discrepantes (outliers). No caso da hipótese de distâncias viajadas, que é a hipótese que mais utiliza aprendizado de máquina, tentamos vários algoritmos e o que deu melhor resultado, ou seja, foi mais eficaz em encontrar pontos fora do padrão, foi o método de redução polinomial. Se quiser saber mais sobre os métodos de aprendizado recomendo esse artigo da série de artigos técnicos.
  • O que foi tentado antes, mas não funcionou muito bem (se isso ocorreu)?
    Cada classificador implementado na Rosie passa pelo processo de desenvolvimento da hipótese, que em linhas gerais, se resume a explorar os dados procurando uma abordagem que negue ou valide a hipótese estudada. Esse processo é feito com Jupyter Notebooks que ajudam a registrar e expor o pensamento da pessoa trabalhando na hipótese. Esses notebooks, uma vez terminados, ficam disponíveis no GitHub onde qualquer pessoa possa estudá-los. Assim cada hipótese tem o registro do que foi tentado e o que deu ou não certo.
  • Qual o percentual de acerto da Rosie hoje?
    Depende da análise, algumas análises são avaliadas apenas validando gastos de acordo com a lei da CEAP, por exemplo, a análise de limites de subcotas. Ou algumas análises verificam a autenticidade dos dados, como a existência dos CNPJ e CPF. Então não existe um percentual fixo de o quão a Rosie acerta, mas sim, depende da hipóteses que está sendo estudada. No mutirão de denúncias a Câmara sentimos que esse percentual é entre 80 e 90%.
  • Mediante a probabilidade alta de ter sido encontrada uma fraude (já verificada pela Rosie), como a reclamação é encaminhada?
    Atualmente quando encontramos um reembolso suficientemente suspeito, é enviado um formulário preenchido com os dados encontrados pela Rosie no site da câmara. Essa é a parte mais manual da Rosie, ela só encontra as suspeitas e um humano ainda precisa olhar a suspeita e juntar os dados para enviar para a câmara, até para fins de validar o que foi encontrado se é justo ou não. A ideia é dar mais independência a Rosie, entretanto nesse começo é mais garantido que exista avaliação humana.
  • Sobre os classifiers da Rosie, o que foi avaliado para definir o que era uma possível fraude? Vocês tiveram algum auxílio (na parte de regras de negócio) de alguém do governo, alguém que “validou” essas regras?
    A princípio começamos entendendo a lei que regia o uso da CEAP pelos deputados federais. Esse passo foi importantíssimo nas análises iniciais e para o nosso entendimento do que poderia ser considerado ou não um reembolso suspeito. Começamos estudando detecção de outliers (pontos fora da curva) pois nossos conhecimentos em ciência de dados nos mostravam que poderia ser uma boa estratégia para encontrar fraudes uma vez que os gastos de uma amostra da população tendem a uma distribuição normal.

VOLUNTÁRIOS

  • O que os voluntários analisam? Vi algumas análises exploratórias de alguns voluntários, mas não soube dizer exatamente o que eles encontraram de relevante.
    Como o projeto é aberto eles tem liberdade para fazer muita coisa. Temos contribuições valiosíssimas como análise de refeições feitas em outras cidades enquanto o deputado estava na Câmara, por exemplo. As ideias que os voluntários abraçam normalmente são sugeridas e discutidas no painel de Issues do GitHub — ali interagimos bastante para ajudar a tornar essas análises e coletas de dados relevantes.
  • Eles pegam os datasets disponíveis (da CEAP) e fazem análises exploratórias tentando descobrir mais padrões de gastos suspeitos, além dos classifiers que a Rosie já tem, ou tudo gira em torno dos classifiers existentes?
    Os dois, mas novas ideias surgem no painel de issues com mais frequência do que alguém tenta refinar um classificador já implementado.
  • Encontrando algo, os voluntários encaminham esses dados para vcs ou antes eles já conseguem testar algo com a Rosie?
    Como tudo que fazemos é com código aberto eles compartilham com a gente utilizando um Pull Request: uma sugestão de código novo a ser incluído no repositório. Em outras palavras eles já compartilham o que acharam, bem como o código que implementa isso. Quando achamos relevante fazemos a revisão de código para aprimorar a contribuição e logo isso entra para nossos repositórios. O interessante é que a contribuição não é com dados (no sentido de datasets), mas com código que transforma esses dados em informação.

JARBAS

  • Vendo as tecnologias que o Jarbas usa (Python 3.5, Yarn, PostgreSQL 9.4+, AMAZON AWS e Google Analytics) como vocês chegaram a conclusão de que deveriam utilizar essas tecnologias? Performance? Custo?
    Python
    : performance e frameworks consolidados para aplicações web, mas também era a mesma linguagem utilizada nos outros repositórios (ou seja, evitava incluir mais uma linguagem no nosso ambiente). E Python 3.5 por se tratar do ano de 2016, 2017…
    Yarn: quando se fala em Yarn no Jarbas provavelmente deve estar querendo se referir a Elm. Elm é uma linguagem excelente para front-end e queríamos testá-la. Gostamos e ficou. Yarn é só uma forma de automatizar a compilação de Elm para JavaScript. Começamos compilando isso diretamente pelo Django com o webassets, depois separamos competências para deixar as coisas mais independentes (quem contribui com front-end não precisa do stack de backend). Aí entrou primeiro compilação pelo npm scripts e depois pelo Yarn, que é mais rápido para gerenciar os pacotes.
    PostgreSQL: Melhor banco de dados do mundo que funciona nativo no Django. Django foi escolhido pela facilidade de gerar uma API para dados públicos com o Django REST Framework.
    Amazon AWS: Não usamos nada da Amazon AWS no Jarbas. Ele é hospedado na Digital Ocean — que nos cedeu uma máquina virtual para o projeto como forma de apoio ao projeto.
  • O que vocês esperam com a liberação ao acesso das informações da CEAP com o API tapioca-jarbas?
    A tapioca-jarbas não foi uma escolha nossa, nem é um projeto nosso. Isso veio da comunidade, mais precisamente o Danilo Roberto Shiga contribuiu com o projeto. No geral a ideia dos wrappers da tapioca é facilitar que a comunidade Python use a API.
  • Com a possibilidade do Jarbas mostrar os dados vindos da Rosie daqui um tempo, serão mostradas as probabilidades de fraude ou só os casos comprovados de reembolsos indevidos?
    A Rosie ainda não fornece ao Jarbas a probabilidade, apenas as suspeitas com verdadeiro ou falso. E isso já está implementado na interface do Jarbas. Se você encontrar um reembolso que é suspeito de acordo com a Rosie, na interface do Jarbas já aparece qual classificador (qual hipótese) levanta a suspeita. Já casos comprovados de reembolsos indevidos são removidos do Jarbas, pois o reembolsos indevidos são removido do sistema da Câmara.

Essas foram algumas de nossas observações técnicas, um pouco do que decidimos sobre como fazer nosso projeto.


Quer contribuir? Comece por aqui. Além disso você pode fazer com que a Operação Serenata de Amor continue à todo vapor. Continue seguindo a gente!