PS: Eu não sou especialistas em agentes de IA, isso é puramente a visão de um engenheiro de produção.
São 5:99 da tarde de uma sexta e tu reescreveste o system prompt pela quinta vez hoje. De manhã o agente alucinou uma resposta e tu ajustaste a instrução.
Rodou de novo, veio torto do outro lado, tu trocaste de modelo. Veio melhor, tu respiraste aliviado. Veio ruim outra vez, e agora tu estás empilhando guardrail em cima de guardrail tentando consertar uma coisa que ontem funcionava.
Cada um desses ajustes tu fizeste de boa-fé, pra corrigir. E a maior parte deles piorou o teu sistema em vez de melhorar.
O problema não é o teu prompt. É ruído, e tu estás tratando ruído como se fosse sinal.
Essa cena já aconteceu antes. Em 1924.
Numa fábrica da Western Electric, um físico chamado Walter Shewhart percebeu uma coisa que se repetia em todo chão de fábrica. O operador media uma peça, ela saía fora do alvo, ele ajustava a máquina. Media a próxima, saía fora pro outro lado, ele ajustava de volta. Cada ajuste era honesto, feito pra corrigir o desvio que ele tinha acabado de ver. E cada ajuste aumentava a variação da peça seguinte, em vez de reduzir.
Shewhart enxergou que existem dois tipos de variação dentro de qualquer processo, e que confundir os dois era a raiz do estrago. Tem a variação que é própria do processo rodando normal, o barulho de fundo do sistema, onde ninguém em específico tem culpa porque está embutido no desenho da coisa. E tem a variação que vem de fora desse padrão, quando algo de fato mudou, uma ferramenta quebrou, o lote de matéria-prima veio diferente, alguém mexeu num parâmetro. A primeira ele chamou de causa comum. A segunda, de causa especial.
O instrumento que ele inventou pra enxergar a diferença foi o gráfico de controle. Antes do gráfico, separar um tipo do outro era chute. Depois dele, virou regra de decisão. Tu só mexes no processo quando um ponto sai da banda natural de variação ou forma um padrão que não é aleatório. Fora disso, deixa quieto.
Cem anos depois, a máquina virou um LLM e a gente esqueceu o gráfico. Tu rodas o agente, o output sai ruim, tu reescreves o prompt. Sem banda, sem regra, sem nem ter na cabeça o conceito de variação de rotina. É o operador de 1924 ajustando a máquina a cada peça, de roupa nova.
Todo output força a mesma pergunta
Um LLM é não-determinístico por construção. O mesmo prompt pode gerar saídas diferentes. Isso é a natureza da coisa.
Então toda vez que o agente te entrega um resultado ruim, tu cais exatamente na pergunta que o Shewhart fazia no chão de fábrica. Isso é sinal, algo de fato mudou ou quebrou, ou isso é ruído, a variação de rotina de um processo que continua o mesmo.
Os dois jeitos de errar
O Deming, que foi quem pegou as ideias do Shewhart e levou pro Japão, formulou isso de um jeito que não tem escapatória. Existem dois jeitos de errar aqui, e os dois custam caro.
O primeiro é tratar causa comum como se fosse especial. Tu reescreves o system prompt por causa de uma alucinação que era só variação e desestabiliza um sistema que estava funcionando. É o operador ajustando a máquina que estava boa.
O segundo é o contrário, tratar causa especial como se fosse comum. A taxa de acerto do teu agente caiu de verdade, o provedor atualizou o modelo por baixo, uma API mudou, teus dados sofreram drift, e tu deste de ombros porque “IA é instável mesmo”. Aí tu perdeste uma regressão real. É o operador que ignora a máquina que quebrou de verdade.
Tu não consegues zerar os dois erros ao mesmo tempo. Quem nunca mexe no agente comete só o segundo. Quem mexe a cada output comete só o primeiro. A única saída é minimizar a perda total, e foi pra isso que o gráfico de controle foi inventado. Ele não acaba com o erro, te dá uma regra pra errar menos no agregado.
Mexer num processo estável sempre piora
O Deming provava isso com um experimento que vale a pena tu imaginares, porque é simples de entender. Tu pegas um funil preso num suporte, miras num alvo na mesa, e deixas cair uma bolinha por ele. A bolinha quase nunca para no alvo, sempre cai um pouco pro lado. O que importa é o que tu fazes com o funil entre uma queda e outra.
Se tu deixas o funil parado, fixo no alvo, tens a menor variação possível, e as bolinhas se espalham num círculo apertado em volta do centro. Se tu ficas ajustando o funil a cada queda, movendo ele pra compensar o último desvio, a variação só aumenta. E tem uma versão ainda pior, que é colocar o funil exatamente onde a última bolinha parou. Isso manda o processo num passeio aleatório que vai se afastando cada vez mais do alvo, sem volta.
A lição é contraintuitiva e é matemática, não opinião. Mexer num processo estável em reação ao último resultado sempre piora o resultado seguinte.
Aplicado a agente, isso tem nome. Tampering. Ficar reescrevendo system prompt, trocando de modelo e empilhando guardrail em reação a um output ruidoso é adicionar a tua própria variação por cima da variação que o sistema já tinha. Tu deixas de ser o operador e viras tu mesmo uma causa especial. A fonte de instabilidade passa a ser tu.
E a IA tem uma armadilha que a fábrica não tinha. Lá, ajustar a máquina dava trabalho, então existia um freio natural pra não ficar mexendo. No prompt, tu “corriges” em dez segundos. O custo baixíssimo do ajuste é o que torna o tampering irresistível. Tu mexes porque é fácil, não porque é certo. Cada vez que tu ajustas o prompt em reação a um output ruim, na maioria das vezes tu não estás melhorando o sistema. Tu estás virando o ruído dele.
Capacidade é uma distribuição
O Wheeler, que escreveu os manuais que traduzem o Shewhart pra prática, separa duas vozes dentro de qualquer processo. Tem a voz do processo, que é o que o agente de fato faz de forma confiável, incluindo a variação natural dele, a capacidade real. E tem a voz do cliente, que é o que tu precisas que ele faça, a especificação.
O erro de quase todo time é olhar um output e decidir “o agente consegue” ou “o agente não consegue” fazer aquilo. Mas um output isolado não te diz quase nada sobre a voz do processo. Tu precisas da distribuição, de vários runs, pra ouvir o que o agente realmente é.
Capacidade é uma distribuição. Julgar um agente por um único output é tão sem sentido quanto julgar uma máquina por uma única peça que saiu da linha.
E tem outra coisa super importante também... Só faz sentido falar em capacidade depois que o processo está estável. Se o teu agente ainda está fora de controle, variando de forma imprevisível por causas especiais que tu nem resolveste, perguntar “ele consegue fazer X?” é prematuro. Primeiro tu estabilizas. Depois tu medes a capacidade contra a especificação.
Detectar melhora é tão difícil quanto detectar piora
O mesmo problema vale ao contrário. Tu mexes no prompt e o próximo output sai melhor. Ele melhorou de verdade, ou tu tiraste uma boa carta no sorteio? Com um run só, tu não tens como saber.
Comparar dois prompts testando um output de cada lado é autoengano. Tu estás declarando vitória em cima de ruído. Pra afirmar que tu mudaste o sistema, tu precisas da distribuição antes e depois, com runs suficientes pra o sinal aparecer através do barulho. Isso é o ciclo que o Deming chamava de PDSA. Tu prevês um resultado, rodas o suficiente pra enxergar sinal, e estudas o gap entre o que tu esperavas e o que veio.
Evals é o nome novo de um problema de 1924
O mundo de IA está redescobrindo tudo isso com o nome de evals. E é bom dizer isso com todas as letras, porque conecta o problema antigo com o vocabulário de agora.
Só que a prática de eval ainda é imatura.
Tu rodas o eval, vês 87%, comparas com os 84% da semana passada e concluis que melhorou. Um score de eval é uma medição com ruído próprio. A diferença entre 87 e 84 pode ser puro acaso amostral, a mesma bolinha caindo um pouco pro outro lado do funil. A disciplina não é ter eval. É entender a variação do teu eval. Sem isso, o eval vira só uma superfície nova pra fazer tampering, agora com IA e bem mais fancy (e caro)
Por que isso é pior na IA do que na fábrica
Não quero te vender a analogia como perfeita, porque ela é mais difícil do que isso, é pra ti fazer pensar.
A variação é maior. Uma máquina pode oscilar milésimos de milímetro. Um LLM pode te entregar respostas qualitativamente diferentes pro mesmo input, não um desvio de medida, uma resposta com outra forma.
E tem uma diferença mais séria, que é o processo mudar debaixo de ti. O provedor atualiza o modelo, roda teste A/B silencioso, depreca uma versão. O “mesmo” endpoint de ontem não é o mesmo processo hoje. Na fábrica, a máquina era a mesma na segunda e na terça.
Na IA, a estabilidade do processo não está nas tuas mãos. Isso não enfraquece a ferramenta do Shewhart, fortalece. A causa especial pode vir do teu fornecedor, sem aviso, e sem entender se teu processo é estável tu não tens como saber que veio.
Soma o drift dos teus dados e do teu contexto, que são fontes de variação que não existem numa peça de metal, e tu tens mais jeitos do processo se mexer sem que tu percebas, não menos.
Por que é tão difícil não mexer
Mexer é pior, e ainda assim é o que todo mundo faz, por medo e por pressão. O agente falha na frente de um stakeholder e a pressão pra fazer alguma coisa agora é enorme.
Só que reconhecer corretamente uma causa comum e não mexer é, muitas vezes, a decisão certa, e é a mais difícil de defender numa reunião. Reagir é confortável. Esperar a evidência aparecer exige sangue-frio.
Nada disso é novo
Nada disso é novo. O Shewhart desenhou o primeiro gráfico de controle num bilhete de uma página em maio de 1924. O Deming passou a vida toda em cima disso e levou as ideias pro Japão. O Wheeler escreveu os manuais. As ferramentas pra separar sinal de ruído estão prontas há cem anos, paradas na prateleira, esperando alguém precisar delas de novo.
A tecnologia é nova. O processo probabilístico embaixo dela, e a tentação de reagir a cada resultado dele, já têm nome e solução há um século.
A história anda em ciclos, e isso vale pra forma como a gente lida com cada tecnologia nova. Cada geração chega achando que as regras antigas não se aplicam a ela, e aí paga o preço cheio de redescobrir, no susto e com nome novo, o que já estava resolvido. Foi o que aconteceu com evals, uma palavra de 2026 pra um problema que o chão de fábrica já tinha resolvido em 1924.
A disciplina que tu precisas já foi inventada. O teu trabalho com agente é reconhecer em que ciclo tu estás e pegar a ferramenta que já está ali.
Saber do que realmente acontece no Gemba será cada vez mais valioso. Isso sim trará os famosos insights valiosos que irão mudar o jogo.
Heitor “Apenas um Engenheiro” Sasaki
Quer ser um DC, leia o doc e me mande mensagem no Linkedin/insta.
Vais ter acesso a todos os nossos materiais + os prompts que temos (escrita, entrevista, currículo, negócios e o DVP)
(podes ver os resultados do DC no Insta)
Dá uma conferida nos Data Creators disponíveis:
Tem mais, mas esses são os que posso publicar.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.