A arquitetura do Jev desvendada

Sondei o Jev com 10,000 chamadas à API para perceber, a grandes traços, como está construído, e porque é que a maioria das opiniões de charlatães no X está completamente errada. O X está cheio de opiniões inflamadas sobre o lançamento do Jev, e a maioria falha o ponto por completo: «12 milhões de visualizações por um classificador JSON? Sim, estamos numa bolha.» Um LLM comum gera «90% de confiança» como texto; a sua probabilidade de produzir essas palavras não estabelece uma probabilidade de 90% de estar certo. E, no entanto, construímos a deteção de fraude, a moderação, o encaminhamento e a avaliação de risco exatamente em torno deste padrão: pagamos por uma geração token a token e depois tratamos uma afirmação de confiança não validada como uma probabilidade sobre a qual o nosso software pode agir.

A proposta do Jev é manter o conhecimento de um LLM pré-treinado e, ao mesmo tempo, substituir as afirmações de confiança geradas por probabilidades de decisão lidas diretamente das suas representações internas. Essas probabilidades são treinadas contra resultados. Dá-lhe um estado, perguntas e respostas permitidas partilhados; ele devolve as distribuições em paralelo, sem gerar texto.¹ Para toda esta classe de aplicações, isso resolve os dois problemas: a fiabilidade do sinal de decisão e o cálculo desnecessário gasto a produzi-lo.

Há só um problema: não é de pesos abertos, e a TypeSafe recusa partilhar a sua investigação… Por isso vou fazê-lo eu (com os meus melhores esforços).

As provas apontam para um transformer causal (provavelmente com MoE esparso) reaproveitado para decisões: codificação de estado partilhado, ramos de perguntas isolados e leituras diretas de probabilidade em vez de geração de texto. Depois de sondar a API da TypeSafe (à procura de assinaturas no escalonamento da latência com diferentes comprimentos de contexto, na reordenação de perguntas, etc.), de peneirar toda a documentação e investigação públicas com o Astra, e de procurar trabalhos anteriores, acho que tenho um modelo bastante exato de como funciona e da sua arquitetura.

A espinha dorsal esparsa é a parte menos certa, mas é particularmente vantajosa para este domínio, com menos desvantagens do que os LLM autorregressivos, por isso seria estranho se não fosse assim. O cálculo partilhado e as saídas diretas de probabilidade estão obviamente muito melhor sustentados. Isto é claramente bastante especulativo, por isso vou tentar ser o mais claro possível quanto ao que foi publicado pela TypeSafe, ao que foi observado em experiências e ao que se infere delas. As APIs de caixa negra tornam espantosamente fácil pôr um manto sobre o fantasma e obter uma ideia aproximada de como é a arquitetura.

Porque é que este desenho é útil

Considera um pedido esquemático de encaminhamento de suporte. Isto ilustra a estrutura da API; as probabilidades de exemplo abaixo são inventadas.

{
  "state": "My payouts have failed three times. The bank says everything is fine. Can someone please fix this?",
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Which team should handle this ticket?",
      "criteria": {
        "payments": "Payout failures and payment processing",
        "account": "Login and account access",
        "other": "Something else"
      }
    },
    "escalate": {
      "type": "noul",
      "instructions": "Does this message require urgent human attention?"
    }
  }
}

Uma resposta útil poderia atribuir a payments uma probabilidade de 0.91 e ao escalonamento urgente apenas 0.42. São incertezas diferentes. O software pode encaminhar o ticket automaticamente e deixar o escalonamento para uma política à parte.

Um transformer causal já sabe construir uma representação do texto da esquerda para a direita. Durante a inferência normal de um modelo de linguagem, processa o prompt, prevê um token, reinjeta esse token e repete. Isto assenta na atenção do descodificador e na projeção de saída introduzidas no Transformer original.³ Mas a fase de processamento do prompt já produziu uma representação rica. Se a tarefa for escolher entre três filas, podemos acoplar uma pequena função que mapeia essa representação diretamente para três números.

Um detalhe aqui resolve grande parte da confusão sobre as respostas em paralelo: a atenção causal descreve que posições podem usar que informação, não a ordem pela qual os tokens de entrada têm de ser executados. Durante o processamento do prompt, ou prefill, todos os tokens de entrada já são conhecidos. O modelo pode processar as suas posições em conjunto dentro de uma camada enquanto a máscara de atenção bloqueia o acesso a posições posteriores; as camadas continuam a correr em sequência. A descodificação autorregressiva acrescenta outra dependência: o próximo token não existe até a previsão anterior ter sido escolhida. O nosso modelo proposto termina após o prefill e a leitura, por isso evita essa dependência token a token.

Isto muda a forma computacional da tarefa. A saída já não precisa de uma sequência de decisões de escrita para "payments": 0.91. A formatação JSON acontece no código normal da aplicação. A rede neuronal fornece as probabilidades.

Supõe agora que o estado é um longo relatório de incidente e que há cinquenta perguntas. A maior parte da entrada é partilhada. Um transformer armazena a informação intermédia sobre os tokens processados na sua cache de chave-valor, habitualmente abreviada para cache KV. No desenho proposto, cada pergunta lê a mesma cache de estado. Cada ramo acrescenta apenas as suas próprias instruções e opções de resposta.

Para um estado de $S$ tokens e $Q$ perguntas, pedidos separados processariam o estado cerca de $Q$ vezes. Partilhar reduz o processamento repetido dos tokens de estado de $QS$ para $S$. As perguntas continuam a ter de atender ao estado; esse trabalho não desaparece. Mas o modelo não precisa de reconstruir repetidamente as representações do estado.

O isolamento também dá à interface um significado útil. Perguntar se o cliente está zangado não deve mudar que fila recebe o ticket. Ambas as perguntas podem inspecionar as mesmas provas sem ler as instruções uma da outra. Os ramos não têm dependência computacional entre si, mesmo quando as suas respostas estão estatisticamente relacionadas.

Por fim, as probabilidades tornam a política a jusante explícita. Se um escalonamento desnecessário custa uma unidade e um caso urgente falhado custa nove, uma regra de decisão simplificada escala quando $p(\text{urgent}) > 0.1$. Esse cálculo só é significativo na medida em que as probabilidades são fiáveis para este fluxo de trabalho. Treinar e avaliar a distribuição de probabilidade torna-se, por isso, parte do produto, em vez de um campo de confiança cosmético.

Nada disto exige difusão. A classificação em paralelo existe há décadas. A combinação interessante é um transformer amplamente capaz, cálculo contextual partilhado, uma interface de saída tipada e um treino que recompensa a incerteza útil.

1. Termina a inferência com uma leitura

O primeiro componente é o mais simples: uma cabeça de previsão em vez de um ciclo de descodificação.

Provas publicadas. O anúncio de lançamento da TypeSafe diz: «O Jev emite todas as probabilidades em paralelo em vez de as gerar de forma autorregressiva token a token». A sua documentação expõe escolhas finitas, decisões de sim/não e pontuações ordenadas. Tudo isto é naturalmente representado por saídas numéricas fixas.¹²

Provas observadas. A API continua a reportar um campo output_tokens, que soa a um registo de geração. Não é. Para perguntas de sim/não, a contagem encaixa exatamente: 4 tokens partilhados, mais 15 por resposta, mais o comprimento em tokens do identificador de cada pergunta. A documentação da TypeSafe diz que esse identificador «não é enviado ao modelo subjacente e não é usado na inferência». Uma contagem que muda com texto que o modelo nunca vê é calculada após a inferência, a partir da resposta serializada. Os valores devolvidos também não a afetam: uma resposta de 0.0 custa o mesmo que uma de 0.01, embora cada dígito, de resto, conte como um token.²²⁴

O tokenizador por trás da contagem não corresponde a nenhum dos 192 tokenizadores públicos que testámos. Corresponde, sim, ao contador de entrada do próprio Jev para texto comum, diferindo apenas em longas sequências de espaços em branco e pontuação. output_tokens é um valor de faturação. Não nos diz nada sobre se o Jev gera texto, e não mediria esse texto mesmo que gerasse. A latência também não segue esse valor: uma pergunta com 200 opções (1,911 tokens de saída) devolveu-se tão depressa como uma com duas, e o tempo de servidor só cresceu com o comprimento da entrada.²⁴²⁵

Uma resposta de 255 opções reportou 2,714 tokens de saída.⁴ Seria um erro dividir esse número pela duração do pedido e chamar ao resultado a velocidade de descodificação do modelo. Um servidor pode serializar milhares de caracteres após uma única avaliação do modelo. O campo de contabilidade não nos diz quantos passos neuronais de descodificação ocorreram.

A leitura proposta pega num vetor oculto final $h$ e produz logits:

Aqui $K$ é o número de respostas permitidas. A matriz $W$ converte uma representação em pontuações de resposta; a softmax transforma essas pontuações numa distribuição. Para uma decisão de sim/não, um escalar e uma sigmoide bastariam.

As classes não precisam de ser conceitos fixos como «payments». Podem ser slots de opções: primeira opção, segunda opção, terceira opção. O ramo fornece o significado de cada slot; o código da aplicação mapeia a sua probabilidade de volta à chave de opção do chamador. Um Score ordenado pode de forma semelhante prever probabilidades sobre níveis e devolver a sua média ponderada pelas probabilidades. Isto suporta decisões novas sem treinar uma cabeça nova para as etiquetas de cada cliente. Um scorer de estilo ponteiro, comparado na secção 4, é a principal alternativa: pontua a representação de cada opção em vez de um slot numerado.

Isto não estabelece que o Jev tenha um módulo classificador com nome próprio. A cabeça de vocabulário de um modelo de linguagem também é uma matriz seguida de softmax. Selecionar $K$ linhas de etiquetas reservadas dessa matriz pode implementar o mesmo cálculo que uma cabeça dedicada de $K$ classes. As linhas podem estar atadas às embeddings de entrada ou treinadas de forma independente; aqui não conseguimos distinguir essas configurações.

A distinção importante é entre ler probabilidades e gerar texto que descreve probabilidades. Um «91%» gerado é uma sequência de tokens. O 0.91 de um classificador é uma entrada da sua distribuição preditiva. Qualquer dos dois pode estar mal calibrado. Nenhum se torna fiável só pelo seu formato.

A descodificação de texto restringida continua a ser uma forma possível de construir uma interface semelhante, mas a TypeSafe descreve explicitamente um caminho de saída diferente. A sua afirmação é uma prova mais forte do que um argumento de latência. As provas apontam para uma leitura numérica direta, um dos dois desenhos comparados na secção 4. Os tokens de etiqueta reservados continuam possíveis, embora o teste de opções falsas ali jogue contra eles.

2. Partilha o estado, isola as perguntas

A decisão seguinte diz respeito a onde o cálculo é reutilizado.

Provas observadas. A contabilidade de tokens é exatamente aditiva nos pequenos exemplos controlados. Uma pergunta mínima de sim/não usou 268 tokens de entrada; duas usaram 276. Um pedido com uma pergunta de sim/não, um Choice de duas opções e um Score de dois níveis usou 318, coincidindo com a soma das suas contribuições medidas acima da sobrecarga partilhada. Isto encaixa num prefixo comum mais sufixos de pergunta, embora a contabilidade sozinha não identifique um grafo computacional.⁴

Um experimento mais informativo move provas entre essas regiões. O estado dizia inicialmente:

The weather is nice today and the park is full of people.

Uma pergunta irmã continha:

The secret code for this request is ZEBRA-7741.
Is the weather described as nice?

A sonda perguntava que código outra pergunta mencionava, com ZEBRA-7741, dois distratores e none como opções. Com o segredo na pergunta irmã, a sua probabilidade reportada foi 0.00. Remover essa pergunta irmã produziu o mesmo resultado. Pôr a declaração no estado em vez disso elevou-a a 0.90–0.92. Foram cinco repetições por condição (visibility nos registos da sonda).⁵

Esta é uma intervenção útil: mover a declaração através de uma fronteira da API muda o seu efeito. Sustenta um isolamento comportamental entre perguntas e o acesso ao estado partilhado. Não expõe a máscara de atenção exata. Chamadas separadas ao modelo, uma máscara em árvore ou outro mecanismo que restrinja o fluxo de informação poderiam produzir o mesmo resultado. A formulação da sonda também pergunta por «outra pergunta» mesmo na condição de estado, por isso não é um teste puro de seguimento literal de instruções.

As medições de serviço acrescentam outra peça. Até cerca de 100 perguntas, o tempo de servidor quase não mudou. A partir daí subiu de forma constante e, token a token, o texto das perguntas custou aproximadamente o dobro do estado. Isso é consistente com calcular o estado uma vez e agrupar o trabalho das perguntas.⁶

Estes são durações do serviço a montante reportadas pelo servidor, não cronometragens de um portátil local. Incluem todo o trabalho e espera que o serviço a montante inclui, e o serviço era partilhado com outros utilizadores.

O Jev impõe dois limites. Cada ramo (o estado mais uma pergunta) está limitado a cerca de 32,768 tokens, e o pedido completo a cerca de 65,536. O limite do pedido conta o estado uma só vez: um estado de 23k tokens com 5,000 perguntas cabe dentro dele. Se cada pergunta processasse a sua própria cópia do estado, esse pedido ultrapassaria os 100 milhões de tokens. O par cabe numa única sequência empacotada de até 2¹⁶ tokens, contendo o estado uma vez e cada pergunta a seguir, com cada ramo limitado a uma janela de contexto de 2¹⁵.²²

Uma cache KV de prefixo com sufixos causais separados é a implementação natural. Hydragen descreve atenção eficiente para sequências que partilham um prefixo; DeFT desenvolve atenção para inferência com estrutura em árvore. Ambos estabelecem que o padrão de serviço é prático. São trabalhos anteriores, não provas de que a TypeSafe usa qualquer uma dessas bibliotecas.⁷⁸

Este desenho também esclarece uma contradição aparente: perguntas isoladas podem ainda ser avaliadas em conjunto no mesmo acelerador. «Paralelo» descreve o seu escalonamento e a ausência de dependências entre respostas. Não tem de significar uma GPU por pergunta.

3. Uma espinha dorsal causal

As experiências não conseguem distinguir um descodificador causal de um codificador bidirecional: em ambos, a decisão final pode ler toda a entrada. Assumo na mesma um descodificador causal, por uma boa razão. A amplitude de conhecimento do Jev (84.6% no MMLU-Pro) exige um pré-treino à escala da fronteira, todo o modelo a essa escala é um descodificador causal, e a TypeSafe descreve o RLCD como pós-treino de um modelo de linguagem pré-treinado. Um Jev bidirecional significaria ou uma base muito mais fraca, ou converter um descodificador a um custo extra, abdicando ao mesmo tempo da cache de prefixo partilhada que o serviço causal proporciona. Isso seria surpreendente, mas não pode ser excluído do exterior.¹²¹⁵

Qual é o modelo pré-treinado, desconhece-se, e o tokenizador não revela nenhum. As contagens de tokens do Jev não coincidem com nenhum dos 192 tokenizadores públicos que testámos em 415 sondas. Divide cada dígito individualmente e procura blocos inteiros antes de fundir: 8 as contam como um token, mas 16 contam como quatro. O seu vocabulário segue de perto o o200k da OpenAI, já que cada cadeia que o Jev conta como um único token é também um único token do o200k, mas a divisão de dígitos e várias fusões excluem o próprio o200k. A correspondência pública mais próxima, o Qwen, concorda em 348 de 415 sondas. Isso exclui um tokenizador público inalterado, não um modelo base público: um vocabulário substituído, um pré-treino continuado ou uma destilação poderiam explicá-lo, assim como uma API que conte tokens de forma diferente do modelo.¹⁸

As experiências mostram, sim, o que a decisão consegue ler. Coloquei um cartão de referência entre as opções de uma pergunta e pedi ao Jev que escolhesse a opção cuja condição o cartão satisfaz. Aqui está um conjunto exato de opções:

alpha: Reference card: status = amber. Reference-only option.
       Never select this option.

beta: Select this option if the reference card's status is amber.

gamma: Select this option if the reference card's status is indigo.

A instrução era: «Lê o cartão de referência e escolhe a única opção cuja condição é satisfeita.» Mudar o valor de referência para indigo troca a resposta correta sem alterar as opções selecionáveis.

Testei ambos os valores, as seis permutações de opções e um segundo modelo com route = east/west, com duas repetições. Um controlo emparelhado colocou a referência no estado partilhado em vez disso. Isso deu 48 ensaios de referência em opções e 48 controlos de referência no estado.²⁰

O Jev consegue usar informação colocada depois das descrições dos candidatos. Com a referência em último lugar, selecionou a opção correta em todos os ensaios, com uma probabilidade média de resposta correta de cerca de 0.88.

O controlo de troca de valor importa tanto como a posição. Com o cartão em último lugar, mudar apenas amber para indigo muda qual opção anterior vence, embora essas descrições anteriores e o estado fiquem idênticos. Um modelo que pontua cada opção de forma independente a partir do seu próprio texto e do estado, e depois apenas normaliza as pontuações, não tem qualquer via para esse facto mudar a ordenação relativa das opções anteriores. Os resultados sustentam um caminho pelo qual as opções influenciam a decisão conjunta.²⁰

Isto encaixa em qualquer leitura calculada depois da lista completa, incluindo ambos os desenhos comparados na secção 4, bem como uma etapa separada de mistura de opções. Os erros restantes mostram um processamento sensível à posição nestes dois modelos; não identificam uma causa única.

A difusão é desnecessária para este cálculo, e nada nestas experiências exige uma desfocagem iterativa. A inferência arquitetural defensável é mais estreita: o cálculo da resposta tem acesso à lista completa de opções. A experiência seguinte testa se ele realmente usa esse contexto conjunto.

4. Deixa as opções interagir antes de escolher

Dentro de uma pergunta, as provas apontam para uma fronteira de informação diferente: as alternativas são lidas em conjunto como uma lista ordenada, seguidas de uma única posição de decisão.

Porquê permitir essa interação? Opções como «nenhuma das anteriores» dependem das outras escolhas. Mesmo alternativas comuns podem esclarecer uma pergunta. «Payments», «account access» e «other» definem uma decisão diferente de «bank», «payment provider» e «customer». Uma representação ao nível da lista permite ao modelo interpretar essa distinção antes de produzir a distribuição.

A prova mais forte é uma experiência com uma opção extra irrelevante.

Começa com quatro causas possíveis de uma falha de pagamento: bank, provider, customer e unknown. Depois acrescenta weather: Bad weather caused it. Se cada opção original receber um logit independente e inalterado e o servidor aplicar a mesma temperatura de softmax, acrescentar uma quinta opção muda a normalização mas não pode mudar as probabilidades relativas entre duas opções existentes:

O denominador comum cancela-se. Isto dá-nos uma previsão específica e falsificável.

O estudo original encontrou uma mudança de aproximadamente +0.49 para +0.08.¹⁰ Para verificar se isto sobrevivia à variabilidade normal entre pedidos, repeti a experiência em dez blocos aleatorizados. Cada bloco incluía a linha de base de quatro opções, um controlo idêntico de quatro opções, uma versão de cinco opções com weather acrescentado, um controlo idêntico de cinco opções e uma versão de cinco opções cuja descrição acrescentada mudava de «Bad weather caused it» para «Wild birds caused it». Cada pedido continha uma pergunta.²¹

O resultado da expansão replicou-se. Agrupando os dois pedidos idênticos de cada condição dentro de cada bloco, o log-odds médio caiu de +0.38 para +0.11. Todos os blocos mostraram uma descida; a mudança média foi −0.28, com um intervalo t emparelhado descritivo de 95% de aproximadamente −0.36 a −0.19. O agrupamento usa os pedidos de controlo para reduzir o ruído normal dos pedidos, em vez de tratar saídas duplicadas como experiências independentes.²¹

Isto é uma prova contra logits fixos e independentes seguidos de uma softmax inalterada. Não identifica o mecanismo de forma única. Mudar a descrição acrescentada mantendo cinco opções deu uma mudança menor e inconclusiva: o seu intervalo emparelhado incluía o zero. Uma temperatura dependente do conjunto continua possível, a par de uma mistura dependente do conteúdo.

Uma leitura que vê a lista completa explica isto naturalmente: acrescentar uma opção muda o contexto que ela lê. O método de ranking ao nível da lista FIRST funciona da mesma maneira, extraindo um ranking dos logits do primeiro token em vez de o gerar token a token.¹¹

Dois tipos de leitura encaixam nas provas. Uma cabeça de posição final pontua cada slot de opção a partir da representação do token de decisão; um scorer de estilo ponteiro compara essa representação com o estado oculto final de cada opção. Ambos deixam as opções influenciarem-se mutuamente. A API aceita no máximo 255 opções (2⁸ − 1), o que se adequa a uma cabeça fixa de 256 slots, mas esse limite é imposto pela validação do pedido, não pelo modelo. Com 200 opções, uma resposta copiada pontuou 1.00 em todas as posições e os erros não transbordaram para as opções vizinhas, o que se adequa a um ponteiro. Nenhum dos resultados é decisivo.²⁶

Opções falsas injetadas nunca deslocaram as reais, por isso as fronteiras entre opções estão marcadas de uma forma que o texto não consegue falsificar, e uma opção cuja condição está duplicada noutro ponto da lista perde probabilidade para as suas rivais.²³

O compromisso também é visível em tarefas comuns: inverter as opções deslocou a probabilidade de uma classificação de suporte técnico de aproximadamente 0.84–0.89 para 0.93–0.96. Isto veio das sondas option_order.⁹ Para uma política de decisão implementada, isso importa. Um limiar perto de 0.9 poderia mudar a ação mesmo com as etiquetas e as provas idênticas. Os testes de permutação pertencem à avaliação de qualquer implementação deste desenho.

5. Treina a distribuição e depois calcula a confiança

O quinto componente é o objetivo de treino. As saídas numéricas diretas poupam trabalho de descodificação, mas uma probabilidade barata pode ainda ser uma má probabilidade.

Imagina um conjunto de casos aos quais se atribui 0.8 de probabilidade de serem urgentes. A calibração pergunta se cerca de 80% o são de facto. É uma propriedade das previsões ao longo dos casos. Não podemos determinar se uma previsão está calibrada a partir de esse caso concreto sair bem.

A TypeSafe chama ao seu método de treino Reinforcement Learning for Calibrated Decisions, ou RLCD. O anúncio diz que otimiza «respostas com probabilidades epistemicamente honestas em tarefas do System One»; a introdução da empresa apresenta o RLCD como um caminho de pós-treino a partir de modelos de linguagem pré-treinados.¹¹² A receita exata não está publicada. A minha receita de treino proposta adapta o transformer e a leitura a tarefas de decisão tipadas usando um objetivo baseado em resultados. Isso dá à espinha dorsal a oportunidade de construir representações úteis para decisões fiáveis, e não apenas completações fluentes.

Um objetivo natural é a perda logarítmica, $-\log p(y)$ para o resultado observado $y$. Outro é a perda de Brier, a distância ao quadrado entre a distribuição prevista e o resultado observado em one-hot. Ambas são regras de pontuação próprias: em esperança, reportar a verdadeira distribuição condicional minimiza a perda. Gneiting e Raftery dão a definição formal e a teoria.¹³ Isto explica o que esse treino tenta alcançar. Não estabelece que perda a TypeSafe usa, se o seu pipeline é aprendizagem por reforço no sentido algorítmico estrito, ou se todos os pesos da espinha dorsal são atualizados.

O facto de serem próprias também não é uma garantia de implementação. Dados finitos, limitações do modelo, erro de otimização e mudança de distribuição podem todos deixar a calibração imperfeita. Guo et al. mostram tanto os problemas de calibração das redes neuronais modernas como a utilidade dos ajustes a posteriori. O treino e a calibração a posteriori são mecanismos compatíveis; a API não consegue separar as suas contribuições.¹⁴

Provas observadas. Os registos de benchmark permitem-nos comparar a probabilidade prevista com a exatidão observada, tanto no agregado como dentro de intervalos de probabilidade. O gráfico mostra essas verificações. A concordância das médias sozinha é uma prova mais fraca do que a concordância dentro dos intervalos: o excesso de confiança num grupo pode cancelar o défice de confiança noutro. Na amostra de 1,200 itens do MMLU, o erro de calibração esperado com dez intervalos foi 0.0313 (definições dos intervalos e previsões ao nível do item). A maioria das previsões concentrou-se perto da certeza: 990 caíram no intervalo 0.9–1.0.¹⁵

O pequeno estudo de matemática recém-gerada acrescenta variação útil. Em problemas gerados de multiplicação de três dígitos, a exatidão foi de 86.7% e a probabilidade superior média de 0.83. Em problemas de palavras de dois passos, a exatidão caiu para 32% e a probabilidade superior média para 0.30. O modelo mostrou-se menos confiante na tarefa mais difícil (fresh_math_results, com 30 itens de multiplicação e 25 de problemas de palavras).¹⁵ Isso é encorajador, embora médias pequenas ao nível da categoria não consigam estabelecer a calibração para todo o tipo de problema não visto.

Esses resultados também mostram porque é que uma pontuação de benchmark pública é uma medida imperfeita daquilo que o modelo sabe. A exatidão no MMLU-Pro foi de 84.6%; os problemas de palavras recém-gerados eram muito mais difíceis.¹⁵ Diferenças na estrutura da tarefa, nos distratores, na dificuldade e na exposição durante o treino poderiam contribuir todas. Essa lacuna não estabelece contaminação do benchmark. Uma formulação nova também não torna a competência matemática ou o conhecimento factual subjacentes algo não visto.

Há uma conclusão separada, invulgarmente clara, sobre o campo da API chamado confidence. O adaptador oficial calcula a confiança de Choice a partir de uma distribuição normalizada, para $K > 1$, como:

Para três opções com uma probabilidade máxima de 0.8, isto dá 0.7. O adaptador trata o caso de uma só opção em separado, devolvendo 1. Mede o quanto a resposta líder se destaca acima de uma distribuição uniforme. Não é outra estimativa aprendida de que a resposta está correta. O tipo Score usa uma fórmula diferente que reflete a distância ao nível modal.¹⁶

No sistema proposto, o treino produz a distribuição preditiva; a aritmética comum produz este campo de resumo. Manter estes dois objetos separados evita um erro conceptual comum: uma distribuição concentrada pode ainda estar errada com confiança.

6. Capacidade esparsa

Espero que o Jev use um transformer de mistura de especialistas esparsa. Em camadas selecionadas, um encaminhador envia cada token por um pequeno subconjunto de redes feed-forward, de modo que o modelo pode armazenar muitos parâmetros e ativar apenas alguns deles por token: a ideia de cálculo condicional demonstrada pelas camadas MoE de porta esparsa de Shazeer et al.¹⁷

Os especialistas esparsos não podem ser observados do exterior, mas são a escolha provável. Um modelo só de prefill está limitado pelo cálculo, que é exatamente o que o escalonamento esparso poupa. Os custos habituais de serviço de um MoE quase desaparecem: não há descodificação token a token, onde a largura de banda de memória domina e a maioria dos especialistas acaba ativa de qualquer forma, e não há uma cache KV de longa duração a competir com os pesos dos especialistas pela memória. As medições apontam no mesmo sentido. O Jev processou cerca de 30k tokens em aproximadamente 160 ms; um modelo denso de 70B num nó de 8×H100 precisaria de cerca de um segundo, enquanto um MoE com cerca de 10B de parâmetros ativos encaixa. E a maioria dos modelos base recentes mais fortes (DeepSeek-V3, Qwen3, GLM-4.5, Kimi K2, gpt-oss) são MoE. Hardware especializado poderia permitir a um modelo denso igualar a velocidade, e as pontuações de benchmark podem exagerar quanto conhecimento o modelo retém, por isso isto continua a ser uma inferência, não uma medição.⁶¹⁵

Nada mais na reconstrução depende disso. Substituir por um transformer denso deixaria a interface, o estado partilhado, os ramos isolados e a leitura exatamente como descritos.

7. Escalona os ramos como um lote, não como uma conversa

O componente final é um motor de serviço que trata os ramos de perguntas como itens de trabalho independentes. Os seus sufixos podem ser empacotados em lotes enquanto leem as representações do estado partilhado. O código da aplicação associa depois as saídas numéricas aos identificadores de pergunta e serializa a resposta.

As medições revelam pequenas diferenças entre respostas idênticas repetidas, incluindo entre perguntas duplicadas dentro de um mesmo pedido. Isto significa que o determinismo ao nível da API não deve ser assumido (noise, dup e determinism).¹⁹ Não implica que o modelo gere ou amostre texto: os núcleos numéricos, o batching dinâmico, o encaminhamento ou uma aleatoriedade deliberada podem todos afetar uma leitura direta.

As ordens das chaves de resposta também variaram num pequeno número de padrões recorrentes.¹⁹ Vários workers com ordenação de hash diferente são uma explicação plausível. No entanto, este canal lateral não identifica o número de workers, não estabelece onde vive a cache KV nem nos diz que precisão numérica é usada. São detalhes de implementação que as observações disponíveis não conseguem resolver.

O que importa para a arquitetura proposta é a ausência de uma cadeia de dependência entre respostas. O modelo não precisa de terminar de escrever a classificação da fila antes de começar a estimativa de urgência. Ambas dependem do estado; nenhuma consome a resposta gerada pela outra.

Continua a haver um limite de dependência. Se uma pergunta posterior precisar genuinamente de uma resposta anterior, a aplicação tem de introduzir outra etapa de decisão ou expressar a decisão conjunta numa só pergunta. Partilhar o contexto não remove a estrutura lógica do fluxo de trabalho.

O que me faria mudar de ideias?

Esta reconstrução faz compromissos de tipos diferentes. As saídas diretas de probabilidade estão descritas publicamente. O isolamento entre perguntas e os efeitos da ordem das opções são comportamentos observáveis. A partilha da cache KV, a atenção causal, as leituras de posição final ou de estilo ponteiro e os especialistas esparsos são explicações progressivamente mais específicas.

A experiência do cartão de referência resolve uma pergunta: a decisão consegue usar opções colocadas em último lugar. O teste de opções falsas mostra que truques no formato da entrada não conseguem forjar fronteiras entre opções. Tarefas relacionais mais amplas poderiam restringir mais a representação, embora o sucesso comportamental por si só continuasse a não identificar de forma única uma máscara de atenção.

Para o tratamento de opções, o seguimento aleatorizado replica um efeito do conjunto de escolhas, mas a intervenção sobre a descrição de tamanho fixo continua inconclusiva. Mais modelos e blocos de pedidos independentes poderiam distinguir uma mudança de temperatura partilhada de interações dependentes do conteúdo. Uma tarefa de dificuldade média com 200 opções poderia separar a cabeça de slots do scorer de ponteiro. Para a calibração, dados de fluxo de trabalho reservados e avaliações repetidas sob mudança importariam mais do que outra pontuação de benchmark agregada. Confirmar os especialistas esparsos exigiria provavelmente uma divulgação ou provas além desta API.

A minha melhor reconstrução do Jev continua a ser a do diagrama inicial: um transformer causal com um prefixo de estado partilhado, sufixos de pergunta isolados, processamento de opções ao nível da lista, leituras numéricas tipadas e um treino orientado a distribuições preditivas. Os especialistas esparsos são a espinha dorsal provável, embora nada mais no desenho dependa deles.

A sua utilidade vem de fazer coincidir o grafo computacional com a tarefa. Um serviço de decisão precisa de ler provas, comparar resultados permitidos e expor incerteza. Um transformer consegue fazer isso sem primeiro transformar cada decisão numa frase.

Métodos

Este ensaio baseia-se numa investigação de 17 de setembro de 2026 ao jev-1.13.0, usando uma conta de acesso antecipado e uma região de serviço observada. O estudo de origem contém 1,029 registos de sonda instrumentados (incluindo os 190 itens de matemática gerada), 6,800 registos de benchmark e verificações factuais separadas. Os estudos de seguimento acrescentaram 146 pedidos relacionais e de interação entre opções (ensaios, resumo), 311 pedidos de contabilidade de tokens, 445 pedidos de impressão digital do tokenizador, 192 pedidos de latência, 148 pedidos de latência por número de opções, 181 pedidos de posição de opção, 105 pedidos de opções falsas e 35 pedidos de limite de contexto. Cada um está ligado a partir das referências, com os pedidos exatos e respostas saneadas. As configurações de benchmark repetidas partilham itens subjacentes; estas contagens não são contagens de problemas independentes.

O pacote de provas descarregável regista as observações usadas neste ensaio. Os exemplos de API na secção inicial são esquemáticos. Os prompts citados de visibility e do cartão de referência vêm dos scripts de sonda e dos pedidos de seguimento guardados. As observações numéricas são específicas desta versão do modelo e desta campanha de testes.

Os valores de latência vêm do cabeçalho de resposta x-envoy-upstream-service-time. São durações do serviço a montante, com fronteiras de fila e de execução desconhecidas, e não cronometragens isoladas do modelo. As varreduras da figura de latência foram executadas um pedido de cada vez, em ordem baralhada; nenhum dos estudos controlou a carga do servidor. As medições locais de relógio de parede não são usadas como prova arquitetural.

As probabilidades eram geralmente devolvidas com duas casas decimais de precisão. Perguntas duplicadas num mesmo pedido partilham condições e podem ter erros correlacionados. A figura de calibração do MMLU usa dez intervalos de igual largura: [0, 0.1), [0.1, 0.2), e assim sucessivamente, com 1.0 incluído no último intervalo. O erro de calibração esperado é a diferença absoluta, ponderada pela amostra, entre a exatidão e a probabilidade superior média em cada intervalo. As estimativas dependem da seleção da amostra, do agrupamento em intervalos e do arredondamento das respostas. As provas sustentam afirmações sobre as distribuições testadas, não uma calibração garantida em futuros fluxos de trabalho de clientes.

Fontes e trabalhos relacionados

As referências experimentais identificam as etiquetas originais dos scripts para que cada observação possa ser localizada no pacote de provas. As citações de artigos estabelecem os mecanismos propostos e os seus precedentes; não estabelecem que o Jev os use.

Fontes

1. TypeSafe (2026). Introducing System One Models and Jev. Fonte principal para a afirmação da saída em paralelo e o objetivo RLCD declarado.
2. TypeSafe. Documentação completa da API, consultada em 17 de setembro de 2026. Perguntas tipadas, distribuições de resposta e contrato da API.
3. Vaswani et al. (2017). Attention Is All You Need. Mascaramento do descodificador, atenção e a camada de saída linear/softmax.
4. Experiências de API: type_preamble e outputs. Aditividade da contabilidade de tokens, alterações de identificador e a resposta de 255 opções.
5. Experiência de API: visibility. Cinco repetições com o segredo numa pergunta irmã, ausente dessa irmã e no estado.
6. Varreduras de latência (192 pedidos sequenciais). Comprimento do estado e número de perguntas, 8 repetições baralhadas cada; durações do serviço a montante reportadas pelo servidor.
7. Juravsky et al. (2024). Hydragen: High-Throughput LLM Inference with Shared Prefixes.
8. Yao et al. (2024). DeFT: Decoding with Flash Tree-attention for Efficient Tree-structured LLM Inference.
9. Experiência de API: option_order. Sensibilidade à ordem em tickets comuns.
10. Experiência de API: iia. Três pedidos por condição, cada um com quarenta perguntas duplicadas; conjuntos de escolhas original, com opção acrescentada e com opção anteposta.
11. Reddy et al. (2024). FIRST: Faster Improved Listwise Reranking with Single Token Decoding.
12. TypeSafe. Introdução à aprendizagem automática. Descrição principal do caminho de pós-treino RLCD e do contrato de calibração.
13. Gneiting and Raftery (2007). Strictly Proper Scoring Rules, Prediction, and Estimation. Journal of the American Statistical Association 102(477):359–378.
14. Guo et al. (2017). On Calibration of Modern Neural Networks.
15. Registos de benchmark e de matemática gerada: exatidão e probabilidades previstas médias. ; Análise de fiabilidade do MMLU: definições dos intervalos, ECE, intervalos de Wilson e 1,200 previsões ao nível do item.
16. TypeSafe. Adaptador oficial de Python, confidence_metrics.py, revisão fb52b103. Fórmulas de confiança de Choice e Score (lido em 17 de setembro de 2026).
17. Shazeer et al. (2017). Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer.
18. Experiência de impressão digital do tokenizador (445 pedidos). Sondas de comprimento de sequência, vocabulário e pré-tokenização, comparadas com 192 tokenizadores públicos.
19. Experiências de API: noise, dup e determinism. Probabilidades repetidas e ordens das chaves de resposta.
20. Experiência relacional de seguimento (96 pedidos). Dois modelos, dois valores de referência, seis permutações, duas localizações e duas repetições; pedidos exatos e respostas saneadas.
21. Experiência de interação entre opções de seguimento (50 pedidos). Dez blocos aleatorizados de base4, null4, append5, replace5 e null5; mudanças emparelhadas e erros padrão.
22. Experiência de limite de contexto (35 pedidos sequenciais). Limites de tokens por ramo e por pedido completo, com casos-limite aceites e rejeitados.
23. Experiência de injeção de opções falsas (105 pedidos). Sete formatos de delimitador, tarefas base saturadas e ambíguas, e vetores de probabilidade completos.
24. Experiências de contabilidade de tokens (311 pedidos). Comprimento do ID de pergunta, tamanho do lote, dificuldade do estado, IDs de palavra e cadeias emparelhadas de estado versus ID.
25. Experiência de latência por número de opções (148 pedidos). Uma ou 20 perguntas com 2–200 opções, etiquetas curtas e longas, mais controlos de desacoplamento entrada/saída.
26. Experiência de posição de opção (181 pedidos). Limite do número de opções, resposta correta deslocada por listas de 10, 50, 200 e 255 opções.

Fonte: A arquitetura do Jev desvendada — Archer, archerhume.com, 17 de setembro de 2026.