Jev AI vs. open source: o GLiNER pode substituí-lo?

Ver no idioma original →

Autoria: James Briggs · 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 vs Open Source: Can GLiNER Replace It? · Canal: James Briggs · 34:10 · Assistir no YouTube

Tópicos: Agentes de IA, Modelos de IA, Modelos locais e open source, Segurança de IA

Resumo

O vídeo apresenta Jev, um modelo de decisão rápido que não é um LLM, e explica como suas saídas probabilísticas calibradas podem ajudar a integrar IA a sistemas com mais previsibilidade. Jev complementa os LLMs em tarefas como classificação, guardrails e seleção de ferramentas, mas não gera texto e tem limites de escala e contexto. O apresentador compara Jev a alternativas open source da família GLiNER, que podem ser menores e mais rápidas localmente, embora não ofereçam a mesma calibração de probabilidades. Em testes com Doom, combinar um modelo rápido com um LLM como estrategista melhora o desempenho em alguns cenários, especialmente quando o modelo local responde com baixa latência.

Pontos-chave

• Jev é um modelo de decisão não generativo, voltado a classificação e decisões rápidas, que complementa os LLMs em vez de substituí-los.
• Uma característica central de Jev é a probabilidade calibrada: uma confiança de 0,8 indica que o modelo tende a acertar aproximadamente 80% das vezes naquele tipo de resposta.
• Jev processa várias decisões em paralelo e pode ser muito mais rápido do que um LLM, mas não gera linguagem natural.
• Os tipos de saída de Jev incluem choice, score e null, que representam opções sem ordem, opções ordenadas e decisões sim/não.
• Jev pode ser útil para guardrails e seleção de ferramentas, desde que a tarefa não exija gerar texto.
• Jev é proprietário e fechado; o vídeo observa que alternativas open source, especialmente os modelos GLiNER, já conseguem resultados competitivos em algumas tarefas.
• GLiNER pode ser executado localmente e, nos testes apresentados, GLiNER 2.5 foi significativamente mais rápido do que Jev pela API.
• Ao contrário de Jev, os modelos GLiNER apresentados não oferecem probabilidades calibradas nem uma distribuição de probabilidade sobre todas as opções.
• Nos testes com Doom, um LLM pode fornecer instruções estratégicas a um modelo rápido; essa combinação ajudou mais em mapas que exigiam buscar armas e itens de saúde.
• O apresentador considera que modelos menores e especializados podem ampliar o acesso à IA e integrar-se a workflows agentic.

Capítulos

Início	Capítulo	Resumo
00:00	O que é Jev e onde se encaixa	O vídeo apresenta Jev como um modelo não generativo de decisões rápidas e o relaciona às ideias de pensamento System 1 e System 2.
02:38	Entradas, saídas e tipos de decisão	O apresentador explica como Jev recebe estado e perguntas, e descreve as saídas choice, score e null.
06:17	Probabilidades calibradas e velocidade	O vídeo mostra por que a calibração ajuda a estimar a confiabilidade de Jev e compara sua latência com a de um LLM.
11:35	Usos e limites de Jev	Jev se destaca em classificação, guardrails e algumas tarefas de seleção de ferramentas, mas não substitui modelos que precisam gerar texto.
14:48	Jev é fechado e surgem alternativas open source	O apresentador comenta a natureza proprietária de Jev e introduz modelos open source que podem reproduzir parte de suas capacidades.
17:24	Comparação com a família GLiNER	O vídeo compara o tamanho e o desempenho dos modelos GLiNER com Jev em tarefas de classificação e guardrails.
20:34	Como GLiNER recebe tarefas e o que perde	O apresentador explica os esquemas de entrada do GLiNER 2.5 e destaca a falta de probabilidades calibradas como uma diferença importante.
25:49	Combinar modelos rápidos com um LLM	A analogia entre pensamento rápido e lento orienta testes em que um LLM fornece instruções estratégicas a um modelo de decisão.
28:26	Testes de Doom e impacto da latência	Em mapas que exigem estratégia, o modelo local combinado com um LLM melhora os resultados, em parte por responder mais rápido que Jev pela API.
31:35	O futuro dos modelos especializados	O vídeo conclui que modelos menores podem ampliar o acesso à IA e recomenda explorar seu uso em guardrails, seleção de ferramentas e workflows agentic.

Citações

É tipado, é ultrarrápido e, muito importante, inclui tomada de decisão calibrada. — 00:30

Quando Jev produz uma probabilidade de 0,8, isso significa que ele estará correto naquele item aproximadamente 80% das vezes. — 06:48

Jev não substitui os LLMs. É um componente adicional que podemos usar ao lado deles. — 13:43

Estamos falando de oito vezes mais rápido, o que é insano. — 25:19

As alternativas open source a Jev certamente têm lugar nos nossos workflows agentic e nas nossas pilhas de IA. — 33:08

Conceitos e entidades

• Jev (modelo): Modelo proprietário de decisão não generativo que produz classificações e probabilidades calibradas.
• GLiNER (modelo): Família de modelos open source que pode realizar reconhecimento de entidades e outras tarefas por meio de esquemas e rótulos definidos na entrada.
• GLiNER 2.5 (modelo): Versão da família GLiNER discutida no vídeo, capaz de classificação e executável localmente.
• GLiGuard (modelo): Modelo da família GLiNER citado nos testes de guardrails.
• TypeSafe AI (empresa): Laboratório que desenvolveu e anunciou Jev.
• Daniel Kahneman (pessoa): Autor de Thinking, Fast and Slow, obra associada à distinção entre pensamento rápido e lento discutida no vídeo.
• Figure Robotics (empresa): Empresa de robótica mencionada como exemplo de uso de sistemas de modelos com diferentes funções.
• VizDoom (ferramenta): Biblioteca usada na demonstração para converter o estado do jogo Doom em dados estruturados.
• DOOM (conceito): Jogo usado nos testes para comparar modelos de decisão e combinações com um LLM.
• probabilidade calibrada (conceito): Probabilidade cuja confiança estimada corresponde aproximadamente à frequência real de acertos do modelo.
• System 1 (conceito): Modo de pensamento rápido e intuitivo usado como analogia para modelos de decisão de baixa latência.
• System 2 (conceito): Modo de pensamento lento e deliberativo usado como analogia para modelos que raciocinam e fornecem instruções estratégicas.
• LLM (conceito): Modelo generativo que produz texto sequencialmente e pode ser usado para conversa, busca e geração de código.

Tradução completa (pt-BR)

00:00 Jev é um dos modelos de IA mais badalados do ano. E o mais interessante nisso é que ele não é um LLM. Não vem da OpenAI, da Anthropic ou da DeepSeek. É um novo laboratório que acaba de sair do modo stealth: a Type Safe AI. E a arquitetura que estão usando aqui não é generativa, embora a IA tenha se concentrado nisso por cerca de quatro anos. Então, é muito

00:30 interessante que, de repente, o hype do mainstream esteja em torno de algo que não é um LLM. Neste caso, acredito que o hype é justificado. É tipado. É ultrarrápido. E, muito importante, inclui tomada de decisão calibrada. Com isso, ele muda o que realmente podemos fazer com IA. E acho que, o que é importante, tudo o que a Type Safe fez com Jev faz a IA parecer um pouco menos distópica. Vou

01:02 explicar melhor isso mais adiante. Então, vamos explorar o lugar de Jev na pilha de IA mais ampla, as alternativas open source muito reais e capazes a Jev e como podemos pensar rápido e devagar para vencer Doom usando apenas Jev. Então, vamos começar pelo que Jev é. A Type Safe anunciou Jev como um novo tipo de modelo. Ele se encaixa na pilha de IA ao lado dos LLMs, sem substituí-los. E a Type Safe

01:34 cunhou o termo modelo System 1 para isso. E não é a única empresa de IA a fazer isso. A Figure Robotics, por exemplo, tem um sistema de três níveis, no qual chama seus modelos de System 0, System 1 e System 2. A ideia por trás dessas convenções de nomenclatura vem do trabalho de Daniel Kahneman e, em especial, do conhecido livro Rápido e devagar: duas formas de pensar. Kahneman argumenta que temos dois modos de

02:05 pensar. Temos o raciocínio lento, chamado System 2, e temos a intuição mais rápida, os vieses da nossa intuição rápida, do nosso cérebro de macaco. Isso é chamado de System 1. Jev, assim como veremos em outros modelos, faz uma analogia imperfeita com o pensamento do System 1. É um modelo de tomada de decisão ultrarrápido que, em termos mais simples, normalmente chamaríamos de

02:38 um modelo de classificação. Então, vamos dar forma a Jev. Certo. Quais são as entradas? Quais são as saídas que obteríamos desse sistema? Jev só está disponível por API e, por meio dela, enviamos perguntas e estado. Essas são as nossas entradas. [limpa a garganta] Elas são assim. Enviamos nossa solicitação para post v1 system one, definimos nosso modelo, mas, mais importante, temos aqui o estado e as perguntas. Quanto ao estado, você pode ver neste

03:10 exemplo que estamos usando Jev para controlar um jogador no videogame Doom. Nesta demonstração de Doom, recebemos um estado de onde estamos em Doom naquele momento. Qual é a nossa saúde, a quantidade de munição, onde estão os inimigos na nossa visão e também onde estão itens importantes, como um kit médico ou uma arma específica. E tudo isso

03:40 vem por meio desta biblioteca chamada vizdoom. Além disso, nos exemplos de Jev em que o vimos jogando Doom, ele não está olhando para o vídeo ou as imagens em si. Está usando a biblioteca vizdoom, que traduz o estado de Doom em um objeto JSON que descreve onde está cada coisa. Então, todas as informações que recebemos de Doom entram no nosso estado, como você pode ver aqui: saúde, arma, munição, inimigos e onde estão as coisas, como o

04:10 kit médico. Depois temos as perguntas, que são decididas por nós ou pelo nosso código com base nesse estado. Que decisões precisamos tomar? Cada decisão está vinculada a uma pergunta. Agora, você vai ver que cada uma das nossas perguntas tem uma estrutura e uma finalidade diferentes. Essa estrutura é uma das qualidades específicas de Jev. Jev permite definir três tipos diferentes de objetos

04:43 e você pode vê-los aqui. Temos o tipo choice, o tipo score e o tipo null. O que significam? Aqui, temos action; o tipo é choice, que define um conjunto fixo de opções, ou categorias, e Jev vai gerar uma distribuição de probabilidade sobre esse conjunto. É importante destacar que o que distingue esse tipo específico é que

05:14 não há ordem entre essas escolhas. Isso é diferente do nosso próximo tipo, score. Score é muito parecido, mas há uma ordem entre as diferentes escolhas. Certo, neste exemplo temos retreat, que significa recuar; na verdade, estamos indo para trás. Depois temos hold position, posição neutra; advance, avançar; e charge, avançar mais rápido. Certo, então há essa escala

05:45 contínua, e aqui você está vendo a saída. Jev vai gerar um valor dependendo de quantas opções de critério fornecemos: de zero a um, se fornecemos apenas duas opções; de um a dois, se há três opções; de dois a três, se há quatro opções. E a saída de score pode, obviamente, ficar entre essas opções, o que representa a natureza não totalmente discreta do tipo score. Null é muito simples. É só um sim ou um não

06:17 mas, de novo, pode ficar em uma escala. Zero é um não direto. Um seria um sim com muita confiança. 0,5 fica no meio. Jev não sabe muito bem se é sim ou não, certo? E então há a escala entre esses valores. Agora, é muito importante que cada uma dessas escolhas retorne o que eles chamam de probabilidade calibrada. E isso é uma das coisas mais importantes sobre Jev

06:48 porque é o que nos permite usar Jev em bases de código reais e fazer isso com confiança. Isso significa que, quando Jev gera uma probabilidade de 0,8, Jev estará correto naquele item específico cerca de 80% das vezes. Talvez isso não pareça muita coisa, mas nos dá uma confiança mensurável e um nível de interpretabilidade sobre o que essas pontuações realmente significam. Com os LLMs, eles também

07:18 geram probabilidades se você pedir, mas elas não são necessariamente muito bem calibradas. Embora tenham melhorado recentemente, como veremos, eles continuam sendo generativos e suas probabilidades não são tão bem calibradas quanto as de Jev. E sabemos disso porque podemos observar a probabilidade informada pelo modelo para algo e verificar com que frequência o modelo realmente acerta essas coisas. E

07:49 o que deveríamos ver é que, quando o modelo diz ter 60% ou 80% de confiança, ele realmente acerte 60% ou 80% das vezes nessas respostas específicas. E vemos isso nestes gráficos. Certo. Aqui estamos calculando o erro esperado de calibração, que é o que acabei de descrever. A linha tracejada no meio é a calibração ideal. É a calibração perfeita. E você pode ver que Jev, aquela pequena linha verde,

08:25 é bem preciso. E, com o GPT-5.6 Luna, ainda não é ruim. Não é tão bom quanto Jev, mas não é ruim. Só que o que fica meio escondido nesses gráficos é que, com Luna, estamos obtendo valores apenas quando ele diz: “Ei, tenho 95% de confiança”, o tempo todo. Então, em geral, Luna só gera pontuações de confiança muito alta, algo que não

08:56 víamos sempre com Jev. Quando errava, Jev tendia a dizer: “Ei, posso estar errado aqui.” Isso é muito, muito poderoso quando pensamos em criar pipelines, workflows e processos reais com Jev em vez de um LLM. Você pode dizer de verdade: “Ei, meu pipeline aqui vai errar cerca de 80% das vezes.” Não conseguimos fazer isso tão bem com LLMs. E isso realmente está nos levando

09:29 a concretizar uma das primeiras visões da IA [limpa a garganta]: combinar processos neurais, usando redes neurais, com lógica simbólica, como código. O que raramente temos aqui é a capacidade de criar sistemas neuro-simbólicos mais previsíveis. E, muito importante, com Jev podemos fazer isso muito rapidamente. Podemos incorporar tomada de decisão verdadeiramente rápida, baseada em redes neurais, ao nosso código. Na minha opinião, esse é o maior

10:02 diferencial de Jev. O modelo em si não é necessariamente muito impressionante, na minha opinião, mas esse uso, ou esse foco em garantir que as probabilidades sejam calibradas para que realmente saibamos, aproximadamente, com que frequência o modelo erra… isso é algo que realmente tem faltado na IA e que, em geral, nos limita na medida em que podemos confiar nela e, portanto,

10:33 integrar IA a sistemas de produção. Além disso, como mencionei, o Jev é ultrarrápido, o que nos leva à latência. Se você olhar para isto, dá para ver quanto tempo Luna leva para gerar algumas opções. Luna é, sabe, o modelo mais rápido — um dos modelos mais rápidos que recebemos da OpenAI no momento. No tempo que Luna leva para gerar uma única decisão, Jev já produziu algo entre

11:04 12 e 14 decisões. Certo, este é o tempo no servidor. Não inclui a latência da rede, mas os dois modelos sofrem a mesma latência de rede. Então, esta é aproximadamente a diferença que você vai observar. E, para levar isso adiante, se empilharmos muitas decisões paralelas para serem tomadas na mesma chamada, certo? Se houver 10 decisões a tomar — neste exemplo, há apenas três. Se forem 10, Luna vai levar mais tempo para gerar mais tokens para

11:35 essas 10 decisões. Jev faz tudo em paralelo. Então, as 10 decisões que você tomou acontecem no mesmo intervalo de tempo que vemos aqui. Assim, fica ainda mais rápido. Isso parece bastante impressionante, mas não podemos usar Jev no lugar de LLMs o tempo todo. Jev é fenomenal para tomar decisões rapidamente, se pudermos definir todas as decisões possíveis com antecedência e se não precisarmos gerar linguagem natural. Certo, Jev não consegue

12:07 gerar tokens como um LLM. Ele é um classificador. Mas, nos casos em que precisamos apenas de classificação, você pode ver os benchmarks aqui. Este é Jev versus Luna. Na maior parte, Jev iguala ou supera Luna, o que é bastante incrível, especialmente considerando a diferença de latência e custo entre eles. O único benchmark em que Luna teve desempenho melhor

12:38 é um benchmark de classificação de intenção para o setor bancário: o Banking Zone 7, lá em cima. No restante, Jev se sai muito bem, particularmente nos benchmarks mais voltados a guardrails. Então, injeção de prompt e verificação de conteúdo tóxico, lá embaixo. Jev superou Luna de forma bastante significativa. O que vemos com isso é que Jev tem um desempenho muito forte para guardrails e também para seleção de ferramentas, dois casos de uso enormes para LLMs

13:10 no momento. Então, Jev pode de fato, com alguns testes e validação, substituir algumas partes de ambos — em particular, dos guardrails. As escolhas de ferramentas são um pouco mais complexas. Nos casos em que as escolhas de ferramentas exigem texto gerado, é claro que Jev não consegue fazer isso. Então, temos que continuar usando um LLM. Mas nem todas as escolhas de ferramentas precisam de geração de texto. Portanto, nesses casos, podemos realmente usar Jev. O que vemos com isso é que Jev

13:43 não substitui LLMs. É um componente adicional que podemos usar junto com LLMs, não um substituto. LLMs continuam sendo a opção principal para tudo que exige texto gerado: chat, busca, geração de código. Sim, ainda precisamos de LLMs para isso, mas Jev pode ser usado em outras situações. Também vale notar que Jev tem algumas limitações até mesmo na tomada de decisões, certo? O desempenho é bom, mas não podemos escalar para um número muito grande de decisões a serem

14:16 tomadas de uma só vez. Então, se você quiser fazer, sabe, mais do que acho que é o limite de 255 decisões paralelas, não dá para fazer isso. É preciso separá-las. E o estado do Jev é limitado a cerca de 32.000 tokens, incluindo a pergunta mais longa. Isso é algo que você deve ter em mente. Por exemplo, não dá para ter conversas muito longas no Jev. [bufa] E também foi relatado que o desempenho do Jev se degrada

14:48 bem antes de você atingir esse limite de 32.000 tokens. Portanto, estados muito grandes talvez não sejam adequados para Jev. No geral, os resultados do Jev são muito interessantes e impressionantes. Mas há um porém: Jev é fechado e proprietário. E esta é provavelmente uma das coisas mais confusas na abordagem da Type Safe, na minha opinião. Vamos chegar a isso. Jev é divulgado como um grande novo

15:20 avanço. Talvez seja verdade, mas não podemos saber: tudo é fechado e proprietário. Os únicos detalhes que temos são relativamente escassos. Sabemos que o processo de pós-treinamento do Jev recebeu o nome de aprendizado por reforço para decisões calibradas, ou RLCD, que lembra o aprendizado por reforço com feedback humano. Se você se lembra, esse foi um dos principais componentes que tornaram o ChatGPT possível. Além disso, também sabemos

15:52 que Jev não é um modelo autorregressivo. O que quero dizer com autorregressivo é que ele não é generativo como um LLM, que gera tokens sequencialmente. Em vez disso, Jev produz valores de probabilidade diretamente a partir de uma rede. Provavelmente ainda é um transformer, mas com uma cabeça diferente ou uma camada diferente acoplada no final, em vez das camadas autorregressivas que encontraríamos em LLMs. Houve um ótimo

16:23 artigo, na verdade, de um cara chamado Archer Hume, intitulado “Jeb’s Architecture Mast”. Recomendo que você dê uma olhada, caso tenha mais interesse em entender um pouco melhor a arquitetura por trás de Jeff. Nada disso foi confirmado, mas, além disso, não sabemos muito. E, de qualquer forma, talvez não precisemos saber, porque há várias alternativas open source ao Jev — e é aí que fico

16:54 um pouco mais confuso com a abordagem da Type Safe. O que Jev faz é, em grande parte, reproduzível com modelos open source que já existiam antes do Jev e que surgiram depois dele. Muitos clones do Jev foram lançados, sabe, em questão de dias. Portanto, com algumas ressalvas, não é necessariamente algo difícil de fazer. Mas o que Jev faz não é tão difícil de

17:24 reproduzir e até de executar localmente, ao contrário de algo como Fable ou GPT6 Opus, que são modelos enormes e exigiriam uma quantidade enorme de treinamento. E, embora não saibamos muito sobre Jev, já vemos modelos open source chegando bem perto. Então, vamos dar uma olhada em alguns desses modelos. Muitos são chamados de modelos System 1 ou de Open Jevs. Há vários nomes. Temos o Jev

17:55 lançado em 15 de setembro. Muito antes disso, já tínhamos os modelos GLiNER. Então, o GLiNER 2.5, o mais recente da Fino AI. Tenho testado o GLiNER 2.5 e vamos falar dele em um minuto. Ele se sai muito bem e foi lançado em agosto. E havia modelos anteriores. Havia GLiNER 2, GLiNER-Guard, GLiNER-Class e também o GLiNER original, que, sabe, acho que é de 2023. Eles já existem há algum tempo. E

18:26 veja o tamanho desses modelos. Para os modelos GLiNER 2.5, estamos falando de 74 a 300 milhões de parâmetros. Isso é minúsculo e funciona muito bem em hardware de consumo. Especialmente este modelo de 74 milhões de parâmetros. Este é, na verdade, o modelo que usamos em nosso teste para jogar Doom. E, em muitos casos, ele superou Jev, certo? Isso é interessante, no mínimo. Nos nossos testes, GLiNER-Guard também superou Jev

18:59 em alguns benchmarks de guardrails. Muito interessante. De novo, estamos falando de 300 milhões de parâmetros. E depois temos esses novos imitadores do Jev. Eles estão recebendo muita atenção na internet, mas, sinceramente, não vi muito valor neles. Funcionam bem em algumas áreas. Superam outros modelos em algumas áreas, mas, na maior parte, sinceramente, os modelos GLiNER parecem se sair melhor. Dá para ver isso aqui. Então, entre esses

19:31 benchmarks que mostrei antes, podemos ver que GLiNER-Guard se sai muito bem nos benchmarks voltados a guardrails: jailbreak e chat tóxico. Não se sai tão bem em injeção de prompt; nesse caso, Jev e Leia parecem funcionar melhor. Von chega bem perto de Jev na seleção de ferramentas e supera GLiNER 2.5, mas, no geral, olhando para os modelos GLiNER — GLiNER 2.5 ou GLiNER-Guard —, temos um desempenho melhor [bufa] do que

20:02 o de outros modelos, ou chegamos bem perto. E, quando você olha para o tamanho de todos esses modelos, os modelos GLiNER são menores e mais rápidos. Então, ao testá-los, concluí que, entre as alternativas open source, GLiNER parece ser a melhor opção, caso você queira essas alternativas. Mas, é claro, como são open source, você pode combinar diferentes modelos. Não há problema nisso. Então, GLiNER é bastante interessante. É uma família de modelos, e você vê isso a partir de

20:34 o nome, certo? GLiNER: a ideia original era, na verdade, reconhecimento de entidades nomeadas, e era isso que o modelo original fazia — e ainda é o que o GLiNER 2.5, o modelo mais recente, faz. Ele ainda consegue fazer isso, mas também consegue fazer outras coisas. Então, os modelos GLiNER fazem as coisas de um jeito bem diferente, mas o que eles têm em comum é que associam rótulos ao texto de entrada. É mais ou menos como inserir perguntas e estado na entrada de um modelo. Todos eles são

21:06 modelos de encoder bidirecional, que são um tipo de transformer sem a cabeça autorregressiva que vemos em LLMs. Aqui, você pode ver as diferenças entre o GLiNER e o GLiNER 2.5 na parte de reconhecimento de entidades nomeadas. Mas ele não dá suporte apenas a reconhecimento de entidades nomeadas, certo? Essa também é uma grande diferença entre o GLiNER e o GLiNER 2.5: o 2.5 pode fazer mais, alterando o esquema que inserimos neste exemplo.

21:38 Estamos fazendo classificação, e é assim que o GLiNER 2.5 faria a classificação, na mesma estrutura do Jev. Você pode ver que tudo isso é definido com esses tokens especiais que aparecem no topo. Temos P, description, L, set, text e outros. Todos eles definem o que o GLiNER 2.5 precisa fazer, como fazer e qual estrutura de saída específica usar. Então, podemos ver aqui que P define o

22:10 nome da tarefa e, opcionalmente, quaisquer instruções relacionadas a ela. É o prompt. Certo, P significa prompt. Antes, estávamos vendo o Jev, e esses elementos eram chamados de perguntas. Então, tínhamos as ações avançar e trocar para as perguntas da espingarda. Depois, temos os rótulos. Esses são os critérios que vimos antes em dois dos exemplos. E, para o tipo nulo do Jev, a resposta é sim ou não. Aqui, em description, é onde colocamos os critérios do Jev,

22:41 para os quais tínhamos uma descrição para cada um dos nossos critérios. E é assim que fazemos isso aqui. Em description, precisamos passar o rótulo, certo? Neste exemplo, temos atirar, mirar à esquerda e mirar à direita, seguidos das instruções para aquele rótulo. E, por fim, temos set text, que separa o esquema de entrada — os rótulos e as perguntas — do nosso estado, ou do texto de entrada, que vem depois do token set text.

23:12 E, por fim, quando temos várias perguntas em paralelo, vários prompts, usamos o token septstruct para separá-los. Aqui, você pode ver, à esquerda, como a estrutura do Jev — perguntas e estado — corresponde à estrutura do GLiNER 2.5, à direita. Isso nos leva a uma das desvantagens de usar o GLiNER ou, pelo que vi, qualquer modelo open source em vez do Jev. Como mencionei antes, uma das principais coisas que tornam o Jev especial é a probabilidade calibrada. Você pode ver aqui que, com o GLiNER 2.5, não há realmente nenhuma garantia de calibração, certo? O Jev vai dizer: “Ei, quero que a ação agora seja atirar, e tenho 98% de confiança nisso”. Já o GLiNER, por um lado, não nos dá uma distribuição de probabilidade para todas as nossas opções e, além disso, não é

23:44 calibrado. Então, uma pontuação de 0,65 para mirar à esquerda não significa que essa opção esteja correta em 65% das vezes. Perdemos a probabilidade calibrada que o Jev nos dá, o que, sendo justo com o Jev e a Type Safe, é um motivo enorme para usar o Jev. Além disso, você precisa usar um modelo diferente para cada caso de uso, certo? Com o Jev, dá para usá-lo em quase tudo, pelos benchmarks que

24:14 vimos. Já com os modelos GLiNER, é preciso usar o GLiNER 2.5, o GLiNER Guard ou algum outro. Então, existem algumas desvantagens, mas, se você conseguir lidar com elas, a melhora na latência é fenomenal. O tempo de servidor informado para o Jev é, em média, de 88 milissegundos. Isso é para uma classificação de Doom. Já com o GLiNER 2.5 small, que é o que

24:46 eu realmente uso na maioria dos meus testes e que teve um desempenho muito bom, estamos falando de oito vezes mais rápido, o que é insano. É muito, muito mais rápido. Sem dúvida, é algo que você precisa levar em conta ao decidir qual desses modelos usar. Considerando esses tempos, tudo é muito mais rápido do que usar um LLM. Mas os LLMs têm alguns benefícios.

25:19 Eles raciocinam sequencialmente por tokens porque são autorregressivos. Eles geram esses tokens. Isso significa que um LLM pode usar computação para pensar, de certa forma, certo? É lento, mas um LLM pode usar computação para raciocinar, pensar e explorar ideias. Esses modelos de classificação de que estamos falando — Jev, GLiNER e outros — não conseguem fazer isso. Eles não são autorregressivos. Sim, é uma vantagem e uma desvantagem. Então, voltando à ideia de pensar rápido

25:49 e devagar, do trabalho de Kahneman, nosso cérebro opera com dois sistemas: sistema um e sistema dois. Embora não seja uma correspondência perfeita, podemos considerar adotar uma estratégia semelhante, especialmente no caso de Doom. O que observei durante os benchmarks e os testes é que, quando usamos apenas um modelo rápido, como o GLiNER 2.5 ou o Jev, o modelo fica mais tático. É como se dissesse: “Certo, atira, mira, atira, mira, atira, mira, atira”. Ele não costuma pensar muito em coisas como: “Certo, talvez eu

26:21 devesse ir buscar armas. Talvez eu devesse ir buscar um pouco de vida, ou algo assim”. Mas, quando adicionamos um LLM — incluímos GPT 5.6 6 Luna na combinação, sem raciocínio —, o LLM pode dar instruções mais estratégicas ao nosso modelo rápido do sistema um. Então podemos dizer: “Ei, vá até aquela sala e pegue a arma de plasma. Vá até aquela sala e pegue um kit médico”, e os modelos do sistema um

26:52 na maioria das vezes vão lá e fazem isso. Então, estamos pegando essa ideia de Kahneman, de pensar rápido e devagar, e aplicando-a às demonstrações de Doom. E também quero destacar que não somos os únicos fazendo isso. Na verdade, é algo que vemos na IA, especialmente na robótica. Acho que provavelmente diferentes empresas de robótica fazem isso em algum nível. Mas sei que a Figure Robotics, acho que com o modelo Helix 2, descreveu explicitamente como

27:23 eles têm sistema um e sistema dois. O sistema dois é o LLM de raciocínio deles, que recebe instruções em linguagem. O sistema um é o modelo de rede neural menor e mais rápido, que aplica essas instruções a metas ou objetivos de movimento. E eles também têm um sistema zero. O sistema zero é quase como os estabilizadores do robô. É meio parecido com o que acontece com os humanos. Quando tocamos em algo muito quente, nosso corpo simplesmente reage e nos faz afastar a mão. Temos o reflexo de nos afastar. É assim que interpreto o sistema zero deles. Neste exemplo, implementamos os sistemas um e dois, obviamente.

27:54 Quando você olha os mapas — e estes são, na verdade, os mapas que o Jev demonstrou —, há Defender Center, Defender Line e Deadly Corridor. São mapas de mira e tiro frenéticos. O que descobrimos é que o LLM não é realmente necessário nesses cenários. O GLiNER

28:26 e o Jev funcionam perfeitamente bem, e adicionar um LLM para orientar esses modelos não faz diferença. Então, não havia muito motivo para isso. Em geral, o LLM nem era usado. Ficava ocioso na maior parte do tempo. De vez em quando, talvez desse alguma contribuição, mas nada particularmente útil. Isso mudou, porém, com o deathmatch. À esquerda, temos apenas o GLiNER operando sozinho, e ele fica só atirando, mirando, atirando, mirando,

29:00 atirando. Não está fazendo mais nada. À direita, vemos o GLiNER com um LLM como orientador, e de vez em quando ele faz algumas coisas, como girar em círculos ou algo assim. Mas o que você vê é o LLM dizendo: “Entre na sala lateral, pegue a arma de plasma, lute contra os inimigos”. Então, quando o jogador acaba ficando com pouca vida, o LLM diz: “Certo, vá buscar um

29:30 atirar. Não está, sabe, fazendo mais nada. À direita, vemos Gler com um treinador de LM, e de vez em quando ele faz algumas coisas, como girar em círculos ou algo assim. Mas o que você vê é que o LM está dizendo: “Vá para a sala lateral, pegue a arma de plasma, lute contra os inimigos.” Então, quando o jogador acaba ficando com pouca vida, o LM diz: “Certo, vá pegar uma

30:01 kit médico.” E o GLiNER faz isso e depois continua atacando os inimigos. Então, a pontuação que vemos de fato no sistema GLiNER mais coach LLM é muito, muito melhor. Agora, como isso se compara ao Jev? É aqui que a diferença de latência entre usar uma API e ter um modelo local faz uma grande diferença. Quando usamos o GLiNER, tudo é executado localmente e temos um tempo de resposta de, sabe, 12 milissegundos

30:32 . Então, o GLiNER pode responder muito mais rápido ao que está acontecendo no jogo do que o Jev. E, por isso, o Jev combinado com um LLM é razoável, mas não faz uma grande diferença na prática. Então, com o GLiNER, há um pequeno aumento na pontuação média. A pontuação mais que dobra, como vocês podem ver, o que é bastante impressionante. E isso acontece por causa disto, certo? O número de decisões que o jogo recebe do GLiNER é de

31:04 8,8 decisões por segundo. Com o Jev, como ele está hospedado, estamos recebendo 2,5 por segundo. E, vale dizer, estou o mais longe possível de onde o Jev está hospedado — no Oeste dos EUA — sem sair da Terra. Mas, ainda assim, mesmo que reduzíssemos pela metade o tempo que o Jev leva para responder, ainda estaríamos longe de alcançar a velocidade do GLiNER. É por isso que a abordagem do Jev não faz todo o sentido para mim. Eu

31:35 acho que algumas das qualidades que tornam o Jev muito bom dificultam que a Typescape tire proveito dele. Como modelo, o Jev precisa ser rápido, o que significa que geralmente precisa ser menor. Isso quer dizer que o open source provavelmente vai alcançar o Jev muito rapidamente. Provavelmente vão encontrar uma maneira de incorporar probabilidade calibrada ao Jev, porque probabilidade calibrada não é necessariamente algo novo. Só não tem sido usada no open source, até onde

32:05 sei. Então, no geral, não tenho certeza de quão grande é a vantagem competitiva da Type com o Jev, embora ache incrível o que fizeram. Uma das razões pelas quais acho isso incrível é que eles pegaram modelos menores e mais especializados, disponibilizaram-nos para todos e fizeram com que todos soubessem que podemos usá-los. E acho que isso nos leva a um futuro menos distópico com IA, porque, se tivermos apenas esses modelos enormes e a única maneira de executá-los for sendo uma grande

32:37 empresa com muito poder computacional, teremos um futuro em que a inteligência pertence a apenas algumas empresas enormes, e o resto de nós não terá isso, certo? Talvez possamos pagar essas empresas por algum acesso à inteligência delas, mas não seremos donos de nada disso. O que o Jev fez foi tirar um pouco desse espaço dos laboratórios principais atuais, que, como vocês sabem,

33:08 são os principais laboratórios, e fizeram isso com um modelo que provavelmente a maioria de nós conseguirá executar localmente em breve, com uma alternativa open source que espero que seja lançada em breve e que iguale o Jev em desempenho e qualidade de calibração. Mas, além disso, o Jev e as alternativas open source definitivamente merecem um lugar nos nossos workflows agênticos, nas nossas pilhas de IA. Acho que o

33:38 lugar mais óbvio para começar são as proteções; depois, a seleção de ferramentas, levando em conta as nuances da geração de texto; e, além disso, explorar onde podemos realmente usar esses novos modelos [música] em IA e na pilha de software mais ampla. Então, acho tudo isso muito empolgante e uma direção incrível para a IA seguir. Mas é isso por enquanto. [música] Espero que tudo isso tenha sido útil, interessante e esclarecedor. Muito obrigado por assistir e vejo vocês de novo no

34:10 [música] próximo vídeo. Tchau. [música] >> [música]

Transcrição original

[00:00] Jev is one of the most hyped AI models of the year. And what is most interesting about that is that it’s not an LLM. It’s not coming from OpenAI anthropic deepseek. It’s a new lab that has just come out of stealth type safe AI. And the architecture that they’re using here is not generative, which has been the entire focus of AI for the past four or so years. So it’s very

[00:30] interesting that all of a sudden the mainstream hype is over something that is not an LLM. In this case, I actually believe the hype is justified. It’s typed. It’s ultra fast. It very importantly includes calibrated decision making and through those things it changes what we can actually do with AI and I think importantly everything that type safe have done with Jeff makes AI feel a little less dystopian and I’ll

[01:02] explain more about that later. So, we’re going to explore Jevit’s its place in the broader AI stack, the very real and capable open-source alternatives to Jev, and how we can think fast and slow to beat solo Jev at doom. So, let’s jump in with what Jev is. So, Typesafe have announced Jev as a new type of model. It fits into the AI stack alongside LMS, not replacing them. and Typesafe have

[01:34] coined this a system one model. And they’re not the only AI company to do this. Figure Robotics, for example, have their three tiered system where they call their models system zero, system one, and system two. And the idea behind those naming conventions is from Daniel Cayman’s work and particularly well-known book, Thinking Fast and Slow. Ga argues that we have two like modes of

[02:05] thinking. We have the slow reasoning and that’s called system two and then we have the faster intuition biases our fast monkey brain intuition. Those are called system one. Jev and we’ll see other models as well draw a imperfect parallel to system one thinking. It is a ultra fast decision making model which in simpler terms we would typically call

[02:38] a classification model. So let’s put some shape around Jev. Okay. What are the inputs? What are the outputs that we would get from this system? So Jev is API only and through the API we send questions and state. Those are our inputs. [clears throat] They look like this. So we send our request to post v1 system one define our model but more importantly we have state and questions here. So state you can see in this

[03:10] example we are using jev to control a player in the video game Doom. So in this Doom demo, we are getting us a state from our where we are in Doom at that current point in time. What is our health, our ammo count, where are enemies in our view and also where are like key items like a medkit or a particular weapon and all of this is

[03:40] coming through this library called vizdoom. Also in the Jev examples where we saw it playing Doom, it’s not looking at the actual video or the images, it’s using this vizdoom library which translates the Doom state into a JSON object describing where everything is. So all that information that we’re getting from Doom goes into our state as you can see here. Health, weapon, ammo, enemies, where things are like the

[04:10] medic. Then we have questions and the questions are decided by us or decided by our code based on that state. What are the decisions we need to make? Each decision ties itself to a question. Now you’ll see each one of our questions they have a a different structure, a different purpose. That structure is one of the specific qualities of Jev. Jev allows us to define three different types of objects

[04:43] and you can see them here. We have the choice type, we have the score type and we have the null type. Now what do they mean? So here we have action the type is choice defines a fixed set of options categories and Jeff is going to output a probability distribution over that set. Importantly and the thing that distinguishes this specific type is that

[05:14] there is no order to these choices and that is different to our next type which is score. score is very similar but there is an order to the different choices. Okay, in this one we have retreat saying we’re actually in reverse we are going backwards then we have whole position neutral we have advance going forwards and charge going forwards faster okay so there is this sliding

[05:45] scale and you’re seeing the output here Jev will output a value depending on how many criteria options we provided we go zero to one if we provided just two options Then from one to two if there’s three options, two to three if there are four options and the score output can obviously land between those options which represents the not fully discrete nature of the score type. New is very simple. It’s just a it’s a yes or a no

[06:17] but again that can land on a scale. There is zero which is just a straight no. One would be a super confident yes. 0.5 is in the middle. Jeb doesn’t really know whether it’s a yes or a no, right? And then you have the the scale in between those. Now, very importantly, every single one of these choices returns what type they’ve called a calibrated probability. And this is one of the most important things about Jev

[06:48] because it is what allows us to use Jev in our in actual code bases and be able to do so confidently. What it means is that when Jev outputs a probability of 0.8, that means Jev will be correct on that particular item roughly 80% of the time. That maybe doesn’t seem like much, but it does give us measurable confidence and a level of interpretability into what these scores genuinely mean. With LMS, they will also

[07:18] output probabilities if you ask them to, but those are not necessarily calibrated particularly well. Although recently they are better calibrated as we’ll see, but they’re still generative and they’re actually not as well calibrated as Jeff’s probabilities. And the way that we know this is we can actually look at the model’s reported probability for something. look at how often the model is actually correct on those things. And

[07:49] what we should see when the model says it is 60 or 80% confident, we should see it is actually correct 60 or 80% of the time on those specific answers. And we see that in these charts here. Okay. So here we’re calculating the expected calibration error, which is what I just described. the dash line in the middle there. That is the ideal calibration. It’s perfect calibration. And you can see that Jev, that little green line is

[08:25] is pretty accurate. And with a GP 5.6 Luna, it is still not bad. It’s not as good as Jeb, but it’s not bad. But what is kind of hidden in these charts is that we’re only really getting values from Luna that were, hey, I’m 95% confident all the time. So it generally Luna is just going through very high confidence scores, which we didn’t

[08:56] always see with Jev. Jev when it was wrong, Jev tended to actually say, “Hey, I’m might be wrong here.” Which is very, very powerful when you consider building actual pipelines, workflows, processes with Jev versus an LLM. You can genuinely say, “Hey, my pipeline here is going to be wrong about 80% of the time.” We can’t do that as well with LLMs. And this is really pushing us

[09:29] towards filling one of those one of the earliest visions of AI [clears throat] which is combining neural processes I using neuronet networks with symbolic logic like code. What we rarely have here is the ability to build more predictable neurosymbolic systems. And very importantly with Jev we can do this very quickly. we can bring truly fast neurobbased decision- making to our code. In my view, that’s the biggest

[10:02] deal with Jev. The model itself isn’t necessarily super impressive in in my view, but that use or that focus of making sure that the probabilities are calibrated so that we actually know roughly how often the model is wrong. that that’s something that’s really been missing from AI and it generally holds us back in how much we can trust and therefore

[10:33] integrate AI into production systems. So beyond that Jev as I mentioned is ultra fast that takes us to latency. If you look at this you can see how long it takes Luna to generate some choices. Luna’s, you know, the fastest, one of the faster models uh that we get from OpenAI at the moment. In the time that it takes Luna to generate a single decision, Jev has output between sort of

[11:04] 12 14 decisions. All right, this is this is server time. This isn’t including network latency, but both of these models suffer the same network latency. So this is roughly the difference you’re going to be looking at. And then to take this further, if we stack many parallel decisions to be made into the same call, right? If there are 10 decisions to make, in this example, there’s only three. If there are 10, Luna is going to take longer to generate more tokens for

[11:35] those 10. Jev does everything in parallel. So the the 10 decisions you made are happening in the same amount of time that you see here. So it gets even faster. So that seems pretty impressive, but we can’t use Jev in place of LLMs all the time. Jev is phenomenal at fast decision-m if we can define all potential decisions to be made ahead of time and where we have no need to output natural language. Okay, Jev cannot

[12:07] generate tokens like an LLM. It’s a classifier. But in those scenarios where we do just need classification, you can see the benchmarks here. This is Jev versus Luna. Jev for the most part is either matching or surpassing Luna, which is pretty incredible, especially given the latency and and cost difference between them. The only benchmark here that Luna outperformed on

[12:38] is a intent classification benchmark for banking the the banking zone 7 one at the top there. The rest Jev’s doing pretty well and particularly on more guardrail focused benchmarks. So prompt injection and toxic check at the bottom there. Jev outperformed Luna pretty significantly. So what we see from this is that Jev has very strong performance for guardrails and also tool selection which are both huge use cases for LMS at

[13:10] the moment. So Jev can genuinely you know with some testing and validation replace some parts of both of those guardrails in particular. tool choices a little more nuanced. In cases where our tool choices require generated text, of course, Jev can’t do that. So, we have to stick to an LLM. But not all tool choices need text generation. So, in those cases, we can genuinely use Jev. So, what we see from that is Jev does

[13:43] not replace LMS. It is a additional component that we can use alongside LMS, not a replacement. LMS are still the go-to for anything that needs generated text, chat, search, code generation. Yeah, we we still need LMS for that, but Jev can be used elsewhere. It’s also worth noting that Jev even in decision making it is a little limited, right? performance is good, but we can’t scale to very large numbers of decisions to be

[14:16] made at once. So, if you’re wanting to do, you know, more than I think the limit is 255 parallel decisions to be made, you you can’t do that. You need to separate those out. And the state of Jev is limited to about 32,000 tokens, and that includes the longest question. So that is something to be aware of. You can’t have very long conversations, for example, going into Jev. [snorts] And it’s also reported that Jev does degrade

[14:48] in performance long before you hit that 32,000 token limit. So very large states, not necessarily a good fit for Jev. So overall, very interesting, very impressive results from Jev. But one wrinkle with Jev is that it is closed source and it is proprietary and this is probably one of the more confusing things that type safe went with in in my view you know we’ll get to that Jev is marketed as this big new

[15:20] advancement maybe that’s true but we can’t know it’s all closed source or proprietary only details we have are relatively sparse we do know that Jev’s post training process has been coined Edin reinforcement learning for calibrated decisions or RLCD which mirrors the earlier if you remember the reinforcement learning with human feedback which is one of the key components that made chat GBT uh a a possibility and beyond that we also know

[15:52] that Jeff is not an auto reggressive model and what I mean by auto reggressive is it’s it’s not generative it’s not like an LLM it’s generating tokens sequentially. Instead, Jev pose probability values directly out of a network. It’s probably still a transformer, but it’s a transformer with a a different head or a different layer fitted onto the end of it versus the auto reggressive layers that we would get out of LMS. There was a very good

[16:23] article actually from a guy called Archer Hume called Jeb’s Architecture Mast. I would recommend you can you can take a look at this if you more if you’re interested in trying to understand a little bit more of the architecture behind Jeff. None of this is confirmed but beyond that we don’t really know much and regardless maybe we don’t need to because there are actually plenty of open- source alternatives to Jev which is where I get

[16:54] a little more confused about type safe’s approach. You see what Jev does is for the most part reproducible with open source models that already exist even before Jev and even after Jev. There have been many copies of Jev that have been released you know within days. So it’s really not a necessarily hard thing to do with some caveats. But what Jev is is not as hard to

[17:24] reproduce and even run locally versus you know something like Fable or GPT6 Opus those are huge models would require a huge amount of training and although we don’t know much about Jev we can see open source models getting pretty close already. So let’s have a look at some of these models. A lot of these are being called either system one models are being called open jevs. There are various names. We have Jev

[17:55] released 15th September. Long before this we had the glina models. So glina 2.5 which is the most recent one from Fino AI. I’ve been testing Gler 2.5 and we’ll talk about it in a minute. It does very well and it was released in August and and there were models before then. There was a Gler 2, Glardard, Glide Class, and the original Gliner as well, which was, you know, 2023, I think. They’ve been around for a while. And

[18:26] look at the size of these models. So, for the Gl 2.5 models, we’re looking at 74 to 300 million parameters. That’s tiny and very runnable on consumer hardware. Especially this 74 million parameter model. This is actually the model that we use in our test to play Doom. And in many instances, it actually outperformed Jev, right? Which is interesting at at the very least. Gliggard in our tests actually outperformed Jev

[18:59] on a few guardrail benchmarks. Very interesting. Again, we’re looking at 300 million parameters there. And then we have these new like copycats of Jev. these, you know, they’re getting a lot of attention online, but honestly, I haven’t seen much necessarily much value in these. They they work well in some areas. They do outperform in some areas, but for the most part, honestly, the Gler models seem to do better. You can see that here. So you know between these

[19:31] benchmarks I I showed before we can see okay Gliggard is doing very well on the guardrail focused benchmarks jailbreak and toxic chat doesn’t do so well on prompt injection in that case actually Jev and Leia seem to work better von is pretty close to jev on tool selection and does beat gl 2.5 but overall looking at the glider models so glide 2.5 or glig guard we get either you better performance [snorts] than

[20:02] other models or pretty close. And then you look at the model sizes of all these models and the glider models are just smaller and they’re faster. So really, you know, when testing these, I I’ve just found glider to be looking at the open source alternatives seems to be the better option if you’re going to s want those. But of course, you know, you can they’re open source, you can mix and match. There’s nothing wrong with that. So, Gliner is quite interesting. It is a family of models and you you see from

[20:34] the name, right? Gler, the original idea was actually named entity recognition and that’s what the original model did and it’s still what Gler 2.5, the most recent model does. It can still do that, but it can do other things as well. So the glider models they do things very differently but the things that they share is that they place labels and input text. So that’s kind of like questions and state into the input of a model. They are all

[21:06] birectional encoder models which is a a type of transformer which lacks the auto reggressive head that we see in LMS. Now here you can see the differences between glider and glide 2.5 but looking at the named entity recognition part of it but it doesn’t only support NE right that’s also a big difference between glina and glide 2.5 2.5 can do more by changing the schema that we input in this example

[21:38] we’re doing classification and this is how glider 2.5 would do classification in the the same structure as Jev And you can see that this is all defined using these special tokens that you see at the top. We have this P description L set stroke step text whatever else. All of those define what glide 2.5 is needing to be needing to do and the way to do it and the particular output structure to use. So we can see here P defines the

[22:10] task name and optionally any instructions around it. It’s the prompt. Okay, P means prompt. So before we were looking at jev and these were called questions. So we had the action advance and switch to shotgun questions. Then we have labels. So these are the the criteria that we saw before for two of the examples. And it’s a yes or no for the null type of Jev. Description here is where we for the criteria with Jev,

[22:41] we had a description for each one of our criteria. And this is how we do that here. So description we have to pass in the label right. So you can see in this example we have shoot aim left aim right and then the instructions for that label. And then finally we have set text that separates out our input schema the labels the questions from our state or the input text which follows the set

[23:12] text token. And then finally, when we do have multiple questions in parallel, multiple prompts, we do use this septstruct token to separate those out. So here you can see on the left how Jeff’s structure, questions, and state map to Gler 2.5’s structure on the right. Now that takes us to one of the drawbacks of using Gliner or from what I’ve seen any open source model versus Jev. Jev, as I mentioned before, one of

[23:44] the key things that makes Jev special is that calibrated probability. You can see here with Glider 2.5, the there isn’t really there’s no no guarantee of calibration here, right? Jev will say, hey, I want the action right now to be shoot and I am 98% confident in that. Glina on the other hand is one not giving us a probability distribution over all of our choices and further it’s

[24:14] not calibrated. So a score of 60 0.65 65 here for aim left doesn’t it doesn’t mean that this is correct 65% of the time we lose that calibrated probability that Jev gives us which in all fairness to Jev and type safe is a huge huge reason to use Jev and further you do need to use a different model for the different uh different use cases right you with Jev you can kind of use it for almost anything from the benchmarks that

[24:46] we saw whereas the glider models, you need to use glider 2.5, glide guard, whatever else. So, there are some drawbacks, but if you can handle those drawbacks, the latency improvement that you get is phenomenal. The server time, reported server time of Jeff, you’re looking at 88 milliseconds here on average. That’s for one classification for Doom. Looking at Glina 2.5 small, which is is the one

[25:19] I actually use for most of my tests and it performed very well. This [snorts] is on a MacBook M4 Pro running it on the GPU. We’re looking at 8 times faster, which is insane. It’s just so so much faster. It’s definitely something that you need to be thinking about when considering which one of these models to actually use. Looking at those times, everything is so much faster than using an LLM. But LM come with some benefits.

[25:49] Reason sequentially over tokens because they are auto reggressive. They’re generating these tokens. That means an LLM can use compute to think in a way, right? It’s slow, but an LM can use compute to reason and think and you know explore ideas. these classification models we’re talking about, you know, Jev, Glina, and the others, they can’t do that. They’re not autoaggressive. Yeah, it’s a pro and a con. So, returning to this idea of thinking fast

[26:21] and slow from Kimon’s work, our brains operate two systems, system one, system two. Although [clears throat] it’s not a perfect parallel, we can consider adopting a similar strategy, especially when it comes to Doom. What I’ve seen during benchmarking and and testing these is that when we use a fast model alone, so when we use Gal 2.5 or Jev, the model goes more tactical. It’s just like, okay, shoot, point, shoot, point, shoot, point, shoot. It doesn’t tend to think too much about, okay, maybe I

[26:52] should go get some weapons. Maybe I should go get some health, whatever else. But when we add an LM, so we had G GPT 5.6 6 Luna to the mix without reasoning. The LM can provide instructions, more strategic instructions to our faster system one model. So we can say, “Hey, go to that room and get the plasma gun. Go to that room, get a mediit, and the system one

[27:23] models for the most part will actually go and do it.” So, we’re taking that idea from Cayman of thinking fast and slow and actually applying it to to the Doom demos. And I’ll also flag that it’s not just us doing this. This is actually something that you see in in AI, particularly in robotics. I think probably different robotics companies are doing some level of this. But I know Figure Robotics I think with their Helix 2 model they explicitly described how

[27:54] they have system one and system 2. System 2 is their like reasoning LLM taking language instructions. System one is their faster smaller neuronet model for applying those instructions to movement goals or objectives. And then they actually also have a system zero. And then system zero is the it’s almost like the stabilizers for the robot. So it’s kind of like with humans in a in a way. So when we touch something that’s very hot, our body just jumps in and

[28:26] forces us to pull that away. We have the reflex to pull away from that. That is how I read their system zero. So we implement system one and two obviously in this example. So when you look at the the maps and these are the maps actually that Jev demoed. There is [clears throat] defender center, defender line and deadly corridor. These are like the twitchy point andoot maps. What we found is that the LM is not really needed in these scenarios. Gler

[29:00] and Jev work perfectly fine and adding an LM to coach those models doesn’t make a difference. So there wasn’t much point. The LM was generally not used. It was just idle most of the time. Every now and again it might you know give some input but nothing particularly useful. That changed however with the death map match. On the left we have just gler operating alone and glider is just like shooting point shoot point

[29:30] shoot. It’s not you know it’s not doing anything else. On the right, we see Gler with an LM coach, and it will do some things every now and again where it’s like spinning in a circle or something. But what you do see is that the LM is saying, “Go into the side room, get the plasma gun, fight the enemies.” Then when the player ends up low on health, the LM says, “Okay, go and get a

[30:01] medkit.” And and Gler does so. and [clears throat] then continues attacking the enemies. So the the score that we actually see from the Gler plus LLM coach system is far far better. Now how does that compared to Jev? This is where the latency difference between using an API and having a local model makes a big difference. When we have Glina everything is run locally and we have that you know 12 milliseconds response

[30:32] time. So Gler can just respond much faster to what is happening in the game compared to Jev. And so the Jev paired with LLM is okay, but it doesn’t actually make a big difference. So it’s a small increase in the in the average score with Gler. The score more than doubles as you as you can see, which is is pretty huge. And that’s because of this, right? the the number of decisions that the game gets from Glina is it’s

[31:04] 8.8 decisions per second. With Jev, because it’s hosted, you we’re getting 2.5 per second. And granted, I’m as far away as possible as I can possibly be while still being on Earth from where Jev is hosted, which is US West. But nonetheless, even if we half the time that Jev takes to respond there when we’re still nowhere near as fast as Gler. So this is where the approach of Jev doesn’t fully make sense to me. I

[31:35] think some of the qualities that make Jev very good make it hard for Typescape to capitalize on. Jev as a model has to be fast, which means it’s it needs to generally be smaller, which means open source can probably will probably catch up very quickly to where Jev is. They will probably find a way to bring calibrated probability into Jev because calibrated probability is not necessarily a new thing. It just hasn’t been used in open source as far as I’m

[32:05] aware. So in general, I’m not sure how deep type’s moat is with Chev although I think what they’ve done is amazing. One of the reasons I think it’s amazing is becauc is that they’ve taken smaller more specialist models and brought them to everyone and made made everyone aware that we can actually use these and I think that leads us to a less dystopian future with AI because if we just have these huge models and the only way you run these huge models is you’re a big

[32:37] company with loads of compute what we get is this future where intelligence is owned by just a few huge companies and the rest of us. We don’t have that, right? We can we can maybe pay those companies for some access to some of their intelligence, but we don’t we don’t own any of it. What Jeb has done has eaten a little bit of that lunch that the current, you

[33:08] know, main labs have and they’ve done it with a model that probably most of us will be able to run locally soon enough with a I expect soon to be released open- source alternative that matches Jev in performance and calibrated goodness. But beyond that, Jev, the open source alternatives, they absolutely deserve a place in our agentic workflows, in our AI stacks. I think the

[33:38] clearest place to start is guardrails and then beyond that tool selection, considering the nuance of of text generation and beyond there just exploring where we can actually use these new models [music] in AI and the broader software stack. So I think this is all very exciting and an amazing direction for AI to be going into. But that is it for now. [music] I hope this has all been useful, interesting, insightful. So thank you very much for watching and I will see you again in the

[34:10] [music] next one. Bye. [music] >> [music]