Cascatas e perguntas em paralelo
A motivação por trás de ambos os padrões é simples: uma chamada a um modelo grande é cara, e a maioria dos pedidos é fácil. Uma chamada de decisão custa uma a duas ordens de magnitude menos do que uma geração, por isso «pergunta primeiro ao barato, escala quando não estiveres certo» é a forma óbvia.
Cascatas: decide só onde estás certo
Uma avaliação direta sobre deteção de alucinações médicas dá um número limpo:
Deixa o modelo de decisão resolver os 37% dos casos em que está pelo menos 90% confiante, e preserva a exatidão de cada modelo grande enquanto elimina 37% das chamadas ao modelo grande.
Vale a pena citá-lo porque diz em que consiste realmente a poupança de uma cascata: a proporção de tráfego que cai dentro da tua região de alta confiança, não uma percentagem fixa. Uma confiança mais apertada significa mais poupança — desde que essa confiança seja real, o que nos devolve à calibração.
Dois detalhes são fáceis de deixar passar:
① Depois do escalonamento, o modelo grande não deve ter liberdade ilimitada. Uma implementação que entrega as linhas incertas a um LLM obriga esse LLM a escolher do mesmo conjunto de etiquetas. Sem isso, o «não tenho a certeza» do modelo pequeno transforma-se numa saída que o teu pipeline não consegue consumir.
② Uma vez tomada uma escolha, mantém-na. Um encaminhador de modelos conserva a sua seleção durante toda a sessão para preservar a continuidade da cache de prompt. Voltar a escolher a cada turno muda o prefixo e deita fora a cache — o dinheiro que poupaste na chamada mais barata volta a sair pela cache.
Perguntas em paralelo: o que poupas é entrada
Os modelos de decisão permitem-te pôr muitas perguntas num único pedido; os exemplos oficiais pedem dezenas de uma vez.
Um benchmark sobre 2,976 chamadas mediu o que isso rende:
| Item | Resultado |
|---|---|
| 8 perguntas em paralelo vs uma a uma | 76–86% de poupança mediana em tokens de entrada |
| Sobrecarga fixa por pedido | cerca de 261 tokens de entrada |
Portanto a poupança não é «o modelo calcula mais depressa», é que o mesmo estado é enviado uma só vez. Quanto mais perguntas, mais essa sobrecarga fixa se dilui. Com uma ou duas perguntas, a diferença entre paralelo e sequencial é da mesma ordem que o ruído entre execuções, e não vale uma mudança de arquitetura.
Contraexemplo: agrupar pode quebrar o ranking
Esta é a conclusão mais contra-intuitiva desta página:
Uma extensão do DuckDB agrupa 40 linhas por predefinição. O benchmark descobriu que o caminho agrupado falha a sua barreira de qualidade de ranking, enquanto uma linha por pedido a passa.
A razão é reconstruível: meter 40 linhas num único pedido pede ao modelo que produza 40 ordenações relativas de uma vez, o que é mais difícil do que comparar alguns candidatos de cada vez. O custo e a fidelidade estão em conflito aqui — e o lado do custo é visível (a fatura), enquanto o lado da fidelidade é invisível a menos que tenhas construído uma barreira para o medir.
A regra geral: as perguntas em paralelo servem para perguntas independentes (classificação, pontuação, julgamento) e não para perguntas que exigem comparar itens uns com os outros.
Mais uma precondição: os erros têm de ser aleatórios
As cascatas funcionam por uma suposição implícita: os erros do modelo pequeno são ruído aleatório, por isso o modelo grande pode corrigi-los.
Testes independentes de calibração fora da distribuição contradizem isso. Choice e Score são
sistematicamente demasiado confiantes; Boolean é sistematicamente pouco confiante. Um
enviesamento sistemático não é ruído: faz o modelo pequeno reportar alta confiança em toda uma
classe de entradas, de modo que essa classe nunca é escalada e é respondida mal todas as
vezes.
O risco, então, não é uma «exatidão ligeiramente menor», mas todo um tipo de entrada ser descartado de forma consistente, de maneira invisível no agregado. Encontrá-lo exige olhar para a exatidão por subclasse, não no conjunto.
Numa frase
Uma cascata poupa em proporção a quanto tráfego se situa na sua região de alta confiança; as perguntas em paralelo poupam amortizando uma sobrecarga fixa. Ambas têm um preço — a primeira aposta que os erros do modelo mais pequeno são aleatórios, a segunda prejudica tarefas que precisam de comparação cruzada.