Serviços que somam ao Bedrock VI: dados, retrieval e conhecimento
- ⬜⚙️ Serviços que somam ao Bedrock V: compute, orquestração e estado(AWS Bedrock — GenAI em Produção)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Esta é a camada que decide a qualidade da resposta — e, no piloto, a maior linha da conta. As duas afirmações parecem desconexas e são o mesmo fato: a escolha do vector store é decisão de custo fixo, não de qualidade de busca. Com poucas centenas de consultas por dia, a capacidade mínima do índice cobra 24 horas por dia e supera toda a inferência — e é por isso que tantos pilotos são julgados caros por um motivo que não tem nada a ver com IA. Este módulo percorre os 13 serviços de armazenamento, indexação, busca e consulta.
Como escolher nesta camada
- A pergunta é de recuperação ou de agregação? "Como cancelo?" busca trecho. "Quantos contratos vencem em março?" é consulta — e forçar isso no retrieval é a origem de resposta errada com aparência de certa.
- Qual o volume de consultas por dia? Abaixo de alguns milhares, o custo fixo do índice domina e o critério de escolha muda completamente.
- O domínio tem identificador literal? Código de norma, SKU e sigla interna não têm vizinhança semântica: exigem índice léxico ao lado do vetorial.
Athena é a resposta certa para pergunta de agregação
"Quantos contratos vencem em março?" não é um problema de recuperação de trecho — é uma consulta. O padrão profissional é dar ao modelo uma ferramenta que roda SQL parametrizado sobre o lago e devolve o número, em vez de esperar que ele conte documentos no contexto. Mais barato, exato e auditável. E a mesma ideia vale para Redshift quando o dado já mora no warehouse.
Armazenamento: a fonte da verdade
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| Amazon S3 | Armazenamento de objeto durável, com versionamento, eventos e classes por frequência de acesso | A fonte da verdade de todo RAG: documento original, entrada e saída de batch, evidência de auditoria — e o evento que dispara a ingestão | Não é banco: não consulte por atributo em tempo de resposta. Listagem em bucket grande é lenta e cara |
| S3 com versionamento | Retenção de todas as versões de cada objeto | Permite provar qual versão exata do documento gerou aquela resposta — requisito de rastreabilidade em setor regulado | Multiplica o armazenamento; exige regra de ciclo de vida para versão antiga |
| S3 Intelligent-Tiering | Move automaticamente o objeto para camada mais barata conforme o acesso cai | Acervo grande com cauda longa de documento raramente lido — o caso típico de base de conhecimento corporativa | Há custo de monitoramento por objeto; em acervo de muitos objetos pequenos pode não compensar |
Versionamento é o que torna a evidência defensável
Numa auditoria, a pergunta não é "o que o documento diz?" — é "o que ele dizia quando a decisão foi tomada?". Sem versionamento, você aponta para o arquivo de hoje e espera que ninguém note que ele mudou. Com versionamento mais o hash gravado na trilha de evidência, a resposta é verificável. É a diferença entre rastreabilidade e narrativa, e custa uma caixa marcada na criação do bucket.
Vector stores: a decisão de custo disfarçada de decisão técnica
Esta é a decisão de maior impacto financeiro de todo projeto de RAG — e a mais tomada no automático. O critério não é qual é "melhor": é qual custo mínimo você aceita pagar quando o tráfego é baixo, porque a maioria dos pilotos vive exatamente aí.
| Serviço | O que é | O que soma ao Bedrock | Custa parado? |
|---|---|---|---|
| OpenSearch Serverless | Busca e análise gerenciada, com índice vetorial e léxico no mesmo lugar | É o que habilita busca híbrida bem feita — a correção para domínio com código, sigla e identificador | Sim: capacidade mínima cobra 24/7, e costuma ser a maior linha do piloto |
| Aurora PostgreSQL + pgvector | Extensão de similaridade vetorial no Postgres gerenciado | Vetor convivendo com o dado relacional: filtro por coluna e similaridade na mesma consulta, em banco que o time já opera | Sim, mas o modo serverless escala para baixo em períodos ociosos |
| S3 Vectors | Armazenamento vetorial sobre objeto, otimizado para custo | Acervo grande com consulta esparsa — e a opção mais próxima de pagar por uso, ideal para piloto | Muito pouco: é o que preserva o custo por consulta durante a avaliação do projeto |
| Neptune Analytics | Banco de grafo com analítica, para GraphRAG | Responde a pergunta que o RAG comum não responde: como A se relaciona com B através de C | Sim, por capacidade provisionada |
| MemoryDB / OpenSearch gerenciado | Alternativas com controle fino de topologia e latência muito baixa | Requisito duro de latência, ou necessidade de afinar o ranking manualmente | Sim, por capacidade — e você passa a operar a topologia |
📋 Piloto de RAG com 30 mil documentos internos, cerca de 200 consultas por dia, e a diretoria acompanhando o custo de perto nos primeiros três meses.
Com 200 consultas por dia, o custo de inferência é pequeno e a capacidade mínima do índice domina a conta. Escolher pelo piso, e não pela sofisticação de busca, é o que mantém o custo por consulta defensável durante o período em que o projeto está sendo julgado.
Alt: OpenSearch Serverless — Melhor busca híbrida do conjunto, e o piso de capacidade pode superar toda a inferência do piloto. Vale quando o volume chegar.
Alt: Aurora com pgvector — Boa opção intermediária se o time já opera Postgres; ainda tem custo de capacidade, embora escale para baixo.
Alt: Nenhum vector store — Para 30 mil documentos não dá para colocar tudo no contexto — mas se fossem algumas dezenas de páginas, esta seria a resposta certa.
Confirme dois números antes de decidir
Antes de escolher, verifique no console e na página de preços da sua região: (1) qual é a capacidade mínima cobrada quando não há tráfego, e (2) se aquele store suporta busca híbrida e filtro de metadados nas Knowledge Bases. Esses dois números decidem custo e qualidade, mudam com o tempo e variam por região — não confie em tabela de blog, inclusive esta.
Busca gerenciada e consulta sobre o lago
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| Amazon Kendra | Busca corporativa gerenciada, com conectores prontos e ranking pronto | Acervo espalhado em muitos sistemas e prazo curto: conectores e herança de permissão da fonte, sem montar pipeline | Cobra por unidade provisionada; você controla menos o chunking e o ranking que numa base de conhecimento própria |
| Amazon Athena | Consulta SQL direta sobre o S3, sem servidor | Responde pergunta de agregação — contagem, soma, série temporal — que o retrieval não responde por natureza | Cobra por dado escaneado: consulta sem partição sobre acervo grande sai caro |
| AWS Glue | Catálogo de esquema e ETL gerenciado | Cataloga e normaliza o dado estruturado que vira contexto ou vira ferramenta de consulta | Curva de aprendizado do catálogo; job mal dimensionado gera custo silencioso |
| Amazon Redshift | Data warehouse analítico de alto desempenho | Quando o dado analítico já mora lá e a pergunta é de agregação em volume grande | Capacidade provisionada ou serverless com mínimo; não é para pergunta esparsa |
| Amazon Kinesis | Ingestão e processamento de stream em tempo real | Alimentar índice ou detecção quase em tempo real, quando o dado nasce em fluxo contínuo | Complexidade de stream só se justifica se a latência de minutos não bastar |
import boto3, time
athena = boto3.client("athena")
# A tool que resolve a pergunta que o RAG NAO resolve.
# Consulta parametrizada: o modelo escolhe os PARAMETROS, nunca escreve o SQL.
# Dar ao modelo uma tool de "executar_sql(query)" e abrir o banco inteiro.
CONSULTAS = {
"contratos_por_vencimento": """
SELECT count(*) AS total, sum(valor) AS valor_total
FROM contratos
WHERE dt_vencimento BETWEEN ? AND ?
AND status = 'ativo'
""",
"tickets_por_categoria": """
SELECT categoria, count(*) AS total
FROM tickets
WHERE dt_abertura >= ?
GROUP BY categoria ORDER BY total DESC LIMIT 20
""",
}
def consultar(nome: str, params: list, workgroup: str, base: str) -> list[dict]:
if nome not in CONSULTAS: # allowlist, nao SQL livre
raise ValueError(f"consulta '{nome}' nao permitida")
ex = athena.start_query_execution(
QueryString=CONSULTAS[nome],
ExecutionParameters=[str(p) for p in params],
WorkGroup=workgroup,
QueryExecutionContext={"Database": base},
)["QueryExecutionId"]
# Athena e assincrono: em tool de chat, limite a espera e devolva erro
# que ENSINA em vez de estourar o timeout da borda.
for _ in range(20):
est = athena.get_query_execution(QueryExecutionId=ex)
estado = est["QueryExecution"]["Status"]["State"]
if estado == "SUCCEEDED":
break
if estado in ("FAILED", "CANCELLED"):
raise RuntimeError("consulta falhou; informe que o dado esta indisponivel")
time.sleep(0.5)
else:
raise TimeoutError("consulta demorou; ofereca enviar o resultado depois")
r = athena.get_query_results(QueryExecutionId=ex)
linhas = r["ResultSet"]["Rows"]
cols = [c["VarCharValue"] for c in linhas[0]["Data"]]
return [dict(zip(cols, [c.get("VarCharValue") for c in l["Data"]]))
for l in linhas[1:]]
Nunca dê ao modelo uma ferramenta de SQL livre
É tentador expor executar_sql(query) e deixar o modelo escrever a consulta — e é abrir o banco inteiro para qualquer coisa que caiba no parâmetro, inclusive o que você não quer. O desenho correto é allowlist: consultas parametrizadas nomeadas, em que o modelo escolhe os parâmetros e nunca o texto do SQL. Você ganha controle de acesso, previsibilidade de custo de varredura e a possibilidade de auditar por nome de consulta.
Ao escolher o vector store para um piloto com poucas centenas de consultas por dia, qual critério deve pesar mais?
Governança do dado que alimenta o modelo
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| AWS Lake Formation | Permissão fina sobre o lago: por tabela, coluna e linha | Quando o recorte de quem vê o quê precisa ser central, e não reimplementado em cada aplicação de IA | Adotar depois exige remodelar o acesso existente; integra melhor com serviços analíticos do que com aplicação própria |
| Amazon DataZone | Catálogo de dados com governança e domínio de negócio | Quando muitos times produzem e consomem dado e ninguém sabe o que existe nem quem é dono | Vale a partir de certa escala organizacional; em um time só, é sobrecarga |
O passo 4 é o que ninguém faz e todo mundo lamenta
Indexar sem metadado de confidencialidade e de validade parece economia de tempo na primeira semana e vira dois problemas graves depois: você não consegue aplicar permissão por filtro (e permissão por prompt não é controle) e não consegue expirar conteúdo obsoleto sem reindexar tudo. Torne o metadado obrigatório na ingestão desde o primeiro documento — retroagir custa a base inteira.
- → curar antes de indexar: obsoleto vira resposta errada com citação
- → pergunta de agregação não é retrieval
- → top-k pequeno: o contexto é o que se paga em todo request
- Armazenamento
- Fora da AWS
- IA e machine learning
- Analytics
- Banco de dados
Repare que a permissão entra na coluna de consumo, como filtro de metadados — e não como instrução no prompt. É a única forma de o documento restrito não existir para quem não pode lê-lo.
- Curar antes de qualquer coisa. Arquivar o obsoleto e o contraditório vale mais que qualquer técnica depois. Documento errado indexado vira resposta errada com citação — pior que não responder.
- Normalizar o formato. OCR estrutural para o que é imagem; catálogo e normalização para o que é estruturado. Não jogue PDF ruim direto no chunking.
- Gerar embeddings em batch. É assíncrono por natureza: rode em modo batch e pague cerca da metade. Reprocesse só o delta quando algo mudar.
- Indexar no store escolhido pelo custo parado. Em volume baixo, a capacidade mínima domina a conta. Grafo só entra se a pergunta for sobre relação entre entidades.
- Recuperar com filtro de permissão. Busca híbrida quando há identificador literal, e o filtro de metadados derivado da identidade do usuário. O restrito não é recuperado.
- Separar agregação de recuperação. "Quantos contratos vencem em março?" vai para consulta parametrizada, não para o índice. Forçar no retrieval produz número errado com aparência de certo.
- Gerar com citação. Top-k pequeno depois de reranking, e fonte sempre visível — é o que permite ao usuário conferir e ao time achar conteúdo desatualizado.
Combinações que se repetem
| Serviço certo | Por quê | O erro comum | |
|---|---|---|---|
| "Como funciona X?" | Base de conhecimento com busca híbrida | É recuperação de trecho, com citação da fonte | Usar só vetorial num domínio cheio de códigos e siglas |
| "Quantos / qual o total?" | Consulta parametrizada sobre o lago | Agregação exige cobertura completa, não os k mais relevantes | Aumentar o top-k esperando que o modelo conte certo |
| "Como A se liga a B?" | Grafo analítico | A resposta está na conexão, não em um documento | Tentar no RAG comum e obter relação inventada |
| "Qual o status do meu pedido?" | Ferramenta no sistema de origem | Dado vivo muda a cada minuto; índice está sempre defasado | Deixar o modelo gerar o número a partir de documento genérico |
| "Resuma tudo sobre X" | Sumarização em batch, materializada | Precisa de cobertura completa, não de recuperação | Pedir resumo por RAG e receber o resumo dos k trechos sorteados |
| Base pequena e estável | Nenhum: contexto cacheado | Algumas dezenas de páginas cabem no prefixo; sem busca, nada se perde | Subir vector store e pagar capacidade mínima sem necessidade |
A última linha é a que mais se ignora
Com janela de contexto grande e cache de prefixo, uma base de algumas dezenas de páginas que muda pouco não precisa de vector store nenhum. Colocar o conteúdo inteiro no prefixo cacheado é mais preciso (nada se perde na busca), mais simples (sem pipeline de ingestão) e frequentemente mais barato — porque elimina a capacidade mínima que cobra o dia inteiro. Faça a conta antes de subir infraestrutura de retrieval.
Erros clássicos desta camada
- Escolher o vector store pela sofisticação da busca em vez do custo parado: em piloto, é a capacidade mínima que aparece na fatura.
- Subir vector store para uma base pequena e estável que caberia inteira no prefixo cacheado.
- Indexar sem metadado de confidencialidade e validade: sem eles não há filtro de permissão nem expiração de conteúdo velho.
- Permissão resolvida no prompt em vez de filtro na consulta: se o trecho restrito entrou no contexto, o vazamento já ocorreu.
- Tratar pergunta de agregação como recuperação: o modelo conta os trechos que recebeu, não o universo.
- Ferramenta de SQL livre para o modelo: abre o banco inteiro para o que couber no parâmetro.
- Só busca vetorial em domínio com código de norma, SKU e sigla: identificador exige correspondência literal.
- Indexar o acervo inteiro sem curadoria: a página de 2019 que contradiz o processo atual é citada com a mesma confiança.
- Trocar de estratégia de chunking sem testar num subconjunto: reindexar a base toda é tempo e dinheiro.
- Consulta no lago sem partição: cobra por dado escaneado, e varredura completa em acervo grande sai caro.
Você precisa responder "quantos contratos de fornecedor vencem no próximo trimestre?" sobre um acervo indexado. Qual é o desenho correto?
Um assistente interno responde bem a perguntas conceituais, mas erra sempre que o usuário cita um código de norma ou identificador de sistema. Qual é a causa mais provável?
Você concluiu a série do ecossistema
Seis módulos, 91 serviços: canais e borda, compute e orquestração, dados e retrieval, IA especializada, segurança e conformidade, observabilidade e FinOps. Daqui a trilha volta para dentro do sistema — RAG de produção, tool use profissional, padrões agênticos, evals e o playbook de custo — com cada serviço desta camada já no lugar certo do seu desenho.
Perguntas frequentes
❓ Onde guardar os vetores: no Postgres ou em serviço dedicado?
❓ Classe de armazenamento importa em projeto de IA?
❓ Preciso de banco de grafo para RAG?
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…