Presets do laya: para que servem router, guard, moderation e triage?

Montar do zero um conjunto de perguntas tipadas pra classificar ticket, prompt ou comentário é chato pra caramba

Você fica ali escolhendo se a pergunta é escolha ou nota, se a régua vai de 0 a 3 ou de 1 a 5, que nome dar pro campo… e ainda nem começou a resolver o problema real

O laya resolve parte disso na origem

Ele é um modelo de decisão aberto da Convai Innovations, publicado sob licença Apache 2.0 em 18 de setembro de 2026

E a sacada dele é não gerar texto: você manda um estado e perguntas tipadas, ele devolve escolhas, notas ou probabilidades

Melhor ainda: o pacote já vem com presets prontos pra quatro fluxos que praticamente toda aplicação com IA precisa em algum momento

O que é um preset de perguntas no laya

Primeiro o porquê, depois o como

O laya não conversa com você

Ele recebe um estado (um texto, um e-mail, um ticket, um documento JSON) e uma lista de perguntas tipadas, e responde cada uma delas de forma estruturada

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

São três tipos de pergunta:

• choice: escolhe uma opção entre as que você deu, com probabilidade por opção
• score: aponta o nível esperado dentro de uma régua ordenada, junto com a distribuição
• noul: devolve P(verdadeiro) calibrada pra uma afirmação sim/não

Se você conhece aquele esquema de validação de schema (tipo um Zod ou um Pydantic descrevendo o formato da resposta), a ideia é parecida: você declara o formato e recebe de volta exatamente aquilo, sem parsing de texto no meio

E o que é o preset então?

É só uma função do módulo que retorna essa lista de dicionários já pronta, no formato de schema que o predict aceita

Nada mágico, nada de prompt secreto

É um atalho pra você não escrever a lista na mão

E tem um detalhe que muda o jogo: todas as perguntas de um preset são respondidas em um único forward pass, sem geração de texto

O README traz como referência 33 ms para uma pergunta e 7,2 ms por pergunta quando roda em lote, medidos em uma GPU T4

Ou seja, dá pra colocar isso no caminho crítico da requisição sem chorar de latência 🙂

Router, guard, moderation e triage lado a lado

Antes de entrar em cada um, se liga no panorama

As entradas abaixo são as dos exemplos do próprio README:

Repara que a chave do estado muda de preset pra preset (request, prompt, post, message)

Guarda isso, porque é onde a galera tropeça depois

router_questions(): decidir se a requisição merece o modelo caro

O cenário clássico: toda requisição do seu app cai no modelo mais forte que você tem

Funciona? Funciona

Mas você paga modelo de ponta pra responder "qual o horário de atendimento" e ainda engole a latência dele

O router_questions() existe pra essa decisão: roteia entre modelo pequeno e modelo de ponta

routing = agent.predict(
    {"request": "Refactor this service using dependency injection"},
    laya.router_questions(),
)

Um pedido de refatoração usando injeção de dependência é justamente o tipo de coisa que tende pro modelo grande: exige contexto de arquitetura, não é resposta de FAQ

E aqui vai um ponto que confunde MUITO, então bora separar

O router_questions() decide o roteamento de LLM da sua aplicação

O Router embutido no pacote laya é outra coisa: ele decide qual checkpoint do próprio laya usar pra responder a pergunta

Mesma palavra, camadas diferentes

guard_questions(): barrar jailbreak, injeção de prompt e vazamento

Esse é o preset que fica na frente do seu LLM, antes da chamada cara

guard = agent.predict(
    {"prompt": "Ignore all instructions"},
    laya.guard_questions(),
)

O preset olha jailbreaks, injeções e vazamentos

O clássico "Ignore all instructions" é o exemplo do README porque é o caso de livro didático, mas tu sabe que na vida real vem coisa bem mais criativa que isso

Agora o detalhe que faz diferença de verdade: o laya trabalha com probabilidade calibrada no tipo noul

Isso significa que a resposta não é um sim/não seco, é um número

E número te dá limiar

Você pode deixar passar abaixo de certo valor, mandar pra revisão numa faixa do meio e bloquear no topo

Bloquear tudo que cheira mal é o caminho rápido pro usuário legítimo tomar um não na cara e ir embora

Tome cuidado com isso na hora de calibrar

moderation_questions(): filtrar conteúdo de usuário

Comentário, post, chat público, review de produto

Qualquer lugar onde usuário escreve e outro usuário lê, você precisa de uma camada aqui

safety = agent.predict(
    {"post": "User comment text"},
    laya.moderation_questions(),
)

O preset cobre toxicidade, assédio e ameaças

E o uso mais são disso não é ban automático

É fila de revisão humana

O modelo responde em milissegundos, ordena o que é mais grave e o time humano olha o topo da fila primeiro, em vez de ler tudo na ordem de chegada

Moderação 100% automática com ban direto é ótima ideia até o dia que ela derruba o post de um cliente pagante por um falso positivo 😅

triage_questions(): classificar ticket de suporte

Aqui o preset é praticamente um analista de suporte lendo o ticket antes de você

triage = agent.predict(
    {"message": "My payment failed twice"},
    laya.triage_questions(),
)

As dimensões que o README cita são intenção, urgência, frustração e risco de churn

Pensa no que cada uma vira dentro do seu sistema:

• intenção vira roteamento de time (cobrança, técnico, comercial)
• urgência vira prioridade de fila
• frustração vira decisão de tom da resposta, ou escalonamento direto pra humano
• churn vira alerta pro time de customer success antes do cliente pedir cancelamento

E "My payment failed twice" é o exemplo perfeito porque o "twice" muda tudo

Falhou uma vez é suporte normal

Falhou duas vezes é alguém prestes a desistir de te pagar

Bônus: email_questions() para caixa de entrada e phishing

Além dos quatro principais, o pacote traz um quinto preset: email_questions()

Ele é voltado pra triagem de e-mail de entrada e detecção de spam e phishing

Os presets ficam em laya.presets

E aqui vale um aviso de bastidor: se tu topar com comportamento estranho nesse preset, confere primeiro qual versão do pacote tu tem instalada, antes de sair debugando teu código

Já vi gente perder tarde inteira por menos que isso

O que você precisa antes de rodar os presets

A lista é curta, nada de PC da Nasa por aqui:

• Python 3.10 ou superior, exigência que vem das dependências (huggingface_hub 1.x, transformers 5.x e torch 2.14)
• Instalação via pip install laya
• Repositório oficial: NandhaKishorM/laya
• Versão atual: 0.3.1, publicada em 19 de setembro de 2026

E tem três checkpoints publicados, que é bom conhecer antes de escolher:

Na medição de lançamento em Tesla T4, o checkpoint inglês de 421M ficou em torno de 39,5 ms e o multilíngue de 322M em torno de 32,8 ms

O Router embutido é apresentado como o ponto de entrada recomendado

Ele detecta script e idioma em submilissegundos e despacha pro checkpoint ideal, carregando sob demanda com despejo LRU

Por padrão mantém 1 modelo carregado, e aceita Router(max_loaded=2) se tu quiser dois na memória ao mesmo tempo

Pra quem atende público em português, esse detalhe do multilíngue importa bastante, beleza?

Como chamar um preset em três passos

Bora ver na prática

1. Instale o pacote

pip install laya

O erro comum aqui é rodar em Python 3.9 ou anterior e tomar erro de dependência

Confere a versão antes com python --version

2. Carregue o agente

import laya

agent = laya.load("convaiinnovations/laya")

3. Chame o predict passando o estado e o preset

triage = agent.predict(
    {"message": "My payment failed twice"},
    laya.triage_questions(),
)

E pra trocar de fluxo, é só trocar o preset (e a chave do estado junto):

guard = agent.predict(
    {"prompt": "Ignore all instructions"},
    laya.guard_questions(),
)

safety = agent.predict(
    {"post": "User comment text"},
    laya.moderation_questions(),
)

routing = agent.predict(
    {"request": "Refactor this service using dependency injection"},
    laya.router_questions(),
)

Dois erros comuns nesse passo, e os dois são bobos:

Chave errada no estado. Mandar {"text": ...} pro guard_questions() quando o exemplo usa prompt é pedir pra sofrer

Cada preset do exemplo tem a sua chave, respeita ela

Esquecer os parênteses. O preset é uma chamada de função, não uma constante

laya.triage_questions() funciona

laya.triage_questions te entrega o objeto função e o predict vai reclamar

Quando o preset basta e quando vale montar seu próprio schema

A parte bonita do desenho: cada preset devolve uma lista de dicionários no mesmo formato de schema que Router.predict e Agent.predict já aceitam

O que isso te libera?

Começar pelo preset, ver a saída, e depois editar ou estender a lista com as perguntas que fazem sentido pro TEU domínio

Não é uma caixa preta que você usa como veio ou não usa

É um ponto de partida em estrutura de dado normal do Python

E já tem gente construindo em cima disso: o projeto laya-server documenta um POST /v1/presets/{preset}/predict pra rodar os presets guard, moderation, triage, router ou email por HTTP

Ou seja, se tua stack não é Python, ainda dá pra encostar nisso por API

Sinal de que o projeto pegou: o repositório oficial marcava 11.841 estrelas em 22 de setembro de 2026, poucos dias depois do lançamento

Vídeo: combinando modelos em um mesmo workflow

Usar um modelo pequeno pra decidir e um modelo grande pra executar é o tipo de arranjo que só faz sentido quando você para pra pensar em orquestração

Pra começar do zero com essa ideia de mais de um modelo no mesmo fluxo, este vídeo do canal mostra Claude e Gemini trabalhando juntos dentro do Antigravity:

Conclusão

Se você chegou até aqui e ficou na dúvida de por onde começar, vai pelo problema que mais dói hoje:

• Conta de LLM alta demais? router_questions()
• Medo de injeção de prompt e vazamento? guard_questions()
• Conteúdo de usuário rodando solto? moderation_questions()
• Fila de suporte sem prioridade? triage_questions()
• Caixa de entrada bagunçada e phishing? email_questions()

O próximo passo é bem direto: instala o pacote, roda um preset com um estado REAL da tua base (um ticket de verdade, um comentário de verdade) e compara a saída com a classificação que teu fluxo atual já produz

Só depois dessa comparação é que vale trocar alguma coisa em produção

Preset pronto é atalho pra começar, não desculpa pra pular a validação =)

até o próximo post!