Jeva, concorrente do Jev: este modelo de 4B nunca escreve uma palavra. Eu o testei

Ver no idioma original →

Autoria: Prompt Engineer 48 · 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: Jeva - the Jev Competitor: This 4B Model Never Writes a Word. I Tested It · Canal: Prompt Engineer 48 · 06:24 · Assistir no YouTube

Tópicos: Inferência e otimização de modelos, Modelos de IA, Modelos locais e open source

Resumo

O vídeo testa o Jeva 4B, um modelo que classifica e pontua opções sem gerar texto, medindo velocidade, estabilidade à reordenação, detecção de casos sem opção adequada e reutilização em cache. Nos testes do apresentador, as respostas foram estáveis e a reutilização acelerou as consultas, mas o modelo frequentemente escolheu “nenhuma opção” mesmo quando havia uma resposta correta. O teste foi pequeno e não reproduziu os resultados do artigo, que são apresentados separadamente. O vídeo recomenda verificar o comportamento de “nenhuma opção” com os próprios dados antes de usar o modelo em produção.

Pontos-chave

• Jeva 4B seleciona entre alternativas, avalia afirmações e atribui pontuações sem gerar explicações em texto.
• O modelo usa uma base Qwen 3.5 4B e exige Linux, GPU Nvidia e kernels CUDA 12.8, conforme a seção de instalação.
• Após a compilação inicial dos kernels, as três perguntas de exemplo foram respondidas em cerca de 300 milissegundos, com zero tokens de saída.
• Em 30 reordenações das opções, o apresentador observou zero mudanças na resposta, embora ela tenha sido frequentemente “nenhuma opção”.
• O modelo identificou bem exemplos fora do tema, mas também rejeitou solicitações de suporte que tinham uma categoria correspondente.
• Desativar a opção “nenhuma opção” melhorou um exemplo de cobrança duplicada, mas dois de quatro pedidos reais foram categorizados corretamente.
• A reutilização em cache reduziu o tempo de uma consulta de 102 para 50 milissegundos no teste apresentado.
• Com 63 opções, o modelo classificou incorretamente um pedido de bloqueio de cartão como compra de criptomoeda.
• Os resultados do apresentador são testes pequenos e não equivalem a um benchmark nem reproduzem todas as avaliações do artigo.

Capítulos

Início	Capítulo	Resumo
00:01	Apresentação do Jeva 4B	O vídeo introduz o modelo, suas funções de classificação e pontuação e as regras que orientam sua concepção.
01:41	Instalação e primeiros testes	O apresentador executa o modelo em uma GPU alugada e testa sua velocidade e o número de tokens gerados.
03:16	Estabilidade e comportamento da opção nula	Os testes mostram respostas estáveis à reordenação, mas também uma tendência a indicar que nenhuma opção se aplica.
04:49	Cache, escala e conclusão	O apresentador mede o ganho de velocidade com cache e o desempenho com mais opções, e recomenda validar o comportamento com dados próprios.

Citações

Não escreveu uma única palavra. — 00:01

A linha de uso mostra: zero tokens de saída. — 02:43

Isso prova que é estável, não que está certo. — 03:16

No meu pequeno teste, ele é muito bom em dizer “nenhuma opção” e um pouco ansioso demais para fazê-lo. — 04:16

Confira o comportamento da opção nula com seus próprios dados primeiro, ou desative-a. — 06:24

Conceitos e entidades

• Jeva 4B (modelo): Modelo de 4 bilhões de parâmetros testado no vídeo para selecionar opções, avaliar afirmações e atribuir pontuações sem gerar texto.
• Jev 1.13 (modelo): Modelo usado como comparação no artigo, que teria mudado a resposta em 17% dos itens de escolha mencionados.
• Qwen3.5 4B (modelo): Modelo-base indicado para o Jeva 4B.
• RunPod (empresa): Serviço usado pelo apresentador para alugar uma GPU e executar o modelo.
• reutilização em cache (conceito): Reaproveitamento de opções já processadas para reduzir o tempo e o processamento de consultas subsequentes.
• opção nula (conceito): Possibilidade de o modelo indicar que nenhuma das alternativas disponíveis se aplica.

Tradução completa (pt-BR)

00:01 Esta é uma única solicitação para um modelo de 4 bilhões de parâmetros. Ele me deu três respostas: uma probabilidade de interrupção de 0,93, a equipe como engenharia e uma pontuação de impacto de 1,98 em 2. Tudo em cerca de 300 milissegundos, e ele não escreveu uma única palavra. Certo, neste vídeo vou testar o Jeva 4B. E guardem o número de “nenhuma das opções acima”, porque esse me surpreendeu. Este é o Jeva, de Chi Lee e Sin Chuan, da National University of Singapore. O artigo é o 2610.18773 no arXiv.

00:37 A página do modelo diz que ele seleciona entre alternativas, verifica se uma afirmação é verdadeira ou pontua algo com base em uma rubrica, sem gerar explicações longas. Ele usa como base o Qwen 3.54B. O código está no GitHub, com cerca de 75 estrelas quando gravei isto, licença Apache 2.0, um contribuidor e nenhum lançamento até agora, então considere-o em estágio inicial. A ideia se baseia em quatro regras. A ordem das opções não deve alterar a resposta. Você pode adicionar mais opções sem uma nova camada de saída. “Nenhuma se aplica” é uma resposta válida

01:09 E as opções que você já processou devem poder ser reutilizadas. Agora, vale lembrar que isso não vai rodar no meu laptop. A seção de instalação diz que é preciso Linux, GPU Nvidia e Python 3.12 com kernels CUDA 12.8, e eu estou no Windows com uma GPU de 8 GB. Um modelo de 4 bilhões de parâmetros em BF16 já ocupa cerca de 8 GB, antes de qualquer outra coisa. Então, aluguei um pod na RunPod. Eu queria a placa de 24 GB mais barata, a 4090, por 34 centavos por hora, mas

01:41 não havia nenhuma disponível, e a A40 com 48 GB, por 59 centavos por hora, estava disponível. Então, usei essa. Instalei o PyTorch 2.9.1 e os requisitos, executei o comando doctor, e você pode ver que ele diz que o forward do kernel passou e que a lista de problemas está vazia. Carregar o checkpoint levou cerca de 20 segundos, e o pico de memória que medi foi de 10 GB. Aqui está o exemplo do readme. Você fornece um estado, que é o texto do chamado, e depois perguntas tipadas.

02:12 A primeira é null, uma resposta de sim ou não. A segunda é choice: escolha uma entre billing, engineering ou general. A terceira é score, com uma rubrica de 0 a 2. O chamado diz que a página de login de produção retorna 503 e que todos os clientes estão bloqueados. Você pode ver uma probabilidade de interrupção de 0,93, engineering com 0,64 e general com 0,34, o que indica um pouco menos de certeza do que eu esperava, além de um impacto de 1,98. A primeira chamada levou 36 segundos

02:43 porque os kernels são compilados, então não se esqueça de fazer uma chamada de aquecimento. Depois disso, tudo, com as três perguntas, levou cerca de 300 milissegundos. E veja a linha de uso: zero tokens de saída. Ele lê as opções e o estado, sem gerar texto. O artigo afirma que não houve nenhuma inversão nas permutações testadas. Então, testei por conta própria: a mesma solicitação, “meu pagamento foi cobrado duas vezes”, e três candidatos. Embaralhei a ordem dos candidatos 30 vezes. Nenhuma inversão, e a maior alteração em qualquer probabilidade foi de cerca de 7 × 10 elevado a

03:16 menos 11, então isso é ruído de ponto flutuante, vale lembrar. A resposta que ele continuou dando foi “nenhuma”, o mesmo null excessivamente ansioso que você verá no próximo teste. Então, isso prova que ele é estável, não que está certo. Para comparação, a página mostra outro modelo, Jev 1.13, que inverte a resposta em 17% dos itens de choice. Eu só testei o Jeva. Portanto, essa comparação vem do artigo, não de mim. Agora, o número que pedi para vocês guardarem: o Jeva pode dizer que nenhuma opção se aplica e fornecer uma estimativa de cobertura separada. Dei a ele

03:46 três equipes — billing, engineering e shipping — e seis solicitações. Três são problemas reais de suporte, três não, como uma receita de bolo de chocolate e quem ganhou a partida de futebol. As três solicitações fora de contexto retornaram null, com 0,93, 0,93 e 0,99. Essa parte é muito boa. Mas veja as três primeiras. “Fui cobrado duas vezes pelo meu pedido” tem a equipe billing bem ali, e ele disse “nenhuma”, com 0,99. A do pacote foi a mesma coisa, 0,99. Só a falha do aplicativo teve uma divisão honesta: 0,52 para null.

04:16 Achei que talvez o problema fosse a forma como escrevi, então testei 16 intenções bancárias. Usei o estilo do Banking77 que, segundo o artigo, eles usam. Com null desativado, “fui cobrado duas vezes” foi corretamente classificado como cobrança duplicada. Com null ativado, ele diz “nenhuma”, com 0,92. Duas das minhas quatro solicitações reais foram correspondidas: chegada do cartão e alteração do PIN. Então, no meu pequeno teste, ele é muito bom em dizer “nenhuma”, e um pouco ansioso demais para fazê-lo. Essa formulação é minha, e foram cerca de 10 solicitações, então isso não é um benchmark. O artigo relata uma AUC de 98,66% para detecção de null no Banking77, e eu

04:49 não reproduzi essa configuração. A última propriedade é a reutilização. Carreguei quatro políticas longas de suporte e fiz três perguntas. A primeira, sem cache, levou 755 milissegundos e codificou 427 tokens de opções. As mesmas quatro opções de novo: 50 milissegundos, zero tokens codificados. Depois, um novo subconjunto com três delas: 50 milissegundos, com 319 tokens servidos pelo cache. A mesma solicitação com o cache desativado levou 102 milissegundos. Então, isso é 2,05 vezes mais rápido, e a

05:21 resposta não mudou: cancelamento nas duas vezes. O artigo fala em cerca de duas vezes mais rápido para decisões de tipo e 27,98 vezes para o conjunto de documentos longos, com reutilização total. Só consegui reproduzir o teste pequeno, então não posso confirmar o maior. Também verifiquei como o desempenho escala com o número de opções. Com o cache desativado, cinco candidatos levaram 101 milissegundos. 16 candidatos, 100. 32 candidatos, 154. E 63 candidatos, 300 milissegundos. Com 63, ele escolheu “compra de criptomoedas” para uma solicitação de bloqueio de cartão,

05:53 o que está errado. Então, minha lista de intenções quase duplicadas é um teste difícil. Não tirem conclusões definitivas disso. O artigo testa até 2048 opções, com 69,88% de precisão e latência mediana de 12 segundos. E isso não foi algo que eu executei. Então, para quem é isso? Se você encaminha chamados, ferramentas ou intenções e quer probabilidades, não parágrafos, com uma resposta estável mesmo quando a ordem muda, ele funciona como anunciado nos meus testes. Se você precisa se comprometer com uma resposta

06:24 quando há uma resposta válida, verifique primeiro o comportamento de null com seus próprios dados ou desative null. Os pesos estavam disponíveis abertamente quando os baixei, sem necessidade de login, embora a página do projeto diga que o acesso é controlado. Se você procura GPUs baratas e confiáveis, eu uso a RunPod, e o link está na descrição. Encerrei o pod assim que consegui as imagens. Digam o que querem que eu teste em seguida, e vejo vocês em outro vídeo.

Transcrição original

[00:01] This is one request to a 4 billion parameter model. It gave me three answers and an outage probability of 0.93, the team descended to, which is engineering, and an impact score of 1.98 out of two. All in about 300 milliseconds, and it did not write a single word. All right, in this video I test Geva 4B, and hold on to the none of the above number, because that one surprised me. So, this is Geva from Chi Lee and Sin Chuan at the National University of Singapore, paper 2610, 18773 on Archif.

[00:37] The model page says it selects among alternatives, checks whether a statement is true, or scores something against a rubric without generating lengthy explanations. It sits on a Qwen 3.54B backbone. The code is on GitHub, about 75 stars when I recorded this, Apache 2.0 license, one contributor, and no releases yet, so treat it as early. The idea is four rules. The order of the options should not change the answer. You can add more options without a new output layer. None apply is a valid

[01:09] answer. And options you have already processed should be reusable. Now, mind you, this is not going to run on my laptop. The install section says Linux and Nvidia GPU and Python 3.12 with CUDA 12.8 kernels, and I’m on Windows with an 8 GB GPU. A 4 billion parameter model in BF16 is already around 8 GB before anything else. So, I rented a pod on RunPod. I wanted the cheapest 24 GB card, the 4090 at 34 cents an hour, but there was

[01:41] no stock, and the A40 with 48 GB at 59 cents an hour was available. So, I used that. I installed PyTorch 2.9.1, the requirements, and ran the doctor command, and you can see it says the kernel forward passed, and the issues list is empty. Loading the checkpoint took about 20 seconds and the peak memory I measured was 10 GB. Here is the example from the readme. You give it a state, which is the ticket text, and then typed questions.

[02:12] The first is null, a yes or no. The second is choice, pick one of billing, engineering, or general. The third is score with a rubric from 0 to 2. The ticket says the production login page returns 503 and all customers are blocked. You can see outage probability 0.93, engineering at 0.64, with general at 0.34, which is a bit less sure than I expected, and impact 1.98. The very first call took 36 seconds

[02:43] because the kernels compile, so mind you do a warm-up call. After that, the whole thing with all three questions took about 300 milliseconds. And look at the usage line output tokens, zero. It is reading the options and the state, not generating text. The paper claims zero flips under tested permutations. So, I tried it myself, same request, my payment was taken twice and three candidates. I shuffled the candidate order 30 times. Zero flips and the largest change in any probability was about 7 * 10 to the

[03:16] minus 11, so that is floating point noise, mind you. The answer it kept giving was none, the same overeager null you will see in the next test. So, this proves it is stable, not that it is right. For comparison, the page shows another model, Jev 1.13, flipping on 17% of choice items. I only tested Jeva. So, that comparison is from the paper, not from me. Now, the number I told you to hold on to, Jeva can say none apply with a separate coverage estimate. I gave it

[03:46] three teams, billing, engineering, and shipping, and six requests. Three are real support issues, three are not, like a chocolate cake recipe and who won the football match. All three off-topic ones came back null at .93, .93 and .99. That part is really good. But look at the first three. I was charged twice for my order has a billing team right there and it said none at .99. The parcel one, same thing .99. Only the app crash got an honest split, .52 null.

[04:16] I thought maybe my wording was the problem, so I tried 16 banking intents. The style of the banking 77 said the paper uses. With null turned off, I got charged twice picks duplicate charge correctly. With null turned on, it says none at .92. Two of my four real requests got matched card arrival and change pin. So in my small test, it is very good at saying none and a bit too eager to say it. This is my own wording and about 10 requests, so it is not a benchmark. The paper reports 98.66% null detection AUC on banking 77 and I

[04:49] did not reproduce that setup. The last property is reuse. I loaded four long support policies and asked three questions. The first one, the cold one, took 755 milliseconds and encoded 427 tokens of options. The same four options again, 50 milliseconds, zero tokens encoded. Then a new subset of three of them, 50 milliseconds with 319 tokens served from the cache and the same request with the cache off was 102 milliseconds. So that is 2.05 times faster and the

[05:21] answer did not change, cancellation both times. The paper says about two times on type decisions and 27.98 times on its long document set at full reuse. I only reproduce the small one, so I can’t confirm the big one. I also checked how it scales with the number of options. Cache off, with five candidates it took 101 milliseconds. 16 candidates, 100. 32 candidates, 154. And 63 candidates, 300 milliseconds. At 63, it picked crypto purchase for a

[05:53] card block request, which is wrong. So, my list of near duplicate intents is a hard test. Take that lightly. The paper tests up to 2048 options at 69.88% accuracy and 12 seconds median latency. And that is not something I ran. So, who is this for? If you route tickets, tools, or intents, and you want probabilities, not paragraphs with a stable answer under reordering, it works as advertised in my tests. If you needed to commit to an answer

[06:24] when one exists, check the null behavior on your own data first, or turn null off. The weights were open when I downloaded them without a login, even though the project page says access controlled. If you’re looking for cheap and reliable GPUs, I use RunPod, and the link is in the description. I pulled the pod down as soon as I had the footage. Let me know what you want me to test next, and I’ll see you in another one.