90% do trabalho real não aparece nos benchmarks de IA

O problema que ninguém queria medir

Benchmarks de IA viraram o placar oficial do setor. Todo lançamento chega com um gráfico novo, uma taxa de acerto maior, um recorde quebrado em código ou matemática. Só que quem opera modelo em produção sente que tem algo errado. O modelo tira nota máxima no teste e tropeça em tarefa simples do dia a dia, entende um contrato mas erra no follow-up com o cliente, escreve função perfeita mas não lida com aquele processo administrativo chato que consome horas da equipe.

Agora temos um número para essa sensação. Cerca de 90% das horas trabalhadas nos Estados Unidos são gastas em tarefas com pouca ou nenhuma cobertura dos benchmarks atuais. Não é uma diferença pequena de amostragem. É um abismo entre o que a gente mede em laboratório e o trabalho que realmente move a economia.

O fato

O levantamento mapeou 923 ocupações da taxonomia O'NET, do Departamento de Trabalho americano, divididas em 22 famílias de empregos. No total, são 18.797 tarefas descritas oficialmente. Os pesquisadores pegaram 29 benchmarks escolhidos por qualidade e relevância econômica e cruzaram cada prompt com essas tarefas usando um juiz LLM, com validação humana em parte da amostra.

O critério foi simples e duro. Uma tarefa só conta como coberta se tiver pelo menos 5 prompts mapeados para ela. Resultado: apenas 208 das 923 ocupações têm ao menos uma tarefa nesse nível de cobertura. E 6 das 22 famílias de empregos não têm nenhuma ocupação com cobertura mínima. Ou seja, famílias inteiras de trabalho praticamente não existem para os benchmarks.

Como funciona na visão de quem opera

Em termos de arquitetura de avaliação, o pipeline é direto. Você pega o prompt do benchmark, pede para um modelo classificar a quais tarefas O'NET ele corresponde, depois agrega por ocupação e pondera pelo tempo estimado que cada tarefa consome, usando estimativas de participação no total de horas trabalhadas. É uma inferência em duas camadas: primeiro o mapeamento semântico, depois a ponderação econômica.

Como operador, dá para ver os limites rápido. O juiz LLM tende a ser generoso no mapeamento, o que na teoria inflaria a cobertura. Mesmo assim o número continua baixíssimo. E a escolha de 29 benchmarks unsaturated, ainda bons e não saturados, ajuda na qualidade mas subestima um pouco áreas muito testadas como engenharia de software. Os próprios autores admitem que a amostra é provisória e incompleta.

O ponto mais interessante é o viés de cobertura. Não é aleatório. Os benchmarks cobrem bem tarefas de advogados expostos à IA, por exemplo, mas quase ignoram secretárias jurídicas e funcionários de cartório, que são igualmente expostos e fazem o trabalho operacional que mantém o escritório rodando. O mesmo padrão se repete em outras áreas. A cabeça bem paga do conhecimento aparece, a cauda longa do trabalho médio, operacional e fragmentado some.

O que isso muda na prática

Para quem constrói produto, isso muda a forma de ler leaderboard. Um modelo líder em código, matemática e perguntas de múltipla escolha não é automaticamente bom em triagem de ticket, conciliação, revisão de documento bagunçado, atendimento com contexto incompleto ou aquele fluxo interno cheio de exceção. Que é exatamente onde a maioria das empresas tenta colocar agente hoje.

Quem ganha com esse cenário atual são os fornecedores de modelo, porque é muito mais fácil vender capacidade geral com gráfico bonito do que provar desempenho em processo real. Quem perde é quem compra. Time de produto, CTO, fundador que assina contrato de API esperando automação de ponta a ponta e descobre na semana dois que a latência estoura, o custo por tarefa explode e a taxa de intervenção humana continua alta.

O que ajustar agora

Se você está avaliando modelo para produção, troque parte do seu eval genérico por um eval tirado do seu próprio log. Puxe 100 casos reais dos últimos 30 dias, anonimize, crie gabarito com o que seu melhor operador fez e rode os modelos candidatos nisso. Meça acerto, custo por tarefa e taxa de escalonamento para humano. Esse mini benchmark interno vale mais que dez tabelas públicas.

• Monte um conjunto de 50 a 100 tarefas reais da sua operação com entrada bagunçada, não prompt limpo.
• Meça custo total por tarefa resolvida, incluindo retries, ferramentas e revisão humana, não só preço por token.
• Registre onde o modelo quebra: falta de contexto, regra implícita, sistema legado ou ambiguidade que humano resolve no feeling.

A tensão que fica

A dúvida real aqui não é se benchmarks são inúteis. Eles são úteis para comparar arquitetura, checar regressão e orientar treino. A dúvida é se eles escalam como proxy de valor econômico. E tudo indica que não. A gente está otimizando para o que é fácil de testar, não para o que é caro de operar.

Isso levanta uma questão incômoda de custo. Cobrir a cauda longa do trabalho real exige benchmarks agentivos, com ferramentas, estado, interrupção e julgamento humano. Isso é caro de construir, lento de rodar e difícil de manter. Vale a pena para um lab investir nisso quando o mercado premia quem sobe 2 pontos em um teste famoso? Provavelmente não, a menos que clientes enterprise comecem a exigir prova em tarefa real antes de fechar contrato.

No fundo, talvez a gente não tenha um problema de capacidade, mas um problema de visibilidade. Não sabemos o quão bom o modelo é no trabalho que os americanos realmente fazem porque quase não olhamos para esse trabalho. E enquanto a avaliação mirar no topo da pirâmide, a automação vai continuar impressionando em demo e patinando em produção.

Conclusão

O recado é simples. Pare de comprar IA por nota em prova e comece a comprar por desempenho em tarefa com dinheiro e tempo envolvidos. Se 90% do trabalho está fora do mapa, sua próxima vantagem está em mapear o seu pedaço antes dos outros. Qual tarefa da sua operação hoje ninguém mede, mas consome mais horas e mais salário?