Avaliar uma feature de IA significa definir qualidade para uma tarefa concreta, montar casos comuns, ambíguos e críticos, combinar avaliação automática com revisão humana calibrada e transformar falhas reais em novos testes. O objetivo não é provar que a IA funciona. É descobrir quando ela ajuda, quando falha e qual controle protege a pessoa e o negócio.
A apresentação começa com três exemplos. O sistema resume um documento, escreve uma resposta elegante e encontra uma informação em segundos. A sala vê velocidade. O que ninguém vê é o caso em que a fonte estava incompleta, a instrução tinha duas interpretações ou a resposta plausível inventou um detalhe.
Esse é o problema dos testes felizes: eles mostram possibilidade, não confiabilidade. Um produto não opera com o exemplo escolhido pelo time. Ele recebe linguagem imperfeita, dados desatualizados, demandas raras, pressão de tempo e pessoas que entendem o resultado de maneiras diferentes.
A tese deste artigo é simples: qualidade em IA é um ciclo de especificar, medir e melhorar, não uma demonstração convincente. Esse ciclo traduz tecnologia para o vocabulário que sustenta uma decisão de produto: tarefa concluída, experiência compreensível, risco controlado, custo viável e resultado observável.
Antes da métrica, defina a tarefa
“Responder bem” não é um requisito. Uma feature que auxilia atendimento pode precisar identificar a intenção, recuperar a política correta, redigir uma resposta útil e sinalizar quando deve escalar. Cada etapa tem um usuário, uma decisão e um tipo de falha.
A documentação pública da OpenAI sobre avaliações organiza o trabalho em três movimentos: especificar, medir e melhorar. A contribuição mais importante para líderes é contextual. Avaliações gerais de um modelo não revelam, sozinhas, se ele atende ao fluxo, aos dados e aos riscos da sua organização.
Comece escrevendo uma frase operacional: “Dado um ticket de entrega, localizar a política vigente, preparar uma resposta que explique o próximo passo e escalar quando faltar evidência”. A partir dela, pergunte:
- qual resultado o usuário precisa alcançar;
- quais fontes podem sustentar a saída;
- o que a feature pode fazer e o que deve recusar;
- que erro causa apenas incômodo e qual causa dano;
- quem revisa exceções e quem decide o lançamento.
Sem essa especificação, a equipe mede estilo, fluidez ou preferência pessoal. Com ela, consegue observar se o sistema cumpriu a tarefa e preservou o limite.
Cinco dimensões de qualidade
Uma única nota confunde dimensões que exigem decisões diferentes. Para uma primeira rubrica, use correção, utilidade, segurança, velocidade e custo. Os pesos mudam conforme o contexto.
Correção pergunta se afirmações, cálculos e referências estão consistentes com a fonte. Utilidade observa se a saída ajuda a concluir a tarefa, em linguagem adequada e no nível certo de detalhe. Segurança cobre conteúdo proibido, exposição de dados, ação indevida e tratamento de incerteza. Velocidade mede o tempo percebido até uma resposta acionável. Custo inclui processamento, revisão, integração e retrabalho.
O perfil de IA generativa do NIST destaca riscos como confabulação, privacidade, segurança da informação e viés prejudicial. A recomendação prática não é transformar a lista em um checklist universal. É mapear quais riscos aparecem no caso de uso e qual evidência mostrará que foram reduzidos.
| Critério | Peso | Pergunta observável | Limite mínimo |
|---|---|---|---|
| Correção | 30% | Fatos e cálculos conferem com a fonte? | Nenhum erro factual crítico |
| Utilidade | 25% | A pessoa conclui a tarefa sem reconstruir a resposta? | Nota 3 de 4 |
| Segurança | 25% | O sistema respeita dados, escopo e escalada? | Zero violação crítica |
| Velocidade | 10% | O retorno chega dentro do tempo útil? | Percentil acordado |
| Custo total | 10% | Processamento e revisão cabem no caso econômico? | Teto por tarefa |
O exemplo usa números apenas para tornar a conversa explícita. Uma feature médica ou financeira pode exigir peso e piso muito maiores para segurança. Um recurso criativo e reversível pode tolerar variação de estilo. Nenhuma média deve compensar uma falha que ultrapassa um limite crítico.
Construa casos que representem o mundo
O conjunto de avaliação precisa conter situações comuns, ambíguas e críticas. Casos comuns mostram desempenho na rotina. Ambíguos revelam se o sistema pede contexto ou inventa uma interpretação. Críticos testam a fronteira em que a saída precisa recusar, escalar ou citar evidência.
O capítulo de dados e avaliação do Google PAIR recomenda aproximar os dados de teste das condições reais e documentar origem, transformação e limitações. Entradas limpas demais criam confiança em um ambiente que o produto nunca encontrará.
ID: identificador estável.
Entrada: pedido e contexto disponíveis.
Tipo: comum, ambíguo ou crítico.
Resultado esperado: comportamento aceitável, não uma frase única.
Fontes permitidas: evidências que podem sustentar a resposta.
Risco: consequência do erro.
Critérios: itens da rubrica aplicáveis.
Resultado observado: nota, justificativa e evidência.
Decisão: aprovado, revisar ou bloquear.
Casos reais precisam ser anonimizados e usados em ambiente autorizado. O conjunto de avaliação não deve se tornar uma cópia invisível de informações pessoais, contratos ou conversas confidenciais.
Avaliação automática precisa de calibração humana
Um modelo pode aplicar uma rubrica em grande volume, identificar saídas suspeitas e justificar notas. Isso reduz o trabalho de triagem. Não elimina a necessidade de especialistas.
Monte primeiro uma amostra avaliada por duas ou mais pessoas que conheçam a tarefa. Discuta divergências até que os critérios fiquem específicos. Depois compare o avaliador automático com esse padrão. Onde ele discorda? Confunde concisão com falta de conteúdo? Premia tom seguro mesmo quando falta fonte?
Uma boa operação usa camadas. Regras determinísticas conferem formato, presença de citação e limites objetivos. Um avaliador automático classifica dimensões interpretativas. Pessoas revisam amostras, casos de baixa confiança, alto impacto e desacordo.
Em classificação, precisão, a proporção das classificações positivas que estavam corretas, e revocação, a proporção dos casos positivos reais que o sistema conseguiu encontrar, mudam de importância conforme o custo de falso positivo e falso negativo. A documentação do Google alerta que a acurácia isolada pode enganar em conjuntos desequilibrados. A tradução para produto é direta: escolha métricas pelo erro que precisa evitar.
Quando o sistema também executa ações, a avaliação precisa conversar com a arquitetura de controle humano em agentes de IA. Uma saída aprovada não autoriza, por si só, qualquer ação, permissão ou destino.
Uma taxonomia transforma falha em decisão
“Resposta ruim” não informa o que mudar. Classifique erros por mecanismo e consequência. Uma taxonomia inicial pode incluir: fato sem suporte, fonte inadequada, instrução ignorada, ambiguidade não reconhecida, omissão importante, exposição de dado, tom impróprio, ação fora do escopo e falha de recuperação.
Para cada categoria, registre severidade, frequência, detectabilidade e responsável. Um erro frequente, mas facilmente percebido, pede uma resposta diferente de um erro raro, invisível e de alto impacto.
1. Execute a versão candidata sobre o conjunto de casos.
2. Aplique verificações determinísticas e a rubrica automática.
3. Encaminhe falhas críticas, incerteza e uma amostra aleatória para especialistas.
4. Compare notas e investigue divergências.
5. Classifique a causa e defina a intervenção.
6. Adicione o erro ao conjunto de regressão, a coleção fixa de casos que uma mudança futura não pode voltar a quebrar.
7. Repita antes de liberar a mudança.
A intervenção pode ser corrigir dados, restringir ferramenta, mudar prompt, alterar interface, acrescentar aprovação ou remover a automação daquela etapa. Nem todo problema se resolve trocando o modelo.
Meça o produto, não apenas a saída
Uma resposta tecnicamente boa pode chegar tarde demais. Pode exigir tanta conferência que o fluxo fica mais caro. Pode também reduzir esforço interno e aumentar a dúvida do cliente.
Conecte quatro camadas: qualidade da saída, experiência, operação e negócio. Na experiência, observe sucesso da tarefa, edição necessária, compreensão, confiança calibrada e abandono. Na operação, acompanhe tempo total, taxa de escalada, retrabalho e incidentes. No negócio, relacione custo, retenção, conversão ou receita somente quando houver um mecanismo plausível.
Latência deve refletir a jornada. Tempo até o primeiro token é diferente de tempo até uma resposta utilizável. Custo por chamada é diferente de custo por tarefa concluída. O denominador correto impede economias aparentes.
Depois do lançamento, a avaliação começa de novo
Dados, modelos, instruções e comportamento das pessoas mudam. O conjunto que sustentou o lançamento envelhece. O AI Risk Management Framework do NIST trata governança, mapeamento, medição e gestão como funções contínuas.
Defina uma rotina: monitorar métricas, revisar amostras, investigar reclamações, incorporar novos casos e reavaliar após mudanças relevantes. Preserve versão do modelo, prompt, fontes e rubrica para reconstruir uma decisão.
Uma queda pode vir de drift, mudança na distribuição das entradas. Também pode vir de uma nova campanha, política ou hábito do usuário. Monitorar sem contexto gera alerta. Monitorar com responsáveis produz ação.
Um primeiro ciclo de avaliação em duas semanas
Na primeira semana, escolha uma tarefa frequente e delimite o resultado. Reúna produto, tecnologia, UX e duas pessoas que dominem o trabalho. Selecione casos já resolvidos, remova dados desnecessários e escreva a rubrica. Avalie manualmente uma amostra para revelar divergências entre especialistas antes de automatizar qualquer nota.
Na segunda semana, execute a versão atual da feature, classifique os erros e compare qualidade, tempo e esforço de revisão com a linha de base. Não altere prompt, modelo e dados ao mesmo tempo, porque a equipe perderá a capacidade de explicar a mudança. Escolha a intervenção mais plausível, repita os casos e documente a decisão.
O resultado desse ciclo não precisa ser um lançamento. Pode ser a descoberta de que o problema está na fonte, que uma etapa exige revisão ou que o caso econômico não fecha. Essa também é uma boa decisão. Avaliação reduz a distância entre entusiasmo e evidência.
Antes de encerrar, registre quem manterá o conjunto, com que frequência as amostras de produção serão revistas e qual evento obriga uma nova avaliação. Sem dono e agenda, a planilha vira memória do piloto. Com rotina, vira infraestrutura de qualidade. O artigo sobre liderança de times na era da IA mostra como incorporar esse ciclo à divisão de trabalho, à revisão e à responsabilidade cotidiana.
Perguntas frequentes
O que é uma avaliação de uma feature de IA?
É um processo contínuo que transforma a expectativa do produto em critérios observáveis, testa casos representativos e usa erros reais para melhorar o sistema.
Uma nota média alta é suficiente para lançar?
Não. A média pode esconder falhas críticas. O lançamento depende também de limites mínimos por critério, análise de erros, revisão humana e plano de monitoramento.
A IA pode avaliar a própria saída?
Pode apoiar a triagem quando usa uma rubrica explícita, mas precisa ser calibrada contra julgamentos humanos e não deve ser a única evidência.
Quantos casos de teste são necessários?
Não existe número universal. Comece com variedade suficiente para cobrir situações comuns, ambíguas e críticas, e amplie o conjunto sempre que surgir um erro relevante.
Quais métricas devem acompanhar a qualidade?
Combine correção, utilidade e segurança com sucesso da tarefa, retrabalho, latência, custo, reclamações e impacto no resultado de negócio.
Qualidade é uma capacidade do time
A demo do início ainda tem valor. Ela abre uma possibilidade. O erro é tratá-la como evidência suficiente para escalar.
Uma equipe madura escreve o que espera, procura deliberadamente onde o sistema falha e transforma descoberta em um teste permanente. Produto define valor. UX observa compreensão e controle. Tecnologia mede comportamento. Operação revela exceções. Risco estabelece limites. Juntos, criam uma feature que pode melhorar sem pedir confiança cega.
A AIUX Brasil ajuda times a transformar intenção em critérios, desenhar avaliações contextuais e conectar qualidade a experiência, custo, risco e receita. O primeiro passo pode ser pequeno: escolha uma tarefa real, reúna os casos que mais ensinam e defina qual erro você não aceita esconder.