Ngân hàng đề — AWS Certified Machine Learning Engineer Associate

Tìm thấy 635 câu.

Câu 1 ML Model Development

A company specializes in providing personalized product recommendations for e-commerce platforms. You’ve been tasked with developing a solution that can quickly generate high-quality product descriptions, tailor marketing copy based on customer preferences, and analyze customer reviews to identify trends in sentiment. Given the scale of data and the need for flexibility in choosing foundational models, you decide to use an AI service that can integrate seamlessly with your existing AWS infrastructure while also offering managed foundational models from third-party providers.

Which AWS service would best meet your requirements?

A
Amazon Personalize
B
Amazon Bedrock
C
Amazon Rekognition
D
Amazon SageMaker

Xem giải thích

Đáp án

B — Amazon Bedrock.

Vì sao đúng

Đề nêu ba nhu cầu và một ràng buộc, và Bedrock đáp ứng cả bốn: | Nhu cầu | Bedrock | |---|---| | Sinh mô tả sản phẩm chất lượng cao, nhanh | foundation model sinh văn bản | | Viết nội dung marketing theo sở thích khách hàng | prompt có tham số | | Phân tích cảm xúc trong đánh giá của khách | model hiểu ngôn ngữ | | Linh hoạt chọn foundation model, gồm cả bên thứ ba | nhiều nhà cung cấp trên một API |

Vế cuối là điểm quyết định của câu này. Đề nói rõ cần "managed foundational models from third-party providers", và đó chính xác là đặc trưng của Bedrock: | Nhà cung cấp | Model | |---|---| | Anthropic | Claude | | Amazon | Titan, Nova | | Meta | Llama | | Mistral, Cohere, AI21, Stability | … |

Tất cả qua một API duy nhất — và với Converse API, đổi từ model này sang model kia chỉ là đổi modelId.

Và "integrate seamlessly with existing AWS infrastructure" được đáp ứng vì Bedrock là dịch vụ AWS gốc: dùng IAM cho quyền, VPC endpoint cho mạng riêng, CloudWatch cho giám sát.

Vì sao các phương án khác sai

D. Amazon SageMaker — đây là phương án gần nhất và làm được về mặt kỹ thuật, nhưng nó là nền tảng để bạn tự huấn luyện và tự host model. Với ba tác vụ trong đề, dùng SageMaker nghĩa là phải chọn model, triển khai endpoint, quản lý instance và auto scaling. (SageMaker JumpStart có sẵn model, nhưng vẫn là bạn host — trái với "managed foundational models".)
A. Amazon Personalize — dịch vụ gợi ý sản phẩm dựa trên hành vi người dùng. Nó rất hợp với phần "personalized product recommendations" trong tên công ty, nhưng nó không sinh văn bản: không viết được mô tả sản phẩm, không viết được nội dung marketing.
C. Amazon Rekognition — dịch vụ thị giác máy tính: nhận diện vật thể, khuôn mặt, văn bản trong ảnh và video. Không liên quan tới ba tác vụ về ngôn ngữ trong đề.

Ghi nhớ

Bốn dịch vụ AI/ML của AWS — nhớ đúng vai: | Dịch vụ | Việc | |---|---| | Bedrock | foundation model được quản lý, nhiều nhà cung cấp — GenAI | | SageMaker | nền tảng ML đầy đủ: huấn luyện, host, quản lý vòng đời | | Personalize | hệ thống gợi ý | | Rekognition | thị giác máy tính |

Các dịch vụ AI chuyên biệt khác hay xuất hiện trong đề thi: | Dịch vụ | Việc | |---|---| | Comprehend | NLP: sentiment, thực thể, PII, phân loại | | Textract | trích xuất văn bản và bảng từ tài liệu | | Transcribe / Polly | giọng nói ↔ văn bản | | Translate | dịch thuật | | Forecast | dự báo chuỗi thời gian | | Fraud Detector | phát hiện gian lận |

Một chi tiết đáng lưu ý cho câu này: phân tích cảm xúc có thể làm bằng Comprehend (rẻ hơn và chuyên biệt hơn cho khối lượng lớn). Nhưng đề yêu cầu một dịch vụ làm cả ba việc kèm ràng buộc về foundation model bên thứ ba — nên Bedrock là câu trả lời đúng.

Cách chọn giữa Bedrock và SageMaker: | Đề nói | Chọn | |---|---| | "managed foundation models", "third-party providers", "quickly" | Bedrock | | "custom model", "fine-tune sâu", "kiểm soát hạ tầng" | SageMaker | | Cần cả hai | ghép: fine-tune trên SageMaker, phục vụ qua Bedrock Custom Model Import |

Câu 2 Chọn nhiều đáp án ML Solution Monitoring, Maintenance, and Security

You are a data scientist working for a financial institution that uses a machine learning model to predict loan defaults. The model was trained on historical data from the past five years, but after being deployed for several months, its accuracy has gradually decreased. Upon investigation, you suspect that the underlying data distribution has changed due to economic shifts and changes in customer behavior. This phenomenon is known as model drift, and you need to address it to ensure the model continues to perform well.

Which of the following approaches would you combine for detecting and managing drift in your ML model? (Select two)

A
Increase the complexity of the model by adding more features and deeper layers, ensuring it can adapt to changing data distributions over time
B
Decrease the complexity of the model by removing features and layers, thereby turning it into a simpler model that can various types of data distributions
C
Deploy a secondary model trained on different data and compare its predictions with the original model to detect any significant differences, indicating potential drift
D
Implement continuous monitoring of input data features and model predictions using statistical tests to detect shifts in data distribution or performance, triggering an alert when drift is detected
E
Retrain the model on the most recent data to ensure it captures current trends, and use model versioning to track performance improvements over time

Xem giải thích

Đáp án

D và E.

D — Giám sát liên tục đặc trưng đầu vào và dự đoán của model bằng kiểm định thống kê để phát hiện dịch chuyển phân bố hoặc suy giảm hiệu năng, kích hoạt cảnh báo khi phát hiện drift
E — Huấn luyện lại trên dữ liệu mới nhất để nắm bắt xu hướng hiện tại, và dùng quản lý phiên bản model để theo dõi cải thiện theo thời gian

Vì sao đúng

Đề mô tả đúng hiện tượng model drift: phân bố dữ liệu đã thay đổi do biến động kinh tế và hành vi khách hàng.

Và hai đáp án chia nhau hai nửa của bài toán: | Nửa | Đáp án | |---|---| | PHÁT HIỆN drift | D — giám sát liên tục | | QUẢN LÝ drift | E — huấn luyện lại + version |

Đề hỏi "detecting and managing" — nên thiếu nửa nào cũng không đủ.

D — kiểm định thống kê là cách phát hiện đúng đắn, không phải cảm tính: | Kiểm định | Dùng cho | |---|---| | Kolmogorov–Smirnov | đặc trưng liên tục — so hai phân bố | | Chi-square | đặc trưng phân loại | | PSI (Population Stability Index) | phổ biến trong tài chính — PSI > 0,25 là drift đáng kể |

Và giám sát cả đặc trưng đầu vào lẫn dự đoán đầu ra, vì chúng cho hai tín hiệu khác nhau:

Đầu vào đổi, đầu ra ổn định → có thể model vẫn tốt
Đầu vào ổn định, đầu ra đổi → có gì đó bất thường
Cả hai đổi                   → drift thật, cần hành động

E — huấn luyện lại là cách khắc phục duy nhất thật sự. Phân bố dữ liệu đã đổi thì model học từ phân bố cũ không thể đúng — không có cách chỉnh tham số nào sửa được. Và version cho phép so sánh bản mới với bản cũ và quay lại nếu bản mới tệ hơn.

Vì sao các phương án khác sai

C. Triển khai model thứ hai huấn luyện trên dữ liệu khác và so sánh dự đoán với model gốc để phát hiện khác biệt — đây là phương án đáng bàn vì nó có phát hiện được tín hiệu, nhưng nó tốn kém và mơ hồ: khi hai model bất đồng, bạn không biết cái nào đúng. Và nó không nói gì về việc khắc phục. Kiểm định thống kê trên phân bố cho câu trả lời trực tiếp hơn nhiều.
A. Tăng độ phức tạp — thêm đặc trưng và tầng sâu hơn để model "thích nghi với phân bố thay đổi theo thời gian" — hiểu sai bản chất drift: model không tự thích nghi, nó cố định sau khi huấn luyện. Thêm độ phức tạp chỉ làm tăng nguy cơ overfitting trên dữ liệu cũ.
B. Giảm độ phức tạp — bỏ bớt đặc trưng và tầng để model đơn giản hơn "xử lý được nhiều loại phân bố" — cùng hiểu lầm theo chiều ngược. Model đơn giản hơn ít overfit hơn, nhưng nó vẫn học từ phân bố cũ và vẫn sai khi phân bố đổi.

Ghi nhớ

Bốn loại drift cần phân biệt: | Loại | Nghĩa | |---|---| | Data drift (covariate shift) | phân bố ĐẦU VÀO đổi | | Concept drift | quan hệ giữa đầu vào và nhãn đổi ← trường hợp trong đề | | Label drift | phân bố NHÃN đổi | | Upstream data change | lỗi pipeline, đơn vị đo đổi |

Loại thứ hai là loại nguy hiểm nhất và cũng đúng với tình huống: cùng một hồ sơ khách hàng, xác suất vỡ nợ đã khác vì kinh tế thay đổi. Đầu vào có thể trông y hệt.

Vòng lặp quản lý drift đầy đủ:

① Giám sát liên tục   → kiểm định thống kê trên đặc trưng và dự đoán
② Cảnh báo            → vượt ngưỡng thì báo
③ Chẩn đoán           → drift ở đặc trưng nào, từ khi nào
④ Huấn luyện lại      → trên dữ liệu mới
⑤ Đánh giá & version  → so với bản cũ trước khi thay

Công cụ trên AWS: | Công cụ | Việc | |---|---| | SageMaker Model Monitor | data quality, model quality, bias và feature attribution drift | | Model Registry | version, trạng thái phê duyệt | | SageMaker Pipelines | tự động hoá vòng huấn luyện lại | | EventBridge + Step Functions | kích hoạt khắc phục tự động |

Hai điều bắt buộc trước khi giám sát được:

Đường cơ sở — suggest_baseline() tính thống kê và ràng buộc từ dữ liệu huấn luyện.
Data capture bật trên endpoint — không bật thì không có dữ liệu suy luận để so.

Và một lưu ý cho bài toán vỡ nợ tín dụng nói riêng: nhãn thật đến rất muộn (biết khách có vỡ nợ hay không phải chờ hàng tháng). Nên model quality monitoring gần như không dùng được theo thời gian thực — phải dựa vào data drift và prediction drift làm chỉ báo sớm. Đó là lý do đáp án D nhấn mạnh giám sát cả đầu vào lẫn dự đoán.

Câu 3 ML Model Development

You are a machine learning engineer at a financial services company tasked with building a real-time fraud detection system. The model needs to be highly accurate to minimize false positives and false negatives. However, the company has a limited budget for cloud resources, and the model needs to be retrained frequently to adapt to new fraud patterns. You must carefully balance model performance, training time, and cost to meet these requirements.

Which of the following strategies is the MOST LIKELY to achieve an optimal balance between model performance, training time, and cost?

A
Implement a tree-based model like XGBoost with early stopping and hyperparameter tuning, balancing accuracy with reduced training time and computational cost
B
Deploy a simpler model like logistic regression to reduce training time and cost, while accepting a slight reduction in model accuracy
C
Choose a support vector machine (SVM) with a nonlinear kernel to enhance accuracy, regardless of the increased training time and cost associated with large datasets
D
Use a deep neural network with multiple layers and complex architecture to maximize performance, even if it requires significant computational resources and longer training times

Xem giải thích

Đáp án

A — Dùng model dựa trên cây như XGBoost với early stopping và tinh chỉnh siêu tham số, cân bằng độ chính xác với thời gian huấn luyện và chi phí tính toán giảm.

Vì sao đúng

Đề đặt ra ba ràng buộc kéo ngược nhau, và XGBoost là điểm cân bằng tốt nhất: | Ràng buộc | XGBoost | |---|---| | Độ chính xác cao (ít cả FP lẫn FN) | rất mạnh với dữ liệu bảng | | Ngân sách hạn chế | chạy trên CPU, không cần GPU | | Huấn luyện lại thường xuyên | huấn luyện nhanh, phút tới giờ |

Vì sao XGBoost là lựa chọn mặc định cho dữ liệu bảng như giao dịch tài chính: dữ liệu gian lận là dữ liệu có cấu trúc (số tiền, thời gian, địa điểm, lịch sử tài khoản) — và với loại dữ liệu này, gradient boosting thường vượt mạng nơ-ron cả về độ chính xác lẫn chi phí.

Early stopping là chi tiết quan trọng cho vế thời gian và chi phí:

xgb.fit(X_train, y_train,
        eval_set=[(X_val, y_val)],
        early_stopping_rounds=20)     # dừng khi validation không cải thiện 20 vòng

Nó tự dừng khi model hết cải thiện — nên bạn không trả tiền cho những vòng lặp vô ích, và cũng tránh overfitting.

Và tinh chỉnh siêu tham số khai thác hết năng lực model mà không cần đổi sang thuật toán đắt hơn.

Vì sao các phương án khác sai

B. Dùng model đơn giản như logistic regression để giảm thời gian và chi phí, chấp nhận độ chính xác thấp hơn một chút — đây là phương án đáng bàn: nó rẻ và nhanh thật. Nhưng đề nói rõ "needs to be highly accurate to minimize false positives and false negatives" — và logistic regression không nắm được tương tác phi tuyến giữa các đặc trưng, vốn là bản chất của mẫu gian lận. Chấp nhận giảm chính xác là đánh đổi sai ở đây.
D. Mạng nơ-ron sâu nhiều tầng để tối đa hiệu năng, bất kể tốn nhiều tài nguyên và thời gian huấn luyện lâu — vi phạm hai trong ba ràng buộc, và điều oái oăm là nó thường không chính xác hơn XGBoost trên dữ liệu bảng. Deep learning thắng ở ảnh, âm thanh và văn bản, không phải ở bảng số.
C. SVM với kernel phi tuyến để tăng độ chính xác, bất kể thời gian và chi phí tăng với dữ liệu lớn — SVM có độ phức tạp huấn luyện xấp xỉ O(n²) tới O(n³), nên với tập dữ liệu giao dịch lớn thì thời gian huấn luyện trở nên không chấp nhận được. Trái thẳng yêu cầu huấn luyện lại thường xuyên.

Ghi nhớ

Cách chọn thuật toán theo loại dữ liệu: | Loại dữ liệu | Thuật toán thường thắng | |---|---| | Dữ liệu bảng (số, danh mục) | gradient boosting: XGBoost, LightGBM | | Ảnh | CNN, vision transformer | | Văn bản | transformer | | Chuỗi thời gian | DeepAR, Prophet, hoặc gradient boosting với đặc trưng trễ |

Dòng đầu là điều hay bị bỏ qua: với dữ liệu bảng, cây quyết định vẫn là tiêu chuẩn vàng, và deep learning hiếm khi đáng công.

Ba kỹ thuật kiểm soát chi phí huấn luyện: | Kỹ thuật | Tiết kiệm | |---|---| | Early stopping | dừng khi hết cải thiện | | Managed Spot Training | giảm tới 90% chi phí instance | | Warm pool | giảm thời gian khởi động giữa các job liên tiếp |

Ba chiến lược tinh chỉnh siêu tham số của SageMaker: | Chiến lược | Đặc điểm | |---|---| | Bayesian | học từ các lần thử trước — hiệu quả nhất | | Random | song song tốt, đơn giản | | Grid | vét cạn, tốn nhất | | Hyperband | dừng sớm nhánh kém — tiết kiệm nhất |

Và một lưu ý riêng cho phát hiện gian lận: dữ liệu cực kỳ mất cân bằng (thường dưới 1% là gian lận). Với XGBoost, hai công cụ xử lý:

scale_pos_weight = so_mau_am / so_mau_duong    # tăng trọng số lớp thiểu số
eval_metric = 'aucpr'                           # PR-AUC, không phải accuracy

Dòng thứ hai quan trọng: accuracy vô nghĩa với dữ liệu mất cân bằng — một model đoán "không gian lận" cho tất cả vẫn đạt 99%. Dùng PR-AUC hoặc F1 mới phản ánh đúng.

Câu 4 ML Solution Monitoring, Maintenance, and Security

A retail company has deployed a machine learning (ML) model using Amazon SageMaker to forecast product demand. The model is exposed via a SageMaker endpoint that processes requests from multiple applications. The company needs to record and monitor all API call events made to the endpoint and receive a notification whenever the number of requests exceeds a specific threshold during peak traffic hours.

Which solution will meet these requirements?

A
Use SageMaker Model Monitor to capture and analyze endpoint traffic and configure a rule to notify when API calls exceed the specified threshold
B
Enable AWS CloudTrail to log all SageMaker API call events and use CloudTrail Insights to send notifications when the API call volume exceeds a threshold
C
Use Amazon EventBridge to capture SageMaker API call events and configure a rule to send a notification when the event count breaches the threshold
D
Use Amazon CloudWatch to monitor the API call metrics for the SageMaker endpoint and create an alarm to send notifications through Amazon SNS when the call count breaches the threshold

Xem giải thích

Đáp án

D — Dùng Amazon CloudWatch giám sát metric lời gọi API của endpoint SageMaker và tạo alarm gửi thông báo qua Amazon SNS khi số lượng lời gọi vượt ngưỡng.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều là việc cơ bản của CloudWatch: | Yêu cầu | Cơ chế | |---|---| | Ghi và giám sát lời gọi tới endpoint | metric Invocations tự động | | Thông báo khi vượt ngưỡng trong giờ cao điểm | CloudWatch alarm → SNS |

SageMaker tự động phát metric lên CloudWatch — không cần cấu hình gì thêm:

Namespace: AWS/SageMaker
  Invocations                    ← số lời gọi
  InvocationsPerInstance
  ModelLatency
  OverheadLatency
  Invocation4XXErrors / 5XXErrors

aws cloudwatch put-metric-alarm   --alarm-name canh-bao-tai-cao-endpoint   --metric-name Invocations --namespace AWS/SageMaker   --dimensions Name=EndpointName,Value=du-bao-nhu-cau                Name=VariantName,Value=AllTraffic   --statistic Sum --period 300 --threshold 10000   --comparison-operator GreaterThanThreshold   --evaluation-periods 2   --alarm-actions arn:aws:sns:...:canh-bao-ml

Hai chi tiết đáng nhớ trong lệnh trên: --statistic Sum (đếm tổng, không phải trung bình) và --evaluation-periods 2 (phải vượt ngưỡng hai chu kỳ liên tiếp mới báo — tránh báo động giả do một đỉnh nhất thời).

Vì sao các phương án khác sai

B. Bật CloudTrail ghi mọi sự kiện API của SageMaker và dùng CloudTrail Insights gửi thông báo khi khối lượng vượt ngưỡng — đây là phương án gần nhất và mắc một hiểu lầm quan trọng: CloudTrail ghi lời gọi API QUẢN LÝ (CreateEndpoint, DeleteModel), không ghi InvokeEndpoint ở mức mặc định. Lời gọi suy luận là data event, phải bật riêng và tốn kém. (CloudTrail Insights phát hiện bất thường trong hoạt động quản lý, không phải trong lưu lượng suy luận.)
C. Dùng EventBridge bắt sự kiện API của SageMaker và tạo rule gửi thông báo khi số sự kiện vượt ngưỡng — EventBridge định tuyến sự kiện, nó không đếm và không so ngưỡng. Một rule kích hoạt trên từng sự kiện; muốn đếm phải tự dựng bộ đếm. Và EventBridge cũng nhận sự kiện quản lý, không nhận từng lời gọi suy luận.
A. Dùng SageMaker Model Monitor bắt và phân tích lưu lượng endpoint, cấu hình rule thông báo khi vượt ngưỡng — sai công cụ: Model Monitor giám sát CHẤT LƯỢNG (data drift, model quality, bias), không giám sát KHỐI LƯỢNG. Nó phân tích nội dung request, không đếm request.

Ghi nhớ

Ba dịch vụ hay bị lẫn khi nói "giám sát": | Dịch vụ | Ghi gì | |---|---| | CloudWatch | metric số học: đếm, độ trễ, lỗi — và ALARM theo ngưỡng | | CloudTrail | AI đã gọi API nào — kiểm toán, không phải giám sát hiệu năng | | EventBridge | định tuyến sự kiện tới đích — không đếm, không so ngưỡng |

Câu hỏi để chọn:

"Tôi cần một con số so với ngưỡng?" → CloudWatch alarm "Tôi cần biết ai đã làm gì?" → CloudTrail "Tôi cần chạy gì đó khi có sự kiện?" → EventBridge

Các metric quan trọng của SageMaker endpoint: | Metric | Ý nghĩa | |---|---| | Invocations | số lời gọi — dùng cho câu này | | InvocationsPerInstance | cơ sở cho auto scaling | | ModelLatency | thời gian model xử lý | | OverheadLatency | thời gian SageMaker thêm vào | | Invocation5XXErrors | lỗi phía máy chủ |

Dòng ModelLatency với OverheadLatency đáng phân biệt khi gỡ lỗi chậm: nếu ModelLatency cao thì vấn đề ở model hoặc instance; nếu OverheadLatency cao thì thường là payload quá lớn hoặc vấn đề mạng.

Ba thống kê của alarm và khi nào dùng: | Thống kê | Dùng cho | |---|---| | Sum | đếm — số lời gọi, số lỗi | | Average | độ trễ trung bình | | p99 | độ trễ đuôi — phản ánh trải nghiệm tệ nhất |

Và một mẹo cho "giờ cao điểm" trong đề: nếu ngưỡng chỉ nên áp trong một khung giờ, dùng metric math với IF hoặc composite alarm kết hợp với một alarm về thời gian — thay vì đặt một ngưỡng cố định gây báo động giả ngoài giờ.

Câu 5 Chọn nhiều đáp án Deployment and Orchestration of ML Workflows

You are an ML Engineer working for a logistics company that uses multiple machine learning models to optimize delivery routes in real-time. Each model needs to process data quickly to provide up-to-the-minute route adjustments, but the company also has strict cost constraints. You need to deploy the models in an environment where performance, cost, and latency are carefully balanced. There may be slight variations in the access frequency of the models. Any excessive costs could impact the project’s profitability.

Which of the following strategies should you consider to balance the tradeoffs between performance, cost, and latency when deploying your model in Amazon SageMaker? (Select two)

A
Choose a lower-cost CPU instance, accepting longer inference times, as the savings on compute costs are more important than minimizing latency
B
Leverage Amazon SageMaker Neo to compile the model for optimized deployment on edge devices, reducing latency and cost but with limited scalability for large datasets
C
Use Amazon SageMaker’s multi-model endpoint to deploy multiple models on a single instance, reducing costs by sharing resources
D
Deploy the model on a high-performance GPU instance to minimize latency, regardless of the higher cost, ensuring real-time route adjustments
E
Implement auto-scaling on a fleet of medium-sized instances, allowing the system to adjust resources based on real-time demand, balancing cost and performance dynamically

Xem giải thích

Đáp án

C và E.

C — Dùng multi-model endpoint của SageMaker triển khai nhiều model trên một instance, giảm chi phí nhờ dùng chung tài nguyên
E — Auto scaling trên một đội instance cỡ trung, cho phép hệ thống điều chỉnh tài nguyên theo nhu cầu thực, cân bằng chi phí và hiệu năng động

Vì sao đúng

Đề nêu ba ràng buộc và một manh mối quan trọng: | Yếu tố | Chi tiết | |---|---| | Nhiều model | tối ưu tuyến đường | | Cần xử lý nhanh, thời gian thực | không hy sinh độ trễ | | Ràng buộc chi phí chặt | không cấp thừa | | "Slight variations in the access frequency" | model được gọi với tần suất khác nhau ← manh mối |

Manh mối cuối chính là điều kiện lý tưởng cho multi-model endpoint:

Nhiều endpoint riêng:
  model A (dùng nhiều)  → instance riêng, dùng 70%
  model B (dùng ít)     → instance riêng, dùng 5%   ← lãng phí
  model C (dùng ít)     → instance riêng, dùng 3%   ← lãng phí

Multi-model endpoint:
  A + B + C → CÙNG instance, nạp và loại bỏ động theo nhu cầu

MME hoạt động bằng cách nạp model vào bộ nhớ khi có request và loại bỏ model ít dùng — nên bạn trả tiền cho một instance thay vì ba, và model dùng nhiều vẫn luôn nằm sẵn trong bộ nhớ.

E — auto scaling xử lý chiều còn lại: MME giải quyết việc nhiều model chia sẻ tài nguyên, auto scaling giải quyết việc tải thay đổi theo thời gian:

autoscaling.put_scaling_policy(
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 1000.0,
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance'}})

Và "medium-sized instances" trong đáp án là lựa chọn có cân nhắc: instance cỡ trung cho hạt điều chỉnh mịn hơn khi co giãn, so với vài instance rất lớn.

Vì sao các phương án khác sai

D. Triển khai trên instance GPU hiệu năng cao để tối thiểu độ trễ, bất kể chi phí cao hơn — vi phạm thẳng ràng buộc chi phí mà đề nói có thể ảnh hưởng tới lợi nhuận dự án. Và model tối ưu tuyến đường thường là model dữ liệu bảng, không cần GPU.
A. Chọn instance CPU rẻ hơn, chấp nhận thời gian suy luận LÂU HƠN, vì tiết kiệm compute quan trọng hơn giảm độ trễ — đánh đổi sai chiều: đề nói rõ cần "process data quickly to provide up-to-the-minute route adjustments". Điều chỉnh tuyến đường đến muộn thì vô dụng.
B. Dùng SageMaker Neo biên dịch model cho thiết bị biên, giảm độ trễ và chi phí nhưng hạn chế khả năng mở rộng với dữ liệu lớn — sai kịch bản triển khai: đề không nhắc gì tới thiết bị biên; đây là hệ thống tập trung xử lý dữ liệu logistics. Và chính phương án tự thừa nhận "limited scalability".

Ghi nhớ

Ba cách tối ưu chi phí khi có nhiều model: | Cách | Cơ chế | Hợp với | |---|---|---| | Multi-model endpoint (MME) | nhiều model chia sẻ một instance, nạp động | nhiều model NHỎ, tần suất dùng KHÁC NHAU | | Multi-container endpoint | nhiều container khác framework trên một endpoint | model dùng framework khác nhau | | Serverless inference | co giãn về 0 | tải thưa, không đều | | Inference component | chia sẻ instance có kiểm soát tài nguyên | model lớn cần GPU |

Khi nào KHÔNG dùng MME: | Tình huống | Lý do | |---|---| | Model rất lớn | không đủ chỗ nạp nhiều model cùng lúc | | Mọi model đều được gọi liên tục | không có gì để loại bỏ — tranh chấp bộ nhớ | | Yêu cầu độ trễ p99 rất chặt | model chưa nạp gây cold start lần đầu |

Dòng cuối là đánh đổi thật của MME: một model lâu không dùng sẽ bị loại khỏi bộ nhớ, và request tiếp theo phải chờ nạp lại từ S3. Với tối ưu tuyến đường thời gian thực, nên giữ model dùng nhiều luôn ấm bằng cách gọi định kỳ.

Bốn loại chính sách auto scaling: | Loại | Cơ chế | |---|---| | Target tracking | giữ một metric ở mức mục tiêu — đơn giản và hiệu quả nhất | | Step scaling | thêm bớt theo bậc | | Scheduled | theo lịch biết trước | | Kết hợp target tracking + scheduled | mẫu tốt nhất cho tải có mùa vụ |

Và metric nên dùng cho auto scaling endpoint: SageMakerVariantInvocationsPerInstance — nó phản ánh trực tiếp lượng việc mỗi instance đang gánh, chính xác hơn CPU (vốn có thể thấp trong khi model đang chờ I/O).

Câu 6 Deployment and Orchestration of ML Workflows

You are an ML engineer at a retail company that uses a SageMaker model to generate product recommendations for customers in real-time. During peak shopping periods, the traffic to the recommendation engine increases dramatically. The company needs to ensure that the model endpoint can handle these spikes in demand without compromising on response time or customer experience. At the same time, you want to optimize costs by scaling down resources during periods of low demand. You are evaluating different scaling policies to manage this dynamic workload effectively.

Which scaling policy is the MOST SUITABLE for this scenario, and why?

A
Use a manual scaling policy where you adjust the number of instances based on real-time monitoring of traffic, allowing you to fine-tune resource allocation as needed during high-demand periods
B
Use a step scaling policy that adjusts the number of instances based on the size of the traffic spike, adding a set number of instances for each level of increased demand
C
Use scheduled scaling to preemptively add or remove instances based on anticipated traffic patterns, such as known peak times during Black Friday, to ensure sufficient capacity is available when needed
D
Use a target tracking scaling policy that automatically adjusts the number of instances based on a predefined target metric, such as CPU utilization or invocations per instance, to maintain a steady level of performance during traffic spikes

Xem giải thích

Đáp án

D — Dùng target tracking scaling policy tự động điều chỉnh số instance dựa trên một metric mục tiêu định trước như CPU utilization hoặc số lời gọi mỗi instance, để duy trì mức hiệu năng ổn định trong các đợt tăng tải.

Vì sao đúng

Đề nêu ba yêu cầu, và target tracking đáp ứng cả ba bằng một cơ chế: | Yêu cầu | Cơ chế | |---|---| | Chịu được đỉnh tải mà không giảm thời gian phản hồi | tự thêm instance khi metric vượt mục tiêu | | Tối ưu chi phí lúc tải thấp | tự giảm instance khi metric xuống dưới mục tiêu | | Quản lý tải động hiệu quả | không cần can thiệp thủ công |

Cách hoạt động — bạn khai kết quả mong muốn, AWS lo phần còn lại:

autoscaling.put_scaling_policy(
    PolicyName='theo-doi-so-loi-goi',
    ServiceNamespace='sagemaker',
    ResourceId='endpoint/goi-y-san-pham/variant/AllTraffic',
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 1000.0,              # mục tiêu: 1000 lời gọi/instance
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance'},
        'ScaleInCooldown': 300,
        'ScaleOutCooldown': 60})            # mở rộng nhanh, thu hẹp chậm

Hai giá trị cooldown khác nhau là chi tiết đáng nhớ: mở rộng nhanh (60 giây) để bắt kịp đỉnh tải, thu hẹp chậm (300 giây) để tránh dao động khi tải lên xuống.

Vì sao target tracking hơn step scaling cho tình huống này: nó tự tính toán mức điều chỉnh cần thiết, thay vì bạn phải đoán trước "tải tăng bao nhiêu thì thêm mấy instance". Với đỉnh tải mua sắm khó dự đoán, việc tự tính đó chính xác hơn nhiều bậc thang do người đặt.

Vì sao các phương án khác sai

C. Dùng scheduled scaling chủ động thêm bớt instance theo mẫu lưu lượng dự kiến, ví dụ giờ cao điểm Black Friday đã biết trước — đây là phương án đáng bàn và hữu ích trong thực tế, nhưng một mình thì không đủ: nó chỉ xử lý những đỉnh tải bạn dự đoán được. Một đợt tăng đột ngột ngoài lịch (bài viết lan truyền, khuyến mãi bất ngờ) sẽ không được xử lý. (Mẫu tốt nhất là kết hợp: scheduled đặt sàn cho ngày biết trước, target tracking lo phần còn lại.)
B. Step scaling policy thêm một số instance cố định theo từng mức tăng của lưu lượng — hoạt động được nhưng cần hiệu chỉnh thủ công các bậc, và bậc thang đặt sai thì hoặc phản ứng chậm hoặc cấp thừa. Target tracking loại bỏ việc đoán này.
A. Scaling thủ công — theo dõi lưu lượng thời gian thực rồi điều chỉnh số instance để tinh chỉnh — không khả thi: đỉnh tải mua sắm đến trong vài phút, và không ai ngồi canh 24/7. Trái yêu cầu "manage this dynamic workload effectively".

Ghi nhớ

Bốn loại chính sách auto scaling: | Loại | Cơ chế | Dùng khi | |---|---|---| | Target tracking | giữ metric ở mức mục tiêu | mặc định — đơn giản và hiệu quả nhất | | Step scaling | bậc thang theo mức vượt ngưỡng | cần kiểm soát chi tiết mức điều chỉnh | | Scheduled | theo lịch biết trước | sự kiện đã biết: Black Friday | | Manual | người tự đổi | môi trường dev |

Nguyên tắc thực dụng: target tracking làm nền, scheduled bổ sung cho ngày đặc biệt. Với Black Friday, đặt lịch nâng MinCapacity từ trước để không phải chờ auto scaling phản ứng khi đợt tăng bắt đầu.

Ba metric dùng cho auto scaling endpoint: | Metric | Đặc điểm | |---|---| | SageMakerVariantInvocationsPerInstance | phản ánh trực tiếp lượng việc — khuyến nghị | | CPUUtilization | có thể thấp trong khi model đang chờ I/O | | Custom metric (độ trễ p99) | chính xác nhất nhưng phải tự đẩy lên |

Dòng giữa đáng nhớ: CPU không phải chỉ báo tốt cho endpoint ML — một model chờ tải dữ liệu có CPU thấp trong khi đang quá tải thật.

Bốn tham số cần đặt đúng: | Tham số | Ảnh hưởng | |---|---| | TargetValue | đặt quá cao thì chậm phản ứng, quá thấp thì cấp thừa | | MinCapacity | sàn — đặt đủ để chịu tải nền, tránh cold start | | MaxCapacity | trần chi phí | | ScaleOutCooldown ngắn hơn ScaleInCooldown | lên nhanh, xuống chậm |

Và một giới hạn cần biết: auto scaling của SageMaker mất vài phút để instance mới sẵn sàng (tải image, nạp model). Với đỉnh tải dựng đứng, chỉ auto scaling là không đủ — đó chính là lý do nên kết hợp scheduled scaling cho những ngày đã biết trước.

Câu 7 Data Preparation for Machine Learning (ML)

A retail company trained an ML model on Amazon SageMaker to detect damaged products from warehouse surveillance images. The training dataset was created using SageMaker Data Wrangler, which included images of damaged and undamaged products. During training and validation, the model achieved high accuracy; however, in production, the model’s performance is degraded due to differences in lighting conditions and image quality across various warehouse locations. The ML engineer needs to improve the model's accuracy to handle variations in image quality with the LEAST amount of time and effort.

What do you recommend?

A
Fine-tune the model by manually collecting additional data from various cameras and retrain it with the new dataset
B
Use SageMaker Data Wrangler’s outlier detection transform to remove outlier images from the dataset and improve the model’s performance
C
Deploy a preprocessing pipeline in Amazon SageMaker to filter out low-quality images before sending them to the model for inference
D
Use SageMaker Data Wrangler’s corrupt image transform to preprocess the training data by simulating variations in image quality for robust model training

Xem giải thích

Đáp án

D — Dùng transform "corrupt image" của SageMaker Data Wrangler để tiền xử lý dữ liệu huấn luyện bằng cách mô phỏng các biến thể về chất lượng ảnh, giúp model huấn luyện bền vững hơn.

Vì sao đúng

Đề mô tả một tình huống kinh điển: model đạt độ chính xác cao lúc huấn luyện và kiểm chứng, nhưng kém trên production vì điều kiện ánh sáng và chất lượng ảnh khác nhau giữa các kho.

Nguyên nhân: tập huấn luyện không phản ánh sự đa dạng của thực tế. Model học được "sản phẩm hỏng trông thế nào trong điều kiện ánh sáng của kho A", chứ không học được đặc trưng bất biến với ánh sáng.

Data augmentation là cách chữa đúng, và Data Wrangler có transform sẵn cho việc này:

Ảnh gốc → sinh thêm các biến thể:
  ├─ thay đổi độ sáng và tương phản
  ├─ thêm nhiễu (Gaussian, muối tiêu)
  ├─ làm mờ (blur)
  ├─ nén JPEG chất lượng thấp
  └─ thay đổi độ bão hoà màu

Model huấn luyện trên tập đã tăng cường sẽ học đặc trưng của hư hỏng thay vì đặc trưng của điều kiện chụp — đó chính là tính bền vững mà đề cần.

Và ràng buộc "LEAST amount of time and effort" là điểm quyết định: đây là một transform có sẵn trong Data Wrangler, áp bằng vài cú nhấp — so với việc đi thu thập dữ liệu mới từ hàng chục kho.

Vì sao các phương án khác sai

A. Fine-tune bằng cách THU THẬP THỦ CÔNG thêm dữ liệu từ nhiều camera khác nhau rồi huấn luyện lại — đây là phương án cho kết quả tốt nhất về mặt chất lượng (dữ liệu thật luôn hơn dữ liệu mô phỏng), nhưng nó vi phạm thẳng ràng buộc "least time and effort": phải đi tới từng kho, chụp, gán nhãn — hàng tuần công việc. Data augmentation cho phần lớn lợi ích với một phần nhỏ công sức.
B. Dùng transform phát hiện ngoại lai của Data Wrangler LOẠI BỎ ảnh ngoại lai khỏi tập dữ liệu — đi ngược hoàn toàn: những ảnh "ngoại lai" (sáng khác thường, mờ) chính là thứ giống với production nhất. Loại chúng đi làm tập huấn luyện càng đồng nhất hơn và model càng mong manh hơn.
C. Triển khai pipeline tiền xử lý LỌC BỎ ảnh chất lượng thấp trước khi đưa vào model suy luận — né tránh vấn đề thay vì giải quyết: những ảnh bị lọc là sản phẩm thật cần kiểm tra, và bỏ qua chúng nghĩa là hàng hỏng lọt lưới. Kho có ánh sáng kém sẽ bị bỏ sót gần như toàn bộ.

Ghi nhớ

Data augmentation — vì sao nó hiệu quả:

Nó dạy model rằng những thay đổi này KHÔNG làm đổi nhãn.

Một sản phẩm hỏng vẫn là sản phẩm hỏng dù chụp sáng hay tối, rõ hay mờ. Augmentation làm cho điều đó tường minh trong dữ liệu huấn luyện.

Các phép augmentation cho ảnh, theo nhóm: | Nhóm | Phép | |---|---| | Hình học | lật, xoay, cắt, thu phóng, dịch chuyển | | Màu sắc | độ sáng, tương phản, bão hoà, sắc độ | | Nhiễu và chất lượng | Gaussian noise, blur, nén JPEG ← đúng vấn đề trong đề | | Che khuất | random erasing, cutout |

Chọn phép augmentation theo biến thể thật sự có ở production — đó là nguyên tắc quan trọng nhất. Đề nói vấn đề là ánh sáng và chất lượng ảnh, nên hai nhóm giữa và cuối là đúng trọng tâm. Lật ngang một sản phẩm có thể không giúp gì nếu camera luôn ở một góc cố định.

Và một cảnh báo: augmentation sai có thể làm hại. Lật dọc một ảnh chữ số biến "6" thành "9"; xoay quá mạnh một sản phẩm có hướng cố định tạo ra dữ liệu không bao giờ xuất hiện thật.

Bốn khả năng của SageMaker Data Wrangler cho ảnh: | Khả năng | Việc | |---|---| | Corrupt image | mô phỏng nhiễu, mờ, nén — tăng bền vững | | Resize / crop | chuẩn hoá kích thước | | Blur / sharpen | biến thể độ nét | | Data quality insights | phát hiện vấn đề trong tập dữ liệu |

Và ba dấu hiệu nhận biết bài toán cần augmentation thay vì thêm dữ liệu: | Dấu hiệu | Ý nghĩa | |---|---| | Chính xác cao lúc train, thấp lúc production | tập huấn luyện thiếu đa dạng | | Lỗi tập trung ở một điều kiện cụ thể | thiếu biến thể của điều kiện đó | | Chính xác thấp ở cả train lẫn validation | không phải vấn đề augmentation — model hoặc đặc trưng chưa đủ |

Dòng cuối quan trọng: augmentation chữa overfitting vào điều kiện chụp, nó không chữa được model học chưa đủ.

Câu 8 ML Model Development

You are a data scientist at a marketing agency tasked with creating a sentiment analysis model to analyze customer reviews for a new product. The company wants to quickly deploy a solution with minimal training time and development effort. You decide to leverage a pre-trained natural language processing (NLP) model and fine-tune it using a custom dataset of labeled customer reviews. Your team has access to both Amazon Bedrock and SageMaker JumpStart.

Which approach is the MOST APPROPRIATE for fine-tuning the pre-trained model with your custom dataset?

A
Use Amazon Bedrock to train a model from scratch using your custom dataset, as Bedrock is optimized for training large models efficiently
B
Use SageMaker JumpStart to deploy a pre-trained NLP model and use the built-in fine-tuning functionality with your custom dataset to create a customized sentiment analysis model
C
Use Amazon Bedrock to select a base foundation model from a third-party provider, then fine-tune the base model directly in the Bedrock interface using your custom dataset
D
Use SageMaker JumpStart to create a custom container for your pre-trained model and manually implement fine-tuning with TensorFlow

Xem giải thích

Đáp án

B — Dùng SageMaker JumpStart triển khai một model NLP đã huấn luyện sẵn và dùng chức năng fine-tune dựng sẵn với tập dữ liệu riêng để tạo model phân tích cảm xúc tuỳ chỉnh.

Vì sao đúng

Đề nêu ba yêu cầu, và JumpStart đáp ứng cả ba: | Yêu cầu | JumpStart | |---|---| | Triển khai nhanh, ít công sức | model đã huấn luyện sẵn, triển khai bằng vài dòng | | Tận dụng model NLP có sẵn | hàng trăm model từ Hugging Face và các nguồn khác | | Fine-tune với tập đánh giá đã gán nhãn | fine-tuning DỰNG SẴN — không phải viết mã huấn luyện |

Vế thứ ba là điểm quyết định, và nó phân biệt JumpStart với ba phương án còn lại:

from sagemaker.jumpstart.estimator import JumpStartEstimator

estimator = JumpStartEstimator(model_id='huggingface-tc-bert-base-uncased')
estimator.fit({'training': 's3://kho/danh-gia-da-gan-nhan/'})
predictor = estimator.deploy()

Ba dòng — không có script huấn luyện, không có container tuỳ chỉnh, không có vòng lặp tối ưu nào phải viết. Đó chính là "minimal training time and development effort".

Và fine-tune trên tập đánh giá riêng là bước đáng giá: model NLP chung hiểu cảm xúc nói chung, nhưng cảm xúc trong đánh giá sản phẩm có đặc thù riêng — "sản phẩm này gây nghiện" là tích cực, dù từ "nghiện" thường mang nghĩa xấu.

Vì sao các phương án khác sai

C. Dùng Bedrock chọn base model của nhà cung cấp bên thứ ba, rồi fine-tune ngay trong giao diện Bedrock với tập dữ liệu riêng — đây là phương án gần nhất và cần phân biệt kỹ. Bedrock có hỗ trợ fine-tuning (custom model), nhưng chỉ cho một số model nhất định, và nó nặng nề hơn nhiều cho một tác vụ phân loại đơn giản: bạn fine-tune một foundation model lớn để làm việc mà một model BERT nhỏ làm tốt hơn, nhanh hơn và rẻ hơn. (Đề cũng nói rõ đội đã có sẵn quyền dùng cả hai và cần "minimal training time" — JumpStart thắng ở đó.)
A. Dùng Bedrock huấn luyện model TỪ ĐẦU với tập dữ liệu riêng, vì Bedrock "tối ưu cho việc huấn luyện model lớn hiệu quả" — sai về chức năng: Bedrock không huấn luyện model từ đầu. Nó phục vụ foundation model có sẵn và hỗ trợ fine-tune, không phải pre-training. Và huấn luyện từ đầu trái thẳng yêu cầu "minimal training time".
D. Dùng JumpStart tạo container tuỳ chỉnh cho model và tự cài đặt fine-tuning bằng TensorFlow — bỏ qua chính giá trị của JumpStart: fine-tuning dựng sẵn tồn tại để bạn không phải viết mã. Tự viết bằng TensorFlow là quay lại công sức tối đa.

Ghi nhớ

Ba cách tuỳ biến model NLP, theo công sức tăng dần: | Cách | Công sức | Dùng khi | |---|---|---| | Dịch vụ AI có sẵn (Comprehend) | thấp nhất | tác vụ chuẩn, không cần tuỳ biến | | JumpStart + fine-tune dựng sẵn | thấp | cần tuỳ biến theo lĩnh vực ← câu này | | Bedrock custom model | vừa | cần năng lực của foundation model lớn | | Tự huấn luyện trên SageMaker | cao | kiến trúc riêng, kiểm soát hoàn toàn |

Một lưu ý đáng cân nhắc cho đề này: Amazon Comprehend custom classification cũng làm được việc phân tích cảm xúc tuỳ chỉnh với công sức còn thấp hơn. Nó không nằm trong bốn phương án, nhưng trong thực tế đáng thử trước — đặc biệt nếu khối lượng lớn và chỉ cần phân loại.

SageMaker JumpStart cung cấp gì: | Thành phần | Chi tiết | |---|---| | Model đã huấn luyện sẵn | hàng trăm model NLP, thị giác, bảng dữ liệu | | Fine-tuning dựng sẵn | script và container có sẵn cho từng model | | Solution templates | mẫu giải pháp đầu-cuối | | Notebook mẫu | ví dụ chạy được ngay |

Phân biệt hai dịch vụ hay bị lẫn: | | JumpStart | Bedrock | |---|---|---| | Model | mã nguồn mở, bạn tự host | foundation model được quản lý | | Hạ tầng | bạn quản lý endpoint | serverless | | Fine-tune | dựng sẵn cho nhiều model | có, cho một số model | | Chi phí | instance-giờ | theo token | | Hợp với | model nhỏ, tác vụ chuyên biệt, khối lượng ổn định | tác vụ ngôn ngữ tổng quát |

Dòng "chi phí" đáng nhớ: với một model phân loại nhỏ chạy khối lượng lớn liên tục, instance-giờ thường rẻ hơn nhiều so với trả theo token của foundation model.

Câu 9 Data Preparation for Machine Learning (ML)

A manufacturing company is building an anomaly detection system to identify defective products in its production lines. The datasets include sensor logs from IoT devices stored in Amazon S3 and a list of production metadata from an on-premises SQL database.

The company must:

Aggregate and preprocess the data from multiple sources.

Implement a solution to detect anomalies automatically in the sensor data.

Visualize the results for analysis by the operations team.

Which solution will meet these requirements most efficiently?

A
Use Amazon SageMaker Data Wrangler to aggregate, clean, and prepare data for anomaly detection while generating visual insights
B
Use Amazon EMR with Spark MLlib to run anomaly detection algorithms and visualize the results using custom dashboards
C
Use Amazon Athena to query the sensor data and identify anomalies through SQL queries. Use Amazon QuickSight to visualize the results
D
Use Amazon Kinesis Data Streams to process and analyze the sensor data in real time for anomaly detection. Use Amazon QuickSight to visualize the results

Xem giải thích

Đáp án

A — Dùng Amazon SageMaker Data Wrangler để gộp, làm sạch và chuẩn bị dữ liệu cho việc phát hiện bất thường, đồng thời sinh thông tin trực quan.

Vì sao đúng

Đề nêu ba yêu cầu và một tiêu chí, và Data Wrangler bao được cả ba trong một công cụ: | Yêu cầu | Data Wrangler | |---|---| | Gộp và tiền xử lý dữ liệu từ nhiều nguồn | connector cho S3 và JDBC (SQL tại chỗ) | | Phát hiện bất thường trong dữ liệu cảm biến | built-in transform và Quick Model | | Trực quan hoá cho đội vận hành | biểu đồ và Data Quality Insights dựng sẵn | | Hiệu quả nhất | một giao diện, ít mã |

Vế gộp nhiều nguồn là điểm mạnh rõ nhất: Data Wrangler nối được S3 (log cảm biến) và cơ sở dữ liệu qua JDBC (metadata sản xuất), rồi join chúng bằng thao tác kéo thả — thay vì viết job Spark.

Nguồn 1: S3 (log cảm biến IoT, Parquet)
Nguồn 2: JDBC (SQL Server tại chỗ, metadata sản xuất)
    ↓ Join theo mã dây chuyền + thời điểm
    ↓ Transform: xử lý thiếu, chuẩn hoá thang đo, tạo đặc trưng trễ
    ↓ Quick Model: đánh giá nhanh khả năng phát hiện
    ↓ Xuất ra: Feature Store, S3, hoặc SageMaker Pipeline

Và "most efficiently" là tiêu chí quyết định: ba phương án còn lại đều yêu cầu ghép nhiều dịch vụ và viết mã, trong khi Data Wrangler làm cả ba việc trong một luồng.

(Cần nói rõ giới hạn: Data Wrangler không phải một hệ thống phát hiện bất thường production. Nó chuẩn bị dữ liệu và cho đánh giá nhanh; model phát hiện bất thường thật vẫn cần huấn luyện — thường bằng Random Cut Forest — và triển khai riêng. Đáp án A đúng theo tiêu chí "gộp, tiền xử lý và trực quan hoá hiệu quả nhất", không phải theo nghĩa nó thay thế toàn bộ pipeline.)

Vì sao các phương án khác sai

B. EMR với Spark MLlib chạy thuật toán phát hiện bất thường và trực quan hoá bằng dashboard tự dựng — mạnh nhưng tốn công nhất: quản lý cụm EMR, viết mã Spark, và tự dựng dashboard. Với dữ liệu quy mô vừa và một đội vận hành nhà máy, đây là công cụ quá nặng.
D. Kinesis Data Streams xử lý và phân tích dữ liệu cảm biến theo thời gian thực, trực quan hoá bằng QuickSight — kiến trúc streaming cho một bài toán không nêu yêu cầu thời gian thực. Và nó không giải quyết vế gộp với metadata từ SQL tại chỗ — Kinesis không nối được với cơ sở dữ liệu quan hệ.
C. Dùng Athena truy vấn dữ liệu cảm biến và tìm bất thường bằng câu SQL, trực quan hoá bằng QuickSight — SQL không phát hiện được bất thường phi tuyến: bạn chỉ viết được ngưỡng cứng ("nhiệt độ > 80"), trong khi bất thường thật thường là tổ hợp bất thường của nhiều chỉ số bình thường. Và Athena không đọc được cơ sở dữ liệu tại chỗ.

Ghi nhớ

SageMaker Data Wrangler — bốn khả năng: | Khả năng | Chi tiết | |---|---| | Kết nối nhiều nguồn | S3, Athena, Redshift, Snowflake, Databricks, JDBC | | 300+ transform dựng sẵn | join, xử lý thiếu, mã hoá, chuẩn hoá, cân bằng lớp | | Data Quality and Insights Report | phát hiện rò rỉ mục tiêu, ngoại lai, mất cân bằng | | Quick Model | huấn luyện thử nhanh để ước lượng chất lượng đặc trưng |

Ba thuật toán phát hiện bất thường trên AWS: | Thuật toán | Đặc điểm | |---|---| | Random Cut Forest (RCF) | không giám sát, dựng sẵn trong SageMaker, hợp với chuỗi thời gian | | Lookout for Equipment | dịch vụ chuyên cho cảm biến thiết bị công nghiệp | | Kinesis Data Analytics RANDOM_CUT_FOREST | phát hiện bất thường trên luồng SQL |

Dòng giữa đáng biết riêng: với bài toán đúng như đề mô tả (cảm biến IoT trên dây chuyền sản xuất), Amazon Lookout for Equipment là dịch vụ được xây riêng — nó không nằm trong bốn phương án, nhưng trong thực tế nên cân nhắc.

Ba loại bất thường trong dữ liệu cảm biến: | Loại | Ví dụ | |---|---| | Điểm (point) | một giá trị vượt xa bình thường — SQL bắt được | | Ngữ cảnh (contextual) | bình thường nói chung nhưng bất thường lúc này — cần model | | Tập hợp (collective) | từng giá trị bình thường nhưng CHUỖI thì bất thường — cần model |

Hai loại sau là lý do SQL không đủ, và cũng là lý do phương án C bị loại.

Câu 10 Data Preparation for Machine Learning (ML)

A research organization collects weather data from multiple sensor devices across various locations. The data is stored as CSV files in a central Amazon S3 bucket. The CSV files contain the same schema, with an observation date column to record when each reading was taken. The organization needs to perform ad-hoc queries on the data to filter and analyze based on the observation date.

The solution must enable efficient querying. Which solution will meet this requirement with the LEAST operational overhead?

A
Stream the new CSV files into Amazon Redshift and query the data using SQL filters on the observation date column
B
Use AWS Glue to create an ETL job that partitions and transforms the CSV files for querying by the observation date and processes the output into a new S3 bucket
C
Use Amazon EMR with Apache Hive to preprocess the CSV files and filter the data using HiveQL
D
Use Amazon Athena and run a CTAS (CREATE TABLE AS SELECT) query with partitioning enabled on the observation date column to query and optimize the CSV files based on the observation date column

Xem giải thích

Đáp án

D — Dùng Amazon Athena và chạy truy vấn CTAS (CREATE TABLE AS SELECT) có bật phân vùng theo cột ngày quan sát để truy vấn và tối ưu các tệp CSV.

Vì sao đúng

Đề nêu hai yêu cầu, và cụm quyết định là "LEAST operational overhead": | Yêu cầu | Cơ chế | |---|---| | Truy vấn ad-hoc lọc theo ngày quan sát | Athena — SQL trực tiếp trên S3 | | Truy vấn hiệu quả | phân vùng theo ngày | | Ít vận hành nhất | serverless, một câu lệnh SQL |

Vì sao phân vùng tạo khác biệt lớn:

Không phân vùng:  mỗi truy vấn QUÉT TOÀN BỘ mọi tệp CSV
                  → chậm và tốn tiền (Athena tính theo dữ liệu quét)

Có phân vùng:     s3://.../ngay_quan_sat=2026-07-15/
                  → truy vấn WHERE ngay_quan_sat = '2026-07-15'
                    chỉ đọc ĐÚNG thư mục đó

Và CTAS làm cả hai việc trong một câu lệnh: tạo bảng mới, phân vùng, và chuyển sang định dạng cột:

CREATE TABLE du_lieu_thoi_tiet_toi_uu
WITH (
  format = 'PARQUET',
  parquet_compression = 'SNAPPY',
  partitioned_by = ARRAY['ngay_quan_sat'],
  external_location = 's3://kho/thoi-tiet-toi-uu/'
) AS
SELECT tram_do, nhiet_do, do_am, ap_suat, ngay_quan_sat
FROM du_lieu_thoi_tiet_csv;

Chuyển sang Parquet là lợi ích thứ hai và thường lớn hơn: định dạng cột nghĩa là truy vấn chỉ đọc những cột nó cần, và nén tốt hơn CSV nhiều lần. Kết hợp cả hai thường giảm dữ liệu quét hàng chục lần.

Vì sao các phương án khác sai

B. Dùng AWS Glue tạo job ETL phân vùng và biến đổi các tệp CSV để truy vấn theo ngày, xuất ra bucket S3 mới — đây là phương án gần nhất và cho kết quả tương đương, nhưng nó tốn vận hành hơn: phải viết job, cấu hình, lên lịch, và giám sát. CTAS làm cùng việc bằng một câu SQL trong Athena. Với tiêu chí "least operational overhead", đó là khác biệt quyết định.
C. Dùng EMR với Apache Hive tiền xử lý CSV và lọc bằng HiveQL — nặng nhất trong bốn: phải khởi tạo và quản lý cụm EMR cho một việc mà Athena làm serverless.
A. Stream các tệp CSV mới vào Amazon Redshift và truy vấn bằng SQL lọc theo cột ngày — thêm một kho dữ liệu phải vận hành: Redshift cần quản lý cụm (hoặc workgroup), quản lý nạp dữ liệu, và trả tiền liên tục. Với truy vấn ad-hoc (không thường xuyên), Athena hợp hơn nhiều về cả chi phí lẫn công sức.

Ghi nhớ

Hai kỹ thuật tối ưu Athena — nên dùng cùng nhau: | Kỹ thuật | Giảm gì | |---|---| | Phân vùng (partitioning) | số tệp phải đọc — theo điều kiện WHERE | | Định dạng cột (Parquet, ORC) | số cột phải đọc + kích thước nhờ nén |

Athena tính tiền theo lượng dữ liệu quét, nên cả hai kỹ thuật giảm trực tiếp cả thời gian lẫn chi phí.

Ba cách tạo phân vùng: | Cách | Đặc điểm | |---|---| | CTAS | một câu SQL, làm luôn cả chuyển định dạng ← câu này | | Glue crawler | tự phát hiện phân vùng có sẵn theo cấu trúc thư mục | | ALTER TABLE ADD PARTITION | thêm thủ công từng phân vùng | | Partition projection | suy ra phân vùng từ mẫu, không cần metadata — nhanh nhất với số phân vùng lớn |

Dòng cuối đáng biết cho dữ liệu chuỗi thời gian: partition projection cho phép Athena tự suy ra phân vùng theo ngày mà không phải ghi hàng nghìn phân vùng vào Glue Catalog — tránh được vấn đề MSCK REPAIR TABLE chạy rất lâu khi số phân vùng lớn.

Nguyên tắc chọn khoá phân vùng: | Nguyên tắc | Chi tiết | |---|---| | Chọn cột hay dùng trong WHERE | ngày quan sát — đúng với đề | | Đừng phân vùng quá mịn | hàng chục nghìn phân vùng nhỏ làm chậm việc lập kế hoạch truy vấn | | Kích thước tệp hợp lý | 128 MB – 1 GB mỗi tệp là khoảng tốt |

Dòng giữa là bẫy hay gặp: phân vùng theo giờ thay vì ngày có thể tạo ra quá nhiều phân vùng nhỏ, và chi phí liệt kê chúng vượt qua lợi ích lọc.

Và một lưu ý về CTAS: nó có giới hạn 100 phân vùng mỗi câu lệnh. Với dữ liệu nhiều năm, phải chạy nhiều lần theo khoảng thời gian, hoặc dùng INSERT INTO sau khi đã tạo bảng.