Observabilidade e Evals em Produção: O Fechamento do LLMOps

Este é o quinto e último artigo da série LLMOps em Produção. No artigo anterior sobre guardrails runtime, vimos como bloquear, filtrar e moldar respostas antes que cheguem ao usuário. Mas todo guardrails depende de uma decisão anterior: qual versão de prompt, qual versão de modelo, qual rota, qual cache. Essas decisões só podem ser auditadas quando o sistema é observável.

Sem prompt completo, versão de modelo e veredito do eval no mesmo span, você não tem observabilidade generativa. Você tem um log de servidor tradicional fingindo que entende LLM.

Principais aprendizados

• Observabilidade generativa exige atributos específicos: prompt completo, versão do modelo, tools usadas, tokens, custo e veredito do eval no mesmo span.
• OpenTelemetry com GenAI semantic conventions (gen_ai.*) é o padrão que evita vendor lock-in de telemetria.
• Online evals (shadow) rodando golden set periódico contra produção são a única forma de detectar drift de modelo silencioso.
• Latência p95/p99, erro rate, cache hit rate e guardrail block rate são métricas operacionais; eval score rolling é métrica de qualidade.
• Rollback automático baseado em degradação de métricas transforma incidente em rotina, não em página aos 3 da manhã.

Por que observabilidade tradicional falha para LLM

OpenTelemetry e GenAI semantic conventions

OpenTelemetry (OTel) é o padrão aberto de telemetria. A vantagem sobre soluções proprietárias é que você não fica refém de um vendor de observabilidade.

A distinção entre gen_ai.request.model e gen_ai.response.model é crítica. Você pode pedir claude-sonnet-4 e receber uma snapshot atualizada do provedor. Sem essa separação, drift de modelo fica invisível.

O diagrama completo: do request ao rollback

Tracing: span por chamada, span por tool, span por guardrail

Código: hook OTel com GenAI attributes

import { trace, SpanStatusCode } from '@opentelemetry/api';

const tracer = trace.getTracer('llmops.app');

type LLMSpanAttributes = {
  promptVersion: string;
  modelRequested: string;
  modelResponded: string;
  temperature: number;
  maxTokens: number;
  toolsAvailable: string[];
  toolsUsed: string[];
  route: string;
  cacheHit: boolean;
  guardrailVerdict: 'pass' | 'block' | 'transform';
};

export async function withLLMSpan<T>(
  attributes: LLMSpanAttributes,
  fn: () => Promise<T>,
): Promise<T> {
  return tracer.startActiveSpan(
    'llm.request',
    { attributes: flattenAttributes(attributes) },
    async (span) => {
      try {
        const result = await fn();
        span.setAttribute('gen_ai.request.model', attributes.modelRequested);
        span.setAttribute('gen_ai.response.model', attributes.modelResponded);
        span.setAttribute('llmops.prompt_version', attributes.promptVersion);
        span.setAttribute('llmops.route', attributes.route);
        span.setAttribute('llmops.cache_hit', attributes.cacheHit);
        span.setAttribute('llmops.guardrail_verdict', attributes.guardrailVerdict);
        span.setAttribute('llmops.tools_used_count', attributes.toolsUsed.length);
        span.setStatus({ code: SpanStatusCode.OK });
        return result;
      } catch (error) {
        span.recordException(error as Error);
        span.setStatus({ code: SpanStatusCode.ERROR });
        throw error;
      } finally {
        span.end();
      }
    },
  );
}

O ponto-chave é capturar prompt_version. Sem isso, regressão após um git revert de prompt fica indistinguível de regressão de modelo.

Exemplo de span capturado

llm.request                       1.84s
├─ gen_ai.system: anthropic
├─ gen_ai.request.model: claude-sonnet-4-20250514
├─ gen_ai.response.model: claude-sonnet-4-20250514-r2
├─ llmops.prompt_version: summarizer.v3.4.1
├─ llmops.route: long_context_fallback
├─ gen_ai.usage.input_tokens: 4200
├─ gen_ai.usage.output_tokens: 380
├─ llmops.cost_usd: 0.0234
├─ llmops.guardrail_verdict: pass
└─ llmops.eval.verdict: pass (judge_score: 0.82)

Métricas que importam

Métricas operacionais

Métricas de qualidade

Drift de modelo: o assassino silencioso

O drift de modelo funciona assim:

1. Seu eval passa em staging.
2. Você promove para produção.
3. Três semanas depois, o provedor atualiza a snapshot internamente (sem alterar o nome do modelo).
4. Algumas classes de respostas começam a falhar.
5. Erro rate está estável (respostas são 200).
6. Usuários reclamam. Sua equipe procura bugs no código. Não encontra.

type DriftBaseline = {
  promptVersion: string;
  modelName: string;
  baselineScore: number;
  threshold: number; // queda aceitável
  windowSize: number; // número mínimo de amostras
};

export function checkDrift(
  baseline: DriftBaseline,
  recentScores: number[],
): DriftVerdict {
  if (recentScores.length < baseline.windowSize) {
    return { kind: 'insufficient_samples', samples: recentScores.length };
  }
  const currentScore =
    recentScores.reduce((a, b) => a + b, 0) / recentScores.length;
  const delta = baseline.baselineScore - currentScore;
  if (delta > baseline.threshold) {
    return { kind: 'drift', score: currentScore, dropFrom: baseline.baselineScore, delta };
  }
  return { kind: 'stable', score: currentScore };
}

Online evals e shadow evals

Evals offline (CI/staging) protegem contra regressões conhecidas. Evals online (produção) protegem contra regressões desconhecidas. O padrão é amostrar 1% a 5% das requisições e julgar essas.

Golden set: o ativo mais valioso

Conjunto curado (entre 50 e 500 casos) que cobre:

• Casos felizes típicos (60%).
• Casos de borda (20%).
• Casos adversariais (15%): prompt injection, PII.
• Casos de regressão documentados (5%).

LLM-as-judge em produção

Vieses conhecidos: position bias, self-preference bias, verbosity bias, format bias. Mitigações:

1. Use um modelo diferente do modelo julgado.
2. Normalize o tamanho da resposta antes de julgar.
3. Calibre contra julgamentos humanos no golden set inicial.

Alertas: do ruído ao sinal

Rollback automático

export function evaluateRollback(
  current: Version,
  previous: Version,
  recentSamples: number[],
  baseline: number,
  policy: RollbackPolicy,
): RollbackDecision {
  if (!previous.isStable) {
    return { kind: 'escalate', reason: 'versão anterior não está marcada como estável' };
  }
  if (recentSamples.length < 20) {
    return { kind: 'no_action', reason: 'amostras insuficientes para decidir' };
  }
  const currentScore = recentSamples.reduce((a, b) => a + b, 0) / recentSamples.length;
  const delta = baseline - currentScore;
  if (delta <= policy.thresholdDelta) {
    return { kind: 'no_action', reason: 'métrica dentro do aceitável' };
  }
  return {
    kind: 'rollback',
    from: current,
    to: previous,
    reason: `${policy.metric} caiu ${delta.toFixed(3)} abaixo do baseline ${baseline}`,
  };
}

Anti-patterns de observabilidade generativa

• Logar sem prompt completo: regressão é indetectável.
• Sem versão de modelo no span: claude-sonnet-4 não é versão; claude-sonnet-4-20250514 é.
• Alertar sem baseline: "p95 subiu para 4s" — subiu em relação a quê?
• Rollback manual em incidente: 40 minutos vs 2 minutos com feature flag.
• Amostrar demais ou de menos: o ponto ótimo está entre 1% e 5%.
• Não distinguir erro explícito de erro semântico: erro rate e eval score precisam coexistir.
• Guardar traces para sempre: 7 dias hot, 30 dias warm com PII redacted.

Como aplicar hoje

1. Instrumente uma rota crítica com OTel e gen_ai.* attributes.
2. Adicione prompt_version como atributo de span e métrica.
3. Construa um golden set inicial com 50 casos.
4. Rode shadow eval em 2% das respostas por duas semanas.
5. Configure três alertas críticos com thresholds explícitos.
6. Implemente feature flag de versão de prompt.
7. Adicione rollback manual documentado. Depois de 3 incidentes, automatize.

Checklist de observabilidade generativa em produção

• Toda chamada de modelo vira um span OTel com gen_ai.* attributes.
• Span raiz carrega prompt_version, traceId, user_id, feature_flag.
• gen_ai.request.model e gen_ai.response.model são capturados separadamente.
• Tokens de entrada e saída são registrados por span.
• Custo por request é calculado e atribuído.
• Latência p50, p95 e p99 estão em um dashboard operacional.
• Golden set com no mínimo 50 casos é versionado em git.
• Shadow eval roda em produção com amostragem entre 1% e 5%.
• Função checkDrift() roda a cada hora contra baseline.
• Alertas comparam contra baseline explícito.
• Feature flag de versão de prompt permite rollback sem redeploy.
• Rollback automático implementado para ao menos uma rota crítica.

Recap da série LLMOps em Produção

1. Introdução ao LLMOps — o que muda quando você coloca um LLM em produção.
2. Roteamento de modelos — como escolher o modelo certo por request.
3. Cache semântico e memória — cache semântico vs exato, TTL, invalidação.
4. Guardrails runtime — camadas de defesa: input filter, output filter, schema validation.
5. Observabilidade e evals em produção — este artigo. Fechamento com OTel, drift detection e rollback.

A série cobre o ciclo completo: escolher o modelo, rotear, cachear, proteger, observar e reverter. Cada peça alimenta a próxima.

Conclusão

Observabilidade generativa não é luxo de equipe grande. É a única diferença entre um sistema que escala e um sistema que apodrece em silêncio durante meses.

Sem prompt_version no span, você não sabe quem causou a regressão. Sem gen_ai.response.model separado de gen_ai.request.model, você não detecta drift silencioso. Sem online evals, você descobre que o modelo piorou quando o cliente cancela. Sem rollback automático, todo incidente vira reunião de guerra.

A série termina onde deveria começar: toda decisão de produto sobre LLM precisa de evidência operacional. Não de impressão. Não de "parece bom em staging". De traces completos, métricas com baseline, evals rodando em produção e rollback testado.

O LLMOps maduro não é sobre ter o modelo mais caro nem o prompt mais elaborado. É sobre transformar cada requisição em uma unidade auditável de engenharia. O resto é decoração.

Fim da série.

Referências

• OpenTelemetry GenAI semantic conventions
• Observability for LLMs — Honeycomb
• Evals are all you need — Hamel Husain
• LLM judge bias and mitigation — Anthropic
• Demystifying evals for AI agents — Anthropic
• OpenLLMetry GenAI conventions