AWSAWS Certified Generative AI Developer - Professional2026-101.5 Design retrieval mechanisms for FM augmentation

Require measured gains before enabling reranking

Completed by the knowledge check

Learning objective

Add Amazon Bedrock reranking only when measured relevance improvements justify latency and cost.

Core idea

Reranking improves the order of evidence you already retrieved. It does not search for missing documents, correct permissions, or prove that an answer is supported. For an architect deciding whether to add it, the useful question is whether a better ordering produces enough additional accepted answers to justify the complete request’s latency and cost.

A reranker introduces another computation, but it can also let you send fewer, more relevant passages to the generation model. AWS describes that potential reduction in generation cost and latency. Treat it as a hypothesis to measure, not a guarantee that adding a model call makes the workload cheaper or faster.

How it works

Place reranking after candidate retrieval

Amazon Bedrock reranker models calculate how relevant source chunks are to a query and reorder them using those scores. AWS documents reranking for textual data only. Do not infer image or audio reranking support from a knowledge base’s ability to retrieve those modalities.

You can integrate reranking into Knowledge Bases retrieval or call the standalone Rerank operation. For a custom knowledge base, vectorSearchConfiguration.rerankingConfiguration selects the reranking stage. Its bedrockRerankingConfiguration.modelConfiguration.modelArn identifies the model, and numberOfRerankedResults controls the result count after reranking.

Keep retrieval depth and reranked output depth distinct. numberOfResults in the vector-search configuration determines the candidates retrieved. Normally, requesting more numberOfRerankedResults than that candidate count cannot return more than numberOfResults. AWS documents an exception with query decomposition: numberOfRerankedResults can be up to five times numberOfResults. See 1.5.9 for decomposition rather than assuming every reranking request expands the candidate set.

Fully managed knowledge bases require a different baseline. With managed embeddings, AWS documents a service-managed reranker enabled by default. Under managedSearchConfiguration, rerankingModelType supports MANAGED, CUSTOM, and NONE; CUSTOM requires the custom reranking configuration. Managed reranking is available only with managed embeddings. A fully managed knowledge base using custom embeddings can use custom reranking or disable it.

The objective’s instruction to “add” reranking therefore is not the default behavior for every knowledge base. In the managed case, explicitly compare NONE with the managed or custom setting. Otherwise, your supposed no-reranker baseline might already include reranking.

Preserve result identity in a custom pipeline

The standalone Rerank operation accepts queries, sources, and rerankingConfiguration. Despite the array-shaped interface, queries contains exactly one item. sources accepts 1–1,000 items. Its Bedrock reranking configuration uses numberOfResults, not the integrated Knowledge Bases parameter numberOfRerankedResults.

The response’s results includes index, the source’s original position in the input array, and relevanceScore. Use index to reconnect the reordered result to its original content, location, and permission metadata. An application that reorders text while leaving citation metadata in the original order can produce citations to the wrong document.

Authorize evidence before submitting it to a reranking model; see 1.4.6. For standalone reranking, the application supplies the source list, so it owns this boundary. A highly relevant unauthorized source must never become a candidate for the reranker or the generator.

Make the experiment decide the rollout

Construct a labeled set that includes narrow factual questions, broad questions, exact identifiers, and unanswerable requests. Fix the corpus, authorization filters, first-stage search, candidate depth, and generator while comparing reranking settings. This isolates ordering gains rather than attributing a larger candidate pool or changed prompt to the reranker.

Amazon Bedrock Evaluations supplies the quality harness. Create one RAG evaluation job per setting, a no-reranking baseline and the reranker under test, on the same prompt dataset. In a retrieve-only job, the reranker is set through rerankingConfiguration in knowledgeBaseRetrievalConfiguration.vectorSearchConfiguration. A retrieve-only job scores the retrieved texts with Builtin.ContextRelevance and Builtin.ContextCoverage, as 1.5.7 describes for search types. A retrieve-and-generate job also scores the generated response, for example with Builtin.Correctness and Builtin.Completeness. These jobs measure quality, not latency or cost, so the measurements below still apply.

Measure how often the necessary evidence reaches the final context, its rank, the fraction of final context that is useful, and final answer acceptance. A better average rank matters only if it changes the application’s outcome. Include queries whose first-stage retrieval already succeeds; unnecessary reranking on easy questions can consume budget without adding value.

Measure both stage time and end-to-end response time, including tail latency. Record retrieved candidate count, reranked result count, input and output tokens for generation, and total workload charges. The standalone API’s returned relevanceScore is a relevance signal, not a latency or cost metric. Use application timing for the stage boundary and actual model usage and pricing for the cost comparison.

A smaller context can offset some added reranking work, but test that smaller context explicitly. Compare a baseline with an equal final context budget before evaluating a version that reduces context size. Otherwise, you cannot distinguish ordering improvements from the effects of changing how much evidence the generator receives.

Set an adoption rule before inspecting the results. For example, require a specified improvement in accepted answers for difficult queries while preserving the response-time target and approved cost per accepted answer. Those thresholds belong to the product’s service objectives; AWS does not supply a universal adoption percentage.

Key distinctions and trade-offs

Retrieval versus reranking: Retrieval determines the candidate set. Reranking orders that set. Improve first-stage recall when required evidence is absent; improve ranking when evidence is present but buried.

Relevance versus support: A reranker judges relevance to a query. It does not verify that generated claims follow from the evidence. Final answer review remains necessary.

Stage cost versus response cost: Another model stage adds work. Sending fewer passages to generation might reduce the total. Compare complete responses rather than celebrating one cheaper component.

Universal versus selective use: Running every query through reranking simplifies control flow. Routing only evidence-poor or difficult queries can save resources, but requires an evaluated routing rule and a separate baseline for each route. Do not invent such a route solely from a score seen in one demonstration.

Architecture / decision scenario

A policy assistant retrieves 30 authorized text chunks but packs only six into its generator prompt. Evaluation shows that the required exception clause often appears below rank six. The team compares the baseline with a custom Knowledge Bases reranker returning six results, using the same 30 candidates and generation settings. These counts are experimental choices.

The reranker improves accepted answers on exception questions, but routine queries show no improvement. The team measures total response latency and cost, including the smaller generation prompts in a second experiment. It retains reranking only for the evaluated query class that meets the product’s acceptance gate.

Before adopting a fully managed knowledge base, it repeats the comparison with rerankingModelType: NONE and MANAGED. It does not assume that migration preserves the no-reranking baseline or that a custom model automatically outperforms the managed option. If candidate recall falls after an ingestion change, it repairs retrieval rather than raising the reranked result count without evidence.

Common exam traps

Expecting a reranker to recover documents absent from the candidate list.
Comparing reranking with a baseline that already uses managed reranking.
Confusing integrated numberOfRerankedResults with standalone numberOfResults.
Passing multiple queries to a standalone request because queries is an array.
Applying textual reranking to every retrieved modality.
Measuring rank improvement without final answer, latency, and cost outcomes.

What to remember

Rerank authorized candidates when poor ordering is the measured problem. Preserve source identity through the returned index. Separate candidate count from final result count, and compare against a genuine no-reranking baseline. Keep the stage only when complete-response quality gains clear the workload’s latency and cost gates.