Guia MLOps LLMOps AIOps
MLOps · LLMOps · AIOps

Série Engenharia de IA · 50 perguntas · 5 partes

As 50 perguntas mais frequentes sobre MLOps, LLMOps e AIOps em entrevistas

Treinamento contínuo, implantação, monitoramento, avaliação de LLMs e automação de incidentes, com os modos de falha, os trade-offs e os padrões de produção que entrevistadores seniores esperam.

Pipelines · Registros · Serving · Drift · Avaliações de LLM · Guardrails · Observabilidade · Incidentes

Tradução para o português do guia Most Asked 50 MLOps, LLMOps and AIOps Interview Questions and Answers, da série de preparação para entrevistas do AI Engineering Insider.

Ir para as 50 perguntas Começar pela visão geral

Visão geral

O que são MLOps, LLMOps e AIOps

Comece aqui

MLOps

É a disciplina de engenharia que leva um modelo do notebook para um serviço em produção e o mantém correto depois disso. Estende o DevOps com dois artefatos que o DevOps nunca precisou gerenciar: os dados, que mudam sem um commit, e os modelos treinados, cujo comportamento depende desses dados. O resultado é um ciclo de vida com dados versionados, pipelines de treinamento automatizados, gates de avaliação, um registro de modelos, implantação controlada e monitoramento capaz de disparar o retreinamento.

LLMOps

É o MLOps para aplicações construídas sobre grandes modelos de linguagem: o artefato que mais muda costuma ser um prompt, um índice de recuperação ou uma versão de modelo de um provedor, a qualidade é julgada sobre texto aberto e não sobre uma única métrica, e o custo cresce com os tokens.

AIOps

Aponta no sentido oposto: aplica ML às operações de TI, usando telemetria para detectar anomalias, correlacionar alertas, encontrar causas-raiz prováveis e automatizar a remediação, inclusive para os próprios sistemas de ML.

Por que importa

Sistemas de ML falham em silêncio. Um serviço web que quebra devolve erros; um modelo que se degrada continua devolvendo previsões confiantes. Sculley et al. (2015) descreveram o resultado como dívida técnica oculta: código de cola, selvas de pipelines, consumidores não declarados e ciclos de retroalimentação, em que o modelo é uma fração pequena do sistema. A prática de Ops é o que mantém essa dívida sob controle.

Onde cada disciplina atua no ciclo

Onde se encaixa

O trabalho de Ops fica entre o desenvolvimento de modelos e o produto. Cientistas de dados entregam uma receita de treinamento, não um arquivo pickle; engenheiros de plataforma fornecem o executor de pipelines, o registro e a pilha de serving; SREs respondem pela confiabilidade. Em produtos com LLM, a mesma equipe costuma ser dona de prompts, recuperação, avaliações e do contrato com o provedor, de modo que o LLMOps muitas vezes é o trabalho inteiro.

Casos de uso reais

Modelos de fraude e crédito retreinados conforme o comportamento muda; sistemas de recomendação com atualização diária de features e testes A/B online; um assistente de suporte cujo prompt, índice de recuperação e versão de modelo são liberados por um gate de avaliação; uma frota de inferência em GPU com autoescalonamento por profundidade de fila; uma camada de AIOps que agrupa uma tempestade de 300 alertas em um único incidente com uma causa provável.

Conceitos que você precisa dominar

  • Reprodutibilidade: código, snapshot dos dados, features, ambiente e configuração produzem o mesmo modelo.
  • Skew entre treino e serving: features calculadas de forma diferente offline e online.
  • Drift: muda a distribuição das entradas (data drift) ou a relação entre entrada e rótulo (concept drift).
  • Treinamento contínuo (CT): pipelines retreinam e reavaliam automaticamente a partir de gatilhos.
  • Gates: verificações automatizadas que bloqueiam uma liberação (validação de dados, limiares de avaliação, análise de canary).
  • Observabilidade: sinais de sistema, dados, qualidade do modelo e negócio, unidos por IDs de requisição e versões.
  • SLOs e orçamentos de erro para latência, disponibilidade e, cada vez mais, qualidade.

Os três lado a lado

MLOpsLLMOpsAIOps
EntregaModelos treinados e os pipelines que os constroemPacotes de prompt, modelo, recuperação e ferramentasDetectores, regras de correlação, automação de runbooks
Falha típicaDrift, skew, vazamento, features desatualizadasAlucinação, injeção, mudança de provedor, picos de custoTempestades de alertas, diagnóstico lento, correções automáticas inseguras
Medido porAUC ou erro em rótulos novos, KPI de negócioNotas de rubrica e de juiz, fundamentação (groundedness), custo por requisiçãoTempo para detectar e resolver, acionamentos de plantão evitados
Gate de liberaçãoSupera o campeão no holdout e nos recortes (slices)Passa na suíte de avaliação com intervalos de confiançaAção reversível, aprovação, trilha de auditoria

Roteiro de aprendizado

Dos pipelines aos sistemas autorrecuperáveis

Três níveis

Cada nível termina com algo que você consegue construir e explicar. Os níveis são cumulativos: as práticas de LLMOps e AIOps se apoiam nos hábitos do Nível 1 de versionar, testar e medir.

Nível 1

Fundamentos

O que aprender

Git, contêineres e noções de CI; o ciclo de vida de ML; divisões treino/validação/teste e vazamento; rastreamento de experimentos; versionamento de dados e modelos; inferência em lote vs online; drift de dados vs de conceito; o que é um SLO.

Por que importa

Toda prática posterior pressupõe que você consiga reproduzir um modelo e explicar por que seus números mudaram.

Construa ou explique depois

Rastrear 20 execuções no MLflow; reproduzir a melhor execução a partir da versão de dados e do commit registrados; explicar drift com um exemplo concreto.

Ferramentas típicas

Git, Docker, MLflow ou W&B, DVC, pytest

Nível 2

Engenharia prática

O que aprender

Orquestração de pipelines (Kubeflow Pipelines, Airflow ou equivalente gerenciado); validação de dados; feature stores e junções point-in-time; registro de modelos com aliases; servidores de modelos (KServe, Triton, BentoML, vLLM); releases canary e shadow; conjuntos de avaliação de LLM, LLM como juiz, versionamento de prompts; tracing com OpenTelemetry.

Por que importa

Este é o trabalho diário de uma equipe de plataforma de ML ou de aplicações com LLM: transformar passos manuais em pipelines repetíveis e com gates.

Construa ou explique depois

Um pipeline que valida dados, treina, avalia contra o campeão, registra e implanta um canary; uma suíte de avaliação de LLM com 100 a 300 casos que roda no CI a cada mudança de prompt.

Ferramentas típicas

Kubeflow ou Airflow, Feast, Great Expectations ou pandera, KServe, Argo Rollouts, Evidently, Langfuse ou similar

Nível 3

Produção e avançado

O que aprender

Treinamento contínuo com gatilhos de drift e de qualidade; autoescalonamento de GPU e internos do serving de LLM (cache KV, batching contínuo, quantização); gateways de LLM, roteamento e cache; guardrails e segurança da cadeia de suprimentos de modelos; SLOs de qualidade; detecção de anomalias em AIOps, correlação de alertas e autorremediação com salvaguardas.

Por que importa

Em escala, os problemas difíceis são custo, latência de cauda, degradação silenciosa e resposta a incidentes, não o treinamento.

Construa ou explique depois

Um laço de CT que retreina com alertas de PSI ou de qualidade e promove por um gate de avaliação; uma implantação vLLM com dashboards de SLO; um job de correlação de alertas com uma ação de runbook aprovada por humano.

Ferramentas típicas

vLLM, Triton, Prometheus, Grafana, OpenTelemetry, um gateway de LLM, ferramentas de incidente no estilo PagerDuty

Insight

Entrevistadores raramente cobram curiosidades sobre ferramentas. Eles testam se você sabe nomear a falha que cada prática previne: o versionamento previne regressões irreproduzíveis, os gates previnem liberações ruins, o monitoramento flagra a degradação silenciosa e o AIOps encurta o tempo entre o sintoma e a causa.

Mergulho técnico

Os seis subsistemas de uma pilha de Ops

Seis subsistemas

Pipelines e treinamento contínuo

O quê e como. Um pipeline é um DAG de etapas em contêineres: ingerir, validar, construir features, treinar, avaliar, registrar. Um orquestrador o executa em uma agenda ou por gatilho e faz cache das etapas inalteradas. A orientação de MLOps do Google (Kazmierczak et al., 2024) descreve três níveis: manual (nível 0), pipelines de treinamento automatizados com CT (nível 1) e CI/CD automatizado do próprio pipeline (nível 2).

Quando. Assim que um modelo é retreinado mais do que ocasionalmente ou mais de uma pessoa mexe nele.

Limites e erros. Automatizar uma divisão com vazamento automatiza o vazamento. Gatilhos que retreinam a cada pequeno drift desperdiçam computação e fazem o comportamento oscilar; combine os gatilhos com um gate de avaliação contra o campeão atual.

Pipeline CI / CT / CD · todo artefato é versionado: código, dados, features, modelo, prompt, configuração

Versionamento, linhagem e registro

O quê. A linhagem registra qual commit de código, snapshot de dados, definições de features, ambiente e hiperparâmetros produziram um modelo. O registro guarda versões de modelo e aponta aliases nomeados (por exemplo, @champion, @challenger) para elas, de modo que a implantação resolve um alias em vez de um caminho de arquivo. O MLflow deixou os estágios fixos e passou a usar aliases por esse motivo.

Trade-off. Fazer snapshot de conjuntos de dados grandes é caro; armazene partições ou versões de tabela imutáveis (Delta, Iceberg) e registre a referência, não uma cópia.

Experimente: alias do registroilustração do Q06 e do Q22

Serving e estratégias de implantação

O processamento em lote serve a decisões diárias; o serving online exige uma feature store e latência baixa; o streaming pontua eventos à medida que chegam. O serving de LLM é limitado por memória: a vazão depende da capacidade do cache KV, do batching contínuo e do cache de prefixo (o PagedAttention do vLLM gerencia a memória do cache KV em blocos; Kwon et al., 2023).

EstratégiaComo funcionaUse quando
ShadowCopia o tráfego e descarta a saídaValidar latência e distribuição da saída com risco zero para o usuário
CanaryPequena fração do tráfego, depois ampliaVerificar métricas ao vivo; rollback automático em violação de SLO
A/BDivisão aleatória, duração fixaMedir impacto de negócio com poder estatístico
Blue-greenDuas pilhas completas, depois a trocaRollback instantâneo; dobra o custo por um breve período
BanditO tráfego migra para o vencedorMuitas variantes, quando o custo do arrependimento (regret) importa

Monitoramento e drift

Monitore quatro camadas: sistema (latência, erros, saturação, memória de GPU), dados (esquema, nulos, intervalos, drift de distribuição), modelo (distribuição das previsões, calibração, acurácia quando os rótulos chegam) e negócio (conversão, taxa de perda). O Índice de Estabilidade Populacional (PSI, Population Stability Index) compara as proporções de referência e de produção em faixas (bins), pi e qi:

PSI = Σi (qi − pi) ln(qi / pi)

Regras práticas comuns leem abaixo de 0,1 como estável, de 0,1 a 0,25 como moderado e acima de 0,25 como significativo; trate esses valores como pontos de partida a ajustar por feature. A capa do original mostra um modelo cuja AUC caiu de cerca de 0,86 para 0,67 quando deixado congelado, e se manteve perto de 0,86 quando alertas de PSI dispararam três retreinamentos.

Erro. Alertar em toda feature que sofre drift. O drift em uma feature sem importância é ruído; pondere os alertas pela importância da feature e confirme com drift de previsão ou com qualidade.

Experimente: PSI em dez decissimulação didática

Referência: normal padrão dividida em decis do treino (10% por faixa). Produção: normal com a média e a escala escolhidas. Faixas vazias recebem épsilon de 1e-4, como no código do Q11.

Registro de modelos e retreinamento contínuo na capa

O painel da capa compara quatro versões treinadas em janelas diferentes, todas medidas nos dias 53 a 59. As versões treinadas com dados mais antigos perdem AUC; o campeão é o modelo mais recente. Com CT, houve 3 alertas de drift, 3 retreinos e 0 passos manuais. A promoção passou por um gate de avaliação, um canary de 10% e rollback automático.

0,671AUC na última semana, v14 congelado
0,860AUC na última semana, com CT
Registro de modelosAUC nos dias 53 a 59, dados da capa

Barras partem de zero. Valores e aliases transcritos da figura da capa do original.

Especificidades de LLMOps

PreocupaçãoMLOps clássicoLLMOps
Artefato principalPesos treinadosPrompt, índice de recuperação, versão do modelo, ferramentas
QualidadeAcurácia, AUC sobre rótulosNotas de rubrica, LLM como juiz, revisão humana
Fator de custoComputação de treinamentoTokens por requisição, horas de GPU
FalhaDrift, skewAlucinação, injeção, mudança de provedor
Unidade de liberaçãoVersão do modeloPrompt + modelo + índice + pacote de configuração

Evals são os testes de regressão do LLMOps: um conjunto versionado de entradas com referências ou rubricas, executado a cada mudança, reportado com intervalos de confiança (as seis versões da capa foram avaliadas em 300 itens; duas ficaram abaixo do gate de 0,85). Juízes LLM apresentam vieses de posição, de verbosidade e de autopreferência (Zheng et al., 2023); por isso, calibre-os contra rótulos humanos e randomize a ordem das respostas.

Nota da tradução

O texto do original diz que duas versões ficaram abaixo do gate de 0,85. A figura da capa mostra três versões bloqueadas (v1, v4 e v5, com 83, 83 e 78) e legenda “ship (3)”. A tradução mantém o texto como está no original e o widget ao lado segue os valores da figura.

Experimente: gate de avaliação300 itens por versão, valores da capa

Pontos em vez de barras, porque o eixo começa em 0,70. Os intervalos de confiança de 95% da capa não têm valores legíveis e foram omitidos.

AIOps

O AIOps aprende linhas de base para métricas (EWMA, decomposição sazonal), sinaliza desvios, agrupa alertas relacionados por tempo e por topologia de serviços e ordena causas prováveis, como um deploy recente ou uma dependência saturada. Um detector EWMA mantém uma média móvel e uma variância, e sinaliza desvios grandes:

μt = μt−1 + α(xt − μt−1)    sinaliza |xt − μt| > kσt

Não atualize a linha de base com pontos sinalizados, ou um incidente passa a ser o novo normal.

Trade-off. Sensibilidade versus fadiga de alertas. A autorremediação (reiniciar, escalar, reverter) deve começar com ações reversíveis e de baixo raio de impacto, sob aprovação.

Experimente: detector EWMAsérie simulada de latência p95
0pontos sinalizados
0dentro do incidente
n/dprimeiro acionamento

Série sintética (semente fixa) com dois picos isolados e um incidente de t = 150 a 170. A capa do original mostra 21 de 23 sinalizações no incidente; aqui os números vêm desta simulação. Nota do widget: congelar a linha de base tem custo, pois uma mudança legítima de nível não é acompanhada sem revisão.

Partes I a V

As 50 perguntas e respostas

Parte
Nível
· ·

Folha de consulta

MLOps, LLMOps e AIOps em uma página

Referência

Termos e siglas

TermoSignificado
CI / CD / CTIntegrar e testar código; entregar releases; retreinar a partir de gatilhos
LinhagemCódigo, dados, features, configuração e ambiente por trás de um modelo
Alias do registroPonteiro nomeado (@champion) para uma versão do modelo
SkewFeatures diferem entre treino e serving
Junção PITJunção point-in-time: valores das features no instante do evento
PSI / KS / JSTamanho de efeito do drift / teste de duas amostras / divergência limitada
SLO / SLIMeta / indicador medido; orçamento de erro = 1 − SLO
TTFT / ITLTempo até o primeiro token / latência entre tokens
Cache KVChaves e valores de atenção em cache por sequência
LLM como juizUm LLM pontua saídas contra uma rubrica
RCAAnálise de causa-raiz (root-cause analysis)
MTTD / MTTRTempo médio para detectar / para resolver

Mapa de ferramentas

TarefaEscolhas comuns
OrquestrarKubeflow Pipelines, Airflow, Dagster, Prefect
Rastrear, registrarMLflow, Weights & Biases
Dados, featuresDVC, tabelas Delta ou Iceberg, Feast
ValidarGreat Expectations, pandera, TFDV
ServirKServe, Triton, BentoML, vLLM, SGLang
Liberar (roll out)Argo Rollouts, canary do KServe, Istio
MonitorarPrometheus, Grafana, Evidently, OpenTelemetry
Tracing e avaliações de LLMLangfuse e similares, harness próprio de avaliação

Fórmulas

PSIΣi (qi − pi) ln(qi/pi); < 0,1 estável, > 0,25 agir
EWMAμt = μt−1 + α(xt − μt−1); sinaliza |xt − μt| > kσt
Orçamento de erro(1 − SLO) × janela; 99,9% em 30 dias ≈ 43 min
Taxa de consumoTaxa de erro / (1 − SLO); acionar em janelas rápida e lenta
Custo de LLMnin cin + nout cout por requisição
Tempo de decodificação≈ TTFT + nout × ITL
IC por bootstrapReamostre os itens de avaliação com reposição e tome 2,5% e 97,5%

Gates de liberação, em ordem

  1. A validação de dados passa (esquema, nulos, intervalos, frescor).
  2. O candidato supera ou iguala o campeão no geral e nos recortes críticos.
  3. Latência, memória e custo dentro do orçamento sob carga semelhante à de produção.
  4. Shadow ou canary saudável por uma janela fixa; rollback automático armado.
  5. Linhagem, model card e aprovação registrados no registro.

Comandos e padrões

BASH
mlflow ui --port 5000
vllm serve <model> --enable-prefix-caching
kubectl argo rollouts promote fraud-api
kubectl argo rollouts abort fraud-api
kubectl rollout undo deployment/fraud-api
PYTHON
uri = "models:/fraud@champion"
m = mlflow.pyfunc.load_model(uri)

Regras práticas e armadilhas

  • Versione prompts, juízes, conjuntos de avaliação e índices, não apenas modelos.
  • Registre features e previsões no momento da decisão, com IDs de requisição e de versão.
  • Alerte sobre sintomas visíveis ao usuário; use dashboards para as causas.
  • Pondere os alertas de drift pela importância da feature; confirme com drift de previsão.
  • Nunca deixe anomalias atualizarem a linha de base contra a qual foram julgadas.
  • Dimensione a capacidade de LLM em tokens por segundo em uma latência-alvo.
  • Conteúdo estável do prompt primeiro, conteúdo variável por último (cache de prefixo).
  • Mantenha o modelo anterior implantável; os esquemas devem continuar retrocompatíveis.
  • Arquivos pickle são código; prefira safetensors e verifique hashes.
  • Nenhuma liberação sem um caminho de rollback e um responsável.

Checklist de implementação

Entregue, observe, corrija

Resumo

Checklist de prontidão para produção

    Cinco marcos de implementação

    1. Treino reproduzível: execuções rastreadas, dados versionados, retreino com um único comando.
    2. Pipeline com gates: valida, treina, avalia contra o campeão, registra.
    3. Serving seguro: contêiner, canary, rollback, SLOs de latência e de erro.
    4. Observabilidade: monitoramento de drift, qualidade e custo, com alertas e responsáveis.
    5. Ciclo fechado: gatilhos de drift ou de qualidade disparam o retreino; o AIOps agrupa alertas e propõe correções reversíveis.

    Princípios para lembrar

    • Modelos falham em silêncio; meça a qualidade, não apenas o uptime.
    • Automatize o gate antes de automatizar o gatilho.
    • Tudo o que muda o comportamento é um artefato versionado.
    • Prefira mudanças reversíveis e um raio de impacto pequeno.
    • Toda falha em produção vira um teste ou um caso de avaliação.

    Para explorar depois

    • Avaliação off-policy e bandits para sistemas com ciclos de retroalimentação.
    • Prefill e decode desagregados, decodificação especulativa, serving multi-LoRA.
    • Arcabouços de agentes: avaliações de trajetória, orçamentos e ferramentas com permissões.
    • Design de SLOs para qualidade e métodos causais para análise de causa-raiz.

    O que você consegue fazer agora

    Explicar os ciclos de vida de ML, de LLM e de AIOps e como eles diferem; projetar um pipeline com validação, gates de avaliação, um registro e liberação segura; escolher métricas e limiares de drift; operar o serving de LLM com sinais sensatos de capacidade, custo e latência; e tratar cenários de produção, do drift silencioso às tempestades de alertas, com uma ordem de diagnóstico clara.

    Leitura complementar

    Do sintoma às primeiras verificações

    SintomaVerifique primeiro, nesta ordemAção imediata segura
    Offline bom, online ruim
    1. Vazamento na divisão
    2. Features servidas vs recalculadas
    3. Descompasso de população
    4. Limiar
    		Suspender o rollout, manter o campeão
    Alerta de drift, métricas estáveis
    1. Importância da feature
    2. Bug de pipeline (unidades, categorias)
    3. Qualidade por recorte
    		Anotar, ajustar o limiar
    Queda de qualidade após liberação
    1. Diff de modelo, prompt, índice e configuração
    2. Recortes com falha
    3. Versão do juiz
    		Reverter o alias ou a flag
    Latência de LLM subiu
    1. Tokens de entrada e de saída
    2. Taxa de acerto do cache de prefixo
    3. Pressão no cache KV
    4. Mix de tráfego
    		Limitar a saída, escalar réplicas
    Pico de custo de LLM
    1. Tokens por feature e por tenant
    2. Novas tentativas e loops
    3. Taxa de acerto de cache
    4. Roteamento
    		Cotas, rotear para um modelo menor
    Respostas de RAG piores
    1. Erros de ingestão
    2. Frescor do índice
    3. Troca do modelo de embedding
    4. Taxa de resultado vazio
    		Fixar o índice anterior
    Tempestade de alertas
    1. Deploys e configurações recentes
    2. Dependências compartilhadas
    3. Agrupamento por topologia
    		Acionar um responsável por incidente

    Notas da tradução

    • Termos técnicos consagrados (drift, canary, gate, rollback, serving, feature store, runbook, trade-off) permanecem em inglês. Os níveis CORE, MID e SENIOR do original aparecem como Base, Intermediário e Sênior.
    • O texto do original sobre o gate de avaliação (duas versões abaixo de 0,85) diverge da figura da capa (três versões bloqueadas). Nenhum dos dois foi alterado; a divergência está assinalada na seção C.5.
    • Onde o original cita apenas “Google Cloud” ou a orientação de MLOps do Google, acrescentei a citação em APA da página consultada (Kazmierczak et al., 2024). As demais citações seguem o original, com dados completos conferidos nas fontes listadas acima.
    • Os widgets de alias, PSI, gate e EWMA calculam resultados na própria página e não reproduzem os dados brutos das figuras da capa, que não constam no PDF. Só o gráfico do registro de modelos usa valores impressos na capa.

    Conteúdo técnico original: Most Asked 50 MLOps, LLMOps and AIOps Interview Questions and Answers, série de preparação para entrevistas do AI Engineering Insider (aiengineeringinsider.com). Este site é uma tradução para o português com projeto visual próprio.