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

Tìm thấy 195 câu.

Câu 71 Deployment and Orchestration of ML Workflows

A cloud architect is tasked with deploying a pre-trained AI model for a customer-facing application. The demand for the model's services fluctuates throughout the day, with occasional peaks in traffic and long periods of low activity. The architect needs to find a solution that scales automatically to handle high traffic while minimizing costs during idle periods.

Which solution will fulfill these requirements with minimal management overhead?

  1. A

    Deploy the model to an Amazon SageMaker endpoint using Provisioned Concurrency with Serverless Inference to cater to dynamically changing traffic patterns
  2. B

    Deploy the model by using Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. Use Amazon EventBridge to trigger auto scaling
  3. C

    Deploy the model to an Amazon SageMaker endpoint. Create SageMaker endpoint auto scaling policies based on Amazon CloudWatch metrics to adjust the number of instances dynamically
  4. D

    Deploy the model to a group of Amazon Elastic Container Service (Amazon ECS) managed EC2 instances and set up an Application Load Balancer (ALB) in front of the ECS fleet to distribute incoming traffic
Xem giải thích

Đáp án

C — Triển khai model lên SageMaker endpoint và tạo chính sách auto scaling dựa trên CloudWatch metric để điều chỉnh số instance động.

Vì sao đúng

Đề nêu ba yêu cầu: | Yêu cầu | Cơ chế | |---|---| | Co giãn tự động khi lưu lượng cao | auto scaling | | Giảm chi phí khi rảnh | giảm số instance xuống mức tối thiểu | | Ít công sức quản lý nhất | SageMaker endpoint là dịch vụ được quản lý |

Auto scaling cho SageMaker endpoint là cơ chế dựng sẵn, cấu hình bằng vài lời gọi API:

autoscaling.register_scalable_target(
    ServiceNamespace='sagemaker',
    ResourceId='endpoint/du-doan-ai/variant/AllTraffic',
    ScalableDimension='sagemaker:variant:DesiredInstanceCount',
    MinCapacity=1, MaxCapacity=10)

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

Điểm phân biệt với phương án A là một chi tiết kỹ thuật cụ thể:

Serverless Inference của SageMaker không có tính năng tên là "Provisioned Concurrency" theo cách phương án A mô tả. SageMaker Serverless Inference có tuỳ chọn provisioned concurrency để giữ sẵn phiên bản ấm, nhưng phương án A ghép nó theo cách lẫn lộn với endpoint thường.

(Cần nói thẳng: Serverless Inference là lựa chọn rất hợp lý cho mẫu lưu lượng mà đề mô tả — có đỉnh và có khoảng dài rảnh rỗi, xem #6495. Nếu phương án A viết đơn giản là "dùng Serverless Inference", nó sẽ cạnh tranh trực tiếp với C. Cách diễn đạt lẫn lộn của nó là điểm loại.)

Và đáp án C chắc chắn đúng trong mọi cách đọc: endpoint với auto scaling là giải pháp chuẩn, được quản lý, và đáp ứng cả ba yêu cầu.

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

  • A. Triển khai lên SageMaker endpoint dùng Provisioned Concurrency với Serverless Inference để phục vụ mẫu lưu lượng thay đổi động — như phân tích trên, phương án này ghép lẫn hai cấu hình khác nhau. Ngoài ra, provisioned concurrency nghĩa là trả tiền giữ sẵn — mâu thuẫn với mục tiêu "minimizing costs during idle periods".
  • **B. Triển khai bằng ECS trên Fargate, dùng EventBridge kích hoạt auto scaling — hai vấn đề: tốn công quản lý hơn (task definition, service, cluster), và EventBridge không phải cơ chế auto scaling — nó định tuyến sự kiện; auto scaling phải do Application Auto Scaling lo.
  • D. Triển khai lên nhóm EC2 do ECS quản lý với ALB phân phối lưu lượng — tốn công nhất: quản lý cả EC2 lẫn ECS lẫn ALB, và không có auto scaling được nêu. Trái thẳng "minimal management overhead".

Ghi nhớ

Bốn kiểu suy luận của SageMaker — và cách chọn theo mẫu lưu lượng: | Kiểu | Co về 0 | Cold start | Dùng khi | |---|---|---|---| | Real-time + auto scaling | ❌ (min ≥ 1) | không | lưu lượng đều với đỉnh ← câu này | | Serverless | ✅ | có | lưu lượng rất thưa, có khoảng dài không dùng | | Asynchronous | ✅ | có | payload lớn, xử lý lâu | | Batch transform | ✅ | — | xử lý cả tệp |

Ranh giới giữa hai lựa chọn đầu:

Nếu có lưu lượng gần như liên tục (dù thấp) → Real-time + auto scaling
Nếu có khoảng DÀI hoàn toàn không request  → Serverless

Điểm hoà vốn thường ở khoảng vài giờ sử dụng liên tục mỗi ngày.

Bốn loại chính sách auto scaling: | Loại | Cách làm | |---|---| | Target tracking | giữ metric ở mức mục tiêu — đơn giản và hiệu quả nhất | | Step scaling | bậc thang theo mức vượt ngưỡng | | Scheduled | theo lịch biết trước — dùng kèm target tracking | | Manual | môi trường dev |

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

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, kết hợp scheduled scaling cho những thời điểm đã biết trước — nâng MinCapacity từ trước thay vì để hệ thống phản ứng sau.

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

You are a data scientist at an insurance company that uses a machine learning model to assess the risk of potential clients and set insurance premiums accordingly. The model was trained on data from the past few years, but recently, the company has expanded its services to new regions with different demographic characteristics. You are concerned that these changes in the data distribution might affect the model's performance and lead to biased or inaccurate predictions. To address this, you decide to use Amazon SageMaker Clarify to monitor and detect any significant shifts in data distribution that could impact the model.

Which of the following actions is the MOST EFFECTIVE for detecting changes in data distribution using SageMaker Clarify and mitigating their impact on model performance?

  1. A

    Implement a random sampling process to manually review a subset of incoming data each month, comparing it with the original training data to check for distribution changes
  2. B

    Set up a continuous monitoring job with SageMaker Clarify to track changes in feature distribution over time and alert you when a significant feature attribution drift is detected, allowing you to investigate and potentially retrain the model
  3. C

    Use SageMaker Clarify to perform a one-time bias analysis during model training, ensuring that the model is initially fair and accurate, and manually monitor future data distribution changes
  4. D

    Use SageMaker Clarify’s bias detection capabilities to analyze the model’s output and identify any disparities between different demographic groups, retraining the model only if significant bias is detected
Xem giải thích

Đáp án

B — Thiết lập job giám sát liên tục với SageMaker Clarify theo dõi thay đổi phân bố đặc trưng theo thời gian và cảnh báo khi phát hiện feature attribution drift đáng kể, để điều tra và huấn luyện lại nếu cần.

Vì sao đúng

Đề mô tả một thay đổi cụ thể: công ty mở rộng sang khu vực mới với đặc điểm nhân khẩu khác, và lo ngại điều đó ảnh hưởng tới model.

Đó chính xác là data drift, và yêu cầu là phát hiện + giảm thiểu tác động.

Vì sao "continuous monitoring" là điểm quyết định:

Phân tích một lần:  chụp ảnh tại một thời điểm
                    → không thấy được xu hướng
                    → không biết khi nào tình hình xấu đi

Giám sát liên tục:  so phân bố hiện tại với baseline, ĐỀU ĐẶN
                    → phát hiện drift NGAY khi nó xảy ra
                    → cảnh báo tự động, không cần ai nhớ kiểm tra

Feature attribution drift — chỉ số mà đáp án nêu — đáng giải thích riêng vì nó tinh vi hơn data drift thông thường: | Chỉ số | Phát hiện | |---|---| | Data drift | phân bố giá trị đặc trưng thay đổi | | Feature attribution drift | MỨC ĐỘ ẢNH HƯỞNG của đặc trưng lên dự đoán thay đổi |

Chỉ số thứ hai là chỉ báo sớm mạnh: nếu model bắt đầu dựa nhiều hơn vào một đặc trưng nhân khẩu khi phục vụ khu vực mới, đó là dấu hiệu vấn đề — kể cả khi độ chính xác tổng thể chưa giảm.

model_bias_monitor = ModelBiasMonitor(role=role, ...)
model_bias_monitor.create_monitoring_schedule(
    endpoint_input=endpoint,
    ground_truth_input=s3_nhan_thuc_te,
    analysis_config=cau_hinh_bias,
    schedule_cron_expression=CronExpressionGenerator.daily())

Và vế "investigate and potentially retrain" đúng về mặt quy trình: cảnh báo kích hoạt điều tra, không tự động huấn luyện lại — vì với định giá bảo hiểm, cần hiểu nguyên nhân trước khi hành động.

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

  • D. Dùng khả năng phát hiện thiên lệch của Clarify phân tích đầu ra model và tìm chênh lệch giữa các nhóm nhân khẩu, chỉ huấn luyện lại nếu phát hiện thiên lệch đáng kể — đây là phương án gần nhất và hữu ích thật, nhưng nó đo sai thứ: đề hỏi về thay đổi PHÂN BỐ DỮ LIỆU, còn phương án này đo thiên lệch giữa các nhóm. Hai chuyện liên quan nhưng khác nhau: phân bố có thể dịch chuyển mà không sinh thiên lệch, và ngược lại.
  • C. Dùng Clarify phân tích thiên lệch MỘT LẦN lúc huấn luyện, rồi giám sát THỦ CÔNG thay đổi phân bố về sau — "one-time" và "manually" đều trái yêu cầu: một lần không phát hiện được thay đổi theo thời gian, và thủ công thì sẽ bị bỏ quên.
  • A. Lấy mẫu ngẫu nhiên và xem xét THỦ CÔNG một tập con dữ liệu mỗi tháng, so với dữ liệu huấn luyện gốc — hoàn toàn thủ công, chậm và không nhất quán: mỗi người xem sẽ đánh giá khác nhau, và "mỗi tháng" là quá thưa với việc mở rộng sang khu vực mới.

Ghi nhớ

Bốn loại giám sát của SageMaker — và cái nào cần nhãn thật: | Loại | Phát hiện | Cần nhãn? | |---|---|---| | Data quality | phân bố đầu vào đổi | ❌ | | Model quality | độ chính xác giảm | ✅ | | Bias drift | chênh lệch giữa các nhóm | ❌ | | Feature attribution drift | đặc trưng chi phối dự đoán đổi | ❌ |

Ba loại nằm ngoài dòng thứ hai đều không cần nhãn thật — điều này quan trọng với bảo hiểm, nơi kết quả thật (khách có yêu cầu bồi thường không) chỉ biết được sau hàng tháng tới hàng năm.

Hai điều kiện bắt buộc trước khi giám sát được: | Điều kiện | Chi tiết | |---|---| | Data capture bật trên endpoint | không bật thì job chạy với báo cáo trống | | Baseline đã tính | suggest_baseline() từ dữ liệu huấn luyện |

Ba mức phản ứng khi phát hiện drift: | Mức | Hành động | |---|---| | Nhẹ | ghi nhận, theo dõi tiếp | | Vừa | điều tra: drift ở đặc trưng nào, có ảnh hưởng độ chính xác không | | Nặng | huấn luyện lại, hoặc chuyển sang xử lý thủ công |

Và một lưu ý riêng cho tình huống trong đề: khi mở rộng sang khu vực mới, drift là điều được dự đoán trước, không phải bất ngờ. Cách tiếp cận chủ động tốt hơn là thu thập dữ liệu từ khu vực mới trước, đánh giá model trên đó, và huấn luyện lại với dữ liệu bao gồm cả khu vực mới — thay vì đợi giám sát báo động sau khi đã định giá sai cho nhiều khách hàng.

Giám sát vẫn cần thiết, nhưng nó là lưới an toàn, không nên là chiến lược chính khi bạn đã biết trước sự thay đổi sắp tới.

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

What is Feature Engineering in the context of machine learning?

  1. A

    Feature Engineering involves selecting, modifying, or creating features from raw data to improve the performance of machine learning models, and it is important because it can significantly enhance model accuracy and efficiency
  2. B

    Feature Engineering is the process of tuning hyperparameters in a machine learning model, and it is important because it optimizes the model’s performance
  3. C

    Feature Engineering refers to the visualization of data to understand patterns, and it is important because it helps in identifying trends in the dataset
  4. D

    Feature Engineering is the process of collecting raw data, and it is important because it ensures the availability of data for model training
Xem giải thích

Đáp án

A — Feature engineering là quá trình chọn lọc, biến đổi hoặc tạo mới đặc trưng từ dữ liệu thô để cải thiện hiệu năng của model ML; nó quan trọng vì có thể nâng đáng kể độ chính xác và hiệu quả của model.

Vì sao đúng

Định nghĩa này bao gồm cả ba hoạt động của feature engineering: | Hoạt động | Ví dụ | |---|---| | Chọn lọc (selecting) | bỏ cột không liên quan hoặc trùng lặp | | Biến đổi (modifying) | chuẩn hoá, mã hoá phân loại, xử lý ngoại lai | | Tạo mới (creating) | tỷ lệ nợ/thu nhập từ hai cột riêng lẻ |

Hoạt động thứ ba thường có tác động lớn nhất, và nó là nơi kiến thức lĩnh vực phát huy:

Dữ liệu thô:  thu_nhap = 50.000.000
              tong_no  = 30.000.000

Đặc trưng tạo mới:  ty_le_no_thu_nhap = 0,6

Model tuyến tính không tự tạo được tỷ số từ hai cột; model cây có thể xấp xỉ nhưng kém hiệu quả. Tạo tường minh cho model đúng thứ nó cần.

Vì sao feature engineering quan trọng — một câu tổng kết được lặp lại nhiều trong thực hành ML:

Một đặc trưng tốt thường cải thiện nhiều hơn hàng chục lần tinh chỉnh siêu tham số.

Bảng so sánh mức tác động điển hình: | Việc | Mức cải thiện thường thấy | |---|---| | Thêm một đặc trưng nghiệp vụ tốt | lớn | | Thêm dữ liệu thật | lớn | | Đổi thuật toán | vừa | | Tinh chỉnh siêu tham số | nhỏ |

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

  • B. Feature engineering là quá trình tinh chỉnh SIÊU THAM SỐ — nhầm hai khái niệm hoàn toàn khác nhau: feature engineering làm việc với dữ liệu đầu vào, tinh chỉnh siêu tham số làm việc với cấu hình thuật toán.
  • C. Feature engineering là TRỰC QUAN HOÁ dữ liệu để hiểu mẫu — đây là EDA (phân tích thăm dò), một bước đi trước feature engineering. EDA giúp bạn quyết định nên tạo đặc trưng nào, nhưng bản thân nó không tạo ra đặc trưng.
  • D. Feature engineering là quá trình THU THẬP dữ liệu thô — đó là thu thập dữ liệu (data collection), bước đầu tiên trong pipeline. Feature engineering diễn ra sau khi đã có dữ liệu.

Ghi nhớ

Vị trí của feature engineering trong pipeline ML:

① Thu thập dữ liệu  → có dữ liệu thô
② EDA               → hiểu dữ liệu, phát hiện vấn đề
③ FEATURE ENGINEERING → biến dữ liệu thô thành đặc trưng model dùng được
④ Huấn luyện        → thuật toán học từ đặc trưng
⑤ Tinh chỉnh        → tối ưu siêu tham số
⑥ Đánh giá          → đo chất lượng

Bốn nhóm kỹ thuật feature engineering: | Nhóm | Kỹ thuật | |---|---| | Biến đổi | chuẩn hoá, log transform, binning, one-hot encoding | | Tạo mới | tỷ số, tương tác, đặc trưng đa thức, tổng hợp theo nhóm | | Tách | feature splitting: ngày giờ → năm, tháng, thứ, giờ | | Chọn lọc | bỏ cột tương quan cao, bỏ cột phương sai gần 0 |

Bốn loại đặc trưng thường mạnh nhất trong thực tế: | Loại | Ví dụ | |---|---| | Tỷ số | nợ/thu nhập, chi tiêu/số lần giao dịch | | Tổng hợp theo thời gian | số giao dịch 7 ngày qua, trung bình 30 ngày | | Độ lệch so với chuẩn cá nhân | giao dịch này so với trung bình của CHÍNH người đó | | Từ timestamp | thứ trong tuần, giờ, có phải ngày lễ |

Loại thứ ba đặc biệt mạnh cho phát hiện bất thường và gian lận: bất thường không phải "giá trị lớn", mà là "lớn đối với người này".

Ba công cụ AWS hỗ trợ feature engineering: | Công cụ | Đặc điểm | |---|---| | SageMaker Data Wrangler | 300+ transform, trực quan | | AWS Glue DataBrew | 250+ transform, cho kỹ sư dữ liệu | | SageMaker Feature Store | lưu và chia sẻ đặc trưng đã tạo |

Và một bẫy cần cảnh giác khi tạo đặc trưng: rò rỉ dữ liệu tương lai. Một đặc trưng như "tổng chi tiêu cả năm" nếu tính tại thời điểm hiện tại rồi dùng để dự đoán một sự kiện trong quá khứ là rò rỉ — model sẽ đạt điểm rất cao lúc kiểm chứng rồi thất bại trên production. Feature Store với time travel chính là công cụ chống điều này.

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

You are a Machine Learning Operations (MLOps) Engineer at a large technology company that runs multiple machine learning workloads across different environments. Your company has a variety of ML use cases, including continuous real-time predictions, scheduled batch processing for weekly model retraining, and small-scale experimentation with multiple hyperparameter tuning jobs that can tolerate failure.

Which of the following strategies represents the best use of spot instances, on-demand instances, and reserved instances for different machine learning workloads, considering the requirements for cost optimization, reliability, and performance? (Select two)

  1. A

    Use reserved instances for real-time predictions that require high availability
  2. B

    Use reserved instances for scheduled batch processing for model retraining
  3. C

    Use on-demand instances for real-time predictions that require high availability
  4. D

    Use spot instances for hyperparameter tuning jobs where interruptions can be tolerated
  5. E

    Use on-demand instances for hyperparameter tuning jobs where interruptions can be tolerated
Xem giải thích

Đáp án

A và D.

  • A — Dùng reserved instance cho dự đoán thời gian thực vốn cần tính sẵn sàng cao
  • D — Dùng spot instance cho job tinh chỉnh siêu tham số nơi gián đoạn chấp nhận được

Vì sao đúng

Đề mô tả ba loại khối lượng công việc, và mỗi loại có mô hình mua phù hợp riêng: | Khối lượng | Đặc điểm | Mô hình mua | |---|---|---| | Dự đoán thời gian thực liên tục | chạy 24/7, không được gián đoạn | Reserved / Savings Plans | | Huấn luyện lại theo lịch hằng tuần | định kỳ, ngắn | on-demand hoặc Spot | | Tinh chỉnh siêu tham số quy mô nhỏ | chịu được lỗi | Spot |

A — Reserved cho suy luận liên tục đúng vì hai lý do:

Chạy 24/7  → có mẫu ổn định để cam kết → Reserved giảm ~40–70%
Cần tính sẵn sàng cao → KHÔNG dùng Spot được (bị thu hồi = dịch vụ đứt)

D — Spot cho tinh chỉnh siêu tham số là ứng dụng lý tưởng của Spot: | Đặc điểm | Vì sao hợp Spot | |---|---| | Mỗi lần thử ĐỘC LẬP | mất một lần thử không ảnh hưởng các lần khác | | Đề nói rõ "can tolerate failure" | đúng điều kiện của Spot | | Nhiều job song song | mất vài cái thì chạy lại | | Chi phí lớn | tinh chỉnh có thể chạy hàng chục lần thử |

SageMaker Managed Spot Training tự xử lý việc thử lại khi bị thu hồi.

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

  • C. Dùng on-demand cho dự đoán thời gian thực cần tính sẵn sàng cao — đây là phương án gần nhất và hoạt động được về mặt kỹ thuật (on-demand ổn định, không bị thu hồi). Nhưng với khối lượng chạy liên tục 24/7, on-demand là lãng phí: bạn trả giá đầy đủ cho một mẫu sử dụng hoàn toàn dự đoán được. Reserved hoặc Savings Plans giảm 40–70% cho đúng trường hợp này.
  • E. Dùng on-demand cho job tinh chỉnh siêu tham số nơi gián đoạn chấp nhận được — bỏ lỡ cơ hội tiết kiệm lớn nhất: chính vế "gián đoạn chấp nhận được" là điều kiện để dùng Spot và giảm tới 90%. Trả giá on-demand cho workload đủ điều kiện Spot là lãng phí rõ ràng.
  • B. Dùng reserved instance cho xử lý theo lô hằng tuần — sai vì thời gian sử dụng quá thấp: job chạy vài giờ mỗi tuần, tức khoảng 1–2% thời gian. Reserved tính tiền theo thời gian cam kết, nên bạn trả cho 98% thời gian không dùng.

Ghi nhớ

Bốn mô hình mua compute — và câu hỏi để chọn: | Mô hình | Giảm giá | Điều kiện | |---|---|---| | On-Demand | 0% | linh hoạt, không cam kết | | Spot | tới 90% | chịu được gián đoạn | | Reserved / Savings Plans | 40–70% | chạy liên tục, cam kết 1–3 năm | | Dedicated Host | — | yêu cầu giấy phép hoặc tuân thủ |

Cây quyết định:

① Workload có chịu được gián đoạn không?
   └─ Có → SPOT
② Có chạy gần như liên tục không?
   └─ Có → RESERVED / SAVINGS PLANS
③ Còn lại → ON-DEMAND

Bẫy phổ biến nhất: nhầm "kéo dài N tháng" với "chạy liên tục N tháng". Một job chạy 2 giờ mỗi tuần trong 6 tháng chỉ dùng khoảng 52 giờ — Reserved cho nó là lãng phí (xem thêm #6462).

Ba loại workload ML và mô hình mua tương ứng: | Workload | Mô hình | |---|---| | Endpoint suy luận production | Savings Plans cho mức nền + on-demand cho đỉnh | | Huấn luyện, tinh chỉnh siêu tham số | Spot (Managed Spot Training) | | Thử nghiệm, notebook | on-demand, nhớ tắt khi không dùng |

Một điểm kỹ thuật quan trọng: SageMaker training job hỗ trợ Spot qua Managed Spot Training, nhưng SageMaker ENDPOINT thì KHÔNG. Nên "dùng Spot cho suy luận" không chỉ là ý tồi — nó không thực hiện được.

Và hai lựa chọn Savings Plans: | Loại | Đặc điểm | |---|---| | SageMaker Savings Plans | áp cho SageMaker: training, inference, notebook | | Compute Savings Plans | áp cho EC2, Fargate, Lambda — không áp cho SageMaker |

Dòng thứ hai là chi tiết dễ vấp: mua nhầm loại thì khoản cam kết không áp được cho workload SageMaker.

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

You are a machine learning engineer at a tech company responsible for maintaining a recommendation engine that drives personalized content for users. The current model has been performing well, but you’ve recently developed a new model that incorporates additional features and advanced techniques. Before fully replacing the existing model, you want to evaluate the new model's performance in a real-world environment. To do this, you decide to use A/B testing to compare the performance of the new model against the current model in terms of business outcomes.

Which of the following approaches is the MOST EFFECTIVE for conducting A/B testing for this use case?

  1. A

    Deploy the new model as the primary endpoint and keep the current model as a fallback. Use AWS Lambda to route a percentage of traffic to the new model and compare the predictions manually to decide which model to keep
  2. B

    Randomly assign a percentage of users to each model and measure engagement metrics, such as click-through rates and session duration, using Amazon CloudWatch to aggregate the results and determine the winning model
  3. C

    Fully deploy the new model and observe its performance over time. If it performs worse than the old model, revert to the previous model and analyze the differences
  4. D

    Deploy both models behind separate endpoints and use Amazon SageMaker Model Monitor to track key performance metrics like accuracy and latency, choosing the better model based on these metrics
Xem giải thích

Đáp án

B — Phân bổ ngẫu nhiên một tỷ lệ người dùng cho mỗi model và đo các chỉ số tương tác như tỷ lệ nhấp và thời gian phiên, dùng CloudWatch tổng hợp kết quả để xác định model thắng.

Vì sao đúng

Đề nêu rõ mục tiêu: so sánh hai model về mặt KẾT QUẢ NGHIỆP VỤ (business outcomes), trong môi trường thực tế.

Và đó là điểm quyết định — nó loại phương án D: | Loại chỉ số | Ví dụ | Đo được gì | |---|---|---| | Chỉ số kỹ thuật | độ chính xác, độ trễ | model dự đoán đúng không | | Chỉ số nghiệp vụ | tỷ lệ nhấp, thời gian phiên, doanh thu | model có tạo giá trị không |

Hai loại này có thể lệch nhau, và đó là lý do phải đo loại thứ hai:

Model B chính xác hơn (dự đoán đúng thứ người dùng SẼ xem)
    nhưng gợi ý toàn nội dung người dùng ĐÃ ĐỊNH xem
    → tỷ lệ nhấp không tăng, người dùng không khám phá gì mới
    → chính xác hơn nhưng GIÁ TRỊ NGHIỆP VỤ thấp hơn

Ba yếu tố của một A/B test hợp lệ, và B có đủ: | Yếu tố | Chi tiết | |---|---| | Phân bổ ngẫu nhiên | loại bỏ thiên lệch chọn mẫu | | Chạy đồng thời | loại bỏ ảnh hưởng của thời điểm (mùa vụ, sự kiện) | | Đo chỉ số nghiệp vụ | đo thứ thật sự quan trọng |

Trên SageMaker, cơ chế đúng để làm việc này là production variant — hai model trên cùng một endpoint với tỷ lệ lưu lượng khai được:

ProductionVariants=[
    {'VariantName': 'model-hien-tai', 'InitialVariantWeight': 90, ...},
    {'VariantName': 'model-moi',      'InitialVariantWeight': 10, ...}]

Mọi chỉ số CloudWatch được tách theo VariantName, nên so sánh trực tiếp được.

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

  • D. Triển khai hai model sau hai endpoint RIÊNG và dùng Model Monitor theo dõi chỉ số như độ chính xác và ĐỘ TRỄ, chọn model tốt hơn dựa trên đó — đây là phương án gần nhất và sai ở loại chỉ số: độ chính xác và độ trễ là chỉ số kỹ thuật, còn đề hỏi về business outcomes. (Hai endpoint riêng cũng cần thêm một tầng định tuyến, phức tạp hơn production variant.)
  • A. Triển khai model mới làm endpoint chính và giữ model cũ làm dự phòng; Lambda định tuyến một phần lưu lượng và so sánh dự đoán THỦ CÔNG — "manually" không mở rộng được: với hàng nghìn người dùng, không ai so sánh tay được. Và "so sánh dự đoán" lại là chỉ số kỹ thuật, không phải kết quả nghiệp vụ.
  • C. Triển khai hoàn toàn model mới và quan sát theo thời gian; nếu tệ hơn thì quay lại bản cũ — không phải A/B test: không có nhóm đối chứng chạy đồng thời, nên mọi thay đổi có thể do thời điểm chứ không do model. Và nó phơi 100% người dùng cho model chưa kiểm chứng.

Ghi nhớ

Hai loại chỉ số khi đánh giá model — luôn cần cả hai: | Loại | Đo | Khi nào dùng | |---|---|---| | Offline (kỹ thuật) | accuracy, AUC, độ trễ | trước khi triển khai | | Online (nghiệp vụ) | CTR, doanh thu, thời gian phiên, tỷ lệ giữ chân | A/B test trên production |

Chỉ số offline tốt là điều kiện CẦN nhưng không ĐỦ. Rất nhiều model thắng offline mà thua online — và chỉ A/B test mới phát hiện được.

Ba cơ chế chia lưu lượng của SageMaker: | Cơ chế | Việc | |---|---| | Production variant | nhiều model trên MỘT endpoint, chia theo trọng số — A/B test | | Blue/green deployment | THAY THẾ model cũ, có canary và auto rollback | | Multi-model endpoint | nhiều model khác nhau chia sẻ instance để tiết kiệm |

Câu hỏi phân biệt:

"Tôi đang SO SÁNH hai model?" → production variant "Tôi đang THAY THẾ model cũ?" → blue/green

Ba nguyên tắc của A/B test đáng tin: | Nguyên tắc | Vì sao | |---|---| | Phân bổ ngẫu nhiên và ỔN ĐỊNH | cùng một người dùng luôn thấy cùng một model | | Chạy đủ lâu | kết luận sớm từ mẫu nhỏ thường sai | | Xác định chỉ số CHÍNH trước khi bắt đầu | tránh chọn chỉ số nào đẹp thì báo cáo cái đó |

Nguyên tắc đầu (sticky assignment) hay bị bỏ sót: nếu một người dùng lúc thấy model A lúc thấy model B, trải nghiệm không nhất quán và chỉ số bị nhiễu. Cách làm: hash user ID để quyết định nhóm, thay vì random ở mỗi request.

Và CloudWatch Evidently đáng biết như lựa chọn thay thế: nó quản lý việc chia nhóm, tính ý nghĩa thống kê, và tự dừng thử nghiệm khi có kết luận — bớt được phần lớn mã tự viết và tránh được lỗi kết luận sớm.

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

A company is using a fleet of Amazon EC2 instances to ingest data from on-premises data sources. The data is in JSON format and ingestion rates can be as high as 1 MB/s. When an EC2 instance is rebooted, the data in flight is lost. The company’s data science team wants to query ingested data in near-real time.

Which solution provides near-real-time data querying that is scalable with minimal data loss?

  1. A

    Store ingested data in an EC2 instance store. Publish data to Amazon Kinesis Data Firehose with Amazon S3 as the destination. Use Amazon Athena to query the data
  2. B

    Store ingested data in an Amazon Elastic Block Store (Amazon EBS) volume. Write to Amazon S3 bucket and use Amazon Redshift Spectrum to query the data
  3. C

    Store ingested data in an Amazon Elastic Block Store (Amazon EBS) volume. Publish data to Amazon ElastiCache for Redis. Subscribe to the Redis channel to query the data
  4. D

    Publish data to Amazon Kinesis Data Streams, use Kinesis Data Analytics to query the data
Xem giải thích

Đáp án

D — Đẩy dữ liệu vào Amazon Kinesis Data Streams, dùng Kinesis Data Analytics truy vấn dữ liệu.

Vì sao đúng

Đề nêu ba yêu cầu, và cụm quyết định là "near-real-time querying" cộng "minimal data loss": | Yêu cầu | Cơ chế | |---|---| | Không mất dữ liệu khi EC2 khởi động lại | đẩy vào stream ngay, không giữ trên instance | | Truy vấn gần thời gian thực | Kinesis Data Analytics — SQL trên luồng | | Mở rộng được | Kinesis co giãn theo shard |

Nguyên nhân mất dữ liệu trong tình huống hiện tại:

Dữ liệu nằm TRÊN EC2 (instance store hoặc EBS) khi instance khởi động lại
    → dữ liệu đang trong bộ nhớ/đệm bị mất

Cách chữa: đẩy ra khỏi instance càng sớm càng tốt, vào một kho bền vững có sao chép — và Kinesis Data Streams lưu bản ghi trên nhiều AZ ngay khi nhận.

Vì sao Kinesis Data Analytics cho vế truy vấn: nó chạy SQL liên tục trên luồng dữ liệu, cho kết quả trong vài giây:

CREATE STREAM canh_bao AS
SELECT STREAM ma_thiet_bi, AVG(gia_tri) AS trung_binh
FROM   nguon_json
GROUP BY ma_thiet_bi,
         STEP(nguon_json.ROWTIME BY INTERVAL '1' MINUTE);

Đây là truy vấn trên dữ liệu đang chảy, không phải trên dữ liệu đã lưu — nên độ trễ tính bằng giây.

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

  • A. Lưu dữ liệu vào instance store của EC2, đẩy sang Kinesis Data Firehose với đích S3, dùng Athena truy vấn — đây là phương án gần nhất và có hai vấn đề: instance store là bộ nhớ tạm — mất hết khi instance dừng (đúng vấn đề đề nêu), và Firehose có độ trễ đệm tối thiểu 60 giây cộng thời gian Athena quét S3 — nên không đạt "near-real-time". (Firehose + Athena là kiến trúc tốt cho phân tích theo lô, không cho truy vấn gần tức thời.)
  • B. Lưu vào EBS, ghi sang S3 và dùng Redshift Spectrum truy vấn — cùng vấn đề độ trễ, và Redshift Spectrum còn chậm hơn Athena cho truy vấn ad-hoc. EBS bền hơn instance store nhưng dữ liệu đang trong bộ đệm ứng dụng vẫn mất khi khởi động lại.
  • C. Lưu vào EBS, đẩy sang ElastiCache for Redis, đăng ký kênh Redis để truy vấn — Redis pub/sub không lưu trữ và không truy vấn được: message đã phát mà không có ai đang nghe thì mất luôn. Đó là mô hình fire-and-forget, ngược hẳn yêu cầu "minimal data loss".

Ghi nhớ

Bốn dịch vụ streaming của AWS — phân biệt cho rõ: | Dịch vụ | Việc | |---|---| | Kinesis Data Streams | thu nhận và lưu tạm luồng dữ liệu (giữ 24h–365 ngày) | | Kinesis Data Firehose | giao luồng tới đích (S3, Redshift, OpenSearch) — CÓ ĐỆM | | Kinesis Data Analytics | chạy SQL hoặc Flink TRÊN luồng | | Amazon MSK | Kafka được quản lý |

Phân biệt hai cái đầu — điểm mấu chốt: | | Data Streams | Data Firehose | |---|---|---| | Độ trễ | dưới một giây | tối thiểu 60 giây (đệm) | | Nhiều consumer | ✅ | ❌ một đích | | Lưu lại dữ liệu | ✅ replay được | ❌ chỉ chuyển tiếp | | Quản lý shard | phải tự lo (hoặc dùng on-demand) | không cần |

Với yêu cầu near-real-time, phải dùng Data Streams; Firehose là lựa chọn cho việc nạp vào kho dữ liệu.

Ba mức độ trễ và kiến trúc tương ứng: | Mức | Kiến trúc | |---|---| | Dưới giây | Kinesis Data Streams + Data Analytics (hoặc Lambda) | | Vài phút | Firehose → S3 → Athena | | Hàng giờ | job theo lô, Glue → S3 → Athena |

Ba cách giảm mất dữ liệu ở tầng thu nhận: | Cách | Chi tiết | |---|---| | Đẩy ra khỏi instance ngay | không tích luỹ trên đĩa cục bộ | | Kinesis Producer Library với retry | tự thử lại khi lỗi tạm thời | | Ghi nhận (ack) sau khi Kinesis xác nhận | không xoá nguồn trước khi chắc chắn đã nhận |

Và một chi tiết về sức chứa: mỗi shard của Kinesis nhận được 1 MB/s hoặc 1.000 bản ghi/s. Đề nói tốc độ tới 1 MB/s, nên cần ít nhất 2 shard để có biên an toàn — hoặc dùng chế độ on-demand để Kinesis tự co giãn.

Câu 77 ML Model Development

You are a machine learning engineer tasked with building a deep learning model to classify images for an autonomous vehicle project. The dataset is massive, consisting of millions of labeled images. Initial training runs on a single GPU instance in Amazon SageMaker are taking too long, and the training costs are rising. You need to reduce the model training time without compromising performance significantly.

Which of the following approaches is the MOST LIKELY to effectively reduce the training time while maintaining model performance?

  1. A

    Implement distributed training using multiple GPU instances to parallelize the training process, reducing the overall time
  2. B

    Reduce the size of the training dataset to speed up training, even if it means using fewer examples per class
  3. C

    Enable early stopping to halt training when the model’s performance on the validation set stops improving, thereby avoiding overfitting
  4. D

    Switch to a smaller instance type to reduce computational costs, accepting a longer training time as a trade-off
Xem giải thích

Đáp án

A — Triển khai huấn luyện phân tán trên nhiều instance GPU để song song hoá quá trình huấn luyện, giảm tổng thời gian.

Vì sao đúng

Đề nêu ba điều kiện: | Điều kiện | Ý nghĩa | |---|---| | Hàng triệu ảnh đã gán nhãn | dữ liệu lớn, không muốn bỏ bớt | | Một GPU quá chậm | cần thêm năng lực tính toán | | Không được giảm hiệu năng đáng kể | không được hy sinh chất lượng |

Huấn luyện phân tán là cách duy nhất trong bốn phương án thêm năng lực mà không đánh đổi chất lượng.

Data parallelism là chiến lược phù hợp ở đây:

Mỗi GPU giữ một BẢN SAO ĐẦY ĐỦ của model
Mỗi GPU xử lý một PHẦN của batch
    ↓
Đồng bộ gradient giữa các GPU (all-reduce)
    ↓
Cập nhật trọng số như nhau trên mọi GPU

Với 8 GPU, mỗi bước xử lý được batch lớn gấp 8 lần — thời gian mỗi epoch giảm gần 8 lần.

Vì sao data parallelism chứ không phải model parallelism: model phân loại ảnh thường vừa một GPU; vấn đề là lượng dữ liệu, không phải kích thước model. (Nếu model không vừa một GPU thì mới cần model parallelism — xem #6426.)

estimator = PyTorch(
    entry_point='train.py',
    instance_type='ml.p4d.24xlarge',
    instance_count=4,                          # 4 instance
    distribution={'torch_distributed': {'enabled': True}})

Và SageMaker Distributed Data Parallel (SMDDP) là thư viện tối ưu riêng cho mạng AWS — thường nhanh hơn giải pháp mã nguồn mở nhờ tận dụng cấu trúc mạng của EC2.

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

  • C. Bật early stopping để dừng khi hiệu năng trên tập kiểm chứng ngừng cải thiện, tránh overfitting — đây là phương án gần nhất và early stopping có giảm thời gian huấn luyện, nhưng nó giải quyết một vấn đề khác: nó ngăn lãng phí epoch thừa, chứ không làm mỗi epoch nhanh hơn. Với hàng triệu ảnh, ngay cả một epoch cũng đã quá chậm. (Nên bật early stopping — nhưng nó không phải câu trả lời cho "một GPU quá chậm".)
  • B. Giảm kích thước tập huấn luyện, kể cả khi phải dùng ít mẫu hơn cho mỗi lớp — hy sinh chất lượng, trái thẳng ràng buộc "without compromising performance significantly". Với xe tự lái, giảm dữ liệu huấn luyện là quyết định có hậu quả an toàn.
  • D. Chuyển sang instance nhỏ hơn để giảm chi phí, chấp nhận thời gian huấn luyện lâu hơn — ngược hoàn toàn: đề yêu cầu giảm thời gian huấn luyện.

Ghi nhớ

Ba chiến lược song song hoá huấn luyện: | Chiến lược | Giải quyết | Điều kiện | |---|---|---| | Data parallelism | dữ liệu quá nhiều | model phải vừa một GPU ← câu này | | Model parallelism | model quá lớn | model không vừa một GPU | | Hybrid | cả hai | model rất lớn + dữ liệu rất lớn |

Ba thư viện huấn luyện phân tán trên SageMaker: | Thư viện | Đặc điểm | |---|---| | SageMaker Distributed Data Parallel (SMDDP) | tối ưu cho mạng AWS — thường nhanh nhất | | SageMaker Model Parallel (SMP) | chia model qua nhiều thiết bị | | PyTorch DDP / Horovod | mã nguồn mở, quen thuộc |

Ba yếu tố ảnh hưởng hiệu quả mở rộng: | Yếu tố | Chi tiết | |---|---| | Băng thông mạng | bật EFA cho instance nhiều GPU | | Kích thước batch mỗi GPU | quá nhỏ thì overhead đồng bộ chiếm ưu thế | | Thông lượng đọc dữ liệu | I/O có thể trở thành nút thắt mới |

Dòng cuối là điều rất hay xảy ra: sau khi thêm GPU, nút thắt chuyển từ tính toán sang đọc dữ liệu. Ba cách xử lý: | Cách | Chi tiết | |---|---| | FastFile mode hoặc FSx for Lustre | thay File mode | | Gộp ảnh thành tệp lớn | RecordIO, TFRecord — giảm số lời gọi S3 | | Tăng số worker tải dữ liệu | num_workers trong DataLoader |

Và một điều chỉnh bắt buộc khi mở rộng: learning rate phải tăng theo kích thước batch tổng. Quy tắc tuyến tính thường dùng: batch tăng 8 lần thì learning rate tăng khoảng 8 lần, kèm warmup vài epoch đầu. Bỏ qua điều này là mở rộng xong mà chất lượng model giảm — đúng thứ đề nói phải tránh.

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

A company uses a generative model to analyze animal images in the training dataset to record variables like different ear shapes, eye shapes, tail features, and skin patterns.

Which of the following tasks can the generative model perform?

  1. A

    The model can recreate new animal images that were not in the training dataset
  2. B

    The model can classify a single species of animals such as cats
  3. C

    The model can identify any image from the training dataset
  4. D

    The model can classify multiple species of animals such as cats, dogs, etc
Xem giải thích

Đáp án

A — Model có thể tạo ra ảnh động vật MỚI chưa từng có trong tập dữ liệu huấn luyện.

Vì sao đúng

Câu hỏi kiểm tra hiểu biết cơ bản về model sinh (generative) so với model phân biệt (discriminative): | Loại model | Học gì | Làm được gì | |---|---|---| | Sinh (generative) | phân bố của DỮ LIỆU P(X) | tạo ra mẫu MỚI | | Phân biệt (discriminative) | ranh giới giữa các lớp P(Y|X) | phân loại |

Đề mô tả rõ model đang làm gì: phân tích ảnh để ghi nhận các biến như hình dạng tai, hình dạng mắt, đặc điểm đuôi, hoa văn da. Đó là học cấu trúc của dữ liệu, không phải học ranh giới phân loại.

Và khi đã học được cấu trúc đó, model có thể tổ hợp lại thành mẫu mới:

Model học được:
  - tai có thể nhọn hoặc cụp
  - hoa văn có thể vằn, đốm, trơn
  - đuôi có thể dài, ngắn, xù
        ↓
Sinh ra tổ hợp CHƯA TỪNG THẤY:
  tai nhọn + hoa văn đốm + đuôi xù  → một con vật mới

Đây chính là điều khiến model sinh khác biệt: nó không tra cứu trong tập huấn luyện, nó lấy mẫu từ phân bố đã học.

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

  • D. Model có thể phân loại nhiều loài như mèo, chó — đó là việc của model PHÂN BIỆT, không phải model sinh. (Có một sắc thái: model sinh có thể dùng cho phân loại — theo quy tắc Bayes, biết P(X|Y) và P(Y) thì suy ra P(Y|X). Nhưng đó là ứng dụng gián tiếp và không hiệu quả bằng model phân biệt chuyên dụng. Câu hỏi hỏi model sinh làm được gì, và câu trả lời đặc trưng nhất là tạo ra dữ liệu mới.)
  • B. Model có thể phân loại MỘT loài duy nhất như mèo — cùng lý do, và còn hẹp hơn.
  • C. Model có thể nhận diện bất kỳ ảnh nào TRONG tập huấn luyện — đó là ghi nhớ, không phải học sinh. Một model chỉ nhận ra ảnh đã thấy thì vô dụng — nó không tổng quát hoá được. (Và nếu một model sinh chỉ tái tạo được đúng ảnh trong tập huấn luyện thì đó là dấu hiệu overfitting nghiêm trọng, gọi là memorization.)

Ghi nhớ

Hai họ model — bảng nền tảng: | | Generative | Discriminative | |---|---|---| | Học | P(X) hoặc P(X, Y) | P(Y|X) | | Trả lời | "dữ liệu này trông thế nào?" | "cái này thuộc lớp nào?" | | Ví dụ | GAN, VAE, Diffusion, LLM | hồi quy logistic, SVM, CNN phân loại | | Làm được | tạo mẫu mới, điền phần thiếu, phát hiện bất thường | phân loại, hồi quy |

Bốn kiến trúc model sinh cho ảnh: | Kiến trúc | Đặc điểm | |---|---| | GAN | hai mạng đối kháng — ảnh sắc nét, khó huấn luyện | | VAE | không gian tiềm ẩn có cấu trúc — ảnh mờ hơn, ổn định hơn | | Diffusion | khử nhiễu dần — chất lượng cao nhất hiện nay | | Autoregressive | sinh từng pixel hoặc token |

Ba ứng dụng của model sinh ngoài việc tạo nội dung: | Ứng dụng | Cách hoạt động | |---|---| | Data augmentation | sinh thêm mẫu cho lớp thiểu số | | Phát hiện bất thường | mẫu có xác suất thấp dưới phân bố đã học = bất thường | | Điền phần thiếu | inpainting, hoàn thiện dữ liệu |

Ứng dụng thứ hai đáng nhớ vì nó nối với các câu khác trong lô này: một model sinh học "trạng thái bình thường" trông thế nào, rồi gắn cờ những gì lệch khỏi đó — cùng nguyên lý với Random Cut Forest ở #6503.

Và một điểm về memorization đáng cảnh giác trong thực tế: nếu model sinh tái tạo gần như y hệt các mẫu trong tập huấn luyện, đó là vấn đề — cả về chất lượng (không tổng quát hoá) lẫn về quyền riêng tư (có thể lộ dữ liệu huấn luyện). Với dữ liệu nhạy cảm, đây là rủi ro cần đo và kiểm soát.

Câu 79 ML Model Development

You are a machine learning engineer working for an e-commerce company. You have developed a recommendation model that predicts products customers are likely to buy based on their browsing history and past purchases. The model initially performs well, but after deploying it in production, you notice two issues: the model's performance degrades over time as new data is added (catastrophic forgetting) and the model shows signs of overfitting during retraining on updated datasets.

Given these challenges, which of the following strategies is the MOST LIKELY to help prevent overfitting and catastrophic forgetting while maintaining model accuracy?

  1. A

    Regularly update the training dataset with new data, apply L2 regularization to manage overfitting, and use an ensemble of models to prevent catastrophic forgetting
  2. B

    Apply L2 regularization to reduce overfitting, use dropout to prevent underfitting, and retrain the model on the entire dataset periodically to avoid catastrophic forgetting
  3. C

    Use early stopping during training to prevent overfitting, incorporate new data incrementally through transfer learning to mitigate catastrophic forgetting, and apply L1 regularization to ensure feature selection
  4. D

    Reduce the model complexity by decreasing the number of features, apply data augmentation to handle underfitting, and leverage L1 regularization to address catastrophic forgetting
Xem giải thích

Đáp án

C — Dùng early stopping khi huấn luyện để chống overfitting, đưa dữ liệu mới vào từng phần qua transfer learning để giảm catastrophic forgetting, và áp L1 regularization để chọn lọc đặc trưng.

Vì sao đúng

Đề nêu hai vấn đề riêng biệt, và đáp án phải xử lý cả hai: | Vấn đề | Cơ chế trong C | |---|---| | Overfitting khi huấn luyện lại | early stopping + L1 regularization | | Catastrophic forgetting | transfer learning, cập nhật từng phần |

Catastrophic forgetting đáng giải thích riêng vì nó là khái niệm ít quen hơn:

Khi huấn luyện tiếp một mạng nơ-ron chỉ trên dữ liệu MỚI, nó "quên" những gì đã học từ dữ liệu cũ — trọng số bị điều chỉnh hoàn toàn theo phân bố mới.

Model học từ dữ liệu 2024 → biết mẫu mua sắm của khách cũ
    ↓ huấn luyện tiếp CHỈ trên dữ liệu 2026
Model quên mẫu 2024 → gợi ý kém cho nhóm khách hàng lâu năm

Transfer learning với cập nhật từng phần giảm điều này bằng cách: | Kỹ thuật | Cách làm | |---|---| | Đóng băng tầng đầu | giữ nguyên biểu diễn tổng quát đã học | | Learning rate thấp cho tầng cũ | thay đổi chậm, không xoá sạch | | Trộn dữ liệu cũ vào lô mới | (replay) — cách trực tiếp nhất |

Early stopping xử lý vế overfitting khi huấn luyện lại: mỗi lần cập nhật trên dữ liệu mới (thường ít hơn dữ liệu gốc) rất dễ overfit vào lô đó.

L1 regularization đưa một số hệ số về đúng 0, tức là tự chọn lọc đặc trưng — hữu ích khi tập đặc trưng phình ra qua các lần cập nhật.

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

  • B. Áp L2 regularization giảm overfitting, dùng dropout để chống UNDERFITTING, và huấn luyện lại trên TOÀN BỘ dữ liệu định kỳ để tránh catastrophic forgetting — đây là phương án gần nhất và có một lỗi khái niệm rõ ràng: dropout chống OVERFITTING, không chống underfitting — nó làm model học được ít hơn, nên với underfitting nó làm tình hình tệ hơn. (Vế "huấn luyện lại trên toàn bộ dữ liệu" thì đúng về nguyên lý — đó là cách chắc chắn nhất tránh quên — nhưng tốn kém và không phải lúc nào cũng khả thi.)
  • **A. Cập nhật dữ liệu thường xuyên, L2 regularization, và dùng ensemble để chống catastrophic forgetting — ensemble không giải quyết catastrophic forgetting: nếu mọi model trong ensemble đều được huấn luyện tiếp trên dữ liệu mới, tất cả cùng quên. (Có một biến thể hợp lệ: giữ model cũ trong ensemble và không cập nhật nó — nhưng phương án không nói vậy.)
  • **D. Giảm độ phức tạp bằng cách bớt đặc trưng, data augmentation để xử lý UNDERFITTING, và L1 để giải quyết catastrophic forgetting — hai lỗi khái niệm: augmentation chống overfitting (không phải underfitting), và L1 là kỹ thuật regularization, không liên quan gì tới catastrophic forgetting.

Ghi nhớ

Catastrophic forgetting — bốn cách giảm thiểu: | Cách | Chi tiết | |---|---| | Rehearsal / replay | trộn dữ liệu cũ vào lô huấn luyện mới — hiệu quả nhất | | Huấn luyện lại toàn bộ | chắc chắn nhất, tốn nhất | | Đóng băng tầng | giữ biểu diễn tổng quát | | Elastic Weight Consolidation | phạt việc thay đổi trọng số quan trọng |

Với hệ thống gợi ý thương mại điện tử, huấn luyện lại toàn bộ định kỳ thường là lựa chọn thực dụng nhất — dữ liệu có sẵn và chi phí huấn luyện không quá lớn.

Phân biệt L1 và L2 regularization: | | L1 (Lasso) | L2 (Ridge) | |---|---|---| | Phạt | tổng |hệ số| | tổng (hệ số)² | | Hiệu ứng | đưa hệ số về ĐÚNG 0 | thu nhỏ nhưng không về 0 | | Dùng cho | chọn lọc đặc trưng | giảm overfitting nói chung | | Kết quả | model thưa (sparse) | model dày |

Bảng phân biệt overfitting và underfitting — bảng này giải quyết được ba lỗi trong các phương án sai: | | Overfitting | Underfitting | |---|---|---| | Train loss | thấp | cao | | Validation loss | cao | cao | | Chữa bằng | dropout, regularization, thêm dữ liệu, early stopping | tăng độ phức tạp model, thêm đặc trưng, huấn luyện lâu hơn |

Dropout, regularization và augmentation đều thuộc cột trái — dùng chúng cho underfitting là làm tình hình tệ hơn.

Và một mẫu vận hành cho hệ thống gợi ý cập nhật liên tục:

Hằng ngày:  cập nhật gia tăng với learning rate thấp + replay dữ liệu cũ
Hằng tháng: huấn luyện lại TOÀN BỘ từ đầu

Mẫu này cân bằng giữa bắt kịp xu hướng mới và không quên khách hàng lâu năm — và lần huấn luyện lại toàn bộ đóng vai trò "đặt lại" mọi trôi dạt tích luỹ.

Câu 80 Deployment and Orchestration of ML Workflows

A data analytics company is using an Amazon EMR cluster to process large volumes of log data collected from various sources. The logs must be processed in batches, and the results are stored in Amazon S3 for downstream analytics. The company requires a cluster configuration that ensures no data loss during processing while being as cost-effective as possible.

Which instance purchasing option will meet these requirements?

  1. A

    Use an On-Demand instance for the primary node and Spot instances for the core nodes as well as the task nodes to reduce costs while ensuring fault tolerance
  2. B

    Use Spot instances for primary and core nodes, and On-Demand instances for task nodes to balance cost and availability
  3. C

    Use an On-Demand instance for the primary node along with the core nodes, and Spot instances for task nodes to reduce costs while ensuring fault tolerance
  4. D

    Use Spot instances for all primary, core, and task nodes to minimize costs and automatically handle failures by replacing interrupted nodes
Xem giải thích

Đáp án

C — Dùng On-Demand instance cho primary node VÀ core node, dùng Spot instance cho task node để giảm chi phí trong khi vẫn đảm bảo chịu lỗi.

Vì sao đúng

Câu hỏi này kiểm tra hiểu biết về ba loại node của EMR và vai trò khác nhau của chúng: | Loại node | Vai trò | Chứa dữ liệu HDFS? | |---|---|---| | Primary (master) | điều phối cụm, quản lý tài nguyên | ❌ nhưng mất là mất cả cụm | | Core | chạy task VÀ lưu dữ liệu HDFS | ✅ CÓ | | Task | chỉ chạy task | ❌ KHÔNG |

Cột cuối là chìa khoá của toàn bộ câu hỏi:

Core node bị thu hồi  → MẤT DỮ LIỆU HDFS trên node đó
                       → có thể mất cả job nếu không đủ bản sao

Task node bị thu hồi  → chỉ mất công việc đang xử lý
                       → YARN giao lại task đó cho node khác
                       → KHÔNG mất dữ liệu

Và primary node bị thu hồi = cả cụm chết — không có gì điều phối nữa.

Đề nói rõ "ensures no data loss during processing", nên: | Node | Lựa chọn | Lý do | |---|---|---| | Primary | On-Demand | mất là chết cả cụm | | Core | On-Demand | giữ dữ liệu HDFS | | Task | Spot | không giữ dữ liệu — an toàn để tiết kiệm |

Đây là mẫu chuẩn được AWS khuyến nghị cho EMR: giữ phần cốt lõi ổn định, dùng Spot cho phần năng lực co giãn.

Và tiết kiệm vẫn đáng kể: trong một cụm điển hình, task node chiếm phần lớn năng lực tính toán, nên giảm tới 90% cho phần đó là khoản tiết kiệm lớn.

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

  • A. On-Demand cho primary, Spot cho CẢ core node lẫn task node — đây là phương án gần nhất và sai ở core node: chúng giữ dữ liệu HDFS, nên bị thu hồi có thể gây mất dữ liệu — trái thẳng yêu cầu "no data loss".
  • B. Spot cho primary và core, On-Demand cho task node — ngược hoàn toàn: đặt Spot ở hai vị trí quan trọng nhất và On-Demand ở vị trí ít quan trọng nhất. Primary bị thu hồi là toàn bộ cụm chết.
  • D. Spot cho TẤT CẢ, tự động xử lý lỗi bằng cách thay node bị gián đoạn — rủi ro cao nhất: primary bị thu hồi thì không có "tự động thay thế" nào cứu được — cụm kết thúc và job phải chạy lại từ đầu.

Ghi nhớ

Ba loại node EMR — bảng cần thuộc: | Node | Chạy gì | Dữ liệu HDFS | Spot được? | |---|---|---|---| | Primary | YARN ResourceManager, HDFS NameNode | metadata | ❌ KHÔNG | | Core | NodeManager + DataNode | ✅ CÓ | ❌ tránh | | Task | chỉ NodeManager | ❌ | ✅ NÊN dùng |

Quy tắc thô: On-Demand cho primary và core, Spot cho task.

Ba cách giảm rủi ro thêm khi dùng Spot cho task node: | Cách | Chi tiết | |---|---| | Instance fleet với nhiều loại instance | giảm xác suất không có capacity | | Đặt tỷ lệ On-Demand tối thiểu | đảm bảo một mức năng lực nền | | Allocation strategy capacity-optimized | chọn pool ít bị thu hồi nhất |

Ba kiến trúc lưu trữ cho EMR: | Kiến trúc | Đặc điểm | |---|---| | HDFS trên core node | nhanh, nhưng gắn với vòng đời cụm | | EMRFS (S3) | bền, tách rời khỏi cụm — khuyến nghị | | Local disk (instance store) | tạm, mất khi node dừng |

Dùng S3 làm nơi lưu trữ chính (EMRFS) thay đổi hẳn bài toán này: nếu dữ liệu vào và ra đều ở S3 và HDFS chỉ dùng cho dữ liệu trung gian, thì rủi ro của việc core node bị thu hồi giảm nhiều — và bạn có thể cân nhắc Spot cho một phần core node.

Đề nói kết quả được lưu vào S3, nhưng không nói rõ dữ liệu trung gian nằm ở đâu — nên giả định thận trọng (giữ core node ổn định) là đúng với yêu cầu "no data loss".

Và một lựa chọn kiến trúc đáng cân nhắc cho workload theo lô như trong đề: cụm tạm thời (transient cluster) — khởi tạo cụm, chạy job, rồi tự tắt. Kết hợp với dữ liệu trên S3, nó loại bỏ phần lớn rủi ro về mất dữ liệu và tránh trả tiền cho cụm nhàn rỗi.