MLOps vs LLMOps: Infraestrutura para Foundation Models

Viacheslav Dubrov

2025-05-06 · Atualizado 2026-07-15 · 9 min · Infraestrutura de IA

Tradução automática Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Quando um release de um foundation model sofre uma regressão, o ficheiro de pesos pode não ter mudado: o elemento variável pode ser um prompt, um índice de retrieval, uma permissão de tool, uma rota ou uma policy. Assim, para engenheiros de ML, de plataformas e de aplicações de AI que já operam MLOps convencional, o artefacto prático é um release manifest que identifica essas dependências e aponta para o primeiro controlo a inspecionar quando surge uma falha.

Este é um modelo operacional editorial, não a afirmação de que todas as aplicações precisam da mesma plataforma. Mantenha a lineage do MLOps, a entrega faseada, a monitorização e o rollback; expanda a unidade que versiona quando as respostas geradas ou as ações de tools fazem com que o comportamento dependa de mais do que dos pesos.

TL;DR. Mantenha a lineage do MLOps, a automação, a entrega faseada, a monitorização e o rollback. Estenda o release manifest para incluir o provider ou os pesos, prompts, schemas, estado do retrieval, tools, routing e policy. Promova esse manifest através de avaliações em camadas e, em seguida, use traces com proteção de privacidade para transformar falhas de produção em novos testes.

O que o MLOps já resolveu

O MLOps estabeleceu controlos que não se tornam obsoletos quando o modelo gera texto:

• lineage dos dados, código, configuração e modelo até ao release
• pipelines de treino ou build reproduzíveis
• validação offline antes da promoção
• registos e identidade imutável dos artefactos
• rollout faseado, objetivos de nível de serviço, rollback e resposta a incidentes
• telemetria da infraestrutura e planeamento de capacidade
• controlo de acessos, retenção e policy de auditoria para os dados

Os foundation models não eliminam estas necessidades. Tornam demasiado pequena a antiga expressão «versão do modelo».

A unidade de release tornou-se um system manifest

Para um sistema baseado num foundation model, recomendo um manifest que registe, no mínimo:

application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisions

A lista exata depende do sistema. A regra editorial é identificar todos os componentes que mudam de forma independente e que podem alterar o comportamento visível para o utilizador.

Considere mutável o nome de um modelo de um provider, a menos que o provider documente uma revisão imutável. Um hash do checkpoint ajuda a identificar pesos self-hosted, mas eu registaria também o runtime, a quantização, o template e a configuração de paralelismo.

Cinco superfícies de falha expandidas

A diferença entre MLOps e LLMOps é mais evidente na análise de falhas do que nas listas de tools.

1. Modelo e serving

Para o planeamento, separe as preocupações de modelos hosted (disponibilidade do provider, quotas, processamento regional e custo de utilização) das preocupações self-hosted (disponibilidade dos pesos, capacidade de GPU, batching, policy de cache, quantização e serving). Os controlos relevantes dependem do deployment escolhido.

Em ambos os modos, inclua latência, erros, throughput, saturação, custo e verificações da qualidade da tarefa na decisão de release.

2. Prompt, schema e orchestration

Num sistema que monta requests em runtime, versione o request montado, e não apenas o texto do prompt: a ordem das mensagens, as descrições das tools, o response schema, o decoding, os retries, o truncation e o código envolvente podem alterar o comportamento.

Trate o JSON analisável como uma verificação de transporte e teste separadamente os invariantes de negócio da tarefa.

3. Retrieval e contexto

O retrieval acrescenta um produto de dados independente entre a fonte de verdade e o modelo:

Num sistema com retrieval-augmented, conserve a revisão da fonte, as versões do parser e do chunker, a identidade do embedding, o build do índice, os metadados de controlo de acessos e o estado de eliminação. O design original de RAG separa o retrieval da geração; use essa separação para testar de forma independente a recuperação de evidência, a filtragem de autorização e a utilização da evidência. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks descreve a arquitetura retrieve-then-generate.

Não use um índice vetorial como substituto de uma feature store ou de um warehouse: a recuperação por similaridade, as features point-in-time e os factos analíticos têm necessidades diferentes de consulta e consistência.

4. Tools e ações

Quando um modelo pode chamar APIs, inclua a autenticação das tools, o princípio do menor privilégio, a validação de argumentos, os timeouts, a idempotência, a policy de aprovação e as verificações de pós-condições no perímetro operacional. O Generative AI Profile do NIST identifica riscos relacionados com conteúdo nocivo, privacidade e segurança; os controlos listados são uma recomendação de engenharia com âmbito definido, não um catálogo completo de controlos.

Faça tracing de qual tool foi disponibilizada, selecionada, chamada, rejeitada, repetida e confirmada. Uma resposta final fluente não prova que o percurso da ação estava correto.

5. Safety, security e policy

Os filtros de conteúdo são um controlo, não uma camada completa de guardrails. As ameaças incluem também prompt injection, retrieval entre tenants, divulgação de segredos, agency excessiva, código não fiável do modelo ou do node e argumentos inseguros para tools.

Expresse as regras de negócio determinísticas fora do modelo sempre que possível. Defina os riscos residuais, teste casos adversariais e atribua um responsável pelas alterações de policy. O Generative AI Profile do NIST é um inventário de riscos útil, não um teste de aceitação turnkey.

A avaliação torna-se um gate de release

Para decisões de release sobre output livre, não dependa de um único número agregado de accuracy. Use vários tipos de evidência e defina qual é autoritativo para cada modo de falha.

Construa uma stack de avaliação com vários tipos de evidência:

1. Verificações determinísticas: validade do schema, presença de citações, tools permitidas, restrições dos argumentos, regras de policy, latência e orçamento.
2. Métricas de componentes: recall e ranking do retrieval, accuracy da seleção de tools, correção dos argumentos das tools e seleção de rotas.
3. Tarefas end-to-end: inputs representativos com critérios de sucesso explícitos e labels de slice.
4. Scoring baseado em modelos: avaliações orientadas por rubricas, calibradas com labels de especialistas e monitorizadas quanto a judge drift.
5. Revisão humana: casos ambíguos, consequentes, novos ou amostrados, nos quais a automação não é autoritativa.
6. Testes adversariais: casos de injection, limites de dados, abuso, recusa e efeitos secundários associados ao threat model.

Guarde os resultados por exemplo, e não apenas as médias, para que a revisão do release possa inspecionar regressões por idioma, tenant, tipo de documento ou classe de ação.

Para um gate de deployment, compare um manifest candidato com o release atual usando a mesma suite versionada. Defina em conjunto thresholds para qualidade, safety, latência e custo; uma rota mais barata que falha a tarefa não é uma otimização.

Os traces ligam a produção à avaliação

As métricas de infraestrutura podem mostrar uma chamada lenta ao modelo. Não conseguem mostrar que o retrieval devolveu um documento não autorizado ou que uma tool foi chamada com a conta errada. A documentação de tracing do MLflow descreve traces que capturam os passos intermédios e os metadados necessários para inspecionar este percurso.

Capture um trace ao longo do percurso de decisão:

• identidade do release manifest e correlação do request
• chamadas ao modelo e ao provider, latência, utilização e estado de conclusão
• query de retrieval, identificadores dos documentos, scores e decisões de filtragem
• revisão do prompt/template sem armazenar indiscriminadamente conteúdo sensível
• disponibilização de tools, argumentos, aprovações, resultados e identificadores de efeitos secundários
• decisões de policy, retries, fallbacks e resultado final

O tracing cria uma nova superfície de governance de dados. Aplique minimização, redação, isolamento de tenants, encriptação, sampling, retenção e revisão de acessos antes de recolher prompts ou documentos completos. As convenções semânticas GenAI do OpenTelemetry podem ajudar na interoperabilidade, mas continuam em desenvolvimento. Fixe a versão da convenção ou do schema, do instrumentation e do collector.

O loop de melhoria é:

production trace → triaged failure → labeled regression case
                 → candidate change → offline comparison
                 → staged release → monitored outcome

O feedback dos utilizadores pode dar prioridade à investigação, mas um thumbs-up não é ground truth. Preserve o trace envolvente e obtenha labels de especialistas para os casos consequentes.

O serving gateway é um perímetro de policy

Um gateway pode desacoplar os clientes da aplicação dos providers ou dos engines self-hosted. Entre as responsabilidades que vale a pena colocar aí estão:

• autenticação, orçamentos por tenant, quotas e limites de taxa
• contratos estáveis de request e response
• seleção de rotas por capacidade, região, latência ou qualidade avaliada
• retries limitados, circuit breakers e semântica explícita de fallback
• particionamento da cache e policy de dados sensíveis
• atribuição de utilização e propagação do release manifest

O fallback é uma alteração de comportamento tanto quanto é um mecanismo de fiabilidade. Se um modelo mais pequeno, um provider alternativo ou um contexto reduzido alterar a qualidade da tarefa, avalie e faça tracing desse ramo como uma rota própria.

Não coloque todas as decisões de orchestration no gateway. Mantenha as regras de domínio junto da aplicação e torne a responsabilidade visível.

O fine-tuning é uma intervenção, não uma escada de maturidade

Escolha a intervenção a partir da falha observada:

LoRA congela os pesos pré-treinados e acrescenta matrizes low-rank treináveis, reduzindo o número de parâmetros treináveis para a tarefa downstream. Essa otimização não elimina os requisitos de governance do dataset, licenciamento do modelo base, avaliação, compatibilidade de serving ou rollback.

Uma sequência prática de adoção

1. Defina a tarefa do utilizador, os limites de dano, os objetivos do serviço e o envelope de custo.
2. Crie o release manifest antes de introduzir um prompt registry, uma base de dados vetorial ou um produto de gateway.
3. Construa um conjunto de avaliação pequeno e dividido em slices, bem como testes determinísticos dos componentes.
4. Instrumente um trace end-to-end com controlos de privacidade e identidades de release estáveis.
5. Promova através de shadow, canary ou tráfego limitado, com um trigger explícito de rollback.
6. Transforme as falhas de produção revistas em casos de regressão e repita.

Acrescente infraestrutura apenas quando esta for responsável por um controlo identificado ou remover um bottleneck medido. «LLMOps platform» não é um requisito de arquitetura.

Conclusão

LLMOps é MLOps aplicado a uma unidade comportamental maior. O modelo continua a ser importante, mas os prompts, a evidência recuperada, as permissões das tools, o routing e a policy podem alterar o resultado sem alterar os pesos.

Versione toda essa unidade, avalie-a antes do release, faça tracing com limites de privacidade e reverta-a como um único sistema.

Referências

• MLflow: avaliar traces de produção - Reutilizar traces de produção para avaliação e atribuir scores à informação intermédia dos traces.
• MLflow: tracing de LLM e agents - Capturar passos intermédios e metadados de traces para investigação.
• Convenções semânticas GenAI do OpenTelemetry - Convenções atualmente em desenvolvimento para spans, métricas, eventos e dados específicos de providers em GenAI.
• NIST AI 600-1: Generative AI Profile - Categorias de risco para prompt injection, privacidade, segurança e outras preocupações relacionadas com GenAI.
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks - Arquitetura original retrieve-then-generate.
• LoRA: Low-Rank Adaptation of Large Language Models - Pesos pré-treinados congelados e matrizes low-rank treináveis para adaptação downstream.