Operar um modelo de linguagem grande em um ambiente de produção já não se limita a treinar, testar e implantar o modelo e monitorar painéis. O sistema moderno pode conectar prompts, bancos de dados vetoriais e fontes de conhecimento e, então, produzir textos abertos avaliados segundo tom, segurança e confiança, além da precisão. É nesse contexto que Daniel Bryant, em um artigo publicado no blog da CNCF, faz uma pergunta prática: quem deve ser responsável pelo pipeline de IA?
O autor entende que a resposta não está em conceder à LLMOps um reino separado, mas em integrá-la a uma plataforma de engenharia bem organizada, que ofereça os recursos necessários por meio das mesmas interfaces usadas pelas equipes de desenvolvimento para as demais cargas de trabalho.
O que significa LLMOps?
LLMOps refere-se ao conjunto de práticas, ferramentas e fluxos de trabalho necessários para desenvolver, implantar e gerenciar grandes modelos de linguagem durante todo o seu ciclo de vida em produção. Esse ciclo inclui gerenciamento de dados, engenharia de prompts, ajuste fino, implantação e serviço de inferência, monitoramento e avaliação, além de segurança e governança.
Segundo a análise, LLMOps não é simplesmente um novo nome para MLOps. Os grandes modelos de linguagem são mais caros para ajustar e servir, e avaliar suas saídas é mais difícil do que reduzir o desempenho a um número claro de precisão. Não basta que o modelo seja preciso; ele também deve ser seguro e confiável, características mais complexas de medir.
Além disso, a operação do modelo não termina na implantação inicial. Os modelos podem se desviar de seu comportamento anterior, os custos podem aumentar, os prompts podem deixar de funcionar como antes e as integrações com sistemas de gerenciamento de relacionamento com o cliente ou bases de conhecimento internas precisam de acompanhamento contínuo.
Um ciclo de vida que se cruza com a engenharia de plataformas
O ciclo de vida de LLMOps vai da preparação dos dados e da engenharia de prompts, tratando os prompts como elementos versionáveis em vez de textos temporários, ao ajuste fino de modelos básicos abertos usando bibliotecas como Hugging Face Transformers. Ele também inclui o versionamento de modelos e prompts e o rastreamento de sua proveniência, o fornecimento de inferência por meio de endpoints apoiados por unidades de processamento gráfico e o monitoramento baseado em feedback humano para detectar desvios e custos.
Cada parte desse ciclo precisa de infraestrutura, controles de acesso e um ambiente de execução, áreas que já estão dentro do escopo da engenharia de plataformas. O autor, porém, distingue a natureza dos dois campos: a engenharia de plataformas concentra-se na infraestrutura, enquanto MLOps concentra-se nos modelos. Por isso, ele não considera que a pergunta útil seja “quem é responsável pelo pipeline?”, mas sim “quem é responsável por cada camada e existe uma entidade que realmente coordene todas elas?”.
O risco de criar uma pilha paralela
A análise divide o cenário de entrega de software entre equipes de DevOps, que podem ficar sobrecarregadas com solicitações de implantação; equipes de engenharia de plataformas, que constroem fluxos padronizados de autosserviço; e equipes de MLOps, que criaram pilhas paralelas porque as ferramentas de DevOps não foram projetadas para gerenciar versões de dados ou monitorar desvios. Com a adição de LLMOps, uma terceira pilha independente pode surgir para prompts, bancos de dados vetoriais e pipelines de RAG, distante da entidade responsável pela governança.
O autor relaciona essa possibilidade ao problema das “operações de IA ocultas”. Uma equipe pode criar seu próprio pipeline de RAG, conectado a um banco de dados vetorial que não passou por revisão, sem que fique claro para a entidade responsável o que está efetivamente em execução. Segundo a análise, o maior risco operacional não está apenas em um chatbot produzir alucinações, mas na disseminação desses recursos para fora da plataforma e em sua permanência fora do alcance da visibilidade e do controle.
O autor não propõe desacelerar as equipes para impedir isso, mas tornar a plataforma capaz de atender rapidamente às solicitações, incorporando a governança ao próprio fluxo de uso. A ausência de um fluxo pronto pode levar as equipes a desenvolver seus recursos fora da plataforma, enquanto oferecer um fluxo padrão ajuda a trazer esses recursos de volta para um ambiente gerenciável.
LLMOps dentro das camadas da plataforma
Bryant baseia-se na concepção do white paper sobre plataformas publicado pelo grupo TAG App Delivery da CNCF, que divide o ambiente em três camadas: os produtos no topo, as plataformas no meio, como a camada de integração razoavelmente mais fina, e os provedores de recursos na base.
Segundo essa concepção, funções como tarefas de ajuste fino, bancos de dados vetoriais, registros de prompts e endpoints de inferência podem ser tratadas como mais um conjunto de recursos da plataforma. Como os demais, eles precisam de APIs, versões e responsabilidades claras. O autor aponta ferramentas do ecossistema CNCF que podem apoiar esse modelo: o Backstage apresenta os fluxos padrão na camada de produto, enquanto o Crossplane monta a infraestrutura na camada inferior, e frameworks como Kratix, KusionStack e KubeVela atuam no meio para disponibilizar um pipeline de LLM por meio de uma interface de autosserviço semelhante à das demais aplicações.
Controles práticos para a governança do pipeline
A análise propõe que as equipes de plataformas adotem um conjunto de controles práticos:
- APIs governadas em vez de scripts informais: as tarefas de ajuste fino, implantação de prompts e endpoints de inferência devem ser solicitadas pela mesma interface de autosserviço usada para as demais necessidades dos desenvolvedores.
- Aplicação de políticas no momento da solicitação: limites de custo, regras de residência de dados e controles de acesso aos modelos devem ser verificados antes do início da tarefa, não depois do surgimento da fatura de serviços em nuvem.
- Aprovação humana proporcional ao impacto: nem todo prompt precisa de aprovação prévia, mas um modelo que lide com dados pessoais de clientes ou tome decisões autônomas pode exigir isso.
- Registro de auditoria claro: o registro deve responder a perguntas como o que mudou e por quê, independentemente de a mudança estar relacionada ao modelo, ao prompt ou aos dados, e quem aprovou a mudança ou o que foi aprovado.
O autor conclui que um pipeline de LLM é mais um consumidor automatizado dos recursos da plataforma e precisa das mesmas garantias oferecidas ao desenvolvedor humano ou ao agente autônomo. As equipes que têm sucesso nesse modelo não escolhem um lado na disputa entre DevOps, plataforma e MLOps; elas tratam o pipeline inteiro como um produto que pode ser versionado, monitorado e gerenciado em termos de custo, com ciclos contínuos de feedback.
Nesse sentido, Bryant não considera que LLMOps elimine ou reinvente a questão da responsabilidade, mas que coloque as plataformas existentes sob maior pressão devido ao tamanho dos modelos, ao seu custo elevado e à dificuldade de avaliá-los. Em sua visão, a solução é construir o fluxo padrão uma única vez e, depois, disponibilizá-lo como um recurso governado para o desenvolvedor, o cientista de dados e o agente inteligente, por meio de uma API ou de uma interface de usuário compartilhada. Ele observa que essa discussão continua dentro da CNCF, especialmente no Platforms Working Group do TAG App Delivery, que está aberto a quem quiser contribuir para ela.