Skill 1.1.1: Extract data from data sources
| Question | Answer & Explanation |
|---|---|
| ### Question 1 - Medical Tokenization and Vector Retrieval A healthcare startup is building a semantic search engine for clinical trial documents using Amazon Bedrock Knowledge Bases and Amazon OpenSearch Serverless. The clinical documents contain heavy medical jargon, complex acronyms, and alphanumeric medication codes that standard tokenizers often break apart. The ingestion pipeline must preserve these domain-specific terms as single tokens to maintain semantic integrity during retrieval. Which TWO steps should the ML engineer take to fulfill these requirements with the LEAST operational overhead? (Select TWO) - A) Write a custom Python script in AWS Lambda to implement a custom Byte-Pair Encoding (BPE) tokenizer specifically for medical terms before calling the Bedrock embedding model. - B) Use an Amazon Bedrock embedding model (e.g., Titan Text Embeddings) that natively supports robust tokenization capable of handling specialized alphanumeric sequences without breaking them. - C) Use Amazon Comprehend Medical to extract medical entities and acronyms, and inject them as domain-specific metadata alongside the standard text chunks. - D) Train a custom Word2Vec model on Amazon SageMaker to generate domain-specific embeddings for the medical codes, bypassing Bedrock entirely. - E) Manually replace all alphanumeric medical codes with generic placeholder tokens (e.g., "MED_CODE_1") using AWS Glue DataBrew before ingestion. |
Correct Answers: B and C Correct Options Analysis: - B is Correct: Amazon Bedrock embedding models like Titan are pre-trained on massive corpora and have tokenizers designed to handle complex alphanumeric sequences and domain jargon effectively without requiring custom tokenization scripts. Using native capabilities minimizes operational overhead. - C is Correct: Using Amazon Comprehend Medical to extract entities and save them as metadata in the Bedrock Knowledge Base allows for filtered retrieval and preserves domain context without altering the underlying text tokens. Distractor Analysis: - A is Incorrect: Writing a custom BPE tokenizer in Lambda introduces significant operational overhead and custom code maintenance, violating the least operational overhead constraint. - D is Incorrect: Training a custom Word2Vec model requires managing SageMaker training jobs and infrastructure, introducing high overhead, and bypasses the native Bedrock integration. - E is Incorrect: Replacing specific codes with generic placeholders destroys the semantic meaning of the codes, defeating the purpose of semantic retrieval. > Key Takeaway: For domain-specific text, rely on robust pre-trained foundation model tokenizers (like Bedrock Titan) and use metadata extraction (via Comprehend Medical) to preserve context, avoiding custom tokenization overhead. |
| ### Question 2 - Domain-Specific Augmentation for Fine-Tuning A legal tech company is preparing a dataset to fine-tune a large language model (LLM) on Amazon SageMaker JumpStart. The dataset consists of thousands of legal contracts, but the team needs to increase the diversity of the training data to improve the model's robustness to varied phrasing of legal clauses. The team must achieve this with minimal custom code and ensure the augmented text remains legally accurate. Which approach should the team use to perform domain-specific text augmentation? - A) Use an LLM in Amazon Bedrock to perform paraphrasing of the legal clauses, generating varied prompt-response pairs for fine-tuning. - B) Apply standard synonym replacement using an open-source NLP library (e.g., NLTK) in an AWS Lambda function, replacing legal terms with general English synonyms. - C) Use Amazon Comprehend to identify key legal phrases, and use AWS Glue DataBrew to randomly shuffle the sentences within each contract. - D) Apply back-translation using a standard machine translation service, translating the contracts to French and back to English. |
Correct Answer: A Correct Option Analysis: - A is Correct: Using an LLM via Amazon Bedrock for paraphrasing allows for domain-specific augmentation that understands the legal context. The LLM can generate varied phrasings while preserving the strict legal meaning, providing high-quality augmented data with minimal custom code. Distractor Analysis: - B is Incorrect: Standard synonym replacement using generic libraries does not understand legal domain specificity. Replacing legal terms (e.g., "indemnification") with general English synonyms would alter the legal meaning and invalidate the contracts. - C is Incorrect: Randomly shuffling sentences in a legal contract will destroy the logical and legal flow of the document, rendering the training data useless for instruction tuning. - D is Incorrect: Back-translation can introduce subtle translation errors and may not preserve the precise legal terminology required in contracts, risking legal inaccuracies. > Key Takeaway: When performing domain-specific augmentation for fine-tuning, use generative AI models (like those in Bedrock) for context-aware paraphrasing rather than generic NLP techniques that might corrupt domain-specific terminology. |
| ### Question 3 - Hierarchical Chunking for Financial Reports A financial services firm is ingesting annual 10-K reports into Amazon Bedrock Knowledge Bases to power a RAG-based financial analyst assistant. The reports contain nested structures (e.g., Sections, Subsections, Tables) where context from parent sections is critical for understanding the child text. The solution must minimize the retrieval of irrelevant text while preserving the broader section context. Which text pre-processing chunking strategy should the ML engineer configure in Bedrock Knowledge Bases to meet this requirement? - A) Fixed-size chunking with a large overlap percentage to capture surrounding context. - B) Semantic chunking to break the text based on meaning rather than length. - C) Hierarchical chunking with parent-child relationships. - D) No chunking, storing each full 10-K report as a single document. |
Correct Answer: C Correct Option Analysis: - C is Correct: Hierarchical chunking breaks documents into parent and child chunks. During retrieval, if a small child chunk matches the query, the system can retrieve the larger parent chunk to provide the necessary surrounding context, which is ideal for structured documents like financial reports. Distractor Analysis: - A is Incorrect: Fixed-size chunking with overlap arbitrarily cuts text based on token count, often breaking tables and sentences awkwardly, and does not intelligently link parent/child context. - B is Incorrect: While semantic chunking breaks on meaning, it does not explicitly maintain the parent-child structural hierarchy needed for nested financial sections. - D is Incorrect: Storing the entire 10-K as a single document means the entire report must be processed in the LLM context window per query, which is cost-prohibitive and leads to the "lost in the middle" phenomenon. > Key Takeaway: Use hierarchical chunking in Amazon Bedrock Knowledge Bases for documents with nested structures to ensure that retrieved child chunks retain the context of their parent sections. |
| ### Question 4 - Stop Word Removal in RAG Pipelines An AI engineering team is building a RAG application using Amazon OpenSearch Service as a vector store. The source documents are technical engineering manuals. A junior engineer suggests pre-processing the text by removing stop words (e.g., "the", "is", "at", "which") before passing the text to the Amazon Bedrock Titan embedding model to save compute costs and reduce noise. What is the MOST accurate assessment of this pre-processing step? - A) It is a best practice because removing stop words reduces the token count, lowering embedding API costs without affecting semantic meaning. - B) It is detrimental because modern transformer-based embedding models rely on the full context of the sentence, and removing stop words can alter the semantic meaning of the text. - C) It is required because OpenSearch vector indexing fails if stop words are present in the embedded text. - D) It is beneficial only if the team is using a legacy bag-of-words model instead of a dense vector embedding model. |
Correct Answer: B Correct Option Analysis: - B is Correct: Modern embedding models (like Titan) are transformer-based and use self-attention mechanisms that rely on the entire sentence structure, including stop words, to capture semantic context. Removing stop words can fundamentally change the meaning of a sentence (e.g., "The machine is not running" vs. "machine not running"). Distractor Analysis: - A is Incorrect: While it reduces token count, the cost savings are negligible compared to the degradation in retrieval quality. Modern models are highly sensitive to missing context. - C is Incorrect: OpenSearch stores the resulting numerical vectors, not the raw text. The presence of stop words in the source text prior to embedding has no impact on OpenSearch's ability to index the vectors. - D is Incorrect: Although true that stop word removal is a legacy bag-of-words technique, the question asks for the most accurate assessment of this step in the context of the current Bedrock/OpenSearch RAG pipeline, making B the more complete and relevant answer. > Key Takeaway: Do not apply traditional stop word removal to text before passing it to modern transformer-based embedding models; these models require the full sentence context to generate accurate dense vectors. |
| ### Question 5 - PII Redaction for Model Fine-Tuning An enterprise is preparing a dataset of customer support chat transcripts to fine-tune a foundation model on Amazon Bedrock. The compliance team has mandated a strict "zero data retention" policy for Personally Identifiable Information (PII) such as social security numbers, credit card details, and customer names. The pre-processing pipeline must automatically detect and completely remove these entities before the data is sent to the fine-tuning job. Which AWS services should be used to fulfill the pre-processing requirement with the LEAST operational overhead? - A) Use Amazon Macie to scan the S3 bucket containing the transcripts, then use AWS Glue to drop the columns containing PII. - B) Write a custom Python regex script in AWS Lambda to find and replace known PII patterns. - C) Use Amazon Comprehend to detect PII entities, and configure it to redact (remove) the identified text, outputting the cleaned transcripts to Amazon S3. - D) Use Amazon Bedrock Guardrails to redact PII dynamically during the fine-tuning process. |
Correct Answer: C Correct Option Analysis: - C is Correct: Amazon Comprehend provides a native PII detection and redaction API. It can identify PII entities in text and output a redacted version of the text where the PII is removed, satisfying the "zero data retention" compliance requirement with no custom code to maintain. Distractor Analysis: - A is Incorrect: Amazon Macie is designed for data discovery and classification across S3 buckets at scale, not for line-by-line text redaction in chat transcripts. Dropping entire columns is not feasible for unstructured chat logs. - B is Incorrect: Writing custom regex for PII detection is brittle, prone to missing edge cases, and introduces unnecessary operational overhead compared to a managed NLP service. - D is Incorrect: Bedrock Guardrails are applied at inference time to protect user inputs and model outputs, not to pre-process and clean a static training dataset stored in S3 for fine-tuning. > Key Takeaway: Use Amazon Comprehend's PII detection and redaction capabilities to pre-process and sanitize unstructured text datasets prior to model fine-tuning, ensuring compliance without managing custom code. |
| ### Question 6 - Multilingual Tokenization for Global RAG A global e-commerce company is building a product search assistant using Amazon Bedrock Knowledge Bases. The product manuals are written in multiple languages, including English, Japanese, and Arabic. The team needs to ensure that the tokenization and embedding processes handle the linguistic nuances and different character sets of these languages effectively. Which approach requires the LEAST amount of custom infrastructure while ensuring high-quality multilingual semantic retrieval? - A) Use AWS Glue to translate all non-English documents to English using Amazon Translate, then embed only the English text. - B) Configure the Bedrock Knowledge Base to use a multilingual embedding model (e.g., Titan Multilingual Embeddings) that natively handles cross-lingual tokenization and semantic mapping. - C) Deploy separate OpenSearch indices for each language and use custom language-specific tokenizers (e.g., Kuromoji for Japanese) configured manually. - D) Use Amazon Comprehend to detect the dominant language, then route the text to dedicated AWS Lambda functions containing language-specific open-source tokenizers. |
Correct Answer: B Correct Option Analysis: - B is Correct: Amazon Bedrock offers multilingual embedding models (such as Titan Multilingual Embeddings) that are specifically pre-trained to understand and map multiple languages into the same vector space. This handles cross-lingual tokenization natively without any custom infrastructure or translation overhead. Distractor Analysis: - A is Incorrect: Translating all documents to English adds a costly ETL step, loses nuanced domain-specific terminology during translation, and fails to support users querying in their native languages. - C is Incorrect: While OpenSearch supports language-specific analyzers, this requires managing separate indices and complex routing logic, which violates the least custom infrastructure constraint. - D is Incorrect: Routing text to custom Lambda functions with open-source tokenizers introduces heavy operational overhead and bypasses the managed capabilities of Bedrock embeddings. > Key Takeaway: For multilingual RAG applications, use a managed multilingual embedding model (like Amazon Titan Multilingual Embeddings) to natively handle different character sets and tokenization without custom translation or separate indexing infrastructure. |
| ### Question 7 - Continuous Pre-training Data Preparation An energy sector company wants to adapt a foundation model to better understand highly specialized geological survey reports. They have amassed a massive corpus of unlabeled geological text and plan to use Amazon Bedrock for continuous pre-training. The engineering team must prepare this text data to ensure the model absorbs the domain vocabulary effectively. Which data preparation strategy is MOST appropriate for this continuous pre-training task? - A) Structure the data into JSONL format with prompt and completion fields to guide the model's responses.- B) Clean the text to remove HTML tags and boilerplate, concatenate the geological reports, and provide it as a large body of unlabeled raw text. - C) Parse the reports into small chunks, generate embeddings for each chunk, and store them in an OpenSearch vector index. - D) Extract key geological terms and manually annotate them with definitions in a CSV file for supervised learning. |
Correct Answer: B Correct Option Analysis: - B is Correct: Continuous pre-training (domain adaptation) uses self-supervised learning on a large corpus of unlabeled domain-specific text. The preparation involves cleaning the text (removing noise) and providing it as raw, unlabeled data so the model can learn the vocabulary, patterns, and structure of the geological domain. Distractor Analysis: - A is Incorrect: Structuring data into prompt and completion pairs is the format required for supervised fine-tuning (instruction tuning), not continuous pre-training.- C is Incorrect: Generating embeddings and storing in a vector index is the preparation step for Retrieval-Augmented Generation (RAG), not for updating model weights via continuous pre-training. - D is Incorrect: Manually annotating terms creates a labeled dataset suitable for supervised learning or fine-tuning, defeating the purpose of using unlabeled text for continuous pre-training. > Key Takeaway: Continuous pre-training requires a large corpus of cleaned, unlabeled domain text to adapt the model's internal weights to new vocabulary, whereas fine-tuning requires labeled prompt-response pairs. |
| ### Question 8 - Preserving Alphanumeric Part Numbers in Text A manufacturing company is creating a maintenance assistant using a RAG architecture. The source data consists of equipment manuals that heavily reference specific part numbers (e.g., AX-9920-Z, RT_44_1b). During testing, the engineering team notices that searches for specific part numbers fail to retrieve the correct manual pages, as the embedding model is splitting these part numbers into sub-components. Which pre-processing technique should the team apply to ensure part numbers are treated as single semantic units during embedding, while keeping the solution most cost-effective? - A) Train a custom embedding model from scratch in Amazon SageMaker using a custom tokenizer that explicitly never splits alphanumeric characters. - B) Use AWS Glue DataBrew to identify part numbers via regex patterns and wrap them in special boundary tokens (e.g., <part> AX-9920-Z </part>) before sending the text to the Bedrock embedding model.- C) Disable the default tokenizer in Amazon Bedrock and pass pre-tokenized arrays of strings directly to the model. - D) Use Amazon Comprehend Custom Entity Recognition to identify part numbers, and replace them with sequential integer IDs before embedding. |
Correct Answer: B Correct Option Analysis: - B is Correct: Using a visual ETL tool like AWS Glue DataBrew to apply a regex transformation that wraps part numbers in special boundary tokens (or underscores) can help the embedding model's tokenizer recognize the sequence as a single cohesive unit, improving retrieval accuracy in a cost-effective manner. Distractor Analysis: - A is Incorrect: Training a custom embedding model from scratch is massively expensive, time-consuming, and highly operationally intensive, violating the cost-effective constraint. - C is Incorrect: Amazon Bedrock embedding APIs do not allow users to disable the model's internal tokenizer or pass raw pre-tokenized arrays; the API accepts raw text strings. - D is Incorrect: Replacing part numbers with generic integer IDs removes the specific semantic and textual information of the part number, making it impossible for the model to map the text "AX-9920-Z" to the correct ID during inference. > Key Takeaway: To prevent modern tokenizers from splitting complex alphanumeric domain identifiers (like part numbers), use text pre-processing to wrap them in boundary tokens or connect them with underscores before passing them to embedding models. |
| ### Question 9 - Low-Code Text Cleaning in SageMaker A data science team is preparing a dataset of scraped product reviews for a text classification model. The raw text contains HTML tags, inconsistent casing, and various special characters. The team wants to perform standard text cleaning (HTML stripping, lowercasing, and punctuation removal) in an interactive, low-code environment before exporting the cleaned data for feature engineering. Which AWS tool should the team use to perform these text pre-processing steps with the LEAST amount of code? - A) AWS Glue DataBrew - B) Amazon SageMaker Data Wrangler - C) AWS Lambda with the BeautifulSoup Python library - D) Amazon EMR with Apache Spark |
Correct Answer: B Correct Option Analysis: - B is Correct: Amazon SageMaker Data Wrangler (integrated into SageMaker Canvas) is an interactive, low-code tool designed specifically for ML data preparation. It provides built-in transforms for text cleaning, such as removing HTML tags, converting to lowercase, and stripping punctuation, allowing the team to build a reusable flow without writing custom scripts. Distractor Analysis: - A is Incorrect: While AWS Glue DataBrew is low-code, it is primarily designed for tabular data ETL and data profiling rather than interactive ML feature engineering workflows. - C is Incorrect: Using AWS Lambda with BeautifulSoup requires writing and deploying custom Python code, which violates the low-code and least-code constraints. - D is Incorrect: Amazon EMR with Spark is a heavy, cluster-based Big Data processing framework. It is highly operationally intensive and completely overkill for interactive text cleaning of a dataset. > Key Takeaway: Amazon SageMaker Data Wrangler (via SageMaker Canvas) is the preferred low-code, interactive AWS tool for ML-specific data preparation, including built-in text cleaning transformations for NLP tasks. |
| ### Question 10 - Preparing Data for Model Distillation A machine learning team wants to reduce the latency and inference cost of their generative AI application. They currently use a large teacher model in Amazon Bedrock to generate high-quality responses to user queries about internal IT troubleshooting. The team decides to distill this capability into a smaller student model. Which data preparation step is required to perform model distillation using Amazon Bedrock? - A) Assemble a large corpus of raw, unlabeled IT troubleshooting manuals for continuous pre-training. - B) Create a set of diverse user prompts covering the IT troubleshooting domain to feed into the teacher model. - C) Manually write thousands of prompt-response pairs as a JSONL file for supervised fine-tuning of the student model. - D) Generate vector embeddings for all historical IT troubleshooting tickets and store them in OpenSearch. |
Correct Answer: B Correct Option Analysis: - B is Correct: For model distillation, the primary artifact to prepare is a diverse set of prompts. The managed distillation process in Amazon Bedrock automatically sends these prompts to the larger teacher model to generate responses, and then uses those prompt-response pairs to fine-tune the smaller student model. Distractor Analysis: - A is Incorrect: Raw, unlabeled manuals are used for continuous pre-training, not for distillation. - C is Incorrect: The core benefit of distillation is that the teacher model generates the responses. Manually writing prompt-response pairs is standard supervised fine-tuning, which bypasses the teacher model entirely. - D is Incorrect: Generating vector embeddings and storing them in a vector database is the data preparation step for a Retrieval-Augmented Generation (RAG) architecture, not for model distillation. > Key Takeaway: To prepare data for model distillation, simply gather a comprehensive set of prompts; the managed service handles querying the teacher model and fine-tuning the student model on the resulting outputs. |