Avaliar saída de IA: uma resposta isolada não basta

Uma boa resposta de IA mostra que o sistema consegue fazer a tarefa uma vez. Não mostra com que frequência ele acerta, em quais entradas ele falha nem se vale a pena manter a ferramenta naquele trabalho. Avaliação de saída trata a geração como amostra: várias entradas representativas, rodadas repetidas e um critério de aceite definido antes. A decisão de ficar ou sair vem por tarefa, não por demo.

Por que uma resposta boa não prova nada

Sistemas de linguagem não são determinísticos. O mesmo pedido pode render respostas de qualidade diferente. O Nielsen Norman Group descreve isso assim (em inglês): uma saída isolada é exemplo, não avaliação. Décadas de software clássico ensinaram o time a tratar “passou uma vez” como prova. Em IA, isso não se sustenta.

O artigo usa o exemplo de atendimento. A mesma pergunta sobre devolução pode sair correta numa rodada, omitir uma exceção na outra e prometer reembolso indevido na terceira. Qual delas representa o sistema? As três juntas, e nenhuma sozinha.

O que a avaliação precisa medir

O mesmo texto do NN/g (em inglês) compara a avaliação de IA a um estudo quantitativo de usabilidade. Em vez de um participante e uma tarefa, você observa várias pessoas em tarefas representativas e reporta média com intervalo de confiança. Em IA, o “participante” é uma execução; a “tarefa” é uma entrada de teste.

Duas perguntas precisam de resposta:

Como o sistema se sai no leque de entradas que a pessoa real vai mandar.
Quão consistente ele é quando a mesma entrada volta.

A primeira é variabilidade de entrada. A segunda é variabilidade entre execuções. Mais entradas não substituem mais rodadas, e o contrário também não.

Quantas entradas e quantas rodadas

O artigo ilustra com 10 perguntas representativas e 5 execuções cada, 50 saídas no total. Esses números não são recomendação universal. Servem para mostrar o desenho: várias entradas, repetição por entrada e resumo da distribuição.

Antes de rodar, defina o que conta como aceitável. No exemplo de atendimento, o NN/g pede resposta correta, com condições e exceções, alinhada à política e com próximo passo quando fizer sentido. Falhar em qualquer item torna a saída inaceitável.

No mínimo, reporte percentual de saídas aceitáveis, intervalo de confiança, variação entre perguntas e consistência na mesma pergunta. Documente modelo, versão, instruções, ferramentas e data. Se qualquer peça mudar, a avaliação vira outra foto.

O que a nota final esconde

Dois sistemas podem acertar 80% das 50 execuções e ter problemas bem diferentes. O NN/g mostra o contraste (em inglês): um acerta 8 de 10 perguntas em toda rodada e falha sempre nas outras 2; o outro acerta 4 de 5 em cada pergunta.

O primeiro é previsível: dá para mapear os temas que falham e encaminhar para pessoa. O segundo é imprevisível: qualquer pergunta pode sair errada, e o uso seguro costuma exigir revisão humana antes do cliente. A média sozinha esconde essa diferença.

Decidir por tarefa: o framework PROVE

Pressão para adotar IA não é evidência de que a ferramenta ajuda. O framework PROVE do NN/g (em inglês) avalia uma ferramenta contra uma tarefa e fecha com uma decisão provisória que dá para defender. As letras cobrem alinhamento com o problema, risco, qualidade da saída, velocidade total e experiência de uso.

Comece pela tarefa recorrente, não pela demo. Confira se o dado que você vai colocar é permitido. Compare a saída com um trabalho seu real, não com um caso amigável. Meça o tempo inteiro: setup, prompt, revisão, correção e formatação. Separe atrito de uma vez de atrito que volta toda semana.

Na escala sugerida, 3 significa “parecido com o que eu já faço”. Uma rodada numa entrada só é triagem, não veredito. O PROVE não recomenda ferramenta para a organização inteira; recomenda se você mantém, testa por um prazo ou deixa de lado naquela tarefa.

Quem verifica: letramento de saída

Usar IA com frequência não é o mesmo que usá-la bem. O estudo do NN/g sobre letramento de IA (em inglês) separa duas capacidades: fluência de prompt e letramento de saída. A primeira comunica intenção, limite e contexto. A segunda avalia o resultado: lacuna, alucinação, fonte e checagem quando o risco sobe.

As duas não crescem juntas. Tem gente fluente em prompt que aceita a resposta no valor de face. Tem gente cética que quase não usa e, por isso, não treina o prompt. Quem verifica de verdade cruza dado, pergunta de novo e troca de ferramenta conforme a tarefa.

Isso importa na avaliação. Sem alguém com letramento de saída, a rodada vira aplauso à resposta mais polida. A análise de adoção de chat de IA no UX (em inglês) mostra uso concentrado em escrita, design e código, e bem menos em tarefas com interação humana ou análise complexa. Tentar a tarefa com IA não prova que a saída passou.

Produtividade medida, com ressalvas

Jakob Nielsen resume três estudos (em inglês) em que a produtividade média subiu 66% com IA generativa. Atendimento ganhou 13,8% mais consultas por hora. Profissionais de negócio escreveram 59% mais documentos por hora. Programadores entregaram 126% mais projetos por semana.

O próprio artigo lista ressalvas. Os dados vieram de versões anteriores, na linha do ChatGPT 3.5. Dois dos três estudos mediram um uso só, muitas vezes o primeiro. O ganho vale nas tarefas que a IA cobre; no restante do dia, o efeito dilui. Cite o 66% com o link e com essas ressalvas no mesmo parágrafo. Produtividade alta sem avaliação de saída ainda pode embutir erro silencioso.

Como fica na Vexor

Na Vexor, meu produto de assistentes de IA no WhatsApp, a regra antes de instalar no cliente é a mesma. Uma resposta boa na demo não é avaliação. O modelo é escolhido por tarefa. Só fica o que aguenta perguntas reais repetidas, no tipo de conversa que o negócio vai receber.

O custo medido ficou na casa de centavos por conversa, com teto mensal por cliente, e a conta está no post sobre custo de IA por conversa. Esse número só faz sentido depois que a qualidade da saída passou no critério da tarefa. Modelo barato que erra e modelo caro que você julgou por uma demo brilhante caem no mesmo erro de método.

Onde as fontes divergem

Estatística contra decisão. O artigo de avaliação trata amostragem, intervalo de confiança e distribuição de falha. O PROVE trata se a ferramenta vale na sua tarefa, com escala e decisão provisória.
Quem verifica. O letramento de saída foca o comportamento de checagem no dia a dia. A avaliação formal foca desenho experimental; os dois se completam, mas respondem perguntas diferentes.
Produtividade contra qualidade. O texto do 66% mede throughput e, em parte, qualidade do entregável. Ele não substitui a amostragem de saídas sobre a política ou o fluxo do seu produto.
Uso contra sucesso. A análise de adoção conta conversas tentadas por ocupação. Não reporta taxa de acerto dessas tentativas.

O erro comum

O erro clássico é julgar pela melhor resposta que apareceu no teste. A demo escolhe a entrada fácil, roda uma vez e vende o destaque. Avaliação séria escolhe o leque real, repete, olha onde falha e só então decide se a ferramenta fica naquela tarefa. Se as rodadas custam demais para repetir, a conclusão clara é que a evidência ainda não basta.