Laya vs Jev na prática: zero-shot, fine-tuning e o custo real de um decision model open-source

A TypeSafe anunciou Jev em 15 de setembro de 2026, apresentando seu primeiro “System One Model”. No histórico oficial do Laya no Hugging Face, o commit marcado como “Initial release” é de 18 de setembro de 2026. Três dias separam esses registros públicos — um intervalo entre anúncio e registro de release, não uma medida do tempo de desenvolvimento. Fontes: anúncio da TypeSafe e registro inicial de release do Laya.

Quando concluí a avaliação de Jev 1.13, Laya já era uma alternativa de pesos abertos que valia investigar. Aprender uma ferramenta era apenas o primeiro passo: o trabalho mais durável foi conseguir avaliar uma abordagem nova com método e medir se ela melhora o sistema.

No mesmo held-out do Ops Triage AI, Laya saiu de 8/70 tuples corretas zero-shot para 60/70 após domain adaptation. Jev havia acertado 66/70 sem treinamento específico no domínio. A pergunta interessante é o que muda quando podemos alterar os pesos de um modelo — e qual responsabilidade vem com esse controle.

Antes de comparar: o que é um decision model?

Jev é um modelo de IA não generativo especializado em decisões estruturadas. Recebe estado ou contexto em linguagem natural e retorna decisões tipadas com distribuições de probabilidade, em vez de gerar uma sequência aberta de tokens como um LLM generativo convencional.

Continua sendo IA. A TypeSafe chama essa categoria de System One Models; é terminologia da empresa, não uma taxonomia acadêmica universal consolidada. Aqui uso também “modelo probabilístico de decisão” ou “structured decision model”.

LLM generativo
texto → geração token a token → texto

Decision model
estado + conjunto de escolhas → distribuição → decisão tipada

Isso muda a interface e o trabalho que pedimos ao modelo. Para triagem, podemos definir categoria, prioridade e risco como escolhas fechadas. Recebemos valores que o software conhece, sem pedir um parágrafo para depois extrair um enum.

Um LLM também pode produzir saídas estruturadas. A diferença não é apenas tamanho ou formato JSON: o decision model é orientado a pontuar o espaço de decisões, em vez de gerar texto livre. Restringir esse espaço reduz problemas de parsing e de valores fora do schema. Uma escolha válida ainda pode estar semanticamente errada.

Onde Laya entra

Laya ocupa um espaço semelhante com código e pesos abertos sob Apache 2.0, inferência não-autoregressiva, self-hosting e possibilidade de fine-tuning. O checkpoint inglês geral usa ModernBERT-large com uma cabeça de decisão: 421 milhões de parâmetros, segundo o model card da revision utilizada.

Nosso experimento fixou convaiinnovations/laya, revision 55cf4c4ebb4ebe31b2550e8bdf3bd21b99753851, com laya==0.3.23. A release do runtime foi publicada em 01/10/2026. Versão da biblioteca e revision dos pesos são identidades diferentes; ambas foram congeladas.

Esse checkpoint base não é laya-typed-decisions, que já recebeu treinamento especializado em outros workflows. Também não usamos o checkpoint multilíngue. “Zero-shot” aqui significa sem treinamento específico no nosso domínio, não ausência de treinamento prévio do modelo.

Um decision model em uma arquitetura real

Uma demonstração de criação de sites por voz que acompanhei ajudou a tornar esse papel concreto. Ela descrevia uma biblioteca com mais de 1.000 assets/componentes e Jev como camada de escolha de ações e assets. O fluxo conceitual era:

voz → transcrição em tempo real → adaptação/correção de contexto
    → decision model → seleção de assets/ações → UI

Esse é um relato da demonstração observada, sem URL verificável no contexto do projeto nem valor de benchmark.

Jev não precisa gerar o site. Um modelo de fala pode transcrever, outra camada normalizar o contexto e um decision model escolher entre ações permitidas. Modelos de fala, LLMs e modelos de decisão podem coexistir em papéis diferentes; o código continua responsável por executar e validar as ações.

O benchmark que já tínhamos

O ativo mais importante era um held-out congelado de 70 tickets sintéticos em inglês, já usado para baseline determinístico, Ollama e Jev 1.13. Mantivemos tickets, labels e definições de métricas. Exact tuple só conta acerto quando categoria, prioridade e risco estão corretos ao mesmo tempo.

Dividimos a investigação em duas perguntas:

Jev não foi executado novamente. Usamos seu resultado histórico congelado, via OpenRouter, com typesafe/jev-1.13, resolvido para typesafe/jev-1.13-20260917.

O experimento B é assimétrico: Jev recebeu zero exemplos de treinamento específicos do domínio; Laya recebeu 1.120 tickets TRAIN. A taxonomia é a mesma, mas os prompts e os caminhos de inferência também diferem. As perguntas de Laya foram ajustadas ao seu orçamento de tokens antes do freeze e mantidas entre A e B. Estamos avaliando generalização sem adaptação e capacidade de especialização, com exposições distintas ao domínio.

Experimento A: Laya zero-shot

No checkpoint geral, zero-shot, nesta taxonomia e neste held-out, o resultado foi:

O padrão mais evidente foi 40/40 prioridades LOW previstas como MEDIUM. Antes de atribuir isso ao modelo, a auditoria examinou opções, ordem, índices, mapping, serialização e normalização. Não encontrou bug de integração que invalidasse o resultado: as probabilidades arquivadas apontavam MEDIUM como top-1, coerente com a escolha publicada.

A auditoria usou outputs parseados, com escolhas e probabilidades copiadas; a resposta nativa bruta não foi preservada byte a byte. Esse material permite conferir o mapping: MEDIUM já era a escolha do modelo, sem conversão LOW → MEDIUM no adapter.

Por que isso não contradiz o benchmark publicado

O material que motivou a investigação mostrava resultados melhores. O model card de laya-typed-decisions explica a diferença: esse checkpoint foi fine-tuned nos workflows do benchmark correspondente. O card separa o checkpoint especializado do base e avisa que os números de Jev foram publicados por terceiros, sem medição no mesmo run.

As métricas publicadas pertencem a outro dataset, protocolo e checkpoint, e medem decisões individuais em vez da nossa tupla por ticket. Essa distinção levou à segunda pergunta: a baixa qualidade zero-shot era uma limitação estrutural ou falta de adaptação ao domínio?

Experimento B: separar aprendizado de avaliação

Criamos 1.120 tickets TRAIN e 280 VALIDATION, também sintéticos, a partir da taxonomia operacional. O gerador determinístico usou cenários autorados, sem LLM e sem ler o held-out ou seus erros para construir exemplos.

TRAIN — 1.120 tickets → altera pesos
VALIDATION — 280 tickets → seleciona checkpoint
HELD-OUT — os mesmos 70 tickets → avaliação final depois do freeze

O held-out ficou fora da geração do dataset, training, validation, checkpoint selection, thresholds, calibration e hyperparameter tuning. Era uma continuação sobre um benchmark cujo resultado agregado já conhecíamos; o arquivo e seus erros ficaram isolados da criação dos novos dados.

VALIDATION compartilha famílias de cenários com TRAIN, embora os textos sejam distintos. É útil para selecionar um checkpoint, mas não representa uma população real independente.

O fine-tuning partiu do mesmo checkpoint base de A. Usamos labels determinísticos como targets one-hot, diferentes das distribuições suaves de um professor probabilístico no exemplo oficial de Laya. Não fizemos ajuste posterior de temperatura: os candidatos usaram temperatura 1,0. O método não é uma replicação exata do benchmark externo e pode influenciar a confidence.

Selecionamos o checkpoint pela maior exact tuple em VALIDATION; os desempates predefinidos consideravam macro-F1, Brier médio e época mais antiga. A época 4 foi selecionada. O Freeze 2, commit 00a9a64, fixou dados, checkpoint, código, inferência e thresholds antes da única avaliação oficial adaptada, com 70/70 respostas válidas e zero falhas.

A infraestrutura necessária para adaptar o modelo

O host local tinha quatro vCPUs, cerca de 4 GB de RAM e nenhuma GPU. Um fine-tuning completo nesse ambiente não era razoável. Usamos uma GPU temporária NVIDIA RTX A5000, 24 GB de VRAM, Python 3.11 e PyTorch 2.5.1 com CUDA 12.1.

Foram quatro epochs com mixed precision — autocast fp16 e pesos mestre fp32 — e gradient accumulation para controlar o uso de memória.

Essa execução trouxe uma evidência concreta da minha direção em ML Systems / AI Infrastructure: além de treinar, precisei verificar se a contabilidade do treinamento correspondia ao que realmente acontecia.

Na primeira execução, o GradScaler pulou um optimizer update, mas o scheduler avançava mesmo assim. Detectamos a anomalia, corrigimos o avanço do scheduler para acompanhar apenas updates aplicados, preservamos a execução inicial como artifact e repetimos o treinamento antes de abrir o held-out adaptado.

Na execução oficial corrigida, registramos 420 tentativas de update, 413 optimizer updates reais, sete skips do GradScaler e 413 scheduler steps. A execução corrigida virou candidata por validade metodológica, não porque apresentasse uma accuracy mais conveniente. Só então fizemos seleção, freeze e avaliação final.

O salto: 11,43% → 85,71%

No mesmo held-out:

O padrão LOW → MEDIUM caiu de 40/40 para 0/40. A adaptação mudou de forma clara o comportamento nesse domínio, como registra o relatório final público.

O fine-tuning não resolveu tudo. Restaram duas categorias, quatro prioridades e cinco riscos incorretos, com sobreposição entre campos: dez tuples erradas. O recall de prioridade HIGH/CRITICAL caiu de 13/14 no zero-shot para 12/14 no adaptado. Melhorar a média não garante melhorar cada erro de severidade.

Jev e Laya adaptado: interpretar a assimetria

Jev mostrou forte generalização out-of-the-box neste benchmark. Laya mostrou quanto controle open source oferece quando podemos adaptar o modelo ao domínio. Os 94,29% de Jev vieram sem os nossos tickets TRAIN; Laya passou de 11,43% zero-shot para 85,71% com essa adaptação. O recall de risco HIGH foi maior no Laya adaptado, mas o denominador é de apenas sete exemplos.

Confidence continuou sendo um problema

No Laya adaptado, a média de answer_confidence — probabilidade top-1 arredondada — quase saturou:

Mesmo assim, dez das 70 tuples estavam erradas. Brier e ECE descrevem este pequeno conjunto; não certificam calibração em tráfego futuro.

O gate exploratório exigia que as três answer_confidence alcançassem o threshold. De 0 até 0,90, manteve 70/70 tickets e exact tuple de 85,71%. Em 0,95 e 0,99, manteve 69/70 e exact tuple de 86,96%. Quase não filtrou erros. Nenhum threshold foi escolhido ou ajustado com esses resultados.

Isso retoma o contraponto do artigo de Jev: confidence alta não significa automaticamente probabilidade confiável de estar correto. Jev reporta sua própria confidence; Laya distingue answer_confidence de uma confidence baseada em entropia. Essas semânticas distintas impedem comparar diretamente os valores.

O gap entre aprendizado e generalização

A sequência 100% → 92,50% → 85,71%, loss de TRAIN registrada como zero na última época e confidence saturada mostram ajuste muito forte aos dados de treinamento. Como VALIDATION ainda compartilha famílias de cenários com TRAIN, a queda no held-out merece atenção.

Interpreto o fit perfeito e as diferenças entre splits como sinais compatíveis com memorização e overconfidence. A amostra é pequena para determinar a gravidade desse efeito ou estimar o gap em produção.

Local não significou automaticamente mais rápido

Os timings de Laya incluem tokenização, inferência das três perguntas, parsing e validação; a média por request não inclui load do modelo. O held-out adaptado rodou em CPU, não na A5000 de treinamento.

Nessa CPU específica, self-hosted Laya não foi automaticamente mais rápido que chamar Jev remotamente. Como as infraestruturas e datas diferem, esses timings descrevem os caminhos observados. A latência histórica do caminho híbrido com Ollama também mede outro percurso, além da inferência standalone.

Open-source não significa custo zero

O run histórico de Jev reportou US$ 0,003789618 por 70 requests. É custo de uso via API naquela execução, não uma projeção atual de preços ou custo total de operação.

Para inferência de Laya, houve US$ 0 de cobrança externa por token/request. CPU/GPU, RAM/VRAM, energia, cloud e operação continuam existindo. O custo da CPU não foi monetizado por falta de tarifa e medição disponíveis.

No treinamento, a taxa registrada do Pod era aproximadamente US$ 0,27 por GPU-hora, ou US$ 0,28/h com disco do container. As tarefas medidas — base VALIDATION, primeira execução anômala e treino/avaliação corrigidos — somaram 1.523,51 segundos, cerca de 25min24s.

O relatório estima US$ 0,1185 para essas tarefas à taxa com disco. Não é o total faturado do Pod: exclui setup, startup do provedor e tempo ocioso; o tempo total faturado e a invoice estavam indisponíveis. A avaliação oficial em CPU não acrescentou tempo de GPU.

Laya elimina a cobrança por token, mas transfere custo e responsabilidade para infraestrutura e operação. O trabalho de preparar dados, investigar uma anomalia e gerenciar artifacts também faz parte da escolha, mesmo sem uma medida monetária de tempo de engenharia.

O verdadeiro trade-off: conveniência e controle

Jev mostrou o valor de um decision model que funciona muito bem sem treinamento específico neste domínio. Laya mostrou outra vantagem: pesos abertos permitem alterar o modelo quando zero-shot não basta.

Open source não nos deu automaticamente melhor accuracy, menor latência ou melhor calibration. Deu controle. Isso significou assumir dataset, training, GPU, checkpoint, calibração, versionamento, deployment, observability e custo operacional. Neste experimento exercitamos dados, treinamento e avaliação; deployment e operação de um serviço adaptado continuam trabalho futuro.

Essa é a decisão de engenharia: quanto vale adaptar o comportamento e hospedar o modelo sob nossas restrições, frente ao esforço necessário para sustentar essa capacidade?

Limitações

• HELD-OUT sintético, em inglês, com apenas 70 tickets de um domínio específico; nenhum tráfego real ou validação em produção.
• Uma execução oficial por protocolo; Jev é um resultado histórico, sem repetição para medir variância.
• TRAIN e VALIDATION também sintéticos; VALIDATION compartilha famílias de cenários com TRAIN.
• Jev e Laya tiveram exposição diferente ao domínio, perguntas diferentes e caminhos de inferência distintos.
• Hardware e datas de medição diferentes; latências não equivalentes.
• Confidence com semânticas diferentes; análises de calibração e coverage descritivas, com amostras pequenas.
• Outputs nativos brutos não foram preservados byte a byte na auditoria zero-shot.
• O checkpoint adaptado de aproximadamente 843 MB não está no Git público; estão publicados seu hash, tamanho, metadados e resultados, não os pesos para download.
• Custo total faturado do Pod indisponível; a estimativa cobre apenas tarefas medidas.
• Jev e Laya continuam evaluation-only no Ops Triage. Nenhum foi integrado à HybridPolicy por causa desses experimentos.

O que faria em um sistema real

Eu começaria com tickets reais rotulados e consentidos para o uso, separando cenários, fontes e períodos para evitar que VALIDATION seja apenas outra redação de TRAIN. Definiria critérios de aceitação por severidade e custo do erro antes de abrir uma nova avaliação final.

Calibração e thresholds precisariam de dados separados e representativos, com revisão humana e fallback avaliados como parte da política. Repetiria os protocolos para medir variância e compararia latência, throughput, load, memória e custo nos caminhos de serving que realmente pretendo operar.

Antes de integrar, versionaria pesos e configuração junto aos dados e ao código, verificaria licença e limites de contexto e prepararia monitoramento de drift, erros e rollback. Uma decisão tipada simplifica a integração; a confiabilidade ainda depende do sistema ao redor.

Evidências e reprodutibilidade

Os números vêm dos relatórios e artifacts públicos do Ops Triage AI, consultados no commit e8c75f0. Os links abaixo fixam esse snapshot. O README nesse commit ainda resume apenas o zero-shot; a evidência de domain adaptation está no relatório final e nos artifacts.

• Zero-shot: relatório A e resultado JSON.
• Adaptação: protocolo e Freeze 2.
• Resultado B: held-out JSON e journal de tentativas.
• Treinamento e seleção: execução corrigida, seleção por VALIDATION e metadados dos pesos.
• Auditoria: mapping e outputs arquivados e primeira execução preservada.
• Referência histórica: relatório Jev 1.13 e artifact Jev.
• Projeto upstream: GitHub oficial do Laya e licença da release utilizada.