🤖 AI

Results and Retrospective Analysis of the CODS 2025 AssetOpsBench Challenge

Este artigo fornece uma análise retrospectiva do desafio CODS 2025 AssetOpsBench, revelando insights críticos, como a saturação das pontuações públicas de planejamento, a correlação negativa entre as avaliações públicas e privadas de execução, o impacto negligenciável do termo t-match nas classificações finais e a constatação de que estratégias bem-sucedidas dependiam mais de guardrails robustos do que de arquiteturas de agentes inovadoras.

Autores originais: Dhaval Patel, Chathurangi Shyalika, Suryanarayana Reddy Yarrabothula, Ling Yue, Shuxin Lin, Nianjun Zhou, James Rayfield

Publicado 2026-05-12

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Dhaval Patel, Chathurangi Shyalika, Suryanarayana Reddy Yarrabothula, Ling Yue, Shuxin Lin, Nianjun Zhou, James Rayfield

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

A Visão Geral: Um "Show de Cozinheiros" para Robôs de IA

Imagine uma competição de culinária de alto risco, mas, em vez de chefs, os participantes são agentes de IA (programas de computador inteligentes). O desafio, chamado CODS 2025 ASSETOPSBENCH, não era sobre preparar um prato bonito; era sobre consertar máquinas industriais quebradas (como grandes ar-condicionados e chillers) usando apenas ferramentas digitais.

Os organizadores montaram um teste de duas partes para ver quem realmente conseguiria fazer o trabalho no mundo real, e não apenas no papel. Eles queriam saber: Esses robôs de IA conseguem planejar um reparo e, em seguida, realmente executá-lo sem travar?

As Duas Trilhas: O Arquiteto vs. O Construtor

Para tornar o teste justo, os organizadores dividiram a competição em duas trilhas separadas, como dois papéis diferentes em uma equipe de construção:

Trilha 1 (O Arquiteto/Planejador): O "motor" que realmente conserta a máquina estava bloqueado. Os participantes podiam apenas alterar o projeto (o prompt). Eles precisavam escrever melhores instruções para a IA sobre como pensar e quais etapas tomar.
Trilha 2 (O Construtor/Executor): O projeto estava bloqueado. Os participantes podiam apenas alterar a equipe de construção (o código de execução). Eles precisavam criar melhores redes de segurança, lidar com erros e garantir que o robô não ficasse preso se algo desse errado.

O Que Eles Encontraram: A Armadilha do "Teste de Prática"

A descoberta mais surpreendente foi que ter um bom desempenho no teste de prática não significava que você passaria no exame real.

A Classificação Pública (O Teste de Prática): Esta era uma lista de pontuações baseada em 11 cenários de prática que todos podiam ver. Muitas equipes obtiveram pontuações perfeitas aqui.
O Teste Oculto (O Exame Real): Os organizadores então pegaram as melhores entradas e as testaram em 11 novos cenários secretos que ninguém havia visto antes.

O Resultado: A correlação entre as pontuações de prática e as pontuações secretas foi essencialmente zero. Era como um aluno tirar um "A" em um teste de matemática de prática, mas reprovar no exame final real porque as perguntas eram ligeiramente diferentes. O artigo descobriu que as pontuações "públicas" eram na verdade enganosas; elas não previam quem conseguiria lidar com o mundo industrial real e bagunçado.

Por Que Isso Aconteceu?

O artigo identifica algumas razões pelas quais o "Teste de Prática" foi uma armadilha:

O Efeito "Teto": O teste de prática era fácil demais para as principais equipes. Assim que uma equipe descobria como obter uma pontuação perfeita nas perguntas de prática, elas paravam de melhorar. Elas apenas ajustavam suas respostas para parecerem perfeitas para aquelas perguntas específicas, em vez de construir um robô que pudesse lidar com qualquer pergunta.
Os Vencedores "Guarda-Chuva": As equipes que realmente venceram o teste oculto não eram aquelas com as ideias de IA mais novas e sofisticadas. Elas eram as "Engenheiras de Guarda-Chuva". Pense nelas como os inspetores de segurança. Elas não inventaram um novo motor; apenas adicionaram freios melhores, planos de backup melhores e melhores maneiras de limpar erros quando o robô ficava confuso. Elas focaram em robustez (não travar) em vez de inovação (novas ideias).
O Problema da Matemática: A maneira como a pontuação final foi calculada tinha um pequeno defeito. Uma parte da pontuação era tão pequena que realmente não importava, mas era suficiente para embaralhar as duas principais equipes. Se você mudasse a matemática ligeiramente, o vencedor teria sido diferente. Isso mostra que a classificação era frágil.

O "Custo" do Robô

O artigo também analisou quanto "combustível" (poder de computação) os robôs usaram.

O Caro vs. O Barato: Algumas tarefas exigiam que a IA lesse milhares de páginas de histórico (caro), enquanto outras eram apenas procurar um número de telefone (barato).
A Surpresa: As tarefas que eram "baratas" em termos de poder de computação eram na verdade as mais difíceis para a IA acertar porque exigiam compreensão profunda. As tarefas "caras" eram na verdade mais fáceis porque a IA apenas precisava seguir uma lista longa e clara de etapas.

A Conclusão: O Que Isso Significa para Futuras Competições

Os autores concluem que, se você quiser testar agentes de IA adequadamente, não pode apenas olhar para uma classificação de pontuações públicas.

Não confie no teste de prática: Você precisa de um "exame final" oculto que ninguém vê até o fim.
Segurança primeiro: Os melhores agentes nem sempre são os mais inteligentes; são aqueles que sabem como lidar com erros sem quebrar.
Verifique sua matemática: Se seu sistema de pontuação for muito sensível a pequenas mudanças, seu vencedor pode ser apenas uma coincidência.

Em resumo, este artigo é uma "análise pós-jogo" que nos diz: Construímos um ótimo teste, mas aprendemos que o placar que mostramos ao público estava mentindo sobre quem era realmente o melhor. Os verdadeiros vencedores foram aqueles que construíram os robôs mais seguros e confiáveis, e não aqueles que pareciam melhores no papel.

Resumo Técnico: Resultados e Análise Retrospectiva do Desafio CODS 2025 ASSETOPSBENCH

Declaração do Problema

O artigo aborda o desafio crítico de avaliar sistemas de IA multiagente em cenários industriais do mundo real, especificamente no domínio "Indústria 4.0" de gestão de ativos físicos. Embora avanços recentes em agentes de Modelos de Linguagem de Grande Porte (LLM) tenham demonstrado capacidades em raciocínio e uso de ferramentas, a transição desses sistemas de benchmarks laboratoriais para implantação revela lacunas significativas de avaliação. Benchmarks estáticos frequentemente favorecem tarefas de especificação restrita e facilmente otimizáveis, falhando em capturar comportamentos essenciais de implantação, como robustez no uso de ferramentas, execução que preserva a privacidade e orquestração multi-etapa. Os autores argumentam que a avaliação baseada em competições oferece uma alternativa principial aos benchmarks estáticos ao expor modos de falha (por exemplo, falhas progressivas de raciocínio) que só emergem sob avaliação cega e iterativa. O problema específico tratado é o design e a análise retrospectiva de uma competição que combina avaliação de agentes, um domínio industrial de ativos físicos e implantação com restrições de privacidade, visando determinar o que tal design de avaliação realmente mede e onde seus incentivos podem não estar alinhados com a capacidade real.

Metodologia

Os autores conduziram uma análise retrospectiva do desafio CODS 2025 ASSETOPSBENCH, hospedado na plataforma Codabench. A metodologia envolveu uma análise multidimensional de artefatos da competição, em vez de um simples relatório de classificação.

Design da Competição: O desafio utilizou um framework de "cenário oculto" com duas trilhas complementares:
- Trilha 1 (Planejamento): Os participantes otimizaram o prompt de planejamento e a construção do Grafo Acíclico Direcionado (DAG) (track1_planning.py), enquanto o executor e os agentes de domínio permaneceram congelados.
- Trilha 2 (Execução): Os participantes otimizaram a lógica de execução do fluxo de trabalho, incluindo caminhos paralelos, agregação de contexto e mecanismos de fallback (track2_execution.py), enquanto o prompt de planejamento e os agentes permaneceram congelados.
Protocolo de Avaliação: As submissões foram avaliadas contra 11 cenários públicos de desenvolvimento e 11 cenários de avaliação ocultos (Fase 1 e Fase 2). A fórmula de pontuação combinou pontuações públicas ( $S_{pub}$ ), pontuações ocultas ( $S_{priv}$ ) e um sinal de correspondência semântica ( $\tau$ ): $C_t = 0.6 S_{pub}^t + 0.3 S_{priv}^t + 0.1 \tau_t$ .
Coleta de Dados: A análise agregou dados de 149 equipes registradas (349 vagas de membros), um log de servidor de 300 linhas de tentativas de submissão e 331 artefatos acessíveis no nível de código-fonte.
Dimensões Analíticas: Os autores analisaram o corpus em cinco dimensões:
1. Participação: Estatísticas de funil e composição das equipes.
2. Comportamento de Submissão: Curvas de aprendizado, progressão de pontuação e confiabilidade.
3. Robustez da Classificação: Sensibilidade das classificações à composição da métrica e alinhamento público-oculto.
4. Custo Computacional: Uso de tokens, chamadas de API e impressões digitais de duração em tempo real (wall-clock).
5. Atribuição de Estratégia: Agrupamento de padrões de implementação (arquétipos) e sua correlação com o desempenho.
Validação: A infraestrutura foi cruzada com uma "Lista de Verificação de Avaliação de Agentes" recentemente publicada para benchmarks confiáveis, a fim de identificar lacunas de design.

Principais Contribuições

Primeiro Benchmark Industrial de Agentes com Restrições de Privacidade: O artigo documenta o primeiro benchmark de trilha competitiva a combinar conjuntamente tarefas multi-etapa de agentes, um domínio industrial de ativos físicos (chillers, unidades de tratamento de ar) e implantação com restrições de privacidade (usando isolamento em contêineres para prevenir vazamento de dados).
Framework Retrospectivo de Nove Dimensões: Os autores propõem um modelo analítico estruturado de nove dimensões para futuras competições de agentes, indo além das métricas agregadas de classificação para incluir funis de participação, análise de saturação de pontuação, impressões digitais computacionais e agrupamento de estratégias.
Evidência Empírica de Desalinhamento Público-Oculto: O estudo fornece evidências estatísticas concretas de que as posições no leaderboard público não preveem a robustez oculta, particularmente em tarefas de execução.
Taxonomia de Estratégias e Análise de Arquétipos: O artigo introduz uma taxonomia de estratégias de agentes, distinguindo entre arquétipos de "planejamento" (engenharia de prompts) e "execução" (engenharia de guardrails), revelando que os melhores desempenhos frequentemente dependem de tratamento robusto de erros em vez de arquiteturas inovadoras.

Resultados

Participação e Desistência: Das 149 equipes registradas, apenas 11 alcançaram status totalmente ranqueado em ambas as trilhas. A taxa de desistência foi significativa, com uma taxa de falha de 17,7% nas tentativas de submissão devido a problemas de conformidade com a plataforma (violações de formato de embalagem/fluxo de trabalho), estabelecendo uma sobrecarga fixa de infraestrutura para avaliação de agentes.
Correlação entre Pontuação Pública e Oculta:
- Trilha de Planejamento: Correlação moderada entre pontuações públicas e ocultas ( $\rho = 0,69$ ), embora as pontuações públicas tenham mostrado otimismo sistemático.
- Trilha de Execução: Sem correlação entre pontuações públicas e ocultas ( $\rho = -0,13, p = 0,71$ ). As pontuações públicas de execução foram estatisticamente indistinguíveis de ruído aleatório em relação ao desempenho oculto.
Saturação de Pontuação e Sensibilidade: O leaderboard público de planejamento saturou em 72,73% para quatro equipes, tornando o sinal público incapaz de discriminar entre os melhores desempenhos. Além disso, a classificação final foi altamente sensível à composição da fórmula de pontuação. O termo "t-match", destinado a contribuir com 10% de peso, foi numericamente inerte devido a diferenças de escala (0–1 vs. 0–100), contribuindo com no máximo 0,05 pontos. O redimensionamento desse termo ou o ajuste dos pesos das trilhas teria trocado as duas primeiras equipes.
Inversão de Custo Computacional: A análise das pegadas computacionais revelou que o domínio "mais barato" (Previsão de Séries Temporais, TSFM) foi o mais sensível a prompts (maior variância de estratégia), enquanto o domínio "mais caro" (Ordens de Serviço, WO) foi o mais robusto. Isso sugere que ponderar benchmarks pelo custo de tokens poderia medir inadvertidamente a sensibilidade a prompts em vez da capacidade do agente.
Padrões de Estratégia:
- Planejamento: As estratégias foram difusas, com alto ruído no agrupamento. As melhores submissões frequentemente alcançaram saturação por meio de elaboração de prompts (por exemplo, exemplos mais longos, catálogos de agentes) sem alterações arquiteturais.
- Execução: As estratégias foram altamente concentradas em três agrupamentos apertados. Os melhores desempenhos foram identificados como "engenheiros de guardrails" que melhoraram a seleção de respostas, limpeza e lógica de fallback em vez de introduzir novas arquiteturas de agentes.
Modos de Falha: A alucinação foi encontrada como um modo de falha acoplado fortemente negativamente correlacionado com a qualidade geral da tarefa ( $r \approx -0,93$ ), servindo como um indicador principal de falha mais ampla. Tarefas de ordem de serviço envolvendo raciocínio de longo horizonte sobre registros históricos consistentemente formaram o teto de capacidade.

Significado e Alegações

O artigo afirma que o desafio CODS 2025 ASSETOPSBENCH demonstra por que competições de agentes devem ser analisadas como instrumentos de avaliação e não meramente como mecanismos de classificação. Os autores afirmam que sua análise revela falhas críticas no design atual de benchmarks, especificamente:

Saturação do Leaderboard: Sinais públicos podem saturar rapidamente, falhando em discriminar entre sistemas de alto desempenho.
Desalinhamento Público-Oculto: A iteração pública pode recompensar estratégias que superajustam a conjuntos específicos de cenários, levando a uma desconexão entre a posição pública e a robustez oculta.
Falhas no Design de Métricas: Funções de pontuação compostas são sensíveis a escolhas de escala numérica (por exemplo, o termo t-match), o que pode alterar arbitrariamente as classificações.
Sucesso Centrado em Guardrails: Em cenários industriais complexos, o melhor desempenho é frequentemente impulsionado por tratamento robusto de erros e controle de contexto ("engenharia de guardrails") em vez de inovações arquitetônicas inovadoras.

Os autores concluem que futuras competições de agentes devem isolar dimensões de capacidade entre trilhas, trazer à tona subpontuações conscientes de habilidades, garantir que componentes de pontuação sejam numericamente comparáveis e tratar metadados de equipe e código versionado como entregas principais. Eles posicionam sua retrospectiva de nove dimensões como um modelo reutilizável para futuros benchmarks, a fim de garantir que as competições funcionem como instrumentos científicos rigorosos capazes de publicar evidências sobre o que foi realmente medido.