Autoaperfeiçoamento Recursivo, Explicado por Meio de um Projeto que Realmente o Faz

O "autoaperfeiçoamento recursivo" é uma daquelas expressões que, na maioria das vezes, é usada para significar uma sensação. Definido sem misticismo, é mais restrito do que isso e mais interessante: um sistema que propõe o seu próprio próximo experimento, executa-o e mantém ou retira o resultado segundo uma regra fixada antecipadamente, com os resultados a alimentar a ronda seguinte. A recursão não é magia e não é ilimitada — é um ciclo com uma função de pontuação, e a sua qualidade é inteiramente determinada pela honestidade com que essa função de pontuação é aplicada. O RSI-Jev, o projeto aberto de terceiros que constrói modelos de decisão Sistema Um ao estilo Jev, é um caso raro em que é possível ler o ciclo em vez de discutir sobre ele: cada hipótese, cada braço falhado e cada lançamento é publicado com os seus números, e o repositório é datado dia a dia. O modelo que esta página usa como exemplo prático é o RSI-Jev v6.0-VL, um modelo de decisão tipada de 4B publicado em 2026-10-06, o que está dentro da última semana. Não é o Jev da TypeSafe nem está afiliado à TypeSafe AI — a própria linha de licença do projeto diz exatamente isso, e o que servimos no OrcaRouter é o outro, typesafe/jev-1.13, no nosso endpoint systemone.

Um esclarecimento antes que a palavra "autoaperfeiçoamento" faça qualquer coisa, seguido de uma data. Isto não é um modelo que se reescreve a si próprio sem limites, e nada nesta página deve ser lido dessa forma. O ciclo em questão reescreve uma receita: propõe uma alteração no treino, registra o que espera que essa alteração faça, gasta tempo de GPU e, em seguida, ou mantém a alteração ou registra por que ela perdeu. O modelo é uma torre Qwen3.5-4B-Base com cabeças de decisão treinadas — uma arquitetura fixa treinada por um script de treino fixo, com a busca acontecendo sobre dados, objetivos e etapas. O ciclo conduz os seus próprios experimentos e aposenta os seus próprios campeões. As pessoas decidem o que vale a pena medir. E a data: a v6.0-VL foi publicada em 2026-10-06, e o projeto já publicou mais um lançamento desde então — a linha avança mais ou menos diariamente, e os números desta página são os ligados ao lançamento aqui nomeado, datados de onde foram lidos. Vale a pena dizer isso logo de início numa página cujo tema é um ciclo que não para de rodar.

O que o termo significa, dito de forma direta

Reduza a frase e restam três partes, todas comuns. Primeiro, um espaço de busca: o conjunto de coisas que poderiam ser mudadas. Segundo, um avaliador: algo que diz se uma mudança ajudou. Terceiro, um registro: o que foi tentado, o que aconteceu e o que foi descartado. Um sistema está fazendo autoaperfeiçoamento recursivo quando a saída da rodada N é a entrada da rodada N+1 em todas essas três partes, sem que um humano volte a derivar o espaço de busca ou a decidir novamente o limiar a cada vez.

O que a maioria dos textos sobre o tema deixa de fora é a segunda parte, e é aí que mora toda a questão. Um loop com um avaliador fraco otimiza o avaliador. Ele vai produzir uma linha que sobe monotonicamente e um sistema que aprendeu o formato do seu próprio exame. Essa falha não exige má intenção nem um bug — é o que acontece por padrão quando o mesmo número tanto seleciona quanto reporta. Então, quando você lê a alegação de que algum sistema está se autoaperfeiçoando, a pergunta útil nunca é "quanto melhor ele ficou?". É "quem definiu o padrão, quando, e ele poderia mudar depois que o resultado foi visto?".

As versões populares deste conceito — as que hoje estão no topo para o termo — são sobretudo prospectivas: a entrada da Wikipédia descreve um sistema a reescrever o seu próprio código em direção a uma "explosão de inteligência", e a cobertura mais ampla tende a incidir sobre se esse cronograma está mais próximo ou mais distante do que o previsto. Esse é um argumento legítimo, e é irrespondível com as evidências de que alguém dispõe atualmente. O que é respondível é a questão menor, que é se um ciclo fechado do tipo descrito acima pode ser construído e mantido fiel às suas próprias regras neste momento. Para isso, um projeto com artefatos públicos vale mais do que uma década de especulação, e é sobre isso que o resto da página trata.

Fechado, não meramente iterativo: cinco mecanismos

Um loop não é fechado porque se repete. Muitos pipelines automatizados se repetem sem nunca serem fechados, porque um pipeline que consegue ajustar seu limiar depois de ver o resultado faz algo categoricamente diferente de um que não consegue. As próprias regras do RSI-Jev são excepcionalmente explícitas sobre a diferença, e podem ser lidas como definições, e não como um manifesto. Cinco delas fazem a maior parte do trabalho.

As previsões são registradas antes da execução. Uma hipótese é anotada com o número que ela espera mover e em quanto, antes que tempo de GPU seja gasto. Uma versão que não atinge o próprio critério é entregue como um fracasso, em vez de ser silenciosamente reformulada. Esse é o mecanismo que impede que o ciclo se torne uma máquina de escrever explicações post-hoc, e isso custa algo real: o registro contém entradas cujo único conteúdo é que alguém estava errado no registro.

Pisos nulos são medidos, não presumidos. A equipe executa braços que são comprovadamente idênticos ao controle — verificados por identidade de objeto antes de qualquer tempo de GPU — e a dispersão entre esses braços é o piso de ruído. Uma diferença menor que esse piso não é um resultado, qualquer que seja a aparência. O próprio critério do projeto reflete isso: em sua suíte interna, o limiar é +0,006, com desvio padrão por semente em um único benchmark de 0,011–0,016, de modo que diferenças de benchmark único abaixo disso não são achados. A maior parte do ruído neste ramo é medido, não estatístico.

Um conjunto reservado é consumido assim que é lido. Cada versão lê o conjunto reservado uma vez, portanto duas versões ainda podem ser comparadas em pé de igualdade — e, como lê-lo o consome, cada versão congela a comparação da seguinte. A formulação do próprio projeto merece ser mantida intacta: o conjunto reservado "é mantido fora do treinamento, não selado da busca". É uma verificação de memorização, não uma garantia de novidade. E a própria cifra da suíte tem um furo que o projeto publicou: uma tarefa interna se sobrepôs a várias centenas de linhas de treinamento, então a partir do v6.0-VL a suíte é reportada sem ela — 0,770 — e o 0,764 anterior do v5.0-VL foi reexpresso como 0,763 sem ela. Essa reexpressão é o ponto. Um número estava sendo inflado, a causa foi encontrada, e o cartão da versão mais antiga foi corrigido em vez de deixado como estava.

As falhas são publicadas, incluindo as que mataram o próprio defensor do projeto. As contagens de destaque do repositório, lidas em 2026-10-08, são coerentes: oito lançamentos em treze dias, e centenas de experimentos documentados com as falhas incluídas. Um resultado negativo é tratado como o produto. O guia de contribuição é direto sobre o porquê — a parte cara de uma busca não é executar o vencedor, e sim executar os perdedores, então um negativo bem medido vindo de fora remove um ramo e vale mais do que um pequeno positivo.

A cadeia de releases é o projeto. Um cartão por release, todos eles, permanentemente na branch principal. Cada cartão carrega os números do seu próprio release, então a velocidade e a calibração de uma versão nunca sobrescrevem as de outra. O projeto declara o motivo diretamente: essa cadeia é a única maneira de ver se um loop de autoaperfeiçoamento está melhorando. Todo o resto — a receita, os scripts, a stack fixada — carrega apenas o release atual, porque a regra oposta tornaria impossível dizer o que é atual. Um checkpoint publicado carrega seu próprio código para que releases antigos permaneçam executáveis sem branches antigas.

O que a disciplina custa e o que ela traz em troca

Duas histórias do registro são o contrapeso honesto à palavra "autoaperfeiçoamento", porque ambas são casos em que as próprias regras do loop tornaram o trabalho mais lento e melhor ao mesmo tempo.

O primeiro é o bug por trás da v1.0. Encontrá-lo exigiu sete negativos registrados. Cada um dos sete era uma correção do lado do otimizador que reduzia uma instabilidade de treinamento sem removê-la, porque a causa era um erro de precisão em nenhum lugar perto do otimizador — e a correção final foi uma linha. Nenhum dos sete valia a pena ser publicado por si só. Juntos, eles são o que tornou a causa localizável, e esse é todo o argumento para registrar e manter negativos: seu valor é conjunto, não individual.

O segundo é menos lisonjeiro, e o projeto o publica mesmo assim, em nota de rodapé. Um braço inicial falhou em exatamente uma salvaguarda — o MMLU-Pro ficou 0,026 abaixo do patamar, contra um limite de 0,020 — e foi registrado como rejeitado. O responsável pela execução então ampliou o limite para 0,030, com o argumento de que o MMLU-Pro é uma salvaguarda contra o esquecimento, e não uma meta, e o braço foi confirmado em quatro seeds novas e se tornou a próxima versão. A rejeição original foi mantida no log, junto com o comentário do próprio projeto de que um patamar movido depois de ver o resultado é o tipo de coisa que um leitor deveria ser capaz de flagrar o projeto fazendo.

Essa nota de rodapé é o parágrafo mais útil do repositório para quem tenta avaliar esse tipo de alegação no mundo real. Um limite que mudou não é prova de má-fé — o raciocínio apresentado é defensável, e o limite ampliado teve então de sobreviver a quatro sementes novas. Mas um limite que mudou em silêncio é um ciclo que já não está fechado, e a diferença entre os dois casos está inteiramente em se aquilo foi ou não registrado por escrito. A regra geral que o projeto adotou depois é a que vale a pena levar para outros sistemas: um quase-acerto que falha exatamente em uma barreira recebe um diagnóstico e um reparo direcionado em vez de ser descartado — e, se o reparo falhar, ele se torna um beco sem saída com um registro.

Com que frequência o loop está errado: catorze configurações, duas mantidas

Eis o número a reter. Através do lançamento que lê imagens, o projeto contabiliza catorze configurações de aprendizagem por reforço e 63 braços treinados por recompensa. Dois foram mantidos.

Cada configuração foi avaliada em relação a um controle supervisionado treinado nos mesmos itens pelo mesmo número de passos, que é a comparação que torna a contagem significativa — um braço de RL superar uma linha de base que nunca precisou igualar não prova nada. As perdas instrutivas, nas palavras do próprio projeto:

• RL de acerto binário — a saída de probabilidade colapsou para 0 e 1. Recompensar o ato de escolher certo, em vez da honestidade das probabilidades reportadas, empurra uma distribuição para os extremos, e um modelo de decisão cuja confiança é sempre total é inútil para aquilo para que os modelos de decisão servem.

• RL com proper-score, a reconstrução do objetivo no estilo Laya — bom aos 300 passos, divergiu aos 1.500. Estável enquanto não fazia grande coisa, e instável exatamente quando começou a importar.

• RLCR — empatado em precisão, pior calibração bruta. Não comprou nenhuma capacidade e pagou por isso na única propriedade que o modelo existe para oferecer.

• Bandit RLCD, em que apenas o resultado da opção escolhida é revelado — não melhor que o treinamento supervisionado com o mesmo feedback. O projeto encerrou seu próprio teste pré-registrado aqui: o braço tinha de superar o treinamento supervisionado em pelo menos duas de quatro métricas de calibração e venceu uma.

O vencedor, e o motivo pelo qual venceu, é o achado mais transferível da página. É uma recompensa listwise — qualidade de ranqueamento medida sobre a ordem de muitos candidatos pontuados separadamente, em vez de tratar cada um isoladamente. O recall de rerranqueamento na primeira posição passou de 0,192 no pai supervisionado para 0,308, com vitórias e derrotas em um teste pareado. A explicação do projeto não é uma história de ajuste: um alvo de treinamento por item pontua cada candidato por si só, e nenhum rótulo único codifica a qualidade de uma ordem entre candidatos. Onde a recompensa dizia algo que os rótulos não conseguem expressar, o RL superou o treinamento supervisionado nas mesmas linhas. Onde não, o treinamento supervisionado igualou-o.

Isso se generaliza numa regra sobre quando esse tipo de loop consegue encontrar qualquer coisa que seja. Com um rótulo de referência em mãos, a atualização esperada do gradiente de política equivale ao gradiente de uma perda supervisionada — a formulação do próprio projeto —, então um "braço de RL" avaliado contra decisões rotuladas é, na verdade, um braço de design de perda. E mudanças no nível da perda moveram a suíte interna em no máximo 0,002, enquanto novos dados a moveram em 0,13. Lidos em conjunto: a alavancagem do loop nunca esteve no objetivo. Estava naquilo que era medido e naquilo que era alimentado.

O que é a resposta honesta a uma pergunta que um leitor tem o direito de fazer. Configurações de RL são citadas em outros lugares como evidência sobre autoaperfeiçoamento em geral; aqui, são evidência sobre um loop em tarefas de decisão. O resultado listwise é uma única seed, e o projeto diz isso: a comparação pareada RL versus supervisionado foi executada em um modelo pai diferente daquele ao qual o release a aplicou, e esse release "não tem controle supervisionado pareado". Um achado com essa ressalva atrelada vale mais do que um sem ela, e é por isso que a página que você está lendo não o generaliza.

Onde o humano se senta

O projeto é explícito, e a explicitude é a parte interessante: o loop conduz os seus próprios experimentos e aposenta os seus próprios campeões, mas não decide o que vale a pena medir, e não percebe sozinho quando um número é tecnicamente verdadeiro e praticamente enganador. São as pessoas que fazem isso.

Duas das próprias regras do projeto existem porque alguém contestou. A salvaguarda do MMLU-Pro foi ampliada em vez de deixar uma quase falha ser descartada. O requisito de sementes agora escala com o tamanho do efeito, em vez de gastar quatro sementes em cada diferença — porque a semente de confirmação, o único número pelo qual um braço não foi selecionado, é a que sustenta a carga, e gastar poder computacional em diferenças que você já consegue ver não compra nada. Uma das versões da cadeia começou como uma recusa a abandonar um braço que havia falhado em uma salvaguarda. O projeto credita nominalmente as pessoas que enviaram esse feedback, nos agradecimentos.

Então, “autoaperfeiçoamento” aqui descreve o meio do loop, não o loop inteiro. O loop é uma busca que roda sem que um humano gire a manivela. O humano ainda está no topo do loop, escolhendo o objetivo, e na parte de baixo, lendo o resultado criticamente — o que é precisamente o arranjo que impede o loop de se tornar uma máquina de confirmar as próprias preferências. Qualquer relato de autoaperfeiçoamento recursivo que omita essa posição está descrevendo um sistema diferente deste, e provavelmente um sistema hipotético.

O que os próprios números do projeto não mostram

A disciplina acima só vale a pena ser descrita se seus limites forem declarados no mesmo fôlego, e o registro de RSI-Jev os declara por si mesmo.

• É um projeto, um tamanho de modelo por vez, uma semente. O checkpoint publicado é de uma única semente, fixado antecipadamente como primário, em vez de escolhido por obter a melhor pontuação. A evidência de RL é uma semente.

• São tarefas de decisão, não de geração: uma pergunta de sim/não, de escolher uma entre k opções ou de avaliar segundo uma rubrica sobre um documento, um chat ou uma imagem, respondida numa única passagem direta com uma probabilidade calibrada por opção. Nada é gerado, pelo que não há tokens de raciocínio para gastar. O que o ciclo demonstra aqui é que consegue melhorar um scorer desse tipo.

• Parte disso não é reproduzível apenas a partir do repositório. Os corpora de treinamento e os conjuntos de desenvolvimento de políticas não são públicos, e o projeto diz isso claramente na ficha de lançamento: "As etapas não podem ser reexecutadas apenas a partir deste repositório." Um construtor de corpus precisa de cerca de 96 GB de memória e não foi reexecutado de ponta a ponta.

• Nem tudo é verificável em absoluto. A suíte interna nunca foi totalmente mantida à parte. Dos quinze benchmarks, dez contribuem com dados de treinamento de alguma forma, então nenhum desses números é zero-shot — o conjunto mantido à parte é a comparação que é mantida à parte, e é a única.

E as partes externas têm seu próprio tecido cicatricial. Uma auditoria após um lançamento encontrou aproximadamente mil itens das linhas de teste do kit de benchmark público nos corpora de treinamento — cerca de 0,3% das linhas do kit, com a maior contribuição individual sendo algumas centenas de linhas de uma única fonte. Reavaliado sem eles, o índice varia no máximo 0,04. Essa correção foi publicada no card do lançamento seguinte, em vez de aplicada silenciosamente, sob a regra que o projeto enuncia como "sem contaminação, verificada em vez de afirmada". É uma regra que lhes custa um número, que é o único tipo de regra que vale a pena ter.

Onde você pode realmente executá-lo — e onde não pode

Nada aqui é servido por OrcaRouter. Nosso catálogo não contém nenhum ID de RSI-Jev nem ficha de modelo para ele, e não haverá nenhuma até que alguém o sirva. O RSI-Jev é instalado a partir do seu próprio repositório e executa seu próprio servidor, que fala a Jev API: você aponta um cliente Jev existente para ele e altera a URL base. Ele roda em Linux, Windows e macOS, em uma GPU CUDA, Apple Silicon ou CPU comum.

The one model we do host is the other side of that contract. TypeSafe's Jev 1.13, which we serve as typesafe/jev-1.13, is the commercial decision model whose request and answer shapes RSI-Jev reproduces, and it is reached on our dedicated systemone endpoint rather than through the chat-completions shape. That is the whole relationship, and it is a structural one rather than a quality claim: one is a hosted commercial model on a vendor's endpoint, the other is a checkpoint you download and serve yourself. Nobody has run an independent head-to-head between them, and this page is not going to declare a winner from two different harnesses.

Se o que você quer é colocar um modelo de decisão como este por trás de uma aplicação, a questão do roteamento é separada da questão do modelo, e é a parte que decide se vale a pena executar o experimento. OrcaRouter é uma API para mais de 200 modelos com 0% de markup — preço de tabela do provedor repassado, de modo que uma mudança de preço de um fornecedor é o seu preço no mesmo dia — além de failover automático e uma DSL de roteamento para compor vários modelos em uma única chamada. Para um modelo de loop que você ainda não consegue chamar por meio de uma API geral, isso importa de uma forma específica: significa que os candidatos alternativos com os quais você o compararia já estão atrás de uma única chave, e a comparação é uma mudança de configuração em vez de uma segunda integração.

A parte que vale a pena guardar

O motivo de escrever sobre autoaperfeiçoamento recursivo por meio de um projeto como este, em vez de por meio do argumento sobre se ele leva a algum lugar dramático, é que as regras do loop são a parte transferível e a especulação não é. Previsões registradas, pisos nulos medidos, conjuntos de retenção gastos, falhas publicadas, uma cadeia de lançamentos imutável: nenhuma dessas é uma propriedade de uma superinteligência. São propriedades de um laboratório que decidiu ser verificável, e estão disponíveis para qualquer equipe que execute busca automatizada hoje, em qualquer escala, em qualquer modelo.

Lido dessa forma, a afirmação interessante no registro de RSI-Jev não é a pontuação. É que o próprio livro-razão do loop diz que ele estava errado muito mais vezes do que certo — duas receitas mantidas de quatorze configurações, sete negativos para encontrar um bug de uma linha, uma barra que se moveu e foi anotada — e que o projeto publicou o livro-razão. Uma subida de 38,38 para 46,24 num índice público em uma única versão é uma curiosidade sem as falhas ao lado. São as falhas que fazem o número significar algo.

Qual é a posição honesta sobre o próprio termo. A questão não é se um sistema pode melhorar a si mesmo. É se a melhoria é medida por algo que poderia ter dito não. Onde essa separação é real e está registrada por escrito, vale a pena ler o loop. Onde não é, uma linha ascendente é uma descrição de um pontuador, não de um sistema que está melhorando — e nenhuma quantidade de recursão corrige isso.