Abordagens para avaliar modelos de fundação

Você passou o tópico anterior fazendo ajuste fino em um modelo. Ele responde bem aos seus prompts de teste, a demo foi tranquila e o time quer subir para produção. Então alguém faz a única pergunta que importa: ele é de fato melhor que o modelo base de onde você partiu, e melhor por quanto?

"Pareceu bom quando eu testei" não é resposta. Dez prompts digitados pela pessoa que construiu a coisa são a evidência mais fraca que existe em software. Este tópico é sobre substituir isso por algo defensável, e começa aqui, nas três famílias de evidência que você pode coletar e no quanto cada uma vale.

Por que um modelo generativo é difícil de corrigir

Um classificador é fácil de corrigir. Passe 1.000 e-mails rotulados, conte quantos ele arquivou como spam corretamente, e você tem accuracy. Cada entrada tem exatamente uma resposta certa, então a correção é aritmética.

Um modelo de fundação quebra isso. Peça um resumo de um relatório de incidente e existem centenas de bons resumos e nenhum único correto. Dois resumos podem não compartilhar quase nenhuma palavra e os dois serem excelentes. Não há nada com que comparar por igualdade, e cada abordagem abaixo é uma forma diferente de contornar esse mesmo problema.

Guarde esse enquadramento, porque ele explica todo o desenho das ferramentas. A avaliação automática contorna comparando com uma resposta de referência e medindo semelhança em vez de igualdade. Um modelo juiz contorna lendo a saída e dando nota. A avaliação humana contorna perguntando para pessoas. Três respostas para a mesma pergunta incômoda.

A analogia da correção de redações, e onde ela quebra

Pense na correção de redações. Um gabarito que conta palavras-chave obrigatórias é rápido, consistente e cego para uma redação bem argumentada que usou outras palavras. Um monitor com uma rubrica lê buscando sentido e dá conta de cem provas. O examinador titular é a autoridade de verdade, mas só consegue ler algumas.

Métricas automáticas são o gabarito de palavras-chave, um modelo juiz é o monitor, e revisores humanos são o examinador. A analogia quebra em um ponto que vale lembrar: um monitor que estudou pelo mesmo livro do aluno tem os mesmos pontos cegos do aluno. Um modelo juiz sofre do mesmo problema, e é por isso que ninguém trata nota de juiz como ground truth.

Abordagem 1: avaliação automática contra um dataset

A avaliação automática, que o Bedrock também chama de avaliação programática, roda seu modelo sobre um conjunto de prompts e calcula notas sem humano no circuito. Você escolhe três coisas ao criar o job: um task type, as métricas que quer e o dataset de prompts.

O task type diz ao Bedrock que tipo de trabalho o modelo está fazendo, o que define o que pode ser medido. O Bedrock oferece general text generation, text summarization, question and answer e text classification, além de uma opção custom.

As métricas caem em três grupos que reaparecem por todo este tópico:

• Accuracy é quão perto a saída está de uma resposta de referência.
• Robustness é quanto a qualidade cai quando a entrada é perturbada sem mudar o sentido, como erros de digitação, mudanças aleatórias de caixa e espaços adicionados ou removidos.
• Toxicity é se a saída contém linguagem nociva, pontuada por um modelo de detecção de toxicidade e não por comparação com uma referência.

Accuracy e robustness precisam saber qual é a resposta certa. Toxicity não, porque ela julga a saída por si mesma.

Datasets prontos, e o seu próprio

O Bedrock traz datasets de prompts prontos para você rodar um job antes de ter escrito qualquer dado de teste. Cada um é uma amostra aleatória de 100 prompts de um dataset open source conhecido, e cada um vem pareado com o task type e a métrica que lhe servem.

Eles servem para uma primeira passada e para checagens de sanidade, e não são a sua aplicação. Um assistente de suporte que responde perguntas sobre o seu produto não vai ser decidido pelo BoolQ. É para isso que existe o dataset de prompts customizado.

Um dataset customizado é um arquivo JSONL no Amazon S3, até 1.000 prompts por job, um objeto JSON por linha:

{"prompt": "Aurillac is the capital of", "referenceResponse": "Cantal", "category": "Capitals"}
{"prompt": "Bamiyan city is the capital of", "referenceResponse": "Bamiyan Province", "category": "Capitals"}
{"prompt": "Sokhumi is the capital of", "referenceResponse": "Abkhazia", "category": "Capitals"}

prompt é a entrada que o modelo recebe. referenceResponse é o ground truth, e é obrigatório para accuracy e robustness porque essas métricas não têm nada com que comparar sem ele. category é opcional e te dá notas separadas por grupo, que é como você descobre que um modelo vai bem em perguntas de cobrança e mal em reembolsos.

O esforço de escrever 200 prompts reais com respostas reais é a coisa de maior valor que um time faz antes de lançar, e é justamente o passo que se pula.

Datasets de benchmark, e a armadilha do leaderboard

Benchmarks públicos são datasets compartilhados que permitem comparar modelos nas mesmas perguntas. Alguns nomes aparecem sem parar:

• GLUE e SuperGLUE reúnem tarefas de compreensão de linguagem, como inferência e similaridade de sentenças.
• MMLU, Massive Multitask Language Understanding, é um teste de múltipla escolha que cobre 57 assuntos, de matemática elementar a história dos Estados Unidos, ciência da computação e direito, desenhado para sondar conhecimento amplo de mundo e resolução de problemas.
• HELM, Holistic Evaluation of Language Models, pontua modelos em 42 cenários com 7 métricas: accuracy, calibração, robustness, justiça, viés, toxicidade e eficiência. O argumento dele é que accuracy sozinha é uma descrição magra de um modelo.

Agora o equívoco, e ele é o caro. É tentador ler um leaderboard como um ranking de qual modelo é melhor para você. Não é. Um benchmark mede desempenho nos dados e no mix de tarefas daquele benchmark, e a sua aplicação não tem nenhum dos dois. Um modelo que lidera o MMLU pode ser mediano em resumir os seus relatórios de incidente no formato que os seus engenheiros de plantão precisam. Benchmarks populares também vazam para os dados de treinamento com o tempo, o que infla notas sem melhorar o modelo.

A regra de trabalho: benchmarks montam a sua lista curta, o seu próprio dataset de prompts escolhe o vencedor. O HELM ajuda aqui como corretivo, porque força a comparação em várias dimensões em vez de um número só.

Abordagem 2: um LLM como juiz

A avaliação baseada em juiz usa um segundo modelo para pontuar o primeiro. O job precisa de dois modelos em dois papéis. O generator model responde aos prompts do seu dataset. O evaluator model lê cada par de prompt e resposta, atribui uma nota e escreve uma explicação de por que pontuou daquele jeito.

O Bedrock oferece métricas prontas para você selecionar, e você pode definir métricas customizadas para os seus próprios critérios. As prontas cobrem mais terreno do que qualquer nota de semelhança consegue:

Duas coisas deixam essa abordagem atraente. A maioria dessas métricas não precisa de resposta de referência, então você consegue avaliar trabalho aberto em que não existe ground truth. E ela roda em velocidade e custo de máquina, então você pontua 500 respostas no tempo que um painel humano precisa para 20.

Você também pode fornecer uma resposta de referência, e o evaluator vai levá-la em conta ao pontuar correctness e completeness. E se você estiver avaliando um modelo fora do Bedrock, pode entregar suas próprias respostas de inferência: o Bedrock pula o passo de invocar e pontua os dados que você trouxe.

O limite é o mesmo da analogia: o juiz é um modelo de fundação. Ele tem preferências de fraseado e de tamanho, e pode errar com confiança. Notas de juiz são evidência forte, não veredito, e times que dependem delas conferem uma amostra à mão.

Abordagem 3: avaliação humana

A avaliação humana coloca pessoas no circuito. No Bedrock você cria um time de trabalho, que pode ser formado pelos seus próprios funcionários ou por especialistas do seu setor, gerenciado por um user pool do Amazon Cognito criado a partir do console. Um job humano pode dar nota a um modelo ou comparar respostas de dois.

O mecanismo de avaliação decide o que você aprende:

Os mecanismos de comparação respondem "qual modelo as pessoas preferem", e os individuais respondem "este modelo é bom o suficiente". Os dois dependem das instruções que você escreve. Uma escala de 5 pontos sem âncoras definidas produz cinco revisores usando cinco escalas diferentes, e o histograma que volta é ruído.

Recorra a humanos quando a régua de qualidade é subjetiva (voz, tom, tato), quando é preciso julgamento de domínio (este resumo jurídico está realmente certo) ou quando o risco torna uma resposta errada caro. Aceite o custo: é mais lento e mais caro que tudo aqui, e por isso os times reservam essa abordagem para a decisão final e para a auditoria periódica em vez do ciclo diário.

Escolher uma abordagem

A regra de decisão que resolve a maioria dos cenários: se a questão te entrega uma resposta de referência ou pede uma nota repetível em volume, é avaliação automática. Se ela pergunta sobre qualidades como helpfulness ou faithfulness em saída aberta e em volume, é um modelo juiz. Se aparecem as palavras "especialista de domínio", "preferência", "tom" ou "subjetivo", é avaliação humana.

Elas não são exclusivas, e times reais empilham as três: métricas automáticas no pipeline a cada mudança, métricas de juiz semanalmente em uma amostra maior, humanos no candidato a release.

Dicas para a prova

• O guia do exame nomeia duas abordagens diretamente, avaliação humana e datasets de benchmark. Reconheça a terceira, a avaliação por juiz, pela estrutura de dois modelos: um generator e um evaluator.
• Accuracy e robustness precisam de resposta de referência. Toxicity, helpfulness e a maioria das métricas de juiz não. Questões sobre "nenhum ground truth disponível" estão eliminando pontuação baseada em referência.
• "Especialistas de domínio", "preferência entre dois modelos" ou uma régua subjetiva de qualidade apontam para avaliação humana. "Pontuar milhares de respostas abertas de forma barata" aponta para um modelo juiz.
• Case cada dataset pronto ao seu propósito: RealToxicityPrompts para toxicity, BOLD para viés em geração aberta, Gigaword para summarization, BoolQ, NaturalQuestions e TriviaQA para question and answer, TREX para conhecimento factual.
• Qualquer alternativa que afirme que uma posição em leaderboard público prova adequação a um caso de uso de negócio está errada.
• Robustness trata de perturbações semanticamente neutras da entrada, como erros de digitação e caixa. Não confunda com accuracy em entrada limpa.

O ponto para guardar: uma abordagem de avaliação é escolhida pela evidência que você tem e pelo que qualidade significa na sua aplicação, não pela ferramenta mais conveniente. Em seguida vem a camada por baixo da palavra "accuracy", as métricas específicas que transformam dois pedaços de texto em um número.