Jev: o modelo que ajudou a colocar os Decision Models no mapa

Jev ajudou a dar visibilidade a uma pergunta que interessa a qualquer arquiteto: por que gerar uma sequência de texto quando a aplicação precisa de uma decisão delimitada? A TypeSafe usa System One Models para nomear sua proposta. Neste especial, usamos Decision Models como termo guarda-chuva e preservamos a nomenclatura específica da empresa.

O contrato antes da conversa

Segundo a TypeSafe, Jev recebe estado não estruturado e perguntas tipadas, devolvendo decisões probabilísticas. A empresa descreve arquitetura própria, amostragem paralela e treinamento por Reinforcement Learning for Calibrated Decisions, ou RLCD. O nome designa treinamento voltado à qualidade das decisões e suas probabilidades. A publicação apresenta a proposta; não oferece detalhes suficientes para uma reprodução independente de toda a arquitetura proprietária. [1]

O desenvolvedor delimita respostas possíveis. O software recebe uma opção válida para o contrato e decide o que fazer com ela. Conformidade de tipo não é garantia de correção semântica. Uma escolha errada não deixa de ser errada porque chegou no formato certo.

Perguntas, tipos e integração

A API documentada usa POST /v1/systemone. Há perguntas choice para opções nomeadas, score para escalas ordenadas e noul para estimar a probabilidade de uma afirmação ser verdadeira. O cliente envia contexto, modelo e critérios. [2]

Este corpo de requisição ilustra uma classificação. A saída pode alimentar uma fila; a aplicação ainda deve tratar erro, timeout e autorização.

{
  "model": "jev-1.13.0",
  "state": "Minha cobrança veio duplicada.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Qual equipe deve analisar este pedido?",
      "criteria": {
        "billing": "Cobranças e pagamentos",
        "technical": "Erros técnicos",
        "other": "Nenhuma das anteriores"
      }
    }
  }
}

Critérios têm efeito operacional. “Urgente” pode significar hoje, um incidente ativo ou risco ao cliente. Se a equipe não concorda com a definição, o problema aparece antes do modelo: falta uma política clara.

Preço e versão confirmados

Na consulta de 2 de outubro, a documentação identifica Jev 1.13 / jev-1.13.0, a US$ 0,042 por milhão de tokens de entrada, com saída gratuita. O orçamento total é 64 mil tokens por requisição; estado mais a maior pergunta ficam sujeitos a 32 mil. A entrada é textual, incluindo objetos JSON e arrays de texto, sem imagens, áudio ou vídeo diretos. [3]

Fixar a versão ajuda a manter rastreáveis os testes e limiares. Um alias atualizado pode mudar comportamento sem alteração no código da aplicação. Limites de taxa também devem ser consultados antes de planejar capacidade.

Evidência do fabricante

BENCHMARK DO FABRICANTE: segundo benchmark publicado pela TypeSafe, a latência de ponta a ponta apresentada no lançamento fica entre 70 e 500 ms. Isso não é um SLA nem uma medição da MnzAI Labs.

Os workflows do fabricante usam probabilidades de modelos externos como referência. A própria empresa reconhece que o desenho dos workflows, a forma de restringir os concorrentes e entradas curtas influenciam os ganhos publicados. Não adotamos os multiplicadores de marketing como promessa para produção. [1]

Uma comparação útil precisa registrar região do cliente, rede, tokens, perguntas, versão, concorrência, retries e distribuição de latência. Um tempo de demonstração sem esse contexto é insuficiente para dimensionar um sistema.

Evidência independente

AVALIAÇÃO INDEPENDENTE / PREPRINT: Deußer, Sparrenberg e Sifa avaliaram Jev 1.13.0 em 37 conjuntos de dados, com 346.009 requisições por menos de US$ 10. O estudo foi submetido em 29 de setembro de 2026. [4]

Os autores relatam boa calibração de escolhas, mas mostram que um limiar binário fixo de 0,5 nem sempre funciona bem. Em UNFAIR-ToS, o micro-F1 passou de 0,50 para 0,75 com limiares ajustados nos dados de treino. Também observam dificuldades em idiomas com poucos recursos, rótulos finos ou ruidosos e avaliações por rubrica. São resultados desse protocolo, sem extrapolação a todas as tarefas.

Outra avaliação independente, de Li, He e Li, investiga coerência probabilística: perguntas logicamente relacionadas deveriam produzir probabilidades compatíveis. O estudo encontra inconsistências em Jev, mesmo distinguindo-as do ruído entre chamadas. Calibração agregada não garante consistência lógica de cada conjunto de respostas. [5]

Ambos são preprints recentes. A leitura correta considera métodos, versões e dados, sem tratar qualquer um como veredicto definitivo. Eles não são medições do mesmo workflow do fabricante e não devem ser misturados em uma tabela de “ganhos”.

Probabilidade, confiança e limiar

Na documentação, confidence de Choice é uma estatística derivada da distribuição. Com três opções e probabilidade máxima de 96%, a fórmula resulta em 94% de confiança. Noul devolve uma probabilidade sem esse campo separado. [6]

Esses números servem como sinais para o sistema. Antes de automatizar, avalie o sinal escolhido contra o custo do erro. Separe dados para ajustar o limiar e para medir o desempenho final. Preserve uma saída de “não sei” e monitore mudanças no domínio.

Onde faz sentido e onde não faz

A própria TypeSafe documenta limitações com leitura literal, números, datas, contexto irrelevante, conteúdo adversarial e ordem das opções. Recomenda manter cálculos em código e usar modelos generativos quando a tarefa exige geração. [7]

Na prática, Jev pode decidir qual caminho um agente deve tentar; o frontier model pode planejar o trabalho mais complexo. O código aplica permissões e orçamento de tentativas. Volte ao hub ou examine como Strands muda a implantação para execução local.

Fontes verificadas em 2 de outubro de 2026

1. TypeSafe: lançamento, método e benchmarks próprios
2. TypeSafe: referência HTTP
3. TypeSafe: modelos, preços e limites
4. Avaliação independente: Evaluating and Benchmarking the System One Model Jev
5. Avaliação independente: Beyond Calibration
6. TypeSafe: definição e cálculo de confiança
7. TypeSafe: limitações de Jev 1.13