Introduzir Cascata de Modelos

Problema

Todo pedido usa o modelo mais caro, inclusive os fáceis, e não há teto de gasto. É o smell Custo Sem Teto, no caso de volume alto.

Solução

Tente primeiro um modelo mais barato e suba para um maior só quando um critério verificável indicar que a resposta barata não serve. Antes de montar a cascata, meça também a alternativa mais simples: o mesmo modelo capaz, com esforço de raciocínio menor.

Antes e depois

-def triage(ticket):
-    return llm_parse(TRIAGE_PROMPT, ticket, schema=Triage, model="large")
+TIERS = [("small", 0.85), ("large", 0.60)]          # limiares calibrados no eval
+
+def triage(ticket):
+    for model, min_conf in TIERS:
+        t = llm_parse(TRIAGE_PROMPT, ticket, schema=Triage, model=model)
+        trace.set("cascade.tier", model)
+        if valid(t) and t.confidence >= min_conf:   # validação em código + confiança
+            return t
+    return human_queue(ticket)

Antes: o modelo grande em tudo.

flowchart LR
  IN(["1. Ticket"]):::io --> L(["2. Modelo grande"]):::llm
  L --> OUT(["3. Classificação"]):::io

Depois: o barato primeiro, o grande quando preciso.

flowchart LR
  IN(["1. Ticket"]):::io --> S(["2. Modelo pequeno"]):::llm
  S --> C{"3. Válido e confiante?"}
  C -->|sim| OUT(["5. Classificação"]):::io
  C -->|não| L(["4. Modelo grande"]):::llm
  L --> OUT

1. O mesmo ticket entra.
2. O modelo pequeno tenta primeiro.
3. Um critério em código decide se a resposta serve.
4. Só os casos que falham no critério sobem para o modelo grande.
5. O degrau usado fica registrado no trace.

Exemplo trabalhado

Imagine o atendimento de um marketplace brasileiro. Chegam milhares de tickets por dia: “cadê meu pedido”, troca, boleto, contestação de Pix. A triagem precisa de fila, prioridade e produto.

No eval, o modelo grande acerta 94% no geral. O pequeno acerta 89%. A diferença parece pequena até você abrir por tipo:

Tipo (exemplo)	Volume	Pequeno acerta	Grande acerta
Rastreio e prazo	alto	97%	98%
Troca e devolução	médio	88%	93%
Pix e chargeback	baixo	71%	92%

Quase todo o volume está nas duas primeiras linhas. Pagar o modelo grande em rastreio compra 1 ponto percentual. Em Pix e chargeback, o mesmo dinheiro compra 21 pontos.

A cascata, neste exemplo, fica assim. O pequeno tenta. O código valida o schema (fila conhecida, prioridade na lista, produto existente). Se a validação passa e a confiança calibrada passa do limiar, a triagem sai. O resto sobe. Chargeback com texto longo pode ter uma regra barata que manda direto ao grande, sem gastar a primeira chamada.

Suponha 10 mil tickets por dia e que o grande custe cerca de 10 vezes o pequeno por chamada. Se 80% ficam no pequeno, o custo diário cai para cerca de 28% do “grande em tudo”, e você ainda paga o grande nos 20% difíceis. Esses números são ilustrativos: rode a conta com o preço e o volume do seu provedor.

O paper FrugalGPT (Chen, Zaharia e Zou, 2023) documenta a mesma ideia com encadeamento de modelos de APIs diferentes: tentar o barato e subir só quando a resposta não atinge um limiar de qualidade. A lição que importa aqui é a mesma. O ganho vem da fração que não sobe, não do modelo extra.

Checagem +20 XP de primeiraNo eval, o modelo pequeno escreve confiança 0,92 em quase todo ticket e acerta 78% nesses casos. O time usa 0,85 como limiar de subida. Qual é o problema?

O limiar deveria ser 0,99, porque 0,85 é baixo demais para qualquer modelo

A confiança declarada não separa acerto de erro, então ela não serve como critério sozinha

O modelo pequeno precisa ser trocado, porque 78% é inaceitável em triagem

Por que funciona

Em cargas de alto volume, a maioria das entradas costuma ser fácil, e qualquer modelo competente acerta. Pagar o modelo maior nessas entradas é custo sem ganho. A cascata reserva o modelo caro para a fração difícil.

O critério é o que faz a cascata funcionar ou falhar. Validação em código (schema, regra de negócio) é o mais confiável. Confiança declarada pelo modelo é útil só depois de calibrada no eval: se o pequeno diz 90% e acerta 70%, o limiar precisa subir. O padrão de destino é a Cascata de Modelos.

A alternativa que muita gente pula

Antes da cascata, rode o mesmo modelo capaz com esforço de raciocínio menor. Vários provedores expõem isso como “effort”, “thinking” ou um flag de raciocínio. Se essa versão empatar em qualidade e custo com a cascata, fique com um modelo só.

Um modelo só é mais fácil de manter. O cache de prompt não se divide. O trace tem um degrau, não dois. A cascata só vale quando o eval mostrar que dois modelos, com um critério de subida, ganham dessa alternativa.

Passo a passo seguro

0. Meça. Rode o eval com o modelo atual e guarde acurácia por categoria e custo por item.
1. Meça a alternativa simples: o mesmo modelo com esforço menor. Se ela empatar em qualidade e custo, fique com ela; um modelo só é mais fácil de manter e não divide o cache.
2. Rode o eval no modelo barato e veja onde ele erra.
3. Escolha o critério de subida: validação em código primeiro, confiança calibrada depois.
4. Calibre os limiares com o eval: acurácia por faixa de confiança no degrau barato.
5. Simule a cascata no dataset: fração que sobe, acurácia final, custo total.
6. Implemente com o degrau no trace e um destino final para o que nenhum degrau resolve.
7. Meça de novo em produção, com amostragem das respostas do degrau barato.

Como calibrar o limiar

Separe o dataset do degrau barato em faixas: confiança abaixo de 0,6, de 0,6 a 0,8, acima de 0,8. Em cada faixa, meça a acurácia real.

O limiar útil é o ponto em que a faixa começa a acertar o bastante para o produto. Se a faixa “acima de 0,8” acerta 96% e a “de 0,6 a 0,8” acerta 74%, um corte perto de 0,8 faz sentido. Se todas as faixas acertam parecido, a confiança não carrega informação. Aí o critério precisa ser outra coisa: tamanho do texto, presença de um CNPJ, regra de negócio que falhou.

Nunca escolha 0,7 porque “parece razoável”. Esse número só existe depois do eval.

Riscos

• Erros confiantes. O modelo barato erra com confiança alta, e o erro não sobe. Revise amostras de respostas aprovadas no primeiro degrau.
• Tudo sobe. Critério rígido demais faz quase tudo ir para o grande, e a cascata só acrescenta latência.
• Latência para os casos difíceis. Quem sobe paga duas chamadas. Avalie se o produto aceita.
• Cache dividido. Modelos diferentes não compartilham cache de prompt.

Erro comum: cascata como enfeite

Um time coloca o modelo pequeno na frente, sobe em qualquer dúvida, e 95% dos pedidos vão ao grande. No trace, “cascata” aparece em todo span. No custo, a conta ficou pior: uma chamada extra em quase tudo, mais o grande.

Isso não é cascata. É o modelo grande com um pedágio na frente. A métrica que denuncia: fração que sobe. Se ela passa de, digamos, dois terços no seu volume, volte ao eval e afrouxe o critério, ou desista da cascata.

Checagem +20 XP de primeiraUma semana depois de ligar a cascata, 94% dos tickets sobem para o modelo grande. Qual é o próximo passo mais útil?

Abrir o eval e o critério de subida: a cascata está só adicionando latência

Adicionar um terceiro degrau ainda maior, para os 6% que restam

Trocar o modelo pequeno por um médio, mantendo o mesmo limiar de 0,85

Desafio

O eval mostra: o modelo pequeno acerta 96% dos tickets curtos e 71% dos tickets com mais de 300 palavras. O grande acerta 97% e 93%. Como você desenharia a cascata?

Ver solução

Use uma regra de roteamento barata antes da cascata: tickets com mais de 300 palavras vão direto ao modelo grande, porque o pequeno erra demais neles. Tickets curtos vão ao pequeno, com validação em código e confiança calibrada para subir os casos duvidosos. Confira no eval a acurácia final por faixa de tamanho e o custo total contra a versão “grande em tudo”.

Teste seu entendimento

Checagem +20 XP de primeiraO eval mostra que o mesmo modelo capaz, com esforço baixo, empata em acurácia com a cascata e custa quase igual. O que você faz?

Implementa a cascata mesmo assim, para ter degraus visíveis no trace

Sobe o esforço em tudo, porque o modelo capaz já está no sistema

Fica com um modelo só. A cascata não pagaria a complexidade

Checagem +20 XP de primeiraO degrau barato aprova um ticket de contestação de Pix com o CNPJ do recebedor invertido, confiança 0,97. Como você pega esse tipo de erro?

Subindo automaticamente todo ticket que menciona Pix para o modelo grande

Amostrando respostas aprovadas no primeiro degrau e validando regras em código, como dígito de CNPJ

Pedindo ao modelo pequeno para 'pensar mais' antes de responder

Checagem +20 XP de primeiraTickets com mais de 300 palavras: o pequeno acerta 71%, o grande 93%. Tickets curtos: 96% e 97%. Qual desenho combina melhor com esses números?

A mesma cascata para todo mundo, com o mesmo limiar de confiança

Só o modelo grande, porque 71% no pequeno é inaceitável

Uma regra de tamanho manda os longos direto ao grande; os curtos entram na cascata

Checagem +20 XP de primeiraEm produção, a acurácia geral da cascata está estável, mas a fila humana cresceu. O trace mostra cascade.tier=large na maior parte desses casos. O que isso sugere?

O modelo pequeno piorou e precisa ser retreinado

O grande também não está resolvendo uma fatia nova, e o destino final (humano) está sobrecarregado

Falta um degrau intermediário entre o pequeno e o grande