Quando a IA erra, o sistema aprende ou apenas tenta de novo?

Um agente falha, recebe um novo prompt e acerta na segunda tentativa. O incidente é marcado como resolvido. Dias depois, outra sessão encontra a mesma situação, repete o erro e consome novamente tempo, tokens e revisão humana.

O sistema corrigiu uma execução. Não aprendeu.

Resumo executivo

Retry restaura uma tentativa. Aprendizado muda a probabilidade de recorrência. Um loop fecha quando a falha produz ao menos um mecanismo durável:

• caso de regressão;
• eval ou rubrica versionada;
• controle novo ou reforçado;
• mudança de contexto, ferramenta ou autoridade;
• documentação operacional endereçável;
• hipótese descartada;
• monitoramento capaz de detectar repetição.

Nem toda falha merece uma grande retrospectiva. Toda falha material merece uma decisão explícita sobre recorrência, impacto e destino do aprendizado.

Cinco respostas que parecem aprendizado

Tentar de novo

Um retry é correto para falha transitória. Torna-se ruído quando esconde erro determinístico, autoridade ausente ou entrada inválida.

Aumentar o prompt

Adicionar instruções pode resolver o caso atual e degradar outros. Sem eval, não sabemos se a mudança generaliza ou apenas memorizou o exemplo.

Trocar o modelo

Um modelo mais capaz pode reduzir determinada classe de erro. Também muda custo, latência, comportamento e safeguards. Upgrade não substitui análise da propriedade que falhou.

Registrar uma nota

Documentação sem caminho de recuperação, owner e gatilho depende de descoberta acidental. O aprendizado existe, mas não está conectado à execução.

Culpar o agente

“O modelo alucinou” descreve um sintoma amplo. Não responde por que o sistema aceitou a saída, qual verificação faltou ou que authority permitiu o efeito.

Da falha ao mecanismo

Use uma cadeia simples:

evento -> impacto -> classe -> causa controlável -> mecanismo -> regressão -> owner -> validade

Evento

Registre o subject: sessão, entrada, modelo, ferramenta, versão, ambiente e saída. Não copie dados sensíveis desnecessários para o aprendizado.

Impacto

Separe falha interna reversível de efeito externo, dado alterado, exposição de informação, decisão financeira ou dano ao usuário. A profundidade da resposta acompanha o risco.

Classe

Uma taxonomia pequena ajuda a encontrar recorrência:

Causa controlável

Não é necessário descobrir uma causa metafísica do modelo. Procure a fronteira que o sistema pode mudar: entrada, ferramenta, contrato, isolamento, verificação, authority ou operação.

Mecanismo

Transforme a lição em artefato executável ou operacional. Uma recomendação sem owner e gatilho permanece uma boa intenção.

Regressão

Reproduza o evento de forma sanitizada. Um teste determinístico é preferível quando existe; eval com rubrica entra quando a propriedade exige julgamento. A claim de qualidade precisa de critério explícito e evidência observável; trace ou inspeção subjetiva isolados são incompletos. [R3-C1]

O learning item como unidade de mudança

Um registro útil contém:

• identificador estável;
• evento e evidência sanitizada;
• classe e risco;
• decisão tomada;
• mecanismo ou justificativa para não mudar;
• repositórios, produtos ou controles afetados;
• owner e prazo;
• teste de regressão;
• estado: candidate, accepted, implemented, verified ou retired.

Essa unidade impede dois extremos: esquecer a falha ou transformar qualquer detalhe em regra global.

Quando não generalizar

Aprendizado também pode ser manter o sistema como está. Um caso isolado, de baixo impacto e altamente improvável pode não justificar complexidade permanente.

Registre a não-mudança com:

• impacto e frequência estimados;
• custo do controle;
• sinal que reabre a decisão;
• validade da conclusão.

“Sem mudança” é decisão. “Não fizemos nada” é ausência de processo.

O perigo do learning backlog

Catálogos extensos podem virar arquivo morto. Três guardrails mantêm o loop vivo:

1. aplicabilidade: cada item aponta para o ponto de execução que deve mudar;
2. prioridade por risco e recorrência: não por ordem de chegada;
3. verificação: implementado não é sinônimo de eficaz.

Métricas úteis incluem recorrência por classe, tempo até mecanismo, itens vencidos e proporção de falhas materiais com regressão. Número bruto de lições incentiva documentação, não aprendizado.

Um ritual de quinze minutos

Para uma falha material, responda:

1. o que aconteceu e qual subject estava ativo?
2. qual efeito ocorreu ou quase ocorreu?
3. onde o sistema poderia ter detectado antes?
4. o que muda de forma durável?
5. como provaremos que a mudança funciona?
6. quem responde e quando revisitaremos?

Se não houver resposta para 4 e 5, o fluxo provavelmente corrigiu o episódio, não o sistema.

O que este artigo prova — e o que não prova

Práticas de incident response, evals e melhoria contínua sustentam a separação entre restaurar e aprender. A FORGE materializa essa separação em registros, gates e regressões. O artigo não prova que todo erro pode ser eliminado, nem que mais regras sempre aumentam confiabilidade.

Sistemas sociotécnicos mudam; modelos, pessoas e processos compartilham falhas. O objetivo é reduzir recorrência evitável e tornar risco residual visível.

Conclusão

Tentar de novo pode ser a resposta operacional correta. Só não deve ser confundido com aprendizado.

O sistema aprende quando uma experiência altera seu comportamento futuro de modo endereçável, testável e proporcional ao risco. Sem isso, cada nova sessão paga novamente pela mesma lição.

Leitura anterior: Do checklist ao controle executável. Próxima leitura sugerida: O agente não pode ser seu próprio auditor.