Reduza os custos de RAG no Amazon Bedrock com compressão orientada por consulta

O problema: tokens de contexto custam caro em escala

Quem já operou uma aplicação de Geração Aumentada por Recuperação (RAG) em produção sabe que os tokens de entrada enviados ao modelo de fundação (FM) representam uma fatia relevante do custo total. O Amazon Bedrock oferece os modelos e as ferramentas para construir essas aplicações, mas a lógica padrão de recuperação tende a priorizar alto recall — ou seja, retornar muitos chunks potencialmente relevantes para garantir que o modelo tenha material suficiente na hora da inferência.

Esse comportamento é sensato do ponto de vista de qualidade, mas tem um custo: com 5 a 20 chunks recuperados em tamanhos típicos, muitas aplicações de RAG acabam enviando milhares de tokens de contexto ao modelo principal em cada consulta. À medida que a escala cresce, esse volume se torna um alvo natural de otimização.

A AWS publicou um padrão técnico que endereça exatamente esse ponto: a compressão de contexto orientada por consulta. A ideia central é inserir um modelo menor e mais barato entre a etapa de recuperação e o modelo principal, filtrando o contexto antes da chamada mais cara. Além da economia, há um benefício adicional: menos contexto irrelevante significa menos superfície para alucinações.

Como o padrão funciona

O fluxo de um RAG tradicional segue estas etapas: a aplicação embute a consulta do usuário, o índice vetorial retorna os top-k chunks, opcionalmente um reranker reordena esses chunks por relevância, todos eles são concatenados no prompt e o modelo principal gera a resposta.

O padrão de compressão adiciona uma única etapa entre a recuperação e a resposta final: um modelo menor lê os chunks recuperados junto com a consulta do usuário e extrai apenas os trechos verbatim relevantes para aquela pergunta. O modelo principal então recebe esse contexto filtrado — muito menor — e gera a resposta.

A implementação proposta pela AWS roda dentro de uma única função AWS Lambda, que orquestra duas chamadas ao Amazon Bedrock via Converse API: primeiro ao modelo de compressão, depois ao modelo principal. O padrão é compatível com qualquer recuperador do Amazon Bedrock, incluindo o Amazon Bedrock Knowledge Bases.

Por que isso funciona economicamente

A lógica financeira depende de dois fatores: a razão de preço entre o modelo menor e o modelo principal, e a taxa de compressão que o modelo menor consegue atingir. Quando o contexto recuperado é grande, o modelo principal é a parte cara da chamada, e a maior parte do conteúdo recuperado não é necessária para responder à pergunta específica do usuário — as economias podem ser expressivas.

Para ilustrar: com R tokens recuperados, uma taxa de compressão c e preços por token distintos para cada modelo, o custo com compressão inclui a chamada ao modelo menor (leitura de R tokens e escrita de R/c tokens) mais a chamada ao modelo principal sobre o contexto reduzido (R/c tokens de entrada). O custo sem compressão inclui apenas a chamada ao modelo principal sobre o contexto completo (R tokens de entrada). A diferença favorece a compressão quando o contexto é grande, a razão de preço entre os modelos é alta e uma parcela significativa do conteúdo recuperado pode ser descartada sem afetar a qualidade da resposta.

A AWS usa Claude Haiku como modelo de compressão e Claude Sonnet como modelo principal no exemplo, mas o padrão funciona com outros pares dentro de uma mesma família de modelos no Amazon Bedrock. O par Amazon Nova Micro com Amazon Nova Pro é outra combinação citada. As taxas atuais estão disponíveis na página de preços do Amazon Bedrock.

Implementação: o prompt de compressão é a peça central

A função Lambda recebe a consulta do usuário e os chunks recuperados, lê os IDs dos dois modelos de variáveis de ambiente e inicializa um cliente do Amazon Bedrock Runtime com retentativas adaptativas. O elemento mais importante da implementação é o prompt de compressão, que instrui o modelo menor a extrair trechos — não resumir, não parafrasear, não reescrever. O modelo deve copiar verbatim apenas as sentenças ou parágrafos curtos que contêm evidências diretamente relevantes para a pergunta, preservando os identificadores de chunk para que o sistema downstream possa citar as fontes.

COMPRESSION_SYSTEM_PROMPT = """You extract evidence from retrieved documents. You will receive a user QUESTION and a list of CHUNKS. Your job: 1. For each chunk, identify the spans (verbatim sentences or short paragraphs) that contain evidence directly relevant to answering the QUESTION. 2. Output ONLY those spans, copied verbatim from the source. Do not paraphrase, summarize, or rewrite. 3. Preserve chunk identifiers so the downstream system can cite sources. 4. If a chunk contains no relevant evidence, output the chunk identifier followed by NO_RELEVANT_EVIDENCE. Output format (strict): [CHUNK_ID: <id>] <verbatim span 1> <verbatim span 2> [CHUNK_ID: <id>] NO_RELEVANT_EVIDENCE Do not add commentary, headings, conclusions, or your own words. Only verbatim spans from the source chunks, grouped by chunk identifier."""

A chamada de compressão roda com temperatura 0.0, o que mantém a extração determinística — o modelo copia os trechos exatamente como aparecem na fonte. Em seguida, o modelo principal recebe a consulta e o contexto comprimido para gerar a resposta final.

# Step 1: Compress. The smaller model filters the retrieved chunks.
compressed = bedrock.converse(
    modelId=COMPRESSION_MODEL_ID,
    system=[{"text": COMPRESSION_SYSTEM_PROMPT}],
    messages=[{"role": "user", "content": [{"text": f"QUESTION:\n{query}\n\nCHUNKS:\n{chunks}"}]}],
    inferenceConfig={"temperature": 0.0},
)

# Step 2: Answer. The primary model reasons over the filtered evidence.
answer = bedrock.converse(
    modelId=ANSWER_MODEL_ID,
    system=[{"text": "Answer using only the evidence provided. Cite sources."}],
    messages=[{"role": "user", "content": [{"text": f"QUESTION:\n{query}\n\nEVIDENCE:\n{compressed}"}]}],
)

Os prompts acima são exemplos e devem ser adaptados ao tipo de documento e às perguntas do seu caso de uso específico.

Pré-requisitos para implementar

• Ter uma conta AWS ativa.
• Criar uma função de papel (role) do Gerenciamento de Identidade e Acesso da AWS (IAM) para que a função Lambda possa acessar o Amazon Bedrock. Consulte a documentação sobre como criar um papel para delegar permissões a um serviço AWS.
• Adicionar as permissões de política necessárias ao papel do IAM.
• Solicitar acesso aos dois modelos utilizados na cascata — o modelo de compressão (Claude Haiku) e o modelo principal (Claude Sonnet) — no console do Amazon Bedrock. Solicite o acesso na seção “Model access” do console.

Resultados do benchmark

Antes de recomendar o padrão, a AWS o avaliou empiricamente. O benchmark cobriu um corpus de mais de 500 mil documentos distribuídos em 9 tipos de fontes corporativas — mensagens de chat, e-mail, tickets de rastreamento de problemas, documentos em drives compartilhados, registros de CRM, transcrições de reuniões, repositórios de código e páginas de wiki. Foram executadas 500 perguntas em 10 categorias, variando de consultas factuais pontuais a perguntas mais amplas com múltiplas partes. As respostas foram avaliadas por um juiz baseado em modelo de linguagem de grande porte (LLM) em quatro dimensões: correção, completude, precisão de citação e concisão. A taxa de alucinação foi rastreada separadamente.

Os resultados consolidados foram os seguintes:

• Custo: baseline 100% → compressão 67% → rerank + compressão 64%
• Tokens enviados ao modelo: baseline 100% → compressão 12% → rerank + compressão 10%
• Latência: compressão +19% mais lenta; rerank + compressão +12% mais lenta
• Qualidade composta (4 dimensões): baseline 100% → compressão 97,5% → rerank + compressão 97,6%
• Taxa de alucinação: baseline 51% → compressão 44% → rerank + compressão 38%

A compressão sozinha atingiu 33% de redução de custo e 8,6 vezes menos tokens enviados ao modelo principal. Com rerank + compressão, os números chegaram a 36% de redução de custo e 10,1 vezes menos tokens.

Na dimensão de qualidade, a correção das respostas ficou dentro de 0,07 ponto da linha de base em todas as condições. A completude e a precisão de citação ficaram ligeiramente abaixo, enquanto a concisão melhorou. Já a taxa de alucinação caiu de 51% no baseline para 44% com compressão e 38% com rerank + compressão.

Um ponto importante: a economia diminui em consultas mais complexas. Para perguntas típicas, a compressão economizou 37% e o rerank + compressão 40%. Para perguntas difíceis, esses números caíram para 26% e 30%, respectivamente.

Considerações para uso em produção

Latência

Adicionar a chamada de compressão inclui uma etapa extra no caminho da requisição. Como o Claude Haiku é otimizado para velocidade e o modelo principal processa um contexto menor, parte da latência adicionada é recuperada na chamada de resposta. O impacto líquido depende do tamanho original do contexto e de quão compute-bound o modelo principal é. Para superfícies com requisitos de latência abaixo de um segundo, a recomendação é medir com os próprios tamanhos de contexto antes de colocar em produção.

Qualidade e fidelidade

O prompt de compressão é projetado para preservar a consistência factual (extração verbatim de toda evidência relevante), os identificadores de chunk para citação, a integridade de raciocínio em múltiplas etapas e os valores numéricos exatos. A instrução “verbatim only” combinada com temperatura 0.0 garante que o modelo de compressão copie os trechos como aparecem na fonte.

Escolha do modelo menor

Três fatores guiam a escolha: a razão de preço relativa entre o modelo menor e o principal (quanto menor o preço do modelo de compressão, maior a margem de economia líquida), a velocidade de inferência (modelos otimizados para velocidade limitam a latência adicional) e o alinhamento de família de modelos (usar modelos da mesma família mantém consistência no tratamento de formatação e marcadores de chunk). A disponibilidade de modelos por região no Amazon Bedrock deve ser verificada antes da implementação.

Abordagem de avaliação antes do deploy

A recomendação é montar um conjunto de avaliação com consultas representativas dos logs da aplicação (anonimizadas), cobrindo tanto buscas pontuais quanto perguntas com múltiplos fatos na proporção em que ocorrem em produção. Rodar os pipelines baseline e comprimido sobre os mesmos resultados de recuperação permite isolar o efeito da compressão. As respostas devem ser avaliadas nas dimensões relevantes para o caso de uso — correção, completude, precisão de citação e fidelidade à evidência recebida pelo modelo principal. Para deployments em produção, o Amazon Bedrock Guardrails pode fornecer filtragem de conteúdo e validação de ancoragem como controles complementares.

Onde esse padrão se encaixa bem

O padrão entrega valor quando três condições se alinham: o contexto recuperado é grande, o modelo principal é a parte cara da chamada e a pergunta é estreita em relação à amplitude do que foi recuperado. Alguns cenários que se encaixam bem:

• Assistentes de conformidade e políticas em setores regulados — utilidades, serviços financeiros, seguros e saúde mantêm boletins, tarifas e documentos de política longos onde uma única seção responde à maioria das perguntas. A extração verbatim preserva a redação regulatória exata e o ID da fonte, o que importa quando a resposta precisa ser defensável em uma auditoria.
• Copilots de suporte ao cliente sobre grandes bases de conhecimento de produto — o top-k é configurado alto para reduzir a chance de perder casos extremos, mas a maioria dos tickets resolve com um ou dois parágrafos de um artigo longo. Em volumes de suporte da ordem de centenas de milhares de tickets por mês, pequenas economias por consulta se acumulam rapidamente.
• Assistentes internos de engenharia e operações sobre runbooks e wikis — documentos internos são verbosos e pouco estruturados, mas as perguntas são específicas. A resposta costuma ser algumas linhas; o contexto de política e background ao redor não é necessário.
• Análise financeira e de calls de resultados — chunks densos (seções de 10-K, parágrafos de transcrição) com perguntas pontuais. A compressão preserva a capacidade de citar a fonte verbatim enquanto reduz o custo por consulta no modelo maior.

Se o workload envolve chat conversacional com contexto recuperado pequeno e requisitos de latência abaixo de um segundo, o padrão pode não ser o mais adequado. Nesses casos, recursos como prompt caching e Intelligent Prompt Routing do Amazon Bedrock oferecem mais valor com menos latência adicional.

Combinando com outras capacidades do Amazon Bedrock

O padrão pode ser combinado com recursos existentes do Amazon Bedrock para otimizações compostas ao longo de todo o pipeline de RAG: prompt caching, Intelligent Prompt Routing e a Rerank API. Cada camada adicional contribui para reduzir custos ou melhorar a relevância do contexto, e o padrão de compressão se encaixa naturalmente nessa stack sem exigir mudanças na lógica de recuperação já existente.

Conclusão

A compressão de contexto orientada por consulta é um padrão de pós-recuperação que se insere entre o recuperador e o modelo principal sem alterar a estratégia de recuperação. Uma única função Lambda orquestra as duas chamadas ao Amazon Bedrock, comprime o contexto e ajusta o equilíbrio entre custo e qualidade para o workload específico. O prompt de compressão lida tanto com consultas simples quanto com perguntas complexas de múltiplas fontes sem exigir lógica de roteamento separada.

Para começar, consulte a documentação do Amazon Bedrock e a página de preços do Amazon Bedrock para os custos atuais dos modelos.

Fonte

Reduce RAG costs on Amazon Bedrock with query-aware compression (https://aws.amazon.com/blogs/machine-learning/reduce-rag-costs-on-amazon-bedrock-with-query-aware-compression/)