Resposta direta
Compare instruções de IA pelo que cada versão muda no processo, não pela qualidade percebida em uma conversa. O que precisa existir antes da comparação: uma versão identificada, a data, o responsável pela mudança e o motivo dela. Sem esse mínimo, duas instruções diferentes não são alternativas; são dois textos soltos. A comparação fica útil quando o mesmo conjunto de casos é aplicado a cada versão e o resultado é registrado item por item. Quem decide escolhe pelo efeito observado e pelo custo de manter a regra, não pelo entusiasmo de quem escreveu.
- Objetivo
- Comparar alternativas
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata a comparação como decisão de processo: o que registrar por versão e como usar o mesmo conjunto de casos, em vez de julgar a instrução pela conversa em que ela foi escrita.
O que cada versão precisa carregar
Uma instrução de IA só é comparável quando deixa rastro. O mínimo é um identificador da versão, a data em que entrou em uso, o responsável pela mudança e o motivo declarado. Sem o motivo, a próxima pessoa não sabe se a alteração resolvia um erro, atendia a uma reclamação ou apenas refletia uma preferência de redação.
Esse registro não exige ferramenta nova. Uma tabela com versão, data, autor, motivo e onde a instrução é aplicada já separa duas coisas que hoje se misturam: a mudança planejada e a mudança que ninguém percebeu que fez. O ponto é que a comparação comece antes do teste, não depois.
Comparar pelo caso, não pela redação
Duas versões de instrução se comparam aplicando o mesmo conjunto de casos às duas. O conjunto precisa ter casos que a mudança pretendia resolver e casos que ela não pretendia tocar. O segundo grupo é o que revela efeito colateral: uma regra nova corrige um comportamento e desalinha outro em silêncio.
O resultado se registra item por item, com o mesmo critério de aceite para as duas versões. Quando o critério é combinado antes, a discussão deixa de ser sobre qual texto soa melhor e passa a ser sobre o que cada versão faz com o processo, o dado de entrada e a responsabilidade de quem revisa a saída.
O que a comparação não resolve
Versionar instrução não garante consistência. Se o dado de entrada muda de fonte ou de formato entre os testes, a diferença observada pode vir do dado e não da instrução. A comparação também empata com frequência em casos comuns e diverge em casos raros, que costumam ser justamente os que geram retrabalho.
Ela não transfere responsabilidade. A versão escolhida continua sendo decisão de alguém, com nome e data, e o resultado precisa ser revisto quando o processo, a base de dados ou o volume mudarem. Comparar alternativas informa a escolha; não a substitui.
Recurso prático
Índice de escolha entre duas versões de instrução
Índice = (Acertos na versão ÷ Casos testados) × 100 − Penalidade de manutenção
- Acertos na versão
- casos
- Quantidade de casos em que a versão produziu a saída prevista no critério de aceite, contando cada caso uma vez.
- Casos testados
- casos
- Total de casos do conjunto, incluindo os que a mudança não pretendia alterar.
- Penalidade de manutenção
- pontos
- Peso atribuído ao esforço de manter a versão em uso, definido por quem opera antes do teste e igual para as duas versões comparadas.
O erro mais comum é montar o conjunto de casos com exemplos que a versão nova foi escrita para resolver. Isso produz um resultado favorável e esconde o efeito colateral. O conjunto precisa conter casos que a mudança não pretendia tocar; é onde a diferença entre as versões aparece.
Conceitos usados nesta página
- Critério de aceite — Critério de aceite é a condição objetiva que define quando uma entrega, tarefa ou automação é considerada concluída — verificável por quem recebe, não por quem produziu.
Sobre o que está escrito aqui
Conceitos relacionados: instrução de sistema · histórico de versões · conjunto de casos · critério de aceite · registro de mudança. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Workshop executivo, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- IA aplicada e agentes — Página central do tema
- Documento sensível em serviço externo: o que… — documento sensível enviado a serviço externo
- Acervo desatualizado alimentando a IA: onde o… — base de conhecimento desatualizada alimentando a IA
Páginas relacionadas
O mesmo problema em outro objetivo
- Instrução de IA sem versão: onde a resposta perde o lastro — Diagnosticar
- Instrução de IA sem versão: como manter histórico e dono — Organizar um processo
- Instrução de IA sem versão: o que dá para medir — Explicar medição
- Instrução de IA que ninguém versiona: o que fica em produção — Orientar implementação
- Instrução de IA sem versionamento: o que exigir no contrato — Orientar avaliação e contratação
Outras leituras em IA aplicada e agentes
- Expectativa de resultado sem medida: o que definir antes — Roteiro para converter promessa de resultado em critério verificável antes de contratar: linha de base, indicador, responsável e cláusula de medição.
- Pedido de IA sem especificação: onde dividir o contrato — Descreve como separar descoberta de entrega e o que o contrato precisa definir quando a equipe não consegue dizer o que a IA deve fazer.
- Revisão humana maior que o ganho: o que cortar da fila — A página trata a fila de revisão como processo com custo: o que exige conferência integral, o que aceita amostragem, quem aprova e como medir o tempo gasto.
- Promessa de automação total: o que registrar no contrato — Critérios para avaliar e contratar automação anunciada como total: escopo da decisão, caminho da exceção, dono da revisão e critério de aceite.
- Piloto de IA sem critério de sucesso: o que medir — O critério de um piloto de IA em andamento: o que medir, contra qual base comparar e quem responde pelo veredito.