Critérios de avaliação: sua IA realmente ajuda o negócio?

Infelizmente, é comum ver aplicações de IA com retorno sobre o investimento duvidoso. Parte disso é porque avaliar IA é difícil, e parte é porque quem desenvolve não tem visibilidade de como a aplicação está sendo usada.

Pense em um time que criou um modelo para estimar o preço de carros usados a partir das informações do dono. Um ano depois, os usuários parecem gostar do recurso, mas ninguém sabe dizer se as estimativas estão corretas. Ou nas empresas que, no começo da febre do ChatGPT, correram para colocar chatbots no suporte ao cliente e até hoje não sabem se eles ajudam ou atrapalham a experiência.

Moda à parte, decisões de negócio ainda são tomadas olhando o retorno. A aplicação precisa mostrar valor para continuar no ar. Por isso, as aplicações de IA mais comuns em produção são justamente as que têm critérios de avaliação claros:

• Sistemas de recomendação: o sucesso aparece no aumento de engajamento ou de compras.
• Detecção de fraude: dá para medir o dinheiro economizado com as fraudes evitadas.
• Geração de código: diferente de outros tipos de geração, código pode ser avaliado pela correção funcional. Roda ou não roda, passa nos testes ou não passa.

Desenvolvimento orientado por avaliação

Antes de investir tempo e dinheiro em uma aplicação, entenda como ela vai ser avaliada. A ideia lembra o desenvolvimento orientado por testes (TDD), em que você escreve os testes antes do código. Na engenharia de IA, o equivalente é definir os critérios de avaliação antes de construir.

A avaliação é, provavelmente, o maior gargalo para a adoção de IA. Quem consegue montar pipelines de avaliação confiáveis destrava muitas aplicações novas.

Os critérios podem ser organizados em quatro grupos.

Capacidade específica de domínio

Para criar um agente que escreve código, você precisa de um modelo que saiba programar. Para traduzir latim para inglês, precisa de um modelo que entenda os dois idiomas. Essas são capacidades específicas de domínio.

Elas dependem da configuração do modelo (arquitetura, tamanho) e, principalmente, dos dados de treinamento. Se o modelo nunca viu latim no treinamento, ele não vai entender latim. Simples assim. Um modelo sem a capacidade que sua aplicação exige não serve, por melhor que seja em outras coisas.

Para verificar isso, existem benchmarks públicos e privados para quase tudo: geração e depuração de código, matemática, conhecimento científico, senso comum, raciocínio, conhecimento jurídico, uso de ferramentas, jogos e por aí vai.

Capacidade de geração

Modelos generativos trouxeram problemas novos, e com eles métricas novas. O mais urgente é a alucinação. Em tarefas criativas ela até é bem-vinda, mas em tarefas que dependem de fatos é um problema sério.

Por isso, uma das métricas mais acompanhadas é a consistência factual. Outra é a segurança: o que foi gerado pode causar dano ao usuário ou à sociedade? Segurança aqui é um termo guarda-chuva para toxicidade e vieses de todo tipo. Como uma informação errada também pode causar dano, a inconsistência factual acaba entrando nesse guarda-chuva.

Consistência factual local e global

Dá para verificar a consistência factual de duas formas:

• Local: a resposta é comparada com um contexto fornecido. Se o contexto diz que o céu é roxo e o modelo responde "o céu é roxo", a resposta é consistente. Se responde "o céu é azul", é inconsistente, mesmo que no mundo real seja azul.
• Global: a resposta é comparada com o conhecimento geral. "O céu é azul" é considerado correto porque é um fato amplamente aceito. Isso importa para aplicações abertas, como chatbots gerais, checagem de fatos e pesquisa de mercado.

Verificar contra fatos explícitos é bem mais fácil. Se não há contexto, primeiro você precisa encontrar fontes confiáveis, extrair os fatos e só então validar a afirmação.

A parte mais difícil, na verdade, é decidir o que é fato. "Messi é o melhor jogador do mundo", "a mudança climática é uma das crises mais urgentes do nosso tempo", "o café da manhã é a refeição mais importante do dia": se isso é fato ou não depende das fontes em que você confia. E a internet está cheia de desinformação, estatística inventada e conteúdo sensacionalista.

Ao criar métricas de alucinação, analise as respostas do modelo para entender quais tipos de pergunta têm mais chance de gerar alucinação. O seu benchmark deve focar nelas.

Capacidade de seguir instruções

Aqui a pergunta é: o modelo faz o que você pediu? Se ele é ruim em seguir instruções, não importa o quão bom seja o seu prompt, o resultado vai ser ruim.

Um exemplo: você pede para o modelo classificar o sentimento de um tweet como NEGATIVO, POSITIVO ou NEUTRO. Ele parece entender o sentimento, mas responde FELIZ ou BRAVO. Ou seja, ele tem a capacidade de domínio (entende sentimento), mas falha em seguir a instrução de formato.

Existem estudos que listam dezenas de tipos de instrução que podem ser verificados automaticamente. Alguns exemplos:

Outra forma de avaliar é transformar cada instrução em uma lista de perguntas de sim ou não. Para a instrução "crie um questionário para ajudar hóspedes a avaliar o hotel", as perguntas seriam:

• O texto gerado é um questionário?
• O questionário é voltado para hóspedes de hotel?
• Ele ajuda o hóspede a escrever uma avaliação do hotel?

O modelo só segue a instrução se todas as respostas forem sim. Cada pergunta pode ser respondida por uma pessoa ou por uma IA como juiz.

Se a sua aplicação pede para a IA assumir um papel, avalie também se ela se mantém no personagem. Às vezes dá para criar uma heurística simples: se o personagem fala pouco, meça o tamanho médio das respostas. Fora isso, o caminho mais fácil é, de novo, a IA como juiz.

Custo e latência

Um modelo que gera respostas excelentes, mas é lento e caro demais, não serve. Avaliar um modelo é equilibrar qualidade, latência e custo, e muitas empresas escolhem um modelo um pouco pior quando ele é mais rápido e barato.

Otimizar vários objetivos ao mesmo tempo é um campo de estudo próprio, a otimização de Pareto. O segredo é ter clareza do que é negociável e do que não é. Se latência não é negociável, você começa filtrando os modelos que não atendem ao limite de latência e escolhe o melhor entre os que sobraram.

Métricas de latência

Existem várias, e vale saber quais importam para você:

• tempo até o primeiro token;
• tempo por token;
• tempo entre tokens;
• tempo total por consulta.

A latência não depende só do modelo, mas também do prompt e das variáveis de amostragem. Como modelos autorregressivos geram um token por vez, quanto mais tokens na resposta, maior a latência. Dá para controlar isso pedindo respostas concisas, definindo uma condição de parada ou usando outras técnicas de otimização.

Com os critérios definidos, o próximo passo é usá-los para escolher o modelo certo para a sua aplicação.

Referência

Este artigo faz parte dos meus estudos sobre engenharia de IA, baseados no livro AI Engineering: Building Applications with Foundation Models, de Chip Huyen (O'Reilly, 2025).