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

Tìm thấy 195 câu.

Câu 11 Deployment and Orchestration of ML Workflows

You are a lead machine learning engineer at a growing tech startup that is developing a recommendation system for a mobile app. The recommendation engine must be able to scale quickly as the user base grows, remain cost-effective to align with the startup’s budget constraints, and be easy to maintain by a small team of engineers. The company has decided to use AWS for the ML infrastructure. Your goal is to design an infrastructure that meets these needs, ensuring that it can handle rapid scaling, remains within budget, and is simple to update and monitor.

Which combination of practices and AWS services is MOST LIKELY to result in a maintainable, scalable, and cost-effective ML infrastructure?

  1. A

    Train models using Amazon EMR for cost efficiency, deploy the models using AWS Lambda for serverless inference, and manually monitor the system using CloudWatch to reduce operational overhead
  2. B

    Implement Amazon SageMaker for model training, deploy the models using Amazon EC2 with manual scaling to handle inference, and use AWS CloudFormation for managing infrastructure as code to ensure repeatability
  3. C

    Use Amazon SageMaker for training, deploy models on Amazon ECS for flexible scaling, and implement infrastructure monitoring with a combination of CloudWatch and AWS Systems Manager to ensure maintainability
  4. D

    Use Amazon SageMaker for both training and deployment, leverage auto-scaling endpoints for real-time inference, and apply SageMaker Pipelines for orchestrating end-to-end ML workflows, ensuring scalability and automation
Xem giải thích

Đáp án

D — Dùng Amazon SageMaker cho cả huấn luyện lẫn triển khai, tận dụng auto-scaling endpoint cho suy luận thời gian thực, và áp SageMaker Pipelines điều phối quy trình ML đầu-cuối.

Vì sao đúng

Đề nêu ba tiêu chí, và D đáp ứng cả ba bằng cách giữ mọi thứ trong một dịch vụ được quản lý: | Tiêu chí | Cơ chế | |---|---| | Mở rộng nhanh khi người dùng tăng | auto-scaling endpoint | | Hiệu quả chi phí | co giãn theo tải, không cấp thừa | | Dễ bảo trì bởi đội nhỏ | một dịch vụ, không quản lý hạ tầng |

Tiêu chí cuối là điểm quyết định cho một startup: đội kỹ sư nhỏ. Mỗi dịch vụ thêm vào là thêm một thứ phải học, phải giám sát, phải vá lỗi.

SageMaker (một dịch vụ):
  ├─ Training job        → huấn luyện, tự tắt khi xong
  ├─ Auto-scaling endpoint → suy luận, co giãn theo tải
  ├─ Model Registry      → version và phê duyệt
  └─ Pipelines           → điều phối, chạy lại khi có dữ liệu mới

SageMaker Pipelines cho vế "dễ cập nhật": quy trình từ chuẩn bị dữ liệu tới triển khai được khai báo thành mã, chạy lại được, và có lineage tracking tự động — nên khi một model có vấn đề, đội nhỏ vẫn truy được nó sinh ra từ đâu.

Và training job của SageMaker chỉ tính tiền khi chạy — không có instance nào nằm chờ, đúng nhu cầu tiết kiệm của startup.

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

  • C. SageMaker để huấn luyện, triển khai trên Amazon ECS cho co giãn linh hoạt; giám sát bằng CloudWatch kết hợp Systems Manager — đây là phương án gần nhất và hoạt động tốt về kỹ thuật, nhưng nó thêm gánh nặng vận hành: đội phải quản lý task definition, service, cluster capacity, và ghép hai hệ giám sát. SageMaker endpoint làm cùng việc mà không cần gì trong số đó.
  • B. SageMaker huấn luyện, triển khai trên EC2 với scaling THỦ CÔNG; dùng CloudFormation để hạ tầng là mã — scaling thủ công trái thẳng yêu cầu "scale quickly as the user base grows". Và quản lý EC2 (vá lỗi, AMI, load balancer) là công việc mà đội nhỏ không nên gánh.
  • A. Huấn luyện bằng EMR, triển khai bằng Lambda, giám sát THỦ CÔNG bằng CloudWatch — ba vấn đề: EMR cần quản lý cụm, Lambda có giới hạn kích thước gói (250 MB giải nén, 10 GB với container) nên không hợp model lớn, và "manually monitor" không phải cách giảm gánh nặng vận hành — nó chuyển gánh nặng sang con người.

Ghi nhớ

Ba lựa chọn triển khai model — theo gánh nặng vận hành: | Lựa chọn | Vận hành | Hợp với | |---|---|---| | SageMaker endpoint | thấp nhất — được quản lý hoàn toàn | hầu hết trường hợp | | ECS/EKS | vừa — quản lý container | cần môi trường runtime tuỳ chỉnh | | EC2 | cao — quản lý máy | yêu cầu rất đặc thù | | Lambda | thấp | model NHỎ, tải thưa |

Nguyên tắc cho đội nhỏ:

Mỗi dịch vụ thêm vào là một chi phí vận hành thường trực. Chọn ít dịch vụ hơn, kể cả khi mỗi cái không tối ưu tuyệt đối.

Bốn thành phần của SageMaker nên dùng cùng nhau: | Thành phần | Việc | |---|---| | Training jobs | huấn luyện, chỉ trả tiền lúc chạy | | Endpoints (auto-scaling) | suy luận thời gian thực | | Model Registry | version, phê duyệt, rollback | | Pipelines | điều phối và tự động hoá |

Ba cách tiết kiệm chi phí trong SageMaker mà startup nên bật ngay: | Cách | Tiết kiệm | |---|---| | Managed Spot Training | tới 90% chi phí huấn luyện | | Auto-scaling với MinCapacity thấp | không trả tiền cho instance nhàn rỗi | | Serverless inference | co về 0 — hợp với giai đoạn đầu tải thưa |

Dòng cuối đáng cân nhắc cho một startup mới: serverless inference không tốn gì khi không có request, đổi lại có cold start. Khi lượng người dùng ổn định và tăng lên, chuyển sang endpoint real-time với auto scaling — như đáp án D mô tả.

Và một điểm về khả năng bảo trì hay bị bỏ qua: hạ tầng là mã. Dù chọn SageMaker, vẫn nên khai endpoint và pipeline bằng CDK hoặc CloudFormation — để dựng lại được môi trường và biết ai đổi gì. Đây là điều phương án B nói đúng, dù các vế khác của nó sai.

Câu 12 ML Model Development

A retail company is developing a customer churn prediction model on AWS to identify customers likely to cancel their subscriptions. The training dataset includes customer purchase history, support interaction logs, and subscription data. The purchase history and support logs are stored in Amazon S3, while the subscription data resides in an on-premises PostgreSQL database.

The dataset has two major challenges:

A class imbalance where very few customers are labeled as "churned", impacting the model’s learning.

There are strong feature interdependencies among categorical features (e.g., "membership tier") and numerical features (e.g., "purchase frequency").

The ML engineer needs to select an Amazon SageMaker built-in algorithm to train the model and address the challenges with the least operational effort. Which algorithm should the ML engineer use to meet these requirements?

  1. A

    Amazon SageMaker Random Cut Forest (RCF)
  2. B

    Amazon SageMaker K-Means
  3. C

    Amazon SageMaker Linear Learner
  4. D

    Amazon SageMaker Neural Topic Model (NTM)
Xem giải thích

Đáp án

C — Amazon SageMaker Linear Learner.

Vì sao đúng

Đề nêu bài toán và hai thách thức: | Yếu tố | Chi tiết | |---|---| | Bài toán | dự đoán khách hàng rời bỏ — phân loại NHỊ PHÂN có giám sát | | Thách thức 1 | mất cân bằng lớp nặng | | Thách thức 2 | phụ thuộc lẫn nhau giữa đặc trưng phân loại và số | | Ràng buộc | ít công sức vận hành nhất |

Bước lọc đầu tiên loại ngay ba phương án: đây là bài toán có giám sát, phân loại nhị phân, và trong bốn lựa chọn chỉ Linear Learner thuộc loại đó.

Thuật toán Loại
Linear Learner có giám sát — phân loại và hồi quy ✅
Random Cut Forest không giám sát — phát hiện bất thường ❌
K-Means không giám sát — phân cụm ❌
Neural Topic Model không giám sát — mô hình chủ đề văn bản ❌

Và Linear Learner có cơ chế dựng sẵn cho mất cân bằng lớp — đúng thách thức thứ nhất:

linear = sagemaker.estimator.Estimator(image_uri, role, ...)
linear.set_hyperparameters(
    predictor_type='binary_classifier',
    balance_multiclass_weights=True,        # tự cân bằng trọng số lớp
    binary_classifier_model_selection_criteria='f1')   # chọn theo F1, không phải accuracy

Dòng cuối đáng chú ý: Linear Learner huấn luyện nhiều model song song với các siêu tham số khác nhau và tự chọn model tốt nhất theo tiêu chí bạn đặt. Với dữ liệu mất cân bằng, chọn theo F1 hoặc precision-recall thay vì accuracy là điều bắt buộc — và nó có sẵn tuỳ chọn đó.

Vế "least operational effort" cũng được đáp ứng: thuật toán dựng sẵn nghĩa là không viết mã huấn luyện, không dựng container.

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

  • A. Random Cut Forest (RCF) — đây là phương án dễ chọn nhầm vì "khách hàng rời bỏ là thiểu số" nghe giống bài toán bất thường. Nhưng RCF là không giám sát — nó không dùng nhãn trong khi đề nói rõ có dữ liệu đã gán nhãn "churned". Bỏ nhãn đi là vứt bỏ thông tin quý nhất.
  • B. K-Means — phân cụm không giám sát: nó nhóm khách hàng giống nhau lại, nhưng không dự đoán được ai sẽ rời bỏ. Có thể dùng để phân khúc khách hàng như một bước phụ trợ, không phải để giải bài toán chính.
  • D. Neural Topic Model (NTM) — mô hình chủ đề cho VĂN BẢN: nó tìm các chủ đề ẩn trong tập tài liệu. Có thể hữu ích để phân tích log hỗ trợ khách hàng thành đặc trưng, nhưng không phải model dự đoán rời bỏ.

Ghi nhớ

Các thuật toán dựng sẵn của SageMaker — phân theo loại bài toán: | Bài toán | Thuật toán | |---|---| | Phân loại / hồi quy (dữ liệu bảng) | Linear Learner, XGBoost, Factorization Machines | | Phát hiện bất thường | Random Cut Forest, IP Insights | | Phân cụm | K-Means | | Giảm chiều | PCA | | Chủ đề văn bản | LDA, Neural Topic Model | | Phân loại văn bản | BlazingText | | Chuỗi thời gian | DeepAR | | Ảnh | Image Classification, Object Detection |

Cách nhận biết nhanh trong đề thi:

Có nhãn và cần dự đoán nhãn đó → có giám sát. Không có nhãn, tìm cấu trúc ẩn → không giám sát.

Ba cách xử lý mất cân bằng lớp: | Cách | Chi tiết | |---|---| | Trọng số lớp | balance_multiclass_weights — Linear Learner có sẵn | | Oversampling lớp thiểu số | SMOTE, hoặc "balance data" của Data Wrangler | | Undersampling lớp đa số | vứt dữ liệu — ít khi tốt |

Và ba chỉ số đánh giá đúng cho dữ liệu mất cân bằng: | Chỉ số | Vì sao | |---|---| | F1 | cân bằng precision và recall | | PR-AUC | phù hợp hơn ROC-AUC khi lớp dương rất hiếm | | Recall | khi bỏ sót tốn kém hơn báo nhầm |

Accuracy là chỉ số sai ở đây: nếu chỉ 2% khách rời bỏ, một model đoán "không ai rời bỏ" đạt 98% accuracy mà hoàn toàn vô dụng.

(Ghi chú: đề nêu "strong feature interdependencies" như một thách thức, và XGBoost xử lý tương tác đặc trưng tốt hơn hẳn model tuyến tính. Nhưng XGBoost không có trong bốn phương án, nên Linear Learner là lựa chọn đúng trong phạm vi câu hỏi. Trong thực tế, với dữ liệu bảng và mất cân bằng, XGBoost thường là lựa chọn đầu tiên.)

Câu 13 Deployment and Orchestration of ML Workflows

You are an ML engineer at a data analytics company tasked with training a deep learning model on a large, computationally intensive dataset. The training job can tolerate interruptions and is expected to run for several hours or even days, depending on the available compute resources. The company has a limited budget for cloud infrastructure, so you need to minimize costs as much as possible.

Which strategy is the MOST EFFECTIVE for your ML training job while minimizing cost and ensuring the job completes successfully?

  1. A

    Deploy the training job on a fixed number of On-Demand EC2 instances to ensure stability, and manually add Spot Instances as needed to speed up the job during off-peak hours
  2. B

    Use Amazon EC2 Auto Scaling to automatically add Spot Instances to the training job based on demand, and configure the job to continue processing even if some Spot Instances are interrupted
  3. C

    Use Amazon SageMaker Managed Spot Training to dynamically allocate Spot Instances for the training job, automatically retrying any interrupted instances via checkpoints
  4. D

    Start the training job using only Spot Instances to minimize cost, and switch to On-Demand instances manually if any Spot Instances are interrupted during training
Xem giải thích

Đáp án

C — Dùng SageMaker Managed Spot Training để cấp phát Spot Instance động cho job huấn luyện, tự động thử lại các instance bị ngắt thông qua checkpoint.

Vì sao đúng

Đề nêu ba điều kiện, và cả ba đều chỉ về Spot: | Điều kiện | Ý nghĩa | |---|---| | Job chịu được gián đoạn | đủ điều kiện dùng Spot | | Chạy vài giờ tới vài ngày | tiết kiệm tích luỹ rất lớn | | Ngân sách hạn chế | Spot giảm tới 90% |

Managed Spot Training là cách dùng Spot đúng đắn nhất, vì SageMaker lo toàn bộ phần khó:

estimator = Estimator(
    image_uri=image, role=role, instance_type='ml.p3.2xlarge',
    use_spot_instances=True,
    max_run=86400,              # thời gian huấn luyện tối đa
    max_wait=172800,            # thời gian chờ Spot + huấn luyện
    checkpoint_s3_uri='s3://kho/checkpoint/')

Checkpoint là mảnh làm cho toàn bộ chuyện này khả thi:

Huấn luyện → lưu checkpoint lên S3 định kỳ
    ↓ Spot bị thu hồi
SageMaker chờ Spot có lại
    ↓ khởi động lại
Nạp checkpoint gần nhất và TIẾP TỤC — không bắt đầu lại từ đầu

Không có checkpoint, mỗi lần bị ngắt là mất toàn bộ tiến độ — và với job chạy vài ngày, xác suất bị ngắt ít nhất một lần là rất cao.

Và max_wait lớn hơn max_run là chi tiết cần đặt đúng: nó cho SageMaker thời gian chờ Spot khả dụng bên cạnh thời gian huấn luyện thật.

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

  • B. EC2 Auto Scaling tự thêm Spot Instance theo nhu cầu và cấu hình job tiếp tục xử lý kể cả khi một số Spot bị ngắt — đây là phương án gần nhất và về nguyên tắc là đúng hướng, nhưng nó tự dựng lại thứ Managed Spot Training làm sẵn: bạn phải tự lo checkpoint, tự xử lý việc thu hồi, tự khởi động lại, tự quản lý AMI và cụm. Với tiêu chí "most effective", công cụ được quản lý thắng.
  • A. Chạy trên số EC2 On-Demand cố định để ổn định, thêm Spot thủ công khi cần tăng tốc trong giờ thấp điểm — trả giá On-Demand cho phần lớn workload, trong khi job hoàn toàn chịu được gián đoạn. Và "thêm thủ công" là công việc tay không cần thiết.
  • D. Bắt đầu chỉ bằng Spot, chuyển sang On-Demand THỦ CÔNG nếu bị ngắt — không khả thi cho job chạy nhiều ngày: ai đó phải canh và can thiệp mỗi lần bị thu hồi, có thể vào lúc nửa đêm. Và nếu không có checkpoint thì việc chuyển sang On-Demand cũng phải bắt đầu lại từ đầu.

Ghi nhớ

Ba lựa chọn mua compute cho huấn luyện: | Lựa chọn | Giá | Điều kiện | |---|---|---| | On-Demand | cơ sở | job không chịu được gián đoạn | | Spot | giảm tới 90% | job chịu được gián đoạn + có checkpoint | | Savings Plans / Reserved | giảm ~40% | khối lượng ổn định, cam kết dài hạn |

Điều kiện dùng Spot — cả hai đều bắt buộc:

  1. Workload chịu được gián đoạn
  2. Có checkpoint — nếu không, tiết kiệm được tiền nhưng mất thời gian nhiều hơn

Ba loại workload phù hợp với Spot: | Workload | Vì sao | |---|---| | Huấn luyện model | có checkpoint tự nhiên theo epoch | | Xử lý dữ liệu theo lô | chia nhỏ được, chạy lại được | | Tinh chỉnh siêu tham số | mỗi lần thử độc lập — mất một cái không sao |

Và ba loại không nên dùng Spot: | Workload | Vì sao | |---|---| | Endpoint suy luận production | bị thu hồi là dịch vụ đứt | | Job có hạn chót cứng | không đảm bảo có Spot | | Job không thể checkpoint | mất toàn bộ tiến độ |

Hai tham số quan trọng của Managed Spot Training: | Tham số | Việc | |---|---| | max_run | thời gian huấn luyện tối đa | | max_wait | tổng thời gian gồm cả chờ Spot — phải ≥ max_run |

Và một chỉ số nên xem sau mỗi job: Managed Spot Training savings hiện trong log — nó cho biết thực tế tiết kiệm được bao nhiêu phần trăm, hữu ích để quyết định có nên dùng Spot cho loại instance đó nữa không.

Với instance GPU khan hiếm (như p4d, p5), tỷ lệ bị thu hồi có thể cao và thời gian chờ dài — khi đó cân nhắc SageMaker Training Plans hoặc capacity reservation thay vì Spot.

Câu 14 ML Model Development

You are a data scientist at a financial technology company developing a fraud detection system. The system needs to identify fraudulent transactions in real-time based on patterns in transaction data, including amounts, locations, times, and account histories. The dataset is large and highly imbalanced, with only a small percentage of transactions labeled as fraudulent. Your team has access to Amazon SageMaker and is considering various built-in algorithms to build the model.

Given the need for both high accuracy and the ability to handle imbalanced data, which SageMaker built-in algorithm is the MOST SUITABLE for this use case?

  1. A

    Select the Random Cut Forest (RCF) algorithm for its ability to detect anomalies in transaction data
  2. B

    Use the Linear Learner algorithm with weighted classification to address the class imbalance
  3. C

    Apply the XGBoost algorithm with a custom objective function to optimize for precision and recall
  4. D

    Implement the K-Nearest Neighbors (k-NN) algorithm to classify transactions based on similarity to known fraudulent cases
Xem giải thích

Đáp án

C — Áp dụng XGBoost với hàm mục tiêu tuỳ chỉnh để tối ưu cho precision và recall.

Vì sao đúng

Đề nêu ba yếu tố, và XGBoost là lựa chọn đúng cho cả ba: | Yếu tố | XGBoost | |---|---| | Dữ liệu giao dịch có cấu trúc | mạnh nhất với dữ liệu bảng | | Cần độ chính xác cao | gradient boosting là tiêu chuẩn cho phát hiện gian lận | | Dữ liệu mất cân bằng nặng | scale_pos_weight + chọn metric đúng |

Vế "custom objective function to optimize for precision and recall" là điểm quyết định. Với dữ liệu chỉ có dưới 1% là gian lận, tối ưu theo accuracy là vô nghĩa — model đoán "không gian lận" cho tất cả vẫn đạt 99%.

xgb.set_hyperparameters(
    objective='binary:logistic',
    scale_pos_weight=99,          # ≈ số mẫu âm / số mẫu dương
    eval_metric='aucpr',          # PR-AUC, KHÔNG phải accuracy hay ROC-AUC
    max_depth=6, eta=0.1, subsample=0.8)

Hai tham số quan trọng nhất: | Tham số | Việc | |---|---| | scale_pos_weight | tăng trọng số lớp thiểu số — model không bỏ qua gian lận | | eval_metric='aucpr' | PR-AUC phù hợp hơn ROC-AUC khi lớp dương rất hiếm |

Dòng thứ hai đáng nhớ riêng: ROC-AUC trông rất đẹp với dữ liệu mất cân bằng vì nó bị chi phối bởi lớp đa số. PR-AUC tập trung vào chính lớp bạn quan tâm.

Và XGBoost còn có hai ưu điểm thực dụng cho phát hiện gian lận: xử lý được giá trị thiếu tự nhiên (giao dịch thường thiếu trường), và cho feature importance — điều mà đội điều tra gian lận cần để hiểu vì sao một giao dịch bị gắn cờ.

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

  • B. Linear Learner với weighted classification để xử lý mất cân bằng — đây là phương án gần nhất và giải quyết được vế mất cân bằng, nhưng nó thua ở vế độ chính xác: model tuyến tính không nắm được tương tác phi tuyến giữa các đặc trưng. Mẫu gian lận thường là tổ hợp ("số tiền lớn và địa điểm lạ và ngoài giờ thường lệ") — đúng thứ cây quyết định giỏi và model tuyến tính không diễn đạt được.
  • A. Random Cut Forest (RCF) để phát hiện bất thường trong dữ liệu giao dịch — không giám sát, nên nó bỏ qua nhãn mà đề nói là có sẵn. RCF hữu ích khi không có nhãn hoặc khi muốn bắt kiểu gian lận chưa từng thấy; với dữ liệu đã gán nhãn thì học có giám sát cho kết quả tốt hơn nhiều.
  • D. K-Nearest Neighbors (k-NN) phân loại giao dịch theo độ tương đồng với ca gian lận đã biết — hai vấn đề: k-NN rất chậm lúc suy luận (phải so với toàn bộ tập huấn luyện) nên không hợp yêu cầu thời gian thực, và nó hoạt động kém với dữ liệu mất cân bằng vì láng giềng gần nhất hầu như luôn thuộc lớp đa số.

Ghi nhớ

Ba cách xử lý mất cân bằng lớp — nên kết hợp: | Cách | Chi tiết | |---|---| | Trọng số lớp | scale_pos_weight trong XGBoost | | Lấy mẫu lại | SMOTE, oversampling — làm trên tập huấn luyện, KHÔNG làm trên tập kiểm chứng | | Chọn metric đúng | PR-AUC, F1, recall — không phải accuracy |

Dòng giữa có một bẫy quan trọng: chỉ cân bằng tập huấn luyện, giữ nguyên tập kiểm chứng và kiểm thử. Cân bằng cả tập đánh giá sẽ cho điểm số đẹp không phản ánh thực tế production.

Bốn chỉ số và khi nào dùng: | Chỉ số | Ý nghĩa | Dùng khi | |---|---|---| | Precision | trong số bị gắn cờ, bao nhiêu đúng | báo nhầm tốn kém (làm phiền khách) | | Recall | trong số gian lận thật, bắt được bao nhiêu | bỏ sót tốn kém (mất tiền) | | F1 | trung bình điều hoà của hai cái trên | cân bằng | | PR-AUC | hiệu năng qua mọi ngưỡng | so sánh model với dữ liệu mất cân bằng |

Với phát hiện gian lận, đánh đổi precision–recall là quyết định NGHIỆP VỤ, không phải kỹ thuật: chặn nhầm một giao dịch thật làm khách hàng khó chịu; bỏ sót một giao dịch gian lận mất tiền thật. Ngưỡng nên do bộ phận rủi ro quyết định, và model nên trả về xác suất để ngưỡng điều chỉnh được mà không phải huấn luyện lại.

Ba đặc trưng quan trọng cho model phát hiện gian lận: | Nhóm | Ví dụ | |---|---| | Đặc trưng tổng hợp theo thời gian | số giao dịch trong 1 giờ, tổng tiền trong 24 giờ | | Độ lệch so với hành vi thường | số tiền so với trung bình của chính tài khoản đó | | Đặc trưng địa lý | khoảng cách so với giao dịch trước, tốc độ di chuyển ngụ ý |

Nhóm thứ hai thường mạnh nhất: gian lận không phải là "giao dịch lớn", mà là "giao dịch bất thường đối với người này".

Và một dịch vụ đáng nhắc: Amazon Fraud Detector được xây riêng cho bài toán này, có sẵn đặc trưng và model chuyên biệt. Nó không nằm trong bốn phương án, nhưng trong thực tế đáng cân nhắc trước khi tự xây.

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

An e-commerce company’s ML engineer is tasked with building a machine learning model to predict customer purchase behavior. To ensure consistency and reusability of features, the engineer decides to use Amazon SageMaker Feature Store to create, manage, and store features for training and inference. Given this context, consider the following steps:

  1. Prepare training dataset by accessing the feature data from the store

  2. Load the feature data into the store.

  3. Set up a feature group to organize and store features.

What should be the correct order of steps to create and use the features in Amazon SageMaker Feature Store?

  1. A

    3,1,2
  2. B

    3,2,1
  3. C

    1,2,3
  4. D

    2,3,1
Xem giải thích

Đáp án

B — Thứ tự 3, 2, 1:

  1. Tạo feature group để tổ chức và lưu đặc trưng
  2. Nạp dữ liệu đặc trưng vào store
  3. Chuẩn bị tập huấn luyện bằng cách truy cập dữ liệu từ store

Vì sao đúng

Thứ tự này là thứ tự bắt buộc về mặt kỹ thuật, không phải quy ước:

③ Tạo feature group   → định nghĩa SCHEMA: tên, kiểu, khoá định danh, cột thời gian
        ↓ (phải có chỗ chứa trước)
② Nạp dữ liệu         → ghi bản ghi vào store
        ↓ (phải có dữ liệu trước)
① Đọc ra để huấn luyện → truy vấn offline store dựng tập huấn luyện

Mỗi bước không thể làm trước bước trước nó: không nạp được vào một feature group chưa tồn tại, và không đọc được dữ liệu chưa nạp.

Bước ③ — tạo feature group khai báo cấu trúc:

feature_group = FeatureGroup(name='dac-trung-khach-hang', sagemaker_session=session)
feature_group.create(
    s3_uri='s3://kho/feature-store/',
    record_identifier_name='ma_khach_hang',      # khoá định danh
    event_time_feature_name='thoi_diem',          # cột thời gian — BẮT BUỘC
    role_arn=role,
    enable_online_store=True)                     # bật cả online lẫn offline

Bước ② — nạp dữ liệu:

feature_group.ingest(data_frame=df_dac_trung, max_workers=4, wait=True)

Bước ① — đọc ra dựng tập huấn luyện:

query = feature_group.athena_query()
query.run(f'SELECT * FROM "{query.table_name}" WHERE thoi_diem <= ...',
          output_location='s3://kho/tap-huan-luyen/')

Vì sao các thứ tự khác sai

  • A. 3, 1, 2 — tạo feature group rồi đọc ra trước khi nạp: store rỗng, không có gì để đọc.
  • C. 1, 2, 3 — đọc trước khi có store: không có feature group nào để truy cập.
  • D. 2, 3, 1 — nạp trước khi tạo feature group: không có đích để ghi vào.

Ghi nhớ

SageMaker Feature Store giải quyết ba vấn đề kinh điển của ML: | Vấn đề | Cách giải quyết | |---|---| | Trùng lặp công sức | nhiều đội dùng chung một định nghĩa đặc trưng | | Training–serving skew | cùng một đặc trưng cho huấn luyện và suy luận | | Rò rỉ dữ liệu tương lai | time travel — lấy giá trị tại đúng thời điểm |

Vấn đề thứ hai là lý do quan trọng nhất để dùng Feature Store: nếu đặc trưng lúc huấn luyện tính bằng một script và lúc suy luận tính bằng một script khác, hai bên sẽ lệch nhau — và model hoạt động kém trên production mà không ai hiểu vì sao.

Hai loại store: | Loại | Đặc điểm | Dùng cho | |---|---|---| | Online store | độ trễ mili giây, chỉ bản ghi MỚI NHẤT | suy luận thời gian thực | | Offline store | S3, chứa TOÀN BỘ lịch sử | huấn luyện, phân tích |

Ba trường bắt buộc khi tạo feature group: | Trường | Việc | |---|---| | record_identifier_name | khoá định danh — như khoá chính | | event_time_feature_name | thời điểm giá trị có hiệu lực | | Feature definitions | tên và kiểu của từng đặc trưng |

Trường thứ hai là nền tảng của time travel — khả năng hỏi "giá trị đặc trưng này là gì tại thời điểm giao dịch xảy ra". Không có nó, tập huấn luyện sẽ chứa thông tin từ tương lai, và model đạt điểm rất cao lúc kiểm chứng rồi thất bại trên production.

Và một lưu ý về chi phí: online store tính tiền theo dung lượng và số lời gọi, offline store chỉ là S3. Nếu chỉ dùng cho huấn luyện thì tắt online store để tiết kiệm.

Câu 16 Chọn nhiều đáp án ML Model Development

Which benefits might persuade a developer to choose a transparent and explainable machine learning model? (Select two)

  1. A

    They foster trust and confidence in model predictions
  2. B

    They facilitate easier debugging and optimization
  3. C

    They enhance security by concealing model logic
  4. D

    They require less computational power and storage
  5. E

    They simplify the integration process with other systems
Xem giải thích

Đáp án

A và B.

  • A — Chúng tạo dựng niềm tin và sự tin cậy vào dự đoán của model
  • B — Chúng giúp gỡ lỗi và tối ưu dễ dàng hơn

Vì sao đúng

Model minh bạch và giải thích được cho hai lợi ích cốt lõi, hướng tới hai nhóm người khác nhau: | Lợi ích | Dành cho ai | |---|---| | A — Niềm tin | người dùng, khách hàng, cơ quan quản lý | | B — Gỡ lỗi | nhà phát triển |

A — vì sao minh bạch tạo niềm tin: khi model từ chối một khoản vay hoặc gắn cờ một giao dịch, người bị ảnh hưởng có quyền biết vì sao. Và nhiều ngành có yêu cầu pháp lý về điều này — quyền được giải thích trong quyết định tự động là một nguyên tắc trong nhiều bộ luật bảo vệ dữ liệu.

Không có giải thích, người dùng chỉ có hai lựa chọn: tin mù quáng hoặc không dùng.

B — vì sao minh bạch giúp gỡ lỗi: đây là lợi ích thực dụng mà nhà phát triển cảm nhận hàng ngày.

Model hộp đen sai:      "model dự đoán sai" — không biết bắt đầu từ đâu

Model giải thích được:  "đặc trưng 'mã bưu chính' đang chi phối 60% quyết định"
                        → phát hiện model đang học một đặc trưng thay thế
                          cho thứ không nên dùng

Đây là cách phát hiện rò rỉ dữ liệu (data leakage), đặc trưng thay thế cho thuộc tính nhạy cảm, và học tắt — những lỗi mà chỉ nhìn vào điểm số thì không bao giờ thấy.

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

  • C. Chúng tăng cường bảo mật bằng cách CHE GIẤU logic của model — mâu thuẫn trực tiếp: minh bạch nghĩa là phơi bày logic, không phải che giấu. (Và "bảo mật nhờ che giấu" vốn không phải nguyên tắc bảo mật tốt.)
  • D. Chúng cần ít năng lực tính toán và bộ nhớ hơn — đúng một cách tình cờ nhưng không phải là lý do: model đơn giản (hồi quy tuyến tính, cây quyết định nông) thường vừa nhẹ vừa dễ giải thích, nhưng giải thích được không kéo theo nhẹ. Một model phức tạp vẫn giải thích được bằng SHAP hoặc LIME, và những kỹ thuật đó tốn thêm tính toán chứ không tiết kiệm.
  • E. Chúng đơn giản hoá việc tích hợp với hệ thống khác — không liên quan: tích hợp phụ thuộc vào API, định dạng dữ liệu và giao thức, không phụ thuộc vào việc model có giải thích được hay không.

Ghi nhớ

Hai khái niệm hay bị dùng lẫn: | Khái niệm | Nghĩa | |---|---| | Interpretability (diễn giải được) | bản thân model đơn giản đủ để hiểu — hồi quy tuyến tính, cây nông | | Explainability (giải thích được) | model có thể phức tạp, nhưng có công cụ giải thích từng dự đoán |

Ba kỹ thuật giải thích model phức tạp: | Kỹ thuật | Cách làm | |---|---| | SHAP | phân bổ đóng góp của từng đặc trưng vào từng dự đoán | | LIME | xấp xỉ cục bộ bằng model đơn giản quanh một điểm | | Feature importance | mức quan trọng tổng thể — thô hơn nhưng rẻ |

SageMaker Clarify cung cấp SHAP dựng sẵn, cho cả giải thích toàn cục (đặc trưng nào quan trọng nói chung) và cục bộ (vì sao dự đoán NÀY như vậy).

Ba lý do nghiệp vụ để đòi hỏi giải thích được: | Lý do | Chi tiết | |---|---| | Yêu cầu pháp lý | quyết định tín dụng, tuyển dụng, bảo hiểm ở nhiều nước | | Phát hiện thiên lệch | thấy được model đang dựa vào đặc trưng thay thế cho thuộc tính nhạy cảm | | Chấp nhận của người dùng | bác sĩ, thẩm định viên không dùng công cụ họ không hiểu |

Dòng giữa là ứng dụng quan trọng nhất trong thực tế: model không được đưa chủng tộc hay giới tính vào, nhưng nó có thể học mã bưu chính như một đại diện — và chỉ có giải thích được mới phát hiện ra.

Và một đánh đổi cần biết: model đơn giản dễ hiểu hơn nhưng thường kém chính xác hơn. Nên lựa chọn thực tế thường là model mạnh + công cụ giải thích, chứ không phải hy sinh độ chính xác. Ngoại lệ là những lĩnh vực mà quy định đòi hỏi model bản thân phải đơn giản.

Câu 17 Chọn nhiều đáp án ML Model Development

You are working on a machine learning project for a financial services company, developing a model to predict credit risk. After deploying the initial version of the model using Amazon SageMaker, you find that its performance, measured by the AUC (Area Under the Curve), is not meeting the company’s accuracy requirements. Your team has gathered more data and believes that the model can be further optimized.

You are considering various methods to improve the model’s performance, including feature engineering, hyperparameter tuning, and trying different algorithms. However, given the limited time and computational resources, you need to prioritize the most impactful strategies.

Which of the following approaches are the MOST LIKELY to lead to a significant improvement in model performance? (Select two)

  1. A

    Perform hyperparameter tuning using Bayesian optimization and increase the number of trials to explore a broader search space
  2. B

    Increase the size of the training dataset by incorporating synthetic data and then retrain the existing model
  3. C

    Switch to a more complex algorithm, such as deep learning, and use transfer learning to leverage pre-trained models
  4. D

    Use Amazon SageMaker Debugger to debug and improve model performance by addressing underlying problems such as overfitting, saturated activation functions, and vanishing gradients
  5. E

    Focus on feature engineering by creating domain-specific features and use SageMaker Clarify to evaluate feature importance
Xem giải thích

Đáp án

D và E.

  • E — Tập trung vào feature engineering — tạo đặc trưng theo lĩnh vực và dùng SageMaker Clarify đánh giá mức quan trọng của đặc trưng
  • D — Dùng SageMaker Debugger để gỡ lỗi và cải thiện hiệu năng bằng cách xử lý các vấn đề nền tảng như overfitting, hàm kích hoạt bão hoà, gradient tiêu biến

Vì sao đúng

Đề đặt ra một bài toán ưu tiên: thời gian và tài nguyên hạn chế, nên phải chọn chiến lược có tác động lớn nhất.

Và hai đáp án đại diện cho hai nguyên tắc quan trọng:

E — feature engineering thường có tác động lớn nhất. Đây là kinh nghiệm được lặp lại trong hầu hết dự án ML thực tế:

Thêm một đặc trưng nghiệp vụ tốt  → AUC tăng 0,05
Tinh chỉnh siêu tham số kỹ lưỡng   → AUC tăng 0,01

Với rủi ro tín dụng, những đặc trưng theo lĩnh vực thường mạnh nhất: | Đặc trưng | Ý nghĩa | |---|---| | Tỷ lệ nợ trên thu nhập | không suy ra được từ hai cột riêng lẻ nếu model tuyến tính | | Xu hướng số dư 6 tháng | hướng thay đổi, không phải giá trị hiện tại | | Tần suất thanh toán trễ gần đây | trọng số theo thời gian |

Và Clarify đánh giá mức quan trọng khép kín vòng lặp: bạn biết đặc trưng mới có đóng góp thật hay chỉ thêm nhiễu.

D — chẩn đoán trước khi tối ưu. Đây là nguyên tắc thứ hai và cũng quan trọng không kém:

Nếu model đang overfitting hoặc gradient đang tiêu biến, tinh chỉnh siêu tham số sẽ không cứu được.

SageMaker Debugger bắt các vấn đề nền tảng:

rules=[Rule.sagemaker(rule_configs.overfit()),
       Rule.sagemaker(rule_configs.vanishing_gradient()),
       Rule.sagemaker(rule_configs.saturated_activation()),
       Rule.sagemaker(rule_configs.loss_not_decreasing())]

Nó phân biệt được "model chưa đủ tốt" với "quá trình huấn luyện đang hỏng" — hai chuyện cần cách chữa hoàn toàn khác nhau.

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

  • A. Tinh chỉnh siêu tham số bằng Bayesian optimization và tăng số lần thử để khám phá không gian rộng hơn — đây là phương án gần nhất và hữu ích thật, nhưng nó tốn nhiều tài nguyên tính toán nhất trong khi cho mức cải thiện nhỏ nhất so với hai đáp án kia. Với ràng buộc "limited time and computational resources", đây là lựa chọn kém ưu tiên. (Nên làm — nhưng làm sau, khi đặc trưng đã tốt và quá trình huấn luyện đã lành mạnh.)
  • C. Chuyển sang thuật toán phức tạp hơn như deep learning và dùng transfer learning tận dụng model đã huấn luyện sẵn — hai vấn đề: deep learning thường không thắng gradient boosting trên dữ liệu bảng, và transfer learning gần như không áp dụng được cho dữ liệu tài chính có cấu trúc (không có model tiền huấn luyện nào cho "bảng số liệu tín dụng" như cách có cho ảnh hay văn bản).
  • B. Tăng kích thước tập huấn luyện bằng dữ liệu tổng hợp rồi huấn luyện lại — rủi ro cao: dữ liệu tổng hợp chỉ tái tạo các mẫu đã có trong dữ liệu gốc, nên nó không thêm thông tin mới. Với rủi ro tín dụng, nó còn có thể khuếch đại thiên lệch sẵn có — một vấn đề nghiêm trọng trong lĩnh vực chịu quản lý.

Ghi nhớ

Thứ tự ưu tiên khi cải thiện hiệu năng model — theo tỷ lệ tác động trên công sức: | Ưu tiên | Việc | Tác động | |---|---|---| | 1 | Kiểm tra quá trình huấn luyện có lành mạnh không | cao — sửa lỗi nền tảng | | 2 | Feature engineering | cao nhất thường thấy | | 3 | Thêm dữ liệu THẬT | cao nếu có sẵn | | 4 | Đổi thuật toán | vừa | | 5 | Tinh chỉnh siêu tham số | thấp nhất — nhưng dễ làm nhất |

Nghịch lý thường gặp: mục 5 dễ tự động hoá nhất nên hay được làm đầu tiên, trong khi mục 1 và 2 cho lợi ích lớn hơn nhiều.

Ba vấn đề nền tảng mà Debugger bắt được: | Vấn đề | Triệu chứng | |---|---| | Overfitting | loss huấn luyện giảm, loss kiểm chứng tăng | | Vanishing gradient | gradient tiến về 0 ở các tầng đầu — model ngừng học | | Saturated activation | kích hoạt kẹt ở biên (0 hoặc 1) — gradient không truyền được |

Ba loại đặc trưng đáng tạo cho rủi ro tín dụng: | Loại | Ví dụ | |---|---| | Tỷ số | nợ/thu nhập, dư nợ/hạn mức | | Xu hướng theo thời gian | thay đổi số dư 3 tháng, 6 tháng | | Tổng hợp có trọng số thời gian | số lần trễ hạn, gần đây tính nặng hơn |

Loại thứ nhất đáng chú ý: model tuyến tính không tự tạo được tỷ số từ hai cột — bạn phải tạo. Model cây có thể xấp xỉ nhưng kém hiệu quả. Đây là ví dụ điển hình cho việc kiến thức lĩnh vực vượt qua sức mạnh thuật toán.

Và một điều nên làm cùng với E: kiểm tra rò rỉ dữ liệu khi thêm đặc trưng mới. Một đặc trưng làm AUC nhảy vọt bất thường thường là dấu hiệu nó chứa thông tin từ tương lai — Clarify và Data Wrangler đều có kiểm tra target leakage cho việc này.

Câu 18 Deployment and Orchestration of ML Workflows

You are a data scientist at a retail company responsible for deploying a machine learning model that predicts customer purchase behavior. The model needs to serve real-time predictions with low latency to support the company’s recommendation engine on its e-commerce platform. The deployment solution must also be scalable to handle varying traffic loads during peak shopping periods, such as Black Friday and holiday sales. Additionally, you need to monitor the model's performance and automatically roll out updates when a new version of the model is available.

Given these requirements, which AWS deployment service and configuration is the MOST SUITABLE for deploying the machine learning model?

  1. A

    Deploy the model using Amazon SageMaker real-time hosting services with an auto-scaling endpoint, enabling you to automatically adjust the number of instances based on traffic demand
  2. B

    Use AWS Lambda to deploy the model as a serverless function, automatically scaling based on the number of requests, and store the model artifacts in Amazon S3
  3. C

    Deploy the model on Amazon EC2 instances with a load balancer to distribute traffic, manually scaling the instances based on expected traffic during peak periods
  4. D

    Deploy the model on Amazon SageMaker with batch transform jobs, running the jobs periodically to generate predictions and storing the results in Amazon S3 for the recommendation engine
Xem giải thích

Đáp án

A — Triển khai bằng SageMaker real-time hosting với auto-scaling endpoint, cho phép tự động điều chỉnh số instance theo nhu cầu lưu lượng.

Vì sao đúng

Đề nêu bốn yêu cầu, và SageMaker real-time endpoint đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Dự đoán thời gian thực, độ trễ thấp | endpoint thường trực, model đã nạp sẵn | | Co giãn theo tải mùa vụ | auto-scaling | | Giám sát hiệu năng | CloudWatch metric tự động + Model Monitor | | Tự động phát hành phiên bản mới | blue/green deployment dựng sẵn |

Vế thứ tư đáng nói riêng vì nó là thứ SageMaker cho sẵn mà các phương án khác phải tự dựng:

sm.update_endpoint(
    EndpointName='goi-y-mua-hang',
    EndpointConfigName='cau-hinh-moi',
    DeploymentConfig={
        'BlueGreenUpdatePolicy': {
            'TrafficRoutingConfiguration': {
                'Type': 'CANARY',
                'CanarySize': {'Type': 'CAPACITY_PERCENT', 'Value': 10}},
            'TerminationWaitInSeconds': 600},
        'AutoRollbackConfiguration': {
            'Alarms': [{'AlarmName': 'canh-bao-do-tre-cao'}]}})

Hai dòng cuối là điểm mạnh: 10% lưu lượng sang bản mới trước, và tự rollback nếu alarm kêu.

Và auto-scaling theo SageMakerVariantInvocationsPerInstance xử lý vế Black Friday: số instance tăng theo lượng việc thật, rồi giảm lại khi qua đợt.

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

  • B. Triển khai bằng AWS Lambda làm hàm serverless, tự co giãn theo số request, lưu artifact model trên S3 — đây là phương án đáng bàn vì Lambda co giãn rất tốt, nhưng nó có ba giới hạn thật: kích thước gói (250 MB giải nén, 10 GB với container), không có GPU, và cold start khi phải nạp model từ S3. Với model gợi ý phục vụ đỉnh tải Black Friday, cold start ở đúng lúc cao điểm là vấn đề. (Lambda hợp với model rất nhỏ và tải thưa — xem thêm #6471.)
  • C. Triển khai trên EC2 với load balancer, scaling THỦ CÔNG theo lưu lượng dự kiến trong đợt cao điểm — scaling thủ công trái yêu cầu "scalable to handle varying traffic loads", và quản lý EC2 (AMI, vá lỗi, cấu hình) là gánh nặng không cần thiết.
  • D. Triển khai bằng batch transform chạy định kỳ sinh dự đoán và lưu S3 cho engine gợi ý dùng — không phải thời gian thực: dự đoán tính sẵn theo lô không phản ánh hành vi người dùng trong phiên hiện tại. Với gợi ý mua sắm, phần lớn giá trị nằm ở việc phản ứng với thứ khách vừa xem.

Ghi nhớ

Bốn kiểu triển khai của SageMaker — bảng này lặp lại nhiều lần trong đề thi: | Kiểu | Độ trễ | Co về 0 | Dùng khi | |---|---|---|---| | Real-time | mili giây | ❌ | người dùng đang chờ ← câu này | | Serverless | có cold start | ✅ | tải thưa, không có GPU | | Asynchronous | phút tới giờ | ✅ | payload lớn, xử lý lâu | | Batch transform | theo job | ✅ | không cần endpoint, xử lý cả tệp |

Ba cấu hình cần đặt cho endpoint production: | Cấu hình | Việc | |---|---| | Auto-scaling với MinCapacity ≥ 2 | chịu tải và chịu được mất một AZ | | Data capture | lưu request và response — cần cho Model Monitor | | Blue/green với auto rollback | phát hành an toàn |

Dòng giữa hay bị quên và hậu quả im lặng: không bật data capture thì Model Monitor không có gì để phân tích, và bạn chỉ phát hiện ra khi cần nó nhất.

Ba chiến lược phát hành của SageMaker: | Chiến lược | Cách làm | |---|---| | All-at-once | chuyển 100% ngay — chỉ dùng cho dev | | Canary | một phần nhỏ trước, theo dõi, rồi phần còn lại | | Linear | tăng đều theo bậc |

Và production variant là công cụ bổ sung đáng biết: nó cho phép hai model chạy song song trên cùng endpoint với tỷ lệ lưu lượng khai được — hữu ích cho A/B test model, khác với blue/green vốn nhắm vào việc thay thế.

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

A financial services company is building a customer churn prediction model on AWS. The dataset includes call logs, customer interaction history, and transactional data from an on-premises PostgreSQL database. The call logs and interaction history are stored in Amazon S3, while the PostgreSQL tables remain on-premises. The data science team needs to aggregate and preprocess data from these various sources to ensure it is ready for machine learning model training. They must also resolve challenges such as feature inconsistencies and ensure schema alignment across the data sources.

Which AWS service or feature can efficiently connect and aggregate the data from these sources?

  1. A

    Use Amazon EMR Spark jobs to preprocess and aggregate the data directly from S3 and on-premises sources for ML model training
  2. B

    Use AWS Database Migration Service (DMS) to transfer and preprocess data for ML training
  3. C

    Use Amazon SageMaker Data Wrangler to connect, aggregate, and preprocess the data
  4. D

    Use AWS Lake Formation to aggregate and centrally manage the data from S3 and on-premises PostgreSQL for seamless access and integration
Xem giải thích

Đáp án

D — Dùng AWS Lake Formation để gộp và quản lý tập trung dữ liệu từ S3 và PostgreSQL tại chỗ, cho phép truy cập và tích hợp liền mạch.

Vì sao đúng

Đề nêu bốn yêu cầu: | Yêu cầu | Lake Formation | |---|---| | Nối và gộp dữ liệu từ nhiều nguồn | Glue connection tới JDBC + S3, blueprint nạp dữ liệu | | Quản lý tập trung | một Data Catalog cho mọi nguồn | | Giải quyết schema không khớp | catalog chuẩn hoá schema, Glue transform | | Truy cập liền mạch cho các bước sau | mọi engine đọc qua catalog |

Lake Formation dựng một lớp catalog thống nhất phía trên các nguồn khác nhau:

S3 (call log, lịch sử tương tác)  ─┐
                                    ├─→ Glue Data Catalog ─→ Athena, SageMaker,
PostgreSQL tại chỗ (giao dịch)  ───┘   (schema chuẩn hoá)     EMR, QuickSight
     qua Glue JDBC connection

Sau khi nạp, dữ liệu từ hai nguồn xuất hiện như các bảng trong cùng một catalog — nên bước chuẩn bị dữ liệu cho ML chỉ là truy vấn, không phải công việc tích hợp.

Và quản lý quyền tập trung là lợi ích đi kèm quan trọng với dữ liệu tài chính: cấp quyền một lần ở Lake Formation, mọi engine tuân theo.

Ghi nhớ về sự khác biệt với #6450

Đây là điểm cần nói thẳng: câu này và #6450 trong cùng lô mô tả hai tình huống rất giống nhau nhưng có đáp án khác nhau.

#6450 #6460 (câu này)
Nguồn S3 + SQL tại chỗ S3 + PostgreSQL tại chỗ
Yêu cầu gộp, phát hiện bất thường, trực quan hoá nối, gộp, chuẩn bị cho ML
Đáp án nguồn Data Wrangler Lake Formation

Phương án C của câu này là Data Wrangler, và nó cũng làm được mọi thứ đề yêu cầu: Data Wrangler có connector JDBC, join được nhiều nguồn, và có transform xử lý schema không khớp — đó chính là công việc nó được thiết kế để làm.

Cách đọc đề để phân biệt hai đáp án: | Trọng tâm | Công cụ | |---|---| | "chuẩn bị dữ liệu cho MỘT model, ít mã" | Data Wrangler | | "quản lý TẬP TRUNG, nhiều đội dùng chung, có quản trị" | Lake Formation |

Đề này nhấn mạnh "aggregate and centrally manage" và "seamless access and integration" — nghiêng về quản trị dữ liệu ở tầng nền tảng hơn là chuẩn bị dữ liệu cho một thí nghiệm.

Trong thực tế, hai công cụ này bổ sung nhau chứ không loại trừ: Lake Formation dựng nền catalog và quyền, Data Wrangler đọc từ đó để chuẩn bị đặc trưng. Nếu gặp câu hỏi kiểu này trong đề thi, đọc kỹ xem trọng tâm là quản trị nền tảng hay chuẩn bị dữ liệu cho một model cụ thể.

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

  • C. SageMaker Data Wrangler để nối, gộp và tiền xử lý — như đã bàn ở trên, đây là phương án rất mạnh và trong nhiều bối cảnh sẽ là câu trả lời đúng. Nó thua ở vế quản lý tập trung: Data Wrangler là công cụ của một luồng chuẩn bị dữ liệu, không phải lớp quản trị dùng chung cho tổ chức.
  • A. EMR Spark job tiền xử lý và gộp trực tiếp từ S3 và nguồn tại chỗ — tốn công nhất: quản lý cụm, viết mã Spark, tự lo kết nối tới cơ sở dữ liệu tại chỗ. Và không có lớp catalog nào cho các bước sau dùng lại.
  • B. AWS DMS chuyển và tiền xử lý dữ liệu cho huấn luyện ML — DMS di trú và đồng bộ dữ liệu, nó KHÔNG tiền xử lý: không join, không tạo đặc trưng, không xử lý schema không khớp. DMS là một phần của giải pháp (đưa dữ liệu PostgreSQL lên AWS), không phải toàn bộ.

Ghi nhớ

Bốn dịch vụ tích hợp dữ liệu — nhớ đúng vai: | Dịch vụ | Việc | |---|---| | Lake Formation | catalog + quyền tập trung cho data lake | | Glue | ETL: crawl, biến đổi, nạp | | DMS | di trú và CDC từ cơ sở dữ liệu | | Data Wrangler | chuẩn bị đặc trưng cho ML, ít mã |

Kiến trúc thường gặp dùng cả bốn:

PostgreSQL tại chỗ ─DMS→ S3 ─Glue crawler→ Data Catalog
                                                ↓ (Lake Formation quản quyền)
                                          Data Wrangler → Feature Store → SageMaker

Ba khả năng của Lake Formation: | Khả năng | Chi tiết | |---|---| | Blueprint | mẫu nạp dữ liệu từ nguồn JDBC hoặc log | | Data Catalog thống nhất | mọi nguồn xuất hiện như bảng | | Quyền chi tiết | bảng, cột, dòng, ô — xem #6387 |

Và một lưu ý về kết nối tới cơ sở dữ liệu tại chỗ: Glue cần Glue connection trong VPC có đường tới hệ thống tại chỗ (qua Direct Connect hoặc VPN). Đây là bước hạ tầng phải chuẩn bị trước, và cả Lake Formation lẫn Data Wrangler đều phụ thuộc vào nó.

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

A healthcare organization manages a large dataset containing patient records stored in Amazon S3. The dataset includes information such as patient names, addresses, and phone numbers, but it contains duplicate records due to inconsistencies in data entry. Some duplicates are exact matches, while others have slight variations (e.g., spelling errors in names or incomplete addresses). The organization needs to identify and group duplicate records efficiently while ensuring minimal code development to streamline the deduplication process.

Which solution on AWS will detect duplicates in the dataset with the LEAST operational overhead?

  1. A

    Use AWS Glue FindMatches to automatically detect and group duplicate records in the dataset
  2. B

    Use AWS Glue ETL to create a custom job for processing and filtering duplicate records.
  3. C

    Use SageMaker Data Wrangler to detect and group duplicate records in the dataset by leveraging its data preparation and transformation features
  4. D

    Use Amazon EMR with Apache Spark to write a custom deduplication script using SparkSQL
Xem giải thích

Đáp án

A — Dùng AWS Glue FindMatches để tự động phát hiện và nhóm các bản ghi trùng lặp trong tập dữ liệu.

Vì sao đúng

Đề nêu hai loại trùng lặp, và đây là chỗ quyết định: | Loại | Ví dụ | |---|---| | Trùng khớp chính xác | hai dòng giống hệt | | Trùng gần đúng | "Nguyễn Văn A" và "Nguyen Van A"; địa chỉ thiếu số nhà |

Loại thứ hai là thứ SQL và quy tắc không giải quyết được. Không có biểu thức nào bắt được mọi biến thể lỗi chính tả, viết tắt và thiếu thông tin.

FindMatches là transform học máy dựng sẵn của Glue cho đúng bài toán này:

1. Glue sinh ra một tập ví dụ để bạn gán nhãn
   "Hai bản ghi này có phải cùng một người không?" → Có / Không
2. Bạn gán nhãn vài trăm cặp (giao diện có sẵn)
3. Glue huấn luyện model so khớp
4. Chạy trên toàn bộ tập dữ liệu → nhóm các bản ghi cùng thực thể

Và "LEAST operational overhead" là tiêu chí quyết định: bạn không viết thuật toán so khớp mờ nào — không Levenshtein, không Soundex, không ngưỡng tương đồng phải hiệu chỉnh. Chỉ gán nhãn ví dụ, phần còn lại là transform có sẵn.

glueContext.create_dynamic_frame.from_catalog(...)
# rồi áp FindMatches transform đã huấn luyện

Với dữ liệu bệnh nhân, chất lượng so khớp rất quan trọng: gộp nhầm hai người khác nhau nguy hiểm hơn nhiều so với bỏ sót một bản trùng — và FindMatches cho phép điều chỉnh đánh đổi precision–recall khi huấn luyện.

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

  • C. Dùng SageMaker Data Wrangler phát hiện và nhóm bản ghi trùng bằng các tính năng chuẩn bị và biến đổi dữ liệu — đây là phương án gần nhất và Data Wrangler có transform "drop duplicates", nhưng nó chỉ xử lý trùng khớp CHÍNH XÁC. Nó không giải quyết được vế "slight variations" mà đề nêu rõ là một nửa vấn đề.
  • B. Dùng Glue ETL viết job tuỳ chỉnh xử lý và lọc bản ghi trùng — tự viết logic so khớp mờ: đây chính là công sức mà FindMatches loại bỏ. Và một thuật toán tự viết sẽ cần hiệu chỉnh ngưỡng liên tục.
  • D. Dùng EMR với Spark viết script khử trùng lặp bằng SparkSQL — tốn công nhất: quản lý cụm cộng với tự viết thuật toán. Và SparkSQL cũng chỉ so khớp theo biểu thức, không học được từ ví dụ.

Ghi nhớ

Entity resolution (phân giải thực thể) — bài toán nhận ra nhiều bản ghi cùng chỉ một thực thể. Hai cách tiếp cận: | Cách | Đặc điểm | |---|---| | Dựa trên luật | so chuỗi, chuẩn hoá, ngưỡng — dễ hiểu nhưng giòn | | Dựa trên học máy | học từ ví dụ đã gán nhãn — bắt được biến thể không lường trước |

Ba dịch vụ AWS liên quan: | Dịch vụ | Việc | |---|---| | Glue FindMatches | khử trùng lặp và so khớp bằng ML, trong pipeline Glue | | AWS Entity Resolution | dịch vụ chuyên biệt — so khớp dựa trên luật hoặc ML, không cần Glue | | Data Wrangler "drop duplicates" | chỉ trùng chính xác |

Dòng giữa đáng biết: AWS Entity Resolution là dịch vụ ra sau, chuyên cho bài toán này và có sẵn cả quy tắc dựng sẵn cho dữ liệu khách hàng. Nó không nằm trong bốn phương án, nhưng trong thực tế đáng cân nhắc.

Ba yếu tố quyết định chất lượng khử trùng lặp: | Yếu tố | Chi tiết | |---|---| | Chất lượng dữ liệu gán nhãn | vài trăm cặp gán nhãn cẩn thận hơn vài nghìn cặp cẩu thả | | Chọn cột để so khớp | tên + ngày sinh + địa chỉ mạnh hơn chỉ tên | | Đánh đổi precision–recall | với dữ liệu y tế: ưu tiên precision |

Dòng cuối quan trọng với tình huống trong đề: gộp nhầm hồ sơ hai bệnh nhân khác nhau là sự cố an toàn nghiêm trọng, trong khi bỏ sót một bản trùng chỉ là dữ liệu thừa. FindMatches cho phép đặt tham số precisionRecallTradeoff nghiêng về precision cho đúng lý do này.

Và một bước nên làm trước khi khử trùng lặp: chuẩn hoá dữ liệu (viết hoa thống nhất, chuẩn hoá định dạng địa chỉ và số điện thoại). Nó không thay thế được so khớp mờ, nhưng làm cho model dễ học hơn nhiều.