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

Tìm thấy 195 câu.

Câu 81 ML Model Development

You are a data scientist at an e-commerce company working to develop a recommendation system for customers. After building several models, including collaborative filtering, content-based filtering, and a deep learning model, you find that each model excels in different scenarios. For example, the collaborative filtering model works well for returning customers with rich interaction data, while the content-based filtering model performs better for new customers with little interaction history. Your goal is to combine these models to create a recommendation system that provides more accurate and personalized recommendations across all customer segments.

Which of the following strategies is the MOST LIKELY to achieve this goal?

  1. A

    Use stacking, where the predictions from the collaborative filtering and content-based filtering models are fed into a deep learning model as inputs, allowing the deep learning model to make the final recommendation
  2. B

    Implement a hybrid model that combines the predictions of collaborative filtering, content-based filtering, and deep learning using a weighted average, where weights are based on model performance for different customer segments
  3. C

    Apply boosting by sequentially training the collaborative filtering, content-based filtering, and deep learning models, where each model corrects the errors of the previous one
  4. D

    Use a bagging approach to train multiple instances of the deep learning model on different subsets of the data and average their predictions to improve overall performance
Xem giải thích

Đáp án

B — Triển khai hybrid model kết hợp dự đoán của collaborative filtering, content-based filtering và deep learning bằng trung bình có trọng số, trong đó trọng số dựa trên hiệu năng của từng model cho từng phân khúc khách hàng.

Vì sao đúng

Đề mô tả một quan sát quan trọng: mỗi model xuất sắc ở một tình huống khác nhau: | Model | Mạnh ở | |---|---| | Collaborative filtering | khách hàng cũ có nhiều dữ liệu tương tác | | Content-based filtering | khách hàng MỚI, ít lịch sử — giải quyết cold start | | Deep learning | mẫu phức tạp |

Và mục tiêu là gợi ý tốt cho MỌI phân khúc khách hàng.

Trọng số theo phân khúc là cách trực tiếp diễn đạt quan sát đó:

Khách hàng MỚI (chưa có lịch sử):
  content-based    0,7
  collaborative    0,1   ← không có dữ liệu để dùng
  deep learning    0,2

Khách hàng CŨ (nhiều tương tác):
  content-based    0,2
  collaborative    0,5   ← phát huy tối đa
  deep learning    0,3

Đây là mẫu hybrid recommender kinh điển, và nó giải quyết được cold start problem — vấn đề khó nhất của hệ thống gợi ý: khách hàng mới không có lịch sử để collaborative filtering hoạt động, nhưng content-based vẫn gợi ý được dựa trên thuộc tính sản phẩm.

Và trọng số có thể học từ dữ liệu: đo hiệu năng của từng model trên từng phân khúc, rồi đặt trọng số tỷ lệ thuận.

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

  • A. Dùng stacking, đưa dự đoán của collaborative và content-based làm đầu vào cho model deep learning để nó ra quyết định cuối — đây là phương án gần nhất và hoàn toàn hợp lệ về mặt kỹ thuật. Nó thua ở hai điểm: model deep learning đang là một trong ba model cơ sở, nên dùng chính nó làm meta-model là lẫn lộn vai trò; và stacking khó diễn giải hơn — bạn không kiểm soát được rõ ràng "với khách mới thì dựa vào content-based", điều mà trọng số theo phân khúc cho một cách tường minh.
  • C. Áp dụng boosting, huấn luyện tuần tự ba model, mỗi cái sửa lỗi của cái trước — mô tả sai boosting: boosting dùng cùng một loại weak learner lặp lại và huấn luyện từ đầu, không ghép ba loại model khác nhau đã có sẵn.
  • D. Dùng bagging, huấn luyện nhiều bản của model deep learning trên các tập con rồi lấy trung bình — bỏ mất hai model kia: nó chỉ dùng deep learning, nên không tận dụng được điểm mạnh của collaborative và content-based mà đề đã chỉ ra.

Ghi nhớ

Ba loại hệ thống gợi ý — và điểm mạnh yếu: | Loại | Dựa trên | Điểm yếu | |---|---|---| | Collaborative filtering | hành vi của người dùng tương tự | cold start với người dùng và sản phẩm MỚI | | Content-based | thuộc tính của sản phẩm | ít đa dạng — luôn gợi ý thứ tương tự | | Hybrid | kết hợp cả hai | khắc phục được cả hai điểm yếu |

Cold start là ba vấn đề khác nhau: | Loại | Vấn đề | Cách chữa | |---|---|---| | Người dùng mới | không có lịch sử | content-based, hoặc hỏi sở thích ban đầu | | Sản phẩm mới | chưa ai tương tác | content-based dựa trên thuộc tính | | Hệ thống mới | không có dữ liệu nào | luật nghiệp vụ, gợi ý phổ biến |

Ba cách kết hợp trong hybrid recommender: | Cách | Chi tiết | |---|---| | Weighted | trung bình có trọng số — đơn giản, diễn giải được ← câu này | | Switching | chọn MỘT model theo điều kiện | | Feature combination | đưa đầu ra của model này làm đặc trưng cho model kia |

Cách thứ hai đáng nhắc: với cold start rõ ràng (khách hoàn toàn mới), chuyển hẳn sang content-based đơn giản hơn và cho kết quả tương đương so với đặt trọng số 0,9.

Ba chỉ số đánh giá hệ thống gợi ý: | Chỉ số | Đo | |---|---| | Precision@K, Recall@K | trong K gợi ý đầu, bao nhiêu đúng | | NDCG | có tính tới THỨ TỰ — gợi ý đúng ở vị trí 1 giá trị hơn vị trí 10 | | Coverage, Diversity | gợi ý có đa dạng không hay chỉ lặp lại vài sản phẩm |

Dòng cuối quan trọng trong thực tế: một hệ thống chỉ gợi ý sản phẩm bán chạy sẽ có precision cao nhưng không tạo ra giá trị mới — người dùng vốn đã tìm thấy những sản phẩm đó. Đây cũng là lý do phải đo bằng A/B test trên chỉ số nghiệp vụ (xem #6516), không chỉ bằng chỉ số offline.

Và Amazon Personalize đáng nhắc: nó cung cấp sẵn các thuật toán hybrid và xử lý cold start — không nằm trong bốn phương án, nhưng trong thực tế thường là lựa chọn nhanh hơn tự xây.

Câu 82 ML Model Development

A telecommunications company collects data about customer interactions and stores it in an Amazon S3 bucket. The company uses Amazon Athena to query the data and identify patterns. The dataset includes a churn indicator as the target variable, and the company wants to assess whether an ML model can accurately predict customer churn.

Which solution will provide this information with the LEAST development effort?

  1. A

    Download the dataset locally, preprocess the data manually, and use a third-party AutoML library to train and evaluate models
  2. B

    Use Amazon SageMaker Autopilot to automatically analyze the dataset, generate candidate models, and evaluate their ability to predict customer churn
  3. C

    Use Amazon Bedrock with a pre-trained foundation model to directly analyze the dataset and predict churn without training a custom model
  4. D

    Leverage Amazon SageMaker Studio to build a custom workflow for preprocessing, feature engineering, training, and evaluation of predictive models
Xem giải thích

Đáp án

B — Dùng Amazon SageMaker Autopilot tự động phân tích tập dữ liệu, sinh các model ứng viên và đánh giá khả năng dự đoán khách hàng rời bỏ.

Vì sao đúng

Đề nêu mục tiêu và một ràng buộc chặt: | Yếu tố | Chi tiết | |---|---| | Mục tiêu | đánh giá xem ML có dự đoán được rời bỏ không | | Dữ liệu | có sẵn trên S3, đã có cột nhãn (churn indicator) | | Ràng buộc | ít công sức phát triển nhất |

SageMaker Autopilot làm toàn bộ quy trình tự động:

Chỉ cần: đường dẫn S3 + tên cột mục tiêu
    ↓ Autopilot tự làm:
    ├─ phân tích dữ liệu, suy ra kiểu từng cột
    ├─ tiền xử lý: xử lý thiếu, mã hoá, chuẩn hoá
    ├─ chọn thuật toán phù hợp (XGBoost, Linear Learner, MLP)
    ├─ tinh chỉnh siêu tham số
    └─ xếp hạng các model ứng viên theo chỉ số

automl = AutoML(role=role, target_attribute_name='churn',
                problem_type='BinaryClassification',
                job_objective={'MetricName': 'F1'})
automl.fit(inputs='s3://kho/du-lieu-khach-hang/')

Và Autopilot phù hợp đặc biệt cho mục đích "đánh giá tính khả thi" — điều mà đề đang hỏi: | Đầu ra | Giá trị | |---|---| | Chỉ số của model tốt nhất | ML có khả thi không | | Bảng xếp hạng nhiều model | biết loại thuật toán nào hợp | | Notebook giải thích được sinh ra | thấy Autopilot đã làm gì, dùng làm điểm khởi đầu | | Feature importance | biết đặc trưng nào quan trọng |

Dòng thứ ba đáng chú ý: Autopilot sinh ra notebook chứa toàn bộ mã nó dùng — nên nó không phải hộp đen, và bạn dùng được kết quả để phát triển tiếp.

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

  • D. Dùng SageMaker Studio xây quy trình TUỲ CHỈNH cho tiền xử lý, feature engineering, huấn luyện và đánh giá — đây là phương án gần nhất và cho kết quả tốt nhất về lâu dài, nhưng nó tốn công nhất — trái thẳng ràng buộc "LEAST development effort". Với mục đích đánh giá khả thi, chạy Autopilot trước rồi mới đầu tư công sức là thứ tự đúng.
  • A. Tải dữ liệu về máy, tiền xử lý thủ công, dùng thư viện AutoML của bên thứ ba — tốn công hơn và có rủi ro: tải dữ liệu khách hàng viễn thông về máy cá nhân là vấn đề bảo mật, và bạn mất mọi tích hợp với hạ tầng AWS.
  • C. Dùng Bedrock với foundation model phân tích trực tiếp tập dữ liệu và dự đoán rời bỏ mà không huấn luyện model riêng — sai công cụ cho loại dữ liệu: foundation model mạnh về văn bản và ảnh, không phải về dữ liệu bảng có cấu trúc. Với dữ liệu bảng, model ML truyền thống (đặc biệt là gradient boosting) chính xác hơn nhiều, rẻ hơn nhiều, và cho feature importance mà LLM không cho.

Ghi nhớ

SageMaker Autopilot — bốn việc nó tự làm: | Việc | Chi tiết | |---|---| | Phân tích dữ liệu | suy ra kiểu cột, phát hiện vấn đề | | Feature engineering tự động | mã hoá, chuẩn hoá, xử lý thiếu | | Chọn thuật toán và tinh chỉnh | thử nhiều pipeline, xếp hạng | | Sinh notebook giải thích | minh bạch, dùng lại được |

Ba loại bài toán Autopilot hỗ trợ: | Loại | Ví dụ | |---|---| | Phân loại nhị phân | dự đoán rời bỏ ← câu này | | Phân loại nhiều lớp | phân loại sản phẩm | | Hồi quy | dự đoán giá |

Khi nào dùng AutoML, khi nào tự xây: | Tình huống | Chọn | |---|---| | Đánh giá tính khả thi nhanh | AutoML | | Tạo đường cơ sở để so sánh | AutoML | | Dữ liệu bảng chuẩn, không có đặc thù | AutoML thường đủ | | Cần kiến thức lĩnh vực sâu trong feature engineering | tự xây | | Yêu cầu kiến trúc model đặc biệt | tự xây |

Mẫu làm việc khuyến nghị: chạy Autopilot trước làm đường cơ sở, rồi tự xây và so với đường cơ sở đó. Nếu công sức tự xây không vượt được AutoML, đó là thông tin có giá trị — và không hiếm khi xảy ra với dữ liệu bảng.

Ba công cụ AutoML trên AWS: | Công cụ | Đối tượng | |---|---| | SageMaker Autopilot | nhà khoa học dữ liệu — có API và notebook | | SageMaker Canvas | nhà phân tích nghiệp vụ — hoàn toàn trực quan | | Amazon Forecast, Personalize | chuyên biệt theo bài toán |

Và một lưu ý cho bài toán rời bỏ nói riêng: dữ liệu thường mất cân bằng (ít khách rời bỏ), nên đặt job_objective là F1 hoặc AUC, không để mặc định accuracy. Autopilot cho phép khai điều này, và nó thay đổi hẳn model nào được chọn là tốt nhất.

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

You are a machine learning engineer responsible for optimizing the cost and performance of an ML model deployed on Amazon SageMaker. The model serves real-time predictions for an e-commerce platform, and the current instance type is providing reliable performance but at a higher cost than anticipated. Your goal is to determine the most cost-effective instance type that still meets the performance requirements for low-latency predictions.

Which approach is the MOST EFFECTIVE for rightsizing the instance family and size for your SageMaker endpoint?

  1. A

    Use SageMaker Inference Recommender to select the lowest-cost instance type, regardless of performance, and configure autoscaling to handle any additional load during peak times
  2. B

    Use SageMaker Inference Recommender to run load tests across various instance types and configurations, compare the performance and cost of each, and select the instance type that offers the best balance between cost and performance
  3. C

    Manually review the performance metrics from Amazon CloudWatch for the current instance and experiment with different instance types by redeploying the model on each until you find the optimal one
  4. D

    Use AWS Compute Optimizer to analyze the current instance’s CPU and memory usage, and automatically switch to the smallest recommended instance type that matches the utilization metrics
Xem giải thích

Đáp án

B — Dùng SageMaker Inference Recommender chạy load test trên nhiều loại instance và cấu hình, so sánh hiệu năng và chi phí của từng cái, rồi chọn loại cho cân bằng tốt nhất giữa chi phí và hiệu năng.

Vì sao đúng

Đề nêu bài toán rất cụ thể: instance hiện tại chạy tốt nhưng đắt hơn dự kiến, và mục tiêu là tìm loại rẻ hơn mà vẫn đạt yêu cầu độ trễ thấp.

Inference Recommender được xây riêng cho việc này:

Bạn cung cấp: model + yêu cầu hiệu năng (độ trễ tối đa, thông lượng tối thiểu)
    ↓
Inference Recommender TỰ ĐỘNG:
    ├─ triển khai model lên nhiều loại instance khác nhau
    ├─ chạy load test thật trên mỗi cái
    ├─ đo độ trễ p50/p90/p99, thông lượng, chi phí mỗi suy luận
    └─ xếp hạng theo tiêu chí bạn đặt

sm.create_inference_recommendations_job(
    JobName='toi-uu-endpoint-goi-y',
    JobType='Advanced',
    InputConfig={
        'ModelPackageVersionArn': arn_model,
        'JobDurationInSeconds': 7200,
        'ResourceLimit': {'MaxNumberOfTests': 10},
        'EndpointConfigurations': [
            {'InstanceType': 'ml.c5.xlarge'},
            {'InstanceType': 'ml.m5.xlarge'},
            {'InstanceType': 'ml.g4dn.xlarge'}]},
    StoppingConditions={
        'MaxInvocations': 1000,
        'ModelLatencyThresholds': [{'Percentile': 'P95', 'ValueInMilliseconds': 100}]})

Hai chi tiết đáng chú ý: ModelLatencyThresholds đảm bảo không chọn instance vi phạm yêu cầu độ trễ, và kết quả kèm chi phí mỗi suy luận — nên so sánh là so sánh trực tiếp thứ bạn quan tâm.

Điểm mạnh so với thử thủ công: nó đo bằng LOAD TEST THẬT trên chính model của bạn, chứ không suy đoán từ thông số kỹ thuật.

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

  • A. Dùng Inference Recommender chọn loại instance RẺ NHẤT bất kể hiệu năng, và cấu hình autoscaling để xử lý tải thêm lúc cao điểm — đây là phương án gần nhất và dùng đúng công cụ nhưng sai tiêu chí: cụm "regardless of performance" trái thẳng yêu cầu "still meets the performance requirements for low-latency predictions". Và autoscaling không sửa được độ trễ của một lần suy luận — nó thêm instance, không làm mỗi instance nhanh hơn.
  • C. Xem thủ công chỉ số CloudWatch của instance hiện tại và thử từng loại instance bằng cách triển khai lại cho tới khi tìm được cái tối ưu — tốn thời gian và không có hệ thống: mỗi lần thử là một lần triển khai, và bạn cần load test nhất quán để so sánh công bằng — chính là thứ Inference Recommender tự động hoá.
  • D. Dùng AWS Compute Optimizer phân tích mức dùng CPU và bộ nhớ, tự chuyển sang loại instance nhỏ nhất khớp với mức sử dụng — Compute Optimizer không hỗ trợ SageMaker endpoint (nó phân tích EC2, EBS, Lambda, ECS Fargate). Và CPU/bộ nhớ không phải chỉ báo đủ cho suy luận ML — độ trễ mới là thứ quan trọng, và nó phụ thuộc vào kiến trúc model chứ không chỉ vào mức dùng tài nguyên.

Ghi nhớ

SageMaker Inference Recommender — hai loại job: | Loại | Đặc điểm | |---|---| | Default | quét nhanh, gợi ý loại instance dựa trên model | | Advanced | load test đầy đủ với lưu lượng bạn khai, có ngưỡng độ trễ |

Bốn thứ nó trả về cho mỗi cấu hình: | Chỉ số | Ý nghĩa | |---|---| | ModelLatency (p50, p90, p99) | độ trễ ở các phân vị | | MaxInvocations | thông lượng tối đa | | CostPerHour, CostPerInference | chi phí — so sánh trực tiếp | | CPU/Memory utilization | mức dùng tài nguyên |

Dòng thứ ba là thứ khiến công cụ này hữu ích: chi phí mỗi suy luận kết hợp cả giá instance lẫn thông lượng — một instance đắt hơn nhưng nhanh gấp ba có thể rẻ hơn tính trên mỗi request.

Ba yếu tố ảnh hưởng lựa chọn instance cho suy luận: | Yếu tố | Chi tiết | |---|---| | Model có cần GPU không? | model nhỏ chạy CPU thường rẻ hơn nhiều | | Kích thước model so với bộ nhớ | phải vừa, có biên an toàn | | Mẫu lưu lượng | ổn định → instance lớn hơn ít hơn; thất thường → nhỏ hơn nhiều hơn |

Dòng đầu là nguồn tiết kiệm lớn nhất thường bị bỏ qua: rất nhiều model không cần GPU khi suy luận, dù đã huấn luyện trên GPU. Với model gợi ý dạng bảng, instance CPU (ml.c5, ml.m5) thường đủ và rẻ hơn nhiều lần.

Bốn cách khác giảm chi phí suy luận: | Cách | Chi tiết | |---|---| | Rightsizing instance | ← câu này | | Auto scaling với MinCapacity thấp | không trả tiền cho instance nhàn rỗi | | Multi-model endpoint | nhiều model chia sẻ instance | | Nén model (quantization, pruning) | model nhỏ hơn chạy được trên instance rẻ hơn |

Cách cuối nối với #6508: giảm kích thước model không chỉ giúp triển khai lên thiết bị biên, nó còn hạ được cấp instance cần dùng trên đám mây.

Và một lưu ý về quy trình: chạy Inference Recommender lại sau mỗi lần model thay đổi đáng kể. Kiến trúc mới có đặc tính hiệu năng khác, và loại instance tối ưu cho phiên bản trước chưa chắc còn tối ưu.

Câu 84 Deployment and Orchestration of ML Workflows

You are a data scientist at a financial services company tasked with deploying a lightweight machine learning model that predicts creditworthiness based on a customer’s transaction history. The model needs to provide real-time predictions with minimal latency, and the traffic pattern is unpredictable, with occasional spikes during business hours. The company is cost-conscious and prefers a serverless architecture to minimize infrastructure management overhead.

Which approach is the MOST SUITABLE for deploying this solution, and why?

  1. A

    Use an Amazon EC2 instance to host the model, with AWS Lambda functions handling the communication between the API Gateway and the EC2 instance for prediction requests
  2. B

    Deploy the model using Amazon ECS (Elastic Container Service) and configure an AWS Lambda to trigger the ECS service on-demand, ensuring that the model is only running during peak traffic periods
  3. C

    Deploy the model directly within AWS Lambda as a function, and expose it through an API Gateway endpoint, allowing the function to scale automatically with traffic and provide real-time predictions
  4. D

    Deploy the model as a SageMaker endpoint for real-time inference, and configure AWS Lambda to preprocess incoming requests before sending them to the SageMaker endpoint for prediction
Xem giải thích

Đáp án

C — Triển khai model trực tiếp trong AWS Lambda dưới dạng một hàm, phơi qua API Gateway endpoint, để hàm tự co giãn theo lưu lượng và cho dự đoán thời gian thực.

Vì sao đúng

Đề nêu bốn yếu tố, và cả bốn đều chỉ về Lambda: | Yếu tố | Lambda | |---|---| | Model NHẸ (lightweight) | vừa giới hạn kích thước gói | | Lưu lượng khó đoán, có đỉnh | co giãn tự động, tức thì | | Ưu tiên serverless, ít quản lý hạ tầng | không có instance nào phải quản | | Tiết kiệm chi phí | trả theo lần gọi — 0 request = 0 tiền |

Từ khoá quyết định là "lightweight". Đây là điều kiện làm cho Lambda khả thi:

Giới hạn Lambda:
  Gói ZIP giải nén:  250 MB
  Container image:    10 GB
  Bộ nhớ:             tới 10 GB
  Thời gian:          15 phút
  GPU:                KHÔNG có

Một model dự đoán tín nhiệm từ lịch sử giao dịch — thường là gradient boosting hoặc hồi quy — dễ dàng vừa trong vài chục MB.

Và mô hình tính tiền khớp với lưu lượng khó đoán:

SageMaker endpoint:  trả tiền 24/7 kể cả 0 request
Lambda:              trả theo số lần gọi và thời gian chạy
                     → giờ thấp điểm gần như không tốn gì

Với công ty cost-conscious và lưu lượng unpredictable, khác biệt này rất lớn.

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

  • D. Triển khai model làm SageMaker endpoint cho suy luận thời gian thực, dùng Lambda tiền xử lý request trước khi gửi tới endpoint — đây là phương án gần nhất và hoạt động tốt về mặt kỹ thuật, nhưng nó không phải serverless: SageMaker endpoint là instance chạy liên tục, tính tiền 24/7. Trái hai yêu cầu "serverless architecture" và "cost-conscious". (Với model lớn hoặc lưu lượng đều, D sẽ là lựa chọn đúng.)
  • B. Triển khai bằng ECS và cấu hình Lambda kích hoạt ECS service theo yêu cầu, chỉ chạy model trong giờ cao điểm — phức tạp và có cold start rất lớn: khởi động một ECS task mất hàng chục giây tới vài phút. Với dự đoán thời gian thực, người dùng đầu tiên sau mỗi lần khởi động sẽ chờ rất lâu.
  • A. Host model trên EC2 instance, Lambda làm cầu nối giữa API Gateway và EC2 — hoàn toàn không serverless: EC2 phải quản lý (vá lỗi, AMI, auto scaling) và chạy liên tục. Lambda ở giữa chỉ thêm một chặng mà không giải quyết gì.

Ghi nhớ

Ba lựa chọn triển khai serverless cho model ML: | Lựa chọn | Điều kiện | Cold start | |---|---|---| | AWS Lambda | model nhỏ (< 250 MB zip / 10 GB image), không GPU | có, vài trăm ms tới vài giây | | SageMaker Serverless Inference | model tới 6 GB RAM, không GPU | có | | SageMaker Real-time + auto scaling | mọi model, có GPU | không (min ≥ 1 instance) |

Phân biệt hai lựa chọn đầu: | | Lambda | SageMaker Serverless | |---|---|---| | Đóng gói | tự viết handler | container suy luận chuẩn SageMaker | | Tích hợp Model Registry | ❌ | ✅ | | Data capture, Model Monitor | ❌ | ✅ | | Chi phí | rẻ nhất với model nhỏ | rẻ, hơi cao hơn |

Nguyên tắc: nếu cần các tính năng vận hành ML (giám sát, đăng ký phiên bản) thì dùng SageMaker Serverless; nếu chỉ cần chạy một hàm dự đoán đơn giản thì Lambda gọn hơn.

Ba cách giảm cold start của Lambda cho model ML: | Cách | Chi tiết | |---|---| | Provisioned Concurrency | giữ sẵn N phiên bản ấm — có phí | | Nạp model ở phạm vi module | model nạp một lần, dùng lại cho các lần gọi tiếp theo | | Giảm kích thước gói | ít thư viện, dùng Lambda layer |

Cách thứ hai là mẫu quan trọng nhất và hay bị làm sai:

model = joblib.load('/opt/model.pkl')     # ← NGOÀI handler, chạy 1 lần

def lambda_handler(event, context):
    return {'prediction': model.predict(...)}   # dùng lại model đã nạp

Đặt lời gọi nạp model bên trong handler nghĩa là nạp lại ở mỗi request — biến một dự đoán 5 mili giây thành 500 mili giây.

Câu 85 Deployment and Orchestration of ML Workflows

You are a data scientist at a healthcare company working on deploying a machine learning model that predicts patient outcomes based on real-time data from wearable devices. The model needs to be containerized for easy deployment and scaling across different environments, including development, testing, and production. The company wants to ensure that container images are managed efficiently, securely, and consistently across all environments.

Given these requirements, which combination of AWS services is the MOST SUITABLE for building, storing, deploying, and maintaining the containerized ML solution?

  1. A

    Use Amazon ECS to manage and deploy the containerized model, Amazon S3 to store container images, and manually push updates to the containers using the AWS CLI
  2. B

    Use Amazon ECR to store the container images, Amazon EKS for orchestrating the containers, and AWS CodePipeline for automating the CI/CD pipeline, ensuring that updates to the model are seamlessly deployed
  3. C

    Use Amazon ECR to store container images, manually deploy containers on Amazon EC2 instances, and use AWS CloudFormation to manage the infrastructure configuration
  4. D

    Use Docker Hub to store the container images, Amazon EKS for orchestrating the containers, and AWS Lambda to trigger updates to the containers when new images are pushed
Xem giải thích

Đáp án

B — Dùng Amazon ECR lưu container image, Amazon EKS điều phối container, và AWS CodePipeline tự động hoá CI/CD để cập nhật model được triển khai liền mạch.

Vì sao đúng

Đề nêu bốn yêu cầu, và B là đáp án duy nhất phủ hết: | Yêu cầu | Cơ chế | |---|---| | Đóng gói container để triển khai và co giãn | EKS | | Quản lý image hiệu quả và AN TOÀN | ECR — quét lỗ hổng, IAM, mã hoá | | Nhất quán giữa dev, test, production | cùng một image, khác cấu hình | | Tự động hoá cập nhật | CodePipeline |

Vì sao ECR chứ không phải Docker Hub hay S3 — ba lý do cụ thể: | Lý do | Chi tiết | |---|---| | Bảo mật | IAM kiểm soát truy cập, mã hoá at-rest bằng KMS | | Quét lỗ hổng | tự động quét image tìm CVE — quan trọng với y tế | | Tích hợp gốc | ECS, EKS, Lambda, SageMaker đều kéo từ ECR bằng IAM role |

CodePipeline cho vế "consistently across all environments":

Commit mã → CodeBuild dựng image → đẩy lên ECR (một tag duy nhất)
    ↓ triển khai vào dev      ─┐
    ↓ triển khai vào test     ─┼─ CÙNG MỘT IMAGE
    ↓ triển khai vào prod     ─┘

Đây là nguyên tắc build once, deploy everywhere: thứ bạn kiểm thử ở test chính xác là thứ chạy ở production.

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

  • C. Dùng ECR lưu image, triển khai THỦ CÔNG lên EC2, và CloudFormation quản lý cấu hình hạ tầng — đây là phương án gần nhất (ECR đúng, IaC đúng) nhưng "manually deploy" trái yêu cầu tự động hoá và nhất quán. Và quản lý container trực tiếp trên EC2 tốn công hơn EKS nhiều.
  • D. Dùng Docker Hub lưu image, EKS điều phối, Lambda kích hoạt cập nhật khi có image mới — Docker Hub không đáp ứng yêu cầu bảo mật: không có IAM, không quét lỗ hổng tích hợp, và với dữ liệu y tế thì việc đặt image ở registry công cộng là vấn đề tuân thủ.
  • A. Dùng ECS triển khai, S3 lưu container image, đẩy cập nhật thủ công bằng AWS CLI — S3 không phải container registry: nó lưu được tệp tar của image nhưng không có phiên bản theo tag, không có quét lỗ hổng, và ECS/EKS không kéo image từ S3 được.

Ghi nhớ

Nơi lưu từng loại artifact — bảng nên thuộc: | Loại | Nơi đúng | |---|---| | Container image | ECR | | Artifact model (trọng số) | S3 | | Mã nguồn | Git (CodeCommit, GitHub) | | Metadata model | SageMaker Model Registry |

Ba lựa chọn điều phối container trên AWS: | Lựa chọn | Đặc điểm | |---|---| | ECS | đơn giản hơn, tích hợp sâu AWS | | EKS | Kubernetes chuẩn — di động, hệ sinh thái lớn | | Fargate | serverless cho cả ECS lẫn EKS — không quản lý node |

Với ML, EKS có lợi thế riêng: hệ sinh thái Kubernetes có nhiều công cụ ML (Kubeflow, KServe), và SageMaker Operators for Kubernetes cho phép điều khiển SageMaker từ trong cụm.

Ba tính năng bảo mật của ECR cho môi trường y tế: | Tính năng | Chi tiết | |---|---| | Image scanning | quét CVE tự động khi đẩy lên, hoặc quét liên tục | | Immutable tags | chặn ghi đè tag — đảm bảo v1.2.3 luôn là cùng một image | | Lifecycle policy | tự xoá image cũ, giảm chi phí |

Dòng giữa đáng bật cho môi trường chịu quản lý: không có nó, một image production có thể bị thay đổi âm thầm, và hồ sơ kiểm toán mất ý nghĩa.

Và một nguyên tắc về nhất quán giữa các môi trường:

Khác biệt giữa dev, test và prod phải nằm trong CẤU HÌNH, không nằm trong IMAGE.

Dựng ba image khác nhau cho ba môi trường là cách chắc chắn để có ba hành vi khác nhau — và bug chỉ xuất hiện ở production.

Câu 86 Deployment and Orchestration of ML Workflows

A financial services company deployed a machine learning model using Amazon SageMaker Asynchronous Inference in the past with successful performance. Now, the company needs to deploy a new ML model that detects fraudulent credit card transactions in real-time within their banking application. However, when using SageMaker Asynchronous Inference for this new model, the performance is poor and does not meet the real-time requirements. Additionally, the company wants to receive notifications whenever there is a deviation in the model's quality.

As an AWS Certified Machine Learning Engineer Associate, what do you recommend?

  1. A

    Retain SageMaker Asynchronous Inference and enable autoscaling for the endpoint to improve performance, while using Amazon SQS for notifications
  2. B

    Use SageMaker Batch Transform for inference and set up a monitoring system with SageMaker Model Monitor to send notifications for quality deviations
  3. C

    Increase the instance size and response timeout settings for SageMaker Asynchronous Inference and use Amazon SNS for quality deviation notifications
  4. D

    Switch to SageMaker Real-Time Inference for the deployment and use SageMaker Model Monitor for model quality deviations
Xem giải thích

Đáp án

D — Chuyển sang SageMaker Real-Time Inference cho việc triển khai, và dùng SageMaker Model Monitor để phát hiện sai lệch chất lượng model.

Vì sao đúng

Đề nêu hai vấn đề, và mỗi cái cần một cơ chế riêng: | Vấn đề | Giải pháp | |---|---| | Asynchronous Inference không đạt yêu cầu THỜI GIAN THỰC | chuyển sang Real-Time Inference | | Cần thông báo khi chất lượng model sai lệch | Model Monitor |

Vì sao Asynchronous không phù hợp cho phát hiện gian lận thời gian thực:

Asynchronous Inference:
  Request → xếp hàng → xử lý → ghi kết quả ra S3 → thông báo
  Độ trễ: giây tới phút

Phát hiện gian lận thẻ tín dụng:
  Cần quyết định TRONG khi giao dịch đang diễn ra
  Độ trễ chấp nhận được: vài chục mili giây

Đây không phải vấn đề cấu hình — nó là sai kiểu triển khai cho loại workload.

Và đề đã cài một manh mối quan trọng: công ty đã dùng Async thành công trước đây cho một model khác. Điều đó cho thấy Async không "hỏng" — nó chỉ được dùng cho một loại workload khác. Đây là lỗi phổ biến: dùng lại kiến trúc đã thành công cho một bài toán có yêu cầu hoàn toàn khác.

Model Monitor cho vế thứ hai:

model_quality_monitor.create_monitoring_schedule(
    endpoint_input=endpoint_name,
    ground_truth_input='s3://.../nhan-thuc-te/',
    problem_type='BinaryClassification',
    schedule_cron_expression=CronExpressionGenerator.hourly())

Vi phạm ngưỡng phát ra sự kiện, và CloudWatch alarm cộng SNS gửi thông báo.

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

  • C. Tăng kích thước instance và cài đặt timeout cho Asynchronous Inference, dùng SNS cho thông báo — đây là phương án gần nhất và sai ở nguyên nhân gốc: độ trễ của Async không đến từ instance nhỏ, nó đến từ CƠ CHẾ HÀNG ĐỢI. Instance to hơn xử lý nhanh hơn một chút, nhưng vẫn phải qua hàng đợi và ghi kết quả ra S3. (SNS cho thông báo thì đúng, nhưng SNS chỉ là kênh gửi — bạn vẫn cần Model Monitor để phát hiện.)
  • A. Giữ Asynchronous và bật autoscaling để cải thiện hiệu năng, dùng SQS cho thông báo — cùng lỗi: autoscaling tăng thông lượng, không giảm độ trễ của cơ chế bất đồng bộ. Và SQS là hàng đợi, không phải dịch vụ thông báo — nó không "gửi" cho ai cả.
  • B. Dùng Batch Transform cho suy luận và Model Monitor cho thông báo — còn xa thời gian thực hơn Async: batch transform chạy theo job trên một tệp dữ liệu, không phục vụ request đến bất kỳ lúc nào.

Ghi nhớ

Bốn kiểu suy luận của SageMaker — chọn theo yêu cầu độ trễ: | Kiểu | Độ trễ | Dùng khi | |---|---|---| | Real-time | mili giây | giao dịch đang chờ quyết định ← câu này | | Serverless | có cold start | lưu lượng thưa | | Asynchronous | giây tới giờ | payload lớn, xử lý lâu, có hàng đợi | | Batch transform | theo job | xử lý cả tệp, offline |

Bốn loại giám sát của Model Monitor: | Loại | Phát hiện | Cần nhãn thật? | |---|---|---| | 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 đổi | ❌ |

Đề hỏi về "deviation in the model's quality", tức là loại thứ hai — nhưng nó cần nhãn thật, mà với gian lận thẻ tín dụng nhãn đến rất muộn (chờ khách khiếu nại).

Cách xử lý thực tế: dùng data quality và prediction drift làm chỉ báo sớm, và model quality monitoring chạy chậm hơn khi nhãn về. Nếu tỷ lệ giao dịch bị gắn cờ đột ngột thay đổi mà không có lý do nghiệp vụ, đó thường là dấu hiệu sớm nhất.

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

Và bài học tổng quát từ câu này:

Kiến trúc thành công cho một workload không tự động phù hợp với workload khác. Luôn bắt đầu từ yêu cầu độ trễ và hình dạng lưu lượng, không từ thứ đã dùng lần trước.

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

You are a DevOps engineer responsible for maintaining a serverless machine learning application that provides real-time predictions using AWS Lambda. Recently, users have reported increased latency when interacting with the application, especially during peak usage hours. You need to quickly identify the root cause of the latency and resolve the performance issues to ensure the application remains responsive.

Which combination of monitoring and observability tools is the MOST EFFECTIVE for troubleshooting the latency and performance issues in this serverless application?

  1. A

    Use Amazon CloudWatch Alarms to set thresholds for Lambda duration and error rates, and configure AWS X-Ray to periodically sample traces from the application for analysis
  2. B

    Enable detailed monitoring in Amazon CloudWatch to track Lambda invocations, errors, and throttles, and manually inspect the Lambda code to identify performance bottlenecks
  3. C

    Deploy Amazon CloudWatch Logs Insights to query and analyze the application logs for errors, and use AWS Config to review recent changes to the infrastructure that might have introduced latency
  4. D

    Use AWS X-Ray to trace requests across the entire application, identify bottlenecks, and visualize the end-to-end latency for each request. Combine this with Amazon CloudWatch Lambda Insights to monitor the Lambda function’s memory usage, CPU usage, and invocation times
Xem giải thích

Đáp án

D — Dùng AWS X-Ray theo dấu request qua toàn bộ ứng dụng, xác định nút thắt và trực quan hoá độ trễ đầu-cuối cho từng request; kết hợp với CloudWatch Lambda Insights để giám sát mức dùng bộ nhớ, CPU và thời gian gọi của hàm Lambda.

Vì sao đúng

Đề nêu yêu cầu tìm nguyên nhân gốc nhanh, và hai công cụ trong đáp án cho hai góc nhìn bổ sung nhau: | Công cụ | Trả lời | |---|---| | X-Ray | "request này chậm ở CHẶNG NÀO?" | | Lambda Insights | "hàm này thiếu TÀI NGUYÊN gì?" |

X-Ray cho bức tranh đầu-cuối — thứ mà log và metric riêng lẻ không cho:

Request đến API Gateway        12 ms
  ├─ Lambda cold start        480 ms   ← nút thắt!
  ├─ Truy vấn DynamoDB          8 ms
  ├─ Gọi SageMaker endpoint   145 ms
  └─ Xử lý và trả về            5 ms

Không có tracing, bạn chỉ thấy "Lambda duration = 650 ms" mà không biết 480 ms nằm ở đâu.

Lambda Insights bổ sung tầng tài nguyên — thứ mà metric CloudWatch mặc định không có: | Metric | Ý nghĩa | |---|---| | memory_utilization | cấp thiếu bộ nhớ ⇒ chậm; cấp thừa ⇒ tốn tiền | | cpu_total_time | Lambda phân bổ CPU theo tỷ lệ bộ nhớ | | init_duration | thời gian cold start — tách riêng |

Dòng giữa là điểm hay bị bỏ sót về Lambda:

Lambda cấp CPU tỷ lệ thuận với bộ nhớ khai báo. Tăng bộ nhớ từ 512 MB lên 1.024 MB tăng gấp đôi CPU — và với hàm nặng tính toán, nó có thể giảm cả thời gian lẫn chi phí (chạy nhanh gấp đôi với giá gấp đôi mỗi mili giây = hoà, nhưng thường nhanh hơn gấp đôi).

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

  • A. CloudWatch Alarm đặt ngưỡng cho duration và tỷ lệ lỗi, cấu hình X-Ray lấy mẫu ĐỊNH KỲ trace để phân tích — đây là phương án gần nhất và sai ở hai chỗ: alarm phát hiện có vấn đề nhưng không chẩn đoán nguyên nhân, và lấy mẫu mặc định của X-Ray (1 request/giây + 5%) thường bỏ sót đúng những request chậm mà bạn cần xem.
  • C. CloudWatch Logs Insights truy vấn log tìm lỗi, và AWS Config xem lại thay đổi hạ tầng gần đây — Config theo dõi thay đổi cấu hình, không đo hiệu năng. Và Logs Insights hữu ích nhưng log không có thông tin về thời gian từng chặng trừ khi bạn tự đo và ghi.
  • B. Bật detailed monitoring theo dõi số lần gọi, lỗi và throttle, rồi kiểm tra THỦ CÔNG mã Lambda tìm nút thắt — "manually inspect the code" không phải cách gỡ lỗi hiệu năng: nút thắt thường nằm ở lời gọi bên ngoài hoặc cold start, không nhìn ra được từ mã.

Ghi nhớ

Ba tầng quan sát cho ứng dụng serverless: | Tầng | Công cụ | Trả lời | |---|---|---| | Metric | CloudWatch | "có vấn đề không?" | | Trace | X-Ray | "chậm ở đâu?" | | Log | CloudWatch Logs Insights | "chuyện gì đã xảy ra?" |

Ba nguyên nhân độ trễ phổ biến nhất của Lambda: | Nguyên nhân | Cách nhận biết | Cách chữa | |---|---|---| | Cold start | init_duration cao | Provisioned Concurrency, giảm kích thước gói | | Thiếu bộ nhớ/CPU | memory_utilization gần 100% | tăng bộ nhớ | | Chờ dịch vụ bên ngoài | subsegment X-Ray dài | tối ưu truy vấn, dùng cache |

Hai khái niệm của X-Ray cần phân biệt: | | Annotation | Metadata | |---|---|---| | Lọc và tìm kiếm được | ✅ | ❌ | | Dùng cho | user_tier, model_version, nhóm kích thước | payload chi tiết |

Quy tắc: thứ bạn sẽ muốn LỌC theo phải là annotation.

Và về lấy mẫu — chi tiết quan trọng cho việc bắt vấn đề hiếm:

{"rules": [{
  "description": "Bắt 100% request chậm",
  "fixed_target": 1, "rate": 0.05,
  "http_method": "*", "url_path": "*"}]}

Lấy mẫu mặc định tối ưu cho chi phí, không tối ưu cho bắt ca hiếm. Với vấn đề chỉ xảy ra lúc cao điểm, tăng tỷ lệ lấy mẫu tạm thời trong lúc điều tra.

Câu 88 ML Model Development

A travel agency has collected a large volume of customer feedback recordings from calls made to its customer support team after launching a new vacation package. The agency wants to evaluate the success of the vacation package by analyzing the sentiment of customer feedback. The ML engineer needs to process and analyze the recordings to identify positive and negative sentiments in the least amount of time.

Which action should the ML engineer take?

  1. A

    Build a custom sentiment analysis model using Amazon SageMaker and train it with labeled customer feedback data
  2. B

    Use AWS Glue to preprocess the feedback recordings and implement a sentiment analysis solution using open-source libraries
  3. C

    Use Amazon Transcribe to convert the customer feedback recordings into text, and then use Amazon Comprehend to analyze the text for sentiment
  4. D

    Manually transcribe the recordings, convert them to English using Amazon Translate, and run a custom script to analyze sentiment
Xem giải thích

Đáp án

C — Dùng Amazon Transcribe chuyển bản ghi âm phản hồi thành văn bản, rồi dùng Amazon Comprehend phân tích cảm xúc của văn bản đó.

Vì sao đúng

Đề nêu bài toán và một ràng buộc quyết định: "in the least amount of time".

Hai bước, hai dịch vụ được quản lý, không huấn luyện gì:

Bản ghi âm cuộc gọi
    ↓ Amazon Transcribe (speech-to-text)
Văn bản
    ↓ Amazon Comprehend (sentiment analysis)
Tích cực / Tiêu cực / Trung tính / Lẫn lộn

transcribe.start_transcription_job(
    TranscriptionJobName='phan-hoi-khach-hang',
    Media={'MediaFileUri': 's3://kho/ghi-am/'},
    LanguageCode='vi-VN')

comprehend.batch_detect_sentiment(
    TextList=danh_sach_van_ban, LanguageCode='vi')

Vì sao đây là cách nhanh nhất: | Yếu tố | Chi tiết | |---|---| | Không cần dữ liệu gán nhãn | Comprehend đã được huấn luyện sẵn | | Không cần huấn luyện | gọi API là xong | | Không cần hạ tầng | cả hai đều serverless | | Xử lý theo lô được | start_transcription_job chạy hàng loạt |

Và Comprehend trả về bốn nhãn cảm xúc kèm điểm tin cậy, đủ cho mục đích "đánh giá thành công của gói du lịch".

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

  • A. Xây model phân tích cảm xúc TUỲ CHỈNH trên SageMaker và huấn luyện với dữ liệu phản hồi đã gán nhãn — đây là phương án gần nhất về mặt "làm được", nhưng tốn thời gian nhất: phải gán nhãn dữ liệu, huấn luyện, đánh giá, triển khai. (Model tuỳ chỉnh chỉ đáng làm khi lĩnh vực có từ ngữ đặc thù mà model chung hiểu sai — và ngay cả khi đó, Comprehend custom classification cũng nhanh hơn tự xây trên SageMaker.)
  • B. Dùng AWS Glue tiền xử lý bản ghi âm và cài đặt phân tích cảm xúc bằng thư viện mã nguồn mở — Glue không xử lý được âm thanh (nó là công cụ ETL cho dữ liệu có cấu trúc), và tự dựng bằng thư viện mã nguồn mở là tự lo hạ tầng và độ chính xác.
  • D. Chép tay bản ghi âm, dùng Amazon Translate chuyển sang tiếng Anh, chạy script tuỳ chỉnh phân tích cảm xúc — "manually transcribe" là điểm loại: với khối lượng lớn bản ghi âm, chép tay là không khả thi. (Và bước dịch sang tiếng Anh là thừa — Comprehend hỗ trợ nhiều ngôn ngữ trực tiếp.)

Ghi nhớ

Các dịch vụ AI có sẵn của AWS — nhóm hay hỏi: | Dịch vụ | Việc | |---|---| | Transcribe | giọng nói → văn bản | | Polly | văn bản → giọng nói | | Comprehend | NLP: cảm xúc, thực thể, PII, phân loại, cụm từ khoá | | Translate | dịch thuật | | Textract | trích xuất văn bản từ tài liệu và ảnh | | Rekognition | thị giác: vật thể, khuôn mặt, nội dung | | Lex | chatbot | | Kendra | tìm kiếm doanh nghiệp |

Mẫu ghép hai dịch vụ là một dạng câu hỏi rất phổ biến: | Bài toán | Chuỗi dịch vụ | |---|---| | Phân tích cảm xúc từ âm thanh | Transcribe → Comprehend ← câu này | | Phân tích tài liệu scan | Textract → Comprehend | | Phụ đề đa ngôn ngữ | Transcribe → Translate → Polly | | Kiểm duyệt video | Rekognition + Transcribe → Comprehend |

Bốn khả năng của Comprehend: | Khả năng | Trả về | |---|---| | Sentiment | POSITIVE, NEGATIVE, NEUTRAL, MIXED + điểm | | Entities | tên người, địa điểm, tổ chức, ngày tháng | | Key phrases | cụm từ quan trọng | | PII detection | thông tin cá nhân | | Custom classification | phân loại theo nhãn CỦA BẠN |

Dòng cuối đáng nhớ: nếu bốn nhãn cảm xúc mặc định không đủ (ví dụ cần phân loại theo "khiếu nại về giá / về dịch vụ / về lịch trình"), Comprehend custom classification cho phép huấn luyện phân loại riêng — vẫn nhanh hơn nhiều so với tự xây trên SageMaker.

Và một tính năng của Transcribe hữu ích cho phân tích cuộc gọi: speaker diarization (ShowSpeakerLabels) — tách lời của khách hàng khỏi lời của nhân viên hỗ trợ. Không có nó, cảm xúc của hai bên bị trộn lẫn và kết quả mất ý nghĩa.

Câu 89 Deployment and Orchestration of ML Workflows

You are an ML engineer working for a logistics company that uses machine learning models to optimize delivery routes, predict maintenance needs, and forecast demand. The company wants to deploy several models into production, each serving different business functions but running on the same infrastructure to minimize costs. These models differ in the frequency of updates. The company is considering whether to use a multi-model deployment approach or a multi-container deployment approach on Amazon SageMaker to manage these models efficiently.

Given these requirements, which deployment strategy is MOST SUITABLE for managing these diverse models?

  1. A

    Use a multi-model deployment on a single SageMaker endpoint to host all models together, allowing you to dynamically load and serve models as needed without needing separate endpoints
  2. B

    Deploy each model individually using separate SageMaker endpoints, ensuring each model has dedicated resources and can be scaled independently
  3. C

    Implement a multi-container deployment strategy on a single SageMaker endpoint, where each model runs in its own container, allowing you to manage resource allocation more precisely across models
  4. D

    Use a hybrid approach where frequently updated models are deployed using multi-model endpoints and more complex models are deployed using multi-container endpoints, balancing flexibility and resource management
Xem giải thích

Đáp án

A — Dùng multi-model deployment trên MỘT SageMaker endpoint để host mọi model cùng nhau, cho phép nạp và phục vụ model động theo nhu cầu mà không cần endpoint riêng.

Vì sao đúng

Đề nêu hai yếu tố quyết định: | Yếu tố | Hệ quả | |---|---| | Nhiều model chạy trên cùng hạ tầng để giảm chi phí | cần chia sẻ tài nguyên | | Các model KHÁC NHAU về tần suất cập nhật | cần cập nhật độc lập |

Multi-model endpoint (MME) giải quyết cả hai, và yếu tố thứ hai là điểm đáng chú ý nhất:

MME nạp model từ S3 theo nhu cầu:
  s3://kho-model/toi-uu-tuyen-duong.tar.gz
  s3://kho-model/du-doan-bao-tri.tar.gz
  s3://kho-model/du-bao-nhu-cau.tar.gz

Cập nhật một model = TẢI TỆP MỚI LÊN S3
  → KHÔNG triển khai lại endpoint
  → KHÔNG ảnh hưởng hai model kia

Đây là điểm mạnh riêng của MME mà multi-container không có: thêm, sửa, xoá model chỉ là thao tác trên S3.

Và cơ chế chia sẻ tài nguyên khớp với mô hình sử dụng:

Model dùng nhiều  → luôn nằm trong bộ nhớ
Model dùng ít     → bị loại bỏ (evict) khi cần chỗ, nạp lại khi có request

Với ba model phục vụ ba chức năng nghiệp vụ khác nhau, tần suất gọi khác nhau — nên phần lớn thời gian chỉ một vài model cần nằm trong bộ nhớ.

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

  • C. Multi-container deployment trên một endpoint, mỗi model chạy trong container riêng, quản lý phân bổ tài nguyên chính xác hơn — đây là phương án gần nhất và là một tính năng thật, nhưng nó kém phù hợp ở đây: multi-container dành cho model dùng FRAMEWORK KHÁC NHAU (một TensorFlow, một PyTorch, một XGBoost), và cập nhật một container đòi triển khai lại endpoint. Đề nhấn mạnh khác biệt về tần suất cập nhật, không phải về framework.
  • B. Triển khai mỗi model trên endpoint RIÊNG, mỗi model có tài nguyên riêng và co giãn độc lập — trái yêu cầu "running on the same infrastructure to minimize costs": ba endpoint là ba lần chi phí instance.
  • D. Kết hợp: model cập nhật thường xuyên dùng MME, model phức tạp dùng multi-container — nghe hợp lý nhưng phức tạp không cần thiết: bạn phải vận hành hai kiểu endpoint, và đề không nêu yêu cầu nào buộc phải tách như vậy.

Ghi nhớ

Ba cơ chế chia sẻ tài nguyên trên SageMaker endpoint: | Cơ chế | Dùng khi | |---|---| | Multi-model endpoint (MME) | nhiều model CÙNG framework, tần suất dùng khác nhau | | Multi-container endpoint | model dùng FRAMEWORK KHÁC NHAU | | Inference component | model lớn cần GPU, cần kiểm soát tài nguyên từng model |

Bảng so sánh MME với multi-container: | | MME | Multi-container | |---|---|---| | Số model | hàng nghìn | tối đa 15 | | Framework | phải giống nhau | có thể khác nhau | | Nạp model | động từ S3 | cố định khi tạo endpoint | | Cập nhật một model | tải tệp lên S3 | triển khai lại endpoint | | Cold start | có khi model chưa nạp | không |

Dòng áp chót là lý do chính chọn MME cho câu này.

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

Ba cách giảm cold start trong MME: | Cách | Chi tiết | |---|---| | Giữ model nóng ấm | gọi định kỳ để không bị evict | | Instance nhiều bộ nhớ hơn | chứa được nhiều model cùng lúc | | Giảm kích thước model | quantization, pruning |

Và một chi tiết vận hành: MME có metric riêng — ModelLoadingWaitTime và ModelCacheHit. Theo dõi hai chỉ số này cho biết bộ nhớ có đủ không: tỷ lệ cache hit thấp nghĩa là model bị evict quá thường xuyên, và cần instance lớn hơn.

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

Which of the following are examples of supervised learning? (Select two)

  1. A

    Clustering
  2. B

    Linear regression
  3. C

    Association rule learning
  4. D

    Document classification
  5. E

    Neural network
Xem giải thích

Đáp án

B và E theo khoá đáp án của nguồn:

  • B — Linear regression (hồi quy tuyến tính)
  • E — Neural network (mạng nơ-ron)

Vì sao B đúng

Hồi quy tuyến tính là ví dụ điển hình của học có giám sát: nó học từ các cặp (đầu vào, nhãn số) để dự đoán giá trị liên tục cho dữ liệu mới.

Dữ liệu huấn luyện: (diện tích, số phòng) → GIÁ NHÀ  ← có nhãn
Model học:          y = w₁·diện_tích + w₂·số_phòng + b

Ghi chú về chất lượng câu hỏi

Câu này có vấn đề, và cần nói rõ.

Phương án D — "Document classification" (phân loại tài liệu) — CŨNG là học có giám sát, và là ví dụ kinh điển hơn cả E:

Dữ liệu huấn luyện: văn bản → NHÃN DANH MỤC ("thể thao", "kinh tế")
                              ↑ có nhãn ⇒ có giám sát

Phân loại (classification) là một trong hai nhánh chính của học có giám sát, bên cạnh hồi quy.

Còn phương án E — "Neural network" — KHÔNG phải một kiểu học, nó là một KIẾN TRÚC MODEL. Mạng nơ-ron dùng được cho cả ba hình thức học: | Hình thức | Ví dụ mạng nơ-ron | |---|---| | Có giám sát | CNN phân loại ảnh, mạng dự đoán giá | | Không giám sát | autoencoder, GAN, self-supervised learning | | Tăng cường | deep Q-network |

Nên xếp "neural network" vào cột học có giám sát là một phép quy nạp không chính xác về mặt khái niệm.

Cách đọc câu này: nếu gặp trong đề thi, nhiều khả năng người ra đề muốn nói "những phương án nào KHÔNG phải học không giám sát" — và A (clustering) cùng C (association rule learning) rõ ràng là không giám sát, nên còn lại ba phương án. Việc chọn B và E thay vì B và D là lựa chọn khó biện minh; D là đáp án ít nhất cũng đúng ngang E.

Vì sao A và C chắc chắn sai

  • A. Clustering (phân cụm) — học KHÔNG giám sát: nhóm dữ liệu tương tự lại mà không có nhãn. K-Means là ví dụ điển hình.
  • C. Association rule learning (học luật kết hợp) — học KHÔNG giám sát: tìm mẫu đồng xuất hiện trong dữ liệu ("người mua bánh mì thường mua sữa"). Thuật toán Apriori là ví dụ.

Ghi nhớ

Ba hình thức học máy: | Hình thức | Dữ liệu | Mục tiêu | |---|---|---| | Có giám sát | có NHÃN | dự đoán nhãn cho dữ liệu mới | | Không giám sát | không nhãn | tìm cấu trúc ẩn | | Tăng cường | phần thưởng từ môi trường | học chính sách hành động |

Hai nhánh của học có giám sát: | Nhánh | Đầu ra | Ví dụ | |---|---|---| | Phân loại | nhãn rời rạc | phân loại tài liệu, phát hiện gian lận | | Hồi quy | giá trị liên tục | dự đoán giá, dự báo nhu cầu |

Ba bài toán học không giám sát thường gặp: | Bài toán | Thuật toán | |---|---| | Phân cụm | K-Means, DBSCAN | | Giảm chiều | PCA, t-SNE | | Phát hiện bất thường | Random Cut Forest, Isolation Forest | | Học luật kết hợp | Apriori, FP-Growth |

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 → không giám sát.

Và một điểm cần phân biệt rõ, chính là điểm câu hỏi này làm mờ:

"Thuật toán/kiến trúc" khác với "hình thức học".

Mạng nơ-ron, cây quyết định, SVM đều là model; có giám sát, không giám sát, tăng cường là cách huấn luyện chúng. Cùng một kiến trúc dùng được ở nhiều hình thức học khác nhau.