Avaliação em Produção

O Que Significa “Avaliação em Produção”

Avaliação em produção é a disciplina de medir e validar o comportamento de um modelo enquanto o modelo está atendendo tráfego real. Ela combina três capacidades complementares:

  1. Métricas online (online metrics): medir continuamente resultados do usuário, do negócio e do sistema (muitas vezes com rótulos atrasados ou ruidosos).
  2. Avaliação contrafactual (counterfactual evaluation) (a.k.a. avaliação fora de política (off-policy evaluation)): estimar como um novo modelo ou política teria se comportado sem implantá-lo totalmente.
  3. Experimentação segura (safe experimentation): executar implantações controladas (testes A/B, canários, interleaving) com proteções para minimizar danos.

A validação offline (conjuntos de teste, backtests) é necessária, mas insuficiente, porque a produção introduz:

  • Mudança de distribuição (distribution shift) (novos usuários, novo conteúdo, sazonalidade)
  • Ciclos de feedback (feedback loops) (recomendações mudam o que os usuários veem, o que muda dados futuros)
  • Observabilidade parcial (partial observability) (você só observa resultados para ações que tomou)
  • Restrições do mundo real (real-world constraints) (latência, custo, segurança, conformidade)

Este artigo foca na teoria e na prática de avaliar modelos como parte de operá-los, e em como isso se conecta a Monitoramento, Observabilidade para Apps de LLM, SLOs para Funcionalidades de IA e Volantes de Dados.

Métricas Online: O Que Medir e Por Quê

Camadas de métricas: negócio, usuário, modelo e sistema

Uma forma prática de estruturar a avaliação em produção é definir métricas em quatro camadas:

  1. Métricas de negócio

    • Receita por sessão, taxa de conversão, churn, custo por resolução
    • Muitas vezes o objetivo final, mas geralmente atrasado e confundido (sazonalidade, marketing)

  2. Métricas de experiência do usuário

    • Taxa de cliques (CTR), tempo de permanência, taxa de sucesso da tarefa, uso recorrente
    • Mais imediatas, mas podem ser manipuladas (por exemplo, clickbait aumenta o CTR)

  3. Métricas de qualidade do modelo

    • Precisão/recall, calibração, métricas de ranqueamento (NDCG), avaliações humanas, violações de segurança
    • Frequentemente exigem rótulos (podem estar atrasados ou ausentes)

  4. Métricas do sistema

    • Latência (p50/p95/p99), taxa de erro, timeouts, uso de tokens, utilização de GPU
    • Essenciais porque um modelo “melhor” que é mais lento pode reduzir resultados do usuário

Em produção, você normalmente acompanha um pequeno conjunto de métricas primárias (o que você otimiza) e métricas de proteção (guardrail metrics) (o que não pode regredir).

Indicadores antecedentes vs. defasados

Muitos resultados importantes são atrasados. Por exemplo:

  • Modelos de fraude: rótulos de fraude reais podem chegar dias depois.
  • Relevância de busca: compras acontecem após múltiplas sessões.
  • Assistentes de LLM: “isso foi útil?” pode ser opcional e esparso.

Um padrão comum é definir:

  • Indicadores antecedentes (leading indicators) (disponíveis imediatamente): clique, permanência, prompts de avaliação do usuário, taxa de abandono, taxa de reformulação
  • Indicadores defasados (lagging indicators) (chegam mais tarde): reembolsos, chargebacks, retenção, QA humano

Em seguida, você valida que os indicadores antecedentes são preditivos dos resultados defasados, em vez de assumir que são.

Proteções que importam em produção

As proteções devem refletir risco real. Exemplos comuns:

  • Segurança: taxa de toxicidade, violações de política, taxa de sucesso de jailbreak (apps de LLM)
  • Confiabilidade: taxa de crash, timeouts, resultados vazios
  • Justiça (fairness): métricas de impacto desigual por coorte (quando apropriado e legal)
  • Custo: custo por requisição, tokens por tarefa bem-sucedida
  • Latência: latência p95 ponta a ponta e amplificação de cauda sob carga

Isso se conecta diretamente à definição de metas em SLOs para Funcionalidades de IA.

Instrumentação: Registrando o Que Você Precisa (Sem Arrependimentos)

A avaliação online é tão boa quanto os dados que você registra. Um log típico de avaliação em produção normalmente precisa de:

  • Um request_id / session_id estável
  • Identificadores de modelo/versão (modelo, prompt, config de recuperação, versão do pipeline de features)
  • A ação tomada (lista ranqueada, resposta escolhida, decisão por limiar)
  • A propensão dessa ação (probabilidade sob a política de serving) para avaliação contrafactual
  • Features de usuário/contexto (com escopo cuidadosamente definido; veja Privacidade em Logs)
  • Resultados observados (clique, compra, avaliação do usuário), com timestamps

Exemplo de esquema (simplificado):

{
  "timestamp": "2026-01-06T10:14:22Z",
  "request_id": "abc-123",
  "user_id_hash": "u_9f…",
  "context": {
    "locale": "en-US",
    "device": "mobile"
  },
  "served_policy": {
    "model_version": "ranker_v42",
    "prompt_version": null,
    "feature_pipeline_version": "fs_2026_01_05"
  },
  "action": {
    "type": "ranked_list",
    "items": ["i17", "i02", "i99"]
  },
  "propensity": {
    "method": "softmax_sampling",
    "p_action": 0.12
  },
  "outcomes": {
    "clicked_item": "i02",
    "dwell_seconds": 18.4
  }
}

Para sistemas de LLM, também registre traces estruturados (prompt, chamadas de ferramenta, resultados de recuperação, filtros de segurança) usando padrões descritos em Observabilidade para Apps de LLM.

Fundamentos Estatísticos: Comparando Métricas Online Corretamente

Variância, sazonalidade e dados correlacionados

Dados de produção são bagunçados:

  • Usuários geram múltiplos eventos → observações são correlacionadas.
  • Tráfego muda por hora/dia → forte sazonalidade.
  • Fatores externos (campanhas, incidentes) criam não estacionariedade.

Implicações práticas:

  • Prefira agregação por usuário (por exemplo, métrica média por usuário) antes de comparar variantes.
  • Use controles baseados em tempo (rode testes em ciclos semanais completos).
  • Considere estratificação (compare dentro de coortes como localidade/dispositivo).

Intervalos de confiança e “significância prática”

Significância estatística não implica valor de negócio. Na avaliação em produção, você quer ambos:

  • Confiança (o efeito é real?)
  • Tamanho de efeito (vale a pena lançar?)

Uma prática útil é definir um efeito mínimo detectável (minimum detectable effect, MDE) e um efeito mínimo prático (minimum practical effect, MPE) para cada métrica primária.

Múltiplas métricas e múltiplas comparações

Se você acompanha 20 métricas e comemora qualquer vitória significativa, você vai lançar regressões. Mitigações incluem:

  • Pré-registrar um pequeno número de métricas primárias
  • Usar proteções como restrições rígidas
  • Aplicar métodos de correção (por exemplo, Benjamini–Hochberg) ao explorar muitas métricas

Experimentação Segura: De Testes A/B a Canários

Padrões centrais de experimentação

  1. Teste A/B (ensaios controlados randomizados)

    • Padrão-ouro quando viável
    • Atribuir usuários/sessões aleatoriamente a controle vs. tratamento

  2. Implantações canário (canary rollouts)

    • Aumentar gradualmente o tráfego para um novo modelo enquanto monitora proteções
    • Frequentemente usado quando as métricas são lentas ou o risco é alto

  3. Modo sombra (shadow mode)

    • O novo modelo roda em paralelo, mas não afeta saídas visíveis ao usuário
    • Ótimo para latência, estabilidade e comparação offline; limitado para métricas de resultado do usuário

  4. Interleaving (ranqueamento/busca)

    • Misturar resultados de dois rankers em uma lista para obter sinais de preferência mais rápidos
    • Reduz variância em comparação ao A/B padrão para problemas de ranqueamento

Essas implantações devem se integrar com Registro de Modelos (promoção/rollback) e CI/CD para Modelos (gates automatizados).

Desenhando uma implantação segura: um exemplo

Suponha que você esteja implantando um novo assistente de suporte baseado em LLM. Um plano seguro poderia ser:

  • Stage 0: Avaliação offline em suítes de teste curadas + prompts de red-team
  • Stage 1: Modo sombra por 1–2 dias
    Medir latência, taxa de erro de ferramenta, taxa de recusa e comparar com saídas baseline.
  • Stage 2: Canário a 1% com proteções rígidas
    Auto-rollback se: latência p95 +20%, taxa de escalonamento +5%, violações de política > limiar.
  • Stage 3: Teste A/B 10–50%
    Métrica primária: taxa de deflexão de casos (antecedente), Proteção: queda de CSAT, violações de segurança.
  • Stage 4: Rampa para 100% + manter um holdout (por exemplo, 5%) para detecção de drift de longo prazo.

Um “holdout” é valioso porque preserva um baseline contínuo para detectar regressões lentas e efeitos de ciclo de feedback ao longo do tempo.

Proteções e kill switches

Experimentação segura requer controles operacionais:

  • Rollback automático baseado em violações de proteções
  • Kill switch manual para incidentes
  • Limitação de taxa e disjuntores (circuit breakers) para falhas de dependências (ferramentas, recuperação)
  • Fallbacks (por exemplo, modelo menor, resposta por template) como descrito em Padrões de Design de Sistemas de LLM

Avaliação Contrafactual (Off-Policy Evaluation): Medindo o Que Você Não Implantou

O problema central: você só observa resultados para ações escolhidas

Em recomendação, ranqueamento, anúncios e sistemas tipo bandit, você observa feedback apenas do que mostrou:

  • Você recomendou o item A → você observa se A foi clicado.
  • Você não recomendou o item B → você não observa se B teria sido clicado.

Este é o problema contrafactual e ele quebra a avaliação ingênua de replay offline.

A avaliação contrafactual aborda isso usando dados registrados de uma política de comportamento (behavior policy) (a política que gerou os logs) para estimar desempenho de uma política alvo (target policy) (o novo modelo).

Scores de propensão e a ideia de amostragem por importância

Se a política de comportamento escolheu a ação (a) no contexto (x) com probabilidade (p(a|x)), então resultados observados sob a política de comportamento podem ser reponderados para aproximar resultados sob uma política alvo.

O estimador mais comum é Pontuação Inversa por Propensão (Inverse Propensity Scoring, IPS):

[ \hat{V}{IPS}(\pi) = \frac{1}{N}\sum{i=1}^{N} \frac{\pi(a_i|x_i)}{p(a_i|x_i)} r_i ]

  • (r_i) é a recompensa observada (clique, compra etc.)
  • (p(a_i|x_i)) é a propensão registrada sob a política de comportamento
  • (\pi(a_i|x_i)) é a probabilidade de a política alvo escolher a mesma ação

Em políticas alvo determinísticas, (\pi(a_i|x_i)) é 1 se ela tomaria aquela ação; caso contrário, 0.

Exemplo prático de IPS (recompensa binária)

def ips_estimate(logs, target_policy_prob):
    """
    logs: iterable of dicts with fields:
      - x: context
      - a: action taken
      - r: reward observed (0/1)
      - p: behavior propensity p(a|x)
    target_policy_prob(x, a): returns pi(a|x)
    """
    total = 0.0
    n = 0
    for e in logs:
        w = target_policy_prob(e["x"], e["a"]) / max(e["p"], 1e-12)
        total += w * e["r"]
        n += 1
    return total / max(n, 1)

Por que a avaliação contrafactual é difícil na prática

  1. Você deve registrar propensões corretamente

    • Se você não consegue computar (p(a|x)), estimadores do tipo IPS são inválidos.

  2. A variância pode explodir

    • Se a política alvo dá peso a ações raramente tomadas pela política de comportamento, os pesos (\pi/p) ficam enormes.

  3. Incompatibilidade de suporte

    • Se a política de comportamento nunca tomou certas ações em uma região do espaço de contexto, você não consegue avaliar políticas que as escolhem.

  4. Trade-off viés–variância

    • Métodos que reduzem variância frequentemente introduzem viés; você deve escolher com base na tolerância a risco.

Estimadores comuns além de IPS

  • IPS auto-normalizado (Self-normalized IPS, SNIPS): reduz variância normalizando pesos, mas adiciona algum viés.
  • Duplamente Robusto (Doubly Robust, DR): combina um modelo de desfecho (\hat{r}(x,a)) com IPS; frequentemente mais estável.
  • Método Direto (Direct Method, DM): prediz recompensa com um modelo supervisionado; pode ser enviesado se o modelo estiver errado.

Uma regra prática: se você consegue construir um modelo de recompensa razoável e tem propensões, DR frequentemente é um baseline forte.

Avaliação contrafactual para ranqueamento e recomendadores

Para ranqueamento, “a ação” é uma lista, que é combinatoriamente grande. Estratégias práticas incluem:

  • Registrar componentes randomizados (por exemplo, trocar posições com probabilidade conhecida)
  • Avaliar no nível de propensões item-posição
  • Usar interleaving online para reduzir dependência de OPE quando possível

Onde a avaliação contrafactual se encaixa em um fluxo de trabalho de produção

A avaliação contrafactual é mais útil quando:

  • Experimentos online são caros ou arriscados
  • Você precisa filtrar modelos candidatos antes do teste A/B
  • Você está iterando rapidamente (por exemplo, muitas variantes de ranker)

Um fluxo de trabalho comum:

  1. Treinar muitos candidatos offline.
  2. Rodar avaliação contrafactual em dados registrados para eliminar perdedores óbvios.
  3. Testar A/B apenas os melhores candidatos com proteções fortes.

Isso complementa (não substitui) a experimentação online.

Considerações Específicas de LLM para Avaliação em Produção

Sistemas de LLM frequentemente se comportam como políticas sobre texto e ações de ferramentas, e a avaliação tem desafios extras:

Métricas além de “acurácia”

Métricas online úteis para apps de LLM incluem:

  • Sucesso da tarefa (confirmação explícita do usuário, sinais de conclusão)
  • Taxa de sucesso de ferramenta (chamadas de API funcionam, schemas válidos)
  • Sinais de “arrependimento” (regret): usuário re-prompta, abandona, escala para humano
  • Métricas de segurança: violações de política, incidentes de vazamento de PII
  • Métricas de custo: tokens por tarefa resolvida, chamadas de ferramenta por sessão

Avaliação automatizada e sinais avaliados pelo modelo

Muitas equipes usam avaliadores “LLM como juiz (LLM-as-a-judge)” em pipelines de produção (por exemplo, para pontuar utilidade ou conformidade com rubricas). Trate isso como dispositivos de medição ruidosos:

  • Calibre avaliadores contra rótulos humanos
  • Monitore drift no comportamento do avaliador (especialmente se o modelo avaliador for atualizado)
  • Mantenha avaliadores fora do caminho crítico para decisões em tempo real, a menos que a latência permita

Versionamento de prompt e configuração é essencial; veja PromptOps e Versionamento (Dados, Código, Modelos).

Ciclos de feedback são mais rápidos

Se um agente de LLM começa a chamar uma ferramenta incorretamente, ele pode gerar:

  • Falhas em cascata (recuperação ruim → resposta ruim → mais tentativas)
  • Picos de carga (loops de retry, conversas mais longas)

Experimentação segura deve incluir proteções de chamada de ferramenta e limites de orçamento.

Juntando Tudo: Um Playbook Prático de Avaliação em Produção

1) Defina o contrato de avaliação

Para cada funcionalidade de IA, documente:

  • Métrica(s) primária(s) e por que elas se alinham ao objetivo do produto
  • Proteções (segurança, latência, custo, justiça)
  • Unidade de randomização (usuário, sessão, requisição)
  • Política de decisão: o que se qualifica como “lançar”, “iterar” ou “rollback”

2) Instrumente uma vez, use em todo lugar

Projete logs para suportar:

  • Dashboards online (quase em tempo real)
  • Análise de experimentos
  • Avaliação contrafactual
  • Forense pós-incidente

Coordene isso com Rastreamento de Experimentos e Treinamento Reprodutível (Configs, Artefatos).

3) Comece com shadow + canary, depois A/B

Um padrão seguro para mudanças significativas:

  • Shadow para validar correção e custo/latência
  • Canary para validar proteções de segurança sob tráfego real
  • A/B para medir impacto no usuário e no negócio

4) Use avaliação contrafactual para reduzir a carga de experimentos

Quando você tem muitas políticas candidatas, use OPE como uma camada de triagem para evitar rodar muitos testes online.

5) Mantenha um holdout e monitore efeitos de longo prazo

Mantenha um pequeno holdout baseline para detectar:

  • Regressões lentas
  • Dinâmicas de ciclo de feedback (por exemplo, homogeneização do recomendador)
  • Mudança de distribuição

Em seguida, conecte a avaliação a alertas de Monitoramento contínuos e recalibração periódica.

Modos de Falha Comuns (e Como Evitá-los)

  • Otimizar uma métrica proxy que diverge do valor

    • Exemplo: CTR aumenta, mas a retenção do usuário cai devido a clickbait.
    • Correção: validar proxies contra resultados de longo prazo; usar proteções.

  • Registrar logs sem propensões

    • Você não consegue fazer avaliação contrafactual confiável depois.
    • Correção: desenhar exploração e registro de propensão desde cedo.

  • Experimentos enviesados por interferência

    • Em marketplaces/feeds sociais, o tratamento de um usuário afeta os resultados de outro.
    • Correção: randomização por cluster, desenho de experimento ciente de rede.

  • Espiar (peeking) e testes repetidos

    • Olhar resultados diariamente e parar quando ficar significativo aumenta falsos positivos.
    • Correção: métodos de teste sequencial ou janelas de avaliação pré-definidas.

  • Lançar sem automação de rollback

  • Ignorar latência de cauda

    • A latência média parece boa, mas p99 prejudica UX e conversões downstream.
    • Correção: tratar latência de cauda como proteção.

Resumo

Avaliação em produção não é uma técnica única; é um modelo operacional:

  • Métricas online dizem o que está acontecendo agora, mas exigem definições cuidadosas, instrumentação e disciplina estatística.
  • Avaliação contrafactual permite estimar “o que teria acontecido” usando propensões registradas, ajudando você a iterar com segurança e eficiência.
  • Experimentação segura (shadow, canary, A/B, interleaving) fornece evidência causal enquanto minimiza risco por meio de proteções, rollbacks e exposição em etapas.

Quando bem feita, a avaliação em produção transforma a implantação em um ciclo de aprendizado controlado—viabilizando iteração confiável e o tipo de melhoria contínua descrita em Volantes de Dados.