Um ciclo profissional com 15 etapas
Este framework organiza o trabalho; não obriga a preencher 15 documentos. Em uma tarefa simples, a maior parte cabe em uma ficha. Em uma aplicação com efeitos externos, cada etapa precisa de evidência proporcional ao risco. Os princípios de definir sucesso e avaliar antes de otimizar aparecem nas orientações de avaliação dos fornecedores. [S07, S08]
DEFINIR CONSTRUIR MEDIR OPERAR
Objetivo Baseline Executar Versionar
Contexto Dataset Comparar Monitorar
Critérios Variantes Identificar falhas Iterar
↑ ↓
└──── melhoria ─────┘
1. Definir objetivo
Escreva o resultado operacional: “classificar tickets para sugerir encaminhamento”. Identifique quem usa a saída e o que acontece se ela estiver errada. Não comece por “usar o modelo mais avançado”. Entrega: uma frase de tarefa, um destinatário e um limite de escopo. Conferência: é possível dizer se o resultado foi entregue?
2. Definir contexto
Reúna política, vocabulário, documentos, restrições e ferramentas realmente disponíveis. Separe material vigente, histórico e informação desconhecida. Entrega: pacote mínimo de contexto com fontes identificadas. Conferência: o prompt está recebendo tudo que precisa, sem dados sensíveis desnecessários?
3. Criar baseline
Escreva a versão mais simples que descreve a tarefa adequadamente. Salve o texto integral. Entrega: PROMPT-1.0, configuração e exemplo de entrada. Conferência: outra pessoa consegue reproduzir a tentativa? Uma baseline fraca propositalmente pode exagerar o ganho da variante; use uma referência honesta.
4. Criar dataset de teste
Selecione situações do trabalho, incluindo casos frequentes e falhas de alto impacto. Remova identificadores desnecessários. Separe desenvolvimento, seleção e confirmação. Entrega: identificador, entrada, referência, segmento e criticidade por caso. Conferência: há casos que podem reprovar sua solução preferida?
5. Definir critérios de avaliação
Determine o que é obrigatório, o que pode variar e o que elimina a resposta. Defina rubrica, pesos, métricas e critérios de escolha antes dos resultados. Entrega: RUB-1 e regra de promoção. Conferência: dois avaliadores têm instruções suficientes para chegar a vereditos justificáveis?
6. Executar testes
Rode a baseline nas entradas selecionadas e preserve as saídas sem edição. Registre falhas técnicas, tempo limite e uso de ferramentas. Entrega: log de execução por caso. Conferência: respostas ausentes e tentativas adicionais estão registradas, não excluídas?
7. Comparar resultados
Compare a baseline com a referência esperada ou, quando já existir, com a versão anterior. Calcule aprovação, notas e falhas por segmento. Entrega: tabela de diferenças. Conferência: a média está escondendo erros graves ou uma classe importante?
8. Identificar falhas
Agrupe erros por origem provável: requisito ambíguo, dado ausente, fonte errada, classificação, cálculo, formato, ferramenta ou permissão. Entrega: lista priorizada por frequência e impacto. Conferência: existe evidência para a hipótese de causa?
9. Criar variantes
Faça a menor alteração que testa a hipótese escolhida. Mantenha a baseline intacta. Entrega: B, diferença em relação a A e resultado esperado da mudança. Conferência: o teste permite entender o que foi alterado? Se mudar vários componentes, declare comparação de configurações completas.
10. Executar A/B test
Compare A e B nas mesmas entradas offline. Controle contexto, parâmetros e ferramentas; use avaliação cega quando possível. Entrega: resultados pareados, perdas, ganhos e empates. Conferência: cada candidata teve a mesma oportunidade, sem selecionar apenas a melhor tentativa?
11. Selecionar melhor versão
Aplique a regra definida: primeiro critérios eliminatórios, depois qualidade e custo/tempo. Confirme a escolha em entradas reservadas. Entrega: decisão e limites. Conferência: “nenhuma” e “empate” são opções reais? Se a candidata falhar criticamente, não existe obrigação de promover uma vencedora.
12. Testar casos extremos
Teste entrada vazia, texto muito longo, idioma inesperado, conflito de fonte, injeção de instrução, indisponibilidade de ferramenta e retorno parcial. Entrega: evidência dos comportamentos de exceção. Conferência: a aplicação falha de modo tratável? Limites de contexto e permissões não podem depender apenas da boa vontade do modelo.
13. Versionar o prompt
Registre texto, modelo/configuração, política, dataset, rubrica e responsável. Entrega: pacote identificável e versão anterior preservada. Conferência: um relatório produzido ontem pode ser rastreado à configuração que o gerou? Não é necessário armazenar raciocínio privado para manter esse registro.
14. Monitorar desempenho
Acompanhe amostra de respostas, falhas críticas, exceções, custo por resultado utilizável e tempo de revisão. Verifique se a distribuição de entradas mudou. Entrega: painel ou registro periódico com responsável. Conferência: o monitoramento detectaria a falha antes que ela se repetisse em escala?
15. Iterar continuamente
Converta incidentes em casos de regressão, atualize fontes e teste novas versões quando houver motivo. Preserve um conjunto novo para confirmação. Entrega: histórico de melhoria e revisão da decisão de uso. Conferência: continuar, simplificar ou interromper são possibilidades consideradas?
Ficha única para uma equipe pequena
Tarefa e responsável:
Dados/política autorizados e versão:
Prompt baseline e modelo/configuração:
Dataset e rubrica:
Hipótese e variante:
Resultados reais ou simulados, claramente identificados:
Falhas críticas e regressões:
Decisão: manter / promover em piloto / corrigir / interromper
Escopo de uso, revisão e data/gatilho da próxima avaliação:
Versão anterior e procedimento de retorno:
Cadência proporcional ao risco
Para rascunhos internos, revisão pelo autor e registro simples podem bastar. Para respostas frequentes ao público, use amostragem, revisão de exceções e políticas explícitas. Para ações em sistemas, acrescente validação, permissão e confirmação. Para decisões de alto impacto, envolva responsáveis qualificados e controles específicos do domínio. Não trate um único score genérico como autorização para todos esses níveis.
Matriz de maturidade de Prompt Engineering
Sete níveis e evidências para avançar
Maturidade descreve capacidade de operar com consistência, não quantidade de jargão, número de agentes ou custo da ferramenta. Uma pessoa pode estar no nível 6 em extração de documentos e no nível 2 em atendimento. Avalie por processo, não apenas pela empresa inteira.
| Nível | Como se caracteriza | Fragilidade típica | O que é necessário para avançar | Evidência de avanço |
|---|---|---|---|---|
| 1: Prompt casual | Pedidos improvisados, sem critério explícito | Avaliação por impressão | Definir objetivo, dados e formato | Um pedido reproduzível com critério de conferência |
| 2: Prompt estruturado | Briefing claro, contexto e restrições | Cada pessoa recria o próprio pedido | Separar partes fixas e variáveis | Template utilizável por outra pessoa |
| 3: Templates reutilizáveis | Padrões compartilhados e exemplos | “Funciona para mim” sem teste | Criar casos de teste e registrar respostas | Dataset pequeno com referências revisadas |
| 4: Prompt testing | Comparação de versões em casos definidos | Critérios incompletos e resultados pouco comparáveis | Calibrar rubricas e combinar avaliadores | Scorecard com falhas, métricas e decisão sustentada |
| 5: LLM evaluation | Critérios por tarefa, avaliação humana e automatizada | Dificuldade de rastrear mudanças | Versionar configurações e observar uso real | Saída ligada a prompt, política, modelo e avaliação |
| 6: Versionamento e observabilidade | Histórico, registros e diagnóstico de falhas | Métricas técnicas desconectadas do negócio | Implantar promoção gradual, retorno e feedback | Piloto controlado com metas operacionais verificadas |
| 7: Produção e otimização contínua | Uso real monitorado, melhoria e responsabilidades | Acomodação, mudança de dados ou políticas | Manter revisão proporcional ao risco | Incidentes viram testes; resultados reais orientam decisões |
Observabilidade é a capacidade de entender o que ocorreu a partir de registros e indicadores. Ela não exige armazenar todo o conteúdo de clientes. Registre o mínimo necessário, com acesso restrito e tratamento adequado de dados.
Como aplicar a matriz em uma reunião
Escolha uma rotina, como resumo de tickets. Peça evidências dos níveis, não autoavaliações vagas. Se há templates, mas não existe nenhum resultado de teste preservado, o processo ainda não atingiu o nível 4. Escolha a menor ação que fecha a lacuna: montar dez casos e avaliá-los, em vez de contratar imediatamente uma plataforma de monitoramento.
Exemplo de diagnóstico fictício
Uma equipe possui 30 prompts em uma pasta, mas ninguém sabe a versão de política usada. Isso caracteriza reutilização parcial, não maturidade de produção. A ação prioritária é selecionar três prompts de uso frequente, registrar responsáveis, criar testes e retirar versões obsoletas. A quantidade de prompts não é evidência de qualidade.
Regra de progressão
Avance quando o novo comportamento se repetir no trabalho e puder ser demonstrado. Não é necessário alcançar o nível 7 para usar IA em um rascunho. O nível exigido depende do impacto da aplicação; aumentar autonomia sem aumentar evidência não representa maturidade.