O que é o Google RRSI?

Autoria: Data Science in your pocket · 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: What is Google RRSI ? · Canal: Data Science in your pocket · 09:23 · Assistir no YouTube

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

Resumo

O vídeo apresenta RRSI, uma abordagem do Google para a melhoria recursiva e regularizada de agent harnesses, sem alterar os pesos do modelo. A evolução sem controles pode levar a overfitting: o harness memoriza tarefas do benchmark e perde desempenho em tarefas fora da distribuição. RRSI limita e registra as mudanças propostas, filtra possíveis vazamentos do benchmark e exige que ganhos compensem ruído e custo em tokens. Segundo os resultados apresentados, a abordagem preserva parte dos ganhos fora da distribuição e reduz o uso de tokens em comparação com a evolução sem regularização.

Pontos-chave

O harness inclui system prompts, fluxo de controle, ferramentas, memória e gestão de contexto; seus componentes podem mudar sem alterar os pesos do modelo.
A evolução recursiva sem regularização pode memorizar tarefas e respostas do conjunto usado para evoluir o harness.
O orçamento de edições diminui ao longo das rodadas, facilitando atribuir resultados a mudanças específicas.
Um registro de tentativas ajuda o proposer a evitar falhas repetidas e a desenvolver mudanças que deram certo.
Um critic rejeita alterações que parecem incluir nomes, entidades ou respostas específicas do benchmark.
A seleção exige ganhos acima de um limite ajustado ao ruído e que compensem eventuais custos adicionais de tokens.
Um pruner remove componentes sem contribuição positiva recente.
O vídeo relata ganhos de até 14,1 pontos no split de evolução e ganhos mantidos em benchmarks fora da distribuição.
Na comparação apresentada, o harness final do RRSI usa menos tokens de política que o da evolução sem regularização.

Capítulos

Início	Capítulo	Resumo
00:00	O harness e a evolução recursiva	O vídeo define o harness e explica como ele pode evoluir sem que os pesos do modelo mudem.
01:34	O risco de overfitting	A evolução automatizada pode levar o harness a memorizar tarefas do split usado repetidamente.
03:36	Como o RRSI regulariza a busca	A abordagem combina orçamento de edições decrescente, histórico de mudanças, exploração e filtros contra vazamento.
06:13	Critérios de seleção e resultados	O vídeo descreve os critérios de aceitação e relata ganhos de generalização e redução de tokens.
07:46	Ablação e conclusão	A comparação de ablação indica que as regularizações de proposta e aceitação contribuem para o desempenho fora da distribuição.

Citações

E se um agente de IA pudesse reescrever seu próprio manual de operação? — 00:00

No conjunto de treinamento, os ganhos parecem enormes; mas, em benchmarks fora da distribuição, eles diminuem ou desaparecem. — 02:35

Ajustes genéricos no nível dos mecanismos — planejamento melhor, novas tentativas melhores, higiene de memória melhor — passam para a avaliação. — 06:43

Lembre-se do orçamento, registre o histórico, filtre vazamentos, cobre pelos tokens e pode o que não serve. — 09:23

Conceitos e entidades

RRSI (conceito): Abordagem de melhoria recursiva e regularizada de agent harnesses apresentada no vídeo.
agent harness (conceito): Conjunto de componentes ao redor do modelo que define instruções, fluxo de controle, ferramentas, memória e contexto.
overfitting (conceito): Ajuste excessivo ao conjunto de tarefas usado na evolução, que pode prejudicar o desempenho fora dessa distribuição.
Google (empresa): Empresa associada ao artigo de pesquisa sobre RRSI mencionado no vídeo.
Harvey (ferramenta): Benchmark citado na comparação de ablação apresentada no vídeo.

Tradução completa (pt-BR)

00:00 E se um agente de IA pudesse reescrever o próprio manual de operação, seus prompts, suas ferramentas, sua memória, e ficar um pouco melhor a cada rodada sem que ninguém jamais mexesse no modelo em si? Isso é o autoaperfeiçoamento recursivo no nível do harness. É poderoso e tem uma falha fatal. Se deixado por conta própria, ele trapaceia. Hoje, vamos analisar o RRSI, o autoaperfeiçoamento recursivo regularizado de harnesses de agentes, um artigo de pesquisa do Google que ensina agentes a evoluir com responsabilidade.

00:32 Primeiro, o que exatamente é um harness? Pense em um modelo de linguagem grande como um motor congelado: poderoso, mas inútil por conta própria. O harness é tudo o que é acoplado a esse motor para transformá-lo em um agente: os system prompts que dizem quem ele deve ser, o fluxo de controle que decide o que acontece em seguida, as ferramentas que ele pode chamar, a memória que pode ler e escrever e o gerenciamento de contexto que decide o que o modelo realmente vê em cada etapa. Aqui está uma ideia fundamental de toda essa linha de pesquisa. Os pesos do modelo

01:03 nunca mudam. Todo o aprimoramento, toda a evolução acontece na estrutura ao redor. E o harness importa muito mais do que a maioria das pessoas pensa. Pegue exatamente o mesmo modelo congelado e envolva-o em três harnesses diferentes. Você terá três agentes muito diferentes. Um harness fraco desperdiça o potencial do modelo. Um ótimo harness parece uma atualização gratuita do modelo. Até agora, esse harness era feito à mão, com engenheiros analisando trajetórias malsucedidas, ajustando prompts e adicionando ferramentas. Isso funciona, mas sua escala depende da

01:34 paciência humana. A pergunta óbvia é: por que não automatizar isso? Automatizar as edições do harness cria um ciclo parecido com este. Comece com o harness atual. Um proponente, que também é um LLM, lê o feedback de execuções malsucedidas e bem-sucedidas e sugere edições. Reescrever este prompt, adicionar esta ferramenta, mudar esta lógica de novas tentativas. As candidatas passam por uma triagem e, em seguida, são avaliadas em uma divisão do benchmark. Um seletor decide se a melhor candidata substitui o

02:05 harness atual ou se mantemos o incumbente. Depois, o ciclo se repete. Rodada após rodada, o harness reescreve a si mesmo. Os pesquisadores chamam isso de autoaperfeiçoamento recursivo no nível do sistema de agentes: o sistema aprimora a própria estrutura que o define. E, na divisão de treinamento, funciona muito bem. As pontuações sobem rodada após rodada. Mas há um porém. O ciclo seleciona edições que têm bom desempenho na divisão usada para evoluir o sistema, o mesmo conjunto finito

02:35 de tarefas repetido várias vezes. Então, o harness começa a memorizar. Ele codifica nomes de tarefas diretamente. Incorpora respostas. Adiciona truques que só funcionam naqueles benchmarks específicos. Na distribuição de treinamento, os ganhos parecem enormes, mas, quando você executa esse harness em benchmarks fora da distribuição, esses ganhos diminuem ou desaparecem por completo. Alguns harnesses evoluídos acabam ficando piores do que eram no início. Em aprendizado de máquina, chamaríamos isso de sobreajuste. O diagnóstico do RRSI:

03:06 a evolução sem regularização é apenas sobreajuste a um conjunto de teste sem gradientes. Então, como corrigir o sobreajuste? O aprendizado de máquina respondeu a isso décadas atrás: regularize. Reduza a capacidade do modelo à medida que o treinamento avança. Pare cedo. Penalize a complexidade. Pode pesos que não são mais úteis. E nunca, jamais, confie na pontuação de treinamento. Valide com dados reservados. O RRSI pega todo esse conjunto de práticas e

03:36 o aplica à evolução de harnesses. Ele não restringe o que o agente pode mudar. Qualquer componente continua sendo uma opção. Em vez disso, regulariza como a busca propõe mudanças e quais mudanças têm permissão para sobreviver. Duas extremidades do ciclo, dois conjuntos de restrições. Eis a máquina em quatro partes. A cada rodada, o proponente analisa o harness atual e um histórico estruturado de tudo o que já foi tentado, e gera edições candidatas dentro de um orçamento que diminui com o tempo, além de um incentivo

04:09 para componentes que ainda não foram explorados. As candidatas passam por um crítico que rejeita qualquer coisa com aparência de vazamento do benchmark antes da avaliação, que é cara. As que sobrevivem recebem pontuações. Então, o seletor aplica três filtros. Um limite ajustado ao ruído, que rejeita ganhos insignificantes e pequenos. Uma regra de custo de tokens, que exige que cada token adicional se justifique com ganhos medidos. E um podador que elimina componentes que deixaram de contribuir. Se nada passar pelos filtros, o

04:40 incumbente permanece inalterado. Vamos examinar de perto a primeira restrição do proponente: o orçamento de edições com decaimento temporal. No início da evolução, uma candidata pode agrupar várias edições coordenadas. É nessa fase que acontecem grandes mudanças arquiteturais. Por exemplo, numa etapa de planejamento, reconfigurar o ciclo de ferramentas. Mas, à medida que as rodadas avançam, o orçamento diminui. As candidatas das rodadas finais recebem cada vez menos edições por proposta. Por quê? Atribuição. Quando uma candidata muda cinco coisas

05:11 e a pontuação muda, não dá para saber qual edição ajudou. Pequenas edições nas rodadas finais tornam cada mudança aceita passível de avaliação e impedem que o harness se transforme numa reescrita enorme e confusa que ninguém entende. É pelo mesmo motivo que reduzimos gradualmente as taxas de aprendizado. Explore com ousadia no início; refine com cuidado no final. Segunda restrição: memória e exploração. Toda candidata já proposta é registrada em um histórico: qual componente

05:41 ela alterou, a hipótese por trás da mudança, o diff real, como a pontuação e o custo mudaram e se ela foi aceita. O proponente lê esse histórico para deixar de repetir tentativas fracassadas e começar a desenvolver o que deu certo. Além disso, o RRSI acompanha quais componentes do harness já foram testados e quais continuam intocados. Se a evolução estagnar por várias rodadas sem nenhuma edição aceita, um bônus de exploração direciona o proponente para componentes ainda não explorados. É um mapa do espaço de busca que ilumina

06:13 os cantos escuros, em vez de ficar percorrendo o mesmo corredor para sempre. Agora, o lado do seletor, que entra em ação antes mesmo de a avaliação começar. O crítico é um filtro contra vazamento. Ele lê cada candidata e pergunta: esta edição menciona nomes específicos de tarefas, entidades ou respostas específicas do benchmark, ou uma lógica que só é ativada na divisão de avaliação? Se sim, ela é rejeitada na hora. Nenhuma execução cara é desperdiçada. Esse filtro elimina exatamente o modo de falha que

06:43 vimos antes. O harness não pode codificar diretamente o conjunto de teste se as candidatas que fazem isso nunca passam pelo crítico. Só melhorias em mecanismos genéricos chegam à avaliação: planejamento melhor, novas tentativas melhores, gerenciamento de memória melhor. Mais três filtros protegem a decisão final. Primeiro, o limite ajustado ao ruído. As pontuações dos benchmarks têm ruído, então a candidata precisa superar o incumbente por uma margem; caso contrário, uma longa sequência de pequenos ganhos é apenas um lento declínio. Segundo, a

07:14 regra de custo de tokens. Se a sua edição faz o agente gastar mais tokens, esse custo precisa ser compensado com ganhos medidos. Nada é de graça. Terceiro, o podador. Qualquer componente sem contribuição positiva recente é sinalizado e removido. Juntos, esses mecanismos mantêm o harness enxuto. Cada peça precisa justificar seu lugar. Cada token precisa valer a pena. Então, funciona? Em oito benchmarks que abrangem programação, tarefas de espaço de trabalho com agentes e projeto de engenharia, o RRSI obtém ganhos de até 14,1 pontos na

07:46 divisão contra a qual evolui, como esperado. Mas eis o que importa: ele mantém até 4,7 pontos de ganho em cinco benchmarks fora da distribuição, ganhos que a evolução sem regularização descarta. E tem mais: o harness final é executado com 30% menos tokens de política do que o harness sem regularização. Melhor generalização, inferência mais barata. A bateria de avaliação também não é brincadeira: Terminal Bench, SWB Bench Verified, Harvey Lab, Job Inch, GDPVAL,

08:19 Apex Agents, e Design, e Frontiering. A evidência mais clara é o estudo de ablação no Harvey LAB, em que todas as variantes compartilham o mesmo harness inicial, a mesma política congelada, o mesmo número de rodadas e o mesmo orçamento de candidatas. A evolução sem regularização realmente vence na divisão usada para evoluir: 92,8 contra 90,5 do RRSI. Mas veja a média fora da distribuição: 40,3 contra 43,6. E os tokens por teste: 3,8 milhões contra

08:51 2,42 milhões. Remova apenas as regularizações das propostas e o resultado fora da distribuição cai para 41,9. Remova as regularizações de aceitação e cai para 41,0. As duas partes do projeto contribuem. A evolução sem regularização vence na divisão e perde o rumo. A ideia geral é que o autoaperfeiçoamento recursivo é real. Ele já acontece no nível do harness e, sem regularização, engana você. Em retrospecto, a receita do RRSI é quase banal.

09:23 E você sabe: controle o orçamento, lembre-se do histórico, filtre o vazamento, cobre pelos tokens, elimine o peso morto. Banal, e funciona. Melhor generalização com menos tokens. O código está disponível em open source sob a licença Apache 2 no GitHub. A página do projeto é regularizedsi.com. Se esta explicação foi útil, inscreva-se no Data Science in Your Pocket e até a próxima.

Transcrição original

[00:00] What if an AI agent could rewrite its own operating manual, its prompts, its tools, its memory, and get a little better every single round without anyone ever touching the model itself? That’s recursive self-improvement at the harness level. It’s powerful and it has a fatal flaw. Left alone, it cheats. Today, we break down RRSI, regularized recursive self-improvement of agent harnesses, a Google research paper that teaches agents to evolve responsibly.

[00:32] First, what exactly is a harness? Think of a large language model as a frozen engine, powerful but useless on its own. The harness is everything bolted around that engine that turns it into an agent, the system prompts that tell it who to be, the control flow that decides what happens next, the tools it’s allowed to call, the memory it can read and write, and the context management that decides what the model actually sees on every step. Here’s a key insight of this whole line of research. The model’s weights

[01:03] never change. All of the improvement, all of the evolution happens in the surrounding scaffolding. And the harness matters far more than most people think. Take the exact same frozen model and wrap it in three different harnesses. You get three very different agents. A weak harness wastes the model. A great harness feels like a free model upgrade. Until now, that harness was handcrafted, engineers staring at failed trajectories, tweaking prompts, adding tools. That works, but it scales with

[01:34] human patience. The obvious question, why not automate it? Automating harness edits gives you a loop that looks like this. Start with today’s harness. A proposer, itself an LL, reads feedback from failed and successful runs and suggests edits. Rewrite this prompt, add this tool, change this retry logic. Candidates get screened, then evaluated on a benchmark split. A selector decides whether the best candidate replaces the current

[02:05] harness or whether we keep the incumbent. Then the loop repeats. Round after round, the harness rewrites itself. Researchers call this recursive self-improvement at the agent system level, the system improving the very scaffolding that defines it. And on the training split, it works beautifully. Scores climb round after round. Here’s the catch. The loop selects edits that score well on the evolve split, the same finite set

[02:35] of tasks over and over. So, the harness starts memorizing. It hard codes task names. It bakes in answers. It adds hacks that only work on those exact benchmarks. On the training distribution, the gains look huge, but run that harness on out-of-distribution benchmarks, and those gains shrink or vanish entirely. Some evolved harnesses end up worse than the one they started from. In machine learning, we’d call this overfitting. RRSI’s

[03:06] diagnosis, unregularized evolution is just gradient-free overfitting to a test set. So, how do you fix overfitting? Machine learning answered this decades ago. You regularize. You shrink the capacity of your model as training progresses. You stop early. You penalize complexity. You prune dead weights. And you never ever trust the training score. You validate on held-out data. RRSI takes this entire playbook and

[03:36] ports it to harness evolution. It doesn’t restrict what the agent may change. Any component is still fair game. Instead, it regularizes how the search proposes changes and how W H I C it changes get to survive. Two ends of the loop, two sets of constraints. Here’s the four machine. Each round, the proposer looks at the current harness plus a structured history of everything tried before and emits candidate edits under a budget that shrinks over time and with a nudge

[04:09] toward components nobody has explored yet. Candidates pass through a critic that rejects anything smelling of benchmark leakage before expensive evaluation. Survivors get scored. Then the selector applies three gates. A noise-adjusted floor that refuses tiny insignificant wins. A token cost rule that demands every extra token pay for itself in measured gain. And a pruner that amputates components that stopped pulling their weight. If nothing passes the gates, the

[04:40] incumbent survives unchanged. Let’s zoom into the proposer’s first constraint, the temporally annealed edit budget. Early in evolution, a candidate may bundle several coordinated edits. That’s when big architectural moves happen. At a planning stage, rewire the tool loop. But as rounds progress, the budget decays. Late candidates get fewer and fewer edits per proposal. Why? Attribution. When one candidate changes five things

[05:11] and the score moves, you can’t tell which edit helped. Small late edits make every accepted change accountable and stop the harness from drifting into a giant tangled rewrite nobody understands. It’s the same reason we anneal learning rates. Explore boldly early, refine carefully late. Second constraint, memory and exploration. Every candidate ever proposed is written into a history ledger, which component

[05:41] it touched, the hypothesis behind it, the actual diff, how the score and cost moved, and whether was accepted. The proposer reads this ledger so it stops retrying failures and starts building on wins. On top of that RRSI tracks which harness components have been tried and which are untouched. If evolution stalls several rounds with no accepted edit and exploration bonus pushes the proposer toward unexplore components. It’s a map of the search space lighting

[06:13] up the dark corners instead of pacing the same hallway forever. Now the selector side and it starts before evaluation even happens. The critic is a leakage screen. It reads each candidate and asks, does this edit mention specific task names, specific entities or answers from the benchmark, logic that only fires on the evaluation split? If yes, reject it on the spot. No expensive rollouts wasted. This one filter kills the exact failure mode we

[06:43] saw earlier. The harness can’t hardcode the test set if the test set never survives the critic. Only generic mechanism level improvements. Better planning, better retries, better memory hygiene make it through to evaluation. Three more gates guard the final decision. First, the noise adjusted floor. Benchmark scores are noisy so candidate must clear margin above the incumbent otherwise a long chain of tiny wins is just a slow walk downward. Second, the

[07:14] token cost rule. If your edit makes the agent burn more tokens that cost must be paid for with measured gain. No free lunches. Third, the pruner. Any component with no recent positive contribution gets flagged and removed. Together they keep the harness lean. Every piece earning its place. Every token earning its keep. So does it work? Across eight benchmarks spanning coding, agentic workspace tasks, and engineering design RRSI gains up to 14.1 points on

[07:46] the split it evolves against expected. But, here’s what matters. It keeps up to 4.7 points on five out of distribution benchmarks, gains that unregularized evolution throws away. And the kicker, the final harness runs on 30% fewer policy tokens than the unregularized one. Better generalization, cheaper inference. The evaluation suite is no joke, either. Terminal bench, SWB bench verified, Harvey lab, job inch, GDPVAL,

[08:19] Apex agents, and design, and frontiering. The cleanest evidence is the ablation on Harvey LAB, where every variant shares the same starting harness, frozen policy, rounds, and candidate budget. Unregularized evolution actually wins the evolve split, 92.8 versus RRSI’s 90.5. But, look at out of distribution average, 40.3 versus 43.6. And tokens per trial, 3.8 million versus

[08:51] 2.42. Remove just the proposal regularizers and OOD drops to 41.9. Remove the acceptance regularizers, 41.0. Both halves of the design pull weight. Unregularized evolution wins the split and loses the plot. The big picture, recursive self-improvement is real. It’s already running at the harness level, and without regularization, it lies to you. RRSI’s recipe is almost boring in

[09:23] hindsight. And you know the budget, remember the history, screen the leakage, charge for tokens, prune the dead weight. Boring, and it works. Better generalization for fewer tokens. Code is open Apache 2 on GitHub. The project page is regularizedsi.com. If this breakdown helped, subscribe to Data Science in Your Pocket, and I’ll see you in the next one.