Resumo Técnico: Rumo à Engenharia de Avaliação: Um Estudo Empírico de Harnesses de Avaliação de ML no Mundo Real

1. Declaração do Problema

A avaliação de Aprendizado de Máquina (ML) sustenta o progresso da IA, contudo a infraestrutura de software que executa essas avaliações — conhecida como harnesses de avaliação — recebeu atenção limitada sob uma perspectiva de Engenharia de Software (ES). Embora a literatura existente se concentre em o que avaliar (métricas, benchmarks, capacidades), ela trata os próprios harnesses como ferramentas transparentes, em vez de produtos de software engenheirados com fluxos de trabalho operacionais distintos, modos de falha e compensações de design.

Essa lacuna gera uma falta de compreensão sobre a Engenharia de Avaliação (EvalEng): as preocupações de ES que surgem da operacionalização da avaliação, incluindo design de harness, gerenciamento de dependências, correção de pontuação e integridade dos resultados. Sem essa compreensão, a confiabilidade da avaliação de ML é comprometida por questões como contaminação de benchmarks, resultados irreproduzíveis e erros silenciosos de pontuação que são difíceis de detectar em infraestruturas complexas.

2. Metodologia

Os autores conduziram um estudo empírico em larga escala de 57 harnesses de avaliação de código aberto e 19.638 issues do GitHub (relatórios de bugs, solicitações de recursos e perguntas de uso) coletados até 6 de janeiro de 2026. O estudo empregou uma metodologia de quatro estágios:

1. Coleta de Harnesses: Os pesquisadores identificaram 57 harnesses a partir de fontes curadas (por exemplo, Awesome Production ML List) e expandiram a cobertura por meio de pesquisas no GitHub baseadas em palavras-chave. Os critérios de inclusão exigiam funcionalidade explícita de avaliação/benchmarking, invocação de modelos e manutenção ativa (500+ estrelas, atividade nos últimos 12 meses).
2. Extração de Fluxo de Trabalho: Utilizando ordenação de cartões aberta iterativa e comparação constante em documentação e execução local, a equipe derivou um modelo hierárquico de fluxo de trabalho. Esse processo atingiu saturação teórica no 51º harness.
3. Mineração de Issues: A equipe recuperou 19.638 issues dos 57 harnesses (abrangendo 59 repositórios).
4. Classificação: Uma abordagem híbrida combinou anotação manual com classificação por Modelo de Linguagem Grande (LLM).
   • Anotação Manual: Uma amostra estatisticamente significativa de 377 issues foi rotulada manualmente por dois autores para estabelecer uma taxonomia para estágios de fluxo de trabalho e causas raiz. A confiabilidade interavaliador foi alta (Cohen's $\kappa > 0,87$).
   • Calibração de LLM: Um classificador baseado em Claude Haiku 4.5 foi calibrado contra rótulos de consenso humano e aplicado ao corpus completo para mapear issues para estágios de fluxo de trabalho e categorias de causas raiz.

3. Principais Contribuições

O artigo estabelece uma base empírica para a EvalEng por meio de quatro contribuições primárias:

1. Um Modelo de Fluxo de Trabalho Unificado: Um modelo de cinco estágios, nove etapas e 34 estratégias descrevendo o ciclo operacional da avaliação de ML (Provisionamento $\to$ Especificação $\to$ Execução $\to$ Avaliação $\to$ Relatórios).
2. Mapeamento Empírico de Issues: Uma classificação de 16.560 issues relevantes para fluxo de trabalho no GitHub entre os 57 harnesses, identificando onde ocorre o atrito operacional.
3. Taxonomia de Causas Raiz: Uma taxonomia de dez categorias de desafios operacionais, distinguindo entre defeitos de software (por exemplo, erros algorítmicos) e lacunas de capacidade (por exemplo, recursos não implementados).
4. Identificação de Lacuna de Adoção: Uma análise revelando lacunas significativas em capacidades orientadas à produção, como quantificação de incerteza e alerta de regressão.

4. Principais Resultados

RQ1: Fluxo de Trabalho Operacional

O estudo identificou um fluxo de trabalho de cinco estágios:

• Provisionamento: Configuração de ambiente e configuração de credenciais.
• Especificação: Definição de entradas (modelos, conjuntos de dados) e juízes de pontuação.
• Execução: Execução do Sistema Sob Teste (SUT).
• Avaliação: Cálculo de métricas e agregação de pontuações.
• Relatórios: Visualização de resultados e alertas sobre regressões.

Descobertas:

• Domínio Offline: A maioria dos harnesses (40,4% Suites Padronizadas de LLM, 21,1% Bibliotecas de Domínio Restrito) está restrita a fluxos de trabalho estáticos e offline. Apenas 17,5% (Plataformas de LLM Full-Stack) abrangem todos os cinco estágios.
• Lacunas de Estratégia: Embora a instalação (git clone, pacotes Python) seja quase universal, a implantação em contêineres é rara (21,1%). A amostragem de tráfego de produção é suportada por apenas 7,0% dos harnesses.
• Deficiências em Relatórios: Relatórios são o estágio menos suportado. Apenas 22,8% dos harnesses quantificam incerteza, e apenas 8,8% fornecem alerta de regressão.

RQ2: Causas Raiz de Desafios Operacionais

O estudo classificou 16.560 issues em dez causas raiz. As três principais causas representam 61,7% de todas as issues:

1. Lacuna de Recurso Não Implementado (24,3%): Funcionalidade necessária está ausente.
2. Deficiência de Documentação (20,3%): Instruções ausentes ou desatualizadas.
3. Lacuna de Validação (17,2%): Falta de validação de entrada/saída.

Padrões Específicos de Arquétipo:

• Suites Padronizadas de LLM: Alto volume de issues; a causa raiz secundária é Quebra de Dependência Externa (8,9%) devido à dependência de conjuntos de dados upstream em constante mudança.
• Sondas Específicas de Tarefa: A causa raiz secundária é Erro Algorítmico (11,9%), pois a pontuação adaptada ao domínio carece de implementações de referência.
• Plataformas Full-Stack: A causa raiz secundária é Incompatibilidade de Contrato de Interface (10,6%) devido à integração complexa de múltiplos componentes.
• Bibliotecas de Domínio Restrito: Deficiência de Documentação (31,8%) é a causa raiz primária, superando lacunas de recursos.

RQ3: Distribuição de Causas Raiz entre Estágios

As causas raiz não estão distribuídas uniformemente; concentram-se em estágios específicos:

• Provisionamento: Dominado por Incompatibilidade de Ambiente (16,1%) e Quebra de Dependência Externa (20,1%).
• Especificação: Concentrado em Lacuna de Recurso Não Implementado (32,8%) e Deficiência de Documentação (27,1%).
• Avaliação: Dominado por Erro Algorítmico (25,9%) e Lacuna de Validação (22,5%).
• Transversal: Lacuna de Validação é a única causa raiz que aparece acima de 10% em todos os cinco estágios, indicando uma necessidade sistêmica de melhor validação semântica.

Mudança de Fluxo de Trabalho: Os desafios mudam de questões relacionadas ao ambiente nos estágios iniciais para questões relacionadas à pontuação nos estágios posteriores.

5. Significado e Implicações

O artigo argumenta que a confiabilidade da avaliação é uma preocupação distinta de engenharia de software que requer atenção além do design de métricas.

• Para Desenvolvedores:

  • Vá além da validação de esquema para contratos de API semânticos para prevenir falhas silenciosas (por exemplo, tipos válidos, mas semântica incorreta).
  • Implemente verificação independente de oráculo (por exemplo, teste metamórfico, teste diferencial) para pipelines de pontuação, pois as saídas dos harnesses frequentemente carecem de verdade fundamental independente.
  • Adapte a manutenção a modos de falha específicos de arquétipo (por exemplo, fixação de dependências para suites de benchmark, teste de contrato para plataformas full-stack).
  • Publique documentos de especificação legíveis por máquina (semelhantes a cartões de modelo) declarando cobertura de fluxo de trabalho, dependências e padrões de desafios conhecidos.

• Para Usuários:

  • Não trate a saída do harness como verdade fundamental sem verificação independente, especialmente ao desviar de configurações de benchmark projetadas.
  • Reconheça que a maioria dos harnesses carece de quantificação de incerteza, tornando difícil distinguir lacunas reais de capacidade de artefatos do harness.

• Para Pesquisadores:

  • Trate a engenharia de avaliação como um problema de pesquisa em ES. Os frameworks existentes de MLOps e teste requerem adaptação estrutural para lidar com as restrições únicas dos harnesses de avaliação (por exemplo, sensibilidade a prompts, linhas de base em mudança e deslocamentos de distribuição de tráfego estático versus produção).
  • Investigue como definir limiares de regressão e significância estatística em ambientes onde as linhas de base não são estáveis.

O estudo conclui que melhorar a confiabilidade da avaliação requer uma abordagem holística para o design de fluxo de trabalho em todos os estágios, em vez de melhorias isoladas em métricas ou benchmarks. O modelo de fluxo de trabalho e a taxonomia de causas raiz fornecidos oferecem uma linha de base para pesquisa longitudinal para rastrear a maturação da infraestrutura de avaliação.