Skip to content

Skill 1.2.5: Configure and use embedding models to transform text and image data into numerical representations

A retail company is building a visual product search feature for its e-commerce platform. Customers will upload photos of clothing items, and the system must return visually similar products from the catalog. The ML team needs to generate embeddings for both customer-uploaded photos and catalog product images to enable similarity search in Amazon OpenSearch Service.

The solution must support both text descriptions and product images in a unified vector space, and the team wants to minimize the number of embedding models they manage. Additionally, embeddings must be generated through Amazon Bedrock to avoid provisioning infrastructure.

Which action should the ML engineer take to meet these requirements?

A) Call the Amazon Titan Multimodal Embeddings model through Amazon Bedrock to generate embeddings for both product images and text descriptions B) Use SageMaker to train separate CNN models for image embeddings and a transformer model for text embeddings C) Use Amazon Rekognition to extract labels from images, then encode those labels using a one-hot encoder before indexing D) Deploy a self-hosted CLIP model on Amazon EC2 and create custom inference endpoints for embedding generation E) Use Amazon Bedrock Guardrails to convert images directly into vector embeddings without a separate model

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: Amazon Titan Multimodal Embeddings (available through Amazon Bedrock) generates embeddings for text and images in a shared, unified vector space. This enables cross-modal similarity search without managing separate models for each modality, and fully managed Bedrock access eliminates infrastructure overhead.

Distractor Analysis

  • B is Incorrect: Training separate embedding models introduces high operational overhead and does not guarantee a unified vector space where text and image embeddings are directly comparable. This violates the "minimize models managed" constraint.
  • C is Incorrect: One-hot encoded labels do not capture semantic similarity in visual features. Rekognition provides categorical labels, not dense embeddings suitable for similarity search.
  • D is Incorrect: Self-hosting a CLIP model on EC2 requires significant infrastructure management (GPU instances, load balancing, scaling), violating the "minimize infrastructure" requirement.
  • E is Incorrect: Amazon Bedrock Guardrails performs content filtering, redaction, and safety checks—it does not generate embeddings.

Key Takeaway: Amazon Titan Multimodal Embeddings through Bedrock enables unified text-image vector spaces without managing separate embedding models or infrastructure.

Question 2 - Chunking Strategy for RAG with Technical Documentation

A pharmaceutical company is building a RAG-powered assistant for its regulatory affairs team. The source documents include FDA submission files, clinical trial reports, and standard operating procedures, stored as PDFs in Amazon S3. The assistant uses Amazon Bedrock Knowledge Bases with Amazon OpenSearch Serverless as the vector store.

The regulatory documents contain complex hierarchical structures with nested sections, appendices, and cross-references. Queries may target specific subsections or tables. The team wants retrieval to preserve structural context (which parent section a chunk belongs to) while maintaining semantic precision for specific queries.

Which chunking strategy should the team configure in Amazon Bedrock Knowledge Bases?

A) Fixed-size chunking with a chunk size of 300 tokens and zero overlap B) No chunking, treating each full PDF as a single embedding C) Hierarchical chunking that maintains parent-child relationships between sections and subsections D) Semantic chunking that splits documents only when topic changes are detected E) Fixed-size chunking with a chunk size of 8000 tokens and 10% overlap

Click to reveal Answer & Explanation

Correct Answer: C

Correct Option Analysis

  • C is Correct: Hierarchical chunking preserves parent-child relationships, allowing retrieval to return both the specific chunk and its structural context (section heading, parent section). This directly addresses the requirement to maintain structural context while enabling precise subsection-level retrieval.

Distractor Analysis

  • A is Incorrect: Fixed-size chunking at 300 tokens fragments structured documents without preserving section relationships, losing critical structural context even with overlap.
  • B is Incorrect: Treating entire PDFs as single chunks produces embeddings that are too diffuse—retrieval returns large portions of irrelevant text, and specific subsection queries would perform poorly.
  • D is Incorrect: Pure semantic chunking splits on topic shifts but does not explicitly maintain hierarchical parent-child relationships needed for structured regulatory content. It may break at natural language boundaries that don't align with document structure.
  • E is Incorrect: An 8000-token chunk is far too large for precise retrieval; the relevant subsection will be buried in a massive amount of irrelevant text, creating the "lost in the middle" problem during generation.

Key Takeaway: Use hierarchical chunking for structured documents with nested sections where both context and precision are required, while fixed-size chunking suits simpler, uniform documents.

Question 3 - Embedding Model Selection for Domain-Specific Spanish Text

A legal technology startup is building a contract review system for the Spanish legal market. The system must identify semantically similar clauses across contracts to support precedent search. All contracts are in Spanish, including complex legal terminology. The team plans to use Amazon SageMaker for model hosting and has evaluated several embedding models.

The team requires an embedding model that supports Spanish text and can handle domain-specific legal vocabulary. The team also wants to avoid training a custom model from scratch due to limited GPU budgets. They are evaluating embedding models available through Amazon Bedrock.

Which TWO actions should the team take? (Select TWO)

A) Use Amazon Titan Text Embeddings V2, which supports multilingual text including Spanish B) Fine-tune a monolingual English embedding model on a small Spanish corpus using SageMaker C) Use the Cohere Embed model available through Amazon Bedrock, which supports multilingual embeddings D) Train a Word2Vec model from scratch on Spanish legal documents using SageMaker E) Use Amazon Comprehend to translate all Spanish documents to English before generating embeddings

Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

  • A is Correct: Amazon Titan Text Embeddings V2 supports multilingual text, including Spanish, and is available through Bedrock with no custom training required.
  • C is Correct: Cohere Embed (available via Amazon Bedrock) provides multilingual embedding capabilities supporting Spanish and other languages, eliminating the need for custom model training.

Distractor Analysis

  • B is Incorrect: Fine-tuning an English-only embedding model on a small Spanish corpus would produce poor-quality embeddings because the base model's tokenizer and pre-trained representations are optimized for English. This approach cannot overcome fundamental language limitations with limited fine-tuning data.
  • D is Incorrect: Training Word2Vec from scratch requires significant GPU compute and a massive corpus to produce high-quality embeddings. This violates the "limited GPU budgets" constraint and fails to capture context-dependent semantics compared to modern transformer-based embeddings.
  • E is Incorrect: Translating Spanish to English before embedding introduces additional latency, operational complexity, and potential translation errors—especially with legal terminology where precision matters. This adds unnecessary steps to the pipeline.

Key Takeaway: When working with non-English text, select pre-trained multilingual embedding models from Bedrock (Titan, Cohere) rather than fine-tuning English-only models or training from scratch.

Question 4 - Vector Dimension and Index Configuration

A fintech company is building a semantic search system for customer support tickets. The team has chosen an embedding model that outputs 1536-dimensional vectors. They plan to use Amazon OpenSearch Serverless with a vector collection to store embeddings for approximately 10 million support tickets, growing at 500,000 tickets per month.

The search feature must return results with sub-second latency during peak hours when the system handles 100 queries per second. The team wants to balance search accuracy with infrastructure cost.

Which configuration should the ML engineer recommend?

A) Configure the vector collection with 1536 dimensions, use the k-NN plugin with exact search (score_all), and provision the minimum OpenSearch Compute Units (OCUs) B) Configure the vector collection with 1536 dimensions and use Approximate Nearest Neighbor (ANN) search with HNSW or IVF algorithms configured for recall targets C) Reduce embedding dimensions to 128 using PCA before indexing to minimize storage and improve performance, accepting reduced semantic accuracy D) Store the raw 1536-dimensional vectors in Amazon DynamoDB and implement a custom cosine similarity search using AWS Glue E) Increase OCUs to maximum and enable exact nearest neighbor search to guarantee 100% recall

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Approximate Nearest Neighbor (ANN) algorithms like HNSW (Hierarchical Navigable Small World) or IVF (Inverted File Index) provide sub-second search over millions of embeddings by sacrificing a small amount of recall (typically 95-99%) for massive performance gains. This is the standard approach for production-scale vector search and provides configurable tradeoffs between latency, cost, and accuracy.

Distractor Analysis

  • A is Incorrect: Exact search (score_all) over millions of vectors at 100 QPS would require significant compute resources and would not achieve sub-second latency without massive (and expensive) provisioning. The minimum OCU setting would cause severe performance degradation.
  • C is Incorrect: PCA dimensionality reduction to 128 dimensions significantly degrades semantic accuracy—1536-dimensional embeddings are carefully trained to represent nuanced relationships. This premature optimization sacrifices quality for minimal storage savings.
  • D is Incorrect: DynamoDB is not designed for large-scale similarity search over high-dimensional vectors. Implementing custom cosine similarity in Glue would produce unacceptably slow query times (batch-oriented, not real-time) and represents unnecessary re-implementation of existing vector database capabilities.
  • E is Incorrect: Exact nearest neighbor search over 10 million+ vectors at 100 QPS is computationally prohibitive and extremely cost-inefficient. Maximum OCUs would still not guarantee sub-second latency at scale, and exact search provides marginal accuracy gain over well-tuned ANN.

Key Takeaway: Use Approximate Nearest Neighbor (ANN) algorithms in OpenSearch Serverless for production vector search at scale—they provide excellent accuracy (95-99% recall) with dramatically better performance and cost characteristics than exact search.

Question 5 - Embedding Pipeline for Streaming Documents

A news media company is building a real-time content recommendation system. New articles are published continuously and must become searchable within 60 seconds of publication. The pipeline includes image extraction from articles, text extraction from article bodies, and multimodal embedding generation.

The system must handle variable publication volumes (5-200 articles per minute) and automatically scale. The team wants to use AWS Lambda for event-driven processing and Amazon Bedrock for embedding generation. The architecture must minimize operational overhead and ensure articles are searchable within the latency requirement.

Which architecture should the team implement?

A) Configure an S3 Event Notification to trigger a Lambda function that reads the article, calls Bedrock for text embeddings, calls Bedrock for image embeddings, then writes both to separate OpenSearch vector indices in a single batch operation B) Use AWS Glue to schedule a batch job every 5 minutes that processes all new articles and writes embeddings to OpenSearch C) Configure S3 Event Notifications to trigger a Lambda function that calls Bedrock to generate multimodal embeddings (combining text and images from the article) and writes them to OpenSearch Serverless D) Use Amazon Kinesis Data Firehose to buffer articles, then use an AWS Glue streaming job to generate embeddings and write to OpenSearch E) Use Amazon EMR with Spark Streaming to process articles in real-time and call Bedrock from Spark worker nodes

Click to reveal Answer & Explanation

Correct Answer: C

Correct Option Analysis

  • C is Correct: Amazon Titan Multimodal Embeddings can process text and images together (or separately) to generate unified vector representations. Using Lambda with S3 event notifications provides automatic scaling from 5-200 articles per minute, while Bedrock manages embedding model infrastructure. Writing directly to OpenSearch Serverless meets the 60-second latency requirement without additional orchestration complexity.

Distractor Analysis

  • A is Incorrect: While functionally similar, using separate text and image embeddings creates disconnected vectors that cannot support unified multimodal queries. The correct approach is to use multimodal embeddings that capture cross-modal relationships. Additionally, this implies managing two separate vector indices, increasing complexity unnecessarily.
  • B is Incorrect: A 5-minute batch schedule violates the 60-second latency requirement. Glue batch jobs also have cold-start times that would further delay processing.
  • D is Incorrect: Kinesis Firehose with Glue streaming adds unnecessary infrastructure complexity compared to direct Lambda + Bedrock integration. Glue streaming also has higher minimum costs and provisioning requirements, violating the "minimize operational overhead" constraint.
  • E is Incorrect: Running a persistent EMR cluster with Spark Streaming is the highest operational overhead option. This architecture requires cluster management, scaling policies, and worker node optimization—all unnecessary when Lambda and Bedrock can handle the same workload with less overhead.

Key Takeaway: For low-latency embedding generation at variable scale, use Amazon Titan Multimodal Embeddings through Bedrock with event-driven Lambda—this supports unified text-image search with minimal operational overhead.

Question 6 - Embedding Cost Optimization for Large-Scale Batch Processing

A healthcare analytics company needs to generate embeddings for 50 million medical research abstracts stored in Amazon S3. These embeddings will be used for offline semantic similarity analysis and clustering. The processing job runs monthly and has a 72-hour completion window.

The team is evaluating two options: (1) using Amazon Bedrock on-demand model invocations, or (2) using Amazon SageMaker with a deployed embedding model. The embedding model outputs 1024-dimensional vectors.

Which approach is MOST cost-effective for this use case?

A) Use Amazon Bedrock with on-demand pricing and process all 50 million documents using concurrent Lambda invocations B) Deploy an embedding model on a SageMaker real-time endpoint (ml.g5.xlarge) and process documents sequentially over the 72-hour window C) Use SageMaker Batch Transform with an embedding model, processing documents in large batches with GPU instances (ml.g5.12xlarge) during the monthly job window D) Use Amazon Bedrock with provisioned throughput for 72 hours each month E) Store the raw text in DynamoDB and generate embeddings at query time using a Lambda function

Click to reveal Answer & Explanation

Correct Answer: C

Correct Option Analysis

  • C is Correct: SageMaker Batch Transform is designed specifically for large-scale, offline batch inference over massive datasets. It runs only during the processing window (no persistent endpoint costs), can leverage large GPU instances for maximum throughput, and processes data in optimal batch sizes. For 50 million documents processed monthly, batch transform provides significantly lower per-document cost than on-demand API calls or persistent endpoints.

Distractor Analysis

  • A is Incorrect: Amazon Bedrock on-demand pricing for 50 million documents at typical Bedrock per-token rates would be extremely expensive. Each abstract may be hundreds of tokens, resulting in billions of input tokens processed per job—far exceeding batch transform costs. On-demand Bedrock is designed for interactive workloads, not bulk processing.
  • B is Incorrect: A single ml.g5.xlarge real-time endpoint processing 50 million documents sequentially would likely exceed the 72-hour window due to throughput constraints. Even if possible, the endpoint provisioning costs and single-instance processing represent an inefficient approach for batch workloads.
  • D is Incorrect: Bedrock provisioned throughput is designed for guaranteed capacity at consistent load levels. Provisioning 72 hours of throughput for a monthly batch job wastes capacity (and cost) during non-processing periods, and is typically more expensive than an on-demand or batch-optimized approach.
  • E is Incorrect: Generating embeddings at query time for 50 million documents is completely impractical. This would require embedding every document on the fly (with high latency per query) and violates the offline batch processing requirement. DynamoDB storage for 50 million records also adds unnecessary cost.

Key Takeaway: For large-scale batch embedding generation, use SageMaker Batch Transform with GPU instances—it's purpose-built for bulk inference and avoids the per-token costs of on-demand API calls or idle endpoint costs.

Question 7 - Embedding Batching and Token Limits

A customer service platform is building a semantic search system over customer feedback survey responses. The responses include both short comments (10-50 words) and detailed complaint narratives (500-5000 words). The embedding model has a maximum input token limit of 8192 tokens, and the team is using Amazon Bedrock for embedding generation.

The team wants to ensure all responses—regardless of length—are represented in the vector store. Longer responses need to be searchable by specific complaint topics, not just overall sentiment.

Which TWO actions should the team implement? (Select TWO)

A) Truncate all responses to 8192 tokens before generating embeddings, discarding any text beyond that limit B) For responses exceeding the token limit, split them into overlapping chunks and create multiple embedding entries in the vector store, each tagged with the same survey ID metadata C) Use Amazon Comprehend to summarize long responses to under 8192 tokens before embedding D) For shorter responses (under 512 tokens), embed them individually without chunking E) Skip long responses that exceed the token limit and only process shorter responses

Click to reveal Answer & Explanation

Correct Answers: B and D

Correct Options Analysis

  • B is Correct: Splitting long responses into overlapping chunks (e.g., 2000 tokens with 200-token overlap) ensures that no content is lost and that specific complaint topics within long narratives become searchable. Tagging all chunks with the same survey ID metadata enables aggregation during retrieval.
  • D is Correct: Short responses (under 512 tokens) fit comfortably within model token limits and should be embedded as single units. This preserves the complete context of the entire response without unnecessary fragmentation.

Distractor Analysis

  • A is Incorrect: Simple truncation at 8192 tokens would preserve longer responses, but truncation at any limit discards potentially important complaint details from the end of long responses. Given that most responses are well under 8192 tokens, the issue is embedding quality for medium-length responses and searchability of specific themes within long narratives.
  • C is Incorrect: Summarization through Comprehend introduces an additional processing step, costs, and potential information loss. Summaries may miss specific complaint details that need to be retrievable. Chunking preserves more information and allows topic-specific retrieval.
  • E is Incorrect: Skipping long responses creates blind spots in the search system—the very responses most likely to contain multiple issues would be excluded from retrieval, violating the requirement that all responses be represented.

Key Takeaway: When embedding long documents, split them into overlapping chunks and use metadata (e.g., survey ID) to associate multiple chunks with the same source—this preserves searchability for specific topics without losing information.

Question 8 - Embedding Model Consistency for Training vs. Inference

A fraud detection team is building a model that uses transaction description embeddings as input features. During development, the team used Amazon Titan Text Embeddings V1 to generate 1536-dimensional embeddings from transaction descriptions. The model was trained using these embeddings as features, achieving strong performance.

Before deployment, another team member suggests upgrading to Amazon Titan Text Embeddings V2, which produces different embedding dimensions and is trained on newer data. The V2 model shows better semantic accuracy in independent benchmarks.

What is the correct action regarding the embedding model choice for production deployment?

A) Switch to V2 embeddings, retrain the fraud detection model with new V2 features, then deploy the updated model B) Deploy the model with V1 embeddings because the fraud detection model was trained on V1 features and switching models without retraining would introduce feature skew C) Use both V1 and V2 embeddings as input features to improve the model's accuracy D) Switch to V2 embeddings without retraining, since improved embedding quality will automatically improve model performance E) Replace the embedding model with a one-hot encoding approach to avoid dependency on external embedding models

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: The fraud detection model's learned weights are tuned to the specific feature space produced by V1 embeddings. Deploying with V2 embeddings without retraining would introduce training-serving skew—the model would receive inputs in a vector space it was never trained on, causing unpredictable performance degradation. Using V1 for production maintains consistency and is the correct immediate action.

Distractor Analysis

  • A is Incorrect: While technically valid, this option represents a proactive model upgrade path, not the correct answer for immediate deployment. The question asks about deployment action, and retraining is not stated as an immediate requirement. Retraining would require additional weeks of validation, data collection, and testing before production readiness.
  • C is Incorrect: Combining different embedding dimensions and semantic spaces creates feature engineering challenges and inconsistent representations. This would likely degrade model performance without clear benefit.
  • D is Incorrect: This is dangerously wrong—switching embedding models without retraining the downstream model introduces exactly the training-serving skew that causes production failures. The fraud model's weights were optimized for V1's specific vector representations; V2 vectors would be as foreign as feeding images to a text model.
  • E is Incorrect: One-hot encoding is fundamentally unsuitable for capturing semantic relationships in text features. Transaction descriptions have high vocabulary cardinality, and one-hot encoding would create extremely sparse, high-dimensional features that lack the semantic information V1 embeddings capture. This is a regression to inferior methodology.

Key Takeaway: When embeddings serve as model features, consistency between training and inference is critical—never swap embedding models without retraining the downstream model on the new embedding space.

Question 9 - Image Embedding Preprocessing Requirements

An e-commerce company is implementing a visual similarity search feature for fashion items. Product images stored in Amazon S3 vary significantly in size, aspect ratio, and format (JPEG, PNG, WebP). The team plans to use Amazon Titan Image Generator or Amazon Titan Multimodal Embeddings through Amazon Bedrock to generate image embeddings for the vector search index.

The team asks about preprocessing requirements for image embeddings. Which statement is TRUE about image preprocessing for Amazon Bedrock multimodal embedding models?

A) Images must be preprocessed to exact 224x224 pixel resolution and converted to JPEG format before embedding generation B) The model accepts standard image formats (JPEG, PNG, etc.) and automatically handles resizing and normalization internally—no custom preprocessing is required C) Images must be converted to base64 and embedded into JSON payloads before calling Bedrock APIs, with all images resized to 1024x1024 pixels D) Images must be converted to grayscale to reduce embedding model complexity and improve vector quality E) The team must use Amazon Rekognition to preprocess images by detecting objects before passing them to the embedding model

Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Amazon Bedrock's multimodal embedding models (including Titan Multimodal Embeddings) accept standard image formats (JPEG, PNG, among others) and handle internal resizing, normalization, and preprocessing as part of the model inference pipeline. Users provide the raw image data via the API, and the model processes it appropriately—no custom preprocessing code is required.

Distractor Analysis

  • A is Incorrect: The 224x224 requirement was common for older open-source models like ResNet, but Amazon's managed multimodal embedding models handle arbitrary image sizes and formats internally. Requiring custom resizing adds unnecessary operational overhead.
  • C is Incorrect: While base64 encoding is the standard API transmission format for images, the statement's claim about mandatory 1024x1024 resizing is incorrect. Different Bedrock models have different internal processing, but users are not required to resize images to specific dimensions before API calls.
  • D is Incorrect: Converting to grayscale discards valuable color information that contributes to visual similarity. Fashion items rely heavily on color for similarity matching—a red dress and a blue dress of the same design should not produce identical embeddings, and grayscale conversion would lose this discriminating feature.
  • E is Incorrect: Rekognition object detection produces categorical labels, not preprocessing steps required for embedding generation. Adding this step introduces unnecessary latency and cost without improving embedding quality for similarity search.

Key Takeaway: Amazon Bedrock multimodal models handle image preprocessing internally—clients only need to transmit standard image formats via the API; manual resizing, format conversion, or external preprocessing is unnecessary.

Question 10 - Vector Index Metadata Filtering

A legal research platform has indexed 5 million case law documents using embeddings stored in Amazon OpenSearch Serverless. Each document has been chunked into sections and embedded. The team needs to enable faceted search: users must be able to filter results by court jurisdiction, document type (opinion, statute, regulation), publication year range, and case status.

The search pipeline must combine vector similarity search with structured metadata filtering. Queries must return precise results with "must" filters (e.g., court=Supreme Court AND year > 2010) while ranking results by semantic similarity to the query text.

Which configuration should the ML engineer implement?

A) Store metadata as separate fields in the OpenSearch index alongside vector fields, then use a query with must clauses for filters combined with knn search on the vector field B) Embed metadata into the text before embedding generation, ensuring filters are part of the semantic search C) Store metadata in a separate DynamoDB table and perform post-query filtering in the application layer D) Implement multiple separate OpenSearch indices per filter combination (e.g., one index per court + document type combination) E) Use Amazon Bedrock Knowledge Bases metadata filtering with a single flat vector index, disabling filterable metadata extraction

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: OpenSearch supports combined queries where structured filters (using must clauses on regular fields) are applied together with k-NN vector similarity search. This enables precise filtering by jurisdiction, document type, and date range while ranking matching results by semantic similarity. The approach is efficient, scalable, and leverages native OpenSearch query capabilities.

Distractor Analysis

  • B is Incorrect: Embedding metadata into the text before embedding is a workaround that makes filtering unreliable—court names, dates, and document types become part of the semantic vector but cannot be precisely filtered. A query for "Supreme Court cases" might semantically match "Appeals Court" documents if the embedding space considers them similar, defeating precise filtering requirements.
  • C is Incorrect: Post-query filtering in the application layer requires retrieving many more results than needed (to ensure filtered results remain after processing), causing excessive latency and inefficient vector search. This approach also breaks pagination and ranking metrics since filtering happens after similarity scoring.
  • D is Incorrect: Creating separate indices per filter combination would result in an explosion of index count (4 courts × 3 document types × 20 year ranges = 240+ indices), making management, updates, and cross-filter queries impractical. This violates scalability and operational efficiency requirements.
  • E is Incorrect: Disabling metadata extraction eliminates the structured filtering capability entirely. Bedrock Knowledge Bases supports metadata filtering when configured properly, and OpenSearch Serverless supports combined vector and filter queries natively.

Key Takeaway: Use OpenSearch's native combined query capabilities—must clauses on metadata fields plus k-NN on vector fields—to enable precise filtered semantic search without workarounds or excessive index fragmentation.