Como Construí o Portugal
Data Intelligence

Os dados económicos de Portugal estão em todo o lado e em lado nenhum

Se quiseres perceber como a economia portuguesa se moveu pela crise da dívida soberana, pela COVID e pela recuperação, os dados existem, mas estão dispersos por várias autoridades estatísticas nacionais e europeias, cada uma com o seu portal, formato, cadência e manias. O INE publica uma coisa, o Banco de Portugal outra, o Eurostat e o BCE mais duas. Não há um único sítio que os consolide, os alinhe numa linha temporal comum e te deixe fazer perguntas transversais como "como é que o desemprego e as yields da dívida soberana se moveram juntos?"

Esse era o problema à superfície. A verdadeira razão por que o construí foi empurrar a minha própria profundidade, levar um projeto de respostas brutas de API até um briefing pronto para administração, sendo dono de cada camada pelo meio, em vez de herdar um dataset limpo e fazer só a última milha.

A primeira decisão: o que é real e o que é modelado

Doze pilares ao longo de quinze anos são muita superfície, e nem tudo está disponível através de uma API aberta e limpa. A decisão inicial mais importante não foi técnica. Foi sobre honestidade. Dividi os dados em dois níveis e tornei a divisão explícita em todo o lado onde importa.

Teria sido fácil apresentar os doze pilares como se tivessem todos a mesma autoridade. Não o fiz, porque no momento em que alguém descobre um número modelado apresentado como evangelho, deixa de confiar em todos. O dataset commitado é determinístico e reproduzível a partir de um snapshot, por isso qualquer um o pode reconstruir e obter o mesmo resultado, e a documentação de proveniência dos dados explica exatamente que pilares são quais.

Um pipeline em três fases, cada camada minha

O sistema é um único comando (python main.py) que corre três fases de ponta a ponta. Mantê-las bem separadas (extrair, analisar, entregar) significou que podia reconstruir qualquer camada sem tocar nas outras, e testar cada uma isoladamente.

A verdade pouco glamorosa do trabalho com dados é que a camada do meio é a parte fácil de exibir e a parte difícil de garantir confiança. Por isso gastei a maior parte do esforço nos dois extremos que ninguém fotografa: o portão de qualidade à entrada, e o "então e depois?" à saída.

A camada aborrecida que decide tudo

Um único número errado num dashboard macro não é um bug cosmético. É o tipo de coisa que leva um leitor a descartar em silêncio o relatório inteiro. Por isso, antes de qualquer série chegar à camada de analytics, passa por um framework de validação com oito verificações. Cada pilar, cada carga, todas as vezes.

Cada execução escreve um relatório de qualidade em JSON e um registo de linhagem (um run_id UUID, checksums de ficheiros, metadados de proveniência) para que, se um número parecer errado, o consiga rastrear de trás para a frente pelas camadas até ao lote e à fonte exatos que o produziram. Essa rastreabilidade é a diferença entre "acho que os dados estão bem" e "consigo provar de onde isto veio".

Para além dos gráficos: o que a camada de analytics faz mesmo

É aqui que o instinto de um analista financeiro encontrou um toolkit estatístico mais profundo. O objetivo nunca foi prever o PIB português melhor do que o banco central. Foi demonstrar os métodos como deve ser, com validação honesta em vez de uma linha confiante traçada para o futuro.

O enquadramento honesto em todo o lado: onde um método é genuinamente robusto nestes dados, apoio-me nele; onde os pilares modelados o tornam ilustrativo, digo-o. Um gráfico de previsão que esconde as suas próprias métricas de erro é marketing, não análise.

De "aqui estão os dados" para "aqui está o que significam"

A maior coisa que separa este projeto de um conjunto arrumado de gráficos é a camada final. Um dashboard obriga o leitor a fazer a interpretação. Um entregável consultivo faz a interpretação por ele, e assume uma posição. A plataforma gera um briefing HTML autocontido que termina não com um gráfico, mas com uma matriz de risco e recomendações estratégicas.

Manter o relatório determinístico foi uma decisão de produto deliberada, não uma limitação. Para algo apresentado como análise económica, um número que muda de cada vez que regeneras a página é pior do que inútil. É um buraco de confiança. O LLM acelera a prosa; nunca decide os valores.

Porque é que um projeto de portfólio tem 489 testes

Seria razoável perguntar porque é que um projeto de analytics a solo precisa de uma suite de testes real, de containers e de CI. A resposta é que a disciplina de engenharia é parte do que o projeto pretende demonstrar, que consigo construir trabalho de dados da forma como uma equipa teria mesmo de o manter.

O que resultou, e o que eu mudaria

O projeto fez aquilo para que o construí: levou-me por todas as camadas de uma plataforma de dados, de uma resposta bruta de API a uma recomendação sobre a qual um leitor pudesse agir. Algumas reflexões honestas: