Estimacao de Metricas de Complexidade Financeira

Descrição do problema

Após reuniões com a equipe técnica da Sefic, alguns dos gargalos observados ao longo do ciclo de vida completo de um projeto cultural foram:

• Análise de Objeto
• Análise Financeira
• Tempo de parecer/aprovação

Dentre esses, o que aparenta ser o maior problema atualmente é a prestação de contas no Minc. Esse problema ocorre, principalmente, pelo fato de ser demorado para avaliar os comprovantes de cada um dos projetos e verificar se os projetos realmente cumpriram o que foi determinado pelas Instruções Normativas. Hoje, Há cerca de 17 mil projetos já executados pela lei de incentivo e que ainda não foram avaliados.

Uma possível solução para amenizar este problema seria o desenvolvimento de um sistema que recomenda quais projetos aparentam ser mais complexos para serem avaliados, além de recomendar itens da planilha que fogem dos padrões.

Hipótese

Hipótese Global

Considerando que não há dados suficientes para que possamos identificar projetos como problemáticos ou de boa qualidade, foi definido que a equipe trabalharia com a hipótese de anomalia.

A hipótese levantada é de que projetos anômalos, ou seja, que são diferentes da maioria do mesmo segmento, tem uma grande chance de serem mais complexos, mais difíceis de serem avaliados.

Mesmo que essa hipótese pudesse ser inválida, seria uma etapa relevante para desenvolvimento de melhores soluções.

Para avaliar a hipótese global, definiu-se que a anormalidade de projetos poderia ser avaliada em várias dimensões. Uma das possibilidades seria analisar a normalidade com relação a:

1. Aspectos Financeiros do projeto.
2. Proponentes responsáveis pelo projeto.
3. Fornecedores de um dado projeto.
4. Aspectos Temporais do ciclo de vida do projeto.
5. Serviços.

Hipótese Específica

Atacamos primeiramente a dimensão financeira. As features/características levantadas para a avaliação até o momento foram:

• Total do número de itens.
• Total do valor captado do projeto.
• Total do valor comprovado do projeto.
• Total do valor aprovado do projeto.
• Número de comprovantes do projeto.
• Porcentagem de itens do projeto em relação a distribuição dos itens mais comuns para aquele segmento ou area.
• Número de projetos já enviados por aquele proponente ou outros “escritores” da proposta.
• Porcentagem ou distribuição dos fornecedores do projeto em relação a fornecedores já conhecidos.
• Porcentagem de itens acima da mediana histórica, média do desvio da mediana, ou o próprio vetor de diferença em relação a mediana.

Todas essas métricas foram escolhidas por meio de brainstorms tendo em mente que precisávamos de critérios objetivos que identificassem os projetos.

A partir disso, foi levantada a hipótese de que projetos anômalos com relação a essas features são projetos de difícil análise no âmbito financeiro, ou seja, alta complexidade financeira.

Assumindo essa hipótese como verdadeira, a avaliação da complexidade pode ser realizada por meio de algoritmos de detecção de anomalias (outlier detection).

Solução

A solução desenvolvida considera que deseja-se construir um sistema de informação/recomendação, para auxiliar a avaliação e tomada de decisão dos analistas. Dessa forma, essas métricas deveriam ser avaliadas não só em conjunto mas também de forma individual.

Portanto, a solução definida gera uma score/nota para avaliar o quão um projeto é diferente dos demais levando em conta cada uma das métricas individualmente e todas as métricas em conjunto.

A avaliação individual de cada métrica é util para mostrar ao avaliador no que ele deveria focar ao analisar um projeto específico, ou seja, guia-lo na análise. Já a avaliação geral do projeto é útil como um indicador do projeto como um todo, e pode ser usado como critério para alocação dos avaliadores de projetos.

Na primeira solução foram utilizadas ferramentas estatísticas para identificação de similaridade. Foi feita uma análise baseada em Gaussiana.

Resultados

Os resultados obtidos permitem identificar projetos anômalos, mas isso não generaliza bem para a identificação de projetos problemáticos ou complexos. Os resultados obtidos até hoje, porém, são bastante úteis para o desenvolvimento de sistemas mais complexos.

Algumas das avaliações feitas que evidenciem o que foi dito pode ser vista no seguinte documento Avaliação do SALIC ML.

Neste documento citamos que dentre os 15 projetos com o maior número de diligencias, 4 foram considerados como tendo um nível muito baixo de complexidade pelo SALIC-ML. Ou seja, cerca de 25% dos projetos com alta complexidade foram avaliados de forma totalmente incorreta pelo sistema.

Além disso, alguns projetos denunciados pela mídia por corrupção como ‘Minha Cidade’ e ‘Caminhos Sinfônicos’ foram avaliados como projetos muito bons pelo sistema.

Conclusão

Percebe-se, portanto, que apesar de demonstrar alguns resultados interessantes, o sistema está em um estado inicial, experimental e precisa ser evoluído.

Apesar dos problemas encontrados, o produto desenvolvido e o conhecimento adquirido são muito úteis para o aprimoramento do sistema. Com mais tempo acredita-se que será possível obter melhoras significativas.

Possíveis evoluções

Uma melhoria que será aplicada ao longo do tempo é o aumento da quantidade e da qualidade das features utilizadas.

Outra evolução bastante relevante é utilizar algoritmos de detecção de anomalia mais adequados para o contexto em que estamos trabalhando.

Apesar dessas evoluções serem úteis, a principal melhoria do sistema seria obtida ao aplicar algoritmos supervisionados de aprendizagem de máquina. Para isso acontecer seria necessário um ser humano avaliar os projetos previamente e dar uma nota e essa nota seria utilizada para treinar o sistema. Dessa forma, o sistema poderia estimar qual seria a nota dada por um analista a um determinado projeto.

---

Detalhes da solução

Dados utilizados

Todos os dados utilizados podem ser obtidos ao executar as queries SQL contidas na pasta “data/scripts” do repositório Salic-ML. Para cada uma das métricas serão descritos os dados utilizados.

Origem no Banco de Dados

Total do número de itens

---

Para obter o número total de itens de um projeto, basta consultar a tabela SAC.dbo.tbPlanilhaAprovacao. O projeto pode ser identificado pelo IdPRONAC.

O identificador de um item é idPlanilhaItem, e o nome do item correspondente pode ser obtido a partir da tabela SAC.dbo.tbPlanilhaItens.

Para construir esta métrica basta identificar quantos itens cada projeto possui.

---

Total do valor captado do projeto

---

A tabela utilizada para a obtenção de dados que se referem a captação de recursos foi a SAC.dbo.Captacao.

O projeto pode ser identificado utilizando-se os campos AnoProjeto e Sequencial.

Para construir esta métrica basta somar todos os valores captados.

---

Total do valor comprovado do projeto

---

As tabelas necessárias para verificar o valor comprovado de um projeto são BDCORPORATIVO.scSAC.tbComprovantePagamentoxPlanilhaAprovacao e SAC.dbo.tbPlanilhaAprovacao.

Através da tbPlanilhaAprovacao é possível identificar os ítens de um projeto a partir do seu idPlanilhaItem(e o nome do item em SAC.dbo.tbPlanilhaItens).

Para cada item, pode-se obter o comprovante correspondente utilizando a chave primária de tbPlanilhaAprovacao (idPlanilhaAprovacao). Com o idPlanilhaAprovacao é possível fazer uma query na tabela tbComprovantePagamentoxPlanilhaAprovacao e obter o valor comprovado de cada item (coluna vlComprovado).

Caso deseja-se obter o comprovante de pagamento, pode-se utilizar o idComprovantePagamento para realizar uma consulta na tabela BDCORPORATIVO.scSAC.tbComprovantePagamento.

Para construir essa métrica basta somar os valores comprovados de cada item de um dado projeto.

---

Total do valor aprovado do projeto

---

Para obter o valor aprovado de um projeto, basta consultar a tabela SAC.dbo.tbPlanilhaAprovacao. O projeto pode ser identificado pelo IdPRONAC.

O identificador de um item é idPlanilhaItem, e o custo total de cada item pode ser definido por: vlUnitario, qtItem, nrOcorrencia, qtDias.

Dessa forma, para calcular o valor aprovado do projeto basta calcular o que foi aprovado para cada um dos itens (considerando a quantidade).

---

Número de comprovantes do projeto

---

As tabelas necessárias para verificar o número de comprovantes de um projeto são BDCORPORATIVO.scSAC.tbComprovantePagamentoxPlanilhaAprovacao e SAC.dbo.tbPlanilhaAprovacao.

Através da tbPlanilhaAprovacao é possível identificar os ítens de um projeto a partir do seu idPlanilhaItem(e o nome do item em SAC.dbo.tbPlanilhaItens).

Para cada item, pode-se obter o comprovante correspondente utilizando a chave primária de tbPlanilhaAprovacao (idPlanilhaAprovacao). Com o idPlanilhaAprovacao é possível fazer uma query na tabela tbComprovantePagamentoxPlanilhaAprovacao e obter informações referentes a comprovação de cada item.

Caso deseja-se obter o comprovante de pagamento, pode-se utilizar o idComprovantePagamento para realizar uma consulta na tabela BDCORPORATIVO.scSAC.tbComprovantePagamento.

Para construir essa métrica basta verificar o número de entradas na tabela tbComprovantePagamentoxPlanilhaAprovacao para um projeto, ou seja, para cada um dos itens pertencentes a um projeto.

---

Porcentagem de itens do projeto em relação a distribuição dos itens mais comuns para aquele segmento ou area

---

Para a obtenção dessa métrica são utilizadas duas tabelas. A tabela SAC.dbo.tbPlanilhaAprovacao é utilizada para identificar os itens de um projeto e a tabela SAC.dbo.Projetos é utilizada para identificar qual é a área ou segmento de um dado projeto.

O identificador de um item é idPlanilhaItem, e o nome do item correspondente pode ser obtido a partir da tabela SAC.dbo.tbPlanilhaItens.

Para construir esta métrica deve-se primeiramente avaliar os itens comuns em cada segmento e, posteriormente, compara os projetos de um dado segmento com os demais do mesmo segmento.

---

Número de projetos já enviados por aquele proponente ou outros “escritores” da proposta

---

O campo CgcCpf da tabela SAC.dbo.Projetos pode ser utilizado para identificar todas o proponente de cada projeto. Dado o CgcCpf de um dado proponente, basta fazer uma consulta nesta tabela. Porém, é recomendado que sejam filtrados os projetos obtidos nessa consulta. Dessa forma que somente projetos com pelo menos um item aprovado ou algum item comprovado, por exemplo, sejam levados em consideração.

---

Porcentagem ou distribuição dos fornecedores do projeto em relação a fornecedores já conhecidos

---

As tabelas utilizadas para verificar os fornecedores de um projeto são BDCORPORATIVO.scSAC.tbComprovantePagamentoxPlanilhaAprovacao, BDCORPORATIVO.scSAC.tbComprovantePagamento, Agentes.dbo.Agentes, Agentes.dbo.Nomes e SAC.dbo.tbPlanilhaAprovacao

Através da tbPlanilhaAprovacao é possível identificar os ítens de um projeto a partir do seu idPlanilhaItem(e o nome do item em SAC.dbo.tbPlanilhaItens).

Para cada item, pode-se obter o comprovante correspondente utilizando a chave primária de tbPlanilhaAprovacao (idPlanilhaAprovacao). Com o idPlanilhaAprovacao é possível fazer uma query na tabela tbComprovantePagamentoxPlanilhaAprovacao e obter informações referentes a comprovação de cada item.

Posteriormente, pode-se utilizar o idComprovantePagamento para realizar uma consulta na tabela BDCORPORATIVO.scSAC.tbComprovantePagamento e obter o idFornecedor.

Utilizando o idFornecedor, é possível consultar o CNPJ/CPF e algumas outras informações de um fornecedor pela tabela Agentes.dbo.Agentes usando o campo idAgente (idAgente=idFornecedor).

O nome do fornecedor pode ser obtido por meio da tabela Agentes.dbo.Nomes. Basta procurar por um idAgente igual ao idFornecedor.

---

Porcentagem de itens acima da mediana histórica, média do desvio da mediana, ou o próprio vetor de diferença em relação a mediana

---

Para desenvolver essa métrica basta verificar o valor de cada item de cada projeto. Após fazer isso, compara-se os valores dos itens de um projeto como os demais.

Para obter o valor de cada item basta consultar a tabela SAC.dbo.tbPlanilhaAprovacao. O projeto pode ser identificado pelo IdPRONAC.

O identificador de um item é idPlanilhaItem, e o valor unitário de cada item pode ser definido por vlUnitario.

---

Algoritmos utilizados

Gaussiana

O uso da Gaussiana é interessante quando a distribuição dos dados é aproximadamente normal. Dessa forma, a detecção de outliers baseado nela foi feita da seguinte forma:

Inicialmente, para uma dada métrica que pode ser representada por valores numéricos, verifica-se a média e o desvio padrão da distribuição. A partir dessas duas informações é possível montar a Gaussiana que mais se aproxima da distribuição a ser avaliada.

Dada uma nova realização, verifica-se se ela se encontra próximo do centro ou da calda da Gaussiana. Quanto mais próximo da calda, mais provável que o dados sendo avaliado seja outlier. Dessa forma, define-se um threshold a partir do qual todos os pontos entre o (threshold x desvio padrão) e o final da calda da Gaussiana são considerados outliers.

Na prática, basta definir o threshold. Se o novo dado for maior que a (média + (threshold x desvio padrão)) ou menor que (média - (threshold x desvio padrão)) ele é outlier.

Local Outlier Factor (LOF)

O LOF é baseado no conceito de densidade local. Ele utiliza-se dos k vizinhos mais próximos para calcular a distancia entre um ponto e os demais e utilizar essa distância para estimar a densidade local.

Ao comparar as densidades locais de um objeto aos seus vizinhos, é possível identificar regiões de maior e menor densidades. Os objetos que estão em regiões de menor densidade são os definidos como Outliers pelo algoritmo.

Link para notebooks que avaliam alguns métodos para a detecção de anomalia de cada métrica:

Os notebooks utilizados para essas avaliações estão em:

https://github.com/lappis-unb/salic-ml/tree/master/notebooks/report

Os nomes seguem o padrão ‘analysis_of_xxxxx’.