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

Engenharia de SoftwareInteligencia Artificial

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

Cargo: Analista Judiciário - Tecnologia da Informação - Arquiteto 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

GabaritoB — implementar 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;

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

MLOps – Monitoramento e Ação Frente a Data Drift

Gabarito: letra B. Embora a degradação do F1-score de 0,89 para 0,72 indique possível drift, a banca considera que 0,72 ainda é aceitável para detecção de fraudes em produção, e a melhor prática inicial é implementar alertas de monitoramento mais sensíveis para acompanhar a evolução antes de qualquer intervenção drástica no pipeline.

O problema relata que as features agregadas (médias móveis de 7 e 30 dias) apresentaram drift estatisticamente significativo (p<0,01), enquanto as features brutas permaneceram estáveis. Isso sugere que o conceito de negócio (padrões de fraude) pode estar mudando lentamente, mas o modelo ainda performa de forma aceitável.

Alternativa A — ❌ Incorreta

Descartar as features agregadas é uma ação extrema e prematura. Elas contribuíram para o desempenho inicial do modelo e, com monitoramento adequado, podem ser mantidas. A simples remoção ignora a informação temporal que elas carregam.

Alternativa B — ✅ Correta ⟵ GABARITO

A alternativa propõe aumentar a sensibilidade dos alertas de monitoramento e manter o pipeline inalterado, sob o argumento de que o F1-score de 0,72 é aceitável. Essa é uma abordagem conservadora e alinhada com boas práticas: antes de retreinar ou modificar o modelo, é prudente coletar mais dados para confirmar a tendência de degradação, evitando ações desnecessárias que poderiam introduzir instabilidade.

Alternativa C — ❌ Incorreta

A estratégia blue-green é uma técnica de deployment, não uma solução direta para drift. Embora seja útil para testar novos modelos, o enunciado não menciona necessidade de troca de versão ou paralelização de tráfego; o foco deve ser no monitoramento e no entendimento da causa do drift.

Alternativa D — ❌ Incorreta

Retreinamento automático com janela deslizante pode ser uma solução, mas a justificativa de “recalcular as features sobre períodos mais curtos para reduzir latência conceitual” não é clara e não ataca diretamente o drift. Além disso, retreinar sem monitoramento adequado pode levar a overfitting ou instabilidade.

Alternativa E — ❌ Incorreta

Trocar gradient boosting por uma rede neural recorrente não é necessariamente mais robusto a drift; modelos mais complexos podem sofrer de overfitting e são mais difíceis de manter. A recomendação de boas práticas é primeiro monitorar e entender o drift, não trocar o algoritmo.

NÃO CAIA NESSA!

A banca tenta fazer o candidato acreditar que a queda do F1 exige retreinamento imediato. No entanto, a questão afirma que o drift está apenas nas features agregadas e o score de 0,72 é considerado aceitável no contexto. A alternativa B explora essa sutileza: monitoramento mais sensível é a ação inicial correta, não a retreinamento.

Gabarito: letra B.

Link permanente: /questoes/fg133942