Modelo de IA Jev explicado | System One AI, como funciona e aplicações reais | Ele vai substituir os LLMs?

Autoria: At A Glance! · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: JEV AI Model Explained | System One AI, How It Works & Real-World Application | Will it replace LLM? · Canal: At A Glance! · 17:16 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos de IA, RAG, busca e recuperação de informação

Resumo

O vídeo apresenta Jev como um modelo voltado a decisões estruturadas e probabilísticas, em vez da geração de texto livre típica de um LLM. Jev recebe um estado e uma pergunta tipada, e retorna decisões como sim ou não, uma opção entre alternativas ou uma pontuação; o código da aplicação decide e executa a ação seguinte. O vídeo mostra possíveis usos em roteamento, seleção de ferramentas e avaliação de relevância em pipelines RAG, além de comparar Jev com JSON mode e apresentar alegações de desempenho e custo. Também ressalta limitações, como decisões incorretas, probabilidades que não garantem segurança e a necessidade de revisão humana em casos de risco. A conclusão é que Jev complementa os LLMs, mas não é necessariamente um substituto: cada componente pode ser usado para a tarefa mais adequada.

Pontos-chave

Jev foi apresentado como um modelo para decisões definidas, com saídas estruturadas e probabilidades.
O fluxo separa o estado fornecido, a pergunta tipada, a decisão do modelo e a ação executada pelo código.
As três primitivas de decisão descritas são null, choice e score.
Possíveis aplicações incluem classificação, roteamento, seleção de ferramentas, guardrails e validação de trechos recuperados em RAG.
Ao contrário do JSON mode, Jev usa um espaço de respostas definido previamente, segundo a apresentação.
O vídeo reporta latência de 70 a 500 milissegundos e alegações de preço e desempenho atribuídas à TypeSafe AI; esses números não são apresentados como universais.
LLMs são indicados para geração de linguagem e tarefas abertas; Jev, para decisões delimitadas; e o código, para lógica determinística e execução.
As probabilidades de Jev não garantem que uma decisão esteja correta ou que uma ação seja segura.
Em ações de alto risco, o sistema pode encaminhar casos para revisão humana.
A mensagem final é que Jev pode complementar os LLMs, em vez de substituí-los.

Capítulos

Início	Capítulo	Resumo
00:02	O que é Jev e qual problema pretende resolver	O vídeo introduz Jev como uma alternativa para decisões estruturadas, distinguindo sua saída de uma explicação livre de um LLM.
03:09	Fluxo de trabalho e primitivas de decisão	A apresentação explica como Jev recebe um estado e uma pergunta tipada e descreve as primitivas null, choice e score.
06:19	Velocidade e aplicações em agentes e RAG	São apresentados dados de latência e exemplos de uso de Jev para avaliar decisões em fluxos com ferramentas e informações recuperadas.
09:26	JSON mode, avaliações, preço e desempenho	O vídeo compara Jev com JSON mode e apresenta resultados de avaliação e alegações de custo e velocidade, com ressalvas sobre seu alcance.
13:06	Casos de uso, limitações e conclusão	A apresentação delimita os usos de Jev, ressalta riscos e revisão humana e conclui que o modelo complementa, mas não necessariamente substitui, os LLMs.

Citações

A aplicação fornece informações. Jev responde a uma pergunta definida, e o código usa essa resposta para executar a ação. — 01:06

Essas primitivas representam três perguntas diferentes: é verdade? Qual opção? Quanto ou com que intensidade? — 05:17

O objetivo é usar cada um desses componentes para a tarefa que foi projetado para realizar. — 13:38

Jev não é necessariamente um substituto para um LLM. É uma interface diferente para a inteligência. — 15:41

Conceitos e entidades

Jev (modelo): Modelo descrito no vídeo como especializado em decisões estruturadas e probabilísticas.
System One AI (conceito): Abordagem apresentada no vídeo para decisões delimitadas, em contraste com a geração sequencial de texto.
LLM (conceito): Modelo de linguagem usado, entre outras coisas, para gerar texto e planejar etapas de um fluxo.
null, choice e score (conceito): Primitivas citadas para responder a perguntas de sim ou não, escolher entre opções e atribuir uma pontuação.
RAG (conceito): Fluxo que recupera informações para apoiar uma resposta gerada, no qual Jev pode avaliar a relevância de trechos.
JSON mode (conceito): Modo que solicita a um modelo de linguagem uma saída em texto estruturado, cuja validade ainda pode exigir verificações.
TypeSafe AI (empresa): Empresa à qual a apresentação atribui as alegações publicadas de preço e desempenho de Jev.

Tradução completa (pt-BR)

00:02 [música] Olá, pessoal, sejam bem-vindos de volta ao meu canal no YouTube. Neste vídeo, vamos analisar o modelo Jev. Então, vamos começar entendendo o que o Jev faz. Este slide compara uma pergunta típica que poderíamos fazer a um LLM: “O que devo fazer com o chamado?”. Vocês podem ver essa pergunta: “O que devo fazer com este chamado?”, comparada ao tipo de decisão direta que o Jev pode produzir.

00:33 Em vez de gerar uma explicação em texto livre, como um LLM faz, o Jev pode retornar resultados estruturados. Por exemplo, vocês podem ver que o resultado é uma rota, que é cobrança, e também foi fornecida uma probabilidade de 0,91. Isso significa que a rota selecionada é cobrança, com uma probabilidade de 91%. O workflow mostrado aqui é: estado, que vai para o modelo Jev. Em seguida, ele fornece uma decisão tipada, e então o código executa

01:06 a ação. Em palavras simples, a aplicação fornece informações. O Jev responde a uma pergunta definida, e o código usa essa resposta para executar a ação. Essa é a ideia central do Jev. O Jev foi projetado especificamente para decisões de software rápidas, estruturadas e respaldadas por probabilidades, em vez de conversas comuns. Espero que vocês já tenham uma visão geral do que exatamente é o Jev. Observem o problema ilustrado neste slide. Em muitas

01:37 aplicações, fornecemos informações a um LLM e recebemos texto gerado. Analisamos esse texto, validamos e, então, executamos a ação necessária. Para uma decisão simples, isso pode introduzir etapas desnecessárias. A saída pode ter problemas de formatação. Talvez seja necessário tentar novamente ou ela pode gerar uma incerteza que a aplicação tem dificuldade para tratar de forma consistente. Por exemplo, se a aplicação só precisa selecionar uma rota, gerar uma resposta de texto completa e depois extrair a rota pode dar mais trabalho do que o

02:09 necessário. Uma instrução if é uma construção de programação que executa uma ação específica quando uma condição é satisfeita. O argumento do slide é que alguns workflows de IA usam um LLM para decisões que poderiam ser tratadas de forma mais direta. Este slide compara duas abordagens: LLMs que priorizam o chat e modelos System 1, como o Jev. Um LLM que prioriza o chat se concentra em gerar linguagem. Sua saída costuma ser produzida por meio da geração sequencial de

02:39 tokens. O Jev, por outro lado, foi projetado para retornar saídas orientadas à decisão, como opções predefinidas, pontuações e probabilidades. Essa comparação também destaca a diferença entre texto flexível e valores tipados que o software pode consumir, assim como entre a confiança expressa por meio de um prompt e as probabilidades retornadas como parte da decisão. Por exemplo, uma abordagem pode explicar uma reclamação, enquanto a outra seleciona uma questão.

03:09 A principal conclusão é que esses modelos têm prioridades de design diferentes. O Jev foi feito para lidar com decisões definidas, enquanto um LLM continua sendo útil para gerar linguagem de forma flexível. Espero que vocês estejam entendendo essa abordagem System 1. Agora, vamos dar uma olhada no workflow completo do Jev. Primeiro, fornecemos um estado. Pode ser um chamado, um trecho de texto recuperado, um documento, dados em JSON ou o estado atual de um agent de IA. Em seguida, definimos a pergunta tipada. O Jev avalia essa pergunta

03:42 com base no estado fornecido e retorna a decisão estruturada. Por fim, o código da aplicação usa esse resultado para encaminhar a solicitação, filtrar informações, continuar um workflow ou enviar um caso para revisão. Observem que o Jev não aparece executando sozinho a aplicação inteira. Ele fornece a decisão, enquanto o código determina qual ação vem em seguida. Essa separação é importante porque permite manter distinto o papel do Jev na tomada de decisões da lógica de execução da aplicação. Por exemplo, vocês podem ver o estado: o cliente foi cobrado duas vezes

04:13 e quer um reembolso. Agora, o Jev pode identificar exatamente para qual fila o caso deve ser encaminhado, qual é o nível de urgência e se é necessário encaminhá-lo para uma pessoa ou não. Então, é assim que o Jev funciona para decisões. Espero que estejam entendendo. Agora, vamos dar uma olhada nos três primitivos de decisão do Jev: bool, choice e score. O primeiro é bool. Bool responde a uma pergunta de sim ou não. Por exemplo: “Isto é verdade?”. A saída

04:45 será sim ou não. Digamos que a resposta seja sim; então, ele retornará sim, junto com a probabilidade de a resposta estar correta, que é 94%. O segundo é choice. Entre as opções fornecidas, qual tem maior probabilidade de estar correta? Choice seleciona entre alternativas predefinidas. No exemplo de encaminhamento, cobrança tem uma probabilidade de 0,82. Suporte técnico tem probabilidade de 0,13 e vendas, de 0,05. Assim, vocês podem ver como ele fornece a probabilidade de todas as opções definidas.

05:17 O terceiro é score. Score avalia algo em uma escala ordenada. Aqui, a urgência é representada por uma pontuação de 8,2 em 10, junto com informações de confiança. Esses são os três primitivos de decisão usados no Jev. Vamos ver um exemplo. A mensagem do cliente reúne três ideias. O cliente percebe que foi cobrado duas vezes e, então, diz que precisa receber o dinheiro de volta hoje. O sistema pode selecionar a rota adequada, avaliar a urgência e determinar se é necessário encaminhar o caso para uma pessoa.

05:48 Esses primitivos representam três perguntas diferentes: é verdade? Qual opção? Quanto ou com que intensidade? Espero que vocês tenham entendido os três primitivos diferentes usados no Jev. Por que o Jev é rápido? Como sabemos, um LLM convencional geralmente gera os tokens de saída sequencialmente, um de cada vez. O Jev foi projetado para produzir suas saídas de decisão sem o mesmo processo de decodificação de tokens de saída em texto livre. A

06:19 apresentação informa uma latência de ponta a ponta de 70 a 500 milissegundos. Latência é o tempo necessário para retornar um resultado. O exemplo mostra uma decisão estruturada que contém informações como a rota selecionada e a urgência, em vez de uma explicação longa. Isso pode ser vantajoso quando uma aplicação precisa tomar decisões com frequência e agir imediatamente com base nelas. No entanto, a latência informada deve ser entendida no contexto da carga de trabalho e da infraestrutura testadas. Ela não é uma garantia para todas as aplicações. Espero

06:51 que vocês tenham entendido. Espero que agora saibam por que ele pode ser tão rápido. Vamos acompanhar o workflow do agent mostrado à esquerda. Um usuário envia uma solicitação. O LLM planeja o que fazer, e o Jev verifica uma decisão antes de o workflow continuar. Em seguida, a aplicação determina se deve usar uma ferramenta, continuar ou realizar outra ação permitida. Depois que a ferramenta escolhida é executada, o Jev pode avaliar o resultado, e o LLM pode preparar a

07:21 resposta para o usuário. Este exemplo mostra o LLM propondo a ferramenta de reembolso. O Jev avalia se a ferramenta é adequada, enquanto o código realiza a execução. A lista à direita mostra possíveis usos do Jev: seleção de ferramentas, encaminhamento, guardrails, pontuação de relevância, encaminhamento para revisão e ramificações de workflow. Um guardrail é um controle que ajuda a evitar ações inadequadas. A distinção importante é que o Jev pode ajudar na decisão, mas a aplicação ainda precisa impor as regras de permissão e execução. Por exemplo, se usarmos um LLM, ele dirá: “Eu

07:53 devo chamar a ferramenta de reembolso”. Mas, se usarmos o Jev, ele dirá se essa ferramenta de reembolso é adequada, também com uma probabilidade. E, de acordo com isso, o código executa a ferramenta. Espero que vocês tenham entendido como o Jev pode ser usado dentro de um agent de IA e como ele pode ser melhor do que usar um LLM para tool calling ou execução. Agora, vamos ver um exemplo real. Este slide demonstra como o Jev pode funcionar como uma etapa de decisão em um pipeline de RAG. Aqui, vocês podem ver que o processo começa com uma consulta do usuário. Um

08:24 retriever busca informações relevantes e retorna os trechos recuperados, como acontece em um RAG. Em seguida, o Jev avalia se o trecho recuperado dá suporte à pergunta do usuário. Assim, ele funciona como uma etapa de decisão. O trecho de exemplo diz que a política permite reembolsos em até 30 dias. A pergunta é se esse trecho dá suporte à pergunta do usuário sobre reembolso. O slide mostra o resultado como “sim”, com uma probabilidade de 93%. Agora, dependendo

08:55 do resultado, o workflow pode gerar uma resposta, recuperar informações novamente ou pedir esclarecimentos ao usuário. Aliás, espero que vocês saibam o que é RAG. É geração aumentada por recuperação: recuperar informações relevantes para dar suporte a uma resposta gerada por IA. O motivo pelo qual o Jev se encaixa aqui é que a verificação de relevância é uma decisão limitada. O sistema pode usar a probabilidade para ajudar a controlar o workflow, em vez de tratar automaticamente cada trecho recuperado como útil. Espero que este exemplo tenha deixado claro como o Jev pode ser útil em casos de uso cotidianos de IA generativa.

09:26 Agora, o que torna o Jev diferente do modo JSON? Se vocês não sabem, o modo JSON pede que um modelo de linguagem produza texto estruturado. O exemplo contém uma rota e um valor de confiança. Como podem ver, a rota é cobrança e o valor de confiança é 0,91. Mesmo quando a saída parece um JSON válido, a aplicação ainda pode precisar verificar o esquema, validar os valores ou tentar novamente se a saída não for adequada. O Jev

09:56 em vez disso, usa uma pergunta tipada com um espaço de resposta definido previamente. Por exemplo, digamos que as raízes permitidas sejam faturamento, suporte técnico e vendas. Aqui, o Jev não pode gerar uma quarta raiz, como sucesso do cliente. Essa é a principal ideia por trás do uso do Jev e do que o diferencia do modo JSON. Se usarmos o modo JSON nos bastidores, estaremos usando apenas um LLM, e o LLM pode gerar resultados vagos a qualquer momento e talvez gerar um JSON inválido. Então, todos esses problemas desaparecem quando usamos o Jev. Espero que

10:27 vocês tenham entendido também a diferença entre o modo JSON e o Jev. Este slide apresenta resultados de uma avaliação independente do Jev, identificada na apresentação como um estudo de arquivo de setembro de 2026. Ela abrange 13 conjuntos de dados e 346.009 solicitações. Os números de acurácia zero-shot exibidos são 95% no ARC, 96% no HellaSwag, 97% no SST-2 e 97% no IMDb. Para

11:00 o Belebele, a apresentação relata 86,7% de acurácia em 122 idiomas. Este slide também informa que o Jev superou o modelo Qwen 3.8 de 27 bilhões de parâmetros em 27 dos 37 conjuntos de dados e o modelo Gemma 4 E4 de 4 bilhões de parâmetros em todos os 37 conjuntos de dados daquela avaliação. Zero-shot significa que o modelo é avaliado sem exemplos específicos da tarefa no prompt. Esses

11:31 resultados abrangem diferentes tarefas, incluindo classificação, roteamento, leitura, compreensão, moderação e pontuação por rubrica. São resultados encorajadores da avaliação apresentada, mas não devem ser tratados como uma classificação universal de modelos de IA. Agora, vamos falar sobre velocidade e custo. Este slide apresenta as alegações publicadas pela TypeSafe AI sobre preço e desempenho. O preço exibido é de 0,042 por milhão de tokens de entrada, e os tokens de saída são indicados como gratuitos. A latência de ponta a ponta informada é de

12:03 70 a 500 milissegundos. Também há uma alegação de que é 193,6 vezes mais rápido e 446,6 vezes mais barato do que uma avaliação de workflow de um fornecedor. Por que isso importa? Pense em uma decisão de roteamento repetida milhões de vezes. Mesmo uma pequena diferença no tempo de resposta ou no custo pode se tornar importante nessa escala. No entanto, o slide ressalva explicitamente que esses multiplicadores são resultados das avaliações de workflow da própria TypeSafe AI. Eles não são resultados universais de benchmark.

12:35 Ao avaliar um modelo para produção, devemos comparar a mesma carga de trabalho, medir a latência de ponta a ponta e calcular o custo real da aplicação completa. Onde o Jev se encaixa e onde não se encaixa? Neste slide, à esquerda, temos os casos em que ele se encaixa bem; à direita, os casos em que não é a ferramenta principal. Basicamente, você pode usar o Jev para classificação, roteamento, pontuação, guardrails, seleção de ferramentas, triagem, verificação e pontos de decisão em tempo real. Você pode simplesmente usar o Jev em todos esses componentes. Mas, quando

13:06 se trata de escrever textos longos, lidar com conversas abertas, fazer geração criativa, produzir explicações longas, realizar cálculos exatos ou executar tarefas de raciocínio sem restrições, o Jev não é a ferramenta certa. O diagrama na parte inferior combina três componentes. O LLM gera e raciocina. O Jev decide e controla o fluxo, e o código lida com a lógica determinística. Isso significa que não precisamos escolher apenas um modelo para a aplicação inteira. Por exemplo, um LLM

13:38 pode gerar uma resposta, o Jev pode selecionar uma categoria e o código pode aplicar as regras de negócio. O objetivo é usar cada um desses componentes na tarefa para a qual foi projetado. Espero que estejam entendendo. Agora, vamos também dar uma olhada nas limitações que vocês devem conhecer ao usar o Jev. Claro, o Jev não é uma IA sem erros. Nenhuma IA é livre de erros. Vocês devem saber onde ele falha ou onde pode falhar. Primeiro, o Jev pode tomar decisões incorretas, com certeza. Sim, decisões erradas são possíveis. A probabilidade que vocês obtêm não é garantida,

14:08 seja qual for. Segundo, as probabilidades precisam ser interpretadas com cuidado. Uma probabilidade de 0,90 não significa automaticamente que uma ação é segura. Terceiro, perguntas ou opções de resposta mal elaboradas podem levar a decisões ruins. Vocês precisam ter isso em mente. Quarto, o desempenho também pode variar conforme a tarefa, especialmente em idiomas com poucos recursos, entradas ruidosas e avaliações baseadas em rubricas. Além disso, vocês precisam se lembrar de que o Jev é um modelo fechado, disponibilizado

14:38 por meio de uma API gerenciada, com pesos que não são públicos, e de que suas evidências públicas e seu ecossistema ainda estão em desenvolvimento. Vejam o exemplo do pagamento. Mesmo que o Jev retorne “pagamento aprovado” com 97% de probabilidade, isso não autoriza automaticamente o pagamento. É aqui que entra a distinção entre um fluxo automatizado de alta confiança e um fluxo de baixa confiança ou alto risco, que exige revisão humana. Espero que tenham entendido. Este slide contrasta duas

15:09 abordagens. A primeira é pedir a um modelo de IA que faça tudo. A segunda é usar o componente adequado para cada etapa. O diagrama mostra o workflow: usuário, LLM, Jev, código e ferramentas. Lembrem-se: o LLM raciocina ou gera conteúdo. O Jev classifica, atribui pontuações ou toma decisões. O código executa e aplica as regras. As ferramentas realizam a operação necessária. Podemos ver como essas responsabilidades podem trabalhar juntas. O LLM planeja. O Jev escolhe uma ferramenta. O código a executa. O Jev verifica os resultados. E o LLM explica

15:41 o resultado. Observem que o workflow pode envolver várias etapas, em vez de uma única decisão. A mensagem central é que o Jev não é necessariamente um substituto para LLM. É uma interface diferente para a inteligência. Lembrem-se disso: não é um substituto para LLM. Vamos reunir tudo o que vimos até agora nesta apresentação. Vocês podem ver este diagrama. Ele mostra como um estado — mostra a pergunta de estado, o Jev e o código — começa com as informações disponíveis. Definam a

16:11 decisão que precisamos tomar para receber uma resposta apoiada por uma probabilidade, fornecida pelo Jev, e deixem que a aplicação determine o que acontece em seguida. O LLM gera textos, o Jev gera decisões e a IA de produção combina os dois. O exemplo final mostra uma mensagem de cliente levando a uma decisão de faturamento com probabilidade de 0,91, urgência do resultado de 87 e resultado da revisão humana de 76. Então, o código escolhe a próxima etapa. Esses números ilustram como várias decisões podem alimentar um workflow. Eles não devem ser interpretados como garantia

16:43 de correção. Então, a lição geral é simples. O Jev fornece decisões probabilísticas estruturadas que os softwares podem usar, enquanto o LLM continua sendo valioso para raciocínio e geração de linguagem. Obrigado. Chegamos ao fim desta introdução ao Jev. Espero que vocês tenham entendido cada slide e cada conceito apresentado. Se gostaram deste vídeo, curtam, compartilhem e se inscrevam no meu canal. Também ativem o sininho e não se esqueçam de me seguir no Instagram. Juntem-se a mim no Telegram. Obrigado por assistir. Tenham um bom dia.

17:16 [música] >> [música]

Transcrição original

[00:02] [music] Hey everyone, welcome back to my YouTube channel. In this particular video, we’ll be looking into the Jeff model. So, let’s begin by understanding what Jeff does. This particular slide compares a typical question we might ask an LLM. What should I do with the ticket? You can see this question. What should I do with this ticket? with the kind of direct decision Jeff can produce.

[00:33] Instead of generating a free form explanation like how an LLM does, Jeff can return a structured results. For example, you can see the result is route which is billing and it has also given a probability of 0 91. This means the selected route is billing with a probability of 91. The workflow shown here is state. It goes to the Jeff model. Then it gives a typed decision and then the code does

[01:06] the action. In simple words, the application provides information. Jeff answers a defined question and the code uses that answer to take the action. This is the central idea of Jeff. Jeff is specifically designed for fast structured probability backed software decisions rather than ordinary conversations. I hope you have got an overview of what exactly Jev is. Look at this problem illustrated on this slide. In many

[01:37] applications, we provide information to an LLM receive generated text. We parse that text, validate it, and then execute the required action. For a simple decision, this can introduce unnecessary steps. The output might have formatting problems. It might require retries or produce uncertainty that is difficult for application to handle consistently. For example, if the application only needs to select a route, generating a full text response and then extracting the route can be more work than

[02:09] necessary. An if statement is a programming construct that executes a particular action when a condition is satisfied. The slides argument is that some AI workflows use a large language model for decisions that could be handled more directly. This particular slide compares two approaches. Chat first LLMs and system one models such as Jeff. A chat first LLM focuses on generating language. Its output is typically produced through a sequential

[02:39] token generation. Jeff, by contrast, it’s designed to return decision- oriented outputs such as predefined choices, scores, and probabilities. This comparison also highlights the difference between flexible text and typed values that software can consume, as well as between confidence expressed through a prompt and probabilities returned as part of the decision. For example, one approach might explain a complaint while the other selects a Q.

[03:09] The key takeaway is that these models have different design priorities. Jeff is intended to handle defined decisions while an LLM remains useful for flexible language generation. I hope you’re understanding this system one approach. Now let’s have a look at the entire workflow of Jeff. First, we provide a state. Now this could be a ticket, a retrieved text chunk, a document, a JSON data, or the current state of an AI agent. Next, we define the typed question. Jeff evaluates that question

[03:42] against the provided state and returns the structured decision. Finally, the application code uses this result to route the request, filter information, continue a workflow, or send a case for review. Notice that Jeff is not shown executing the entire application by itself. It supplies the decision while the code determines what action follows. The separation is important because it allows the model’s decision-m role to remain distinct from the application’s execution logic. For example, you can see the state customer was charged twice

[04:13] and wants a refund. Now, Jev here can identify exactly which queue it should go to, how urgent it is, and whether human escalation is required or not. So for decision-m things this is how Jeff works. I hope you are understanding this. Now let’s have a look at the three decision primitives of Jeff and those are null, choice and score. Now first is null. N answers a yes or no question. For example, is this true? The output

[04:45] will be either yes or no. Let’s say if it is yes, then it will return yes as well as the probability of how much possibly the answer is correct. which is 94. Second is choice. Out of the given options, which one is more likely to be correct? So, choice selects among the predefined alternatives. In the routing example, billing has a probability of.82. Technical has the probability of.13 and sales has a probability of 05. So, you can see this is how it gives the probability of all the defined options.

[05:17] The third is score. Score evaluates something on an ordered scale. Here urgency is represented by a score 8.2 out of 10 along with the confidence information. So these are the three decision primitives which are used in Jeff. Let’s take an example. The customer message brings three ideas together. A customer sees they were charged twice and then need their money back today. The system can choose the appropriate route,

[05:48] access, assess the urgency and evaluate whether the escalation is needed or not. These primitives represent three different questions. Is it true? Which option? How much or how strongly? I hope you have understood all the three different primitives which are used in Jeff. Why Jeff is fast? Now, as we know a conventional LLM generally generates the output tokens sequentially one by one. Jeff is designed to produce its decision outputs without the same free form output token decoding process. The

[06:19] presentation reports an end toend latency of 70 to 500 milliseconds. Latency means the time taken to return a result. The example illustrates a structured decision containing information such as the selected route and urgency rather than a long explanation. This can be beneficial when an application needs to make frequent decisions and act on them immediately. However, the reported latency should be understood in the context of the tested workload and infrastructure. It is not a guarantee for every application. I hope

[06:51] you have understood this. I hope now you know why it can be so fast. Let’s follow the agent workflow which is shown on the left. A user submits a request. The LLM plans what to do and Jeff checks a decision before the workflow proceeds. The application then determines whether to use a tool, continue, or take another permitted action. After the chosen tool gets executed, Jeff can evaluate the result and the LLM can prepare the

[07:21] response for the user. This example shows the LLM proposing refund tool. Jeff evaluates whether the tool is appropriate while the code performs the execution. The right side list possible Jeff uses tool selection routing guide rails relevant scoring escalation and workflow branching. A guardrail is a control that helps prevent unsuitable actions. The important distinction is that Jeff can support the decision while the application must still enforce permission and execution rules. For example, if we use LLM, it will say I

[07:53] should call the refund tool. But if we use Jeff, it will say that is refund tool appropriate with a probability also. And accordingly, the code executes the tool. I hope you have understood how Jeff can be used inside an AI agent and how it can be better rather than using an LLM for tool calling or execution. Now let’s take a real example. This particular slide demonstrates how Jeff can act as a decision gate in a rack pipeline. Now here you can see the process starts with a user query. A

[08:24] retriever searches for relevant information and returns the retrieved chunks as what happens in a rag. Jeff then evaluates whether the retrieved chunk supports the user question. So this acts as a decision gate. The example chunk says the policy allows refund within 30 days. The question is whether this chunk supports the user’s refund question. The slide illustrates the result as yes with a probability of 93. Now depending

[08:55] on the result, the workflow can generate an answer, retrieve information again or ask the user for clarification. By the way, I hope you know what drag is. It is retrieval augmented generation. Retrieving relevant information to support an AI generated response. The reason Jeff fits here is that relevance checking is a bounded decision. the system can use its probability to help control the workflow rather than treating every single retrieve chunk as automatically useful. So I hope this example might have clear how Jeff can be useful in day-to-day use

[09:26] cases of generative AI. Now what makes Jeff different from JSON mode? See if you don’t know JSON mode asks a language model to produce structured text. The example contains a root and a confidence value. As you can see root is billing confidence value is.91. Even when the output looks like a valid JSON the application may still need to check the schema validate the values or retry if the output is unsuitable. Jeff

[09:56] instead uses a typed question with an answer space defined beforehand. For example, let’s say the permitted roots are billing, technical and sales. Here Jeff cannot generate a fourth root such as customer success. This is the main ideology behind using Jeff and how it is different from JSON mode. JSON mode if we use it behind the scenes we are using LM only and LLM can anytime generate some vague results and might uh generate some invalid JSON. So all those issues gets rid of when we use Jeff. So I hope

[10:27] you have understood the difference between the JSON mode also and Jeff. This particular slide presents results from an independent evaluation of Jeff identified in the presentation as a September 2026 archive study. It covers 13 data sets and 3 lakh 46,09 request. The displayed zeroot accuracy figures are 95% on arc, 96% on heliswag, 97%age on SST2 and 97%age on IMDb. For

[11:00] bleel the presentation reports 86.7 percentage of accuracy across 122 languages. This slide also reports the Jeff beat Quen 3.8 27 billion parameter model on 27 of the 37 data sets and GMA 4 E4 billion parameter model on 37 of all 37 data sets in that on all 37 data sets in that evaluation. Zeroshot means the model is evaluated without task specific examples in the prompt. These

[11:31] results cover different tasks including classification, routing, reading, comprehension, moderation, and rubric scoring. We are encouraging results from the reported evaluation, but they should not be treated as a universal ranking of AI models. Now, let’s talk about the speed and cost. This particular slide represents TypeSafe AI’s published pricing and performance claims. The displayed price is 0.042 per million input tokens with output tokens listed as free. The reported end

[12:03] to end latency is 70 to 500 milliseconds. There is also a claim of 193.6 times faster and 446.6 times cheaper than a vendor workflow evaluation. Now why does this matter? Consider a routing decision repeated millions of times. Even a small difference in response time or cost can become important at that scale. However, the slide explicitly qualifies these multipliers as results from the type C’s own workflow evaluations. They are not universal benchmark results.

[12:35] When evaluating a model for production, we should compare the same workload, measure end to end latency, and calculate the actual cost of the complete application where Jeff fits and where it doesn’t. You can see on this displayed slide on the left side we have the good fit and on the right side we have not as the primary tool for. So basically you can use Jeff in classification, routing, scoring, guardrails, tool selection, triarch, verification, real-time decision gates on all these components you can simply put Jeff. But when it

[13:06] comes to the sides where you have to write long form text, open-ended conversations you have to handle or you have to look for the creative generation, long explanations, exact arithmetic, unconstrained reasoning task. For all this, Jeff is not the correct tool that you have to use. The diagram at the bottom combines three components. The LLM, the LLM generates and reasons. The Jeff decides and gates and code handles deterministic logic. This means we don’t need to choose only one model for the entire application. For example, an LLM

[13:38] can generate a response. Jeff can select a category and code can enforce the business rules. The goal is to use each of these components for the task it is designed to perform. I hope you’re understanding. Now let’s also have a look at the limitations that you should know while using Jeff. Of course, Jeff is not error-free AI. No AI is error-free. You should know where it goes wrong or where it can go wrong. See, first Jeff can make incorrect decisions for sure. Yes, wrong decisions are possible. Your probability whatever you are getting,

[14:08] it’s not guaranteed. Second, its probabilities needs to be interpreted carefully. A probability of 0.90 does not automatically mean an action is safe. Third, poorly designed questions or answers pieces can lead to poor decisions. This you have to keep in mind. Fourth, performance can also vary by task particularly for low resource languages, noisy inputs and rubric based evaluation. Also, you need to remember that Jev is a closed model delivered

[14:38] through a managed API with weights that are not public and that its public evidence and ecosystem are still in development. Look at the payment example. Even if Jeb outputs approved payment with a 97% probability, that does not authorize the payment automatically. Here comes the distinction between a high confidence automated path and a low confidence or high-risk path that requires human review. Hope you understand this. This particular slide contrast two

[15:09] approaches. The first is to ask one AI model to do everything. The second is to use the right primitive for each step. The diagram here shows the workflow. User LLM, Jeff, code, and tools. Remember the LLM reasons or generates. The Jeff classifies scores or decides the code, executes it, and enforces. The tools perform the required operation. We can see how these responsibilities can work together. The LLM plans. Jeff chooses a tool. Code executes it. Jeff verifies the results. And LLM explains

[15:41] the outcome. Notice that the workflow can involve multiple stages rather than a single decision. The central message is that JE is not necessarily an LLM replacement. It is different interface for intelligence. Remember this, it’s not a replacement for LLM. Let’s bring all together the entire presentation that we have seen so far. You can see this particular diagram. It shows how a state it shows the state question Jeff and code begin with the information available. define the

[16:11] decision we need to receive a probability backed answer which Jeff gives and let the application determine what happens next. LLM generates strings, Jeff generates decisions and production AI combines them. The final example shows a customer message leading to a billing decision with.91 probability and urgency of the result is87 and a human review result of 76. The code then chooses the next step. These numbers illustrate how multiple decisions can feed into a workflow. They should not be interpreted as a guarantee

[16:43] of correctness. So the overall lesson is simple. Jeff provides structured probabilistic decisions that softwares can use while LLM remains valuable for reasoning and language generation. Thank you. This brings us to the end of the introduction to Jeff. I hope you have understood every single slide and every single concept involved in this. Like this particular video, please do like, share and subscribe to my channel. Also hit the bell icon and don’t forget to follow me on Instagram. Please join me on Telegram. Thanks for watching. Have a good day ahead.

[17:16] [music] >> [music]