decision-cascade ensina um modelo local a calcular o custo do erro antes de chamar um LLM externo

Uma história conhecida: você constrói um sistema com um modelo local pequeno e um modelo externo grande. O esquema simples de roteamento é este: se o modelo local não está confiante, envia-se a requisição para a nuvem. O limiar costuma ser tirado do nada, digamos 0.6. Um mês após a primeira publicação, o autor do projeto decision-cascade fez a si mesmo uma pergunta incômoda: por que exatamente 0.6?

Por que o limiar de confiança é um critério ruim

A confiança do modelo e o benefício da escalada são coisas diferentes. É possível ter dúvida sobre uma resposta em que o erro não custa nada: por exemplo, escolher uma entre duas opções equivalentes. Pagar por uma chamada externa ali não faz sentido. Ou é possível ter 0.8 de confiança e errar justamente onde o erro é caro. Um limiar não distingue esses casos.

Por isso o projeto ganhou a escalada benefit-aware. O motor compara a utilidade esperada da resposta local e da escalada, levando em conta o custo do erro e o custo da chamada ao modelo externo. Se o benefício do refinamento for menor que o custo da chamada, a cascata permanece local. Se for maior, sai para fora. A decisão não é tomada por um modelo que avalia se está certo, mas por um sistema que calcula se vale a pena pagar pelo refinamento.

Para o product manager, essa é uma linguagem clara: o erro tem preço em dinheiro, tempo ou reputação, e a chamada ao LLM também tem. A escalada passa a ser uma linha do orçamento, e não um efeito colateral do ajuste de um limiar.

O que mostraram as demos e os benchmarks

O autor testou a abordagem em dois jogos locais, nos quais as decisões têm consequências. No xadrez contra o Stockfish, 19% de escaladas fecham metade da lacuna até o modo «pensar sempre a fundo» e custam 38% do cálculo completo. Em um labirinto no estilo Pac-Man, uma política cautelosa obtém 94% dos pontos com 33% de escaladas, o dobro da estratégia gulosa. Ninguém quer transformar o motor em grande mestre. O ponto é outro: a economia da escalada funciona onde a decisão tem preço.

Há ainda uma comparação com dois modelos «reais», Clef-Flash (9,4B) e Laya (421M), em conjuntos públicos. Condições: n=200 e uma única GPU de 16 GB.

• AG News, acurácia: 87,3% no decision-cascade (124M), 85,5% no Clef-Flash, 66,2% no Laya.
• AG News, latência mediana: 10 ms contra 130 ms do Clef-Flash e 16 ms do Laya.
• RouterBench, acurácia: 54,2% contra 44,2% do Clef-Flash e 31,2% do Laya.
• RouterBench, latência mediana: 21 ms contra 170 ms do Clef-Flash.

A conclusão do autor: um modelo pequeno com cabeças treinadas supera um concorrente de 9B em tarefas de tomada de decisão e funciona cerca de 10 vezes mais rápido. Em geração livre, como ele mesmo admite, o modelo maior vence. O script eval/competitors/reproduce_real.sh e os JSON brutos estão nas releases, então os números podem ser conferidos.

Integração e onde está a pegadinha

Para quem olha o projeto como dependência, a principal mudança é esta: a versão 1.x agora tem um contrato estável. O formato dos packs e as variáveis DECISION_* não quebrarão sem uma versão major e uma janela de depreciação. O projeto está no PyPI, e o início rápido com um codificador hash leva alguns minutos, sem GPU e sem baixar modelos.

Agora as limitações, que o próprio autor lista com honestidade. Por padrão, as cabeças são aleatórias; uma qualidade significativa exige SFT/RLCD ou um pack de pesos pronto. O modelo de risco só é útil depois de acumular exemplos. A calibração de domínio para o seu cenário terá de ser feita por conta própria. E não esqueça a escala das medições: n=200, e os benchmarks foram montados pelo próprio autor, ou seja, não é uma avaliação independente.

O que fazer com isso

Mesmo que você não instale o decision-cascade, a ideia se aplica a qualquer combinação de «modelo barato mais modelo caro». Pare de rotear apenas pela confiança. Defina ao menos uma estimativa aproximada do custo do erro por tipo de requisição e compare-a com o custo da chamada. Em tarefas de classificação, escolha de opções e avaliação, isso pode reduzir bastante o gasto com APIs externas com pouca perda de qualidade. Entre os planos do projeto estão um transformer codificador com attention-mask de estados e a integração profunda em agentes de chat. O autor pede que enviem casos em que a cascata escala no lugar errado, e essa é a forma mais útil de testar a abordagem na prática.