Seu modelo mental para testes de IA

O que fica, o que sai: como aplicar seu conhecimento de testes da Web ao novo mundo dos LLMs.

Maud Nalpas

Exemplo de aplicativo

O ThemeBuilder é o exemplo de aplicativo usado nesta série. Ele gera um objeto JSON que contém um lema gerado por LLM e uma paleta de cores.

• O lema e a paleta precisam corresponder ao nome, à descrição, ao público-alvo e ao tom da marca de entrada.
• O lema não pode ser tóxico e precisa ser curto (menos de seis palavras).
• O contraste da paleta de cores precisa ser acessível, conforme definido pelas diretrizes mínimas da WCAG, com uma taxa de contraste de 4,5:1.

Avaliações objetivas e subjetivas

Como você testa se o ThemeBuilder funciona conforme o esperado?

As avaliações baseadas em regras (às vezes chamadas de avaliações exatas) são testes objetivos com uma resposta binária de correta ou incorreta. Elas são mais adequadas para perguntas sobre formato de dados, taxa de contraste ou outras com uma resposta definitiva. É possível implementar esses testes com código programático normal.

Algumas verificações são objetivas, com uma resposta binária de correta ou incorreta. Elas são mais adequadas para perguntas sobre formato de dados, taxa de contraste ou outras com uma resposta definitiva. É possível implementar esses testes com código programático normal. Eles são chamados de avaliações baseadas em regras ou avaliações exatas.

Exemplo:

// Example rule-based eval: data format
function evaluateFormat(appOutput) {
  // Check if JSON is valid, colors are hex, no empty strings, motto is 6 words or fewer
  // Use deterministic tools like zod for schema validation
  return "PASS"; // or "FAIL"
}

Outras verificações são subjetivas, como o alinhamento da marca e do público-alvo para o lema e a paleta de cores. Embora a detecção de toxicidade seja uma tarefa de classificação, ela também é subjetiva porque envolve julgamento.

Embora os testes subjetivos também envolvam classificação, o intervalo do que é correto e incorreto pode variar muito. Por exemplo, avaliar o alinhamento da marca e do público-alvo para o lema e a paleta de cores. A detecção de toxicidade também é subjetiva.

Embora a avaliação de qualidades subjetivas possa parecer algo que apenas um especialista humano pode fazer, é possível automatizar esses testes em escala com a técnica LLM-as-a-judge.

[Os juízes de LLM] são rápidos, fáceis de usar e relativamente baratos [...] Eles se tornaram um dos métodos mais comuns, se não o mais comum, para avaliar modelos de IA em produção.

— Engenharia de IA, Chip Huyen

Exemplo:

// Example LLM-as-a-judge eval for a subjective quality like brand fit
async function evalBrandFit(userInput, appOutput) {
  const brandPrompt = `You are an expert brand strategist. Evaluate the
  following generated motto for the company whose target audience is
  ${userInput.audience}, and who describes itself as
  ${userInput.companyDescription}: ${appOutput.motto}`
  // Call the LLM judge
  const evalResult = evalWithLLM(brandPrompt);
  // Return the consolidated results
  return {
    mottoBrandFit: evalResult,
  };
}

// Helper that communicates with the LLM API
async function evalWithLLM(prompt) {
  // ... Call LLM with the prompt ...
  // ... Parse the resulting judgement ("PASS" or "FAIL") + rationale
  return {
    status: "PASS",
    rationale: "This motto perfectly captures the brand and tone, because..."
  };
}

O modelo imita o julgamento humano. Portanto, você precisa de uma maneira de dizer ao juiz exatamente o que está procurando. Para isso, ofereça uma rubrica ao juiz.

Uma rubrica é um conjunto estruturado de critérios ou diretrizes de pontuação que um juiz (humano ou de IA) usa para avaliar uma saída. Ela fornece uma estrutura consistente para avaliar qualidades subjetivas em todas as avaliações.

Outros tipos de avaliações

Talvez você queira usar avaliações baseadas em referência ou em pares.

Baseadas em referência

Elas medem a semelhança com uma resposta de informação empírica. Use-as para tarefas como tradução ou fatos técnicos em que uma boa resposta conhecida exista.

Por par

Um juiz pode dar uma pontuação PASS a duas versões diferentes, mesmo quando uma é melhor que a outra. A avaliação por par resolve isso, oferecendo ao juiz duas saídas (A e B) para a mesma entrada e instruindo o juiz a escolher um vencedor.

Por exemplo, imagine que você está avaliando um lema para um café amigável:

Input: "Friendly cafe"

Pointwise evaluation:
Output A: "Come get coffee." // PASS
Output B: "Your morning smile in a cup." // PASS
2 PASS. Unconclusive!

Pairwise evaluation:
Output B wins. It captures the "friendly" tone more effectively than the generic Output A.

Use a avaliação por par para selecionar qual versão do modelo você vai implantar ou para comparar dois comandos diferentes.

Testes da Web padrão x avaliações de IA

Presumimos que você, leitor deste curso, já sabe como testar um site e um aplicativo da Web. Ao adicionar a IA, é necessário mudar seu modelo mental atual. Use a avaliação de IA para realizar as seguintes ações:

• Realizar testes de regressão: quando você muda o comando ou o modelo, o aplicativo é interrompido? Você está recebendo paletas de cores quebradas ou lemas tóxicos? Ao contrário de um app da Web em que uma interrupção é uma funcionalidade de software, aqui você está verificando se a saída do LLM é de alta qualidade e segura. Isso envolve subjetividade.
• Otimizar o aplicativo: o aplicativo está melhorando? Você está melhorando as métricas desejadas? Por exemplo, você está recebendo mais lemas da marca sem aumentar a toxicidade?
• Escolher o modelo certo: existe um modelo melhor para seu caso de uso? Antes da IA, você escolhe sua pilha da Web uma vez. Com a IA, é recomendável fazer um benchmark dos modelos regularmente para identificar oportunidades de mudar para um modelo melhor (e potencialmente mais barato).

Camadas de testes

Um código-fonte saudável precisa ter várias camadas de testes: testes de unidade, testes de regressão e integração e testes de ponta a ponta. As avaliações também precisam ser em camadas.

• Use avaliações baseadas em regras combinadas com avaliações de LLM-as-a-judge para automatizar totalmente os testes do aplicativo de IA. Dessa forma, é possível detectar problemas no desenvolvimento diário e na CI/CD, além de testar se os candidatos a lançamento atendem à sua barra de qualidade.
• Execute testes de integração e regressão para verificar a qualidade em escala.
• Execute avaliações humanas manuais como um teste de aceitação.

Além dessas avaliações executadas no tempo de build, monitore o tráfego de produção com avaliações de tempo de execução. Elas podem ajudar a identificar problemas de qualidade ou segurança em entradas reais.

Continue evoluindo suas avaliações

As avaliações precisam crescer junto com o aplicativo. À medida que os modelos ficam mais inteligentes, atualize as avaliações antigas.

Adicione exemplos complicados aos conjuntos de dados de teste regularmente, como novos casos extremos ou entradas de usuários surpreendentes encontradas na produção.

O que suas avaliações medem?

Antes de criar avaliações, é necessário entender como avaliar uma saída. Há alguns termos que você precisa conhecer.

Os critérios são as regras, as dimensões que precisam ser testadas. Por exemplo, alinhamento da marca, toxicidade e acessibilidade.

Cada critério de avaliação é medido por uma métrica. Uma métrica é uma pontuação única e concreta que mede a saída do modelo em relação ao critério. Essa pontuação pode ser binária ou um valor dentro de um intervalo que mede a distância ou a proximidade da saída à expectativa do avaliador.

É possível medir o mesmo critério com diferentes tipos de métricas. Por exemplo, para o alinhamento da marca:

• "Esse lema está alinhado à marca?" A métrica é PASS ou FAIL.
• "Em uma escala de 1 a 5, quão bem o lema se alinha à marca?" A métrica é um número inteiro entre um e cinco.

Um avaliador é o código ou modelo que pontua o critério. Os avaliadores determinam as métricas.