A IA agora cria seus próprios mundos de treinamento. Eu reconstruí um deles.
Autoria: Prompt Engineer 48 · 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: AI Now Builds Its Own Training Worlds. I Rebuilt One. · Canal: Prompt Engineer 48 · 06:13 · Assistir no YouTube
Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Ferramentas de desenvolvimento com IA, Modelos de IA
O vídeo apresenta o CompoWorld, uma abordagem para criar ambientes de treino para agents que usam ferramentas, combinando serviços reutilizáveis e tarefas verificáveis. O paper relata ganhos em oito benchmarks, mas os resultados variam e são dos próprios autores. O repo público contém 20 trajetórias de exemplo e um link para o modelo, mas não inclui o gerador de ambientes, então não permite reproduzir o trabalho completo. O apresentador recria a ideia em uma versão pequena, com três serviços, e demonstra como tarefas encadeadas ficam mais difíceis.
Pontos-chave
Seção intitulada “Pontos-chave”- O CompoWorld combina serviços reutilizáveis em tarefas para treinar agents que usam ferramentas.
- O paper reporta uma melhora média de 9,17 pontos em oito benchmarks; os ganhos são desiguais.
- O maior salto citado é de 22 pontos no Automation Bench.
- O repo tem um arquivo com 20 trajetórias de exemplo, mas não contém o gerador nem os 448 serviços.
- A reconstrução do apresentador é um protótipo próprio de cerca de 100 linhas de Python, não o código do paper.
- O protótipo encadeia calendário, sistema de arquivos e rastreador de tarefas por meio de um grafo de dependências.
- As tarefas são verificadas pelo estado final, e não pela comparação das ações executadas.
- Um agente simplório teve menor taxa de sucesso em tarefas com mais etapas encadeadas.
- O apresentador não treinou um modelo nem reproduziu os resultados do paper.
Capítulos
Seção intitulada “Capítulos”| Início | Capítulo | Resumo |
|---|---|---|
| 00:00 | A proposta do CompoWorld | O vídeo explica como serviços reutilizáveis e tarefas geradas por composição podem criar mundos de treino para agents. |
| 01:34 | Resultados e limites do repo | O apresentador examina os resultados dos benchmarks e observa que o repo não contém o gerador necessário para reproduzir o paper. |
| 02:37 | Análise das trajetórias de exemplo | As 20 trajetórias mostram tarefas compostas por vários serviços, com ferramentas genéricas e dependências entre etapas. |
| 04:11 | Reconstrução em pequena escala | O protótipo gera tarefas a partir de um grafo de dependências e as verifica pelo estado final dos serviços. |
| 05:42 | Conclusões e o que falta reproduzir | O apresentador resume os limites dos resultados e do repo, e recomenda aguardar a publicação do código para reproduzir o paper. |
Citações
Seção intitulada “Citações”Um script gerou, verificou e criou 60 delas em menos de um segundo neste laptop. — 00:00
A reprodução completa a partir deste repo não é possível. — 02:37
Ele não compara as ações. Examina o estado final. — 04:41
Quanto mais serviços você encadeia, mais difícil fica a tarefa. — 05:12
Se você quer reproduzir o paper, espere o código. — 05:42
Conceitos e entidades
Seção intitulada “Conceitos e entidades”- CompoWorld (conceito): Abordagem apresentada no paper para escalar ambientes de treinamento por meio da composição de serviços e tarefas.
- Compositional Environment Scaling for General Agents (conceito): Título do paper sobre o método CompoWorld para criar ambientes compostos para agents.
- Qwen3.6 35B A3B (modelo): Modelo que, segundo o vídeo, foi treinado pelos autores do paper.
- Claude Opus 4.6 (modelo): Modelo que, segundo o paper, foi superado pelo modelo treinado no Automation Bench.
- Toy World (ferramenta): Protótipo de cerca de 100 linhas de Python criado pelo apresentador para demonstrar a ideia em pequena escala.
- Python (ferramenta): Linguagem usada pelo apresentador para carregar as trajetórias de exemplo e construir seu protótipo.
- AutomationBench (conceito): Benchmark no qual o vídeo destaca um ganho de 22 pontos nos resultados reportados pelos autores.
- RunPod (empresa): Serviço de GPUs que o apresentador recomenda para quem precisa de recursos de computação.
Tradução completa (pt-BR)
Seção intitulada “Tradução completa (pt-BR)”00:00 Aqui está uma tarefa de cinco etapas. Leia uma nota, coloque a reunião no calendário, adicione uma tarefa, encerre uma tarefa antiga e escreva um relatório. Ninguém escreveu essa tarefa. Um script a gerou, verificou e criou 60 versões em menos de um segundo neste laptop. Essa é a ideia central de um novo artigo chamado CompoWorld. No final, vou mostrar como reconstruí isso e em que ponto o projeto real deixa de ser open source. Então, este é o artigo: CompoWorld, Compositional Environment Scaling for General Agents. São 12 autores. Foi submetido pela primeira vez em 27 de setembro e revisado
00:31 em 30 de setembro. O problema é simples. Para treinar um agent que usa ferramentas, você precisa de mundos de prática com tarefas e de uma forma de verificar a resposta. Criá-los manualmente não é escalável. Então, eles mantêm uma biblioteca de serviços reutilizáveis. Agents de programação transformam descrições de ferramentas em serviços funcionais com estado tipado. Quando uma ferramenta não pode ser implementada, um modelo de mundo a simula. Depois, uma caminhada aleatória pelo grafo de dependências conecta os serviços. Assim, as informações precisam passar de um serviço para o seguinte.
01:02 E os números, se você olhar aqui: 448 serviços, 10.132 ferramentas, 3.000 trajetórias para fine-tuning supervisionado e 1.000 tarefas para aprendizado por reforço. O modelo que eles treinaram é o Qwen 3.6 35B A3B. Guarde isso, porque quero conferir o que o repo realmente oferece. Aqui está a tabela de resultados do repo. Oito benchmarks, e o ganho médio é de 9,17 pontos. Vale lembrar que são pontos absolutos, não porcentagem. O Tau cubed banking vai de 10,65 para 16,49.
01:34 Deep planning: de 26,04 para 35,21. Vita bench: de 38,94 para 49,44. O maior resultado é no automation bench, de 10,33 para 32,33. Isso representa mais 22 pontos. E o skills bench vai de 32,52 para 47,71. O artigo diz que isso supera Claude Opus 4.6 no automation bench. Agora, deixe-me ser cético por um minuto. O WebArena 2.0 só sobe de 34,47 para 36,09, cerca de 1,6 ponto, e o ALE vai de 7,77 para
02:07 13,59, um salto melhor, mas ainda uma pontuação baixa. Então, o ganho nessa tabela é real, mas é desigual. E esses são os números dos próprios autores. Eu não os reproduzi, e não posso reproduzi-los — vou mostrar por quê. Então, vamos abrir o repo. Ele tem 22 stars, zero forks e não tem arquivo de licença. Dentro da pasta compo world há um readme e um arquivo de dados com 20 trajetórias de exemplo, cerca de 3,85 MB. Não há um gerador de ambientes aqui. Não há 448 serviços. O
02:37 modelo está vinculado no Hugging Face, mas o componente que cria os mundos não está neste repo. Então, não é possível reproduzir o trabalho por completo usando apenas este repo, e quero deixar isso bem claro. O que podemos fazer é ler esses 20 exemplos. Carreguei-os com Python. Cada um usa de cinco a sete serviços. Por exemplo, uma tarefa de operações jurídicas usa Seatbase, ServiceM8, Neon, ABM Dev e Brevo. Cada tarefa disponibiliza ao agent apenas quatro ferramentas, e ele precisa descobrir as demais por meio de um gateway. As tarefas duram entre 15 e 48 etapas
03:08 e entre 37 e 95 chamadas de ferramenta. As tags de capacidade incluem coisas como restrição entre ambientes, dependência sequencial e ramificação condicional. Deixe-me abrir a primeira. É uma tarefa de operações jurídicas datada de 15 de janeiro, e o usuário pede a execução completa do pagamento de um acordo para um caso, seguindo as regras internas e respeitando uma restrição rígida: não mexer em nada que pertença ao caso encerrado. O agent não começa com uma caixa de ferramentas enorme. Ele começa com quatro ferramentas genéricas: listar serviços, listar ferramentas, descrever ferramenta e
03:39 chamar ferramenta. A primeira chamada retorna 15 serviços, e apenas cinco deles estão na lista de serviços da tarefa. Essa execução levou 74 mensagens e 51 chamadas de ferramenta, e recebeu nota 1,0. Então, o que posso fazer por conta própria? Posso reconstruir a ideia em pequena escala. Certo, esta é a minha versão. Tem cerca de 100 linhas de Python. Chama-se Toy World. E vale lembrar: este é o meu brinquedo. Não é o código do artigo. Rodei tudo neste laptop com uma RTX 4060 de 8 GB, e ele nem sequer usa a GPU. Há três serviços: um
04:11 calendário, um sistema de arquivos e um gerenciador de tarefas. Cada um tem seu próprio estado e suas próprias ferramentas. Depois, temos a parte do artigo: o grafo de dependências. Cada ferramenta informa o que consome e o que produz. A leitura de um arquivo produz uma nota de reunião. Uma nota de reunião alimenta o calendário. Criar um evento alimenta uma tarefa. E uma tarefa alimenta a criação de um relatório. Uma caminhada aleatória por esse grafo é uma tarefa. Vamos executá-la. O gerador escolhe um nó, cria um plano com três, quatro ou cinco etapas e escreve a instrução em inglês simples. Aqui está uma. Leia a
04:41 nota da retrospectiva. Coloque a reunião no calendário. Adicione a tarefa preparar retrospectiva, com vencimento na data da reunião. Marque preparar demonstração como concluída. E escreva o resumo em um arquivo de relatório. Agora, o verificador não compara as ações. Ele analisa o estado final. O evento está lá com a data e a hora certas? A tarefa está lá? O arquivo foi escrito com o texto exato? Uma tarefa só conta como verificada se o plano de referência for aprovado e um plano vazio falhar. Assim, uma tarefa que já esteja concluída não pode passar despercebida. Gerei 60 tarefas, e as 60 foram
05:12 verificadas. Para ser justo, isso acontece por construção, já que fui eu que escrevi o solver de referência. A parte interessante é a dificuldade. Criei de propósito um agent bem burro que pula etapas aleatoriamente em tarefas de três etapas. Ele é aprovado em 60% das tarefas de quatro etapas e em 40% das de cinco etapas — 15%. Então, quanto mais serviços você encadeia, mais difícil fica a tarefa. É esse o controle que o artigo está ajustando, mas em uma escala muito maior. Se eu tivesse mais uma semana, substituiria minha baseline burra por um modelo de verdade com tool calling e veria onde ele falha. Não fiz esse teste, então
05:42 não vou afirmar que obtive um resultado. Então, esta é a minha conclusão. A ideia se sustenta. Consegui reconstruir a versão pequena em uma tarde, e a dificuldade aumenta conforme a cadeia cresce. Os números são dos próprios autores, e o maior salto — mais 22 pontos no automation bench — é em um benchmark. Eu não interpretaria isso como mais 22 pontos em todos os casos. E o repo oferece um readme, 20 trajetórias e um link para o modelo, mas não um gerador. Se você quer aprender como funciona o escalonamento de ambientes, crie um brinquedo como o meu. Se quiser reproduzir o artigo, espere pelo código.
06:13 Treinar um modelo de 35 bilhões de parâmetros não é algo que você faça em um laptop. Se você está procurando GPUs baratas e confiáveis, eu uso RunPod, e o link está na descrição. Então, neste vídeo, vimos o que a CompoWorld afirma, o que o repo realmente contém e como criei uma versão com três ferramentas que gera e verifica tarefas. Pode experimentar no seu próprio sistema e me dizer nos comentários se o próximo vídeo deve ser sobre o skill two EMV do mesmo repo. Vejo vocês em outro vídeo.
Transcrição original
[00:00] Here is a five-step task. Read a note, put the meeting on the calendar, add a task, close an old task, and write a report. Nobody wrote it. A script generated it, checked it, and made 60 of them in under a second on this laptop. This is the core idea of a new paper called CompoWorld. By the end, I will show you how I rebuilt it and where the real project stops being open. So, this is the paper, CompoWorld, Compositional Environment Scaling for General Agents, 12 authors, first submitted on 27 September, and revised
[00:31] on 30 September. The problem is simple. To train an agent that uses tools, you need practice worlds with tasks and a way to check the answer. Building those by hand does not scale. So, they keep a library of reusable services. Coding agents turn tool descriptions into working services with type state. When a tool cannot be implemented, a world model simulates it. Then, a random walk over the dependency graph links services together. So, information has to flow from one service into the next.
[01:02] And the numbers, if you look here, 448 services, 10,132 tools, 3,000 trajectories for supervised fine-tuning, and 1,000 tasks for reinforcement learning. The model they trained is Qwen 3.6 35B A3B. Hold on to that because I want to check what the repo actually gives us. Here is the results table from the repo. Eight benchmarks, and the average gain is 9.17 points. Mind you, these are absolute points, not not percent. Tau cubed banking goes from 10.65 to 16.49.
[01:34] Deep planning, 26.04 to 35.21. Vita bench, 38.94 to 49.44. The big one is automation bench, 10.33 to 32.33. That is plus 22 points. And skills bench goes from 32.52 to 47.71. The paper says this beats Claude Opus 4.6 on automation bench. Now, let me be a skeptic for a minute. We the bench 2.0 only moves from 34.47 to 36.09, about 1.6 points, and ALE goes from 7.77 to
[02:07] 13.59, a better jump, but still a low score. So, the gain is real in this table, but it is uneven. And these are the authors’ own numbers. I did not reproduce them, and I cannot and I will show you why. So, let’s go ahead and open the repo. It has 22 stars, zero forks, and there is no license file. Inside, the compo world folder has a readme and one data file with 20 example trajectories, about 3.85 MB. There is no environment generator here. There are no 448 services. The
[02:37] model is linked on hugging face, but the thing that builds the worlds is not in this repo. So, full reproduction from this repo is not possible, and I want to say that clearly. What we can do is read those 20 examples. I loaded them with Python. Each one uses five to seven services. For example, one legal ops task uses seat base, service M, eight, neon, ABM dev, and brevo. Each one gives the agent only four tools, and the agent has to discover the rest through a gateway. The tasks run between 15 and 48 steps,
[03:08] and between 37 and 95 tool calls. The capability tags say things like cross environment constraint, sequential dependency, and conditional branching. Let me open the first one. It is a legal ops task dated 15th January, and the user asks for a full settlement disbursement run for one matter with house rules to follow and one hard constraint, do not touch anything that belongs to the closed matter. The agent does not start with a big toolbox. It starts with four generic tools, list services, list tools, describe tool, and
[03:39] call tool. The first call returns 15 services, and only five of them are in the task’s service list. This run took 74 messages and 51 tool calls, and it scored 1.0. So, what can I do on my own? I can rebuild the idea small. Okay, so this is my version. It is about 100 lines of Python. It is called Toy World. And mind you, this is my toy. It is not the paper’s code. I ran it on this 8 GB RTX 4060 laptop, and it does not even touch the GPU. There are three services, a
[04:11] calendar, a file system, and a task tracker. Each one has its own state and its own tools. Then we have the part from the paper, the dependency graph. Each tool says what it consumes and what it produces. A file read produces a meeting note. A meeting note feeds the calendar. Create an event feeds a task. And a task feeds a report write. A random walk through this graph is a task. Let’s run it. The generator picks a node, builds a plan with three, four, or five hops, and writes the instruction in plain English. Here is one. Read the
[04:41] retro note. Put the meeting on the calendar. Add a task prep retro due on the meeting date. Mark prep demo prep complete. And write the summary to a report file. Now, the checker, it does not compare the actions. It looks at the final state. Is the event there with the right date and time? Is the task there? Is this Is the file written with the exact text? A task only counts as verified if the reference plan passes and an empty plan fails. So, a task that is already done cannot slip through. I generated 60 tasks, and all 60 were
[05:12] verified. To be fair, that is by construction since I wrote the reference solver. The interesting part is difficulty. I made a deliberately dumb agent randomly skips steps on three hop tasks. It passes 60% on four hops, 40% on five hops, 15%. So, the more services you chain, the harder the task gets. That is the dial the paper is turning at a much bigger scale. If I had another week, I would swap my dumb baseline for a real model with tool calling and see where it breaks. I did not run that, so
[05:42] I’m not going to claim a result. So, here’s where I land. The idea holds up. I could rebuild the small version in an afternoon and the difficulty does scale with the chain. The numbers are the authors own and the biggest jump plus 22 on automation bench is one benchmark. I would not read it as plus 22 everywhere. And the repo gives you a read me 20 trajectories and a model link but not a generator. If you want to learn how environment scaling works, build a toy like mine. If you want to reproduce the paper, wait for the code.
[06:13] Training at 35 billion parameter model is not something you do on a laptop. If you’re looking for a cheap and reliable GPUs, I use RunPod and the link is in the description. So in this video we have seen what Compoworld claims, what the repo really contains and how I built a three-tool version that generates and verifies tasks. Go ahead and try it on your own system and let me know in the comments if the next one should be skill two EMV from the same repo. I’ll see you in another one.