Padrões de Implantação

Padrões de implantação são formas controladas de introduzir um novo modelo (ou uma mudança adjacente ao modelo, como um prompt, um pipeline de recuperação ou um conjunto de funcionalidades) em produção, minimizando riscos. Em sistemas de IA, “risco” não é apenas indisponibilidade — inclui piora de qualidade, comportamento enviesado, regressões de segurança, maior latência/custo e ciclos de realimentação que silenciosamente contaminam dados futuros de treinamento.

Este artigo cobre três estratégias de rollout amplamente usadas — sombra, canário e A/B — e como implementá-las em pilhas reais de serving de modelos.

Por que padrões de implantação importam no serving de ML/LLM

Rollouts de software tradicional assumem que o comportamento é amplamente determinístico e que a correção pode ser validada com testes. Sistemas de aprendizado de máquina (machine learning) quebram essas premissas:

• O comportamento do modelo é probabilístico e pode mudar de forma significativa com pequenos desvios na distribuição de dados.
• A verdade fundamental (ground truth) geralmente é atrasada (rótulos de fraude chegam dias depois; satisfação do usuário é ruidosa).
• Qualidade é multidimensional (acurácia, calibração, segurança, justiça, latência, custo).
• Existem ciclos de realimentação (seu modelo muda os dados nos quais ele treinará depois).
• LLMs adicionam partes móveis adicionais: prompts, recuperação, uso de ferramentas, filtros de segurança, parâmetros de decodificação e versões de modelos do fornecedor.

Padrões de implantação fazem parte de um conjunto operacional mais amplo que inclui Servir Modelos, Monitoramento de Modelos e Reversões & Resposta a Incidentes.

Fundamentos compartilhados: versões, roteamento e observabilidade

Os três padrões dependem dos mesmos blocos de construção.

Versionamento e “o que conta como um release”

Em sistemas de ML, um “release” pode incluir:

• Pesos do modelo + arquitetura
• Transformações de funcionalidades / código de pré-processamento
• Esquema do feature store (feature store) e suposições de atualidade (Feature Stores)
• Pós-processamento (limiares, regras de negócio)
• Para apps com LLM: templates de prompt, mensagens de sistema, configuração de recuperação (Geração Aumentada por Recuperação (Retrieval-Augmented Generation)), políticas de ferramentas, filtros de segurança, parâmetros de decodificação

Trate esses itens como artefatos versionados (imutáveis) mais configuração em tempo de execução (auditada, com controle de mudanças).

Roteamento e atribuição de tráfego

Você precisa de um mecanismo para decidir, por requisição, qual versão irá atendê-la:

• Roteamento no API gateway
• Malha de serviços (service mesh) (ex.: Istio/Linkerd)
• Balanceador de carga + backends ponderados
• Roteamento em nível de aplicação (um serviço “roteador”)

Decisões-chave:

• Atribuição aleatória vs determinística: testes A/B tipicamente exigem atribuição determinística “aderente” (sticky) por usuário/sessão.
• Unidade de aleatorização: usuário, dispositivo, conta, consulta ou requisição.
• Estratificação: garantir coortes balanceadas entre regiões, plataformas ou níveis de clientes.

Observabilidade: logs, métricas, traces e chaves de junção

Para comparar versões, você precisa conseguir juntar eventos:

• ID de correlação por requisição
• Versão do modelo e hash da configuração
• ID do snapshot de funcionalidades (ou vetor completo de funcionalidades, com restrições de privacidade)
• Saída + escores de incerteza
• Decomposição de latência e uso de tokens (para LLMs)
• Resultados a jusante (cliques, conversões, escalonamentos, estornos)

Sem observabilidade robusta, “rollout seguro” vira adivinhação.

Implantações sombra (a.k.a. modo sombra, lançamento oculto)

Uma implantação sombra executa o novo modelo ao lado do modelo atual de produção com entradas reais de produção, mas suas saídas não são usadas para afetar a experiência do usuário.

Para o que shadow é bom

Sombreamento é melhor quando você quer validar:

• Correção funcional (sem travamentos, esquemas compatíveis)
• Desempenho (latência, memória, throughput, custo)
• Similaridade ou sanidade das saídas em relação ao incumbente
• Regressões de segurança para saídas de LLM (toxicidade, vazamento de PII, violações de política)
• Paridade do pipeline de dados: o novo modelo depende de funcionalidades ausentes ou desatualizadas no online?

O sombreamento é especialmente útil quando a verdade fundamental é atrasada; ainda assim você consegue detectar regressões óbvias cedo.

Padrões de arquitetura de shadow

Abordagens comuns:

1. Duplicar tráfego na borda
   O gateway duplica requisições para o backend sombra (assíncrono é comum), enquanto apenas a resposta primária é retornada.

2. Execução dupla no serviço
   O serviço de serving chama ambos os modelos e registra ambas as saídas, mas retorna apenas o resultado primário.

3. Replay orientado a eventos
   Requisições de produção são registradas e reproduzidas no modelo sombra mais tarde. Isso reduz risco, mas é menos “em tempo real”.

Exemplo prático: sombreamento de um sumarizador com LLM

Suponha que você substitua uma LLM de fornecedor por um modelo mais barato. Você pode usar shadow para comparar:

• Segurança: violações de política
• Proxies de qualidade: tamanho do resumo, repetição, taxa de recusa
• Custo: tokens, latência

Pseudocode sketch:

def handle_request(req):
    primary = primary_model.generate(req.text)

    # Fire-and-forget shadow execution (do not block response)
    submit_background_job(
        shadow_infer,
        request_id=req.id,
        text=req.text,
        primary_output=primary.text,
    )

    return primary.text

def shadow_infer(request_id, text, primary_output):
    shadow = shadow_model.generate(text)

    log_comparison({
        "request_id": request_id,
        "primary_version": primary_model.version,
        "shadow_version": shadow_model.version,
        "primary_text": primary_output,
        "shadow_text": shadow.text,
        "shadow_latency_ms": shadow.latency_ms,
        "shadow_tokens": shadow.tokens,
        "diff_metrics": compute_text_metrics(primary_output, shadow.text),
        "safety_flags": run_safety_checks(shadow.text),
    })

Decisões-chave de design e armadilhas

• Custo computacional: sombreamento dobra a carga de inferência; considere amostragem (ex.: 1–10% do tráfego).
• Privacidade e conformidade: duplicar requisições pode ampliar exposição de dados; aplique as mesmas regras de tratamento de PII e retenção.
• Não determinismo: saídas de LLM variam; registre sementes/parâmetros de decodificação e avalie com métricas robustas.
• Com o que você compara?
  O modelo incumbente não é verdade fundamental. Shadow frequentemente é combinado com:
  • conjuntos de avaliação offline
  • filas de revisão humana
  • classificadores automatizados de segurança
  • rótulos de desfecho atrasados

Quando avançar além do shadow

Shadow costuma ser um pré-passo para canário ou A/B. Você “se forma” quando:

• taxa de erro e latência estão dentro dos SLOs
• saídas passam por gates de segurança
• disponibilidade de funcionalidades é validada
• você tem exemplos registrados suficientes para estimar o risco provável de regressão

Releases canário (entrega progressiva)

Um release canário envia uma pequena fração do tráfego real de usuários para o novo modelo e usa sua saída em produção, enquanto a maior parte permanece no modelo estável. O tráfego é então aumentado gradualmente se as métricas de saúde continuarem boas.

Canário trata principalmente de segurança e risco operacional em vez de mensuração rigorosa de produto (embora você possa coletar evidências ao longo do caminho).

Etapas típicas de rollout canário

Uma progressão comum:

1. 0% (apenas shadow ou staging)
2. 1% de tráfego (ou uma pequena coorte interna)
3. 5%
4. 25%
5. 50%
6. 100% (rollout completo)

Em cada etapa, você avalia gates como:

• latência p95/p99, timeouts
• taxa de erro, OOMs, throttling
• custo por requisição (tempo de GPU, tokens)
• sinais de segurança (toxicidade, vazamento de PII)
• KPIs de negócio (conversão, perda por fraude), quando disponíveis

Exemplo de roteamento canário com Istio (tráfego ponderado)

Um exemplo simplificado (ilustrativo):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: ranker
spec:
  hosts:
    - ranker.default.svc.cluster.local
  http:
    - route:
        - destination:
            host: ranker
            subset: v1
          weight: 95
        - destination:
            host: ranker
            subset: v2
          weight: 5

Você combinaria isso com um DestinationRule definindo os subsets v1 e v2.

Considerações de ML específicas de canário

• A seleção de coorte importa: rotear por porcentagem apenas pode enviesar o tráfego (ex.: usuários intensivos geram mais requisições). Considere canarizar por usuário em vez de por requisição quando os desfechos são no nível do usuário.
• Guarda-corpos de qualidade: para classificação/regressão, limiares podem precisar de recalibração; para ranking, métricas podem derivar de modo sutil.
• Fallback de segurança: para LLMs, implemente um fallback de “conclusão segura” ou roteie requisições de alto risco de volta ao modelo estável.
• Rollback automatizado: canário é mais poderoso quando pode reverter rapidamente. Conecte isso aos seus playbooks de incidente em Reversões & Resposta a Incidentes.

Exemplo: canário de modelo de fraude com rótulos atrasados

Rótulos de fraude podem levar dias. Mesmo assim, um canário ajuda a detectar:

• regressões de latência que estouram timeouts em pagamentos
• bugs de esquema causando recusas em massa
• mudança de distribuição causando deslocamentos extremos de score (ex.: todo mundo vira “alto risco”)

Você pode colocar gates em indicadores antecedentes:

• mudanças na taxa de aprovação por segmento
• estabilidade da distribuição de scores
• picos no volume de revisão manual
• códigos de exceção a jusante

Testes A/B (experimentos online controlados)

Um teste A/B divide o tráfego em dois (ou mais) grupos para medir o impacto causal de uma mudança. Diferente do canário, A/B é principalmente para tomada de decisão: o modelo B melhora métricas o suficiente para justificar o rollout?

Na prática, as equipes frequentemente:

• fazem canário por segurança, depois
• fazem A/B para mensuração, depois
• fazem rollout se o resultado for positivo

O que torna A/B “de verdade” (vs apenas um canário)

Para interpretar resultados de forma causal, você precisa de:

• Atribuição aleatória às variantes
• Atribuição estável (sticky bucketing)
• Métricas primárias predefinidas e métricas de guarda-corpo
• Tamanho de amostra / poder estatístico suficientes
• Análise correta (evitar viés de “espiar”; lidar com múltiplas métricas)

Se você pular isso, frequentemente enviará mudanças que “parecem boas” por ruído ou confundimento.

Atribuição sticky via hashing (exemplo)

Uma abordagem típica é bucketing determinístico por ID de usuário:

import hashlib

def bucket(user_id: str) -> float:
    h = hashlib.sha256(user_id.encode("utf-8")).hexdigest()
    return int(h[:8], 16) / 0xFFFFFFFF  # ~[0,1)

def choose_variant(user_id: str) -> str:
    x = bucket(user_id)
    return "B" if x < 0.5 else "A"   # 50/50 split

Isso garante que um usuário veja consistentemente o mesmo modelo, o que reduz variância e evita efeitos de “mistura”.

Métricas para testes A/B de ML/LLM

Escolha:

• Métrica primária: o principal critério de sucesso (ex.: CTR, taxa de conversão, receita, tempo até resolução)
• Guarda-corpos: métricas que não podem piorar (latência, taxa de crash, violações de segurança, churn, indicadores de justiça)

Para modelos, também acompanhe:

• Calibração de score e deriva (Deriva de Dados)
• Resultados de longo prazo (retenção) vs cliques de curto prazo
• Deltas por segmento (novos usuários, localidades, tipos de dispositivo)

Para LLMs:

• Taxa de resolução, taxa de escalonamento, utilidade avaliada pelo usuário
• Violações de política de segurança
• Custo de tokens por desfecho bem-sucedido

Exemplo prático: A/B de modelo de ranking

Você implanta um novo modelo de learning-to-rank (aprendizado para ranqueamento). Você randomiza por usuário e mede:

• Primária: “taxa de adicionar ao carrinho”
• Guarda-corpos: latência p95, abandono de busca, taxa de reclamações

Você também pode registrar métricas offline como NDCG em dados rotulados, mas decisões de envio devem ser guiadas por métricas online quando possível.

Armadilhas estatísticas e experimentais (comuns em ML)

• Interferência/efeitos de rede: a experiência de um usuário afeta outros (precificação em marketplaces, feeds sociais). Premissas padrão de A/B quebram.
• Não estacionariedade: modelos aprendem online ou sofrem deriva; o efeito muda ao longo do tempo.
• Exposição repetida: métricas no nível do usuário exigem atribuição sticky; aleatorização por requisição infla variância.
• Múltiplas comparações: se você acompanha 30 métricas e “escolhe um vencedor”, você vai shippar ruído em excesso.
• Peeking (espiar resultados): checar resultados diariamente e parar quando der significativo enviesará resultados; considere métodos sequenciais ou horizontes fixos.

(Um tratamento estatístico profundo está além desta página, mas o recado operacional é: planeje sua análise antes de executar o teste.)

Escolhendo entre shadow, canário e A/B

Guia rápido de decisão

• Use shadow quando você precisa de confiança em correção e segurança sem impacto ao usuário.
• Use canário quando você está pronto para impacto ao usuário, mas quer rollback rápido se algo quebrar.
• Use A/B quando você precisa de uma estimativa causal de melhoria para justificar uma decisão de produto.

Pipeline progressivo típico

Uma sequência comum no mundo real:

1. Avaliação offline em conjuntos de dados curados (Métricas de Avaliação)
2. Shadow em tráfego de produção amostrado
3. Canário com gates operacionais rígidos e rollback automatizado
4. A/B para quantificar impacto no negócio (ou pular se for mudança apenas de risco)
5. Rollout completo com monitoramento contínuo

Padrões de implementação em sistemas de produção

Padrão 1: Serviço roteador (nível de aplicação)

Um roteador dedicado decide qual endpoint de modelo chamar e lida com:

• atribuição sticky
• fallbacks
• logging
• rate limiting

Prós: flexível, portátil entre infra
Contras: adiciona latência e mais um serviço para operar

Padrão 2: Roteamento por service mesh / gateway

Divisão de tráfego na camada de rede (ex.: Istio) é ótima para canários:

• roteamento ponderado fácil
• retries e circuit breaking
• telemetria consistente

Mas, para A/B com aderência por usuário, você frequentemente ainda precisa de:

• roteamento baseado em header (bucket do usuário passado como header)
• ou roteamento em nível de aplicação

Padrão 3: Escrita dupla / leitura dupla para pipelines de funcionalidades

Falhas em ML muitas vezes vêm das funcionalidades, não do modelo. Rollouts mais seguros às vezes incluem:

• cálculo sombra de funcionalidades (calcular novas funcionalidades e registrá-las)
• pontuação dupla do modelo com ambos os conjuntos de funcionalidades
• validação de que funcionalidades online correspondem às funcionalidades offline de treinamento

Isso reduz o “desalinhamento entre treinamento e serving” (training-serving skew).

Padrão 4: Gate de segurança + fallback (específico de LLM)

Para implantações de LLM, combine rollouts com:

• classificadores de política
• detecção de tópicos sensíveis
• templates de recusa
• fallbacks determinísticos para prompts de alto risco

Um design útil é: o novo modelo fica condicionado a checagens de segurança, e falhas são roteadas para o modelo estável.

Checklists operacionais

Checklist de prontidão para shadow

• Amostragem de tráfego shadow configurada e custo orçado
• Saída + latência + uso de tokens registrados com identificadores de versão
• Checagens automatizadas de segurança/qualidade executando nas saídas shadow
• Critérios claros de promoção para canário

Checklist de prontidão para canário

• Roteamento ponderado e mecanismo de rollback rápido testados
• Gates de SLO/SLA definidos (latência, erros, custo)
• Dashboards de guarda-corpo e alertas em funcionamento
• Playbook de plantão alinhado com Reversões & Resposta a Incidentes

Checklist de prontidão para A/B

• Unidade de randomização escolhida (usuário/conta/sessão) e atribuição sticky implementada
• Métrica primária e guarda-corpos definidos antecipadamente
• Tamanho de amostra ou duração planejados (evitar parar ad-hoc)
• Plano de análise por segmento (para capturar regressões localizadas)
• Logging suporta atribuição de desfechos à variante

Modos comuns de falha (e como evitá-los)

• Shadow parece bom, produção falha: shadow não exercita dependências a jusante (caches, atualidade de funcionalidades, rate limits). Inclua checagens ponta a ponta e canário de qualquer forma.
• Canário passa, mas A/B falha: gates de canário podem focar em métricas operacionais, não em valor para o usuário. Adicione guarda-corpos voltados ao usuário cedo.
• A/B “vence”, mas prejudica métricas de longo prazo: otimiza cliques de curto prazo; acompanhe retenção/qualidade e rode horizontes mais longos quando necessário.
• Regressões silenciosas de segurança: métricas de segurança não foram instrumentadas ou foram amostradas de forma agressiva demais. Trate segurança como um guarda-corpo de primeira classe.
• Ciclos de realimentação contaminam dados de treinamento: registre qual variante produziu quais ações e use isso na seleção de dados de treinamento.

Resumo

Implantações shadow, canário e A/B são ferramentas complementares para reduzir risco e melhorar a qualidade de decisão em rollouts de ML e LLM:

• Shadow: validar correção, desempenho e segurança em entradas reais sem impacto ao usuário.
• Canário: expor usuários progressivamente enquanto controla rigorosamente o raio de impacto e permite rollback rápido.
• A/B: quantificar impacto causal e tomar decisões de produto com confiança.

Usadas em conjunto — com versionamento, roteamento e observabilidade fortes — essas práticas formam a espinha dorsal de um Servir Modelos seguro e moderno em MLOps.