Lab 83 — RAG mínimo que funciona, com citação

⏱ 33 min·⭐ 175 XP

O problema, e a empresa que o tem

A central de atendimento da Cadência recebe cerca de 1.200 perguntas por dia, entre lojistas parceiros e clientes finais, pelo chat do painel de atendimento. Três semanas atrás, alguém do mesmo time que fez a L81 plugou uma chamada direta ao Bedrock no painel: o atendente digita a pergunta do cliente, e uma sugestão de resposta aparece ao lado, pronta para copiar. Para perguntas genéricas — "vocês entregam em todo o Brasil?", "como funciona o PIX parcelado?" — funciona bem, e o time adotou sem cerimônia.

O problema aparece nas perguntas específicas da Cadência: política de devolução, garantia por categoria de produto, frete por lojista. O modelo nunca viu os documentos internos que descrevem essas políticas — eles nunca foram publicados na internet, e não fazem parte de nenhum corpus de treino público. Sem nenhum trecho desses documentos no prompt, o modelo completa a resposta com o padrão mais provável de uma política de e-commerce genérica: soa igualmente confiante, igualmente bem escrita, e não tem relação nenhuma com a política real da Cadência.

O caso que chegou à equipe de dados: um atendente aceitou a sugestão do modelo para "qual a política de devolução de material elétrico?" — a resposta dizia "30 dias corridos, sem necessidade de nota fiscal". A política real da Cadência para material elétrico é 7 dias, com nota fiscal e produto lacrado, por exigência de segurança elétrica dos fornecedores. O cliente devolveu um produto usado fora do prazo real, a loja parceira reclamou do prejuízo, e o caso virou chamado formal — o primeiro sinal de que "parece uma resposta boa" não é o mesmo que "é a resposta certa".

NívelAvançado — depende do L62 (documentos e catálogo já em camadas no S3) e do tema do L81 (cliente que já sabe chamar o Bedrock)

Pré-requisitosL62 concluído (camada ouro alimentando texto por loja), familiaridade com uma chamada básica ao Bedrock (tema do L81), .NET 8

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

Custo relativoBaixo a médio — o OpenSearch Serverless cobra por capacidade mínima (OCU) mesmo parado, e é o item que mais pesa na fatura deste laboratório

ServiçosBedrock (modelo + Knowledge Bases), S3, OpenSearch Serverless, Lambda (.NET 8), API Gateway, CloudWatch, IAM

Volume medido≈1.200 perguntas/dia na central de atendimento; ≈18% (≈216/dia) são sobre política específica da Cadência — o recorte que este laboratório resolve

Requisito declaradotoda resposta sobre política tem de citar o trecho exato que a fundamenta, e a taxa de acerto tem de ser medida contra um conjunto de perguntas com resposta conhecida

Hipótese declaradaa fração de perguntas específicas é pequena, mas cada resposta errada carrega risco financeiro ou de conformidade — é o que justifica medir acerto, não confiar na fluência do texto

Ao final você temum RAG respondendo com trecho citável, com taxa de acerto medida antes (LLM direto) e depois (com recuperação) contra um golden set de 40 perguntas

🚨

Resposta plausível e errada, sem fonte

Uma resposta plausível e bem escrita não é uma resposta correta, e ninguém no painel de atendimento tinha como distinguir as duas só lendo o texto. É esse o defeito que este laboratório resolve — não "o modelo erra às vezes", mas "o modelo nunca teve acesso ao documento real, e nada no fluxo avisava disso".

⚠️

O que este laboratório NÃO é

Não é sobre escolher o banco vetorial certo — as quatro opções (Knowledge Bases/OpenSearch, OpenSearch provisionado, S3 Vectors, Aurora pgvector) são comparadas na mesma base de conhecimento pelo L84. Não é sobre melhorar a recuperação com busca híbrida e reranking — isso é o L85. Não é sobre guardrails como controle de segurança — isso é o L86, e a distinção entre "filtro na saída" e "controle de verdade" importa. Este laboratório prova a forma mínima que funciona: recuperar antes de gerar, citar a fonte, e medir a taxa de acerto com um número — não com a sensação de que "agora parece melhor".

O que você vai conseguir fazer

Objetivos verificáveis: cada um se prova com um comando ou uma medição na seção de implantação, não com a sensação de ter entendido RAG.

Medir a taxa de acerto de um LLM respondendo direto, sem nenhum trecho de documento recuperado.
Publicar os documentos reais da Cadência (política de devolução, garantia, frete e catálogo por loja) numa base de conhecimento gerenciada, com chunking configurado.
Configurar a ingestão que transforma cada documento em trechos, embeddings e um índice vetorial, sem escrever o pipeline de sincronização à mão.
Fazer uma consulta em C#/.NET 8 que devolve resposta com o trecho exato citado, não um resumo sem fonte.
Construir um golden set de perguntas com resposta oficial conhecida, e medir a taxa de acerto do sistema com RAG contra ele.
Explicar por que RAG resolve o problema de conhecimento desatualizado sem re-treinar o modelo.
Diagnosticar um erro residual do RAG e dizer se a causa é chunking, recuperação ou documento ausente/duplicado.
Restringir a chamada ao modelo e à base de conhecimento por IAM, com o ARN específico do recurso, não `"Resource": "*"`.

O que a certificação cobra disto

Conceito	Certificação	Como aparece aqui	O que dominar
RAG (Retrieval-Augmented Generation)	AIF-C01, MLA-C01	LLM direto e com Knowledge Bases, medidos lado a lado no mesmo golden set	por que RAG resolve conhecimento desatualizado sem re-treinar o modelo
Chunking (estratégia de divisão de documento)	MLA-C01	tamanho fixo com sobreposição, calibrado para não cortar uma tabela ao meio	o trade-off entre trecho pequeno (preciso, pouco contexto) e grande (contexto, impreciso)
Embedding e busca por similaridade	AIF-C01, MLA-C01	a Knowledge Base gera o embedding e indexa no OpenSearch Serverless	embedding é vetor; busca vetorial encontra sentido, não palavra exata
Atribuição / citação (grounding)	AIF-C01	RetrieveAndGenerate devolve o trecho e a fonte usados para gerar cada resposta	resposta sem fonte rastreável não é confiável em domínio regulado
Bedrock Knowledge Bases (RAG gerenciado)	AIF-C01, MLA-C01	ingestão, chunking, embedding e indexação geridos pelo serviço, sem servidor próprio	a diferença entre "gerenciado" (este módulo) e "eu opero o índice" (L84)
Alucinação e mitigação	AIF-C01	medida diretamente: taxa de acerto do golden set antes e depois do RAG	RAG não elimina alucinação sozinho — reduz drasticamente quando o dado existe no acervo

ConceitoRAG (Retrieval-Augmented Generation)

CertificaçãoAIF-C01, MLA-C01

Como aparece aquiLLM direto e com Knowledge Bases, medidos lado a lado no mesmo golden set

O que dominarpor que RAG resolve conhecimento desatualizado sem re-treinar o modelo

ConceitoChunking (estratégia de divisão de documento)

CertificaçãoMLA-C01

Como aparece aquitamanho fixo com sobreposição, calibrado para não cortar uma tabela ao meio

O que dominaro trade-off entre trecho pequeno (preciso, pouco contexto) e grande (contexto, impreciso)

ConceitoEmbedding e busca por similaridade

CertificaçãoAIF-C01, MLA-C01

Como aparece aquia Knowledge Base gera o embedding e indexa no OpenSearch Serverless

O que dominarembedding é vetor; busca vetorial encontra sentido, não palavra exata

ConceitoAtribuição / citação (grounding)

CertificaçãoAIF-C01

Como aparece aquiRetrieveAndGenerate devolve o trecho e a fonte usados para gerar cada resposta

O que dominarresposta sem fonte rastreável não é confiável em domínio regulado

ConceitoBedrock Knowledge Bases (RAG gerenciado)

CertificaçãoAIF-C01, MLA-C01

Como aparece aquiingestão, chunking, embedding e indexação geridos pelo serviço, sem servidor próprio

O que dominara diferença entre "gerenciado" (este módulo) e "eu opero o índice" (L84)

ConceitoAlucinação e mitigação

CertificaçãoAIF-C01

Como aparece aquimedida diretamente: taxa de acerto do golden set antes e depois do RAG

O que dominarRAG não elimina alucinação sozinho — reduz drasticamente quando o dado existe no acervo

💡

Onde isto costuma ser cobrado errado

A pergunta clássica descreve um chatbot que responde bem em teste e erra em produção sobre um fato específico da empresa, e pede a causa. A resposta esperada não é "o modelo é ruim" nem "falta prompt engineering" — é que o modelo nunca teve o documento no contexto. O erro de raciocínio mais comum é tratar "o modelo é treinado com muito texto" como sinônimo de "o modelo tem acesso ao documento da minha empresa": são coisas diferentes, e só a segunda resolve o problema.

Requisitos, e como cada um muda o desenho

Requisito não funcional que não vira uma linha de configuração é intenção. A coluna da direita é onde cada um deixou marca no Terraform, no prompt ou no pipeline de ingestão.

Requisito	Valor declarado	O que ele decide no desenho
Resposta cita o trecho exato que a fundamenta	obrigatório	RetrieveAndGenerate com citações habilitadas; sem citação, a resposta não é mostrada ao atendente como sugestão pronta
Pergunta fora do que os documentos cobrem não vira resposta inventada	obrigatório	prompt de fundamentação instrui "responda só com o contexto recuperado; sem trecho suficiente, diga que não encontrou"
Taxa de acerto medida, não estimada	golden set de 40 perguntas com resposta oficial	suíte de avaliação roda contra o mesmo conjunto antes e depois de qualquer mudança de prompt ou chunking
Resposta cabe no tempo de um atendimento ao vivo	até 3 s	orçamento de latência somando busca vetorial e geração, medido e com margem
Documento alterado pelo jurídico aparece na resposta em tempo razoável	algumas horas, não dias	job de ingestão disparado por evento de escrita no S3, não reingestão agendada do acervo inteiro
Trecho recuperado não pode vir cortado no meio de uma tabela	obrigatório	chunking de tamanho fixo com sobreposição, calibrado pela maior tabela do acervo
Cada resposta permite auditoria de qual trecho foi usado	obrigatório	log estruturado com id do documento e do trecho citado, publicado no CloudWatch
Chamada ao modelo e à base de conhecimento restrita à aplicação de atendimento	segurança	IAM role com `bedrock:InvokeModel`/`bedrock:Retrieve` restrito ao ARN do modelo e da knowledge base específicos

RequisitoResposta cita o trecho exato que a fundamenta

Valor declaradoobrigatório

O que ele decide no desenhoRetrieveAndGenerate com citações habilitadas; sem citação, a resposta não é mostrada ao atendente como sugestão pronta

RequisitoPergunta fora do que os documentos cobrem não vira resposta inventada

Valor declaradoobrigatório

O que ele decide no desenhoprompt de fundamentação instrui "responda só com o contexto recuperado; sem trecho suficiente, diga que não encontrou"

RequisitoTaxa de acerto medida, não estimada

Valor declaradogolden set de 40 perguntas com resposta oficial

O que ele decide no desenhosuíte de avaliação roda contra o mesmo conjunto antes e depois de qualquer mudança de prompt ou chunking

RequisitoResposta cabe no tempo de um atendimento ao vivo

Valor declaradoaté 3 s

O que ele decide no desenhoorçamento de latência somando busca vetorial e geração, medido e com margem

RequisitoDocumento alterado pelo jurídico aparece na resposta em tempo razoável

Valor declaradoalgumas horas, não dias

O que ele decide no desenhojob de ingestão disparado por evento de escrita no S3, não reingestão agendada do acervo inteiro

RequisitoTrecho recuperado não pode vir cortado no meio de uma tabela

Valor declaradoobrigatório

O que ele decide no desenhochunking de tamanho fixo com sobreposição, calibrado pela maior tabela do acervo

RequisitoCada resposta permite auditoria de qual trecho foi usado

Valor declaradoobrigatório

O que ele decide no desenholog estruturado com id do documento e do trecho citado, publicado no CloudWatch

RequisitoChamada ao modelo e à base de conhecimento restrita à aplicação de atendimento

Valor declaradosegurança

O que ele decide no desenhoIAM role com `bedrock:InvokeModel`/`bedrock:Retrieve` restrito ao ARN do modelo e da knowledge base específicos

Arquitetura mínima: o modelo respondendo sem nenhum trecho recuperado

Este é exatamente o desenho que a Cadência tem hoje — não uma versão simplificada de propósito. Ele é implantável de verdade, responde em menos de um segundo, e o defeito só aparece quando a pergunta exige um fato que só existe dentro da empresa.

O modelo responde com o que aprendeu no treino — nunca com o que a Cadência escreveu

Central de atendimento

Atendente da Cadênciadigita a pergunta do cliente e vê a sugestão pronta para copiar, sem indicação de incerteza

Aplicação

API do painel de atendimentoúnico ponto de entrada da pergunta; não sabe nem precisa saber que não há recuperação

Função "sugerir-resposta" (.NET 8)monta o prompt só com a pergunta do atendente, sem buscar nada antes

Modelo, sem contexto nenhum

Bedrock — Clauderesponde com o padrão mais provável do treino; não tem como saber que a Cadência existe

Documentos reais da Cadência — nunca consultados

S3 — política de devolução, garantia, freteescritos pelo jurídico e pela operação; nenhuma peça deste desenho lê este bucket

→ pergunta digitada em português, sem estrutura
→ encaminha a chamada HTTP
→ prompt = só a pergunta do atendente, sem nenhum trecho de documento
→ resposta fluente, sem fonte nem confiança declarada
→ sugestão que o atendente aceita na maioria das vezes

Fora da AWS
Rede e entrega
Compute
IA e machine learning
Armazenamento

É o que a Cadência tem hoje: uma chamada direta ao Bedrock, sem nenhum trecho de documento no prompt. Percorra os passos e repare no último nó: os documentos reais da política de devolução estão ali, no S3, e nenhuma seta chega até eles — é essa ausência de aresta que é o defeito, não um bug de código.

🚨

A confiança do texto não mede a correção do fato

Fluência não é acurácia, e o atendente não tinha como distinguir as duas só lendo o texto. O modelo foi treinado para completar texto de forma coerente, não para admitir incerteza — por isso a resposta errada sobre material elétrico saiu tão bem escrita quanto uma resposta certa teria saído.

Arquitetura para produção: do documento ao trecho citado

A diferença em relação à Figura 1 não é "adicionar um banco de dados" — é que a resposta passa a depender de uma busca que acontece ANTES da geração, sobre um acervo que é atualizado de forma independente da pergunta. Cada peça nova rastreia a uma linha da tabela de requisitos.

Recupera antes de gerar, e a resposta carrega a citação

Central de atendimento

Atendente da Cadênciamesma pergunta da Figura 1, para comparar diretamente o resultado

Aplicação

API do painel de atendimentomesmo ponto de entrada; o que muda é o que a função atrás dele faz

Função "responder-com-citacao" (.NET 8)chama RetrieveAndGenerate — não monta o prompt sozinha, delega busca e geração ao Bedrock

Documentos reais da Cadência

S3 — política de devolução, garantia, frete, catálogo ouroo mesmo bucket de camadas do L62; jurídico e operação escrevem aqui, sem saber do RAG

Ingestão: do documento ao vetor

Bedrock Knowledge Basesorquestra o job de ingestão a cada objeto novo ou alterado no bucket

Chunking de tamanho fixo500 tokens por trecho, 20% de sobreposição, calibrado pela maior tabela do acervo

Modelo de embedding (Titan)transforma cada trecho de texto num vetor de números que representa o sentido

Índice vetorial

OpenSearch Serverlessguarda vetor e texto original do trecho; a Knowledge Base gerencia o ciclo de vida inteiro

Geração com citação

Bedrock — RetrieveAndGeneratebusca os k trechos mais próximos da pergunta ANTES de gerar qualquer palavra da resposta

Observação e auditoria

CloudWatch — log de citaçãoregistra qual trecho e qual documento fundamentaram cada resposta, para auditoria

→ pergunta digitada em português, mesma interface da Figura 1
→ encaminha a chamada HTTP
→ evento de escrita dispara ingestão incremental do objeto alterado
→ quebra o documento em trechos com sobreposição
→ cada trecho vira um vetor de embedding
→ grava vetor e texto original do trecho no índice
→ RetrieveAndGenerate: pergunta do atendente + id da knowledge base
→ busca por similaridade: os k trechos mais próximos do vetor da pergunta
→ os k trechos recuperados, com o texto original de cada um
→ resposta gerada citando o trecho exato usado
→ resposta com citação: trecho + referência ao documento de origem
→ loga o id do trecho citado em cada resposta

Fora da AWS
Rede e entrega
Compute
Armazenamento
IA e machine learning
Conceito de arquitetura
Analytics
Gestão e governança

A mesma pergunta, o mesmo atendente — o que muda é tudo entre a API e a resposta. Cada peça nova rastreia a um requisito da tabela: o pipeline de ingestão existe porque o documento tem de virar trecho buscável; o índice vetorial existe porque a busca precisa achar sentido, não palavra exata; e a chamada ao modelo agora inclui os trechos recuperados — é essa inclusão, não o modelo em si, que produz a citação.

ƒ O orçamento de 3 s do atendimento tem de caber a busca e a geração juntas

latencia_total ≈ latencia_busca_vetorial + latencia_geracao_com_contexto

latencia_busca_vetorial

≈80–150 ms, no índice OpenSearch Serverless

cresce pouco com o tamanho do acervo porque a busca é aproximada (ANN) sobre os k mais próximos, não uma varredura de tudo.

k (trechos recuperados)

3 a 5, o padrão usado aqui

mais trechos aumentam a chance de achar a resposta certa, mas também aumentam o prompt e a chance de o modelo se confundir entre trechos — o ajuste fino disso é o assunto do L85.

latencia_geracao_com_contexto

≈1,3–1,5 s, Claude com os trechos no prompt

maior que a chamada direta da Figura 1 porque o prompt cresce com os trechos recuperados, e o modelo gera texto que nomeia a fonte.

✅

O que a citação entrega, que fluência nunca entregou

O ganho que mais importa não é a velocidade — é que a resposta passa a ter algo que o atendente pode CONFERIR: um trecho exato, de um documento real, que ele pode abrir e ler antes de repassar ao cliente. Isso não existia na versão mínima; e não é o modelo que mudou, é o fato de ele agora ter algo real para citar.

Como funciona, ponta a ponta

🗺️ Do documento no S3 à resposta citada na tela do atendente

1. Documento novo ou alterado chega ao S3O jurídico sobe uma versão nova da política de devolução, ou o job do L62 atualiza o catálogo ouro por loja. Nenhum dos dois sabe que existe um RAG consumindo este bucket.

2. O evento de escrita dispara a ingestão da Knowledge BaseA Knowledge Base detecta o objeto novo e inicia um job de ingestão incremental — processa só o que mudou, não o acervo inteiro de novo.

3. O documento é dividido em trechos com sobreposição500 tokens por trecho, 20% de sobreposição, para que uma tabela de garantia por categoria não seja cortada no meio de uma linha.

4. Cada trecho vira um vetor de embedding e entra no índiceO modelo de embedding transforma o texto num vetor de números; o OpenSearch Serverless grava o vetor junto do texto original do trecho.

5. Atendente pergunta; a aplicação chama RetrieveAndGenerateA função .NET 8 não monta o prompt sozinha — chama a API do Bedrock que já orquestra busca e geração numa única requisição.

6. O modelo busca antes de gerar qualquer palavraA pergunta vira vetor, o índice devolve os k trechos mais próximos, e só então pergunta e trechos entram juntos no prompt do modelo.

7. A resposta chega com a citação, não com um resumo sem fonteCada frase gerada aponta para o trecho e o documento que a sustentam; o atendente pode abrir o link e ver o texto original antes de repassar ao cliente.

O log abaixo é o que a aplicação escreve no CloudWatch a cada resposta gerada — é o material bruto da auditoria: qual trecho, de qual documento, fundamentou aquela resposta específica.

resposta-com-citacao.json

{
  "evento": "RESPOSTA_COM_CITACAO_GERADA",
  "timestamp": "2026-08-08T14:02:11.340Z",
  "pergunta": "Qual a política de devolução de material elétrico?",
  "knowledgeBaseId": "KB7F3A9C1D",
  "trechosRecuperados": 3,
  "trechoCitado": {
    "documento": "s3://cadencia-documentos-atendimento/politicas/devolucao-material-eletrico.md",
    "chunkId": "devolucao-material-eletrico.md#chunk-4",
    "texto": "Material elétrico: devolução em até 7 dias corridos, mediante nota fiscal e produto lacrado, por exigência de segurança elétrica dos fornecedores."
  },
  "latenciaMs": 1487,
  "_comentario": "chunkId e documento sao o que a auditoria confere depois — nao o texto da resposta gerada, que pode parafrasear o trecho."
}

💡

O caminho de "não encontrei" é parte do desenho, não uma falha dele

Quando os k trechos recuperados não têm relação suficiente com a pergunta, o prompt de fundamentação instrui o modelo a responder que não encontrou a informação — não a completar com conhecimento geral. Esse caminho aparece medido na seção de prova adiante: é uma resposta CORRETA quando a pergunta realmente não tem resposta no acervo.

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

📋 A central de atendimento da Cadência precisa responder perguntas sobre política em linguagem natural, sem inventar, com um jeito de provar taxa de acerto para o jurídico — e uma equipe pequena, sem time dedicado a operar banco vetorial.

✓ Bedrock Knowledge Bases (RAG gerenciado) sobre S3, com OpenSearch Serverless como índice, medido contra um golden set de 40 perguntas com resposta oficial

Knowledge Bases resolve ingestão, chunking, embedding e indexação como serviço gerenciado — sem exigir que a equipe opere um pipeline próprio. RetrieveAndGenerate resolve a exigência de "nunca inventar" ao gerar só a partir de trechos recuperados, com citação obrigatória. E o golden set resolve a exigência do jurídico de um número comparável, em vez de "parece melhor".

Alt: Manter o LLM direto e só melhorar o prompt ("responda com precisão") — prompt engineering não dá acesso a um documento que o modelo nunca viu; a taxa de acerto sobe pouco, porque o problema é falta de CONTEXTO, não de instrução — e é exatamente o que a seção de prova mede.

Alt: Fine-tuning do modelo com os documentos da Cadência — a política de devolução é revisada pelo jurídico com frequência; re-treinar o modelo a cada alteração é caro e lento — RAG só reingere o arquivo alterado, em minutos.

Alt: Operar o próprio banco vetorial (Aurora com pgvector, por exemplo) — ganha controle fino sobre o índice, perde velocidade de entrega — é exatamente a comparação de quatro opções que o L84 aprofunda; aqui o objetivo é provar que RAG funciona, não otimizar o banco vetorial ainda.

Alt: Amazon Kendra para a busca, orquestrando a geração separadamente — Kendra é ótimo para busca empresarial, mas não entrega geração de resposta com citação no mesmo fluxo — exigiria orquestrar busca e chamada ao modelo manualmente, reconstruindo o que Knowledge Bases já entrega pronto.

Decisão	Escolha	Alternativas	Motivo	O que se perde
Onde indexar o vetor	OpenSearch Serverless, gerenciado pela Knowledge Base	Aurora pgvector; S3 Vectors; OpenSearch provisionado	zero servidor para operar, e a Knowledge Base já cuida do ciclo de vida do índice	menos controle sobre o algoritmo de busca e sobre custo por hora fixo — é a comparação do L84
Tamanho do chunk	500 tokens, 20% de sobreposição	chunk por documento inteiro; chunk semântico por seção	a maior tabela de garantia por categoria cabe inteira num chunk, sem cortar linha	trecho maior às vezes traz contexto irrelevante junto com o relevante
O que fazer sem trecho relevante	responder "não encontrei isso nos documentos"	deixar o modelo completar com o que sabe do treino	evita fabricar resposta sobre o que não está no acervo	o atendente recebe "não sei" às vezes onde uma busca manual mais paciente acharia a resposta
Frequência de reingestão	job disparado por evento de escrita no S3	reingestão agendada a cada N horas	documento alterado pelo jurídico aparece em minutos, não no fim do dia	evento perdido, raro, atrasa a atualização até a próxima escrita disparar de novo
Onde a citação é validada	golden set de 40 perguntas com resposta conhecida, revisado por humano	confiar na taxa de satisfação do atendente	dá um número comparável entre versões de prompt e de chunking	40 perguntas não cobrem toda pergunta possível — é amostra, não garantia total

DecisãoOnde indexar o vetor

EscolhaOpenSearch Serverless, gerenciado pela Knowledge Base

AlternativasAurora pgvector; S3 Vectors; OpenSearch provisionado

Motivozero servidor para operar, e a Knowledge Base já cuida do ciclo de vida do índice

O que se perdemenos controle sobre o algoritmo de busca e sobre custo por hora fixo — é a comparação do L84

DecisãoTamanho do chunk

Escolha500 tokens, 20% de sobreposição

Alternativaschunk por documento inteiro; chunk semântico por seção

Motivoa maior tabela de garantia por categoria cabe inteira num chunk, sem cortar linha

O que se perdetrecho maior às vezes traz contexto irrelevante junto com o relevante

DecisãoO que fazer sem trecho relevante

Escolharesponder "não encontrei isso nos documentos"

Alternativasdeixar o modelo completar com o que sabe do treino

Motivoevita fabricar resposta sobre o que não está no acervo

O que se perdeo atendente recebe "não sei" às vezes onde uma busca manual mais paciente acharia a resposta

DecisãoFrequência de reingestão

Escolhajob disparado por evento de escrita no S3

Alternativasreingestão agendada a cada N horas

Motivodocumento alterado pelo jurídico aparece em minutos, não no fim do dia

O que se perdeevento perdido, raro, atrasa a atualização até a próxima escrita disparar de novo

DecisãoOnde a citação é validada

Escolhagolden set de 40 perguntas com resposta conhecida, revisado por humano

Alternativasconfiar na taxa de satisfação do atendente

Motivodá um número comparável entre versões de prompt e de chunking

O que se perde40 perguntas não cobrem toda pergunta possível — é amostra, não garantia total

⚠️

A dívida que este laboratório não paga

O golden set de 40 perguntas cobre política de devolução, garantia e frete — não cobre negociação de preço, disponibilidade de estoque em tempo real, nem dúvida sobre pedido específico de um cliente. Este laboratório não estende o RAG para esses casos: cada um tem uma fonte de dado diferente (o pedido vive no RDS do ERP, não em documento), e misturar os dois no mesmo acervo é o antipadrão que a tabela adiante nomeia.

Construir: a base de conhecimento (S3 → chunking → embedding → índice)

O bucket é o mesmo tipo de fonte que o L62 já organiza em camadas: aqui ele guarda a política de devolução, a política de garantia, a política de frete e um export em texto plano do catálogo ouro por loja. A Knowledge Base é quem transforma isso em algo buscável — sem que o jurídico precise saber o que é chunking.

base-conhecimento.tf

# base-conhecimento.tf — bucket de documentos, índice vetorial e a Knowledge Base
# que os conecta. Confira a versão do provider AWS antes de aplicar: os recursos
# aws_bedrockagent_* e aws_opensearchserverless_* mudaram de shape mais de uma vez
# desde que Knowledge Bases foi lançado.

resource "aws_s3_bucket" "documentos_atendimento" {
  bucket = "cadencia-documentos-atendimento"
  tags = { squad = "atendimento", projeto = "rag-politica", lab = "L83" }
}

resource "aws_s3_bucket_versioning" "documentos_atendimento" {
  bucket = aws_s3_bucket.documentos_atendimento.id
  versioning_configuration { status = "Enabled" }
  # versionamento evita que uma sobrescrita do jurídico apague, sem histórico, a
  # versão anterior de uma política — o mesmo cuidado que o L62 já aplica ao lake.
}

# ── Índice vetorial: OpenSearch Serverless, com as duas políticas que ele exige ──
resource "aws_opensearchserverless_security_policy" "criptografia" {
  name = "cadencia-rag-criptografia"
  type = "encryption"
  policy = jsonencode({
    Rules = [{ ResourceType = "collection", Resource = ["collection/cadencia-rag-*"] }]
    AWSOwnedKey = true
  })
}

resource "aws_opensearchserverless_security_policy" "rede" {
  name = "cadencia-rag-rede"
  type = "network"
  policy = jsonencode([{
    Rules = [{ ResourceType = "collection", Resource = ["collection/cadencia-rag-*"] }]
    AllowFromPublic = false
    SourceVPCEs = [aws_ec2_managed_prefix_list.acesso_kb.id]
  }])
}

resource "aws_opensearchserverless_collection" "base_conhecimento" {
  name = "cadencia-rag-politica-atendimento"
  type = "VECTORSEARCH"
  depends_on = [
    aws_opensearchserverless_security_policy.criptografia,
    aws_opensearchserverless_security_policy.rede,
  ]
}

# ── Papel que a Knowledge Base assume para ler o S3 e chamar o modelo de embedding ──
resource "aws_iam_role" "knowledge_base" {
  name = "cadencia-rag-knowledge-base-role"
  assume_role_policy = data.aws_iam_policy_document.confianca_bedrock.json
}

resource "aws_iam_role_policy" "kb_acesso_restrito" {
  role = aws_iam_role.knowledge_base.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["s3:GetObject", "s3:ListBucket"]
        # Resource especifico do bucket de documentos — nao "arn:aws:s3:::*".
        Resource = [
          aws_s3_bucket.documentos_atendimento.arn,
          "${aws_s3_bucket.documentos_atendimento.arn}/*",
        ]
      },
      {
        Effect = "Allow"
        Action = ["bedrock:InvokeModel"]
        # Restrito ao MODELO DE EMBEDDING, nao a bedrock:* — a Knowledge Base nunca
        # gera texto de resposta, so vetoriza.
        Resource = ["arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0"]
      },
      {
        Effect = "Allow"
        Action = ["aoss:APIAccessAll"]
        Resource = [aws_opensearchserverless_collection.base_conhecimento.arn]
      },
    ]
  })
}

resource "aws_bedrockagent_knowledge_base" "politica_atendimento" {
  name     = "cadencia-politica-atendimento"
  role_arn = aws_iam_role.knowledge_base.arn

  knowledge_base_configuration {
    type = "VECTOR"
    vector_knowledge_base_configuration {
      embedding_model_arn = "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0"
    }
  }

  storage_configuration {
    type = "OPENSEARCH_SERVERLESS"
    opensearch_serverless_configuration {
      collection_arn    = aws_opensearchserverless_collection.base_conhecimento.arn
      vector_index_name = "cadencia-politica-index"
      field_mapping {
        vector_field   = "embedding"
        text_field     = "texto"
        metadata_field = "metadados"
      }
    }
  }
}

resource "aws_bedrockagent_data_source" "documentos" {
  knowledge_base_id = aws_bedrockagent_knowledge_base.politica_atendimento.id
  name               = "documentos-juridico-e-catalogo"

  data_source_configuration {
    type = "S3"
    s3_configuration { bucket_arn = aws_s3_bucket.documentos_atendimento.arn }
  }

  vector_ingestion_configuration {
    chunking_configuration {
      chunking_strategy = "FIXED_SIZE"
      fixed_size_chunking_configuration {
        max_tokens         = 500
        overlap_percentage = 20
        # 20% de sobreposicao e o numero calibrado pela maior tabela de garantia
        # por categoria do acervo — ver a secao de prova para o efeito medido.
      }
    }
  }
}

⚠️

A primeira ingestão não é o padrão de operação

O job de ingestão inicial processa o acervo inteiro e pode levar minutos, dependendo do volume de documentos. Alterações pontuais depois disso são incrementais — só o objeto que mudou é reprocessado, não o bucket inteiro de novo. Confirme isso no console: uma ingestão completa disparada a cada pequena edição é o antipadrão que a seção de anti-padrões nomeia adiante.

Construir: a consulta com citação (C#/.NET 8)

A função de atendimento troca uma chamada de `InvokeModel` — a que o tema do L81 mostra — por uma chamada de `RetrieveAndGenerate`. A aplicação não decide mais o que buscar nem monta o prompt com o contexto: delega as duas coisas numa única requisição gerenciada, e recebe de volta a resposta já acompanhada da citação.

ServicoRespostaComCitacao.cs

// ServicoRespostaComCitacao.cs — chama RetrieveAndGenerate em vez de InvokeModel
// puro. A diferenca estrutural em relacao ao cliente do L81 nao e o SDK, e o que
// a chamada FAZ: busca antes de gerar, e devolve a fonte junto da resposta.

public class ServicoRespostaComCitacao
{
    private readonly AmazonBedrockAgentRuntimeClient _cliente = new();

    private const string KnowledgeBaseId = "KB7F3A9C1D";
    private const string ModeloArn =
        "arn:aws:bedrock:us-east-1:111122223333:inference-profile/us.anthropic.claude-sonnet-4-20250514-v1:0";

    // Instrucao de fundamentacao: o unico lugar do sistema que probe o modelo de
    // completar com conhecimento geral quando o contexto recuperado nao basta.
    private const string InstrucaoDeFundamentacao =
        "Responda SOMENTE com base nos trechos em $search_results$. " +
        "Se os trechos nao contiverem a resposta, diga que nao encontrou essa " +
        "informacao nos documentos da Cadência — nunca complete com conhecimento geral.";

    public async Task<RespostaComCitacao> ResponderAsync(string pergunta)
    {
        var pedido = new RetrieveAndGenerateRequest
        {
            Input = new RetrieveAndGenerateInput { Text = pergunta },
            RetrieveAndGenerateConfiguration = new RetrieveAndGenerateConfiguration
            {
                Type = RetrieveAndGenerateType.KNOWLEDGE_BASE,
                KnowledgeBaseConfiguration = new KnowledgeBaseRetrieveAndGenerateConfiguration
                {
                    KnowledgeBaseId = KnowledgeBaseId,
                    ModelArn = ModeloArn,
                    GenerationConfiguration = new GenerationConfiguration
                    {
                        PromptTemplate = new PromptTemplate { TextPromptTemplate = InstrucaoDeFundamentacao },
                    },
                },
            },
        };

        var resposta = await _cliente.RetrieveAndGenerateAsync(pedido);

        // Cada citacao aponta pro trecho (chunk) e pro documento de origem — e isso
        // que vira o link clicavel na tela do atendente, nao um resumo sem fonte.
        var citacoes = resposta.Citations
            .SelectMany(c => c.RetrievedReferences)
            .Select(r => new Citacao(r.Content.Text, r.Location.S3Location.Uri))
            .ToList();

        if (citacoes.Count == 0)
        {
            // Sem trecho recuperado, a resposta NAO sai como sugestao pronta para
            // copiar — vira "nao encontrei isso nos documentos", nunca uma invencao.
            return RespostaComCitacao.SemFonte();
        }

        return new RespostaComCitacao(resposta.Output.Text, citacoes);
    }
}

O ponto que mais separa este cliente do da versão mínima não é a chamada em si — é o que acontece quando `citacoes.Count == 0`. Na versão mínima, o modelo sempre responde alguma coisa. Aqui, a ausência de trecho recuperado é um caminho de código explícito, não uma exceção não tratada.

Segurança: quem pode chamar o modelo e a base

Duas roles distintas participam deste desenho, com privilégio calculado pelo uso real de cada uma — o mesmo princípio do L41, aplicado a Bedrock em vez de a um banco. A role da Knowledge Base (seção de construção anterior) só lê o bucket de documentos e só invoca o modelo de embedding. A role da função de atendimento, abaixo, só invoca o modelo de geração e só consulta ESTA knowledge base — nunca `bedrock:*`, e nunca uma base de conhecimento de outro time.

policy-funcao-atendimento.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ChamarModeloDeGeracaoRestrito",
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:Retrieve", "bedrock:RetrieveAndGenerate"],
      "Resource": [
        "arn:aws:bedrock:us-east-1:111122223333:inference-profile/us.anthropic.claude-sonnet-4-20250514-v1:0",
        "arn:aws:bedrock:us-east-1:111122223333:knowledge-base/KB7F3A9C1D"
      ]
    },
    {
      "Sid": "SemAcessoAOutraKnowledgeBase",
      "Effect": "Deny",
      "Action": ["bedrock:Retrieve", "bedrock:RetrieveAndGenerate"],
      "NotResource": "arn:aws:bedrock:us-east-1:111122223333:knowledge-base/KB7F3A9C1D"
    }
  ]
}

💡

Por que o Deny explícito, e não só a ausência de Allow

A instrução negada explicitamente (`NotResource`) importa mais do que parece: sem ela, a mesma credencial da função de atendimento poderia, no futuro, ser reusada para consultar uma outra knowledge base criada por outro time — por exemplo, uma que indexasse dado de RH. `Deny` explícito fecha essa porta mesmo que uma policy futura, mal escrita, tente abri-la — `Deny` sempre vence sobre `Allow` na avaliação do IAM.

Implantar, e provar com número

A prova não é "a resposta parece melhor" — é rodar o mesmo conjunto de 40 perguntas duas vezes, contra os dois desenhos, e contar.

prova.sh

# prova.sh — roda o MESMO golden set de 40 perguntas contra os dois desenhos, e
# conta. Nenhuma conclusao aqui vem de "a resposta parece melhor".

GOLDEN_SET=golden-set-politica-cadencia.jsonl  # 40 linhas: {pergunta, resposta_oficial}

# ── Rodada 1: LLM direto (Figura 1), sem nenhuma recuperacao ─────────────────
python3 avaliar.py --endpoint sugerir-resposta --golden "$GOLDEN_SET" \
  --saida resultado-sem-rag.json
# Resultado medido: 14 de 40 corretas (35,0%); 0 de 40 com trecho citavel;
# latencia media 700 ms

# ── Rodada 2: RAG (Figura 2), com recuperacao e citacao ──────────────────────
python3 avaliar.py --endpoint responder-com-citacao --golden "$GOLDEN_SET" \
  --saida resultado-com-rag.json
# Resultado medido: 37 de 40 corretas (92,5%); 37 de 40 com trecho citavel;
# latencia p95 1,6 s

# ── Diagnostico dos 3 erros residuais ─────────────────────────────────────────
jq '.[] | select(.correto == false)' resultado-com-rag.json
# 2 casos: tabela de garantia cortada no limite do chunk — o trecho recuperado
#          continha a categoria, mas nao o prazo, que ficava no chunk seguinte.
# 1 caso:  duas versoes da politica de frete no bucket (a antiga nao tinha sido
#          arquivada) — a busca recuperou um trecho da versao errada.

Prova	Antes — LLM direto (Figura 1)	Depois — com RAG (Figura 2)	O que mudou
Taxa de acerto no golden set (40 perguntas)	14/40 — 35,0%	37/40 — 92,5%	a recuperação deu ao modelo o trecho que ele nunca teve no treino
Respostas com trecho citável	0/40 — 0%	37/40 — 92,5%	RetrieveAndGenerate só gera resposta a partir de trecho recuperado
Latência p95 por pergunta	≈700 ms	≈1,6 s	a busca soma tempo, mas ainda cabe no orçamento de 3 s declarado para o atendimento
Respostas que assumem "não sei" quando devia	0/40 (sempre respondia algo)	1/40 (é um acerto)	RAG pode recusar responder quando o acervo não cobre; o LLM direto nunca recusava
Erros residuais, e a causa de cada um	—	2 de tabela cortada no limite do chunk, 1 de documento duplicado no bucket	os 3 apontam para decisão de chunking e higiene do acervo — não para falha do padrão RAG

ProvaTaxa de acerto no golden set (40 perguntas)

Antes — LLM direto (Figura 1)14/40 — 35,0%

Depois — com RAG (Figura 2)37/40 — 92,5%

O que mudoua recuperação deu ao modelo o trecho que ele nunca teve no treino

ProvaRespostas com trecho citável

Antes — LLM direto (Figura 1)0/40 — 0%

Depois — com RAG (Figura 2)37/40 — 92,5%

O que mudouRetrieveAndGenerate só gera resposta a partir de trecho recuperado

ProvaLatência p95 por pergunta

Antes — LLM direto (Figura 1)≈700 ms

Depois — com RAG (Figura 2)≈1,6 s

O que mudoua busca soma tempo, mas ainda cabe no orçamento de 3 s declarado para o atendimento

ProvaRespostas que assumem "não sei" quando devia

Antes — LLM direto (Figura 1)0/40 (sempre respondia algo)

Depois — com RAG (Figura 2)1/40 (é um acerto)

O que mudouRAG pode recusar responder quando o acervo não cobre; o LLM direto nunca recusava

ProvaErros residuais, e a causa de cada um

Antes — LLM direto (Figura 1)—

Depois — com RAG (Figura 2)2 de tabela cortada no limite do chunk, 1 de documento duplicado no bucket

O que mudouos 3 apontam para decisão de chunking e higiene do acervo — não para falha do padrão RAG

⚠️

A taxa de acerto aponta ONDE olhar, não conserta sozinha

Os 3 erros residuais não são aleatórios, e por isso são corrigíveis: os 2 casos de tabela cortada pedem um chunk maior ou uma estratégia por seção nesse documento específico (assunto do L84/L85); o caso de documento duplicado pede disciplina de arquivamento no bucket, não mudança de arquitetura. Nenhum dos três é resolvido re-rodando o mesmo teste — cada um exige uma correção diferente, identificada pelo diagnóstico, não pela taxa agregada sozinha.

Quebrar de propósito: quatro falhas, e a que reintroduz o problema original

92,5% de acerto contra o golden set é o resultado do caminho feliz. As quatro injeções abaixo produzem resposta errada COM citação — que é pior que resposta errada sem citação, porque a citação é justamente o que faz o atendente confiar.

Falha injetada	Como injetar	Sintoma enganoso	Diagnóstico correto
Documento removido do bucket, índice não sincronizado	Apagar a política de garantia do S3 e perguntar sobre garantia sem reingerir	A resposta vem completa, com citação apontando para um arquivo que não existe mais. Nada no log indica problema	O índice vetorial é uma CÓPIA do acervo, não uma visão dele. Enquanto a ingestão não roda, o índice responde por um mundo que já mudou. O sintoma inverso é o perigoso: documento ATUALIZADO e não reingerido faz o sistema citar, com fonte e confiança, a política revogada. Toda alteração de documento precisa disparar reingestão, e o painel precisa mostrar a idade da última sincronização
Pergunta cuja resposta não está no acervo	Perguntar sobre uma política que a Cadência nunca escreveu — férias, por exemplo	O modelo responde bem, de forma plausível, sobre política de férias de e-commerce em geral	É o defeito do L81 voltando por dentro do RAG. Recuperação que não encontra nada relevante ainda assim devolve os trechos MENOS distantes, e o modelo redige em cima deles ou do que sabe de treino. A defesa não é o prompt pedir para não inventar: é um piso de score de relevância abaixo do qual a aplicação responde "não encontrei" sem chamar geração nenhuma. Sem esse piso, o RAG não elimina a alucinação — só a acompanha de uma citação
Chunk cortando a tabela de prazos ao meio	Reduzir o tamanho do chunk e reingerir a política de garantia, que tem os prazos numa tabela	A resposta cita o trecho certo do documento certo. E dá o prazo errado	O trecho recuperado contém o cabeçalho da tabela e não a linha da categoria, ou a linha sem o cabeçalho que diz o que a coluna significa. A citação está correta — ela aponta para onde o modelo leu — e o conteúdo lá não sustenta a resposta. Citação prova PROVENIÊNCIA, nunca correção. É o defeito residual que o L85 reabre e diagnostica de novo com outro instrumento
Documento duplicado no acervo, em versões diferentes	Subir a política de devolução duas vezes, uma com o prazo antigo	As duas versões são recuperadas, o modelo escolhe uma, e a resposta é internamente coerente	O acervo passou a conter uma contradição, e não existe nada no desenho que detecte contradição — a recuperação otimiza semelhança com a pergunta, não consistência entre trechos. Higiene de acervo não é tarefa de arrumação: é requisito de correção. Um único documento por assunto, com versão, e ingestão que substitui em vez de acrescentar

Falha injetadaDocumento removido do bucket, índice não sincronizado

Como injetarApagar a política de garantia do S3 e perguntar sobre garantia sem reingerir

Sintoma enganosoA resposta vem completa, com citação apontando para um arquivo que não existe mais. Nada no log indica problema

Diagnóstico corretoO índice vetorial é uma CÓPIA do acervo, não uma visão dele. Enquanto a ingestão não roda, o índice responde por um mundo que já mudou. O sintoma inverso é o perigoso: documento ATUALIZADO e não reingerido faz o sistema citar, com fonte e confiança, a política revogada. Toda alteração de documento precisa disparar reingestão, e o painel precisa mostrar a idade da última sincronização

Falha injetadaPergunta cuja resposta não está no acervo

Como injetarPerguntar sobre uma política que a Cadência nunca escreveu — férias, por exemplo

Sintoma enganosoO modelo responde bem, de forma plausível, sobre política de férias de e-commerce em geral

Diagnóstico corretoÉ o defeito do L81 voltando por dentro do RAG. Recuperação que não encontra nada relevante ainda assim devolve os trechos MENOS distantes, e o modelo redige em cima deles ou do que sabe de treino. A defesa não é o prompt pedir para não inventar: é um piso de score de relevância abaixo do qual a aplicação responde "não encontrei" sem chamar geração nenhuma. Sem esse piso, o RAG não elimina a alucinação — só a acompanha de uma citação

Falha injetadaChunk cortando a tabela de prazos ao meio

Como injetarReduzir o tamanho do chunk e reingerir a política de garantia, que tem os prazos numa tabela

Sintoma enganosoA resposta cita o trecho certo do documento certo. E dá o prazo errado

Diagnóstico corretoO trecho recuperado contém o cabeçalho da tabela e não a linha da categoria, ou a linha sem o cabeçalho que diz o que a coluna significa. A citação está correta — ela aponta para onde o modelo leu — e o conteúdo lá não sustenta a resposta. Citação prova PROVENIÊNCIA, nunca correção. É o defeito residual que o L85 reabre e diagnostica de novo com outro instrumento

Falha injetadaDocumento duplicado no acervo, em versões diferentes

Como injetarSubir a política de devolução duas vezes, uma com o prazo antigo

Sintoma enganosoAs duas versões são recuperadas, o modelo escolhe uma, e a resposta é internamente coerente

Diagnóstico corretoO acervo passou a conter uma contradição, e não existe nada no desenho que detecte contradição — a recuperação otimiza semelhança com a pergunta, não consistência entre trechos. Higiene de acervo não é tarefa de arrumação: é requisito de correção. Um único documento por assunto, com versão, e ingestão que substitui em vez de acrescentar

⚠️

As quatro produzem resposta com citação

É a característica comum e o motivo de estarem juntas. A citação foi vendida internamente como a garantia de que a resposta é confiável, e ela não é isso — ela diz de onde o texto veio, não que a conclusão esteja certa. Ao apresentar este sistema a quem vai usá-lo, essa distinção precisa ser dita em voz alta, senão o atendente para de conferir exatamente porque existe citação.

Quiz rápido

Um atendente pergunta ao LLM "qual a política de devolução de material elétrico da Cadência?" e recebe uma resposta fluente e específica, mas errada. O modelo foi treinado com bilhões de documentos — por que ele não sabe a política real da Cadência?

Observabilidade: as perguntas que o painel tem de responder

Um RAG quebra de um jeito específico: continua respondendo. Não há erro 500, não há fila crescendo, não há CPU subindo. Estas são as perguntas que separam "respondendo" de "respondendo certo".

Qual a proporção de respostas SEM nenhuma citação nos últimos sete dias? É o indicador direto de recuperação vazia — e cada uma delas é uma resposta gerada do conhecimento de treino, não do acervo da Cadência.
Qual o score de relevância do melhor trecho recuperado, em distribuição? A cauda inferior dessa distribuição é o conjunto de perguntas que o acervo não cobre.
Quanto tempo faz desde a última sincronização bem-sucedida da base de conhecimento?
Quais documentos do acervo NUNCA foram recuperados em 30 dias? São peso morto no índice, ou assunto sobre o qual ninguém pergunta — e as duas conclusões mudam o que fazer.
Qual a divisão da latência entre recuperação e geração? Elas escalam por motivos diferentes e a soma esconde qual das duas piorou.
Quantas respostas o atendente editou antes de enviar ao cliente? É o único sinal de qualidade que vem de humano, e é o mais valioso do painel.

Alarme	Limiar inicial	O que ele pega
RespostasSemCitacao	acima de 5% da janela de 1 hora	recuperação devolvendo vazio — acervo incompleto, índice corrompido ou ingestão quebrada
IdadeDaSincronizacao	acima de 24 horas	documento atualizado no S3 que o índice ainda não conhece: a primeira falha injetada, detectada antes de alguém citar política revogada
ScoreMaximoBaixo	melhor trecho abaixo do piso de relevância em mais de 10% das perguntas da hora	lacuna de acervo — um assunto novo que os clientes começaram a perguntar
LatenciaRecuperacaoP95	acima do dobro da linha de base medida na implantação	degradação do índice conforme o acervo cresce, separada da latência do modelo
TaxaDeEdicaoPeloAtendente	acima da linha de base medida nas duas primeiras semanas	queda de qualidade percebida por quem usa, antes de qualquer métrica técnica mudar

AlarmeRespostasSemCitacao

Limiar inicialacima de 5% da janela de 1 hora

O que ele pegarecuperação devolvendo vazio — acervo incompleto, índice corrompido ou ingestão quebrada

AlarmeIdadeDaSincronizacao

Limiar inicialacima de 24 horas

O que ele pegadocumento atualizado no S3 que o índice ainda não conhece: a primeira falha injetada, detectada antes de alguém citar política revogada

AlarmeScoreMaximoBaixo

Limiar inicialmelhor trecho abaixo do piso de relevância em mais de 10% das perguntas da hora

O que ele pegalacuna de acervo — um assunto novo que os clientes começaram a perguntar

AlarmeLatenciaRecuperacaoP95

Limiar inicialacima do dobro da linha de base medida na implantação

O que ele pegadegradação do índice conforme o acervo cresce, separada da latência do modelo

AlarmeTaxaDeEdicaoPeloAtendente

Limiar inicialacima da linha de base medida nas duas primeiras semanas

O que ele pegaqueda de qualidade percebida por quem usa, antes de qualquer métrica técnica mudar

Escala: 1.200 perguntas por dia, 12 mil, 120 mil — e a perda de uma zona

Ordem de grandeza	O que muda no desenho	O que NÃO muda
1.200 perguntas/dia, 4 documentos (hoje)	Nada. A base gerenciada absorve isso sem tuning, e o gargalo é humano — o atendente lendo a sugestão	O piso de custo do índice vetorial, que existe desde a primeira pergunta e independe do volume
12 mil perguntas/dia, 400 documentos	A ingestão deixa de ser evento raro e vira pipeline: reingerir tudo a cada mudança passa a ser caro e lento, e a atualização precisa ser incremental. O limite de taxa do modelo de geração passa a ser sentido no pico da tarde	A forma da chamada. Recuperar-e-gerar continua sendo uma requisição, e a aplicação continua sem montar prompt
120 mil perguntas/dia, 40 mil documentos	A recuperação vira o gargalo antes da geração, e a qualidade do ranking passa a dominar a qualidade da resposta — é onde o L85 deixa de ser refinamento e vira necessidade. Cache de resposta para perguntas repetidas (L89) passa a pagar sozinho	A necessidade de piso de relevância e de higiene de acervo, que já eram obrigatórias com 4 documentos
Perda de uma zona de disponibilidade	A base de conhecimento gerenciada e o modelo continuam respondendo — são serviços regionais, não zonais. O que cai é a sua aplicação, se ela estiver em uma zona só	A resposta correta aqui é a do L01, sem novidade: tarefas em duas zonas atrás do balanceador. A camada de IA deste laboratório não acrescenta requisito zonal nenhum
Perda da região inteira	Tudo para. O índice vive numa região, e reconstruí-lo em outra leva o tempo de uma ingestão completa do acervo	É o que o L99 trata, e o número que interessa não é o RTO da aplicação — é o tempo de reingestão do acervo, que ninguém mede até precisar

Ordem de grandeza1.200 perguntas/dia, 4 documentos (hoje)

O que muda no desenhoNada. A base gerenciada absorve isso sem tuning, e o gargalo é humano — o atendente lendo a sugestão

O que NÃO mudaO piso de custo do índice vetorial, que existe desde a primeira pergunta e independe do volume

Ordem de grandeza12 mil perguntas/dia, 400 documentos

O que muda no desenhoA ingestão deixa de ser evento raro e vira pipeline: reingerir tudo a cada mudança passa a ser caro e lento, e a atualização precisa ser incremental. O limite de taxa do modelo de geração passa a ser sentido no pico da tarde

O que NÃO mudaA forma da chamada. Recuperar-e-gerar continua sendo uma requisição, e a aplicação continua sem montar prompt

Ordem de grandeza120 mil perguntas/dia, 40 mil documentos

O que muda no desenhoA recuperação vira o gargalo antes da geração, e a qualidade do ranking passa a dominar a qualidade da resposta — é onde o L85 deixa de ser refinamento e vira necessidade. Cache de resposta para perguntas repetidas (L89) passa a pagar sozinho

O que NÃO mudaA necessidade de piso de relevância e de higiene de acervo, que já eram obrigatórias com 4 documentos

Ordem de grandezaPerda de uma zona de disponibilidade

O que muda no desenhoA base de conhecimento gerenciada e o modelo continuam respondendo — são serviços regionais, não zonais. O que cai é a sua aplicação, se ela estiver em uma zona só

O que NÃO mudaA resposta correta aqui é a do L01, sem novidade: tarefas em duas zonas atrás do balanceador. A camada de IA deste laboratório não acrescenta requisito zonal nenhum

Ordem de grandezaPerda da região inteira

O que muda no desenhoTudo para. O índice vive numa região, e reconstruí-lo em outra leva o tempo de uma ingestão completa do acervo

O que NÃO mudaÉ o que o L99 trata, e o número que interessa não é o RTO da aplicação — é o tempo de reingestão do acervo, que ninguém mede até precisar

Custo: as quatro dimensões, e a que cresce sem ninguém mexer em nada

A intuição diz que RAG custa o preço do modelo. A fatura mostra quatro linhas, e a que mais surpreende não é nenhuma das duas óbvias.

ƒ Custo mensal do RAG de atendimento

mensal = (trechos_ingeridos × preço_embedding × reingestões) + (piso_do_índice_vetorial) + (perguntas × (tok_contexto + tok_pergunta) ÷ 1000 × preço_entrada) + (perguntas × tok_resposta ÷ 1000 × preço_saída)

trechos_ingeridos × preço_embedding × reingestões

Transformar documento em vetor

Barato por trecho e enganoso no total, porque o multiplicador é o número de REINGESTÕES. Reingerir o acervo inteiro a cada correção de vírgula num documento paga tudo de novo. É a dimensão que cresce por processo, não por uso.

piso_do_índice_vetorial

Manter o índice existindo

Cobra por capacidade mínima mesmo com zero pergunta no fim de semana. Para acervo pequeno com tráfego irregular, costuma ser a maior linha da conta — e é a que o L84 mede lado a lado entre quatro backends.

tok_contexto

Os trechos recuperados entrando no prompt

O termo silencioso. Cada pergunta reenvia alguns milhares de tokens de contexto, e é aqui que quase todo o custo de token de um RAG mora — não na pergunta do usuário, que tem dezenas de tokens. Recuperar cinco trechos em vez de três muda a fatura proporcionalmente.

tok_resposta

O que o modelo escreve

Cobrado mais caro por token que a entrada, e muito menor em volume. Limitar o tamanho da resposta ajuda a experiência antes de ajudar a fatura.

Cenário	O que domina	O que ninguém nota
Protótipo — 4 documentos, 50 perguntas por dia	O piso do índice vetorial, sozinho, é praticamente a conta inteira	Um RAG parado custa quase o mesmo que um RAG em uso nesta escala. Piloto esquecido ligado é a forma mais comum de desperdício desta banda
Produção — 1.200 perguntas por dia	O contexto recuperado passa a dominar: milhares de tokens de entrada, 1.200 vezes por dia	Reduzir de cinco para três trechos recuperados corta a maior linha da conta em quase 40% — e só é seguro fazer isso medindo o acerto contra o golden set, que é exatamente o instrumento que este laboratório constrói
Acervo vivo — jurídico revisando política toda semana	A reingestão passa a competir com o uso	Reingestão completa semanal de um acervo grande pode custar mais que as perguntas do mês. Ingestão incremental não é otimização prematura aqui — é a diferença entre custo proporcional ao acervo e custo proporcional ao acervo vezes a frequência de revisão

CenárioProtótipo — 4 documentos, 50 perguntas por dia

O que dominaO piso do índice vetorial, sozinho, é praticamente a conta inteira

O que ninguém notaUm RAG parado custa quase o mesmo que um RAG em uso nesta escala. Piloto esquecido ligado é a forma mais comum de desperdício desta banda

CenárioProdução — 1.200 perguntas por dia

O que dominaO contexto recuperado passa a dominar: milhares de tokens de entrada, 1.200 vezes por dia

O que ninguém notaReduzir de cinco para três trechos recuperados corta a maior linha da conta em quase 40% — e só é seguro fazer isso medindo o acerto contra o golden set, que é exatamente o instrumento que este laboratório constrói

CenárioAcervo vivo — jurídico revisando política toda semana

O que dominaA reingestão passa a competir com o uso

O que ninguém notaReingestão completa semanal de um acervo grande pode custar mais que as perguntas do mês. Ingestão incremental não é otimização prematura aqui — é a diferença entre custo proporcional ao acervo e custo proporcional ao acervo vezes a frequência de revisão

💡

A conta que decide

Preço de embedding, de armazenamento vetorial, de instância e por 1.000 tokens muda por região e por modelo. Os valores relativos abaixo servem para dimensionar a decisão; confirme o número vigente na página de preços antes de usar em proposta. O número que autoriza este sistema não é o custo por pergunta: é o custo por pergunta comparado ao minuto de atendente que ele economiza, e ao custo de UMA resposta errada sobre prazo de devolução de material elétrico — que foi o evento que originou o laboratório.

Well-Architected nos seis pilares

Pilar	Situação hoje	Risco	Melhoria	Prioridade
Excelência operacional	Ingestão disparada à mão quando alguém lembra	Índice defasado respondendo política revogada com citação	Ingestão disparada por evento de escrita no bucket, com alarme de idade da sincronização	Alta
Segurança	Papel escopado à base específica; documentos internos num bucket privado	O acervo inteiro é visível a qualquer pergunta — não há noção de quem pode ver o quê	Filtro de permissão por fonte na recuperação, que é exatamente o L93	Alta se o acervo passar a ter documento restrito; irrelevante enquanto tudo for política pública
Confiabilidade	Serviços gerenciados regionais; aplicação em duas zonas	A região é ponto único, e reconstruir o índice em outra leva o tempo de uma ingestão completa	Medir o tempo de reingestão do acervo e declará-lo como RTO real; o desenho multi-região é o L99	Média
Eficiência de desempenho	Recuperação vetorial pura, cinco trechos, sem reordenação	O trecho certo pode existir no índice e não entrar no prompt — a falha que o L85 diagnostica	Busca híbrida com reordenação (L85), medida contra o mesmo golden set	Alta — é o maior ganho de qualidade disponível
Otimização de custo	Cinco trechos recuperados por pergunta, sem cache	O contexto recuperado é a maior linha da fatura e ninguém mediu se cinco trechos são melhores que três	Medir acerto por número de trechos e ajustar; cache de resposta para pergunta repetida (L89)	Média
Sustentabilidade	Índice provisionado 24 horas para tráfego de horário comercial	Capacidade ociosa à noite e no fim de semana	Avaliar backend com cobrança por requisição para acervo pequeno — a comparação do L84	Baixa

PilarExcelência operacional

Situação hojeIngestão disparada à mão quando alguém lembra

RiscoÍndice defasado respondendo política revogada com citação

MelhoriaIngestão disparada por evento de escrita no bucket, com alarme de idade da sincronização

PrioridadeAlta

PilarSegurança

Situação hojePapel escopado à base específica; documentos internos num bucket privado

RiscoO acervo inteiro é visível a qualquer pergunta — não há noção de quem pode ver o quê

MelhoriaFiltro de permissão por fonte na recuperação, que é exatamente o L93

PrioridadeAlta se o acervo passar a ter documento restrito; irrelevante enquanto tudo for política pública

PilarConfiabilidade

Situação hojeServiços gerenciados regionais; aplicação em duas zonas

RiscoA região é ponto único, e reconstruir o índice em outra leva o tempo de uma ingestão completa

MelhoriaMedir o tempo de reingestão do acervo e declará-lo como RTO real; o desenho multi-região é o L99

PrioridadeMédia

PilarEficiência de desempenho

Situação hojeRecuperação vetorial pura, cinco trechos, sem reordenação

RiscoO trecho certo pode existir no índice e não entrar no prompt — a falha que o L85 diagnostica

MelhoriaBusca híbrida com reordenação (L85), medida contra o mesmo golden set

PrioridadeAlta — é o maior ganho de qualidade disponível

PilarOtimização de custo

Situação hojeCinco trechos recuperados por pergunta, sem cache

RiscoO contexto recuperado é a maior linha da fatura e ninguém mediu se cinco trechos são melhores que três

MelhoriaMedir acerto por número de trechos e ajustar; cache de resposta para pergunta repetida (L89)

PrioridadeMédia

PilarSustentabilidade

Situação hojeÍndice provisionado 24 horas para tráfego de horário comercial

RiscoCapacidade ociosa à noite e no fim de semana

MelhoriaAvaliar backend com cobrança por requisição para acervo pequeno — a comparação do L84

PrioridadeBaixa

Onde mais IA entra neste RAG, e onde ela só acrescenta custo

O laboratório inteiro é IA, então a pergunta útil é onde cabe mais um modelo. Três candidatos aparecem sempre nesta conversa, e só um deles se paga aqui.

Ideia	Vale a pena?	Por quê
Um modelo reordenando os trechos recuperados	Sim, e é o próximo laboratório	É o único ponto da lista em que um modelo enxerga o que a busca vetorial não enxerga: ele lê a pergunta e o trecho JUNTOS, em vez de comparar dois vetores produzidos separadamente. Dois dos três erros residuais deste laboratório são exatamente disso, e o L85 mede o ganho contra o mesmo golden set
Um modelo decidindo se vale a pena buscar antes de buscar	Não	Acrescenta uma chamada de modelo em toda pergunta para evitar uma busca que custa uma fração dela. E erra: a decisão "isto está no acervo?" só pode ser respondida com confiança DEPOIS de buscar, olhando o score de relevância — que é grátis, determinístico e já está na resposta
Um modelo gerando as perguntas do golden set	Parcialmente, e com cuidado	Serve para AMPLIAR cobertura a partir de perguntas reais do chat, e não serve para criar o gabarito: gabarito conferido por modelo mede o quanto dois modelos concordam, não o quanto o sistema acerta. A pergunta pode ser gerada; a resposta esperada precisa de humano que conheça a política

IdeiaUm modelo reordenando os trechos recuperados

Vale a pena?Sim, e é o próximo laboratório

Por quêÉ o único ponto da lista em que um modelo enxerga o que a busca vetorial não enxerga: ele lê a pergunta e o trecho JUNTOS, em vez de comparar dois vetores produzidos separadamente. Dois dos três erros residuais deste laboratório são exatamente disso, e o L85 mede o ganho contra o mesmo golden set

IdeiaUm modelo decidindo se vale a pena buscar antes de buscar

Vale a pena?Não

Por quêAcrescenta uma chamada de modelo em toda pergunta para evitar uma busca que custa uma fração dela. E erra: a decisão "isto está no acervo?" só pode ser respondida com confiança DEPOIS de buscar, olhando o score de relevância — que é grátis, determinístico e já está na resposta

IdeiaUm modelo gerando as perguntas do golden set

Vale a pena?Parcialmente, e com cuidado

Por quêServe para AMPLIAR cobertura a partir de perguntas reais do chat, e não serve para criar o gabarito: gabarito conferido por modelo mede o quanto dois modelos concordam, não o quanto o sistema acerta. A pergunta pode ser gerada; a resposta esperada precisa de humano que conheça a política

Anti-padrões deste laboratório

Anti-padrão	Por que alguém faz	Sintoma em produção	Forma correta
Perguntar direto ao LLM sem nenhuma recuperação	é o caminho mais rápido para uma demo, e funciona bem o suficiente até alguém perguntar algo específico	resposta plausível e errada, sem fonte, aceita pelo atendente sem checar	recuperar o trecho relevante ANTES de gerar qualquer palavra da resposta
Instruir "responda com precisão e não invente" sem dar contexto	parece que uma instrução de comportamento resolve o que na verdade é falta de dado	a taxa de acerto sobe pouco ou nada, porque o modelo continua sem acesso ao documento real	dar o TRECHO certo no prompt — instrução sem dado não cria conhecimento
Chunk grande demais, "para não perder contexto"	intuitivamente parece mais seguro incluir mais texto do que menos	a recuperação traz páginas inteiras; o modelo tem de achar a informação certa dentro do próprio contexto, e às vezes erra por excesso	chunk do tamanho da unidade de resposta, com sobreposição pequena e calibrada
Reindexar o acervo inteiro a cada alteração pequena	é mais simples de implementar do que detectar exatamente o que mudou	job de ingestão caro e demorado rodando por uma vírgula corrigida num documento	ingestão incremental, disparada pelo evento de escrita do objeto específico
Confiar na taxa de satisfação do atendente como medida de qualidade	é o número que já existe, sem construir nada novo para medir	o atendente aceita resposta errada com confiança porque o texto parece bem escrito — fluência não é acurácia	golden set com resposta oficial conhecida, comparado por acerto, não por impressão

Anti-padrãoPerguntar direto ao LLM sem nenhuma recuperação

Por que alguém fazé o caminho mais rápido para uma demo, e funciona bem o suficiente até alguém perguntar algo específico

Sintoma em produçãoresposta plausível e errada, sem fonte, aceita pelo atendente sem checar

Forma corretarecuperar o trecho relevante ANTES de gerar qualquer palavra da resposta

Anti-padrãoInstruir "responda com precisão e não invente" sem dar contexto

Por que alguém fazparece que uma instrução de comportamento resolve o que na verdade é falta de dado

Sintoma em produçãoa taxa de acerto sobe pouco ou nada, porque o modelo continua sem acesso ao documento real

Forma corretadar o TRECHO certo no prompt — instrução sem dado não cria conhecimento

Anti-padrãoChunk grande demais, "para não perder contexto"

Por que alguém fazintuitivamente parece mais seguro incluir mais texto do que menos

Sintoma em produçãoa recuperação traz páginas inteiras; o modelo tem de achar a informação certa dentro do próprio contexto, e às vezes erra por excesso

Forma corretachunk do tamanho da unidade de resposta, com sobreposição pequena e calibrada

Anti-padrãoReindexar o acervo inteiro a cada alteração pequena

Por que alguém fazé mais simples de implementar do que detectar exatamente o que mudou

Sintoma em produçãojob de ingestão caro e demorado rodando por uma vírgula corrigida num documento

Forma corretaingestão incremental, disparada pelo evento de escrita do objeto específico

Anti-padrãoConfiar na taxa de satisfação do atendente como medida de qualidade

Por que alguém fazé o número que já existe, sem construir nada novo para medir

Sintoma em produçãoo atendente aceita resposta errada com confiança porque o texto parece bem escrito — fluência não é acurácia

Forma corretagolden set com resposta oficial conhecida, comparado por acerto, não por impressão

Evolução em níveis: da resposta sem fonte à plataforma compartilhada

A terceira arquitetura não é um desenho novo — é a resposta a QUANDO trocar de desenho. Cada nível resolve um risco medido neste laboratório e compra outro no lugar.

🗺️ De LLM direto a RAG como plataforma — e o risco que cada nível troca por outro

Nível 1 — ProtótipoRisco resolvido: nenhum. Novo risco: resposta plausível e errada, sem fonte, aceita por quem confia no texto bem escrito. Custo: só o preço por chamada ao modelo — o motivo de ter sido adotado sem cerimônia.

→

Chamada direta ao Bedrock, sem nenhuma recuperação. É o que a Cadência tinha, e sobreviveu 3 semanas sem ninguém notar.

Nível 2 — Este laboratórioRisco resolvido: alucinação sobre o que os documentos cobrem. Novo risco: erro de chunking corta trecho ao meio, e documento duplicado confunde a recuperação. Custo: OpenSearch Serverless cobra capacidade mínima mesmo parado, mais o custo por chamada de embedding e geração.

→

RAG mínimo: Knowledge Bases + OpenSearch Serverless, taxa de acerto medida contra golden set (35% → 92,5%).

Nível 3 — Recuperação melhorRisco resolvido: recuperação trazer o trecho ERRADO, não só nenhum trecho. Novo risco: mais peças no pipeline, mais superfície para calibrar. Custo: cresce com a chamada extra de reranking por pergunta.

→

Comparar as quatro opções de banco vetorial (L84) e somar busca híbrida — léxica mais vetorial — com reranking (L85).

Nível 4 — Controle sobre o que o sistema diz e fazRisco resolvido: resposta sobre tópico proibido, ou ação disparada sem controle. 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 (L86), e agente com ferramenta quando a resposta exige AGIR, não só responder (L87).

Nível 5 — Avaliação contínuaRisco resolvido: alteração que piora a taxa de acerto sem ninguém perceber até a reclamação do cliente. Novo risco: viés do juiz automático concordando sistematicamente com o próprio modelo. Custo: chamadas de avaliação a cada deploy, pequenas frente ao tráfego real.

→

O golden set vira suíte que reprova regressão de qualidade no CI a cada mudança de prompt ou chunking, com LLM-como-juiz complementando a checagem manual (L88).

Nível 6 — Dados e IA, plataforma compartilhadaRisco resolvido: cada time reconstruindo o próprio RAG do zero. Novo risco: um acervo 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.

→

Uma base de conhecimento compartilhada entre atendimento, lojista e busca de catálogo (L94), com múltiplos acervos e controle de quem vê o quê — a mesma pergunta "onde guardar o dado" que o L84 aprofunda, agora em escala de plataforma. É também o padrão descrito na solução S4 do catálogo de arquiteturas de IA na AWS.

💡

Por que este laboratório vem antes do L84 e do L85

A ordem não é negociável: busca híbrida e reranking (nível 3) pressupõem que a recuperação básica já funciona e já está medida — é o texto que ancora a comparação com o resultado vetorial, e é exatamente o que este laboratório entrega. Quem tenta reranking antes de ter RAG mínimo funcionando está otimizando um número que ainda não mediu.

Quando algo não funciona

Sintoma	Causa provável	Como investigar	Log ou métrica	Correção
A resposta vem sem nenhuma citação	Recuperação não devolveu nada acima do piso de relevância	Repetir a mesma pergunta chamando só a recuperação, sem geração, e olhar os scores	Proporção de respostas sem citação; distribuição de score do melhor trecho	Se o acervo não cobre o assunto, responder "não encontrei" é o comportamento certo — a correção é no acervo, não no prompt
A citação aponta para o documento certo e o prazo está errado	O trecho recuperado cortou a tabela: veio a linha sem o cabeçalho, ou o contrário	Ler o texto exato do trecho citado, não o documento inteiro	O conteúdo do trecho retornado, registrado para amostra de perguntas	Ajustar a estratégia de divisão para não partir tabela, e conferir contra o golden set — mudar o tamanho do chunk conserta um caso e quebra outro se ninguém medir
Responde com a política antiga, com confiança	Documento atualizado no bucket e índice não reingerido	Comparar a data de modificação do objeto no S3 com a da última sincronização	Idade da última sincronização bem-sucedida	Reingerir e, principalmente, disparar a ingestão por evento de escrita — este sintoma é o que mais custa credibilidade
Duas perguntas quase iguais recebem respostas contraditórias	Documento duplicado em versões diferentes no acervo	Recuperar sem gerar e verificar se os trechos vêm de arquivos distintos com o mesmo assunto	Origem dos trechos recuperados por pergunta	Um documento por assunto. A contradição está no acervo, e nenhum ajuste de modelo a resolve
A latência dobrou sem mudança de código	O acervo cresceu e a recuperação passou a dominar o tempo	Separar no traço o tempo de recuperação do tempo de geração	Latência p95 de recuperação e de geração, em séries separadas	É o sinal de que a escala mudou de faixa. Sem a separação das duas métricas, o time otimiza o modelo enquanto o problema está no índice

SintomaA resposta vem sem nenhuma citação

Causa provávelRecuperação não devolveu nada acima do piso de relevância

Como investigarRepetir a mesma pergunta chamando só a recuperação, sem geração, e olhar os scores

Log ou métricaProporção de respostas sem citação; distribuição de score do melhor trecho

CorreçãoSe o acervo não cobre o assunto, responder "não encontrei" é o comportamento certo — a correção é no acervo, não no prompt

SintomaA citação aponta para o documento certo e o prazo está errado

Causa provávelO trecho recuperado cortou a tabela: veio a linha sem o cabeçalho, ou o contrário

Como investigarLer o texto exato do trecho citado, não o documento inteiro

Log ou métricaO conteúdo do trecho retornado, registrado para amostra de perguntas

CorreçãoAjustar a estratégia de divisão para não partir tabela, e conferir contra o golden set — mudar o tamanho do chunk conserta um caso e quebra outro se ninguém medir

SintomaResponde com a política antiga, com confiança

Causa provávelDocumento atualizado no bucket e índice não reingerido

Como investigarComparar a data de modificação do objeto no S3 com a da última sincronização

Log ou métricaIdade da última sincronização bem-sucedida

CorreçãoReingerir e, principalmente, disparar a ingestão por evento de escrita — este sintoma é o que mais custa credibilidade

SintomaDuas perguntas quase iguais recebem respostas contraditórias

Causa provávelDocumento duplicado em versões diferentes no acervo

Como investigarRecuperar sem gerar e verificar se os trechos vêm de arquivos distintos com o mesmo assunto

Log ou métricaOrigem dos trechos recuperados por pergunta

CorreçãoUm documento por assunto. A contradição está no acervo, e nenhum ajuste de modelo a resolve

SintomaA latência dobrou sem mudança de código

Causa provávelO acervo cresceu e a recuperação passou a dominar o tempo

Como investigarSeparar no traço o tempo de recuperação do tempo de geração

Log ou métricaLatência p95 de recuperação e de geração, em séries separadas

CorreçãoÉ o sinal de que a escala mudou de faixa. Sem a separação das duas métricas, o time otimiza o modelo enquanto o problema está no índice

Limpeza: o que o destroy não leva

limpeza.sh

# limpeza.sh — ordem importa: a Knowledge Base referencia o índice e o bucket,
# e o Terraform destroy sozinho nao apaga objeto versionado nem esvazia bucket.

# 1) Apagar a data source e a knowledge base primeiro (dependencia do indice)
aws bedrock-agent delete-data-source --knowledge-base-id KB7F3A9C1D --data-source-id DS9E2B
aws bedrock-agent delete-knowledge-base --knowledge-base-id KB7F3A9C1D

# 2) Esvaziar TODAS as versoes do bucket antes do destroy — bucket versionado
#    com objeto dentro nao e removido por "terraform destroy" nem por
#    "aws s3 rb" simples; e o bucket que mais dinheiro esconde depois do laboratorio.
aws s3api list-object-versions --bucket cadencia-documentos-atendimento \
  --query "[Versions,DeleteMarkers][].{Key:Key,VersionId:VersionId}" --output json \
  | jq -c '.[]' | while read -r obj; do
    aws s3api delete-object --bucket cadencia-documentos-atendimento \
      --key "$(echo "$obj" | jq -r .Key)" --version-id "$(echo "$obj" | jq -r .VersionId)"
  done

# 3) terraform destroy cuida do resto: colecao OpenSearch Serverless, políticas
#    de seguranca, roles do IAM, o proprio bucket vazio, e o grupo de logs da
#    funcao de atendimento
terraform destroy -auto-approve

# 4) Conferir que nao sobrou colecao do OpenSearch Serverless cobrando OCU
aws opensearchserverless list-collections \
  --query "collectionSummaries[?name=='cadencia-rag-politica-atendimento']"
# Esperado: lista vazia

⚠️

O que continua cobrando depois de "destruir"

Duas coisas que `terraform destroy` sozinho não resolve: um bucket S3 versionado com objeto dentro fica preso (o provider recusa apagar bucket não-vazio, e cada versão conta como objeto), e o grupo de logs da função de atendimento continua existindo com a retenção configurada se ele foi criado fora do módulo Terraform que você está destruindo. A capacidade mínima do OpenSearch Serverless (OCU) é o item que mais cobra parado neste laboratório especificamente — confira o passo 4 antes de fechar o navegador.

Resumo: problema, peça e motivo

Problema	Peça	Motivo
Resposta inventada, sem fonte	Bedrock Knowledge Bases (RetrieveAndGenerate)	só gera depois de recuperar, e devolve a citação junto da resposta
Documento real nunca chega ao modelo	S3 como fonte da base de conhecimento	o mesmo bucket que já guarda política e catálogo do L62, sem duplicar dado
Onde procurar o trecho certo	OpenSearch Serverless, gerenciado pela Knowledge Base	busca por similaridade vetorial, sem operar índice à mão
Tabela de garantia cortada ao meio	Chunking de tamanho fixo com sobreposição	o trecho recuperado carrega a linha inteira, não metade dela
"Melhorou" sem prova	Golden set de 40 perguntas, medido antes e depois	35% para 92,5% — um número comparável entre versões, não uma impressão
Chamada sem controle de acesso	IAM com Resource específico do modelo e da base	nenhuma aplicação além da de atendimento invoca este modelo ou esta base

ProblemaResposta inventada, sem fonte

PeçaBedrock Knowledge Bases (RetrieveAndGenerate)

Motivosó gera depois de recuperar, e devolve a citação junto da resposta

ProblemaDocumento real nunca chega ao modelo

PeçaS3 como fonte da base de conhecimento

Motivoo mesmo bucket que já guarda política e catálogo do L62, sem duplicar dado

ProblemaOnde procurar o trecho certo

PeçaOpenSearch Serverless, gerenciado pela Knowledge Base

Motivobusca por similaridade vetorial, sem operar índice à mão

ProblemaTabela de garantia cortada ao meio

PeçaChunking de tamanho fixo com sobreposição

Motivoo trecho recuperado carrega a linha inteira, não metade dela

Problema"Melhorou" sem prova

PeçaGolden set de 40 perguntas, medido antes e depois

Motivo35% para 92,5% — um número comparável entre versões, não uma impressão

ProblemaChamada sem controle de acesso

PeçaIAM com Resource específico do modelo e da base

Motivonenhuma aplicação além da de atendimento invoca este modelo ou esta base

Desafio — sem roteiro

💡

O requisito

Adicione um documento à base que CONTRADIZ diretamente um documento já existente (ex: duas versões de uma política com datas diferentes dizendo coisas opostas) e observe o que o sistema faz quando perguntado sobre o tema.

⚠️

Critério de aceite — executável, não "verifique se funciona"

A resposta do sistema para uma pergunta cujo tema tem os dois documentos conflitantes NÃO escolhe silenciosamente um dos dois sem avisar — ela cita as DUAS fontes (a citação é o contrato do laboratório) e, no mínimo, sinaliza a divergência, mesmo que a resposta final privilegie uma delas.

Dica 1: Se os dois documentos tiverem data, o jeito mais simples de resolver o conflito é adicionar a data aos metadados de cada chunk e instruir o prompt a preferir o mais recente EXPLICITAMENTE — mas isso só funciona se a citação também mostrar a data, senão o usuário não consegue auditar a escolha.
Dica 2: Teste com uma pergunta que force os DOIS documentos a aparecerem entre os top-k resultados da busca — se o retriever só traz um dos dois, o teste não está avaliando o comportamento de conflito, está testando busca.
Dica 3: Uma resposta que ignora o conflito e cita só uma fonte, mesmo que a informação esteja certa, falha o critério — o requisito é sobre TRANSPARÊNCIA do conflito, não sobre acertar qual documento é o vigente.

✅

Lembrete de limpeza

Todo recurso que este desafio criar entra no mesmo `terraform destroy` do laboratório — nada fica para trás cobrando sozinho.

Perguntas frequentes

❓ RAG substitui o fine-tuning do modelo com os documentos da Cadência?

Não — os dois resolvem problemas diferentes, e RAG é o caminho certo quando o documento muda com frequência. Fine-tuning grava conhecimento nos pesos do modelo, e atualizar significa re-treinar, um processo caro e lento; a política de devolução da Cadência é revisada pelo jurídico regularmente, e RAG só precisa reingerir o arquivo alterado — minutos depois, a resposta já reflete a versão nova. Fine-tuning valeria para ensinar um estilo ou um comportamento consistente, não um fato que muda toda semana.

❓ Por que a resposta do LLM direto parecia tão confiante mesmo estando errada?

Porque fluência e acurácia são propriedades independentes, e o modelo foi treinado para completar texto de forma coerente, não para admitir incerteza. Sem nenhum trecho de documento no prompt, ele responde com o padrão estatístico mais provável de uma política de devolução genérica de e-commerce — e essa resposta sai gramaticalmente perfeita, bem estruturada, e sem nenhuma relação com a política real da Cadência. É por isso que o atendente não tinha como distinguir a resposta certa da errada só lendo o texto: as duas soam igualmente boas.

❓ Chunking de 500 tokens com 20% de sobreposição serve para qualquer documento?

Não, e calibrar esse número é o assunto que este módulo assume, sem aprofundar — veja o L84 e o L85 para a comparação completa. Aqui, 500 tokens com 20% de sobreposição foi escolhido porque cabe a maior tabela de garantia por categoria sem cortar uma linha ao meio, que era a causa de 2 dos 3 erros residuais medidos. Um documento com parágrafos mais longos e menos estrutura tabular pode pedir um chunk maior; um FAQ curto pode pedir um chunk por pergunta-resposta. O número certo é medido contra o próprio acervo, não copiado de outro módulo.

❓ O que acontece quando a pergunta do atendente não tem resposta em nenhum documento?

O sistema responde que não encontrou a informação nos documentos da Cadência, em vez de completar com conhecimento geral do modelo — é o comportamento que o prompt de fundamentação instrui explicitamente, e o que distingue RAG bem configurado de um LLM direto. No golden set medido, essa é a única resposta classificada como "não sei" das 40, e ela conta como acerto: a pergunta realmente não tinha trecho correspondente no acervo, e admitir isso é mais correto do que inventar uma política que não existe.

❓ Knowledge Bases usa sempre OpenSearch Serverless por baixo?

Não — Knowledge Bases é a camada gerenciada de ingestão e recuperação, e ela pode apontar para diferentes armazenamentos de vetor, incluindo OpenSearch Serverless (o padrão mais simples de configurar, usado aqui), Aurora com pgvector, Redis ou um índice do Pinecone. A escolha muda custo, controle sobre o algoritmo de busca e latência — é exatamente a comparação de quatro opções medidas no mesmo acervo que o L84 faz. Este módulo fixa OpenSearch Serverless de propósito, para isolar a pergunta "RAG funciona?" da pergunta "qual banco vetorial?".

❓ Por que a latência subiu de 700 ms para 1,6 s com RAG, e isso é um problema?

Subiu porque agora existem duas etapas em vez de uma — a busca vetorial soma de 80 a 150 ms, e a geração fica mais lenta porque o prompt cresce com os trechos recuperados e o modelo produz uma resposta que nomeia a fonte. Não é um problema aqui porque o orçamento declarado para o atendimento é de até 3 segundos, e 1,6 s deixa margem confortável; num canal com orçamento mais apertado, como um agente de voz em tempo real, essa mesma margem poderia não caber, e a escolha de arquitetura mudaria.

❓ Por que medir num golden set de só 40 perguntas, e não em toda pergunta possível?

Porque um golden set não existe para provar cobertura total — existe para dar um número comparável entre versões do sistema, e 40 perguntas com resposta oficial já revelam a diferença estrutural entre "sem recuperação" e "com recuperação" (35% contra 92,5%). Testar contra toda pergunta possível não é viável nem necessário: o valor está em manter o MESMO conjunto fixo toda vez que se muda chunking, prompt ou modelo, para que a comparação meça o efeito da mudança, não uma amostra diferente de perguntas.

Fixando

Quiz rápido

Depois de implantar o RAG, a taxa de acerto no golden set subiu de 35% para 92,5%, mas não chegou a 100%. Os 3 erros residuais medidos vieram de tabela cortada no limite do chunk e de um documento duplicado (versão antiga ainda no bucket). O que isso mostra sobre RAG?

Quiz rápido

No golden set de 40 perguntas, uma recebeu a resposta "não encontrei essa informação nos documentos da Cadência" — e essa resposta foi classificada como ACERTO, não erro. Por que uma recusa em responder conta como taxa de acerto?

Próximo laboratório

💡

Próximo passo: L84 (onde guardar o vetor) e L85 (recuperação híbrida e reranking)

Este laboratório fixou o banco vetorial (OpenSearch Serverless, gerenciado pela Knowledge Base) para isolar a pergunta "RAG funciona?". O L84 volta exatamente a essa decisão e mede as quatro opções — Knowledge Bases/OpenSearch, OpenSearch provisionado, S3 Vectors e Aurora pgvector — no mesmo acervo da Cadência, com recall, latência e custo comparados lado a lado. Depois, o L85 ataca os 3 erros residuais medidos aqui pela raiz: busca híbrida (léxica + vetorial) com reranking, para reduzir os casos em que a recuperação traz o trecho errado, não o trecho nenhum.

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 84 — Onde guardar vetor: quatro opções, uma decisão

100 Laboratórios de Arquitetura AWS · 31 min · +190 XP

→

Temas deste módulo

Discussão

Carregando comentários…

Lab 83 — RAG mínimo que funciona, com citação

⏱ 33 min·⭐ 175 XP

O problema, e a empresa que o tem

NívelAvançado — depende do L62 (documentos e catálogo já em camadas no S3) e do tema do L81 (cliente que já sabe chamar o Bedrock)

Pré-requisitosL62 concluído (camada ouro alimentando texto por loja), familiaridade com uma chamada básica ao Bedrock (tema do L81), .NET 8

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

Custo relativoBaixo a médio — o OpenSearch Serverless cobra por capacidade mínima (OCU) mesmo parado, e é o item que mais pesa na fatura deste laboratório

ServiçosBedrock (modelo + Knowledge Bases), S3, OpenSearch Serverless, Lambda (.NET 8), API Gateway, CloudWatch, IAM

Volume medido≈1.200 perguntas/dia na central de atendimento; ≈18% (≈216/dia) são sobre política específica da Cadência — o recorte que este laboratório resolve

Requisito declaradotoda resposta sobre política tem de citar o trecho exato que a fundamenta, e a taxa de acerto tem de ser medida contra um conjunto de perguntas com resposta conhecida

Ao final você temum RAG respondendo com trecho citável, com taxa de acerto medida antes (LLM direto) e depois (com recuperação) contra um golden set de 40 perguntas

🚨

Resposta plausível e errada, sem fonte

⚠️

O que este laboratório NÃO é

O que você vai conseguir fazer

Objetivos verificáveis: cada um se prova com um comando ou uma medição na seção de implantação, não com a sensação de ter entendido RAG.

Medir a taxa de acerto de um LLM respondendo direto, sem nenhum trecho de documento recuperado.
Publicar os documentos reais da Cadência (política de devolução, garantia, frete e catálogo por loja) numa base de conhecimento gerenciada, com chunking configurado.
Configurar a ingestão que transforma cada documento em trechos, embeddings e um índice vetorial, sem escrever o pipeline de sincronização à mão.
Fazer uma consulta em C#/.NET 8 que devolve resposta com o trecho exato citado, não um resumo sem fonte.
Construir um golden set de perguntas com resposta oficial conhecida, e medir a taxa de acerto do sistema com RAG contra ele.
Explicar por que RAG resolve o problema de conhecimento desatualizado sem re-treinar o modelo.
Diagnosticar um erro residual do RAG e dizer se a causa é chunking, recuperação ou documento ausente/duplicado.
Restringir a chamada ao modelo e à base de conhecimento por IAM, com o ARN específico do recurso, não `"Resource": "*"`.

O que a certificação cobra disto

Conceito	Certificação	Como aparece aqui	O que dominar
RAG (Retrieval-Augmented Generation)	AIF-C01, MLA-C01	LLM direto e com Knowledge Bases, medidos lado a lado no mesmo golden set	por que RAG resolve conhecimento desatualizado sem re-treinar o modelo
Chunking (estratégia de divisão de documento)	MLA-C01	tamanho fixo com sobreposição, calibrado para não cortar uma tabela ao meio	o trade-off entre trecho pequeno (preciso, pouco contexto) e grande (contexto, impreciso)
Embedding e busca por similaridade	AIF-C01, MLA-C01	a Knowledge Base gera o embedding e indexa no OpenSearch Serverless	embedding é vetor; busca vetorial encontra sentido, não palavra exata
Atribuição / citação (grounding)	AIF-C01	RetrieveAndGenerate devolve o trecho e a fonte usados para gerar cada resposta	resposta sem fonte rastreável não é confiável em domínio regulado
Bedrock Knowledge Bases (RAG gerenciado)	AIF-C01, MLA-C01	ingestão, chunking, embedding e indexação geridos pelo serviço, sem servidor próprio	a diferença entre "gerenciado" (este módulo) e "eu opero o índice" (L84)
Alucinação e mitigação	AIF-C01	medida diretamente: taxa de acerto do golden set antes e depois do RAG	RAG não elimina alucinação sozinho — reduz drasticamente quando o dado existe no acervo

ConceitoRAG (Retrieval-Augmented Generation)

CertificaçãoAIF-C01, MLA-C01

Como aparece aquiLLM direto e com Knowledge Bases, medidos lado a lado no mesmo golden set

O que dominarpor que RAG resolve conhecimento desatualizado sem re-treinar o modelo

ConceitoChunking (estratégia de divisão de documento)

CertificaçãoMLA-C01

Como aparece aquitamanho fixo com sobreposição, calibrado para não cortar uma tabela ao meio

O que dominaro trade-off entre trecho pequeno (preciso, pouco contexto) e grande (contexto, impreciso)

ConceitoEmbedding e busca por similaridade

CertificaçãoAIF-C01, MLA-C01

Como aparece aquia Knowledge Base gera o embedding e indexa no OpenSearch Serverless

O que dominarembedding é vetor; busca vetorial encontra sentido, não palavra exata

ConceitoAtribuição / citação (grounding)

CertificaçãoAIF-C01

Como aparece aquiRetrieveAndGenerate devolve o trecho e a fonte usados para gerar cada resposta

O que dominarresposta sem fonte rastreável não é confiável em domínio regulado

ConceitoBedrock Knowledge Bases (RAG gerenciado)

CertificaçãoAIF-C01, MLA-C01

Como aparece aquiingestão, chunking, embedding e indexação geridos pelo serviço, sem servidor próprio

O que dominara diferença entre "gerenciado" (este módulo) e "eu opero o índice" (L84)

ConceitoAlucinação e mitigação

CertificaçãoAIF-C01

Como aparece aquimedida diretamente: taxa de acerto do golden set antes e depois do RAG

O que dominarRAG não elimina alucinação sozinho — reduz drasticamente quando o dado existe no acervo

💡

Onde isto costuma ser cobrado errado

Requisitos, e como cada um muda o desenho

Requisito não funcional que não vira uma linha de configuração é intenção. A coluna da direita é onde cada um deixou marca no Terraform, no prompt ou no pipeline de ingestão.

Requisito	Valor declarado	O que ele decide no desenho
Resposta cita o trecho exato que a fundamenta	obrigatório	RetrieveAndGenerate com citações habilitadas; sem citação, a resposta não é mostrada ao atendente como sugestão pronta
Pergunta fora do que os documentos cobrem não vira resposta inventada	obrigatório	prompt de fundamentação instrui "responda só com o contexto recuperado; sem trecho suficiente, diga que não encontrou"
Taxa de acerto medida, não estimada	golden set de 40 perguntas com resposta oficial	suíte de avaliação roda contra o mesmo conjunto antes e depois de qualquer mudança de prompt ou chunking
Resposta cabe no tempo de um atendimento ao vivo	até 3 s	orçamento de latência somando busca vetorial e geração, medido e com margem
Documento alterado pelo jurídico aparece na resposta em tempo razoável	algumas horas, não dias	job de ingestão disparado por evento de escrita no S3, não reingestão agendada do acervo inteiro
Trecho recuperado não pode vir cortado no meio de uma tabela	obrigatório	chunking de tamanho fixo com sobreposição, calibrado pela maior tabela do acervo
Cada resposta permite auditoria de qual trecho foi usado	obrigatório	log estruturado com id do documento e do trecho citado, publicado no CloudWatch
Chamada ao modelo e à base de conhecimento restrita à aplicação de atendimento	segurança	IAM role com `bedrock:InvokeModel`/`bedrock:Retrieve` restrito ao ARN do modelo e da knowledge base específicos

RequisitoResposta cita o trecho exato que a fundamenta

Valor declaradoobrigatório

O que ele decide no desenhoRetrieveAndGenerate com citações habilitadas; sem citação, a resposta não é mostrada ao atendente como sugestão pronta

RequisitoPergunta fora do que os documentos cobrem não vira resposta inventada

Valor declaradoobrigatório

O que ele decide no desenhoprompt de fundamentação instrui "responda só com o contexto recuperado; sem trecho suficiente, diga que não encontrou"

RequisitoTaxa de acerto medida, não estimada

Valor declaradogolden set de 40 perguntas com resposta oficial

O que ele decide no desenhosuíte de avaliação roda contra o mesmo conjunto antes e depois de qualquer mudança de prompt ou chunking

RequisitoResposta cabe no tempo de um atendimento ao vivo

Valor declaradoaté 3 s

O que ele decide no desenhoorçamento de latência somando busca vetorial e geração, medido e com margem

RequisitoDocumento alterado pelo jurídico aparece na resposta em tempo razoável

Valor declaradoalgumas horas, não dias

O que ele decide no desenhojob de ingestão disparado por evento de escrita no S3, não reingestão agendada do acervo inteiro

RequisitoTrecho recuperado não pode vir cortado no meio de uma tabela

Valor declaradoobrigatório

O que ele decide no desenhochunking de tamanho fixo com sobreposição, calibrado pela maior tabela do acervo

RequisitoCada resposta permite auditoria de qual trecho foi usado

Valor declaradoobrigatório

O que ele decide no desenholog estruturado com id do documento e do trecho citado, publicado no CloudWatch

RequisitoChamada ao modelo e à base de conhecimento restrita à aplicação de atendimento

Valor declaradosegurança

O que ele decide no desenhoIAM role com `bedrock:InvokeModel`/`bedrock:Retrieve` restrito ao ARN do modelo e da knowledge base específicos

Arquitetura mínima: o modelo respondendo sem nenhum trecho recuperado

O modelo responde com o que aprendeu no treino — nunca com o que a Cadência escreveu

Central de atendimento

Atendente da Cadênciadigita a pergunta do cliente e vê a sugestão pronta para copiar, sem indicação de incerteza

Aplicação

API do painel de atendimentoúnico ponto de entrada da pergunta; não sabe nem precisa saber que não há recuperação

Função "sugerir-resposta" (.NET 8)monta o prompt só com a pergunta do atendente, sem buscar nada antes

Modelo, sem contexto nenhum

Bedrock — Clauderesponde com o padrão mais provável do treino; não tem como saber que a Cadência existe

Documentos reais da Cadência — nunca consultados

S3 — política de devolução, garantia, freteescritos pelo jurídico e pela operação; nenhuma peça deste desenho lê este bucket

→ pergunta digitada em português, sem estrutura
→ encaminha a chamada HTTP
→ prompt = só a pergunta do atendente, sem nenhum trecho de documento
→ resposta fluente, sem fonte nem confiança declarada
→ sugestão que o atendente aceita na maioria das vezes

Fora da AWS
Rede e entrega
Compute
IA e machine learning
Armazenamento

🚨

A confiança do texto não mede a correção do fato

Arquitetura para produção: do documento ao trecho citado

Recupera antes de gerar, e a resposta carrega a citação

Central de atendimento

Atendente da Cadênciamesma pergunta da Figura 1, para comparar diretamente o resultado

Aplicação

API do painel de atendimentomesmo ponto de entrada; o que muda é o que a função atrás dele faz

Função "responder-com-citacao" (.NET 8)chama RetrieveAndGenerate — não monta o prompt sozinha, delega busca e geração ao Bedrock

Documentos reais da Cadência

S3 — política de devolução, garantia, frete, catálogo ouroo mesmo bucket de camadas do L62; jurídico e operação escrevem aqui, sem saber do RAG

Ingestão: do documento ao vetor

Bedrock Knowledge Basesorquestra o job de ingestão a cada objeto novo ou alterado no bucket

Chunking de tamanho fixo500 tokens por trecho, 20% de sobreposição, calibrado pela maior tabela do acervo

Modelo de embedding (Titan)transforma cada trecho de texto num vetor de números que representa o sentido

Índice vetorial

OpenSearch Serverlessguarda vetor e texto original do trecho; a Knowledge Base gerencia o ciclo de vida inteiro

Geração com citação

Bedrock — RetrieveAndGeneratebusca os k trechos mais próximos da pergunta ANTES de gerar qualquer palavra da resposta

Observação e auditoria

CloudWatch — log de citaçãoregistra qual trecho e qual documento fundamentaram cada resposta, para auditoria

→ pergunta digitada em português, mesma interface da Figura 1
→ encaminha a chamada HTTP
→ evento de escrita dispara ingestão incremental do objeto alterado
→ quebra o documento em trechos com sobreposição
→ cada trecho vira um vetor de embedding
→ grava vetor e texto original do trecho no índice
→ RetrieveAndGenerate: pergunta do atendente + id da knowledge base
→ busca por similaridade: os k trechos mais próximos do vetor da pergunta
→ os k trechos recuperados, com o texto original de cada um
→ resposta gerada citando o trecho exato usado
→ resposta com citação: trecho + referência ao documento de origem
→ loga o id do trecho citado em cada resposta

Fora da AWS
Rede e entrega
Compute
Armazenamento
IA e machine learning
Conceito de arquitetura
Analytics
Gestão e governança

ƒ O orçamento de 3 s do atendimento tem de caber a busca e a geração juntas

latencia_total ≈ latencia_busca_vetorial + latencia_geracao_com_contexto

latencia_busca_vetorial

≈80–150 ms, no índice OpenSearch Serverless

cresce pouco com o tamanho do acervo porque a busca é aproximada (ANN) sobre os k mais próximos, não uma varredura de tudo.

k (trechos recuperados)

3 a 5, o padrão usado aqui

mais trechos aumentam a chance de achar a resposta certa, mas também aumentam o prompt e a chance de o modelo se confundir entre trechos — o ajuste fino disso é o assunto do L85.

latencia_geracao_com_contexto

≈1,3–1,5 s, Claude com os trechos no prompt

maior que a chamada direta da Figura 1 porque o prompt cresce com os trechos recuperados, e o modelo gera texto que nomeia a fonte.

✅

O que a citação entrega, que fluência nunca entregou

Como funciona, ponta a ponta

🗺️ Do documento no S3 à resposta citada na tela do atendente

3. O documento é dividido em trechos com sobreposição500 tokens por trecho, 20% de sobreposição, para que uma tabela de garantia por categoria não seja cortada no meio de uma linha.

4. Cada trecho vira um vetor de embedding e entra no índiceO modelo de embedding transforma o texto num vetor de números; o OpenSearch Serverless grava o vetor junto do texto original do trecho.

5. Atendente pergunta; a aplicação chama RetrieveAndGenerateA função .NET 8 não monta o prompt sozinha — chama a API do Bedrock que já orquestra busca e geração numa única requisição.

6. O modelo busca antes de gerar qualquer palavraA pergunta vira vetor, o índice devolve os k trechos mais próximos, e só então pergunta e trechos entram juntos no prompt do modelo.

O log abaixo é o que a aplicação escreve no CloudWatch a cada resposta gerada — é o material bruto da auditoria: qual trecho, de qual documento, fundamentou aquela resposta específica.

resposta-com-citacao.json

{
  "evento": "RESPOSTA_COM_CITACAO_GERADA",
  "timestamp": "2026-08-08T14:02:11.340Z",
  "pergunta": "Qual a política de devolução de material elétrico?",
  "knowledgeBaseId": "KB7F3A9C1D",
  "trechosRecuperados": 3,
  "trechoCitado": {
    "documento": "s3://cadencia-documentos-atendimento/politicas/devolucao-material-eletrico.md",
    "chunkId": "devolucao-material-eletrico.md#chunk-4",
    "texto": "Material elétrico: devolução em até 7 dias corridos, mediante nota fiscal e produto lacrado, por exigência de segurança elétrica dos fornecedores."
  },
  "latenciaMs": 1487,
  "_comentario": "chunkId e documento sao o que a auditoria confere depois — nao o texto da resposta gerada, que pode parafrasear o trecho."
}

💡

O caminho de "não encontrei" é parte do desenho, não uma falha dele

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

✓ Bedrock Knowledge Bases (RAG gerenciado) sobre S3, com OpenSearch Serverless como índice, medido contra um golden set de 40 perguntas com resposta oficial

Decisão	Escolha	Alternativas	Motivo	O que se perde
Onde indexar o vetor	OpenSearch Serverless, gerenciado pela Knowledge Base	Aurora pgvector; S3 Vectors; OpenSearch provisionado	zero servidor para operar, e a Knowledge Base já cuida do ciclo de vida do índice	menos controle sobre o algoritmo de busca e sobre custo por hora fixo — é a comparação do L84
Tamanho do chunk	500 tokens, 20% de sobreposição	chunk por documento inteiro; chunk semântico por seção	a maior tabela de garantia por categoria cabe inteira num chunk, sem cortar linha	trecho maior às vezes traz contexto irrelevante junto com o relevante
O que fazer sem trecho relevante	responder "não encontrei isso nos documentos"	deixar o modelo completar com o que sabe do treino	evita fabricar resposta sobre o que não está no acervo	o atendente recebe "não sei" às vezes onde uma busca manual mais paciente acharia a resposta
Frequência de reingestão	job disparado por evento de escrita no S3	reingestão agendada a cada N horas	documento alterado pelo jurídico aparece em minutos, não no fim do dia	evento perdido, raro, atrasa a atualização até a próxima escrita disparar de novo
Onde a citação é validada	golden set de 40 perguntas com resposta conhecida, revisado por humano	confiar na taxa de satisfação do atendente	dá um número comparável entre versões de prompt e de chunking	40 perguntas não cobrem toda pergunta possível — é amostra, não garantia total

DecisãoOnde indexar o vetor

EscolhaOpenSearch Serverless, gerenciado pela Knowledge Base

AlternativasAurora pgvector; S3 Vectors; OpenSearch provisionado

Motivozero servidor para operar, e a Knowledge Base já cuida do ciclo de vida do índice

O que se perdemenos controle sobre o algoritmo de busca e sobre custo por hora fixo — é a comparação do L84

DecisãoTamanho do chunk

Escolha500 tokens, 20% de sobreposição

Alternativaschunk por documento inteiro; chunk semântico por seção

Motivoa maior tabela de garantia por categoria cabe inteira num chunk, sem cortar linha

O que se perdetrecho maior às vezes traz contexto irrelevante junto com o relevante

DecisãoO que fazer sem trecho relevante

Escolharesponder "não encontrei isso nos documentos"

Alternativasdeixar o modelo completar com o que sabe do treino

Motivoevita fabricar resposta sobre o que não está no acervo

O que se perdeo atendente recebe "não sei" às vezes onde uma busca manual mais paciente acharia a resposta

DecisãoFrequência de reingestão

Escolhajob disparado por evento de escrita no S3

Alternativasreingestão agendada a cada N horas

Motivodocumento alterado pelo jurídico aparece em minutos, não no fim do dia

O que se perdeevento perdido, raro, atrasa a atualização até a próxima escrita disparar de novo

DecisãoOnde a citação é validada

Escolhagolden set de 40 perguntas com resposta conhecida, revisado por humano

Alternativasconfiar na taxa de satisfação do atendente

Motivodá um número comparável entre versões de prompt e de chunking

O que se perde40 perguntas não cobrem toda pergunta possível — é amostra, não garantia total

⚠️

A dívida que este laboratório não paga

Construir: a base de conhecimento (S3 → chunking → embedding → índice)

base-conhecimento.tf

# base-conhecimento.tf — bucket de documentos, índice vetorial e a Knowledge Base
# que os conecta. Confira a versão do provider AWS antes de aplicar: os recursos
# aws_bedrockagent_* e aws_opensearchserverless_* mudaram de shape mais de uma vez
# desde que Knowledge Bases foi lançado.

resource "aws_s3_bucket" "documentos_atendimento" {
  bucket = "cadencia-documentos-atendimento"
  tags = { squad = "atendimento", projeto = "rag-politica", lab = "L83" }
}

resource "aws_s3_bucket_versioning" "documentos_atendimento" {
  bucket = aws_s3_bucket.documentos_atendimento.id
  versioning_configuration { status = "Enabled" }
  # versionamento evita que uma sobrescrita do jurídico apague, sem histórico, a
  # versão anterior de uma política — o mesmo cuidado que o L62 já aplica ao lake.
}

# ── Índice vetorial: OpenSearch Serverless, com as duas políticas que ele exige ──
resource "aws_opensearchserverless_security_policy" "criptografia" {
  name = "cadencia-rag-criptografia"
  type = "encryption"
  policy = jsonencode({
    Rules = [{ ResourceType = "collection", Resource = ["collection/cadencia-rag-*"] }]
    AWSOwnedKey = true
  })
}

resource "aws_opensearchserverless_security_policy" "rede" {
  name = "cadencia-rag-rede"
  type = "network"
  policy = jsonencode([{
    Rules = [{ ResourceType = "collection", Resource = ["collection/cadencia-rag-*"] }]
    AllowFromPublic = false
    SourceVPCEs = [aws_ec2_managed_prefix_list.acesso_kb.id]
  }])
}

resource "aws_opensearchserverless_collection" "base_conhecimento" {
  name = "cadencia-rag-politica-atendimento"
  type = "VECTORSEARCH"
  depends_on = [
    aws_opensearchserverless_security_policy.criptografia,
    aws_opensearchserverless_security_policy.rede,
  ]
}

# ── Papel que a Knowledge Base assume para ler o S3 e chamar o modelo de embedding ──
resource "aws_iam_role" "knowledge_base" {
  name = "cadencia-rag-knowledge-base-role"
  assume_role_policy = data.aws_iam_policy_document.confianca_bedrock.json
}

resource "aws_iam_role_policy" "kb_acesso_restrito" {
  role = aws_iam_role.knowledge_base.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["s3:GetObject", "s3:ListBucket"]
        # Resource especifico do bucket de documentos — nao "arn:aws:s3:::*".
        Resource = [
          aws_s3_bucket.documentos_atendimento.arn,
          "${aws_s3_bucket.documentos_atendimento.arn}/*",
        ]
      },
      {
        Effect = "Allow"
        Action = ["bedrock:InvokeModel"]
        # Restrito ao MODELO DE EMBEDDING, nao a bedrock:* — a Knowledge Base nunca
        # gera texto de resposta, so vetoriza.
        Resource = ["arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0"]
      },
      {
        Effect = "Allow"
        Action = ["aoss:APIAccessAll"]
        Resource = [aws_opensearchserverless_collection.base_conhecimento.arn]
      },
    ]
  })
}

resource "aws_bedrockagent_knowledge_base" "politica_atendimento" {
  name     = "cadencia-politica-atendimento"
  role_arn = aws_iam_role.knowledge_base.arn

  knowledge_base_configuration {
    type = "VECTOR"
    vector_knowledge_base_configuration {
      embedding_model_arn = "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0"
    }
  }

  storage_configuration {
    type = "OPENSEARCH_SERVERLESS"
    opensearch_serverless_configuration {
      collection_arn    = aws_opensearchserverless_collection.base_conhecimento.arn
      vector_index_name = "cadencia-politica-index"
      field_mapping {
        vector_field   = "embedding"
        text_field     = "texto"
        metadata_field = "metadados"
      }
    }
  }
}

resource "aws_bedrockagent_data_source" "documentos" {
  knowledge_base_id = aws_bedrockagent_knowledge_base.politica_atendimento.id
  name               = "documentos-juridico-e-catalogo"

  data_source_configuration {
    type = "S3"
    s3_configuration { bucket_arn = aws_s3_bucket.documentos_atendimento.arn }
  }

  vector_ingestion_configuration {
    chunking_configuration {
      chunking_strategy = "FIXED_SIZE"
      fixed_size_chunking_configuration {
        max_tokens         = 500
        overlap_percentage = 20
        # 20% de sobreposicao e o numero calibrado pela maior tabela de garantia
        # por categoria do acervo — ver a secao de prova para o efeito medido.
      }
    }
  }
}

⚠️

A primeira ingestão não é o padrão de operação

Construir: a consulta com citação (C#/.NET 8)

ServicoRespostaComCitacao.cs

// ServicoRespostaComCitacao.cs — chama RetrieveAndGenerate em vez de InvokeModel
// puro. A diferenca estrutural em relacao ao cliente do L81 nao e o SDK, e o que
// a chamada FAZ: busca antes de gerar, e devolve a fonte junto da resposta.

public class ServicoRespostaComCitacao
{
    private readonly AmazonBedrockAgentRuntimeClient _cliente = new();

    private const string KnowledgeBaseId = "KB7F3A9C1D";
    private const string ModeloArn =
        "arn:aws:bedrock:us-east-1:111122223333:inference-profile/us.anthropic.claude-sonnet-4-20250514-v1:0";

    // Instrucao de fundamentacao: o unico lugar do sistema que probe o modelo de
    // completar com conhecimento geral quando o contexto recuperado nao basta.
    private const string InstrucaoDeFundamentacao =
        "Responda SOMENTE com base nos trechos em $search_results$. " +
        "Se os trechos nao contiverem a resposta, diga que nao encontrou essa " +
        "informacao nos documentos da Cadência — nunca complete com conhecimento geral.";

    public async Task<RespostaComCitacao> ResponderAsync(string pergunta)
    {
        var pedido = new RetrieveAndGenerateRequest
        {
            Input = new RetrieveAndGenerateInput { Text = pergunta },
            RetrieveAndGenerateConfiguration = new RetrieveAndGenerateConfiguration
            {
                Type = RetrieveAndGenerateType.KNOWLEDGE_BASE,
                KnowledgeBaseConfiguration = new KnowledgeBaseRetrieveAndGenerateConfiguration
                {
                    KnowledgeBaseId = KnowledgeBaseId,
                    ModelArn = ModeloArn,
                    GenerationConfiguration = new GenerationConfiguration
                    {
                        PromptTemplate = new PromptTemplate { TextPromptTemplate = InstrucaoDeFundamentacao },
                    },
                },
            },
        };

        var resposta = await _cliente.RetrieveAndGenerateAsync(pedido);

        // Cada citacao aponta pro trecho (chunk) e pro documento de origem — e isso
        // que vira o link clicavel na tela do atendente, nao um resumo sem fonte.
        var citacoes = resposta.Citations
            .SelectMany(c => c.RetrievedReferences)
            .Select(r => new Citacao(r.Content.Text, r.Location.S3Location.Uri))
            .ToList();

        if (citacoes.Count == 0)
        {
            // Sem trecho recuperado, a resposta NAO sai como sugestao pronta para
            // copiar — vira "nao encontrei isso nos documentos", nunca uma invencao.
            return RespostaComCitacao.SemFonte();
        }

        return new RespostaComCitacao(resposta.Output.Text, citacoes);
    }
}

Segurança: quem pode chamar o modelo e a base

policy-funcao-atendimento.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ChamarModeloDeGeracaoRestrito",
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel", "bedrock:Retrieve", "bedrock:RetrieveAndGenerate"],
      "Resource": [
        "arn:aws:bedrock:us-east-1:111122223333:inference-profile/us.anthropic.claude-sonnet-4-20250514-v1:0",
        "arn:aws:bedrock:us-east-1:111122223333:knowledge-base/KB7F3A9C1D"
      ]
    },
    {
      "Sid": "SemAcessoAOutraKnowledgeBase",
      "Effect": "Deny",
      "Action": ["bedrock:Retrieve", "bedrock:RetrieveAndGenerate"],
      "NotResource": "arn:aws:bedrock:us-east-1:111122223333:knowledge-base/KB7F3A9C1D"
    }
  ]
}

💡

Por que o Deny explícito, e não só a ausência de Allow

Implantar, e provar com número

A prova não é "a resposta parece melhor" — é rodar o mesmo conjunto de 40 perguntas duas vezes, contra os dois desenhos, e contar.

prova.sh

# prova.sh — roda o MESMO golden set de 40 perguntas contra os dois desenhos, e
# conta. Nenhuma conclusao aqui vem de "a resposta parece melhor".

GOLDEN_SET=golden-set-politica-cadencia.jsonl  # 40 linhas: {pergunta, resposta_oficial}

# ── Rodada 1: LLM direto (Figura 1), sem nenhuma recuperacao ─────────────────
python3 avaliar.py --endpoint sugerir-resposta --golden "$GOLDEN_SET" \
  --saida resultado-sem-rag.json
# Resultado medido: 14 de 40 corretas (35,0%); 0 de 40 com trecho citavel;
# latencia media 700 ms

# ── Rodada 2: RAG (Figura 2), com recuperacao e citacao ──────────────────────
python3 avaliar.py --endpoint responder-com-citacao --golden "$GOLDEN_SET" \
  --saida resultado-com-rag.json
# Resultado medido: 37 de 40 corretas (92,5%); 37 de 40 com trecho citavel;
# latencia p95 1,6 s

# ── Diagnostico dos 3 erros residuais ─────────────────────────────────────────
jq '.[] | select(.correto == false)' resultado-com-rag.json
# 2 casos: tabela de garantia cortada no limite do chunk — o trecho recuperado
#          continha a categoria, mas nao o prazo, que ficava no chunk seguinte.
# 1 caso:  duas versoes da politica de frete no bucket (a antiga nao tinha sido
#          arquivada) — a busca recuperou um trecho da versao errada.

Prova	Antes — LLM direto (Figura 1)	Depois — com RAG (Figura 2)	O que mudou
Taxa de acerto no golden set (40 perguntas)	14/40 — 35,0%	37/40 — 92,5%	a recuperação deu ao modelo o trecho que ele nunca teve no treino
Respostas com trecho citável	0/40 — 0%	37/40 — 92,5%	RetrieveAndGenerate só gera resposta a partir de trecho recuperado
Latência p95 por pergunta	≈700 ms	≈1,6 s	a busca soma tempo, mas ainda cabe no orçamento de 3 s declarado para o atendimento
Respostas que assumem "não sei" quando devia	0/40 (sempre respondia algo)	1/40 (é um acerto)	RAG pode recusar responder quando o acervo não cobre; o LLM direto nunca recusava
Erros residuais, e a causa de cada um	—	2 de tabela cortada no limite do chunk, 1 de documento duplicado no bucket	os 3 apontam para decisão de chunking e higiene do acervo — não para falha do padrão RAG

ProvaTaxa de acerto no golden set (40 perguntas)

Antes — LLM direto (Figura 1)14/40 — 35,0%

Depois — com RAG (Figura 2)37/40 — 92,5%

O que mudoua recuperação deu ao modelo o trecho que ele nunca teve no treino

ProvaRespostas com trecho citável

Antes — LLM direto (Figura 1)0/40 — 0%

Depois — com RAG (Figura 2)37/40 — 92,5%

O que mudouRetrieveAndGenerate só gera resposta a partir de trecho recuperado

ProvaLatência p95 por pergunta

Antes — LLM direto (Figura 1)≈700 ms

Depois — com RAG (Figura 2)≈1,6 s

O que mudoua busca soma tempo, mas ainda cabe no orçamento de 3 s declarado para o atendimento

ProvaRespostas que assumem "não sei" quando devia

Antes — LLM direto (Figura 1)0/40 (sempre respondia algo)

Depois — com RAG (Figura 2)1/40 (é um acerto)

O que mudouRAG pode recusar responder quando o acervo não cobre; o LLM direto nunca recusava

ProvaErros residuais, e a causa de cada um

Antes — LLM direto (Figura 1)—

Depois — com RAG (Figura 2)2 de tabela cortada no limite do chunk, 1 de documento duplicado no bucket

O que mudouos 3 apontam para decisão de chunking e higiene do acervo — não para falha do padrão RAG

⚠️

A taxa de acerto aponta ONDE olhar, não conserta sozinha

Quebrar de propósito: quatro falhas, e a que reintroduz o problema original

Falha injetada	Como injetar	Sintoma enganoso	Diagnóstico correto
Documento removido do bucket, índice não sincronizado	Apagar a política de garantia do S3 e perguntar sobre garantia sem reingerir	A resposta vem completa, com citação apontando para um arquivo que não existe mais. Nada no log indica problema	O índice vetorial é uma CÓPIA do acervo, não uma visão dele. Enquanto a ingestão não roda, o índice responde por um mundo que já mudou. O sintoma inverso é o perigoso: documento ATUALIZADO e não reingerido faz o sistema citar, com fonte e confiança, a política revogada. Toda alteração de documento precisa disparar reingestão, e o painel precisa mostrar a idade da última sincronização
Pergunta cuja resposta não está no acervo	Perguntar sobre uma política que a Cadência nunca escreveu — férias, por exemplo	O modelo responde bem, de forma plausível, sobre política de férias de e-commerce em geral	É o defeito do L81 voltando por dentro do RAG. Recuperação que não encontra nada relevante ainda assim devolve os trechos MENOS distantes, e o modelo redige em cima deles ou do que sabe de treino. A defesa não é o prompt pedir para não inventar: é um piso de score de relevância abaixo do qual a aplicação responde "não encontrei" sem chamar geração nenhuma. Sem esse piso, o RAG não elimina a alucinação — só a acompanha de uma citação
Chunk cortando a tabela de prazos ao meio	Reduzir o tamanho do chunk e reingerir a política de garantia, que tem os prazos numa tabela	A resposta cita o trecho certo do documento certo. E dá o prazo errado	O trecho recuperado contém o cabeçalho da tabela e não a linha da categoria, ou a linha sem o cabeçalho que diz o que a coluna significa. A citação está correta — ela aponta para onde o modelo leu — e o conteúdo lá não sustenta a resposta. Citação prova PROVENIÊNCIA, nunca correção. É o defeito residual que o L85 reabre e diagnostica de novo com outro instrumento
Documento duplicado no acervo, em versões diferentes	Subir a política de devolução duas vezes, uma com o prazo antigo	As duas versões são recuperadas, o modelo escolhe uma, e a resposta é internamente coerente	O acervo passou a conter uma contradição, e não existe nada no desenho que detecte contradição — a recuperação otimiza semelhança com a pergunta, não consistência entre trechos. Higiene de acervo não é tarefa de arrumação: é requisito de correção. Um único documento por assunto, com versão, e ingestão que substitui em vez de acrescentar

Falha injetadaDocumento removido do bucket, índice não sincronizado

Como injetarApagar a política de garantia do S3 e perguntar sobre garantia sem reingerir

Sintoma enganosoA resposta vem completa, com citação apontando para um arquivo que não existe mais. Nada no log indica problema

Falha injetadaPergunta cuja resposta não está no acervo

Como injetarPerguntar sobre uma política que a Cadência nunca escreveu — férias, por exemplo

Sintoma enganosoO modelo responde bem, de forma plausível, sobre política de férias de e-commerce em geral

Falha injetadaChunk cortando a tabela de prazos ao meio

Como injetarReduzir o tamanho do chunk e reingerir a política de garantia, que tem os prazos numa tabela

Sintoma enganosoA resposta cita o trecho certo do documento certo. E dá o prazo errado

Falha injetadaDocumento duplicado no acervo, em versões diferentes

Como injetarSubir a política de devolução duas vezes, uma com o prazo antigo

Sintoma enganosoAs duas versões são recuperadas, o modelo escolhe uma, e a resposta é internamente coerente

⚠️

As quatro produzem resposta com citação

Quiz rápido

Um atendente pergunta ao LLM "qual a política de devolução de material elétrico da Cadência?" e recebe uma resposta fluente e específica, mas errada. O modelo foi treinado com bilhões de documentos — por que ele não sabe a política real da Cadência?

Observabilidade: as perguntas que o painel tem de responder

Qual a proporção de respostas SEM nenhuma citação nos últimos sete dias? É o indicador direto de recuperação vazia — e cada uma delas é uma resposta gerada do conhecimento de treino, não do acervo da Cadência.
Qual o score de relevância do melhor trecho recuperado, em distribuição? A cauda inferior dessa distribuição é o conjunto de perguntas que o acervo não cobre.
Quanto tempo faz desde a última sincronização bem-sucedida da base de conhecimento?
Quais documentos do acervo NUNCA foram recuperados em 30 dias? São peso morto no índice, ou assunto sobre o qual ninguém pergunta — e as duas conclusões mudam o que fazer.
Qual a divisão da latência entre recuperação e geração? Elas escalam por motivos diferentes e a soma esconde qual das duas piorou.
Quantas respostas o atendente editou antes de enviar ao cliente? É o único sinal de qualidade que vem de humano, e é o mais valioso do painel.

Alarme	Limiar inicial	O que ele pega
RespostasSemCitacao	acima de 5% da janela de 1 hora	recuperação devolvendo vazio — acervo incompleto, índice corrompido ou ingestão quebrada
IdadeDaSincronizacao	acima de 24 horas	documento atualizado no S3 que o índice ainda não conhece: a primeira falha injetada, detectada antes de alguém citar política revogada
ScoreMaximoBaixo	melhor trecho abaixo do piso de relevância em mais de 10% das perguntas da hora	lacuna de acervo — um assunto novo que os clientes começaram a perguntar
LatenciaRecuperacaoP95	acima do dobro da linha de base medida na implantação	degradação do índice conforme o acervo cresce, separada da latência do modelo
TaxaDeEdicaoPeloAtendente	acima da linha de base medida nas duas primeiras semanas	queda de qualidade percebida por quem usa, antes de qualquer métrica técnica mudar

AlarmeRespostasSemCitacao

Limiar inicialacima de 5% da janela de 1 hora

O que ele pegarecuperação devolvendo vazio — acervo incompleto, índice corrompido ou ingestão quebrada

AlarmeIdadeDaSincronizacao

Limiar inicialacima de 24 horas

O que ele pegadocumento atualizado no S3 que o índice ainda não conhece: a primeira falha injetada, detectada antes de alguém citar política revogada

AlarmeScoreMaximoBaixo

Limiar inicialmelhor trecho abaixo do piso de relevância em mais de 10% das perguntas da hora

O que ele pegalacuna de acervo — um assunto novo que os clientes começaram a perguntar

AlarmeLatenciaRecuperacaoP95

Limiar inicialacima do dobro da linha de base medida na implantação

O que ele pegadegradação do índice conforme o acervo cresce, separada da latência do modelo

AlarmeTaxaDeEdicaoPeloAtendente

Limiar inicialacima da linha de base medida nas duas primeiras semanas

O que ele pegaqueda de qualidade percebida por quem usa, antes de qualquer métrica técnica mudar

Escala: 1.200 perguntas por dia, 12 mil, 120 mil — e a perda de uma zona

Ordem de grandeza	O que muda no desenho	O que NÃO muda
1.200 perguntas/dia, 4 documentos (hoje)	Nada. A base gerenciada absorve isso sem tuning, e o gargalo é humano — o atendente lendo a sugestão	O piso de custo do índice vetorial, que existe desde a primeira pergunta e independe do volume
12 mil perguntas/dia, 400 documentos	A ingestão deixa de ser evento raro e vira pipeline: reingerir tudo a cada mudança passa a ser caro e lento, e a atualização precisa ser incremental. O limite de taxa do modelo de geração passa a ser sentido no pico da tarde	A forma da chamada. Recuperar-e-gerar continua sendo uma requisição, e a aplicação continua sem montar prompt
120 mil perguntas/dia, 40 mil documentos	A recuperação vira o gargalo antes da geração, e a qualidade do ranking passa a dominar a qualidade da resposta — é onde o L85 deixa de ser refinamento e vira necessidade. Cache de resposta para perguntas repetidas (L89) passa a pagar sozinho	A necessidade de piso de relevância e de higiene de acervo, que já eram obrigatórias com 4 documentos
Perda de uma zona de disponibilidade	A base de conhecimento gerenciada e o modelo continuam respondendo — são serviços regionais, não zonais. O que cai é a sua aplicação, se ela estiver em uma zona só	A resposta correta aqui é a do L01, sem novidade: tarefas em duas zonas atrás do balanceador. A camada de IA deste laboratório não acrescenta requisito zonal nenhum
Perda da região inteira	Tudo para. O índice vive numa região, e reconstruí-lo em outra leva o tempo de uma ingestão completa do acervo	É o que o L99 trata, e o número que interessa não é o RTO da aplicação — é o tempo de reingestão do acervo, que ninguém mede até precisar

Ordem de grandeza1.200 perguntas/dia, 4 documentos (hoje)

O que muda no desenhoNada. A base gerenciada absorve isso sem tuning, e o gargalo é humano — o atendente lendo a sugestão

O que NÃO mudaO piso de custo do índice vetorial, que existe desde a primeira pergunta e independe do volume

Ordem de grandeza12 mil perguntas/dia, 400 documentos

O que NÃO mudaA forma da chamada. Recuperar-e-gerar continua sendo uma requisição, e a aplicação continua sem montar prompt

Ordem de grandeza120 mil perguntas/dia, 40 mil documentos

O que NÃO mudaA necessidade de piso de relevância e de higiene de acervo, que já eram obrigatórias com 4 documentos

Ordem de grandezaPerda de uma zona de disponibilidade

O que muda no desenhoA base de conhecimento gerenciada e o modelo continuam respondendo — são serviços regionais, não zonais. O que cai é a sua aplicação, se ela estiver em uma zona só

O que NÃO mudaA resposta correta aqui é a do L01, sem novidade: tarefas em duas zonas atrás do balanceador. A camada de IA deste laboratório não acrescenta requisito zonal nenhum

Ordem de grandezaPerda da região inteira

O que muda no desenhoTudo para. O índice vive numa região, e reconstruí-lo em outra leva o tempo de uma ingestão completa do acervo

O que NÃO mudaÉ o que o L99 trata, e o número que interessa não é o RTO da aplicação — é o tempo de reingestão do acervo, que ninguém mede até precisar

Custo: as quatro dimensões, e a que cresce sem ninguém mexer em nada

A intuição diz que RAG custa o preço do modelo. A fatura mostra quatro linhas, e a que mais surpreende não é nenhuma das duas óbvias.

ƒ Custo mensal do RAG de atendimento

trechos_ingeridos × preço_embedding × reingestões

Transformar documento em vetor

piso_do_índice_vetorial

Manter o índice existindo

tok_contexto

Os trechos recuperados entrando no prompt

tok_resposta

O que o modelo escreve

Cobrado mais caro por token que a entrada, e muito menor em volume. Limitar o tamanho da resposta ajuda a experiência antes de ajudar a fatura.

Cenário	O que domina	O que ninguém nota
Protótipo — 4 documentos, 50 perguntas por dia	O piso do índice vetorial, sozinho, é praticamente a conta inteira	Um RAG parado custa quase o mesmo que um RAG em uso nesta escala. Piloto esquecido ligado é a forma mais comum de desperdício desta banda
Produção — 1.200 perguntas por dia	O contexto recuperado passa a dominar: milhares de tokens de entrada, 1.200 vezes por dia	Reduzir de cinco para três trechos recuperados corta a maior linha da conta em quase 40% — e só é seguro fazer isso medindo o acerto contra o golden set, que é exatamente o instrumento que este laboratório constrói
Acervo vivo — jurídico revisando política toda semana	A reingestão passa a competir com o uso	Reingestão completa semanal de um acervo grande pode custar mais que as perguntas do mês. Ingestão incremental não é otimização prematura aqui — é a diferença entre custo proporcional ao acervo e custo proporcional ao acervo vezes a frequência de revisão

CenárioProtótipo — 4 documentos, 50 perguntas por dia

O que dominaO piso do índice vetorial, sozinho, é praticamente a conta inteira

O que ninguém notaUm RAG parado custa quase o mesmo que um RAG em uso nesta escala. Piloto esquecido ligado é a forma mais comum de desperdício desta banda

CenárioProdução — 1.200 perguntas por dia

O que dominaO contexto recuperado passa a dominar: milhares de tokens de entrada, 1.200 vezes por dia

CenárioAcervo vivo — jurídico revisando política toda semana

O que dominaA reingestão passa a competir com o uso

💡

A conta que decide

Well-Architected nos seis pilares

Pilar	Situação hoje	Risco	Melhoria	Prioridade
Excelência operacional	Ingestão disparada à mão quando alguém lembra	Índice defasado respondendo política revogada com citação	Ingestão disparada por evento de escrita no bucket, com alarme de idade da sincronização	Alta
Segurança	Papel escopado à base específica; documentos internos num bucket privado	O acervo inteiro é visível a qualquer pergunta — não há noção de quem pode ver o quê	Filtro de permissão por fonte na recuperação, que é exatamente o L93	Alta se o acervo passar a ter documento restrito; irrelevante enquanto tudo for política pública
Confiabilidade	Serviços gerenciados regionais; aplicação em duas zonas	A região é ponto único, e reconstruir o índice em outra leva o tempo de uma ingestão completa	Medir o tempo de reingestão do acervo e declará-lo como RTO real; o desenho multi-região é o L99	Média
Eficiência de desempenho	Recuperação vetorial pura, cinco trechos, sem reordenação	O trecho certo pode existir no índice e não entrar no prompt — a falha que o L85 diagnostica	Busca híbrida com reordenação (L85), medida contra o mesmo golden set	Alta — é o maior ganho de qualidade disponível
Otimização de custo	Cinco trechos recuperados por pergunta, sem cache	O contexto recuperado é a maior linha da fatura e ninguém mediu se cinco trechos são melhores que três	Medir acerto por número de trechos e ajustar; cache de resposta para pergunta repetida (L89)	Média
Sustentabilidade	Índice provisionado 24 horas para tráfego de horário comercial	Capacidade ociosa à noite e no fim de semana	Avaliar backend com cobrança por requisição para acervo pequeno — a comparação do L84	Baixa

PilarExcelência operacional

Situação hojeIngestão disparada à mão quando alguém lembra

RiscoÍndice defasado respondendo política revogada com citação

MelhoriaIngestão disparada por evento de escrita no bucket, com alarme de idade da sincronização

PrioridadeAlta

PilarSegurança

Situação hojePapel escopado à base específica; documentos internos num bucket privado

RiscoO acervo inteiro é visível a qualquer pergunta — não há noção de quem pode ver o quê

MelhoriaFiltro de permissão por fonte na recuperação, que é exatamente o L93

PrioridadeAlta se o acervo passar a ter documento restrito; irrelevante enquanto tudo for política pública

PilarConfiabilidade

Situação hojeServiços gerenciados regionais; aplicação em duas zonas

RiscoA região é ponto único, e reconstruir o índice em outra leva o tempo de uma ingestão completa

MelhoriaMedir o tempo de reingestão do acervo e declará-lo como RTO real; o desenho multi-região é o L99

PrioridadeMédia

PilarEficiência de desempenho

Situação hojeRecuperação vetorial pura, cinco trechos, sem reordenação

RiscoO trecho certo pode existir no índice e não entrar no prompt — a falha que o L85 diagnostica

MelhoriaBusca híbrida com reordenação (L85), medida contra o mesmo golden set

PrioridadeAlta — é o maior ganho de qualidade disponível

PilarOtimização de custo

Situação hojeCinco trechos recuperados por pergunta, sem cache

RiscoO contexto recuperado é a maior linha da fatura e ninguém mediu se cinco trechos são melhores que três

MelhoriaMedir acerto por número de trechos e ajustar; cache de resposta para pergunta repetida (L89)

PrioridadeMédia

PilarSustentabilidade

Situação hojeÍndice provisionado 24 horas para tráfego de horário comercial

RiscoCapacidade ociosa à noite e no fim de semana

MelhoriaAvaliar backend com cobrança por requisição para acervo pequeno — a comparação do L84

PrioridadeBaixa

Onde mais IA entra neste RAG, e onde ela só acrescenta custo

O laboratório inteiro é IA, então a pergunta útil é onde cabe mais um modelo. Três candidatos aparecem sempre nesta conversa, e só um deles se paga aqui.

Ideia	Vale a pena?	Por quê
Um modelo reordenando os trechos recuperados	Sim, e é o próximo laboratório	É o único ponto da lista em que um modelo enxerga o que a busca vetorial não enxerga: ele lê a pergunta e o trecho JUNTOS, em vez de comparar dois vetores produzidos separadamente. Dois dos três erros residuais deste laboratório são exatamente disso, e o L85 mede o ganho contra o mesmo golden set
Um modelo decidindo se vale a pena buscar antes de buscar	Não	Acrescenta uma chamada de modelo em toda pergunta para evitar uma busca que custa uma fração dela. E erra: a decisão "isto está no acervo?" só pode ser respondida com confiança DEPOIS de buscar, olhando o score de relevância — que é grátis, determinístico e já está na resposta
Um modelo gerando as perguntas do golden set	Parcialmente, e com cuidado	Serve para AMPLIAR cobertura a partir de perguntas reais do chat, e não serve para criar o gabarito: gabarito conferido por modelo mede o quanto dois modelos concordam, não o quanto o sistema acerta. A pergunta pode ser gerada; a resposta esperada precisa de humano que conheça a política

IdeiaUm modelo reordenando os trechos recuperados

Vale a pena?Sim, e é o próximo laboratório

IdeiaUm modelo decidindo se vale a pena buscar antes de buscar

Vale a pena?Não

IdeiaUm modelo gerando as perguntas do golden set

Vale a pena?Parcialmente, e com cuidado

Anti-padrões deste laboratório

Anti-padrão	Por que alguém faz	Sintoma em produção	Forma correta
Perguntar direto ao LLM sem nenhuma recuperação	é o caminho mais rápido para uma demo, e funciona bem o suficiente até alguém perguntar algo específico	resposta plausível e errada, sem fonte, aceita pelo atendente sem checar	recuperar o trecho relevante ANTES de gerar qualquer palavra da resposta
Instruir "responda com precisão e não invente" sem dar contexto	parece que uma instrução de comportamento resolve o que na verdade é falta de dado	a taxa de acerto sobe pouco ou nada, porque o modelo continua sem acesso ao documento real	dar o TRECHO certo no prompt — instrução sem dado não cria conhecimento
Chunk grande demais, "para não perder contexto"	intuitivamente parece mais seguro incluir mais texto do que menos	a recuperação traz páginas inteiras; o modelo tem de achar a informação certa dentro do próprio contexto, e às vezes erra por excesso	chunk do tamanho da unidade de resposta, com sobreposição pequena e calibrada
Reindexar o acervo inteiro a cada alteração pequena	é mais simples de implementar do que detectar exatamente o que mudou	job de ingestão caro e demorado rodando por uma vírgula corrigida num documento	ingestão incremental, disparada pelo evento de escrita do objeto específico
Confiar na taxa de satisfação do atendente como medida de qualidade	é o número que já existe, sem construir nada novo para medir	o atendente aceita resposta errada com confiança porque o texto parece bem escrito — fluência não é acurácia	golden set com resposta oficial conhecida, comparado por acerto, não por impressão