RAG na AWS com Amazon Bedrock Knowledge Bases: decisões de chunking, busca, avaliação e LGPD para ir a produção

RAG (geração aumentada por recuperação) é o padrão em que a aplicação busca os trechos mais relevantes dos documentos da empresa e os entrega ao modelo junto com a pergunta, para que a resposta se apoie neles e cite a fonte. Na AWS, o serviço gerenciado para isso é o Amazon Bedrock Knowledge Bases. Em produção, a qualidade da resposta depende mais da ingestão e da recuperação (como o documento é dividido, indexado, filtrado e reordenado) do que da escolha do modelo de geração.

Verificado contra a documentação do Amazon Bedrock Knowledge Bases na atualização de 15/10/2026. Modelos, regiões e opções de vector store mudam: confira a página oficial antes de decidir.

Isso muda onde o time investe. Trocar o modelo de geração altera um parâmetro da chamada; refazer o chunking exige uma nova fonte de dados e uma nova ingestão, porque a documentação do conector S3 registra que a estratégia de chunking não pode ser alterada depois que a fonte é conectada. As decisões abaixo seguem a ordem em que aparecem num projeto real: se RAG é o padrão certo, que tipo de base usar, como dividir o documento, onde guardar os vetores, como recuperar, como avaliar, como cumprir a LGPD e quanto isso custa.

Quando usar RAG, contexto direto ou ajuste fino

RAG resolve um problema específico: dar ao modelo acesso a um acervo que não cabe no prompt e que muda com frequência, com rastreabilidade de onde veio cada afirmação. Há dois caminhos vizinhos que resolvem outros problemas, e confundi-los é a primeira fonte de retrabalho.

• Contexto direto: o documento vai inteiro no prompt. O Amazon Bedrock oferece a consulta a um documento sem criar uma base de conhecimento, que atende bem a análise pontual de um contrato ou relatório.
• RAG: o acervo é indexado uma vez e atualizado por sincronização incremental; cada pergunta recupera só os trechos relevantes.
• Ajuste fino: a personalização de modelo ensina formato, tom e vocabulário de domínio. Ela altera o comportamento do modelo, e não cria vínculo entre a resposta e um documento citável.

Os três se combinam. Um assistente de suporte pode usar RAG para os fatos e um modelo ajustado para o formato da resposta. O critério que decide é a citação: se a área de negócio, o jurídico ou a auditoria precisam saber de onde veio a resposta, o desenho começa por RAG.

Knowledge Base gerenciada ou gerenciada por você

Desde a disponibilidade geral anunciada em 17 de junho de 2026, o Amazon Bedrock oferece dois tipos de base, e essa é a primeira decisão de arquitetura. A tabela comparativa da documentação resume as diferenças:

• Managed Knowledge Base: a AWS opera o armazenamento, a indexação e a recuperação. A busca é sempre híbrida, o reranking gerenciado vem ligado por padrão, há recuperação agêntica para consultas de vários passos, conectores nativos (S3, SharePoint, Confluence, Google Drive, OneDrive, Web Crawler e Custom), filtro de permissão por documento com listas de controle de acesso (exceto no Web Crawler) e integração com o Amazon Bedrock AgentCore Gateway.
• Customer-managed Knowledge Base: você escolhe, provisiona e opera o vector store, define a estratégia de busca e tem acesso direto ao índice. É o modelo que aceita as estratégias de chunking hierárquica e semântica descritas adiante.

Dois detalhes mudam o desenho. Primeiro, a API RetrieveAndGenerate não funciona com a base gerenciada; nela, a aplicação usa Retrieve ou AgenticRetrieveStream e faz a geração por conta própria. Segundo, a lista de Regiões da base gerenciada na documentação não inclui São Paulo. Para quem precisa manter documentos e índice no Brasil, o caminho é a base gerenciada por você, que é o foco do restante deste guia.

Arquitetura de referência

O fluxo de uma base gerenciada por você, com as decisões de segurança já posicionadas:

Fontes internas (SharePoint, wiki, ERP, pastas de rede)
   |  rotina de cópia controlada pelo projeto
   v
Amazon S3, bucket de uso geral na mesma Região da base
   |  Amazon Macie: descoberta de dado pessoal antes da ingestão
   |  arquivo .metadata.json ao lado de cada documento
   v
Ingestão (StartIngestionJob, sincronização incremental)
   parsing -> chunking -> modelo de embeddings
   v
Vector store (OpenSearch Serverless, Aurora PostgreSQL, S3 Vectors...)
   ^
   |  Retrieve: filtro de metadados + busca híbrida + reranking
   |
API do assistente (Amazon API Gateway + AWS Lambda)
   |  tenant e nível de acesso lidos do token validado
   v
Modelo de geração (Converse ou RetrieveAndGenerate)
   |  Amazon Bedrock Guardrails: dado sensível e fundamentação contextual
   v
Resposta com citações para o usuário

A primeira escolha de código é entre as duas APIs de consulta descritas no guia de recuperação:

• Retrieve: devolve os trechos com content, location, metadata e score. A aplicação monta o prompt, chama o modelo e aplica o Amazon Bedrock Guardrails. Mais código, controle total do prompt, do modelo e do registro de auditoria.
• RetrieveAndGenerate: recupera, gera e devolve a resposta com citations, cada uma ligando um trecho do texto gerado às referências recuperadas. Aceita guardrailConfiguration, modelo de prompt próprio e sessão de conversa.

Um detalhe da documentação orienta essa escolha: o Guardrails é aplicado à entrada e à resposta gerada, e não aos trechos recuperados da base. Se um documento indexado contém dado pessoal, o trecho volta inteiro na resposta da Retrieve. O controle de dado sensível, portanto, começa na fonte, antes da ingestão.

Chunking: opções e trade-off

Chunking é a divisão do documento em trechos que viram embeddings. Trecho pequeno gera embedding preciso e contexto pobre; trecho grande traz contexto e dilui a relevância. A documentação de chunking descreve as opções:

• Padrão: trechos de aproximadamente 300 tokens, respeitando o limite das frases. É o ponto de partida da comparação.
• Tamanho fixo: você define o máximo de tokens por trecho e o percentual de sobreposição entre trechos vizinhos. Na referência da API, maxTokens vai de 1 a 8.192 e overlapPercentage de 1 a 99. Em conteúdo com parsing avançado, o serviço respeita limites lógicos como páginas e seções e não junta conteúdo entre eles.
• Hierárquico: dois níveis, pai e filho, com sobreposição em tokens. A busca encontra o trecho filho, mais preciso, e entrega ao modelo o trecho pai, mais completo. Por isso o número de resultados devolvidos pode ser menor que o solicitado. A documentação não recomenda essa estratégia com S3 Vectors e alerta que, acima de 8.000 tokens combinados, o tamanho dos metadados pode estourar o limite.
• Semântico: compara frases vizinhas e corta onde a dissimilaridade passa de um limiar em percentil. Os parâmetros são o máximo de tokens, o buffer (frases vizinhas consideradas no embedding, de 0 a 1 na referência da API) e o limiar de percentil, de 50 a 99. Limiar mais alto gera menos trechos e trechos maiores. Usa um modelo de fundação na ingestão, com custo adicional proporcional ao volume de dados.
• Sem chunking: cada arquivo vira um trecho. Combina com pré-processamento que já entrega um arquivo por unidade de sentido. Nessa opção, a citação perde o número de página e o filtro pelo campo x-amz-bedrock-kb-document-page-number deixa de existir.
• Lambda de transformação: uma função própria executada na etapa POST_CHUNKING, com um bucket S3 intermediário. Serve para chunking que o serviço não oferece (com a estratégia sem chunking) ou para acrescentar metadados por trecho sobre uma estratégia nativa. Metadado de trecho prevalece sobre o de arquivo em caso de colisão.
• Multimodal: as estratégias de texto valem só para texto. Com Amazon Nova Multimodal Embeddings, áudio e vídeo são divididos por duração, configurável de 1 a 30 segundos; com o parser do Amazon Bedrock Data Automation, o conteúdo vira texto (transcrição e resumo de cena) e segue as estratégias de texto.

A configuração vai em vectorIngestionConfiguration, na criação da fonte de dados. Os valores abaixo são de exemplo, para calibrar com a avaliação:

# Tamanho fixo
"chunkingConfiguration": {
  "chunkingStrategy": "FIXED_SIZE",
  "fixedSizeChunkingConfiguration": { "maxTokens": 300, "overlapPercentage": 20 }
}

# Hierárquico: primeiro nível é o pai, segundo é o filho
"chunkingConfiguration": {
  "chunkingStrategy": "HIERARCHICAL",
  "hierarchicalChunkingConfiguration": {
    "levelConfigurations": [ { "maxTokens": 1500 }, { "maxTokens": 300 } ],
    "overlapTokens": 60
  }
}

# Semântico
"chunkingConfiguration": {
  "chunkingStrategy": "SEMANTIC",
  "semanticChunkingConfiguration": {
    "maxTokens": 300,
    "bufferSize": 1,
    "breakpointPercentileThreshold": 95
  }
}

Ponto de partida por tipo de documento, a confirmar no conjunto de perguntas de referência:

Escolha do vector store

O vector store guarda os embeddings, o texto dos trechos e os metadados. A página de pré-requisitos lista as opções suportadas pela base gerenciada por você. Os dois eixos que mais pesam são o modelo de custo (capacidade fixa ou cobrança por uso) e o suporte a busca híbrida, que combina embeddings com busca no texto bruto.

A coluna de busca híbrida segue a página de configuração de consultas, que cita Amazon RDS, OpenSearch Serverless e MongoDB. A referência da API menciona apenas OpenSearch Serverless. Segundo a página de configuração, em store sem suporte a consulta cai para busca semântica, sem erro. Quando a busca híbrida for requisito, um teste simples resolve a dúvida antes de fechar o desenho: chamar a Retrieve no store escolhido com overrideSearchType em HYBRID e depois em SEMANTIC, com as mesmas perguntas do conjunto de referência, e comparar os trechos devolvidos. Listas idênticas em todas as perguntas, inclusive nas que dependem de termo exato (código de produto, número de cláusula), indicam que a consulta está caindo para a busca semântica.

Sobre custo, a documentação do OpenSearch Serverless permite mínimo zero de OCU por grupo de coleções, com o efeito de partida a frio na primeira consulta, e um máximo que funciona como teto de gasto. O Amazon S3 Vectors, que consta como disponível em São Paulo na página de Regiões e cotas do S3 Vectors, é descrito pela AWS como adequado a cargas de consulta pouco frequente. Um assistente interno usado em horário comercial e uma busca exposta a clientes com tráfego constante levam a escolhas diferentes.

Recuperação: metadados, busca híbrida e reranking

Por padrão, a consulta devolve até cinco trechos. O parâmetro numberOfResults aceita de 1 a 100. Mais trechos aumentam a chance de trazer a resposta e também os tokens enviados ao modelo e o ruído no contexto. No chunking hierárquico, o número se refere aos trechos filhos, e filhos do mesmo pai são substituídos por um único pai.

O filtro de metadados é a ferramenta que mais melhora a precisão e a que sustenta o isolamento entre clientes ou áreas. No S3, cada documento ganha um arquivo com o mesmo nome acrescido de .metadata.json, na mesma pasta, com limite de 10 KB, conforme a documentação do conector:

{
  "metadataAttributes": {
    "tenant_id": {
      "value": { "type": "STRING", "stringValue": "cliente-0042" },
      "includeForEmbedding": false
    },
    "area": {
      "value": { "type": "STRING", "stringValue": "financeiro" },
      "includeForEmbedding": true
    },
    "nivel_acesso": {
      "value": { "type": "NUMBER", "numberValue": 2 },
      "includeForEmbedding": false
    },
    "vigente_ate": {
      "value": { "type": "NUMBER", "numberValue": 20271231 },
      "includeForEmbedding": false
    }
  }
}

O campo includeForEmbedding decide se o par chave e valor é concatenado ao texto antes do embedding. Com true, consultas que mencionam o valor ("política do financeiro") ganham relevância; com false, o metadado serve só para filtro. Identificador de cliente e nível de acesso ficam fora do embedding: são controle, não conteúdo.

O ponto de segurança mais importante deste guia está no mesmo documento: todo dado sincronizado fica disponível para qualquer identidade com a permissão bedrock:Retrieve na base. O filtro é um parâmetro da consulta, e não uma autorização. Por isso ele é montado no servidor, a partir da identidade já validada, e nunca a partir de um campo que o cliente envia:

import os
import boto3

kb = boto3.client("bedrock-agent-runtime", region_name=os.environ["AWS_REGION"])
KB_ID = os.environ["KNOWLEDGE_BASE_ID"]

def recuperar(pergunta: str, claims: dict) -> list:
    # claims vêm do autorizador do API Gateway (token já validado),
    # nunca do corpo da solicitação enviada pelo navegador
    filtro = {
        "andAll": [
            {"equals": {"key": "tenant_id", "value": claims["tenant_id"]}},
            {"lessThanOrEquals": {"key": "nivel_acesso",
                                  "value": int(claims["nivel_acesso"])}},
        ]
    }
    resposta = kb.retrieve(
        knowledgeBaseId=KB_ID,
        retrievalQuery={"text": pergunta},
        retrievalConfiguration={
            "vectorSearchConfiguration": {
                # valor ilustrativo, calibrar com o conjunto de referência
                "numberOfResults": 8,
                "overrideSearchType": "HYBRID",
                "filter": filtro,
            }
        },
    )
    return resposta["retrievalResults"]

Os operadores disponíveis e as combinações com andAll e orAll (até cinco expressões por grupo) estão na página de configuração de consultas. Alguns operadores dependem do store: in e notIn têm melhor suporte em OpenSearch Serverless e Neptune Analytics, e S3 Vectors não aceita startsWith nem stringContains. A mesma página descreve o filtro implícito, em que um modelo Anthropic Claude gera o filtro a partir da pergunta e de um esquema de metadados. Ele ajuda na relevância (área, período); o filtro de isolamento continua explícito.

Quando o contrato exige separação forte entre clientes, uma base por cliente elimina a dependência do filtro e permite escopar a permissão bedrock:Retrieve pelo ARN de cada base, com o custo de operar mais bases e mais índices. O filtro por metadados atende o isolamento entre áreas de uma mesma empresa; a base por cliente atende o contrato que proíbe qualquer índice compartilhado.

O reranking reordena os trechos recuperados com um modelo dedicado antes de entregá-los ao modelo de geração. A lista de modelos de reranking traz o Amazon Rerank 1.0 e o Cohere Rerank 3.5 e lista as Regiões de cada modelo; São Paulo não consta. O padrão de uso é recuperar um número de trechos maior que o final e entregar ao modelo só os melhores após o reranking, com numberOfRerankedResults. Para perguntas compostas, a decomposição de consulta divide a pergunta em subconsultas antes da busca.

Avaliar antes de publicar

A avaliação transforma a discussão sobre chunking, número de trechos e modelo em decisão com evidência. As avaliações do Amazon Bedrock para RAG têm dois tipos de job, e ambos aceitam uma Knowledge Base ou respostas de uma fonte RAG externa:

• Retrieve only (somente recuperação): mede a qualidade dos trechos recuperados. Métricas integradas: Context relevance e Context coverage. A segunda exige resposta de referência no conjunto de dados.
• Retrieve and generate (recuperação e geração): mede a resposta final. Métricas: Correctness, Completeness, Helpfulness, Logical coherence, Faithfulness, Citation precision e Citation coverage, além das métricas de IA responsável Harmfulness, Stereotyping e Refusal.

O conjunto de perguntas de referência usa JSON Lines, com até 1.000 prompts por conjunto, no formato da documentação do dataset. Uma linha, expandida para leitura:

{
  "conversationTurns": [
    {
      "prompt": {
        "content": [
          { "text": "Qual o prazo para solicitar reembolso de despesa de viagem?" }
        ]
      },
      "referenceResponses": [
        {
          "content": [
            { "text": "O prazo está na política de viagens, seção 4: até o fim do mês seguinte ao retorno." }
          ]
        }
      ]
    }
  ]
}

O conjunto é o ativo mais valioso do projeto, e a qualidade dele vem de quem conhece o negócio. Um método que funciona:

1. Colete perguntas reais com as áreas que vão usar o assistente, incluindo as mal formuladas e as que o acervo não responde.
2. Escreva a resposta de referência com a área dona do documento, apontando a seção de origem.
3. Inclua perguntas de fronteira: documento revogado, informação de outro cliente, pergunta fora do escopo. Elas medem filtro, vigência e recusa.
4. Defina o mínimo aceitável por métrica antes de rodar, com a área de negócio, e registre a decisão.
5. Rode de novo a cada mudança de chunking, modelo de embeddings, modelo de geração, número de trechos ou modelo de prompt. Como o chunking não muda numa fonte existente, a comparação é feita com uma segunda fonte de dados ou uma segunda base, em paralelo, com o mesmo conjunto.

Construindo o assistente RAG com o Kiro

O Kiro, a IA agêntica da AWS para desenvolvimento de software, organiza o trabalho do agente em artefatos versionados no repositório: steering para as regras permanentes, specs para requisito, desenho e tarefas, hooks para automação disparada por evento e MCP para ferramentas externas, conforme a documentação oficial. Num assistente RAG, esses artefatos têm uma função precisa: impedir que o agente, ao implementar uma tarefa, desfaça uma decisão de isolamento, de dado pessoal ou de avaliação que o time já tomou.

Steering: as regras que o agente não reinterpreta

O arquivo abaixo usa inclusão fileMatch, descrita na documentação de steering: ele entra no contexto quando o trabalho envolve o código do assistente ou a infraestrutura da base, e fica fora das demais tarefas do repositório.

---
inclusion: fileMatch
fileMatchPattern: ["src/assistente/**/*.py", "infra/kb/**"]
---
# Assistente RAG: regras do projeto

## Isolamento
- tenant_id e nivel_acesso vêm sempre das claims do autorizador do
  API Gateway. Nunca do corpo, da query string ou de cabeçalho enviado
  pelo cliente.
- Toda chamada à Retrieve passa por montar_filtro(), em
  src/assistente/filtro.py. Chamada direta ao cliente
  bedrock-agent-runtime fora desse módulo é erro de revisão.
- Filtro implícito (implicitFilterConfiguration) só melhora relevância;
  nunca substitui o filtro de tenant.

## Metadados
- tenant_id e nivel_acesso com includeForEmbedding false.
- Chave nova de metadado entra em docs/rag/metadados.md no mesmo PR.

## Chunking e ingestão
- A configuração de chunking vive em infra/kb/ e é versionada no IaC.
- Mudança de estratégia cria uma fonte de dados nova. A fonte existente
  não é editada, porque a estratégia não muda depois de conectada.
- Fonte de dados nova só recebe tráfego depois de aprovada pela spec
  avaliacao-rag.

## Dado pessoal
- Nenhum trecho recuperado, pergunta ou resposta em log. Registrar só
  ID de documento, score e ID da requisição.
- Nenhum segredo neste arquivo: IDs e credenciais vêm de variável de
  ambiente ou do AWS Secrets Manager.

As regras são verificáveis numa revisão de código, e é isso que as torna úteis ao agente: "sempre das claims do autorizador" vira um ponto que o revisor confere linha a linha. O desenho completo de escopos, modos de inclusão e manutenção do steering está em steering no Kiro.

Spec: o conjunto de referência como critério de aceite

A spec transforma a avaliação descrita acima em requisito. Os critérios seguem a notação EARS, que a página de Feature Specs adota para o requirements.md:

# Requisitos: avaliação do assistente RAG

## Requisito 2: aprovação de configuração nova da base

**User story:** Como dono do assistente, quero que toda configuração
nova de chunking, embeddings ou vector store seja avaliada com o
conjunto de referência antes de receber tráfego, para que a mudança
não piore as respostas sem que ninguém perceba.

### Critérios de aceitação
1. WHEN a ingestão da fonte de dados nova terminar com status COMPLETE,
   THE SYSTEM SHALL executar um job de avaliação Retrieve only com o
   conjunto versionado em eval/referencia.jsonl.
2. THE SYSTEM SHALL comparar Context relevance e Context coverage com
   os mínimos registrados em docs/rag/limiares.md, acordados com a
   área de negócio antes da primeira execução.
3. IF alguma métrica ficar abaixo do mínimo, THEN THE SYSTEM SHALL
   bloquear a promoção da configuração nova e registrar o resultado
   no PR.
4. WHEN o teste de isolamento consultar, com as claims do tenant A,
   uma pergunta cuja resposta só existe em documento do tenant B,
   THE SYSTEM SHALL devolver zero trechos com tenant_id do tenant B.
5. THE SYSTEM SHALL anexar ao PR o ARN do job de avaliação e o caminho
   dos resultados no Amazon S3.

Os mínimos ficam fora da spec, num arquivo próprio, por um motivo prático: quem decide o patamar aceitável é a área dona do conteúdo, e o valor muda quando o acervo muda. A spec fixa a regra (comparar e bloquear); o arquivo de limiares guarda o número acordado e o histórico de quem o aprovou. O ciclo de requisito, desenho e tarefas revisados está em specs no Kiro.

Hook: avaliação disparada quando a configuração da base muda

O gatilho óbvio seria salvar o arquivo de chunking, e ele leva a um resultado enganoso: no momento em que o arquivo é salvo, a fonte de dados nova ainda não foi criada nem ingerida, e a avaliação mediria o índice antigo. Por isso o hook usa PostTaskExec, que a documentação de tipos de hook descreve como disparado depois que uma tarefa da spec termina, e o próprio script decide se há o que avaliar:

{
  "version": "v1",
  "hooks": [
    {
      "name": "avaliar-rag",
      "description": "Dispara a avaliação Retrieve only quando a tarefa alterou a configuração da base",
      "trigger": "PostTaskExec",
      "action": { "type": "command", "command": "tools/kiro-hooks/avaliar-rag.sh" }
    }
  ]
}

#!/usr/bin/env bash
set -euo pipefail

# Só avalia se a tarefa alterou a configuração da base
if git diff --quiet origin/main -- infra/kb/; then
  echo "Configuração da base inalterada; avaliação não disparada."
  exit 0
fi

# Conta de desenvolvimento, nunca a de produção
export AWS_PROFILE=rag-dev

ARN=$(aws bedrock create-evaluation-job \
  --cli-input-json file://eval/job-retrieve-only.json \
  --job-name "rag-ro-$(date +%Y%m%d%H%M%S)" \
  --query jobArn --output text)

echo "Avaliação disparada: $ARN"
echo "Status: aws bedrock get-evaluation-job --job-identifier $ARN"

Três decisões estão embutidas nesses dois arquivos:

• O hook dispara e não espera. O job de avaliação é assíncrono, e a documentação de ações de hook aplica ao comando um tempo limite de execução, de 60 segundos por padrão. O script devolve o ARN, que entra no contexto do agente pela saída padrão, e a conferência do resultado contra os limiares é uma tarefa da spec.
• O nome do job é gerado a cada execução. A configuração do job (base, modelo avaliador, papel de serviço, conjunto e bucket de saída) fica em eval/job-retrieve-only.json, no formato da página de criação de job Retrieve only; o nome passado na linha de comando muda em cada disparo.
• A avaliação tem custo. O job consome inferência do modelo avaliador, cobrada conforme a página de preços do Amazon Bedrock. O filtro por git diff evita pagar por uma avaliação a cada tarefa que não tocou na base.

Gatilhos, formato do JSON, códigos de saída e os cuidados com hooks de comando e de agente estão em hooks no Kiro.

MCP: consultar a base de desenvolvimento a partir do Kiro

Durante a calibragem do chunking, ver os trechos que a base devolve para uma pergunta acelera o diagnóstico. O Amazon Bedrock Knowledge Base Retrieval MCP Server, do repositório awslabs/mcp, expõe ao agente as ferramentas ListKnowledgeBases e QueryKnowledgeBases. A configuração segue o formato da documentação de MCP do Kiro:

{
  "mcpServers": {
    "kb": {
      "command": "uvx",
      "args": ["awslabs.bedrock-kb-retrieval-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "rag-dev",
        "AWS_REGION": "sa-east-1",
        "FASTMCP_LOG_LEVEL": "ERROR",
        "BEDROCK_KB_RERANKING_ENABLED": "false"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Os cuidados vêm da própria documentação do servidor e do desenho de isolamento deste guia:

• Só a base de desenvolvimento fica visível. O servidor lista as bases que têm a tag mcp-multirag-kb com valor true. Marque apenas a base de desenvolvimento e escope a permissão de consulta do perfil rag-dev pelo ARN dela.
• O filtro de tenant não vale aqui. A consulta pelo MCP não passa por montar_filtro(), e os trechos devolvidos entram no contexto do agente. A base de desenvolvimento recebe documentos sintéticos ou anonimizados, nunca o acervo de produção com dado pessoal.
• Reranking desligado em São Paulo. O servidor lê BEDROCK_KB_RERANKING_ENABLED e exige modelo de reranking disponível na Região; como São Paulo não consta na lista de Regiões dos modelos de reranking, o valor fica em false.
• Confirmação mantida. Com autoApprove vazio, cada consulta passa pela aprovação de quem está no Kiro, o que deixa visível o que entra no contexto.

Escopo de servidores, agentes personalizados com ferramentas restritas e governança de MCP estão em MCP no Kiro.

Segurança e LGPD

Um assistente RAG trata dado pessoal sempre que os documentos contêm dado pessoal, e quase todo acervo corporativo contém: contratos, atas, chamados, currículos. Os controles abaixo se somam ao desenho de LGPD na nuvem.

Descoberta antes da ingestão. O Amazon Macie descobre dado sensível em buckets S3 de uso geral, com identificadores gerenciados e identificadores próprios por expressão regular. Rodar um job de descoberta no bucket de origem antes da primeira sincronização mostra o que vai entrar no índice. Documento com dado pessoal que não serve à finalidade do assistente sai do escopo ou é anonimizado antes da ingestão, já que o Guardrails não atua sobre os trechos recuperados.

Exclusão na fonte. A documentação de sincronização registra que documento apagado na fonte é removido do vector store na próxima sincronização. Isso dá um fluxo verificável para a solicitação de eliminação de um titular: apagar o objeto e o arquivo de metadados no S3, executar StartIngestionJob, confirmar o status COMPLETE e consultar com um filtro pelo documento para provar que ele não volta mais. Dois cuidados: a política de exclusão de dados da fonte (DELETE ou RETAIN) define se os vetores ficam no store quando a própria fonte é removida, e o bucket intermediário da Lambda de transformação também guarda cópias que precisam de regra de ciclo de vida.

Isolamento. Permissão bedrock:Retrieve escopada pelo ARN da base, filtro montado no servidor e, quando o contrato pedir, base por cliente. Na base gerenciada, há filtro por lista de controle de acesso com contexto do usuário na consulta, nas Regiões em que ela está disponível.

Região e inferência entre Regiões. O bucket S3 precisa estar na mesma Região da base, e os modelos de embeddings Amazon Titan Text Embeddings V2 e Cohere Embed Multilingual constam como disponíveis em São Paulo na tabela de modelos suportados. Documentos, índice e embeddings ficam no Brasil. O modelo de geração é a decisão sensível: com inferência entre Regiões, prompts e respostas podem ser processados fora da Região de origem, e o que é armazenado para detecção de abuso fica na Região de destino. O prompt de um RAG carrega os trechos recuperados, então essa decisão alcança o conteúdo dos documentos. Três práticas: chamar GetInferenceProfile a partir de São Paulo para ver as Regiões de destino reais (a documentação orienta não confiar só no prefixo do perfil), auditar pelo campo additionalEventData.inferenceRegion do AWS CloudTrail e registrar a escolha no inventário de tratamento, com a análise de transferência internacional prevista nos artigos 33 a 36 da LGPD e regulamentada pela ANPD na Resolução CD/ANPD nº 19/2024.

Fundamentação contextual. A verificação de fundamentação contextual do Amazon Bedrock Guardrails pontua se a resposta está ancorada na fonte (grounding) e se responde à pergunta (relevance), com limiares configuráveis de 0 a 0,99. Os limites documentados são 100.000 caracteres de fonte, 1.000 de pergunta e 5.000 de resposta. A documentação lista sumarização, paráfrase e pergunta e resposta como casos suportados e exclui o chatbot conversacional; em streaming, uma resposta irrelevante pode chegar ao usuário antes de ser marcada. No mesmo guardrail, o filtro de informação sensível bloqueia ou mascara dado pessoal na resposta gerada.

Custo

O custo de um RAG tem componentes fixos e variáveis, e cada decisão técnica acima move um deles. A referência de preços é a página oficial do Amazon Bedrock, cotada em dólar, com o câmbio entrando no orçamento em real.

• Embeddings na ingestão: cobrados pelos tokens do modelo de embeddings na primeira carga e em cada documento alterado. Quando só o arquivo de metadados muda (e o documento não é CSV nem passa por Lambda de transformação), a sincronização atualiza os metadados sem chamar o modelo de embeddings.
• Vector store: capacidade mínima no OpenSearch Serverless, cluster no Aurora ou cobrança por uso no S3 Vectors. É o componente que existe mesmo sem nenhuma pergunta.
• Tokens de contexto: número de trechos vezes tamanho do trecho, somado à pergunta e ao modelo de prompt, a cada pergunta. É aqui que numberOfResults e o chunking hierárquico (que entrega o pai, maior) aparecem na fatura.
• Chunking semântico: usa um modelo de fundação na ingestão, com custo proporcional ao volume de dados.
• Reranking: cobrado por consulta, e cada consulta cobre até 100 trechos, segundo a página de preços.
• Guardrails: a fundamentação contextual é cobrada por unidade de texto, contada sobre fonte, pergunta e resposta somadas.
• Base gerenciada: armazenamento do índice por GB e chamadas de recuperação; embeddings e reranking gerenciados sem custo adicional, segundo a tabela comparativa da documentação.

Como alocar esse custo por produto e por cliente, e limitar o gasto de inferência no próprio código, está em FinOps de IA generativa na AWS.

Checklist de prontidão

1. Tipo de base decidido (gerenciada ou gerenciada por você) com a Região e a necessidade de residência registradas.
2. Inventário do acervo com dono por pasta e job do Amazon Macie executado antes da primeira sincronização.
3. Arquivo .metadata.json em todo documento, com tenant, área, nível de acesso e vigência.
4. Estratégia de chunking escolhida por comparação no conjunto de referência, com a configuração versionada no IaC.
5. Vector store escolhido pelo padrão de consulta, com mínimo e máximo de capacidade definidos.
6. Filtro de isolamento montado no servidor a partir do token; teste automatizado que tenta ler documento de outro tenant.
7. Permissão bedrock:Retrieve escopada pelo ARN da base, sem curinga.
8. numberOfResults e reranking calibrados pelas métricas, e não por intuição.
9. Conjunto de perguntas de referência com perguntas de fronteira e mínimo aceitável por métrica acordado com a área.
10. Job de avaliação executado de novo a cada mudança de chunking, modelo ou prompt.
11. Amazon Bedrock Guardrails com filtro de informação sensível e fundamentação contextual onde o caso de uso é suportado.
12. Perfil de inferência verificado com GetInferenceProfile e decisão registrada no inventário de tratamento.
13. Fluxo de eliminação testado: apagar na fonte, sincronizar, provar a ausência.
14. Citações exibidas ao usuário com link para o documento de origem.
15. Orçamento e alarme de custo por componente, com o dono de cada um.

Um assistente sobre documentos internos chega a produção quando cada item tem dono e evidência. É esse o recorte de um projeto de IA aplicada com a RFX Tecnologia: escolher o acervo inicial, desenhar ingestão, recuperação e isolamento, montar o conjunto de avaliação com a sua área de negócio e deixar LGPD e custo documentados desde a primeira sincronização.

Para o time escrever a spec do assistente com método, com steering, specs, hooks e MCP no repositório, veja a adoção do Kiro com a RFX.

Para ver como um projeto desse tipo é escopado, com requisitos, decisões de arquitetura e entregáveis, consulte o exemplo de escopo do assistente com Amazon Bedrock Knowledge Bases. Quando o assistente passa a executar ações nos sistemas, o próximo passo é o desenho de agentes com Amazon Bedrock AgentCore; o uso de IA generativa no ciclo de desenvolvimento está em IA generativa no SDLC com Amazon Bedrock.

Perguntas frequentes

O que é RAG na AWS?

RAG (geração aumentada por recuperação) é o padrão em que a aplicação busca trechos relevantes dos documentos da empresa e os entrega ao modelo junto com a pergunta, para que a resposta se apoie nesses trechos e cite a fonte. Na AWS, o serviço gerenciado para isso é o Amazon Bedrock Knowledge Bases, que cuida da ingestão, da divisão em trechos (chunking), dos embeddings, do índice vetorial e da recuperação.

Qual estratégia de chunking usar no Amazon Bedrock Knowledge Bases?

Comece pelo chunking padrão, que divide o texto em trechos de aproximadamente 300 tokens respeitando o fim das frases, e compare com as alternativas usando um conjunto de perguntas de referência. Documentos longos e bem seccionados tendem a se beneficiar do hierárquico, textos sem estrutura do semântico, e formatos próprios de uma Lambda de transformação. A estratégia não pode ser alterada depois que a fonte de dados é conectada, então a comparação vem antes da produção.

Qual vector store escolher para uma Knowledge Base?

Depende de três fatores: padrão de consulta, necessidade de busca híbrida e modelo de custo. Segundo a documentação do Amazon Bedrock, a busca híbrida é suportada em Amazon RDS (Aurora PostgreSQL), Amazon OpenSearch Serverless e MongoDB com campo de texto filtrável. Amazon S3 Vectors é cobrado por uso e indicado para consultas pouco frequentes. OpenSearch Serverless cobra a capacidade mínima configurada mesmo sem tráfego.

Como isolar documentos de clientes ou áreas diferentes na mesma Knowledge Base?

Com um arquivo de metadados por documento (tenant, área, nível de acesso) e um filtro aplicado em toda consulta. O filtro precisa ser montado no servidor a partir da identidade autenticada, porque a documentação registra que todo dado sincronizado fica disponível para quem tem a permissão bedrock:Retrieve. Para isolamento contratual forte, uma base por cliente elimina a dependência do filtro.

Dá para manter documentos e índice de uma Knowledge Base no Brasil?

Sim, com a Knowledge Base gerenciada por você na Região de São Paulo: o bucket S3 precisa estar na mesma Região da base, e os modelos de embeddings Amazon Titan Text Embeddings V2 e Cohere Embed Multilingual constam como disponíveis em sa-east-1. O ponto de atenção é o modelo de geração: com inferência entre Regiões, prompts e respostas podem ser processados fora da Região de origem, o que entra no registro de tratamento e na análise de transferência internacional.

Como avaliar um assistente RAG antes de publicar?

Com as avaliações do Amazon Bedrock para RAG, em dois modos: somente recuperação (métricas Context relevance e Context coverage) e recuperação e geração (Correctness, Completeness, Helpfulness, Logical coherence, Faithfulness, Citation precision, Citation coverage e métricas de IA responsável). O conjunto de perguntas de referência, em JSON Lines, aceita até 1.000 prompts e deve ser executado de novo a cada mudança de chunking, modelo ou prompt.

Sobre o autor

Rodrigo Araújo

Arquiteto de Soluções, IA e Cloud | RFX Tecnologia

Arquiteto de Soluções, IA e Cloud na RFX Tecnologia, lidera projetos de migração, FinOps e IA aplicada na nuvem para empresas do Nordeste e de todo o Brasil. É também o idealizador da Jornada de Inovação AWS em João Pessoa, encontro que aproxima donos de negócio da região das aplicações reais de cloud e inteligência artificial.