MLOps vs LLMOps: as diferenças técnicas reais

As duas disciplinas compartilham princípios, mas as práticas divergem em pontos que importam. Onde MLOps clássico não cobre LLM em produção.

MLOps existe como disciplina formal desde ~2019. LLMOps é termo que ganhou tração em 2023 e se consolidou em 2024-2025. A pergunta razoável é: por que precisamos de termos diferentes? Por que MLOps tradicional não cobre o caso de LLM?

A resposta curta: porque o objeto que está em produção é fundamentalmente diferente. Em MLOps clássico, você opera modelos que você treinou (XGBoost, random forest, redes neurais customizadas) sobre features tabulares. Em LLMOps, você opera modelos que outra empresa treinou, chamados via API, com prompts versionados como código e output em linguagem natural. As primitivas mudam. Os problemas mudam.

O que se mantém igual

Antes de listar diferenças, vale reconhecer o que continua válido:

• Pipeline CI/CD continua sendo CI/CD
• Versionamento, reprodutibilidade, governança continuam vitais
• Monitoring, alerting e observability continuam essenciais
• Eval em ambiente isolado antes de deploy continua sendo prática correta
• A/B testing e deploy progressivo (canário) continuam aplicáveis

Quem é bom em MLOps tem 50% do caminho andado pra ser bom em LLMOps. Os 50% restantes são técnica específica.

Diferença 1: o que você versiona

MLOps clássico

Você versiona: dataset de treino, código de feature engineering, hiperparâmetros, pesos do modelo (.pkl, .onnx, .joblib), metadados de treinamento. Ferramentas: DVC, MLflow, Weights & Biases. O artefato é o modelo treinado.

LLMOps

Você versiona: prompts (system, user, assistant), schemas de output, versão do modelo da API (gpt-4o-2024-08-06 vs gpt-4o-2024-11-20), configuração (temperatura, top-p, max_tokens), conjunto de ferramentas disponíveis ao modelo, base de conhecimento usada em RAG. Pesos do modelo? Não, eles não são seus.

O artefato principal é o prompt template + config, não o modelo. Isso muda a ferramentaria:

• PromptLayer: versionamento de prompt com diff visual
• LangSmith: versionamento de prompt + trace de execução
• Promptfoo: versionamento + eval automatizado

# Versionamento de prompt como código
# prompts/customer_support_v2.3.yaml
version: "2.3"
model: gpt-4o-2024-11-20
temperature: 0.2
system: |
  Você é assistente de suporte da empresa X.
  Responda em português brasileiro.
  Se não souber, diga "não tenho essa informação".
tools:
  - search_kb
  - create_ticket
eval_set: eval_sets/support_v2.jsonl

Diferença 2: a natureza do drift

MLOps clássico

Drift é estatístico: distribuição das features de entrada muda (data drift), ou a relação entre features e target muda (concept drift). Você detecta com testes como Kolmogorov-Smirnov, PSI (Population Stability Index), comparações de média e variância. Quando dispara, você retreina.

LLMOps

Drift é semântico e qualitativo. Os tipos principais:

• Drift do modelo da API: a OpenAI atualiza o modelo silenciosamente (mesmo em versões "pinned", há mudanças sutis de servidor) e o comportamento muda. Você só percebe via eval contínuo.
• Drift de hallucination: taxa de alucinação aumenta para certas categorias de pergunta. Não tem teste estatístico clássico — você precisa de eval com LLM-as-judge ou anotação humana.
• Drift de distribuição de pergunta: usuários começam a perguntar coisa que sua base RAG não cobre. Não é drift no modelo — é gap na base de conhecimento.
• Drift de custo: requisições começam a consumir mais tokens (prompts crescendo, retrievals trazendo mais contexto), e o custo por interação sobe sem aviso.

No mundo de LLM, "o modelo está se comportando estranho" raramente vem de mudança nos pesos — vem de mudança em prompt, base RAG, distribuição de input ou versão de API. Diagnóstico exige instrumentação diferente.

Diferença 3: o que você monitora

Em MLOps tradicional, você monitora: latência da inferência, taxa de erro, accuracy/F1 contra ground truth, distribuição de features.

Em LLMOps, você monitora tudo isso e mais:

• Tokens consumidos: entrada e saída, por endpoint, por usuário. Essa é métrica de custo direto.
• Custo em dólar: total e por interação. LLMs caros podem queimar orçamento em horas se algo der ruim.
• Latência por fase: retrieval, reranking, LLM call, parsing. Identificar gargalos exige granularidade.
• Faithfulness: a resposta tem base no contexto recuperado? Métrica via LLM-as-judge ou modelos especializados.
• Answer relevance: a resposta endereça a pergunta?
• Toxicity / safety: output passa em filtros de moderação?
• Tool call success rate: em agentes, qual percentual das chamadas a ferramentas terminam com sucesso? Loops de retry?

Ferramentas dominantes em maio de 2026: Phoenix (open source, da Arize), LangSmith (do ecossistema LangChain), Weights & Biases (que pivotou pesado pra cobrir LLM em 2024-2025), Helicone, Langfuse. Cada uma com filosofia ligeiramente diferente.

Diferença 4: como você avalia

Em MLOps, eval é matemático: comparar predição com label, calcular métrica. Determinístico.

Em LLMOps, eval é mais sutil. Você precisa de:

• Eval set curado: conjunto de pares (input, resposta esperada ou critério de qualidade) — preferencialmente vindos de logs reais
• LLM-as-judge: outro modelo (geralmente mais forte) julga se a resposta passa em critérios definidos
• Métricas específicas: faithfulness, answer relevance, context precision, context recall (vide Ragas)
• Eval humano amostral: 5-10% das interações revisadas por humano para calibrar o LLM-judge
• Regressão: antes de toda mudança de prompt ou versão de modelo, rodar eval set completo e comparar

# Exemplo de eval com Ragas
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision

result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy, context_precision]
)
print(result.to_pandas())

Diferença 5: como você faz deploy

Em MLOps, deploy significa empacotar o modelo em container, expor endpoint, fazer canário. Em LLMOps, você não está fazendo deploy do modelo — ele já está rodando na OpenAI/Anthropic. Você está fazendo deploy de:

• Nova versão do prompt
• Nova versão do retriever
• Nova base RAG indexada
• Nova configuração de tool calling
• Mudança de versão de modelo da API

O ciclo é mais rápido (não tem retreinamento), mas mais frágil — mudança pequena de prompt pode quebrar 10% dos casos sem você perceber, se eval não pegar. Por isso eval automatizado em CI é não-negociável.

O que estudar para entrar em LLMOps

• Fundamentos de MLOps: pipelines, CI/CD para ML, monitoring básico
• Eval frameworks: Ragas, DeepEval, Phoenix
• Observability: LangSmith ou Langfuse, traces distribuídos
• Custo e otimização: token counting, cache semântico, model routing (chamar modelo mais barato quando possível)
• Segurança de prompt: prompt injection, output filtering, PII handling
• Eval com LLM-as-judge: como escrever rubric, como evitar viés

Conclusão prática

MLOps e LLMOps não competem — eles convivem. Em produto sério de IA em 2026, você precisa dos dois. MLOps cuida do que você treina (classificador customizado, embeddings finetunados, ranker), LLMOps cuida do que você compõe (prompts, agentes, RAG). Quem entende profundamente um e superficialmente o outro está limitado. O profissional completo entende a fundação MLOps e domina as primitivas que são exclusivas de LLM — versionamento de prompt, eval semântico, observability de tokens e custo, drift sem ground truth. Essa combinação é o que sustenta IA em produção que não quebra silenciosamente.