Como avaliar o Laya com seu próprio conjunto de testes (e parar de confiar no achismo)

Fala aí, beleza? Se liga nisso: a acurácia de benchmark do Laya não diz se ele acerta nas SUAS decisões 🙂

O Laya é a família de modelos de decisão open source da Convai Innovations, com pesos e código sob licença Apache 2.0, lançada em 18 de setembro de 2026 (poucos dias depois do Jev)

E ele tem um detalhe que muda tudo: não gera texto

Tu manda um estado (um ticket, um e-mail, um texto ou um JSON) mais perguntas tipadas, e ele devolve respostas tipadas com probabilidades, tudo num único forward pass

Nada de parse, nada de caçar um ‘sim’ perdido no meio de um parágrafo haha

Então dá pra medir acerto de forma objetiva: a resposta bateu com o gabarito ou não bateu

É isso que a gente vai montar aqui, um conjunto de avaliação seu, pra avaliar o Laya com dado real e sair do achismo

Por que os números oficiais do Laya não bastam pro seu caso?

Os números oficiais são bons, mas cada um responde uma pergunta diferente

E aí mora a pegadinha 😛

O 0,766 é massa, só que tem contexto: o checkpoint foi ajustado no split de treino do próprio benchmark (1.200 casos e 6.000 decisões)

Ou seja, ele estudou pra aquela prova

Quando o mesmo modelo encara casos rotulados à mão em domínios onde não foi treinado, o acerto cai pra 59,6%

E o base sem ajuste nenhum fica pouco acima do chute aleatório

Isso não é defeito escondido, tá? O próprio projeto orienta tratar o Laya como uma base rápida pra especializar, não como oráculo zero-shot, e recomenda fazer fine-tune e recalibrar nos seus dados

Então a pergunta ‘o Laya é bom?’ não tem resposta genérica

A pergunta certa é: ele é bom no MEU fluxo? E só um conjunto seu responde isso

E se você ainda está na dúvida entre usar um modelo pronto ou treinar seu próprio classificador, esse mesmo conjunto é o que vai decidir a briga

O que você precisa antes de começar a avaliar:

Nada de PC da Nasa aqui, a lista é curta

• Amostras reais do seu fluxo: tickets, e-mails, mensagens ou JSON que já passaram pelo seu sistema
• Alguém que conheça o domínio: quem vai rotular precisa saber qual é a decisão certa, não só achar
• Uma planilha ou arquivo simples: pra registrar o gabarito e o que o modelo respondeu
• O runtime instalado: roda na sua própria GPU ou CPU

A instalação é via pip:

pip install laya

E pra atualizar:

pip install -U laya

Sobre os checkpoints, são três, todos Apache 2.0 (os detalhes ficam no model card do Laya no Hugging Face):

• Inglês, com 421M de parâmetros (base ModernBERT-large)
• Multilíngue, com 322M de parâmetros (base mmBERT-base, mais de 100 idiomas)
• laya-typed-decisions, ajustado em fluxos de decisão tipada

O ajustado fica em convaiinnovations/laya-typed-decisions e a demo fica no Space convaiinnovations/laya-demo

Dica: usa a demo pra testar a ideia antes de instalar qualquer coisa

Joga uns três ou quatro casos seus lá e vê se as perguntas fazem sentido, isso economiza tempo depois 🙂

E se o plano é rodar isso num servidor seu mais pra frente, vale entender fila e batching numa VPS antes de sair jogando volume

Passo a passo: montando seu conjunto de avaliação do Laya

Bora ver na prática?

Cada passo tem o erro que mais aparece nele, porque é justamente ali que a avaliação vira achismo de novo

Passo 1: separar amostras reais (as difíceis também)

Pega casos do seu fluxo de verdade, e não só os bonitinhos

O caso típico o modelo provavelmente acerta, o que te interessa é o ticket ambíguo, a mensagem com ironia, o pedido raro que aparece uma vez por mês

Outro ponto: respeita o contexto do checkpoint

São 512 tokens no checkpoint inglês e 1.024 no multilíngue, então aquele e-mail gigante com histórico inteiro de conversa pode não caber

O erro comum deste passo: montar o conjunto só com casos típicos (e aí a nota fica linda e mentirosa) e incluir textos longos que estouram o contexto sem perceber

Passo 2: escrever as perguntas no tipo certo

O Laya trabalha com três tipos de pergunta:

• choice: escolhe uma opção entre várias (ex.: qual a categoria do ticket?)
• score: posiciona um valor numa escala ordinal (ex.: qual a urgência?)
• noul: devolve a probabilidade de algo ser verdadeiro (ex.: o cliente está pedindo reembolso?)

Que escala ordinal? É uma escala com ordem, tipo baixa, média, alta, onde ‘alta’ é mais que ‘média’, mas a distância entre elas não é um número exato

Escolher o tipo certo já é metade da avaliação

O erro comum deste passo: usar choice onde um noul resolve. Se a decisão é sim ou não, uma pergunta de verdadeiro ou falso é mais direta do que uma lista de opções

Passo 3: rotular à mão ANTES de ver a saída do modelo

Aqui é o coração do negócio

Quem conhece o domínio lê cada caso e escreve a resposta esperada, sem ter visto o que o Laya respondeu

Uma linha do seu gabarito pode ficar assim (esse formato é SEU, pra organizar os rótulos, não é formato de entrada do Laya):

{
  "id": "ticket-0042",
  "estado": "Paguei duas vezes o mesmo pedido e ninguém me responde",
  "pergunta": "Qual a categoria do ticket?",
  "tipo": "choice",
  "opcoes": ["cobrança", "entrega", "técnico", "outro"],
  "resposta_esperada": "cobrança",
  "gravidade_se_errar": "grave"
}

Se dois rotuladores discordam num caso, anota isso

Muitas vezes o caso é ambíguo até pra humano, e cobrar do modelo algo que nem vocês concordam não faz sentido

O erro comum deste passo: rotular olhando a resposta do Laya. Você acaba concordando com ele sem perceber e contamina o gabarito (já vi muita avaliação morrer assim…)

Passo 4: definir erro grave versus erro tolerável

Nem todo erro custa igual

Mandar um ticket de ‘dúvida’ pra fila de ‘sugestão’ é chato, liberar uma ação errada num fluxo de cobrança é outra conversa

O próprio Laya dá uma referência boa: a saída de agir ou escalar foi treinada com uma matriz de custo

Fazendo a conta: agir compensa quando o ganho esperado supera o custo de escalar

Com probabilidade p de acerto, agir vale 4p – 3, e isso só passa de -0,5 quando p passa de 62,5%

Abaixo disso, mandar pra um humano sai mais barato

Agora adapta ao seu negócio: se errar no seu fluxo custa MUITO mais que isso, o ponto em que vale agir sobe junto

Marca cada caso do conjunto como grave ou tolerável, do jeito que está no campo gravidade_se_errar do exemplo

O erro comum deste passo: tratar todo erro com o mesmo peso e olhar só a acurácia, como se trocar duas categorias parecidas fosse igual a aprovar uma ação perigosa

Passo 5: rodar e registrar TUDO que ele devolve

Com o conjunto rotulado, roda os casos no Laya e anota o resultado ao lado do gabarito

Cada chamada leva cerca de 33 ms, então dá pra rodar o conjunto inteiro várias vezes sem sofrimento

A planilha pode ter estas colunas:

A coluna de agir ou escalar vem da saída act/escalate da cabeça de decisão, que estima se aquela decisão deveria ir pra um humano

O erro comum deste passo: guardar só a resposta final. Sem a probabilidade você perde justamente o que vai usar nos passos 7 e 8

Passo 6: comparar versões da pergunta com o conjunto FIXO

Agora vem a parte divertida: reescrever a pergunta e ver se melhora

Muda o texto, muda as opções, troca um choice por um noul… e roda de novo no mesmo conjunto

Se for mexer nas opções de um choice, cuidado: perguntas choice degradam com mais de 20 opções

Se a sua lista está enorme, provavelmente vale quebrar em duas perguntas

O erro comum deste passo: mudar a pergunta e o conjunto ao mesmo tempo. Aí você não sabe se melhorou por causa da pergunta ou porque os casos ficaram mais fáceis

Passo 7: olhar os casos de fronteira, não a média

A média é confortável, mas ela esconde onde o modelo erra feio

Filtra a planilha e olha com carinho:

• Casos com probabilidade perto do limiar de decisão
• Todos os erros marcados como graves
• A acurácia separada por tipo de pergunta

Pra ter uma referência, a acurácia oficial por tipo é esta:

Se no seu conjunto um tipo está muito abaixo dos outros, já tem uma pista de onde mexer

O erro comum deste passo: celebrar a média e ignorar os poucos casos onde ele erra de forma grave. Um erro grave frequente derruba o fluxo inteiro, por mais bonita que seja a média

Passo 8: checar a calibração antes de confiar na probabilidade

Que calibração? É o quanto a probabilidade bate com a realidade: se o modelo diz que está muito confiante num grupo de casos, a taxa de acerto nesse grupo deveria acompanhar essa confiança

A métrica usada é a ECE (erro de calibração esperado), e quanto menor, melhor

Aqui tem um detalhe importante: a ECE de 0,081 anunciada só aparece depois do ajuste de temperatura por domínio e tipo de pergunta

No bruto, a ECE é 0,213 no checkpoint base e 0,144 antes do ajuste

Tradução: a confiança crua do modelo não é garantia, ela precisa ser recalibrada nos seus dados

Na prática, agrupa os casos do seu conjunto por faixa de probabilidade e confere se a taxa de acerto de cada faixa acompanha a confiança que ele declarou

O erro comum deste passo: usar a probabilidade crua como verdade e montar regra de automação em cima dela. Tome cuidado com isso!

Em quais fluxos vale montar esse conjunto de avaliação?

Os 108 casos rotulados à mão que citei lá em cima cobrem nove domínios, e eles são ótimos exemplos do que dá pra avaliar

Pra cada um, o que separa erro grave de tolerável muda bastante:

• Tickets de suporte: errar a subcategoria é tolerável, deixar de marcar um ticket urgente é grave
• Reviews: confundir neutro com levemente positivo é tolerável, ler reclamação séria como elogio é grave
• Guardrails de agentes: bloquear algo inofensivo é chato, liberar uma ação que deveria ser barrada é grave
• Incidentes: errar a equipe responsável atrasa, subestimar a severidade é grave
• Moderação: remover algo aceitável incomoda, deixar passar conteúdo proibido é grave
• E-mail: errar a pasta é tolerável, jogar um e-mail importante como irrelevante é grave
• Entregas: errar o motivo do atraso é tolerável, não detectar uma entrega extraviada é grave
• Leads de vendas: errar o nível de interesse é tolerável, descartar um lead quente é grave
• Mensagens de clínica: errar o assunto da mensagem é tolerável, não identificar algo que precisa de atenção imediata é gravíssimo

E aqui entra outro motivo pra ter um conjunto fixo: comparar melhorias de forma justa

Um exemplo da comunidade: a abordagem de Mixture of Experts do Vishal Mysore sobre o Laya (projeto dele, não da Convai) chegou a 67,3% contra 59,6% nos mesmos 108 casos e 312 respostas, tá tudo no repositório layaMOE

Só dá pra afirmar que melhorou porque o conjunto foi o mesmo

Com o seu vale a mesma lógica: nova versão da pergunta, novo checkpoint, nova técnica, tudo passa pela mesma prova 😀

Próximo passo: do conjunto de avaliação ao ajuste fino

Recapitulando: o conjunto rotulado é o que separa decisão confiável de achismo

Com ele você sabe onde o Laya acerta, onde erra feio, se a confiança dele bate com a realidade e se uma mudança realmente melhorou alguma coisa

E tem mais: esse mesmo conjunto vira a base pra especializar e recalibrar o Laya nos seus dados, que é exatamente o que o próprio projeto recomenda

O caminho prático fica assim:

1. Começa pequeno, com casos reais do seu fluxo (incluindo os difíceis)
2. Testa as perguntas na demo do Space antes de instalar
3. Instala com pip install laya e mede versão contra versão no mesmo conjunto

Sem fórmula mágica, sem prompt secreto, só gabarito bem feito e paciência pra olhar os erros haha

Faça o teste com o seu fluxo e depois me conta como foi, beleza?

Até o próximo post! =)