// pipeline de dados · API pública · em produção
Astraea
Pipeline de monitoramento de objetos próximos à Terra e eventos solares: ingestão das APIs da NASA, transformação com dbt Core, API pública REST e um modelo que estima a probabilidade de um asteroide ter a flag de PHA da NASA.
Problema
O Astraea junta dados públicos da NASA sobre asteroides próximos à Terra e eventos solares em um pipeline, e os expõe numa API pública. Sobre esses dados há um modelo de machine learning, e foi ele que precisou ser refeito.
A versão anterior (1.0.0) previa o risk_label, que é calculado por regra sobre as mesmas colunas que o modelo recebia. A acurácia alta só mostrava que ele tinha reaprendido a regra. O alvo agora é a flag is_potentially_hazardous da NASA, usando só velocidade relativa, distância de aproximação em distâncias lunares e magnitude H, sem a flag como entrada (3 variáveis).
Dados
A ingestão é diária, via NASA NeoWs e DONKI. A transformação usa dbt Core em camadas staging e mart, e o PostgreSQL é o armazenamento central.
Para o modelo: 2.083 aproximações de 1.822 asteroides. Sobre os positivos, os dois números aparecem no relatório do modelo e medem coisas diferentes: 189 aproximações com a flag positiva, que correspondem a 180 asteroides (o mesmo asteroide pode ter mais de uma aproximação).
Decisões
O risco exibido é uma regra, não o modelo
O risco exibido é o risk_score por regra, uma heurística própria com limiares escolhidos por mim (20 km/s, 1.000.000 km, 0,5 km), e não uma metodologia da NASA. A pontuação soma 3 pontos se o asteroide é PHA, 2 se a velocidade passa de 20 km/s, 2 se a distância fica abaixo de 1.000.000 km e 1 se o diâmetro passa de 0,5 km. Com 6 pontos ou mais o risco é alto; com 3 ou mais, médio.
O modelo expõe outra coisa: a probabilidade de a flag de PHA da NASA ser positiva.
Validação
StratifiedGroupKFold com 5 folds, agrupado por asteroide, para que o mesmo asteroide não apareça no treino e no teste. Além disso, uma avaliação temporal, com treino nas datas mais antigas e teste nas mais recentes (corte em 12 de julho de 2026).
API
9 endpoints: 7 de dados com prefixo /v1, mais / e /health. Limite de 60 requisições por minuto por IP. Documentação em astraea-api.alexarnoni.com/docs.
Resultado
O score de risco é calculado por regra no dbt
| Modelo | Precisão | Recall | F1 | PR-AUC |
|---|
Com o limiar padrão de 0,5, o recall é 0,44: o modelo deixa passar mais da metade dos PHAs.
Comparação com uma regra simples
O modelo ordena os asteroides melhor do que a magnitude sozinha em validação agrupada (PR-AUC 0,64 contra 0,36, nas probabilidades fora da amostra dos 5 folds juntos; na tabela, 0,65 é a média entre folds). Com recall alto, a vantagem sobre o corte simples H <= 22 é pequena (precisão 0,405 contra 0,389, dentro do ruído). A regra H <= 22 sozinha tem recall 0,995 e precisão 0,39. Análise exploratória feita depois de ver os primeiros resultados, fora do plano original. Os números desta comparação estão no relatório do modelo.
Limitações
- A MOID (distância mínima de interseção orbital, limite de 0,05 UA), que define a flag junto com H, não está entre as variáveis do modelo.
- A distância usada é a de uma aproximação específica, não uma propriedade estável do asteroide.
- H domina o modelo. O diâmetro estimado foi descartado por ser função exata de H.
- Há poucos asteroides positivos (180).
- O F1 cai de 0,52 para 0,39 no split temporal, e os dados não separam deriva temporal de variância (43 positivos no teste). Detalhes no relatório.
Stack e links