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

Tìm thấy 195 câu.

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

A company's data scientist has deployed a sentiment analysis machine learning model to an Amazon SageMaker endpoint. Given the involvement of multiple stakeholders, the data scientist needs to explain how the model generates its predictions and clarify the factors influencing the model's decisions.

Which solution will provide an explanation for the model's predictions?

  1. A

    Use Amazon SageMaker Model Monitor that offers tools to provide explainations on model quality
  2. B

    Configure a SageMaker Clarify processing job to analyze your model for bias and explainability
  3. C

    Use Amazon Textract to automatically extract text and data from the ML model and provide insights on its predictions
  4. D

    Leverage CloudWatch Insights derived from SageMaker AI endpoint invocation metrics to analyze your model for bias and explainability
Xem giải thích

Đáp án

B — Cấu hình một SageMaker Clarify processing job để phân tích model về thiên lệch và khả năng giải thích.

Vì sao đúng

Đề nêu yêu cầu rõ ràng: giải thích cách model đưa ra dự đoán và làm rõ các yếu tố ảnh hưởng tới quyết định — đó chính là định nghĩa của explainability, và Clarify là dịch vụ được xây cho việc đó.

Clarify cung cấp hai loại giải thích: | Loại | Trả lời | |---|---| | Toàn cục (global) | "Model nói chung dựa vào những đặc trưng nào?" | | Cục bộ (local) | "Vì sao dự đoán NÀY như vậy?" |

Với model phân tích cảm xúc, giải thích cục bộ là thứ các bên liên quan cần:

Đánh giá: "Sản phẩm giao nhanh nhưng đóng gói tệ"
Dự đoán: NEUTRAL (0,52)

Đóng góp SHAP:
  "giao nhanh"     →  +0,31  (đẩy về tích cực)
  "tệ"             →  −0,28  (đẩy về tiêu cực)
  "nhưng"          →  −0,05

clarify_processor.run_explainability(
    data_config=DataConfig(s3_data_input_path=..., s3_output_path=...),
    model_config=ModelConfig(model_name=ten_model, ...),
    explainability_config=SHAPConfig(baseline=[du_lieu_co_so],
                                     num_samples=100,
                                     agg_method='mean_abs'))

Và Clarify chạy được ở nhiều giai đoạn: | Giai đoạn | Việc | |---|---| | Trước huấn luyện | phát hiện thiên lệch trong DỮ LIỆU | | Sau huấn luyện | thiên lệch trong DỰ ĐOÁN + feature importance | | Trên production | giám sát bias drift và feature attribution drift |

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

  • A. Dùng SageMaker Model Monitor vốn cung cấp công cụ giải thích về chất lượng model — đây là phương án gần nhất và hai dịch vụ hay đi cùng nhau, nhưng chúng làm việc khác nhau: Model Monitor phát hiện chất lượng giảm và drift, còn Clarify giải thích VÌ SAO model dự đoán như vậy. (Model Monitor có tính năng feature attribution drift — nhưng nó dùng Clarify bên dưới, và nó phát hiện thay đổi chứ không giải thích một dự đoán cụ thể.)
  • C. Dùng Amazon Textract tự động trích xuất văn bản và dữ liệu từ ML model và cho thông tin về dự đoán — mô tả một việc không tồn tại: Textract trích xuất văn bản từ tài liệu và ảnh, nó không "đọc" được model. Đây là câu vô nghĩa về mặt kỹ thuật.
  • D. Dùng CloudWatch Insights từ metric gọi endpoint để phân tích thiên lệch và khả năng giải thích — CloudWatch chỉ có metric vận hành: số lời gọi, độ trễ, tỷ lệ lỗi. Nó không nhìn vào nội dung dự đoán, nên không phân tích được thiên lệch hay đóng góp của đặc trưng.

Ghi nhớ

Hai khái niệm cần phân biệt: | Khái niệm | Nghĩa | |---|---| | Interpretability | bản thân model đủ đơn giản để hiểu trực tiếp | | Explainability | model phức tạp + công cụ giải thích từng dự đoán |

Ba kỹ thuật giải thích và phạm vi: | Kỹ thuật | Phạm vi | Tốc độ | |---|---|---| | SHAP | cục bộ (tổng hợp lên được thành toàn cục) | TreeSHAP nhanh, KernelSHAP chậm | | PDP | toàn cục — hình dạng ảnh hưởng của một đặc trưng | vừa | | Feature importance | toàn cục, thô hơn | nhanh |

SageMaker Clarify cung cấp cả SHAP lẫn PDP dựng sẵn.

Bốn khả năng của Clarify: | Khả năng | Chi tiết | |---|---| | Pre-training bias | CI, DPL, CDD — thiên lệch trong dữ liệu | | Post-training bias | DPPL, DI, RD — thiên lệch trong dự đoán | | Explainability (SHAP) | đóng góp của từng đặc trưng | | Monitoring | bias drift và feature attribution drift trên production |

Ba lý do nghiệp vụ cần explainability: | Lý do | Chi tiết | |---|---| | Yêu cầu quy định | nhiều lĩnh vực buộc phải giải thích quyết định tự động | | Niềm tin của các bên liên quan | đúng tình huống trong đề | | Phát hiện lỗi model | đặc trưng quan trọng bất thường thường là dấu hiệu rò rỉ dữ liệu |

Dòng cuối là lợi ích thực dụng nhất trong quá trình phát triển: nếu SHAP cho thấy model đang dựa nặng vào một đặc trưng không nên quan trọng, đó thường là rò rỉ dữ liệu — và chỉ công cụ giải thích mới lộ ra được.

Và với model xử lý văn bản như phân tích cảm xúc, Clarify hỗ trợ giải thích ở mức token — chỉ ra từ nào trong câu đẩy dự đoán theo hướng nào, đúng thứ cần để giải thích cho người không chuyên kỹ thuật.

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

A financial services company operates in a hybrid cloud environment and has deployed a machine learning model on premises to provide personalized financial recommendations. The model processes data stored in Amazon S3, which includes sensitive customer information such as Social Security numbers and financial transaction details. The company must ensure that all sensitive data is identified and removed before it is processed by the model. The company needs to implement a solution that can handle these requirements with the least operational overhead.

Which solution will meet these requirements?

  1. A

    Use AWS DataBrew to create a data transformation pipeline that scans for sensitive data and applies predefined rules to clean the dataset
  2. B

    Use Amazon Macie to automatically identify sensitive data in Amazon S3 and then call a Lambda function to remove the sensitive data
  3. C

    Deploy an AWS Glue ETL job to scan the S3 bucket, detect sensitive data using a custom Python script, and redact the sensitive information
  4. D

    Leverage Amazon Comprehend to classify and redact sensitive entities from the data stored in Amazon S3 before it is used by the model
Xem giải thích

Đáp án

B — Dùng Amazon Macie tự động nhận diện dữ liệu nhạy cảm trong S3, rồi gọi Lambda function xoá dữ liệu nhạy cảm.

Vì sao đúng

Đề nêu ba yếu tố, và Macie khớp cả ba: | Yếu tố | Macie | |---|---| | Dữ liệu nằm trong Amazon S3 | Macie quét S3 — đúng phạm vi | | Nhận diện số bảo hiểm, chi tiết giao dịch tài chính | loại dữ liệu Macie phát hiện sẵn | | Ít công sức vận hành nhất | dịch vụ được quản lý, không viết luật nhận diện |

Macie là dịch vụ chuyên phát hiện dữ liệu nhạy cảm TRONG S3 — nó dùng máy học và so khớp mẫu, và có sẵn bộ nhận diện cho hàng chục loại:

aws macie2 create-classification-job   --job-type ONE_TIME   --s3-job-definition '{"bucketDefinitions": [{"accountId":"123456789012",
                        "buckets":["kho-du-lieu-khach-hang"]}]}'   --name "quet-truoc-khi-xu-ly"

Và luồng tự động hoá khép kín:

Macie phát hiện dữ liệu nhạy cảm
    ↓ EventBridge event (Macie Finding)
Lambda: xoá hoặc che trường nhạy cảm, hoặc chuyển sang bucket cách ly
    ↓
Chỉ dữ liệu sạch mới tới model tại chỗ

Ba loại dữ liệu Macie phát hiện được — bao gồm cả hai loại đề nêu: | Loại | Ví dụ | |---|---| | PII | tên, địa chỉ, số bảo hiểm xã hội, số hộ chiếu | | Tài chính | số thẻ, số tài khoản ngân hàng | | Thông tin xác thực | AWS access key, private key |

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

  • D. Dùng Amazon Comprehend phân loại và che thực thể nhạy cảm từ dữ liệu trong S3 trước khi model dùng — đây là phương án gần nhất và Comprehend PII detection là công cụ tốt, nhưng nó làm việc với VĂN BẢN trong pipeline xử lý, không quét kho dữ liệu S3. Bạn phải tự viết logic đọc từng object, gọi Comprehend, ghi lại — trong khi Macie làm việc đó ở mức bucket. (Hai dịch vụ bổ sung nhau: Macie kiểm kê kho, Comprehend che trong pipeline.)
  • C. Triển khai Glue ETL job quét bucket, phát hiện dữ liệu nhạy cảm bằng script Python tuỳ chỉnh, và che thông tin — tự viết bộ nhận diện: bạn phải viết và bảo trì regex cho từng loại dữ liệu, và độ phủ phụ thuộc vào việc bạn nghĩ ra đủ mẫu. Trái tiêu chí "least operational overhead".
  • A. Dùng AWS DataBrew tạo pipeline biến đổi quét dữ liệu nhạy cảm và áp luật định trước — DataBrew là công cụ chuẩn bị dữ liệu, không phải công cụ phát hiện dữ liệu nhạy cảm ở quy mô kho. Nó có transform che dữ liệu, nhưng bạn phải biết trước cột nào nhạy cảm.

Ghi nhớ

Ba dịch vụ xử lý dữ liệu nhạy cảm — nhớ đúng phạm vi: | Dịch vụ | Phạm vi | Việc | |---|---|---| | Amazon Macie | kho dữ liệu S3 | PHÁT HIỆN và phân loại | | Comprehend PII | văn bản trong pipeline | phát hiện và CHE | | Bedrock Guardrails | lúc gọi model | chặn PII trong prompt và phản hồi |

Cả ba nên dùng cùng nhau trong một kiến trúc đầy đủ: Macie kiểm kê kho, Comprehend che trong pipeline, Guardrails bắt những gì lọt qua.

Hai chế độ của Macie: | Chế độ | Độ phủ | Chi phí | |---|---|---| | Automated sensitive data discovery | lấy mẫu | thấp | | Classification job | quét ĐẦY ĐỦ | cao hơn |

Với yêu cầu "tất cả dữ liệu nhạy cảm phải được nhận diện và xoá", classification job quét đầy đủ là bắt buộc — lấy mẫu để lọt object chưa quét.

Ba hành động sau khi Macie phát hiện: | Hành động | Chi tiết | |---|---| | Gắn thẻ | do_nhay_cam = cao — pipeline lọc theo thẻ | | Cách ly | chuyển sang bucket riêng có quyền hạn chế | | Che hoặc xoá | Lambda xử lý nội dung |

Và một điểm quan trọng về thứ tự cho kiến trúc lai như trong đề:

Quét và làm sạch TRƯỚC KHI dữ liệu rời khỏi AWS.

Model chạy tại chỗ (on-premises) nghĩa là dữ liệu phải đi ra khỏi ranh giới AWS — nên việc làm sạch phải hoàn tất trước bước truyền. Nếu để model tại chỗ tự lọc, dữ liệu nhạy cảm đã ra khỏi vùng kiểm soát rồi.

Ba chi tiết vận hành đáng biết: | Chi tiết | Ghi chú | |---|---| | Macie tính tiền theo lượng dữ liệu quét | với kho lớn, cân nhắc quét theo prefix | | Custom data identifier | khai thêm mẫu riêng của tổ chức bằng regex | | Allow list | tránh báo động giả cho dữ liệu công khai đã biết |

Câu 143 Deployment and Orchestration of ML Workflows

A retail company uses a machine learning model to predict customer demand. The vendor of the model supplies cleaned and prepared training data every 3-4 days, which is uploaded to an Amazon S3 bucket. The company has set up an Amazon SageMaker pipeline to retrain the model whenever new data becomes available. Until now, triggering the SageMaker pipeline has been a manual task. An ML engineer is tasked with implementing an automated solution to trigger the pipeline automatically whenever new data is uploaded to the S3 bucket.

What solution should the ML engineer implement to achieve this with the LEAST operational effort?

  1. A

    Using Amazon S3 Event Notifications, add a notification configuration that identifies the event you want Amazon S3 to publish. Add SageMaker pipeline as the destination to this notification configuration
  2. B

    Create an S3 Lifecycle configuration for the s3 bucket with an event pattern that matches the S3 upload event. Create a rule to trigger SageMaker pipeline
  3. C

    Enable Amazon EventBridge for the S3 bucket and create an EventBridge rule with an event pattern that matches the S3 upload event. Set the SageMaker pipeline as the target for the rule
  4. D

    Set up a cron job to check for S3 data uploads once a day. If an S3 data file is detected, the cron job will invoke an AWS Lambda function, which will then trigger the SageMaker pipeline
Xem giải thích

Đáp án

C — Bật Amazon EventBridge cho S3 bucket và tạo EventBridge rule có event pattern khớp sự kiện tải lên S3; đặt SageMaker pipeline làm target của rule.

Vì sao đúng

Đề nêu yêu cầu: tự động kích hoạt pipeline khi có dữ liệu mới, với công sức vận hành ít nhất.

EventBridge có thể gọi trực tiếp SageMaker pipeline làm target — không cần Lambda trung gian:

{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {
    "bucket": {"name": ["kho-du-lieu-huan-luyen"]},
    "object": {"key": [{"prefix": "du-lieu-moi/"}]}
  }
}

Rule target: arn:aws:sagemaker:...:pipeline/du-doan-nhu-cau

Ba lợi ích so với các cách khác: | Lợi ích | Chi tiết | |---|---| | Không cần Lambda trung gian | ít thành phần hơn = ít thứ hỏng hơn | | Lọc linh hoạt | theo prefix, suffix, kích thước — ngay trong event pattern | | Thêm consumer dễ dàng | thêm rule mới mà không đụng cấu hình bucket |

Một bước bắt buộc dễ quên: phải bật EventBridge notification trên bucket:

aws s3api put-bucket-notification-configuration   --bucket kho-du-lieu-huan-luyen   --notification-configuration '{"EventBridgeConfiguration": {}}'

Không bật thì S3 không phát sự kiện tới EventBridge, và rule không bao giờ khớp.

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

  • A. Dùng S3 Event Notifications và đặt SageMaker pipeline làm ĐÍCH của cấu hình thông báo — đây là phương án gần nhất và sai ở một chi tiết cụ thể: S3 Event Notification chỉ hỗ trợ bốn đích: Lambda, SQS, SNS, và EventBridge. SageMaker pipeline KHÔNG phải đích hợp lệ. Muốn dùng cách này phải thêm Lambda ở giữa — nhiều công hơn phương án C.
  • B. Tạo S3 Lifecycle configuration với event pattern khớp sự kiện tải lên, tạo rule kích hoạt pipeline — S3 Lifecycle không kích hoạt được gì: nó là cơ chế quản lý vòng đời lưu trữ (chuyển lớp lưu trữ, xoá sau N ngày). Nó không phát sự kiện và không có khái niệm "event pattern".
  • D. Đặt cron job kiểm tra dữ liệu mỗi ngày một lần; nếu phát hiện tệp thì gọi Lambda kích hoạt pipeline — hai vấn đề: phải có nơi chạy cron (thêm hạ tầng), và kiểm tra mỗi ngày một lần không phù hợp với dữ liệu tới mỗi 3–4 ngày — độ trễ tới 24 giờ mà không cần thiết.

Ghi nhớ

Bốn đích hợp lệ của S3 Event Notification: | Đích | Dùng khi | |---|---| | Lambda | xử lý ngay bằng mã | | SQS | cần đệm, xử lý theo lô | | SNS | fan-out nhiều bên nhận | | EventBridge | linh hoạt nhất — lọc phức tạp, nhiều loại target |

EventBridge là lựa chọn khuyến nghị cho pipeline ML vì nó hỗ trợ rất nhiều loại target, bao gồm: | Target | Ghi chú | |---|---| | SageMaker Pipeline | gọi trực tiếp, không cần Lambda | | Step Functions | workflow phức tạp | | Lambda, SQS, SNS | như S3 notification | | ECS task, Batch job | |

Ba cách kích hoạt SageMaker pipeline: | Cách | Dùng khi | |---|---| | EventBridge rule (sự kiện) | dữ liệu mới tới ← câu này | | EventBridge schedule (cron) | chạy định kỳ | | Gọi API StartPipelineExecution | từ mã hoặc CI/CD |

Ba mẫu event pattern hữu ích:

// Chỉ tệp Parquet trong một prefix
{"detail": {"object": {"key": [{"prefix": "du-lieu/"}, {"suffix": ".parquet"}]}}}

// Chỉ tệp lớn hơn ngưỡng
{"detail": {"object": {"size": [{"numeric": [">", 1000000]}]}}}

Và một cân nhắc thực tế cho tình huống trong đề: nếu nhà cung cấp tải lên nhiều tệp cho một lô dữ liệu, kích hoạt pipeline ở mỗi tệp sẽ chạy pipeline nhiều lần không cần thiết. Hai cách xử lý: | Cách | Chi tiết | |---|---| | Tệp đánh dấu hoàn tất | kích hoạt khi thấy _SUCCESS hoặc manifest.json | | SQS + Lambda gom nhóm | đợi một khoảng rồi mới kích hoạt một lần |

Cách đầu đơn giản và đáng tin hơn — và là quy ước phổ biến trong pipeline dữ liệu.

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

A retail company trained a sales forecasting ML model by preprocessing the training data using AWS Glue DataBrew. During preprocessing, the ML engineer used z-score normalization to standardize the training data. Now, the company needs to preprocess the real-time sales data for inference by applying the same z-score normalization parameters as the training data to ensure consistency in predictions.

Which solution will meet this requirement?

  1. A

    Use AWS Lambda to create a custom function for z-score normalization that calculates new parameters for each batch of sales data
  2. B

    Export the z-score normalization recipe from AWS Glue DataBrew and apply the same recipe to preprocess the real-time sales data for inference
  3. C

    Manually calculate the z-score normalization parameters again for the real-time sales data and use these parameters during inference preprocessing
  4. D

    Apply a SageMaker Processing job to perform z-score normalization on the real-time sales data and automatically derive new parameters
Xem giải thích

Đáp án

B — Xuất recipe z-score normalization từ AWS Glue DataBrew và áp chính recipe đó để tiền xử lý dữ liệu bán hàng thời gian thực cho suy luận.

Vì sao đúng

Đề nêu yêu cầu cốt lõi: áp CÙNG tham số chuẩn hoá của dữ liệu huấn luyện lên dữ liệu suy luận để đảm bảo tính nhất quán.

Vì sao phải dùng cùng tham số — đây là điểm mấu chốt:

Z-score:  z = (x − μ) / σ

Lúc huấn luyện:  μ = 1.500.000, σ = 300.000   (tính từ dữ liệu huấn luyện)
                 doanh số 1.800.000 → z = 1,0

Nếu suy luận tính LẠI tham số từ lô hiện tại:
                 μ = 2.000.000, σ = 400.000
                 doanh số 1.800.000 → z = −0,5   ← GIÁ TRỊ KHÁC HẲN
                 → model nhận đầu vào không khớp với thứ nó đã học

Đây là hiện tượng training–serving skew, và nó gây sai lệch âm thầm: model chạy bình thường, không lỗi, chỉ là dự đoán sai.

DataBrew recipe lưu lại toàn bộ tham số đã tính:

{
  "Action": {"Operation": "STANDARDIZE",
             "Parameters": {"sourceColumn": "doanh_so",
                            "mean": "1500000", "stddev": "300000"}}
}

Xuất recipe và áp lại nghĩa là dùng đúng μ và σ của lúc huấn luyện — đúng thứ đề yêu cầu.

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

  • D. Dùng SageMaker Processing job chuẩn hoá dữ liệu thời gian thực và TỰ SUY RA tham số mới — đây là phương án gần nhất và sai ở đúng chỗ: "automatically derive new parameters" chính là nguyên nhân gây sai lệch. Công cụ đúng nhưng logic sai.
  • C. Tính TAY lại tham số z-score cho dữ liệu thời gian thực và dùng chúng khi tiền xử lý — cùng lỗi, và còn thêm việc thủ công.
  • A. Dùng Lambda viết hàm tuỳ chỉnh tính tham số mới cho MỖI LÔ dữ liệu — tệ nhất: mỗi lô có tham số khác nhau, nên cùng một giá trị doanh số cho ra z-score khác nhau tuỳ theo lô nào nó rơi vào.

Ghi nhớ

Nguyên tắc vàng của tiền xử lý:

Tham số biến đổi phải được TÍNH từ dữ liệu huấn luyện và ÁP LẠI cho dữ liệu suy luận — không bao giờ tính lại.

Điều này đúng cho mọi phép biến đổi có tham số: | Phép biến đổi | Tham số phải lưu | |---|---| | Standardization (z-score) | μ và σ | | Min-max normalization | min và max | | One-hot encoding | danh sách giá trị đã thấy | | Imputation | giá trị điền (trung bình, trung vị) | | Target encoding | ánh xạ giá trị → trung bình nhãn |

Dòng one-hot encoding hay bị bỏ sót: nếu dữ liệu suy luận có một giá trị chưa từng thấy lúc huấn luyện, cần biết trước để xử lý (bỏ qua, hoặc gán vào cột "Khác") — chứ không tạo cột mới.

Ba cách đảm bảo nhất quán giữa huấn luyện và suy luận: | Cách | Chi tiết | |---|---| | Xuất và tái dùng recipe | DataBrew recipe, Data Wrangler flow ← câu này | | SageMaker Feature Store | cùng một đặc trưng cho cả train lẫn serve | | Inference pipeline | đóng gói bước tiền xử lý CÙNG model trong một endpoint |

Cách thứ ba đáng biết vì nó mạnh nhất về mặt đảm bảo:

PipelineModel(models=[
    SKLearnModel(...),    # container tiền xử lý (chứa scaler đã fit)
    XGBoostModel(...)])   # container model

Với inference pipeline, bước tiền xử lý là một phần của endpoint — không có cách nào gọi model mà bỏ qua nó.

Và ba triệu chứng của training–serving skew: | Triệu chứng | Ghi chú | |---|---| | Chỉ số offline tốt, production kém | dấu hiệu kinh điển | | Phân bố dự đoán lệch khỏi lúc kiểm chứng | phát hiện bằng Model Monitor | | Không có lỗi kỹ thuật nào | đây là điều khiến nó khó phát hiện |

Dòng cuối là lý do skew nguy hiểm: hệ thống hoạt động "bình thường" về mọi mặt kỹ thuật, và chỉ có chỉ số nghiệp vụ mới lộ ra vấn đề.

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

A financial institution uses an Amazon Redshift database to store transactional and customer data, including sensitive information such as personally identifiable information (PII). A data analyst needs access to specific columns of the database to perform customer behavior analysis. The institution wants to ensure that sensitive data, such as PII, is not exposed to the analyst while maintaining the integrity of the source data. The solution must avoid duplicating or transforming the data into a separate dataset.

What do you recommend to address these requirements with the LEAST implementation effort?

  1. A

    Export the data to Amazon S3, apply anonymization to sensitive fields using AWS Glue, and allow the analyst to query the transformed data
  2. B

    Use Amazon Redshift row-level security to restrict access to sensitive rows while allowing access to all columns
  3. C

    Create a materialized view in Amazon Redshift that excludes sensitive fields and grant the analyst access to the view
  4. D

    Implement Amazon Redshift dynamic data masking policies to obfuscate sensitive columns dynamically while allowing the analyst to access permitted data
Xem giải thích

Đáp án

D — Triển khai dynamic data masking policy của Amazon Redshift để che các cột nhạy cảm một cách động, trong khi vẫn cho chuyên viên phân tích truy cập dữ liệu được phép.

Vì sao đúng

Đề nêu ba ràng buộc, và dynamic data masking đáp ứng cả ba: | Ràng buộc | Cơ chế | |---|---| | Không lộ PII cho chuyên viên phân tích | che theo vai trò lúc truy vấn | | Giữ nguyên tính toàn vẹn dữ liệu gốc | dữ liệu KHÔNG bị thay đổi | | KHÔNG nhân bản hay biến đổi thành tập riêng | không tạo bản sao nào |

Dynamic data masking áp lúc truy vấn, không đụng dữ liệu lưu:

CREATE MASKING POLICY che_so_the
WITH (so_the VARCHAR(20))
USING ('XXXX-XXXX-XXXX-' || SUBSTRING(so_the, 16, 4));

ATTACH MASKING POLICY che_so_the
ON giao_dich(so_the)
TO ROLE chuyen_vien_phan_tich;

Kết quả tuỳ theo người truy vấn:

Chuyên viên phân tích:  SELECT so_the FROM giao_dich
                        → XXXX-XXXX-XXXX-1234

Đội tuân thủ:           SELECT so_the FROM giao_dich
                        → 4532-1234-5678-1234

Cùng một bảng, cùng một truy vấn, kết quả khác nhau theo vai trò — và dữ liệu gốc không hề bị sửa.

Ba lợi ích so với các cách khác: | Lợi ích | Chi tiết | |---|---| | Không nhân bản | không có bản sao phải đồng bộ | | Không sửa dữ liệu gốc | đội tuân thủ vẫn thấy đầy đủ | | Áp ở tầng CSDL | mọi công cụ truy vấn đều tuân theo |

Dòng cuối quan trọng: chuyên viên phân tích dùng BI tool, notebook, hay SQL client đều nhận cùng kết quả đã che — không phụ thuộc vào việc ứng dụng nhớ lọc.

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

  • C. Tạo materialized view loại bỏ các trường nhạy cảm và cấp quyền cho chuyên viên truy cập view đó — đây là phương án gần nhất và hoạt động được, nhưng nó tạo ra một bản sao dữ liệu (materialized view lưu kết quả vật lý) — trái ràng buộc "avoid duplicating". (Một view thường thì không nhân bản và cũng là giải pháp hợp lệ — nhưng phương án nói rõ là materialized view.)
  • B. Dùng row-level security hạn chế truy cập các DÒNG nhạy cảm trong khi cho phép truy cập MỌI CỘT — sai chiều kiểm soát: vấn đề là cột nhạy cảm (PII), không phải dòng. Cho truy cập mọi cột nghĩa là chuyên viên vẫn thấy số bảo hiểm và thông tin cá nhân.
  • A. Xuất dữ liệu ra S3, ẩn danh trường nhạy cảm bằng Glue, rồi cho chuyên viên truy vấn dữ liệu đã biến đổi — vi phạm ràng buộc "không nhân bản", và tạo ra một bản sao phải đồng bộ liên tục khi dữ liệu gốc thay đổi.

Ghi nhớ

Bốn cơ chế kiểm soát truy cập của Redshift: | Cơ chế | Kiểm soát | |---|---| | Column-level grant | cột nào được SELECT | | Row-level security (RLS) | dòng nào thấy được | | Dynamic data masking (DDM) | GIÁ TRỊ hiển thị thế nào | | View | tập hợp cột và dòng qua truy vấn |

Phân biệt column-level grant với dynamic data masking: | | Column grant | Dynamic masking | |---|---|---| | Chuyên viên thấy cột | ❌ không thấy cột nào cả | ✅ thấy cột, giá trị bị che | | Truy vấn có cột đó | lỗi permission | chạy bình thường | | Dùng khi | cột hoàn toàn không liên quan | cần biết cột tồn tại, đếm, nhóm được |

Dòng cuối là ưu thế của masking: chuyên viên vẫn COUNT(DISTINCT so_the) hoặc GROUP BY được — hữu ích cho phân tích hành vi mà không cần biết giá trị thật.

Ba mức che thường dùng: | Mức | Ví dụ | |---|---| | Che toàn bộ | XXXXXXXX | | Che một phần | XXXX-XXXX-XXXX-1234 — giữ 4 số cuối | | Băm (hash) | a3f9c21b — nhất quán, nối bản ghi được |

Mức thứ ba đáng dùng khi cần theo dõi cùng một khách hàng qua nhiều bản ghi mà không biết họ là ai.

Và một điểm về phạm vi áp dụng: dynamic data masking áp cho vai trò (role), không áp cho từng người. Nên cần thiết kế vai trò cẩn thận — và superuser luôn thấy dữ liệu gốc, đó là chi tiết cần nhớ khi thiết kế quản trị.

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

What is the primary distinction between discriminative models and generative models in the context of generative AI?

  1. A

    Discriminative models are only used for text classification, while generative models are only used for image classification
  2. B

    Generative models are trained on labeled data, while discriminative models can be trained on both labeled and unlabeled data
  3. C

    Discriminative models are used to generate new data, while generative models are used only for classification
  4. D

    Generative models focus on generating new data from learned patterns, whereas discriminative models classify data by distinguishing between different classes
Xem giải thích

Đáp án

D — Model sinh (generative) tập trung vào việc SINH RA dữ liệu mới từ các mẫu đã học, trong khi model phân biệt (discriminative) PHÂN LOẠI dữ liệu bằng cách phân biệt giữa các lớp.

Vì sao đúng

Đây là phân biệt nền tảng, và khác biệt nằm ở thứ mà model học: | | Generative | Discriminative | |---|---|---| | Học | P(X) hoặc P(X, Y) — phân bố của DỮ LIỆU | P(Y|X) — ranh giới giữa các lớp | | Trả lời | "Dữ liệu này trông thế nào?" | "Cái này thuộc lớp nào?" | | Làm được | sinh 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 |

Trực giác về khác biệt:

Bài toán: phân biệt ảnh mèo và ảnh chó

Discriminative:  học ĐƯỜNG RANH GIỚI giữa hai lớp
                 → "tai nhọn + râu dài → mèo"
                 → không biết mèo trông thế nào nói chung

Generative:      học MÈO TRÔNG THẾ NÀO và CHÓ TRÔNG THẾ NÀO
                 → vẽ được một con mèo mới
                 → và cũng phân loại được (qua quy tắc Bayes)

Ví dụ hai họ: | Họ | Ví dụ | |---|---| | Generative | GAN, VAE, Diffusion, LLM (GPT, Claude), Naive Bayes | | Discriminative | hồi quy logistic, SVM, random forest, CNN phân loại |

Và mọi model GenAI hiện đại đều thuộc họ sinh — đó là lý do chúng viết được văn bản mới, vẽ được ảnh mới, thay vì chỉ gán nhãn.

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

  • C. Discriminative dùng để SINH dữ liệu mới, generative chỉ dùng để phân loại — đảo ngược hoàn toàn hai định nghĩa.
  • B. Generative huấn luyện trên dữ liệu CÓ NHÃN, discriminative huấn luyện được trên cả có nhãn lẫn không nhãn — ngược lại về mặt điển hình: model sinh thường học không giám sát (LLM học từ văn bản không nhãn, GAN học từ ảnh không nhãn), còn discriminative cần nhãn để học ranh giới. (Có ngoại lệ ở cả hai phía, nhưng phát biểu này sai theo hướng phổ biến.)
  • A. Discriminative chỉ dùng cho phân loại văn bản, generative chỉ dùng cho phân loại ảnh — sai hoàn toàn: cả hai họ đều áp dụng cho mọi loại dữ liệu, và generative không phải để phân loại.

Ghi nhớ

Bốn kiến trúc model sinh: | 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 — ổn định hơn, ảnh mờ hơn | | Diffusion | khử nhiễu dần — chất lượng cao nhất hiện nay | | Autoregressive (LLM) | sinh từng token dựa trên token trước |

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 | |---|---| | 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 | | Data augmentation | sinh thêm mẫu cho lớp thiểu số | | Điền phần thiếu | inpainting, hoàn thiện dữ liệu |

Ứng dụng đầu nối với các thuật toán như Random Cut Forest: cùng nguyên lý — học "bình thường trông thế nào" rồi gắn cờ thứ lệch khỏi đó.

Đánh đổi giữa hai họ: | | Generative | Discriminative | |---|---|---| | Dữ liệu cần | nhiều hơn | ít hơn | | Độ chính xác phân loại | thường thấp hơn | thường cao hơn | | Linh hoạt | cao — làm được nhiều việc | chuyên một việc |

Nếu chỉ cần phân loại, model discriminative thường tốt hơn — nó tập trung toàn bộ năng lực vào việc học ranh giới, thay vì học cả phân bố dữ liệu.

Và một điểm về LLM đáng nhớ: chúng là model sinh tự hồi quy — dự đoán token tiếp theo dựa trên các token trước. Chính cơ chế đơn giản đó, khi mở rộng tới quy mô rất lớn, sinh ra khả năng suy luận và làm nhiều tác vụ mà không cần huấn luyện riêng cho từng cái.

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

A healthcare organization is developing an ML model to predict whether patients are at risk of developing a rare but critical disease. Missing a patient with a disease (a false negative) could delay treatment, potentially leading to severe consequences. However, incorrectly predicting a disease (a false positive) may result in unnecessary follow-up tests, which are less costly compared to missing an actual case.

Which model characteristic should the healthcare organization prioritize to best meet its requirements?

  1. A

    Prioritize a model with high accuracy
  2. B

    Prioritize a model with high recall
  3. C

    Prioritize a model with high precision
  4. D

    Prioritize a model with low recall
Xem giải thích

Đáp án

B — Ưu tiên model có recall cao.

Vì sao đúng

Đề mô tả hai loại lỗi với chi phí RÕ RÀNG KHÔNG ĐỐI XỨNG: | Loại lỗi | Hậu quả | Mức nghiêm trọng | |---|---|---| | False negative (bỏ sót bệnh nhân) | chậm trễ điều trị, hậu quả nặng nề | rất cao | | False positive (báo nhầm) | xét nghiệm theo dõi không cần thiết | thấp hơn |

Và recall là chỉ số đo trực tiếp việc bỏ sót:

Recall = TP / (TP + FN)
                    ↑
            số ca bệnh BỊ BỎ SÓT

Recall cao  →  FN thấp  →  ít bệnh nhân bị bỏ sót

Đánh đổi cần chấp nhận: tăng recall thường giảm precision — nhiều người khoẻ mạnh sẽ bị gọi đi xét nghiệm thêm. Nhưng đề đã nói rõ đó là chi phí thấp hơn so với bỏ sót một ca bệnh.

Cách tăng recall trong thực tế — không cần huấn luyện lại:

Model trả về xác suất, ngưỡng biến nó thành quyết định:

Ngưỡng 0,5:  precision 0,80, recall 0,65
Ngưỡng 0,3:  precision 0,62, recall 0,88   ← ít bỏ sót hơn nhiều
Ngưỡng 0,2:  precision 0,45, recall 0,95

Hạ ngưỡng là cách trực tiếp nhất — và nó là quyết định nghiệp vụ, không phải kỹ thuật.

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

  • C. Ưu tiên model có precision cao — đây là phương án gần nhất và tối ưu đúng chỉ số nhưng SAI CHIỀU: precision cao nghĩa là ít báo nhầm, nhưng đạt được bằng cách thận trọng hơn — và model thận trọng thì bỏ sót nhiều hơn. Đó là đúng thứ đề nói phải tránh.
  • A. Ưu tiên model có accuracy cao — chỉ số gây hiểu lầm với bệnh HIẾM: đề nói rõ đây là "rare but critical disease". Nếu chỉ 0,5% dân số mắc, model đoán "không ai bệnh" đạt accuracy 99,5% mà bỏ sót 100% ca bệnh.
  • D. Ưu tiên model có recall THẤP — ngược hoàn toàn: recall thấp nghĩa là bỏ sót nhiều — chính hậu quả nghiêm trọng nhất mà đề nêu.

Ghi nhớ

Bốn chỉ số và loại lỗi chúng nhắm tới: | Chỉ số | Công thức | Giảm loại lỗi nào | |---|---|---| | Precision | TP / (TP + FP) | false positive | | Recall (Sensitivity) | TP / (TP + FN) | false negative | | F1 | 2PR/(P+R) | cân bằng cả hai | | Specificity | TN / (TN + FP) | false positive (nhìn từ lớp âm) |

Quy tắc chọn theo chi phí nghiệp vụ: | Bỏ sót tốn kém hơn | Báo nhầm tốn kém hơn | |---|---| | Sàng lọc bệnh ← câu này | lọc thư rác (mất email quan trọng) | | Phát hiện gian lận | kiểm duyệt nội dung quá tay | | An toàn (phát hiện lỗi thiết bị) | quảng cáo nhắm sai | | → ưu tiên RECALL | → ưu tiên PRECISION |

F-beta — biến thể khi muốn nghiêng có kiểm soát: | Biến thể | Ưu tiên | |---|---| | F2 (β = 2) | recall gấp đôi — hợp với sàng lọc bệnh | | F1 | cân bằng | | F0.5 | precision gấp đôi |

F2 thường là chỉ số đúng nhất cho tình huống trong đề — nó cân bằng cả hai nhưng nghiêng rõ về recall.

Ba cách tăng recall: | Cách | Chi tiết | |---|---| | Hạ ngưỡng phân loại | nhanh nhất, không cần huấn luyện lại | | Trọng số lớp khi huấn luyện | scale_pos_weight trong XGBoost | | Oversample lớp thiểu số | SMOTE, chỉ trên tập huấn luyện |

Và một nguyên tắc thiết kế quan trọng:

Luôn triển khai model TRẢ VỀ XÁC SUẤT, không phải nhãn cứng.

Cách này cho phép điều chỉnh ngưỡng theo nhu cầu nghiệp vụ mà không phải huấn luyện lại — và với sàng lọc y tế, ngưỡng có thể cần khác nhau cho các nhóm nguy cơ khác nhau.

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

You are a machine learning engineer at a financial services company responsible for maintaining a fraud detection model deployed on Amazon SageMaker. The model processes a high volume of real-time transactions and must respond with low latency to ensure a seamless customer experience. Recently, the model has experienced increased latency during peak traffic times, and there have been instances where requests were dropped due to insufficient capacity.

Which approach is the MOST EFFECTIVE for monitoring and resolving these latency and scaling issues in your ML solution?

  1. A

    Manually monitor the model’s performance using the SageMaker console, and manually increase the instance size whenever latency is detected, to ensure the model remains responsive during peak periods
  2. B

    Implement a serverless architecture using AWS Lambda for model inference to eliminate latency and scaling issues. Use Amazon CloudFront to cache inference results for faster response times
  3. C

    Configure Amazon CloudWatch to monitor key metrics such as invocation latency, model error rates, and CPU utilization. Set up CloudWatch Alarms to automatically trigger an increase in instance count when latency exceeds a predefined threshold, and enable auto-scaling on the SageMaker endpoint to handle traffic spikes
  4. D

    Use Amazon SageMaker Model Monitor to track the performance of the model and identify data drift. Adjust the model’s hyperparameters based on the results to reduce latency and improve scalability during peak times
Xem giải thích

Đáp án

C — Cấu hình CloudWatch giám sát các metric chính như độ trễ gọi endpoint, tỷ lệ lỗi và mức dùng CPU; đặt CloudWatch Alarm tự động kích hoạt tăng số instance khi độ trễ vượt ngưỡng, và bật auto-scaling cho SageMaker endpoint để xử lý đỉnh tải.

Vì sao đúng

Đề nêu hai vấn đề và một yêu cầu, và C xử lý cả ba: | Yếu tố | Cơ chế | |---|---| | Độ trễ tăng lúc cao điểm | auto-scaling thêm instance | | Request bị bỏ do thiếu năng lực | cùng cơ chế | | Giám sát để phát hiện | CloudWatch metric + alarm |

Nguyên nhân gốc là xếp hàng, và auto-scaling giải quyết trực tiếp:

Đỉnh tải với số instance cố định:
  Request đến nhanh hơn khả năng xử lý
    → hàng đợi dài ra
    → độ trễ tăng
    → vượt timeout → request bị bỏ

Auto-scaling:
  Metric vượt mục tiêu → thêm instance
    → hàng đợi ngắn lại → độ trễ về bình thường

autoscaling.put_scaling_policy(
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 1000.0,
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance'},
        'ScaleOutCooldown': 60,      # lên NHANH
        'ScaleInCooldown': 300})     # xuống CHẬM

Và vế giám sát là phần không thể thiếu: nó vừa kích hoạt auto-scaling, vừa cho biết cơ chế có hoạt động không. Ba metric trong đáp án phục vụ ba mục đích khác nhau: | Metric | Cho biết | |---|---| | ModelLatency | model xử lý có chậm không | | Invocation5XXErrors | request có bị bỏ không | | CPU utilization | tài nguyên có bị nghẽn không |

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

  • A. Giám sát THỦ CÔNG qua SageMaker console và tăng kích thước instance bằng tay mỗi khi phát hiện độ trễ — đây là phương án gần nhất về mặt "có làm gì đó", nhưng nó không khả thi: đỉnh tải đến trong vài phút, và không ai canh 24/7. Trái yêu cầu "MOST EFFECTIVE".
  • D. Dùng Model Monitor theo dõi hiệu năng và phát hiện data drift, điều chỉnh siêu tham số để giảm độ trễ và cải thiện khả năng mở rộng — sai công cụ và sai cách chữa: Model Monitor giám sát chất lượng dự đoán, không giám sát độ trễ. Và siêu tham số ảnh hưởng độ chính xác, không ảnh hưởng khả năng co giãn.
  • B. Chuyển sang kiến trúc serverless với Lambda để loại bỏ vấn đề độ trễ, dùng CloudFront cache kết quả suy luận — hai vấn đề: Lambda có cold start (rủi ro cho phát hiện gian lận thời gian thực) và giới hạn kích thước model; và cache kết quả suy luận gian lận là vô nghĩa — mỗi giao dịch là duy nhất, tỷ lệ trúng cache gần bằng không.

Ghi nhớ

Chẩn đoán độ trễ của SageMaker endpoint: | Triệu chứng | Nguyên nhân | Cách chữa | |---|---|---| | Độ trễ TĂNG THEO TẢI | thiếu instance — xếp hàng | auto-scaling ← câu này | | Độ trễ cao KỂ CẢ khi rảnh | instance quá nhỏ cho model | instance lớn hơn hoặc GPU | | OverheadLatency cao | payload lớn, vấn đề mạng | giảm payload |

Cách phân biệt hai dòng đầu: xem ModelLatency ở thời điểm ít request. Nếu nó thấp mà độ trễ đầu-cuối cao, vấn đề là xếp hàng — auto-scaling giải quyết được.

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

Bốn tham số auto-scaling cần đặt đúng: | Tham số | Ảnh hưởng | |---|---| | MinCapacity | ≥ 2 để chịu được mất một AZ | | MaxCapacity | trần chi phí | | TargetValue | quá cao thì phản ứng chậm | | Cooldown lên < xuống | tránh dao động |

Và một giới hạn quan trọng: auto-scaling mất vài phút để instance mới sẵn sàng. Với đỉnh tải dựng đứng, kết hợp thêm scheduled scaling — nâng MinCapacity từ trước cho những khung giờ đã biết (giờ mua sắm cao điểm, cuối tháng). Đây là mẫu thường dùng nhất trong hệ thống tài chính, nơi mẫu lưu lượng khá dự đoán được.

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

You are preparing a dataset for training a machine learning model using SageMaker Data Wrangler. The dataset has several missing values spread across different columns, and these columns contain numeric data. Before training the model, it is essential to handle these missing values to ensure the model performs optimally. The goal is to replace the missing values in each numeric column with the mean of that column.

Which transformation in SageMaker Data Wrangler should you apply to replace the missing values in numeric columns with the mean of those columns?

  1. A

    Encode
  2. B

    Scale
  3. C

    Impute
  4. D

    Drop
Xem giải thích

Đáp án

C — Impute.

Vì sao đúng

Đề mô tả chính xác định nghĩa của imputation: thay giá trị thiếu bằng một giá trị suy ra — ở đây là trung bình của cột.

Trong Data Wrangler, transform "Impute" cho phép chọn chiến lược: | Chiến lược | Dùng khi | |---|---| | Mean (trung bình) | dữ liệu số, phân bố gần đối xứng ← câu này | | Median (trung vị) | dữ liệu số CÓ NGOẠI LAI | | Mode (giá trị phổ biến nhất) | dữ liệu phân loại | | Constant | giá trị cố định do bạn khai |

Vì sao trung vị thường an toàn hơn trung bình:

Cột "thu nhập" có một giá trị ngoại lai rất lớn:
  [30, 35, 40, 45, 10000]
  Trung bình = 2.030   ← bị ngoại lai kéo lệch
  Trung vị   = 40      ← phản ánh đúng hơn

Đề nói rõ dùng mean, nên đáp án là Impute với chiến lược mean — nhưng trong thực tế nên kiểm tra ngoại lai trước.

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

  • D. Drop — đây là phương án gần nhất về mặt "cùng nhóm xử lý giá trị thiếu", nhưng nó XOÁ dòng hoặc cột có giá trị thiếu, không điền vào. Với giá trị thiếu rải rác ở nhiều cột, drop có thể mất phần lớn dữ liệu: nếu mỗi cột thiếu 5% và có 10 cột, khoảng 40% số dòng sẽ có ít nhất một giá trị thiếu.
  • A. Encode — mã hoá dữ liệu phân loại thành số (one-hot, ordinal). Không liên quan tới giá trị thiếu.
  • B. Scale — chuẩn hoá thang đo của dữ liệu số (standardization, min-max). Cũng không xử lý giá trị thiếu. (Và về thứ tự: impute trước, scale sau — nếu scale trước thì giá trị thiếu vẫn thiếu, và tham số scale bị tính từ dữ liệu không đầy đủ.)

Ghi nhớ

Ba nhóm transform xử lý dữ liệu bẩn trong Data Wrangler: | Nhóm | Xử lý | |---|---| | Handle missing (Impute / Drop) | giá trị thiếu | | Handle outliers (Filter) | ngoại lai | | Handle duplicates | dòng trùng |

Ba loại giá trị thiếu — cách xử lý khác nhau: | Loại | Nghĩa | Xử lý | |---|---|---| | MCAR | thiếu hoàn toàn ngẫu nhiên | điền hoặc bỏ đều được | | MAR | thiếu phụ thuộc đặc trưng khác | điền CÓ ĐIỀU KIỆN | | MNAR | thiếu phụ thuộc chính giá trị bị thiếu | tạo cờ "đã thiếu" làm đặc trưng |

Loại thứ ba đáng chú ý và hay bị xử lý sai: nếu bệnh nhân nặng hơn thì hay thiếu kết quả xét nghiệm, thì bản thân việc thiếu mang thông tin — điền bừa vào là xoá mất tín hiệu đó. Cách đúng:

① Tạo cột mới:  xet_nghiem_bi_thieu = 1 nếu thiếu, 0 nếu có
② Rồi mới điền giá trị vào cột gốc
→ model học được cả hai thông tin

Bốn chiến lược điền, theo mức độ tinh vi: | Chiến lược | Đặc điểm | |---|---| | Trung bình / trung vị / mode | đơn giản, nhanh — mất phương sai | | Điền theo nhóm | trung bình trong cùng phân khúc — chính xác hơn | | KNN imputation | dựa trên các mẫu tương tự | | Model-based (MICE) | dự đoán giá trị thiếu bằng model |

Và một quy tắc bắt buộc giống như với chuẩn hoá:

Tính tham số điền (trung bình, trung vị) từ tập HUẤN LUYỆN, rồi áp lại cho tập kiểm chứng, kiểm thử và dữ liệu suy luận.

Tính lại trung bình từ mỗi lô dữ liệu mới là gây training–serving skew — cùng lỗi đã bàn ở #6585.

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

A retail company has developed a recommendation ML model to enhance customer experience on its platform. Before fully deploying the model in production, the company wants to perform online validation by routing 20% of the traffic to the new model while the remaining traffic continues to use the existing model.

Which solution will implement the online validation with minimal operational overhead?

  1. A

    Leverage production variants feature to add the new model into the existing SageMaker endpoint. Assign a weight of 0.2 to the new model variant and use Amazon CloudWatch to monitor the number of invocations
  2. B

    Leverage shadow variants feature to add the new model into the existing SageMaker endpoint. Assign a weight of 0.2 to the new model variant and use Amazon CloudWatch to monitor the number of invocations
  3. C

    Leverage production variants feature to add the new model into the existing SageMaker endpoint. Assign a weight of 20 to the new model variant and use Amazon CloudWatch to monitor the number of invocations
  4. D

    Choose canary traffic shifting in SageMaker and configure the capacity_percent parameter to 20%. Set up Amazon CloudWatch alarms to monitor the endpoint's metrics
Xem giải thích

Đáp án

A — Dùng production variants thêm model mới vào endpoint SageMaker hiện có; gán trọng số 0,2 cho variant model mới và dùng CloudWatch theo dõi số lời gọi.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: định tuyến 20% lưu lượng sang model mới, phần còn lại giữ model cũ, với công sức vận hành ít nhất.

Production variants là cơ chế được thiết kế chính xác cho việc này:

ProductionVariants=[
    {'VariantName': 'model-hien-tai', 'ModelName': 'model-v1',
     'InitialInstanceCount': 4, 'InstanceType': 'ml.m5.xlarge',
     'InitialVariantWeight': 0.8},
    {'VariantName': 'model-moi', 'ModelName': 'model-v2',
     'InitialInstanceCount': 1, 'InstanceType': 'ml.m5.xlarge',
     'InitialVariantWeight': 0.2}]

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cùng MỘT endpoint | client không đổi gì — vẫn gọi cùng URL | | Chia lưu lượng chính xác theo trọng số | SageMaker lo việc định tuyến | | Metric tách theo VariantName | so sánh trực tiếp trong CloudWatch |

Về giá trị trọng số — điểm phân biệt với phương án C: trọng số là TƯƠNG ĐỐI, không phải phần trăm tuyệt đối:

Trọng số 0,8 và 0,2  →  tỷ lệ 4:1  →  80% / 20%  ✅
Trọng số 80 và 20    →  tỷ lệ 4:1  →  80% / 20%  ✅ (cũng đúng)
Trọng số 1 và 0,2    →  tỷ lệ 5:1  →  ~83% / ~17%

Cả 0,8/0,2 lẫn 80/20 đều cho cùng kết quả — nhưng phương án C chỉ nêu trọng số 20 cho model mới mà không nói trọng số của model cũ, nên tỷ lệ không xác định.

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

  • C. Dùng production variants, gán trọng số 20 cho variant model mới — đây là phương án gần nhất và cùng cơ chế đúng, nhưng nó không xác định được tỷ lệ: nếu model cũ có trọng số 1, thì model mới nhận 95% lưu lượng — ngược hẳn ý định. Trọng số chỉ có nghĩa khi biết cả hai giá trị.
  • B. Dùng shadow variants thêm model mới vào endpoint, gán trọng số 0,2 — shadow variant không phục vụ khách hàng: nó nhận BẢN SAO của lưu lượng và kết quả bị vứt bỏ. Đề nói rõ muốn "route 20% of the traffic to the new model" — tức là khách hàng thật sự nhận kết quả model mới. (Shadow testing là công cụ tốt cho bước trước đó — xem #6551.)
  • D. Chọn canary traffic shifting và cấu hình capacity_percent = 20% — sai mục đích: canary traffic shifting là một chế độ của blue/green deployment, dùng để THAY THẾ model cũ dần dần — nó sẽ tự động chuyển sang 100% sau khi qua giai đoạn canary. Đề muốn giữ song song để so sánh, không phải thay thế.

Ghi nhớ

Bốn cơ chế đưa model mới ra production — phân biệt cho rõ: | Cơ chế | Khách hàng nhận kết quả model mới? | Mục đích | |---|---|---| | Shadow variant | ❌ kết quả bị vứt bỏ | kiểm chứng kỹ thuật, rủi ro BẰNG KHÔNG | | Production variant | ✅ theo trọng số | A/B test — SO SÁNH | | Blue/green (canary) | ✅ tăng dần tới 100% | THAY THẾ an toàn | | Multi-model endpoint | — | tiết kiệm tài nguyên, không liên quan |

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 "Tôi chỉ muốn kiểm chứng, chưa dám cho khách thấy?" → shadow

Quy trình phát hành đầy đủ dùng cả ba theo thứ tự:

① Shadow testing   → model mới chạy ổn không? độ trễ thế nào?
② Production variant 20%  → chỉ số nghiệp vụ có tốt hơn không?
③ Blue/green 100%  → thay thế, giữ đường lui

Ba điểm về production variant: | Điểm | Chi tiết | |---|---| | Trọng số là tương đối | tỷ lệ = trọng số này / tổng trọng số | | Đổi trọng số không cần triển khai lại | UpdateEndpointWeightsAndCapacities | | Metric tách theo VariantName | so sánh trực tiếp trong CloudWatch |

Dòng giữa hữu ích cho việc tăng dần: bắt đầu 5%, đo, tăng lên 20%, đo tiếp — mỗi lần chỉ là một lời gọi API.

Và một lưu ý về chỉ số cần đo: số lời gọi (như đáp án nêu) chỉ xác nhận việc chia lưu lượng hoạt động đúng. Để quyết định model nào tốt hơn, cần chỉ số NGHIỆP VỤ — tỷ lệ nhấp, doanh thu, mức độ tương tác — chứ không phải chỉ số kỹ thuật.