Pesquisas exploratórias
Pesquisas exploratórias
Embedded Files
Após a decisão do tema, começamos a nos munir de informações.
Mergulhamos em dados, estatísticas e estudos oficiais para entender de perto o impacto da diabetes na sociedade. Descobrimos números alarmantes, como os mais de 13 milhões de brasileiros vivendo com a condição, e os riscos silenciosos do pré-diabetes — uma fase ainda reversível, mas pouco percebida. A cada leitura, ficava mais claro: não estamos lidando apenas com uma patologia, mas com um problema de saúde pública urgente, que exige informação democratizada, tecnologia inteligente e ação preventiva. E foi com esse senso de responsabilidade que demos nossos primeiros passos. Nossas pesquisas se encontram no nosso google drive, que está linkado nesse site na aba Repositório.
Escolha da base de dados
Escolha da base de dados
Para garantir a qualidade e a utilidade do nosso modelo, analisamos diversas bases de dados disponíveis publicamente. Após uma avaliação criteriosa, optamos pelo Diabetes Health Indicators Dataset, do Kaggle. Esta escolha se deu por três principais motivos: quantidade, qualidade e aplicabilidade dos dados.
Com mais de 250 mil registros, a base nos proporciona volume suficiente para treinar um modelo robusto e confiável. Além disso, ela conta com 22 variáveis explicativas que refletem informações simples e acessíveis — como hábitos alimentares, prática de atividades físicas e acesso à saúde — possibilitando que qualquer pessoa consiga interagir com a solução sem precisar de exames laboratoriais prévios.
Diferente de outras bases analisadas, que eram menores ou exigiam dados clínicos de difícil acesso, essa base nos permite criar um modelo realmente preventivo e inclusivo, com destaque para a identificação de pré-diabetes, uma etapa reversível e essencial para a conscientização do usuário.
Essa escolha reflete nosso compromisso com uma abordagem educativa, acessível e responsável, alinhada ao objetivo principal do Endo.AI: estimular o cuidado ativo com a saúde antes que os sintomas apareçam. O link para a nossa base de dados se encontra na aba Repositório, no link para o Kaggle.
Um outro diferencial importante da base de dados escolhida, é a ausência de dados nulos, reforçando sua robustez.
Análises:
Análises:
Aqui mostraremos algumas análises que nos levaram a insights interessantes e influenciaram o desenvolvimento do projeto:
Matriz de Confusão
Matriz de Confusão
Esta matriz de confusão mostra o desempenho do modelo KNN (k=5) na classificação de pessoas em três categorias: não diabético, pré-diabético e diabético.
O modelo identificou corretamente a maioria dos não diabéticos.
A classificação de pré-diabéticos continua difícil, com muitos sendo confundidos como não diabéticos.
Para diabéticos, o modelo obteve resultados razoáveis, acertando 2.061 casos, mas ainda cometendo erros importantes, principalmente classificando diabéticos como não diabéticos.
Matriz de Confusão
Matriz de Confusão
Esta matriz de confusão mostra o desempenho do modelo KNN (k=7) na classificação de pessoas em três categorias: não diabético, pré-diabético e diabético.
O modelo identificou corretamente a maioria dos não diabéticos.
Houve grande dificuldade na identificação de pré-diabéticos, que foram frequentemente confundidos com não diabéticos.
Para diabéticos, o modelo teve bons resultados, mas ainda com alguns erros, principalmente classificando-os como não diabéticos.
Curva de Aprendizado
Curva de Aprendizado
O gráfico apresenta a curva de aprendizado do modelo KNN (k=3), mostrando a evolução da acurácia no conjunto de treino e de validação conforme o tamanho dos dados de treino aumenta.
A acurácia do treino é alta e se mantém próxima de 96% conforme mais dados são usados.
A acurácia de validação também cresce com mais dados, chegando próxima de 93%.
A diferença entre treino e validação diminui ligeiramente, indicando que o modelo está generalizando melhor com conjuntos de treino maiores.
O comportamento sugere que o modelo se beneficia de mais dados, e que não há overfitting severo.
Alguns insights importantes:
Matrizes de confusão:
Verificamos a partir das matrizes que havia um desbalanceamento entre classes muito grande no data set. A quantidade de não diabéticos era muito maior que a de diabéticos e pré-diabéticos dentro da base de dados. O que nos foi importante para optarmos por, em vez de tirar uma amostra aleatória, deveriámos balancear os dados. Para tanto, utilizamos as técnicas de Undersampling e Oversampling, tendo um resultado mais satisfatório nas métricas do Oversampling.
Curva de aprendizado:
A curva de aprendizado mostra que o modelo KNN melhora sua acurácia conforme aumenta o volume de dados de treino, indicando maior confiabilidade nas previsões com conjuntos maiores. No entanto, um ponto negativo foi o tempo elevado para a execução dessa análise: a previsão levou, em média, 12 minutos e 53 segundos. Além disso, o gráfico evidenciou a necessidade de equilibrar melhor as classes no conjunto de dados, pois o forte desbalanceamento inicial, especialmente entre pessoas diabéticas e não diabéticas, impactava negativamente na qualidade das análises.
Dificuldades enfrentadas (SR2):
Dificuldades enfrentadas (SR2):
O primeiro desafio foi o tempo de processamento necessário para construir os modelos KNN. Como estávamos utilizando o Google Colab, que possui recursos limitados, e o dataset era bastante extenso, o treinamento dos modelos se tornava extremamente demorado. Para contornar essa limitação, optamos por processar os dados localmente, utilizando o Jupyter Notebook em nossos próprios computadores, o que aumentou significativamente a velocidade de execução.
O segundo problema ocorreu na distribuição dos modelos KNN entre os integrantes da equipe e, futuramente, para os usuários da aplicação via GitHub. Devido ao grande tamanho dos arquivos, o repositório do GitHub não suportava o upload direto (via git push). Tentamos utilizar o GitHub LFS, o que resolveu temporariamente a situação, mas rapidamente atingimos o limite de transferência de dados, inviabilizando essa abordagem. Como solução definitiva, armazenamos os modelos no Google Drive e incluímos no read-me do repositório do GitHub um link com instruções claras sobre como e onde os arquivos devem ser colocados localmente.
Por fim, enfrentamos dificuldades na comunicação entre o Front-end e Back-end, especialmente na previsão do modelo KNN (que retornava apenas valores extremos (100% ou 0%)). Analisando o que poderia estar causando esse problema, chegamos na resposta: os dados não estavam sendo enviados corretamente do front-end para o back-end. O problema foi resolvido corrigindo os tipos das variáveis que estavam sendo enviadas do front end, garantindo que estivessem no tipo e formatação esperadas pelo back end. Após resolver esse problema, e para garantir uma maior integridade ao nosso projeto, decidimos aplicar testes automatizados tanto no front quanto no back-end, para garantir que os dados estavam sendo enviados e recebidos corretamente.
Relatório Técnico
Relatório Técnico
Disponibilizamos um relatório completo que descreve o funcionamento da nossa aplicação, incluindo:
Modelo KNN: Explicação sobre como foram implementados os modelos KNN.
Back-end: Linguagem, tecnologias utilizadas e fluxo de processamento.
Front-end: Interface do usuário, interações e integração com o back-end.
Entregáveis SR2:
Page updated
Report abuse