Skill 3.2.8: Implement retrieval pipelines to meet business needs
| Question | Answer & Explanation |
|---|---|
| ### Question 1 - Implementing Hybrid Search for E-Commerce Catalogs A retail company is building a RAG application using Amazon Bedrock Knowledge Bases. The application must retrieve semantically similar product descriptions while also ensuring exact matches for specific alphanumeric product SKUs (e.g., "AB-1234") in the same query. The vector store must support this dual requirement natively, and the team wants to use a fully managed AWS service to minimize operational overhead. Which TWO steps should the ML engineer take to fulfill these requirements? (Select TWO) - A) Select Amazon OpenSearch Serverless as the vector store for the Bedrock Knowledge Base. - B) Select Amazon Neptune as the vector store to leverage graph-based entity retrieval. - C) Enable hybrid search in the OpenSearch collection configuration to combine k-NN vector search with lexical text matching. - D) Configure a custom Lambda function to perform separate vector and keyword searches before merging them in the prompt. - E) Use Amazon S3 as the vector store, as it automatically indexes metadata for keyword filtering. |
Correct Answers: A and C Correct Options Analysis: - A is Correct: Amazon OpenSearch Serverless is a fully managed AWS service that natively integrates with Bedrock Knowledge Bases and supports advanced search capabilities, satisfying the least operational overhead requirement. - C is Correct: Hybrid search combines dense vector search (for semantic similarity) with sparse lexical search (like BM25, for exact keyword/SKU matches) in a single query. OpenSearch Serverless supports this over a filterable text field. Distractor Analysis: - B is Incorrect: Amazon Neptune is a graph database used for relationship-based retrieval, not for native hybrid (semantic + lexical) search over document text and vectors. - D is Incorrect: Writing a custom Lambda function to merge separate searches introduces unnecessary operational overhead and reinvents a feature natively supported by OpenSearch's hybrid search. - E is Incorrect: Amazon S3 can be used as a vector store for cost-effective, low-frequency queries, but it does not support native hybrid search or lexical text matching out of the box. > Key Takeaway: OpenSearch Serverless is the ideal fully managed vector store for Bedrock Knowledge Bases when hybrid search (combining semantic similarity and exact keyword matching) is required. |
| ### Question 2 - Optimizing Retrieval Relevance with Reranking A legal tech startup has deployed an enterprise Q&A bot using Amazon Bedrock Knowledge Bases with an OpenSearch vector store. Initial testing reveals that while the vector search retrieves topically relevant documents, the specific paragraphs containing the legally binding precedents are often buried at the bottom of the top 10 retrieved chunks. The team must improve the relevance order of the retrieved chunks without rewriting the ingestion pipeline or changing the embedding model. Which configuration change meets these requirements with the LEAST operational overhead? - A) Increase the top_k value in the Bedrock Knowledge Base retrieval configuration from 10 to 50.- B) Enable a reranking model (e.g., Amazon Rerank) in the Bedrock Knowledge Base retrieval configuration to re-score the retrieved chunks. - C) Change the embedding model from Amazon Titan Text Embeddings v2 to a larger dimensional model. - D) Implement a custom chunking strategy with smaller overlapping chunks and re-run the ingestion job. |
Correct Answer: B Correct Options Analysis: - B is Correct: Bedrock Knowledge Bases supports the configuration of a reranking model. After the vector store retrieves the top K candidate chunks based on semantic similarity, the reranker (a cross-encoder or specialized reranking model) re-scores them based on semantic relevance to the user's query, elevating the most precise answers to the top of the list without changing the ingestion pipeline. Distractor Analysis: - A is Incorrect: Increasing the top_k value retrieves more chunks, but it does not improve the ranking order of the most relevant chunks. It also increases token consumption and latency for the LLM generation step.- C is Incorrect: Changing the embedding model requires re-indexing the entire vector store (re-running ingestion) and does not guarantee better ordering of specific precedents within the top results compared to a dedicated reranker. - D is Incorrect: Re-chunking requires modifying the ingestion pipeline and re-running the entire ingestion job, violating the least operational overhead constraint. > Key Takeaway: Reranking models in Bedrock Knowledge Bases are applied at query time to improve the relevance order of retrieved chunks without altering the underlying vector index or ingestion pipeline. |
| ### Question 3 - Metadata Filtering for Secure Retrieval A financial services firm is building an HR document Q&A system using Amazon Bedrock Knowledge Bases. The HR documents are stored in Amazon S3 and contain sensitive salary bands restricted to management, as well as general policies available to all employees. The retrieval pipeline must ensure that an employee querying "salary bands" never retrieves management-only documents. The firm wants to enforce this at the retrieval stage before the LLM generates a response. Which feature of Bedrock Knowledge Bases should the engineer implement to satisfy this requirement? - A) Implement an Amazon Bedrock Guardrail to filter out PII in the generated response. - B) Use metadata filtering in the retrieval configuration to restrict the search to documents tagged with the user's access level. - C) Configure OpenSearch Serverless fine-grained access control to restrict read access to the index. - D) Apply S3 bucket policies to restrict access to the management-only PDF files. |
Correct Answer: B Correct Options Analysis: - B is Correct: Metadata filtering allows the retrieval pipeline to narrow the candidate set of vectors before similarity is measured. By ingesting documents with metadata (e.g., access_level: "management" or access_level: "all") and passing this metadata as a filter during the retrieval API call, the vector store will only return chunks that match the user's specific permissions.Distractor Analysis: - A is Incorrect: Bedrock Guardrails operate on the model's input and output to mask PII or block harmful content, but they do not restrict the document retrieval phase based on user roles. - C is Incorrect: While OpenSearch supports fine-grained access control, Bedrock Knowledge Bases abstracts this. The standard pattern for access control within a KB is metadata filtering at query time, not changing the index's read permissions per user dynamically. - D is Incorrect: S3 bucket policies protect the raw files in S3, but once the documents are parsed and embedded into the vector store, S3 policies have no effect on the retrieval pipeline. > Key Takeaway: Metadata filtering turns retrieval into a secure pipeline by narrowing the candidate pool based on user attributes before vector similarity is even calculated. |
| ### Question 4 - Resolving Index Dimension Mismatches A data science team is configuring an Amazon Bedrock Knowledge Base using Amazon Aurora PostgreSQL as the vector store. The team selected the Amazon Titan Text Embeddings v1 model for ingestion. During the creation of the vector store configuration, they manually set the vector index dimensions to 1024. When they start the ingestion job, it fails immediately with a configuration error. The team must resolve this with the least administrative effort.What is the root cause of this failure and how should it be fixed? - A) The index dimensions must match the output dimensions of the selected embedding model (e.g., 1536 for Titan v1); the team must update the vector store configuration. - B) Aurora PostgreSQL does not support custom dimensions; the team must switch to OpenSearch Serverless. - C) The ingestion job requires a VPC endpoint to Aurora; the team must add a private path to the database. - D) The team must use a binary vector quantization format to reduce the 1024 dimensions to match the model's output. |
Correct Answer: A Correct Options Analysis: - A is Correct: The vector index dimensions declared in the knowledge base configuration must exactly match the output dimensions of the specified embedding model. Amazon Titan Text Embeddings v1 outputs 1536 dimensions. A mismatch between the vector store schema and the embedding output will cause the ingestion job to fail when it attempts to insert the vectors. Distractor Analysis: - B is Incorrect: Aurora PostgreSQL (with the pgvector extension) does support vector dimensions up to 16,000. The issue is the mismatch with the specific model, not a limitation of Aurora.- C is Incorrect: While VPC configuration is necessary for private networking, a VPC connectivity issue would manifest as a timeout or network unreachable error, not an immediate configuration validation error regarding dimensions. - D is Incorrect: Binary vector quantization is a storage optimization technique and is not the cause of an initial schema dimension mismatch during job setup. > Key Takeaway: The index dimensions in the vector store configuration must be declared correctly before ingestion and must perfectly match the chosen embedding model's output dimensions. |
| ### Question 5 - Incremental Ingestion and Resync Operations An enterprise uses Amazon Bedrock Knowledge Bases backed by Amazon OpenSearch Serverless to index product manuals stored in an Amazon S3 bucket. New manuals are uploaded to the S3 bucket daily. The ML engineer triggers a resync of the data source. The engineering manager wants to know if the system will incur high costs by re-embedding all 50,000 existing manuals every day, and demands a cost-effective solution that only processes changes. How does the Bedrock Knowledge Base ingestion job handle this scenario natively, and what should the engineer confirm? - A) The ingestion job automatically performs a full re-indexing every time it runs; the engineer must create a separate S3 bucket for new files to avoid costs. - B) The resync automatically processes only the documents that have changed or been added since the last sync; the engineer just needs to trigger the standard ingestion job. - C) The engineer must configure an S3 Event Notification to invoke a Lambda function that selectively updates the vector store via the Bedrock API. - D) The engineer must manually specify a list of changed S3 object keys in the StartIngestionJob API call to limit the scope. |
Correct Answer: B Correct Options Analysis: - B is Correct: Bedrock Knowledge Bases natively supports incremental ingestion. When a data source sync is triggered, it checks the metadata of the S3 objects against the last sync time and only processes, chunks, and embeds the documents that are new or have been modified, significantly reducing compute costs. Distractor Analysis: - A is Incorrect: Bedrock does not perform a full re-indexing on every run unless forced; it natively handles incremental syncs based on S3 object timestamps. - C is Incorrect: Writing a custom Lambda function to handle S3 events and vector updates defeats the purpose of using Bedrock's managed ingestion pipeline and introduces unnecessary overhead. - D is Incorrect: The StartIngestionJob API does not require manually passing a list of changed S3 keys; the managed sync process detects changes automatically.> Key Takeaway: Bedrock Knowledge Bases resync operations are incremental by design, processing only new or modified files to optimize embedding compute costs. |
| ### Question 6 - Vector Store Selection for High-Volume Relational Data A logistics company is building an AI assistant to query its shipment database. The application needs to search for semantically similar delivery notes while also joining the retrieved text with structured relational data (e.g., tracking ID, delivery status) in the same query. The team already uses Amazon Aurora PostgreSQL heavily and wants to minimize the operational overhead of managing a separate vector store. The solution must be highly available. Which vector store configuration best meets these requirements? - A) Use Amazon OpenSearch Serverless and store relational data as metadata fields. - B) Use Amazon Aurora PostgreSQL with the pgvector extension as the vector store for Bedrock Knowledge Bases.- C) Use Amazon Neptune to map relationships between tracking IDs and delivery notes. - D) Use Amazon S3 and retrieve the structured data using an AWS Lambda function after vector search. |
Correct Answer: B Correct Options Analysis: - B is Correct: Aurora PostgreSQL with the pgvector extension is an integrated solution that allows vector embeddings to be stored right beside the relational records they describe. This fulfills the requirement of querying semantically similar text while natively joining with structured relational data (like tracking IDs) without managing a separate vector database, minimizing operational overhead.Distractor Analysis: - A is Incorrect: While OpenSearch can store metadata, it is not a relational database. Joining complex structured relational data is not its primary function, and it introduces a new technology stack for a team already invested in Aurora. - C is Incorrect: Amazon Neptune is a graph database. While it stores relationships, it is not the optimal choice for standard relational data joins alongside vector search. - D is Incorrect: Using S3 for vectors and Lambda for data joins introduces severe operational complexity and high latency compared to an integrated relational vector database like Aurora. > Key Takeaway: For workloads requiring semantic search alongside complex relational data joins, Amazon Aurora PostgreSQL with pgvector keeps embeddings and structured data in the same database, minimizing overhead. |
| ### Question 7 - Graph-Based Retrieval for Relationship Queries A pharmaceutical company's R&D department is building an AI application to discover new drug interactions. The data consists of highly interconnected entities: drugs, proteins, genes, and diseases. The retrieval pipeline must follow the paths between these entities to answer queries like "Which drugs interact with proteins associated with gene X?". The team wants to use a managed AWS service optimized for this specific retrieval pattern. Which vector store and search strategy should the ML engineer implement? - A) Amazon OpenSearch Serverless with hybrid search. - B) Amazon S3 with metadata filtering. - C) Amazon Neptune with SPARQL/Gremlin queries. - D) Amazon RDS for MySQL with standard SQL LIKE queries. |
Correct Answer: C Correct Options Analysis: - C is Correct: Amazon Neptune is a purpose-built graph database. For retrieval that explicitly requires following relationships and paths between interconnected entities (like drugs, genes, and proteins), a graph store supports traversals natively using query languages like Gremlin or SPARQL, which is exactly what this scenario requires. Distractor Analysis: - A is Incorrect: OpenSearch is a search service optimized for document text and vector similarity, not for traversing complex, multi-hop relationship graphs. - B is Incorrect: S3 is an object store and cannot perform relationship traversals or complex graph queries. - D is Incorrect: While SQL can perform JOINs, querying multi-hop relationships in a relational database is highly inefficient and complex compared to a native graph database. > Key Takeaway: When the core business requirement is to retrieve information by traversing interconnected entities and relationships, Amazon Neptune (a graph database) is the correct architectural choice. |
| ### Question 8 - Cost-Optimized Vector Storage for Infrequent Queries A media archive stores millions of historical video transcripts. The team wants to build a RAG application using Amazon Bedrock Knowledge Bases to allow researchers to search these transcripts semantically. The queries will be very infrequent (a few dozen per month), but the dataset is massive (over 500 million vectors). The primary constraint is minimizing the ongoing storage cost of the vector database, while accepting higher query latency. Which vector store configuration best meets these requirements? - A) Amazon OpenSearch Service (Managed Cluster) with high memory instances. - B) Amazon Aurora PostgreSQL with pgvector.- C) Amazon S3 as the vector store. - D) Amazon OpenSearch Serverless. |
Correct Answer: C Correct Options Analysis: - C is Correct: Amazon S3 is supported as a vector store for Bedrock Knowledge Bases. It is the most cost-effective option for storing massive datasets (like millions of transcripts) that are queried infrequently. It trades off higher query latency for significantly lower storage costs compared to always-on database solutions. Distractor Analysis: - A is Incorrect: A managed OpenSearch cluster requires provisioning expensive EC2 instances with high memory, which incurs high ongoing costs regardless of query frequency, violating the cost constraint. - B is Incorrect: Aurora PostgreSQL charges for compute instances and storage. For 500 million vectors, the storage and compute costs would be substantially higher than S3, especially for infrequent queries. - D is Incorrect: OpenSearch Serverless scales to zero when not in use, but storing 500 million vectors in an OpenSearch collection (which requires memory and disk overhead) is significantly more expensive than S3 for massive, cold datasets. > Key Takeaway: For massive vector datasets that are queried infrequently, Amazon S3 provides the most cost-effective storage solution, accepting a trade-off in query latency. |
| ### Question 9 - Configuring Field Mappings Pre-Ingestion A developer is creating a Bedrock Knowledge Base using Amazon OpenSearch Serverless as the vector store. The source data in Amazon S3 includes metadata in a sidecar JSON file, such as department and last_updated. The developer needs to ensure that the department field can be used to filter the search results during retrieval, and the vector embeddings are stored in a specific OpenSearch field named text_vector.What must the developer do before running the ingestion job to ensure the pipeline functions correctly? - A) Configure the field mapping in the Bedrock Knowledge Base data source configuration to map the vector, text chunk, and metadata fields before ingestion. - B) Run the ingestion job, then manually update the OpenSearch index mapping using the OpenSearch Dev Tools console. - C) Use a Lambda function to post-process the OpenSearch documents after the ingestion job completes. - D) Enable hybrid search on the OpenSearch index, which automatically detects and maps metadata fields. |
Correct Answer: A Correct Options Analysis: - A is Correct: Field mappings (mapping the vector field, text chunk field, and metadata fields) must be declared in the Bedrock Knowledge Base configuration before ingestion starts. This ensures the vector store schema is set up correctly to accept the data and that metadata is properly indexed for filtering at query time. Distractor Analysis: - B is Incorrect: OpenSearch index mappings cannot be easily modified once documents have been ingested without reindexing. They must be defined prior to data insertion. - C is Incorrect: Using a Lambda function to post-process documents introduces unnecessary custom code and overhead, and is not the standard way to handle metadata mapping in Bedrock. - D is Incorrect: Enabling hybrid search handles the text and vector search combination, but it does not automatically detect and map arbitrary custom metadata fields for filtering purposes. > Key Takeaway: Field mapping is a critical pre-ingestion step; metadata fields must be explicitly mapped in the Bedrock Knowledge Base configuration before data is indexed to be available for query-time filtering. |
| ### Question 10 - Balancing Retrieval Count and LLM Context Window An AI engineer is tuning the retrieval configuration of an Amazon Bedrock Knowledge Base for a technical support bot. The chosen LLM has a context window limit of 8,000 tokens. The current configuration retrieves the top 20 chunks ( k=20), which frequently exceeds the context window and causes API errors. The team wants to ensure the generation step receives the most relevant context without exceeding token limits, using native Bedrock features.Which configuration should the engineer modify to meet this requirement? - A) Decrease the chunk size during the ingestion job and reduce the k value in the retrieval configuration.- B) Increase the k value and switch to a larger embedding model.- C) Implement a custom orchestrator using AWS Step Functions to truncate the text before passing it to the LLM. - D) Use Amazon Bedrock Guardrails to automatically summarize the retrieved chunks. |
Correct Answer: A Correct Options Analysis: - A is Correct: Retrieving 20 chunks can easily exceed the 8,000 token limit. Reducing the k value (e.g., top 3 or 5) limits the number of retrieved passages. If the chunks themselves are too large, adjusting the chunking strategy during ingestion to smaller chunks ensures that the total retrieved context fits within the LLM's context window.Distractor Analysis: - B is Incorrect: Increasing the k value would worsen the context window overflow. The embedding model size does not dictate the output token count of the retrieved chunks.- C is Incorrect: While a custom orchestrator could truncate text, it introduces high operational overhead. Bedrock Knowledge Bases natively handles prompt assembly, and standard practice is to adjust k and chunk size to fit context limits.- D is Incorrect: Bedrock Guardrails are used for safety, content filtering, and PII redaction, not for summarizing context to fit token limits. > Key Takeaway: To prevent exceeding the LLM context window in a RAG pipeline, tune the retrieval top_k value and the document chunk size during ingestion to control the total volume of text passed to the generation model. |