Preço de imóvel servido por API FastAPI na AWS: MAPE de 9,32% contra vendas reais de 2010, todo request logado e deploy contínuo com healthcheck
Sprint do 4º semestre do Insper com o QuintoAndar como parceiro: um time de quatro tinha que responder por quanto um imóvel vende e sustentar essa resposta em produção. O dataset é o Ames Housing — 1.285 imóveis residenciais de 2006 a 2009, 80 features — e o teste final foi contra 175 vendas reais de 2010, em holdout temporal com ids disjuntos dos do treino. Saíram dois modelos: uma regressão linear de 4 features para explicar preço a corretor e proprietário (MAPE 11,9%, R² 0,832) e um Gradient Boosting para a calculadora pública. Dos 52 commits do repositório da aplicação, 20 são meus — o maior volume do time: a API FastAPI, o logging de predições, os 36 testes, o script e o relatório de validação com os dados de 2010 e o modelo mínimo de 8 campos.
Gradient Boosting escolhido entre 5 modelos em validação cronológica: MAE de US$ 16.117 e MAPE de 9,83% no holdout de 2009, contra US$ 57.077 e 34,69% do baseline de mediana
Validação final contra as 175 vendas reais de 2010: MAE US$ 15.810, MAPE 9,32%, RMSE 26.071 e R² 0,894, com 92% dos imóveis dentro de 20% de erro
Calculadora pública reduzida de 12 para 8 campos por forward selection, no joelho da curva de erro
API FastAPI 0.115 com /predict, /predict/simples, /metrics e /health, contratos em Pydantic e o pré-processamento e as features portados do repo de modelo para ficarem idênticos aos do treino
Todo request gravado em SQLite — inclusive os 422 — com latência, versão do modelo, entrada e saída; o relatório de uso real fechou 300 chamadas com p95 de 11,7 ms e 94,3% de sucesso
36 testes em pytest distribuídos por 8 arquivos, e CI/CD que roda a suíte a cada push e, no merge da main, faz SSH + rsync e docker compose up --build --wait na EC2, com healthcheck depois do deploy
Resposta: Preço de imóvel anda com o tempo. Um split aleatório deixa venda de 2009 no treino e venda de 2007 no teste, e o modelo passa a ser avaliado sabendo o futuro. O corte é por data, a validação foi o ano de 2009, e o teste final foi contra as 175 vendas de 2010 — ano que o treino nunca viu, com ids disjuntos.
Resposta: Log só de predição bem-sucedida mede o modelo, não o serviço. Gravar o 422 junto é o que mostra qual contrato o cliente está errando e com que frequência — é dele que sai a taxa de sucesso de 94,3% nas 300 chamadas do relatório de uso, em vez de uma impressão de que estava tudo bem.
Resposta: O modelo treinado até 2009 errou 9,32% de MAPE num ano que nunca viu, contra 9,83% no holdout de 2009 — ou seja, não houve degradação a corrigir. Retreinar sem sinal de degradação troca um modelo medido por um modelo novo e não medido; a decisão de não mexer ficou escrita no relatório de validação.
MAE dos 5 modelos no holdout cronológico de 2009
Previsto vs. real do Gradient Boosting
Latência por chamada em produção (p95 11,7 ms)
O super app interno da TECNA em Next.js 16: quatro sistemas novos meus — Qualidade com tela de campo sem sinal, Planejamento com caminho crítico, Segurança e Gerenciamento de Projetos —, o manual do proprietário e o CMS do site
