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

Đáp án

D — Dùng Amazon SageMaker Data Wrangler nhập các tập dữ liệu, gộp chúng thành một data frame thống nhất, và dùng các chức năng biến đổi của Data Wrangler để làm sạch và tiền xử lý dữ liệu.

Vì sao đúng

Đề nêu bốn việc, và Data Wrangler làm được tất cả trong một công cụ: | Việc | Data Wrangler | |---|---| | Gộp nhiều tập dữ liệu | join bằng thao tác kéo thả | | Xử lý giá trị thiếu | transform Impute | | Xử lý bản ghi trùng | transform Handle duplicates | | Xử lý ngoại lai | transform Handle outliers / Filter |

Và cụm "most efficient approach" là tiêu chí quyết định — ba phương án còn lại đều tốn công hơn hoặc dùng sai công cụ.

Luồng làm việc trong Data Wrangler:

Import nhiều nguồn (S3, Athena, Redshift, JDBC)
    ↓ Join / Concatenate → một data frame
    ↓ Data Quality and Insights Report → thấy vấn đề ở đâu
    ↓ Handle missing / duplicates / outliers
    ↓ Export → S3, Feature Store, hoặc ProcessingStep trong pipeline

Bước "Data Quality and Insights Report" đáng nhắc riêng vì nó phát hiện tự động đúng ba vấn đề đề nêu, cộng thêm: | Phát hiện | Chi tiết | |---|---| | Giá trị thiếu | tỷ lệ theo từng cột | | Trùng lặp | số dòng trùng | | Ngoại lai | theo phân bố từng cột | | Target leakage | cột rò rỉ thông tin về nhãn — nguy hiểm nhất | | Tương quan | cặp cột trùng thông tin |

Và xuất được thành ProcessingStep nghĩa là công việc thăm dò trở thành mã chạy lại được — không phải viết lại bằng tay.

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

• B. Dùng SageMaker Python SDK gộp các tập dữ liệu thành một pandas data frame và chạy biến đổi trên đó — đây là phương án gần nhất và hoàn toàn khả thi, nhưng nó tốn công hơn: phải viết mã cho từng phép biến đổi, và pandas giới hạn bởi bộ nhớ của instance. Với "large datasets" thì đó là ràng buộc thật. (Với dữ liệu nhỏ và người quen pandas, đây là lựa chọn thực dụng — chỉ là không phải "most efficient" theo tiêu chí đề.)
• A. Gộp THỦ CÔNG các tập dữ liệu, lưu S3, dùng Athena biến đổi và QuickSight trực quan hoá — "manually import and merge" là điểm loại, và Athena dùng SQL cho việc biến đổi phức tạp (xử lý ngoại lai, điền giá trị thiếu theo chiến lược) là rất cồng kềnh.
• C. Dùng SageMaker Ground Truth nhập và gộp dữ liệu, dùng human-in-the-loop để làm sạch — sai dịch vụ hoàn toàn: Ground Truth là công cụ GÁN NHÃN dữ liệu (thuê người gắn nhãn cho ảnh, văn bản). Nó không nhập, không gộp, và không làm sạch dữ liệu.

Ghi nhớ

Bốn công cụ SageMaker hay bị lẫn — nhớ đúng vai: | Công cụ | Việc | |---|---| | Data Wrangler | CHUẨN BỊ dữ liệu: nhập, gộp, làm sạch, biến đổi | | Ground Truth | GÁN NHÃN dữ liệu | | Feature Store | LƯU và PHỤC VỤ đặc trưng đã chuẩn bị | | Clarify | thiên lệch và khả năng giải thích |

Ba nhóm transform của Data Wrangler cho dữ liệu bẩn: | Nhóm | Transform | |---|---| | Giá trị thiếu | Impute (mean, median, mode, constant), Drop | | Trùng lặp | Drop duplicates | | Ngoại lai | Filter, standard deviation / quantile-based |

Ba cách gộp dữ liệu trong Data Wrangler: | Cách | Dùng khi | |---|---| | Join | nối theo khoá chung — như SQL JOIN | | Concatenate | xếp chồng các tập cùng schema | | Union | hợp nhất, loại trùng |

Thứ tự xử lý đúng — quan trọng và hay làm sai:

① Gộp dữ liệu
② Xoá dòng trùng          ← trước, để không tính thống kê sai
③ Xử lý ngoại lai          ← trước khi chuẩn hoá
④ Điền giá trị thiếu       ← tham số tính từ dữ liệu đã sạch
⑤ Mã hoá và chuẩn hoá
⑥ Chia train/validation/test

Bước ③ trước ⑤ đặc biệt quan trọng: nếu chuẩn hoá trước khi xử lý ngoại lai, một giá trị cực đoan sẽ nén toàn bộ dữ liệu còn lại vào khoảng rất hẹp.

Và bước ⑥ ở cuối cũng là quy tắc: chia tập trước khi cân bằng lớp, nhưng tính tham số biến đổi từ tập huấn luyện rồi áp cho các tập khác — nếu không sẽ rò rỉ dữ liệu.

Đáp án

D — Bật CloudWatch Logs thu thập log chi tiết từ SageMaker endpoint, cấu hình CloudWatch Alarm giám sát độ trễ gọi endpoint và tỷ lệ lỗi, và thiết lập thông báo cảnh báo đội khi vượt ngưỡng.

Vì sao đúng

Đề nêu ba triệu chứng và một yêu cầu: | Yếu tố | Cơ chế | |---|---| | Độ trễ tăng | alarm trên ModelLatency và OverheadLatency | | Lỗi timeout | alarm trên Invocation5XXErrors | | Cần phát hiện kịp thời | thông báo tự động qua SNS |

Ba metric của endpoint mà đáp án nhắm tới:

ModelLatency        → model xử lý mất bao lâu
OverheadLatency     → SageMaker thêm bao nhiêu (payload, mạng)
Invocation5XXErrors → bao nhiêu request bị lỗi phía máy chủ

cloudwatch.put_metric_alarm(
    AlarmName='canh-bao-do-tre-gian-lan',
    MetricName='ModelLatency', Namespace='AWS/SageMaker',
    Dimensions=[{'Name': 'EndpointName', 'Value': 'phat-hien-gian-lan'},
                {'Name': 'VariantName', 'Value': 'AllTraffic'}],
    Statistic='Average', Period=60, Threshold=200,
    EvaluationPeriods=2,
    ComparisonOperator='GreaterThanThreshold',
    AlarmActions=[arn_sns_doi_van_hanh])

Điểm quan trọng: alarm phải đặt trên metric của ENDPOINT, không phải của training job — đây là chỗ phương án A sai.

Và EvaluationPeriods=2 tránh báo động giả do một đỉnh nhất thời.

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

• A. Dùng Logs Insights tìm kiếm và phân tích log từ SageMaker TRAINING JOB, và đặt alarm trên CPU và bộ nhớ của EC2 instance chạy model — đây là phương án gần nhất và sai đối tượng giám sát: vấn đề nằm ở endpoint đang phục vụ, không phải ở training job. Và bạn không quản lý EC2 instance của SageMaker endpoint — chúng do dịch vụ quản lý, bạn giám sát qua metric của endpoint.
• B. Bật CloudTrail ghi mọi lời gọi API và dùng CloudWatch Logs giám sát lưu lượng mạng; đặt alarm dựa trên hoạt động API để phát hiện vấn đề hiệu năng — CloudTrail ghi ai gọi API nào, nó không đo hiệu năng. Đặt alarm trên số lời gọi API không cho biết chúng nhanh hay chậm.
• C. Dựa vào SageMaker console giám sát metric, lưu training log KHÔNG đặt alarm, chỉ phân tích khi có vấn đề xảy ra — phản ứng thay vì chủ động: "analyzing logs only when issues arise" nghĩa là bạn biết vấn đề qua lời phàn nàn của người dùng, không qua hệ thống.

Ghi nhớ

Các metric của SageMaker endpoint — nhóm cần thuộc: | Metric | Namespace | Ý nghĩa | |---|---|---| | Invocations | AWS/SageMaker | tổng số lời gọi | | InvocationsPerInstance | AWS/SageMaker | cơ sở cho auto-scaling | | ModelLatency | AWS/SageMaker | thời gian MODEL xử lý | | OverheadLatency | AWS/SageMaker | thời gian SageMaker thêm vào | | Invocation4XXErrors / 5XXErrors | AWS/SageMaker | lỗi client / máy chủ | | CPUUtilization, MemoryUtilization | /aws/sagemaker/Endpoints | tài nguyên instance |

Phân biệt hai loại độ trễ khi chẩn đoán: | Nếu cao | Nguyên nhân thường gặp | |---|---| | ModelLatency | model nặng, instance nhỏ, hoặc xếp hàng | | OverheadLatency | payload lớn, vấn đề mạng, serialization chậm |

Ba thống kê của alarm và khi nào dùng: | Thống kê | Dùng cho | |---|---| | Average | xu hướng chung | | p99 | trải nghiệm tệ nhất — quan trọng nhất cho độ trễ | | Sum | đếm (số lời gọi, số lỗi) |

Với ứng dụng tài chính thời gian thực, p99 quan trọng hơn Average: trung bình 50 ms nghe tốt, nhưng nếu p99 là 3 giây thì 1% giao dịch bị treo — và đó là những giao dịch người dùng nhớ nhất.

Ba tầng quan sát nên có cùng nhau: | Tầng | Công cụ | Trả lời | |---|---|---| | Metric + Alarm | CloudWatch | "có vấn đề không?" | | Log | CloudWatch Logs Insights | "chuyện gì đã xảy ra?" | | Trace | AWS X-Ray | "chậm ở chặng nào?" |

Và một cấu hình nên bật cùng lúc: auto-scaling — vì với endpoint bị quá tải, alarm chỉ báo tin xấu, còn auto-scaling mới giải quyết nó (xem #6589).

Đáp án

C và E.

• E — Dùng Amazon Rekognition tạo face collection cho nhân viên được phép
• C — Thiết lập Lambda kích hoạt thao tác FACE MATCH khi có ảnh mới lên S3; ghi kết quả vào DynamoDB để kiểm toán

Vì sao đúng

Đề nêu bốn yêu cầu, và cặp C+E đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Ít ảnh của nhân viên — không huấn luyện được model riêng | Rekognition face collection cần RẤT ÍT ảnh | | Nhận diện chính xác nhân viên được phép | SearchFacesByImage — face matching | | Ít công sức vận hành | dịch vụ được quản lý, không huấn luyện | | Lưu dữ liệu để kiểm toán | DynamoDB |

Vì sao face collection giải quyết được vấn đề "ít ảnh":

Huấn luyện model nhận diện khuôn mặt từ đầu:
  cần hàng nghìn ảnh mỗi người

Rekognition face collection:
  cần MỘT vài ảnh mỗi người
  → Rekognition trích xuất vector đặc trưng khuôn mặt
  → so khớp bằng khoảng cách vector, không cần huấn luyện

# ① Một lần: đăng ký nhân viên vào collection
rekognition.index_faces(
    CollectionId='nhan-vien-duoc-phep',
    Image={'S3Object': {'Bucket': 'kho-anh', 'Name': 'nv-001.jpg'}},
    ExternalImageId='NV001')

# ② Mỗi lần có ảnh mới từ camera
ket_qua = rekognition.search_faces_by_image(
    CollectionId='nhan-vien-duoc-phep',
    Image={'S3Object': {'Bucket': 'anh-camera', 'Name': key}},
    FaceMatchThreshold=95)

Và phân biệt face MATCH với face DETECTION là điểm quyết định giữa C và D: | Thao tác | Trả lời | |---|---| | Face detection (DetectFaces) | "Có khuôn mặt trong ảnh không?" — không biết là ai | | Face match (SearchFacesByImage) | "Khuôn mặt này là AI?" — so với collection |

Đề cần nhận diện nhân viên được phép, nên phải là match.

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

• D. Lambda kích hoạt thao tác FACE DETECTION khi có ảnh mới, ghi kết quả vào DynamoDB — đây là phương án gần nhất và sai ở đúng một từ: detection chỉ phát hiện CÓ khuôn mặt, không cho biết đó là ai. Nó không phân biệt được nhân viên được phép với người lạ.
• B. Dùng Rekognition tạo CUSTOM LABELS cho nhân viên được phép — dùng sai tính năng: Rekognition Custom Labels dành cho nhận diện VẬT THỂ và cảnh tuỳ chỉnh (logo, sản phẩm lỗi, loại thiết bị). Nó không thiết kế cho nhận diện khuôn mặt — và nó cũng cần nhiều ảnh huấn luyện hơn.
• A. Dùng Amazon Lookout for Vision tạo custom label cho nhân viên — sai dịch vụ hoàn toàn: Lookout for Vision là dịch vụ phát hiện lỗi trong ảnh công nghiệp (sản phẩm hỏng trên dây chuyền). Không liên quan tới khuôn mặt.

Ghi nhớ

Các thao tác khuôn mặt của Amazon Rekognition: | Thao tác | Việc | |---|---| | DetectFaces | phát hiện CÓ khuôn mặt, trả về thuộc tính (tuổi ước lượng, cảm xúc) | | IndexFaces | thêm khuôn mặt vào collection | | SearchFacesByImage | tìm khuôn mặt khớp trong collection ← câu này | | CompareFaces | so hai ảnh trực tiếp, không cần collection |

Phân biệt hai cách so khớp: | | CompareFaces | SearchFacesByImage | |---|---|---| | So với | một ảnh nguồn | cả collection | | Quy mô | 1:1 | 1:N — hàng triệu khuôn mặt | | Dùng khi | xác minh danh tính đã khai | nhận diện trong nhóm ← câu này |

Ba dịch vụ thị giác của AWS — nhớ đúng phạm vi: | Dịch vụ | Việc | |---|---| | Rekognition | khuôn mặt, vật thể, cảnh, văn bản trong ảnh, kiểm duyệt | | Rekognition Custom Labels | vật thể tuỳ chỉnh — logo, sản phẩm | | Lookout for Vision | phát hiện lỗi công nghiệp |

Ba tham số quan trọng của face matching: | Tham số | Ảnh hưởng | |---|---| | FaceMatchThreshold | ngưỡng tin cậy — 95+ cho ứng dụng an ninh | | MaxFaces | số kết quả trả về | | QualityFilter | lọc ảnh chất lượng thấp |

Ngưỡng là quyết định nghiệp vụ: với khu vực an ninh cao như phòng mổ, ngưỡng cao (99) giảm nguy cơ cho người lạ vào, đổi lại nhân viên thật đôi khi phải thử lại.

Và ba lưu ý về quyền riêng tư và tuân thủ khi triển khai nhận diện khuôn mặt: | Lưu ý | Chi tiết | |---|---| | Dữ liệu sinh trắc chịu quy định nghiêm ngặt | nhiều nơi cần sự đồng ý rõ ràng | | Mã hoá collection và bảng kiểm toán | KMS cho cả hai | | Đặt thời hạn lưu trữ | TTL trên DynamoDB — không giữ vô thời hạn |

Và một điều nên có trong hệ thống an ninh thật: đường thoát cho con người — khi không khớp, nên cảnh báo để nhân viên an ninh kiểm tra, chứ không tự động khoá cửa với một bác sĩ đang cần vào phòng mổ.

Đáp án

D — Dùng chức năng blocked phrase (cụm từ bị chặn) của Amazon Q Business để lọc bỏ các phản hồi có nhắc tới điểm đến du lịch lỗi thời trước khi trả kết quả.

Vì sao đúng

Đề nêu yêu cầu: đảm bảo phản hồi của API không nhắc tới điểm đến lỗi thời hoặc không còn khả dụng, và Amazon Q Business có tính năng dựng sẵn cho đúng việc đó.

Blocked phrases là cơ chế lọc ở tầng dịch vụ:

Q Business sinh phản hồi
    ↓ kiểm tra với danh sách cụm từ bị chặn
    ├─ có cụm từ bị chặn → KHÔNG trả về phản hồi đó
    └─ sạch → trả về người dùng

Ba lợi ích so với các cách khác: | Lợi ích | Chi tiết | |---|---| | Không cần mã | cấu hình danh sách trong Q Business | | Áp cho MỌI phản hồi | không phụ thuộc ứng dụng nhớ lọc | | Cập nhật tức thì | thêm điểm đến vào danh sách là có hiệu lực ngay |

Vế cuối quan trọng cho ngành du lịch: điểm đến bị đóng cửa hoặc gói tour hết hạn thay đổi thường xuyên, và cập nhật một danh sách nhanh hơn nhiều so với sửa mã hay nạp lại dữ liệu.

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

• B. Đặt Lambda xử lý phản hồi từ Q Business và loại bỏ tham chiếu tới điểm đến lỗi thời trước khi hiển thị — đây là phương án gần nhất và hoạt động được, nhưng nó tự dựng lại tính năng có sẵn: phải viết hàm, bảo trì, xử lý lỗi, và đảm bảo mọi đường gọi đều đi qua nó. Trong khi blocked phrases làm cùng việc bằng cấu hình.
• A. Cấu hình Kendra retriever loại trừ nội dung liên quan tới điểm đến lỗi thời khỏi tập dữ liệu phản hồi — đây là hướng đúng về nguyên tắc (loại từ nguồn tốt hơn lọc ở đầu ra), nhưng nó khó hơn nhiều trong thực tế: bạn phải xác định và loại bỏ tài liệu ở tầng index, và model vẫn có thể nhắc tới điểm đến đó từ kiến thức nền. (Lý tưởng là làm cả hai: gỡ tài liệu lỗi thời khỏi nguồn VÀ đặt blocked phrases làm lưới an toàn.)
• C. Dùng Comprehend phân tích văn bản phản hồi và chặn phản hồi chứa điểm đến lỗi thời — dùng sai công cụ: Comprehend phân tích cảm xúc, thực thể, cụm từ khoá — nó không có khái niệm "danh sách cấm" và bạn vẫn phải tự viết logic so khớp.

Ghi nhớ

Amazon Q Business — bốn cơ chế kiểm soát nội dung: | Cơ chế | Việc | |---|---| | Blocked phrases | chặn phản hồi chứa cụm từ cụ thể | | Topic control (guardrails) | chặn theo CHỦ ĐỀ, nhận diện ngữ nghĩa | | Document access control | người dùng chỉ thấy tài liệu họ có quyền | | Response settings | giới hạn nguồn trả lời (chỉ dữ liệu doanh nghiệp, hoặc cả kiến thức model) |

Phân biệt hai cơ chế đầu: | | Blocked phrases | Topic control | |---|---|---| | Khớp theo | chuỗi cụ thể | ngữ nghĩa | | Dùng cho | tên riêng, sản phẩm ngừng bán ← câu này | chủ đề rộng (tư vấn pháp lý, y tế) | | Hạn chế | không bắt được cách diễn đạt khác | cần định nghĩa và ví dụ |

Hạn chế của blocked phrases đáng biết: nếu chặn "Đảo X" nhưng model viết "hòn đảo phía nam nổi tiếng ấy", nó lọt qua. Với yêu cầu chặt chẽ, kết hợp cả hai cơ chế.

Ba tầng kiểm soát nội dung cho ứng dụng trợ lý — theo thứ tự nên áp: | Tầng | Cách làm | |---|---| | Nguồn dữ liệu | gỡ tài liệu lỗi thời khỏi index — gốc rễ nhất | | Lúc sinh | blocked phrases, topic control | | Sau khi sinh | hậu xử lý bằng mã |

Tầng đầu là tốt nhất nhưng không phải lúc nào cũng đủ nhanh; tầng hai là lưới an toàn cấu hình được; tầng ba chỉ nên dùng cho luật rất đặc thù.

Và một quy trình vận hành nên có cho ngành du lịch: đồng bộ danh sách blocked phrases với hệ thống quản lý sản phẩm — khi một gói tour bị đánh dấu ngừng bán, tự động thêm tên điểm đến vào danh sách chặn. Cách này tránh được khoảng thời gian mà trợ lý vẫn quảng cáo thứ không còn bán.

Đáp án

A — Thêm tag vào user profile trong SageMaker domain, và cấu hình AWS Budgets gửi cảnh báo khi vượt ngưỡng.

Vì sao đúng

Đề nêu ba yếu tố, và đáp án A đáp ứng cả ba với công sức ít nhất: | Yếu tố | Cơ chế | |---|---| | Mười lập trình viên trong MỘT domain | tag ở mức user profile phân biệt được từng người | | Cảnh báo tự động khi vượt ngưỡng | AWS Budgets | | Theo dõi chi phí compute của SageMaker | tag lan truyền xuống tài nguyên |

Cơ chế lan truyền tag của SageMaker:

Tag trên user profile
    ↓ tự động lan xuống
Tài nguyên do người dùng đó tạo:
  ├─ Studio app (JupyterLab, KernelGateway)
  ├─ Training job
  ├─ Processing job
  └─ Endpoint

Nhờ đó, chi phí của mỗi lập trình viên được gắn thẻ tự động mà không ai phải nhớ gắn tay.

Và AWS Budgets là công cụ đúng cho vế cảnh báo:

aws budgets create-budget --budget '{
  "BudgetName": "sagemaker-doi-poc",
  "BudgetLimit": {"Amount": "5000", "Unit": "USD"},
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST",
  "CostFilters": {"TagKeyValue": ["user:Doi$poc-ml"]}}'

Vượt ngưỡng → SNS gửi email cho đội.

Một bước bắt buộc dễ quên: tag phải được kích hoạt làm cost allocation tag trong Billing console thì mới lọc được trong Budgets và Cost Explorer.

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

• B. Thêm custom tag bằng cách sửa user profile, chỉnh cấu hình lan truyền tag ở mức user profile cho từng người, rồi cấu hình Budgets — đây là phương án gần nhất và mô tả thêm những bước không cần thiết: SageMaker tự động lan truyền tag từ user profile xuống tài nguyên; không có cấu hình "tag propagation settings ở mức user profile" phải chỉnh riêng cho từng người. Phương án này đúng về hướng nhưng phức tạp hoá.
• C. Thêm tag vào user profile, cấu hình Cost Explorer gửi cảnh báo khi vượt ngưỡng — sai dịch vụ cho vế cảnh báo: Cost Explorer là công cụ phân tích và trực quan hoá, nó không gửi cảnh báo theo ngưỡng. Đó là việc của Budgets.
• D. Thêm tag vào IAM profile của từng người, cấu hình Trusted Advisor theo dõi chi phí và sinh khuyến nghị — hai lỗi: tag trên IAM user không lan truyền xuống tài nguyên SageMaker, và Trusted Advisor khuyến nghị tối ưu, không cảnh báo theo ngưỡng ngân sách.

Ghi nhớ

Bốn công cụ chi phí — nhớ đúng vai: | Công cụ | Việc | |---|---| | AWS Budgets | đặt ngưỡng và CẢNH BÁO ← câu này | | Cost Explorer | phân tích, lọc theo tag, dự báo | | Compute Optimizer | khuyến nghị kích thước tài nguyên | | Trusted Advisor | khuyến nghị rộng: nhàn rỗi, RI, bảo mật |

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

"Báo cho tôi khi vượt ngưỡng" → Budgets "Tiền đi đâu?" → Cost Explorer

Ba loại budget của AWS Budgets: | Loại | Theo dõi | |---|---| | Cost budget | chi tiêu bằng tiền | | Usage budget | mức dùng (giờ instance, GB) | | RI/SP utilization | mức tận dụng cam kết |

Ba mức tag trong SageMaker và phạm vi lan truyền: | Mức | Lan truyền tới | |---|---| | Domain | mọi tài nguyên trong domain | | User profile | tài nguyên của người dùng đó ← câu này | | Space | tài nguyên trong space đó |

Ba khoản chi phí SageMaker lớn nhất và cách kiểm soát: | Khoản | Kiểm soát | |---|---| | Studio app quên tắt | auto-shutdown lifecycle config | | Endpoint không còn ai gọi | alarm trên Invocations = 0 | | Training job trên instance lớn | Managed Spot Training |

Dòng đầu là nguyên nhân phổ biến nhất của hoá đơn bất ngờ với đội mới dùng SageMaker Studio: app JupyterLab tính tiền theo thời gian chạy và không tự tắt khi đóng trình duyệt. Cấu hình lifecycle script tự tắt sau N giờ nhàn rỗi là việc nên làm ngay từ đầu.

Và ba nguyên tắc để tagging thật sự hoạt động: | Nguyên tắc | Chi tiết | |---|---| | Chuẩn hoá tên tag từ đầu | Project khác project | | Kích hoạt cost allocation tag | bắt buộc, nếu không tag không hiện trong Budgets | | Ép buộc bằng Tag Policy | chặn tạo tài nguyên thiếu thẻ |

Đáp án

B — Amazon SageMaker Clarify.

Vì sao đúng

Đề nêu ba yêu cầu quản trị, và Clarify đáp ứng cả ba: | Yêu cầu | Clarify | |---|---| | Minh bạch — theo dõi và kiểm toán quyết định của model | báo cáo giải thích cho từng dự đoán | | Công bằng — đảm bảo không thiên lệch | chỉ số thiên lệch trước và sau huấn luyện | | Giám sát tuân thủ | bias drift và feature attribution drift trên production |

Và với chấm điểm tín dụng, ba yêu cầu đó là bắt buộc về mặt pháp lý — nhiều quy định buộc tổ chức tín dụng phải giải thích được lý do từ chối và chứng minh không phân biệt đối xử.

Clarify cung cấp bốn khả năng, phủ toàn bộ vòng đời: | Khả năng | Giai đoạn | |---|---| | Pre-training bias | trên DỮ LIỆU, trước khi huấn luyện | | Post-training bias | trên DỰ ĐOÁN, sau khi huấn luyện | | Explainability (SHAP) | giải thích từng dự đoán và toàn cục | | Monitoring | bias drift và feature attribution drift trên production |

clarify_processor.run_bias(
    data_config=DataConfig(...),
    bias_config=BiasConfig(label_values_or_threshold=[1],
                           facet_name='nhom_tuoi',
                           group_name='muc_thu_nhap'),
    pre_training_methods='all',
    post_training_methods='all')

Và giải thích cục bộ là thứ tổ chức tín dụng cần nhất:

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

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

• **A. SageMaker Model Monitor — đây là phương án gần nhất và hai dịch vụ bổ sung nhau, nhưng Model Monitor phát hiện CHẤT LƯỢNG giảm và drift, còn đề hỏi về minh bạch, công bằng và khả năng giải thích. Model Monitor không giải thích được vì sao một hồ sơ bị từ chối. (Model Monitor có tính năng bias drift — nhưng nó dùng Clarify bên dưới.)
• **D. AWS CloudTrail — ghi lại lời gọi API: ai đã tạo model, ai đã cập nhật endpoint. Hữu ích cho kiểm toán thao tác vận hành, nhưng nó không biết gì về nội dung dự đoán hay tính công bằng của model.
• **C. SageMaker Autopilot — công cụ AutoML: tự động khám phá và huấn luyện model. Nó làm việc ở giai đoạn phát triển, không phục vụ quản trị. (Autopilot có sinh notebook giải thích quy trình, nhưng đó là giải thích cách nó chọn model, không phải giải thích dự đoán.)

Ghi nhớ

Bốn công cụ quản trị ML của SageMaker — mỗi cái một khía cạnh: | Công cụ | Khía cạnh quản trị | |---|---| | Clarify | công bằng và khả năng giải thích | | Model Monitor | chất lượng dữ liệu và model theo thời gian | | Model Cards | tài liệu: mục đích, giới hạn, chỉ số, xếp hạng rủi ro | | ML Lineage Tracking | nguồn gốc: model từ dữ liệu nào, job nào | | Model Registry | phiên bản và phê duyệt | | CloudTrail | ai đã làm gì |

Một hệ thống ML chịu quản lý cần cả sáu, và mỗi cái trả lời một câu hỏi khác nhau của kiểm toán viên:

"Model này có công bằng không?"          → Clarify
"Vì sao hồ sơ này bị từ chối?"           → Clarify (SHAP)
"Model có còn hoạt động tốt không?"      → Model Monitor
"Model này dùng để làm gì, giới hạn nào?" → Model Card
"Model này từ dữ liệu nào ra?"           → Lineage
"Ai đã duyệt phiên bản đang chạy?"       → Model Registry + CloudTrail

Các chỉ số thiên lệch của Clarify: | Chỉ số | Đo | |---|---| | CI | mất cân bằng số lượng giữa các nhóm | | DPL | chênh lệch tỷ lệ nhãn dương trong DỮ LIỆU | | DPPL | chênh lệch tỷ lệ dự đoán dương của MODEL | | DI | tỷ số — quy tắc 80% | | CDD | DPL có điều kiện theo biến khác | | RD | chênh lệch recall — equal opportunity |

Ba cách chạy Clarify: | Cách | Dùng khi | |---|---| | Processing job (theo yêu cầu) | phân tích một lần, hoặc trong pipeline | | Monitoring schedule | giám sát liên tục trên production | | Tích hợp trong SageMaker Pipeline | sinh báo cáo tự động cho mỗi phiên bản model |

Cách thứ ba nên là mặc định cho hệ thống chịu quản lý: mỗi lần huấn luyện lại, báo cáo công bằng được sinh tự động và lưu cùng model — thay vì phải nhớ chạy nó trước mỗi kỳ kiểm toán.

Đáp án

A — Phân vùng dữ liệu trên S3 theo năm, tháng, ngày (ví dụ year=YYYY/month=MM/day=DD), tổ chức log theo thư mục ngày, và cấu hình S3 lifecycle policy chuyển dữ liệu sang Glacier sau 90 ngày.

Vì sao đúng

Đề nêu ba yêu cầu, và đáp án A đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Tối ưu hiệu năng truy vấn Athena | phân vùng theo ngày | | Truy vấn xu hướng 7 ngày gần nhất | chỉ đọc 7 thư mục thay vì toàn bộ | | Lưu 90 ngày rồi chuyển sang lưu trữ rẻ hơn | lifecycle policy |

Vì sao phân vùng tạo khác biệt lớn với Athena:

Không phân vùng:
  SELECT ... WHERE ngay >= current_date - 7
  → Athena QUÉT TOÀN BỘ 90 ngày dữ liệu rồi mới lọc
  → tính tiền theo lượng dữ liệu quét ⇒ đắt và chậm

Có phân vùng theo ngày:
  s3://.../year=2026/month=08/day=29/
  → Athena chỉ đọc ĐÚNG 7 thư mục
  → giảm dữ liệu quét khoảng 13 lần

Athena tính tiền theo lượng dữ liệu quét, nên phân vùng giảm cả thời gian lẫn chi phí cùng lúc.

Cấu trúc phân vùng kiểu Hive (key=value) được Athena nhận diện tự động:

SELECT user_id, COUNT(*) AS luot_xem
FROM   log_xem_video
WHERE  year = '2026' AND month = '08' AND day BETWEEN '23' AND '29'
GROUP BY user_id;

Và lifecycle policy cho vế lưu trữ:

{"Rules": [{
  "Filter": {"Prefix": "logs/"},
  "Transitions": [{"Days": 90, "StorageClass": "GLACIER"}],
  "Status": "Enabled"}]}

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

• **C. Dùng lifecycle policy XOÁ log cũ hơn 90 ngày và cấu hình Athena truy vấn log thô KHÔNG dùng phân vùng hay prefix — đây là phương án gần nhất về vế lưu trữ (dù đề nói lưu trữ, không phải xoá), nhưng nó bỏ hoàn toàn vế tối ưu hiệu năng: không phân vùng nghĩa là mọi truy vấn quét toàn bộ dữ liệu.
• B. Lưu log ở định dạng JSON KHÔNG NÉN và dựa vào bộ lọc của Athena cho phân tích 7 ngày — tệ về mọi mặt: JSON không nén tốn dung lượng gấp nhiều lần, là định dạng theo dòng nên phải đọc mọi cột, và không phân vùng nên quét toàn bộ.
• D. Nén toàn bộ log mỗi ngày thành MỘT tệp lớn và dùng Athena quét các tệp nén — tệp quá lớn không phân tách được: nếu nén bằng gzip, Athena không thể xử lý song song một tệp — nó phải giải nén tuần tự. Đây là mẫu chống chỉ định cho truy vấn phân tích.

Ghi nhớ

Ba kỹ thuật tối ưu Athena — nên dùng cùng nhau: | Kỹ thuật | Giảm gì | |---|---| | Phân vùng | số tệp phải đọc — theo điều kiện WHERE | | Định dạng cột (Parquet, ORC) | số cột phải đọc + kích thước nhờ nén | | Kích thước tệp hợp lý | 128 MB – 1 GB — tránh tệp quá nhỏ hoặc quá lớn |

Đáp án A chỉ nêu kỹ thuật đầu; trong thực tế nên chuyển log sang Parquet để giảm thêm nhiều lần nữa.

Nguyên tắc chọn khoá phân vùng: | Nguyên tắc | Chi tiết | |---|---| | Chọn cột hay dùng trong WHERE | ngày — đúng với đề | | Đừng phân vùng quá mịn | hàng chục nghìn phân vùng nhỏ làm chậm lập kế hoạch truy vấn | | Cân bằng số phân vùng và kích thước | mỗi phân vùng nên có ít nhất vài chục MB |

Dòng giữa là bẫy phổ biến: phân vùng theo giờ thay vì ngày tạo ra gấp 24 lần số phân vùng — và với dữ liệu 90 ngày, đó là hơn 2.000 phân vùng. Chi phí liệt kê chúng có thể vượt lợi ích lọc.

Bốn cách quản lý phân vùng: | Cách | Đặc điểm | |---|---| | Glue crawler | tự phát hiện phân vùng theo cấu trúc thư mục | | ALTER TABLE ADD PARTITION | thêm thủ công | | MSCK REPAIR TABLE | quét toàn bộ — rất chậm với nhiều phân vùng | | Partition projection | suy ra phân vùng từ mẫu — nhanh nhất, không cần metadata |

Partition projection là lựa chọn tốt nhất cho log theo ngày:

TBLPROPERTIES (
  'projection.enabled' = 'true',
  'projection.day.type' = 'date',
  'projection.day.range' = '2024-01-01,NOW',
  'projection.day.format' = 'yyyy-MM-dd')

Nó tránh được hoàn toàn vấn đề MSCK REPAIR chạy hàng phút khi số phân vùng lớn.

Các lớp lưu trữ S3 theo chi phí: | Lớp | Chi phí | Thời gian lấy lại | |---|---|---| | Standard | cao nhất | tức thì | | Standard-IA | thấp hơn | tức thì | | Glacier Instant Retrieval | thấp | tức thì | | Glacier Flexible Retrieval | rất thấp | phút tới giờ | | Deep Archive | thấp nhất | giờ |

Nếu vẫn cần truy vấn dữ liệu cũ đôi khi, Glacier Instant Retrieval là lựa chọn tốt hơn Glacier thường — rẻ hơn Standard nhiều mà vẫn đọc được ngay.

Đáp án

A và E.

• E — Khởi chạy các instance huấn luyện trong CÙNG MỘT subnet VPC
• A — Lưu dữ liệu huấn luyện ở cùng Region VÀ cùng Availability Zone với nơi đặt instance

Vì sao đúng

Đề nêu vấn đề rất cụ thể: huấn luyện phân tán chậm vì độ trễ giao tiếp mạng giữa các instance.

Với data parallelism, các instance phải đồng bộ gradient sau MỖI bước:

Mỗi bước huấn luyện:
  ① Mỗi GPU tính gradient trên phần dữ liệu của nó
  ② ALL-REDUCE: đồng bộ gradient giữa MỌI instance   ← nghẽn ở đây
  ③ Cập nhật trọng số

Với hàng nghìn bước mỗi epoch, độ trễ mạng nhân lên rất nhanh

E — cùng subnet là cách trực tiếp nhất giảm độ trễ: | Vị trí | Độ trễ tương đối | |---|---| | Cùng subnet (cùng AZ) | thấp nhất | | Khác AZ, cùng Region | cao hơn đáng kể | | Khác Region | cao nhất |

A — dữ liệu cùng AZ loại bỏ độ trễ đọc dữ liệu qua AZ, và cũng loại bỏ phí truyền dữ liệu giữa các AZ.

Hai đáp án bổ sung nhau: E tối ưu giao tiếp giữa các instance, A tối ưu việc đọc dữ liệu.

Và cấu hình trong SageMaker:

estimator = PyTorch(
    ..., instance_count=8,
    subnets=['subnet-0abc123'],                    # ← MỘT subnet
    security_group_ids=['sg-0def456'],
    distribution={'torch_distributed': {'enabled': True}})

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

• C. Khởi chạy instance ở các subnet KHÁC NHAU trong cùng VPC để cân bằng lưu lượng mạng và giảm nghẽn — đây là phương án gần nhất và lập luận nghe hợp lý nhưng sai: subnet khác nhau thường nghĩa là AZ khác nhau, và giao tiếp qua AZ có độ trễ cao hơn. "Cân bằng lưu lượng" không phải vấn đề ở đây — vấn đề là độ trễ đồng bộ.
• B. Lưu dữ liệu ở cùng Region nhưng KHÁC AZ với instance — thêm độ trễ và thêm phí truyền dữ liệu giữa AZ một cách không cần thiết.
• D. Lưu dữ liệu ở Region KHÁC với instance — tệ nhất: độ trễ cao nhất và phí truyền dữ liệu liên Region đắt.

Ghi nhớ

Ba yếu tố ảnh hưởng hiệu quả huấn luyện phân tán: | Yếu tố | Chi tiết | |---|---| | Độ trễ mạng giữa các instance | cùng subnet, cùng AZ, bật EFA | | Băng thông mạng | chọn instance có băng thông cao | | Kích thước batch mỗi GPU | quá nhỏ thì overhead đồng bộ chiếm ưu thế |

EFA (Elastic Fabric Adapter) là thứ đáng bật nhất và đề không nhắc tới: | Đặc điểm | Chi tiết | |---|---| | Bỏ qua kernel OS | độ trễ thấp hơn nhiều so với TCP thường | | Có trên instance lớn | p4d, p5, trn1 | | Cần placement group | đặt instance gần nhau về vật lý |

Ba mức tối ưu vị trí, từ ngoài vào trong:

Cùng Region        → tránh phí và độ trễ liên Region
Cùng AZ            → giảm độ trễ đáng kể
Cùng placement group (cluster) → độ trễ thấp nhất, cần cho EFA

Cluster placement group là mức sâu nhất: nó đặt các instance trên cùng rack hoặc rất gần nhau về vật lý — cần thiết để EFA phát huy hết tác dụng.

Ba chiến lược song song hoá — nhớ để chọn đúng: | Chiến lược | Giải quyết | Nhu cầu mạng | |---|---|---| | Data parallelism | dữ liệu quá nhiều | cao — đồng bộ gradient mỗi bước | | Tensor parallelism | một lớp quá lớn | rất cao — trao đổi trong mỗi lớp | | Pipeline parallelism | tổng số lớp quá nhiều | thấp hơn — chỉ trao đổi ở ranh giới giai đoạn |

Dòng cuối đáng biết: nếu mạng là nút thắt không khắc phục được, pipeline parallelism trao đổi ít dữ liệu hơn — một lựa chọn thay thế khi tensor parallelism quá nặng về mạng.

Và một chẩn đoán nên làm trước khi tối ưu mạng: bật SageMaker Debugger profiling. Nó cho biết thời gian đi đâu — nếu GPU nhàn rỗi vì chờ dữ liệu chứ không phải chờ đồng bộ, thì tối ưu I/O (FSx for Lustre, gộp tệp) mới là việc cần làm.

Đáp án

D — Nạp dữ liệu vào SageMaker Data Wrangler, thực hiện các phép biến đổi, rồi lưu dữ liệu đã biến đổi vào SageMaker Feature Store.

Vì sao đúng

Đề nêu ba bước, và cặp Data Wrangler + Feature Store khớp đúng ba bước đó: | Bước | Công cụ | |---|---| | Nạp dữ liệu thô | Data Wrangler — connector cho nhiều nguồn | | Biến đổi và tạo đặc trưng | Data Wrangler — 300+ transform | | Lưu đặc trưng cho huấn luyện về sau | Feature Store |

Và hai công cụ này được thiết kế để nối trực tiếp với nhau:

Data Wrangler flow
    ↓ Export destination: "SageMaker Feature Store"
Feature group được tạo và nạp tự động
    ↓
Offline store (S3)  → huấn luyện
Online store        → suy luận thời gian thực

Vì sao Feature Store là đích đúng — ba vấn đề nó giải quyết: | Vấn đề | Cách giải quyết | |---|---| | Trùng lặp công sức | nhiều đội dùng chung định nghĩa đặc trưng | | Training–serving skew | CÙNG một đặc trưng cho cả huấn luyện lẫn suy luận | | 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ứ hai là lý do quan trọng nhất: nếu đặc trưng lúc huấn luyện tính bằng một script và lúc suy luận tính bằng script khác, hai bên sẽ lệch nhau — và model hoạt động kém trên production mà không ai hiểu vì sao.

Và vế "for future model training" trong đề chính là mô tả offline store: nó lưu toàn bộ lịch sử đặc trưng trên S3, sẵn sàng cho mọi lần huấn luyện về sau.

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

• A. Nạp vào AWS Glue biến đổi, lưu S3, rồi nạp vào SageMaker bằng SDK Python — đây là phương án gần nhất và hoàn toàn khả thi, nhưng nó thiếu Feature Store: dữ liệu trên S3 là tệp, không phải đặc trưng được quản lý — không có time travel, không có online store, không chia sẻ được giữa các đội. (Glue phù hợp hơn khi dữ liệu ở quy mô terabyte; với ML feature engineering thì Data Wrangler tích hợp tốt hơn.)
• C. Lưu dữ liệu thô trên S3, rồi nối Feature Store TRỰC TIẾP để nạp và BIẾN ĐỔI dữ liệu — Feature Store không biến đổi dữ liệu: nó lưu trữ và phục vụ đặc trưng đã được chuẩn bị. Bạn phải biến đổi ở nơi khác rồi ghi vào.
• B. Nạp vào RDS, rồi dùng SageMaker Clarify nạp và biến đổi dữ liệu để lưu vào Feature Store — Clarify không nạp và không biến đổi dữ liệu: nó phân tích thiên lệch và khả năng giải thích. Đây là dùng sai dịch vụ hoàn toàn.

Ghi nhớ

Luồng chuẩn từ dữ liệu thô tới model:

Dữ liệu thô (S3, Redshift, JDBC...)
    ↓ Data Wrangler / Glue: làm sạch, biến đổi, tạo đặc trưng
FEATURE STORE
    ├─ offline store (S3)  → huấn luyện, phân tích
    └─ online store        → suy luận thời gian thực
    ↓
Training job → Model → Endpoint

Bốn công cụ SageMaker và vai trò — bảng hay bị nhầm: | Công cụ | Việc | |---|---| | Data Wrangler | CHUẨN BỊ: nhập, gộp, làm sạch, biến đổi | | Feature Store | LƯU và PHỤC VỤ đặc trưng đã chuẩn bị | | Ground Truth | GÁN NHÃN dữ liệu | | Clarify | thiên lệch và khả năng giải thích |

Hai loại store của Feature Store: | 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 |

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 |

Trường thứ hai là thứ chống rò rỉ dữ liệu tương lai:

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 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ị TẠI thời điểm giao dịch

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

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

Đáp án

A — Dùng Amazon SageMaker Pipelines định nghĩa và tự động hoá toàn bộ quy trình ML, bao gồm tiền xử lý dữ liệu, biến đổi dữ liệu và huấn luyện model.

Vì sao đúng

Đề nêu bốn yêu cầu: | Yêu cầu | Cơ chế | |---|---| | Tự động hoá TOÀN BỘ luồng từ tiền xử lý tới huấn luyện | Pipelines — một định nghĩa duy nhất | | Tính toán khoa học phức tạp, mất hàng giờ | ProcessingStep với container tuỳ chỉnh | | Nhiều định dạng: CSV, Parquet, JSON | container xử lý được mọi định dạng | | Hiệu quả và mở rộng được | SageMaker tự cấp phát và thu hồi tài nguyên |

ProcessingStep với container riêng xử lý được vế "specialized scientific computations":

processor = ScriptProcessor(
    image_uri=arn_container_khoa_hoc,        # container có thư viện chuyên ngành
    command=['python3'],
    instance_type='ml.m5.24xlarge',
    instance_count=10,                        # xử lý song song
    max_runtime_in_seconds=28800)             # 8 giờ

buoc_tien_xu_ly = ProcessingStep(
    name='TinhToanPhanTuHoc',
    processor=processor,
    inputs=[ProcessingInput(source='s3://kho/mo-phong/', destination='/opt/ml/input')],
    outputs=[ProcessingOutput(source='/opt/ml/output', destination='s3://kho/da-xu-ly/')])

Ba lợi ích của việc giữ mọi thứ trong một pipeline: | Lợi ích | Chi tiết | |---|---| | Phụ thuộc tường minh | bước huấn luyện nhận đầu ra của bước tiền xử lý | | Lineage tự động | biết model sinh ra từ dữ liệu nào qua bước nào | | Không tính phí điều phối | chỉ trả tiền cho job thật sự chạy |

Và SageMaker Processing job tự tắt khi xong — không có cụm nào nằm chờ, khác với EMR.

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

• B. Dùng Amazon EMR tiền xử lý dữ liệu lớn, chạy tính toán khoa học, lưu kết quả vào S3 trước khi khởi động SageMaker training — đây là phương án gần nhất và EMR mạnh cho xử lý phân tán, nhưng nó thiếu vế TỰ ĐỘNG HOÁ: đề yêu cầu "automate the entire workflow", còn phương án này mô tả hai bước rời rạc không có gì nối chúng. Và bạn phải quản lý cụm EMR.
• C. Dùng Step Functions điều phối tiền xử lý bằng Glue và tích hợp với SageMaker để huấn luyện — hoạt động được nhưng thiếu chuyên môn ML: mất lineage tự động, và Glue kém phù hợp cho "specialized scientific computations" — nó là công cụ ETL, không phải môi trường tính toán khoa học tuỳ chỉnh.
• D. Dùng Glue workflow biến đổi và tiền xử lý trước khi xuất sang SageMaker — cùng vấn đề với C, và Glue job có giới hạn thời gian chạy — với tính toán "can take hours", đó là ràng buộc cần kiểm tra.

Ghi nhớ

So sánh hai công cụ điều phối cho ML: | | SageMaker Pipelines | Step Functions | |---|---|---| | Chuyên cho ML | ✅ step dựng sẵn | tổng quát | | Lineage tự động | ✅ | phải tự làm | | Phí điều phối | không có | theo lần chuyển trạng thái | | Ghép dịch vụ ngoài ML | hạn chế (có LambdaStep, CallbackStep) | ✅ 200+ dịch vụ |

Nguyên tắc: mọi bước đều là ML → Pipelines; nhiều dịch vụ ngoài ML → Step Functions.

Ba lựa chọn chạy tiền xử lý quy mô lớn: | Lựa chọn | Đặc điểm | |---|---| | SageMaker Processing | container của bạn, tự tắt khi xong, tích hợp pipeline | | AWS Glue | serverless Spark, hợp ETL chuẩn | | Amazon EMR | Spark/Hadoop đầy đủ — mạnh nhất, tốn công quản lý nhất |

SageMaker Processing thắng khi cần môi trường tính toán TUỲ CHỈNH — như thư viện hoá học tính toán trong đề: bạn đóng gói chúng vào container và chạy, không cần cụm Spark.

Ba loại ProcessingStep container: | Loại | Dùng khi | |---|---| | SKLearnProcessor | xử lý bằng scikit-learn và pandas | | PySparkProcessor | cần Spark cho dữ liệu rất lớn | | ScriptProcessor với image riêng | thư viện chuyên ngành ← câu này |

Và một cân nhắc cho 6 TB dữ liệu: nếu tính toán song song hoá được theo phân tử, dùng instance_count lớn với s3_data_distribution_type='ShardedByS3Key' để chia dữ liệu cho các instance — mỗi cái xử lý một phần, song song thật sự.

Ba step nên có trong pipeline production: | Step | Việc | |---|---| | ProcessingStep đánh giá | sinh báo cáo chỉ số | | ConditionStep | chặn model kém không lên production | | RegisterModel | đăng ký kèm trạng thái chờ duyệt |