Por que os benchmarks de IA ignoram 90% do trabalho real

Uma amiga minha comanda operações em uma empresa de logística de porte médio, e na primavera passada o time dela passou três semanas avaliando se um LLM poderia assumir o fluxo de tratamento de exceções — aquele trabalho nada glamouroso de conciliar notas fiscais que não batem com os pedidos de compra entre três sistemas que se detestam. O material do fornecedor estava cheio de números impressionantes: MMLU, GSM8K, HumanEval, um punhado de benchmarks agênticos. O modelo tirou nota máxima em todos os testes prontos que lhe deram. Aí apontaram para uma semana real de exceções, e ele associou com total confiança uma nota fiscal de US$ 14.000 ao pedido de compra errado, porque um fornecedor tinha abreviado o próprio nome de forma diferente. Nenhum leaderboard mede isso.

Essa lacuna agora é mensurável. Um mapeamento recente dos benchmarks públicos de IA contra a taxonomia O*NET do Departamento do Trabalho dos EUA — todas as 923 ocupações e 18.797 tarefas que compõem o trabalho americano — descobriu que 90% das horas de trabalho nos EUA são gastas em tarefas com pouca ou nenhuma cobertura de benchmark. Apenas 208 das 923 ocupações têm ao menos uma tarefa respaldada por cinco ou mais prompts de benchmark. Seis das 22 famílias de ocupações não têm nenhum. A conclusão incômoda não é que a IA seja fraca. É que nossos instrumentos para medir a capacidade da IA estão apontados quase inteiramente para a parte errada da economia.

O que os benchmarks de IA realmente cobrem

A metodologia por trás desse mapeamento vale a pena entender, porque é mais cuidadosa do que a manchete sugere. Os pesquisadores pegaram 29 benchmarks agênticos de alta qualidade e não saturados — testes em que o modelo precisa realmente executar trabalho, e não apenas responder perguntas — e usaram um juiz baseado em LLM (validado contra especialistas humanos) para marcar cada prompt de benchmark com as tarefas O*NET que ele exercita. Uma tarefa conta como "coberta" se pelo menos cinco prompts a mapeiam. Combine isso com estimativas de quanto tempo de trabalho cada tarefa consome, e você tem um retrato da economia inteira do que nossa suíte de avaliação consegue enxergar.

O que ela enxerga é estreito e alto, não amplo. Engenharia de software e análise financeira estão saturadas de benchmarks. Motorista de caminhão, operação de usina de gás, serviço de alimentação e a maior parte do trabalho diário da saúde são basicamente invisíveis. E o viés não se limita a quais tarefas são tecnicamente automatizáveis. Tarefas marcadas como "expostas à IA" têm cerca de seis vezes mais chance de serem avaliadas do que as não expostas — o que faz sentido — mas, mesmo controlando por isso, tarefas de ocupações com grandes massas salariais totais aparecem significativamente super-representadas. As tarefas de advogados são fortemente cobertas. Secretários jurídicos e escreventes de tribunal, que enfrentam exposição semelhante à IA, quase não aparecem.

Leia de novo: estamos comparando a IA com a versão prestigiosa de uma profissão e ignorando a versão que a maioria das pessoas de fato exerce. A cauda longa do trabalho intelectual de renda média — os coordenadores, escreventes, especialistas e agendadores cujas horas somam uma parcela enorme da economia — quase não tem infraestrutura de medição. Quando alguém afirma que a IA consegue fazer uma porcentagem do "trabalho intelectual", pergunte qual trabalho intelectual, medido como e contra qual lista de tarefas. A resposta honesta costuma ser: uma fatia fina e não representativa, medida com testes pensados para artigos de pesquisa.

A saturação de benchmarks é uma falha de design de avaliação

Passei anos construindo pipelines de avaliação, e a lição mais difícil foi esta: um benchmark é um modelo do mundo, e a maioria dos benchmarks são modelos péssimos. Eles comprimem uma tarefa humana confusa, contextual e de várias etapas em um prompt limpo com uma resposta verificável, porque isso é barato de corrigir. Depois, a Lei de Goodhart faz o resto. No momento em que um benchmark vira alvo do desenvolvimento do modelo, ele deixa de medir a capacidade que deveria representar. Os dados de treino absorvem a distribuição do teste, os times ajustam para o leaderboard, e as notas sobem enquanto o desempenho no mundo real fica estagnado ou piora.

A saturação é o sintoma visível. Quando todo modelo de fronteira passa de 90% em um teste, o teste parou de discriminar — mas o problema mais profundo é que reagimos construindo outro benchmark no mesmo estilo, cobrindo os mesmos tipos de tarefa, porque são as que sabemos corrigir automaticamente. Perguntas de múltipla escolha geram perguntas de múltipla escolha mais difíceis. Desafios de programação geram desafios de programação mais difíceis. Enquanto isso, ninguém constrói o benchmark para "perceber que a cláusula de indenização deste contrato contradiz silenciosamente a term sheet de março", porque corrigir isso exige um advogado, tempo e julgamentos que resistem à automação.

Por isso discordo da ideia de que saturação de benchmark significa que a IA "resolveu" um domínio. Saturação significa que o instrumento chegou ao limite, ponto final. Um termômetro que marca 40°C no máximo não prova que a sala está a 40 graus; prova que você precisa de outro termômetro. Se você está avaliando modelos para uso em produção — e principalmente se está construindo sistemas de decisão baseados em LLM onde erros têm custo real —, diferenças de leaderboard em benchmarks saturados deveriam pesar quase zero na sua decisão.

Sabemos com precisão o quão bons os modelos são no trabalho que decidimos medir. Quase não sabemos nada sobre os outros noventa por cento.

O efeito do poste de luz na avaliação de IA

Há uma piada antiga sobre um bêbado procurando as chaves debaixo de um poste — não porque as perdeu ali, mas porque é onde está a luz. A construção de benchmarks segue a mesma lógica, e os dados confirmam que isso não é aleatório. O estudo de mapeamento descobriu que a importância da tarefa dentro de uma ocupação prediz a cobertura: tarefas O*NET avaliadas como as mais importantes para sua ocupação têm de seis a dez vezes mais chance de serem testadas do que as menos importantes. À primeira vista, isso parece priorização sensata. Na prática, significa que medimos as tarefas de vitrine e ignoramos o tecido conectivo.

Todo trabalho é, em grande parte, tecido conectivo. A tarefa de um engenheiro de software que tem benchmark é "implementar uma função que passe nesses testes". O dia real dele inclui ler a migração meio pronta de um colega, descobrir qual stakeholder de fato é dono de uma decisão e perceber que o ticket descreve o problema errado. Já escrevi antes sobre como ferramentas de programação agêntica têm sucesso ou fracassam exatamente nisso: o loop, o contexto e os limites de permissão importam mais do que a qualidade bruta da geração. Nada disso aparece em uma nota no estilo HumanEval.

Há também um problema de definição sutil nos próprios números de cobertura. "Coberto" significa que cinco ou mais prompts mapeiam para uma tarefa — não que esses cinco prompts capturem a tarefa. Treze prompts sobre orientar pais em problemas de criação dos filhos não representam o que um assistente social faz ao longo de uma carteira de casos, de uma audiência no tribunal e de uma visita domiciliar. Se você aplicasse a definição de "bem coberto" de um leigo, a fatia medida da economia não seria 10%. Seria arredondada para zero. O poste de luz não é apenas estreito; a luz que ele projeta é fina.

Modelos geram, mas ninguém avalia o julgamento

Aqui está a assimetria que considero mais devastadora. Quase todo benchmark existente testa a produção: escreva o código, redija o memorando, resolva o problema. Mas a metade economicamente crítica da maioria das tarefas reais é a detecção — pegar o erro, sinalizar a inconsistência, saber quando a resposta confiante está errada. O valor de um contador júnior não está em produzir uma conciliação; está em perceber que um número parece suspeito. Benchmarks quase nunca testam isso, porque construir uma tarefa de detecção de erros com correção é muito mais difícil do que construir uma tarefa de geração com correção. Você precisa de artefatos falhos realistas, erros sutis porém plausíveis e concordância humana sobre o que conta como ter pego o erro.

Esta é a falácia do porteiro aplicada ao design de avaliação. Substitua um porteiro por uma porta automática e você descobre, tarde demais, que o porteiro também recebia moradores, aceitava encomendas e vigiava a rua. Automatize a parte avaliada de um trabalho e você descobre que as partes não avaliadas eram estruturais. O modelo da minha amiga da logística conseguia redigir notas de conciliação excelentes — a tarefa visível —, enquanto silenciosamente estragava o casamento dos valores, que é o julgamento que tornava as notas valiosas. A suíte de avaliação pontuou o acompanhamento e ignorou o prato principal.

Até que a detecção de erros receba tratamento de benchmark de primeira classe, espere uma lacuna persistente entre o desempenho na demonstração e o desempenho em produção. É a mesma lacuna que existe entre o que uma especificação diz e o que a implementação faz — e, assim como no software, é nessa lacuna que as falhas se multiplicam. Um modelo que gera no 90º percentil e verifica no 30º é, em produção, um funcionário do 30º percentil com vantagem de velocidade de digitação.

Ponderando as avaliações pela distribuição real de tarefas

A ideia mais prática do trabalho de mapeamento de benchmarks também é a mais simples: se os benchmarks super-representam algumas tarefas, pare de calcular médias sobre prompts e passe a calcular médias sobre tarefas, ponderadas pelo tempo de trabalho que cada uma realmente consome. Uma média simples de todos os prompts marcados como "analista financeiro" é dominada pela tarefa que por acaso tem mais prompts de benchmark — geralmente aquela para a qual foi mais fácil montar um conjunto de dados. Uma média ponderada pela O*NET dá a cada tarefa real o mesmo peso. A diferença pode ser dramática.

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

Duas coisas merecem atenção nesse trecho. Primeiro, a nota ponderada cai porque as tarefas mais fracas do modelo estavam sub-representadas no conjunto de prompts — exatamente a distorção que uma média plana esconde. Segundo, e mais importante: "aconselhar cliente" desaparece totalmente do cálculo, porque nenhum prompt a mapeia. Qualquer esquema de ponderação descarta silenciosamente tarefas sem cobertura, e a ausência de cobertura é a norma para a maior parte da economia. Ponderar resolve o problema da ponderação. Não resolve o problema dos dados ausentes. Isso exige construir novas avaliações, não recalcular médias das antigas.

Como avaliar a IA com base no trabalho que você realmente faz

Se você está escolhendo ou implantando modelos, a lacuna de cobertura da economia tem uma implicação concreta: benchmarks públicos são uma referência fraca para o seu caso de uso, a menos que você esteja justamente no pequeno canto brilhante que eles medem. Então construa o seu próprio canto. Isso é menos heroico do que parece, e supera com folga confiar no material de vendas do fornecedor.

• Amostre tarefas de logs, não da imaginação. Extraia uma semana de tickets, e-mails ou exceções reais e amostre por frequência. Seu conjunto de avaliação deve parecer com o histograma da sua carga de trabalho, incluindo a cauda entediante — e a cauda entediante é a maior parte do trabalho.
• Pondere por tempo ou custo e reporte os dois números. Uma média simples e uma média ponderada delimitam a verdade. Se um modelo vence na média simples, mas perde na ponderada, é porque ele é bom nas tarefas fáceis de testar — exatamente o modo de falha que você está tentando filtrar.
• Inclua tarefas de verificação. Pegue saídas reais — inclusive as sabidamente ruins — e avalie o modelo pela capacidade de pegar erros plantados e naturais. Na minha experiência, habilidade de detecção e de geração são pouco correlacionadas, e detecção é o que você está de fato comprando.
• Mantenha um conjunto privado e renove-o. Qualquer avaliação reutilizada por meses vira alvo de treino, mesmo sem intenção, assim que alguém começa a ajustar prompts para ela. Renove os casos a cada trimestre.
• Meça resultados de ponta a ponta sempre que possível. Se a tarefa é "conciliar esta nota fiscal", avalie a conciliação, não a prosa intermediária. Métricas intermediárias bajulam modelos da mesma forma que testes unitários bajulam código sem cobertura de integração.

Há um efeito final, mais silencioso, que vale nomear e que qualquer pessoa que usa ferramentas de programação com IA no dia a dia vai reconhecer: a doença de custos de Baumol em escala micro. Quando a geração fica vinte vezes mais rápida, você não passa o dia gerando. Passa no que não acelerou — revisando, coordenando, verificando, decidindo. O restante não avaliado não diminui conforme a IA melhora; ele cresce para ocupar o tempo liberado e se torna uma parcela maior do que determina se valeu a pena implantar a IA. Medir a fatia automatizável com precisão cada vez maior enquanto se ignora o restante não é apenas incompleto. Inverte o que importa.

Nada disso é um argumento de que o progresso da IA é falso — os ganhos de capacidade são reais, e já apostei projetos neles. É um argumento de que nossa cultura de medição está apontada para a distribuição errada. Os benchmarks foram construídos onde prompts eram baratos de escrever e corrigir: código, matemática, conhecimento no estilo de prova. A economia, em sua maioria, não é isso. Até que a avaliação alcance a realidade, trate toda afirmação manchete sobre capacidade como uma declaração sobre a décima parte brilhante do mapa, e construa avaliações que cubram os seus próprios noventa por cento escuros. As organizações que fizerem esse trabalho de medição chato e pouco glamouroso tomarão decisões de implantação melhores do que todo mundo atualizando leaderboards — e não será nem de perto uma disputa.