Solução · AI Operations
Os teus prompts estão em produção e ninguém sabe ao certo que versão está a correr
O prompt é a peça que mais manda no comportamento da tua IA e, em quase todas as empresas, edita-se à mão, sem revisão, sem histórico e sem forma de voltar atrás. Montamos e operamos a função que o transforma num artefacto versionado, testado antes de subir e reversível num minuto.
O problema
O artefacto que mais manda na tua IA é o único que ninguém governa
- Ninguém consegue afirmar ao certo que versão do prompt está a servir neste momento, quem a mudou pela última vez nem porquê.
- Uma alteração de uma linha publica-se diretamente sobre produção, porque não existe um ambiente onde a testar antes com casos reais.
- Quando a qualidade cai, não se consegue voltar à versão anterior: não está guardada em lado nenhum, ou está no histórico de uma conversa de chat.
- O mesmo prompt vive duplicado no código, numa ferramenta e na área de transferência de alguém, e cada cópia leva meses a derivar por sua conta.
- Quando o fornecedor atualiza o modelo há que rever prompts, mas ninguém sabe quais existem, quais dependem desse modelo nem com que critério foram validados.
- A equipa deixou de mexer nos prompts. Não porque estejam bem: porque mudá-los mete medo e ninguém quer ser quem parte a produção a uma quinta-feira.
O custo de continuar igual
Estás a operar um sistema cuja peça de maior impacto não tem controlo de alterações. O custo chega por dois lados ao mesmo tempo. Primeiro, a regressão que ninguém viu chegar e que é um cliente a descobrir. Depois, mais caro, a paralisia: quando mudar o prompt é uma aposta, a equipa deixa de lhe tocar e o sistema deixa de melhorar precisamente quando o mercado começa a mexer-se. A isto junta-se uma terceira frente, que aparece assim que alguém pergunta de fora: sem histórico não consegues reconstruir que instruções governavam o teu sistema no dia em que tomou uma decisão concreta.
A solução
Montamos e operamos a gestão da mudança dos teus prompts: versão, teste, implementação faseada e volta atrás
- 1Inventariamos e consolidamos. Tiramos cada prompt de onde estiver —código, ferramentas, documentos, cabeças— e transformamo-lo num artefacto com identificador, dono, versão e histórico, com uma única fonte de verdade de onde leem todos os ambientes.
- 2Separamos ambientes e pomos um gate. Uma alteração nasce fora de produção, passa pela bateria de casos e só sobe se ultrapassar o limiar acordado. O mesmo gate para toda a gente, sem exceções por urgência: a urgência gere-se com um caminho rápido documentado, não a saltar o controlo.
- 3Construímos a bateria de testes do prompt: um conjunto de casos reais e adversariais, congelado e versionado, que corre contra cada candidato e compara a sua saída com a da versão que está viva. Sem comparação contra a versão viva, um bom resultado não significa nada.
- 4Implementamos por fases. A versão nova entra primeiro sobre uma porção do tráfego, com a anterior a correr em paralelo sobre as mesmas entradas, e só depois sobre a totalidade. A volta atrás é uma mudança de ponteiro: um minuto, sem implementar código e sem reunião.
- 5Operamos a função no dia a dia: quem pode mudar o quê, o que se revê antes de subir, o que fica registado de cada alteração para se poder reconstruir depois, e a revisão programada sempre que o fornecedor mexe no modelo por baixo.
O que muda
O que deixas de perder
A pergunta «que versão está a correr» deixa de ser uma investigação e passa a ser uma consulta: há um identificador, um histórico e um dono por cada prompt em produção.
Mecanismo
Uma alteração deixa de ser uma aposta: compara-se contra a versão viva sobre os mesmos casos antes de subir, e sobe por fases sobre uma parte do tráfego.
Mecanismo
A volta atrás deixa de depender de alguém se lembrar do texto anterior: é uma mudança de ponteiro para uma versão guardada, sem implementar código.
Mecanismo
O que medimos: tempo desde que se deteta uma regressão até ser revertida, % de alterações que passam pelo gate, alterações revertidas sobre o total e número de prompts em produção sem dono identificado.
O que medimos
Ficha técnica
- Trabalho que elimina
- editar prompts à mão sobre produção, sem histórico, sem comparação contra a versão viva e sem forma de voltar atrás quando a qualidade cai
- Implementação habitual
- 4–8 semanas
- Entrada
- uma proposta de alteração sobre um prompt em produção: um ajuste de instrução, uma mudança de modelo ou uma correção depois de um incidente
- Saída
- uma versão nova testada contra a bateria de casos, comparada com a viva, implementada por fases e reversível num minuto, com o registo de quem, quando e porquê
- Compatível com
- OpenAIAnthropicAzure OpenAIGoogle Vertex AILangSmithLangfusePromptfooBraintrustGitHub ActionsGitLab CI
- Pode ligar-se a
- Tu repositorio y tu circuito de revisión de códigoTus registros de producción, de donde salen los casos de pruebaTu función de evaluación continua de calidad, si ya la tienes montadaTu registro de trazabilidad y tu inventario de sistemas de IA
- O que medimos
- tempo desde que se deteta uma regressão até ser revertida% de alterações que passam pelo gate antes de produção% de alterações revertidas sobre o total implementadoprompts em produção sem dono identificado
- Adequado para
- empresas com IA em produção e várias pessoas a mexer em prompts —CIO, COO ou responsável de IA— que precisam de poder mudar depressa sem partir nada e de demonstrar o que governava o sistema em cada momento
- Não adequado para
- quem tem um só prompt estável em que não se toca há meses, ou quem procura medir se a resposta do agente é boa: isso é avaliação de qualidade, uma função distinta e complementar
Perguntas frequentes
No que governam. A avaliação contínua mede se a resposta do teu agente é boa hoje: amostra conversas reais, pontua-as contra um critério e deteta que a qualidade caiu. Esta função governa a mudança do artefacto que produz essa resposta: onde vive o prompt, quem lhe pode tocar, que teste tem de passar antes de subir, como se implementa e como se volta atrás. São complementares e funcionam melhor juntas —a bateria de casos e as métricas de qualidade alimentam-se do mesmo—, mas resolvem problemas distintos: uma diz-te que algo se partiu, a outra faz com que parti-lo seja reversível e raro.
O Git é o alicerce e usamo-lo, mas por si só resolve metade. Dá-te histórico e revisão, e isso já é mais do que a maioria tem. O que não te dá: um ambiente onde testar o candidato contra casos reais antes de subir, a comparação automática contra a versão que está viva, a implementação sobre uma parte do tráfego e a volta atrás sem implementar código —que é o que precisas às onze da noite. Além disso, em muitas equipas quem melhor escreve os prompts não trabalha no repositório, e obrigá-lo a passar por um pull request para mudar uma frase acaba na cópia paralela do costume.
Ao contrário: o que trava hoje é o medo. Nas equipas sem controlo de alterações mexe-se pouco nos prompts e de respiração suspensa, porque qualquer ajuste pode partir algo que ninguém vai detetar até um cliente se queixar. Quando testar custa minutos e voltar atrás custa um minuto, o custo de errar baixa tanto que as pessoas voltam a experimentar. O gate não está lá para acrescentar burocracia: está para que a mudança seja barata. E para o que é verdadeiramente urgente há um caminho rápido documentado, com revisão posterior obrigatória.
Montamos no teu negócio?
Localizaste o problema. Nós entregamos a solução e deixamo-la medida.