A AWS introduziu um novo padrão para reduzir os custos de recuperação com IA no Amazon Bedrock. Se você desenvolve aplicações de geração aumentada por recuperação (RAG), essa configuração pode diminuir seus gastos com tokens, mas seus usuários podem esperar mais pelas respostas.
Em uma publicação divulgada em 2026-08-21 no AWS Machine Learning Blog, a AWS mostrou como posicionar um modelo pequeno entre a recuperação e a resposta final. Em vez de enviar blocos longos de texto para um modelo grande, um modelo rápido extrai primeiro apenas as frases exatas e relevantes.
Como a configuração funciona
O design de referência roda dentro de uma função AWS Lambda usando a Amazon Bedrock Converse API. Você precisa de uma conta AWS, permissões do IAM e acesso aos modelos.
O pipeline divide o trabalho entre dois modelos:
– Claude Haiku atua como o compressor, selecionando trechos de texto literais que correspondem à pergunta do usuário.
– Claude Sonnet lê apenas o texto reduzido e escreve a resposta final.
A AWS testou três abordagens em mais de 500,000 documentos de nove tipos de fontes corporativas e 500 perguntas em 10 categorias: RAG de referência, apenas compressão e rerank mais compressão.
O que os números mostram
De acordo com a AWS, reduzir o contexto gera uma grande economia:
– Volume de tokens: Cai para 12% com compressão (8.6x menos tokens) e 10% com rerank mais compressão (10.1x menos tokens), em comparação com 100% no RAG de referência.
– Custo total: Cai para 67% (uma economia de 33%) e 64% (uma economia de 36%).
– Pontuação de qualidade: Permanece próxima à referência (97.5% e 97.6% contra 100%), com base em um juiz LLM avaliando correção, completude, precisão de citações e concisão.
– Taxa de alucinação: Cai de 51% na referência para 44% com compressão e 38% com rerank, com a fidelidade monitorada separadamente.
– Latência: Sobe em +19% com compressão e +12% com rerank mais compressão. A velocidade sofre um impacto.
As alegações que você deve verificar por conta própria
Esses números vêm inteiramente de testes internos da AWS em um único corpus avaliado por um juiz LLM. Ninguém fora da AWS os verificou de forma independente, e eles não representam uma garantia de desempenho para outras cargas de trabalho, faixas de preço ou modelos. Adicionar outra chamada de modelo cria um novo ponto de falha. O compressor pode acidentalmente descartar fatos vitais, enfraquecer citações ou falhar com trechos malformados e injeção de prompt.
Como testar esse padrão
Não altere seu pipeline de produção ainda. Teste seus próprios dados primeiro.
Defina um conjunto fixo de consultas de teste com seu recuperador, configurações de top-k, divisão em blocos e IDs de modelos. Execute as consultas pelos três caminhos: RAG de referência, compressão e rerank mais compressão. Registre tokens de entrada, tokens de saída, custo do Lambda, custo do modelo e a latência p50 e p95. Mais importante ainda, analise os trechos comprimidos diretamente. Verifique o que é descartado. Se a latência de cauda disparar ou evidências essenciais forem perdidas, manter o caminho do RAG de referência continua sendo a opção mais segura.