De RAG à produção: meu roteiro de estudos em LLMOps

Quando comecei a estudar para o ITA, em 2018–2019, adotei um ciclo que uso até hoje: aprender o suficiente para começar, praticar, e voltar à teoria quando algo trava. Funciona porque a teoria deixa de ser abstrata. Ela chega na hora em que você precisa dela. Quero aplicar esse mesmo processo ao desenvolvimento de aplicações com LLMs.

Este roteiro começa com RAG, geração aumentada por recuperação, e termina com um serviço rodando em Kubernetes. A ideia em uma frase: em vez de confiar só no que o modelo decorou, você entrega os documentos certos junto com a pergunta. A partir daí é uma aplicação só evoluindo: recuperar informação, medir a qualidade das respostas, criar uma API, investigar falhas e automatizar a entrega. Fundamentos de LLM e treinamento do zero ficam de fora.

Roteiro revisado em 20 de outubro de 2026. Os projetos e critérios de avanço abaixo são a minha síntese para orientar os estudos, não requisitos oficiais dos cursos.

Como seguir o percurso

Escolha um acervo que você já conhece: documentação técnica pública, suas notas de estudo, ou uma base de suporte sem dados sensíveis. Use o mesmo acervo nos três projetos finais. Assim você compara a evolução dos resultados sem trocar o terreno debaixo dos pés.

Para começar, basta Python, Git, HTTP/JSON, SQL básico e Docker. Kubernetes entra no meio do caminho. Um modelo via API já resolve as primeiras etapas, então não precisa de GPU na sua mesa tão cedo.

O percurso tem quatro fases:

1. Construir: ingestão → recuperação → respostas com fontes.
2. Medir: avaliação → melhorias de recuperação → API → rastreamento.
3. Operar: atualização dos dados → Kubernetes → serviço de inferência.
4. Entregar: monitoramento → escala → GitOps → recuperação de falhas.

As fases se sobrepõem. Não estranhe voltar para uma delas quando um teste de carga expuser um problema na recuperação.

@mnsgrosa inverted-classroom 2 estrelas

Meu ciclo de estudo virou uma skill aberta, e o card acima leva ao repositório onde ela mora. É a sala de aula invertida com um vício meu: não consigo mais estudar sem tentar antes. Leio o suficiente para entender o que o exercício pede, uma ideia ou um exemplo, e parto para o código. Errar ali é o ponto. É o erro que diz qual página da teoria vale abrir, e não o contrário.

Por isso cada seção daqui para baixo traz a prática antes dos links. Ler tudo primeiro dá uma sensação boa de entendimento. E ela some na hora de rodar o primeiro índice. Tentar antes é o que mostra o que faltou.

1. Construir uma base RAG reproduzível

Comece com um fluxo explícito, sem mágica: carregar documentos, limpar o texto, dividir em trechos, gerar embeddings, indexar e recuperar contexto para responder. Guarde identificadores, origem e versão dos documentos desde o primeiro dia. PostgreSQL com pgvector serve como base principal; FAISS vale como exercício de comparação.

Na prática: escreva comandos para indexar um acervo pequeno e fazer perguntas. Registre os trechos recuperados e devolva respostas com referências que você consiga abrir e conferir. Quando a resposta não estiver no acervo, o sistema precisa dizer isso, e não inventar.

Siga quando: você conseguir reconstruir o índice a partir de uma instalação limpa, explicar cinco respostas de ponta a ponta e mostrar perguntas que o acervo não responde.

Recursos: trilha LLM Engineer de Maxime Labonne e RAG e busca vetorial no LLM Zoomcamp.

2. Avaliar antes de sofisticar a recuperação

A tentação aqui é grande: pular direto para busca híbrida e reranking porque parece mais avançado. Segure a mão por uma etapa. Sem conjunto de avaliação, você não sabe se melhorou o sistema ou apenas o trocou.

Monte perguntas cujos documentos relevantes você já conhece. Separe o conjunto de desenvolvimento da avaliação final, senão você acaba ajustando o sistema para o teste. Inclua perguntas sem resposta, perguntas ambíguas e tentativas de acessar conteúdo que não deveria estar disponível.

Meça recuperação e geração separadamente, porque o erro pode morar em qualquer um dos dois lados e você precisa saber de quem é a culpa. Hit Rate e MRR avaliam a busca; correção, apoio nas fontes e precisão das citações avaliam as respostas. Um avaliador baseado em LLM só é útil com rubrica e com comparação contra revisão humana.

Depois, compare a busca inicial com busca híbrida e reranking. Mexa no tamanho dos trechos e no orçamento de contexto, uma variável por vez. Se mudar duas coisas juntas e o resultado melhorar, você não vai saber qual delas funcionou. Query rewriting, HyDE e recuperação por SQL ou grafos podem esperar o problema que justifique essa complexidade.

Siga quando: existir um relatório comparável entre configurações, com erros por pergunta, qualidade, latência e custo. Escreva também o motivo da configuração final.

Recursos: avaliação no Zoomcamp, Ragas e RAG em produção com LlamaIndex.

3. Criar uma aplicação observável

Exponha o pipeline por uma API. Defina formatos de entrada e saída, autenticação, limites, timeouts, tentativas limitadas e cancelamento. Separe a ingestão do atendimento às perguntas, porque os dois ritmos são bem diferentes: um roda em lote, o outro precisa responder em segundos.

Instrumente o caminho inteiro: API → recuperação → reranking → geração → resposta. Um identificador de requisição deve amarrar logs, spans, fontes, versões e feedback. Acompanhe latência, erros, tokens e custo por resposta bem-sucedida, e decida com cuidado quais dados entram na telemetria.

Projeto final 1, assistente de conhecimento observável: entregue API ou interface, ambiente Docker Compose, avaliação reproduzível e painel de acompanhamento. Depois provoque uma falha de recuperação e um timeout, e mostre como identificou a causa nos sinais coletados.

Para avançar: defina metas de qualidade e orçamento de latência/custo antes do teste final. Como referência inicial, tente Hit Rate@5 de 0,85 nas perguntas respondíveis e pelo menos 90% de citações válidas. Reporte contagens, revisão humana e limitações, inclusive o que não funcionou.

Recursos: projeto do Zoomcamp, FastAPI, Langfuse e sinais do OpenTelemetry.

4. Operar os dados e aprender Kubernetes

Depois do primeiro projeto, duas frentes podem avançar em paralelo.

• Dados: automatize ingestão, reprocessamento e publicação do índice. Teste atualizações, exclusões, revogação de acesso, falhas parciais e restauração de backup. Rodar duas vezes não pode duplicar conteúdo.
• Plataforma: aprenda Pods, Deployments, Services, Jobs, Secrets, PVCs, probes e limites de recursos. Use KIND para implantar a aplicação e diagnosticar problemas de configuração, rede e disponibilidade.

Siga quando: você conseguir substituir um Pod sem perder os dados necessários, impedir que uma instância indisponível receba tráfego e restaurar uma versão anterior do índice.

Recursos: orquestração no Zoomcamp, Kestra, Kubernetes Basics e Lab 00 do School of DevOps.

5. Servir modelos, observar capacidade e escalar

Conecte a aplicação a um modelo servido com vLLM, mantendo a recuperação independente do backend de inferência. Aprenda a versionar pesos, validar artefatos e esperar o carregamento do modelo antes de liberar tráfego. Compare distribuição por OCI com download de armazenamento de objetos via initContainer.

Vale servir o mesmo modelo de três formas, nem que seja para sentir a diferença:

• Deployment com vLLM: ponto de partida com poucos componentes.
• vLLM Router: distribuição entre réplicas e investigação de afinidade de sessão/cache.
• KServe: recursos declarativos para modelos e runtimes reutilizáveis.

Use Prometheus e Grafana para ligar fila, cache e throughput ao tempo até o primeiro token e à latência percebida. Compare réplicas fixas com autoscaling. Mas cuidado: o modelo leva tempo para subir e a capacidade tem teto, então HPA e KEDA precisam reagir a sinais que façam sentido para a carga.

Projeto final 2, plataforma de serving reproduzível: reconstrua o ambiente, execute testes de carga, provoque a perda de um Pod e demonstre diagnóstico e recuperação. Escolha a arquitetura com base nas medições, não no que parece mais moderno.

Recursos: labs de packaging, serving, observabilidade e escala, métricas do vLLM e KServe. Os exercícios em CPU ensinam a operação; os números de desempenho deles não representam uma implantação em GPU.

6. Automatizar a entrega e praticar incidentes

Versione uma entrega completa: imagem da aplicação, modelo, prompt, índice e relatório de avaliação. Use CI para validar mudanças, Argo Workflows para executar pipelines e Argo CD para reconciliar a versão declarada no Git.

O fluxo que quero implementar é mudança → avaliação → artefatos imutáveis → promoção → observação → rollback quando necessário. O Lab 12 do School of DevOps ensina a orquestração, mas assume abertamente que não existe barreira de qualidade e traz etapas demonstrativas que precisam de scripts reais. Neste roteiro, uma avaliação reprovada bloqueia a promoção. Sem exceção.

Projeto final 3, operação durante um incidente: simule atualização do acervo, indisponibilidade do modelo, pico de tráfego, perda do índice e violação de acesso. Registre impacto, detecção, diagnóstico, recuperação e o teste de regressão que você criou depois.

Conclua quando: conseguir promover e reverter uma versão real, restaurar dados e apresentar arquitetura, resultados de qualidade/capacidade/custo, objetivos de serviço e procedimentos de operação.

Recursos: GitOps com Argo CD e pipeline com Argo Workflows.

Aprofundamentos opcionais

Fine-tuning entra quando a análise de erros justificar adaptar o comportamento do modelo. Se a recuperação resolve o problema, não complique. Quando fizer sentido, use dados revisados, avaliação independente e comparação com o modelo original, e passe o resultado pelo mesmo processo de entrega. O laboratório de LoRA oferece um ponto de partida.

GPU scheduling, GPU Operator e otimização de inferência são outra trilha possível, e fazem mais sentido depois de medir os limites do serviço. O roadmap de infraestrutura de IA ajuda a organizar esse aprofundamento.

Meu critério para continuar é simples: conseguir mostrar o que construí, explicar o resultado e reproduzir a evidência.