Como transformar feedback em avaliação de IA

Feedback para avaliações de inteligência artificial ganha valor quando deixa de ser apenas reclamação e passa a descrever uma situação avaliável. O trabalho aqui não é diagnosticar a causa da falha, mas selecionar relatos com tarefa, contexto, expectativa e risco recorrente, reescrevê-los como casos de avaliação de IA e definir como a falha será verificada na revisão seguinte.

Nem todo feedback merece virar teste. Mas alguns exemplos revelam exatamente o tipo de problema que não pode voltar despercebido.

Quando um feedback merece virar caso de avaliação

Um produto com IA costuma gerar muitos comentários: “a resposta foi ruim”, “não entendeu meu pedido”, “inventou uma regra”, “fez certo para um caso e errado para outro”. Parte disso é ruído operacional. Parte é sinal de uma falha que precisa entrar no sistema de prevenção.

A diferença está na qualidade do relato. Um feedback merece virar caso de avaliação quando descreve, ou permite reconstruir, quatro elementos:

• a tarefa que a pessoa tentava concluir;
• o contexto que mudava a resposta esperada;
• o resultado correto ou aceitável;
• o risco de a falha se repetir com impacto relevante.

Se o comentário diz apenas “a IA foi confusa”, talvez ele sirva para descoberta, suporte ou investigação qualitativa. Se diz “a IA recomendou uma condição que não se aplicava ao plano do usuário, mesmo com o plano disponível no contexto”, há matéria prima para avaliação.

Essa distinção evita dois erros comuns. O primeiro é transformar qualquer reclamação em teste, criando uma suíte inchada e difícil de manter. O segundo é tratar relatos ricos como casos isolados, resolvidos por correção pontual, sem impedir que o mesmo padrão volte na próxima mudança de instrução, contexto, interface ou modelo.

O critério é simples: feedback útil para avaliação não prova qualidade nem fracasso geral. Ele identifica uma situação que deve ser reproduzida e verificada nas próximas mudanças.

Como extrair a tarefa real por trás do relato

O relato bruto quase sempre fala da resposta aparente. O caso de avaliação precisa falar da tarefa real.

Imagine que um usuário diga: “o assistente respondeu uma coisa errada sobre reembolso”. Isso ainda é insuficiente. Para transformar em caso avaliável, o time precisa reescrever o episódio em termos operacionais:

• qual era a entrada do usuário;
• em que estado o produto estava;
• quais dados estavam disponíveis para a IA;
• que ação a IA deveria executar;
• qual consequência poderia ocorrer se a IA falhasse.

A pergunta deixa de ser “a resposta parece boa?” e passa a ser “nesta situação, com este contexto, a funcionalidade preserva a regra que deveria preservar?”.

Essa mudança é especialmente relevante em funcionalidades com agentes de IA, ou seja, sistemas que executam etapas para tentar concluir uma tarefa. A Anthropic distingue a trajetória de execução do agente do resultado efetivo no ambiente: uma mensagem dizendo que a tarefa terminou não basta para comprovar que o resultado foi produzido. Para avaliação, isso significa que o teste não deve aceitar apenas uma resposta convincente. Ele precisa verificar se a tarefa foi cumprida ou se a restrição foi respeitada.

Em produtos menos autônomos, a mesma lógica vale. Um resumo, uma recomendação, uma classificação ou uma resposta de suporte também precisa ser avaliada contra a tarefa real. Se a pessoa precisava decidir o próximo passo, a avaliação deve considerar se a saída ofereceu informação suficiente, pediu esclarecimento quando necessário ou evitou uma orientação indevida.

Esse ponto conecta este artigo ao debate sobre sucesso de tarefa em produtos com IA: antes de avaliar uma resposta, o time precisa saber qual trabalho aquela resposta deveria ajudar a concluir.

Como transformar exemplos em critérios de sucesso

O próximo passo é trocar adjetivos por critérios observáveis.

“Resposta ruim” não é critério. “Resposta incompleta” também pode ser vago demais, se ninguém souber o que conta como completo. Um critério de sucesso precisa dizer o que deve acontecer para o caso ser aprovado.

Alguns exemplos de critérios possíveis:

• completude mínima: a resposta cobre os campos ou condições necessários para a tarefa;
• respeito a restrição: a IA não recomenda uma ação proibida pelo contexto disponível;
• uso correto de contexto: a saída considera plano, permissão, histórico, idioma, categoria ou outra informação relevante;
• pedido de esclarecimento: quando a entrada é ambígua, a IA não força uma conclusão;
• recusa adequada: quando a tarefa está fora do escopo, a IA explica o limite sem inventar alternativa;
• consistência com base esperada: a resposta coincide com uma fonte interna definida pelo time.

O critério não deve ser inferido automaticamente pela ferramenta. Ele é uma decisão de produto, dados, suporte e engenharia. A ferramenta pode ajudar a executar a avaliação, mas alguém precisa decidir o que é aceitável naquele contexto.

O comentário aponta uma falha. O critério define o que precisa ser observado para que essa falha não passe sem teste.

Há também um limite importante: critérios não substituem julgamento humano em casos ambíguos, sensíveis ou com consequência operacional relevante. Nesses casos, a avaliação pode indicar risco, organizar evidências e bloquear mudanças automáticas, mas a decisão pode continuar exigindo revisão humana.

Como escolher verificadores para prevenir repetição da falha

Depois do critério, vem o verificador. Verificador é o mecanismo usado para decidir se o caso passou ou falhou.

Nem todo verificador precisa ser sofisticado. Em alguns casos, uma checagem automática simples resolve: a resposta contém uma informação obrigatória, não contém uma expressão proibida, preserva uma categoria ou retorna um formato esperado. Em outros, a avaliação exige comparação com uma base de referência, revisão humana ou execução no ambiente.

A escolha depende do tipo de falha que você quer prevenir:

• se a falha é estrutural, como ausência de campo obrigatório, uma checagem automática pode bastar;
• se a falha envolve interpretação de contexto, uma comparação com resposta esperada pode funcionar melhor;
• se a falha envolve qualidade semântica, revisão humana pode ser necessária;
• se a falha envolve ação no produto, o verificador precisa olhar o efeito no ambiente, não apenas a mensagem da IA.

Essa última distinção é decisiva. Em uma funcionalidade que atualiza cadastro, abre chamado, altera status ou consulta uma política, a frase “feito” não comprova que algo foi feito. O verificador deve observar o resultado esperado, quando isso for possível e seguro.

A Anthropic descreve avaliações com entradas, critérios de sucesso e verificadores, inclusive com a possibilidade de várias tentativas. A aplicação prática aqui é não confundir boa aparência com bom resultado. Uma resposta bem escrita pode falhar no critério. Uma resposta menos elegante pode cumprir a tarefa com segurança.

Para aprofundar a coleta anterior a essa conversão, vale conectar o processo ao artigo sobre como coletar feedback útil sobre funcionalidades inteligentes. Sem contexto capturado na origem, a avaliação nasce frágil.

Como definir limites de aceitação sem esconder regressões

Um caso de avaliação precisa de limite de aceitação. Sem limite, o time apenas acumula exemplos e opiniões. Com limite, a avaliação passa a orientar uma decisão: publicar, ajustar, investigar ou interromper a mudança.

O cuidado é não deixar a média esconder um problema relevante. A Google SRE explica, no contexto de monitoramento, que médias podem ocultar comportamentos problemáticos e que visões diferentes atendem públicos diferentes. A mesma cautela se aplica a avaliações de IA: uma taxa agregada aceitável pode esconder falhas em um tipo de entrada, perfil de usuário, plano, idioma, canal ou fluxo.

Por isso, limites de aceitação devem considerar segmentos quando houver diferença relevante. Não é preciso criar recortes infinitos. É preciso escolher os recortes que mudam o risco.

Alguns cortes úteis podem ser:

• tipo de tarefa: consulta, recomendação, classificação, execução;
• complexidade da entrada: pedido simples, pedido ambíguo, pedido com exceção;
• contexto disponível: com dados completos, com dados parciais, sem contexto suficiente;
• perfil operacional: usuário novo, usuário recorrente, equipe interna, suporte;
• categoria de risco: baixo retrabalho, decisão do usuário, possível quebra de confiança.

A Microsoft recomenda observar métricas e segmentos durante experimentos para identificar regressões e evitar interpretações precipitadas. Essa recomendação não transforma avaliação em experimento, mas reforça um princípio útil: decisões tomadas só pela visão agregada podem chegar cedo demais.

O limite de aceitação também precisa ser definido antes da avaliação. Se o time ajusta o limite depois de ver o resultado, o caso deixa de proteger a decisão e passa a justificar uma preferência.

Exemplo fictício: do feedback bruto ao caso de avaliação

Exemplo fictício, criado apenas para demonstrar o método.

Feedback bruto recebido pelo suporte: “A IA sugeriu uma política de reembolso que não vale para meu plano”.

Esse relato, sozinho, ainda não é um caso de avaliação. Ele precisa ser convertido.

A tarefa real: o usuário queria saber se poderia solicitar reembolso de uma compra feita em determinado canal.

O contexto necessário: o usuário estava em um plano específico, com uma regra diferente de reembolso. O plano estava disponível no contexto do produto. A política geral existia, mas havia uma exceção aplicável àquele plano.

A entrada do caso: uma pergunta do usuário sobre reembolso, formulada de modo natural, sem mencionar o plano explicitamente.

O resultado esperado: a IA deve consultar ou usar o contexto do plano antes de responder. Se o plano tiver regra específica, a resposta deve informar a regra aplicável. Se o contexto estiver ausente ou contraditório, a IA deve pedir esclarecimento ou orientar a conferência no canal apropriado, conforme o desenho do produto.

O critério de sucesso: a resposta não pode recomendar a política geral quando houver uma regra específica disponível no contexto do plano. Deve deixar clara a condição aplicável ou pedir esclarecimento quando a informação necessária não estiver disponível.

O verificador: comparação com uma base esperada de políticas por plano, combinada com revisão humana para casos em que a resposta peça esclarecimento. Se a funcionalidade executar uma ação, como abrir uma solicitação, o verificador deve checar se a solicitação foi criada na categoria correta ou se foi bloqueada quando a regra não permitia avanço.

O limite de aceitação: o caso não deve ser avaliado apenas no agregado. O time deve olhar separadamente perguntas sobre política geral e perguntas em que há exceção por plano. Se a falha aparecer justamente nas exceções, a média geral não deve autorizar a mudança sem investigação.

A ação preventiva: se o caso falhar, a próxima mudança não deve ser publicada como está. As alternativas podem incluir ajustar o contexto entregue à IA, revisar a instrução, melhorar a recuperação da política correta, ampliar casos de avaliação para outros planos ou manter revisão humana no fluxo afetado.

Nada nesse exemplo mede um resultado real. Ele mostra uma hipótese operacional a avaliar: se a IA respeita uma regra específica quando o contexto do usuário muda a resposta esperada.

Checklist de triagem de feedback para avaliação

Use este checklist quando revisar exemplos vindos de suporte, revisão humana, pesquisa, analytics ou uso interno:

• O feedback descreve uma tarefa real? Registre o que o usuário tentava fazer, não apenas a opinião sobre a resposta.
• Há contexto suficiente para reproduzir a situação? Inclua plano, permissões, dados disponíveis, histórico relevante ou restrições que mudam a resposta esperada.
• Existe uma expectativa verificável? Troque adjetivos genéricos por um resultado observável: responder, recusar, pedir esclarecimento, preservar uma regra ou executar uma ação.
• A falha representa risco recorrente ou relevante? Priorize casos que podem se repetir, afetar decisão do usuário, gerar retrabalho ou comprometer confiança no produto.
• O verificador mede o resultado, não só a aparência da resposta? Cheque se a tarefa foi cumprida no ambiente ou se a saída respeitou o critério definido.
• O limite de aceitação protege segmentos sensíveis? Avalie se a média geral pode esconder problemas em grupos, tipos de entrada ou fluxos específicos.
• O caso orienta uma decisão concreta? Defina antes da avaliação o que acontece se o caso falhar: bloquear publicação, ajustar contexto, revisar instrução, ampliar dados de teste ou manter revisão humana.

Esse checklist não transforma todo feedback em avaliação. Ele ajuda a decidir quais relatos têm contexto, expectativa e risco suficientes para virar caso avaliável.

Como revisar o conjunto de casos antes da próxima mudança

Casos de avaliação envelhecem. O produto muda, o contexto muda, o comportamento dos usuários muda e algumas falhas deixam de representar o risco principal. Por isso, a revisão do conjunto de casos deve acontecer antes de mudanças relevantes, não apenas depois de um incidente.

A revisão pode partir de quatro perguntas:

• os casos ainda representam tarefas reais do produto atual?
• há falhas recorrentes no suporte que ainda não viraram casos?
• algum caso testa só aparência de resposta, sem verificar resultado?
• os limites de aceitação ainda protegem os segmentos onde o risco é maior?

Esse ponto se conecta ao guia sobre como transformar uma falha em hipótese de melhoria. A falha ajuda a formular uma hipótese. O caso de avaliação ajuda a impedir que a hipótese seja publicada sem proteção mínima contra regressão.

Também vale manter vínculo com o núcleo de ciclos de aprendizagem em produtos com IA, porque avaliação não é arquivo morto. É um mecanismo de aprendizagem operacional: transforma uso, erro e revisão em critérios que melhoram a próxima decisão.

Na revisão seguinte, o avanço depende de separar o feedback disponível e converter apenas os exemplos com contexto, expectativa e risco claros em casos de avaliação de IA. O time precisa definir critérios de sucesso, verificadores e limites de aceitação antes de usar esses casos para decidir uma mudança.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Como escolher métricas para um produto com IA

Fontes

• Anthropic: Demystifying evals for AI agents
• Google SRE Workbook: Monitoring
• Microsoft Research: Patterns of trustworthy experimentation during experiment stage