Jev ou treinar seu próprio classificador: qual caminho escolher para decisões em escala?

Comprar ou construir

É a pergunta mais velha da engenharia e ela voltou a bater na porta, agora em cima de classificação em escala

A TypeSafe AI lançou o Jev, primeiro modelo da classe que eles chamam de System One, em acesso antecipado com lista de espera desde 15 de setembro de 2026. A sacada é que ele não gera texto: ele devolve decisões tipadas com probabilidade

E aí o papo muda de figura, né?

Porque o lugar que esse modelo ocupa não é o do chatbot, é o lugar do classificador que tu treinaria na mão. Então bora comparar os dois caminhos de verdade: adotar o Jev versus treinar e manter seu próprio classificador 🙂

O que é o Jev e por que ele entra nessa comparação

A ideia do System One é simples de explicar

Tu manda um estado (o state, que é o contexto em linguagem natural) e junto um mapa de perguntas tipadas (o questions). O modelo responde todas numa passada paralela

A chamada é um POST para https://api.typesafe.ai/v1/systemone, com os campos model, state e questions

POST https://api.typesafe.ai/v1/systemone

{
  "model": "jev-1.13.0",
  "state": "...contexto do ticket, do documento, do evento...",
  "questions": { ... }
}

Pré-inscrição Curso Jev

Domine o Jev e coloque decisões de IA dentro do seu sistema

Você vai aprender a usar o Jev, o System One Model da TypeSafe AI, pra automatizar decisões com resposta tipada e confiança medida, sem depender de chat nem de alguém revisando cada passo. Entre na lista de espera para garantir a condição de lançamento!

Quero minha vaga

E que perguntas são essas?

São três tipos, e só três:

• Noul: sim ou não
• Choice: escolha dentro de uma lista que tu define
• Score: nota numa escala

Se você já montou um classificador binário, um multiclasse e um regressor de nota, acabou de reconhecer os três. É o mesmo trio de sempre, só que a interface é um schema em vez de um model.pkl

A saída fica restrita aos tipos que o desenvolvedor definiu. A empresa descreve o modelo como incapaz de emitir string fora do formato, justamente porque ele não gera texto livre

Esse ponto é o coração da comparação: previsibilidade de saída por construção, não por parsing e retry

E quem está por trás disso?

A TypeSafe AI saiu do stealth com US$ 40 milhões em rodada seed liderada pela DCVC, de acordo com o SiliconANGLE

A mesma reportagem diz que a empresa foi fundada por Diogo Almeida (ex-pesquisador da OpenAI, que trabalhou em RLHF, InstructGPT, ChatGPT e GPT-4) junto com Erik Gafni e Sasha Sheng

Tome cuidado com os números de marketing que circulam por aí: a TypeSafe fala em até 193,6x mais rápido e 444,6x mais barato em pico frente a LLMs, mas isso vem de workflow evals internas, montadas pelo time deles, e a própria empresa registra que esses valores estão na ponta alta do ganho do mundo real

Ou seja: serve como sinal de direção, não como promessa de fatura

Jev x classificador próprio: comparação por critério

Repara numa linha específica: o alias que se move

Um alias é um nome que resolve para um ID de modelo versionado, e ele avança quando entra um novo release

E aqui vale desfazer uma confusão comum: estável NÃO é sinônimo de congelado. O jev-latest é o canal estável (o oposto do canal de preview), só que ele continua se movendo quando sai release novo. Na prática isso significa que a resposta pode mudar sem nenhuma alteração do seu lado. Quem quer resposta parada no tempo usa o ID versionado, não o alias

Já me ferrei uma vez com dependência que "atualizou sozinha" em produção, e não foi nem com IA. Guarda essa

Quatro cenários reais e qual caminho faz sentido em cada um

1. Triagem de tickets com regra que muda toda semana

Aqui o classificador próprio sofre e o motivo é estrutural

Cada vez que o time de suporte inventa uma categoria nova ou muda o critério de urgência, teu dataset envelhece. Tu não muda o modelo, tu muda os rótulos e roda tudo de novo

No caminho do schema tipado, mudar a regra é mudar a pergunta. Um Choice com a lista nova, um Noul a mais pra flag de urgência, e segue o jogo

Esse tipo de triagem costuma viver dentro de um fluxo automatizado, e aí a lógica de decisão é a mesma de quando você escolhe entre n8n e Zapier pra orquestrar: o que dói não é a ferramenta, é o custo de mexer quando a regra muda

Veredito do cenário: decisão tipada ganha, por causa do custo de mudança

2. Moderação em domínio muito específico com milhões de exemplos rotulados

Cenário oposto, e aqui eu não venderia migração nenhuma

Se você já tem milhões de exemplos rotulados num domínio fechado, você tem o ativo mais caro dessa história inteira. Esse dataset codifica nuance que nenhum modelo genérico viu

E tem um detalhe que pesa: o Jev não é ajustado por cliente, não tem fine-tuning nem LoRA com seus dados. Os mesmos pesos servem todas as contas

Então o que te diferencia hoje continua morando no seu modelo

Veredito do cenário: fica com o seu. No máximo, use a decisão tipada como segunda opinião em casos de baixa confiança

3. Pipeline novo, sem dataset, precisando rotear e enriquecer dados

Esse é o clássico do "nem existe rótulo ainda"

Você precisa decidir pra onde vai cada registro, marcar dois ou três atributos e seguir. Treinar classificador aqui é começar pelo fim: sem dado rotulado, não tem treino

A rota do schema tipado te dá saída imediata e, de quebra, o fluxo começa a gerar dados de decisão que você pode auditar depois. Se um dia fizer sentido treinar algo próprio, você vai ter histórico

Veredito do cenário: começa pelo modelo pronto, sem dúvida

4. Decisão que depende de data ou de magnitude numérica exata

Agora a parte que a TypeSafe tem a honestidade de publicar

A própria empresa mantém uma página de fraquezas conhecidas do jev-1.13, e tem três pontos ali que mudam decisão de arquitetura:

• ele é literal: responde a pergunta que você escreveu, não a que você quis escrever
• a calibração numérica dos níveis de Score é fraca, então não dá pra reconstruir magnitude exata por interpolação
• ele lê datas como texto, o que torna comparação, distância e janela de datas não confiável

Se a sua regra é "vencido há mais de 30 dias" ou "diferença de valor acima de X", isso não é trabalho de modelo nenhum, é trabalho de código

Calcula a data e o delta no seu backend, entrega o resultado já pronto dentro do state, e deixa pro modelo só a parte de julgamento

Veredito do cenário: não delega aritmética e calendário. Pré-processa e só depois pergunta

Veredito: o critério simples de decisão

Quatro perguntas resolvem a maior parte dos casos

1. Você tem dataset rotulado de verdade? Se não tem, treinar não é uma opção, é um projeto
2. Suas regras mudam em semanas ou em anos? Semanas puxam pra schema editável. Anos sustentam modelo próprio
3. Você precisa de saída em schema fixo? Se parsing quebrado te acorda de madrugada, o tipo restrito resolve o problema na raiz
4. A decisão depende de data, magnitude exata ou nuance implícita? Então parte disso sai do modelo e vai pro seu código, independente do caminho escolhido

O custo escondido de cada lado

Do lado do classificador próprio, o custo escondido não é o treino, é o depois: pipeline de retreino, drift silencioso, rotulagem que nunca acaba e a pessoa que sabe mexer naquilo pedindo demissão

Do lado do Jev, o custo escondido é dependência de fornecedor num produto em early access, mais o alias que pode passar a resolver para outra versão quando entra um novo release

E tem um terceiro, que a documentação faz questão de deixar claro: calibração é propriedade de grupo. Ela vale sobre muitas previsões e não garante que aquela resposta individual esteja correta

Traduzindo: probabilidade boa no agregado não é selo de acerto no caso isolado. Desenha teu fluxo contando com isso

Se reprodutibilidade importa no teu produto, fixa jev-1.13.0 em produção e deixa jev-latest pro ambiente onde tu testa versão nova antes de promover. É a mesma disciplina de pinar versão de dependência, nada de novo debaixo do sol

Quando a escolha é de ferramenta, não de modelo

Escolher caminho técnico é uma habilidade por si só, e ela aparece em todo lugar: na hora de decidir entre Claude Code e Cursor, na hora de escolher stack e agora na hora de decidir se você treina ou consome uma decisão tipada

Pra quem tá começando a pensar nesse tipo de bifurcação de carreira e de projeto, esse vídeo do canal mostra como funciona o raciocínio de escolher um caminho entre dois que parecem igualmente válidos

Próximo passo

Se tu quer colocar a mão, hoje o caminho é a lista de espera do acesso antecipado

Ou os gateways de terceiros, onde o modelo aparece como typesafe/jev: ele está listado no Vercel AI Gateway e no Cloudflare Workers AI

E a sugestão de sempre, que vale pra qualquer modelo novo: escolhe uma decisão pequena e mensurável do teu fluxo, roda em paralelo com o que já existe hoje e compara contra o teu baseline atual

Nada de migrar fluxo crítico no hype 😛

Com a lista de perguntas lá de cima e a página de fraquezas conhecidas na mão, dá pra decidir com bastante clareza qual dos dois caminhos serve pro teu caso

Até o próximo post!