Avaliação de Sistemas de IA – Parte 1

Critérios de Avaliação

Antes de investir tempo, dinheiro e recursos na construção de uma aplicação, é importante entender como essa aplicação será avaliada. Chamamos essa abordagem de desenvolvimento orientado à avaliação.

Uma aplicação de IA deve começar com uma lista de critérios de avaliação específicos para ela. Em geral, você pode pensar nos critérios nos seguintes grupos: capacidade específica de domínio, capacidade de geração, capacidade de seguir instruções e custo e latência.

Capacidade Específica de Domínio

As capacidades específicas de domínio de um modelo são limitadas por sua configuração (como arquitetura e tamanho do modelo) e pelos dados de treinamento. Modelos que não possuem as capacidades exigidas pela sua aplicação não funcionarão para você. Para avaliar se um modelo possui as capacidades necessárias, você pode se basear em benchmarks específicos do domínio, sejam públicos ou privados.

Capacidades específicas de domínio são comumente avaliadas por meio de avaliação exata. Você também pode se preocupar com eficiência e custo. Se uma consulta SQL gerada pelo seu modelo de texto para SQL estiver correta, mas for muito lenta ou exigir muita memória para ser executada, ela pode não ser utilizável.

Capacidades em domínios não relacionados à programação são frequentemente avaliadas com tarefas de resposta fechada, como questões de múltipla escolha. Saídas fechadas são mais fáceis de verificar e reproduzir.

Uma pergunta de múltipla escolha pode ter uma ou mais respostas corretas. Uma métrica comum é a acurácia — quantas perguntas o modelo acertou.

Capacidade de Geração

Modelos generativos, com suas novas capacidades e casos de uso, apresentam novos problemas que requerem novas métricas. O problema mais urgente são as alucinações indesejadas. Uma métrica que muitos desenvolvedores desejam medir é a consistência factual. Outra questão comum é a segurança: as saídas geradas podem causar danos aos usuários e à sociedade?

Consistência Factual

• Consistência factual local: A saída é avaliada com base em um contexto. A saída é considerada factualmente consistente se for apoiada pelo contexto fornecido. Por exemplo, se o modelo disser “o céu é azul” e o contexto afirmar que o céu é roxo, essa saída é inconsistente.
• Consistência factual global: A saída é avaliada com base em conhecimento geral. Se o modelo disser “o céu é azul” e isso for um fato amplamente aceito, essa afirmação é considerada correta.

A consistência factual é mais fácil de verificar contra fatos explícitos. Se não houver contexto, é necessário primeiro buscar fontes confiáveis, extrair os fatos e então validar a afirmação. A parte mais difícil é muitas vezes determinar o que são os fatos.

Assumindo que você já tenha o contexto, a abordagem mais direta é usar a IA como juiz. IAs podem ser solicitadas a avaliar praticamente qualquer coisa, inclusive consistência factual.

Em vez de usar juízes genéricos, é possível treinar avaliadores especializados em consistência factual. Eles recebem pares (premissa, hipótese) e retornam classes como: implicação, contradição ou neutro.

A consistência factual é crucial em sistemas de Geração com Apoio de Recuperação (RAG). Dada uma consulta, o sistema RAG recupera informações de bases externas para complementar o modelo. A resposta gerada deve ser consistente com o contexto recuperado.

Segurança

Conteúdos inseguros geralmente pertencem a uma das categorias abaixo:

1. Linguagem imprópria.
2. Recomendações ou tutoriais perigosos (“guia passo a passo para assaltar um banco”).
3. Discurso de ódio.
4. Violência.
5. Estereótipos.
6. Vieses ideológicos, políticos ou religiosos.

É possível usar IAs generalistas para detectar esses casos, e muitos já fazem isso. Modelos como GPT, Claude e Gemini podem identificar conteúdos prejudiciais se bem orientados. Também é necessário que os provedores desenvolvam ferramentas de moderação, algumas das quais são disponibilizadas ao público.

Capacidade de Seguir Instruções

Avaliar essa capacidade significa perguntar: o modelo segue bem as instruções que você dá? Se o modelo não segue instruções corretamente, não importa o quão boas sejam, os resultados serão ruins.

É essencial para aplicações que requerem saídas estruturadas, como formatos JSON ou que sigam expressões regulares.

Critérios de seguimento de instruções

Diferentes benchmarks têm diferentes definições. Dois benchmarks citados são:

• IFEval (Instruction-Following Evaluation): avalia se o modelo segue formatos esperados.
• INFOBench: tem visão mais ampla e avalia também se o modelo segue restrições de conteúdo (ex: “fale apenas sobre mudanças climáticas”), diretrizes linguísticas (ex: “use inglês vitoriano”) e estilo (ex: “use tom respeitoso”).

Interpretação de papéis (roleplaying)

Muito comum na prática, envolve pedir que o modelo assuma um personagem ou persona:

1. Para interação com usuários (ex: jogos ou histórias).
2. Como técnica de engenharia de prompts.

Se o modelo precisa assumir um papel, verifique se ele permanece no personagem. Dependendo do papel, é possível criar heurísticas. Ex: se o personagem fala pouco, uma heurística pode ser o número médio de palavras geradas. A forma mais simples de avaliar é usar IA como juiz, analisando tanto estilo quanto conhecimento.

Custo e Latência

Um modelo que gera saídas de alta qualidade, mas é lento ou caro demais, é inutilizável. Avalie o equilíbrio entre qualidade, latência e custo.

A otimização de múltiplos objetivos é um campo ativo chamado otimização de Pareto. Você deve deixar claro quais objetivos são negociáveis e quais não são.

Seleção de Modelo

No fim das contas, o que importa não é qual modelo é o melhor, mas qual é o melhor para sua aplicação. Após definir seus critérios, avalie os modelos com base neles.

Durante o desenvolvimento, conforme você explora diferentes técnicas de adaptação, será necessário selecionar modelos várias vezes. Por exemplo, você pode começar testando com o modelo mais poderoso, e depois ver se um menor atende às necessidades.

Em geral, o processo segue dois passos:

1. Determinar o melhor desempenho alcançável.
2. Mapear os modelos considerando custo e desempenho, e escolher o que entrega mais valor.

Mas a realidade é mais complexa.

Fluxo de Seleção de Modelo

Diferencie atributos “hard” (impossíveis ou impraticáveis de mudar) de “soft” (que você pode mudar). Exemplos de atributos hard: licença, tamanho do modelo, dados de treinamento. Exemplos de atributos soft: acurácia, toxicidade, consistência factual.

O fluxo de avaliação consiste em:

1. Eliminar modelos com atributos hard incompatíveis.
2. Usar dados públicos para escolher os mais promissores.
3. Rodar experimentos com seu pipeline para escolher o melhor.
4. Monitorar em produção, detectando falhas e coletando feedback.

Construir ou Comprar um Modelo

Código aberto, pesos abertos e licenças

O termo “modelo open source” é controverso. Inicialmente, significava poder baixar e usar. Hoje, alguns argumentam que só é open source se os dados de treinamento também forem públicos.

Modelos com dados abertos permitem maior flexibilidade, como re-treinamento com alterações na arquitetura ou nos dados.

• Open weight: modelo com pesos abertos, mas sem dados abertos.
• Open model: modelo com dados abertos.

Verifique a licença do modelo:

• Permite uso comercial?
• Há restrições?
• Permite usar as saídas para treinar outro modelo?

Alguns chamam de restricted weight os modelos com código aberto, mas licença restritiva.

Modelos open source vs APIs de modelo

Para ser acessado, um modelo precisa ser hospedado e executado. O serviço de inferência recebe consultas, executa o modelo e retorna a resposta. Esse serviço é acessado via API.

Modelos podem ser disponibilizados via código aberto, via API, ou ambos. Modelos comerciais geralmente estão disponíveis apenas via API licenciada. Modelos open source podem ser usados em qualquer API.

A decisão de hospedar você mesmo ou usar uma API depende do caso de uso. E isso pode mudar com o tempo. Considere sete fatores: privacidade de dados, rastreabilidade dos dados, desempenho, funcionalidades, custo, controle e possibilidade de uso no dispositivo.

Privacidade de Dados

APIs de modelos hospedados externamente não são uma opção para empresas com políticas rígidas de privacidade que proíbem o envio de dados para fora da organização. Ao usar uma API de modelo, há o risco de o provedor utilizar seus dados para treinar seus modelos. Embora a maioria afirme que não faz isso, suas políticas podem mudar.

Rastreabilidade e Direitos Autorais dos Dados

Preocupações com rastreabilidade e direitos autorais podem levar empresas a diferentes direções: modelos open source, modelos proprietários ou nenhum dos dois. A maioria dos modelos não divulga seus dados de treinamento. Por isso, algumas empresas preferem modelos totalmente abertos, com dados públicos e auditáveis.

Desempenho

Diversos benchmarks mostram que a diferença entre modelos open source e proprietários (mais rápidos) está diminuindo.

Funcionalidade

Muitas funcionalidades são necessárias para que um modelo funcione bem em determinado caso de uso. Exemplos:

• Escalabilidade: garantir que o serviço de inferência suporte o tráfego da aplicação, mantendo latência e custo aceitáveis.
• Chamada de funções: permitir que o modelo utilize ferramentas externas — essencial para RAG e agentes.
• Saídas estruturadas: como gerar saídas em JSON.
• Controles de saída (guardrails): evitar respostas ofensivas ou inadequadas.

Essas funcionalidades são difíceis e demoradas de implementar. Por isso, muitas empresas preferem usar APIs que já as oferecem. O lado negativo é a limitação às funcionalidades fornecidas. E a adaptação (fine-tuning) só é possível se o provedor permitir.

Custo da API versus Custo de Engenharia

APIs cobram por uso e podem se tornar muito caras em aplicações de alto volume. Por outro lado, hospedar um modelo exige tempo, equipe especializada e esforço de engenharia.

Modelos proprietários geralmente são mais fáceis de começar e escalar, enquanto modelos open source são mais fáceis de adaptar. Em ambos os casos, é desejável que a API siga um padrão comum, o que facilita a troca de modelos.

Controle, Acesso e Transparência

Se sua empresa depende de um modelo, é natural querer controle sobre ele — algo que APIs comerciais nem sempre oferecem.

Para proteger usuários e evitar ações judiciais, os provedores de modelos aplicam filtros de segurança, como bloquear piadas racistas ou imagens de pessoas reais. Modelos comerciais tendem a ser mais restritivos, o que pode limitar usos específicos.

Outro risco é perder o acesso ao modelo. Modelos comerciais não podem ser “congelados” como os open source. Mudanças nos modelos são frequentes, nem sempre comunicadas, e podem quebrar prompts sem aviso.

Execução no Dispositivo

Se você quiser rodar o modelo localmente (on-device), APIs de terceiros estão fora de questão.

A seguir, você pode refinar sua seleção utilizando dados públicos de desempenho dos modelos. Este será o conteúdo de nosso próximo artigo. Até lá!

Referências

Huyen, Chip. AI Engineering: Building Applications with Foundation Models