2025-05-06 · Atualizado 2026-07-15

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

MLOps vs LLMOps: Infraestrutura para Modelos Fundacionais e Sistemas LLM

Os modelos fundamentais alteraram várias premissas subjacentes aos processos clássicos de MLOps. As equipas costumam adaptar ou utilizar um modelo pré-treinado em vez de treinar cada modelo do zero, sendo que as respostas geradas e as ações das ferramentas exigem uma avaliação que vá além de uma métrica de previsão fixa.

A disciplina de MLOps continua a ser aplicável. O que mudou foi a unidade operacional: o comportamento de uma aplicação baseada em modelos de linguagem pode depender de prompts, da decodificação, da recuperação de informações, dos contratos de ferramentas, das permissões, do encaminhamento de solicitações e das políticas definidas, bem como dos pesos do modelo. Este artigo explica o que permaneceu útil e quais novos sistemas LLM foram introduzidos.

TL;DR. Mantenha a trilha de auditoria, a automação, a entrega em fases, o monitorização e a capacidade de reversão no âmbito do MLOps. Amplie o manifesto de lançamento para incluir o fornecedor ou os pesos, prompts, esquemas, estado de recuperação, ferramentas, roteamento e políticas. Valide esse manifesto através de avaliações em camadas sucessivas e, em seguida, utilize rastreios sensíveis à privacidade para transformar falhas em produção em novos testes.

O que o MLOps já resolveu

Controlos MLOps que continuam a ser necessários para sistemas de modelos fundamentais

Os controlos estabelecidos em MLOps não se tornam obsoletos quando o modelo gera texto:

cadeia de rastreabilidade que vai dos dados, código, configurações e modelos até à versão final lançada
treino ou compilação repetível pipelines
validação offline antes da promoção
registos e identidade imutável dos artefatos
implementação faseada, objetivos a nível de serviço, mecanismos de reversão e resposta a incidentes
telemetria de infraestrutura e planeamento de capacidade
políticas de controlo de acesso, retenção e auditoria para os dados

Os modelos fundamentais não eliminam estas necessidades. Eles tornam a expressão antiga “versão do modelo” insuficiente.

A unidade de lançamento passou a ser um manifesto de sistema

A unidade de lançamento ampliada, que vai das práticas MLOps até às LLMOps

Num serviço de previsão convencional, o código, a lógica das características e a identidade do modelo são frequentemente os fatores que explicam a maior parte das alterações de comportamento. Num sistema baseado em modelos fundamentais, deve ser registado, 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. O princípio invariante é que um manifesto deve identificar todos os componentes que mudam de forma independente e que podem alterar o comportamento visível para o utilizador.

O alias de modelo de um fornecedor não é necessariamente um artefato imutável. Um hash checkpoint auto-hospedado é mais preciso, mas as configurações de runtime, quantização, modelo e paralelismo continuam a fazer parte do registo de lançamento.

Cinco superfícies de falha ampliadas

A diferença entre MLOps e LLMOps torna‑se mais evidente na análise de falhas do que em listas de ferramentas.

1. Modelo e serving

Os modelos hospedados introduzem fatores como a disponibilidade do fornecedor, quotas de uso, processamento regional, alterações de alias e uma estrutura de custos baseada no pagamento por token. Já os modelos auto-hospedados envolvem questões relacionadas com as cadeias de abastecimento de pesos, a capacidade GPU, o agrupamento de operações, a política de cache, a quantização e a implementação distribuída de serving.

Ambos exigem controlos de latência, erros,throughput, saturação e custos. Nenhum dos modos de implementação elimina a avaliação da qualidade.

2. Prompt, esquema e orquestração

Uma prompt é uma configuração semelhante a código, mas o texto puro de prompt por si só não define o comportamento. A ordem das mensagens, as descrições das ferramentas, o esquema de resposta, a decodificação, as tentativas de recuperação, o truncamento e o código envolvente são todos fatores importantes.

Versione a solicitação montada e a política de orquestração. Teste o structured outputs com analisadores e invariantes de negócio, em vez de considerar um “JSON” válido como sinal de sucesso da tarefa.

3. Recuperação e contexto

A recuperação de informação cria um produto de dados independente entre a fonte de verdade e o modelo:

RAG caminho de dados e avaliação

O pipeline deve preservar a revisão de origem, as versões do analisador e do divididor de trechos, a identidade do embedding, a construção do índice, os metadados de controle de acesso e o estado de exclusão. É necessário avaliar a recuperação de informações antes da geração: se o sistema encontrou as evidências corretas, se houve aplicação adequada dos filtros de autorização e se a resposta utilizou corretamente as evidências fornecidas.

Um índice vetorial não substitui uma loja de características ou um armazém de dados. Ele serve para a recuperação de similaridades; as características estruturadas em tempo específico e os factos analíticos mantêm requisitos diferentes em termos de consistência e consultas.

4. Ferramentas e ações

Quando um modelo consegue chamar APIs, as falhas de qualidade podem tornar‑se efeitos colaterais. A fronteira operacional passa a incluir autenticação de ferramentas, princípio do menor privilégio, validação de argumentos, tempos de espera, propriedade idempotente, política de aprovação e verificações de pós‑condição.

Registe qual ferramenta foi oferecida, selecionada, chamada, rejeitada, tentada novamente ou confirmada. Uma resposta final precisa não consegue provar que o percurso de ação foi o correto.

5. Segurança, proteção e políticas

Os filtros de conteúdo representam apenas um mecanismo de controle, e não uma camada de proteção completa. As ameaças incluem ainda prompt injection, recuperação de dados entre tenants, divulgação de segredos, agência excessiva, código de modelo ou nó não confiável, bem como argumentos de ferramentas inseguros.

Quando possível, expresse as regras de negócio determinísticas fora do modelo. Defina os riscos residuais, teste casos adversários e atribua um responsável pelas alterações nas políticas. O Perfil Generativo AI do NIST constitui um inventário útil de riscos, mas não representa um teste de aceitação pronto a ser utilizado.

A avaliação torna‑se uma porta de liberação

A saída em formato livre torna insuficiente um único valor de precisão agregada. No entanto, isso não significa que a qualidade seja impossível de ser medida.

Crie uma pilha de avaliação com vários tipos de evidências:

Verificações determinísticas: validade do esquema, presença de citações, ferramentas permitidas, restrições aos argumentos, regras de política, latência e orçamento.
Métricas de componentes: recuperação e recall, precisão na seleção de ferramentas, correção dos argumentos utilizados e seleção da rota.
Tarefas end-to-end: entradas representativas com critérios de sucesso explícitos e etiquetas de segmentação.
Avaliação baseada em modelos: julgamentos orientados por rubricas, calibrados com base em etiquetas de especialistas e monitorizados para detetar desvios nos avaliadores.
Revisão humana: casos ambíguos, de alto impacto, inovadores ou amostrais em que a automação não possui autoridade decisória.
Testes adversariais: casos de injeção, violação de limites de dados, abuso, recusa e efeitos colaterais relacionados com o modelo de ameaças.

Armazene os resultados por exemplo, e não apenas as médias. Uma nova versão pode melhorar a média global, mas ao mesmo tempo piorar o desempenho para uma determinada língua, utilizador, tipo de documento ou classe de ação.

O gateway de deploy compara um manifesto candidato com a versão atual do mesmo conjunto versionado. Os limiares devem abranger em conjunto qualidade, segurança, latência e custo; uma solução mais barata que falha na tarefa não constitui uma otimização.

Os rastros ligam a produção à fase de avaliação

loop de operação de rastreio até avaliação

As métricas de infraestrutura podem indicar uma chamada ao modelo lenta. No entanto, não conseguem revelar se a recuperação de dados retornou um documento não autorizado ou se uma ferramenta foi acionada com a conta incorreta.

Capturar um rasto ao longo do caminho de decisão:

Correlação entre a identidade do manifesto de lançamento e os pedidos recebidos
Chamadas ao modelo e aos fornecedores, latência, utilização e estado final
Consultas de recuperação, identificadores de documentos, pontuações e decisões de filtragem
Revisão de prompt/template sem armazenar de forma indiscriminada conteúdos sensíveis
Ofertas de ferramentas, argumentos, aprovações, resultados e identificadores de efeitos colaterais
Decisões de política, tentativas de repetição, soluções alternativas e resultado final

O rastreio cria uma nova camada de governação de dados. Antes de recolher todo o prompts ou os documentos correspondentes, deve aplicar-se minimização, redação, isolamento por tenant, encriptação, amostragem, retenção e revisão de acessos. As convenções de OpenTelemetry de tipo generativo-AI podem contribuir para a interoperabilidade, mas os seus esquemas continuam a evoluir; por isso, é essencial fixar as versões das ferramentas de instrumentação e dos coletores.

O ciclo de melhoria é:

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

O feedback dos utilizadores pode priorizar uma investigação, mas um “thumbs-up” não constitui a verdade factual. É necessário preservar o registo de atividades associado e obter etiquetas de especialistas para os casos mais críticos.

A gateway serving representa um limite de política

Portal de inferência como limite de política e encaminhamento

Um gateway pode desacoplar os clientes de aplicação dos fornecedores ou dos motores auto-hospedados. As suas responsabilidades úteis podem incluir:

Autenticação, orçamentos de utilizador, quotas e limites de taxa
Contratos estáveis de pedido e resposta
Seleção de rotas por capacidade, região, latência ou qualidade avaliada
Tentativas limitadas, disjuntores elétricos e semântica explícita de fallback
Particionamento de cache e política de dados sensíveis
Atribuição de utilização e propagação de manifestos de libertação

O fallback é uma alteração de comportamento, e não apenas um mecanismo de fiabilidade. Se um modelo mais pequeno, um fornecedor alternativo ou um contexto reduzido afetarem negativamente a qualidade da tarefa, deve-se avaliar e rastrear esse caminho como uma rota independente.

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

Fine-tuning é uma única intervenção, e não uma escala de maturidade

Escolha a intervenção a ser aplicada com base na falha observada:

Falha
Fatos atuais ou privados em falta	recuperação e sincronização de fontes
Formato incorreto ou argumentos inválidos	esquema, saída restrita, validação
Comportamento inconsistente da tarefa	prompt, exemplos, escolha do modelo e, em seguida, dados de adaptação
Latência ou custo excessivos	roteamento, contexto, cache, agrupamento em lotes, quantização
Ação não autorizada ou insegura	permissões da ferramenta e política determinística
O comportamento do domínio não pode ser recuperado a partir do contexto.	fine-tuning ou outro modelo especializado

LoRA e outros métodos eficientes em termos de parâmetros reduzem o número de parâmetros passíveis de treino; no entanto, eles não eliminam as exigências relativas à governação de dataset, à licenciação do modelo base, à avaliação, à compatibilidade com serving, nem aos procedimentos de reversão.

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

Defina a tarefa do utilizador, os limites de risco, os objetivos do serviço e o orçamento disponível.
Crie o manifesto de lançamento antes de introduzir um registo prompt, uma base de dados vetorial ou um produto de gateway.
Elabore um conjunto de avaliação pequeno e dividido em partes, bem como testes para componentes determinísticos.
Implemente um rastreio end-to-end equipado com mecanismos de controlo de privacidade e identidades estáveis para lançamentos.
Faça a transição gradual através de modos “shadow”, “canary” ou tráfego limitado, com um mecanismo de reversão explícito.
Converta os falhas verificadas em produção em casos de regressão e repita o processo.

Adicione infraestrutura apenas quando existir um mecanismo de controlo nomeado ou quando se eliminar um gargalo medido. A “plataforma LLMOps” não constitui um requisito de arquitetura.

Conclusão

O LLMOps é o MLOps aplicado a uma unidade comportamental mais ampla. O modelo continua a ser fundamental, mas prompts, as evidências recuperadas, as permissões das ferramentas, o encaminhamento e as políticas podem alterar o resultado sem modificar os pesos.

A versão que integra toda a unidade, é avaliada antes do lançamento, acompanhada por limites de privacidade, e revertida como um único sistema. Essa é a diferença operacional que realmente importa.