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

Đáp án

D — Thứ tự 2, 4, 3: 2. Việc tải dữ liệu mới kích hoạt pipeline qua S3 event notification 4. SageMaker huấn luyện lại model bằng dữ liệu cập nhật trên S3 3. Pipeline triển khai model đã huấn luyện lại lên SageMaker endpoint cho dự đoán thời gian thực

Vì sao đúng

Ba bước tạo thành một chuỗi CI/CD hoàn chỉnh: kích hoạt → huấn luyện → triển khai.

Và đề cài hai bẫy, mỗi cái nhắm vào một hiểu lầm phổ biến:

Bẫy thứ nhất — bước 5: "S3 Lifecycle rule cố khởi động pipeline khi dữ liệu mới tới".

S3 Lifecycle rule KHÔNG kích hoạt được gì cả. Nó là cơ chế quản lý vòng đời lưu trữ: chuyển object sang lớp lưu trữ rẻ hơn, hoặc xoá sau N ngày. Nó không phát sự kiện tới dịch vụ khác.

Cơ chế đúng là S3 event notification (bước 2), phát sự kiện tới EventBridge, Lambda, SQS hoặc SNS khi có object mới.

Bẫy thứ hai — bước 1: "triển khai model vào SageMaker Model Monitor cho suy luận thời gian thực".

Model Monitor KHÔNG phải nơi triển khai. Nó giám sát một endpoint đã tồn tại — phát hiện data drift, model quality drift, bias drift.

Nơi triển khai đúng là SageMaker endpoint (bước 3).

Luồng đầy đủ:

Dữ liệu mới lên S3
    ↓ ② S3 event notification → EventBridge → CodePipeline
Pipeline chạy
    ↓ ④ SageMaker training job huấn luyện lại
    ↓ ③ Triển khai lên endpoint
Endpoint phục vụ dự đoán thời gian thực
    ↓ (bổ sung) Model Monitor GIÁM SÁT endpoint này

Vì sao các thứ tự khác sai

• A. 2, 4, 1 — kích hoạt và huấn luyện đúng, nhưng bước 1 sai: Model Monitor không phải đích triển khai.
• C. 5, 4, 3 — huấn luyện và triển khai đúng, nhưng bước 5 sai: Lifecycle rule không kích hoạt pipeline.
• B. 5, 4, 1 — sai cả hai đầu.

Ghi nhớ

Ba cơ chế S3 hay bị nhầm lẫn: | Cơ chế | Việc | |---|---| | S3 Event Notification | phát sự kiện khi object được tạo, xoá, thay đổi | | S3 Lifecycle rule | chuyển lớp lưu trữ hoặc xoá theo tuổi object | | S3 Versioning | giữ nhiều phiên bản của cùng một object |

Đích của S3 event notification: | Đích | Dùng khi | |---|---| | EventBridge | linh hoạt nhất — lọc theo mẫu, nhiều target | | Lambda | xử lý ngay, đơn giản | | SQS | cần đệm, xử lý theo lô | | SNS | fan-out nhiều bên nhận |

EventBridge là lựa chọn khuyến nghị cho pipeline ML: nó cho phép lọc theo prefix và suffix linh hoạt, và thêm consumer mới mà không đụng cấu hình bucket.

Bốn thành phần của một pipeline huấn luyện lại tự động: | Thành phần | Vai trò | |---|---| | Kích hoạt | S3 event, EventBridge schedule, hoặc Model Monitor alarm | | Huấn luyện | SageMaker training job | | Cửa chất lượng | so chỉ số với model hiện tại — CHỈ triển khai nếu tốt hơn | | Triển khai | endpoint với blue/green |

Thành phần thứ ba không có trong ba bước của đề, nhưng nó là thứ nên có trong thực tế: huấn luyện lại tự động mà không kiểm tra chất lượng có thể thay một model tốt bằng một model tệ hơn — đặc biệt nguy hiểm nếu lô dữ liệu mới có vấn đề.

Và ba dịch vụ giám sát sau khi triển khai: | Dịch vụ | Giám sát | |---|---| | CloudWatch | độ trễ, số lời gọi, lỗi | | Model Monitor | data drift, model quality drift | | Clarify | bias drift, feature attribution drift |

Đáp án

A — Chuyển từ Random Search sang Bayesian Optimization và thu hẹp khoảng giá trị của các siêu tham số quan trọng.

Vì sao đúng

Đề mô tả hai triệu chứng: một số lần thử không hội tụ, và kết quả không như mong đợi. Cả hai đều chỉ về khoảng tìm kiếm quá rộng.

Hai thay đổi trong đáp án tấn công hai khía cạnh khác nhau:

① Bayesian Optimization thay Random Search — khác biệt về nguyên lý:

Random Search:  mỗi lần thử ĐỘC LẬP, không học từ lần trước
                → lãng phí lần thử vào vùng đã biết là kém

Bayesian:       dựng model xác suất về quan hệ (siêu tham số → kết quả)
                → mỗi lần thử CHỌN vùng hứa hẹn nhất
                → hội tụ nhanh hơn nhiều với cùng số lần thử

② Thu hẹp khoảng giá trị — trực tiếp sửa nguyên nhân "không hội tụ":

# Quá rộng — nhiều lần thử rơi vào vùng vô nghĩa
'learning_rate': ContinuousParameter(0.000001, 1.0)

# Hợp lý — dựa trên hiểu biết về thuật toán
'learning_rate': ContinuousParameter(0.001, 0.3, scaling_type='Logarithmic')

Với learning rate 1,0, model phân kỳ thay vì hội tụ — đó chính là "not converging effectively" mà đề mô tả.

Và scaling_type='Logarithmic' là chi tiết đáng nhớ: learning rate nên được tìm kiếm theo thang log, vì khác biệt giữa 0,001 và 0,01 lớn hơn nhiều so với giữa 0,1 và 0,11.

Hai thay đổi này bổ sung nhau: thu hẹp khoảng loại bỏ vùng vô nghĩa, Bayesian khai thác hiệu quả vùng còn lại.

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

• B. Dùng Grid Search với khoảng RỘNG cho mọi siêu tham số và tăng tổng số lần thử — hai lỗi: khoảng rộng giữ nguyên vấn đề không hội tụ, và grid search bùng nổ tổ hợp (3 siêu tham số × 10 giá trị = 1.000 lần thử). Với dữ liệu lớn như đề mô tả, đây là lựa chọn tốn kém nhất.
• C. Tăng số siêu tham số cần tinh chỉnh và mở rộng khoảng cho tất cả — đi ngược hoàn toàn: nhiều chiều hơn và khoảng rộng hơn nghĩa là không gian tìm kiếm lớn hơn theo cấp số nhân, và cùng số lần thử sẽ phủ được ít hơn.
• D. Giảm tổng số lần thử nhưng tăng số job song song để tăng tốc — hiểu sai về Bayesian: chạy song song nhiều job nghĩa là các job không học được từ nhau. Với Bayesian optimization, song song cao làm giảm hiệu quả — nó thoái hoá dần về random search. Và giảm tổng số lần thử thì càng ít cơ hội tìm được cấu hình tốt.

Ghi nhớ

Bốn chiến lược tinh chỉnh siêu tham số của SageMaker: | Chiến lược | Cách làm | Hiệu quả | |---|---|---| | Grid | vét cạn mọi tổ hợp | tệ nhất — bùng nổ tổ hợp | | Random | chọn ngẫu nhiên | song song tốt, không học | | Bayesian | học từ lần thử trước | hiệu quả nhất theo số lần thử | | Hyperband | dừng sớm nhánh kém | tiết kiệm nhất về TÀI NGUYÊN |

Cách chọn: | Tình huống | Chọn | |---|---| | Ít lần thử, muốn kết quả tốt nhất | Bayesian | | Nhiều tài nguyên song song, muốn nhanh | Random | | Model deep learning huấn luyện lâu | Hyperband — dừng sớm tiết kiệm rất nhiều | | Không gian rất nhỏ (2–3 giá trị mỗi tham số) | Grid |

Đánh đổi quan trọng của Bayesian: max_parallel_jobs càng cao thì càng kém hiệu quả, vì các job chạy song song không thấy kết quả của nhau. Quy tắc thô: đặt song song khoảng 10% tổng số lần thử.

Ba nguyên tắc đặt khoảng siêu tham số: | Nguyên tắc | Chi tiết | |---|---| | Dùng thang log cho tham số biến thiên nhiều bậc | learning rate, regularization | | Bắt đầu rộng vừa phải rồi thu hẹp | chạy một vòng thăm dò trước | | Đừng tinh chỉnh mọi thứ | 2–4 siêu tham số quan trọng nhất là đủ |

Với hầu hết model, chỉ vài siêu tham số thật sự quan trọng: learning rate gần như luôn đứng đầu, sau đó là độ sâu/kích thước model và regularization. Tinh chỉnh mười tham số cùng lúc thường tệ hơn tinh chỉnh ba tham số đúng.

Đáp án

B — 1-B, 2-D, 3-A:

• 1. Embedding → B. Biểu diễn số của văn bản (hoặc dữ liệu) trong không gian vector nhiều chiều
• 2. Token → D. Đơn vị văn bản (từ, từ con, hoặc ký tự) mà LLM xử lý
• 3. RAG → A. Phương pháp kết hợp truy xuất tri thức bên ngoài với AI sinh để cho câu trả lời chính xác và liên quan hơn

Vì sao đúng

Ba khái niệm này là nền tảng của mọi ứng dụng GenAI, và mỗi cái ở một tầng khác nhau:

Embedding — biểu diễn ý nghĩa bằng số:

"con mèo"  → [0.23, -0.81, 0.45, ...]   (1.024 chiều)
"con mèo"  và  "chú mèo"  → hai vector RẤT GẦN nhau
"con mèo"  và  "máy bay"  → hai vector xa nhau

Đây là nền tảng của tìm kiếm ngữ nghĩa: gần nhau trong không gian vector nghĩa là gần nhau về ý nghĩa.

Token — đơn vị xử lý của model:

"Học máy rất thú vị"  →  ["Học", "máy", "rất", "thú", "vị"]
"tokenization"        →  ["token", "ization"]     ← từ con

Token quan trọng vì tính tiền và giới hạn ngữ cảnh đều đo bằng token, không đo bằng từ. Quy tắc thô: 1 token ≈ 4 ký tự tiếng Anh; tiếng Việt có dấu tốn nhiều token hơn.

RAG — ghép truy xuất với sinh:

Câu hỏi → tìm tài liệu liên quan → đưa vào prompt → model trả lời có căn cứ

Hai khái niệm còn lại trong đề

Đề liệt kê năm khái niệm nhưng chỉ hỏi ba — hai cái còn lại cũng cần nhớ:

4. Temperature → E. Tham số điều khiển độ ngẫu nhiên của đầu ra: | Giá trị | Hành vi | Dùng khi | |---|---|---| | 0 – 0,3 | gần như tất định, ổn định | trích xuất dữ liệu, phân loại, sinh JSON | | 0,5 – 0,7 | cân bằng | trả lời câu hỏi, tóm tắt | | 0,8 – 1,0+ | sáng tạo, đa dạng | viết nội dung, động não ý tưởng |

5. Prompt → C. Đầu vào cung cấp cho model để hướng nó sinh ra phản hồi phù hợp.

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

• C. 1-B, 2-D, 3-C — đây là phương án gần nhất và chỉ sai ở mục cuối: 3 là RAG, và C là mô tả của Prompt, không phải RAG.
• A. 1-D, 2-B, 3-A — đảo ngược embedding và token: 1 là embedding (biểu diễn số), không phải "đơn vị văn bản".
• D. 4-C, 5-E, 3-A — hai mục đầu sai: 4 là Temperature (mô tả E), 5 là Prompt (mô tả C) — phương án này ghép ngược cả hai.

Ghi nhớ

Bảng khái niệm GenAI nền tảng: | Khái niệm | Nghĩa | Vì sao quan trọng | |---|---|---| | Token | đơn vị văn bản model xử lý | tính tiền và giới hạn ngữ cảnh đo bằng token | | Embedding | vector biểu diễn ý nghĩa | nền tảng của tìm kiếm ngữ nghĩa và RAG | | Prompt | đầu vào hướng dẫn model | chất lượng prompt quyết định chất lượng đầu ra | | Temperature | độ ngẫu nhiên của đầu ra | đặt sai là đầu ra không dùng được | | RAG | truy xuất + sinh | chống ảo giác, đưa tri thức riêng vào |

Ba tham số lấy mẫu hay đi cùng nhau: | Tham số | Điều khiển | |---|---| | Temperature | độ "phẳng" của phân bố xác suất | | Top-P (nucleus) | chỉ lấy các token có tổng xác suất tích luỹ ≤ P | | Top-K | chỉ lấy K token có xác suất cao nhất |

Khuyến nghị thực dụng: chỉnh một trong hai (temperature hoặc top-P), không chỉnh cả hai cùng lúc — chúng tương tác với nhau theo cách khó dự đoán.

Và một điểm về embedding đáng nhớ cho mọi hệ thống RAG:

Vector từ hai model embedding khác nhau KHÔNG so sánh được với nhau.

Đổi model embedding nghĩa là bắt buộc dựng lại toàn bộ index — không có cách vá cục bộ nào.

Đáp án

C — Dùng SageMaker Data Wrangler tiền xử lý dữ liệu, bao gồm biến dữ liệu PHÂN LOẠI thành dữ liệu SỐ bằng one-hot encoding và chuẩn hoá các đặc trưng số.

Vì sao đúng

Đề nêu bốn yếu tố, và Data Wrangler đáp ứng cả bốn: | Yếu tố | Data Wrangler | |---|---| | Dữ liệu ở S3 và PostgreSQL tại chỗ | connector cho cả hai | | Đặc trưng phân loại và số lẫn lộn | transform riêng cho từng loại | | Chuẩn bị cho huấn luyện | xuất thẳng sang Feature Store hoặc S3 | | Ít công sức vận hành nhất | giao diện trực quan, không viết mã |

Điểm phân biệt giữa B và C là CHIỀU của phép biến đổi, và đây là một lỗi khái niệm rõ ràng:

ĐÚNG (C):  phân loại → số     "region: Bắc/Trung/Nam" → 3 cột nhị phân
SAI   (B):  số → phân loại     ← one-hot encoding KHÔNG làm việc này

One-hot encoding chỉ đi theo một chiều: nó biến một cột phân loại thành nhiều cột nhị phân, vì thuật toán ML cần đầu vào là số:

region        →   region_Bac  region_Trung  region_Nam
"Bắc"                  1            0            0
"Trung"                0            1            0
"Nam"                  0            0            1

Và chuẩn hoá đặc trưng số là bước đi kèm cần thiết: "purchase amount" có thể từ 10.000 tới 50.000.000 còn "session duration" từ 5 tới 600 — với thuật toán phân cụm (đề nói đang xây model phân khúc khách hàng), thang đo lệch nhau làm một đặc trưng chi phối hoàn toàn khoảng cách.

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

• B. Data Wrangler tiền xử lý, bao gồm biến dữ liệu SỐ thành dữ liệu PHÂN LOẠI bằng one-hot encoding và chuẩn hoá đặc trưng số — đây là phương án gần nhất và sai ở đúng chiều biến đổi. Mọi thứ khác giống hệt C. (Biến số thành phân loại là binning, một kỹ thuật khác — xem #6487.)
• D. Dùng Glue ETL job chuyển dữ liệu phân loại sang dạng số và áp các phép biến đổi tuỳ chỉnh — đúng về kỹ thuật nhưng tốn công hơn: phải viết mã, cấu hình job, lên lịch. Trái tiêu chí "LEAST operational overhead".
• A. Dùng truy vấn Athena biến đổi THỦ CÔNG dữ liệu phân loại thành số rồi lưu lại S3 — tốn công nhất và dễ sai nhất: one-hot encoding bằng SQL đòi viết CASE WHEN cho từng giá trị, và phải sửa lại mỗi khi xuất hiện giá trị mới. Athena cũng không đọc được PostgreSQL tại chỗ.

Ghi nhớ

Các phép mã hoá đặc trưng phân loại — chọn theo bản chất dữ liệu: | Phép | Cách làm | Dùng khi | |---|---|---| | One-hot encoding | mỗi giá trị → một cột nhị phân | không có thứ tự, ít giá trị | | Ordinal encoding | gán số theo thứ tự | có thứ tự tự nhiên: "thấp/trung/cao" | | Label encoding | gán số tuỳ ý | model cây (không giả định thứ tự) | | Target encoding | thay bằng giá trị trung bình của nhãn | nhiều giá trị (high cardinality) | | Hashing | băm vào số cột cố định | rất nhiều giá trị |

Bẫy quan trọng của one-hot: bùng nổ số chiều. Một cột "mã bưu chính" với 5.000 giá trị sẽ thành 5.000 cột. Với đề này, region và customer tier đều ít giá trị nên one-hot phù hợp.

Ba phép chuẩn hoá đặc trưng số: | Phép | Công thức | Dùng khi | |---|---|---| | Standardization (Z-score) | (x − μ) / σ | phân bố gần chuẩn — mặc định tốt | | Min-max normalization | (x − min) / (max − min) | cần khoảng [0, 1] cố định | | Robust scaling | dùng trung vị và IQR | có nhiều ngoại lai |

Ba loại thuật toán cần chuẩn hoá: | Loại | Vì sao | |---|---| | Dựa trên khoảng cách (K-Means, k-NN, SVM) | thang đo lệch làm méo khoảng cách | | Mạng nơ-ron | hội tụ nhanh hơn nhiều | | Hồi quy có regularization | phạt công bằng giữa các hệ số |

Và loại không cần: model cây (decision tree, random forest, XGBoost) — chúng chia theo ngưỡng nên thang đo không ảnh hưởng. Đề này nói phân khúc khách hàng, thường dùng K-Means — nên chuẩn hoá là bắt buộc.

Đáp án

A — Dùng SageMaker Pipelines với conditional step để triển khai quy trình phê duyệt thủ công trước khi đưa model lên production.

Vì sao đúng

Đề nêu ba yêu cầu, và cái quyết định là "manual approval-based workflow" cho toàn bộ vòng đời ML: | Yêu cầu | Cơ chế | |---|---| | Quy trình ML đầu-cuối | Pipelines | | Chỉ model đã duyệt mới lên production | ConditionStep + Model Registry | | Quản lý tập trung | Model Registry |

Mẫu chuẩn kết hợp ConditionStep với trạng thái phê duyệt của Model Registry:

# ① Cửa tự động: chỉ đăng ký nếu chỉ số đạt ngưỡng
buoc_dieu_kien = ConditionStep(
    name='KiemTraChatLuong',
    conditions=[ConditionGreaterThanOrEqualTo(
        left=JsonGet(step_name='DanhGia', property_file=bao_cao,
                     json_path='metrics.auc'),
        right=0.80)],
    if_steps=[buoc_dang_ky],
    else_steps=[])

# ② Cửa thủ công: đăng ký ở trạng thái CHỜ DUYỆT
buoc_dang_ky = RegisterModel(
    ...,
    approval_status='PendingManualApproval')   # ← không tự lên production

Vòng lặp hoàn chỉnh:

Pipeline chạy → đánh giá → ConditionStep chặn model kém
                              ↓ đạt ngưỡng
                        Đăng ký ở PendingManualApproval
                              ↓
                    Người xem báo cáo và bấm duyệt
                              ↓ EventBridge bắt sự kiện đổi trạng thái
                        Pipeline triển khai chạy

Mẫu này giữ tự động hoá đầu-cuối mà vẫn có một cửa kiểm soát của con người — đúng yêu cầu quản trị nội bộ của tổ chức tài chính.

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

• C. Dùng AWS CodePipeline quản lý triển khai và đặt manual approval action cho việc cập nhật endpoint — đây là phương án gần nhất và CodePipeline thật sự có manual approval action. Nhưng nó không phải giải pháp ML đầu-cuối: đề yêu cầu hỗ trợ thử nghiệm, huấn luyện, quản lý phiên bản, triển khai và giám sát — CodePipeline chỉ lo phần triển khai. (Trong thực tế, ghép cả hai là mẫu hợp lệ: Pipelines lo phần ML, CodePipeline lo phần phát hành.)
• B. Dùng Model Monitor xác thực và phê duyệt model trước khi triển khai — sai chức năng: Model Monitor giám sát model ĐANG CHẠY (drift, chất lượng dữ liệu). Nó không tham gia vào quyết định triển khai và không có khái niệm phê duyệt.
• D. Dùng Lineage Tracking xác thực và phê duyệt model — cùng lỗi: lineage ghi lại quan hệ nguồn gốc, nó không phê duyệt gì. Nó hữu ích hỗ trợ người duyệt (biết model từ dữ liệu nào), nhưng không phải cơ chế phê duyệt.

Ghi nhớ

Hai loại cửa kiểm soát trong pipeline ML — nên có cả hai: | Cửa | Cơ chế | Chặn gì | |---|---|---| | Tự động | ConditionStep so chỉ số với ngưỡng | model kém rõ ràng | | Thủ công | PendingManualApproval trong Model Registry | model đạt ngưỡng nhưng cần người xem xét |

Cửa tự động lọc bỏ phần lớn trường hợp xấu; cửa thủ công bắt những thứ chỉ số không đo được — như "model này tốt nhưng nó học một đặc trưng ta không muốn dùng".

Ba trạng thái của Model Registry: | Trạng thái | Ý nghĩa | |---|---| | PendingManualApproval | chờ người duyệt — mặc định nên dùng cho production | | Approved | được phép triển khai | | Rejected | không đạt, giữ lại để tham chiếu |

Cách tự động hoá phần sau khi duyệt:

{
  "source": ["aws.sagemaker"],
  "detail-type": ["SageMaker Model Package State Change"],
  "detail": {"ModelApprovalStatus": ["Approved"]}
}

EventBridge rule này kích hoạt pipeline triển khai ngay khi có người bấm duyệt — không ai phải chạy lệnh gì.

Và ba thứ nên đưa vào báo cáo cho người duyệt xem: | Thứ | Vì sao | |---|---| | Chỉ số so với model hiện tại | "tốt hơn" quan trọng hơn "đạt ngưỡng" | | Báo cáo bias của Clarify | với model tín dụng là yêu cầu quy định | | Feature importance | phát hiện model học đặc trưng không nên dùng |

Với đánh giá rủi ro tín dụng như đề mô tả, cả ba đều gần như bắt buộc về mặt tuân thủ.

Đáp án

D:

• building_type_year → feature splitting (tách đặc trưng)
• city → one-hot encoding
• building_size → standardization (chuẩn hoá)

Vì sao đúng

Mỗi đặc trưng có một vấn đề riêng, và mỗi kỹ thuật giải quyết đúng một vấn đề:

① building_type_year — hai thông tin trong một cột. Đây là dấu hiệu kinh điển của việc cần tách đặc trưng:

"Office-1995"  →  building_type = "Office"   (phân loại)
                  year_constructed = 1995      (số)

Giữ nguyên thì model không dùng được cả hai: nó không so sánh được năm xây dựng, và không nhóm được theo loại toà nhà. Sau khi tách, mỗi phần được xử lý bằng kỹ thuật phù hợp với kiểu của nó.

② city — phân loại không có thứ tự. One-hot encoding là lựa chọn đúng:

city         →  city_HN  city_HCM  city_DN
"Hà Nội"           1        0        0
"TP.HCM"           0        1        0

Vì sao không dùng label encoding (gán 1, 2, 3): nó tạo ra thứ tự giả — model sẽ hiểu rằng "TP.HCM > Hà Nội" và "Đà Nẵng gấp ba Hà Nội", điều hoàn toàn vô nghĩa.

③ building_size — số liên tục, thang đo lớn. Chuẩn hoá là đúng:

Diện tích: 50 → 50.000 m²
Các đặc trưng khác: 0 → 1
→ không chuẩn hoá thì diện tích CHI PHỐI hoàn toàn

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

• C. building_type_year → feature splitting, city → one-hot, building_size → binning — đây là phương án gần nhất và sai ở mục cuối: binning làm MẤT thông tin. Với dự đoán giá thuê, diện tích là một trong những yếu tố quan trọng nhất, và chia nó thành nhóm ("nhỏ/vừa/lớn") vứt bỏ mức chi tiết mà model cần. (Binning chỉ hợp lý khi quan hệ rõ ràng phi tuyến theo bậc, hoặc khi cần giảm ảnh hưởng của ngoại lai.)
• B. building_type_year → feature splitting, city → binning, building_size → standardization — binning không áp dụng được cho dữ liệu phân loại: binning là chia giá trị số liên tục thành khoảng. "Hà Nội" không nằm trong khoảng nào cả.
• A. building_type_year → standardization, city → binning, building_size → one-hot — sai cả ba: không chuẩn hoá được một chuỗi hỗn hợp; không binning được dữ liệu phân loại; và one-hot cho một biến số liên tục sẽ tạo ra hàng nghìn cột vô nghĩa.

Ghi nhớ

Bốn kỹ thuật feature engineering — nhận biết khi nào dùng: | Kỹ thuật | Dấu hiệu cần dùng | |---|---| | Feature splitting | một cột chứa NHIỀU thông tin: "Office-1995", "Hà Nội, Việt Nam", ngày giờ | | One-hot encoding | cột PHÂN LOẠI không có thứ tự, ít giá trị | | Standardization | cột SỐ với thang đo khác nhau | | Binning | cột số mà quan hệ với nhãn là phi tuyến theo bậc |

Bảng chọn theo kiểu dữ liệu: | Kiểu | Kỹ thuật | |---|---| | Phân loại, ít giá trị, không thứ tự | one-hot | | Phân loại, có thứ tự | ordinal encoding | | Phân loại, rất nhiều giá trị | target encoding hoặc hashing | | Số, thang đo lệch | standardization hoặc min-max | | Số, nhiều ngoại lai | robust scaling | | Hỗn hợp trong một cột | tách trước, rồi xử lý từng phần |

Ba ví dụ khác của feature splitting đáng biết: | Cột gốc | Tách thành | |---|---| | Ngày giờ | năm, tháng, ngày, thứ, giờ, có phải cuối tuần | | Địa chỉ | đường, quận, thành phố, mã bưu chính | | Tên đầy đủ | họ, tên đệm, tên |

Dòng đầu đặc biệt giá trị: từ một cột timestamp, bạn tạo ra được hàng chục đặc trưng có ý nghĩa — và với dự đoán giá thuê, "quý mấy trong năm" hay "thứ mấy" có thể mang tín hiệu thật.

Và một lưu ý về year_constructed sau khi tách: có thể biến nó thành "tuổi toà nhà" (năm hiện tại − năm xây) — thường mang tín hiệu trực tiếp hơn con số năm tuyệt đối, và không bị lỗi thời khi thời gian trôi qua.

Đáp án

A — Áp dụng XGBoost nhờ khả năng xử lý dữ liệu mất cân bằng hiệu quả thông qua regularization, trọng số lớp, và hiệu quả tính toán được tối ưu.

Vì sao đúng

Cả ba kỹ thuật boosting trong đề đều hợp lệ về nguyên lý, nên câu hỏi thực chất là: cái nào có công cụ tốt nhất cho dữ liệu mất cân bằng?

XGBoost thắng ở ba điểm cụ thể:

① scale_pos_weight — xử lý mất cân bằng trực tiếp:

scale_pos_weight = so_mau_am / so_mau_duong    # ví dụ 99 nếu 1% gian lận

Tham số này tăng trọng số của lớp thiểu số trong hàm mất mát — model bị phạt nặng hơn khi bỏ sót một ca gian lận.

② Regularization (L1 và L2) dựng sẵn — quan trọng đặc biệt với dữ liệu mất cân bằng, vì model rất dễ overfit vào một nhúm nhỏ mẫu dương:

xgb.set_hyperparameters(reg_alpha=0.1, reg_lambda=1.0, max_depth=6)

Gradient Boosting truyền thống không có regularization dựng sẵn — đây là khác biệt kỹ thuật thật sự giữa hai thuật toán.

③ Metric đánh giá phù hợp:

eval_metric='aucpr'      # PR-AUC — đúng cho lớp dương hiếm

Và ba lợi ích thực dụng đi kèm: xử lý giá trị thiếu tự nhiên (giao dịch thường thiếu trường), feature importance (đội điều tra cần biết vì sao một giao dịch bị gắn cờ), và huấn luyện song song nhanh (đề nhắc "optimized computational efficiency").

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

• C. Dùng Gradient Boosting và chỉnh THỦ CÔNG learning rate và trọng số lớp, tránh sự phức tạp của XGBoost — đây là phương án gần nhất và hoạt động được, nhưng nó tự làm bằng tay thứ XGBoost có sẵn, và thiếu regularization dựng sẵn. Lập luận "tránh sự phức tạp" không đứng vững: XGBoost là thuật toán dựng sẵn của SageMaker, dùng nó không phức tạp hơn.
• B. Dùng Gradient Boosting huấn luyện tuần tự các weak learner, dùng gradient của hàm mất mát để cải thiện lớp thiểu số — mô tả đúng cơ chế nhưng thiếu công cụ: gradient boosting không tự xử lý mất cân bằng; bạn phải tự thêm trọng số, và nó vẫn thiếu regularization.
• D. Dùng AdaBoost tập trung sửa lỗi của weak classifier, tăng trọng số cho mẫu bị phân loại sai ở mỗi vòng lặp — đây là phương án đáng bàn vì AdaBoost thật sự tăng trọng số cho mẫu sai, nghe như phù hợp với mất cân bằng. Nhưng nó có hai nhược điểm nghiêm trọng ở đây: rất nhạy với nhiễu và ngoại lai (dữ liệu giao dịch đầy cả hai), và không có regularization.

Ghi nhớ

Ba biến thể boosting — khác biệt cốt lõi: | Thuật toán | Cơ chế | Điểm yếu | |---|---|---| | AdaBoost | tăng trọng số mẫu bị sai | rất nhạy với nhiễu và ngoại lai | | Gradient Boosting | khớp gradient của hàm mất mát | không có regularization dựng sẵn | | XGBoost | GB + regularization + tối ưu tính toán | phức tạp hơn về siêu tham số |

XGBoost thêm gì so với Gradient Boosting: | Bổ sung | Lợi ích | |---|---| | L1 và L2 regularization | chống overfitting | | scale_pos_weight | xử lý mất cân bằng | | Xử lý giá trị thiếu tự nhiên | không cần điền trước | | Huấn luyện song song, cache-aware | nhanh hơn nhiều | | Cắt tỉa cây theo chiều sâu | cây hiệu quả hơn |

Ba tham số XGBoost quan trọng nhất cho dữ liệu mất cân bằng: | Tham số | Việc | |---|---| | scale_pos_weight | cân bằng lớp | | eval_metric='aucpr' | đánh giá đúng | | max_depth thấp (4–6) | chống overfit vào ít mẫu dương |

Và một lưu ý: scale_pos_weight và oversampling không nên dùng cùng lúc ở mức tối đa — làm cả hai là cân bằng gấp đôi, và model sẽ dự đoán quá nhiều ca dương. Chọn một, hoặc dùng cả hai ở mức nhẹ rồi đo kết quả.

Với dữ liệu bảng như giao dịch tài chính, XGBoost và LightGBM là hai lựa chọn tiêu chuẩn — và deep learning hiếm khi vượt được chúng, như đã bàn ở #6444.

Đáp án

A — Chọn Pipe input mode để stream dữ liệu trực tiếp từ S3 tới instance huấn luyện, cho phép model bắt đầu xử lý ngay mà không cần lưu toàn bộ dataset trên đĩa cục bộ.

Vì sao đúng

Đề nêu ba yếu tố quyết định: | Yếu tố | Hệ quả | |---|---| | 10 triệu ảnh, vài terabyte | quá lớn để tải hết xuống đĩa cục bộ | | Tránh nghẽn I/O | cần thông lượng cao | | Bắt đầu huấn luyện sớm | không chờ tải xong |

Vì sao File mode không dùng được: nó tải toàn bộ dataset xuống đĩa của instance trước khi bắt đầu:

File mode với 5 TB:
  ├─ cần instance có đĩa ≥ 5 TB (đắt hoặc không tồn tại)
  └─ chờ tải xong (hàng giờ) trước khi GPU bắt đầu làm việc
      → GPU đắt tiền nằm chờ

Pipe mode stream dữ liệu qua Unix FIFO:

S3 → stream → GPU xử lý ngay
     (không lưu xuống đĩa)

Ba lợi ích: bắt đầu ngay, không cần đĩa lớn, và chồng lấn việc tải dữ liệu với việc tính toán.

Ghi chú về thực tiễn hiện nay

Cần nói rõ một điểm mà đề không nêu: AWS hiện khuyến nghị FastFile mode hơn Pipe mode cho hầu hết trường hợp.

Trong bốn phương án, A vẫn là đáp án đúng vì phương án B ghép FastFile với FSx for Lustre theo cách lẫn lộn — FastFile mode stream từ S3, còn FSx for Lustre là một hệ thống tệp riêng biệt; hai thứ này không "kết hợp" như phương án mô tả. Nhưng nếu gặp một câu tương tự có phương án "FastFile mode từ S3" đứng riêng, đó thường là lựa chọn hiện đại hơn.

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

• B. FastFile mode với FSx for Lustre, cho phép stream theo yêu cầu từ S3 với độ trễ thấp và thông lượng cao — đây là phương án gần nhất và lẫn lộn hai cơ chế khác nhau: FastFile stream từ S3, còn FSx for Lustre là một hệ thống tệp riêng mà bạn liên kết với S3 rồi mount vào instance. Chúng là hai lựa chọn thay thế nhau, không phải kết hợp. (FSx for Lustre một mình là lựa chọn rất tốt cho tình huống này, đặc biệt khi đọc lặp cùng dữ liệu qua nhiều job.)
• C. File mode tải toàn bộ dataset xuống đĩa cục bộ trước khi huấn luyện — không khả thi với vài terabyte: cần đĩa rất lớn và thời gian chờ rất dài.
• D. File mode với EFS mount dataset qua nhiều instance — EFS chậm hơn nhiều so với FSx for Lustre cho khối lượng công việc huấn luyện, và đắt hơn cho dữ liệu quy mô terabyte. EFS thiết kế cho tệp dùng chung nói chung, không phải cho thông lượng cao trong ML.

Ghi nhớ

Bốn chế độ đưa dữ liệu vào training job: | Chế độ | Cách hoạt động | Dùng khi | |---|---|---| | File | tải hết xuống đĩa trước | dataset nhỏ (< vài chục GB) | | Pipe | stream tuần tự từ S3 | dataset lớn, đọc tuần tự | | FastFile | POSIX, tải lazy theo nhu cầu | dataset lớn — khuyến nghị hiện nay | | FSx for Lustre | hệ thống tệp hiệu năng cao liên kết S3 | đọc LẶP cùng dữ liệu qua nhiều job |

Cách chọn: | Tình huống | Chọn | |---|---| | Dataset nhỏ, một job | File | | Dataset rất lớn, một hoặc vài job | FastFile | | Nhiều job liên tiếp trên cùng dataset | FSx for Lustre | | Cần truy cập ngẫu nhiên và shuffle | FastFile hoặc FSx |

Dòng thứ ba đáng chú ý cho môi trường nghiên cứu: FSx for Lustre tải dữ liệu từ S3 một lần rồi phục vụ nhiều job với độ trễ rất thấp — kết hợp với warm pool (xem #6469) cho chu trình thử nghiệm nhanh nhất.

Ba cách khác giảm nghẽn I/O khi huấn luyện với ảnh: | Cách | Chi tiết | |---|---| | Gộp ảnh thành tệp lớn | RecordIO, TFRecord, WebDataset — giảm số lời gọi S3 | | Tăng số worker tải dữ liệu | num_workers trong DataLoader | | Giảm kích thước ảnh trước | không cần độ phân giải gốc nếu model không dùng tới |

Cách đầu thường có tác động lớn nhất với 10 triệu tệp nhỏ: đọc 10 triệu object riêng lẻ từ S3 chậm hơn nhiều so với đọc vài nghìn tệp gộp, dù tổng dung lượng như nhau.

Đáp án

C — Mean Absolute Error (MAE).

Vì sao đúng

Điểm quyết định nằm ở một câu trong đề: "The model outputs a continuous numerical value" — thời gian giao hàng tính bằng giờ.

Đó là bài toán HỒI QUY, không phải phân loại — và ba phương án còn lại đều là chỉ số cho phân loại: | Chỉ số | Loại bài toán | |---|---| | MAE | hồi quy ✅ | | Accuracy | phân loại ❌ | | Precision | phân loại ❌ | | AUC-ROC | phân loại ❌ |

MAE đo sai số trung bình theo đúng đơn vị của bài toán:

MAE = trung bình của |giá trị thật − giá trị dự đoán|

MAE = 1,5  →  "trung bình model sai lệch 1,5 GIỜ"

Đây là ưu điểm lớn nhất của MAE: diễn giải trực tiếp được. Người vận hành logistics hiểu ngay "sai 1,5 giờ" nghĩa là gì — trong khi RMSE cho một con số khó diễn giải hơn.

Và MAE có một đặc tính phù hợp với dữ liệu giao hàng: ít nhạy với ngoại lai. Một chuyến hàng bị kẹt 3 ngày do bão không làm méo toàn bộ chỉ số, trong khi RMSE (bình phương sai số) sẽ bị nó chi phối.

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

• A. Accuracy — chỉ áp dụng cho phân loại: nó đếm tỷ lệ dự đoán đúng chính xác. Với giá trị liên tục, dự đoán 4,7 giờ trong khi thực tế 4,8 giờ là "sai" theo accuracy — dù đó là một dự đoán rất tốt.
• B. Precision — cũng là chỉ số phân loại, đo tỷ lệ dự đoán dương đúng. Không có khái niệm "dương tính" trong bài toán dự đoán số giờ.
• D. AUC-ROC — đo khả năng phân biệt hai lớp qua các ngưỡng. Không có hai lớp nào ở đây.

Ghi nhớ

Chỉ số theo loại bài toán — bảng nền tảng cần thuộc: | Loại | Chỉ số | |---|---| | Hồi quy | MAE, MSE, RMSE, R², MAPE | | Phân loại nhị phân | Accuracy, Precision, Recall, F1, AUC-ROC, PR-AUC | | Phân loại nhiều lớp | Accuracy, macro/micro F1, confusion matrix | | Phân cụm | Silhouette score, Davies–Bouldin | | Xếp hạng | NDCG, MAP |

So sánh các chỉ số hồi quy: | Chỉ số | Công thức | Đặc điểm | |---|---|---| | MAE | trung bình |sai số| | cùng đơn vị, ít nhạy ngoại lai | | MSE | trung bình (sai số)² | phạt nặng sai số lớn, đơn vị bình phương | | RMSE | √MSE | cùng đơn vị, nhạy với ngoại lai | | R² | tỷ lệ phương sai giải thích được | không có đơn vị, so sánh giữa bài toán | | MAPE | trung bình |sai số|/thật × 100% | phần trăm — dễ hiểu, nhưng hỏng khi giá trị thật gần 0 |

Cách chọn giữa MAE và RMSE — đây là quyết định nghiệp vụ: | Tình huống | Chọn | |---|---| | Mọi sai số đều tệ như nhau theo tỷ lệ | MAE | | Sai số LỚN tệ hơn nhiều lần sai số nhỏ | RMSE | | Có nhiều ngoại lai không tránh được | MAE |

Với dự đoán thời gian giao hàng, cần cân nhắc: nếu sai 5 giờ tệ hơn 5 lần sai 1 giờ (khách huỷ đơn), RMSE phù hợp hơn. Nếu chỉ cần biết mức sai trung bình, MAE dễ truyền đạt hơn.

Và một chỉ số đáng cân nhắc thêm cho bài toán này: quantile loss. Với giao hàng, thường dự đoán muộn tệ hơn dự đoán sớm — quantile regression cho phép tối ưu bất đối xứng đó, thay vì phạt hai chiều như nhau.

Đáp án

D — Amazon SageMaker Data Wrangler.

Vì sao đúng

Đề nêu bốn việc và một ràng buộc, và cả năm đều khớp với Data Wrangler: | Việc | Data Wrangler | |---|---| | Chọn lọc dữ liệu | connector và bộ lọc | | Làm sạch | 300+ transform dựng sẵn | | Thăm dò | Data Quality and Insights Report | | Trực quan hoá | biểu đồ phân bố, tương quan, ngoại lai | | Trong MỘT giao diện trực quan duy nhất | đúng thiết kế của công cụ |

Cụm cuối là điểm quyết định — "using a single visual interface" — và đó là lý do tồn tại của Data Wrangler:

Data Wrangler (một giao diện):
  ├─ Kết nối: S3, Athena, Redshift, Snowflake, Databricks, JDBC
  ├─ Thăm dò: thống kê mô tả, biểu đồ, phát hiện vấn đề
  ├─ Làm sạch: xử lý thiếu, ngoại lai, trùng lặp
  ├─ Biến đổi: mã hoá, chuẩn hoá, tạo đặc trưng
  └─ Xuất: S3, Feature Store, hoặc bước trong SageMaker Pipeline

Và với hàng triệu dòng dữ liệu bảng, Data Wrangler xử lý được: nó lấy mẫu để hiển thị tương tác nhưng áp dụng phép biến đổi lên toàn bộ dữ liệu khi xuất — nên bạn thao tác nhanh mà kết quả vẫn đầy đủ.

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

• C. Amazon SageMaker Clarify — đây là phương án dễ nhầm vì Clarify có sinh biểu đồ và báo cáo, nhưng nó chuyên về thiên lệch và khả năng giải thích, không phải chuẩn bị dữ liệu. Nó không làm sạch, không biến đổi, không tạo đặc trưng.
• B. Amazon SageMaker Feature Store — lưu trữ và phục vụ đặc trưng đã chuẩn bị xong; nó không chuẩn bị chúng. Feature Store là đích đến của Data Wrangler, không phải thay thế.
• A. SageMaker Model Dashboard — giám sát các model đã triển khai (trạng thái endpoint, cảnh báo drift, model card). Hoàn toàn không liên quan tới chuẩn bị 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: chọn, làm sạch, biến đổi, trực quan hoá | | Feature Store | LƯU và PHỤC VỤ đặc trưng đã chuẩn bị | | Clarify | THIÊN LỆCH và GIẢI THÍCH | | Ground Truth | GÁN NHÃN dữ liệu | | Model Dashboard | giám sát model đang chạy |

Luồng làm việc điển hình dùng ba công cụ đầu:

Dữ liệu thô (S3, Redshift, JDBC)
    ↓ Data Wrangler: làm sạch, biến đổi
    ↓ Feature Store: lưu đặc trưng, dùng chung cho train và serve
    ↓ Training job
    ↓ Clarify: kiểm tra thiên lệch và giải thích
Model

Bốn khả năng của Data Wrangler đáng nhớ: | Khả năng | Chi tiết | |---|---| | Data Quality and Insights Report | phát hiện rò rỉ mục tiêu, ngoại lai, mất cân bằng, cột trùng | | Quick Model | huấn luyện thử nhanh để ước lượng chất lượng đặc trưng | | 300+ transform dựng sẵn | không cần viết mã | | Xuất thành pipeline | biến các bước trực quan thành mã chạy lại được |

Khả năng cuối quan trọng cho việc chuyển từ thăm dò sang sản xuất: bạn làm sạch dữ liệu bằng giao diện, rồi xuất thành một ProcessingStep để chạy lại tự động trong pipeline — không phải viết lại bằng tay.

Và Data Quality and Insights Report nên là việc đầu tiên chạy trên bất kỳ dataset mới nào: nó thường phát hiện ngay những vấn đề mà nếu bỏ sót sẽ tốn nhiều ngày gỡ lỗi về sau — đặc biệt là rò rỉ mục tiêu, nguyên nhân số một của những model "quá tốt để là thật".