Ganhos e limites do RAG com Amazon Bedrock e S3 Vectors

O rerank colocou mais fontes confirmadas no topo da busca. A limpeza reduziu o volume de texto enviado ao modelo. Se a gente parasse nessas duas medidas, deixaria de olhar para o que saiu das conversas e para a forma como a resposta usou o que ficou.

Em um dos pilotos, por exemplo, a conversa chegou inteira ao modelo. A resposta trouxe o procedimento final e a confirmação do cliente, com citações corretas, mas confundiu falas do cliente com uma orientação do atendente. Também deixou de mostrar que uma orientação anterior havia sido corrigida. O trecho necessário estava ali, só que a resposta não preservou o sentido da conversa.

Esses resultados vêm de um estudo que fizemos no Dati Labs entre setembro e outubro de 2026, com uma base de atendimento. Comparamos o preparo dos documentos, a divisão em trechos, os modelos de embeddings e a reordenação da busca. Aqui, vamos passar pelas escolhas que tiveram efeito na recuperação e pelas que exigiram uma revisão mais cuidadosa do conteúdo.

Em uma conversa de suporte, uma sugestão pode ser descartada algumas mensagens depois, e uma resposta curta pode confirmar que o problema foi resolvido. São detalhes que precisam sobreviver ao preparo e chegar à resposta com o mesmo significado. Foi olhando para eles que conseguimos entender melhor os limites de cada ajuste.

A arquitetura usada na avaliação

Usamos o Amazon Bedrock para acessar os modelos de IA e o Amazon Bedrock Knowledge Bases para organizar a ingestão dos documentos e recuperar os trechos relacionados a cada pergunta. O Amazon S3 Vectors foi o armazenamento vetorial principal do estudo.

Nesse desenho, os modelos de embeddings representam os textos numericamente para permitir buscas por significado, mesmo quando a pergunta usa palavras diferentes das que estão no documento. O S3 Vectors armazena e permite consultar essas representações. As Knowledge Bases integram esse índice à recuperação do conteúdo que vai apoiar a resposta. A documentação da integração entre S3 Vectors e Knowledge Bases detalha esse fluxo.

Na análise, precisamos considerar separadamente o armazenamento, a ordem dos resultados e a geração da resposta. Um ganho em uma dessas partes não pode ser atribuído automaticamente às outras.

O estudo de setembro usou principalmente S3 Vectors e incluiu comparações com OpenSearch Serverless. Já os pilotos de outubro ficaram em um laboratório com S3 Vectors, concentrados em um atendimento. A recuperação integral desse documento permitiu examinar a resposta sabendo que o desfecho estava no contexto, sem atribuir sua omissão à busca.

Reordenação e critérios de aceitação

O ganho mais consistente de recuperação veio do rerank. Nessa etapa, um modelo avalia novamente a relação entre os trechos encontrados e a pergunta, para reordenar os candidatos antes de entregá-los à geração. Esse é o papel descrito na documentação de reordenação do Bedrock.

Para comparar as duas buscas, a chamada pode ser feita diretamente pelo retrieve, sem gerar uma resposta ainda. Este primeiro exemplo pede até 25 trechos e mostra os dez primeiros, com a fonte e a pontuação. A estrutura está na referência do Boto3 para retrieve.

Os exemplos usam uma pergunta fictícia e uma Knowledge Base textual com S3 Vectors em us-west-2. Para executá-los, substitua o ID e use uma base já ingerida, com credenciais e permissões para consultar a base e usar o modelo de rerank. As chamadas podem gerar cobrança. São exemplos ilustrativos, não uma nova execução do estudo.

import boto3

client = boto3.client("bedrock-agent-runtime", region_name="us-west-2")
kb_id = "KBID123456"  # Substitua pelo ID da sua Knowledge Base.
pergunta = "Por que meu relatório está vazio?"

sem_rerank = client.retrieve(
    knowledgeBaseId=kb_id,
    retrievalQuery={"text": pergunta},
    retrievalConfiguration={
        "vectorSearchConfiguration": {
            "numberOfResults": 25,
            "overrideSearchType": "SEMANTIC",
        }
    },
)

for posicao, trecho in enumerate(sem_rerank["retrievalResults"][:10], 1):
    print(posicao, trecho["location"], trecho["score"])

A segunda chamada mantém a mesma base, pergunta e busca semântica. Acrescenta a reordenação dos candidatos para devolver até dez resultados. O campo é numberOfRerankedResults, dentro de bedrockRerankingConfiguration, conforme a configuração de rerank no Retrieve. O ARN abaixo usa o Cohere Rerank 3.5, disponível em us-west-2.

com_rerank = client.retrieve(
    knowledgeBaseId=kb_id,
    retrievalQuery={"text": pergunta},
    retrievalConfiguration={
        "vectorSearchConfiguration": {
            "numberOfResults": 25,
            "overrideSearchType": "SEMANTIC",
            "rerankingConfiguration": {
                "type": "BEDROCK_RERANKING_MODEL",
                "bedrockRerankingConfiguration": {
                    "modelConfiguration": {
                        "modelArn": "arn:aws:bedrock:us-west-2::foundation-model/cohere.rerank-v3-5:0"
                    },
                    "numberOfRerankedResults": 10,
                },
            },
        }
    },
)

for posicao, trecho in enumerate(com_rerank["retrievalResults"], 1):
    print(posicao, trecho["location"], trecho["score"])

Para comparar as buscas, precisamos observar se a fonte que sustenta a resposta subiu de posição, caiu ou deixou de aparecer. As pontuações vêm de avaliações diferentes, então não basta comparar seus valores. Os números a seguir são do estudo histórico, não da pergunta fictícia usada no código.

Na configuração que reproduzia a base de produção, usamos busca por significado, sem filtros, com S3 Vectors. O Cohere Rerank 3.5 reordenava 25 candidatos e devolvia 10 resultados. A fonte confirmada apareceu em primeiro lugar em 10 de 14 perguntas reais, contra 7 sem reordenação. Houve também uma pergunta que piorou de posição.

Esse resultado sustenta um ganho na ordenação para a configuração medida. Não mostra quantas perguntas receberam respostas corretas nem demonstra uma vantagem causada pela troca de armazenamento. A revisão também encontrou um limite na própria lista de fontes de referência, que incluía um atendimento confirmado sem orientação útil.

Também avaliamos um conjunto separado de 32 perguntas sintéticas, criadas a partir do próprio acervo e sem validação humana prévia. Uma configuração que foi melhor nessas perguntas ficou pior nas reais. Por isso, o resultado sintético serviu como apoio à investigação, sem substituir a comparação com dúvidas reais.

O rerank também mudou a escala da pontuação usada pelo agente para aceitar um resultado. Ao reaplicar o corte antigo aos registros, o agente descartaria fontes confirmadas. A adoção da reordenação precisa, portanto, incluir uma revisão desse corte com exemplos que devem ser aceitos e perguntas que a base não consegue responder. Manter o mesmo valor só porque a busca continua devolvendo uma pontuação pode anular parte do ganho.

Preservar a mudança de orientação

Uma conversa de suporte registra hipóteses e correções junto da solução. Essa sequência precisa fazer parte da avaliação da resposta.

Considere um exemplo fictício, criado apenas para ilustrar o problema. Uma pessoa abre um chamado porque um relatório veio vazio. O atendente sugere atualizar o aplicativo. Depois de examinar as informações, percebe que a versão está correta e retira essa orientação. O problema era o filtro de período. A pessoa ajusta o filtro, gera o relatório novamente e confirma que os dados apareceram.

Uma resposta que recomenda atualizar o aplicativo pode citar uma frase real desse atendimento. O erro está em apresentar a tentativa inicial como solução, ignorando a correção que veio depois.

Também faltaria um passo se a resposta dissesse apenas para ajustar o filtro, sem mencionar que é preciso gerar o relatório novamente. E a confirmação de que funcionou naquele chamado não basta para dizer que o procedimento resolve qualquer relatório vazio.

Para avaliar fidelidade, precisamos conferir quem fez cada afirmação, se ela foi mantida ou revista e a que resultado a confirmação se refere. Verificar apenas a existência da citação deixa essas relações de fora.

Divisão em trechos conforme o conteúdo

A divisão dos documentos em trechos, ou chunking, afeta o que a busca consegue localizar e quanto contexto chega ao modelo. Além do tamanho, interessa onde fica o corte. Uma orientação e sua correção podem acabar em trechos diferentes. No piloto da abertura, porém, o desfecho já estava no contexto; a falha ocorreu na interpretação.

Comparamos o corte padrão, blocos por turno de conversa e a divisão hierárquica. Nesta última, a busca procura em trechos menores e pode devolver uma parte maior do documento para ampliar o contexto, como descreve a documentação de chunking do Bedrock.

Também comparamos Titan V2 e Cohere v3, modelos que criam as representações numéricas usadas na busca. Nem a troca entre eles nem a mudança na divisão do texto mostrou uma vantagem consistente nas perguntas reais. O estudo não sustenta escolher uma dessas alternativas como padrão superior para toda base.

Os critérios de preparo precisam levar em conta o tipo de conteúdo. Nas conversas em TXT, precisamos preservar quem falou, a ordem das mensagens e a ligação entre pergunta, orientação e confirmação. A correção de uma tentativa anterior precisa continuar acessível.

Nos manuais em PDF, HTML ou Markdown, a revisão deve conferir o texto extraído e manter títulos, condições e exceções junto do procedimento. Nas tabelas, cada valor precisa continuar ligado ao cabeçalho certo.

Em FAQs e fichas resumidas, precisamos conferir a fonte de cada passo. Um atendimento sem solução não pode virar uma orientação pronta depois do resumo.

Esses critérios orientam a preparação e a revisão. Não representam uma comparação por formato já realizada pelo estudo nem um tamanho de trecho recomendado para qualquer arquivo.

Redução de volume e perdas no preparo

A limpeza retirou cabeçalhos repetidos, avisos automáticos e outros elementos das conversas. Reduziu a quantidade média de texto enviada ao modelo, mas não melhorou a recuperação nas perguntas reais. Em algumas perguntas, a entrada aumentou.

A revisão identificou respostas curtas do cliente removidas logo depois de perguntas do atendente. Uma mensagem de uma palavra pode confirmar que o procedimento funcionou. Quando a regra trata esse conteúdo como dispensável, a redução de volume pode vir acompanhada da perda do desfecho.

As fichas de FAQ geradas por modelo reduziram ainda mais a entrada. Porém, a leitura integral de quatro casos encontrou passos que não existiam nas conversas de origem. Eram atendimentos sem orientação suficiente, transformados em fichas que pareciam prontas para responder. Esses casos demonstraram uma falha, sem permitir calcular uma taxa de erro para todas as fichas.

A decisão de adotar um preparo mais compacto precisa considerar o conteúdo preservado. Comparar a conversa original com a versão preparada permite verificar se a orientação final, as correções e a confirmação continuam presentes. A contagem de texto, sozinha, não responde a essa questão.

Anonimização e conferência independente

O preparo combinou regras, dicionários e detectores de dados pessoais. Na revisão, outros detectores encontraram resíduos que a conferência baseada nas mesmas regras da anonimização não havia acusado.

Esse resultado reforça a necessidade de uma conferência independente sobre o texto preparado e sobre o conteúdo efetivamente devolvido pela busca. O cuidado se estende às fichas e planilhas derivadas. Uma cópia recriada com outra versão do preparo pode perder proteções que já existiam no material revisado.

A substituição de nomes por marcadores também precisa preservar quem disse o quê. Na revisão, interessa tanto o que ficou exposto quanto o que foi removido sem necessidade. Apagar a identificação não deve apagar a sequência que permite interpretar o atendimento.

Critérios para avaliar a resposta final

Nesse caso, comparamos mudanças nas instruções, respostas organizadas em campos e uma troca de modelo. O procedimento final passou a aparecer, o formato melhorou e as citações passaram a apontar para os trechos certos. Ainda assim, nenhuma saída atendeu a todos os critérios. Faltavam limites importantes, e a interpretação da mudança de orientação continuava errada. As extrações reprovadas foram bloqueadas, em vez de virar uma orientação para o usuário.

Antes de julgar a saída, precisamos definir o que a resposta deve preservar, incluindo o procedimento completo, as orientações que foram revistas, a confirmação relatada e os limites do caso. A leitura das fontes completas e o registro de todo o contexto enviado ao modelo permitem investigar onde a falha aconteceu. Comparar uma mudança por vez ajuda a separar o efeito de cada escolha.

O que aprendemos com o estudo

O estudo mostrou onde cada ajuste contribuiu e onde ainda precisamos ter cuidado. O rerank trouxe uma melhora concreta na posição das fontes confirmadas. Já a redução do volume de texto exigiu uma revisão do que estava sendo removido, porque mensagens curtas e correções podiam ser essenciais para entender o atendimento. Nos pilotos de geração, mesmo com a informação disponível e as citações corretas, ainda encontramos respostas que mudavam o sentido da conversa.

Esses resultados ajudaram a definir uma forma mais cuidadosa de avaliar o RAG. Precisamos acompanhar o conteúdo desde a conversa original, conferir o que foi preservado no preparo, observar o que a busca recuperou e revisar como isso apareceu na resposta. Essa comparação permite identificar onde uma falha aconteceu e escolher o próximo ajuste com base no problema observado.

Os testes tiveram um recorte específico e não definem uma configuração ideal para toda base de atendimento. Ainda assim, deixam um aprendizado que orienta esse trabalho. Para transformar conversas em uma fonte útil de orientação, precisamos preservar o que elas contam, incluindo as tentativas, as correções e os limites da solução encontrada. É essa continuidade entre a fonte e a resposta que dá sentido aos ganhos de recuperação e aproxima o sistema da ajuda que a pessoa espera receber.