LLMOps na prática: do prompt ao pipeline de avaliação
LLMs evoluem rápido. Por isso, cada ajuste de prompt, modelo, retrieval ou estratégia de RAG pode gerar regressões depois do deploy.
Sem um processo contínuo de avaliação, times acabam promovendo versões “teoricamente melhores” que, na prática, pioram a qualidade, aumentam o p95 de latência ou estouram custos de inferência.
Este guia mostra como implementar um pipeline mínimo de avaliação em LLMOps para acompanhar qualidade, latência e custo com critérios objetivos, dados comparáveis e decisões reprodutíveis ao longo do ciclo de vida do produto.
A ideia é simples: sair do “parece melhor” e criar um processo em que cada versão de prompt, modelo ou retrieval seja avaliada contra um baseline claro antes de chegar aos usuários. Para base conceitual, vale conectar esse fluxo a referências clássicas de produção de ML, como Hidden Technical Debt e ML Test Score, que reforçam a importância de testes, monitoramento e governança em sistemas de aprendizado de máquina.
Por que avaliar continuamente (e não só antes do deploy)
Drift de dados e de objetivos
O contexto de negócio muda. As perguntas dos usuários mudam. As bases de conhecimento são atualizadas. Como resultado, uma configuração que funcionava bem no lançamento pode perder performance em intents frequentes ou casos críticos.
Por isso, a avaliação precisa ser periódica. Benchmarks como HELM, da Stanford, reforçam a importância de avaliar modelos de linguagem em múltiplas dimensões, não apenas por uma métrica isolada.
Trade-offs invisíveis
Melhorar cobertura pode degradar groundedness, aumentar latência ou elevar custo. Da mesma forma, reduzir tokens pode deixar a resposta mais barata, mas menos útil.
Em aplicações com LLMs, quase sempre há trade-offs entre qualidade, velocidade, custo, segurança e experiência do usuário. Por isso, o pipeline de avaliação deve observar várias métricas ao mesmo tempo.
Conformidade e confiança
Relatórios de avaliação e system cards mostram como times documentam testes de segurança, qualidade e comportamento antes e depois do lançamento. Esse padrão ajuda produto, engenharia, segurança e auditoria a trabalharem com evidências, não apenas com impressões.
Leituras da Tekne também podem complementar o tema, como LLMs no dia a dia do analista: 4 automações rápidas e o Bootcamp de ML & IA, especialmente para quem quer conectar uso prático de LLMs a pipelines mais estruturados.
O que medir (as três dimensões críticas)
Qualidade
Qualidade mede utilidade, correção e aderência à tarefa.
Em tarefas fechadas, como classificação, use métricas clássicas de ML, como acurácia, precisão, recall e F1. Já em geração aberta, use rubricas discretas, por exemplo de 0 a 5, combinadas com LLM-as-a-Judge e auditoria humana.
Essa abordagem escala melhor do que revisão manual completa, mas precisa de cuidado. Pesquisas recentes discutem vieses, inconsistência e limites do uso de LLMs como avaliadores automáticos.
Também acompanhe métricas como:
- alucinação;
- groundedness, ou uso adequado de fontes;
- toxicidade;
- vazamento de PII;
- consistência entre execuções;
- aderência ao formato esperado.
Latência
Latência mede o tempo necessário para entregar uma resposta útil.
Acompanhe p50 e p95 por etapa do fluxo: retrieval, rerank, geração, moderação e pós-processamento. Também vale medir time-to-first-token, especialmente em experiências conversacionais.
Essa visibilidade ajuda em decisões de rollout, canary, rollback e definição de SLAs por tipo de chamada.
Custo
Custo não deve ser medido apenas por requisição. Em muitos produtos, a métrica mais útil é o custo por tarefa concluída, como ticket resolvido, resposta aceita ou análise finalizada.
Além disso, monitore tokens por resposta, retries, rate limits, chamadas externas e custo por acerto útil. Uma regra prática é otimizar custo sem violar os limites mínimos de qualidade e latência.
Pipeline mínimo de avaliação (do prompt ao deploy)
1. Monte uma amostra representativa
Comece com uma amostra de 150 a 500 exemplos de logs anonimizados, estratificados por intenção, dificuldade e impacto.
Separe um golden set, com respostas canônicas ou critérios bem definidos, e um gray set, com casos mais abertos avaliados por rubrica. Esse conjunto deve evoluir com o produto.
2. Padronize variantes
Versione tudo que pode alterar o comportamento da aplicação:
- prompt templates;
- modelo;
- temperatura;
- top-p;
- retrievers;
- vector stores;
- orquestração;
- regras de pós-processamento.
Essa etapa é essencial para comparações justas. Se você muda prompt, modelo e retrieval ao mesmo tempo, fica difícil saber o que realmente melhorou ou piorou.
3. Meça qualidade
Para tarefas fechadas, use métricas determinísticas, como acurácia e F1.
Para geração aberta, combine rubricas com LLM-as-a-Judge e auditoria humana em uma amostra menor, por exemplo entre 10% e 20% dos casos. O avaliador automático ajuda a ganhar escala, enquanto a revisão humana reduz o risco de aceitar julgamentos inconsistentes.
4. Registre tempo e custo
Registre timestamps por etapa, uso de tokens, número de chamadas e custo estimado.
Depois, gere relatórios por cenário, intent e versão. O objetivo é entender não apenas se a versão ficou melhor, mas quanto ela custa e qual impacto gera no p95.
5. Faça comparação justa
Execute testes A/B offline usando a mesma amostra. Fixe seeds quando aplicável e mantenha o versionamento de modelo, prompt, retriever e base de conhecimento.
Essa disciplina reduz decisões baseadas em exemplos isolados e aproxima o pipeline de práticas de produção já discutidas em ML Test Score.
6. Defina gates de promoção
Antes de promover uma versão, estabeleça gates objetivos.
Uma versão só deve avançar se cumprir critérios como:
- qualidade maior ou igual à meta;
- p95 dentro do SLA;
- custo por acerto abaixo do teto;
- ausência de incidentes críticos;
- evidências registradas contra o baseline.
Dessa forma, baseline e candidate deixam de ser comparados por opinião e passam a ser comparados por evidência.
7. Faça deploy em etapas
Evite lançar uma mudança crítica direto para todo o tráfego.
Comece com shadow deploy, sem impacto direto para usuários. Depois, avance para canary, com uma fração controlada do tráfego, como 5% a 20%, dependendo do risco do caso de uso.
Durante essa etapa, monitore métricas online, como CSAT, reabertura de ticket, bloqueios de moderação, abandono de fluxo e feedback explícito dos usuários.
8. Mantenha um ciclo de melhoria
Erros recorrentes devem virar novos casos no conjunto de avaliação.
Além disso, atualize rubricas quando os objetivos do produto mudarem. Um pipeline de avaliação em LLMOps não é um artefato estático; ele funciona melhor como um benchmark vivo, revisado conforme o produto amadurece.
Metas realistas de partida
As metas abaixo devem ser tratadas como ponto de partida, não como regra universal:
- Qualidade: nota média ≥ 4,0/5 no golden set e alucinação ≤ 3% em consultas críticas.
- Latência: p95 ≤ 1,8× o p50 e ≤ 2,5 s para respostas curtas.
- Custo: redução de 20% versus baseline por tarefa, mantendo qualidade acima do limiar definido.
Esses valores precisam ser calibrados com dados históricos, impacto no negócio, criticidade do caso de uso e expectativa do usuário. Em um chatbot de suporte, por exemplo, o SLA aceitável pode ser diferente de um fluxo de análise documental ou geração de relatório.
Quando acionar rollback
Rollback deve ser tratado como parte normal da operação, não como sinal de fracasso.
Considere reverter uma versão quando houver:
- queda de 5% a 10% no score de qualidade versus baseline em duas janelas consecutivas;
- p95 fora do SLA por três picos seguidos em tráfego comparável;
- custo por acerto acima do teto por dois dias;
- vazamento de PII;
- toxicidade acima do limiar;
- alucinação grave em conteúdo regulado;
- incidentes de segurança relacionados a prompt injection, exfiltração ou uso indevido de ferramenta.
Para riscos específicos de aplicações com LLMs, o OWASP Top 10 for LLM Applications é uma referência mais adequada do que links genéricos sobre vazamento de credenciais.
Boas práticas & guardrails
- Observabilidade — log estruturado com request id, intent, prompt id, fontes usadas; isso reduz “dívida técnica” clássica em ML.
- Privacidade e ética — anonimização, filtros de PII e limites para dados sensíveis.
- Controle de variabilidade — seeds e temperatura estáveis em avaliação; few-shot fixo; caching de respostas/embeddings.
- Documentação viva — changelog de prompts/modelos, histórico de decisões e gates.
- Stack sugerido — PGVector (vetores/embeddings) e LangChain/LangGraph (orquestração/observabilidade) contam com documentação robusta e suporte da comunidade.
Conclusão e próximo passo
LLMOps eficaz começa com avaliação simples, contínua e comparável.
Ao estabelecer amostras representativas, rubricas claras, métricas de qualidade, controle de latência, monitoramento de custo e gates objetivos de promoção e rollback, você reduz regressões sem travar a inovação.
Na prática, o ganho está em transformar mudanças de prompt, modelo e retrieval em decisões rastreáveis. Em vez de promover uma versão porque ela parece melhor em alguns exemplos, o time passa a comparar baseline e candidate com critérios definidos.
Para acelerar a implantação desse pipeline com práticas de MLOps, LLMOps e GenAI, conheça o Bootcamp de ML & IA da Tekne e explore conteúdos relacionados, como LLMs no dia a dia do analista.
