Lab 84 — Onde guardar vetor: quatro opções, uma decisão

⏱ 31 min·⭐ 190 XP

O problema, e a empresa que o tem

O RAG de atendimento da Cadência (L83) está no ar há três semanas, respondendo com citação e taxa de acerto medida contra o golden set. O índice vetorial por trás dele é o OpenSearch Serverless — não porque alguém comparou as alternativas, mas porque é a opção que o console do Bedrock Knowledge Bases provisiona sozinha quando você aceita os valores padrão. Ninguém mediu recall, latência nem custo antes de aceitar.

A pergunta chegou de dois lados na mesma semana. Do time de dados: "por que não pgvector no Aurora que já temos rodando desde o L14?" — o cluster tem um reader que fica ocioso fora do horário do relatório de faturamento. E do financeiro, olhando a fatura: "e S3 Vectors, que a AWS anuncia como mais barato?" As duas perguntas são legítimas, e nenhuma tinha resposta com número — só "parece que funciona" e "parece caro".

Este laboratório reaproveita o MESMO acervo de documentos do L83 (política de devolução, garantia, frete) somado ao catálogo ouro por loja do L62 — 900 lojas, cerca de 44 mil trechos depois do chunking — e mede QUATRO backends de armazenamento vetorial na mesma consulta, no mesmo dia: Knowledge Bases padrão com OpenSearch Serverless gerenciado, OpenSearch self-managed, S3 Vectors e Aurora pgvector. A decisão final não vem de qual parece melhor isolado — vem de recall, latência p50/p99 e custo mensal, lado a lado.

NívelAvançado — depende do L14 (Aurora rodando, com reader ocioso) e do L83 (RAG mínimo com citação, já em produção sobre OpenSearch Serverless)

Pré-requisitosL14 e L83 concluídos, familiaridade com SQL e com uma consulta ANN básica, .NET 8

Tempo estimadoEstudo 55 min · implementação 3 h a 3 h 30

Custo relativoMédio durante o benchmark — os quatro backends rodam em paralelo por algumas horas; alto se qualquer um ficar esquecido ligado depois (ver seção de limpeza)

ServiçosBedrock Knowledge Bases, OpenSearch Serverless, Amazon OpenSearch Service (self-managed), S3 Vectors, Aurora PostgreSQL (pgvector), Fargate (.NET 8), CloudWatch, Cost Explorer, IAM

Acervo medido≈44.400 trechos — 1.200 de política (mesmo do L83) + 43.200 do catálogo ouro por loja (900 lojas × 48 trechos), embeddings Titan v2 de 1.024 dimensões

Requisito declaradorecall@5, latência p50/p99 e custo mensal medidos nos quatro backends, sobre o mesmo acervo e o mesmo golden set, no mesmo dia

Hipótese declaradao backend escolhido em produção nasceu do caminho de menor resistência da documentação, não de uma comparação — a hipótese é que ao menos um dos outros três serve melhor o requisito real

Ao final você temuma tabela com recall@5, p50, p99 e custo mensal das quatro opções, e uma decisão escrita com o trade-off explícito — não a sensação de que uma parece melhor

🚨

O defeito não é o backend — é nunca ter comparado

Escolher banco vetorial por moda tem um custo específico e recorrente: o OpenSearch Serverless cobra capacidade mínima (4 OCU) mesmo com tráfego zero — cerca de US$700 por mês, neste laboratório, só de piso. Ninguém decidiu pagar isso; o console decidiu por padrão, e a fatura chegou três semanas depois da primeira pergunta que ninguém fez: "quanto custa a opção que a documentação sugere primeiro?"

⚠️

O que este laboratório NÃO é

Não é sobre melhorar a recuperação com busca híbrida e reranking — isso é o L85, que parte do backend escolhido aqui. Não é sobre guardrails como controle de verdade sobre a resposta — isso é o L86. Não é sobre modelar o schema do pgvector do zero — o L14 já decidiu quando usar Aurora, e este laboratório assume esse Aurora como dado. Este laboratório prova UMA coisa: qual dos quatro backends serve o requisito de recall, latência e custo do RAG de atendimento — com número, não com preferência.

O que você vai conseguir fazer

Objetivos verificáveis: cada um se prova com uma medição na seção de implantação, não com a sensação de que um backend "parece mais rápido".

Publicar o mesmo acervo (documentos do L83 + catálogo ouro do L62) nos quatro backends: OpenSearch Serverless, OpenSearch self-managed, S3 Vectors e Aurora pgvector.
Construir um golden set de 60 perguntas com resposta oficial, cobrindo política e busca por produto no catálogo.
Medir recall@5 dos quatro backends contra o mesmo golden set, no mesmo dia, isolando a busca vetorial da geração.
Medir latência p50 e p99 de cada backend, separadamente da latência de geração já medida no L83.
Calcular o custo mensal projetado de cada backend a partir do modelo de cobrança real — não de um número decorado.
Explicar por que índice ANN troca exatidão por velocidade, e como HNSW e IVF fazem essa troca de formas diferentes.
Escrever uma decisão com o trade-off explícito: qual backend, por quê, e o que se perde ao escolhê-lo.
Restringir o acesso a cada backend por IAM específico do backend — nunca uma policy copiada de outro.

O que a certificação cobra disto

Conceito	Certificação	Como aparece aqui	O que dominar
Índice ANN (Approximate Nearest Neighbor)	MLS-C01, MLA-C01	os quatro backends usam ANN, com implementações diferentes (HNSW nos dois OpenSearch e no pgvector; IVF-like no S3 Vectors)	ANN troca exatidão por velocidade — recall@k mede exatamente o quanto se perde
HNSW vs. índice por clusters (IVF)	MLS-C01	OpenSearch e pgvector usam grafo HNSW; S3 Vectors usa uma variação de clustering otimizada para armazenamento em objeto	HNSW: melhor recall, mais memória residente; clustering: mais barato, recall menor em corpus pequeno
Trade-off recall vs. latência vs. custo	MLS-C01, MLA-C01	tabela única com os quatro backends, mesmo acervo, mesmo golden set, mesmo dia	não existe backend "melhor" isolado — existe o que serve o requisito não funcional declarado
RAG gerenciado vs. índice operado pela equipe	AIF-C01, MLA-C01	aprofunda a pergunta que o L83 deixou em aberto, agora com número: Knowledge Bases (gerenciado) contra pgvector e OpenSearch self-managed (operados)	gerenciado tira o trabalho de tuning; operado tira o piso de capacidade reservada
Disponibilidade e replicação do índice vetorial	SAA-C03, MLA-C01	o reader do Aurora lê o mesmo volume de cluster do writer (sem cópia); a coleção OpenSearch Serverless é multi-AZ por padrão internamente	cada backend replica de um jeito diferente, e o lag de replicação entra na medição de latência
Capacidade reservada vs. cobrança sob demanda	MLA-C01	o piso de OCU do OpenSearch Serverless contra a cobrança por consulta do S3 Vectors	capacidade reservada garante latência previsível; sob demanda garante custo baixo quando o tráfego é incerto

ConceitoÍndice ANN (Approximate Nearest Neighbor)

CertificaçãoMLS-C01, MLA-C01

Como aparece aquios quatro backends usam ANN, com implementações diferentes (HNSW nos dois OpenSearch e no pgvector; IVF-like no S3 Vectors)

O que dominarANN troca exatidão por velocidade — recall@k mede exatamente o quanto se perde

ConceitoHNSW vs. índice por clusters (IVF)

CertificaçãoMLS-C01

Como aparece aquiOpenSearch e pgvector usam grafo HNSW; S3 Vectors usa uma variação de clustering otimizada para armazenamento em objeto

O que dominarHNSW: melhor recall, mais memória residente; clustering: mais barato, recall menor em corpus pequeno

ConceitoTrade-off recall vs. latência vs. custo

CertificaçãoMLS-C01, MLA-C01

Como aparece aquitabela única com os quatro backends, mesmo acervo, mesmo golden set, mesmo dia

O que dominarnão existe backend "melhor" isolado — existe o que serve o requisito não funcional declarado

ConceitoRAG gerenciado vs. índice operado pela equipe

CertificaçãoAIF-C01, MLA-C01

Como aparece aquiaprofunda a pergunta que o L83 deixou em aberto, agora com número: Knowledge Bases (gerenciado) contra pgvector e OpenSearch self-managed (operados)

O que dominargerenciado tira o trabalho de tuning; operado tira o piso de capacidade reservada

ConceitoDisponibilidade e replicação do índice vetorial

CertificaçãoSAA-C03, MLA-C01

Como aparece aquio reader do Aurora lê o mesmo volume de cluster do writer (sem cópia); a coleção OpenSearch Serverless é multi-AZ por padrão internamente

O que dominarcada backend replica de um jeito diferente, e o lag de replicação entra na medição de latência

ConceitoCapacidade reservada vs. cobrança sob demanda

CertificaçãoMLA-C01

Como aparece aquio piso de OCU do OpenSearch Serverless contra a cobrança por consulta do S3 Vectors

O que dominarcapacidade reservada garante latência previsível; sob demanda garante custo baixo quando o tráfego é incerto

💡

Onde isto costuma ser cobrado errado

A pergunta clássica descreve um sistema de busca semântica com latência alta ou fatura inesperada, e pede a causa. A armadilha mais comum é tratar "gerenciado" como sinônimo de "correto": o backend padrão de um assistente de console resolve o problema de provisionar, não o de servir o requisito de recall, latência ou custo declarado — essas três dimensões nunca são resolvidas por default, só por medição.

Requisitos, e como cada um muda o desenho

Requisito que não vira uma linha do benchmark é intenção. A coluna da direita é onde cada um deixou marca no harness, no Terraform ou na decisão final.

Requisito	Valor declarado	O que ele decide no desenho
Resposta continua citando o trecho exato, trocando o backend	obrigatório	RetrieveAndGenerate funciona igual nos quatro — a troca fica só em storage_configuration.type da Knowledge Base
Latência de busca cabe no orçamento de 3 s do atendimento (herdado do L83)	busca + geração ≤ 3 s	descarta S3 Vectors do caminho de atendimento AO VIVO, sem descartar o serviço por completo
Recall@5 não pode ficar abaixo do que o LLM direto sem RAG já entregaria	≥ 0,85 (a barra medida no L83 antes do RAG)	qualquer backend abaixo da barra é eliminado antes de entrar na comparação de custo
Custo mensal medido, não estimado por material de marketing	golden set roda nos quatro no mesmo dia, mesma hora	elimina viés de comparar números de datas ou cargas diferentes
Equipe de duas pessoas continua sem plantão dedicado a banco vetorial	operação não pode exigir tuning contínuo de cluster	pesa contra OpenSearch self-managed mesmo quando ele vence em recall
Infraestrutura que já existe conta como custo zero de novo serviço	reaproveitar o Aurora do L14 quando servir	dá ao pgvector uma vantagem estrutural de custo que nenhum preço por unidade apaga
Decisão registrada com número, não com sensação	recall, p50/p99 e custo mensal lado a lado, na mesma tabela	decision_box e comparison_table, nunca "parece mais rápido"
Trocar de backend não pode quebrar a auditoria de citação	obrigatório	o campo `chunkId`/`documento` do log do L83 precisa existir nos quatro backends escolhidos

RequisitoResposta continua citando o trecho exato, trocando o backend

Valor declaradoobrigatório

O que ele decide no desenhoRetrieveAndGenerate funciona igual nos quatro — a troca fica só em storage_configuration.type da Knowledge Base

RequisitoLatência de busca cabe no orçamento de 3 s do atendimento (herdado do L83)

Valor declaradobusca + geração ≤ 3 s

O que ele decide no desenhodescarta S3 Vectors do caminho de atendimento AO VIVO, sem descartar o serviço por completo

RequisitoRecall@5 não pode ficar abaixo do que o LLM direto sem RAG já entregaria

Valor declarado≥ 0,85 (a barra medida no L83 antes do RAG)

O que ele decide no desenhoqualquer backend abaixo da barra é eliminado antes de entrar na comparação de custo

RequisitoCusto mensal medido, não estimado por material de marketing

Valor declaradogolden set roda nos quatro no mesmo dia, mesma hora

O que ele decide no desenhoelimina viés de comparar números de datas ou cargas diferentes

RequisitoEquipe de duas pessoas continua sem plantão dedicado a banco vetorial

Valor declaradooperação não pode exigir tuning contínuo de cluster

O que ele decide no desenhopesa contra OpenSearch self-managed mesmo quando ele vence em recall

RequisitoInfraestrutura que já existe conta como custo zero de novo serviço

Valor declaradoreaproveitar o Aurora do L14 quando servir

O que ele decide no desenhodá ao pgvector uma vantagem estrutural de custo que nenhum preço por unidade apaga

RequisitoDecisão registrada com número, não com sensação

Valor declaradorecall, p50/p99 e custo mensal lado a lado, na mesma tabela

O que ele decide no desenhodecision_box e comparison_table, nunca "parece mais rápido"

RequisitoTrocar de backend não pode quebrar a auditoria de citação

Valor declaradoobrigatório

O que ele decide no desenhoo campo `chunkId`/`documento` do log do L83 precisa existir nos quatro backends escolhidos

Arquitetura mínima: a escolha que ninguém decidiu

Este é o desenho que está em produção — o mesmo do L83, olhado agora pela lente de "qual decisão foi tomada aqui, e por quem". A resposta é: nenhuma decisão foi tomada. O assistente do console escolheu por padrão, e o sistema funciona bem o suficiente para que ninguém tivesse motivo de questionar — até a pergunta sobre pgvector e S3 Vectors chegar.

Um backend, escolhido porque é o que o assistente do console provisiona sozinho

Acervo — mesmo bucket do L83

S3 — documentos + catálogo ouroo mesmo bucket de camadas do L62, somado às políticas do L83 nesta rodada

Ingestão gerenciada pela Knowledge Base

Bedrock Knowledge Basesorquestra ingestão, chunking e embedding sem pedir onde indexar — decide o índice sozinha

Chunking de tamanho fixo500 tokens, 20% de sobreposição — o mesmo parâmetro herdado do L83, nunca recalibrado

Titan Embed Text v2gera o vetor de 1.024 dimensões; o mesmo modelo entraria em qualquer dos quatro backends

Onde o vetor caiu — sem comparação

OpenSearch Serverless (padrão do Knowledge Bases)recebe o vetor porque é a única opção que o console cria sem pedir configuração de rede

As outras três opções — nunca desenhadas nem medidas

Aurora pgvector (o cluster do L14)existe, roda, tem reader ocioso fora do pico do relatório — e ninguém testou indexar vetor nele

S3 Vectorsanunciado como mais barato por GB, nunca medido em latência nem em recall real

OpenSearch self-manageddaria mais controle sobre o parâmetro do índice HNSW, e nunca entrou na conversa

→ evento de escrita dispara ingestão
→ quebra o documento em trechos com sobreposição
→ cada trecho vira um vetor de 1.024 dimensões
→ único destino configurado — o padrão do assistente do console

Armazenamento
IA e machine learning
Conceito de arquitetura
Analytics
Banco de dados

É o que a Cadência tem hoje, herdado direto do L83: o vetor cai em OpenSearch Serverless porque é o único caminho que o Knowledge Bases percorre sem pedir nenhuma decisão de rede ou capacidade. Percorra os passos e repare nos três últimos nós: pgvector, OpenSearch self-managed e S3 Vectors existem no catálogo do provedor Terraform da mesma forma que o OpenSearch Serverless — e nenhuma seta chega até eles. A ausência de comparação é o defeito, não o backend escolhido.

🚨

Um backend que funciona não é o mesmo que um backend medido

"Funciona" e "foi a decisão certa" não são a mesma frase, e a diferença entre elas custa dinheiro real todo mês. O piso de capacidade do OpenSearch Serverless cobra igual estando o RAG parado ou a todo vapor — é o tipo de custo que sobrevive a qualquer otimização de código, porque não é sobre código.

Arquitetura para produção: as quatro medidas no mesmo acervo

A diferença em relação ao desenho anterior não é "mais um backend" — é que a pergunta "onde o vetor mora?" deixa de ter uma resposta única e passa a ter quatro respostas, medidas lado a lado. Cada peça nova existe porque a tabela de requisitos exige um número que a arquitetura mínima nunca produziu.

O mesmo vetor, gravado nos quatro backends, e um harness que consulta os quatro com a mesma pergunta

Acervo e ingestão — idênticos nos quatro

S3 — documentos + catálogo ouromesmo bucket, mesmo conteúdo — a única variável do experimento é o backend de destino

Chunking de tamanho fixo500 tokens, 20% de sobreposição — parâmetro travado para não confundir efeito de chunking com efeito de backend

Titan Embed Text v2gera o MESMO vetor uma única vez por trecho, gravado nos quatro em seguida

Backend A — OpenSearch Serverless (Knowledge Bases padrão)

OpenSearch Serverlesso que já está em produção desde o L83 — participa do benchmark como linha de base conhecida

Backend B — OpenSearch self-managed, em VPCVPC

OpenSearch (domínio provisionado, 3 nós)índice HNSW tunado à mão — ef_search e m ajustados manualmente pela equipe, dentro de sub-rede privada

Backend C — S3 Vectors

S3 Vectorsíndice sobre armazenamento em objeto, sem capacidade reservada — regional, fora de qualquer VPC

Backend D — Aurora pgvector, em VPCVPC

Aurora PostgreSQL — extensão pgvectorreaproveita o cluster e o reader ociosos do L14, com um índice HNSW dedicado à busca vetorial

Harness de benchmark e decisão

Golden set — 60 perguntas40 de política (mesmas do L83) + 20 novas de busca no catálogo por loja, com resposta oficial conhecida

Harness de benchmark (.NET 8 em Fargate)dispara a mesma consulta vetorial nos quatro backends e registra recall, latência e custo projetado

CloudWatch — latência por backendp50 e p99 calculados separadamente por backend, nunca numa média única que esconde o pior caso

Cost Explorer — custo projetadotraduz o modelo de cobrança de cada backend em uma projeção mensal comparável

→ documento do L83 + catálogo ouro do L62
→ trecho de 500 tokens, 20% de sobreposição — idêntico nos quatro
→ mesmo vetor gravado nos quatro, para a comparação ser honesta
→ mesmo vetor gravado nos quatro, para a comparação ser honesta
→ mesmo vetor gravado nos quatro, para a comparação ser honesta
→ mesmo vetor gravado nos quatro, para a comparação ser honesta
→ 60 perguntas com resposta oficial conhecida
→ consulta idêntica, ida e volta com id do chunk e distância
→ consulta idêntica, ida e volta com id do chunk e distância
→ consulta idêntica, ida e volta com id do chunk e distância
→ consulta idêntica, ida e volta com id do chunk e distância
→ latência de cada chamada, com o backend como dimensão
→ custo mensal projetado, por backend

Armazenamento
Conceito de arquitetura
Analytics
Banco de dados
Gestão e governança

Não é o desenho anterior com uma caixa a mais: a topologia inteira muda de forma — existe uma fase de gravação em paralelo, um golden set, um harness de benchmark e quatro caminhos de consulta que nunca existiram no desenho mínimo. Cada peça nova rastreia um requisito da tabela anterior: o harness mede porque o requisito exige número, não estimativa; os quatro backends recebem o MESMO vetor porque a comparação só é honesta se a entrada for idêntica.

⚠️

Os quatro existem só durante a medição

Manter os quatro backends rodando além do benchmark é o próprio antipadrão que este laboratório investiga: capacidade paga por comparação que já terminou. A seção de limpeza desliga os três que não foram escolhidos assim que a tabela de resultados estiver fechada.

Como funciona, ponta a ponta

🗺️ Do golden set à tabela com recall, latência e custo

1. O golden set de 60 perguntas é carregado pelo harness40 perguntas de política (do L83) e 20 sobre busca de produto no catálogo, cada uma com o id do trecho oficial que deveria ser recuperado.

2. Cada pergunta vira UM embedding, calculado uma única vezO mesmo vetor de consulta é reaproveitado nas quatro chamadas seguintes — gerar quatro embeddings diferentes introduziria uma variação que não é do backend.

3. O vetor de consulta é enviado aos quatro backends, em paraleloCada backend usa sua própria API nativa de busca vetorial — não passa pelo RetrieveAndGenerate, que mistura geração com recuperação e enviesaria a medição de latência.

4. Cada backend devolve seus 5 vizinhos mais próximosId do trecho e distância, sempre top-5 — o mesmo k usado na produção real do L83, para o número ser comparável ao que o atendente vê.

5. O harness compara o trecho esperado contra os 5 devolvidosSe o id oficial do golden set aparece entre os 5, a pergunta conta como acerto — recall@5 é a fração de perguntas que acertam, por backend.

6. Latência é medida por chamada, separada por backendp50 e p99 calculados ao fim da rodada inteira (60 perguntas × 4 backends = 240 chamadas), nunca numa amostra pequena que esconderia cauda longa.

7. Custo mensal é projetado, não medido em produção aindaA partir do modelo de cobrança real de cada backend (capacidade reservada, instância, por GB, incremental) — a projeção usa o volume medido do acervo, não um número de folheto.

8. Os quatro números entram na mesma tabela, ao lado da decisão escritaRecall, p50, p99 e custo — juntos, porque decidir olhando só um deles é a mesma armadilha que escolher por moda.

O log abaixo é o que o harness grava por pergunta — o material bruto que vira a tabela de recall e latência da próxima seção.

benchmark-consulta.json

{
  "evento": "BENCHMARK_CONSULTA_EXECUTADA",
  "timestamp": "2026-08-08T09:14:02.881Z",
  "pergunta": "Qual a política de devolução de material elétrico?",
  "chunkIdEsperado": "devolucao-material-eletrico.md#chunk-4",
  "resultadosPorBackend": {
    "opensearch_serverless": {"top5contemEsperado": true, "latenciaMs": 71},
    "opensearch_provisionado": {"top5contemEsperado": true, "latenciaMs": 39},
    "s3_vectors": {"top5contemEsperado": true, "latenciaMs": 194},
    "aurora_pgvector": {"top5contemEsperado": true, "latenciaMs": 33}
  },
  "_comentario": "esta pergunta acertou nos quatro; recall@5 agregado por backend sai da soma das 60 perguntas, nao de uma unica linha como esta."
}

💡

Por que medir a busca separada da geração

O harness mede a busca vetorial ISOLADA da geração de resposta. A latência que o atendente sente no L83 soma esta etapa com a chamada ao Claude — separar as duas é o que permite dizer, com precisão, quanto de um orçamento de 3 s cada peça consome.

Implantar e medir: recall, latência e custo das quatro opções

Esta é a tabela que o laboratório existe para produzir. Os quatro backends receberam o mesmo vetor, responderam ao mesmo golden set de 60 perguntas, no mesmo dia — os números abaixo não são estimativa de documentação, são o resultado da rodada.

Backend	Recall@5	Latência p50	Latência p99	Custo mensal	Operação
OpenSearch Serverless (Knowledge Bases padrão)	0,93	68 ms	240 ms	≈ US$700 (piso de 4 OCU, independe de tráfego)	zero — gerenciado pelo Knowledge Bases
OpenSearch self-managed (3× r6g.large.search)	0,95	41 ms	160 ms	≈ US$540 (instâncias + armazenamento)	alta — patch, capacidade, tuning de índice
S3 Vectors	0,86	180 ms	520 ms	≈ US$19 (armazenamento + consulta, sem capacidade reservada)	baixa — sem cluster para operar
Aurora pgvector (reaproveita o L14)	0,94	35 ms	140 ms	≈ US$95 (incremental sobre o cluster já existente)	média — índice HNSW e VACUUM ficam com a equipe

BackendOpenSearch Serverless (Knowledge Bases padrão)

Recall@50,93

Latência p5068 ms

Latência p99240 ms

Custo mensal≈ US$700 (piso de 4 OCU, independe de tráfego)

Operaçãozero — gerenciado pelo Knowledge Bases

BackendOpenSearch self-managed (3× r6g.large.search)

Recall@50,95

Latência p5041 ms

Latência p99160 ms

Custo mensal≈ US$540 (instâncias + armazenamento)

Operaçãoalta — patch, capacidade, tuning de índice

BackendS3 Vectors

Recall@50,86

Latência p50180 ms

Latência p99520 ms

Custo mensal≈ US$19 (armazenamento + consulta, sem capacidade reservada)

Operaçãobaixa — sem cluster para operar

BackendAurora pgvector (reaproveita o L14)

Recall@50,94

Latência p5035 ms

Latência p99140 ms

Custo mensal≈ US$95 (incremental sobre o cluster já existente)

Operaçãomédia — índice HNSW e VACUUM ficam com a equipe

ƒ O piso de custo do OpenSearch Serverless não depende de tráfego

custo_mensal_minimo ≈ ocu_minimo × preco_por_ocu_hora × horas_no_mes

ocu_minimo

4 OpenSearch Compute Units

2 de indexação + 2 de busca — o mínimo que a AWS reserva por coleção VECTORSEARCH, mesmo com o índice vazio.

preco_por_ocu_hora

consulte o AWS Pricing Calculator

a ordem de grandeza usada nesta medição foi de aproximadamente US$0,24 — confira o valor atual antes de decidir; é o tipo de número que muda de ciclo para ciclo.

horas_no_mes

730, fixo

é o motivo do custo não cair mesmo com tráfego zero: capacidade reservada cobra por hora ligada, não por consulta.

✅

Nenhum backend vence em tudo — e não precisa

Aurora pgvector entrega a segunda melhor latência e o segundo melhor recall dos quatro, pelo menor custo incremental — porque o cluster já existe desde o L14. Não é o backend com o MELHOR número isolado em nenhuma coluna; é o que melhor serve os requisitos declarados (latência dentro do orçamento de 3 s, custo baixo, operação que a equipe já faz) somados.

As decisões, e o que se perde em cada uma

📋 A Cadência tem RAG em produção (L83) sobre OpenSearch Serverless, escolhido porque era o caminho padrão do Knowledge Bases. A equipe opera Aurora desde o L07/L14, com um reader ocioso fora do horário de pico do relatório. A pergunta chegou de dois lados — "por que não pgvector, que já temos rodando?" e "e S3 Vectors, que é mais barato?" — e ninguém tinha medido nada até este laboratório.

✓ Aurora PostgreSQL com pgvector, reaproveitando o cluster e o reader ociosos do L14, com um índice HNSW dedicado à busca vetorial

Menor custo incremental dos quatro (≈US$95/mês, contra o piso de ≈US$700 do OpenSearch Serverless), melhor latência (p50 de 35 ms, p99 de 140 ms — dentro do orçamento de 3 s do L83 com folga), e recall@5 de 0,94, a um ponto percentual do melhor resultado medido (OpenSearch self-managed, 0,95), sem exigir um cluster dedicado. A equipe já opera este Aurora desde o L07; estender essa operação para incluir um índice vetorial é menos trabalho do que aprender a operar OpenSearch do zero.

Alt: Manter OpenSearch Serverless (o que já está em produção desde o L83) — zero mudança e zero risco de regressão, mas o piso de ≈US$700/mês independe de tráfego, e nem recall nem latência são os melhores medidos — é o preço de nunca ter comparado.

Alt: OpenSearch self-managed (3 instâncias, tuning manual) — melhor recall e melhor latência do trio de OpenSearch, mas exige uma equipe operando patch, capacidade e parâmetro de índice HNSW que os dois desenvolvedores da Cadência não têm — troca custo de nuvem por custo de gente.

Alt: S3 Vectors, pelo custo mais baixo — ≈US$19/mês é dez vezes mais barato que o segundo colocado, mas p99 de 520 ms, somado à geração, estoura o orçamento de 3 s do atendimento ao vivo do L83 — serve para acervo frio ou processamento em lote, não para este caminho.

Alt: Reescrever o RAG do zero, sem Knowledge Bases, direto sobre pgvector — perderia o RetrieveAndGenerate gerenciado (chunking, citação, orquestração) que o L83 já validou em produção — a decisão aqui é TROCAR o backend de armazenamento, não descartar o pipeline que já funciona.

Decisão	Escolha	Alternativas	Motivo	O que se perde
Backend do índice vetorial	Aurora pgvector (índice HNSW)	OpenSearch Serverless; OpenSearch self-managed; S3 Vectors	menor custo incremental e melhor latência, com operação que a equipe já faz	perde o zero-ops do backend gerenciado — VACUUM e reindexação passam a ser responsabilidade da equipe
Tamanho do golden set do benchmark	60 perguntas (40 do L83 + 20 novas de catálogo)	manter só as 40 perguntas originais de política	cobre os dois tipos de conteúdo do acervo unificado, não só um deles	60 perguntas ainda é amostra — não cobre toda pergunta possível sobre 900 lojas
Onde medir a latência	no ponto de recuperação pura, separado da geração	medir o round-trip completo do RetrieveAndGenerate	isola o que o backend controla do que o modelo de geração controla	o número isolado não é exatamente o que o atendente sente — a soma completa continua medida no L83
Quando reconsiderar esta decisão	a cada ordem de grandeza de crescimento do acervo	nunca remedir, confiar no número de hoje indefinidamente	recall e latência mudam com o volume — pgvector tem um limite de RAM que 1 milhão de trechos pode alcançar	remedir tem custo de engenharia; o trade-off é aceitar isso contra decidir às cegas depois

DecisãoBackend do índice vetorial

EscolhaAurora pgvector (índice HNSW)

AlternativasOpenSearch Serverless; OpenSearch self-managed; S3 Vectors

Motivomenor custo incremental e melhor latência, com operação que a equipe já faz

O que se perdeperde o zero-ops do backend gerenciado — VACUUM e reindexação passam a ser responsabilidade da equipe

DecisãoTamanho do golden set do benchmark

Escolha60 perguntas (40 do L83 + 20 novas de catálogo)

Alternativasmanter só as 40 perguntas originais de política

Motivocobre os dois tipos de conteúdo do acervo unificado, não só um deles

O que se perde60 perguntas ainda é amostra — não cobre toda pergunta possível sobre 900 lojas

DecisãoOnde medir a latência

Escolhano ponto de recuperação pura, separado da geração

Alternativasmedir o round-trip completo do RetrieveAndGenerate

Motivoisola o que o backend controla do que o modelo de geração controla

O que se perdeo número isolado não é exatamente o que o atendente sente — a soma completa continua medida no L83

DecisãoQuando reconsiderar esta decisão

Escolhaa cada ordem de grandeza de crescimento do acervo

Alternativasnunca remedir, confiar no número de hoje indefinidamente

Motivorecall e latência mudam com o volume — pgvector tem um limite de RAM que 1 milhão de trechos pode alcançar

O que se perderemedir tem custo de engenharia; o trade-off é aceitar isso contra decidir às cegas depois

⚠️

A dívida que esta decisão não paga

Esta decisão vale para o acervo e o tráfego medidos hoje — 44 mil trechos, atendimento humano no meio do caminho. Ela não se estende automaticamente para um cenário de 1 milhão de trechos ou de latência sub-10ms sem novo teste: a tabela de escala mais adiante mostra onde cada backend muda de comportamento.

Construir: os quatro backends sobre o mesmo acervo

O bucket e a Knowledge Base são os mesmos do L83. O que este laboratório acrescenta são os três backends alternativos — self-managed OpenSearch, S3 Vectors e o índice pgvector no Aurora existente — mais o harness que consulta os quatro com o mesmo vetor.

quatro-backends.tf

# quatro-backends.tf — os quatro destinos do MESMO vetor, para o benchmark.
# A Knowledge Base do L83 ja existe e continua apontando para o backend A;
# aqui declaramos B, C e D so para a rodada de medicao. Confira a versao do
# provider AWS antes de aplicar: recursos aws_bedrockagent_*, aws_opensearch_*
# e o suporte a S3 Vectors no Knowledge Bases mudaram de shape mais de uma vez.

variable "prefixo" {
  type    = string
  default = "cadencia-l84"
}

# ── Backend B: OpenSearch self-managed, dentro da VPC do L07 ──────────────
resource "aws_opensearch_domain" "backend_b" {
  domain_name    = "${var.prefixo}-opensearch-provisionado"
  engine_version = "OpenSearch_2.15"

  cluster_config {
    instance_type  = "r6g.large.search"
    instance_count = 3
  }

  vpc_options {
    subnet_ids         = [data.aws_subnet.privada_a.id]
    # security group referencia o SG da task do harness, nunca faixa de IP.
    security_group_ids = [aws_security_group.acesso_opensearch.id]
  }

  ebs_options {
    ebs_enabled = true
    volume_type = "gp3"
    volume_size = 100
  }

  encrypt_at_rest { enabled = true }

  tags = { squad = "atendimento", lab = "L84", finalidade = "benchmark-vetorial" }
}

resource "aws_security_group" "acesso_opensearch" {
  name   = "${var.prefixo}-sg-opensearch"
  vpc_id = data.aws_vpc.cadencia.id

  ingress {
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    # referencia o SG da task do harness — nunca 0.0.0.0/0 num backend com dado real.
    security_groups = [aws_security_group.harness_benchmark.id]
  }
}

# ── Backend C: S3 Vectors ──────────────────────────────────────────────────
# O recurso nativo do provider AWS para S3 Vectors mudou de nome mais de uma vez
# desde o lancamento do servico; se `aws_s3vectors_index` nao existir na sua
# versao do provider, crie o bucket e o indice via chamada ao SDK (S3VectorsClient)
# num passo de bootstrap, como o harness ja faz para popular o backend.
resource "aws_s3vectors_bucket" "backend_c" {
  bucket = "${var.prefixo}-s3-vectors"
  tags   = { squad = "atendimento", lab = "L84", finalidade = "benchmark-vetorial" }
}

resource "aws_s3vectors_index" "backend_c" {
  bucket_name     = aws_s3vectors_bucket.backend_c.bucket
  index_name      = "cadencia-acervo"
  dimension       = 1024
  distance_metric = "cosine"
}

# ── Backend D: Aurora pgvector — REAPROVEITA o cluster do L14, não cria outro ──
data "aws_rds_cluster" "cadencia" {
  cluster_identifier = "cadencia-pedidos" # o mesmo cluster do L14
}

# A extensão e o índice entram por migração SQL (ver pgvector-indice.sql),
# não por recurso do Terraform — pgvector é extensão do Postgres, não peça de infra.

# ── Log group do harness — cobra por retenção, entra na limpeza ───────────
resource "aws_cloudwatch_log_group" "harness" {
  name              = "/cadencia/l84/harness-benchmark"
  retention_in_days = 30
  tags              = { squad = "atendimento", lab = "L84" }
}

O índice do pgvector não é recurso de infraestrutura — é uma extensão do Postgres, criada por migração SQL sobre o cluster que o L14 já provisionou.

pgvector-indice.sql

-- pgvector-indice.sql — roda no mesmo cluster Aurora do L14, sem criar cluster novo.
-- O índice HNSW é o que faz a busca por similaridade não virar um sequential scan.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE IF NOT EXISTS acervo_vetorial (
    id          BIGSERIAL PRIMARY KEY,
    chunk_id    TEXT NOT NULL UNIQUE,
    documento   TEXT NOT NULL,
    texto       TEXT NOT NULL,
    embedding   VECTOR(1024) NOT NULL
);

-- HNSW: m = vizinhos por nó (mais = melhor recall, mais RAM);
-- ef_construction = esforço na hora de montar o índice (só paga uma vez, na carga).
CREATE INDEX IF NOT EXISTS acervo_vetorial_hnsw
    ON acervo_vetorial
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- O operador da consulta TEM de casar com o operador do índice (<=> = cosseno).
-- Usar <-> (distância euclidiana) aqui faria o planner ignorar o índice HNSW
-- e cair em sequential scan — é o defeito da seção de troubleshooting adiante.
-- SELECT chunk_id, documento, texto, embedding <=> $1 AS distancia
--   FROM acervo_vetorial
--   ORDER BY embedding <=> $1
--   LIMIT 5;

O harness em .NET 8 consulta os quatro backends com o mesmo vetor. O trecho abaixo mostra o cliente do backend D (pgvector) — o mais novo dos quatro para quem só operou OpenSearch até aqui — com pool de conexões e retry com jitter, seguindo o mesmo padrão de resiliência do L14.

HarnessPgVector.cs

// HarnessPgVector.cs — consulta o backend D (Aurora pgvector) com pool e retry.
// Os outros três backends seguem o mesmo padrão de harness, trocando só o
// cliente de consulta (OpenSearch REST client / S3VectorsClient do SDK).
using Npgsql;
using Polly;
using Polly.Retry;

public sealed class HarnessPgVector
{
    private readonly NpgsqlDataSource _pool;
    private readonly AsyncRetryPolicy _retry;

    public HarnessPgVector(string connectionString)
    {
        // pool, nunca uma conexão nova por requisição — mesma regra do L07/L14.
        _pool = NpgsqlDataSource.Create(connectionString);
        _retry = Policy
            .Handle<NpgsqlException>()
            .WaitAndRetryAsync(3, tentativa =>
                TimeSpan.FromMilliseconds(80 * Math.Pow(2, tentativa))
                + TimeSpan.FromMilliseconds(Random.Shared.Next(0, 40))); // jitter
    }

    public async Task<ResultadoConsulta> ConsultarAsync(float[] vetorConsulta, string chunkIdEsperado)
    {
        var inicio = System.Diagnostics.Stopwatch.StartNew();

        var top5 = await _retry.ExecuteAsync(async () =>
        {
            await using var cmd = _pool.CreateCommand(
                "SELECT chunk_id FROM acervo_vetorial " +
                "ORDER BY embedding <=> $1 LIMIT 5");
            cmd.Parameters.AddWithValue(new Pgvector.Vector(vetorConsulta));

            var ids = new List<string>();
            await using var reader = await cmd.ExecuteReaderAsync();
            while (await reader.ReadAsync())
                ids.Add(reader.GetString(0));
            return ids;
        });

        inicio.Stop();
        return new ResultadoConsulta(
            Backend: "aurora_pgvector",
            Top5ContemEsperado: top5.Contains(chunkIdEsperado),
            LatenciaMs: inicio.ElapsedMilliseconds);
    }
}

public sealed record ResultadoConsulta(string Backend, bool Top5ContemEsperado, long LatenciaMs);

⚠️

Confira o shape do provider antes de aplicar

O provedor Terraform da AWS mudou o shape dos recursos de S3 Vectors e do suporte a novos backends do Knowledge Bases mais de uma vez desde o lançamento de cada serviço. Rode `terraform plan` antes de aplicar às cegas — é o mesmo aviso que o L83 já fazia sobre `aws_bedrockagent_*`, e continua valendo.

Quebrar de propósito: quatro falhas, e três não levantam erro nenhum

A tabela de medição acima decide o backend. Estas quatro injeções decidem se você vai perceber quando a decisão parar de valer. Repare que só a primeira produz exceção — as outras três degradam a qualidade da resposta sem nada no log, que é o modo característico de falha de sistema de recuperação vetorial.

Falha injetada	Como injetar	Sintoma enganoso	Diagnóstico correto
Operador de distância diferente do opclass do índice	No Aurora, criar o índice HNSW com `vector_cosine_ops` e consultar com o operador de distância L2 (`<->`) em vez do de cosseno (`<=>`)	A consulta responde normalmente, com resultados plausíveis, e fica dezenas de vezes mais lenta conforme o acervo cresce. A leitura imediata é "pgvector não escala"	O índice não foi usado. O planejador do Postgres só escolhe o índice HNSW quando o operador da consulta corresponde à classe de operador com que o índice foi criado — caso contrário faz varredura sequencial sobre os 44 mil trechos e ainda assim devolve resposta correta, só que lendo tudo. `EXPLAIN ANALYZE` mostrando `Seq Scan` é o diagnóstico em uma linha, e é a primeira coisa a rodar antes de concluir qualquer coisa sobre desempenho de pgvector
`ef_search` reduzido para ganhar latência	Baixar `hnsw.ef_search` e repetir o golden set de 60 perguntas	A latência p99 melhora de forma convincente, e o painel de desempenho fica mais bonito. Nenhum erro, nenhum alarme	O recall caiu junto, e ninguém mediu. Esse parâmetro é exatamente a alavanca entre latência e qualidade da busca aproximada: menos exploração do grafo significa resposta mais rápida e mais chance de o trecho certo não estar entre os recuperados. O RAG continua respondendo — com citação, com confiança, e mais vezes errado. É a razão de este laboratório medir recall contra golden set em vez de olhar latência sozinha
Acervo cresce sem reindexar	Ingerir mais 40 mil trechos e repetir o golden set sem tocar em nenhum parâmetro de índice	Tudo continua respondendo, e o custo sobe de forma proporcional e previsível	Parâmetro de índice aproximado é dimensionado para um tamanho de acervo; ao dobrar o acervo, a mesma configuração explora uma fração menor do grafo e o recall cai de novo, em silêncio. A medição deste laboratório tem prazo de validade, e o prazo é o próximo crescimento relevante do acervo. Registre junto da tabela o tamanho em que ela foi medida
Tráfego zerado por um fim de semana	Suspender as consultas de sexta a segunda e olhar a fatura dos quatro backends na segunda-feira	Três dos quatro custam praticamente nada. Um deles custou o fim de semana inteiro	Aqui a falha injetada é a ausência de carga, e ela separa os backends por MODELO DE COBRANÇA, não por desempenho — que é a dimensão que a tabela de medição não mostra. Coleção gerenciada com piso de capacidade cobra a capacidade provisionada, não a consulta; armazenamento vetorial cobrado por requisição não cobra nada em repouso. Confirme os pisos vigentes na página de preços de cada serviço antes de decidir: são o tipo de número que muda, e para acervo pequeno com tráfego irregular eles dominam a conta inteira

Falha injetadaOperador de distância diferente do opclass do índice

Como injetarNo Aurora, criar o índice HNSW com `vector_cosine_ops` e consultar com o operador de distância L2 (`<->`) em vez do de cosseno (`<=>`)

Sintoma enganosoA consulta responde normalmente, com resultados plausíveis, e fica dezenas de vezes mais lenta conforme o acervo cresce. A leitura imediata é "pgvector não escala"

Diagnóstico corretoO índice não foi usado. O planejador do Postgres só escolhe o índice HNSW quando o operador da consulta corresponde à classe de operador com que o índice foi criado — caso contrário faz varredura sequencial sobre os 44 mil trechos e ainda assim devolve resposta correta, só que lendo tudo. `EXPLAIN ANALYZE` mostrando `Seq Scan` é o diagnóstico em uma linha, e é a primeira coisa a rodar antes de concluir qualquer coisa sobre desempenho de pgvector

Falha injetada`ef_search` reduzido para ganhar latência

Como injetarBaixar `hnsw.ef_search` e repetir o golden set de 60 perguntas

Sintoma enganosoA latência p99 melhora de forma convincente, e o painel de desempenho fica mais bonito. Nenhum erro, nenhum alarme

Diagnóstico corretoO recall caiu junto, e ninguém mediu. Esse parâmetro é exatamente a alavanca entre latência e qualidade da busca aproximada: menos exploração do grafo significa resposta mais rápida e mais chance de o trecho certo não estar entre os recuperados. O RAG continua respondendo — com citação, com confiança, e mais vezes errado. É a razão de este laboratório medir recall contra golden set em vez de olhar latência sozinha

Falha injetadaAcervo cresce sem reindexar

Como injetarIngerir mais 40 mil trechos e repetir o golden set sem tocar em nenhum parâmetro de índice

Sintoma enganosoTudo continua respondendo, e o custo sobe de forma proporcional e previsível

Diagnóstico corretoParâmetro de índice aproximado é dimensionado para um tamanho de acervo; ao dobrar o acervo, a mesma configuração explora uma fração menor do grafo e o recall cai de novo, em silêncio. A medição deste laboratório tem prazo de validade, e o prazo é o próximo crescimento relevante do acervo. Registre junto da tabela o tamanho em que ela foi medida

Falha injetadaTráfego zerado por um fim de semana

Como injetarSuspender as consultas de sexta a segunda e olhar a fatura dos quatro backends na segunda-feira

Sintoma enganosoTrês dos quatro custam praticamente nada. Um deles custou o fim de semana inteiro

Diagnóstico corretoAqui a falha injetada é a ausência de carga, e ela separa os backends por MODELO DE COBRANÇA, não por desempenho — que é a dimensão que a tabela de medição não mostra. Coleção gerenciada com piso de capacidade cobra a capacidade provisionada, não a consulta; armazenamento vetorial cobrado por requisição não cobra nada em repouso. Confirme os pisos vigentes na página de preços de cada serviço antes de decidir: são o tipo de número que muda, e para acervo pequeno com tráfego irregular eles dominam a conta inteira

⚠️

Três destas falhas passariam por um teste de fumaça

A segunda, a terceira e a quarta não geram exceção, não acionam alarme e não aparecem em teste automatizado que verifique "a busca respondeu". Duas delas pioram a resposta que o cliente lê e a terceira aparece só na fatura. É por isso que a métrica que este laboratório defende é recall contra um conjunto de perguntas conhecido, medido periodicamente — a única das quatro que denuncia as três primeiras.

Segurança

Risco	Probabilidade	Impacto	Prevenção	Detecção	Resposta
Policy de acesso copiada entre backends com escopo errado	Média	Alto	policy específica por backend (data access policy do OpenSearch, role do RDS, policy do S3 Vectors) — nunca reusada entre os quatro	CloudTrail + IAM Access Analyzer	revogar a policy copiada e reemitir com o escopo mínimo do backend real
Credencial do Aurora (usuário Postgres) exposta em variável de ambiente do harness	Média	Alto	Secrets Manager com rotação, lido em runtime pela aplicação .NET 8 — nunca embutido na imagem	GuardDuty + alerta de acesso fora do padrão de horário	rotacionar a credencial e auditar `pg_stat_activity` por conexão suspeita
Bucket do S3 Vectors com política pública por engano	Baixa	Alto	Block Public Access na conta, policy explícita só para a role da aplicação	Config com regra de bucket público + Macie	corrigir a policy imediatamente e revisar CloudTrail por leitura indevida
Harness de benchmark com permissão de escrita quando só precisava de leitura	Média	Médio	role do harness só com ações de consulta por backend — nunca `PutItem`/`Index`/`INSERT` em produção	revisão de policy no CI, antes do merge	remover a permissão de escrita e reexecutar o benchmark com a role corrigida

RiscoPolicy de acesso copiada entre backends com escopo errado

ProbabilidadeMédia

ImpactoAlto

Prevençãopolicy específica por backend (data access policy do OpenSearch, role do RDS, policy do S3 Vectors) — nunca reusada entre os quatro

DetecçãoCloudTrail + IAM Access Analyzer

Respostarevogar a policy copiada e reemitir com o escopo mínimo do backend real

RiscoCredencial do Aurora (usuário Postgres) exposta em variável de ambiente do harness

ProbabilidadeMédia

ImpactoAlto

PrevençãoSecrets Manager com rotação, lido em runtime pela aplicação .NET 8 — nunca embutido na imagem

DetecçãoGuardDuty + alerta de acesso fora do padrão de horário

Respostarotacionar a credencial e auditar `pg_stat_activity` por conexão suspeita

RiscoBucket do S3 Vectors com política pública por engano

ProbabilidadeBaixa

ImpactoAlto

PrevençãoBlock Public Access na conta, policy explícita só para a role da aplicação

DetecçãoConfig com regra de bucket público + Macie

Respostacorrigir a policy imediatamente e revisar CloudTrail por leitura indevida

RiscoHarness de benchmark com permissão de escrita quando só precisava de leitura

ProbabilidadeMédia

ImpactoMédio

Prevençãorole do harness só com ações de consulta por backend — nunca `PutItem`/`Index`/`INSERT` em produção

Detecçãorevisão de policy no CI, antes do merge

Respostaremover a permissão de escrita e reexecutar o benchmark com a role corrigida

A policy mínima do harness cobre os três backends alternativos — o acesso ao OpenSearch Serverless já é o mesmo restringido no L83, sem mudança aqui.

harness-benchmark-policy.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AcessoAoIndiceOpenSearchProvisionado",
      "Effect": "Allow",
      "Action": ["es:ESHttpGet", "es:ESHttpPost"],
      "Resource": "arn:aws:es:us-east-1:111122223333:domain/cadencia-l84-opensearch-provisionado/*"
    },
    {
      "Sid": "AcessoAoIndiceS3Vectors",
      "Effect": "Allow",
      "Action": ["s3vectors:QueryVectors", "s3vectors:GetIndex"],
      "Resource": "arn:aws:s3vectors:us-east-1:111122223333:bucket/cadencia-l84-s3-vectors/*"
    },
    {
      "Sid": "SegredoDoPgvectorNuncaNaImagem",
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:cadencia-aurora-l14-*"
    }
  ]
}

Quiz rápido

Por que o RAG da Cadência acabou usando OpenSearch Serverless — o que este laboratório chama de "escolhido por moda"?

Observabilidade e operação

As perguntas que o painel do harness precisa responder, durante e depois do benchmark:

Qual backend está respondendo a consulta agora, e com que latência?
O recall do golden set caiu desde a última medição, para algum backend?
A capacidade mínima do OpenSearch Serverless está sendo desperdiçada (tráfego zero, custo fixo)?
O reader do Aurora está competindo entre busca vetorial e o relatório de faturamento do L14?
Alguma consulta caiu para sequential scan no pgvector, sinal de índice não usado?

Alarme	Limiar inicial	O que ele pega
Latência p99 de busca vetorial	> 250 ms por 5 min	backend degradando antes do orçamento de 3 s do L83 estourar
CPU do reader do Aurora (pgvector)	> 70% por 10 min	busca vetorial competindo com o relatório de faturamento do L14
OCU consumidas = OCU mínimas do OpenSearch Serverless	7 dias seguidos	capacidade reservada sem tráfego suficiente para justificar o piso
Sequential scan detectado no pgvector	qualquer ocorrência em `pg_stat_statements`	índice HNSW não sendo usado — geralmente operador de distância errado na query

AlarmeLatência p99 de busca vetorial

Limiar inicial> 250 ms por 5 min

O que ele pegabackend degradando antes do orçamento de 3 s do L83 estourar

AlarmeCPU do reader do Aurora (pgvector)

Limiar inicial> 70% por 10 min

O que ele pegabusca vetorial competindo com o relatório de faturamento do L14

AlarmeOCU consumidas = OCU mínimas do OpenSearch Serverless

Limiar inicial7 dias seguidos

O que ele pegacapacidade reservada sem tráfego suficiente para justificar o piso

AlarmeSequential scan detectado no pgvector

Limiar inicialqualquer ocorrência em `pg_stat_statements`

O que ele pegaíndice HNSW não sendo usado — geralmente operador de distância errado na query

Escala e resiliência: como cada backend se comporta em cada ordem de grandeza

Volume de trechos	OpenSearch Serverless	OpenSearch self-managed	S3 Vectors	Aurora pgvector
10	recall e latência iguais aos medidos aqui — a capacidade mínima já cobre	sobra de capacidade nas 3 instâncias, sem ganho perceptível de recall	latência de acesso ao objeto já é o teto — não piora com volume tão baixo	cabe tranquilamente no reader existente, sem disputa por memória
10 mil	ainda dentro do OCU mínimo, sem mudança de custo	ainda folgado — ganho de recall começa a compensar o tuning manual	latência estável, ainda em torno de 180 ms	índice HNSW cresce, mas cabe em memória do reader sem ajuste
1 milhão	OCU escala automaticamente — custo passa a acompanhar o volume	precisa somar nós de dados, replanejamento manual de capacidade	latência começa a subir com mais partições consultadas por busca	índice HNSW passa a exigir mais RAM do que o reader do L14 tem disponível — é o limite real do pgvector nesta escala
pico de campanha (20×, medido no L14)	escala automática absorve; a fatura acompanha o pico	precisa capacidade pré-provisionada para o pico, ou a latência degrada	sem capacidade reservada, absorve o pico sem replanejamento prévio	compete por CPU com o relatório de faturamento do L14 se não isolar o reader
falha de AZ	coleção é multi-AZ por padrão internamente, sem ação da equipe	réplica entre AZs precisa ser configurada manualmente, senão perde disponibilidade	regional — sobrevive a falha de AZ isolada por padrão	failover do Aurora promove um reader — a mesma mecânica já medida no L07

Volume de trechos10

OpenSearch Serverlessrecall e latência iguais aos medidos aqui — a capacidade mínima já cobre

OpenSearch self-managedsobra de capacidade nas 3 instâncias, sem ganho perceptível de recall

S3 Vectorslatência de acesso ao objeto já é o teto — não piora com volume tão baixo

Aurora pgvectorcabe tranquilamente no reader existente, sem disputa por memória

Volume de trechos10 mil

OpenSearch Serverlessainda dentro do OCU mínimo, sem mudança de custo

OpenSearch self-managedainda folgado — ganho de recall começa a compensar o tuning manual

S3 Vectorslatência estável, ainda em torno de 180 ms

Aurora pgvectoríndice HNSW cresce, mas cabe em memória do reader sem ajuste

Volume de trechos1 milhão

OpenSearch ServerlessOCU escala automaticamente — custo passa a acompanhar o volume

OpenSearch self-managedprecisa somar nós de dados, replanejamento manual de capacidade

S3 Vectorslatência começa a subir com mais partições consultadas por busca

Aurora pgvectoríndice HNSW passa a exigir mais RAM do que o reader do L14 tem disponível — é o limite real do pgvector nesta escala

Volume de trechospico de campanha (20×, medido no L14)

OpenSearch Serverlessescala automática absorve; a fatura acompanha o pico

OpenSearch self-managedprecisa capacidade pré-provisionada para o pico, ou a latência degrada

S3 Vectorssem capacidade reservada, absorve o pico sem replanejamento prévio

Aurora pgvectorcompete por CPU com o relatório de faturamento do L14 se não isolar o reader

Volume de trechosfalha de AZ

OpenSearch Serverlesscoleção é multi-AZ por padrão internamente, sem ação da equipe

OpenSearch self-managedréplica entre AZs precisa ser configurada manualmente, senão perde disponibilidade

S3 Vectorsregional — sobrevive a falha de AZ isolada por padrão

Aurora pgvectorfailover do Aurora promove um reader — a mesma mecânica já medida no L07

💡

Onde o pgvector encontra seu limite real

A linha de 1 milhão de trechos é onde a decisão deste laboratório tem prazo de validade: o índice HNSW do pgvector é residente em memória, e o reader do L14 não foi dimensionado pensando em busca vetorial em grande escala. Cruzar essa linha é o gatilho para remedir — não para assumir que a decisão de hoje continua valendo.

Custos e FinOps

Cenário	Volume	Backend recomendado	Custo aproximado	Por quê
Protótipo, validando a ideia	< 1.000 trechos	S3 Vectors	≈ US$5–10/mês	custo desprezível compensa a latência mais alta enquanto ninguém depende do orçamento de 3 s do atendimento
Produção pequena (o cenário medido neste laboratório)	≈ 44 mil trechos	Aurora pgvector	≈ US$95/mês incremental	reaproveita o Aurora do L14, menor custo total e melhor latência, com operação que a equipe já faz desde o L07
Alta escala, múltiplos times consumindo	> 1 milhão de trechos	OpenSearch self-managed, com equipe dedicada	≈ US$540+/mês, cresce com nós de dados	só compensa quando o volume justifica ter alguém cuidando do índice em tempo integral — é o Nível 6 da evolução

CenárioProtótipo, validando a ideia

Volume< 1.000 trechos

Backend recomendadoS3 Vectors

Custo aproximado≈ US$5–10/mês

Por quêcusto desprezível compensa a latência mais alta enquanto ninguém depende do orçamento de 3 s do atendimento

CenárioProdução pequena (o cenário medido neste laboratório)

Volume≈ 44 mil trechos

Backend recomendadoAurora pgvector

Custo aproximado≈ US$95/mês incremental

Por quêreaproveita o Aurora do L14, menor custo total e melhor latência, com operação que a equipe já faz desde o L07

CenárioAlta escala, múltiplos times consumindo

Volume> 1 milhão de trechos

Backend recomendadoOpenSearch self-managed, com equipe dedicada

Custo aproximado≈ US$540+/mês, cresce com nós de dados

Por quêsó compensa quando o volume justifica ter alguém cuidando do índice em tempo integral — é o Nível 6 da evolução

⚠️

Números voláteis apontam para a fonte, não para a memória

Os valores de custo mensal desta seção e da tabela de medição são estimativas calculadas no AWS Pricing Calculator em 07/ago/2026, para o volume específico medido aqui. Preço de capacidade e de armazenamento mudam por ciclo de produto — confira o número atual antes de decidir; o que não muda é o MODELO de cobrança de cada backend (capacidade reservada vs. por consulta vs. incremental).

Well-Architected

Pilar	Situação	Risco	Melhoria	Prioridade
Excelência operacional	quatro backends candidatos, cada um com operação diferente	equipe aprende quatro operações em vez de uma	documentar runbook só do backend escolhido — não manter os quatro em produção	Alta
Segurança	cada backend tem modelo de IAM diferente (data access policy do OpenSearch vs. role do RDS vs. policy do S3 Vectors)	policy copiada de um backend para outro por engano, com escopo errado	policy específica por backend, revisada na troca — nunca reusada	Alta
Confiabilidade	pgvector roda no mesmo Aurora que já atende o relatório do L14	busca vetorial compete com o relatório pela mesma instância	reader dedicado para busca vetorial, como o L14 já isolou o relatório da escrita	Média
Eficiência de performance	recall e latência medidos uma vez, no volume de hoje	o número não escala — 1 milhão de trechos muda a resposta (ver tabela de escala)	remedir a cada ordem de grandeza de crescimento do acervo	Média
Otimização de custo	OCU mínimo do OpenSearch Serverless cobra mesmo parado	fatura de capacidade reservada sem tráfego suficiente para justificar	medir custo real por backend antes de decidir, nunca por tabela de preço isolada	Alta
Sustentabilidade	quatro índices vetoriais rodando em paralelo, só para o benchmark	manter os quatro além da medição desperdiça capacidade computacional	desligar os três backends não escolhidos assim que a tabela fechar (seção de limpeza)	Média

PilarExcelência operacional

Situaçãoquatro backends candidatos, cada um com operação diferente

Riscoequipe aprende quatro operações em vez de uma

Melhoriadocumentar runbook só do backend escolhido — não manter os quatro em produção

PrioridadeAlta

PilarSegurança

Situaçãocada backend tem modelo de IAM diferente (data access policy do OpenSearch vs. role do RDS vs. policy do S3 Vectors)

Riscopolicy copiada de um backend para outro por engano, com escopo errado

Melhoriapolicy específica por backend, revisada na troca — nunca reusada

PrioridadeAlta

PilarConfiabilidade

Situaçãopgvector roda no mesmo Aurora que já atende o relatório do L14

Riscobusca vetorial compete com o relatório pela mesma instância

Melhoriareader dedicado para busca vetorial, como o L14 já isolou o relatório da escrita

PrioridadeMédia

PilarEficiência de performance

Situaçãorecall e latência medidos uma vez, no volume de hoje

Riscoo número não escala — 1 milhão de trechos muda a resposta (ver tabela de escala)

Melhoriaremedir a cada ordem de grandeza de crescimento do acervo

PrioridadeMédia

PilarOtimização de custo

SituaçãoOCU mínimo do OpenSearch Serverless cobra mesmo parado

Riscofatura de capacidade reservada sem tráfego suficiente para justificar

Melhoriamedir custo real por backend antes de decidir, nunca por tabela de preço isolada

PrioridadeAlta

PilarSustentabilidade

Situaçãoquatro índices vetoriais rodando em paralelo, só para o benchmark

Riscomanter os quatro além da medição desperdiça capacidade computacional

Melhoriadesligar os três backends não escolhidos assim que a tabela fechar (seção de limpeza)

PrioridadeMédia

Evolução em níveis

🗺️ De um backend por padrão a plataforma de dados compartilhada — e o risco que cada nível troca por outro

Nível 1 — ProtótipoRisco resolvido: nenhum. Novo risco: piso de custo de capacidade reservada pago sem decisão consciente, e recall/latência nunca comparados a nada. Custo: ≈US$700/mês, fixo, independente de tráfego.

→

OpenSearch Serverless, escolhido porque é o padrão do Knowledge Bases — nunca medido contra alternativa. É o que a Cadência tinha até este laboratório.

Nível 2 — Este laboratórioRisco resolvido: decisão tomada por moda, sem número. Novo risco: a equipe passa a operar HNSW (VACUUM, `ef_search`, `m`) que antes era gerenciado pelo Knowledge Bases. Custo: cai de ≈US$700 para ≈US$95/mês incremental.

→

As quatro opções medidas no mesmo acervo, com golden set de 60 perguntas; pgvector no Aurora do L14 vence por custo incremental e latência, com a operação do índice passando a ser da equipe.

Nível 3 — Recuperação melhor (L85)Risco resolvido: recuperação trazer o trecho ERRADO mesmo com o backend certo. Novo risco: mais peças no pipeline, mais superfície para calibrar. Custo: cresce com a chamada extra de reranking por pergunta.

→

Busca híbrida (léxica + vetorial) somada a reranking, sobre o backend escolhido aqui — a pergunta deixa de ser só "onde" e passa a incluir "como recuperar melhor".

Nível 4 — Controle sobre o que o sistema diz (L86)Risco resolvido: resposta sobre tópico proibido, mesmo com recuperação correta. Novo risco: falso positivo do guardrail bloqueando pergunta legítima. Custo: chamada adicional de avaliação por resposta.

→

Guardrails como controle real de tópico e conteúdo sobre a resposta gerada, independente de qual backend vetorial alimentou a recuperação.

Nível 5 — Avaliação contínuaRisco resolvido: mudança que piora o recall sem ninguém perceber até a reclamação do cliente. Novo risco: suíte de avaliação desatualizada em relação ao acervo real, se o golden set não crescer junto. Custo: chamadas de avaliação a cada deploy, pequenas frente ao tráfego real.

→

O golden set de 60 perguntas vira suíte de CI, reprovando regressão de recall a cada mudança de chunking, de modelo de embedding ou de parâmetro de índice.

Nível 6 — Dados e IA, plataforma compartilhadaRisco resolvido: cada time reconstruindo o próprio índice vetorial do zero, cada um escolhendo por moda de novo. Novo risco: um índice compartilhado vira ponto único de contenção e de vazamento de informação entre times. Custo: diluído entre consumidores, mas a operação vira produto interno com dono próprio.

→

A escolha de backend vetorial deste laboratório vira decisão de plataforma: múltiplos times (atendimento, lojista, busca de catálogo) compartilham o mesmo índice, com controle de quem vê qual acervo (mesmo padrão do L94).

Extensão com IA

💡

IA já é o assunto — a próxima alavanca é recuperação, não mais modelo

Este laboratório inteiro já é sobre infraestrutura de IA — não há uma camada extra de "adicionar IA" a acrescentar sobre uma decisão de banco de dados comum. A alavanca de IA que ainda falta aqui não é mais modelo, é melhor RECUPERAÇÃO: busca híbrida somando léxico (BM25) a vetorial, e reranking reordenando o top-k antes de gerar — é exatamente o L85, que parte do backend escolhido nesta medição.

Anti-patterns

Erro	Por que alguém faz	Sintoma em produção	Forma correta
Aceitar o backend padrão do Knowledge Bases sem medir	é o caminho de menor resistência da documentação — o console já cria a coleção sozinho, e ninguém questiona até o custo ou a latência doer	fatura de capacidade mínima chega alta mesmo com tráfego baixo, e ninguém sabe justificar o número	medir as quatro opções no mesmo acervo antes de decidir, como este laboratório
Trocar de backend só porque "parece mais barato no anúncio"	o preço por GB de um serviço novo é vendido isolado, e o número isolado convence rápido	latência sobe, o orçamento de 3 s do atendimento estoura, e ninguém liga os dois fatos	medir latência e recall junto com custo — as três dimensões, nunca uma sozinha
Confundir recall alto em teste isolado com recall real no golden set	testar com três perguntas fáceis dá um número bonito rápido, sem esforço de curadoria	o sistema erra em produção perguntas que o teste nunca cobriu	golden set representativo, com perguntas difíceis e ambíguas — não só as óbvias
Migrar índice vetorial copiando os vetores prontos, sem reindexar	parece que copiar o vetor já resolve — o dado é "o mesmo"	recall despenca porque o parâmetro de construção do índice (`ef_construction`, `m`) era outro no backend de origem	reindexar com os parâmetros do novo backend — nunca copiar índice pronto entre motores diferentes
Ignorar o custo de OPERAR o índice, olhando só o custo de armazenar	a fatura de armazenamento é pequena e some no orçamento geral, então parece que "acabou"	VACUUM ou reindexação consomem CPU do Aurora na hora de pico, sem ninguém ter provisionado para isso	medir o custo de manutenção do índice junto com o de armazenamento, não separado

ErroAceitar o backend padrão do Knowledge Bases sem medir

Por que alguém fazé o caminho de menor resistência da documentação — o console já cria a coleção sozinho, e ninguém questiona até o custo ou a latência doer

Sintoma em produçãofatura de capacidade mínima chega alta mesmo com tráfego baixo, e ninguém sabe justificar o número

Forma corretamedir as quatro opções no mesmo acervo antes de decidir, como este laboratório

ErroTrocar de backend só porque "parece mais barato no anúncio"

Por que alguém fazo preço por GB de um serviço novo é vendido isolado, e o número isolado convence rápido

Sintoma em produçãolatência sobe, o orçamento de 3 s do atendimento estoura, e ninguém liga os dois fatos

Forma corretamedir latência e recall junto com custo — as três dimensões, nunca uma sozinha

ErroConfundir recall alto em teste isolado com recall real no golden set

Por que alguém faztestar com três perguntas fáceis dá um número bonito rápido, sem esforço de curadoria

Sintoma em produçãoo sistema erra em produção perguntas que o teste nunca cobriu

Forma corretagolden set representativo, com perguntas difíceis e ambíguas — não só as óbvias

ErroMigrar índice vetorial copiando os vetores prontos, sem reindexar

Por que alguém fazparece que copiar o vetor já resolve — o dado é "o mesmo"

Sintoma em produçãorecall despenca porque o parâmetro de construção do índice (`ef_construction`, `m`) era outro no backend de origem

Forma corretareindexar com os parâmetros do novo backend — nunca copiar índice pronto entre motores diferentes

ErroIgnorar o custo de OPERAR o índice, olhando só o custo de armazenar

Por que alguém faza fatura de armazenamento é pequena e some no orçamento geral, então parece que "acabou"

Sintoma em produçãoVACUUM ou reindexação consomem CPU do Aurora na hora de pico, sem ninguém ter provisionado para isso

Forma corretamedir o custo de manutenção do índice junto com o de armazenamento, não separado

Troubleshooting

Sintoma	Causa provável	Como investigar	Log/métrica	Correção
Recall cai depois de trocar de backend	parâmetros do índice (`ef_search`, `m`, número de clusters) não foram recalibrados para o novo motor	rodar o golden set completo antes e depois da troca, comparando recall@5 pergunta a pergunta	resultado do benchmark harness, por pergunta e por backend	recalibrar `ef_search`/`m` (HNSW) ou os parâmetros equivalentes do novo backend para o volume real do acervo
Latência p99 do pgvector sobe durante o horário de pico do relatório	a busca vetorial e o relatório de faturamento do L14 competem pelo mesmo reader do Aurora	correlacionar o timestamp da consulta lenta com CloudWatch do reader (CPU, IOPS)	Performance Insights do reader, filtrado por `pg_stat_statements`	reader dedicado para busca vetorial, separado do reader de relatório — mesmo padrão do L14
Custo do OpenSearch Serverless não cai mesmo sem tráfego	capacidade mínima (OCU) é cobrada independente de uso	Cost Explorer filtrado pelo serviço OpenSearch Serverless	OCU consumidas vs. OCU mínimas, no console do OpenSearch	aceitar o piso como parte consciente da decisão, ou migrar para um backend sem capacidade reservada
S3 Vectors devolve resultado certo, mas a resposta chega depois do tempo aceitável	latência p99 de 520 ms, somada à geração, estoura o orçamento de 3 s herdado do L83	medir separadamente busca e geração no log estruturado de citação do L83	campo `latenciaMs` do log, decomposto por fase	usar S3 Vectors para acervo frio ou processamento em lote, não no caminho de atendimento ao vivo
Query no pgvector ignora o índice HNSW e faz sequential scan	o operador de distância na query não casa com o operador usado na criação do índice (`<=>` cosseno vs. `<->` euclidiana)	`EXPLAIN ANALYZE` na query, procurando "Seq Scan" em vez de "Index Scan"	plano de execução do Postgres	criar o índice com o mesmo operador usado na consulta, e confirmar com `EXPLAIN` antes de medir latência

SintomaRecall cai depois de trocar de backend

Causa provávelparâmetros do índice (`ef_search`, `m`, número de clusters) não foram recalibrados para o novo motor

Como investigarrodar o golden set completo antes e depois da troca, comparando recall@5 pergunta a pergunta

Log/métricaresultado do benchmark harness, por pergunta e por backend

Correçãorecalibrar `ef_search`/`m` (HNSW) ou os parâmetros equivalentes do novo backend para o volume real do acervo

SintomaLatência p99 do pgvector sobe durante o horário de pico do relatório

Causa provávela busca vetorial e o relatório de faturamento do L14 competem pelo mesmo reader do Aurora

Como investigarcorrelacionar o timestamp da consulta lenta com CloudWatch do reader (CPU, IOPS)

Log/métricaPerformance Insights do reader, filtrado por `pg_stat_statements`

Correçãoreader dedicado para busca vetorial, separado do reader de relatório — mesmo padrão do L14

SintomaCusto do OpenSearch Serverless não cai mesmo sem tráfego

Causa provávelcapacidade mínima (OCU) é cobrada independente de uso

Como investigarCost Explorer filtrado pelo serviço OpenSearch Serverless

Log/métricaOCU consumidas vs. OCU mínimas, no console do OpenSearch

Correçãoaceitar o piso como parte consciente da decisão, ou migrar para um backend sem capacidade reservada

SintomaS3 Vectors devolve resultado certo, mas a resposta chega depois do tempo aceitável

Causa provávellatência p99 de 520 ms, somada à geração, estoura o orçamento de 3 s herdado do L83

Como investigarmedir separadamente busca e geração no log estruturado de citação do L83

Log/métricacampo `latenciaMs` do log, decomposto por fase

Correçãousar S3 Vectors para acervo frio ou processamento em lote, não no caminho de atendimento ao vivo

SintomaQuery no pgvector ignora o índice HNSW e faz sequential scan

Causa provávelo operador de distância na query não casa com o operador usado na criação do índice (`<=>` cosseno vs. `<->` euclidiana)

Como investigar`EXPLAIN ANALYZE` na query, procurando "Seq Scan" em vez de "Index Scan"

Log/métricaplano de execução do Postgres

Correçãocriar o índice com o mesmo operador usado na consulta, e confirmar com `EXPLAIN` antes de medir latência

Perguntas frequentes

❓ Por que o Knowledge Bases usa OpenSearch Serverless por padrão?

Porque é o único backend que o assistente do console provisiona sozinho, sem pedir nenhuma decisão de rede ou de capacidade — ele cria a coleção VECTORSEARCH e resolve criptografia e política de rede com valores padrão. É o caminho de menor resistência da documentação, não uma avaliação de recall, latência ou custo: neste laboratório, esse caminho custa cerca de US$700 por mês só de capacidade mínima, rodando ou parado, porque o serviço cobra por unidade reservada, não por consulta.

❓ Vale a pena trocar um RAG que já funciona (L83) por causa de um benchmark de custo?

Vale quando a diferença medida é grande o suficiente para justificar o trabalho de migração — e, neste caso, é: o custo incremental do pgvector é cerca de sete vezes menor que o piso do OpenSearch Serverless, com latência melhor, não pior. Trocar por uma diferença de 5% num número não vale o risco de regressão; trocar por uma diferença de 7× no custo mensal, mantendo recall equivalente, é exatamente o tipo de decisão que este laboratório existe para sustentar com número.

❓ S3 Vectors é sempre a opção errada por causa da latência alta?

Não — a latência alta (p99 de 520 ms neste benchmark) só desqualifica S3 Vectors para o caminho de atendimento AO VIVO, que tem orçamento de 3 segundos somando busca e geração. Para um acervo consultado em lote, sem usuário esperando resposta em tempo real — enriquecimento noturno de catálogo, por exemplo — o custo dez vezes menor pode ser exatamente a escolha certa. A decisão depende do requisito de latência declarado, não de uma regra fixa sobre o serviço.

❓ Por que medir recall@5 e não recall@1 ou recall@10?

Porque 5 é o número de trechos que o RetrieveAndGenerate do L83 efetivamente recupera antes de gerar a resposta — medir com um k diferente do k real de produção mediria um sistema que não existe. Recall@1 seria mais rígido que o sistema real precisa ser, e recall@10 mediria uma folga que o prompt de geração nunca recebe. O k do benchmark tem de casar com o k da produção, senão o número não se aplica à decisão que ele deveria sustentar.

❓ Todos os quatro backends podem alimentar a mesma Knowledge Base do Bedrock?

Sim — a Knowledge Base separa a camada de ingestão (chunking, embedding, RetrieveAndGenerate) da camada de armazenamento vetorial, e o campo `storage_configuration.type` é o que muda entre OpenSearch Serverless, OpenSearch provisionado, pgvector no RDS/Aurora e, mais recentemente, S3 Vectors. É essa separação que torna a comparação deste laboratório possível sem reescrever o pipeline de citação que o L83 já validou.

❓ Por que o pgvector venceu se o OpenSearch self-managed teve o melhor recall medido?

Porque recall isolado não era o único requisito declarado — latência, custo incremental e a capacidade da equipe de operar o backend sem plantão dedicado também eram. O OpenSearch self-managed ganhou por apenas um ponto percentual de recall (0,95 contra 0,94) e perdeu de forma expressiva em custo e em exigência operacional para uma equipe de duas pessoas. A decisão certa é a que melhor serve TODOS os requisitos declarados, não a que vence isoladamente em uma única coluna da tabela.

❓ O índice HNSW do pgvector aguenta o crescimento futuro da Cadência?

Aguenta até um ponto medido e declarado neste laboratório: a tabela de escala mostra que, por volta de 1 milhão de trechos, o índice HNSW passa a exigir mais memória do que o reader do Aurora do L14 tem disponível hoje. Até lá, o pgvector é a escolha correta pelos números medidos; passar dessa marca é o gatilho explícito para remedir as quatro opções de novo, não para assumir que a decisão de hoje continua valendo para sempre.

Fixando

Quiz rápido

Qual é a razão CORRETA, segundo a decisão registrada neste laboratório, para preferir Aurora pgvector a OpenSearch Serverless no caso da Cadência?

Quiz rápido

O que recall@5 mede neste benchmark, e por que ele pode ser MENOR num backend com índice "mais sofisticado" no papel?

Checklist de produção

Golden set com pelo menos 60 perguntas, cobrindo os dois tipos de conteúdo do acervo
Recall@5, latência p50/p99 e custo mensal medidos nos quatro backends, no mesmo dia
Decisão escrita com o trade-off explícito, não só o nome do vencedor
Backend escolhido tem runbook próprio; os três descartados foram desligados
Reader dedicado para busca vetorial, se o backend escolhido for pgvector, separado do reader de relatório
Alarmes de latência p99 e de custo de capacidade reservada configurados
Policy de IAM específica do backend escolhido, revisada — nenhuma copiada de outro backend

Limpeza do laboratório

Este laboratório cria três backends só para o benchmark. O vencedor (pgvector) reaproveita infraestrutura que já existia; os outros dois que não estavam em produção — OpenSearch self-managed e S3 Vectors — cobram até serem removidos.

limpar-l84.sh

#!/usr/bin/env bash
# limpar-l84.sh — derruba os TRÊS backends que perderam o benchmark.
# O backend escolhido (Aurora pgvector) NAO entra aqui: ele reaproveita o
# cluster do L14, que continua vivo para o resto da plataforma.
set -euo pipefail

echo "1/4 — Removendo o dominio OpenSearch self-managed (backend B)"
aws opensearch delete-domain --domain-name cadencia-l84-opensearch-provisionado
aws opensearch describe-domain --domain-name cadencia-l84-opensearch-provisionado \
  --query 'DomainStatus.Deleted' # confirme "true" antes de seguir

echo "2/4 — Removendo o indice e o bucket do S3 Vectors (backend C)"
aws s3vectors delete-index --bucket-name cadencia-l84-s3-vectors --index-name cadencia-acervo
aws s3vectors delete-bucket --bucket-name cadencia-l84-s3-vectors

echo "3/4 — Removendo o grupo de logs do harness (retencao de 30 dias, mas cobra ate la)"
aws logs delete-log-group --log-group-name /cadencia/l84/harness-benchmark

echo "4/4 — O backend A (OpenSearch Serverless) e o D (Aurora pgvector) NAO sao removidos:"
echo "      o primeiro segue em producao desde o L83; o segundo reaproveita o cluster do L14."
echo "      Se a decisao final foi trocar de backend em producao, desativar o A e' um passo"
echo "      separado, fora deste laboratorio — e so depois de migrar o trafego real."

⚠️

"Destruir" não remove tudo sozinho

`terraform destroy` no domínio OpenSearch self-managed NÃO remove o log group de erro de índice que ele cria automaticamente, nem o snapshot manual se você tirou algum durante o teste de recall. Confira os dois separadamente antes de considerar a limpeza completa — é o mesmo tipo de resíduo que o L01 já alertava para snapshot de RDS.

Resumo visual

Problema	Serviço	Motivo
Backend escolhido sem medir recall, latência ou custo	benchmark harness (.NET 8) + golden set de 60 perguntas	mede os quatro no mesmo acervo, no mesmo dia
Cada backend cobra e opera de um jeito diferente	Aurora pgvector, OpenSearch Serverless, OpenSearch self-managed, S3 Vectors	mesma pergunta, quatro respostas mensuráveis lado a lado
Decisão precisa sobreviver ao próximo crescimento de volume	tabela de escala por ordem de grandeza	recall e latência mudam com 1 milhão de trechos — a decisão de hoje tem prazo de validade
Índice não escolhido continua cobrando depois do teste	seção de limpeza	desliga os dois backends que perderam o benchmark e não reaproveitavam infra existente

ProblemaBackend escolhido sem medir recall, latência ou custo

Serviçobenchmark harness (.NET 8) + golden set de 60 perguntas

Motivomede os quatro no mesmo acervo, no mesmo dia

ProblemaCada backend cobra e opera de um jeito diferente

ServiçoAurora pgvector, OpenSearch Serverless, OpenSearch self-managed, S3 Vectors

Motivomesma pergunta, quatro respostas mensuráveis lado a lado

ProblemaDecisão precisa sobreviver ao próximo crescimento de volume

Serviçotabela de escala por ordem de grandeza

Motivorecall e latência mudam com 1 milhão de trechos — a decisão de hoje tem prazo de validade

ProblemaÍndice não escolhido continua cobrando depois do teste

Serviçoseção de limpeza

Motivodesliga os dois backends que perderam o benchmark e não reaproveitavam infra existente

💡

Próximo laboratório: L85

O backend está decidido e medido. O próximo gargalo não é mais ONDE guardar o vetor — é O QUE recuperar: busca híbrida somando léxico a vetorial, e reranking reordenando o resultado antes da geração. Isso é o L85, que parte exatamente do backend escolhido aqui.

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

🔍

Lab 85 — Recuperação híbrida e reranking

100 Laboratórios de Arquitetura AWS · 36 min · +195 XP

→

Temas deste módulo

Discussão

Carregando comentários…

Lab 84 — Onde guardar vetor: quatro opções, uma decisão

⏱ 31 min·⭐ 190 XP

O problema, e a empresa que o tem

NívelAvançado — depende do L14 (Aurora rodando, com reader ocioso) e do L83 (RAG mínimo com citação, já em produção sobre OpenSearch Serverless)

Pré-requisitosL14 e L83 concluídos, familiaridade com SQL e com uma consulta ANN básica, .NET 8

Tempo estimadoEstudo 55 min · implementação 3 h a 3 h 30

Custo relativoMédio durante o benchmark — os quatro backends rodam em paralelo por algumas horas; alto se qualquer um ficar esquecido ligado depois (ver seção de limpeza)

ServiçosBedrock Knowledge Bases, OpenSearch Serverless, Amazon OpenSearch Service (self-managed), S3 Vectors, Aurora PostgreSQL (pgvector), Fargate (.NET 8), CloudWatch, Cost Explorer, IAM

Acervo medido≈44.400 trechos — 1.200 de política (mesmo do L83) + 43.200 do catálogo ouro por loja (900 lojas × 48 trechos), embeddings Titan v2 de 1.024 dimensões

Requisito declaradorecall@5, latência p50/p99 e custo mensal medidos nos quatro backends, sobre o mesmo acervo e o mesmo golden set, no mesmo dia

Ao final você temuma tabela com recall@5, p50, p99 e custo mensal das quatro opções, e uma decisão escrita com o trade-off explícito — não a sensação de que uma parece melhor

🚨

O defeito não é o backend — é nunca ter comparado

⚠️

O que este laboratório NÃO é

O que você vai conseguir fazer

Objetivos verificáveis: cada um se prova com uma medição na seção de implantação, não com a sensação de que um backend "parece mais rápido".

Publicar o mesmo acervo (documentos do L83 + catálogo ouro do L62) nos quatro backends: OpenSearch Serverless, OpenSearch self-managed, S3 Vectors e Aurora pgvector.
Construir um golden set de 60 perguntas com resposta oficial, cobrindo política e busca por produto no catálogo.
Medir recall@5 dos quatro backends contra o mesmo golden set, no mesmo dia, isolando a busca vetorial da geração.
Medir latência p50 e p99 de cada backend, separadamente da latência de geração já medida no L83.
Calcular o custo mensal projetado de cada backend a partir do modelo de cobrança real — não de um número decorado.
Explicar por que índice ANN troca exatidão por velocidade, e como HNSW e IVF fazem essa troca de formas diferentes.
Escrever uma decisão com o trade-off explícito: qual backend, por quê, e o que se perde ao escolhê-lo.
Restringir o acesso a cada backend por IAM específico do backend — nunca uma policy copiada de outro.

O que a certificação cobra disto

Conceito	Certificação	Como aparece aqui	O que dominar
Índice ANN (Approximate Nearest Neighbor)	MLS-C01, MLA-C01	os quatro backends usam ANN, com implementações diferentes (HNSW nos dois OpenSearch e no pgvector; IVF-like no S3 Vectors)	ANN troca exatidão por velocidade — recall@k mede exatamente o quanto se perde
HNSW vs. índice por clusters (IVF)	MLS-C01	OpenSearch e pgvector usam grafo HNSW; S3 Vectors usa uma variação de clustering otimizada para armazenamento em objeto	HNSW: melhor recall, mais memória residente; clustering: mais barato, recall menor em corpus pequeno
Trade-off recall vs. latência vs. custo	MLS-C01, MLA-C01	tabela única com os quatro backends, mesmo acervo, mesmo golden set, mesmo dia	não existe backend "melhor" isolado — existe o que serve o requisito não funcional declarado
RAG gerenciado vs. índice operado pela equipe	AIF-C01, MLA-C01	aprofunda a pergunta que o L83 deixou em aberto, agora com número: Knowledge Bases (gerenciado) contra pgvector e OpenSearch self-managed (operados)	gerenciado tira o trabalho de tuning; operado tira o piso de capacidade reservada
Disponibilidade e replicação do índice vetorial	SAA-C03, MLA-C01	o reader do Aurora lê o mesmo volume de cluster do writer (sem cópia); a coleção OpenSearch Serverless é multi-AZ por padrão internamente	cada backend replica de um jeito diferente, e o lag de replicação entra na medição de latência
Capacidade reservada vs. cobrança sob demanda	MLA-C01	o piso de OCU do OpenSearch Serverless contra a cobrança por consulta do S3 Vectors	capacidade reservada garante latência previsível; sob demanda garante custo baixo quando o tráfego é incerto

ConceitoÍndice ANN (Approximate Nearest Neighbor)

CertificaçãoMLS-C01, MLA-C01

Como aparece aquios quatro backends usam ANN, com implementações diferentes (HNSW nos dois OpenSearch e no pgvector; IVF-like no S3 Vectors)

O que dominarANN troca exatidão por velocidade — recall@k mede exatamente o quanto se perde

ConceitoHNSW vs. índice por clusters (IVF)

CertificaçãoMLS-C01

Como aparece aquiOpenSearch e pgvector usam grafo HNSW; S3 Vectors usa uma variação de clustering otimizada para armazenamento em objeto

O que dominarHNSW: melhor recall, mais memória residente; clustering: mais barato, recall menor em corpus pequeno

ConceitoTrade-off recall vs. latência vs. custo

CertificaçãoMLS-C01, MLA-C01

Como aparece aquitabela única com os quatro backends, mesmo acervo, mesmo golden set, mesmo dia

O que dominarnão existe backend "melhor" isolado — existe o que serve o requisito não funcional declarado

ConceitoRAG gerenciado vs. índice operado pela equipe

CertificaçãoAIF-C01, MLA-C01

Como aparece aquiaprofunda a pergunta que o L83 deixou em aberto, agora com número: Knowledge Bases (gerenciado) contra pgvector e OpenSearch self-managed (operados)

O que dominargerenciado tira o trabalho de tuning; operado tira o piso de capacidade reservada

ConceitoDisponibilidade e replicação do índice vetorial

CertificaçãoSAA-C03, MLA-C01

Como aparece aquio reader do Aurora lê o mesmo volume de cluster do writer (sem cópia); a coleção OpenSearch Serverless é multi-AZ por padrão internamente

O que dominarcada backend replica de um jeito diferente, e o lag de replicação entra na medição de latência

ConceitoCapacidade reservada vs. cobrança sob demanda

CertificaçãoMLA-C01

Como aparece aquio piso de OCU do OpenSearch Serverless contra a cobrança por consulta do S3 Vectors

O que dominarcapacidade reservada garante latência previsível; sob demanda garante custo baixo quando o tráfego é incerto

💡

Onde isto costuma ser cobrado errado

Requisitos, e como cada um muda o desenho

Requisito que não vira uma linha do benchmark é intenção. A coluna da direita é onde cada um deixou marca no harness, no Terraform ou na decisão final.

Requisito	Valor declarado	O que ele decide no desenho
Resposta continua citando o trecho exato, trocando o backend	obrigatório	RetrieveAndGenerate funciona igual nos quatro — a troca fica só em storage_configuration.type da Knowledge Base
Latência de busca cabe no orçamento de 3 s do atendimento (herdado do L83)	busca + geração ≤ 3 s	descarta S3 Vectors do caminho de atendimento AO VIVO, sem descartar o serviço por completo
Recall@5 não pode ficar abaixo do que o LLM direto sem RAG já entregaria	≥ 0,85 (a barra medida no L83 antes do RAG)	qualquer backend abaixo da barra é eliminado antes de entrar na comparação de custo
Custo mensal medido, não estimado por material de marketing	golden set roda nos quatro no mesmo dia, mesma hora	elimina viés de comparar números de datas ou cargas diferentes
Equipe de duas pessoas continua sem plantão dedicado a banco vetorial	operação não pode exigir tuning contínuo de cluster	pesa contra OpenSearch self-managed mesmo quando ele vence em recall
Infraestrutura que já existe conta como custo zero de novo serviço	reaproveitar o Aurora do L14 quando servir	dá ao pgvector uma vantagem estrutural de custo que nenhum preço por unidade apaga
Decisão registrada com número, não com sensação	recall, p50/p99 e custo mensal lado a lado, na mesma tabela	decision_box e comparison_table, nunca "parece mais rápido"
Trocar de backend não pode quebrar a auditoria de citação	obrigatório	o campo `chunkId`/`documento` do log do L83 precisa existir nos quatro backends escolhidos