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

Tìm thấy 195 câu.

Câu 51 ML Model Development

You are a data scientist at a credit risk management company building a machine learning model to predict loan defaults. To ensure transparency and regulatory compliance, you need to explain how the model makes its predictions, particularly for high-stakes decisions such as loan approvals or rejections. The company wants a detailed understanding of the influence of individual features on the model’s predictions for specific customers, as well as an overall view of how features impact the model's predictions across the entire dataset.

Which of the following explanations BEST describes the differences between Shapley values and Partial Dependence Plots (PDP) in the context of model explainability, and how you might use them for this purpose?

  1. A

    Shapley values and PDP are both global explainability methods that show the average effect of features on model predictions. Use either method to understand overall feature importance, but Shapley values are computationally less expensive than PDP
  2. B

    Shapley values provide a local explanation by quantifying the contribution of each feature to the prediction for a specific instance, while PDP provides a global explanation by showing the marginal effect of a feature on the model’s predictions across the dataset. Use Shapley values to explain individual predictions and PDP to understand the model's behavior at a dataset level
  3. C

    Shapley values provide a global view of the model’s behavior by measuring the average effect of each feature across all instances, while PDP offers a local view by showing the effect of a single feature on the model’s prediction for a specific instance. Use Shapley values to understand overall feature importance and PDP to interpret individual predictions
  4. D

    Shapley values provide a visual interpretation of feature importance using plots, while PDP provides numeric values indicating the marginal contribution of features to the model's predictions. Use Shapley values for visual analysis and PDP for quantitative analysis
Xem giải thích

Đáp án

B — Shapley values cho giải thích CỤC BỘ — định lượng đóng góp của từng đặc trưng vào dự đoán của một trường hợp cụ thể; PDP cho giải thích TOÀN CỤC — cho thấy ảnh hưởng biên của một đặc trưng lên dự đoán trên toàn bộ tập dữ liệu.

Vì sao đúng

Đề nêu hai nhu cầu khác nhau, và mỗi công cụ phục vụ một nhu cầu: | Nhu cầu | Công cụ | |---|---| | "ảnh hưởng của từng đặc trưng lên dự đoán cho KHÁCH HÀNG CỤ THỂ" | Shapley values | | "cái nhìn tổng thể về ảnh hưởng của đặc trưng TRÊN TOÀN BỘ dữ liệu" | PDP |

Shapley values — cục bộ, cho từng dự đoán:

Khách hàng #4821 bị TỪ CHỐI vay. Vì sao?
  Điểm cơ sở (trung bình mọi khách):        0,35
  + tỷ lệ nợ/thu nhập cao        →  +0,28
  + có 3 lần trễ hạn 12 tháng qua →  +0,19
  − thu nhập ổn định 5 năm        →  −0,08
  ─────────────────────────────────────────
  Điểm rủi ro cuối:                          0,74  → từ chối

Đây chính là thứ cần khi phải giải thích cho một khách hàng cụ thể vì sao họ bị từ chối — và nhiều quy định về tín dụng yêu cầu chính điều này.

Đặc tính toán học đáng nhớ: các giá trị Shapley cộng lại đúng bằng chênh lệch giữa dự đoán và giá trị cơ sở. Không có phần dư không giải thích được.

PDP — toàn cục, cho một đặc trưng:

Ảnh hưởng của "tỷ lệ nợ/thu nhập" lên xác suất vỡ nợ:

xác suất │        ╱────
         │      ╱
         │  ───╱
         └──────────────  tỷ lệ nợ/thu nhập
           0.2  0.4  0.6

Nó cho thấy hình dạng của quan hệ — tuyến tính, phi tuyến, có ngưỡng — trên toàn bộ tập dữ liệu.

Hai công cụ trả lời hai câu hỏi khác nhau, và tổ chức tín dụng cần cả hai: PDP để hiểu và kiểm chứng model nói chung, Shapley để giải thích từng quyết định.

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

  • C. Shapley cho cái nhìn TOÀN CỤC, PDP cho cái nhìn CỤC BỘ — đây là phương án gần nhất và đảo ngược hoàn toàn hai vai trò. (Có một sắc thái: giá trị Shapley có thể tổng hợp lên thành cái nhìn toàn cục bằng cách lấy trung bình trị tuyệt đối qua nhiều mẫu — nhưng bản chất của nó là cục bộ, còn PDP thì luôn là toàn cục.)
  • A. Cả hai đều là phương pháp toàn cục, và Shapley rẻ hơn PDP về tính toán — sai hai chỗ: Shapley bản chất là cục bộ, và Shapley ĐẮT hơn PDP đáng kể (tính chính xác đòi xét mọi tổ hợp đặc trưng, nên thực tế phải dùng xấp xỉ như KernelSHAP hay TreeSHAP).
  • D. Shapley cho diễn giải bằng BIỂU ĐỒ, PDP cho giá trị SỐ — cả hai đều có cả biểu đồ lẫn số. Sự khác biệt nằm ở phạm vi (cục bộ hay toàn cục), không ở hình thức trình bày.

Ghi nhớ

Hai loại giải thích — phân biệt bằng câu hỏi: | Loại | Trả lời | |---|---| | Cục bộ (local) | "Vì sao model dự đoán như vậy cho TRƯỜNG HỢP NÀY?" | | Toàn cục (global) | "Model nói chung dựa vào những gì?" |

Các kỹ thuật giải thích: | Kỹ thuật | Phạm vi | |---|---| | SHAP | cục bộ (tổng hợp lên được thành toàn cục) | | LIME | cục bộ | | PDP | toàn cục | | ICE plot | cục bộ — PDP cho từng mẫu riêng | | Feature importance | toàn cục, thô hơn |

ICE plot đáng biết như một bổ sung cho PDP: PDP lấy trung bình qua mọi mẫu, nên nó che mất trường hợp đặc trưng ảnh hưởng ngược chiều ở các nhóm khác nhau. ICE vẽ từng đường riêng và lộ ra điều đó.

Ba lý do cần giải thích được trong tín dụng: | Lý do | Chi tiết | |---|---| | Yêu cầu pháp lý | nhiều nơi buộc phải nêu lý do từ chối cấp tín dụng | | Phát hiện thiên lệch | thấy model đang dựa vào đặc trưng thay thế cho thuộc tính nhạy cảm | | Gỡ 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 |

SageMaker Clarify cung cấp cả SHAP lẫn PDP dựng sẵn, và có thể chạy như một ProcessingStep trong pipeline — nên báo cáo giải thích được sinh tự động cho mỗi phiên bản model.

Và một cảnh báo về SHAP: giá trị Shapley cho biết đặc trưng ĐÓNG GÓP thế nào vào dự đoán, không cho biết QUAN HỆ NHÂN QUẢ. Một đặc trưng có SHAP cao không có nghĩa thay đổi nó sẽ thay đổi kết quả thực tế — nó chỉ nghĩa là model đang dựa vào nó.

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

A financial services company uses Amazon SageMaker to develop and register machine learning (ML) models for various business needs, such as fraud detection, risk assessment, and customer segmentation. These models are stored in model groups within the SageMaker Model Registry. The data science team is categorized into three specialized groups based on their areas of focus: fraud detection models, risk assessment models, and customer segmentation models. An ML engineer needs to implement a solution to organize the existing models into these three business categories to improve discoverability at scale, while ensuring the integrity of the model artifacts and their existing groupings remains unaffected.

Which solution will meet these requirements?

  1. A

    Use SageMaker Model Registry collections to group existing model groups into high-level categories, such as fraud detection, risk assessment, and customer segmentation
  2. B

    Move models into newly created SageMaker model groups for fraud detection, risk assessment, and customer segmentation, reassigning them from their current groups
  3. C

    Use SageMaker Feature Store to tag models with metadata for fraud detection, risk assessment, and customer segmentation. Filter models using queries on the Feature Store.
  4. D

    Attach custom tags to each model artifact in the SageMaker Model Registry to specify their category and filter models based on tags
Xem giải thích

Đáp án

A — Dùng SageMaker Model Registry collections để nhóm các model group hiện có thành các danh mục cấp cao như phát hiện gian lận, đánh giá rủi ro và phân khúc khách hàng.

Vì sao đúng

Đề nêu ba yêu cầu, và cái quyết định là ràng buộc cuối: | Yêu cầu | Cơ chế | |---|---| | Tổ chức model theo ba danh mục nghiệp vụ | collections | | Cải thiện khả năng tìm kiếm ở quy mô | phân cấp hai tầng | | KHÔNG ảnh hưởng artifact và nhóm hiện có | collections là lớp TỔ CHỨC, không di chuyển gì |

Collections là một lớp phân cấp nằm TRÊN model group:

Collection: "Phát hiện gian lận"
  ├─ Model group: "gian-lan-the-tin-dung"
  │     ├─ version 1, 2, 3
  ├─ Model group: "gian-lan-chuyen-khoan"
  └─ Model group: "gian-lan-tai-khoan-moi"

Collection: "Đánh giá rủi ro"
  ├─ Model group: "rui-ro-tin-dung"
  └─ Model group: "rui-ro-thanh-khoan"

Điểm mấu chốt: collection chỉ THAM CHIẾU tới model group, không di chuyển chúng. Nên: | Đảm bảo | Chi tiết | |---|---| | Artifact không đụng tới | vẫn nằm nguyên chỗ trên S3 | | Nhóm hiện có không đổi | version, lịch sử, phê duyệt giữ nguyên | | Đảo ngược được | gỡ khỏi collection không mất gì |

Đó chính là ý của "ensuring the integrity of the model artifacts and their existing groupings remains unaffected".

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

  • D. Gắn custom tag cho từng model artifact trong Model Registry để chỉ danh mục, rồi lọc theo tag — đây là phương án gần nhất và hoạt động được ở quy mô nhỏ, nhưng nó thua ở ba điểm: tag không tạo phân cấp (chỉ là nhãn phẳng), phải gắn cho từng model thay vì một lần cho cả group, và không có giao diện duyệt theo danh mục — bạn phải nhớ đúng chuỗi tag để lọc.
  • B. Chuyển model sang các model group MỚI cho ba danh mục, gán lại từ nhóm hiện tại — vi phạm thẳng ràng buộc: "reassigning them from their current groups" chính là thay đổi cấu trúc hiện có. Và nó phá vỡ lịch sử phiên bản: các version trong group cũ không mang sang được.
  • C. Dùng Feature Store gắn metadata cho model rồi lọc bằng truy vấn — sai công cụ hoàn toàn: Feature Store lưu đặc trưng dữ liệu, không lưu metadata model. Nó không có khái niệm model nào cả.

Ghi nhớ

Ba tầng tổ chức của SageMaker Model Registry: | Tầng | Chứa gì | |---|---| | Collection | nhóm các model group — danh mục nghiệp vụ | | Model group | các phiên bản của cùng một bài toán | | Model package version | một phiên bản cụ thể, bất biến |

Ba cách tổ chức model và khi nào dùng: | Cách | Đặc điểm | |---|---| | Collection | phân cấp, duyệt được, không đụng dữ liệu | | Tag | nhãn phẳng, linh hoạt, lọc được | | Quy ước đặt tên | đơn giản nhất, dễ lệch nhất |

Collection và tag không loại trừ nhau — mẫu tốt là dùng collection cho phân cấp chính (theo lĩnh vực nghiệp vụ) và tag cho các chiều cắt ngang (môi trường, chủ sở hữu, mức tuân thủ).

Nguyên tắc thiết kế rút ra từ câu này:

Khi cần tổ chức lại mà không được phá vỡ cấu trúc hiện có, tìm cơ chế THAM CHIẾU thay vì DI CHUYỂN.

Điều này đúng cho nhiều tình huống: alias thay vì đổi tên index, symlink thay vì di chuyển tệp, collection thay vì gán lại group.

Và ba thứ nên đi kèm mỗi model group để tìm kiếm thật sự hiệu quả ở quy mô: | Thứ | Vì sao | |---|---| | Mô tả rõ ràng | tên group thường quá ngắn để hiểu | | Tag chủ sở hữu | biết hỏi ai khi có vấn đề | | Model card | mục đích sử dụng, giới hạn, chỉ số |

Với hàng chục model trong một tổ chức tài chính, thiếu ba thứ này thì việc "cải thiện khả năng tìm kiếm" chỉ giải quyết được một nửa vấn đề.

Câu 53 ML Model Development

An ML engineer is training a time series forecasting model using a recurrent neural network (RNN) to predict electricity demand for a utility company. The model is trained using stochastic gradient descent (SGD) as the optimizer. During training, the engineer notices the following:

The training loss and validation loss remain high.

The loss values oscillate, decreasing for a few epochs and then increasing again before repeating the cycle.

The ML engineer needs to resolve this issue to stabilize the training process and improve model performance. What should the ML engineer do to improve the training process?

  1. A

    Apply dropout regularization to the RNN layers to improve generalization and reduce oscillations in the loss
  2. B

    Reduce the learning rate to allow the gradient updates to converge more smoothly and prevent oscillations in the loss values
  3. C

    Increase the number of training epochs to give the model more time to learn the patterns in the data
  4. D

    Increase the learning rate to allow the gradient updates to converge more smoothly and prevent oscillations in the loss values
Xem giải thích

Đáp án

B — Giảm learning rate để các bước cập nhật gradient hội tụ mượt hơn và tránh dao động trong giá trị loss.

Vì sao đúng

Đề mô tả hai triệu chứng đi cùng nhau, và đó là chữ ký kinh điển của learning rate quá lớn: | Triệu chứng | Ý nghĩa | |---|---| | Loss huấn luyện VÀ loss kiểm chứng đều cao | model chưa học được (không phải overfitting) | | Loss dao động — giảm vài epoch rồi tăng lại, lặp lại | bước nhảy quá lớn, vượt qua điểm cực tiểu |

Trực quan về điều đang xảy ra:

Learning rate QUÁ LỚN:
   loss │ ╲    ╱╲    ╱╲
        │  ╲  ╱  ╲  ╱  ╲     ← nhảy qua nhảy lại quanh đáy
        │   ╲╱    ╲╱    ╲
        └──────────────────  epoch

Learning rate PHÙ HỢP:
   loss │╲
        │ ╲___
        │     ╲____          ← giảm đều rồi ổn định
        └──────────────────  epoch

Mỗi bước cập nhật là θ ← θ − η·∇L. Nếu η (learning rate) quá lớn, bước nhảy vượt qua đáy và hạ cánh ở phía bên kia — cao hơn chỗ vừa rời đi. Lặp lại chính là dao động mà đề mô tả.

Vì sao đây KHÔNG phải overfitting — điểm phân biệt quan trọng nhất của câu này: | | Overfitting | Learning rate quá lớn | |---|---|---| | Loss huấn luyện | THẤP | cao | | Loss kiểm chứng | cao | cao | | Hình dạng | hai đường tách xa dần | cả hai cùng dao động |

Đề nói rõ cả hai đều cao — nên các kỹ thuật chống overfitting (dropout) không giải quyết được gì.

Và RNN đặc biệt nhạy với learning rate vì gradient được lan truyền ngược qua nhiều bước thời gian, dễ khuếch đại.

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

  • A. Áp dụng dropout cho các tầng RNN để cải thiện tổng quát hoá và giảm dao động — đây là phương án gần nhất và chẩn đoán sai bệnh: dropout chống overfitting, nhưng triệu chứng ở đây là cả hai loss đều cao — model đang chưa học được, không phải học quá mức. Thêm dropout sẽ làm nó học được còn ít hơn.
  • D. TĂNG learning rate để bước cập nhật hội tụ mượt hơn — ngược hoàn toàn: tăng learning rate làm dao động mạnh hơn, và có thể dẫn tới phân kỳ. (Phần mô tả "hội tụ mượt hơn" giống hệt đáp án B — đây là bẫy chỉ khác một từ.)
  • C. Tăng số epoch để model có thêm thời gian học — không giải quyết gì: dao động là có tính chu kỳ, nên chạy thêm 100 epoch chỉ cho thêm 100 chu kỳ dao động. Thời gian không sửa được bước nhảy quá lớn.

Ghi nhớ

Chẩn đoán qua đường cong loss — bảng này rất hay dùng: | Triệu chứng | Nguyên nhân | Cách chữa | |---|---|---| | Cả hai loss cao, dao động | learning rate quá lớn | giảm learning rate | | Cả hai loss cao, phẳng lì | learning rate quá nhỏ, hoặc model quá đơn giản | tăng LR, tăng năng lực model | | Train thấp, validation cao và tăng | overfitting | dropout, early stopping, augmentation | | Loss thành NaN | gradient bùng nổ | gradient clipping, giảm LR | | Loss giảm rồi đứng yên sớm | mắc cực tiểu cục bộ | đổi optimizer, warm restart |

Ba kỹ thuật quản lý learning rate: | Kỹ thuật | Chi tiết | |---|---| | Learning rate schedule | giảm dần theo epoch: step decay, cosine annealing | | Adaptive optimizer | Adam, RMSprop — tự điều chỉnh theo từng tham số | | Learning rate finder | tăng dần LR và quan sát loss để tìm khoảng tốt |

Với RNN, Adam thường ổn định hơn SGD thuần — đề nói đang dùng SGD, nên đổi sang Adam là một cải tiến hợp lý bên cạnh việc giảm learning rate.

Và ba vấn đề riêng của RNN cần biết: | Vấn đề | Cách chữa | |---|---| | Vanishing gradient | dùng LSTM hoặc GRU thay RNN thuần | | Exploding gradient | gradient clipping — giới hạn chuẩn của gradient | | Chuỗi quá dài | truncated backpropagation through time |

Gradient clipping đáng bật mặc định cho mọi RNN:

torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)

Nó ngăn một batch bất thường làm hỏng toàn bộ quá trình huấn luyện — rẻ và gần như không có nhược điểm.

Câu 54 Deployment and Orchestration of ML Workflows

You are working as a machine learning engineer for a startup that provides image recognition services. The service is currently in its beta phase, and the company expects varying levels of traffic, with some days having very few requests and other days experiencing sudden spikes. The company wants to minimize costs during low-traffic periods while still being able to handle large, infrequent spikes of requests efficiently. Given these requirements, you are considering using Amazon SageMaker for your deployment.

Which of the following statements is the BEST recommendation for the given scenario?

  1. A

    Use Batch transform to run inference with Amazon SageMaker that minimizes costs during low-traffic periods while managing large infrequent spikes of requests efficiently
  2. B

    Use Amazon SageMaker Serverless Inference that minimizes costs during low-traffic periods while managing large infrequent spikes of requests efficiently
  3. C

    Use Amazon SageMaker Asynchronous Inference that minimizes costs during low-traffic periods while managing large infrequent spikes of requests efficiently
  4. D

    Use Amazon SageMaker Real-time Inference that minimizes costs during low-traffic periods while managing large infrequent spikes of requests efficiently
Xem giải thích

Đáp án

B — Dùng Amazon SageMaker Serverless Inference, vừa giảm chi phí trong giai đoạn ít lưu lượng vừa xử lý hiệu quả các đợt tăng đột biến không thường xuyên.

Vì sao đúng

Đề nêu ba đặc điểm, và Serverless Inference khớp cả ba: | Đặc điểm | Serverless Inference | |---|---| | Có ngày rất ít request | co giãn về 0 — KHÔNG trả tiền khi không có request | | Có ngày tăng đột biến | tự co giãn theo lưu lượng | | Đang ở giai đoạn beta, muốn tiết kiệm | trả theo thời gian tính toán thật sự dùng |

Điểm mấu chốt là khả năng co về 0 — đây là điều mà endpoint real-time không làm được:

Real-time endpoint:  trả tiền 24/7 kể cả 0 request
                     → ngày ít lưu lượng vẫn tốn đầy đủ

Serverless:          0 request = 0 chi phí
                     → chỉ trả cho thời gian thật sự xử lý

Với một startup đang trong giai đoạn beta và lưu lượng thất thường, khác biệt này rất lớn về mặt tài chính.

Đánh đổi cần biết: cold start. Khi không có request một thời gian, request tiếp theo phải chờ khởi tạo (thường vài giây tuỳ kích thước model). Đề nói dịch vụ đang ở beta và ưu tiên giảm chi phí — nên đánh đổi này chấp nhận được.

Và nếu về sau cần giảm cold start, Provisioned Concurrency cho Serverless Inference giữ sẵn một số phiên bản ấm — nhưng khi đó bạn bắt đầu trả tiền cho phần giữ sẵn.

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

  • C. Asynchronous Inference, giảm chi phí lúc ít lưu lượng và xử lý các đợt tăng lớn — đây là phương án gần nhất và nó cũng co giãn về 0, nhưng nó thay đổi mô hình tương tác: request được xếp hàng, kết quả trả về S3, client phải chờ thông báo. Với dịch vụ nhận diện ảnh mà người dùng đang chờ kết quả, đó là trải nghiệm rất khác. (Async đúng khi payload lớn hoặc xử lý mất nhiều phút — không phải trường hợp này.)
  • A. Batch transform, giảm chi phí lúc ít lưu lượng và xử lý các đợt tăng lớn — không phải suy luận theo yêu cầu: batch transform chạy theo job trên một tệp dữ liệu có sẵn. Nó không phục vụ được request đến bất kỳ lúc nào.
  • D. Real-time Inference, giảm chi phí lúc ít lưu lượng — mâu thuẫn với chính nó: endpoint real-time luôn chạy và luôn tính tiền, kể cả khi không có request nào. Nó không giảm được chi phí trong giai đoạn ít lưu lượng.

Ghi nhớ

Bốn kiểu suy luận của SageMaker — bảng nền tảng: | Kiểu | Độ trễ | Co về 0 | Dùng khi | |---|---|---|---| | Real-time | mili giây, ổn định | ❌ | lưu lượng liên tục, cần độ trễ ổn định | | Serverless | có cold start | ✅ | lưu lượng thưa hoặc thất thường ← câu này | | Asynchronous | phút tới giờ | ✅ | payload lớn, xử lý lâu | | Batch transform | theo job | ✅ | xử lý cả tệp, không cần endpoint |

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

Người dùng đang chờ kết quả ngay?
  ├─ Có, lưu lượng đều      → Real-time
  ├─ Có, lưu lượng thất thường → Serverless
  └─ Không
      ├─ Request đến rải rác → Asynchronous
      └─ Có sẵn cả tệp       → Batch transform

Ba giới hạn của Serverless Inference cần biết: | Giới hạn | Giá trị | |---|---| | Bộ nhớ | 1 GB – 6 GB | | GPU | KHÔNG hỗ trợ | | Concurrency tối đa | có trần theo cấu hình |

Dòng giữa quan trọng: model nhận diện ảnh cần GPU thì không dùng Serverless được. Với model nhỏ chạy CPU thì ổn — và ở giai đoạn beta, model thường chưa lớn.

Ba cách giảm cold start: | Cách | Chi tiết | |---|---| | Provisioned Concurrency | giữ sẵn N phiên bản ấm — có phí | | Giảm kích thước model | quantization, pruning | | Giảm kích thước container | ít lớp, ít thư viện |

Và một mẹo thực dụng cho giai đoạn beta: bắt đầu bằng Serverless, đo lưu lượng thật, rồi chuyển sang Real-time với auto scaling khi lưu lượng đủ đều. Điểm hoà vốn thường ở khoảng vài giờ sử dụng liên tục mỗi ngày — dưới ngưỡng đó Serverless rẻ hơn.

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

Which of the following strategies best aligns with the defense-in-depth security approach for generative AI applications on AWS?

  1. A

    Using a single authentication mechanism for all users and services accessing the AI models
  2. B

    Relying solely on data encryption to protect the AI training data
  3. C

    Implementing a single-layer firewall to block unauthorized access to the AI models
  4. D

    Applying multiple layers of security measures including input validation, access controls, and continuous monitoring to address vulnerabilities
Xem giải thích

Đáp án

D — Áp dụng nhiều lớp biện pháp bảo mật bao gồm kiểm tra đầu vào, kiểm soát truy cập và giám sát liên tục để xử lý các lỗ hổng.

Vì sao đúng

Defense in depth (phòng thủ theo chiều sâu) là nguyên tắc bảo mật nền tảng, và định nghĩa của nó chính là đáp án D:

Không lớp phòng thủ nào là hoàn hảo. Dựng nhiều lớp độc lập sao cho khi một lớp thất bại, các lớp khác vẫn giữ được.

Ba biện pháp trong đáp án đại diện cho ba tầng khác nhau: | Biện pháp | Chặn gì | |---|---| | Kiểm tra đầu vào | prompt injection, payload độc hại, dữ liệu sai định dạng | | Kiểm soát truy cập | người không có quyền, phạm vi thiệt hại khi lộ thông tin xác thực | | Giám sát liên tục | phát hiện tấn công đang diễn ra và bất thường |

Ba phương án còn lại đều mắc cùng một lỗi: chúng dựa vào một cơ chế duy nhất — và đó chính là điều defense in depth phản đối.

Kiến trúc phòng thủ nhiều lớp cho ứng dụng GenAI:

Người dùng
  ↓ ① WAF                    — IP xấu, giới hạn tần suất
  ↓ ② Xác thực và uỷ quyền   — Cognito, IAM, đặc quyền tối thiểu
  ↓ ③ Kiểm tra đầu vào       — schema, kích thước, classifier chống jailbreak
  ↓ ④ Guardrails             — nội dung độc hại, chủ đề cấm, PII
 MODEL
  ↓ ⑤ Kiểm tra đầu ra        — grounding, luật nghiệp vụ, lọc PII
  ↓ ⑥ Giám sát và ghi vết    — CloudWatch, CloudTrail, phát hiện bất thường
Người dùng

Mỗi lớp bắt được thứ lớp khác bỏ sót, và chặn càng sớm càng rẻ.

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

  • B. Chỉ dựa vào mã hoá dữ liệu để bảo vệ dữ liệu huấn luyện — đây là phương án gần nhất về mặt "có làm gì đó", nhưng mã hoá chỉ bảo vệ dữ liệu lúc lưu và lúc truyền. Nó không ngăn được người có quyền truy cập hợp lệ lạm dụng, không ngăn prompt injection, không phát hiện được gì. Và chữ "solely" là điểm loại.
  • A. Một cơ chế xác thực duy nhất cho mọi người dùng và dịch vụ truy cập model — vi phạm cả defense in depth lẫn đặc quyền tối thiểu: một cơ chế chung nghĩa là lộ một lần là lộ tất cả, và không phân biệt được quyền của người dùng cuối với quyền của dịch vụ nội bộ.
  • C. Tường lửa một lớp chặn truy cập trái phép vào model — bảo vệ chu vi mạng là một lớp, không phải toàn bộ. Nó không làm gì với tấn công đến từ người dùng hợp lệ (prompt injection), và không bảo vệ được dữ liệu bên trong.

Ghi nhớ

Defense in depth — ba nguyên tắc: | Nguyên tắc | Chi tiết | |---|---| | Nhiều lớp độc lập | thất bại của một lớp không kéo theo lớp khác | | Chặn sớm nhất có thể | càng gần cửa ngõ càng rẻ | | Giả định lớp nào cũng có thể thủng | thiết kế cho tình huống đó |

Sáu rủi ro riêng của ứng dụng GenAI và lớp phòng thủ tương ứng: | Rủi ro | Phòng thủ | |---|---| | Prompt injection | classifier đầu vào + Guardrails PROMPT_ATTACK | | Rò rỉ dữ liệu qua đầu ra | lọc PII ở đầu ra, contextual grounding | | Ảo giác | RAG + grounding check | | Lạm dụng và chi phí bùng nổ | giới hạn tần suất, ngân sách token | | Truy cập trái phép | IAM, VPC endpoint, đặc quyền tối thiểu | | Đầu độc dữ liệu huấn luyện | kiểm tra nguồn dữ liệu, Macie quét trước |

Năm trụ cột bảo mật của AWS Well-Architected áp cho GenAI: | Trụ cột | Áp dụng | |---|---| | Quản lý danh tính và truy cập | Cognito, IAM, ABAC | | Bảo vệ hạ tầng | VPC endpoint, security group, WAF | | Bảo vệ dữ liệu | KMS, Macie, che PII | | Phát hiện | CloudTrail, CloudWatch, GuardDuty | | Ứng phó sự cố | runbook, khả năng rollback |

Và một nguyên tắc thực dụng: lớp phòng thủ phải độc lập về cơ chế, không chỉ nhiều về số lượng. Ba tường lửa đặt nối tiếp nhau vẫn là một lớp — vì chúng cùng thất bại trước cùng một loại tấn công. Kiểm tra đầu vào, kiểm soát truy cập và giám sát thì thất bại theo những cách khác nhau, nên chúng bổ sung thật sự cho nhau.

Câu 56 ML Model Development

You are a data scientist at a pharmaceutical company that builds predictive models to analyze clinical trial data. Due to regulatory requirements, the company must maintain strict version control of all models used in decision-making processes. This includes tracking which data, hyperparameters, and code were used to train each model, as well as ensuring that models can be easily reproduced and audited in the future. You decide to implement a system to manage model versions and track their lifecycle effectively.

Which of the following strategies is the MOST LIKELY to ensure model versioning, repeatability, and auditability?

  1. A

    Use SageMaker Model Monitor to track the performance of models in production, ensuring that any changes in model behavior are documented for future audits
  2. B

    Leverage the SageMaker Model Registry to register, track, and manage different versions of models, capturing all relevant metadata, including data sources, hyperparameters, and training code
  3. C

    Use Amazon S3 to store each version of the model manually, tagging the stored files with metadata about the training data, hyperparameters, and code used for training
  4. D

    Create a version control system in Git for the model’s training code and configuration files, while storing the trained models in a separate S3 bucket for easy retrieval
Xem giải thích

Đáp án

B — Dùng SageMaker Model Registry để đăng ký, theo dõi và quản lý các phiên bản model, ghi lại mọi metadata liên quan gồm nguồn dữ liệu, siêu tham số và mã huấn luyện.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều là chức năng cốt lõi của Model Registry: | Yêu cầu | Cơ chế | |---|---| | Kiểm soát phiên bản nghiêm ngặt | version bất biến, tự động tăng | | Theo dõi dữ liệu, siêu tham số, mã | metadata + lineage tự động | | Tái lập và kiểm toán được | mọi thông tin nằm cùng một chỗ |

Ba loại thông tin cần cho khả năng tái lập, và Model Registry giữ đủ cả ba:

sm.create_model_package(
    ModelPackageGroupName='du-doan-thu-nghiem-lam-sang',
    InferenceSpecification={
        'Containers': [{'Image': arn_image_ecr,        # ① MÃ (trong container)
                        'ModelDataUrl': s3_artifact}]},
    ModelMetrics={'ModelQuality': {'Statistics': {...}}},
    CustomerMetadataProperties={
        'dataset_version': 's3://.../thu-nghiem-2026-q2/',  # ② DỮ LIỆU
        'git_commit': 'a3f9c21',                             # ③ MÃ NGUỒN
        'hyperparameters': json.dumps(sieu_tham_so)          # ④ SIÊU THAM SỐ
    },
    ModelApprovalStatus='PendingManualApproval')

Và lineage tự động bổ sung phần quan hệ: model này sinh ra từ training job nào, job đó đọc dataset nào — thứ mà kiểm toán viên ngành dược cần để tái dựng toàn bộ đường đi.

Điểm phân biệt với các phương án tự dựng: tính bất biến. Model package version không sửa được sau khi tạo — nên một hồ sơ kiểm toán không thể bị thay đổi về sau, dù vô tình hay cố ý. Đó là yêu cầu cứng trong ngành chịu quản lý.

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

  • D. Git quản lý phiên bản mã huấn luyện và tệp cấu hình, lưu model đã huấn luyện trong một bucket S3 riêng — đây là phương án gần nhất và là một nửa của giải pháp đúng (Git cho mã là thực hành tốt), nhưng nó thiếu liên kết: không có gì nối "model trong S3 này" với "commit Git kia" và "dataset nọ". Kiểm toán viên sẽ phải tự ghép, và việc ghép đó dựa vào trí nhớ chứ không dựa vào hệ thống.
  • C. Dùng S3 lưu THỦ CÔNG từng phiên bản model, gắn tag metadata về dữ liệu, siêu tham số và mã — "manually" là điểm yếu chính: quy ước do người đặt sẽ lệch theo thời gian, tag có giới hạn kích thước (10 tag, 256 ký tự mỗi giá trị), và không có trạng thái phê duyệt.
  • A. Dùng Model Monitor theo dõi hiệu năng model trên production, ghi lại thay đổi hành vi để kiểm toán sau này — sai giai đoạn: Model Monitor giám sát model đang chạy, nó không quản lý phiên bản và không ghi lại model được huấn luyện thế nào. Nó là công cụ bổ sung, không thay thế.

Ghi nhớ

Bốn thứ cần lưu để một model tái lập được: | Thứ | Nơi lưu | |---|---| | Mã huấn luyện | Git commit hash + container image trong ECR | | Dữ liệu | S3 URI + version của dataset | | Siêu tham số | metadata trong Model Registry | | Môi trường | container image (đã cố định phiên bản thư viện) |

Thiếu bất kỳ thứ nào thì "tái lập" chỉ là gần đúng — và trong ngành dược, gần đúng không đủ.

Ba khả năng của Model Registry cho tuân thủ: | Khả năng | Chi tiết | |---|---| | Version bất biến | tạo rồi không sửa được | | Trạng thái phê duyệt | ai duyệt, khi nào (qua CloudTrail) | | Liên kết Model Card | mục đích sử dụng, giới hạn, chỉ số |

Mẫu đầy đủ cho môi trường chịu quản lý — kết hợp bốn công cụ:

Git (mã)  →  SageMaker Pipeline (chạy)
                 ├─ Experiments (chỉ số từng lần chạy)
                 ├─ Lineage (quan hệ artifact)
                 └─ Model Registry (phiên bản + phê duyệt + model card)

Và ba chi tiết thực dụng hay bị bỏ sót: | Chi tiết | Vì sao | |---|---| | Cố định phiên bản thư viện trong container | pip install tensorflow hôm nay khác hôm qua | | Đặt version cho dataset | S3 versioning hoặc thư mục theo ngày | | Ghi cả seed ngẫu nhiên | không có seed thì không tái lập chính xác được |

Dòng đầu là nguyên nhân phổ biến nhất khiến "chạy lại đúng mã, đúng dữ liệu" vẫn cho kết quả khác — và nó chỉ lộ ra khi bạn thật sự cần tái lập, thường là lúc kiểm toán.

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

Which AWS service is used to store, share and manage inputs to Machine Learning models used during training and inference?

  1. A

    Amazon SageMaker Data Wrangler
  2. B

    Amazon SageMaker Feature Store
  3. C

    Amazon SageMaker Ground Truth
  4. D

    Amazon SageMaker Clarify
Xem giải thích

Đáp án

B — Amazon SageMaker Feature Store.

Vì sao đúng

Câu hỏi mô tả chính xác định nghĩa của Feature Store: lưu trữ, chia sẻ và quản lý đầu vào cho model ML dùng trong cả huấn luyện lẫn suy luận.

Ba từ khoá trong câu hỏi đều là chức năng cốt lõi: | Từ khoá | Feature Store | |---|---| | Store (lưu trữ) | online store + offline store | | Share (chia sẻ) | nhiều đội, nhiều model dùng chung định nghĩa đặc trưng | | Training AND inference | cùng một đặc trưng cho cả hai — đây là điểm mấu chốt |

Cụm "training and inference" là lý do tồn tại của Feature Store, vì nó giải quyết một vấn đề kinh điển:

Training–serving skew: đặc trưng lúc huấn luyện tính bằng một script, lúc suy luận tính bằng script khác — hai bên lệch nhau, và model hoạt động kém trên production mà không ai hiểu vì sao.

KHÔNG có Feature Store:
  Huấn luyện: script Spark tính "chi tiêu trung bình 30 ngày"
  Suy luận:   mã Java tính lại — làm tròn khác, xử lý null khác
              → model nhận đầu vào KHÁC với thứ nó đã học

CÓ Feature Store:
  Cả hai đọc CÙNG một đặc trưng từ cùng một nơi

Hai loại store phục vụ hai nhu cầu: | Store | Đặc điểm | Dùng cho | |---|---|---| | Online | độ trễ mili giây, chỉ bản ghi MỚI NHẤT | suy luận thời gian thực | | Offline | S3, toàn bộ lịch sử | huấn luyện, phân tích |

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

  • A. Amazon SageMaker Data Wrangler — đây là phương án gần nhất và nó TẠO RA đặc trưng, nhưng không lưu trữ và phục vụ chúng. Data Wrangler là bước trước Feature Store trong luồng làm việc, không phải thay thế.
  • C. Amazon SageMaker Ground Truth — dịch vụ gán nhãn dữ liệu (thuê người hoặc dùng active learning để tạo nhãn). Nó tạo ra nhãn, không phải đặc trưng, và không lưu trữ chúng cho suy luận.
  • D. Amazon SageMaker Clarify — dịch vụ phát hiện thiên lệch và giải thích model. Không liên quan tới lưu trữ đặc trưng.

Ghi nhớ

Vị trí của Feature Store trong luồng ML:

Dữ liệu thô
    ↓ Data Wrangler / Glue: biến đổi
FEATURE STORE  ←── nơi đặc trưng "sống"
    ├─ offline store → huấn luyện
    └─ online store  → suy luận thời gian thực

Ba vấn đề Feature Store giải quyết: | Vấn đề | Cách giải quyết | |---|---| | Training–serving skew | cùng một nguồn đặc trưng cho cả hai | | Trùng lặp công sức | nhiều đội dùng lại đặc trưng đã có | | Rò rỉ dữ liệu tương lai | time travel — lấy giá trị TẠI thời điểm sự kiện |

Vấn đề thứ ba đáng giải thích thêm vì nó tinh vi:

Sai:   dùng "tổng chi tiêu của khách" tính tại HÔM NAY
       để huấn luyện dự đoán một giao dịch từ 6 tháng trước
       → model học từ thông tin CHƯA TỒN TẠI lúc đó

Đúng:  Feature Store lấy giá trị đặc trưng TẠI thời điểm giao dịch

Đây là dạng rò rỉ dữ liệu khó phát hiện nhất, và nó khiến model đạt điểm rất cao lúc kiểm chứng rồi thất bại trên production.

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

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

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

A financial institution has deployed a machine learning model using Amazon SageMaker to predict whether credit card transactions are fraudulent. To ensure model performance remains consistent, the company configured Amazon SageMaker Model Monitor to track deviations in the model accuracy over time. The model's baseline accuracy was recorded during its initial deployment. However, after several months of operation, the model’s accuracy drops significantly despite no changes being made to the model.

What could be the reason for the reduced model accuracy?

  1. A

    Amazon SageMaker Model Monitor miscalculated the accuracy metric due to a configuration error
  2. B

    The model’s hyperparameters have automatically adjusted during inference, causing a decline in predictive accuracy
  3. C

    The deployed model’s architecture degraded over time, reducing its predictive performance
  4. D

    Concept drift occurred in the underlying customer data that was used for predictions, changing the relationship between input features and the target variable over time
Xem giải thích

Đáp án

D — Concept drift đã xảy ra trong dữ liệu khách hàng: quan hệ giữa đặc trưng đầu vào và biến mục tiêu đã thay đổi theo thời gian.

Vì sao đúng

Đề cho ba manh mối, và chúng loại trừ mọi nguyên nhân kỹ thuật: | Manh mối | Loại trừ | |---|---| | "no changes being made to the model" | không phải lỗi triển khai | | Giảm dần sau vài tháng | không phải sự cố đột ngột | | Model Monitor phát hiện được | chỉ số đúng, chỉ là kết quả xấu đi |

Còn lại một khả năng: thế giới đã thay đổi, model thì không.

Concept drift trong bối cảnh phát hiện gian lận thẻ:

Lúc huấn luyện (2024):
  "giao dịch > 5 triệu ở nước ngoài lúc 3h sáng" → khả năng cao là gian lận

Hiện tại (2026):
  ├─ kẻ gian đã ĐỔI CHIẾN THUẬT — chia nhỏ nhiều giao dịch
  ├─ khách hàng thật đi du lịch nhiều hơn, mua sắm online 24/7
  └─ CÙNG một mẫu đầu vào giờ mang ý nghĩa KHÁC

Phát hiện gian lận là lĩnh vực dễ bị concept drift nhất, vì có một yếu tố đặc biệt: đối thủ là con người có chủ đích. Kẻ gian quan sát model chặn gì và điều chỉnh để né — nên quan hệ giữa đặc trưng và nhãn thay đổi có chủ ý, không phải ngẫu nhiên.

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

  • B. Siêu tham số của model tự động điều chỉnh trong lúc suy luận, làm giảm độ chính xác — không có cơ chế nào như vậy: model đã huấn luyện là tĩnh. Trọng số và siêu tham số cố định cho tới khi bạn huấn luyện lại. Đây là mô tả một hành vi không tồn tại.
  • C. Kiến trúc model bị suy thoái theo thời gian, giảm hiệu năng dự đoán — phần mềm không "hao mòn": cùng một model, cùng một đầu vào, luôn cho cùng một đầu ra. Không có sự suy thoái vật lý nào.
  • A. Model Monitor tính sai chỉ số do lỗi cấu hình — đây là phương án gần nhất về mặt "có thể xảy ra", nhưng nó không giải thích được tính GIẢM DẦN: lỗi cấu hình cho ra số sai ngay từ đầu và ổn định, không giảm đều qua nhiều tháng. (Vẫn nên loại trừ nó khi điều tra — nhưng nó không khớp với mẫu quan sát được.)

Ghi nhớ

Bốn loại drift — phân biệt bằng cái gì thay đổi: | Loại | Cái gì thay đổi | |---|---| | Data drift (covariate shift) | phân bố ĐẦU VÀO P(X) | | Concept drift | quan hệ P(Y|X) ← câu này | | Label drift | phân bố NHÃN P(Y) | | Upstream data change | lỗi pipeline, đơn vị đo đổi |

Cách nhận biết loại nào: | Quan sát | Kết luận | |---|---| | Đầu vào đổi, độ chính xác giữ nguyên | data drift vô hại | | Đầu vào KHÔNG đổi, độ chính xác giảm | concept drift ← đề này | | Cả hai đổi | thường là cả hai loại |

Ba lĩnh vực có concept drift nhanh nhất: | Lĩnh vực | Vì sao | |---|---| | Phát hiện gian lận | kẻ gian chủ động thích nghi | | Bảo mật, lọc thư rác | cùng lý do | | Tài chính, tín dụng | biến động kinh tế | | Hành vi mua sắm | mùa vụ, xu hướng |

Ba chiến lược ứng phó: | Chiến lược | Chi tiết | |---|---| | Huấn luyện lại theo lịch | đơn giản, có thể huấn luyện lại khi chưa cần | | Huấn luyện lại khi phát hiện drift | hiệu quả hơn — Model Monitor kích hoạt | | Học trực tuyến (online learning) | cập nhật liên tục, phức tạp và rủi ro hơn |

Và một khó khăn thực tế riêng của phát hiện gian lận: nhãn thật đến rất muộn. Bạn chỉ biết một giao dịch có gian lận hay không sau khi khách khiếu nại — có thể hàng tuần sau. Nên model quality monitoring gần như không dùng được theo thời gian thực, và phải dựa vào: | Chỉ báo sớm | Ý nghĩa | |---|---| | Data drift trên đặc trưng đầu vào | mẫu giao dịch đang đổi | | Prediction drift | tỷ lệ giao dịch bị gắn cờ thay đổi bất thường | | Tỷ lệ khiếu nại | trễ nhưng là tín hiệu thật |

Dòng giữa là chỉ báo hữu ích nhất trong thực tế: nếu model đột nhiên gắn cờ ít hơn hẳn mà số khiếu nại không giảm, đó là dấu hiệu kẻ gian đã tìm được cách né.

Câu 59 Deployment and Orchestration of ML Workflows

You are an ML engineer at an e-commerce company tasked with building an automated recommendation system that scales during peak shopping seasons. The solution requires provisioning multiple compute resources, including SageMaker for model training, EC2 instances for data preprocessing, and an RDS database for storing user interaction data. You need to automate the deployment and management of these resources, ensuring that the stacks can communicate effectively. The company prioritizes infrastructure as code (IaC) to maintain consistency and scalability across environments.

Which approach is the MOST SUITABLE for automating the provisioning of compute resources and ensuring seamless communication between stacks?

  1. A

    Manually provision the SageMaker, EC2, and RDS resources using the AWS Management Console, ensuring that communication is established by manually updating security groups and networking configurations
  2. B

    Use AWS Elastic Beanstalk to deploy the entire ML solution, relying on its built-in environment management to handle the provisioning and communication between resources automatically
  3. C

    Use AWS CloudFormation with nested stacks to automate the provisioning of SageMaker, EC2, and RDS resources, and configure outputs from one stack as inputs to another to enable communication between them
  4. D

    Use AWS CDK (Cloud Development Kit) to define the infrastructure in a high-level programming language, deploying each service as an independent stack without configuring inter-stack communication
Xem giải thích

Đáp án

C — Dùng AWS CloudFormation với nested stack tự động hoá việc cấp phát SageMaker, EC2 và RDS, và cấu hình output của stack này làm input cho stack kia để chúng giao tiếp được với nhau.

Vì sao đúng

Đề nêu ba yêu cầu, và nested stack đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Tự động hoá cấp phát nhiều loại tài nguyên | CloudFormation | | Các stack giao tiếp được với nhau | Outputs → Parameters | | Hạ tầng là mã, nhất quán giữa các môi trường | template có version, chạy lại được |

Nested stack chia hạ tầng thành các module quản lý được, thay vì một template khổng lồ:

# Stack cha
Resources:
  StackMang:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.../mang.yaml

  StackCSDL:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.../rds.yaml
      Parameters:
        VpcId: !GetAtt StackMang.Outputs.VpcId       # ← output → input
        SubnetIds: !GetAtt StackMang.Outputs.SubnetIds

  StackML:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://s3.../sagemaker.yaml
      Parameters:
        DbEndpoint: !GetAtt StackCSDL.Outputs.Endpoint   # ← nối tiếp

Cơ chế Outputs → Parameters là điểm mấu chốt cho yêu cầu "ensuring the stacks can communicate": stack mạng tạo VPC và xuất ID của nó; stack RDS nhận ID đó làm tham số; stack SageMaker nhận endpoint của RDS. CloudFormation tự suy ra thứ tự triển khai từ các phụ thuộc này.

Và ba lợi ích của nested stack so với một template duy nhất: | Lợi ích | Chi tiết | |---|---| | Dùng lại được | template mạng dùng chung cho nhiều dự án | | Vượt giới hạn | một template có trần về số tài nguyên | | Cập nhật độc lập | sửa stack ML không đụng stack mạng |

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

  • D. Dùng AWS CDK định nghĩa hạ tầng bằng ngôn ngữ lập trình cấp cao, triển khai mỗi dịch vụ thành stack ĐỘC LẬP KHÔNG cấu hình giao tiếp giữa các stack — đây là phương án gần nhất và CDK thật sự là công cụ rất tốt (thậm chí thường được ưa hơn CloudFormation thuần). Nhưng nó bị loại bởi chính vế cuối: "without configuring inter-stack communication" trái thẳng yêu cầu "ensuring the stacks can communicate effectively". (CDK làm được điều đó rất dễ bằng cách truyền tham chiếu giữa các construct — phương án cố tình bỏ đi phần đó.)
  • **A. Cấp phát THỦ CÔNG qua Console, thiết lập giao tiếp bằng cách cập nhật thủ công security group và cấu hình mạng — vi phạm thẳng yêu cầu IaC, và không tái lập được giữa các môi trường.
  • B. Dùng Elastic Beanstalk triển khai toàn bộ giải pháp ML, dựa vào quản lý môi trường dựng sẵn — sai công cụ: Beanstalk dành cho ứng dụng web và worker, nó không cấp phát được SageMaker training job hay RDS như một phần của kiến trúc ML.

Ghi nhớ

Ba công cụ IaC trên AWS: | Công cụ | Đặc điểm | |---|---| | CloudFormation | YAML/JSON khai báo, nền tảng cho các công cụ khác | | CDK | ngôn ngữ lập trình (TypeScript, Python) → sinh ra CloudFormation | | Terraform | đa cloud, HCL |

CDK biên dịch xuống CloudFormation, nên mọi khả năng của CloudFormation đều dùng được — bao gồm nested stack và truyền tham chiếu giữa các stack.

Ba cách chia sẻ giá trị giữa các stack: | Cách | Đặc điểm | |---|---| | Nested stack (Outputs → Parameters) | chặt chẽ, cha điều phối con | | Cross-stack reference (Export/ImportValue) | giữa các stack độc lập | | SSM Parameter Store | linh hoạt nhất, không tạo phụ thuộc cứng |

Đánh đổi cần biết của cách thứ hai: giá trị đã export và đang được import thì KHÔNG xoá hay sửa được — bạn phải gỡ bên import trước. Điều này gây khó khi cần thay đổi hạ tầng nền. Cách thứ ba tránh được vấn đề đó nhưng mất tính kiểm tra tự động của CloudFormation.

Ba nguyên tắc chia stack: | Nguyên tắc | Chi tiết | |---|---| | Chia theo tốc độ thay đổi | mạng đổi hiếm, ứng dụng đổi thường xuyên | | Chia theo vòng đời | thứ xoá cùng nhau thì để cùng stack | | Chia theo quyền sở hữu | đội nào quản gì |

Với kiến trúc trong đề, cách chia hợp lý là: stack mạng (VPC, subnet, security group) → stack dữ liệu (RDS) → stack ML (SageMaker, EC2 tiền xử lý). Ba tầng này có tốc độ thay đổi rất khác nhau.

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

You are a Data Scientist working for an e-commerce company that is developing a machine learning model to predict whether a customer will make a purchase based on their browsing behavior. You need to evaluate the model's performance using different evaluation metrics to understand how well the model is predicting the positive class (i.e., customers who will make a purchase). The dataset is imbalanced, with a small percentage of customers making a purchase. Given this context, you must decide on the most appropriate evaluation techniques to assess your model's effectiveness and identify potential areas for improvement.

Which of the following evaluation techniques and metrics should you prioritize when assessing the performance of your model, considering the dataset's imbalance and the need for a comprehensive understanding of both false positives and false negatives? (Select two)

  1. A

    Evaluate the model using the confusion matrix, which provides insights into true positives, false positives, true negatives, and false negatives, allowing you to calculate additional metrics such as precision, recall, and F1 score
  2. B

    Prioritize Root mean squared error (RMSE) as the key metric, as it measures the average magnitude of the errors between predicted and actual values
  3. C

    Use precision and recall to focus on the model's ability to correctly identify positive cases while minimizing false positives and false negatives
  4. D

    Utilize the AUC-ROC curve to evaluate the model’s ability to distinguish between classes across various thresholds, particularly in the presence of class imbalance
  5. E

    Use accuracy as the primary metric, as it measures the percentage of correct predictions out of all predictions made by the model
Xem giải thích

Đáp án

A và C.

  • A — Dùng confusion matrix, cho biết TP, FP, TN, FN và từ đó tính được precision, recall, F1
  • C — Dùng precision và recall để tập trung vào khả năng nhận diện đúng ca dương trong khi giảm thiểu cả FP lẫn FN

Vì sao đúng

Đề nêu hai yêu cầu, và cặp A+C đáp ứng đúng cả hai: | Yêu cầu | Đáp án | |---|---| | Dữ liệu mất cân bằng | cả hai — không bị đánh lừa như accuracy | | Hiểu CẢ false positive LẪN false negative | A cho bức tranh đầy đủ, C định lượng hai loại lỗi |

A — confusion matrix là nền tảng, vì mọi chỉ số phân loại đều dẫn xuất từ nó:

                  Dự đoán MUA    Dự đoán KHÔNG MUA
Thực tế MUA           TP                 FN         ← bỏ lỡ khách hàng
Thực tế KHÔNG MUA     FP                 TN         ← quảng cáo nhầm

Nó cho thấy model sai theo kiểu nào, không chỉ sai bao nhiêu — và đó là thông tin để cải thiện.

C — precision và recall định lượng hai loại lỗi: | Chỉ số | Trả lời | Sai thì tốn gì | |---|---|---| | Precision | trong số dự đoán "sẽ mua", bao nhiêu đúng? | chi phí quảng cáo lãng phí | | Recall | trong số khách thật sự mua, bắt được bao nhiêu? | doanh thu bỏ lỡ |

Với thương mại điện tử, đánh đổi này là quyết định nghiệp vụ: chi phí hiển thị một quảng cáo thấp, nên thường ưu tiên recall — thà quảng cáo thừa còn hơn bỏ lỡ khách.

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

  • D. Dùng AUC-ROC đánh giá khả năng phân biệt giữa các lớp qua nhiều ngưỡng, đặc biệt khi có mất cân bằng lớp — đây là phương án gần nhất và AUC-ROC hữu ích thật, nhưng vế cuối là chỗ sai: ROC-AUC KHÔNG đặc biệt phù hợp với dữ liệu mất cân bằng. Ngược lại, nó có thể cho con số đẹp giả tạo vì FPR có mẫu số rất lớn (số mẫu âm). PR-AUC mới là chỉ số phù hợp cho lớp dương hiếm.
  • E. Dùng accuracy làm chỉ số chính — chỉ số sai điển hình cho dữ liệu mất cân bằng: nếu 2% khách hàng mua, model đoán "không ai mua" đạt 98% accuracy mà hoàn toàn vô dụng.
  • B. Ưu tiên RMSE, đo sai số trung bình giữa giá trị dự đoán và thực tế — chỉ số HỒI QUY: đây là bài toán phân loại nhị phân (mua hay không mua), không có "sai số" liên tục nào để đo.

Ghi nhớ

Chỉ số cho phân loại mất cân bằng — xếp theo mức phù hợp: | Chỉ số | Phù hợp | Ghi chú | |---|---|---| | Confusion matrix | ✅ nền tảng | thấy được kiểu lỗi | | Precision, Recall, F1 | ✅ | định lượng hai loại lỗi | | PR-AUC | ✅ tốt nhất khi lớp dương rất hiếm | | | ROC-AUC | ⚠️ có thể đẹp giả tạo | dùng khi cân bằng tương đối | | Accuracy | ❌ gây hiểu lầm | |

Vì sao ROC-AUC gây hiểu lầm với dữ liệu rất mất cân bằng — đáng hiểu kỹ:

FPR = FP / (FP + TN)

Với 99% mẫu âm:  TN rất lớn
→ dù có 1.000 báo động giả, FPR vẫn nhỏ
→ đường ROC vẫn đẹp
→ nhưng precision thì thảm hại

PR-AUC dùng precision thay cho FPR, nên nó phản ánh trực tiếp tỷ lệ báo nhầm trong số cảnh báo — khắt khe hơn và trung thực hơn.

Ba chỉ số dẫn xuất từ confusion matrix: | Chỉ số | Công thức | |---|---| | Precision | TP / (TP + FP) | | Recall | TP / (TP + FN) | | F1 | 2 × P × R / (P + R) — trung bình điều hoà |

F-beta là biến thể đáng biết khi hai loại lỗi không cân bằng về chi phí:

F2 (β=2): ưu tiên recall gấp đôi  → dùng khi bỏ sót tốn kém
F0.5:     ưu tiên precision        → dùng khi báo nhầm tốn kém

Và nguyên tắc quan trọng nhất: chọn chỉ số theo CHI PHÍ NGHIỆP VỤ của từng loại lỗi, không theo thói quen. Với dự đoán khách hàng mua hàng, bỏ lỡ một khách (FN) thường tốn hơn hiển thị một quảng cáo thừa (FP) — nên recall nên được ưu tiên, và ngưỡng phân loại nên đặt thấp hơn 0,5.