Engenharia de Software · FGV · 2026 | Questão sqc-fg133794

Engenharia de SoftwareInteligencia Artificial

Código: fg133794
Banca: FGV
Órgão: TJ-RJ
Ano: 2026
Nível: Superior

Cargo: Analista Judiciário - Tecnologia da Informação - Analista de Inteligência Artificial

Uma fintech desenvolveu um pipeline ponta a ponta (end-to-end) de machine learning para detecção de fraudes em transações financeiras.O pipeline inclui as seguintes etapas:(1) ingestão de dados em tempo real via streaming;(2) feature engineering com agregações temporais (médias móveis de 7 e 30 dias);(3) predição usando um modelo de gradient boosting;(4) deployment em arquitetura de microsserviços.Após três meses em produção, o time de MLOps observou degradação gradual no F1-score de 0.89 para 0.72, enquanto o monitoramento revelou que as distribuições das features agregadas apresentavam mudanças estatisticamente significativas (p < 0.01 no teste de Kolmogorov-Smirnov), embora as features brutas individuais permanecessem estáveis.Considerando as melhores práticas de pipelines de ML em produção e estratégias de deployment, a equipe deve:

Adescartar as features agregadas temporais do pipeline, pois são a causa do data drift observado, e retreinar o modelo usando apenas as features brutas individuais que permaneceram estáveis;
Bimplementar apenas alertas de monitoramento mais sensíveis para detectar drift precocemente, mantendo o pipeline atual inalterado, pois o F1-score de 0.72 ainda é considerado aceitável para aplicações de detecção de fraudes em produção;
Cadotar estratégia de deployment blue-green para testar um novo modelo treinado com dados recentes em paralelo com o modelo atual, direcionando gradualmente o tráfego para o novo modelo enquanto monitora métricas de desempenho e features drift;
Dimplementar um sistema de retreinamento automático com janela deslizante que periodicamente atualiza o modelo com dados recentes, mantendo as features agregadas mas recalculando-as sobre períodos mais curtos para reduzir latência conceitual;
Eaumentar a complexidade do modelo substituindo gradient boosting por deep learning com redes neurais recorrentes, pois modelos mais complexos são mais robustos a drift e podem capturar padrões temporais automaticamente sem feature engineering.

Revelar gabarito e comentário

GabaritoC — adotar estratégia de deployment blue-green para testar um novo modelo treinado com dados recentes em paralelo com o modelo atual, direcionando gradualmente o tráfego para o novo modelo enquanto monitora métricas de desempenho e features drift;

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Degradação de modelo em produção – Data Drift em features agregadas

Gabarito: letra C. A degradação do F1-score combinada com drift estatístico nas features agregadas (mas não nas brutas) indica que o padrão temporal mudou, exigindo retreinamento do modelo com dados recentes. A estratégia blue-green permite testar o novo modelo de forma segura, direcionando gradualmente o tráfego e monitorando métricas, alinhando-se às melhores práticas de MLOps.

O problema clássico de concept drift ocorre quando a relação entre as features e o alvo muda ao longo do tempo. Aqui, as features brutas estão estáveis, mas as médias móveis (7 e 30 dias) apresentam drift. Isso sugere que os padrões temporais que o modelo aprendeu estão desatualizados. A solução não é descartar as features (podem ser relevantes) nem ignorar o drift, mas sim retreinar o modelo com dados recentes e implantá-lo de forma controlada.

1Ingestão em streaming
2Feature engineering (médias 7/30 dias)
3Predição (gradient boosting)
4Deployment em microsserviços

LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

Descartar as features agregadas é uma reação drástica e desnecessária. Elas são úteis para capturar sazonalidade e tendências. O drift está nas agregadas, mas o modelo pode ser retreinado com elas em novos dados, sem eliminá-las. A causa do drift pode ser uma mudança no comportamento do usuário, não nas features em si.

Alternativa B — ❌ Incorreta

Manter o pipeline inalterado e apenas alertar é passivo. Um F1-score de 0.72 representa queda significativa (de 0.89), e aceitar isso sem ação pode levar a perdas financeiras em fraudes. O monitoramento é necessário, mas deve ser acompanhado de correção.

Alternativa C — ✅ Correta ⟵ GABARITO

A implantação blue-green mantém duas versões do sistema: a atual (blue) e a nova (green) com modelo retreinado. Gradualmente, o tráfego é redirecionado para o green enquanto se monitoram métricas de desempenho e drift de features. Isso permite validação segura, rollback rápido se necessário, e resolve o drift ao usar dados recentes. É a abordagem recomendada para atualizações em produção.

Alternativa D — ❌ Incorreta

Embora o retreinamento automático com janela deslizante seja uma prática comum, a sugestão de recalcular as agregadas sobre períodos mais curtos para reduzir latência conceitual não ataca o cerne do problema. A latência conceitual (defasagem entre dados de treino e produção) é mitigada, mas a mudança na distribuição das agregadas pode persistir. Além disso, retreinamento automático sem validação em paralelo pode introduzir modelos piores.

Alternativa E — ❌ Incorreta

Trocar gradient boosting por redes neurais recorrentes (RNN) não é garantia de robustez a drift. Modelos mais complexos são mais propensos a overfitting e exigem mais dados. Além disso, RNNs capturam dependências temporais, mas o drift pode não estar na sequência, e sim nos valores das agregações. Aumentar complexidade sem diagnóstico correto é arriscado.

PEGA ESSA DICA!

Sempre que houver degradação de performance com drift em features, priorize retreinamento com dados recentes e deployment controlado (blue-green ou canary). Não descarte features nem ignore o monitoramento.

Gabarito: letra C

Link permanente: /questoes/fg133794