O que é o Jev e como aplicá-lo: o modelo de julgamento da TypeSafe

O Jev é o modelo de julgamento da TypeSafe, o que a empresa chama de modelo System One: uma IA que não gera texto, mas responde a perguntas fechadas e devolve probabilidades. Existe para resolver a pergunta que surge em quase todos os projetos de IA que encalham e que quase nunca se formula em voz alta: quem decide. Não quem escreve o prompt nem quem escolhe o modelo. Quem decide se este ticket escala, se esta fatura passa, se este pedido continua.

Durante três anos, a resposta por omissão tem sido pedir a um modelo generativo que devolva um JSON com a decisão lá dentro e confiar que o formato aguente. Costuma aguentar. O que não aguenta é a auditoria.

O Jev é a proposta contrária, e o nome não é decorativo: System One remete para o pensamento rápido, aquela resposta que uma pessoa com critério dá num segundo sem precisar de deliberar. Em vez de prosa, devolve uma distribuição de probabilidade sobre as opções definidas antecipadamente. A versão em vigor é o jev-1.13 e a documentação das primitivas é a fonte de tudo o que se segue.

Três formas de resposta, e nenhuma mais

Essa é toda a superfície do modelo. A brevidade é deliberada.

• Choice: a resposta é uma de um conjunto conhecido e sem ordem interna, como a categoria de um ticket. O código atua com um ramo por opção.
• Score: a resposta é uma posição num espetro que se pode descrever por níveis, como a gravidade de uma incidência. O código atua com um limiar, uma ordenação ou um peso.
• Noul: a resposta é um sim ou um não limpos, e o que interessa é a probabilidade, não a etiqueta. O código atua com um if.

As três devolvem sempre algo que o código consome sem ter de interpretar prosa, que é a propriedade que verdadeiramente importa aqui, porque elimina de uma vez todo o estrato defensivo de leitura, repetições e validação de formato que acompanha qualquer integração séria com um modelo generativo. Um Choice devolve a opção escolhida, as probabilidades de todas e uma confiança. Um Score devolve a média ponderada dos níveis. Um Noul devolve um número entre zero e um.

A regra de desenho que ordena todo o resto cabe numa frase: uma boa pergunta para o Jev é uma que uma pessoa com conhecimento responderia num segundo se tivesse o contexto certo à frente. Esta mensagem transmite urgência? Vale. Analise esta mensagem e decida o que fazer, não vale. Isso segundo não é uma pergunta. É uma incumbência, e há que parti-la em perguntas pequenas e recompor as respostas no código.

A diferença para pedir a decisão a um LLM

Está no sítio onde vive a política. Soa a pormenor de arquitetura. É o que decide se o sistema pode ser auditado seis meses depois.

Quando se pede a um modelo generativo que classifique e decida, a regra de negócio acaba escrita dentro do prompt, misturada com a instrução, o formato de saída e as exceções que foram sendo acrescentadas ao longo do tempo. Mudar um limiar significa então reescrever um parágrafo em prosa e voltar a avaliar tudo do zero, sem qualquer garantia de que a mudança não tenha deslocado à mesma o comportamento de outros três casos que ninguém estava a ver, e o resultado é que ninguém sabe com certeza o que faz o sistema, porque o sistema é um texto.

A divisão do Jev é explícita: o modelo aporta o julgamento, o código fica com o controlo de fluxo, a aritmética e a política. Os pesos e os limiares vivem no código. A documentação insiste num ponto que vale sublinhar porque contraria o instinto de quase toda a gente: quando a decisão final está errada mas cada resposta individual está certa, o que está mal é a política, por isso mudam-se os pesos e deixam-se as perguntas em paz.

Há um segundo contraste, menos filosófico e mais operacional. O Jev não conta. Também não soma, nem compara datas. A documentação di-lo sem rodeios e oferece o padrão de substituição: para contar elementos lança-se um Noul por elemento no mesmo pedido e somam-se no código as respostas que ultrapassam o limiar. Quem já viu um modelo generativo falhar uma contagem de sete linhas reconhece o problema de imediato.

Quatro padrões que cobrem quase tudo

O primeiro é o fan-out especulativo. Todas as perguntas que partilham o mesmo estado viajam num único pedido, incluídas as que só importam nalguns ramos. São respondidas em paralelo, por isso perguntar a mais acrescenta pouquíssima latência e pouquíssimos tokens ao custo total do pedido, e o código simplesmente ignora as respostas de que não precisa nesse ramo concreto. Um segundo pedido só se justifica quando a resposta do primeiro determina que dados ir buscar.

O segundo é o encaminhamento por confiança, e é o que mais se parece com dirigir uma equipa. A resposta dita o quê. A confiança determina se há ação.

Esses valores são os que a documentação da confiança usa como ponto de partida, com a instrução explícita de começar conservador e de os ajustar contra os dados próprios.

O terceiro é o scoring composto. Um julgamento complexo, desses que numa reunião se resolvem dizendo que depende, parte-se num Score por cada dimensão que realmente pesa na decisão, cada um normaliza-se pelo seu número de níveis e depois combinam-se com os pesos que se fixam no código. Quando as prioridades do negócio mudam, mexe-se num peso. Não se reescreve uma pergunta.

O quarto é o percurso da taxonomia: um Choice por cada nível da árvore, percorrido no código, dando a cada opção como critério o que dela pende para que o modelo veja o que está por baixo de cada ramo antes de a escolher, e seguindo mais de um ramo ao mesmo tempo quando as probabilidades saem parecidas.

Donde sai esse estado é uma decisão à parte, e há equipas que a resolvem pondo Model Context Protocol à frente, para que o contexto chegue já filtrado dos sistemas que o têm.

Convém dizer também o que nenhum dos quatro resolve. Se a precisão cai quando crescem os dados de entrada, o problema é que o estado transporta detalhe irrelevante e há que filtrá-lo antes no código. Se uma pergunta reformulada troca um erro por outro, essa pergunta está a pesar duas propriedades ao mesmo tempo e há que parti-la. E o estado não é tratado como hostil por defeito: o texto que se manda pode orientar a resposta, por isso os casos adversários testam-se antes de se avançar para produção.

O que muda para o talento tech que colabora em projetos

Surge uma capacidade nova, e não é saber usar uma ferramenta. Essa distinção separa quem é pago à hora de quem é pago pelo critério.

Desenhar um programa Jev são cinco passos, e nenhum se resolve escrevendo prompts mais longos:

1. Enumerar as decisões que o sistema tem de tomar, cada uma como ramo, limiar ou ordenação.
2. Escrever uma pergunta atómica por julgamento, e partir qualquer uma que pese duas propriedades.
3. Escolher a primitiva segundo o que o código vai fazer da resposta.
4. Construir o estado mínimo que responde a todas, calculando no código o que o código puder calcular.
5. Compor as respostas no código: ramos, pesos e portas de confiança.

Isso é análise de decisão e desenho de sistema. É um músculo de engenharia, não de redação, e é continuidade direta do que já exige montar um agente de IA do princípio ao fim: a diferença é que aqui a parte de julgamento deixa de estar escondida dentro de um prompt e passa a ser uma peça que se pode mostrar, medir e defender.

A parte mais subestimada é a avaliação. A documentação é categórica: revê-se uma ou duas perguntas por iteração, nunca mais, porque as probabilidades movem-se de formas difíceis de antecipar, e nenhuma revisão se dá por boa sem dados etiquetados atrás. Uma confiança mais alta, por si só, não demonstra que a pergunta tenha melhorado. Quem souber montar esse banco de provas, escolher os casos que verdadeiramente discriminam e defender os resultados perante um comité que pergunta pelo risco antes que pela tecnologia, tem um argumento comercial que quase ninguém consegue ainda sustentar com a evidência em cima da mesa.

O mercado português dá uma pista de para onde vai isto, embora ainda não nomeie o Jev. Segundo a análise de mercado da Shakers, 469 das 21 658 ofertas tech com skills etiquetadas em Portugal nomeiam LangChain, contra 7 112 que nomeiam Python (n=25 012 ofertas ativas, 21 658 com skills etiquetadas, de junho a outubro de 2026). A orquestração de modelos já tem procura declarada e nome próprio dentro do texto das ofertas, que é o primeiro sítio onde uma capacidade nova se torna visível antes de alguém lhe pôr etiqueta formal num catálogo de funções. A camada de julgamento dentro dessa orquestração é a peça que ainda não tem etiqueta.

Esse número mede menções no texto das ofertas, não requisitos contrastados um a um. E o denominador honesto é o das ofertas com skills etiquetadas, não o corpus inteiro, porque o resto não tem skills atribuídas e contá-lo inflacionaria a percentagem.

O que muda para uma empresa

A pergunta de comité deixa de ser qual é o melhor modelo. Passa a ser outra: que decisões estamos a delegar, e com que limiar. Isso é governação, não compras, e é a conversa que falta na maioria das implementações de agentes de IA nas empresas.

Três consequências práticas. A política torna-se legível, porque os limiares estão no código e versionados como qualquer outra decisão de engenharia, pelo que se pode responder com exatidão, com o histórico à frente, ao que foi automatizado, sob que condição e a partir de que data exata. Surge um caminho de saída desenhado e não improvisado, porque o encaminhamento por confiança obriga a definir desde o início o que acontece quando o modelo não está seguro, que é exatamente o cenário que as demonstrações nunca mostram. E baixa o custo de mudar de ideias: se amanhã o negócio decidir que a gravidade pesa mais do que a urgência, isso é um peso numa linha de código.

Vale a pena situar isto no problema de fundo. O estudo da BCG sobre mais de 1 250 empresas cifra o fosso sem rodeios: só 5% obtém valor à escala e 60% não obtém valor material apesar de um investimento substancial (BCG, setembro de 2025). Boa parte desse implementation gap não é um problema de modelo. É que ninguém definiu que decisão se estava a automatizar, nem com que confiança mínima, nem quem responde quando a resposta é duvidosa.

Um modelo de julgamento não resolve isso sozinho. Obriga a escrevê-lo, que é bastante mais do que conseguem a maioria das ferramentas, e o padrão repete-se em qualquer sistema que chega a produção a sério: o mesmo passa ao levar uma arquitetura RAG a produção, em que a recuperação raramente é o estrangulamento e o que falha é não se ter decidido o que fazer com o que foi recuperado.

Os limites, antes de os descobrir em produção

• Não gera texto. Se é preciso uma resposta redigida, isso é outro modelo. O Jev fica à frente para decidir qual, ou atrás para verificar o que saiu.
• Não raciocina por passos. Um problema que exige encadear três inferências parte-se em três perguntas literais e une-se no código.
• Não faz aritmética, contagens nem comparação de datas. Para datas, o padrão documentado é extrair cada parte com um Choice sobre opções enumeradas, incluindo uma para o caso de não constar, e montar e comparar no código.
• A sua escala não é uma magnitude contínua. Um Score de 1,0 pode significar certeza no nível 1 ou um empate entre os níveis 0 e 2, por isso leem-se as probabilidades a par do número e usa-se o resultado para aplicar um limiar ou para ordenar, nunca para deduzir uma quantidade.
• O contexto tem teto. O estado e todas as perguntas partilham 64 000 tokens, e o estado mais a pergunta mais longa têm de caber em 32 000.

Tudo isto está descrito para o jev-1.13. A própria documentação avisa que vários destes limites mudarão em versões posteriores, por isso a página das irregularidades do modelo volta a ler-se sempre que a versão mudar. Não uma única vez ao começar.

Por onde começar esta semana

Começa-se por uma decisão que hoje uma pessoa toma de forma repetitiva, muitas vezes por dia e quase sempre da mesma maneira, e cujo critério se saiba descrever numa só frase sem recorrer a um esquema nem a uma exceção que só conhece quem leva cinco anos na equipa. A decisão escreve-se por extenso como pergunta fechada. A primitiva escolhe-se segundo o que o código vai fazer da resposta, que é o critério de seleção e não a elegância do formato. Juntam-se trinta casos já resolvidos com a resposta correta, passam-se pelo modelo e veem-se as probabilidades dos falhanços.

Se o modelo falha com confiança alta, quase sempre é porque leu a instrução de forma estritamente literal, atendendo a cada palavra que foi escrita e a nenhuma das que se davam por supostas, enquanto se queria dizer algo ligeiramente diferente que nunca chegou a ser escrito. A explicação que se daria ao ver esse erro é, literalmente, a metade que faltava da instrução: escreve-se dentro dela.

Perguntas frequentes sobre o Jev

O Jev substitui um LLM generativo?

Não. Cobre uma função diferente: decidir entre opções definidas por quem o usa, não produzir texto. O habitual é combiná-los, com o Jev a classificar e a decidir a rota à frente, e um modelo generativo a redigir atrás quando é preciso redigir.

O que é um Noul?

Uma das três primitivas de resposta do Jev. Devolve um número entre 0 e 1 para uma condição que admite um sim ou um não limpos, e o sinal está na própria probabilidade. Um 0,5 significa que o modelo não está seguro, não que a resposta seja intermédia. Para medir um grau usa-se um Score.

Pode auditar-se uma decisão tomada com o Jev?

Mais do que uma tomada dentro de um prompt. As perguntas, os critérios de cada opção, os limiares e os pesos são artefactos de código versionados, e cada resposta traz a sua distribuição de probabilidade completa.

Quantas perguntas convém mandar juntas?

Todas as que partilhem o mesmo estado, num único pedido, incluídas as que só se usam nalguns ramos. São respondidas em paralelo, por isso perguntar a mais acrescenta pouca latência e poucos tokens.

Há procura disto no mercado português?

Da camada de orquestração, sim e com nome próprio: 469 das 21 658 ofertas tech com skills etiquetadas nomeiam LangChain, segundo a análise de mercado da Shakers (n=25 012 ativas, de junho a outubro de 2026). Do Jev em concreto, ainda não: é um modelo recente e nenhuma oferta o nomeia.