RELATÓRIO DE CUMPRIMENTO DO OBJETO ETAPA V Abril
title: RELATÓRIO DE CUMPRIMENTO DO OBJETO ETAPA IV - Ecossistemas de Software Livre - Abril 2019 author: Carla Silva Rocha Aguiar (Coordenadora do Projeto) date: 28 de abril de 2019 geometry: "left=3cm,right=3cm,top=2cm,bottom=2cm" colorlinks: true
O presente relatório apresenta o acompanhamento do trabalho realizado no projeto "Ecossistemas de Software Livre", Termo de Cooperação para Descentralização de Crédito, Processo Ofício No 0646/2017/FUB-UnB, Vigência Outubro 2017 à Outubro 2019. O relatório apresentado é referente aos avanços realizados na Etapa IV (Outubro 2018 à Janeiro 2019), de acordo com o cronograma do Plano de Trabalho.
Toda alteração no cronograma proposto foi realizada a partir de renegociação com a CGTEC do Ministério da Cultura, e tais alterações estão descritas no relatório.
O período de Outubro 2018 à Janeiro 2019 contemplou as fases de planejamento e execução. Abaixo serão apresentados, brevemente, os principais avanços alcançados no período. Toda a documentação e acompanhamento do projeto está disponibilizado e pode ser acessado na organização do laboratório lappis-unb, e no repositório específico do projeto lappis-unb/EcossistemasSWLivre. Todo o planejamento e execução das tarefas podem ser acompanhados tanto nas issues quanto nas páginas wiki.
Abaixo serão apresentados os principais avanços alcançados no período, por pacote de trabalho (de acordo com o Plano de Trabalho), de acordo com o cronograma, no período citado.
O objetivo principal deste período foi a melhoria da inteligência da Tais e aumento do seu conhecimento.
- Estudo das estruturas internas do Rasa
- Teste de parâmetros do Rasa
- Atualização do Rasa
- Cadastro de novas perguntas e respostas
- Melhoria das respostas já cadastradas
- Ambiente de produção
- Integração entre o Rasa e Rocketchat
- Estudo das estruturas internas do Rasa
- Levantar possíveis algoritmos implementados no rasa
- Investigar quais cabem no nosso contexto
- Utilizar e testar os algoritmos alterando as estruturas de conversa necessárias
- Teste de parâmetros do Rasa
- Levantar parâmetros dos algoritmos
- Testar diferentes parâmetros para identificar os que dão os melhores resultados
- Atualização do Rasa
- Atualizar o rasa para a versão 11
- Evolução do connector com o rocketchat
- Reestruturar os containers para comportar a atualização
- Cadastro de novas perguntas e respostas
- Levantamento dos conhecimentos pendentes da Taís
- Priorização dos conhecimentos
- Estruturação do conhecimento em perguntas e respotas
- Cadastro das perguntas e repostas
- Teste do novo conhecimento
- Melhoria das respostas já cadastradas
- Revisão dos textos escritos
- Melhoria das perguntas e textos de repostas
- Ambiente de produção
- Configuração dos livechat na página inicial da lei rouanet
- Integração entre o Rasa e Rocketchat
- Desenvolvimento do tracker store para o elasticsearch
- Levantamento da stack do elasticsearch
- Configuração do elasticsearch
- Elaboração da vizualizações no kibana
Na reunião de planejamento estratégico foram estabelecidos os seguintes objetivos:
- Integrar o ML no Salic
- Colocar o ML em produção
- Monitorar a ML em produção
- Evoluir a acurácia dos modelos
- Formalizar o plano de Entrega Continua - modelo workshop
- Sistema de Recomendação com base em Indicadores de Complexidade
- Sistema de Recomendação com base na Recomendação de projetos similares
A primeira versão do relatório de complexidade foi completada no final de Outubro. Estável o suficiente para iniciar a integração com o SALIC. Esse serviço acessa o banco de dados do Salic tanto para realizar o treinamento dos modelos, quanto para estimar as métricas dos projetos. Foi diagnosticado pela CGTEC um alto volume de requisições ao banco do salic (pois além do salic, o versalic também acessa o banco). Por esse motivo, além da sobrecarga de tarefas urgentes ocupou a equipe de técnicos da CGTEC, a subida em produção foi adiada. Com isso, todas as atividades relacionadas foram colocadas em espera.
Realizamos uma série de estudos para testar distribuições de probabilidade que gerassem modelos de "estereótipo vs. outlier" mais precisos. Definimos o limiar de outlier em 5% e comparamos as seguintes distribuições de probabilidade: Log-Normal, Gammma, KDE-Gauss com a distribuição gaussiana usada até então. Tudo isso em conjunto com o algoritmo de comparação "Lof".
De forma geral, KDE-Gauss foi a mais precisa porém alguns indicadores de complexidade renderam resultados mais precisos com outras distribuições. O detalhe dos estudos para cada métrica está disponível aqui:
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_approved_funds.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_common_items.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_common_items.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_items_price.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_items_receipts_ratio.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_new_providers.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_number_of_items.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_number_of_receipts.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_proponent_projects.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_raised_funds.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_verified_and_raised_funds_ratio.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/analysis_of_verified_funds.ipynb
O próximo passo é implementar as técnicas identificadas nesses estudos na ferramenta de diagnóstico de complexidade.
5. Formalizar o plano de Entrega Continua - modelo workshop e 6. Sistema de Recomendação com base em Indicadores de Complexidade
A dinâmica de entrega contínua funcionou particularmente bem com os dois workshops realizados onde pudemos apresentar as evoluções parciais à equipe da SEFIC e validar a fundo estas evoluções.
Ficou clara a necessidade de separar o diagnóstico de complexidade em duas partes: complexidade da análise de resultado, com a maioria das métricas trabalhadas até então, e saúde do projeto, com métricas que fazem mais sentido na fase de acessibilidade.
Nos aprofundamos na complexidade da análise de resultado, refatorando e recombinando algumas métricas. Também identificamos uma nova métrica, que considera a quantidade de comprovantes para cada tipo de transação financeira realizada durante a execução. A versão mais recente da página de diagnóstico contém as seguintes métricas:
Tivemos também a oportunidade de identificar dimensões que podem ser parametrizadas para acelerar a análise de objeto. Essas dimensões serão investigadas nas próximas etapas do projeto.
Iniciou-se o desenvolvimento de uma ferramenta que busca, dado um projeto cultural apto a ser analisado financeiramente, retornar um conjunto de projetos (já analisados) que sejam similares a este. O propósito é fornecer de forma fácil ao técnico as experiências passadas de análise em projetos parecidos.
Para isto, desenhou-se um roadmap de construção da ferramenta, a qual inicia na definição do "estereótipo" de um projeto: um vetor contendo dados característicos como segmento, produto cultural principal, resumo do projeto, título, itens culturais, etc. Construído o vetor de características / estereótipo de um projeto, pode-se buscar os projetos mais similares entre si.
Finalizou-se com a construção de protótipos, em notebook Python, que testam diferentes vetores de features dos projetos e calculam a similaridade entre eles, usando medidas de similaridade coerentes com os dados levantados. Estes protótipos darão base à ferramenta definitiva na API.
Documentação relacionada:
- https://github.com/lappis-unb/salic-ml/wiki/Um-algoritmo-de-detec%C3%A7%C3%A3o-de-similaridade-de-projetos---Roadmap
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/doing/projects_similarity_feature_engineering.ipynb
- https://github.com/lappis-unb/salic-ml/blob/master/notebooks/report/textual_features.ipynb
Conforme acordado com os gestores da SEFIC, o foco da frente de visualização de dados até o final do projeto é a adaptação de todos os relatórios disponíveis no Portal Comparar. Esta release iniciou a transição dos estudos de protótipos de visualização para a adaptação dos primeiros relatórios do portal Comparar.
- Concluir protótipos iniciados na fase de estudos
- Avaliação de usabilidade intrínseca dos protótipos
- Análise do portal Comparar e início da adaptação dos relatórios.
Tomando como base os resultados da análise que fizemos do portal Comparar, foi identificado que o relatório CAPTAÇÃO DE RECURSO POR UF - DESDE 1992, seria o mais viável com base nos dados disponíveis na API do SALIC, bem como com os protótipos já criados.
Relatório de análise do portal Comparar
Com isso, foi desenvolvida uma nova visualização Mapa de Captação, contendo as dimensões do relatório escolhido. Também identificamos os relatórios de Projetos apresentados por ano, região e uf, Projetos apresentados por ano, área e segmento cultural e Projetos apresentados por ano, região e uf, área e segmento cultural como os próximos a serem adaptados.
Em paralelo, a análise de usabilidade identificou algumas dezenas de problemas, sobretudo relacionados à clareza de compreensão dos detalhes como rótulos e legendas. Estes problemas foram priorizados (#204, #205, #206, #207 e #208) e serão resolvidos à medida que os protótipos forem adaptados à novas visualizações.
1. Concluir protótipos iniciados na fase de estudos
Finalizamos algumas pendências da release anterior que eram importantes para considerar que a etapa de prototipagem estava conluída de fato.
- Estudo Mobile para protótipo de deslocamento (#161)
- Incrementar página principal da biblioteca de protótipos (#181)
2. Avaliação de usabilidade intrínseca dos protótipos
Visto que a partir desta release os protótipos começariam a ser adaptados para visualizações em ambiente de produção, realizamos uma série de estudos de usabilidade e acessibilidade para identificar possíveis problemas de experiência que precisariam ser corrigidos antes da entrada em produção.
Além disso, as visualizações precisam atender os padrões governamentais de acessibilidade tanto para a versão desktop quanto para a versão mobile. Todos os problemas foram mapeados em issues, conforme mencionado acima. Do ponto de vista interno do Laboratório, essas atividades permitiram um primeiro contato dos bolsistas de design com atividades de avaliação de usabilidade.
- Revisão de protótipos de acordo com as normas de acessibilidade do Governo Federal e do W3C (#193)
- Redefinir contrastes da paleta de cores da plataforma (#192)
- Avaliação heurística da versão Desktop dos protótipos (#202)
- Avaliação heurística da versão Mobile dos protótipos (#210)
- Estudo sobre melhores formas de disposição de ícones do mapa (#106)
3. Análise do portal Comparar e início da adaptação dos relatórios
Esta atividade foi o cerne da entrega. Fizemos um longo trabalho de análise do portal Comparar para entender o tamanho do escopo e o conteúdo dos relatórios. Em seguida, fizemos a correspondência entre o portal Comparar e a realidade do material do Promova Cultura: tanto a API do SALIC quanto os protótipos de visualização disponíveis. O intuito foi de encontrar quais relatórios poderíamos adaptar e disponibilizar no tempo mais curto possível.
Depois da análise concluímos que nenhum relatório do portal Comparar tem dados 100% disponíveis na API. Optamos por ajustar a visualização primeiro e evoluir a API em seguida.
- Análise de todos os relatórios disponíveis no portal Comparar (#191)
- Identificar relatórios do Comparar mais próximos aos protótipos criados pela equipe (#200)
- Início da adaptação do relatório "Proponente - Captação de recursos por UF" (#209 e #217)
- Mapeamento de mudanças necessárias na API para suportar o relatório "Proponente - Captação de recursos por UF" (#219)