Parameter Golf com AutoResearch — Weco AI

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: Parameter Golf with AutoResearch — Weco AI · Canal: AI Engineer · 34:10 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Inferência e otimização de modelos

Resumo

A equipe da Weco AI apresenta o AutoResearch, um ciclo em que um agent propõe mudanças em código, avalia os resultados e mantém as que melhoram uma métrica. Os palestrantes explicam como Aiden participou do desafio Parameter Golf, em que o objetivo era treinar um modelo sob limites rigorosos de tamanho e tempo. Em seguida, detalham os componentes de um experimento de AutoResearch e destacam a importância de avaliações rápidas, observabilidade e controle humano. A apresentação termina com uma competição baseada em Flappy Bird, na qual os participantes otimizam um controlador para diferentes cenários.

Pontos-chave

• O AutoResearch automatiza ciclos de tentativa e erro: propõe mudanças, testa-as com uma avaliação e conserva as que melhoram a métrica.
• No Parameter Golf, modelos e código de treinamento precisavam caber em 16 MB, e o treinamento tinha de terminar em até 10 minutos.
• Aiden foi apresentado como o principal colaborador do desafio, com sete recordes de leaderboard e trabalho reutilizado por outros participantes.
• No mini Parameter Golf, o objetivo é minimizar o BPB de validação, que mede a capacidade do modelo de prever texto não visto.
• Uma avaliação útil deve ser rápida, barata, pouco ruidosa e resistente a tentativas de manipulação da métrica.
• O sistema também precisa definir o código editável, a métrica e a meta, o número de etapas, os limites de tempo e a orientação inicial ao agent.
• Busca estruturada, inspeção das mudanças e possibilidade de orientar a pesquisa durante a execução ajudam a tornar o processo observável e controlável.
• A competição de Flappy Bird pede que os participantes otimizem um controlador para quatro mundos, usando a média das pontuações como métrica.

Capítulos

Início	Capítulo	Resumo
00:12	Introdução ao AutoResearch	A equipe define o ciclo de tentativa e erro automatizado e apresenta seus usos e desafios.
03:31	Programa da oficina e histórico da equipe	Os palestrantes descrevem as atividades da oficina e apresentam o trabalho anterior da equipe com Aiden.
05:39	O desafio Parameter Golf	Dex explica as regras do desafio e os resultados atribuídos a Aiden e a seus colaboradores.
08:17	Preparação do mini Parameter Golf	A equipe apresenta a versão reduzida do desafio e orienta os participantes a iniciar uma execução.
10:52	Anatomia de uma execução de AutoResearch	A apresentação detalha o código editável, a avaliação, a métrica, o orçamento de etapas e as instruções iniciais.
16:40	Estrutura, observabilidade e controle	Os palestrantes mostram como inspecionar as mudanças e orientar a busca, inclusive com ideias humanas.
20:49	Demonstração e perguntas	A equipe demonstra a configuração e o dashboard, responde a perguntas e mostra uma primeira melhoria.
28:52	Competição de Flappy Bird e encerramento	Os participantes recebem as regras para otimizar um controlador em quatro cenários e competem pela maior pontuação.

Citações

Você dá ao modelo de linguagem seu código e um script de avaliação reproduzível. — 00:52

Você quer que a avaliação seja rápida, barata e tenha pouco ruído. — 12:27

É quando você deixa de observar e começa a assumir o controle. — 19:15

Executar AutoResearch em algo tão difícil não é simplesmente configurar e esquecer. — 20:17

Conceitos e entidades

• autoresearch (conceito): Ciclo automatizado em que um agent modifica código, executa uma avaliação e mantém as mudanças que melhoram o resultado.
• Parameter Golf (conceito): Desafio de treinamento de modelos de linguagem com limites de tamanho dos artefatos e de duração do treinamento.
• mini Parameter Golf (conceito): Versão reduzida do Parameter Golf, preparada para permitir que participantes observem várias etapas de pesquisa durante a oficina.
• Aiden (ferramenta): Agent autônomo de engenharia de machine learning apresentado como o sistema que contribuiu para o desafio Parameter Golf.
• Weco AI (empresa): Empresa cuja equipe apresenta a oficina e seu sistema de AutoResearch.
• MLE Bench (benchmark): Benchmark mencionado na apresentação como avaliação na qual Aiden foi testado.
• Modal (ferramenta): Plataforma de computação usada na oficina para executar treinamento e avaliações.
• GitHub (ferramenta): Plataforma usada para compartilhar o repo e enviar pull requests no contexto do desafio.
• Flappy Bird (conceito): Jogo usado como base para a competição final de otimização de um controlador.
• Opus 4.8 (modelo): Modelo definido como padrão para os participantes da competição de Flappy Bird.

Tradução completa (pt-BR)

00:12 Bem-vindos. Por favor, sentem-se se ainda não o fizeram. Meu nome é Vam. Estamos aqui com Jung Yao, Droo e Dex. Antes de mais nada, muito obrigado a Sean e à AI Engineer World’s Fair por nos receberem. Este é, em geral, um ótimo espaço para falar de IA, e estamos muito, muito felizes por estar aqui. Se ainda não conseguiram configurar tudo, não se preocupem. Teremos bastante tempo para fazer isso mais tarde. Junga vai nos dar uma breve introdução aos fundamentos por trás de AutoResearch.

00:52 Certo. Caso alguém ainda não saiba o que é AutoResearch, aqui vai uma explicação rápida. AutoResearch é basicamente um ciclo de tentativas e erros. Você fornece a um modelo de linguagem seu código e um script de avaliação reproduzível. Ele continua tentando ideias e testando-as com base na avaliação; mantém as ideias que melhoram a pontuação e descarta todo o resto.

01:22 Alguns exemplos de métricas incluem acurácia, velocidade e custo. Um ciclo semelhante já existe no meio acadêmico há cerca de dois anos, mas se tornou viral neste ano, quando Kapasi publicou sobre isso nos scripts de treinamento de modelos dele, e descobriu-se que funciona muito bem para ele.

01:55 Em apenas algumas semanas, os casos de uso de AutoResearch se espalharam do treinamento para praticamente tudo: engenharia de backend, engenharia de prompt e de agent, aceleração da inference de modelos. E também chegou rapidamente à produção. Por exemplo, reduziu a latência do pipeline de CI/CD da Shopify e melhorou o agent de uso do navegador da empresa.

02:27 Em abril, nosso agent experimental de pesquisa, Aiden, chegou até a vencer o desafio de contratação da OpenAI, chamado Parameter Golf, sobre o qual vamos falar um pouco mais daqui a pouco. Também vou fazer uma palestra na quarta-feira especificamente sobre isso. Então, AutoResearch pode ser muito poderoso, mas também é difícil de dominar. Com um agent de programação comum, você basicamente orienta o agent a cada

03:00 passo, mas, no caso de AutoResearch, é como se o agent estivesse executando um ciclo por conta própria. Isso faz com que seu prompt e sua configuração tenham um efeito muito maior. Se você os direcionar para a avaliação certa, basicamente deixa o agent explorar tudo por você; caso contrário, só vai gastar todos os seus tokens de RM. Então, esperamos que este workshop dê a vocês um bom ponto de partida para aprender sobre AutoResearch e

03:31 aplicá-lo ao próprio trabalho. Certo, vamos voltar para Bay. Obrigado, Janelle. Então, é assim que vamos passar as próximas duas horas. Dex vai apresentar o Parameter Golf, o desafio em que inscrevemos nosso agent, explicar do que se tratava esse desafio e como nosso agent acabou se tornando o colaborador mais influente. Depois será a vez de vocês. Vamos ajudar a configurar tudo e iniciar uma execução de AutoResearch no seu laptop. Enquanto

04:03 o AutoResearch estiver rodando em segundo plano, vamos explicar os fundamentos de um ciclo de AutoResearch e os elementos que realmente moldam o comportamento de um agent. Depois, vamos nos aprofundar e fazer uma demonstração guiada, em que vocês poderão executar, orientar e inspecionar ao vivo o que o agent está fazendo. E vamos terminar com uma parte divertida: uma competição ao vivo. Vocês vão usar tudo o que aprenderam hoje, direcionar o AutoResearch a um jogo que todos já jogamos e competir para ver qual agent consegue a maior

04:34 pontuação, e o vencedor levará um prêmio muito legal. Um pouco mais sobre quem somos. Já trabalhamos com AutoResearch há bastante tempo. Antes da Weco, lançamos o Aiden em abril de 2024, um agent autônomo de engenharia de machine learning. A ideia básica era dar a ele um problema de machine learning, deixar que escrevesse código, executasse experimentos, lesse os resultados e continuasse melhorando. Quando a OpenAI criou o MLE Bench, o Aiden foi um

05:07 dos primeiros agents avaliados de forma independente e, nesse benchmark, obteve cerca de quatro vezes a taxa de medalhas do segundo melhor agent. Mais recentemente, como comentamos, direcionamos nosso agent ao Parameter Golf e, entre mais de mil pesquisadores, ele se tornou o colaborador número um. Vou passar a palavra ao Dex, que vai contar mais sobre a competição.

05:39 Olá a todos, meu nome é Dex. Vou falar sobre o Parameter Golf. O Parameter Golf é um desafio de criação de modelos open source. O objetivo é treinar o melhor modelo de linguagem possível dentro de duas restrições rígidas. Os quatro artefatos, incluindo os pesos do modelo e o código de treinamento, precisam caber em 16 megabytes, e o treinamento precisa terminar em até 10 minutos. As submissões são avaliadas por bits por byte (BPB) no conjunto de validação do FineWeb, e quanto menor, melhor.

06:10 A OpenAI forneceu um conjunto de dados de referência e scripts de avaliação, para que os participantes pudessem melhorar o modelo de forma iterativa e enviar seus resultados pelo GitHub. Então, tudo é open source. Também ofereceram um milhão de dólares em créditos de computação e analisaram todas as submissões. Durante os 44 dias da competição, 6 pesquisadores participaram e abriram 248 PRs, consumindo aproximadamente

06:43 250 mil dólares em computação de GPU. O placar final é curto: apenas 47 PRs foram incorporados como recordes, vindos de 31 colaboradores. Para essa competição, criamos o Aiden, um sistema multi-agent de autoaperfeiçoamento, baseado nas famílias de modelos Claude e GPT, que roda indefinidamente para ajudar a otimizar uma única métrica. No Parameter Golf, o Aiden automatizou o ciclo de pesquisa em quatro etapas. Ele busca artigos públicos no arXiv, implementações robustas no GitHub e seus próprios registros de execução. Depois, propõe novas ideias, testa-as, verifica se estão dentro das regras, mantém as que funcionam, escreve a implementação e executa os experimentos.

07:14 Quando os resultados passam pelos critérios de qualidade, ele cria e envia um PR para revisão. E os resultados são impressionantes. O Aiden estabeleceu sete recordes no placar. Isso é o dobro do número obtido pelo próximo melhor participante humano. Também teve o maior índice H de OPR em toda a competição, o que significa que o Aiden não apenas produziu recordes aceitos. Ele publicou trabalho reutilizável que outros participantes continuaram desenvolvendo. 435 PRs posteriores citaram e se basearam no trabalho do Aiden, e ele conseguiu isso com uma fração do orçamento: usou apenas 4% da computação de GPU da comunidade. Foi responsável por 15% do total de recordes incorporados. Isso o torna 3,7 vezes mais eficiente em termos de custo do que a média dos participantes.

07:46 E isso conclui a apresentação sobre como o Aiden se tornou o colaborador número um no desafio open source. Obrigado. Legal. Então, vamos executar o AutoResearch em uma versão do mesmo desafio Parameter Golf que o Dex acabou de apresentar. Para facilitar, vamos chamar isso de mini PG, que significa mini Parameter Golf. Como o Dex comentou, a competição real de Parameter Golf era pesada. Cada experimento envolvia treinar um modelo de linguagem em um conjunto de dados enorme. Isso funciona quando a competição dura quatro semanas, mas, em um workshop como o de hoje, vocês nunca conseguiriam ver a execução do AutoResearch. Então, pensem no mini PG como uma versão em escala reduzida do desafio.

08:17 Vocês ainda vão treinar um modelo de linguagem de verdade, avaliá-lo com o mesmo avaliador fixo e reduzir o mesmo número, o valp, que essencialmente mede o quanto o modelo

08:47 prevê textos que ainda não viu. Mas reduzimos a escala. Estamos usando um conjunto de dados minúsculo, em vez do FineWeb, e um treinamento e uma avaliação que levam apenas alguns minutos. Assim, vocês vão conseguir iniciar um ciclo e ver várias etapas reais acontecendo ao vivo. Antes de passar às instruções do próximo slide, vou dar uma breve orientação. Vocês vão executar o AutoResearch por conta própria no mini Parameter Golf. Vão se inscrever em duas plataformas, caso ainda não tenham feito isso. Uma delas é

09:19 a Weco, nosso agent de AutoResearch, que executa uma busca; a outra é a Modal, onde vocês vão computar, treinar e avaliar seus experimentos. Créditos grátis. Obrigado, Modal. Depois, vocês vão clonar nosso repo de Parameter Golf e passá-lo ao seu agent de programação. Peçam que ele inicie uma execução. Ele cuida da configuração e começa o ciclo. Quando estiver funcionando em segundo plano, vocês poderão deixá-lo rodando, e voltaremos em cerca de 15 ou 20 minutos para explicar os detalhes.

09:51 Temos nosso agente de AutoResearch, que faz uma busca, e o outro é a Modal, onde você computa, treina e avalia seus experimentos. Créditos gratuitos. Obrigado, Modal. Então, você vai clonar nosso repo de parameter golf e entregá-lo ao seu agente de programação. Diga a ele para iniciar uma execução. Ele cuida da configuração e começa o ciclo. Quando estiver funcionando e rodando em segundo plano, você pode iniciá-lo, e voltaremos em cerca de 15 ou 20 minutos para mostrar os detalhes por dentro.

10:22 As instruções estão aqui. Cadastre-se no WO em dashboard.ai. Cadastre-se na Modal em modal.com/signup. Há um código para resgatar seus créditos da Modal. Se você já tem uma conta na Modal, pode acessar diretamente modal.com/crediteds e inserir seu código lá. Depois de concluir essas duas etapas, clone o repo mostrado aqui e peça ao seu agent para configurar o mini PG a partir do readme e iniciar uma execução. Se tiver algum problema ou

10:52 tiver alguma dúvida, fique à vontade para escanear o QR code e inserir o código lá; vamos acompanhar. Ou levante a mão e iremos até você. Voltem daqui a cerca de 105 minutos. Obrigado, pessoal. >> Certo. Desculpem pelo problema com a internet. Acho que estão trabalhando para resolver, mas, até lá, acho que seria bom passar pela anatomia de uma execução de auto research. Vamos fazer isso no contexto do WCO como sistema de auto research e do mini PG como tarefa. Mas

11:24 esse tipo de contrato que temos aqui é bastante geral. A maioria dos sistemas de auto research vai fazer perguntas muito parecidas e considerar as mesmas coisas. Certo. A primeira coisa é o arquivo-fonte. É isso que o agent realmente precisa modificar. Ele define o espaço de busca e onde o agent pode fazer alterações. Pode ser um único arquivo ou vários arquivos. No caso do miniPG, é este arquivo chamado solution.py, e o solution.py

11:56 define essencialmente a configuração do modelo e a dinâmica de treinamento que ocorre enquanto o modelo está sendo treinado. A segunda coisa, que na minha opinião é provavelmente a parte mais crucial de um sistema de auto research, é a avaliação. Você quer ter uma maneira bem simples de permitir que seu sistema de auto research avalie cada solução que gera. E quer que ele produza uma única métrica escalar.

12:27 Você quer que a avaliação seja rápida, barata e tenha pouco ruído. Isso, essencialmente, permite executar mais etapas se você tiver um orçamento fixo ou uma restrição de tempo. E, se houver pouco ruído, tanto você quanto o agent terão mais confiança ao subir a encosta do desempenho na tarefa que estiverem pesquisando com auto research. Mas é preciso ter em mente que agents adoram explorar brechas na métrica de recompensa.

12:58 Eles adoram encontrar brechas no protocolo de avaliação e no benchmark. Por isso, você realmente quer descobrir como tornar sua avaliação o mais robusta possível. As duas coisas seguintes são a métrica e o objetivo. Você precisa se fazer duas perguntas: o que quero melhorar e é melhor obter um valor maior ou menor? No nosso caso, para o mini PG, queremos minimizar o BP de validação. Portanto, queremos encontrar um modelo

13:29 que seja melhor em fazer previsões sobre textos que não foram vistos. A próxima coisa é o número de etapas pelas quais você realmente executa o sistema de auto research. Isso é um pouco complicado, porque é difícil saber de antemão quantas etapas você deve dar ao seu sistema. Neste caso, escolhemos 20 porque queremos dar aos agents tempo suficiente para explorar ideias diferentes, e assim você pode ver o que o agent está explorando, o que funciona e o que não funciona. Mas, em geral, testar mais ideias

14:02 leva a mais avanços. Isso remete ao que eu dizia antes: se a avaliação for rápida ou barata, quando houver alguma restrição de tempo ou de custo, você poderá executar mais etapas. Então, mais uma vez, a avaliação é sempre muito importante. Certo. Você também quer limitar o

14:35 tempo de execução da avaliação, porque muitas coisas podem dar errado. Os loops podem travar, o hardware pode falhar e, às vezes, o agent produz um código muito ruim que faz todo o sistema parar de responder. Por isso, você quer limitar o tempo da execução da avaliação. No nosso caso, definimos o limite como 210 segundos. O motivo é que reservamos 60 segundos para treinar o modelo, 60 segundos para testá-lo em textos que não foram vistos e, depois, 90 segundos como

15:07 margem para a Modal inicializar as GPUs para o treinamento, inicializá-las para os testes e cobrir qualquer outro tipo de sobrecarga existente. A última coisa é a orientação que você dá ao agent no início da otimização. É assim que você direciona o agent desde o começo. Você deve pensar nisso como o conhecimento que acumulou com experimentos que provavelmente já realizou, reunindo uma série de

15:38 conhecimentos especializados no domínio e conhecimento humano. Talvez você tenha algumas ideias sobre o que funciona, o que seria interessante testar e o que não funciona. É aqui que você pode fornecer esse tipo de orientação. No caso do WICO, basta apontá-lo para um arquivo Markdown com todas as suas informações e contexto. O agent pode usar isso, o que lhe dá a melhor chance de obter sucesso. No caso do mini PG, podem ser algumas restrições rígidas

16:10 ou ideias diferentes que parecem funcionar muito bem, como se concentrar em compressão, em diferentes métodos de quantização ou talvez até em compartilhamento de pesos entre blocos diferentes do modelo. Vamos apenas demonstrar como começar com auto research, considerando os problemas com a internet.

16:40 Antes de chegarmos a isso, vamos falar um pouco mais sobre o que, na nossa opinião, torna um sistema de auto research pronto para produção realmente pronto para produção. O primeiro ponto é a estrutura. Temos uma busca em árvore, na qual o agent mostra todas as tentativas que executou, para que as ideias, como o Duv mencionou, possam se desenvolver umas a partir das outras, em vez de começar do zero. O segundo ponto é a observabilidade. Você pode abrir qualquer tentativa e ler

17:10 a alteração exata no código que está por trás da pontuação, para entender por que o agent está seguindo aquela abordagem. O terceiro ponto é a capacidade de direcionamento. Você tem uma sensação de controle. Pode inserir suas próprias ideias e conhecimentos enquanto o loop está em execução e pedir que o agent tente novas direções caso fique preso. Falando um pouco mais sobre a busca baseada em árvore: em breve vamos demonstrá-la no nosso dashboard de auto research, mas esse tipo de auto research trata o problema como um processo estruturado de

17:41 otimização de código. Ele começa pela raiz da árvore. Como você pode ver, a pontuação foi 0,5, que é simplesmente a pontuação medida do programa de referência. Cada nó depois da raiz é uma versão modificada do código, executada na avaliação e acompanhada de uma pontuação. Você pode pensar nessa árvore como um grafo de experimentos. Como pode ver, a busca se baseia no que funciona. Estamos encontrando bons candidatos e eliminando os ruins. Assim, quando um ramo melhora a pontuação, a busca aproveita essas ideias e se aprofunda a seguir, o que

18:13 significa que você pode inspecionar as alterações exatas que seu sistema de auto research está fazendo e se basear nelas. A próxima ideia de que falamos foi a observabilidade. Como você pode ver todos os nós dessa busca baseada em árvore, pode abrir qualquer um deles e ver exatamente o que mudou. Pode ver sua métrica mudar em tempo real e relacionar essa mudança a um motivo. Passe o cursor sobre um nó para obter um resumo do que

18:44 mudou e abra-o para ler o diff exato. Assim, quando a métrica dá um salto, você pode ler a alteração que o causou. Normalmente, essas execuções duram horas e abrangem centenas de experimentos. Então, depois de conseguir ver o que o sistema está fazendo, o próximo passo natural é poder mudar o que ele faz. É aí que você para de assistir e começa a assumir o controle. Se eu tiver uma ideia que quero testar e a escrever em linguagem simples, o sistema abre um novo ramo e você pode vê-lo testar essa ideia

19:15 uma nova ideia e fazer novos nós desenvolverem uma nova curva. Também posso definir um orçamento para cada nó, para que ele gaste computação onde eu quiser. E essa é a parte que tornou isso utilizável em problemas reais, porque talvez você tenha contexto e intuição que um agent não tem. Pelo menos por enquanto, acreditamos que é importante encontrar maneiras de incorporar o julgamento humano ao sistema sempre que necessário. Quero fundamentar esse ponto — a capacidade de direcionar — em algo concreto. Porque, no Parameter Golf…

19:46 …a capacidade de direcionar foi uma parte importante do motivo pelo qual nos saímos bem. Isso é um avanço real da competição. Começou com nosso agent — a linha rosa — durante cinco dias, de 15 a 19 de abril. Ele continuou tentando coisas novas: novos mecanismos de attention, compressão, uma pilha mais elaborada, mas a pontuação basicamente estagnou. Havia alguém da comunidade que lançou um novo tokenizer engenhoso, que é a linha azul. E, em até oito horas depois que essa mudança surgiu, nosso

20:17 sistema a adotou, combinou-a com as partes em que já vinha trabalhando e alcançou o maior salto em semanas. Fazer auto research em algo tão difícil não é simplesmente configurar e esquecer. É uma colaboração em que direcionamos o agent. Incorporamos ideias das pessoas ao nosso redor. E é essencialmente a capacidade de direcionamento que torna esse ciclo possível. É assim que os avanços reais acontecem. Vou passar a palavra a Dex e Jungao para falarem um pouco mais sobre

20:49 como configurar auto research. Vamos basicamente reproduzir o processo que vocês estavam tentando fazer nos laptops. >> Certo. O que vamos fazer aqui é explicar a ideia geral: como isso acontece? Vamos usar nosso hotspot do celular. Então vamos improvisar um pouco. Espero que não se importem. Então…

21:19 Sim, você pode… sim, certo. Talvez também possamos percorrer todo o documento que está sendo enviado ao Claude. >> Sim. Basicamente, você pode entrar no repo e dar uma instrução simples, como “inicie o Weco usando o README”. Se a internet estiver boa, acho que ele deve iniciar a execução padrão do Weco, e nós…

21:51 também podemos explicar como o comando do Weco funciona. Neste caso, você tem um arquivo de código-fonte. A solução é basicamente o script de treinamento do Mini PG. Acho que o comando de eval — como o Z também mencionou — é uma orientação adicional, ou um prompt, que vai orientar todo o processo de busca. A métrica é o BPB de validação.

22:21 Isso é como uma perda em um conjunto de validação separado — uma perda apenas nesse conjunto reservado. O objetivo é minimizar, e os outros são apenas configurações que mencionamos. Ah, desculpem. O comando de eval é, na verdade, o comando bash que você vai executar para rodar a eval, e, no fim, ele vai produzir uma pontuação — vai imprimir uma pontuação no terminal

22:53 que será passada ao agent, e esse é o sinal-chave que vai conduzir todo o ciclo de tentativa e erro. >> Enquanto isso, também posso mostrar o dashboard. Então, se você entrar no dashboard do Weco — acho que fiz algo errado —, basicamente vai ver várias coisas. Depois que o comando for iniciado automaticamente pelo agent…

23:25 Acho que aí o prompt vai aparecer e vocês poderão experimentar os recursos que oferecemos. Temos uma execução para começar? >> Sim, acho que está começando. >> Certo, ainda está rodando. Está dizendo… sim, o Claude está trabalhando.

24:05 Uma pergunta da plateia enquanto vocês fazem isso. Primeiro: é possível aumentar o brilho do dashboard ou mudar para o modo claro? >> Comece de novo. >> Estou bem aqui. Você pode ativar o modo claro no dashboard? Está um pouco difícil de enxergar. >> Entendi. Modo claro. Esqueci. Onde fica? Tem…

24:41 Uma segunda pergunta: auto research pode ser aplicado a RL? Qual é a métrica escalar quando há várias coisas para otimizar? >> O que é… >> Auto research pode ser aplicado a RL? Qual é a métrica escalar quando há várias coisas para otimizar? >> Entendi. Sim. Dá definitivamente para aplicar a IO, ou seja, aplicar a scripts de treinamento de IO. Acho que existe um…

25:13 …projeto derivado chamado Sobound Speedrunner que faz exatamente isso, para o pós-treinamento de um modelo Aquin para jogar um jogo. E, sim, nesse projeto você pode aplicar auto research aos scripts de treinamento de IR. E, sobre a segunda pergunta: há vários objetivos para otimizar.

25:45 A ideia é, no fim, combiná-los em uma única métrica: você pode aplicar pesos diferentes a essas métricas ou tratar algumas delas como restrições e otimizar uma delas. Por exemplo, se estiver fazendo algo como detecção de fraude, pode manter a acurácia e tentar otimizar a precisão. E, para…

26:15 o Parameter Golf, exatamente, você mantém o tamanho do modelo como uma restrição e otimiza a acurácia do sistema. Sim, podemos ver que o agent já gerou um nó. O nó zero zero é basicamente o nó raiz, a solução de referência, e 3,93 é o BPB de validação associado a

26:47 essa solução. E você pode ver que o auto research do Weco já gerou um nó aqui. Aqui também temos um resumo das ideias que ele tentou, e parece que já está melhorando. Ah, sim, você também pode abrir o código e ver o que foi realmente alterado.

27:18 >> Sim. Temos estabilidade? >> Certo. Para isso, você pode simplesmente dizer ao agent, por exemplo: “explore o método de quantização”. Está conectado? >> Sim. Método de quantização; não mude apenas a configuração do modelo, porque não queremos fazer só ajuste de hiperparâmetros. Também queremos experimentar um método mais agressivo.

27:49 >> Acho que não está conectado. Acho que o Claude não seguiu a instrução. Sim, basicamente também oferecemos suporte para vocês…

28:20 …trazerem o agent Claude Code para o nosso dashboard. Chamamos isso de sessão em ponte. Basicamente, vocês podem ver o dashboard, a estrutura em árvore, a métrica e o Claude Code ao mesmo tempo. Aí podem dizer ao Claude Code: “Certo, esta é a direção para a qual quero conduzir todo o processo de busca”. >> Conversei com alguns de vocês, acho que…

28:52 …a internet talvez esteja um pouco melhor. Alguns de vocês estão usando hotspot; sei que há alguns problemas com pagamentos do Modal. Vamos passar à parte final, que é a competição. Vocês não precisam do Modal para isso. Originalmente, ela foi planejada como uma competição de 30 minutos, mas vamos dar a vocês até o fim do dia. Falando um pouco mais sobre o desafio: todos vocês já jogaram Flappy Bird.

29:22 Vamos fazer uma Flappy Wo Cup. Basicamente, espero que todos já tenham jogado Flappy Bird. Você toca para bater as asas, desvia dos canos e voa o mais longe que consegue. Sua pontuação final depende da distância que você voa. Transformamos isso em um problema de auto research. Então, em vez de jogar, há um controlador chamado should flap, que decide a cada frame se o pássaro deve bater as asas. O trabalho de vocês é

29:54 otimizar esse controlador. A métrica é a pontuação média, e vocês querem que ela seja a mais alta possível; vence quem obtiver a maior pontuação. Todo jogo tem uma reviravolta. Não vamos executar isso apenas no Flappy Bird. Vamos executar em quatro mundos diferentes. O primeiro é o normal, que corresponde ao jogo clássico. O segundo tem vãos móveis, em que o vão entre os canos sobe e desce. No terceiro mundo, o vento empurra o

30:25 pássaro. E o quarto mundo é variável, combinando todas as condições. Sua pontuação é a média nos quatro mundos. Então, não dá para se concentrar em apenas um. Um controlador que se sai bem no jogo normal, mas morre com o vento, não vai vencer. E a tabela de classificação avalia vocês em um conjunto de validação oculto, que nunca verão. Então, obviamente, não dá para ajustar demais ao jogo público. Algumas regras — principalmente para garantir que seja justo — e…

30:57 isso não quebra. E nós compartilharemos o repo do GitHub em breve. Você só edita o controller, que é o controller.py. Você deve manter exatamente como está a assinatura de step_flap. Então, não pode mexer no jogo nem no avaliador. Sem imports, bibliotecas externas ou acesso a arquivos. Assim, mantemos tudo autocontido. E, para manter a competição justa, não é permitido computação paralela. Então, vocês vão usar o Weco para fazer auto research.

31:29 Todos estão usando o mesmo modelo por padrão, Opus 4.8. Então, todos têm as mesmas condições. E lembrem-se de que a pontuação local que vocês veem no laptop não vai corresponder ao placar, por causa do nosso conjunto de testes oculto. Algumas dicas. Vocês terão cerca de 50 etapas no Weco. Na verdade, isso é considerando o limite de 30 minutos. Então, acho que vocês podem executar etapas ilimitadas até o

32:00 fim do dia. Podem começar pela versão de referência. A versão de referência já funciona. Então, melhorem o código em vez de reescrever o controller. Pensem em fazer pequenas alterações focadas. Coisas como ajustar a margem de segurança, o controle de velocidade, a margem inferior, adaptar o comportamento para cada mundo e talvez implementar alguns dos recursos de que falamos hoje. Seja inspecionando os nós que tiveram bons resultados, desenvolvendo a partir deles, trazendo ideias de fora e testando várias

32:32 direções. Estas são as instruções do jogo. A propósito, vocês estão competindo por um Nintendo Switch. Para determinar quem vence, coloquem o nome da equipe e o e-mail de vocês. Até o fim do dia, quem tiver a maior pontuação… entraremos em contato com essa pessoa. Enquanto isso, vamos continuar respondendo às perguntas pelo nosso Slido ou…

33:04 por favor, levantem a mão se tiverem alguma pergunta. Certo, estamos quase encerrando. As pontuações estão começando a aparecer. Não sei quem é Fern Nog, mas isso é um pouco suspeito, porque há apenas um nó. Então, vamos inspecionar as execuções de vocês para garantir que ninguém esteja trapaceando. [risos] Boa tentativa. Vamos deixar esta competição aberta até…

33:34 a meia-noite de hoje. Vamos encontrar uma forma de entrar em contato com vocês. Podem inserir o e-mail de vocês; também temos os e-mails das execuções que vocês estão fazendo. Ou podem simplesmente entrar em contato conosco pelo nosso site. Mas fiquem à vontade para continuar tentando. E obrigado a todos por virem.

34:10 >> [música]

Transcrição original

[00:12] Uh, welcome. Please grab a seat if you haven’t already. My name is Vam. We have Jung Yao, Droo, and Dex. Before anything else, uh, a huge thank you to Sean and the AI engineers worldfare for having us. This is generally um a great room of AI and we’re really really happy to be here. Um if you haven’t been able to get set up yet, no worries. Uh we’re going to have ample time to get it to to it later. Um Junga will give us a brief background on the basics behind auto research.

[00:52] Okay. Um in case any of you still don’t know uh auto research is this is just a quick brief. So auto research is basically a loop of a try and errors. You give a language model your code and a replayable evaluation script. It will keep trying ideas and test them against the eval and it keeps the ideas that improve the score and discard everything

[01:22] else. So some example metrics includes accuracy, speed uh and cost. Similar loop has been exist uh in academic for a while like two years but it really got viral in this year when Kapasi uh posted about it in his model training scripts and turned out works really well for him.

[01:55] In just a few weeks, it just the use case of auto research spread from training to everything like a backend engineering, prompt and agent engineering, speed up model inference and it also quickly show up in production. For example, it reduce the latency of Shopify’s CI/CD pipeline and improve the browser use the company’s browser use agent.

[02:27] In April, our experimental research agent Aiden even won OpenAI’s hiring challenge uh called the prime golf uh which we will tell you a bit more soon and uh I also have a talk on Wednesday specifically about it. Um so okay auto research can be really powerful but it’s also hard to master with a normal coding agent you basically steer um agent every

[03:00] single step but for auto research it’s like the agent is running in a loop on its own so it’s much bigger multiplier on your prompt and your setup pointed at the right eval you basically let it boil the ocean for you, but otherwise you’re just burning through all your RM tokens. Um so hopefully this workshop will give you a good starting point to learn about auto research and

[03:31] um apply that in your own work. Okay, we’ll come back to Bay. Thanks Janelle. Um so here’s how we’ll spend the next two hours. Um, Dex will take you inside parameter golf, uh, the challenge that we entered our agent into. Um, what that challenge was actually all about and how our agent ended up as the most influential contributor. Um, then it’s your turn. Uh, we’ll get you set up and kick off an auto research run on your laptop. While

[04:03] your auto research is running in the background, we’ll break down the basics of an auto research loop and the pieces that actually shape what an agent does. Um, and we’ll go deeper and do a guided demo where you’re able to run, steer, and inspect what your agent is doing live. And we’ll finish with a fun part, which is a live competition. Um, you’ll take everything that you learned today, point auto research at a game that we’ve all played before, and go head-to-head to see whose agent can get the highest

[04:34] score uh, with the winner walking away with a really cool prize. a little bit more on who we are. Um, so we’ve been working on auto research for quite some time now. Before WICO, uh, we released aid in April 2024, which was an autonomous ML engineering agent. The basic idea was give it a machine learning problem, let it write code, run experiments, read the results, and keep improving. When OpenAI built MLE Bench, aid was one

[05:07] of the first agents they evaluated independently and on that benchmark it scored about four times the medal rate of the next best agent. More recently, as we discussed, we pointed our agent to parameter golf and across more than a thousand research it researchers, it became the number one contributor. I’m going to hand it off to Dex who’s going to tell us more about the competition.

[05:39] Hello everyone, my name is Dex. Uh so I’m going to talk about the paramet golf. So paramet golf is open as uh model craft challenge. The goal is to train the best language model you can under two hard constraints. uh once the four artifacts including model weights plus training code has to fit in 16 megabytes and the training has to finish within 10 minutes. Submissions are scored by bits per bpb on the fine

[06:10] wide validation set and the low is better. Openi provided a baseline data set and evaluation scripts so participants can for the ripple improve the model and submit their result through GitHub. So everything is open sourced. They also put up a million dollar in computer credits and reviewed every submission. During the 44 day competition, there were,6 researchers entered and filed 248 PR roughly about

[06:43] uh 250k of GPU compute burn. The final lead board is short. Only 47 PRs merge as records from 31 contributors. And for this competition, we build Aiden, a self-improving multi-aging system based on the cloud and GPT model families that run indefinitely to help clamp on a single metric. In permit golf, Aiden automated the four research loop. It pulls public page papers from

[07:14] archive, strong implementations from GitHub and its own part logs. Then propose new ideas, tests them, audit them for legality, keep the ones that work, write the implementation and run the parents. Once the results, clear the quality gates, it will create and submit a PR for review. And the results are remarkable. Aiden landed seven mer leaderboard records. That’s twice the next best human. It

[07:46] also had the highest OPR H index in the whole competition which means Aiden didn’t just produce accept records. It published reusable work that other participants kept building on 435 downstream PR stated and built on Aiden’s work and it got there on a fraction of the budget from just 4% of the community’s GPU compute. It got 15% of total merged records. That’s 3.7 times more cost effective than the field

[08:17] average. And this wraps up a how Aiden becomes the number one contributor to the open herring challenge. Thank you. Cool. So, we’re actually going to run auto research on a version of the same parameter golf challenge that Dex just walked you through. Uh, for future reference, we will just call this mini PG, which stands for mini parameter golf. Um, as Dex discussed, the real

[08:47] parameter golf competition was heavy. Every single experiment was training a language model on a massive data set, which is fine when the competition is over four weeks, but in a workshop like today, you’d never actually be able to see your auto research run. So, think of mini PG as a scale model of the challenge. uh you’re still going to train a real language model, score it on the same fixed evaluator, and drive down the same single number valp, which is essentially measuring how well the model

[09:19] predicts text it hasn’t seen. But what we did is we shrank this in scale. We’re using a tiny data set instead of fine web and training an eval that only takes a few minutes. So you’ll actually be able to get a loop going and see several steel several real steps live. So before I get to the instructions on the next slide, just a little bit of orientation. Um you’re going to run auto research yourself on mini parameter golf. You’re going to sign up for two platforms if you haven’t already. One is

[09:51] we our auto research agent that runs a search and the other is modal uh the compute your experiments train and evaluate on. Free credits. Thank you modal. Um then you will clone our parameter golf repo uh and hand it to your coding agent. tell it to kick off a run. It handles the setup and it’ll start the loop. Once it’s going and it’s running in the background, uh you can kick it off and we will check back in in around 15 or 20 minutes to take you inside the details.

[10:22] Instructions are here. Um sign up for WO on dashboard.ai. Um modal for moto modto.com-signup. Uh there’s a code to claim your modal credits. Um, if you already have a modal account, you can go directly to modal.com/crediteds and enter your code there. Um, and once you’re done with those two steps, uh, clone the repo shown here, um, and tell your agent to set up mini PG from the readme and kick off a run. If you run into any issues or

[10:52] have any questions, feel free to scan the QR code and enter it there and we’ll be monitoring that or uh, raise your hand and we’ll come to you. check back in in around 105 minutes. Thanks, guys. >> Uh, all right. So, sorry about the internet problem. I think it’s being worked on, but until then, I think it would be good to maybe go through uh the anatomy of an auto research run. And we’re going to be doing this in the context of uh WCO as the auto research system and mini PG as the task. But

[11:24] really, this this kind of contract that we have here is fairly general. Most auto research systems are going to have you ask very similar questions and uh think about the same things. Okay. So the first thing is the source file. Uh this is what the agent actually has to modify. This defines the search space and where it can make changes. So this can be a single file, it can be it can be multiple files. In the case of minip it’s uh this one file called solution.py and solution.py PI

[11:56] essentially defines the model config and the uh uh the training dynamics that’s going to go on while the model is training. And then the second thing and in my opinion this is probably the most crucial part of an auto research system is the evaluation. And so you want to have a very simple way of allowing your auto research system to evaluate every solution that it generates. Um, and you want to have it output a single scalar

[12:27] metric. And you want the eval to be fast, you want it to be cheap, you want it to have low noise. Uh, because this essentially leads to your ability to run more steps if you have a fixed budget or a fixed time constraint. Um, and if there’s low noise, then both you as well as the agent are more confident as you’re kind of hill climbing on, uh, whatever task you’re, uh, autoresarching on. And so, uh, one thing to be aware of though is agents love to reward hack.

[12:58] So, they love to find holes in your evaluation protocol, holes in your benchmark. And so, you really want to figure out how to make your eval as robust as possible. The next two things are the metric and the goal. So you really want to ask yourself two questions. Um what do I want to improve and is higher or lower better? Um and in our case for mini PG, you want to minimize the validation BP. So you essentially want to find a model

[13:29] that is better at predicting on unseen text. The next thing is the number of steps you actually run the auto research system for. This is a bit tricky because it’s difficult to know a priority how many steps you should give your your system. We’ve chosen 20 in this case just because we want to give your agents enough time to kind of explore different ideas and you can you can see what the agent is actually exploring, what works, what doesn’t. Um but really more ideas

[14:02] that gets tried uh generally leads to more breakthroughs. And so uh this goes back to what I was saying earlier where if you have a fast eval um or if you have a cheap eval then when you’re under some kind of time constraint or cost constraint, you can run more steps. Um and so uh again the eval is is always super important to uh consider. All right. So you also want to bound the

[14:35] uh time for which your eval runs for uh because a lot of things can go wrong. So loops can stall, hardware can fail, uh sometimes the agent will produce really bad code that causes the entire system to hang. And so you want to bound the the actual evaluation running. Um in our case, we set it to be 210 seconds. And the reason for that is we give 60 seconds for uh training the model, 60 seconds for testing the model on unseen text and then 90 seconds which is a

[15:07] buffer for you know modal to spin up the GPUs for training, spin it up for um uh for the testing and any other kinds of uh overheads that exist. And the last thing is the guidance that you give the agent at the start of your optimization. Uh so this is how you steer the agent from the start. And you really want to think about it as you know you’ve probably run experiments before. You’ve compounded a bunch of

[15:38] domain expertise and human knowledge. And you might have some ideas about things that work, things that might be interesting to try and maybe things that don’t work. And so this is where you can provide that kind of guidance. Um in the case of WICO, you can simply point it to a markdown file, have all of your information and context in there. Um and the agent is able to use this and uh it gives the agent the best chance at uh at finding success. Um, in the case of mini PG, this can be uh some hard constraints

[16:10] or different ideas that seem to work quite well like uh focusing on compression uh different quantization methods uh maybe even weight sharing across different blocks in the model. Um we are just going to demo how to get started on auto research for you considering the internet issues. Um

[16:40] before we get to that a little bit more about what we think um makes auto production grade auto research actually production grade. Um the first is structure. So uh we have a treeb brace search uh where the agent shows you every attempt it’s run so that ideas as duv had mentioned can sort of compound on each other instead of starting from scratch. The second is observability. Um you can sort of open any attempt read

[17:10] the exact code change behind its score so you can see why the agent is taking the approach it is. And the third thing is steerability. So you have a sense of control. You can inject your own ideas and knowledge while the loop is running and have it try new directions in case it’s stuck. A little bit more about the treebased search. Um we will shortly demo this on our auto research dashboard, but um treebased auto research essentially treats the problem as a structured

[17:41] optimization process over code. Uh it starts with the root of the tree. As you can see the score was 0.5 um which is just the baseline program and a measured score. Every node after that route is a modified version of the code run against your eval with a score attached. You can think of this tree as an experiment graph. As you can see the search builds on what works. We’re finding good candidates and pruning bad ones. So when a branch improves a score it builds on those ideas and goes deeper next. which

[18:13] means that you can inspect the exact changes your auto research system is making and build off of those. So the next idea we talked about was observability. Um because you can see every one of the nodes in this treebased search, you can open any one of them and see exactly what changed. You can see your metric move in real time correlating to a movement correlating the movement to a reason. You can hover over over a node, get a summary of what

[18:44] changed, and you can open it and read the exact diff. So when the metric jumps, you can read the change that caused it. And typically, these runs go for hours across hundreds of experiments. So once you can see what it’s doing, the next natural step is to be able to change what it does. This is essentially when you stop watching and start to take over. Um, if I have an idea I want to try in plain English, um, I take the idea, it opens a new branch and you can see it try this

[19:15] new idea and have new nodes develop and a new curve. I can also put a budget to each node so it spends compute where I want. And this is the part that made it usable on real problems because you might have context and intuition that an agent doesn’t. At least for now, we believe it’s important to find ways to fold human judgment into the system whenever it’s necessary. I want to ground that point uh steerability in something real. Um because parameter because in parameter

[19:46] golf steerability was a big part of why we did well. Um this is an actual breakthrough from the competition. It started with our agent uh which is the line in pink. um for five days from April 15th to April 19th. Uh it kept trying new things, um new attention, compression, a richer stack, but the score essentially plateaued. There was a human in the community uh that shipped a clever new tokenizer, which is the blue line. Um, and within eight hours of emerging that change, our

[20:17] system picked it up, fused it with the pieces it had already been working on, and shipped the biggest jump in weeks. Running auto research on something this hard is less of a set it and forget it. Uh, it’s a collaboration where we steer the agent. We pull in ideas from the people around us. And steerability is essentially what makes that loop possible. It’s how real breakthroughs actually happen. Um, I’m going to hand it over to Dex and Jungao to talk a little bit more about

[20:49] how to get auto research set up. Um, we’ll essentially mimic the process that you guys were trying to do on your laptops. >> Okay. Um, so what we are going to do here is we just walk you guys through the high level idea like how how does it happen? We just use our mobile hotspot. Um so we will be freestyling a little bit here. Uh hope you don’t mind. Um so

[21:19] yeah can you just uh yeah okay maybe we can also walk through the whole doc being fed to uh claude. So >> yeah. So basically uh so you can go into the rebel and some like simple instruction like start the wo raw based on the readme and it should be like if the internet is good I think it should start the uh default wle run and uh we

[21:51] can also go over via the like the how is the wle command working. Yeah, this case you have a source file. The solution is basically the training script of mini PG. I assume like a eval command is I think Z also mentioned this is additional guidance or prompt that will guide the whole uh search process and the metric is a validation BPB. Uh

[22:21] this is like a hold out um uh loss like a loss only hold out set. Uh go is minimize and others are just configs we just mentioned. Oh, sorry. Eval commander is actually the the bash command that uh you’re going to run the uh uh run the eval and eventually it will output a uh score like it print a score to the terminal

[22:53] and it’s going to be passed by the agent and that’s the key uh signal that will drive the whole tri and error loops. >> Yeah. Um in meanwhile I can also show the dashboard. So if you go into the W dashboard um and I think there I did some wrong and you you basically see a lot of things and uh after the the command like auto booted

[23:25] by the agent um I think then you you will see the romping popped up and then you can try out the features we provide. Yeah. Um, do we have a run just to get started? >> Yeah, I think it’s just starting. >> Okay, still running saying um yeah, Claud is working.

[24:05] Uh question from the audience while you guys are doing that. Um one, is it possible to turn up the brightness on the dashboard or switch to light mode? >> Start again. >> I’m I’m right here. Can you turn the light mode on the dashboard? It’s a little hard to see. >> I see. Light mode. Forgot. Where is it? Is there

[24:41] uh second question is can auto research apply to RL? What is the scalar metric when there are multiple things to optimize? >> What is the >> can auto research apply to RL? What is the scalar metric when there are multiple things to optimize? >> I see. Yeah. Um it can definitely be applied to IO like apply to IO training scripts. Um I think there is a

[25:13] um derived a project called sobound uh speedr runner that’s actually exactly doing it like for post training aquin model uh for playing a game and uh yeah in that project you can apply auto research to the uh IR IR training scripts And um the second question you have a multiple objectives to optimize for.

[25:45] Um the idea is you eventually just combine them to a single metric like you either apply different weights on those different metrics or you treat some of the matrix as constraint and optimize for one of them. For example, if you’re doing things like fraud detection, you might hold the uh accuracy and trying to optimize the precision. Um and uh for

[26:15] parameter golf exactly you hold the model size as a constraint and you optimize for the accuracy of the system. Yeah, we can see the um agent already generated uh one node. So the zero zero node is basically the root node the baseline solution and 3.93 means the validation BPB attached to

[26:47] that solution and uh you can see the wos auto research already generated one node here um um here we also have a summary of the uh ideas it’s tried And uh seems like already getting improvement. Oh yeah, you can also >> also open the code and see what’s actually been changed.

[27:18] >> Yeah. Do we have a stability? >> Okay. Uh for stability you can basically tell the agent for example say like uh explore the quantization method. Is it connected? >> Yeah. Uhization method do not change the not just change the model config because we don’t like just want to do the hyperparame tuning. We also want to try like more aggressive

[27:49] method. >> I don’t think it’s connected. I think clock didn’t follow the instruction. Yeah, basically we also support you

[28:20] bring your claw code agent to our dashboard. We call it a bridged uh session. Um so basically yeah you can you can see the dashboard the tree structure the metric and the uh clock code at the same time and then you can tear clock code okay this is the uh the direction I want to steer the whole uh search process to >> checked in with some of you I think

[28:52] internet might be a little better uh some of you guys are using hotspot I know there’s some modal payment issues. We’re going to move on to the final part which is the competition aspect. Uh you don’t need modal for this and originally this was designed to be a 30inut competition but we will give you guys until the end of the day um a little bit more on what this is. You guys have all played Flappy Bird. Um

[29:22] we’re going to do a Flappy Wo Cup. So essentially, everyone hopefully has played Flappy Bird. You tap to flap. You dodge the pipes and you fly as far as you can. And your final score is dependent on how far you fly. We have turned this into an auto research problem. So instead of playing it, there’s a controller called should flap that decides every frame whether the bird should flap. Your job is to

[29:54] optimize that controller. The metric is the average score and you want that as high as possible with the highest score winning. With all games, there’s a twist. Uh we’re not just running this on Flappy Bird. Uh we’re running this across four different worlds. So the first world is normal, which is the classic game. The second is moving gap where the pipe gap drifts up and down. The third world has wind pushing the

[30:25] bird around. And the fourth world is variable which mixes all the conditions. Your score is the average across all four of these worlds. So you can’t just focus on one. Um a controller that does well in a normal game but dies in the wind won’t win. And the leaderboard scores you on a hidden validation set that you never see. So you can’t obviously overfit on the public game. A few rules uh mostly so it’s fair and

[30:57] it doesn’t break. Uh you only and we will share the GitHub repo for this shortly. Uh you only edit the controller which is a controller.py. You keep you should keep should flap signature exactly as it is. So you can’t touch the game or the evaluator. No imports, external libraries, file IO. So we’re keeping this self-contained. And in the spirit of keeping it fair, uh, no parallel compute allowed. So you would be using WICO for auto research.

[31:29] Um, everyone is defaulted to the same model, Opus 4.8. So it’s a level playing field. And remember, the local score that you see on your laptop isn’t going to match the leaderboard because of our hidden test set. Some tips. Um, you’ll get about 50 steps on WCO. Uh, actually this is with the 30 minute time time frame. So, uh, I guess you can run unlimited steps until the

[32:00] end of the day. Um, can start from the baseline. uh the baseline already works. So improve the code rather than rewriting the controller. Uh think about making small focused edits. Um things like tuning the safety margin, the velocity keyboard, the bottom buffer, adjusting the behavior per world and um maybe implement some of the features we talked about today. Whether it’s inspecting nodes that scored well, building on them, bringing in ideas from outside, um, and trying several

[32:32] directions. This is the instructions for the game. Um, by the way, you guys are playing for a Nintendo Switch. Uh the way that we’re going to determine who wins is for your team name, put in your email and by the end of the day, the highest score uh we will reach out to the person that that is. In the meantime, we’re going to continue answering questions from our Slido or uh

[33:04] please raise your hand if you have any questions. Okay, we’re just about to wrap up here. Um scores look like they’re coming in. I don’t know who Fern Nog is, but a little suspicious because there’s only one node and so we will be inspecting your runs to ensure that there’s no cheating going on. Um, [laughter] nice try. Uh, we will be opening this competition uh till

[33:34] midnight tonight. um we will find a way to get to you can put in your email or we’re also we also have your emails uh from the runs that you guys are doing or you can just contact us on our website. But um feel free feel free to keep going at it. And um thank you all for coming.

[34:10] >> [music]