Bedrock Knowledge Bases — RAG gerenciado
- ⬜🪨 Amazon Bedrock — modelos, invocação e pricing(AWS AI Practitioner (AIF-C01))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Knowledge Bases é o RAG do Bedrock com as peças já montadas. Você aponta para um bucket, escolhe um modelo de embedding e um banco vetorial, e o serviço faz o resto: quebra o documento em pedaços, gera o vetor de cada pedaço, indexa, e na hora da pergunta recupera os trechos mais próximos e os injeta no prompt.
Isso resolve o problema mais citado de foundation model: ele não conhece o seu dado. O modelo foi treinado até uma data, com material público. Sua política de reembolso interna, o contrato do cliente e o manual do seu produto não estavam lá. RAG é como colocar isso na mesa no momento da pergunta, em vez de tentar enfiar no modelo.
Por que não basta colar o documento no prompt
A primeira ideia de todo mundo é: se o modelo aceita 200 mil tokens, jogo o manual inteiro. Funciona para um manual. Deixa de funcionar por três motivos, e o exame cobra os três.
| Tentativa | Onde quebra |
|---|---|
| Colar tudo no prompt | Você paga tokens de entrada em CADA pergunta. Um manual de 100 mil tokens consultado mil vezes por dia custa como se você tivesse lido o manual mil vezes — porque foi isso que aconteceu. |
| Colar tudo no prompt (parte 2) | Acima de certo volume a precisão cai: informação relevante no meio de muito contexto irrelevante é mais difícil de usar. Mais contexto não é linearmente melhor. |
| Fine-tuning do documento | Fine-tuning ensina forma e estilo, não fatos consultáveis. E cada atualização do documento exige treinar de novo. Documento que muda toda semana é o caso onde fine-tuning é a pior escolha. |
| RAG | Recupera só os 3–5 trechos relevantes por pergunta. Paga tokens do que importa, atualiza trocando o arquivo no S3, e o modelo pode citar a fonte. |
Como isso aparece no exame
A pergunta de prova costuma vir disfarçada: "a base de conhecimento muda diariamente e a empresa quer respostas com citação da fonte". Duas pistas, uma resposta: muda diariamente elimina fine-tuning; citar a fonte é característica de RAG, porque só o RAG sabe de qual documento o trecho veio.
O caminho completo, da ingestão à resposta
Knowledge Bases tem dois tempos distintos, e confundi-los é a fonte mais comum de erro conceitual. A ingestão acontece uma vez por documento e é caríssima em comparação. A consulta acontece a cada pergunta e é barata. Quem desenha achando que a ingestão roda a cada pergunta superestima o custo por dez.
- → sync
- → sync
- → cada pedaço
- → grava vetor
- → busca vizinhos
- → trechos + metadado
- → contexto
- → prompt montado
- → resposta + citação
- Armazenamento
- Fora da AWS
- Conceito de arquitetura
- Analytics
- IA e machine learning
Duas linhas de tempo no mesmo desenho: a de cima roda quando você sincroniza a base, a de baixo a cada pergunta. O custo de embedding é de ingestão; o custo de inferência é de consulta. Separar os dois é o que faz a conta fechar.
- O chunking decide a qualidade do RAG inteiro. Pedaço grande traz contexto sobrando e dilui a similaridade; pedaço pequeno perde o sentido que estava no parágrafo. Chunking hierárquico indexa o pedaço pequeno mas devolve o trecho maior ao redor — costuma ser o melhor default.
- Embedding transforma texto em coordenada. Cada pedaço vira um vetor de centenas de dimensões. Textos com sentido parecido caem perto. Trocar o modelo de embedding depois obriga a reindexar tudo: os vetores antigos ficam num espaço diferente e as distâncias perdem significado.
- A busca é por vizinhança, não por palavra. A pergunta também é embedada, e o índice devolve os K vetores mais próximos. Por isso o RAG acha "prazo para devolver" num documento que só diz "janela de reembolso" — e por isso ele também erra quando a proximidade semântica engana.
- O modelo só vê o que foi recuperado. RetrieveAndGenerate monta o prompt com a pergunta e os trechos. Se o retrieval trouxe o trecho errado, o modelo responde com convicção sobre o trecho errado. Quase todo problema atribuído a "o modelo alucinou" em RAG é, na verdade, retrieval ruim.
- A citação vem do metadado, não do modelo. A resposta traz de qual documento cada trecho veio porque o índice guardou essa referência junto do vetor. É o que permite auditoria — e é a razão pela qual RAG é a resposta quando a questão pede rastreabilidade da fonte.
As duas APIs, e quando usar cada uma
Knowledge Bases expõe duas operações, e a diferença entre elas aparece em prova como "a empresa quer controlar o prompt final".
| Operação | O que devolve | Quando usar |
|---|---|---|
| Retrieve | Só os trechos, com score e metadado | Você quer montar o prompt à mão, misturar com outra fonte, ou aplicar sua própria lógica antes de gerar. |
| RetrieveAndGenerate | A resposta pronta, com citações | O caso comum. Menos código e menos decisão sua — o serviço monta o prompt e chama o modelo. |
import boto3
agente = boto3.client("bedrock-agent-runtime")
# Caminho curto: o serviço recupera E gera.
resp = agente.retrieve_and_generate(
input={"text": "Qual é o prazo de reembolso para plano anual?"},
retrieveAndGenerateConfiguration={
"type": "KNOWLEDGE_BASE",
"knowledgeBaseConfiguration": {
"knowledgeBaseId": "KB123ABC",
# O modelo de GERAÇÃO. O de embedding foi definido na criação da base
# e não se troca sem reindexar.
"modelArn": "anthropic.claude-sonnet-4-5-20250929-v1:0",
},
},
)
print(resp["output"]["text"])
for c in resp["citations"]:
for ref in c["retrievedReferences"]:
# É daqui que sai "segundo o documento X" — do metadado, não do modelo.
print(" fonte:", ref["location"])A pegadinha dos dois modelos
O `modelArn` da chamada é o modelo que GERA a resposta. O modelo de embedding é escolhido quando a base é criada e fica preso a ela: trocá-lo exige reindexar todos os documentos, porque vetor gerado por um modelo não é comparável com vetor gerado por outro. É uma decisão de arquitetura, não de configuração.
Uma seguradora tem 40 mil apólices em PDF no S3, atualizadas diariamente, e quer um assistente que responda dúvidas de atendimento citando a apólice usada. Qual arquitetura atende?
Escolhendo o vector store
O exame não pede que você conheça HNSW. Pede que reconheça qual opção atende ao requisito descrito — e os requisitos que aparecem são custo, volume e "já usamos esse banco".
| Vector store | Encaixa quando |
|---|---|
| OpenSearch Serverless | Default do console. Escala sozinho e é o caminho de menor fricção. Tem um custo mínimo mensal mesmo com pouco uso — o que costuma incomodar em prova de conceito. |
| Aurora PostgreSQL com pgvector | Você já tem Aurora e quer o vetor ao lado do dado relacional, numa transação só. Menos peças na arquitetura. |
| S3 Vectors | Volume grande com consulta pouco frequente. O mais barato por vetor guardado, com latência maior — arquivo morto pesquisável. |
| Pinecone · MongoDB Atlas | A empresa já padronizou nele. Bedrock integra; não é preciso migrar para dentro da AWS só por causa do RAG. |
📋 Uma fintech vai colocar 8 mil documentos de compliance numa base de conhecimento. Já roda Aurora PostgreSQL para o núcleo transacional. Consulta esperada: algumas centenas por dia, com pico no fechamento do mês.
O volume é modesto e o banco já existe, com backup, monitoramento e rotina de operação prontos. Guardar o vetor ao lado do dado relacional elimina uma peça da arquitetura e permite filtrar por metadado com SQL comum antes da busca vetorial — que é justamente o que resolve "achou o trecho certo do documento errado".
Alt: OpenSearch Serverless — É o default do console e escala sem esforço, mas cobra um mínimo mensal mesmo com uso baixo. Para centenas de consultas por dia, esse piso domina a conta.
Alt: S3 Vectors — Mais barato por vetor guardado, e a latência maior seria aceitável aqui — mas 8 mil documentos não é volume que justifique otimizar armazenamento, e adiciona um serviço novo à operação.
Alt: Pinecone ou outro serviço externo — Só faz sentido se a empresa já tivesse padronizado nele. Trazer um fornecedor novo para um requisito que o Aurora atende é custo de integração e de auditoria sem ganho.
Onde o RAG gerenciado quebra
Saber o limite é o que separa quem passou de quem decorou. Três falhas aparecem em cenário de prova.
| Sintoma | Causa real | O que fazer |
|---|---|---|
| Responde "não encontrei" com o documento na base | Chunking cortou a informação no meio, ou o termo da pergunta não é semanticamente próximo do termo do documento | Chunking hierárquico e busca híbrida (vetor + palavra-chave) |
| Responde com dado desatualizado | A base não foi sincronizada depois da mudança no S3 | O sync é explícito — não há sincronização automática ao alterar o arquivo |
| Cita a fonte errada com convicção | O retrieval trouxe trecho parecido mas de outro contexto | Filtro por metadado na consulta, para restringir o universo antes de buscar |
Sync não é automático
Um documento novo no S3 não entra na base sozinho. É preciso disparar o ingestion job. Em cenário de prova, "atualizamos a política mas o assistente responde a versão antiga" é sempre falta de sync — não é cache do modelo e não é preciso recriar a base.
Perguntas frequentes
❓ Knowledge Bases substitui montar RAG na mão?
❓ De onde o Knowledge Bases pode ingerir documento?
❓ Qual banco vetorial o Knowledge Bases usa?
Fixando
Depois de seis meses em produção, o time quer trocar o modelo de embedding da base de conhecimento por um mais recente. Qual é a consequência?
O assistente responde "não encontrei essa informação" para uma pergunta cuja resposta existe, num parágrafo, no documento indexado. Qual é a primeira hipótese a investigar?
Próximo passo
Ainda no Domínio 3: o próximo módulo mostra o que acontece quando o modelo precisa fazer algo além de responder — chamar API, decidir passo seguinte, encadear ação. É aif-bedrock-agents.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…