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

Engenharia de SoftwareInteligencia Artificial

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

Cargo: Analista Judiciário - Tecnologia da Informação - Cientista de Dados

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”.

Pipeline ML em produção: tratamento de drift e estratégias de deployment

Gabarito: letra C. A degradação do F1-score de 0,89 para 0,72, acompanhada de mudanças significativas nas distribuições das features agregadas (p < 0,01 no teste KS), caracteriza data drift. A melhor prática em MLOps é treinar um novo modelo com dados recentes e implantá-lo gradualmente usando uma estratégia como blue-green ou canary release, monitorando métricas e drift antes de migrar todo o tráfego. Essa abordagem minimiza riscos e permite validar o novo modelo em ambiente controlado.

1Ingestão streaming
2Feature engineering (agregações 7/30d)
3Predição (gradient boosting)
4Deployment (microsserviços)

LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

Descartar as features agregadas porque sofreram drift é uma reação excessiva. Elas ainda podem ser preditivas se o modelo for retreinado com a nova distribuição. Além disso, features brutas sozinhas geralmente perdem poder preditivo. O correto é retreinar o modelo mantendo as mesmas features e usar uma estratégia de deployment segura.

Alternativa B — ❌ Incorreta

Manter o pipeline inalterado com apenas alertas de monitoramento não resolve a degradação de performance. Um F1-score de 0,72 em detecção de fraudes é inaceitável na maioria dos cenários. Ação corretiva é necessária, e o monitoramento sozinho não corrige o drift.

Alternativa C — ✅ Correta ⟵ GABARITO

A estratégia blue-green consiste em manter duas versões do modelo (azul = atual, verde = novo treinado com dados recentes) em paralelo, direcionando gradualmente o tráfego da azul para a verde enquanto se monitoram métricas de desempenho e drift. Isso permite detectar problemas antes da migração total, seguindo as melhores práticas de MLOps para atualização segura de modelos em produção.

Alternativa D — ❌ Incorreta

Embora o retreinamento automático com janela deslizante seja útil, a alternativa propõe recalcular as features sobre períodos mais curtos (alterando a definição original de 7 e 30 dias), o que pode quebrar a consistência e introduzir concept drift. Além disso, não menciona nenhuma estratégia de deployment — retreinar automaticamente sem validação gradual pode colocar um modelo inferior em produção.

Alternativa E — ❌ Incorreta

Aumentar a complexidade do modelo (trocando gradient boosting por redes neurais recorrentes) não o torna inerentemente robusto a drift. Modelos mais complexos podem sofrer overfitting e ainda precisam de feature engineering adequada. O drift deve ser tratado com retreinamento e monitoramento, não com substituição algorítmica.

Conclusão: A única alternativa que combina retreinamento com dados recentes e uma estratégia de deployment segura (blue-green) é a letra C, seguindo as melhores práticas de MLOps.

Gabarito: letra C.

Link permanente: /questoes/fg133970