Laya ou regex e listas de palavras: quando a regra simples já resolve?

Nem todo problema de classificação pede modelo

E muita condição if bem escrita resolve melhor que qualquer rede neural, sério 🙂

Fala aí, beleza? A Convai Innovations soltou o Laya, um modelo de decisão de pesos abertos com licença Apache 2.0, que chegou prometendo classificar tickets, e-mails e traces de agentes

Só que regex e listas de palavras continuam aí: rápidas, transparentes e sem precisar de um único dado de treino

Então bora decidir com calma quando vale Laya ou regex, sem cair na armadilha de colocar modelo em problema de formato fixo haha

O que é o Laya e por que ele não é um LLM?

O Laya é um modelo de decisão aberto e não autorregressivo

Que diabos é isso? Um LLM normal gera texto token a token, um atrás do outro

O Laya não gera texto nenhum: ele recebe um estado (um e-mail, um ticket de suporte, um trace de agente ou um objeto JSON) mais perguntas tipadas, e devolve decisões com probabilidades e confiança por pergunta

Os tipos de pergunta são três:

• choice: escolher um rótulo
• score: dar uma nota de intensidade
• yes/no: responder sim ou não como probabilidade

E tudo isso sai de uma vez, numa única passada do modelo (o tal do forward pass)

Quais checkpoints do Laya existem?

Foram publicados 3 checkpoints:

• Base em inglês: ModernBERT-large, 421M parâmetros, contexto de 512
• Multilíngue: mmBERT-base, 322M parâmetros, contexto de 1.024 tokens e mais de 100 idiomas (página do laya-multilingual)
• laya-typed-decisions: a versão ajustada com fine-tune

A latência divulgada é de cerca de 39,5 ms por classificação no checkpoint inglês e 32,8 ms no multilíngue, numa GPU Tesla T4

Nada de PC da Nasa, né? 😀

Como instalar o Laya?

O pacote Python sai direto do pip:

pip install laya

Se quiser pegar as correções mais recentes do runtime:

pip install -U laya

Pra que a Convai indica o Laya?

Os casos de uso apontados pela própria Convai são processamento de faturas, roteamento de tickets, moderação, guardrails e observabilidade de traces de agentes

Ou seja: a camada de classificação que fica ao redor de um LLM

Quando regex e listas de palavras já resolvem

Aqui vai a parte que pouca gente que vende modelo gosta de admitir…

Regex funciona muito bem em formato rígido e padrão bem definido

Telefone, e-mail, CEP, ISBN, número de cartão, datas ISO: tudo isso tem formato fixo, e uma expressão regular captura sem drama

E ela traz três vantagens que modelo nenhum entrega do mesmo jeito:

• É rápida: roda na hora, sem carregar peso de modelo
• É transparente: dá pra auditar linha a linha e explicar EXATAMENTE por que algo casou
• Não precisa de dado de treino: escreveu, testou, tá valendo

Pensa numa auditoria de compliance que te pergunta por que aquele registro foi marcado

Com regex tu aponta o padrão e pronto, com um modelo tu aponta uma probabilidade

Então a mensagem honesta é essa: se uma condição simples cobre o caso, colocar um modelo no meio só adiciona custo e opacidade

Antes de trocar if/else por um modelo, vale olhar se a regra atual está errando de verdade ou se tá tudo certo e é só o hype falando mais alto hehe

Onde a regra simples quebra: paráfrase, ironia e outro idioma

Beleza, agora o outro lado da moeda

A regra é ótima até o significado depender de contexto

Por que regex falha com paráfrase?

Se liga nesse exemplo: "charged twice" e "my payment processed two times" dizem a MESMA coisa (cobraram duas vezes)

Mas um padrão escrito pra primeira frase pode pegar só ela, e deixar a segunda passar batido

E aí tu cai no ciclo de ir adicionando variação atrás de variação…

Um modelo que lê o estado inteiro e responde uma pergunta tipada (tipo um choice de "motivo do ticket") é justamente a proposta pra esse cenário

E ironia e sarcasmo?

Na ironia, o sentido pretendido costuma ser diferente do literal

"Nossa, que atendimento maravilhoso, esperei só três dias" tem palavras positivas e intenção negativa, e uma regra baseada em palavras não enxerga isso

Na literatura, modelos de ML (um SVM, por exemplo) superam técnicas baseadas em regras usadas como baseline na detecção de sarcasmo

Tome cuidado aqui: não existe benchmark público confirmado do Laya especificamente com ironia ou sarcasmo, então o ponto é que regra sofre nesse caso, não que o Laya resolve com garantia

Listas de palavras em outro idioma funcionam?

Funcionam até certo ponto

Listas de palavras deixam muita coisa de fora, principalmente em idiomas menos comuns, onde as listas abertas são esparsas

E tem a ofuscação: cada variação tipo letra trocada por número entra como item novo, e a lista cresce sem nunca ficar completa

É aqui que um checkpoint multilíngue, como o de mais de 100 idiomas do Laya, tenta cobrir o buraco que a lista deixa

De novo: também não há benchmark público confirmado do Laya em português, então isso é pra avaliar com os seus dados, não pra assumir

Regex, listas de palavras e Laya lado a lado

Bora ver tudo junto numa tabela?

Quanto o Laya acerta sem fine-tune?

Essa é a limitação que a própria documentação admite, e é o dado mais importante do post

No benchmark de decisões tipadas (2.000 decisões em quatro fluxos):

Percebeu? No zero-shot, os dois checkpoints ficam ABAIXO do baseline de classe majoritária

Traduzindo: chutar sempre a classe mais comum dá resultado melhor que usar o modelo cru

Só com fine-tune ele dá o salto pra 0,766

O caminho híbrido: regra no formato, modelo no contexto

Na prática, a resposta raramente é "um ou outro"

Em sistemas de NER (reconhecimento de entidades) em produção, é comum dividir o trabalho:

• Regex cuida das entidades de formato bem definido
• Modelo de ML cuida dos casos ambíguos e do contexto

Dá pra aplicar a mesma lógica no Laya como camada de classificação ao redor de um LLM, seja em roteamento, guardrails ou traces de agentes

A regra filtra o óbvio primeiro: se o ticket tem número de pedido, a regex extrai; se tem CPF, a regex pega

O modelo entra só no que exige leitura: o motivo real da reclamação, a intenção escondida atrás da ironia, a mensagem que chegou em outro idioma

É como ter um estagiário que resolve o que é checklist e só chama o sênior quando o caso é cabeludo 😛

E falando em agentes: pra começar do zero no assunto de agente queimando contexto à toa, este vídeo do canal apresenta o FastContext e mostra essa discussão de eficiência na prática

Veredito: quando vale trocar a regra pelo Laya?

Fica na regra quando:

• O padrão é fixo e bem definido
• A auditoria importa e tu precisa explicar cada decisão
• A regra atual já acerta o que precisa acertar

Considera o Laya quando:

• Paráfrase, ironia e múltiplos idiomas estão derrubando a tua regex
• A lista de palavras virou um monstro que nunca fica completa
• Tu tem dados pra especializar o modelo

Esse último ponto não é detalhe

A própria documentação pede pra tratar o Laya como uma base rápida pra especializar, não como um oráculo zero-shot

E os números confirmam: sem fine-tune ele fica abaixo da classe majoritária

Então se a ideia era baixar e sair usando sem dado nenhum, será? A regra provavelmente te serve melhor

É a mesma lógica de decidir quando o modelo aberto resolve: a ferramenta certa depende do problema, não do hype

Conclusão: comece pela regra, suba para o modelo quando ela falhar

Recapitulando o caminho:

1. Lista onde a tua regra atual erra: separa os casos de paráfrase, de idioma e de ironia que estão passando. O erro comum aqui é olhar só os acertos e achar que tá tudo bem
2. Mantém regex no que é formato fixo: telefone, e-mail, CEP, ISBN, cartão e datas ISO continuam com a regra
3. Se os erros de contexto justificarem, instala o Laya:

pip install laya

4. Avalia o caminho de fine-tune a partir do checkpoint adequado: o base em inglês se o teu texto é só em inglês, o multilíngue se tem outros idiomas no meio. O erro comum deste passo é julgar o modelo pelo zero-shot e esquecer que o salto de desempenho vem da especialização

Regra simples não é gambiarra, é engenharia bem feita quando o problema cabe nela

E modelo não é mágica, é ferramenta pra quando a regra não dá mais conta =)

Até o próximo post!