Sondas de API desvendam a arquitetura do Jev

A tese: Jev como modelo de decisão, não gerador de texto

Em um ensaio detalhado, o autor relata ter feito cerca de 10.000 chamadas à API da TypeSafe para inferir como o Jev, modelo lançado em setembro de 2026, é construído internamente. O ponto de partida é uma crítica ao padrão comum da indústria: LLMs comuns produzem frases como "90% de confiança", e o custo em tokens de gerar essas palavras não garante que a probabilidade seja real - mesmo assim, sistemas de fraude, moderação e roteamento agem sobre essas alegações não validadas. A proposta do Jev seria manter o conhecimento de um LLM pré-treinado, mas substituir a geração de texto por distribuições de probabilidade lidas diretamente das representações internas e treinadas contra resultados reais.

Sondando uma caixa-preta

Como o modelo não é open-weights e a TypeSafe não publica a pesquisa, o autor combinou três fontes: experimentos de latência e contagem de tokens na API, documentação oficial e busca de trabalhos anteriores. A conclusão, explicitamente especulativa, aponta para um transformer causal (provavelmente com MoE esparso) reaproveitado para decisões, com três elementos: codificação de estado compartilhado, ramificações de perguntas isoladas e readouts de probabilidade diretos.

Evidências por componente

Readout em vez de decodificação. A documentação afirma que o Jev "produz todas as probabilidades em paralelo em vez de gerar tokens autoregressivamente". O campo output_tokens da API, que parece registrar geração, é na verdade uma figura de cobrança: sua contagem muda com identificadores que o modelo nunca vê, não corresponde a nenhum dos 192 tokenizers públicos testados e não se correlaciona com a latência - uma pergunta com 200 opções retornou tão rápido quanto uma com duas.

Estado compartilhado, perguntas isoladas. A contagem de tokens é exatamente aditiva entre perguntas, consistente com um prefixo comum mais sufixos por pergunta. Em um experimento de intervenção, mover um segredo da pergunta irmã para o estado compartilhado elevou a probabilidade de o modelo relatar o código de 0,00 para 0,90–0,92. Limites da API (32.768 tokens por ramificação, 65.536 por requisição, contando o estado uma vez) sugerem um cache de prefixo com sufixos causais separados; até ~100 perguntas, o tempo de servidor quase não muda.

Backbone causal e interação entre opções. As sondas não conseguem distinguir um decodificador causal de um encoder bidirecional, mas o autor assume o causal pelo desempenho de 84,6% no MMLU-Pro e pelo padrão da indústria. Um experimento de referência mostra que o Jev usa informações colocadas depois das opções candidatas (16/16 acertos com a carta de referência por último). Mais importante: adicionar uma opção irrelevante ("clima ruim causou") deslocou os log-odds entre opções existentes em todos os dez blocos de repetição (média de −0,28), refutando logits independentes fixos - as opções interagem antes da escolha. O autor nota o custo prático: reordenar opções mudou uma probabilidade de ~0,84–0,89 para ~0,93–0,96, o que pode alterar decisões com limiares próximos de 0,9.

Treinamento e calibração. A TypeSafe chama seu método de RLCD (Reinforcement Learning for Calibrated Decisions), mas a receita exata é não publicada; o autor propõe objetivos como log loss ou Brier loss, regras de pontuação proprias. Em 1.200 itens do MMLU, o erro de calibração esperado em dez bins foi de 0,0313. Problemas de matemática recém-gerados mostraram confiança que acompanha a dificuldade: produtos de dois dígitos com 97,8% de confiança média e 96% de acerto; problemas de dois passos com 30,4% e 32%. Modular exponenciação foi a exceção clara: 56% de acerto com probabilidade média de 35%.

Capacidade esparsa. A parte menos certaina da inferência é o MoE esparso, sustentado pela medida de que o Jev processa ~30 mil tokens em ~160 ms - muito rápido para um modelo denso de 70B, compatível com cerca de 10B de parâmetros ativos.

Conclusão

O autor mantém o ceticismo apropriado: cada componente é rotulado como evidência publicada, observada ou inferida, e lista o que o faria mudar de ideia. O argumento central é que a combinação - transformer pré-treinado, computação de estado compartilhada, interface de saída tipada e treinamento que recompensa incerteza útil - resolve dois problemas de uma vez: a confiabilidade do sinal de decisão e o desperdício de computação na geração token por token.