Cascatas e perguntas em paralelo

A motivação por trás dos dois padrões é simples: uma chamada a um modelo grande é cara, e a maioria das requisições é fácil. Uma chamada de decisão custa uma a duas ordens de magnitude menos do que uma geração, então “pergunte primeiro à barata, escale quando estiver em dúvida” é a forma óbvia.

Cascatas: decida só onde você tem certeza

Uma avaliação frente a frente em detecção de alucinação médica dá um número limpo:

Deixe o modelo de decisão resolver os 37% dos casos em que ele está pelo menos 90% confiante, e ele preserva a precisão de cada modelo grande enquanto remove 37% das chamadas ao modelo grande.

Vale citar isso porque diz qual é de fato a economia de uma cascata: a parcela do tráfego que cai dentro da sua região de alta confiança, e não alguma porcentagem fixa. Quanto mais rígida a confiança, mais se economiza — desde que essa confiança seja real, o que remete à calibração.

Dois detalhes são fáceis de esquecer:

① Depois do escalonamento, o modelo grande não deveria ter liberdade ilimitada. Uma implementação que entrega linhas incertas a um LLM força esse LLM a escolher do mesmo conjunto de rótulos. Sem isso, o “em dúvida” do modelo pequeno se converte numa saída que seu pipeline não consegue consumir.

② Uma vez feita a escolha, mantenha-a. Um roteador de modelos mantém sua seleção durante toda a sessão para preservar a continuidade do cache de prompt. Re-escolher a cada turno muda o prefixo e joga o cache fora — o dinheiro que você economizou na chamada mais barata sai de volta pelo cache.

Perguntas em paralelo: o que você economiza é entrada

Os modelos de decisão permitem colocar muitas perguntas numa única requisição; os exemplos oficiais fazem dezenas de uma vez.

Um benchmark sobre 2,976 chamadas mediu o que isso rende:

Então a economia não é “o modelo calcula mais rápido” — é que o mesmo estado é enviado uma vez. Quanto mais perguntas, mais fino fica esse overhead fixo distribuído. 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

Este é o achado mais contraintuitivo desta página:

Uma extensão do DuckDB agrupa 40 linhas por padrão. O benchmark descobriu que o caminho agrupado falha no seu gate de qualidade de ranking, enquanto uma linha por requisição passa.

A razão é reconstruível: empacotar 40 linhas numa requisição 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. Custo e fidelidade estão em conflito aqui — e o lado do custo é visível (a conta), enquanto o lado da fidelidade é invisível a menos que você tenha construído um gate para medi-lo.

A regra geral: perguntas em paralelo servem para perguntas independentes (classificação, pontuação, julgamento) e não para perguntas que exigem comparação de itens entre si.

Mais uma precondição: os erros precisam ser aleatórios

As cascatas funcionam por causa de uma suposição implícita: os erros do modelo pequeno são ruído aleatório, então o modelo grande pode corrigi-los.

Um teste independente de calibração fora da distribuição contradiz isso. Choice e Score são sistematicamente superconfiantes; Boolean é sistematicamente subconfiante. Um viés sistemático não é ruído: ele faz o modelo pequeno relatar confiança alta em uma classe inteira de entradas, então essa classe nunca é escalonada e é respondida errado todas as vezes.

O risco, então, não é “precisão um pouco menor”, mas um tipo inteiro de entrada sendo descartado de forma consistente, de forma invisível no nível agregado. Encontrá-lo exige olhar a precisão por subclasse, não a geral.

Em uma frase

Uma cascata economiza na proporção de quanto tráfego fica na sua região de alta confiança; perguntas em paralelo economizam amortizando um overhead fixo. Ambas têm um preço — a primeira aposta que os erros do modelo menor são aleatórios, a segunda prejudica tarefas que precisam de comparação cruzada.