O que é RLCD, o treinamento por trás das decisões calibradas do Jev da TypeSafe AI?

Um modelo que não escreve texto, devolve uma decisão e o quanto ele confia nela

Essa é a promessa que a TypeSafe AI colocou na mesa quando saiu do stealth, em 15 de setembro de 2026, junto com o Jev. A empresa afirma ter construído um stack novo focado em automação: uma nova arquitetura de modelo, um sampler paralelo e um método de treinamento chamado Reinforcement Learning for Calibrated Decisions, o tal do RLCD

Bora entender o que cada pedaço disso significa na prática, e o que ainda não dá pra afirmar

Quem é a TypeSafe AI e de onde vem o Jev

A TypeSafe passou cerca de dois anos fechada antes de aparecer

A saída do stealth veio acompanhada de um seed de aproximadamente US$ 40 milhões liderado pela DCVC

A atribuição de autoria pesa na leitura da coisa: segundo a própria TypeSafe, Diogo Almeida é o CEO e coautor dos papers do InstructGPT e do GPT-4, vindo da OpenAI, Erik Gafni é CTO e Sasha Sheng é COO

Isso não prova nada sobre o produto, beleza? Mas explica por que o anúncio circulou rápido e por que vale a pena entender a proposta em vez de ignorar como mais um lançamento qualquer

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Como funciona o Jev na prática: entrada, saída e o score

O contrato do modelo é bem mais parecido com uma chamada de função do que com um chat

Você manda duas coisas: um estado não estruturado (o contexto bruto, do jeito que ele chega) e uma lista de ações permitidas

E recebe de volta uma decisão tipada, acompanhada de uma probabilidade, o score de confiança

Se você já escreveu um if em cima do retorno de uma função, o modelo mental é esse. Não tem prosa pra parsear, não tem "claro! aqui está o JSON que você pediu" no meio do caminho

E pra que serve o score?

Aqui tá a parte mais interessante do desenho

O score existe pra que o SEU software decida o que fazer com a decisão. Ele vira um gate de roteamento na aplicação

Segundo a TypeSafe, os caminhos possíveis são:

• agir automaticamente, quando a confiança é alta o bastante pro seu risco
• pedir mais informação, quando falta contexto
• escalar pra um humano
• acionar um modelo mais lento e mais caro pra resolver o caso difícil

Repara que isso é arquitetura de aplicação, não mágica de modelo. A ideia de fatiar por confiança funciona com qualquer fornecedor, desde que o número que você recebe signifique alguma coisa

E é exatamente aí que entra o RLCD

O que o RLCD muda no treino

O RLHF, que virou padrão nos LLMs de chat, otimiza preferência humana: a resposta que a pessoa acha melhor

O RLCD, segundo a empresa, otimiza outra coisa: o modelo é treinado pra devolver uma decisão junto com uma probabilidade calibrada sobre lógica de execução, de modo que o score se correlacione com a acurácia real da saída

Traduzindo o que "calibrado" quer dizer: a expectativa é que a frequência real de acerto acompanhe o score que o modelo devolve. Um número que você pode usar como limiar em vez de um número bonito e sem lastro

Tome cuidado com um detalhe: a TypeSafe não publicou paper nem technical report descrevendo o algoritmo do RLCD até agora. O que existe é a descrição do objetivo, não a receita

Jev x LLM tradicional: o que muda na arquitetura

A diferença central que a empresa aponta é que o Jev emite todas as probabilidades em paralelo, num único passe, em vez de gerar token a token de forma autorregressiva

E ele abre mão da geração de strings de vez: é otimizado pra saída estruturada e, segundo a TypeSafe, não pode alucinar

Esses US$ 42 por bilhão dão US$ 0,042 por milhão de tokens de entrada

A saída sair de graça faz sentido dentro da proposta: a saída é minúscula, uma decisão e um número, não um textão

O que sustenta e o que ainda não sustenta nos números da TypeSafe

Agora a parte que separa leitura técnica de repost de release

A TypeSafe reporta ganhos de 20x a 200x em velocidade e de 40x a 400x em custo comparando com fluxos equivalentes de LLM

E cita ainda um pico interno de 193,6x mais rápido e 444,6x mais barato, ou seja, o melhor caso de custo divulgado estoura o teto da faixa que a própria empresa anuncia

São números vendor-reported. Ou seja, medidos pela própria empresa, no próprio setup

Tem um detalhe metodológico que muda bastante o peso da palavra "acurácia" aqui: os benchmarks são internos e as respostas de referência foram derivadas de saídas de modelos concorrentes, GPT-6 Astra e Claude Fable 5.1

Isso significa que o que está sendo medido é concordância com uma referência gerada por modelo, não correção verificada de forma independente

Não é fraude, é uma escolha de metodologia comum. Só não é a mesma coisa que "o Jev acerta mais"

Somando: a empresa declarou publicamente, no post "Lies, Damned Lies, and Benchmarks", que opta por não participar de leaderboards públicos, preferindo avaliações próprias ligadas a atualizações de produto

Dá pra defender a posição (leaderboard tem seus vícios, todo mundo sabe), mas o efeito prático é que não existe reprodução independente em larga escala pra cruzar com os números

E também não foram divulgadas métricas concretas de calibração pra sustentar a alegação de probabilidades calibradas

Então o veredito honesto é esse: a arquitetura declarada é coerente e interessante, o resultado ainda está na palavra da casa

Cuidado com a sigla: RLCD já existia na literatura

Se liga nisso, porque é o tipo de coisa que gera confusão em thread técnica

Você busca RLCD esperando achar o treinamento do Jev e cai num paper de alinhamento de modelos de linguagem

A causa é simples: a sigla já estava ocupada. RLCD (Reinforcement Learning from Contrastive Distillation) é um trabalho de Yang, Klein e colegas, publicado em 2023 e aceito no ICLR 2024, sem nenhuma relação com a TypeSafe

Mesmas quatro letras, significados diferentes: Calibrated Decisions de um lado, Contrastive Distillation do outro

Como evitar a bagunça quando você for citar:

• escreva a sigla expandida na primeira menção, sempre
• em artigo ou doc interno, deixe claro o contexto ("RLCD da TypeSafe" ou "RLCD, arXiv 2307.12950")
• se for linkar, linke a fonte certa, porque o buscador vai misturar as duas

Já me ferrei uma vez discutindo sigla homônima em review de código, e não tem discussão mais chata que essa 😅

Como acessar o Jev hoje

Primeiro o esperado: o Jev é oferecido como modelo proprietário e hospedado, acessível por HTTP API

Até agora não há informação pública confirmando pesos abertos ou opção de rodar o modelo localmente

E ele está em early access, com lista de espera, sem data de disponibilidade geral anunciada

1. Entre na waitlist em typesafe.ai. O erro comum aqui é planejar cronograma de produto em cima disso: não existe GA anunciada, então trate como avaliação, não como fornecedor contratado

2. Escolha o caminho de integração. A TypeSafe oferece SDKs oficiais em Python e JavaScript, além da API HTTP crua

3. Se for de Python, confira a versão antes de instalar: o SDK exige Python 3.10 ou superior. O erro comum é rodar o pip install num ambiente 3.9 antigo e tomar erro de resolução que não explica nada

4. Instale o SDK apontando pro índice extra da TypeSafe:

pip install "typesafe-sdk>=0.5.7" --extra-index-url https://pypi.typesafe.ai/

5. Configure a chave na variável de ambiente que o cliente lê. O erro comum é passar a chave hardcoded no código e depois descobrir que o client procura no ambiente:

export TYPESAFE_API_KEY="sua-chave-aqui"

6. Use a rota de modelo do early access, que é jev-latest. Ela já é chamada por padrão pelo cliente do SDK, então normalmente você não precisa declarar nada

7. Se preferir bater direto na API, o endpoint da System One API é POST https://api.typesafe.ai/v1/systemone

Daqui pra frente eu prefiro não inventar: o formato exato do payload, limites de rate e janela de contexto não estão documentados publicamente de forma confirmada, e chutar isso só ia te fazer perder tempo debugando o meu erro

Pra quem tá organizando a própria evolução técnica enquanto o mercado troca de stack a cada semestre, esse vídeo do canal mostra três coisas que atrasam a carreira de dev e como sair delas

Conclusão

Dá pra separar o Jev em duas pilhas bem diferentes

Na pilha da arquitetura declarada temos coisas concretas e coerentes: saída de probabilidades em paralelo em vez de token a token, saída estruturada tipada sem geração de strings, e o RLCD treinando o modelo pra devolver uma probabilidade calibrada em vez de otimizar preferência humana

Na pilha do resultado comprovado ainda tem pouca coisa: os ganhos de velocidade e custo são internos, a referência dos benchmarks veio de saídas de outros modelos, e não rolou reprodução independente em larga escala

O próximo passo prático depende de onde você tá

Se quer avaliar de verdade, entra na waitlist e mede no SEU fluxo, com os seus casos, porque é o único número que importa pro seu produto

E se não tem acesso ainda, tem algo que você pode fazer hoje: desenhar o gate de confiança da sua aplicação. Definir a partir de qual score você age sozinho, quando pede mais contexto, quando escala pra humano e quando chama o modelo caro

Essa lógica de roteamento vale independente do fornecedor, e é ela que segura a aplicação de pé quando o modelo erra

Até o próximo post! 🙂