Do protótipo à produção: um pipeline de LLMOps

O protótipo de IA costuma ficar pronto numa semana. A distância entre esse protótipo e algo que roda em produção com usuários reais é onde a maioria dos projetos morre, e ela raramente é culpa do modelo.

O que muda quando você não treina o modelo

A disciplina de MLOps foi construída em torno de um pipeline que termina em treino e implantação de modelo. Boa parte dos projetos de IA generativa não treina nada: consome um modelo por API.

Isso elimina algumas etapas e cria outras. Some o retreino periódico. Aparece a gestão de prompt, a gestão de contexto, o controle de custo por chamada e a dependência de um fornecedor que atualiza o modelo sem pedir licença.

O que continua valendo do MLOps clássico é a espinha dorsal: versionamento de tudo que influencia o resultado, automação do caminho até produção e monitoramento contínuo depois. O guia de MLOps do Google Cloud descreve essa progressão em níveis de maturidade, e ela se aplica quase inteira aqui.

Versione o que de fato muda a resposta

Numa aplicação de LLM, o artefato não é só o código. A saída muda se mudar qualquer um destes:

• o prompt (incluindo instruções de sistema);
• o modelo e a sua versão;
• os parâmetros de geração;
• a base de conhecimento indexada e a configuração de recuperação;
• as definições de ferramenta disponíveis.

Se algum desses vive fora do controle de versão, você não consegue reproduzir um incidente. Prompt em variável de ambiente editada pelo painel é o erro mais comum, e o mais caro no dia em que a resposta piorar sem ninguém ter feito deploy.

A entrelaçamento é o problema difícil

Um estudo de caso da Microsoft sobre engenharia de software para aprendizado de máquina apontou uma diferença estrutural em relação ao software tradicional: componentes de IA são mais difíceis de tratar como módulos isolados, porque ficam entrelaçados de formas não óbvias.

Na prática isso significa que a mudança que parece local não é. Ajustar o prompt para melhorar um tipo de pergunta degrada outro. Trocar o modelo de embedding invalida o índice inteiro. Mudar a temperatura muda a taxa de acionamento de ferramenta.

Por isso a suíte de avaliação precisa rodar sobre o conjunto inteiro de cenários a cada mudança, não só sobre o cenário que motivou a mudança.

Um pipeline mínimo que já é sério

Quatro estágios cobrem a maior parte do risco:

1. Desenvolvimento. Prompt e configuração versionados junto com o código. Avaliação local rápida antes de abrir PR.
2. Integração. Avaliação determinística no CI, mais o conjunto dourado. Falha bloqueia merge.
3. Implantação progressiva. Nova versão atrás de uma chave, liberada para uma fração do tráfego, com comparação de qualidade e custo contra a versão atual.
4. Observação. Registro de entrada, saída, versão de prompt, latência, custo e feedback do usuário, com amostragem para revisão humana.

O estágio 3 é o que mais falta nos projetos que vejo, e é o que transforma erro grande em erro pequeno.

Custo é requisito, não relatório

Em sistema tradicional, custo aparece na conta no fim do mês. Em aplicação de LLM, custo é função direta de decisão de desenho: tamanho do contexto, número de chamadas por interação, modelo escolhido por rota.

Trate custo por interação como um SLO. Defina o teto aceitável, meça em produção por rota e alarme quando estourar. Sem isso, a otimização só acontece depois do susto na fatura, e aí costuma ser feita com pressa e sem avaliação, degradando qualidade.

O fallback precisa existir antes de precisar

Dependência de API externa significa indisponibilidade que não está no seu controle. Defina o comportamento antes: resposta em cache, modelo alternativo, degradação explícita para o usuário ou fila para processar depois.

Escolher isso durante o incidente é como escolher o plano de rollback durante o rollback.

O que isso significa para o seu time

Comece tirando o prompt de qualquer lugar que não seja o repositório. É a mudança mais barata com maior efeito sobre reprodutibilidade.

Depois, adicione a implantação progressiva. Não precisa de plataforma sofisticada: uma chave de configuração, uma fração de tráfego e um painel comparando qualidade e custo entre versões já resolve.

E defina o teto de custo por interação junto do requisito funcional, na mesma conversa. Fica mais barato do que descobrir três meses depois que a arquitetura escolhida não fecha a conta.