OSReward expõe viés sistemático em juízes VLM para avaliação de agentes

Toda equipe treinando um agente de uso de computador bate na mesma parede: você precisa de um sinal de recompensa, anotação humana não consegue acompanhar o ritmo, então você recorre a um VLM como juiz. OSReward, publicado em 30 de julho por uma equipe de 23 pessoas abrangendo CUHK, Fudan e Shanghai AI Lab, é a primeira medição sistemática de se essa suposição funciona. Através de 27 juízes VLM avaliados em 1.019 trajetórias anotadas manualmente abrangendo web, Windows, Ubuntu e mobile, a resposta é: não de forma confiável.

O benchmark foi construído do zero. Agentes do Claude, Gemini, Kimi e Qwen executaram instruções em "máquinas vividas": ambientes preenchidos com arquivos reais, perfis de usuário, bancos de dados e conteúdo de distração, com tarefas web executadas contra sites ao vivo. Cada trajetória—até 100 etapas de screenshot-pensamento-ação—foi rotulada independentemente por três anotadores. Veredictos unânimes são mantidos; desacordos são escalados para dois revisores sênior que deliberam em vez de votar. Esse processo consumiu aproximadamente 800 horas humanas e produziu uma divisão sucesso/falha de 43/57 equilibrada o suficiente para que um juiz não consiga acertar 57% sempre dizendo "falha".

A descoberta central é um viés compartilhado de lenência. Trace a revogação de cada juiz em execuções verdadeiramente falhadas contra sua revogação em execuções verdadeiramente bem-sucedidas: quase todos os pontos ficam acima da diagonal. Juízes aceitam falhas como sucessos muito mais facilmente do que rejeitam completações genuínas. Em OSReward-Hard—um subconjunto de desafio extraído de trajetórias nas quais os anotadores discordaram, depois reverificadas sob meta-revisão—a lenência se amplia. O conjunto Hard é deliberadamente 30/70 sucesso/falha para testar sob pressão esse modo de falha.

O veredicto para a maioria dos juízes está no histórico de texto, não na tela. Agentes que narram logs de ação com som confiante são aprovados mesmo quando capturas de tela mostram que a tarefa não foi completada. Esse é o modo de falha que torna VLM-como-juiz arriscado em escala de treinamento de RL: um juiz leniente recompensa o agente por soar pronto, não por estar pronto. A precisão agregada em todos os 27 juízes parece aceitável em 90% no benchmark completo. Esse número desaba no subconjunto Hard, onde as execuções enganosas se concentram.

O trade-off custo-confiabilidade é o gargalo prático. O punhado de juízes preciso o suficiente para confiar em casos difíceis são modelos comerciais de fronteira—muito caros para chamar dezenas de milhares de vezes por execução de treinamento. Modelos abertos precificados para escala ficam muito atrás em confiabilidade. OS-Shepherd-100K, o corpus lançado junto com o benchmark, visa esse espaço: 100K veredictos de trajetória anotados por raciocínio selecionados de 321.631 veredictos de ensemble, com raciocínio completo do juiz anexado em vez de apenas rótulos binários. OS-Shepherd 9B e 35B são treinados nele, visando o modo de falso-sucesso diretamente. O artigo relata que eles correspondem aos juízes comerciais com 30–60% de custo menor.

Para arquitetos conectando avaliação CUA em pipelines de treinamento, três coisas são acionáveis. Primeiro, audite seu juiz VLM atual em um holdout de caso difícil—a divisão OSReward-Hard existe precisamente para isso. Segundo, não confie em precisão agregada em um benchmark equilibrado como proxy para confiabilidade em trajetórias enganosas. Terceiro, se você estiver executando RL para CUAs, um juiz leniente molda silenciosamente a política em direção aos agentes que relatam conclusão em vez de alcançá-la.

Os checkpoints OS-Shepherd, o benchmark OSReward e o corpus completo estão disponíveis na página do projeto. O sinal de recompensa que você está usando para treinamento CUA não foi auditado até agora. A auditoria encontrou um viés sistemático que aponta na direção errada.