Advanced RAG: Patterns, Retrieval Optimization, and Reranking
Explore advanced RAG workflows focusing on retrieval patterns, metadata filters, query decomposition, and reranking to optimize AI knowledge bases. Understand how to choose architectures, tune retrieval with evidence, and build reliable pipelines using AWS Bedrock services.
We'll cover the following...
The previous lesson built a basic RAG flow: chunk, embed, retrieve the top k chunks, and generate. In production that flow fails in predictable ways. A part number returns chunks about similar parts. A policy question gets the right answer for the wrong country. The best chunk is ranked eighth and never reaches the model. A two-part question gets half an answer.
Most of these failures are fixed by settings on the retrieval request, not by new infrastructure. Retrieval is done when the right chunks come back at the top for representative queries, the score, location, and metadata of each result show why, and the pattern fits the shape of the data: documents, tables, or connected entities.
The diagram below shows the stages of a tuned retrieval pipeline and where each technique in this lesson acts.
Choosing a RAG architecture pattern
The pattern follows from the shape of the data and the kind of question users ask. Amazon Bedrock Knowledge Bases covers most patterns with a different knowledge base type or store, so the choice is usually a configuration, not a custom build.
The following table compares the patterns the exam expects you to recognize.
RAG architecture patterns on AWS
Pattern | Data and Questions | AWS Implementation | Typical Exam Signal |
Vector RAG (semantic search) | Unstructured documents, natural-language questions | Bedrock knowledge base with a vector store | “Answer questions from manuals and policies” |
Hybrid search | Documents that mix prose with exact identifiers | Same knowledge base with the | “Part numbers, error codes, or SKUs aren’t matched” |
Structured data retrieval | Tables in a data warehouse, questions that need aggregation | Knowledge base connected to a structured data store, with Amazon Redshift as the query engine | “Total sales by region last quarter” |
GraphRAG | Facts spread across documents and linked by entities | Knowledge base with Amazon Neptune Analytics | “Connect related facts across many documents” |
Agentic RAG | Multi-step or comparative questions, several sources | Agentic retrieval on a Bedrock Managed Knowledge Base, or an agent that calls a knowledge base | “Break the question into steps and search several sources” |
Custom pipeline | Unsupported stores, self-hosted models, streaming sources | Your own code around a vector store (previous lesson) | “Self-managed OpenSearch on EC2” |
Three of these patterns need more detail:
Structured data retrieval converts the question into SQL. Amazon Redshift (provisioned or Serverless) is the query engine, and the tables can be in Redshift or in the AWS Glue Data Catalog. Grant the knowledge base’s database user
SELECTonly, because running generated SQL is a security risk. Search type, metadata filters, and reranking apply only to unstructured data.GraphRAG runs a vector search, then follows graph links from the matching chunks to related chunks and entities, for answers that need several steps across documents. It supports only Amazon S3 data sources, 1,000 files per data source by default, and no autoscaling of the Neptune Analytics graph.
Agentic RAG uses a foundation model to split a question into sub-queries, retrieve for each, and check whether the results suffice. Agents that call knowledge bases as tools are covered in the Bedrock Agents and Guardrails lesson and in Chapter 11.
Bedrock also offers two kinds of vector knowledge base. With a customer-managed knowledge base, you choose and run the vector store ...