O blog de Machine Learning da AWS detalhou uma técnica para reduzir o custo de sistemas de retrieval-augmented generation (RAG) construídos sobre o Amazon Bedrock. A abordagem, chamada de compressão sensível à consulta (query-aware compression), filtra os trechos recuperados de acordo com a pergunta específica do usuário antes de enviá-los ao modelo de linguagem subjacente, em vez de encaminhar documentos ou blocos de texto inteiros como estão.
A maioria dos sistemas RAG recupera um número fixo de blocos de documento por consulta e passa todos eles para a janela de contexto do modelo, independentemente de quanto desse texto é realmente relevante para a pergunta. Isso infla a contagem de tokens por requisição — e, como o Bedrock e a maioria dos LLMs hospedados cobram por token, isso infla diretamente a fatura. O método da AWS pontua e reduz o conteúdo recuperado às partes que importam para determinada consulta, diminuindo os tokens enviados ao modelo sem exigir um índice de recuperação diferente ou um modelo subjacente diferente.
Isso importa operacionalmente porque o RAG se tornou a arquitetura padrão para bots de suporte com IA, busca de conhecimento interno e assistentes de capacitação de vendas em empresas pequenas e médias — sistemas que respondem perguntas puxando informações de documentos, tickets ou manuais de produto da empresa, em vez de depender apenas dos dados de treinamento de um modelo. À medida que o uso escala de um piloto para uma implantação completa, os custos de token gerados por janelas de contexto superdimensionadas costumam ser o maior item de despesa, superando o custo das próprias chamadas ao modelo.
Para uma empresa B2B de 10 a 200 funcionários que já roda ou está pilotando uma ferramenta de suporte ou busca baseada em RAG no Bedrock, essa técnica é diretamente aplicável: trata-se de uma modificação de pipeline, não de uma reconstrução de arquitetura, e o post da AWS inclui os mecanismos necessários para implementá-la. Empresas avaliando fornecedores de automação de suporte com IA também devem perguntar se o pipeline de recuperação do fornecedor já aplica compressão ou filtragem semelhante — a diferença aparece na fatura mensal, não na demonstração.
O post da AWS não trouxe números de preço, benchmarks de latência ou dados de adoção além da descrição arquitetural; as equipes devem tratar a magnitude da economia como dependente da carga de trabalho e não confirmada até ser testada contra o próprio corpus de recuperação.