Seu LLM as a judge é um mentiroso confiante: como criar verificadores melhores — Browserbase

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Your LLM Judge Is a Confident Liar: Building Better Verifiers — Browserbase · Canal: AI Engineer · 20:32 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA

Resumo

Miguel, da Browserbase, e Corby, pesquisador da Microsoft, apresentam um verificador para avaliar agentes que usam a web, criado para enfrentar as limitações de ambientes determinísticos e de LLM as a judge existentes. O método usa rubricas específicas, seleciona capturas de tela relevantes como evidência e separa a qualidade do processo do resultado final, distinguindo falhas controláveis das que dependem do ambiente. Em testes, o verificador reduziu falsos positivos e alcançou concordância com avaliadores humanos; dados filtrados por ele também levaram a modelos de melhor qualidade. Os autores discutem ainda como auto research pode acelerar a construção de verificadores, os limites desse processo e a publicação de um benchmark com rótulos humanos.

Pontos-chave

• A natureza aberta e mutável da web torna difícil verificar tarefas com ambientes totalmente determinísticos.
• Verificadores existentes podem estar muito confiantes e ainda assim classificar incorretamente o sucesso de um agente.
• O verificador proposto cria uma rubrica alinhada ao que foi pedido e avalia cada critério com capturas de tela relevantes da trajetória.
• O método separa uma pontuação do processo de um resultado booleano sobre o que um usuário razoável consideraria sucesso.
• Erros em um critério não devem se propagar para outros critérios independentes da rubrica.
• A avaliação distingue falhas controláveis pelo agente de obstáculos externos, como um produto fora de estoque.
• O verificador reduziu falsos positivos e concordou com avaliadores humanos em nível comparável à concordância entre os próprios humanos.
• Trajetórias filtradas pelo verificador produziram dados de fine-tuning de maior qualidade e modelos melhores nos experimentos apresentados.
• Um loop de auto research construiu um verificador em cerca de um dia, mas alcançou apenas aproximadamente 70% da concordância obtida pelo sistema desenvolvido pelos pesquisadores.
• Os autores publicaram o trabalho, o código dos experimentos e rótulos humanos; também investigam uma aplicação a tarefas de desktop.

Capítulos

Início	Capítulo	Resumo
00:01	Por que verificadores melhores são necessários	Os palestrantes explicam por que a web aberta e mutável dificulta avaliações determinísticas e relatam erros confiantes de verificadores existentes.
04:46	Como funciona o verificador universal	O sistema cria uma rubrica, seleciona capturas de tela relevantes e produz pontuações que distinguem processo e resultado.
10:31	Validação com avaliadores humanos e dados de treino	Os experimentos mostram a concordância com rótulos humanos e a utilidade de filtrar trajetórias para produzir dados de melhor qualidade.
15:45	Auto research, código aberto e novos benchmarks	Os palestrantes discutem como a automação acelera experimentos, apresentam os materiais publicados e comentam a criação de um benchmark.
17:49	Aplicações a tarefas de desktop	Na sessão de perguntas, Corby descreve planos para adaptar o verificador a tarefas corporativas realizadas no desktop.
19:00	Como evitar overfitting aos rótulos humanos	Os pesquisadores explicam que reservaram trajetórias não usadas durante o desenvolvimento para avaliar o sistema com rótulos independentes.

Citações

Em muitas situações, eles estão muito confiantes e errados. — 03:10

Você não está treinando um agente melhor. Está treinando um mentiroso mais competente. — 03:42

Queríamos avaliar apenas o que foi pedido, sem critérios extras. — 06:22

Construir verificadores é tão importante quanto construir os próprios modelos. — 15:14

Conceitos e entidades

• Browserbase (empresa): Empresa de infraestrutura para executar agentes na web por meio de navegadores na nuvem.
• Microsoft (empresa): Empresa onde Corby trabalha como pesquisador e na qual se investigam aplicações do verificador.
• universal verifier (conceito): Verificador apresentado na palestra, que usa rubricas e evidências da trajetória para avaliar agentes que realizam tarefas na web.
• LLM as a judge (conceito): Uso de um LLM para julgar se a saída ou a trajetória de um agente atende aos critérios de uma tarefa.
• rubric (conceito): Conjunto de critérios explícitos que define o que conta como sucesso em uma tarefa.
• process score (conceito): Pontuação que pode conceder crédito parcial pelo processo seguido pelo agente.
• outcome verifier (conceito): Avaliação booleana que indica se o resultado da tarefa corresponde ao que um usuário razoável esperaria.
• KUA Verifier Bench (conceito): Benchmark mencionado na palestra, que inclui rótulos humanos e dados para avaliar verificadores.
• auto research (conceito): Uso de um loop automatizado de pesquisa e experimentação para desenvolver ou otimizar sistemas.
• WebVoyager (conceito): Benchmark de tarefas na web mencionado como exemplo de benchmark que usa um LLM como verificador.
• Mind2Web (conceito): Benchmark de tarefas na web citado na palestra entre os benchmarks com verificadores baseados em LLM.
• OSWorld (conceito): Benchmark de uso de computador mencionado como referência para avaliação de agentes.
• FARS 7B (modelo): Modelo de agente de navegador descrito por Corby como usado em um experimento de avaliação.
• Opus 4.6 (modelo): Modelo indicado pelos palestrantes como base dos resultados de auto research relatados.
• Stagehand (ferramenta): Framework open source da Browserbase que Miguel diz desenvolver há cerca de um ano e meio.

Tradução completa (pt-BR)

00:01 [música] Boa tarde a todos. Obrigado por terem vindo. Espero que estejam aproveitando muito a expo até agora. Estamos na reta final, mas sei que tem sido uma expo maravilhosa, maravilhosa, pelo menos para mim. Então, espero que estejam aprendendo bastante e que possamos ensinar mais um pouco. Sou Miguel. Sou líder técnico da nossa plataforma de agent na Browserbase. Para quem não conhece, a Browserbase é uma

00:34 empresa de infraestrutura para fazer deploy de agents na web. Ela basicamente desbloqueia toda a web, não apenas o que é facilmente acessível, gerenciando browsers na nuvem e todo o runtime necessário para fazer automação agentic na web em escala. Então, vamos lá. >> E eu sou Corby. Sou pesquisador na Microsoft e tenho colaborado com a Browserbase para ajudar a criar verifiers realmente bons. >> Hoje, estamos aqui para falar sobre uma pesquisa que publicamos há cerca de um mês

01:06 . Ela é sobre evals, ambientes de RL e juízes de LLM como verifiers. Desde o início — trabalho há cerca de um ano e meio neste framework open source chamado stchen —, como todo bom produto agentic precisa fazer, estávamos criando evals para garantir que as mudanças que introduzíamos no framework e os recursos do modelo continuassem melhorando e avançando nesses evals

01:39 . No começo, todos esses evals eram ambientes determinísticos. Era relativamente simples. Os recursos dos modelos eram um tanto limitados e, por isso, conseguíamos criar muitos ambientes determinísticos. À medida que os recursos dos modelos continuaram melhorando e nós continuamos aprimorando o agent harness, isso simplesmente deixou de ser escalável. Passamos a corrigir constantemente ou gerar sites estáticos, criar trajetórias mais longas com muitos checkpoints para garantir que os evals fossem determinísticos e pudessem ser

02:09 verificados. Há muitos problemas diferentes ao automatizar a web em escala e verificar se aquilo que você pretendia fazer realmente deu certo. A web é muito aberta. Não há apenas um caminho para a resposta correta. Não existe ground truth. Às vezes, a web muda e o produto que você estava verificando já não está mais lá. Isso acaba com todo o determinismo do seu ambiente, e há bloqueios. Há muitos erros do ambiente

02:39 que você enfrenta e que não permitem obter um sinal determinístico verificável. Então, recorremos ao que a maioria das pessoas faz: tentar usar um juiz de LLM para ajudar a melhorar e escalar essa operação. Mas logo descobrimos que muitos dos principais benchmarks — alguns de vocês talvez conheçam o OSWorld, para uso de computador — têm benchmarks análogos para uso da web, chamados Online-Mind2Web e WebVoyager.

03:10 Eles vêm com juízes de LLM como verifiers. E o que percebemos ao usar nossos anotadores humanos especialistas para verificar o verifier é que, em muitos casos, ele está completamente errado, mas com muita confiança. Isso leva a resultados em que não dá para confiar. Então, rapidamente percebemos que, mesmo que você usasse isso como recompensa de RL ou como sinal para melhorar seu harness e a pesquisa automatizada, não estaria treinando um agent melhor. Estaria apenas

03:42 treinando um mentiroso mais competente. Em um caso de uso real na Microsoft, treinamos este modelo FARS 7B, que é um agent de navegador web. Avaliamos o mesmo modelo no mesmo benchmark usando o juiz oficial do WebVoyager, que é o GPT-4o. Ele disse que a taxa de sucesso era de 74%. Mas há uma diferença enorme em relação à verdade: quando usamos nosso novo verifier universal, que tem alta concordância com os rótulos humanos, esse

04:14 número cai rapidamente para algo como 38%. Há uma diferença enorme entre o que os verifiers existentes dizem e o que é realmente o ground truth. Então, precisávamos encontrar uma maneira de fechar essa lacuna. Os verifiers existentes têm muitas fraquezas. Eles usam modelos menores e muito menos inteligentes como juiz de LLM; usam o o4-mini ou o GPT-4o. Nem sequer usam rubrics. As rubrics são o elemento mais importante, porque é preciso atribuir crédito a quem merece. Eles não analisam as capturas de tela relevantes ou

04:46 tentam analisar todas as capturas de tela e logo se perdem, ultrapassando a context window do juiz de LLM. Às vezes, nem sequer analisam a resposta final ou o histórico de ações do modelo. Nosso verifier cobre todos esses pontos. Em linhas gerais, funciona assim — você pode consultar o artigo para mais detalhes. Dada uma tarefa como reservar o voo mais barato de Seattle para Boston, a primeira coisa que fazemos é gerar uma rubric muito boa, e vou dar alguns exemplos. Uma rubric pode ter umas 10 critérios diferentes que definem o que é ter sucesso. E

05:18 então, com base nos critérios da rubric, analisamos a trajetória do agent. Neste caso, todas as capturas de tela são as evidências do ground truth. Classificamos quais capturas de tela da trajetória são mais relevantes para cada critério. Em seguida, usamos esse conjunto das evidências mais relevantes, as top K, para determinar se o critério foi atendido ou não e se há alguma diferença ou contradição entre o que o agent disse que fez e o que o estado do ambiente realmente mostrou. Com isso, geramos

05:50 uma rubric pontuada, que chamamos de pontuação de processo, porque em alguns casos ela concede crédito parcial. Também geramos um valor booleano de resultado, basicamente para indicar se o agent concluiu a tarefa de acordo com o que um usuário razoável esperaria. Este é um exemplo da saída da rubric. Basicamente, é uma lista de critérios, e o verifier de resultado é uma indicação de verdadeiro ou falso, acompanhada de uma explicação sobre

06:22 por que um usuário razoável esperaria que essa trajetória tivesse dado certo ou não. Havia quatro princípios orientadores quando criamos este verifier universal. O primeiro diz respeito à criação da rubric: queríamos avaliar apenas o que foi solicitado, sem critérios adicionais. Também não queríamos que erros se propagassem de um critério da rubric para outro. Queríamos que fossem isolados. Vou dar um exemplo disso. Também era necessário analisar as capturas de tela do ground truth. Isso é indispensável. Os agents

06:52 muitas vezes afirmam com excesso de confiança que fizeram algo quando, na verdade, não fizeram. Por isso, é preciso analisar o estado do ground truth. Também precisávamos separar o que o agent podia controlar daquilo que não podia controlar. O agent opera em um navegador web, que é um ambiente que nem sempre consegue controlar. Também vou mostrar alguns exemplos disso. Este é um exemplo de como é uma rubric boa e uma ruim. A tarefa é encontrar um hotel barato em Jacarta para essas datas e, em seguida, usar o endereço do hotel

07:24 para procurar a cafeteria mais próxima e informar o nome e o endereço dela. Uma rubric ruim, que vimos ser gerada, incluiria um critério do tipo: “Informe o preço total da estadia no hotel”. Esse é, na verdade, um critério adicional que não foi solicitado na tarefa, mas vimos muitas rubrics geradas ingenuamente fazerem algo assim. Elas diminuiriam artificialmente as pontuações porque o agent não fez algo que não lhe foi pedido. Quanto a evitar que os erros se propaguem,

07:55 há erros muito sutis, porque muitas tarefas se encadeiam quando são tarefas de várias etapas. Neste exemplo, a tarefa era determinar o patrimônio líquido da pessoa com o sobrenome mais longo entre os membros do NSYNC e dos Backstreet Boys. Certo. Neste caso, o agent pensou erroneamente que Timberlake tinha o sobrenome mais longo, que tem apenas 10 letras, quando, na verdade, Kirkpatrick tinha o sobrenome mais longo. Então, o modelo cometeu um erro de aritmética em um dos critérios de

08:27 a rubrica, e isso não deveria se propagar para o próximo critério da rubrica, que é informar o patrimônio líquido da pessoa que você escolheu. Certo? Então, se você conseguir informar com precisão o patrimônio líquido de Timberlake, não deveria ser penalizado neste critério. Deveria ser penalizado apenas naquele. Alucinações são o principal ponto em que realmente queríamos nos concentrar. Então, nesta tarefa, este é um exemplo de uma alucinação muito sutil: você queria encontrar algumas informações sobre um modelo de legendagem de imagens, e o agent

08:58 disse que esse modelo teve um aumento de 6,2% em uma pontuação CIDEr, mas, na realidade, o resumo do artigo correspondente dizia que o aumento foi de apenas 2,8% na pontuação CIDEr. Então, foi um erro muito sutil que até mesmo humanos não perceberiam, a menos que um LLM o apontasse. Isso dá uma visão geral de como as pontuações de processo e as pontuações de resultado diferem. No caso que mencionamos, um dos princípios era separar falhas controláveis das incontroláveis.

09:28 Então, se a tarefa for comprar, digamos, este brinquedo de pelúcia da Amazon, e o agent procurar o brinquedo corretamente, mas descobrir que está sem estoque e não puder prosseguir, dizemos que o agent recebe a pontuação máxima por fazer o melhor possível para atingir o objetivo, mas o resultado ainda não foi alcançado, porque ele não conseguiu comprar o produto que queria, já que estava sem estoque. Então, basicamente, enumeramos vários cenários que poderiam ocorrer e como atribuiríamos

09:59 crédito se o agent conseguisse encontrar, de outra maneira, um brinquedo de pelúcia semelhante como alternativa. Ele ainda teria sucesso nesse caso, em ambos os casos, e seria penalizado se cometesse um erro controlável. Seria penalizado se alucinasse, e assim por diante. Então, basicamente, enumeramos um esquema com todos os possíveis modos de falha e como atribuiríamos crédito a cada um deles, e o verificador universal segue esse esquema. Então, basicamente, para avaliar o

10:31 verificador e realmente determinar se conseguimos melhorar iterativamente a precisão dele, começamos a elaborar muitos experimentos com especialistas humanos e criamos uma plataforma inteira para coletar dados sobre o que chamamos de rótulos de referência, que também disponibilizamos no Cool Verify Bench para que outras pessoas possam usá-los no treinamento. O processo que seguimos foi o seguinte. Primeiro, mostrávamos toda a trajetória de evidências aos verificadores humanos, e os anotadores avaliavam com base nas evidências e no resultado de

11:02 todas as ações realizadas pelo agent. Depois, eles recebiam a avaliação do verificador universal e eram solicitados a dizer se concordavam ou discordavam da avaliação do verificador universal. Descobrimos que esse era um sinal muito confiável para determinar se estávamos seguindo na direção certa, porque vou passar diretamente para este ponto: o verificador começou a corrigir os humanos

11:34 em determinado momento. Ele identificava coisas que os humanos deixavam passar. E, no fim, o resultado do verificador universal nesses rótulos de referência foi que conseguimos reduzir os falsos positivos de quase metade a zero. O kappa de Cohen é uma métrica para medir a concordância entre anotadores. E o que podemos ver aqui é que o verificador universal concorda com os humanos com a mesma frequência com que os humanos concordam entre si. Então, podemos ver uma pontuação kappa de Cohen de

12:06 0,58, em comparação com os dois anotadores por tarefa, para os quais também calculamos o kappa de Cohen para ver o quanto concordavam entre si. Outra maneira de verificar a qualidade do nosso verificador é treinar de fato com dados filtrados por ele. Então, fizemos um experimento em que mantivemos constante o número de exemplos de treinamento. Neste

12:37 caso, eram 3 mil ou 9 mil trajetórias de treinamento, mas filtramos essas trajetórias de acordo com a aprovação ou não do nosso verificador. Ao fazer SFT, que foi o que fizemos aqui, você quer treinar apenas com exemplos de SFT que sejam trajetórias realmente bem-sucedidas. Então, se você treinar com 3 mil trajetórias filtradas pela pontuação de processo do nosso verificador universal, obterá um modelo de qualidade muito superior à de um modelo treinado com um verificador pior, como o nosso verificador de referência. E isso também se manteve em

13:09 escalas maiores. Então, basicamente, esse experimento nos mostrou que, se você tem um verificador de qualidade superior, pode filtrar dados de qualidade superior, e treinar com esses dados leva a um modelo de qualidade superior. Essa foi a prova experimental definitiva, além da concordância com os humanos, de que esse modelo, esse verificador, funciona e é confiável em um cenário real de produção. A última coisa que fizemos, meio que como um projeto paralelo, foi tentar determinar

13:41 se a pesquisa automática com IA consegue criar o mesmo verificador que criamos. Basicamente, Miguel e eu nos sentamos por três semanas para criar o verificador universal, ajustar os prompts e escrever o código. Ao longo dessas três semanas, fizemos cerca de 30 experimentos diferentes para determinar se o verificador que estávamos criando concordava com os rótulos humanos. Certo. E é isso que a pontuação kappa de Cohen no eixo Y mede. Ela mede se um sistema de verificação individual concorda

14:14 com os rótulos humanos. A linha azul representa o modelo — o sistema que Miguel e eu estávamos criando —, esse sistema de pesquisa automática, esse verificador universal. Depois, queríamos ver se, removendo tudo o que fizemos, a IA conseguiria, em um ciclo de pesquisa automática, criar o mesmo verificador que criamos, com o mesmo nível de qualidade e fidelidade. É isso que as linhas vermelha e verde representam. A linha vermelha mostra se, removendo todo o nosso código e os prompts, a IA conseguiria reproduzi-lo.

14:44 A conclusão a que chegamos é que, embora tenhamos levado cerca de três semanas para criar esse verificador, um ciclo de pesquisa automática conseguiria fazê-lo em cerca de um dia. Ele executou o mesmo número de experimentos em aproximadamente um dia. No entanto, só atingiu cerca de 70% da concordância que o nosso verificador conseguiu alcançar. Então, ainda há uma diferença. A conclusão que eu tiraria disso é que você pode usar pesquisa automática para criar métricas e verificadores, pelo menos para acelerar a

15:14 experimentação. Mas provavelmente ainda é necessário algum nível de intervenção humana. Mais uma vez, esses resultados foram obtidos com Opus 4.6. Ainda não testei com Fable. Talvez se saia melhor, mas é uma referência inicial bastante poderosa e avançou bastante. Então, a pesquisa automática não só pode ajudar você a criar um modelo, como também pode ajudar a criar um verificador, o que achamos bem legal. E criar verificadores é tão importante quanto criar os próprios modelos: essa é uma das conclusões que quero deixar para vocês

15:45 Então, sim, e só para enfatizar ainda mais: a linha verde representa o verificador de pesquisa automática, inicializado com muitas das descobertas que fizemos ao longo das três semanas de experimentação. Nessa otimização, ele conseguiu atingir percentuais mais altos do que os que havíamos alcançado até então. Portanto, combinar a intuição humana com ciclos de pesquisa automática tem se mostrado a estratégia mais poderosa para muitas tarefas de pesquisa.

16:17 Todo o trabalho é open source. O artigo foi publicado como preprint no arXiv. O repo da Microsoft contém os rótulos de referência no Kua Verifier Bench. Ele também contém o código para executar os experimentos. Mas, além disso, essa pesquisa também resultou em um benchmark inteiramente novo. Falamos brevemente sobre Online-Mind2Web e WebVoyager. Eu passo muito tempo

16:48 tempo trabalhando com laboratórios, ajudando a garantir que possamos fornecer a eles um sinal quantitativo para melhorar seus modelos. Muitos desses benchmarks open source estão ficando saturados muito rapidamente, e é muito difícil fornecer qualquer tipo de sinal, porque parece que os dados de teste já fazem parte da distribuição dos dados de treinamento. Por isso, esse novo benchmark demonstrou ter a maior lacuna até o sucesso completo, e é minha ferramenta de uso diário para garantir que eu consiga

17:19 identificar se as capacidades do modelo são fortes, onde são insuficientes e como continuar reduzindo a lacuna. Então, >> você tinha mais slides? >> Não. >> Certo, >> podemos responder a algumas perguntas, acho, mas estamos bem de tempo. >> Sim. É. Então, a pergunta é se usamos o verificador universal para outros tipos de tarefas além de

17:49 tarefas na web. Uma coisa em que estamos trabalhando agora na Microsoft é aplicar uma versão desse verificador a tarefas de desktop, como coisas que você faria no laptop, por exemplo, workflows corporativos. Esperamos publicar outro benchmark, não só com dados da web, mas também com dados de desktop no estilo corporativo. E teríamos basicamente o mesmo tipo de verificador para isso também. Ele analisaria um pouco mais de informação porque, em desktops, você tem o terminal, mais telemetria e mais logs do que apenas o

18:20 navegador. Então, o verificador também levaria essas coisas em conta. É. Mais alguma pergunta? >> Sim. >> Eu, pessoalmente, nunca… Quando você apresentou, fiquei pensando: como você pensa sobre essa apresentação?

19:00 É. >> É. Então, a pergunta é como garantir que você não esteja ajustando demais o verificador aos rótulos humanos, porque isso é um problema. Miguel e eu passamos muito tempo trabalhando nessa questão. Uma coisa que fizemos foi separar dois conjuntos de rótulos. Tínhamos um conjunto de cerca de 150 trajetórias. Eu mesmo rotulei cerca de 50 delas e as usei para fazer hill climbing naqueles 30 experimentos. Mas

19:31 as outras cem trajetórias ficaram basicamente reservadas. Elas foram rotuladas por humanos que havíamos contratado, com uma sobreposição de 2x. Quando terminamos de criar nosso verificador, entregamos a eles, esses anotadores humanos, e cada trajetória foi rotulada por duas pessoas. Desculpem: dois humanos rotularam cada trajetória, e foi isso que publicamos no KUA verifier bench. Esses são os números que apresentamos aqui. Então, estamos bem confiantes de que não houve ajuste excessivo, porque reservamos pelo menos dois terços

20:01 dos rótulos. Não treinamos nem iteramos com base neles. >> Sim. Isso é muito importante: você não quer treinar com eles para conseguir… >> Sim. Sim. Sim. O padrão-ouro é contratar humanos e treiná-los para fazer a tarefa de verificação eles mes

20:32 mos. E então ver se o seu sistema concorda com eles. É. Mais alguma pergunta? Alguém quer nos ajudar a criar mais benchmarks? >> Sim. Ah, sim. Certo. Certo. Sim. Sim. Sim. >> Ótimo. Bem, muito obrigado. Espero que aproveitem o resto da exposição. Foi um prazer. >> Muito obrigado. >> Muito obrigado. >> É. É.

Transcrição original

[00:01] [music] Good afternoon everyone. Um, thank you for coming. Hope you’ve had a great expo so far. We’re in the last stretch, but I know it’s been a wonderful, wonderful expo, at least for me. So hopefully you’re learning a lot and we can teach you a little bit more. Um, so I’m Miguel. I’m the tech lead for uh our agent platform at Browserbase. For those of you who don’t know, browserbase is a

[00:34] infrastructure company for deploying agents on the web. Um it basically unlocks all of the web, not just what is easily accessible uh by managing browsers in the cloud and all the runtime that uh requires to do agentic web automation at scale. So um let >> and I’m Corby. I’m a researcher at Microsoft and I’ve been collaborating with with browser base to help build really good verifiers. >> So today we’re here to talk about some research that we published about a month

[01:06] ago. Um and it is regarding evalance. It is regarding RL environments and LM judges as verifiers. So early on so I’ve been working on this open source framework called stchen for about a year and a half now. And from the beginning as any good agentic product needs to have we were building evals to make sure that the changes that we were introducing in the framework and that the model capabilities continue to improve and hill climb on those evals

[01:39] and at the beginning all those evals were deterministic environments. um it was relatively simple. Model capabilities were some somewhat constrained and so we were able to build a lot of deterministic environments as model capabilities continue to improve as we continue to make improvements on the agent harness that just didn’t scale. We found ourselves constantly patching or generating static sites um coming up with longer trajectories with a lot of checkpoints to make sure that the evals were deterministically

[02:09] verifiable. And so there’s many different project problems with automating the web at scale and verifying that what you intended to do actually succeeded. And it’s that the web is very open-ended. There’s not just one path to correctness. Um there is no ground truth. Sometimes the web changes and the product that you were checking for before is no longer there. So that breaks the whole determinism of your environment and there’s blockages. there’s a lot of the environment errors

[02:39] that you face that don’t let you get sort of a verifiable deterministic signal. So we recurred to what most people do which is trying to use an LLM judge to help improve um and scale this operation. But we quickly found out that a lot of the leading benchmarks and some of you may know about OS World uh for computer use but there’s some analogous benchmarks for web use called online minor web and web voyager.

[03:10] Those come with LLM judges as verifiers. And what we noticed when we were using our sort of human expert annotators to verify the verifier is that in many instances they’re very confidently wrong. And that leads to results that you can’t really trust. So very quickly we realize that even if you were using this as an RL reward or as a signal to improve your hardness and auto research, you’re not really training a better agent. You’re just

[03:42] training a more competent liar. And so in a real world use case at Microsoft, we trained this FARS 7B model which is a a web browser agent. And the same model on the same benchmark, we judged it according to the official web voyager judge, which is GPT40. Uh and it said that it had 74% uh success rate. But there’s a huge gap between the real truth which is when we used our new universal verifier uh which has high agreement with human labels that that

[04:14] number quickly becomes 30 like 38%. So there’s a huge gap between what the existing verifiers say and what is actually the ground truth. And so we needed to find a way to to close this gap. The existing verifiers have lots of weaknesses. Um they’re they use smaller and like much dumber models. uh as the LM as a judge they use 04 mini or GBT40 they don’t even use rubrics so rubrics are the most critical thing that you need to have because you need to assign credit to where credit is due they don’t look at the the relevant screenshots or

[04:46] they or they try to look at all the screenshots and they quickly get lost and overflow the context window of the LLM as a judge and sometimes they don’t even look at the final answer or the action history of the model so our verifier checks all of these boxes um and this is kind of how it works uh at a very high level you And you can look in the paper for more details, but given a task like book a cheapest flight from Seattle to Boston, the first thing we do is we generate a really good rubric and I’ll give some examples of that. And a rubric has like maybe 10 different criteria of what success looks like. And

[05:18] then given that that criteria in the rubric, we look at the agents trajectory. All of the screenshots in this case are the the evidence of the ground truth. and we rank what are the most relevant screenshots in the trajectory for each criterion. And then we use that group of of top K evidence to determine whether that criterion was met or not and if there’s any like differences or contradictions between what the agent said it did and what the state of the environment actually showed. And then given that we output uh

[05:50] a scored rubric which we we call like a process score because it gives partial credit in some cases. and we give an we output a uh an outcome boolean uh value to turn to basically say whether the agent accomplished the task according to what a reasonable user was would expect. Um and so this is an example of what the rubric uh the rubric output is. It’s basically a list of criteria um as well as the outcome verifier is basically a true false flag with an explanation as

[06:22] to why a reasonable user would expect um this trajectory to have succeeded or not. There were four guiding principles when we created this universal verifier. One is around rubric creation which is we wanted to grade only what was asked and not any extraneous criterion. Uh we also did not want errors to cascade from one rubric uh criterion to another. We wanted them to be isolated. And I’ll give an example of that. You also wanted to look at the ground truth screenshots. Like this is a must. The agents will

[06:52] often overconfidently claim that they did something when in fact they did not do it. And so you have to look at the ground truth state. And then we also needed to separate um what the agent could control versus what the agent could not control. The agent operates in a web browser. The web browser is an environment that it doesn’t always have ability to control and I’ll show some examples of that too. So this is an example of what a good and bad rubric looks like. The task here is to uh find a cheap uh hotel in Jakarta for these dates and then use the hotel’s address

[07:24] to search for the closest coffee shop and then output the name and address of that coffee shop. Now a bad rubric which we did see happen would output a criteria saying like please tell me the total price for the stay at the hotel. This is actually an extraneous criterion that was not asked for in the task but we saw a lot of rubrics naively generated do something like this and they would artificially deflate the scores because the agent didn’t do something it wasn’t asked to do. Um when it comes to not cascading errors, um

[07:55] there are very subtle mistakes because a lot of tasks build on each other uh if they are like multi-step tasks. So in this example here, the task was to um determine the net worth of the individual with the longest last name from among the members of NSync and Backstreet Boys. Okay. And so the agent in this case mistakenly thought that Timberlake had the longest last name which is only 10 letters whereas Kirkpatrick actually had the longest last name. So the model made one arithmetic mistake in one criteria of

[08:27] the rubric and that should not cascade to the next criteria of the rubric which is report the net worth of of the person that you chose. Right? So if you’re able to report the net worth of Timberlake uh accurately then you shouldn’t get penalized in this criteria. you should only get penalized in that one. Hallucinations is the biggest one uh that we really wanted to focus on. So in this task, this is an example of a very subtle hallucination uh where you wanted to find some information about some image captioning model and the agent

[08:58] said that this model had plus 6.2% in some cider score, but in reality the abstract of the underlying paper said it was only 2.8% in cider score. And so this was a like a very subtle mistake that even humans will not catch unless an LLM will flag it. Um so this kind of gives uh an overview of of how process scores and outcome scores differ. Um in the case we mentioned one of the principles was we wanted to separate controllable versus uncontrollable um

[09:28] failures. So, if the task is to buy, say, this uh plushy toy from Amazon, and the agent accurately searched for the plushy toy, but found that it was out of stock, it could not continue. And so, here we say that the agent gets full marks for doing its best effort uh to achieve the goal, but the outcome was still not met because it couldn’t buy the thing that it wanted to buy because it was out of stock. Um, so we basically enumerated a bunch of scenarios as to what could happen and how do we assign

[09:59] credit if the agent was able to find a similar alternative plushy toy in a different way. Um, it would still get success there uh for both for both cases and it would get penalized if it made a controllable mistake. Uh, it would get penalized if it made hallucinations and so on and so forth. So we basically enumerated a a schema of like all the possible failure modes and how we would assign credit to that and the universal verifier adheres to those to those schema. So >> basically in in order to evaluate the

[10:31] verifier and really tell whether or not we were able to hill climb the accuracy of that verifier, we started designing a lot of experiments with human experts and built a whole platform to collect data on what we call the ground labels that we’ve also released under cool verify bench for others to train upon. But the process that we followed was the following. At first, we would show the full trajectory of evidence to the human verifiers and the annotators would judge based on the evidence and the result of

[11:02] all the actions that the agent took. After that, they would be prompted to a seeing the judgment of the universal verifier to say whether they agree or disagree with a human with a universal verifier. And we found this to be a very reliable signal to tell whether or not we were working in the right direction because I’ll jump to this one straight up, but the verifier started correcting humans

[11:34] at one point. They it would identify things that the humans were missing. And so ultimately the result of the of the universal verifier on these golden labels was that we were able to reduce false positives from almost half to zero and coins cappa isometric to measure inner annotator inner annotator agreement. Um and what we can see here is that the h universal verifier agrees with humans as often as humans agree with one another. So we can see that

[12:06] 0.58 coins scalpa score uh versus the two annotators per task um where we computed coins scappa as well to see how much they agreed with one another. >> Another way another way to uh verify the another way to verify the quality of our verifier is to actually train on data filtered by it. So what we did was we did ran an experiment where we held constant the number of training examples. In this

[12:37] case it was 3k or 9k training trajectories, but we filtered those training trajectories based on whether our verifier said they were pass or not. And so when you’re doing SFT, which is what we did here, you want to train only on SFT examples where they were true uh like successful trajectories. And so if you train on 3,000 trajectories filtered by the process score of our universal verifier, you will get a much higher quality model than if you were to train on a worse verifier like our own a baseline verifier. And this held at

[13:09] larger scales as well. And so this basically this experiment told us that uh if you have a higher quality verifier, it means you can filter higher quality data uh and training on that data leads to a higher quality model. And so this was like the ultimate experimental proof in addition to the um uh to the to the human agreements uh that this model this verifier is working and is and is reliable um in a real production uh scenario. Um the last thing we did kind of as a side project is we wanted to determine

[13:41] whether AI in auto research can build the same verifier that we built. So basically what I did and what Miguel and I did is we sat down for three weeks um to build the universal verifier and to tweak the prompts and to write the code for it. And we basically ran about 30 different experiments over the course of three weeks to determine whether the verifier we were building agrees with human labels. Okay. And so that’s what the Coen Kappa score here on the Y-axis is measuring. It measures whether an individual verifier system is agreeing

[14:14] with the human labels. And so the blue line here is the model Miguel and I, the system Miguel and I were were creating this auto research uh this uh universal verifier. And then we wanted to see if if we stripped everything that we did away, could AI um in an auto research loop build the same verifier that we built with the same level of quality and fidelity? And that’s what the red and green lines here are. The red line is if we took away all of our code and prompts, could AI replicate that? The

[14:44] conclusion that we got from this is that while we took about three weeks to build this verifier, uh an auto research loop could do it in about one day. It ran the same number of experiments in about one day. However, it only reached about 70% of the agreements that our verifier uh was able to reach. So there’s still a gap there. And so the kind of the conclusion that I would draw here is that uh you can use auto research to build uh metrics and verifiers um at least to help you speed up uh

[15:14] experimentation. Um but you probably still need some level of human intervention here. Um then again, these these results were from Opus 4.6. I haven’t tried it with Fable yet. Maybe it will do better, but it’s a pretty powerful baseline and it got pretty far um along the way. So, not only can auto research help you build a model, but in this case, auto research can help you build a verifier as well, which we thought was a pretty cool um thing. And and building verifiers is as important as building the models themselves is one of the takeaways I want to leave you

[15:45] with. So >> yeah, and just to double emphasize um the green light is the auto research verifier um primed with a lot of the findings that we had gotten from the three weeks of experimentation and in that optimization it was able to reach higher percentages than we were ever before. So combining that human intuition with auto research loops has proven to be the most powerful recipe for many research tasks. Um so

[16:17] the all of the work is open source. The paper is published under this uh as a preprint um on archive. Um and the Microsoft repo contains the golden labels on kua verifier bench. It contains the code to run the experiments. But beyond that um this research also yielded an entire new benchmark. So we’ve talked briefly about online minor web and web voyager. I spend a lot of

[16:48] time working with labs helping make sure that we can provide them quantitative signal to improve their models. A lot of those open source benchmarks are very quickly getting saturated and it is very difficult to provide any sort of signal because it feels like the the test data is already in the distribution of the training data. And so this new benchmark has proven to have the biggest gap to complete success and it’s my daily driver to make sure that I can

[17:19] tell whether model capabilities are strong, whether they lack and how to continue to close the gap. So >> did you have more slides? >> No. >> Okay, >> we can take a little bit of I think questions, but uh we’re good on time. >> Yes. Yeah. So the question is the question is whether we’ve used the uh the universal verifier for other kinds of tasks beyond

[17:49] just web web tasks. So one thing we’re working on in Microsoft right now is to apply a version of this verifier for desktop tasks like things that you would do on your laptop like kind of enterprise workflows. And so we hope to publish another benchmark uh of not just web data but also like enterprise style desktop data. Uh and we would have basically the similar the same kind of verifier for that too. It would look at a little bit more information because on desktops you have the terminal, you have more telemetry, more logs than just the

[18:20] browser. So the verifier would take those things into account as well. Yeah. Any other questions? >> Yeah. >> So I personally never when you present I was thinking about like how do you think about that show?

[19:00] Yeah. >> Yeah. So, the question is about how do you make sure you’re not overfitting the verifier to the human labels because that is a problem. Uh Miguel and I spent a lot of time uh working on this question. And so like one thing that we did was we uh kind of held out uh two sets of labels. One we we basically had a set of like 150 trajectories. um on about 50 of those trajectories, I labeled them myself and I used them to hill climb in those 30 experiments. But

[19:31] for the other hundred trajectories, they were basically held out to us. They were done by humans uh that we had paid uh with like 2x overlap. So once our verifier was done being built, we gave it to those human annotators and each human labeled each trajectory, sorry, two humans labeled each trajectory and then that’s what we published in KUA verifier bench. And so those are the numbers that we report here. Um so we’re pretty confident that we didn’t overfit because we held out at least twothirds

[20:01] of the labels. Um like we did not train like iterate on them. >> Yeah. So that’s very important is you don’t want to train on like to be able to >> Yeah. Yeah. Yeah. The gold standard is uh is to hire humans um and train them to do the the verification task themsel

[20:32] and then see whether your system agrees with it. Yeah. Any other questions? Anyone want to help us build more benchmarks? >> Yeah. Oh yeah. Okay. Okay. Yeah. Yeah. Yeah. >> Awesome. Well, thanks a lot. Uh hopefully you enjoyed the rest of the expo. It was a pleasure. >> Thank you so much. >> Thank you so much. >> Yeah. Yeah.