1.1 A promessa fácil e a dívida escondida

Construir um app de LLM começou trivial: uma chamada de API, um prompt, uma resposta convincente numa demo. O problema aparece depois: você mudou uma frase do prompt e não sabe se melhorou ou piorou; um usuário reclamou de uma resposta que você não consegue reproduzir; o custo mensal triplicou sem explicação; trocou de modelo e três casos que funcionavam quebraram silenciosamente.

LLMOps é o conjunto de práticas e ferramentas para operar sistemas de LLM com o mesmo rigor de qualquer software crítico: versionar o que importa, medir a qualidade de forma repetível, observar o comportamento em produção, iterar com base em evidência e controlar custo e latência.

1.2 O ciclo de vida de um sistema de LLM

   ┌────────────┐   ┌──────────────┐   ┌─────────────┐   ┌────────────┐   ┌──────────────┐
   │ 1. Definir │──▶│ 2. Construir │──▶│ 3. Avaliar  │──▶│ 4. Publicar│──▶│ 5. Observar  │
   │ a tarefa e │   │ prompt/RAG/  │   │ offline vs  │   │ (canary,   │   │ traces,      │
   │ o "bom"    │   │ agente/tools │   │ dataset de  │   │ shadow,    │   │ feedback,    │
   │ (rubrica)  │   │              │   │ referência  │   │ A/B)       │   │ evals online │
   └────────────┘   └──────────────┘   └─────────────┘   └────────────┘   └──────┬───────┘
         ▲                                                                        │
         └────────────── 6. Melhorar: error analysis → novos casos ──────────────┘
                            de eval → ajuste de prompt/RAG/modelo

Note que a avaliação aparece duas vezes: offline (antes de publicar, contra um dataset controlado) e online (em produção, sobre tráfego real). E que o ciclo se fecha: os problemas achados em produção viram novos casos de teste. Isso é o "data flywheel" do LLMOps.

1.3 LLMOps × MLOps

LLMOps herda do MLOps o versionamento, CI/CD, monitoramento, gestão de dados e a cultura de experimentação. O que muda é o objeto (prompt/pipeline em vez de pesos), a natureza da métrica (subjetiva, sem gabarito) e a velocidade da iteração.

2.1 O caminho de uma requisição

usuário
  │
  ▼
[ App / API ] ── autentica, monta a requisição
  │
  ▼
[ Gateway de LLM ] ── roteamento de modelo, rate limit, quota, cache, fallback, redaction, custo
  │
  ▼
[ Camada de prompt ] ── template versionado + variáveis + few-shot + system prompt
  │
  ├─▶ [ Recuperação / RAG ] ── embedding, busca vetorial, rerank, montagem de contexto
  ├─▶ [ Ferramentas / agente ] ── loop planejar-agir-observar, chamadas de função
  │
  ▼
[ Provedor de modelo ] ── API hospedada ou modelo self-hosted (vLLM, TGI)
  │
  ▼
[ Pós-processamento ] ── parse/validação de schema, guardrails de saída, citações
  │
  ▼
[ Observabilidade ] ── trace completo: spans, tokens, custo, latência, feedback
  │
  ▼
resposta

2.2 O que cada peça exige de LLMOps

2.3 O gateway de LLM a peça que quase todo time acaba adotando

Um proxy único entre a aplicação e os provedores (LiteLLM, Portkey, Kong AI Gateway, Cloudflare AI Gateway, ou um interno). Centraliza o que você não quer espalhado pelo código: chaves e rotação, roteamento e fallback entre modelos, rate limiting e quota por time/feature, cache semântico, contabilização de custo por chamada, redaction de PII, e o ponto natural para instrumentar tracing. Adotar cedo evita ter que reformar tudo depois.

3.1 Por que "acurácia" não serve

Se a tarefa é classificar (sentimento, categoria, sim/não), você tem rótulo e usa acurácia, F1, matriz de confusão — trate como ML clássico. O problema é a maioria das tarefas de LLM: resumir, responder, redigir, extrair, conversar. Aí não existe uma resposta certa única: dez respostas diferentes podem ser todas boas.

3.2 A taxonomia de avaliação

• Por objeto: avaliar o modelo (benchmarks tipo MMLU, GPQA — úteis para escolher, inúteis para o seu caso) vs avaliar o seu sistema na sua tarefa (o que importa).
• Com referência × sem referência: reference-based compara com uma resposta esperada; reference-free julga a resposta sozinha, por critérios (é fiel ao contexto? responde à pergunta? tem o tom certo?). A maioria da avaliação prática de produto é reference-free com rubrica.
• Quem julga: humano (padrão-ouro, caro, lento), heurística/código (barato, só para o verificável), ou LLM-as-a-judge (escalável, o cavalo de batalha — Módulo 4).
• Determinístico × baseado em modelo: assert de código (o JSON tem os campos? o número está no intervalo? cita a fonte?) vs julgamento semântico.
• Offline × online: contra dataset fixo antes do deploy vs sobre tráfego real depois.

3.3 O dataset de avaliação (o ativo mais valioso do time)

Sua capacidade de melhorar o sistema é limitada pela qualidade do seu conjunto de avaliação. Um bom dataset:

• Reflete o tráfego real: construído a partir de logs de produção, não inventado na mesa. Comece com 50–100 casos reais bem escolhidos — vale mais que 10 mil sintéticos.
• Cobre a distribuição e as bordas: casos fáceis, casos difíceis, casos adversariais, casos onde a resposta certa é "não sei", categorias raras mas críticas.
• Tem o critério explícito por caso: não só a entrada, mas o que torna a saída boa (uma rubrica, uma checklist, uma resposta de referência, ou "deve conter X e não pode afirmar Y").
• É versionado e cresce: todo bug de produção vira um caso novo. É um dataset vivo, com dono.
• É estratificado: você reporta o score por segmento (tipo de pergunta, idioma, cliente), não só a média — a média esconde a regressão numa fatia importante.

# Um caso de eval: entrada + contexto + critérios (não uma "resposta certa" única)
{
  "id": "refund-042",
  "input": "comprei ontem, posso devolver? já usei uma vez",
  "retrieved_context": ["Política: devolução em até 7 dias se o produto não foi usado..."],
  "rubric": {
    "faithful": "a resposta reflete a política recuperada, sem inventar prazo ou condição",
    "addresses_used_item": "reconhece que 'já usei' pode desqualificar a devolução",
    "tone": "cordial, direto, sem jargão jurídico",
    "must_not": "prometer reembolso garantido"
  },
  "segment": "politica-devolucao"
}

4.1 Por que LLM-as-a-judge

Avaliação humana é o padrão-ouro, mas não escala: caro, lento, inconsistente entre avaliadores. Um LLM forte, com uma boa rubrica, concorda com humanos numa taxa alta o suficiente para servir como proxy escalável — você roda milhares de avaliações por centavos, em minutos, a cada mudança de prompt. É a técnica que tornou a avaliação contínua viável.

4.2 Os três formatos

# Juiz pointwise com rubrica e saída estruturada — a base de uma métrica repetível
JUDGE_PROMPT = """Você avalia a resposta de um assistente de suporte.

Pergunta do usuário: {input}
Contexto recuperado: {context}
Resposta do assistente: {output}

Avalie CADA critério como PASS ou FAIL, com uma frase de justificativa:
- faithful: toda afirmação factual é sustentada pelo contexto acima
- relevant: responde de fato à pergunta feita
- safe: não promete nada fora da política; não expõe dado sensível

Responda em JSON: {{"faithful": {{"verdict": "...", "reason": "..."}}, ...}}"""

# dica: temperature=0, peça justificativa ANTES do veredito (raciocínio melhora a nota),
# e rode o juiz 2–3x para casos limítrofes (self-consistency)

4.3 Os vieses do juiz (e como mitigar) avançado

4.4 Calibrar o juiz — o passo que quase todo mundo pula

Um juiz LLM só vale se você mediu a concordância dele com humanos. O processo:

1. Faça 30–50 humanos avaliarem os mesmos casos (idealmente 2 avaliadores por caso, para ter a concordância humano-humano como teto).
2. Rode o juiz nos mesmos casos.
3. Meça a concordância (acurácia vs consenso humano; Cohen's kappa para descontar acerto ao acaso; em pairwise, taxa de concordância).
4. Se baixa, itere na rubrica e no prompt do juiz — adicione exemplos, torne critérios mais específicos — e re-meça.
5. Documente o kappa alcançado. Um juiz com kappa ~0,6–0,8 num critério bem definido é utilizável; abaixo disso, o número engana.

4.5 G-Eval e rubricas estruturadas

G-Eval é um método popular: o juiz recebe o critério, gera os passos de avaliação, e produz uma nota ponderada pelas probabilidades dos tokens de score (reduz a compressão de escala). Frameworks como DeepEval, Ragas, Promptfoo e Phoenix/Arize trazem G-Eval e outras métricas de juiz prontas, com o cuidado dos vieses já embutido — bom ponto de partida antes de escrever o seu.

5.1 Avaliar RAG: separe recuperação de geração

Quando um RAG erra, a causa é uma de duas: não recuperou o documento certo, ou recuperou e mesmo assim respondeu mal. Avaliar o sistema como caixa-preta não distingue — e a correção é oposta (mexer no índice/chunking/reranker vs mexer no prompt de geração). Meça as duas camadas.

RAGAS é o framework de referência para isso (faithfulness, context precision/recall, answer relevancy), com juízes LLM por trás. DeepEval, Phoenix e TruLens cobrem terreno semelhante. Comece por faithfulness e context recall — são as que mais explicam falhas reais.

# Esqueleto de avaliação de RAG com Ragas
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall

resultado = evaluate(
    dataset,   # colunas: question, answer, contexts, ground_truth
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)
# reporte por segmento; um faithfulness caindo aponta para o prompt de geração,
# um context_recall caindo aponta para chunking / embedding / top_k / reranker

5.2 Avaliar agentes: resultado e caminho

Um agente pode acertar o resultado pelo caminho errado (sorte, 15 passos desnecessários, chamou uma ferramenta cara à toa) ou falhar no fim de um caminho quase certo. Avalie ambos:

• Task completion / success rate: a tarefa foi cumprida? Definido por um verificador — de preferência determinístico (o arquivo foi criado? o valor está correto no banco?), ou um juiz com rubrica.
• Tool-call accuracy: chamou as ferramentas certas, na ordem certa, com os argumentos certos? Compare a trajetória real com uma trajetória de referência (exata ou "conjunto de ferramentas esperado").
• Trajetória / eficiência: nº de passos, nº de chamadas de ferramenta, chamadas redundantes, custo e latência acumulados, loops.
• Robustez: recupera de erro de ferramenta? Lida com resultado vazio? Sabe parar e pedir ajuda?
• Segurança da ação: respeitou os limites (não chamou o que não devia)? — conecta com a apostila de Segurança de Aplicações de IA.

6.1 A pirâmide de testes de um app de LLM

6.2 Um gate de CI concreto

# promptfoo: config declarativa que roda no CI a cada PR que toca prompt/modelo
prompts: [file://prompts/suporte_v7.txt]
providers: [openai:gpt-4.1, anthropic:claude-sonnet]     # testa nos dois
tests:
  - vars: { input: "posso devolver produto usado?" }
    assert:
      - type: contains-any
        value: ["não foi usado", "7 dias"]
      - type: not-contains
        value: ["reembolso garantido"]
      - type: llm-rubric
        value: "é fiel à política de devolução e tem tom cordial"
      - type: latency
        threshold: 4000
  - vars: { input: "..." }   # ...mais 150 casos do golden set

# regra do pipeline: falha o build se o score agregado cair > 2 pontos vs baseline,
# OU se QUALQUER segmento cair > 5 pontos, OU se um caso "crítico" regredir

6.3 Offline não basta — estratégias de release

• Shadow / mirroring: a nova versão processa o tráfego real em paralelo, sem servir ao usuário; você compara as saídas e roda evals antes de promover.
• Canary: 1–5% do tráfego vai para a nova versão; monitora métricas de qualidade online, feedback, erro, custo e latência; sobe gradualmente ou reverte.
• A/B test: divisão controlada com métrica de negócio (resolução no primeiro contato, conversão, CSAT) — a prova final de que "melhorou no eval" virou "melhorou para o usuário".
• Rollback rápido: a versão de prompt/modelo é config, não deploy de código — reverter deve ser um clique.

7.1 Tracing de LLM

Um trace registra a árvore completa de uma requisição: o span raiz (a chamada do usuário) e os spans filhos (recuperação, cada chamada de ferramenta, cada chamada ao modelo, guardrails, pós-processamento). Para cada span: entrada, saída, modelo e parâmetros, tokens de entrada/saída, custo, latência, e metadados (usuário, sessão, versão do prompt, feature flag).

• Padrão emergente: as OpenTelemetry Semantic Conventions for GenAI padronizam os nomes de atributos (gen_ai.request.model, gen_ai.usage.input_tokens etc.), então o trace não fica preso a um fornecedor.
• Ferramentas: Langfuse, Arize Phoenix, LangSmith, Braintrust, Helicone, Traceloop/OpenLLMetry — a maioria fala OTel e integra com o seu APM.
• Por que importa: quando um usuário reclama, você abre aquele trace e vê em qual passo a coisa desandou — sem trace, é impossível reproduzir.

7.2 Capturar sinal de qualidade em produção

7.3 Deriva de qualidade — o que monitorar avançado

• Regressão do provedor: o modelo por trás da API muda e seus scores online caem sem nenhum deploy seu. Só um eval online contínuo pega isso. Tenha alarme sobre a série temporal do score.
• Drift de entrada: os usuários passaram a perguntar coisas novas (produto lançou, sazonalidade) que o RAG não cobre. Monitore tópicos/embeddings das perguntas; queda de context recall online é sinal.
• Degradação de RAG: o índice ficou desatualizado, uma fonte parou de ser ingerida — faithfulness cai porque o contexto está errado.
• Custo e latência: prompt cresceu, contexto cresceu, agente entrou em loops mais longos — p95 de latência e custo por requisição são métricas de primeira classe.
• Guardrails: taxa de bloqueio subindo (ataque? mudança de comportamento?) ou falsos positivos irritando usuários.

8.1 Error analysis: o hábito mais rentável

Antes de mexer em qualquer coisa, leia as falhas. Pegue 30–50 casos ruins (de feedback negativo, de evals que falharam), leia entrada + contexto + saída, e rotule a causa. Depois agrupe:

Análise de 40 respostas ruins do assistente de suporte:
  18  (45%)  recuperação falhou — o doc certo não veio no contexto
   9  (22%)  seguiu instrução parcialmente — ignorou o "não prometa reembolso"
   7  (18%)  tom errado — jurídico demais, frio
   4  (10%)  alucinou prazo/condição mesmo com contexto correto
   2   (5%)  pergunta ambígua — deveria ter pedido esclarecimento

→ prioridade clara: 45% é problema de RAG (chunking/embedding), não de prompt.
→ o 2º maior (seguir instrução) é ajuste de prompt barato. Comece por esses dois.

Sem essa contagem, times gastam semanas "melhorando o prompt" quando o problema era o índice. A análise transforma "está ruim" em uma lista priorizada de correções com impacto estimado.

8.2 O ciclo de iteração

1. Error analysis → causa dominante.
2. Adicione ao dataset de avaliação casos que representam essa falha (agora o eval "sente" o problema).
3. Faça uma mudança dirigida (chunking, few-shot, instrução, reranker, modelo).
4. Rode o eval offline: melhorou na fatia alvo sem regredir nas outras?
5. Shadow/canary → confirme online → promova.
6. Repita. Uma variável por vez, sempre medindo.

8.3 A escada de intervenções (barato → caro)

8.4 Gerir os experimentos

• Prompt/config como artefato versionado, com o score de eval atrelado a cada versão (prompt registry: Langfuse, PromptLayer, Humanloop, ou uma tabela sua).
• Registro de experimento: hipótese, mudança, dataset, resultado por segmento, decisão. Seis meses depois você quer saber por que o prompt está do jeito que está.
• Não caçar ruído: diferenças pequenas no eval podem ser variância. Use tamanho de amostra suficiente e olhe intervalo de confiança antes de declarar vitória.

9.1 Guardrails em runtime (foco em qualidade)

Ferramentas: NeMo Guardrails, Guardrails AI, Llama Guard, e os guardrails gerenciados de Bedrock/Azure. Guardrails são camadas probabilísticas — medir falso positivo (usuário legítimo bloqueado) e falso negativo é parte do trabalho, e cada guardrail adiciona latência e custo. A segurança adversarial (prompt injection, exfiltração) está na apostila de Segurança de Aplicações de IA; aqui o foco é a qualidade e a conformidade da resposta.

9.2 SLOs de qualidade

Trate qualidade como confiabilidade: defina metas explícitas, meça continuamente, e tenha error budget.

Exemplos de SLO de um assistente de suporte (medidos por eval online + amostra humana):
  faithfulness   ≥ 97%   (janela de 7 dias)
  answer_relevance ≥ 90%
  taxa de recusa indevida ≤ 2%
  p95 de latência ≤ 4,5 s
  custo por resposta ≤ US$ 0,03
  feedback negativo ≤ 8%

error budget: se faithfulness ficar < 97% por > 24h → congela mudanças, prioriza correção.

9.3 Incidente de regressão de qualidade

• Detecção: alarme no eval online ou no feedback, não "um cliente tuitou".
• Contenção: rollback da última versão de prompt/modelo (é config — reverte rápido); ou desligar o feature flag; ou forçar fallback para modelo/versão conhecida boa.
• Diagnóstico: traces dos casos ruins, diff da última mudança, checar se o provedor mudou o modelo, checar freshness do RAG.
• Correção e postmortem: corrige, adiciona o caso ao eval para não repetir, postmortem sem culpa. Métrica: MTTR de qualidade.

9.4 Governança e conformidade avançado

Na prática: seus datasets de eval, os relatórios por segmento, o histórico de scores, os SLOs e os postmortems são a evidência de conformidade. Um bom LLMOps já produz 80% do que a auditoria pede.

10.1 Os perfis que contratam

10.2 Roadmap de estudo (8–10 semanas)

10.3 Banco de perguntas de entrevista (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. Sistema de eval completo (âncora): um app RAG+ferramentas com dataset de avaliação a partir de dados reais/semi-sintéticos, LLM-as-judge calibrado (com o kappa reportado), decomposição RAG (RAGAS), suite no CI que bloqueia regressão, e um relatório "antes/depois" de uma melhoria dirigida por error analysis. README + artigo.
2. Harness de comparação de modelos: a mesma tarefa avaliada em 4 modelos (qualidade × custo × latência), com pairwise calibrado e recomendação justificada.
3. Observabilidade de LLM do zero: tracing com OpenTelemetry GenAI conventions, dashboard de qualidade online, alarme que detecta uma "regressão de provedor" simulada.
4. Estudo de caso de LLM-as-judge: medir empiricamente os vieses (posição, verbosidade) num juiz e mostrar o efeito das mitigações, com números.

10.5 Ferramentas e fontes para continuar

• Frameworks de eval: DeepEval, Ragas, promptfoo, OpenAI Evals, Phoenix (Arize), TruLens, Giskard.
• Observabilidade / prompt registry: Langfuse, LangSmith, Braintrust, Helicone, PromptLayer, Humanloop; OpenLLMetry/Traceloop.
• Gateways: LiteLLM, Portkey, Kong AI Gateway, Cloudflare AI Gateway.
• Leitura: as OpenTelemetry Semantic Conventions for GenAI; o material de "evals" da OpenAI e da Anthropic; escritos de Hamel Husain e Shreya Shankar sobre eval-driven development e error analysis; o paper original de "LLM-as-a-judge" (MT-Bench / Chatbot Arena) e de G-Eval; o NIST AI RMF Generative AI Profile.