O que é o RSI-Jev? Um ciclo de autoaperfeiçoamento que constrói modelos de decisão ao estilo Jev

RSI-Jev é um projeto de pesquisa aberto e de terceiros que constrói modelos de decisão System One no estilo Jev, e o modelo sobre o qual esta página fala é a sua versão 4B, RSI-Jev v6.0-VL, datada de 2026-10-06. É escrito por Shanghua Gao (@gasvn), com Sufian (@SufianTA) creditado nos agradecimentos do repositório, e não é o Jev da TypeSafe nem está afiliado à TypeSafe AI — a própria linha de licença do projeto diz exatamente isso. A ideia subjacente é suficientemente restrita para ser enunciada numa frase: faça uma pergunta tipada sobre um documento, um chat ou uma imagem — sim/não, escolher-um-entre-k, avaliar numa rubrica — e uma única passagem direta devolve uma probabilidade calibrada para cada opção. Nada é gerado, portanto não há tokens de raciocínio para gastar, e nenhum é gasto. v6.0-VL não é a primeira versão do projeto; é a sétima em doze dias, o que é a coisa mais importante a compreender sobre ele, porque a informação útil aqui está na forma da linha, e não em qualquer checkpoint individual.

Uma coisa precisa ser dita antes de qualquer um dos números, porque ela data todos eles. v6.0-VL foi o primeiro da fila por exatamente um dia. Em 2026-10-07 às 07:56 UTC — esta manhã — o projeto publicou RSI-Jev v6.1-VL, que é a média de v6.0-VL, peso 0,5 cada, com um segundo ajuste fino do mesmo Qwen3.5-4B-Base treinado em outros dados, e que pontua 50,98 no kit Decision Index 0.3 do projeto contra os 46,23 de v6.0-VL nesse mesmo kit. Nada foi treinado após a média. A calibração dele é pior que a do v6.0-VL, e o próprio cartão dele diz isso. Esse lançamento é real e atual; esta página não é sobre ele. Cada número abaixo é lido do registro de lançamento de v6.0-VL, datado de 2026-10-06, e onde uma contagem mudou desde então — a contagem de lançamentos, a contagem de experimentos — esta página fornece tanto o número como estava para v6.0-VL quanto o número como está hoje.

O que o RSI-Jev não é também merece ser dito logo no início, porque duas das três suposições óbvias estão erradas. Ele não é um produto hospedado que você possa chamar hoje por meio de uma API geral, e não é servido pela OrcaRouter — nosso catálogo não traz nenhum id rsi-jev, nenhum id shgao e nenhuma ficha de modelo para ele. A única coisa que temos é o modelo cujo contrato HTTP este projeto copia: o Jev comercial da TypeSafe, que servimos como typesafe/jev-1.13 no endpoint systemone. Um desses dois você chama, e o outro você baixa e serve por conta própria. Tudo abaixo vem do próprio repositório do projeto, dos cartões de lançamento e da documentação de serving, lidos em 2026-10-07, e, quando um número é do próprio projeto e não de uma medição externa, esta página diz de quem ele é.

O que a coisa realmente faz

O projeto se descreve em uma linha como "um sistema de pesquisa recursivamente autoaperfeiçoável que constrói modelos System One no estilo Jev", e os artefatos que produz são decisores em vez de geradores. Você entrega a ele um estado — um documento, uma transcrição de chat, uma transação e, nas versões de visão, até quatro — e um ou mais nomeados. Ele retorna isso, uma probabilidade para cada opção que a pergunta poderia cobrir, e eles são os do Type One:

• noul — um julgamento verdadeiro/falso, retornado como uma única probabilidade, sem distribuição e sem valor de confiança, correspondendo exatamente ao formato de resposta da referência.

• escolha — escolha uma de um conjunto de opções rotuladas, retornada com a distribuição de probabilidade completa e uma estatística de confiança.

• pontuação — avalie em uma rubrica ordenada, retornada como um índice de base zero ponderado por probabilidade nos níveis, além da legenda e da distribuição.

Como não há etapa de geração, não há uma segunda chamada ao modelo nem amostragem. Uma decisão sobre um documento que o modelo já leu é, por construção, uma operação barata, e a própria indicação do projeto para esse custo — “cerca de 10 ms” — pertence à sua era 2B, não à versão atual; os números medidos para o v6.0-VL são apresentados mais adiante.

Dois fatos sobre a propriedade importam mais do que qualquer outra coisa nesta página. O RSI-Jev não é trabalho da TypeSafe e a TypeSafe não o endossou. A linha da licença, citada na íntegra: "Código: MIT. Pesos: Apache-2.0, seguindo o modelo base; algumas fontes de treinamento de imagem são não comerciais, listadas em cada cartão de modelo. Não afiliado à TypeSafe AI." E a relação é unidirecional: o projeto copia deliberadamente o formato de transmissão do Jev, e diz isso, porque um servidor compatível é o objetivo. "Estilo Jev" é a expressão do próprio projeto para o tipo de modelo que ele constrói. O Jev da TypeSafe é um modelo diferente, fechado e comercial, e os dois não são a mesma coisa sob um nome mais curto.

Dentro do modelo atual: uma torre Qwen de 4B com três saídas

O RSI-Jev v6.0-VL é uma torre Qwen3.5-4B-Base com a torre tendo passado por ajuste fino e uma cabeça de decisão treinada no topo. Essa é toda a arquitetura — não há mistura de especialistas, nem roteador, nem segundo modelo. Ele executa o modelo base inteiro, e é por isso que sua contagem de parâmetros é 4,69B e não algo menor: 3,57B ficam nas 32 camadas de decodificador, 0,64B nos embeddings de tokens, 0,33B na torre de visão, 0,05B na cabeça de decisão principal e 0,10B nas duas cabeças de saída antecipada. O checkpoint lançado é autossuficiente e tem 9,7 GB em bf16.

Três cabeças de decisão estão anexadas, nas camadas 16, 20 e 32 da base, e são o mecanismo por trás de tudo pelo que a versão atual é conhecida. Uma quarta saída na camada 12 foi construída, medida e descartada — "A saída da camada 12 perdeu para a cascata da 16 em todas as comparações e não está no pacote" — portanto três são entregues e quatro não. As saídas leem uma cópia desanexada da sua camada, um detalhe que o projeto descobriu da maneira difícil: reajustar as cabeças num tronco cujas saídas tinham sido anexadas durante o treino não tinha recuperado a precisão das camadas profundas, por isso desanexá-las foi o que restaurou a profundidade.

Um número aqui é a maneira mais fácil de interpretar mal o projeto. Tudo até e incluindo a v3.0 era um modelo 2B no Qwen3.5-2B-Base, e essa é a linhagem, não o modelo atual. A v4.0-VL era 2B, a v5.0-VL reduziu um modelo para 3B, e a v6.0-VL é 4B. Uma página que chama o modelo RSI-Jev atual de 2B está com três versões de atraso.

O loop é o projeto de verdade

Os modelos são o resultado; o que está sendo construído é o processo. O projeto afirma que "o loop que executa a pesquisa é a próxima versão do AutoScientists", o sistema de equipes de agentes auto-organizadas publicado pelo laboratório Zitnik, em Harvard, e funciona conforme essa frase sugere. Agentes de IA propõem hipóteses, registram suas previsões antes de gastar tempo de GPU, executam os experimentos e aposentam seus próprios campeões quando as evidências indicam. Dois números tornam isso concreto. Numa leitura em 2026-10-07, a manchete do repositório é oito lançamentos em treze dias, da v1.0 à v6.1-VL; no próprio lançamento da v6.0-VL, em 2026-10-06, lia-se sete lançamentos em doze dias, cada um treinado, avaliado e documentado pelo loop. E a contagem de experimentos, que era 471 quando o lançamento desta página saiu, está em 496 hoje — cada um deles devidamente escrito, incluindo as falhas. Ambas as contagens são do próprio projeto, e ambas se movem.

A disciplina é o que faz esses números significarem algo, e o projeto a lista de forma clara. Pisos nulos são medidos, em vez de presumidos — braços comprovadamente idênticos ao controle, verificados por identidade de objeto antes de qualquer tempo de GPU, de modo que a dispersão entre eles é o piso de ruído e uma diferença menor que essa dispersão não é um resultado. As previsões são registradas antes da execução, então uma versão que não atinge sua própria meta é lançada como uma falha, em vez de ser silenciosamente reformulada. Os artefatos são verificados: um checkpoint é recarregado do disco e reavaliado, e publicado somente se reproduzir as previsões por pergunta de sua execução de treinamento, o que ambos os checkpoints v1.0 fazem em 1.0000. A contaminação é "verificada em vez de afirmada". E as falhas são entregues, incluindo as que mataram o próprio campeão do projeto.

O que é uma contribuição, nas próprias palavras do projeto em seu guia de contribuição: "Uma contribuição aqui é geralmente uma medição, não um patch." O registro de versões publicadas é mantido como uma cadeia, e não como um instantâneo — "versions/ mantém uma ficha por versão, todas elas, na main para sempre… Essa cadeia É o projeto" — e é por isso que os números de uma versão antiga podem ser conferidos com o que o projeto diz sobre eles mais tarde, e por que a correção discutida abaixo fica visível em vez de silenciosa.

O que o v6.0-VL mudou: ele gasta profundidade em vez de tokens

O mecanismo da versão atual é uma configuração chamada esforço, e ele controla algo incomum: quantas camadas do modelo uma requisição pode usar. Como as cabeças ficam em três profundidades, uma pergunta fácil pode ser respondida na camada 16 e uma pergunta difícil pode percorrer todas as 32. baixo para na camada 16, médio em 20, alto em 32, e automático responde na primeira saída cuja probabilidade calibrada supera o limiar dessa saída. Latência mediana por requisição na amostra do Decision Index, medida em uma H200 em bf16: 23 ms em baixo, 27 ms em médio, 40 ms em alto, e 40 ms para o padrão não definido. Essas são medições do próprio projeto em seu próprio hardware e não devem ser misturadas com os números GB10 da documentação de serving, que são de uma máquina diferente.

O comportamento medido de auto é a parte interessante: na suíte de quinze benchmarks do projeto, 20% das perguntas param na camada 16, 46% na camada 20 e 34% chegam até 32, o que dá uma média de 23,3 das 32 camadas. Um único limiar fixo tem média de 20,9, e parar cedo demais é o que um único limiar proporciona. auto não é uma concessão em qualidade, o que vale a pena afirmar, porque é isso que normalmente é uma configuração adaptativa: ela registra a melhor linha da suíte entre todas as configurações (0,771 contra 0,770 da padrão), a melhor linha do MMLU-Pro (0,444 contra 0,440) e a melhor calibração final (ECE 0,024 contra 0,036). O único lugar em que high vence é o conjunto de validação, 0,702 contra auto, que fica em 0,696. Algumas tarefas ficam mensuravelmente piores com a profundidade — BANKING77 piora 0,035, a correspondência de legendas do New Yorker piora 0,060 — e é por isso que o nível de esforço é uma escolha do chamador, e não uma regra imposta pelo servidor.

O resultado que fez disto um lançamento em vez de um experimento está no Decision Index 0.2.1 público do projeto, onde a pontuação passou de 38,38 para o v5.0-VL para 46,24 para o v6.0-VL em um único lançamento. No quadro público datado de 2026-09-28, essa é a pontuação mais alta entre modelos 4B e qualquer coisa menor, e a 14ª de 71 no geral; a próxima entrada nesse tamanho é o JPT-4B, com 43,04. Os lançamentos anteriores nesta linha são linhagem e não o modelo atual: o v5.0-VL (2026-10-02) reduziu o modelo para as primeiras 20 das 32 camadas e o fez dizer "unknown" quando uma pergunta não tem resposta; o v4.0-VL (2026-10-01) foi o primeiro que lê imagens; e o v3.0 (2026-09-28) é o lançamento em que o aprendizado por reforço ajudou pela primeira vez, por meio de uma recompensa de ranqueamento listwise — NDCG@5 sobre 16 candidatos — que elevou o R@1 de reranqueamento de 0,192 para 0,308 contra seu pai supervisionado a um custo de 0,0028 na suíte. É aí que começa a história de RL do projeto, e já está três lançamentos atrás agora.

Os números, com as ressalvas que os acompanham.

O resultado principal do Decision Index 0.2.1 para v6.0-VL é 46,24, em uma execução completa na qual todas as 150.759 solicitações da suíte foram respondidas: conhecimento 28,8, linguagem 46,2, recuperação 55,5, ferramentas 65,8, artes 37,1. A suíte de quinze benchmarks registra 0,770, o conjunto de hold-out 0,698, MMLU-Pro 0,440, e ECE final 0,024 com automático. Duas ressalvas precisam ser feitas no mesmo fôlego que esses números, porque sem elas os números enganam.

O primeiro é um corte na suíte. A tarefa interna da suíte open_jev_ood se sobrepôs a 579 linhas de treinamento, de modo que seu número foi inflado em uma quantidade desconhecida; a partir da v6.0-VL, o projeto reporta a suíte sem ela, em 0,770. O 0,764 da v5.0-VL era com ela, e o card da v6.0-VL reafirma aquele lançamento como 0,763 sem ela. As duas cifras não são comparáveis, e se você compará-las, precisa usar o 0,763 reafirmado e dizer que é isso que está fazendo. O conjunto held-out, o MMLU-Pro e o BBH não têm sobreposição e não são afetados. Uma auditoria relacionada encontrou cerca de 1.000 itens das linhas de teste do kit Decision Index nos corpora de treinamento — ANLI 274, RouterBench-GSM8K 90, ARC 5, e texto de consulta do BRIGHT/ToolRet sem rótulos, aproximadamente 0,3% das linhas do kit — e recalcular a pontuação sem eles altera o índice em no máximo 0,04 na amostra do projeto. Essa é uma correção ao registro da v5.0-VL, publicada no card da v6.0-VL, e é a própria regra de contaminação do projeto custando-lhe um número.

A segunda questão é de quem é este benchmark. O Decision Index é o quadro público da própria RSI-Jev, não um veredito de terceiros, e 46,24 é uma pontuação nesse quadro. Ele não é comparável a nada que a TypeSafe tenha publicado, porque os dois números não vêm da mesma estrutura de testes, e ninguém realizou uma comparação direta independente entre o RSI-Jev e o Jev 1.13. O que se pode dizer é estrutural, e não numérico: um é um modelo comercial hospedado no endpoint de um fornecedor, e o outro é um checkpoint que você baixa e serve por conta própria.

Dois outros elementos de contexto fazem parte do conjunto. O projeto é explícito ao afirmar que "dez dos quinze benchmarks contribuem com dados de treinamento de alguma forma, portanto nenhum desses números é zero-shot"; o conjunto reservado é a comparação que é mantida à parte, e mesmo ele "é mantido fora do treinamento, não está fechado à busca". E o v6.0-VL executou 97 braços em sua própria linha — 93 se as quatro auditorias de dados forem deixadas de fora —, que é a escala de busca que produziu um salto de 7,86 pontos naquele índice.

Ele fala o formato de transmissão do Jev, com quatro diferenças que um chamador deve conhecer

A superfície de compatibilidade é a razão pela qual este projeto existe na forma como existe. A mesma forma de requisição ({state, model, questions}), os mesmos três tipos de pergunta com as mesmas formas de critério, as mesmas formas de resposta, as mesmas 1 a 64 perguntas por requisição, os mesmos envelopes de erro e a mesma estatística de confiança — o pico, K · p_max − 1, K − 1, até 0,1. O ponto dessa superfície é que qualquer coisa escrita para Jev funciona com isto sem," e o servidor diz o que é suportado e o que não é, o que é mais do que a alegação.

• O prompt e o readout são próprios dele. O RSI-Jev é um modelo base com uma cabeça de readout treinada, servido com o codificador com o qual foi treinado, porque usar o prompt da referência "tiraria o modelo de sua distribuição de treinamento". O contrato de rede é a superfície de compatibilidade; o prompt não é.

• As chaves de opção são visíveis para o modelo. A referência as oculta, portanto renomear uma chave comprovadamente não pode alterar uma resposta lá. Aqui, isso é possível, e o servidor relata isso honestamente como option_keys_visible_to_model: true.

• Criteria devem ser strings ou null. Um critério estruturado — um objeto — é rejeitado com um 422, porque nenhuma versão foi treinada com um. Este é o único ponto em que uma requisição que a referência aceita não será executada aqui.

• Nada é cortado. O serviço aceita até 32.768 tokens de texto mais o orçamento de imagem, e uma solicitação mais longa é recusada com um 422 que informa isso em vez de ser truncada silenciosamente. O número de 2.048 tokens que aparece nos cartões mais antigos é o comprimento com o qual os modelos foram treinados, não um limite de serviço, e descrever um truncamento silencioso para 2.048 como comportamento atual está errado.

As contagens de opções diferem por uma ampla margem a favor do serviço: até 5.120 opções por pergunta (RSIJEV_MAX_ANSWERS), contra 160 no treino e 64 admitidas pela referência. Não cite 160 como o limite do serviço. Uma coisa é nova nas respostas do v6.0-VL em vez de herdada: cada resposta informa qual camada respondeu, em usage.depth, juntamente com a confiança calibrada, para que uma decisão adaptativa possa ser auditada a posteriori. Imagens são uma extensão que a referência não tem — de uma a quatro por solicitação, como URLs de dados base64, com o estado referindo-se a cada uma por um marcador literal.

Onde um leitor pode realmente executá-lo, e onde não pode

RSI-Jev é um download. O projeto traz seu próprio servidor, que fala essa API compatível com Jev, e a rota documentada é um pip install a partir do repositório, seguido pelo seu comando serve com o alias do checkpoint e uma configuração de esforço. Os pesos ficam no Hugging Face sob a organização shgao, lançados sob Apache-2.0, seguindo o modelo base, com uma questão em aberto que o próprio projeto declara: cinco das fontes de treinamento de imagens são não comerciais ou apenas para pesquisa, e "se pesos treinados com dados não comerciais herdam esses termos não está resolvido". O código é MIT.

Hardware não é a limitação. O projeto é desenvolvido em um HP ZGX Nano, uma máquina NVIDIA GB10 que o projeto credita à HP e à NVIDIA, e o servidor roda em qualquer GPU CUDA, em Apple Silicon ou em CPU comum — a última opção que a documentação estima em 733 ms para uma única pergunta na própria CPU Arm da GB10, portanto utilizável, não rápida.

O que ele não faz é aparecer em um catálogo geral de modelos, e é aqui que precisamos ser precisos sobre a nossa própria posição. O RSI-Jev não está no OrcaRouter e não há model card para o qual ele possa rotear. O que servimos é o Jev comercial da TypeSafe, typesafe/jev-1.13, no endpoint dedicado systemone, acessado com um POST para /v1/systemone em vez do formato chat-completions da OpenAI — os mesmos formatos de requisição e resposta que este projeto implementa, do modelo cujo contrato ele copia. Essa é toda a relação: os dois falam o mesmo protocolo, nós servimos um deles, e você executa o outro por conta própria. Se você já tem uma chave conosco, o formato de chamada do Jev 1.13 é uma rota de primeira classe na one API para 200+ modelos com 0% de markup (o preço de tabela do provedor é repassado, então reduções de preço do fornecedor entram no ar aqui no mesmo dia) — o que importa para a comparação de uma forma específica. Uma página como esta é fácil de colocar em prática se você puder testar o contrato comercial primeiro e só então decidir se vale a pena o trabalho operacional de executar você mesmo um checkpoint aberto de 4B.

Como ler o RSI-Jev em 2026-10-07

As debilidades que o projeto publica são tão específicas quanto os seus resultados, e as datas importam. Testes externos da v2.1 constataram que o modelo tende para a opção mais severa ou dispendiosa em escolhas ordenadas e pontuações de rubrica, raramente escolhe "unknown" quando o documento não consegue responder, e responde de forma inconsistente a uma pergunta e à sua negação. Lançamentos posteriores direcionaram dados para o caso "unknown" — o KoBBQ unknown-when-ambiguous passou para 0,891 na v4.0-VL, 0,932 na v5.0-VL, e 0,918 / 0,939 na v6.0-VL — e o cartão da v6.0-VL é franco ao afirmar que os ganhos vieram dos dados e não da profundidade, e que os 10% das perguntas que iriam para a camada 32 e param nas camadas 16 ou 20 são onde a política de profundidade ainda está a adivinhar. A reordenação ainda tem caminho a percorrer: a própria ordem de recuperação do hippo-memory obtém 0,484 R@1 e continua à frente do 0,308 que o modelo alcançou na v3.0, um valor que o projeto não reivindicou encurtar desde então. A evidência de RL é uma única semente, e a v3.0 "ela própria não tem um controlo SFT correspondente". Os corpora de treino e os conjuntos de desenvolvimento de políticas não são públicos, pelo que as etapas não podem ser reexecutadas apenas a partir do repositório, e o construtor do corpus de reordenação — cerca de 96 GB de memória — não foi reexecutado de ponta a ponta.

Tração, lida no mesmo dia: 73 estrelas, 5 forks, 0 issues abertas, 7 releases no GitHub. Esses números mudam diariamente, e um repositório de três semanas não é um projeto estabelecido, qualquer que seja sua cadência de lançamentos. O resumo honesto é que o RSI-Jev é um dos esforços de pesquisa mais legíveis nesse canto do campo — uma cadeia de lançamentos datados, mensurados e às vezes malsucedidos, com a busca publicada ao lado das pontuações — e um dos menos verificados de forma independente, já que quase todos os números desta página são dele mesmo e nenhuma parte externa o submeteu a benchmark contra o modelo comercial com o qual ele é compatível.

O que observar não é o próximo lançamento, porque haverá um dentro de dias nessa cadência; é se algo fora do projeto começa a medir. As duas coisas que mudariam o panorama são uma execução de benchmark independente sobre os checkpoints publicados e uma comparação de modelos de decisão que submeta tanto o 4B aberto quanto o modelo hospedado da TypeSafe a um mesmo harness. Nenhuma delas existe hoje. Até que uma exista, a forma útil de ler uma pontuação como 46,24 é como uma alegação bem documentada de um projeto que registra suas previsões com antecedência e publica os braços que falharam — o que é uma trilha de evidências mais forte do que a maioria, e ainda assim não é um resultado de terceiros.