Tudo que você aprendeu até aqui se prova em produção. Aqui você vê padrões para deploy seguro: A/B, canário, rollback rápido, observabilidade. Este módulo é beta — práticas amadurecem com a indústria.
🚦 Anatomia do deploy seguro de LLM
Não é sobre ter coragem — é sobre ter os switches certos antes de precisar deles.
- •1. A/B em pequena % com métrica primária e timeline.
- •2. Canário: 5% → 25% → 100% se métricas OK.
- •3. Rollback hot, em <1 min.
- •4. Kill switch independente do rollback.
- •5. Eval contínuo + alertas.
💡 Implemente kill switch antes de qualquer rollout
Não confie em rollback. Kill switch deve estar em produção e testado antes da primeira liberação. Sem isso, você está exposto a desastre.
🆎 A/B em prompt: variant + métrica primária
Decisão por dado, não opinião
A/B em prompt: roteia % do tráfego para variant, mede métrica primária com significância estatística. Distingue 'achei que melhorou' de 'melhorou medido'. Atenção a sample size: 100 amostras raramente bastam; calcule N necessário antes de rodar.
from scipy.stats import ttest_ind
def roteia(user_id: str) -> str:
return 'v1.1.0' if hash(user_id) % 100 < 10 else 'v1.0.0'
# Após coletar dados:
scores_a = [...] # n=500 da v1.0.0
scores_b = [...] # n=500 da v1.1.0
t, p = ttest_ind(scores_a, scores_b)
if p < 0.05 and scores_b.mean() > scores_a.mean():
print('promote v1.1.0')📑 Resumo navegável
🐤 Canário: rollout incremental
5% → 25% → 100%
Canário é rollout incremental: 5% → 25% → 100% se métricas mantêm. Mudança de modelo (de Claude 4.5 para 4.6) pode quebrar 5% dos casos. Canário pega antes do fan-out total. Sem canário, você está apostando sua produção na qualidade do release notes do provedor.
| Fase | % tráfego | Duração | Critério para subir |
|---|---|---|---|
| 1. canário inicial | 5% | 24-48h | p95 ≤ baseline + 10%, sem incidentes |
| 2. canário expandido | 25% | 24-48h | métricas qualitativas estáveis |
| 3. promoção plena | 100% | — | — |
📑 Resumo navegável
↩️ Rollback rápido: pré-requisito de canário
1 click
Rollback em <1 min é pré-requisito de canário. Versão anterior fica 'quente' (warm cache, modelo carregado). Botão único reverte. Sem isso, canário é teatro: você descobre o problema mas não tem como sair dele rápido.
VARIANT_ATIVO = featureflag.get('llm_variant', 'v1.0.0')
def chamar_llm(query):
if VARIANT_ATIVO == 'v1.0.0':
return pipeline_v1_0_0(query)
elif VARIANT_ATIVO == 'v1.1.0':
return pipeline_v1_1_0(query)
# rollback = mudar VARIANT_ATIVO no flag service (segundos)📑 Resumo navegável
📈 Observabilidade contínua: o que monitorar
Métricas + alertas
Em produção, problemas se manifestam em números antes de virarem reclamações. Dashboards essenciais: latência p50/p95, erro rate, custo, hit de cache, qualidade contínua (judge automático em %). Alertas em desvios significativos — não em valor absoluto.
SLOs típicos para LLM em produção
- ▸Disponibilidade: 99.5% (provedor + retries).
- ▸Latência p95: ≤ 3× p50 (detecta cauda gorda).
- ▸Erro rate: ≤ 1% (excluindo erros do usuário).
- ▸Hit de cache: ≥ 70% em chats com prefixo grande.
- ▸Qualidade contínua: ≥ baseline -2 pp (judge automático).
📑 Resumo navegável
🛑 Kill switch: parar feature instantaneamente
Botão de emergência
Kill switch é flag de configuração que desabilita a feature LLM instantaneamente. Tráfego volta para fallback estático ou erro educativo. Modelo do provedor pode degradar do nada — kill switch dá tempo de investigar sem disaster. Implemente ANTES de qualquer rollout.
def chamar_modelo(query):
if not featureflag.is_enabled('llm_classify'):
return fallback_estatico(query) # ex.: regra heurística simples
try:
return pipeline_llm(query)
except (ProviderError, TimeoutError) as e:
log.error(f'llm fail: {e}')
return fallback_estatico(query)📑 Resumo navegável
🔁 Eval contínuo em produção
Não só pré-deploy
Eval pré-deploy é necessário mas não suficiente. Modelos do provedor mudam; corpus muda; usuários mudam. Eval contínuo em produção (1-5% do tráfego avaliado por LLM-judge automático) captura drift sem esperar reclamação. Cuidado: judge consome tokens — orçar.
from random import random
def chamar_llm_com_eval(query):
resp = pipeline_llm(query)
# 2% do tráfego é judgeado em background
if random() < 0.02:
scheduler.submit(judge_async, query, resp)
return resp
def judge_async(query, resp):
score = llm_judge_groundedness(query, resp)
metrics.gauge('quality_continuous').record(score, tags={'variant': VARIANT_ATIVO})📑 Resumo navegável
📑 Resumo navegável dos tópicos
1 🆎 A/B em prompt: variant + métrica primária — Decisão por dado, não opinião
2 🐤 Canário: rollout incremental — 5% → 25% → 100%
3 ↩️ Rollback rápido: pré-requisito de canário — 1 click
4 📈 Observabilidade contínua: o que monitorar — Métricas + alertas
5 🛑 Kill switch: parar feature instantaneamente — Botão de emergência
6 🔁 Eval contínuo em produção — Não só pré-deploy
✓ O que FAZER
- ✓A/B com métrica primária e sample size calculado
- ✓Canário 5% → 25% → 100% por dia
- ✓Kill switch testado e documentado
- ✓Eval contínuo em produção sampling 1-5%
✗ O que NÃO fazer
- ✗Eyeballing 'parece melhor'
- ✗Big bang rollout
- ✗'Vamos torcer pra não dar problema'
- ✗Eval só em CI
🚫 Quando NÃO usar
- •Volume baixo: A/B precisa de N significativo; com pouco tráfego, espera mais.
- •Mudança trivial e auditada: typo de prompt não precisa de canário.
- •Sem instrumentação básica: implemente tracing ANTES de pensar em rollout sofisticado.
💻 Exemplo de código
# Esquema de feature flag + canário
from random import random
def chamar_modelo(query: str, user_id: str) -> str:
# Kill switch — flag externo (ex.: ConfigCat, LaunchDarkly, env var)
if feature_flag("llm_enabled") is False:
return fallback_estatico(query)
# Canário: 5% recebe variant nova
if hash(user_id) % 100 < 5:
variant = "v1.1.0"
else:
variant = "v1.0.0" # estável
resposta = pipeline_llm(query, variant=variant)
# Eval contínuo: 1% do tráfego é judgeado
if random() < 0.01:
score = judge_async(query, resposta)
emit_metric("groundedness", score, tags={"variant": variant})
return resposta🏋️ Exercício hands-on
Adicione A/B + canário + kill switch + eval contínuo ao P5 (pipeline em produção). Demonstre rollback em 1 min. Em projetos/P5/.
📚 Bibliografia
- Google SRE Book — Production rollout best practices
- Honeycomb — Observability for LLM systems
- Arize AI — ML observability
- Anthropic (2024) — Building safer agentic systems
🎯 Resumo do Módulo
- ✓A/B em prompt com métrica primária e significância.
- ✓Canário 5%→25%→100% — não big bang.
- ✓Kill switch antes de qualquer rollout.
- ✓Rollback hot <1 min — pré-requisito de canário.
- ✓Eval contínuo em produção captura drift.
Próximo Módulo:
Projeto Final P5 — Pipeline em produção