Classificador Epidemiológico de Arboviroses

Estado inicial dos dados SINAN

É preciso esclarecer uma coisa importante, existe um termo chamado: "GIGO", que representa a ideia de "lixo entra, lixo sai", isso é interessante para denotar a relevância de um tratamento coerente dos dados vindos do SINAN. Antes do tratamento, os dados possuíam vários problemas, que iriam dificultar tanto uma análise de dados quanto a realização coerente do pipeline de machine learning. Entre esses problemas estavam diversas colunas sem utilidade para predição.

Essas colunas poderiam fazer um "vazamento" da classificação ou apenas não ajudar na classificação pelo próprio conceito da coluna. Também havia campos vazios ou marcados como ignorados, além disso, cada ano mostrava um padrão diferente em algumas colunas, e após o ano de 2021, não aparece dados com a classificação de "Descartado para Arbovirose X", por isso apenas até esse ano foi feita a extração de dados e uso para teste.

Seleção dos anos

• Os anos de 2014 a 2016 tinham sintomas ausentes ou incompletos.
• Utilizá-los poderia fazer o modelo aprender diferenças de preenchimento, e não diferenças entre casos confirmados e descartados.
• Por isso, o treinamento foi feito com os dados mais consistentes, de 2017 a 2019.
• O ano de 2020 foi separado para ajustar as decisões dos modelos.
• O ano de 2021 foi deixado para a avaliação final.

Classificação dos casos

• Os códigos originais da classificação foram simplificados em dois grupos: confirmado e descartado.
• Casos sem conclusão ou com classificação inconclusiva não foram usados para ensinar os modelos.
• Assim, cada registro utilizado tinha uma resposta clara sobre aquilo que o modelo deveria aprender.

Sintomas

• Os sintomas foram representados como presentes, ausentes ou não informados.
• “Não apresentou febre” foi mantido como algo diferente de “não sabemos se apresentou febre”.
• Além dos sintomas individuais, foi calculada a quantidade de sintomas presentes.
• Também foi registrada a quantidade de sintomas realmente preenchidos.
• Foram criadas combinações para representar sintomas que aparecem juntos.
• Exantema e dor retro-orbital receberam um resumo específico porque apresentaram diferenças relevantes entre confirmados e descartados.

Tempo e sazonalidade

• Foi calculado o número de dias entre o início dos sintomas e a notificação.
• O mês e a semana epidemiológica foram incluídos porque a circulação da dengue muda durante o ano.
• Essas informações foram transformadas em variáveis cíclicas.
• Isso foi necessário porque o calendário forma um ciclo: dezembro está próximo de janeiro, mesmo que numericamente 12 pareça distante de 1.
• A mesma lógica foi aplicada às semanas epidemiológicas.

Informações demográficas e de localização

Características demográficas são um ponto muito importante de tratamento. Para escolaridade foi realizado um agrupamento em níveis semelhantes, e organizados em uma escala crescente, fazendo a variável representar uma progressão desde a escolaridade ausente ou não informada, até níveis mais altos como nível superior, mestrado, doutorado.

• Colunas como sexo, raça e gravidez foram transformadas usando um one-hot encoding, isso permite evitar uma noção de progressão irreal
• Para ocupação como haviam muitas, já que seguiam o CBO, aquelas que tinham baixa quantidade de membros foram agrupadas em "Outros"

Dados de localização foram preservados em: estado, município e região de saúde, isso é útil pois locais diferentes possuem características que podem permitir a proliferação e contaminação com essas arboviroses mais facilmente.

Contexto epidemiológico

Uma das transformações mais interessantes do projeto foi representar oque estava acontecendo no município antes de cada notificação, isso ajuda a entender o "cenário recente" do local em relação circulação recente de arboviroses, para isso foram criadas duas informações principais:

• Volume de notificações no município nas quatro semanas anteriores
• Proporção de casos confirmados nesse mesmo período

A ideia é que os sintomas de uma pessoa podem ganhar significados diferentes dependendo da circulação recente da dengue naquela localidade. Somente semanas anteriores foram consideradas, sem utilizar o resultado do próprio paciente Esse ponto merece uma seção própria porque conecta o tratamento dos dados à lógica epidemiológica do projeto, e foi muito útil para aumentar a capacidade preditiva dos modelos num geral.

Do dado tratado ao conjunto de treinamento

Durante a análise exploratória, percebemos que nenhum grupo de informações era suficiente para representar sozinho a classificação de um caso, os sintomas possuem importância, mas também mudam de significado quando são observados junto à época do ano, ao local da notificação e ao contexto recente do município. Por isso, reuni essas diferentes perspectivas em um mesmo conjunto de 107 features, que se tornou a entrada comum dos modelos de Machine Learning.

O treinamento utilizou 2.874.235 registros de 2017 a 2019, em cada linha o modelo recebia as informações disponíveis sobre a notificação e tentava distinguir os casos confirmados dos descartados. É importante ressaltar que resultados de exames, evolução, encerramento, hospitalização e qualquer outra informação posterior do próprio paciente não fizeram parte das features, pois caso fossem utilizados, o modelo poderia aprender a resposta que deveria prever, criando uma capacidade que não existiria em uma nova triagem.

Também mantive o mesmo esquema de features durante todo o pipeline, isso significa que a ordem, o nome e o tratamento das variáveis usados no treinamento são os mesmos esperados durante uma previsão, algo importante para impedir que os modelos recebam informações organizadas de uma forma durante o treino e de outra quando forem utilizados.

Por que utilizar três modelos diferentes?

Com o conjunto de treinamento pronto, eu poderia escolher apenas um algoritmo e buscar o melhor resultado possível com ele, porém modelos diferentes podem observar padrões diferentes nas mesmas informações. Por isso, selecionei uma rede neural MLP e dois modelos de gradient boosting baseados em árvores, o XGBoost e o LightGBM, os três recebem as mesmas 107 features, mas possuem maneiras diferentes de aprender as relações presentes nos dados.

Essa diferença é útil porque os três modelos não observam os dados da mesma forma, então também não precisam cometer exatamente os mesmos erros. A MLP pode encontrar interações não lineares entre muitas variáveis ao mesmo tempo, enquanto XGBoost e LightGBM constroem sequências de árvores para dividir os registros conforme os padrões encontrados, com isso, cada arquitetura pode contribuir com uma forma diferente de entender o mesmo problema.

Como a MLP aprende com dados tabulares?

Redes neurais são frequentemente associadas a imagens ou textos, porém também podem ser utilizadas com dados tabulares. Nesse projeto, criei uma MLP preparada para lidar separadamente com informações categóricas e numéricas, escolaridade, ocupação, estado, município e região de saúde foram transformados em embeddings, representações menores que permitem à rede aprender semelhanças entre categorias durante o próprio treinamento, em vez de tratar cada código apenas como um número comum.

As features numéricas passaram por uma normalização e depois foram unidas aos embeddings antes de entrar nas quatro camadas ocultas da rede, com 1024, 512, 256 e 128 neurônios. Entre essas camadas utilizei LeakyReLU, Batch Normalization e Dropout, elementos que ajudam a rede a aprender relações complexas, manter o treinamento estável e reduzir o risco de memorizar excessivamente os registros usados no treino, abaixo está a parte principal do código utilizada para montar essa estrutura:

Para treinar a MLP, utilizei o otimizador AdamW e uma função de perda que considera a diferença entre as classes, o aprendizado foi acompanhado no conjunto de validação de 2020 e interrompido quando a rede deixava de melhorar. Com isso, o modelo salvo não era simplesmente o da última época, mas aquele que apresentou o melhor comportamento durante a validação.

XGBoost e LightGBM: duas leituras baseadas em árvores

O XGBoost e o LightGBM pertencem à família do gradient boosting, diferente de uma única árvore de decisão, esses modelos constroem árvores em sequência, fazendo com que cada nova etapa tente corrigir parte dos erros anteriores. Isso é especialmente útil em dados tabulares, em que sintomas, datas, ocupações e localizações podem formar várias combinações difíceis de representar com regras isoladas.

Ainda que os dois utilizem o mesmo princípio, eles não constroem suas árvores exatamente da mesma forma, o XGBoost oferece um processo mais controlado de regularização e crescimento, enquanto o LightGBM foi desenvolvido para treinar com eficiência em conjuntos extensos. Como o projeto possui milhões de registros e mais de uma centena de features, comparar as duas implementações permitiu observar como essas diferenças apareciam na classificação dos casos, abaixo podemos ver a parte do código responsável por criar cada modelo:

Para escolher os hiperparâmetros, utilizei o Optuna sobre amostras estratificadas do treino e da validação, a ferramenta testou diferentes combinações de quantidade e profundidade das árvores, taxa de aprendizado, proporção de linhas e features utilizadas e níveis de regularização. Depois de encontrar a melhor configuração, cada modelo foi treinado novamente com o conjunto completo, sempre usando 2020 para acompanhar o aprendizado e aplicar early stopping quando novas árvores deixavam de trazer melhorias.

O papel da validação temporal

Durante todo esse processo, o ano de 2020 teve uma função diferente dos anos de treinamento. Os dados de 2017 a 2019 foram utilizados para ensinar os padrões aos modelos, enquanto 2020 serviu para comparar configurações, interromper treinamentos no momento adequado e definir como as previsões seriam combinadas, assim, essas decisões foram tomadas observando um período posterior ao treino, mas sem utilizar o conjunto reservado para a avaliação final.

Essa separação foi importante porque uma divisão aleatória misturaria registros de anos diferentes entre treino e validação. Como a circulação da dengue, o preenchimento das notificações e o próprio contexto epidemiológico mudam com o tempo, isso poderia mostrar um resultado melhor do que realmente seria num período futuro, por isso respeitei a ordem dos anos, fazendo o pipeline aprender com o passado para depois classificar novas notificações.

Somente depois de finalizar os modelos, seus hiperparâmetros, os pesos do ensemble e a regra de classificação, o conjunto de 2021 foi carregado para avaliação, assim, seus 940.304 registros não participaram de nenhuma escolha anterior, com isso, o resultado final passou a representar uma avaliação fora do período utilizado para construir o sistema.

Unindo as previsões em um ensemble

Depois do treinamento, cada modelo passou a produzir seu próprio score para um caso, em vez de realizar uma votação simples, combinei esses três valores por meio de uma média ponderada. Os pesos foram definidos a partir do recall de cada modelo na validação de 2020 e depois normalizados, fazendo com que os modelos que encontraram mais casos confirmados nesse período tivessem uma participação ligeiramente maior no resultado conjunto, abaixo está a parte do código que realiza essa combinação:

A ideia do ensemble era aproveitar as diferenças entre os modelos, quando MLP, XGBoost e LightGBM encontram um padrão semelhante, o score conjunto recebe o apoio dos três, quando existe divergência, os pesos ajudam a equilibrar as previsões de acordo com o comportamento que cada modelo apresentou na validação.

Ao final, esse processo entrega um único score de classificação, que ainda precisa ser comparado a um limiar para decidir entre confirmado e descartado. Esse valor não representa uma probabilidade clínica calibrada e não realiza um diagnóstico, a escolha do ponto de operação e o impacto dessa decisão sobre os acertos e erros serão analisados na próxima parte, junto às métricas do modelo.

Abrindo o teste final de 2021

A avaliação foi realizada sobre 940.304 notificações, sendo 484.586 casos descartados e 455.718 casos confirmados, os dois grupos aparecem em quantidades próximas, e como os registros pertencem a um ano posterior ao período de treinamento, o teste se aproxima mais de uma situação real, em que o sistema aprende com dados passados e depois recebe novas notificações no futuro.

Nesse momento, nenhum hiperparâmetro foi alterado, os modelos não foram treinados novamente e o resultado de 2021 não foi utilizado para escolher o limiar. Com isso, as métricas não mostram o melhor ajuste que poderia ser encontrado observando o próprio teste, mas sim o comportamento do pipeline que já estava definido antes de esses registros serem abertos.

A Accuracy mostra que o ensemble acertou pouco mais de sete em cada dez classificações, porém esse valor não deve ser observado sozinho, pois o objetivo do limiar escolhido não era distribuir os erros igualmente, e sim reduzir a quantidade de casos confirmados que seriam ignorados, por isso Precision e Recall precisam ser lidos em conjunto para entendermos qual tipo de erro foi mais aceito pelo sistema.

Com Precision de 66,1%, parte das notificações classificadas como dengue ainda corresponde a casos descartados, enquanto o Recall de 87,3% mostra que a maior parte dos casos realmente confirmados foi encontrada. Esse equilíbrio faz sentido para uma ferramenta de apoio à triagem, pois deixar um caso verdadeiro passar pode ser mais preocupante do que encaminhar um caso adicional para avaliação, embora isso também aumente a quantidade de falsos positivos.

Por que o limiar de 0,30 muda a leitura do modelo?

O ensemble não entrega diretamente as palavras confirmado ou descartado, ele produz um score contínuo e o limiar transforma esse valor em uma classificação. Quando o ponto de corte é reduzido, mais registros passam a ser marcados como positivos, o Recall tende a crescer e menos casos confirmados ficam abaixo do corte, porém a Precision e a especificidade podem diminuir, pois também aumentam os casos descartados enviados para o grupo positivo.

O limiar de 0,30 foi definido utilizando apenas a validação de 2020 e permaneceu congelado antes do teste final, enquanto os modelos individuais mantiveram seus próprios limiares escolhidos no mesmo período, assim, a avaliação de 2021 não foi utilizada para procurar depois o corte que produziria a métrica mais favorável.

Podemos observar que existe uma região em que diferentes limiares produzem valores próximos de F1, por isso, o maior valor isolado dessa métrica não precisa ser a única regra de decisão. No ensemble, o ponto de 0,30 mantém um resultado próximo dos maiores valores e aumenta a sensibilidade, uma escolha coerente com o objetivo de encontrar mais casos confirmados antes da avaliação final.

Lendo os acertos e erros na matriz de confusão

As métricas resumem o comportamento do modelo, mas a matriz de confusão permite observar de onde cada percentual surgiu, separando os acertos sobre casos descartados e confirmados dos dois tipos de erro possíveis, assim, em vez de olhar apenas para a Accuracy, podemos entender quantos registros foram levados para cada lado pelo limiar escolhido.

A principal leitura está na relação entre a linha dos casos confirmados e a linha dos descartados, o quadrante inferior direito mostra os confirmados encontrados, enquanto o superior direito reúne os descartados que também foram enviados para a classe positiva, com isso, conseguimos visualizar por que aumentar o Recall também pode aumentar os falsos positivos.

Essa troca precisa estar clara para quem utiliza o resultado, pois o sistema aceita encaminhar mais registros para o grupo positivo na intenção de reduzir a quantidade de casos confirmados abaixo do limiar, um comportamento que pode ajudar numa priorização, mas que nunca deve ser interpretado como diagnóstico automático.

O ensemble foi melhor em todas as métricas?

Comparar os modelos ajuda a mostrar que não existe apenas uma forma de entender qual foi o melhor, XGBoost e LightGBM alcançaram Accuracy e Precision ligeiramente maiores em seus próprios pontos de operação, enquanto o ensemble, utilizando o limiar de 0,30, abriu mão de parte dessa precisão para encontrar uma proporção muito maior dos casos confirmados.

O gráfico mostra que os modelos alcançaram resultados próximos em várias métricas, enquanto as diferenças aumentam naquelas que dependem do ponto de corte, com isso, o principal papel do ensemble não é superar os outros modelos em todos os resultados, mas combinar suas previsões para entregar o comportamento escolhido para a triagem.

A capacidade de separar os dois grupos

A ROC-AUC observa o modelo em vários limiares, comparando a taxa de verdadeiros positivos com a taxa de falsos positivos, com isso, ela não mostra apenas a decisão tomada em 0,30, mas a capacidade geral de ordenar os casos confirmados acima dos descartados em diferentes pontos de corte.

As curvas quase sobrepostas mostram que os modelos possuem uma capacidade parecida de separar os grupos, e que a diferença mais visível aparece quando os scores são transformados em classes por um limiar, enquanto a Precision-Recall mostra a troca entre encontrar mais confirmados e manter uma maior confiança nas marcações positivas.

Também é importante não confundir ROC-AUC com Accuracy ou com probabilidade clínica, essa métrica resume a ordenação produzida pelo score em diferentes limiares, sem significar que o mesmo percentual de pacientes será classificado corretamente e sem garantir que o valor produzido represente um risco individual calibrado.

Da notificação ao score dos modelos

A página de Triagem reúne as informações disponíveis no momento da notificação, como idade, sexo, gestação, raça, escolaridade, ocupação, localização, datas e sintomas. Também é possível escolher qual arbovirose será avaliada, com isso, a interface organiza os campos enviados ao backend e não depende de informações posteriores, como exame, evolução ou encerramento do caso.

A interface foi construída com React e TypeScript, enquanto a API em FastAPI recebe os campos, aplica a mesma preparação utilizada durante o treinamento e cria as features esperadas pelos modelos, depois disso, MLP, XGBoost e LightGBM produzem seus scores individuais, que são combinados pelo ensemble antes da resposta voltar para o navegador.

Apresentando o resultado sem transformá-lo em diagnóstico

Na resposta, os três scores aparecem separadamente junto aos pesos utilizados no ensemble, e logo abaixo a aplicação mostra a classificação combinada e o limiar aplicado, isso ajuda a entender que o resultado final não vem de um único algoritmo, além de permitir observar quando os modelos apresentam valores semelhantes ou diferentes.

Além da triagem manual, a Home permite sortear um caso anonimizado do teste e comparar a previsão com a classificação registrada na base histórica, essa simulação serve para demonstrar o pipeline completo e não para validar clinicamente uma pessoa, por isso, a aplicação apresenta o resultado como score de classificação e mantém o aviso de que a ferramenta não substitui a avaliação de um profissional de saúde.

Mostrando também o caminho dos dados

Para não limitar a aplicação ao formulário, criei uma página de Pipeline, que explica o caminho entre dados do SINAN, preparação, treinamento, avaliação, modelos salvos e API. Também criei uma página de Panorama Epidemiológico, que reúne as principais descobertas da análise exploratória, assim, quem acessa o projeto consegue entender tanto o resultado exibido quanto todo o processo que existe por trás dele.