NUS lança Jeva-4B: arquitetura de decisão com opção nula e cache de candidatos
Segundo o New AI Era (新智元), o xML Lab da Universidade Nacional de Singapura propõe Jeva: um backbone Qwen3.5-4B com um bloco de decisão que gera diretamente uma escolha, null ou uma pontuação. O artigo relata zero taxa de inversão de ordem e 69,88% de precisão com 2.048 candidatos; os pesos foram publicados no Hugging Face.
O que mudou
Segundo reportagem do New AI Era (新智元) de 26 de outubro de 2026 (data correspondente a 1792987620000 no original), o xML Lab da Universidade Nacional de Singapura publicou um artigo e código propondo a arquitetura Jeva para tarefas de decisão, além do modelo Jeva-4B. A reportagem afirma que o modelo usa Qwen3.5-4B como backbone com um bloco de decisão leve: um codificador compartilhado representa separadamente a requisição e as opções candidatas, e o bloco de decisão lê todo o conjunto de candidatos e atualiza apenas o estado da requisição, de modo que as representações das opções podem ser reutilizadas em cache enquanto o julgamento atual é recalculado a cada vez. A reportagem lista quatro objetivos de design: distinguir "qual candidato é melhor" de "o conjunto tem alguma resposta aceitável", estimando o segundo com uma probabilidade de cobertura separada e permitindo saída null; agregar de forma simétrica sobre o conjunto de candidatos, para que as probabilidades sigam a identidade do candidato e não a posição na lista; aplicar a mesma regra de pontuação a cada candidato, tratando o conjunto completo diretamente em vez de eliminações em múltiplas rodadas; e armazenar em cache as representações semânticas das opções e suas projeções de camada, reutilizando-as quando o conjunto de candidatos é recomposto. O mesmo cálculo suporta três tipos de saída: Choice, Noul (probabilidade de a proposição ser verdadeira) e Score. Os resultados experimentais citados na reportagem vêm todos do artigo: em 3.080 requisições construídas a partir do BANKING77 (16 candidatos por requisição, incluindo 588 casos sem resposta), a AUROC de detecção de null foi 98,66%, contra KEV-BF16 93,61%, InternDecision-4B 84,27% e JevK5 79,44%; em 600 amostras Choice, testando ordem original, ordem inversa e até três permutações aleatórias, a precisão original do Jeva e a precisão de "acertar em todas as ordens testadas" foram ambas 76,67%, sem inversões de decisão observadas, enquanto os controles tiveram taxas de inversão de 17,00%, 22,67% e 26,17%; nas configurações de 32 a 2.048 candidatos do ToolRet, com 2.048 candidatos a precisão foi 69,88% e a latência mediana por requisição em uma única H200 foi 12,04 segundos, contra 67,47% e cerca de 28,35 segundos do JevK5; com 83 perguntas fixas e candidatos expandidos de 32 para 2.048, o Jeva acertou 58 dessas perguntas em todas as escalas, contra 48 do JevK5 e 7 do CLM; no experimento de documentos longos MLDR, quando todos os candidatos estavam em cache a latência mediana da requisição caiu de cerca de 2,10 segundos para 75,1 milissegundos, e a reportagem afirma que nenhuma mudança de decisão foi observada sob diferentes condições de cache. Todos esses números são autorrelatados no artigo e não foram reproduzidos de forma independente aqui.
Impacto para desenvolvedores
Para desenvolvedores, o Jeva não é mais um modelo de chat genérico, mas uma forma que acopla "ordenação + recusa + cache" ao caminho de inferência, o que altera o design de integração de vários tipos de sistema. Primeiro, o contrato de saída muda: o conjunto de candidatos é a entrada de uma requisição e o modelo retorna uma distribuição ou pontuação com null, não um trecho de texto a ser reprocessado. Migrar uma cadeia de prompts atual de "peça ao modelo para gerar um JSON escolhendo um item" para esse tipo de modelo exige definir na camada de serviço os IDs dos candidatos, o limiar de probabilidade de cobertura e o comportamento de fallback para null, além de registrar em log o conjunto completo de candidatos de cada requisição; caso contrário, não será possível saber depois se uma recusa ocorreu porque os candidatos não eram adequados ou por erro do modelo. Segundo, o cache desce da camada de prompt para a camada de arquitetura: a reportagem diz que o que se armazena são representações das opções, não respostas, o que é diretamente relevante para cenários como cláusulas de políticas, bases de documentos longos e critérios de pontuação fixos, em que "os candidatos são relativamente estáveis e as perguntas mudam constantemente", mas implica que a chave de cache deve estar vinculada à versão do modelo, ao tipo de decisão e às configurações de codificação; se o modelo ou a configuração de codificação mudar, o cache antigo deve ser invalidado. Terceiro, o tamanho do conjunto de candidatos não precisa mais ser controlado por eliminações em múltiplas rodadas: a reportagem afirma que 2.048 candidatos ainda são comparados no mesmo cabeçalho de decisão, o que simplifica o fluxo de reordenação após a recuperação, mas também vincula diretamente a latência ao número e ao comprimento dos candidatos; a latência mediana de 12,04 segundos indica que grandes conjuntos de candidatos ainda são tarefas offline ou assíncronas, não chamadas interativas. Cabe notar que os nomes dos modelos de controle na reportagem (como Jev-1.13.0, JevK5 e CLM) e as informações de configuração das baselines são limitados; os leitores não devem extrapolar esses números comparativos para sua própria distribuição de dados ou para conjuntos de candidatos em chinês.
Integração e avaliação
A seguir há sugestões e análises condicionais, não fatos da reportagem. Decisão um: substituir a "seleção generativa" atual por uma interface de cabeçalho de decisão depende de seus candidatos serem enumeráveis e de a recusa precisar ser explícita. Se o negócio realmente tem casos em que "nenhum item do conjunto se aplica" (por exemplo, atribuição de tickets ou roteamento de intenções), o design null-aware da reportagem merece verificação separada: construa um lote de requisições da sua distribuição real em que "não há candidato adequado", misture com requisições que têm resposta, varra o limiar e registre a AUROC e a recall sob uma taxa fixa de falsa recusa (por exemplo, 5%); só vale a pena arcar com a reformulação da interface se essa métrica for claramente superior à solução atual baseada em prompts. Se seus candidatos sempre incluem a resposta correta, o ganho dessa capacidade é limitado e a prioridade de reformulação deve ser reduzida. Decisão dois: adotar o cache de opções depende do padrão de reutilização da biblioteca de candidatos. Primeiro, analise um lote de requisições em produção e calcule a proporção de sobreposição entre conjuntos de candidatos (o exemplo da reportagem é a sobreposição gradual do tipo ABC, BCD, ACD); se a sobreposição for alta e os textos dos candidatos longos, meça, seguindo a ideia da reportagem, a diferença de latência da requisição entre os casos de acerto total e de nenhum acerto no cache; ao mesmo tempo, é obrigatório verificar se a decisão da mesma requisição é consistente antes e depois de um acerto no cache, pois a reportagem apenas afirma que nenhuma mudança de decisão foi observada em seus experimentos, o que não garante equivalência nos seus dados. Se os candidatos forem quase sempre novos, a complexidade da camada de cache pode superar o ganho. Decisão três: o limite superior do número de candidatos deve ser definido pelo orçamento de latência, e não apenas pela precisão. A reportagem apresenta 69,88% de precisão e 12,04 segundos de latência mediana com 2.048 candidatos; esses dois números devem ser vistos em conjunto: se seu cenário exige resposta em segundos, é preciso medir a curva de precisão em conjuntos menores, encontrar o ponto em que a precisão começa a cair e então decidir entre ampliar os candidatos ou manter o corte atual da recuperação. Na avaliação, fixe as perguntas e aumente gradualmente os candidatos (a abordagem da reportagem, com 83 perguntas de 32 a 2.048, pode ser emprestada diretamente) e registre a proporção de "acertos em todas as escalas", o que expõe mais a estabilidade do que a precisão em um único ponto. Decisão quatro: a robustez à ordem deve ser um item de regressão fixo antes do lançamento. Segundo o método da reportagem, teste a ordem original, a ordem inversa e várias permutações aleatórias no mesmo lote de amostras, alinhe os resultados pela identidade do candidato e não pela posição, e registre a taxa de inversão. Em cenários que envolvem conformidade, risco ou pontuação, a taxa de inversão é uma métrica que merece mais atenção do que a precisão média.
Limites e pontos a confirmar
Todos os números experimentais deste artigo vêm de resultados do paper repassados pelo New AI Era (新智元), sem reprodução independente; a configuração e os detalhes de treinamento dos modelos de controle estão incompletos na reportagem, e comparações entre modelos exigem cautela. A reportagem não informa os termos específicos da licença sob a qual os pesos do Jeva-4B foram publicados no Hugging Face; poder baixar os pesos não significa que seja permitido uso comercial ou redistribuição, e é preciso verificar por conta própria o model card e o texto da licença antes de implantar. A reportagem também não traz informações sobre serviço de API, preço ou disponibilidade hospedada; se houver qualquer forma de chamada, vale o que o publicador declarar. Além disso, os experimentos da reportagem se concentram em tarefas em inglês como BANKING77, ToolRet e MLDR, e o desempenho em conjuntos de candidatos em chinês, terminologia setorial e documentos longos é desconhecido. Cabe destacar: a versão Jeva-4B não está atualmente no catálogo de modelos do KimiSeek; não há entrada no KimiSeek que corresponda exatamente a essa versão, e qualquer afirmação sobre sua disponibilidade via API se refere apenas ao publicador, não a este site; para realizar tarefas de decisão semelhantes no KimiSeek, avalie separadamente os modelos já listados no site e use a página de preços como referência.