99,9% de sucesso, uau! O meu fluxo de IA é formidável! Será?

E esse é um dos lugares em que avaliar IA pela média começa a ficar perigoso.

Não porque acurácia seja inútil.

Mas porque um único erro crítico pode custar a operação inteira.

VEM COMIGO!!

Dez erros. Dez problemas diferentes.

Imagine um agente de atendimento.

Ele recebe 1.000 solicitações.

Em 990, responde corretamente.

Nas outras 10:

• em 6, usa uma informação desatualizada;
• em 3, manda o usuário procurar o lugar errado;
• em 1, executa uma ação que não deveria.

A métrica diz:

99% de acerto.

Só que os dez erros não são irmãos.

Um custou vinte segundos.

Outro gerou um ticket.

Outro pode ter custado dinheiro, confiança ou uma bela conversa com o jurídico.

Colocar os três na mesma média é uma maneira confortável de perder informação.

O nome técnico disso importa

Em muitos sistemas, eu não avaliaria apenas accuracy, precision ou recall.

Eu criaria evals ponderados por severidade.

Eval é, basicamente, a bateria de provas que usamos para descobrir como a IA se comporta antes e depois de colocá-la diante de usuários reais.

A diferença é que essa prova não daria um ponto por questão.

Algumas questões valeriam muito mais.

Um erro poderia receber peso 1.

Outro, 10.

Outro poderia simplesmente ser classificado como:

Isso não pode acontecer.

Isso se aproxima do que aparece em avaliações cost-sensitive, nas quais o custo do erro entra na forma como julgamos o sistema.

Porque produto real não vive numa planilha em que todo falso positivo tem o mesmo preço.

Uma IA pode melhorar no dashboard e piorar no mundo real

Suponha que uma nova versão passe de 94% para 97% de acerto.

Ótimo.

Agora abra os erros.

A versão antiga errava principalmente situações simples e recuperáveis.

A nova parou de cometer vários desses erros, mas introduziu um tipo novo de falha em situações sensíveis.

A média subiu.

Eu talvez não lançasse.

Essa é uma das coisas que tornam AI Product diferente de boa parte do software tradicional.

Não estamos desenhando apenas caminhos previsíveis.

Estamos lidando com distribuições de comportamento.

O sistema pode fazer A na segunda, B na terça e, diante de uma entrada estranha que ninguém colocou no demo, inventar C na quarta.

Então eu não quero saber apenas:

Qual é a taxa de acerto?

Quero saber:

Onde ele erra?

Com quem ele erra?

Em qual contexto?

Quanto custa cada tipo de erro?

O usuário percebe que houve erro?

Ele consegue voltar atrás?

Essas respostas começam a mudar a arquitetura.

É aqui que entram os guardrails

Se determinado erro custa muito, eu não tentaria apenas deixar o modelo mais inteligente.

Eu reduziria o espaço em que ele pode errar.

É para isso que servem guardrails: limites técnicos e de negócio que definem até onde a IA pode ir sozinha.

Um agente pode consultar uma fatura?

Talvez.

Pode explicar a política de desconto?

Provavelmente.

Pode conceder qualquer desconto que considere razoável porque o cliente escreveu uma mensagem convincente?

Eu dormiria melhor se não.

Em ações de maior risco, o modelo pode até sugerir.

A execução fica presa a uma regra determinística, a um limite explícito ou a uma aprovação.

Não é falta de confiança na IA.

É arquitetura entendendo que autonomia também tem custo de risco.

Quanto maior o estrago possível, mais cara precisa ser a permissão.

"Coloca um humano no loop."

Essa frase costuma encerrar discussões cedo demais.

Human-in-the-loop significa colocar uma pessoa em algum ponto do processo para revisar, aprovar ou corrigir a decisão da IA.

Funciona.

Mas existe um pequeno inconveniente.

O humano é humano.

Se a IA acertar 300 vezes seguidas, o revisor começa a confiar nela.

A revisão vira:

aprovar.

aprovar.

aprovar.

aprovar.

Até chegar justamente a saída que precisava ser lida.

Esse fenômeno está relacionado ao automation bias, nossa tendência de dar peso excessivo a recomendações automatizadas.

E existe ainda o problema da vigilância.

Atenção sustentada degrada.

Então:

"Tem uma pessoa revisando" não é uma arquitetura de segurança.

Às vezes a saída correta é tornar certos erros impossíveis por design.

Outras vezes é mandar automaticamente os casos de maior risco para revisão.

Ou exigir uma ação adicional quando a confiança do modelo estiver baixa.

Ou usar uma regra determinística para bloquear o que nunca deveria passar.

Confiança também é uma métrica

Tem outro problema com o erro grave.

O usuário não mantém uma planilha emocional com os últimos 147 acertos do sistema.

Ele experimenta o produto.

E memória humana não trata cada segundo dessa experiência igualmente.

Os trabalhos de Kahneman e Redelmeier sobre a peak-end rule mostraram como nossa lembrança de uma experiência pode ser influenciada de maneira desproporcional por seus momentos mais intensos e pelo final.

Isso fica particularmente interessante em IA.

Cem respostas corretas podem construir confiança devagar.

Uma resposta absurdamente errada consegue gastar essa confiança numa tarde.

Depois disso, até as respostas corretas ficam mais caras.

O usuário começa a verificar tudo.

E quando o custo de verificação fica próximo do custo de fazer o trabalho manualmente, começa a desaparecer a razão econômica daquele produto.

A IA continua funcionando.

Só deixou de economizar alguma coisa.

Eu desenharia o eval antes da feature

Antes de produção, eu montaria uma base de casos reais.

Não só os bonitinhos.

Colocaria:

• casos comuns;
• casos ambíguos;
• entradas incompletas;
• situações raras;
• tentativas de burlar o sistema;
• casos em que a fonte está errada;
• casos em que duas fontes discordam;
• principalmente, casos em que um erro custa caro.

Depois classificaria os tipos de falha.

S0 | Irrelevante

O usuário percebe e corrige em segundos.

S1 | Recuperável

Gera atrito, mas o sistema consegue se recuperar.

S2 | Sério

Pode gerar dinheiro perdido, quebra de confiança ou trabalho operacional.

S3 | Crítico

Não deveria chegar ao usuário sem outra camada de proteção.

Não existe nada mágico nessas quatro categorias.

O número de níveis depende do produto.

O importante é parar de fingir que todos os erros têm a mesma biografia.

E isso não termina no lançamento

Eu continuaria rodando esses evals em produção.

Porque o conjunto de testes que representava bem agosto pode representar mal dezembro.

Usuários mudam.

Dados mudam.

Produtos mudam.

O vocabulário muda.

Esse deslocamento é parte do que chamamos de drift.

O sistema continua funcionando.

Só que o mundo ao redor dele já não é exatamente o mesmo.

Uma IA pode piorar sem ninguém ter feito deploy.

Por isso:

Eval não é prova de vestibular. É monitoramento.

A pergunta que eu colocaria no dashboard

Além da taxa de acerto, eu gostaria de ver uma informação separada, grande e impossível de esconder dentro de uma média:

Quantos erros graves tivemos?

Se a IA responde 500 mil vezes por mês, 0,1% de erro ainda significa 500 situações.

Então eu quero saber quais 500.

Talvez 490 sejam quase irrelevantes.

E talvez existam 10 que definam se esse sistema merece continuar tomando aquela decisão.

Em alguns produtos, eu trocaria feliz um ponto de acurácia média por uma redução radical no erro mais perigoso.

O modelo não precisa apenas acertar muito.

Ele precisa errar de um jeito que o produto consiga sobreviver.

Talvez essa seja uma régua melhor para IA.

Não pergunte apenas quantas vezes ela acertou.

Pergunte:

Quando ela errar, porque vai errar, quanto esse erro consegue destruir?