RAG mais rápido: chame menos o LLM em vez de trocar por um modelo mais veloz

O reflexo errado quando o RAG fica lento

Quando um pipeline de RAG (retrieval-augmented generation) começa a parecer lento, a reação mais comum é buscar um modelo mais rápido ou mais barato. Mas há uma alavanca maior e mais barata: chamar o modelo menos vezes.

Pipelines construídos no estilo “agentic” colocam um modelo em toda decisão que exige julgamento. Em uma pergunta difícil, cada chamada compra algo real: uma absorve erros de digitação antes da recuperação, outra impede que uma página errada chegue à geração, e a última devolve uma resposta tipada com citação verificável. O problema é que o mesmo custo é cobrado em perguntas fáceis — e são elas que os usuários mais repetem.

Três chamadas em série significam cerca de dois segundos de espera e tokens pagos em toda pergunta, mesmo nas que uma busca determinística por palavras-chave já tinha resolvido na primeira passada.

O sinal que o pipeline já calcula de graça

A solução proposta não é adicionar um novo modelo, e sim um roteador que lê um sinal que a etapa de recuperação já produz: o score de co-ocorrência de palavras-chave de cada linha. Duas informações decidem a rota: o score da melhor linha e a margem entre ela e a segunda colocada.

• Score alto com margem larga (por exemplo, 5 contra 0): uma única linha respondeu à pergunta. Rota rápida — extração determinística, modelo pulado.
• Score baixo ou margem zero (empate em 2): as palavras se espalharam por várias linhas. A pergunta exige raciocínio — rota completa, com arbitragem e geração.

def route_question(line_df, primary, secondary, *, min_score=4, min_margin=3):
    scores = [co_occurrence_score(t, primary, secondary) for t in line_df["text"]]
    top, second = sorted(scores, reverse=True)[:2]
    confident = top >= min_score and (top - second) >= min_margin
    return "fast" if confident else "full"

O limiar não é uma constante universal: depende do vocabulário do domínio e de quão padronizadas são as perguntas. Ajustar esse corte é uma decisão de negócio, calibrada contra um conjunto rotulado — mas a forma geral viaja bem: gaste o modelo apenas quando a confiança estiver baixa.

Quanto isso economiza na prática

Nos testes do autor, a decisão de roteamento inteira roda em cerca de 0,1 milissegundo, sem nenhuma chamada de rede. O pipeline completo, com as três chamadas em série, soma aproximadamente dois segundos para devolver um número que a busca por palavras-chave já havia isolado.

É uma diferença de ordem de grandeza, não um ganho de ajuste fino — e recai exatamente sobre as perguntas que os usuários mais fazem. No lado do custo, cada pergunta roteada deixa de pagar três chamadas de modelo. Em um help desk que repete as mesmas cinquenta perguntas padronizadas em milhares de contratos, as perguntas fáceis são a maior parte do tráfego.

Além da margem: outros indicadores

A margem é o indicador mais barato, mas não é a otimização inteira. A ideia geral é encontrar, para cada decisão que hoje vai para o modelo, um sinal que a resolva sem ele. Entre as frentes possíveis:

• A resposta que já existe: se uma pergunta já foi respondida e o documento não mudou, devolva a resposta em arquivo, sem recuperação e sem modelo.
• O tipo de pergunta pelo dicionário: para conceitos conhecidos, o formato da resposta (valor único, parágrafo) já está registrado — não é preciso um modelo para descobrir.

A técnica se conecta à clássica ideia de cascata (rodar etapas baratas primeiro e parar assim que uma for confiável), aplicada a chamadas de modelo em vez de janelas de imagem — a mesma linha de FrugalGPT e RouteLLM, mas um passo antes, sem nenhum modelo na triagem.