laya ou LLM gerativo: quando classificar vale mais do que escrever?

Fala aí, beleza? Se tu já montou aquele prompt de classificação de ticket, pediu pro modelo "responder apenas com JSON" e mesmo assim precisou de um try/except porque ele resolveu escrever uma explicação carinhosa antes da chave, tu conhece bem a dor desse post

A rotina é sempre a mesma: manda o texto pro LLM, pede uma categoria, recebe texto, parseia, valida contra o enum, trata o caso em que veio "Urgente (alta prioridade)" em vez de urgente, e reza

Acontece que existe outra categoria de ferramenta pra isso, e ela não é um LLM gerativo com temperatura zero

São os modelos de decisão tipada: em vez de escrever uma resposta, eles respondem uma PERGUNTA estruturada. O laya é o exemplo aberto mais recente disso, e é dele que a gente vai falar aqui =)

O que é o laya e por que ele não gera texto

O laya é um modelo de decisão open-weight publicado pela Convai Innovations. Ele recebe um estado (um texto, um e-mail, um ticket, um JSON) e responde perguntas tipadas sobre esse estado

O detalhe que muda tudo: ele é não autorregressivo

Que significa isso? Um LLM gerativo produz token por token, cada token olhando pros anteriores, até decidir parar. É por isso que ele pode escrever demais, escrever de menos, ou inventar um rótulo que não existe na tua lista

O laya resolve a pergunta em um único forward pass. Não existe token sendo cuspido, não existe string pra parsear, não existe "formato" pra alucinar. A saída já nasce no tipo que tu pediu

Se tu conhece a diferença entre um classificador clássico e um chatbot, é por aí a analogia. Só que aqui o classificador aceita a pergunta como parte da entrada, o que dá uma flexibilidade que o classificador de sempre não tinha

Onde o projeto vive e o que está publicado

O código fica no repositório NandhaKishorM/laya. Pesos e código saem sob licença Apache-2.0, então dá pra usar sem aquele drama de licença restritiva

No Hugging Face a Convai Innovations publicou três checkpoints:

• laya, o de inglês
• laya-multilingual
• laya-typed-decisions

O checkpoint em inglês tem 421M de parâmetros e usa ModernBERT-large como backbone (395M, bidirecional, fully fine-tuned), com uma decision head de 2 camadas transformer treinada do zero

O multilíngue tem 322M de parâmetros, roda em cima do mmBERT-base e cobre mais de 100 idiomas

Tome cuidado com um ponto antes de colocar isso em produção crítica: o projeto é MUITO novo. O repositório foi criado em 18 de setembro de 2026 e a versão mais recente publicada lá é a v0.3.4, de 20 de setembro de 2026

Projeto novo não é defeito, mas é informação de risco, e eu prefiro te falar isso agora do que tu descobrir depois

Os três primitivos tipados: choice, score e noul

Aqui mora a mudança de mentalidade. Tu para de escrever instrução e passa a modelar pergunta

O laya trabalha com três primitivos:

• choice: seleção categórica entre opções
• score: valor em uma escala ordinal
• noul: probabilidade binária, o famoso P(true)

E como é que uma tarefa real vira isso na prática?

Triagem de ticket vira choice

"Esse ticket é de cobrança, bug, dúvida de uso ou cancelamento?"

É um choice puro. A lista de opções é parte da pergunta, e a resposta sai dentro da lista. Não tem o cenário clássico do LLM devolvendo "provavelmente bug, mas pode ser dúvida de uso", que é exatamente a frase que quebra o teu parser

Quando a lista de categorias cresce muito, a modelagem começa a pesar, e aí vale pensar em estratégias pra listas grandes de opções antes de sair despejando duzentos rótulos numa pergunta só

Urgência vira score

"Qual a urgência desse e-mail, de 1 a 5?"

É score. Escala ordinal, resposta ordinal. Tu não precisa combinar com o modelo que ele "deve responder apenas o número", porque não existe caminho pra ele responder outra coisa

Spam vira noul

"Essa mensagem é spam?"

É noul: probabilidade binária. E repara que a saída não é um sim/não seco, é uma probabilidade. Isso importa MUITO pro teu roteamento, porque te dá um dial: acima de tanto, bloqueia; entre tanto e tanto, manda pra revisão humana; abaixo, passa direto

Com prompt de LLM tu até consegue pedir uma nota de confiança, mas ela costuma ser um número inventado com cara de número. Aqui a probabilidade é o produto principal do modelo, e mais pra frente eu explico por que o treino foi desenhado justamente pra ela ser honesta

laya vs LLM gerativo: comparação prática

Bora colocar lado a lado, porque no fim é uma decisão de engenharia, não de torcida

O resumo honesto dessa tabela: o laya ganha na parte chata e repetitiva, e perde feio na parte criativa

Se a tua tarefa cabe numa pergunta fechada e roda em volume, o argumento é forte. Se a tarefa pede texto novo, nem discussão tem

E contra outros classificadores? Os números publicados contra o Jev

Agora muda o adversário. Comparar com LLM gerativo é uma conversa, comparar com outro classificador é outra bem diferente

O benchmark publicado pelo projeto coloca o laya contra o Jev 1.13.0:

Na latência a diferença é gritante: cerca de 7,8x mais rápido

E só pra não misturar as coisas: esses 32,8 ms de p50 são desse benchmark contra o Jev, execução diferente dos 33 ms por pergunta medidos em GPU T4 que eu citei lá em cima. São medições distintas, não o mesmo número arredondado

Na acurácia de hard label e no AG News o laya também fica na frente

Mas repara na última linha, que é a que a maioria dos posts de hype esquece de mostrar: na soft accuracy contra a distribuição completa do teacher, o Jev leva a melhor, 0,580 contra 0,471

Traduzindo: acertar o rótulo final é uma coisa, reproduzir a distribuição de probabilidade inteira é outra. Se o teu sistema usa a distribuição pra decidir (roteamento com faixas, revisão humana em caso de dúvida), essa linha pesa

E tem uma ressalva que eu não posso deixar passar: os números do Jev vêm de publicação de terceiros e não foram medidos na mesma execução. Não é head to head na mesma run, então trata como indicação, não como veredito de laboratório

Se a tua dúvida hoje ainda é entre classificador dedicado e saída estruturada de LLM, vale resolver essa primeira, porque ela vem antes na árvore de decisão

Os dois pegadinhas do laya: zero-shot fraco e calibração ruim de fábrica

Essa é a seção que evita tu perder uma tarde

Sintoma

Tu instala, roda no teu caso sem ajustar nada, olha a acurácia e pensa "pô, e o hype?"

E quando olha as probabilidades, elas não batem com a realidade: o modelo diz 0,9 de confiança em coisas que ele erra com frequência incômoda

Causa

O 0,766 de hard label não é do modelo base em zero-shot. Ele é do checkpoint ajustado no split de treino do próprio benchmark

O base em zero-shot marca 0,362, abaixo da baseline de classe majoritária, que é 0,461. Ou seja, no cenário publicado, chutar sempre a classe mais comum ia melhor que o modelo cru

E a calibração sai ruim de fábrica mesmo: ECE médio de 0,466 no bruto

Solução

Duas coisas, nessa ordem

Primeiro, especializar o checkpoint na tua tarefa em vez de tratar ele como motor de decisão zero-shot. A conclusão publicada pelo próprio benchmark é essa: o laya é uma base rápida pra especializar

Segundo, refitar uma temperatura por tipo de pergunta. Com esse refit o ECE médio cai de 0,466 pra 0,081, que é outro mundo

E por que vale a pena caprichar nessa parte? Porque o treino do laya usa RLCD com recompensa baseada em strictly proper scoring rule, de forma que a recompensa esperada é maximizada ao reportar probabilidades honestas

Ou seja: a probabilidade ali foi desenhada pra ser sinal, não enfeite. Seria uma pena jogar fora por não calibrar

Como prevenir

Simples: não monte a expectativa do projeto em cima de zero-shot

Se o teu plano era "baixo, aponto pra minha base e uso", muda o plano antes de escrever o relatório interno prometendo números

Quando classificar vale mais do que escrever (e quando não vale)

A favor

• Roteamento de tickets em volume: pergunta fechada, milhares de vezes por dia, latência importa
• Moderação: noul com faixa de probabilidade resolve boa parte do fluxo
• Triagem de e-mail: categoria com choice e urgência com score, dois campos, zero parse
• Scoring de leads: escala ordinal é literalmente o formato do score
• Gate antes de chamar um LLM caro: decide rápido e barato se aquele item merece o modelo grande. Esse aqui é o padrão que mais rende na conta
• Rodar local em Apple Silicon: existe um port MLX da comunidade, o laya-mlx, publicado por mizorewww. Repara que é port independente, não lançamento oficial da Convai Innovations. As latências medidas por lá são de 13,4 ms de mediana ponta a ponta pra decisão curta em inglês e 7,4 ms com o checkpoint multilíngue, em M3 Max

Contra

• Resumo de texto
• Redação de resposta pro cliente
• Extração de campos livres (aqueles que não cabem em enum nenhum)
• Raciocínio multi-passo
• Tarefa nova sem NENHUM dado rotulado, porque aí tu cai direto na pegadinha do zero-shot

O padrão híbrido

Na real, a pergunta "laya ou LLM?" quase sempre tem a resposta "os dois, em papéis diferentes"

O laya decide: categoria, urgência, se é spam, se vale escalar

O LLM escreve: a resposta ao cliente, o resumo da thread, o texto que vai pro humano

Cada um fazendo o que faz bem, e o modelo caro sendo chamado só quando realmente precisa. Massa, né?

Como testar o laya no seu caso em poucos minutos

Bora ver na prática. Passo a passo enxuto, só com o que dá pra afirmar com segurança

1. Instale o pacote pelo PyPI

pip install laya

Um pacote só cobre todos os checkpoints. O erro comum deste passo: procurar um download separado de pesos junto da instalação. Não tem. Nada é baixado antes de carregar um modelo

2. Importe o Router, que é o ponto de entrada recomendado

from laya import Router

router = Router(preload=True)

O Router detecta idioma e despacha pro checkpoint adequado. O erro comum aqui: assumir que tu precisa escolher o checkpoint na unha logo de cara, quando o caminho recomendado já faz esse despacho

3. Decida quando os pesos vão baixar

Os pesos vêm do Hugging Face Hub no primeiro uso. Se tu não quer pagar esse custo dentro da primeira requisição real, carrega antes:

router.preload()

O erro comum deste passo: subir o serviço em produção, receber o primeiro request e cronometrar o download do Hub junto com a inferência. Aí o número de latência sai horrível e a culpa não é do modelo

4. Modele a sua tarefa como pergunta tipada

Pega UMA tarefa que hoje roda em prompt e escreve ela como choice, score ou noul. Se ela não cabe em nenhum dos três, provavelmente ela é tarefa de LLM gerativo mesmo, e tudo bem

5. Especialize e refite a temperatura antes de julgar

Esse é o passo que quase todo mundo pula. O erro comum: medir o modelo base em zero-shot, comparar com o teu prompt atual e concluir que não presta. O benchmark publicado já mostra que esse caminho decepciona (0,362 contra baseline de 0,461) e que a calibração precisa do refit por tipo de pergunta pra sair de 0,466 de ECE pra 0,081

Contexto: o outro lado da moeda

Falar de modelo de decisão tipada faz mais sentido quando tu tem na cabeça o que os modelos gerativos grandes estão entregando hoje do lado deles

Pra isso, tem esse vídeo no canal sobre o retorno do Fable 5, o modelo mais poderoso da Anthropic:

Veredito: o laya é base para especializar, não substituto do seu LLM

Pra saída tipada em volume e com latência baixa, o argumento do laya é sólido

Não tem texto pra parsear, não tem espaço pra alucinar formato, não tem cobrança por token e não tem API hospedada pra assinar: tu baixa os pesos do Hugging Face e roda local, sob Apache-2.0. Somando os 33 ms por pergunta e os 7,2 ms em lote medidos em T4, a conta de infra fica bem diferente da de um prompt de classificação rodando o dia inteiro num provedor

Mas o veredito honesto é o que o próprio benchmark publicado conclui: ele é uma base rápida pra especializar, não um motor de decisão zero-shot

E tem a ressalva de maturidade, que eu repito de propósito: repositório criado em setembro de 2026, v0.3.4. É cedo. Quem coloca isso num fluxo crítico hoje precisa ter plano B e monitoramento de verdade

Se tu quer texto novo, raciocínio encadeado ou extração livre, o LLM continua sendo a ferramenta. Ninguém precisa escolher lado nessa

Conclusão

O próximo passo é bem concreto e tu consegue fazer essa semana

Escolhe UMA tarefa de classificação que hoje roda em prompt

Reescreve ela como pergunta choice, score ou noul

Mede acurácia e latência contra a tua solução atual, com o checkpoint especializado e com a temperatura refitada, não no zero-shot cru

Só depois disso tu decide. Decisão com número medido é outro papo…

O código e a documentação estão no repositório NandhaKishorM/laya, que eu linkei lá em cima

E aí, tu tem alguma classificação rodando em prompt hoje que caberia numa pergunta tipada? Conta nos comentários que eu quero ver os casos de uso de vocês =)

até o próximo post!