Resumo Técnico: Design e Relatórios de Benchmarks para Trabalho Intelectual

Declaração do Problema

O desenvolvimento rápido de agentes de Modelos de Linguagem de Grande Escala (LLM) expandiu o escopo da avaliação de IA para o "trabalho intelectual"—trabalho onde o conhecimento serve tanto como entrada quanto como saída, incluindo domínios como programação, pesquisa, saúde e administração. No entanto, o design atual de benchmarks e a lógica de avaliação aderem amplamente aos paradigmas tradicionais de Processamento de Linguagem Natural (PLN). Esses paradigmas tipicamente avaliam comportamentos de entrada-saída delimitados (por exemplo, geração de respostas, sumarização, recuperação) em vez da produção de artefatos de trabalho dentro de fluxos de trabalho situados.

Consequentemente, há um desalinhamento entre as pontuações dos benchmarks e as alegações mais amplas de capacidade de trabalho que elas são usadas para apoiar. Uma pontuação alta em uma tarefa componente (por exemplo, recuperar um documento) não indica de forma confiável a capacidade de um sistema de realizar a atividade completa de trabalho intelectual (por exemplo, triagem clínica ou análise jurídica). Essa inferência é frágil porque o significado de uma saída de trabalho intelectual depende fortemente do papel, dos materiais, do contexto e do fluxo de trabalho a jusante no qual ela é produzida. Os benchmarks atuais frequentemente falham em especificar essas restrições contextuais, levando a pontuações que não podem apoiar de forma confiável alegações sobre capacidades de implantação no mundo real.

Metodologia

O artigo propõe um framework de design e relatório em três etapas para vincular explicitamente as pontuações dos benchmarks a alegações de trabalho específicas. Essa abordagem fundamenta-se em estudos de trabalho, teoria da ação situada e teoria da validade, enfatizando que o trabalho intelectual é organizado por meio de papéis, materiais locais e artefatos que devem ser utilizáveis em fluxos de trabalho a jusante.

1. Definir a Atividade de Trabalho

Os autores argumentam que o escopo do benchmark deve ser definido por "atividade de trabalho" em vez de domínios amplos (por exemplo, "saúde") ou tarefas componentes estreitas (por exemplo, "sumarização"). Para operacionalizar isso, o artigo deriva um inventário de 18 atividades de trabalho transocupacionais a partir do banco de dados de tarefas O*NET (Zonas de Emprego 3–5).

• Processo de Derivação: Começando com 18.796 declarações de tarefas do O*NET, os autores filtraram ocupações de trabalho intelectual, removeram tarefas manuais/rotineiras e retiveram 12.464 declarações. Uma triagem mais rigorosa para "inclusão no atlas" resultou em 8.372 declarações, que foram reescritas em frases neutras em relação à profissão, incorporadas, agrupadas (usando UMAP e HDBSCAN) e consolidadas por meio de revisão de painel de especialistas.
• Resultado: 18 atividades de trabalho distintas (por exemplo, análise, administração, design, inspeção, solução de problemas, registro, coordenação, aconselhamento, investigação) foram identificadas. Elas servem como a unidade de relatório para alegações de benchmark.

2. Especificar o Ambiente Testado

O framework exige que os benchmarks definam explicitamente as condições sob as quais a atividade de trabalho é avaliada. A validade da pontuação é condicionada por quatro dimensões:

• Materiais: Os artefatos disponíveis (documentos, ferramentas, bancos de dados) e se eles incluem itens irrelevantes ou exigem que o sistema os encontre.
• Ferramentas: As capacidades concedidas ao sistema (pesquisa, edição, cálculo, chamadas de API) e se os estados das ferramentas persistem.
• Papel e Escopo: O papel específico que o sistema desempenha, seus limites de decisão e protocolos de escalonamento.
• Estado do Fluxo de Trabalho: A etapa específica do fluxo de trabalho sendo testada (por exemplo, redação inicial versus revisão versus transferência) e o estado necessário após a conclusão.

3. Pontuar o Produto de Trabalho Adequado

A pontuação deve focar no "produto de trabalho"—o objeto deixado pelo sistema para revisão, arquivamento, execução ou continuação a jusante—em vez de apenas no conteúdo visível (por exemplo, uma resposta de chat).

• Design da Rubrica: Os critérios de avaliação devem ser derivados dos requisitos do produto de trabalho, verificando:
  1. Se o resultado utilizou os materiais apropriados.
  2. Se o resultado aderiu ao papel atribuído e às restrições do fluxo de trabalho.
  3. Se o resultado deixou informações necessárias para os atores a jusante (por exemplo, citações rastreáveis, notas de transferência, mudanças de estado).
• Limitação da Alegação: A "Alegação Suportada" é definida como a alegação mais forte que uma pontuação pode suportar, dada a atividade específica, o ambiente testado e o produto avaliado.

Contribuições Principais

1. Uma Estrutura de Relatório em Três Etapas: Uma abordagem formalizada para o design de benchmarks que exige definições explícitas da atividade de trabalho, do ambiente testado e do produto de trabalho pontuado para prevenir alegações de capacidade generalizadas.
2. Inventário de Atividades de Trabalho Baseado no O*NET: Um inventário preliminar de 18 atividades de trabalho recorrentes derivadas de declarações de tarefas do O*NET, fornecendo um vocabulário padronizado para designers de benchmarks mapearem tarefas para alegações de trabalho específicas.
3. Framework de Análise de Casos: A aplicação deste framework a três benchmarks existentes para demonstrar como as escolhas de design moldam as alegações suportadas:
   • GDPVAL: Um benchmark de entregáveis ocupacionais não relacionados a código. A análise mostra que ele suporta alegações sobre a produção de entregáveis de conformidade específicos sob prompts fixos, mas carece de evidências para integração de fluxo de trabalho a jusante.
   • OFFICEQA PRO: Um benchmark de análise de documentos fundamentado. A análise revela que ele suporta alegações sobre análise numérica fundamentada, mas falha em pontuar o rastro de raciocínio do analista ou o pacote de evidências, limitando alegações sobre trabalho de revisão de documentos.
   • APEX-SWE: Um benchmark de engenharia de software. A análise mostra que ele suporta alegações sobre a conclusão de tarefas de integração em um ambiente específico, mas não cobre implantação em produção, revisão de código ou manutenção de longo prazo.

Resultados e Descobertas

O artigo não apresenta novos dados de desempenho experimental, mas sim uma análise estrutural de benchmarks existentes. Os estudos de caso demonstram que:

• Identificação de Lacunas: A maioria dos benchmarks pontua um "proxy" (por exemplo, uma resposta final ou um patch de código) em vez do "produto de trabalho" completo (por exemplo, um documento revisado com mudanças rastreáveis ou um sistema implantado com procedimentos de reversão).
• Limites de Alegação: Os benchmarks atuais frequentemente suportam alegações estreitas (por exemplo, "pode gerar um patch que passa nos testes"), mas são frequentemente interpretados como alegações mais amplas (por exemplo, "pode realizar engenharia de software"). O framework proposto esclarece esses limites.
• Utilidade do Inventário: O inventário de 18 atividades de trabalho mapeia com sucesso para diversos benchmarks, revelando que muitas avaliações atuais cobrem apenas parcialmente atividades específicas (por exemplo, usar "recuperação" como proxy para "investigação" sem testar a seleção ou reconstrução de evidências).

Significado e Alegações

O artigo alega modestamente fornecer uma estrutura mínima de relatório para manter as pontuações de benchmarks de trabalho intelectual vinculadas ao trabalho que elas realmente representam. Ele não alega substituir evidências de implantação ou fornecer uma teoria completa da qualidade dos benchmarks.

• Interpretabilidade: O significado principal é tornar explícita a evidência fornecida por uma pontuação de benchmark. Ao declarar qual atividade é testada, sob qual ambiente e qual produto é pontuado, as partes interessadas podem interpretar melhor o que uma pontuação implica sobre a capacidade do mundo real de um sistema.
• Prevenção de Alegações Excessivas: O framework visa reduzir "alegações de capacidade excessivamente amplas" forçando os relatórios de benchmarks a reconhecerem as lacunas entre a tarefa testada e a alegação de trabalho mais ampla.
• Direção Futura: Os autores sugerem que os benchmarks futuros devem avançar para pontuar produtos de trabalho mais diretamente (por exemplo, mudanças de estado executáveis, artefatos revisados) e que o inventário de atividades de trabalho deve ser tratado como um ponto de partida para revisão e expansão com base em fluxos de trabalho observados e padrões profissionais.

O artigo conclui que, embora estudos de implantação permaneçam necessários para alegações sobre produtividade e valor organizacional, os benchmarks servem a um papel distinto como evidência pública, repetível e comparável pré-implantação. Essa evidência é mais útil quando suas limitações em relação à atividade de trabalho, ao ambiente e ao produto são declaradas explicitamente.