Há um ano a resposta era fácil: os documentos não cabiam no modelo, logo era preciso RAG. Hoje cabem. E a pergunta que os clientes fazem passou a ser "então porque não mando tudo?"
A resposta curta: porque o problema nunca foi caber. Foi encontrar.
A pergunta que decide
Antes de escolher arquitetura, respondo a duas perguntas sobre o caso concreto:
- Quantas vezes por dia a mesma base de documentos é consultada? Uma vez, ou centenas?
- Os documentos mudam entre pedidos, ou são estáveis?
Cruzando as duas, a escolha quase se faz sozinha:
- Volume alto + documentos estáveis → RAG. Se a mesma base de 300 páginas vai ser consultada 200 vezes por dia, indexar uma vez e recuperar só o que interessa em cada pedido compensa — tanto em custo como em latência. É o caso típico de uma base de conhecimento interna, um catálogo de produtos, ou um conjunto de contratos-tipo.
- Volume baixo + documentos que mudam a cada pedido → contexto longo. Se cada pedido traz um documento diferente (um contrato novo, um relatório que o cliente acabou de enviar), não há nada para indexar com antecedência — mandar tudo no prompt é mais simples, mais rápido a implementar, e muitas vezes mais barato do que montar e manter um pipeline de indexação para documentos que só vão ser lidos uma vez.
O erro mais comum que vejo é decidir pela arquitetura mais recente em vez de pelo padrão de uso. Contexto longo é mais simples de implementar — zero infraestrutura de indexação, zero embeddings para manter atualizados — e por isso é tentador usá-lo sempre. Mas "mais simples de implementar" não é o mesmo que "mais barato de correr".
O que custa cada opção
Nota: os números abaixo são um exemplo ilustrativo para mostrar a ordem de grandeza da diferença, não o preço de nenhum modelo específico — os preços reais variam por fornecedor e mudam com frequência. Para um caso concreto, calculamos sempre com os preços e volumes reais desse cliente antes de decidir.
Um exemplo concreto: uma base de 300 páginas (≈150 mil tokens), consultada 50 vezes por dia, todos os dias úteis do mês (~22 dias, 1100 pedidos/mês).
Contexto longo — cada pedido envia as 150 mil tokens inteiras, mais a pergunta. A um preço de referência de €2,76/milhão de tokens de entrada (ordem de grandeza de um modelo intermédio), isso dá €0,41 por pedido só em input, ~€455/mês — sem contar com a resposta nem com o tempo de processamento de 150 mil tokens em cada chamada, que também pesa na latência sentida pelo utilizador.
RAG — indexar a base é um custo único (embeddings de 300 páginas, poucos cêntimos). Cada pedido recupera só os excertos relevantes — tipicamente 2 a 5 mil tokens, não 150 mil. Ao mesmo preço, isso são ~€0,014 por pedido, ~€15/mês. Trinta vezes mais barato, e cada resposta sai também mais depressa, porque o modelo processa muito menos texto.
A diferença cresce com o volume: a 50 pedidos/dia já compensa manter a indexação; a 2 ou 3 pedidos/dia, muitas vezes nem vale a pena — o custo de engenharia de montar e manter o RAG pode superar o que se pouparia em tokens.
Onde cada uma falha
Nenhuma das duas é grátis em risco, só falham de formas diferentes:
RAG falha na recuperação. A resposta pode estar lá, mas se o chunking for mau ou a pergunta não bater certo com os embeddings dos excertos certos, o modelo nunca a vê — e responde com confiança a partir do que recuperou, mesmo que esteja incompleto. É um erro silencioso: não há nenhum sinal óbvio de que faltou contexto.
Contexto longo falha a meio do documento. É um efeito bem documentado: os modelos são mais fiáveis a usar informação no início e no fim do que vão lendo do que no meio — o chamado "lost in the middle". Num documento de 150 mil tokens, um facto isolado algures a meio tem mais probabilidade de ser ignorado do que um que esteja logo nas primeiras páginas. E cada chamada paga o preço inteiro, falhe ou não.
O que fazemos no Bits44
Começamos sempre por contexto longo no protótipo — é a forma mais rápida de validar se o caso de uso funciona, sem construir infraestrutura de indexação para algo que pode nem vingar. Medimos custo e qualidade das respostas em condições reais, não em teoria.
Só passamos a RAG quando os números o justificam: quando o volume de pedidos repetidos sobre a mesma base torna o contexto longo caro ou lento a sério. Nessa altura, o investimento em indexação já tem retorno claro, não é feito por precaução.
É esse o critério todo: não é qual arquitetura é mais sofisticada, é quanto custa e quão bem funciona para o volume e o padrão de dados que o cliente tem — hoje, não daqui a um ano.