Avaliação Humana
O que “Avaliação Humana” Significa (e Quando Você Precisa Dela)
Avaliação humana é qualquer protocolo de avaliação em que pessoas julgam a qualidade das saídas de um modelo — muitas vezes porque métricas automatizadas são incompletas, fáceis de “burlar” (gameable) ou pouco alinhadas ao valor real para o usuário. Ela é amplamente usada para:
- Geração de linguagem natural (resumo, tradução, diálogo, seguimento de instruções)
- Geração multimodal (legendas de imagens, texto-para-imagem, vídeo)
- Segurança e conformidade com políticas (toxicidade, instruções nocivas, privacidade)
- Qualidade de produto ponta a ponta (utilidade, confiança, UX)
A avaliação humana fica ao lado de métricas automáticas offline e do julgamento por modelos. No conjunto mais amplo de ferramentas de avaliação, ela costuma ser a checagem da “última milha” para qualidades difíceis de formalizar. Ela também traz riscos únicos: julgamentos humanos são ruidosos, caros e sistematicamente enviesados, a menos que sejam cuidadosamente projetados.
Tópicos relacionados: Avaliação Offline, Construção de Benchmarks, Reprodutibilidade & Significância Estatística, LLM-como-Juiz, Lei de Goodhart em Métricas.
Formatos Principais: Notas vs Comparações em Pares
A avaliação humana normalmente usa notas absolutas (pontuar cada saída) ou julgamentos comparativos (escolher qual é melhor). Cada um tem propriedades estatísticas e práticas diferentes.
1) Notas Humanas (Julgamentos Absolutos)
Avaliadores atribuem uma pontuação em uma escala discreta ou contínua, frequentemente por critério.
Escalas comuns:
- Likert (Likert) (ex.: 1–5 para concordância ou qualidade)
- Níveis ordinais de qualidade (ex.: Ruim / OK / Bom / Excelente)
- Controles deslizantes contínuos (0–100)
Critérios típicos para saídas de LLMs (large language models):
- Correção / factualidade
- Relevância
- Completude
- Clareza
- Estilo / tom
- Segurança / conformidade com políticas
Exemplo (rubrica de resumo):
- Factualidade (1–5): O resumo introduz erros ou afirmações não sustentadas?
- Cobertura (1–5): Ele captura pontos-chave da fonte?
- Concisão (1–5): Ele evita detalhes desnecessários?
Pontos fortes
- Eficiente ao avaliar muitos sistemas de forma independente
- Funciona bem quando você precisa de limiares absolutos (ex.: “deve ser ≥4/5 em factualidade”)
Pontos fracos
- Diferentes avaliadores interpretam escalas de formas distintas (viés de uso de escala)
- É mais difícil manter consistência do tipo “o que é um 4 vs um 5?” ao longo do tempo (deriva do avaliador)
- Suscetível a ancoragem e efeitos de contexto (o que mais o avaliador viu)
2) Comparações em Pares (Julgamentos Relativos)
Avaliadores veem duas saídas (A e B) para a mesma entrada e escolhem:
- A é melhor, B é melhor, ou empate (às vezes)
- Ocasionalmente com uma opção de intensidade de preferência (ligeiramente vs fortemente)
Exemplo (utilidade de assistente de chat):
Prompt: “Write an email asking to reschedule a meeting.”
Output A: concise, polite email
Output B: longer email with more context
Question: Which response would you prefer to send?
Pontos fortes
- Frequentemente mais confiável do que notas, porque humanos são melhores em comparar do que em calibrar uma escala absoluta
- Reduz a variância entre avaliadores devido à interpretação idiossincrática de pontuações
- Se encaixa naturalmente com aprendizado por preferências (preference learning) (ex.: pipelines no estilo RLHF)
Pontos fracos
- Exige mais anotação por decisão se você quiser um ranking global entre muitos modelos
- Pode ser influenciado por traços superficiais (ex.: verbosidade) a menos que isso seja controlado
- A análise estatística requer um modelo de preferência ou uma agregação cuidadosa
3) Variantes de Ranqueamento e Torneio
Em vez de comparar apenas dois, avaliadores podem ranquear k saídas (ranqueamento k-way), ou o sistema pode executar chaves em estilo torneio para reduzir comparações.
- Ranqueamento k-way pode ser mais eficiente em anotação, mas é cognitivamente mais difícil.
- Torneios (como atualizações Elo) podem escalar para muitos modelos, mas podem introduzir artefatos de chave/ordenação.
Fundamentos Teóricos (O que Você Está Estimando)
A avaliação humana tenta estimar um conceito latente como “utilidade” ou “qualidade”, que não é diretamente observável. Isso motiva um cuidado com teoria de mensuração.
Notas como Medidas Ruidosas
Se um avaliador dá 4/5 para “utilidade”, você pode tratar isso como uma observação ruidosa de uma variável latente contínua. Problemas surgem porque:
- O mapeamento de qualidade latente → número escolhido não é consistente entre avaliadores
- A escala é ordinal na prática (diferenças entre 1→2 e 4→5 podem não ser iguais)
Por isso médias de pontuações Likert podem ser enganosas sem calibração e checagens de confiabilidade.
Preferências em Pares e Modelos de Preferência
Comparações em pares se conectam naturalmente a modelos probabilísticos de preferência:
- Modelo Bradley–Terry (Bradley–Terry model): cada sistema tem um escore de “habilidade”; a probabilidade de A vencer B depende da diferença de escores.
- Modelo Thurstone–Mosteller (Thurstone–Mosteller model): similar, frequentemente com suposições Gaussianas.
- Elo / TrueSkill: variantes de atualização online usadas em torneios.
Esses modelos ajudam a converter muitos julgamentos em pares ruidosos em:
- Um ranking global
- Estimativas de incerteza
- Testes estatísticos de diferenças
Exemplo de formato de dados para julgamentos em pares
{"prompt_id": 17, "winner": "A", "loser": "B", "rater_id": 203}
{"prompt_id": 17, "winner": "B", "loser": "C", "rater_id": 204}
{"prompt_id": 18, "winner": "A", "loser": "C", "rater_id": 203}
Esboço simples de ajuste Bradley–Terry (ilustrativo)
# Pseudocode: fit "skill" parameters s[model]
# so that P(i beats j) = exp(s[i]) / (exp(s[i]) + exp(s[j]))
wins = {(i,j): count_i_beats_j}
skills = initialize_zero()
for step in range(num_steps):
grad = {m: 0.0 for m in models}
for (i,j), w in wins.items():
p = exp(skills[i]) / (exp(skills[i]) + exp(skills[j]))
grad[i] += (w - total(i,j)*p)
grad[j] -= (w - total(i,j)*p)
update(skills, grad)
Na prática, você usaria uma biblioteca, mas a ideia central é: votos em pares se traduzem em um escore calibrado com incerteza em vez de taxas brutas de vitória.
Design Prático: Como Conduzir Bem uma Avaliação Humana
Passo 1: Defina o Construto-Alvo (e o Que Você Não Está Medindo)
Seja explícito sobre o que “qualidade” significa para sua tarefa:
- Para QA factual: “correção” pode dominar.
- Para escrita criativa: “engajamento” ou “voz” podem importar.
- Para suporte ao cliente: “conformidade com políticas” e “acionabilidade” podem ser críticos.
Evite critérios sobrecarregados como “qualidade geral”, a menos que você saiba que quer um sinal holístico de preferência.
Isso se conecta a Construção de Benchmarks: se seu construto for vago, a mensuração será ruidosa e fácil de interpretar de forma equivocada.
Passo 2: Escolha os Avaliadores Certos (Multidão vs Especialista vs Usuários)
- Avaliadores via crowd (crowdsourced raters): escaláveis e rápidos; melhores para qualidades superficiais e preferência ampla; risco de baixa expertise no domínio.
- Especialistas do domínio (médicos, advogados, analistas de segurança): caros, mais lentos; necessários para correção especializada e julgamentos de alto impacto.
- Usuários reais no contexto do produto: maior validade externa; mais difícil de controlar; frequentemente combinado com experimentos online.
Para avaliação de produto ponta a ponta, veja também Avaliação de Apps com LLM.
Passo 3: Escreva Instruções e Rubricas Claras
Boas rubricas:
- Incluem exemplos positivos e negativos
- Esclarecem o que fazer quando as duas saídas são ruins (permitir empates ou “ambas inaceitáveis”)
- Especificam restrições que não podem falhar (ex.: “Qualquer citação alucinada → factualidade ≤2”)
Exemplo de trecho de rubrica (factualidade):
- 5: Sem erros factuais; sustentado pela fonte.
- 3: Pequenas imprecisões que não mudam a alegação principal.
- 1: Grandes alucinações ou contradições com a fonte.
Passo 4: Controle a Apresentação (Randomização e Cegamento)
Para reduzir viés:
- Oculte (blind) do avaliador a identidade do modelo e a condição experimental.
- Randomize:
- Ordem das saídas (A/B)
- Ordem dos prompts
- Qual modelo aparece como A
- Mantenha formatação consistente (mesma fonte, quebras de linha, sem metadados).
Para LLMs, a apresentação é especialmente influente porque pistas de estilo (tamanho, confiança) afetam fortemente a qualidade percebida.
Passo 5: Adicione Controles de Qualidade
Ferramentas comuns:
- Perguntas gold (gold questions) (itens com resposta conhecida)
- Checagens de atenção (ex.: “Selecione a opção 2 para esta pergunta”)
- Testes de qualificação de avaliadores
- Filtros baseados em tempo (sinalizar respostas extremamente rápidas)
- Monitoramento contínuo de deriva do avaliador
Cuidado: perguntas gold podem enviesar a avaliação para o que é fácil de rotular e podem penalizar discordâncias legítimas em tarefas subjetivas.
Passo 6: Planeje a Estatística com Antecedência
Decida previamente:
- Tamanho amostral (quantos prompts, quantas avaliações por prompt)
- Métrica primária (nota média, taxa de vitória, escore Bradley–Terry)
- Como computar intervalos de confiança e significância
Avaliação humana costuma ter alta variância; ela se beneficia da disciplina descrita em Reprodutibilidade & Significância Estatística.
Vieses Comuns em Avaliação Humana (e Como Mitigá-los)
Julgamentos humanos não são apenas ruidosos — eles são sistematicamente enviesados. Abaixo estão vieses recorrentes em avaliações de IA e mitigações práticas.
Ancoragem e Efeitos de Contexto
O que acontece: A nota de um avaliador é influenciada por exemplos anteriores. Se ele primeiro vê uma saída muito forte, saídas posteriores podem receber notas mais severas.
Mitigações
- Randomizar a ordem de prompts e saídas
- Usar comparações em pares em vez de notas absolutas
- Fornecer exemplos de calibração no início
Efeitos de Ordem (Primazia/Recência)
O que acontece: Em comparações A/B, o primeiro ou o segundo item pode ser favorecido por padrões de atenção.
Mitigações
- Contrabalancear a ordem A/B (cada modelo aparece com a mesma frequência como A e B)
- Randomizar a ordem dentro de cada avaliador
Efeito Halo
O que acontece: Um atributo forte (ex.: escrita bem polida) aumenta notas em atributos não relacionados (ex.: correção).
Exemplo: Uma resposta fluente, mas errada, recebe alta “qualidade geral”.
Mitigações
- Separar critérios e solicitá-los de forma independente
- Adicionar instruções explícitas: “Não inferir correção a partir de confiança ou tom.”
- Incluir exemplos adversariais em que fluência e correção divergem
Viés de Uso de Escala (Leniente/Severo)
O que acontece: Alguns avaliadores evitam extremos; outros usam 1 e 5 em excesso. Notas médias passam a depender do avaliador.
Mitigações
- Preferir comparações em pares para comparações globais
- Normalizar por avaliador (às vezes) ou usar modelos de efeitos mistos
- Fornecer exemplos ancorados de rubrica para cada ponto da escala
Viés de Tendência Central
O que acontece: Avaliadores usam demais a opção do meio, especialmente quando estão incertos.
Mitigações
- Usar decisões em pares de escolha forçada quando apropriado
- Oferecer “não é possível julgar” apenas quando realmente necessário, e acompanhar sua taxa
Fadiga e “Satisficing”
O que acontece: Com o tempo, avaliadores prestam menos atenção, escolhem mais rápido e recorrem a atalhos (ex.: escolher a resposta mais curta).
Mitigações
- Tarefas mais curtas, pausas, limitar tamanhos de lote
- Monitorar tempo por item e acerto em perguntas gold
- Rotacionar pools de avaliadores e detectar deriva
Efeitos de Enquadramento e Viés de Instrução
O que acontece: Pequenas mudanças de redação alteram resultados (“útil” vs “preciso” vs “inofensivo”). Avaliadores otimizam o que você pede.
Mitigações
- Pilotar múltiplas variantes de instrução
- Priorizar critérios com clareza (ex.: “Correção é mais importante do que verbosidade.”)
- Alinhar com seu objetivo real para evitar “gaming” de métricas (ver Lei de Goodhart em Métricas)
Viés Cultural e de Idioma
O que acontece: Preferências por tom, polidez, franqueza, humor e formalidade variam entre culturas e demografias.
Mitigações
- Combinar a demografia dos avaliadores com a dos usuários-alvo
- Estratificar a análise por localidade/idioma quando relevante
- Usar rubricas e exemplos localizados
Vieses Relacionados à Segurança (Normalização do Dano)
O que acontece: Exposição repetida a conteúdo tóxico pode dessensibilizar avaliadores, mudando o que eles consideram “inseguro”.
Mitigações
- Fornecer definições claras de segurança e caminhos de escalonamento
- Rotacionar avaliadores, oferecer recursos de apoio, minimizar exposição
- Considerar revisão por especialista para categorias de alto risco (ver Avaliação de Segurança)
“Viés de Verbosidade” na Avaliação de Saídas de LLM
O que acontece: Respostas mais longas frequentemente são avaliadas como mais úteis, mesmo quando adicionam preenchimento ou escondem erros.
Mitigações
- Adicionar concisão como critério ou restrição explícita
- Fornecer comparações normalizadas por comprimento (ex.: “prefira a melhor resposta que seja concisa”)
- Usar métricas de sucesso específicas da tarefa quando possível (resolveu o problema do usuário?)
Confiabilidade: Medindo Concordância e Consistência
A avaliação humana deve reportar não apenas pontuações, mas também o quão confiáveis essas pontuações são.
Confiabilidade Entre Avaliadores (IRR — inter-rater reliability)
Medidas comuns:
- κ de Cohen (Cohen’s κ) (dois avaliadores, categórica)
- κ de Fleiss (Fleiss’ κ) (múltiplos avaliadores, categórica)
- α de Krippendorff (Krippendorff’s α) (flexível: dados faltantes, diferentes níveis de mensuração)
- Correlação / ICC (Correlation / ICC) (para avaliações “quase contínuas”)
A interpretação depende da tarefa: tarefas subjetivas naturalmente têm menor concordância do que rotulagem factual. IRR baixo pode significar:
- A rubrica é pouco clara
- A tarefa é inerentemente ambígua
- Avaliadores não são qualificados
- Diferenças entre modelos são sutis demais para medir
Consistência Intra-avaliador
Teste se o mesmo avaliador faz julgamentos consistentes ao longo do tempo:
- Repetir um pequeno subconjunto de itens
- Verificar contradições ou alta variância
Calibrando Avaliadores
Uma abordagem prática:
- Fase de treinamento com feedback usando um pequeno conjunto gold
- Limiar de qualificação
- Itens periódicos de recalibração durante a tarefa
Agregação e Relato: Transformando Julgamentos Humanos em Resultados
Para Notas
Relato típico:
- Média e erro padrão por modelo
- Gráficos de distribuição (não apenas a média)
- Recorte por critério (ex.: correção vs estilo)
Atenção: fazer média de pontuações Likert ordinais é comum, mas imperfeito. Considere reportar:
- % de saídas avaliadas como ≥4 (métrica de limiar)
- Mediana e quantis
- Modelos de efeitos mistos para considerar variância de avaliador e prompt
Para Comparações em Pares
Opções:
- Taxa de vitória com intervalos de confiança (simples, mas ignora a força do oponente)
- Escores Bradley–Terry / Elo com incerteza (frequentemente mais informativos)
- Análise estratificada por categoria de prompt (ex.: raciocínio vs código vs criativo)
Para significância, faça bootstrap sobre prompts ou use modelos hierárquicos; veja Reprodutibilidade & Significância Estatística.
Múltiplas Comparações
Se você compara muitos modelos, p-values ingênuos vão superestimar a significância. Use:
- Comparações primárias pré-registradas, ou
- Correções (ex.: Holm–Bonferroni), ou
- Reporte tamanhos de efeito com incerteza e evite um enquadramento binário de “vitórias”
Isso também se conecta a Rankings: rankings podem amplificar ruído e incentivar super-otimização para protocolos estreitos de avaliação humana.
Exemplos Práticos
Exemplo 1: Avaliando Dois Modelos de Sumarização
Objetivo: Escolher entre os Modelos A e B para uma funcionalidade de resumo de notícias.
Protocolo:
- Amostrar 500 artigos da sua distribuição-alvo
- Gerar resumos de ambos os modelos
- Para cada artigo, coletar 3 julgamentos em pares sobre:
- Preferência geral
- Preferência de factualidade (explícita)
- Randomizar o posicionamento A/B, ocultar a identidade do modelo
- Ajustar Bradley–Terry para obter um escore global + IC
- Auditar um subconjunto com revisão de especialista para regressões de factualidade
Por que comparações em pares ajudam: avaliadores podem decidir rapidamente qual resumo é melhor sem precisar de uma definição interna estável de “4/5”.
Exemplo 2: Avaliação Humana de Recusas por Segurança
Objetivo: Garantir que o assistente recuse instruções nocivas e permaneça útil para solicitações benignas.
Protocolo:
- Curar prompts: 50% benignos, 50% violadores de política (com subcategorias)
- Avaliadores rotulam:
- “Em conformidade com a política?” (sim/não)
- “Apropriadamente útil?” (1–5)
- Incluir itens gold e regras de escalonamento
- Reportar taxa de conformidade com intervalos de confiança e analisar por categoria de dano
Conecte isso a práticas mais amplas de Avaliação de Segurança; avaliação de segurança frequentemente precisa de suporte especializado para avaliadores e design cuidadoso de taxonomias.
Exemplo 3: Avaliação Humana Voltada a Produto (Assistente RAG)
Objetivo: Avaliar se as respostas estão fundamentadas em documentos recuperados.
Protocolo:
- Mostrar prompt, trechos recuperados e a resposta do modelo
- Pedir que avaliadores marquem:
- “Sustentado por evidência?” (sim/parcialmente/não)
- “Faltam citações-chave?” (sim/não)
- Incluir uma opção “informação insuficiente” se a recuperação não contiver a resposta
- Estratificar por tipo de consulta (factual vs procedural)
Isso se sobrepõe à Avaliação de Apps com LLM, em que a revisão humana frequentemente valida fundamentação e utilidade.
Avaliação Humana em Pipelines Modernos de Desenvolvimento de LLM
Julgamentos humanos não são usados apenas para reportar — eles são usados para treinar:
- Dados de ajuste fino supervisionado (supervised fine-tuning): humanos escrevem ou editam respostas “ideais”
- Conjuntos de dados de preferência (preference datasets): humanos escolhem respostas melhores (em pares)
- Modelagem de recompensa e RLHF/RLAIF: preferências treinam um modelo de recompensa que orienta a otimização de política
Como o treinamento pode superajustar (overfit) ao seu setup de avaliação, assegure que seu protocolo de avaliação não seja trivialmente “aprendível” nem estreito demais — outra instância de preocupações relacionadas à Lei de Goodhart em Métricas e à Avaliação Robusta.
Armadilhas Comuns e Como Evitá-las
- Confundir estilo com correção: separar critérios; adicionar checagens factuais.
- Confiar demais em avaliações humanas pequenas: planejar para variância; reportar incerteza.
- Avaliar em prompts não representativos: amostrar do tráfego real; evitar prompts “de brinquedo”.
- Conjuntos de avaliação vazados: prompts podem estar nos dados de treino; veja Contaminação do Conjunto de Teste.
- Sem cegamento: até metadados sutis podem enviesar avaliadores.
- Super-otimização para a rubrica: atualizar rubricas periodicamente e validar contra resultados do mundo real.
Quando Usar Humanos vs Alternativas
A avaliação humana é valiosa quando:
- O construto é subjetivo (utilidade, preferência, estilo)
- Métricas automatizadas são pouco confiáveis ou fáceis de “burlar”
- Você precisa de uma checagem de “verdade fundamental” para qualidade ponta a ponta
Mas ela pode ser complementada por:
- Métricas automáticas (testes de regressão rápidos)
- Avaliadores baseados em modelo como LLM-como-Juiz para escala (com calibração e auditorias humanas periódicas)
- Experimentos online para impacto real em usuários
Checklist de Boas Práticas
- Defina o construto e os critérios de sucesso com precisão
- Escolha entre notas vs comparações em pares (frequentemente em pares para preferência)
- Use rubricas claras com exemplos ancorados
- Oculte e randomize; contrabalanceie a ordem A/B
- Use controles de qualidade (itens gold, qualificação, monitoramento de deriva)
- Meça confiabilidade (IRR, consistência intra-avaliador)
- Planeje estatística previamente; reporte incerteza e tamanhos de efeito
- Analise fontes de viés (verbosidade, halo, diferenças culturais)
- Valide contra uso real e atualize protocolos ao longo do tempo
A avaliação humana é poderosa porque mede o que usuários realmente percebem — mas esse poder só se sustenta se você tratá-la como um problema sério de mensuração, e não como uma checagem informal de “impressão”.