Confidence gating no laya: como desenhar o fallback quando a decisão não é confiável?

O ponto cego de todo agente automatizado não é a decisão errada

é a decisão errada com cara de certa

O laya ataca justamente isso: é um modelo de decisão da Convai Innovations que recebe um estado e perguntas tipadas e devolve respostas tipadas com probabilidade, sem gerar uma única palavra de texto. Ele foi lançado em 18 de setembro de 2026 sob licença Apache 2.0, com pesos abertos no Hugging Face e código no GitHub

Só que probabilidade na saída não é gate. Gate é o que VOCÊ faz quando aquele número não passa do corte

E é disso que esse post trata: como desenhar o fallback, quando escalar pra humano, quando escalar pra um modelo maior, e por que calibrar vem antes de tudo isso

O que você precisa antes de montar o gate

O laya é distribuído como pacote Python, instalável via pip, e roda em GPU ou CPU própria

pip install laya

Nada de PC da Nasa obrigatório aqui, mas a escolha do checkpoint muda o jogo

Agora o aviso que muda TUDO pra quem vai montar gate: os dois checkpoints saem de fábrica superconfiantes, e o laya-multilingual ainda vem distribuído sem temperaturas ajustadas

Ou seja, nenhum dos dois chega calibrado na sua mão, e no multilingual as temperaturas precisam ser ajustadas antes de você confiar em qualquer probabilidade dele

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

Por que sem calibração não existe gating honesto:

Gating é comparar um número com um corte. Se o número mente, o corte não serve pra nada

E os dois checkpoints saem de fábrica superconfiantes mesmo. O reajuste de uma temperatura por (tipo de pergunta, número de opções) em dados held-out derruba o ECE médio de 0,466 para 0,081 no laya e de 0,314 para 0,106 no laya-multilingual

ECE é o erro de calibração esperado. Traduzindo pro português de gente: o quanto a confiança declarada pelo modelo bate com o acerto real dele

Um ECE de 0,466 é o modelo cravando certeza alta numa faixa onde ele acerta muito menos que isso. Colocar um threshold em cima desse número é se enganar com estatística bonita

Por isso a ordem do post é essa: primeiro calibra, depois liga o gate

Como desenhar o fallback passo a passo

Um detalhe importante antes de começar: o pacote não expõe uma função oficial que decide sozinha abster ou escalar

O que existe é a probabilidade calibrada na saída. O threshold e as rotas de fallback são código seu

Isso é bom, porque o corte certo depende do custo do seu erro, não do humor do modelo

1. Carregar o modelo e rodar o predict

No uso direto, você aponta o laya.load pro repositório do Hugging Face e avalia as perguntas

agent = laya.load("convaiinnovations/laya")
result = agent.predict(state, questions)

Se o seu tráfego não é só em inglês, o ponto de entrada recomendado é o Router embutido, que detecta script e idioma em submilissegundos e despacha pro checkpoint adequado ANTES do forward pass

router = Router(preload=True)
result = router.predict(state, questions)

A detecção cobre 22 alfabetos em menos de 0,5 ms, e dá pra sobrescrever o destino pelo parâmetro model quando você já sabe pra onde quer mandar

O erro comum deste passo: carregar o checkpoint em inglês direto e assumir que ele vai se virar com o resto do mundo. Ele não se vira, e pior, ele não avisa (mais sobre isso na próxima seção)

2. Ler a resposta por chave e tipo

O laya expõe três primitivas de pergunta tipada:

• choice: escolher uma opção, com probabilidade por opção
• score: nível esperado numa escala ordenada, com a distribuição
• noul: P(verdadeiro) calibrado para uma afirmação sim/não

E o dicionário retornado é lido por chave e tipo

answers["department"]["choice"]
answers["urgency"]["score"]
answers["churn_risk"]["noul"]

O erro comum deste passo: tratar os três tipos como se fossem a mesma coisa. Um noul te dá uma probabilidade de verdadeiro, um score te dá uma distribuição sobre uma escala ordenada, e um choice divide massa entre opções concorrentes. São números com significados diferentes

3. Definir o corte POR TIPO de pergunta

Essa é a parte que quase todo mundo faz errado: escolher um número global tipo 0,7 e aplicar no sistema inteiro

Não dá

Um choice com 4 opções tem chute base em 0,25. Um choice com 30 opções tem chute base MUITO menor, então 0,4 ali pode ser um sinal forte. Já um noul tem chute base em 0,5, e 0,55 não significa absolutamente nada

Então o gate nasce por tipo, e dentro do tipo, por número de opções

GATES = {
    ("choice", 4): 0.62,
    ("choice", 12): 0.45,
    ("noul", 2): 0.80,
}

def passou(tipo, n_opcoes, p):
    corte = GATES.get((tipo, n_opcoes))
    return corte is not None and p >= corte

Os números acima são exemplo de estrutura, não recomendação: o corte de verdade sai do SEU conjunto held-out

O erro comum deste passo: copiar threshold de post de blog (inclusive deste) e mandar pra produção sem medir no seu domínio

4. Ajustar a temperatura antes de confiar no número

O reajuste é feito por (tipo de pergunta, número de opções), em dados held-out. É exatamente o mesmo eixo do passo anterior, e não é coincidência: o viés de confiança não é uniforme entre formatos de pergunta

O treino do laya usa RLCD, aprendizado por reforço contra regras de pontuação estritamente próprias, com log score, spherical score e ranked probability score pras perguntas ordinais. A recompensa só é máxima quando a probabilidade declarada bate com a realidade

É um treino desenhado pra honestidade probabilística, e ainda assim o modelo sai superconfiante de fábrica. Isso deveria ser suficiente pra te convencer a medir 🙂

O erro comum deste passo: medir ECE no mesmo conjunto que você usou pra ajustar a temperatura. Aí o número fica lindo e não quer dizer nada. Held-out é held-out

Tome cuidado também com amostra pequena: ECE calculado em poucas dezenas de exemplos balança fácil

5. Implementar as duas rotas e REGISTRAR a flag

Quando o gate não passa, você precisa ter pra onde ir. As duas saídas clássicas são escalar pra humano e escalar pra um modelo maior

def decidir(tipo, n_opcoes, resposta, p):
    if passou(tipo, n_opcoes, p):
        return {"acao": "auto", "valor": resposta, "confianca": p}

    if p < 0.3:
        return {"acao": "humano", "valor": None, "confianca": p}

    return {"acao": "escalar_llm", "valor": resposta, "confianca": p}

Repare numa coisa: mesmo na rota de escalada, a resposta original vai junto com a flag

O padrão saudável aqui é sinalizar, nunca bloquear nem reescrever a saída em silêncio. A aplicação hospedeira é quem decide o que fazer com a flag

Esse desenho de "a decisão automática falhou, e agora?" é irmão do problema de timeout e fallback no Jev, onde a decisão simplesmente não chega a tempo. Aqui ela chega, só que não é confiável

O erro comum deste passo: deixar o fallback engolir o caso silenciosamente. Se você não loga a flag e a confiança, você nunca vai saber quantos por cento do tráfego está caindo no gate, e nunca vai conseguir recalibrar o corte

Quando o confidence gating falha (e como prevenir)

Agora a parte desconfortável. Existem modos de falha documentados em que o gate simplesmente não te protege

Sintoma: resposta absurda com confiança altíssima fora do idioma

Causa: o checkpoint em inglês não degrada com elegância. Em khmer, o README registra acurácia 0,000 com confiança 0,952. E a confiança média nunca cai abaixo de 0,885 em nenhum nível de acurácia

Lê de novo isso: zero de acerto, e o modelo cravando 0,952 de confiança

Solução: roteamento antes do forward pass. É pra isso que o Router existe e é por isso que a detecção de script acontece antes do modelo rodar. Não adianta tentar consertar depois com threshold, porque o número que chega já nasceu podre

Sintoma: erro confiante mesmo com o checkpoint certo

Causa: cauda de erro confiante. Uma avaliação independente publicada como issue no repositório mediu roteamento de skills em chinês nos três checkpoints e relatou 70% no multilingual, 65% no typed-decisions e 60% no inglês, com respostas erradas de alta confiança persistindo. Uma avaliação equivalente em romeno, também publicada como issue, relatou 50% no multilingual e 55% no typed-decisions

A conclusão que os próprios relatos tiram é dura: essa cauda inviabiliza gating por threshold puro

Solução: não pendurar o sistema inteiro num único número. Threshold é a primeira camada, não a única. Combine com regra de negócio (valor da transação, cliente novo, palavra sensível no estado) e com amostragem humana contínua

Sintoma: acurácia despenca quando o menu de opções cresce

Causa: as perguntas do tipo choice degradam a partir de cerca de 20 opções, porque os rótulos candidatos dividem um orçamento fixo de tokens. No Banking77, que é um conjunto de 77 rótulos de intenção, o laya marcou 0,425

Solução: quebrar o espaço de rótulos. Em vez de um choice com 77 saídas, faça um choice de 6 macrocategorias e depois um segundo choice dentro da macro escolhida. Duas perguntas pequenas e calibráveis batem uma pergunta gigante e confusa

Sintoma: o modelo "parece" certeiro demais no piloto

Causa: superconfiança de fábrica, aquele ECE médio de 0,466 no laya antes do reajuste

Solução: calibração, de novo. E lembrar que o laya-multilingual sai sem temperaturas ajustadas

E os números de benchmark?

Vale olhar com cuidado antes de prometer resultado pro seu chefe

O laya ganha no argmax e perde nos outros dois

E tem um detalhe de rodapé que muda a leitura: o 0,766 vem do checkpoint laya-typed-decisions, que foi ajustado no próprio split de treino daquele benchmark, e não do modelo base zero-shot

Pra quem monta gate, soft accuracy e ECE importam MAIS que argmax, porque são eles que falam sobre a qualidade da probabilidade e não só sobre a opção vencedora

Prevenção em uma linha

Roteia antes, calibra depois, mede sempre, e nunca deixe o gate ser a única defesa do sistema

Três arquiteturas de fallback e quando usar cada uma

a) Escalar pra humano em decisões de alto custo

É a rota óbvia pra estorno, cancelamento, bloqueio de conta, qualquer coisa que dói desfazer

O review da eesel aponta que os fornecedores de decisão tipada recomendam escalar pra um humano quando a confiança cai abaixo de aproximadamente 0,3 a 0,5

Essa faixa é ponto de partida, não verdade revelada. Se o seu erro custa caro, você sobe o corte e aceita mandar mais coisa pro humano

b) Laço duplo System-1/System-2 com um LLM maior

Aqui o laya é o System-1: rápido, barato, tipado. Quando ele não sabe, um modelo maior entra como System-2

É exatamente o desenho do gut-check, um portão de verificação de laço duplo pra agentes, mantido pela RFI-IRFOS, que usa o laya como classificador rápido pra sinalizar incerteza e escalar pra um LLM maior quando o modelo rápido não sabe

O comportamento dele é a parte que vale copiar: ele classifica e sinaliza, e nunca bloqueia nem reescreve a saída do agente em silêncio. Quem decide o que fazer com a flag é a aplicação hospedeira

Se você conhece middleware de aplicação web, o conceito é bem semelhante: uma camada que observa, marca e passa adiante, em vez de sequestrar a requisição

c) Repergunta tipada antes de escalar

Essa é a arquitetura mais subestimada das três

Antes de gastar um humano ou um LLM grande, pergunte de novo, de outro jeito:

• quebre um choice grande em dois choice menores
• troque um choice ambíguo por um noul ("é um caso de cobrança?") e resolva no sim/não
• use score quando a resposta vive numa escala ordenada e o que você precisa é do nível esperado, não do rótulo

Nota de orçamento: reperguntar é barato. A latência medida no README numa GPU T4 mostra bem isso

O custo marginal por pergunta despenca quando você manda várias no mesmo lote

Ou seja: mandar 10 perguntas tipadas bem desenhadas custa muito pouco perto de acordar um LLM grande. Desenhe o batch antes, escale depois

Próximo passo: calibre antes de confiar

O recado do post é curto: o seu gate vale exatamente o que a calibração dele vale

Probabilidade descalibrada com threshold em cima é teatro de segurança. Dá a sensação de controle e entrega erro confiante direto pro usuário

O caminho prático, na ordem:

1. instalar o pacote com pip install laya e escolher o checkpoint certo pro seu idioma
2. separar um conjunto held-out do SEU domínio, com os SEUS rótulos
3. medir e ajustar a temperatura por (tipo de pergunta, número de opções)
4. definir o corte por tipo, nunca um número global
5. só então ligar o fallback em produção, com a flag registrada em log

O ponto de partida é o repositório oficial em NandhaKishorM/laya e os pesos na organização convaiinnovations no Hugging Face

E se você não vive em Python, existem runtimes de terceiros: um nativo em MLX, sem geração de texto, PyTorch ou API em nuvem, e bindings pra Node.js/TypeScript via ONNX Runtime

Bora medir antes de confiar? 😀

até o próximo post!