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

Đáp án

B — Dùng Amazon QuickSight tạo dashboard trực quan tích hợp dữ liệu từ CloudWatch Logs qua Amazon S3, cung cấp biểu đồ tương tác cho phép người xem đi sâu vào từng chỉ số khi cần.

Vì sao đúng

Đề nêu bốn yêu cầu, và cụm quyết định là "support both technical and non-technical users": | Yêu cầu | QuickSight | |---|---| | Dashboard tập trung nhiều model, nhiều môi trường | tích hợp nhiều nguồn dữ liệu | | Thân thiện với người dùng | giao diện BI, không cần biết truy vấn | | Thấy được thông tin ngay lập tức | biểu đồ trực quan | | Phục vụ CẢ người không chuyên kỹ thuật | đây là điểm mạnh riêng của QuickSight |

Vì sao QuickSight hơn CloudWatch Dashboard cho đối tượng này: | | CloudWatch Dashboard | QuickSight | |---|---|---| | Đối tượng | kỹ sư vận hành | cả kỹ thuật lẫn nghiệp vụ | | Tương tác | hạn chế | drill-down, lọc, cắt lát | | Kết hợp nhiều nguồn | chỉ metric AWS | S3, Athena, RDS, Redshift, SaaS | | Chỉ số nghiệp vụ | khó đưa vào | ✅ dễ |

Dòng cuối là điểm quan trọng cho một dashboard mà lãnh đạo cũng xem: họ quan tâm tới tỷ lệ chuyển đổi của hệ thống gợi ý, không chỉ độ trễ p99 — và QuickSight kết hợp được cả hai loại chỉ số trên cùng một trang.

Luồng dữ liệu:

CloudWatch Logs / Metrics
    ↓ export sang S3
    ↓ Athena hoặc Glue Catalog
QuickSight (SPICE để tăng tốc)
    ↓
Dashboard chia sẻ cho các bên liên quan

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

• D. Lập CloudWatch Dashboard tổng hợp chỉ số như CPU, bộ nhớ, độ trễ, và dùng SNS gửi báo cáo hằng ngày — đây là phương án gần nhất và CloudWatch Dashboard là công cụ tốt cho đội kỹ thuật, nhưng nó kém phù hợp với người không chuyên: giao diện thiên về vận hành, ít tương tác, và khó kết hợp chỉ số nghiệp vụ. Đề nhấn mạnh "user-friendly" và "non-technical users".
• C. Tạo ứng dụng web tuỳ chỉnh kéo dữ liệu từ CloudWatch Logs, sinh biểu đồ thời gian thực, nhúng vào cổng nội bộ — tự dựng lại một công cụ BI: phải phát triển, bảo trì, xử lý bảo mật và phân quyền. Trái tinh thần chọn dịch vụ có sẵn.
• A. Dùng Lambda truy vấn CloudWatch Logs và gửi kết quả sang S3 hằng ngày, để người xem tự tạo trực quan hoá bằng phần mềm BẢNG TÍNH — đẩy công việc sang người dùng, và bảng tính không phải dashboard: không tương tác, không tự cập nhật, và mỗi người tự làm một kiểu.

Ghi nhớ

Ba công cụ dashboard trên AWS — chọn theo đối tượng: | Công cụ | Đối tượng | Mạnh ở | |---|---|---| | CloudWatch Dashboard | kỹ sư vận hành | metric hạ tầng thời gian thực, alarm | | QuickSight | cả kỹ thuật lẫn nghiệp vụ | BI, drill-down, kết hợp nhiều nguồn | | Managed Grafana | kỹ sư SRE | metric và trace, nhiều nguồn, cộng đồng plugin |

Dòng cuối đáng biết: Amazon Managed Grafana là lựa chọn mạnh cho đội kỹ thuật muốn dashboard phong phú hơn CloudWatch mà không cần đầy đủ tính năng BI của QuickSight.

Ba loại chỉ số cần có trên dashboard model ML: | Loại | Ví dụ | Đối tượng | |---|---|---| | Hạ tầng | CPU, bộ nhớ, số instance | kỹ sư | | Model | độ trễ, thông lượng, tỷ lệ lỗi, độ chính xác | kỹ sư ML | | Nghiệp vụ | tỷ lệ chuyển đổi, doanh thu, mức độ hài lòng | lãnh đạo |

Một dashboard tốt cho nhiều đối tượng thường chia thành nhiều trang — trang tổng quan cho lãnh đạo với chỉ số nghiệp vụ, trang chi tiết cho kỹ sư.

Ba tính năng của QuickSight hữu ích cho trường hợp này: | Tính năng | Chi tiết | |---|---| | SPICE | bộ nhớ đệm trong RAM — dashboard phản hồi nhanh với dữ liệu lớn | | Row-level security | mỗi đội chỉ thấy model của mình | | Anomaly detection dựng sẵn | tự đánh dấu điểm bất thường |

Tính năng thứ hai đáng dùng khi nhiều đội chia sẻ một dashboard: cùng một trang, nhưng mỗi người thấy dữ liệu trong phạm vi của họ.

Và một lưu ý về chi phí: QuickSight tính tiền theo người dùng (author và reader). Với dashboard chia sẻ rộng, cân nhắc embedded dashboard hoặc gói reader — rẻ hơn nhiều so với cấp author cho mọi người.

Đáp án

A và B.

• B — Dùng Amazon Managed Service for Apache Flink xử lý và tổng hợp dữ liệu theo thời gian thực từ Kinesis Data Streams, ghi kết quả tổng hợp vào S3
• A — Dùng Kinesis Data Firehose đọc từ Kinesis Data Streams, tổng hợp qua Lambda trung gian, và ghi kết quả vào S3 với cửa sổ đệm 1 phút

Vì sao đúng

Đề nêu ba yêu cầu, và cả hai đáp án đáp ứng được: | Yêu cầu | Chi tiết | |---|---| | Tổng hợp theo cửa sổ MỘT PHÚT | page view, thời gian mỗi phiên | | Độ trễ thấp | xử lý thời gian thực | | Ít công sức vận hành | dịch vụ được quản lý |

B — Flink là công cụ chuyên cho tổng hợp theo cửa sổ:

CREATE STREAM tong_hop_phut AS
SELECT STREAM ma_phien,
       COUNT(*) AS so_page_view,
       MAX(thoi_diem) - MIN(thoi_diem) AS thoi_gian_phien
FROM   nguon_clickstream
GROUP BY ma_phien,
         STEP(nguon_clickstream.ROWTIME BY INTERVAL '1' MINUTE);

Flink có hỗ trợ cửa sổ thời gian dựng sẵn (tumbling, sliding, session window) — đúng thứ bài toán cần, và quản lý trạng thái giữa các sự kiện trong cùng cửa sổ.

A — Firehose với Lambda transform và buffer một phút:

Kinesis Data Streams
    ↓ Firehose đọc
    ↓ Lambda transform (tổng hợp)
    ↓ buffer 60 giây
S3

Đây là cách đơn giản hơn cho các phép tổng hợp không cần trạng thái phức tạp, và buffer interval của Firehose khớp đúng với cửa sổ một phút mà đề yêu cầu.

Hai cách này đại diện cho hai mức độ phức tạp: Flink mạnh hơn (xử lý được session window, sự kiện đến muộn, trạng thái phức tạp), Firehose + Lambda đơn giản hơn và ít thành phần hơn.

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

• C. Khởi động cụm EMR với Spark Streaming xử lý luồng Kinesis, tổng hợp thời gian thực và lưu vào Redshift — đây là phương án gần nhất về mặt năng lực (Spark Streaming tổng hợp được), nhưng nó tốn công vận hành nhất: phải quản lý cụm EMR, viết mã Spark. Trái yêu cầu "minimal operational overhead". (Và Spark Streaming hoạt động theo micro-batch, nên độ trễ cao hơn Flink.)
• D. Dùng SageMaker Processing job ĐỊNH KỲ kéo dữ liệu từ Kinesis, tổng hợp, ghi vào S3 — không phải xử lý luồng: Processing job chạy theo lô, và "periodically pull" nghĩa là độ trễ tính bằng phút tới hàng chục phút. Trái yêu cầu "low-latency".
• E. Dùng OpenSearch Service nạp trực tiếp từ Kinesis Data Streams và cấu hình dashboard thực hiện tổng hợp theo phút — hai vấn đề: dashboard tổng hợp lúc hiển thị, không tạo ra đặc trưng lưu lại được cho model; và OpenSearch không nhận trực tiếp từ Data Streams (cần Firehose hoặc ingestion pipeline ở giữa).

Ghi nhớ

Bốn dịch vụ streaming và vai trò: | Dịch vụ | Việc | |---|---| | Kinesis Data Streams | thu nhận, lưu tạm, nhiều consumer | | Kinesis Data Firehose | giao tới đích, có buffer và Lambda transform | | Managed Service for Apache Flink | XỬ LÝ và TỔNG HỢP luồng — có trạng thái | | Amazon MSK | Kafka được quản lý |

Ba loại cửa sổ thời gian trong xử lý luồng: | Loại | Đặc điểm | |---|---| | Tumbling | cửa sổ cố định không chồng lấn — "mỗi 1 phút" ← câu này | | Sliding | chồng lấn — "1 phút, cập nhật mỗi 10 giây" | | Session | nhóm theo khoảng im lặng — hợp với phiên người dùng |

Dòng cuối đáng cân nhắc cho bài toán clickstream: session window nhóm sự kiện của một người dùng lại cho tới khi họ ngừng hoạt động — thường phản ánh đúng "phiên" hơn cửa sổ một phút cứng. Flink hỗ trợ, Firehose + Lambda thì không.

Ba lý do chọn Flink thay vì Firehose + Lambda: | Lý do | Chi tiết | |---|---| | Cần trạng thái phức tạp | session window, join giữa các luồng | | Xử lý sự kiện đến muộn | watermark — sự kiện trễ vẫn vào đúng cửa sổ | | Tổng hợp nhiều bước | pipeline xử lý phức tạp |

Dòng giữa quan trọng với clickstream thật: sự kiện từ mobile có thể đến muộn hàng chục giây do mạng. Không xử lý watermark thì chúng bị bỏ hoặc rơi vào cửa sổ sai.

Và về đích lưu kết quả — với mục đích sinh đặc trưng cho model: | Đích | Dùng khi | |---|---| | S3 | huấn luyện theo lô, phân tích | | SageMaker Feature Store (online) | suy luận thời gian thực cần đặc trưng này | | DynamoDB | tra cứu nhanh theo khoá |

Đề nói kết quả dùng cho "feature generation" — nên nếu model gợi ý cần đặc trưng này lúc suy luận, ghi vào Feature Store online store thay vì chỉ S3 sẽ phù hợp hơn.

Đáp án

B — L1 regularization (Lasso), vì nó có thể thu hệ số của một số đặc trưng về ĐÚNG 0, qua đó thực hiện chọn lọc đặc trưng.

Vì sao đúng

Đề nêu hai mục tiêu, và L1 là lựa chọn duy nhất đạt được cả hai: | Mục tiêu | L1 | |---|---| | Giảm overfitting | ✅ như mọi regularization | | ĐƠN GIẢN HOÁ model bằng cách loại bỏ đặc trưng ít quan trọng | ✅ chỉ L1 làm được |

Khác biệt cốt lõi giữa L1 và L2 nằm ở hình dạng hàm phạt:

L1 (Lasso):  phạt = λ · Σ |wᵢ|       → hệ số về ĐÚNG 0
L2 (Ridge):  phạt = λ · Σ wᵢ²        → hệ số nhỏ dần nhưng KHÔNG bao giờ bằng 0

Vì sao L1 đưa được về 0 mà L2 thì không — trực giác hình học:

L1: vùng ràng buộc là hình THOI (có GÓC NHỌN trên các trục)
    → nghiệm tối ưu hay rơi vào góc → một số hệ số = 0

L2: vùng ràng buộc là hình TRÒN (không có góc)
    → nghiệm hiếm khi nằm đúng trên trục → hệ số nhỏ nhưng khác 0

Kết quả thực tế với bài toán giá nhà:

Trước:  50 đặc trưng (vị trí, diện tích, số phòng, 47 tiện ích...)
Sau L1: 12 đặc trưng có hệ số khác 0
        → model đơn giản hơn, dễ giải thích hơn, ít overfit hơn

Và đề nói "some features have very high variance, leading to overfitting" — L1 loại bỏ chính những đặc trưng không đóng góp đủ để bù cho hình phạt.

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

• C. L1 regularization, vì nó phạt hệ số LỚN nặng hơn, làm model ít nhạy với đặc trưng phương sai cao — đây là phương án gần nhất và chọn đúng L1 nhưng giải thích SAI: chính L2 mới phạt hệ số lớn nặng hơn (vì bình phương). L1 phạt tuyến tính, nên nó phạt hệ số nhỏ tương đối nặng hơn — và đó là lý do nó đẩy chúng về 0.
• D. L2 regularization, vì nó loại bỏ đặc trưng ít quan trọng bằng cách đặt hệ số về 0 — gán cho L2 tính chất của L1: L2 không bao giờ đưa hệ số về đúng 0.
• A. L2 regularization, vì nó giảm đều mọi hệ số, cho model ổn định hơn — mô tả L2 chính xác, nhưng nó không đạt mục tiêu thứ hai: đề yêu cầu loại bỏ đặc trưng, mà L2 giữ lại tất cả.

Ghi nhớ

So sánh L1 và L2 — bảng nền tảng: | | L1 (Lasso) | L2 (Ridge) | |---|---|---| | Hàm phạt | λ · Σ|wᵢ| | λ · Σwᵢ² | | Hệ số về 0 | ✅ | ❌ | | Kết quả | model THƯA (sparse) | model dày, hệ số nhỏ | | Chọn lọc đặc trưng | ✅ | ❌ | | Với đặc trưng tương quan | chọn MỘT, bỏ phần còn lại | chia đều hệ số cho cả nhóm | | Nghiệm | không có công thức đóng | có công thức đóng |

Dòng áp chót đáng chú ý: với một nhóm đặc trưng tương quan cao, L1 chọn tuỳ ý một cái — kết quả có thể không ổn định giữa các lần chạy. L2 giữ cả nhóm với hệ số nhỏ hơn.

Elastic Net kết hợp cả hai và giải quyết chính vấn đề đó:

phạt = λ₁ · Σ|wᵢ| + λ₂ · Σwᵢ²

Với dữ liệu bất động sản (nơi diện tích, số phòng, số tầng thường tương quan), Elastic Net thường là lựa chọn tốt hơn L1 thuần.

Cách chọn nhanh: | Mục tiêu | Chọn | |---|---| | Giảm overfitting nói chung | L2 | | Chọn lọc đặc trưng, model thưa | L1 | | Nhiều đặc trưng tương quan + muốn chọn lọc | Elastic Net | | Model cây | không dùng L1/L2 — dùng max_depth, min_child_weight |

Dòng cuối đáng nhớ: regularization L1/L2 áp cho model có hệ số (tuyến tính, mạng nơ-ron). Với model cây, cơ chế chống overfitting khác hẳn — giới hạn độ sâu, số mẫu tối thiểu mỗi lá, và subsample. (XGBoost có tham số reg_alpha và reg_lambda áp cho trọng số lá — nhưng đó là cơ chế khác với L1/L2 trên hệ số đặc trưng.)

Và một lưu ý bắt buộc: phải chuẩn hoá đặc trưng trước khi dùng regularization. Hình phạt áp lên độ lớn hệ số, mà hệ số phụ thuộc thang đo — đặc trưng đo bằng đơn vị nhỏ sẽ có hệ số lớn và bị phạt nặng một cách bất công.

Đáp án

D — Dùng Amazon Comprehend cùng SageMaker Data Wrangler để che các trường dữ liệu nhạy cảm, và dùng Data Wrangler chuẩn bị cùng biến đổi tập dữ liệu.

Vì sao đúng

Đề nêu hai yêu cầu có vẻ mâu thuẫn nhau, và đó là điểm mấu chốt: | Yêu cầu | Hệ quả | |---|---| | Che dữ liệu nhạy cảm trước khi chia sẻ | phải xử lý số bảo hiểm xã hội, thông tin liên hệ | | GIỮ NGUYÊN cấu trúc và THỨ TỰ có ý nghĩa của dữ liệu | không được xoá cột hay phá vỡ quan hệ |

Che (mask) khác với xoá (remove) — và đó là lý do đáp án D thắng phương án B:

XOÁ:  bỏ hẳn cột "ngày nhập viện" → mất thứ tự thời gian, mất đặc trưng quan trọng

CHE:  ngày nhập viện giữ nguyên (không nhạy cảm)
      số bảo hiểm xã hội → thay bằng token hoặc nhãn
      → cấu trúc còn nguyên, dữ liệu nhạy cảm biến mất

Comprehend nhận diện thực thể PII tự động — không cần bạn liệt kê từng loại:

comprehend.detect_pii_entities(Text=van_ban, LanguageCode='en')
# → [{'Type': 'SSN', 'BeginOffset': 45, 'EndOffset': 56, 'Score': 0.99},
#     {'Type': 'PHONE', ...}, {'Type': 'EMAIL', ...}]

Và Data Wrangler ghép hai việc trong một luồng: nó có transform PII dựng sẵn (dùng Comprehend bên dưới), rồi tiếp tục làm sạch và biến đổi dữ liệu — tất cả trong một giao diện, xuất ra được thành ProcessingStep để chạy lại.

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

• B. Dùng AWS Glue XOÁ HẲN các trường nhạy cảm trước khi chia sẻ — đây là phương án gần nhất và vi phạm yêu cầu thứ hai: xoá trường là mất thông tin. Với dữ liệu y tế, một số trường "nhạy cảm" vẫn mang tín hiệu (ví dụ mã vùng trong địa chỉ có thể liên quan tới yếu tố môi trường) — che giữ được cấu trúc mà xoá thì không.
• A. Lưu trên S3 có mã hoá và chia sẻ qua Athena, nối Athena với SageMaker — mã hoá không phải che dữ liệu: nó bảo vệ dữ liệu khi lưu và khi truyền, nhưng người có quyền đọc vẫn thấy toàn bộ số bảo hiểm xã hội ở dạng rõ. Đây là hiểu nhầm phổ biến giữa kiểm soát truy cập và giảm thiểu dữ liệu.
• C. Dùng Amazon Inspector giám sát và cảnh báo về dữ liệu nhạy cảm — sai dịch vụ hoàn toàn: Inspector là dịch vụ quét lỗ hổng bảo mật cho EC2, container và Lambda (CVE, cấu hình sai). Nó không quét nội dung dữ liệu. (Dịch vụ quét dữ liệu nhạy cảm trong S3 là Macie — xem #6583.)

Ghi nhớ

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

Ba mức xử lý dữ liệu nhạy cảm, và tác động tới tính hữu dụng: | Mức | Ví dụ | Giữ được cấu trúc | |---|---|---| | Xoá (redaction) | bỏ hẳn cột | thấp | | Che bằng nhãn | {SSN} | cao | | Token hoá | KH_A1B2 — nhất quán | cao nhất — vẫn nối được bản ghi |

Mức thứ ba đáng dùng khi cần theo dõi cùng một bệnh nhân qua nhiều bản ghi mà không biết họ là ai — token giống nhau cho cùng một người, nhưng không suy ngược ra danh tính được.

Ba loại định danh cần phân biệt — điểm hay bị bỏ sót: | Loại | Ví dụ | Xử lý | |---|---|---| | Trực tiếp | số bảo hiểm, tên, số điện thoại | che hoặc token hoá | | Quasi-identifier | ngày sinh, mã bưu chính, giới tính | khái quát hoá | | Nhạy cảm | chẩn đoán, kết quả xét nghiệm | giữ lại (đây là thứ cần phân tích) |

Loại thứ hai là chỗ mà hầu hết vụ tái định danh xảy ra: xoá tên là chưa đủ — kết hợp ngày sinh chính xác, mã bưu chính và ngày khám thường đủ để xác định một người. Với dữ liệu y tế, cần khái quát hoá (nhóm tuổi thay vì ngày sinh) bên cạnh việc che định danh trực tiếp.

Và Comprehend Medical đáng biết cho lĩnh vực y tế: nó có API DetectPHI nhận diện được các loại PHI đặc thù (mã bệnh án, tên cơ sở khám, số bảo hiểm y tế) mà bộ nhận diện PII thông thường bỏ sót.

Đáp án

C — Dùng AWS CDK làm hạ tầng là mã, cho phép định nghĩa hạ tầng bằng ngôn ngữ lập trình cấp cao, và triển khai microservice bằng Amazon EKS để có điều phối nâng cao và khả năng mở rộng.

Vì sao đúng

Đề yêu cầu hai quyết định, và mỗi cái có lý do riêng: | Quyết định | Lựa chọn | Lý do | |---|---|---| | Công cụ IaC | CDK | ngôn ngữ lập trình — trừu tượng hoá và tái sử dụng tốt hơn | | Dịch vụ container | EKS | điều phối nâng cao cho nhiều microservice |

Vì sao CDK hơn CloudFormation thuần cho kiến trúc microservice:

// Định nghĩa MỘT lần, tái sử dụng cho mọi microservice
class Microservice extends Construct {
  constructor(scope: Construct, id: string, props: MicroserviceProps) {
    // ECR repo, deployment, service, HPA, ingress...
  }
}

new Microservice(this, 'XacThuc', { ... });
new Microservice(this, 'XuLyDuLieu', { ... });
new Microservice(this, 'GoiY', { ... });

Với YAML thuần, ba microservice nghĩa là sao chép ba khối cấu hình gần giống nhau — và mỗi lần sửa phải sửa ba chỗ.

Ba lợi ích cụ thể của CDK: | Lợi ích | Chi tiết | |---|---| | Trừu tượng hoá bằng construct | viết một lần, dùng nhiều lần | | Kiểm tra kiểu lúc biên dịch | bắt lỗi trước khi triển khai | | Vòng lặp, điều kiện, hàm | logic thật, không phải template |

Và EKS cho vế điều phối: với nhiều microservice có phụ thuộc lẫn nhau, Kubernetes cung cấp service discovery, rolling update, health check, và autoscaling ở mức pod — những thứ mà chạy container trực tiếp phải tự lo.

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

• B. Dùng CDK với ECS trên EC2 để kết hợp sự linh hoạt của ngôn ngữ lập trình với kiểm soát trực tiếp hạ tầng máy chủ — đây là phương án gần nhất và CDK là lựa chọn đúng, nhưng ECS trên EC2 nghĩa là bạn quản lý cả cụm máy chủ: vá lỗi, AMI, capacity provider. Đề không nêu yêu cầu nào cần kiểm soát ở mức đó, và nó đi ngược mục tiêu "standardize and automate".
• A. Dùng CloudFormation và ECR với Fargate chạy microservice mà không cần quản lý máy chủ — Fargate là lựa chọn hợp lý, nhưng phương án này nhầm vai của ECR: ECR là kho chứa image, không phải dịch vụ chạy container. Và CloudFormation thuần kém hơn CDK cho kiến trúc nhiều thành phần lặp lại.
• D. CloudFormation với YAML và Amazon Lightsail Containers — Lightsail dành cho ứng dụng đơn giản quy mô nhỏ: nó cố tình giới hạn tính năng để dễ dùng, và không phù hợp với kiến trúc microservice cần mở rộng.

Ghi nhớ

So sánh hai công cụ IaC chính: | | CloudFormation | CDK | |---|---|---| | Ngôn ngữ | YAML/JSON khai báo | TypeScript, Python, Java, Go | | Trừu tượng hoá | template lồng nhau | construct — mạnh hơn nhiều | | Kiểm tra lỗi | lúc triển khai | lúc biên dịch | | Đường cong học | thấp hơn | cao hơn | | Kết quả | template | sinh ra CloudFormation |

CDK biên dịch xuống CloudFormation — nên mọi khả năng của CloudFormation đều dùng được, và bạn xem được template sinh ra bằng cdk synth.

Ba lựa chọn chạy container trên AWS: | Lựa chọn | Đặc điểm | |---|---| | ECS | đơn giản hơn, tích hợp sâu AWS | | EKS | Kubernetes chuẩn — di động, hệ sinh thái lớn | | Fargate | serverless — dùng được với CẢ ECS lẫn EKS |

Fargate không phải lựa chọn thay thế ECS/EKS — nó là chế độ tính toán cho chúng:

ECS + EC2     → bạn quản lý node
ECS + Fargate → AWS quản lý node
EKS + EC2     → bạn quản lý node
EKS + Fargate → AWS quản lý node

Cách chọn giữa ECS và EKS: | Tình huống | Chọn | |---|---| | Đội đã quen Kubernetes | EKS | | Cần di động giữa các cloud | EKS | | Muốn đơn giản nhất, chỉ chạy trên AWS | ECS | | Nhiều microservice có phụ thuộc phức tạp | EKS ← câu này |

Và một đánh đổi cần biết: EKS tốn hơn về vận hành — có phí cụm cố định và cần kiến thức Kubernetes. Với ít hơn năm dịch vụ đơn giản, ECS + Fargate thường là lựa chọn thực dụng hơn.

Đáp án

C — Huấn luyện model trong deep learning là việc dùng tập dữ liệu lớn để điều chỉnh trọng số và bias của mạng nơ-ron qua nhiều vòng lặp, dùng các kỹ thuật như gradient descent để tối thiểu hoá sai số.

Vì sao đúng

Đáp án này mô tả đúng ba thành phần cốt lõi của quá trình huấn luyện: | Thành phần | Vai trò | |---|---| | Dữ liệu lớn | model học từ ví dụ, không từ luật | | Điều chỉnh trọng số và bias | đây chính là "học" | | Gradient descent qua nhiều vòng lặp | cơ chế tìm giá trị tốt |

Vòng lặp huấn luyện một bước:

① Forward pass:   đưa dữ liệu qua mạng → dự đoán
② Tính loss:      so dự đoán với nhãn thật → sai số
③ Backward pass:  lan truyền ngược, tính gradient của loss theo từng trọng số
④ Cập nhật:       w ← w − η · ∂L/∂w        (η = learning rate)
    ↓ lặp lại hàng nghìn tới hàng triệu lần
Trọng số hội tụ về giá trị làm loss nhỏ

Trực giác về gradient descent:

Loss là một "địa hình" trong không gian trọng số
Gradient chỉ hướng DỐC LÊN
    → đi ngược hướng gradient = đi xuống thấp
    → lặp lại cho tới khi tới đáy (loss nhỏ nhất)

Và learning rate là độ dài mỗi bước: quá lớn thì nhảy qua đáy và dao động; quá nhỏ thì đi rất lâu mới tới.

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

• A. Huấn luyện là việc ĐẶT TAY trọng số và bias dựa trên luật định trước — đây là mô tả hệ chuyên gia (expert system), không phải học máy. Toàn bộ giá trị của deep learning nằm ở chỗ model tự tìm ra trọng số từ dữ liệu, thay vì con người phải khai chúng. Với mạng có hàng triệu tham số, đặt tay là bất khả thi.
• B. Huấn luyện KHÔNG cần dữ liệu; mạng tự học từ thuật toán định sẵn mà không cần đầu vào nào — mâu thuẫn với bản chất của học máy: model học từ dữ liệu. Không có dữ liệu thì không có gì để học.
• D. Huấn luyện chỉ dùng SVM và cây quyết định — nhầm hai họ thuật toán: SVM và cây quyết định là model học máy cổ điển, không phải mạng nơ-ron. Deep learning dựa trên mạng nơ-ron nhiều tầng.

Ghi nhớ

Bốn khái niệm nền tảng của huấn luyện: | Khái niệm | Nghĩa | |---|---| | Forward propagation | đưa dữ liệu qua mạng để có dự đoán | | Loss function | đo sai số giữa dự đoán và nhãn thật | | Backpropagation | tính gradient của loss theo từng trọng số | | Optimizer | quy tắc cập nhật trọng số từ gradient |

Ba loại tham số cần phân biệt: | Loại | Ai quyết định | Ví dụ | |---|---|---| | Model parameter | model HỌC | trọng số, bias | | Hyperparameter | CON NGƯỜI đặt trước | learning rate, số tầng, batch size | | Inference parameter | đặt lúc dùng | temperature, top-p (với LLM) |

Các biến thể của gradient descent: | Biến thể | Đặc điểm | |---|---| | Batch GD | dùng toàn bộ dữ liệu mỗi bước — chính xác nhưng rất chậm | | Stochastic GD (SGD) | một mẫu mỗi bước — nhanh nhưng nhiễu | | Mini-batch GD | một lô nhỏ mỗi bước — cân bằng, dùng phổ biến nhất |

Ba optimizer thường dùng: | Optimizer | Đặc điểm | |---|---| | SGD | đơn giản, cần chỉnh learning rate cẩn thận | | SGD + momentum | giữ đà — vượt được cực tiểu cục bộ nông | | Adam | tự điều chỉnh learning rate theo từng tham số — mặc định tốt |

Adam thường là lựa chọn đầu tiên cho deep learning vì nó ít nhạy với việc chọn learning rate — một lý do khiến việc huấn luyện dễ hơn.

Và ba vấn đề hay gặp trong quá trình huấn luyện: | Vấn đề | Triệu chứng | Cách chữa | |---|---|---| | Vanishing gradient | gradient tiến về 0 — mạng ngừng học | ReLU, batch norm, kết nối tắt (residual) | | Exploding gradient | loss thành NaN | gradient clipping | | Overfitting | train tốt, validation kém | dropout, regularization, early stopping |

Đáp án

C — Thiết lập Amazon FSx for Lustre liên kết với S3 bucket hiện có, và cập nhật cấu hình training job để đọc dữ liệu trực tiếp từ hệ thống tệp đó.

Vì sao đúng

Đề nêu đặc điểm dữ liệu rất cụ thể: hàng triệu tệp, mỗi tệp vài megabyte — và đó là kịch bản mà S3 hoạt động kém nhất.

Vì sao S3 chậm với hàng triệu tệp nhỏ:

Mỗi lời gọi GetObject có overhead cố định:
  thiết lập kết nối + xác thực + HTTP
  ≈ vài chục mili giây

Với tệp vài MB, overhead đó chiếm phần đáng kể thời gian
Với hàng triệu tệp, tổng overhead trở thành nút thắt chính

FSx for Lustre loại bỏ overhead đó:

FSx liên kết với S3 bucket
    ↓ tải trước dữ liệu vào hệ thống tệp SONG SONG
Training instance mount FSx như một thư mục cục bộ
    ↓ đọc bằng POSIX, độ trễ dưới mili giây

Ba đặc điểm khiến nó phù hợp: | Đặc điểm | Chi tiết | |---|---| | Hệ thống tệp song song hiệu năng cao | thiết kế cho HPC — hàng trăm GB/s | | Liên kết trực tiếp với S3 | không phải sao chép thủ công | | Đọc lặp rất nhanh | nhiều epoch trên cùng dữ liệu |

Và vế "minimal time" trong đề được đáp ứng: liên kết FSx với bucket có sẵn là một thao tác cấu hình, không phải tổ chức lại dữ liệu.

estimator.fit({'training': FileSystemInput(
    file_system_id='fs-0123456789abcdef',
    file_system_type='FSxLustre',
    directory_path='/du-lieu-huan-luyen',
    file_system_access_mode='ro')})

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

• B. Thiết lập Amazon EFS và liên kết với S3 bucket hiện có — đây là phương án gần nhất và EFS cũng là hệ thống tệp mount được, nhưng nó chậm hơn FSx for Lustre đáng kể cho khối lượng công việc huấn luyện, và đắt hơn ở quy mô terabyte. EFS thiết kế cho tệp dùng chung nói chung, không cho thông lượng cao trong HPC. (Và EFS không có tính năng liên kết tự động với S3 như FSx.)
• A. Bật S3 Transfer Acceleration — giải quyết sai vấn đề: Transfer Acceleration tăng tốc truyền dữ liệu qua khoảng cách địa lý xa bằng cách đi qua edge location. Nút thắt ở đây là số lượng lời gọi, không phải khoảng cách — và training instance thường ở cùng Region với bucket.
• D. Thiết lập S3 Access Point — Access Point là cơ chế quản lý TRUY CẬP, không phải tối ưu hiệu năng: nó cho phép tạo nhiều điểm vào với chính sách khác nhau cho cùng một bucket. Nó không thay đổi tốc độ đọc.

Ghi nhớ

Bốn cách đưa dữ liệu vào SageMaker training job: | Cách | Đặc điểm | Hợp với | |---|---|---| | File mode | tải hết xuống đĩa trước | dataset nhỏ | | Pipe mode | stream tuần tự từ S3 | dataset lớn, ít tệp | | FastFile mode | POSIX, tải lazy từ S3 | dataset lớn, ít tệp | | FSx for Lustre | hệ thống tệp hiệu năng cao | RẤT NHIỀU tệp nhỏ, đọc lặp |

Bảng chọn theo đặc tính dữ liệu — bảng quan trọng nhất của chủ đề này: | Đặc tính | Nút thắt | Chọn | |---|---|---| | Hàng triệu tệp NHỎ | độ trễ mỗi lời gọi | FSx for Lustre | | Ít tệp LỚN | băng thông | FastFile mode | | Đọc LẶP qua nhiều job | tải lại nhiều lần | FSx for Lustre | | Dataset nhỏ, một job | không có | File mode |

So sánh hai hệ thống tệp của AWS: | | FSx for Lustre | EFS | |---|---|---| | Thiết kế cho | HPC, ML — thông lượng rất cao | tệp dùng chung nói chung | | Liên kết S3 | ✅ tự động đồng bộ | ❌ | | Độ trễ | dưới mili giây | mili giây | | Chi phí ở quy mô lớn | hợp lý cho workload tạm | đắt hơn |

Hai chế độ triển khai FSx for Lustre: | Chế độ | Đặc điểm | |---|---| | SCRATCH_2 | tạm, rẻ, không sao lưu — hợp với training job | | PERSISTENT_1/2 | bền, có sao chép, đắt hơn |

SCRATCH thường là lựa chọn đúng cho huấn luyện: dữ liệu gốc vẫn ở S3, nên mất FSx không mất gì.

Và một cách khác đáng cân nhắc song song: gộp hàng triệu tệp nhỏ thành vài nghìn tệp lớn (RecordIO, TFRecord, WebDataset). Nó biến bài toán từ latency-bound thành throughput-bound, và khi đó cả FastFile mode cũng đủ nhanh — rẻ hơn FSx. Đánh đổi là phải xử lý dữ liệu một lần trước.

Đáp án

C — Giảm tham số temperature trong Bedrock API xuống giá trị THẤP và giảm top-K để giới hạn số token model được chọn, đảm bảo phản hồi nhất quán và có kiểm soát.

Vì sao đúng

Đề mô tả triệu chứng: chatbot trả lời hơi khác nhau cho cùng một câu hỏi về chính sách đổi trả — và với thông tin chính sách, sự nhất quán là bắt buộc.

Nguyên nhân nằm ở cách model chọn token:

Ở mỗi bước, model tính xác suất cho MỌI token có thể
    "Bạn có thể đổi trả trong vòng 30 ngày..."
                                    ↑
    Các lựa chọn: "ngày" (0,85), "hôm" (0,08), "buổi" (0,04), ...

Temperature CAO  → làm phẳng phân bố → dễ chọn token xác suất thấp → ĐA DẠNG
Temperature THẤP → làm nhọn phân bố → gần như luôn chọn token cao nhất → NHẤT QUÁN

Hai tham số trong đáp án tác động theo cùng một hướng: | Tham số | Giảm xuống thì | |---|---| | Temperature | phân bố nhọn hơn — gần như tất định | | Top-K | chỉ xét K token cao nhất — loại bỏ lựa chọn hiếm |

bedrock.converse(
    modelId=MODEL,
    messages=[...],
    inferenceConfig={'temperature': 0.0, 'topP': 0.1})

Với temperature = 0, model gần như luôn chọn token có xác suất cao nhất — cùng một câu hỏi cho gần như cùng một câu trả lời.

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

• A. TĂNG temperature và TĂNG top-K để giới hạn số token model được chọn, đảm bảo nhất quán — đây là phương án gần nhất và sai chiều cả hai tham số, đồng thời tự mâu thuẫn: tăng top-K là mở rộng số token được xét, không phải "giới hạn". Tăng cả hai làm đầu ra đa dạng hơn — ngược hẳn mục tiêu.
• B. Bật caching trong ứng dụng để tái dùng phản hồi đã sinh cho câu hỏi thường gặp — đây là phương án có ích trong thực tế (giảm chi phí và độ trễ), nhưng nó không giải quyết nguyên nhân: cache chỉ hoạt động khi câu hỏi khớp, và khách hàng diễn đạt theo nhiều cách khác nhau. Câu hỏi mới vẫn cho câu trả lời khác nhau. (Semantic cache khắc phục được phần nào, nhưng vẫn là vá triệu chứng.)
• D. Huấn luyện lại LLM với tập dữ liệu chuyên ngành bán lẻ để cải thiện tính nhất quán — tốn kém và không đảm bảo: fine-tuning cải thiện kiến thức và giọng điệu, nhưng tính ngẫu nhiên lúc lấy mẫu vẫn còn — model đã fine-tune với temperature cao vẫn cho câu trả lời khác nhau.

Ghi nhớ

Ba tham số lấy mẫu và tác động: | Tham số | Điều khiển | Giảm xuống thì | |---|---|---| | Temperature | độ "phẳng" của phân bố xác suất | tất định hơn | | Top-P (nucleus) | chỉ lấy token có tổng xác suất tích luỹ ≤ P | ít lựa chọn hơn | | Top-K | chỉ lấy K token xác suất cao nhất | ít lựa chọn hơn |

Khuyến nghị thực dụng: chỉnh temperature HOẶC top-P, không chỉnh cả hai — chúng tương tác theo cách khó dự đoán.

Bảng chọn giá trị theo tác vụ: | Tác vụ | Temperature | |---|---| | Trích xuất dữ liệu, phân loại, sinh JSON | 0 – 0,2 | | Trả lời câu hỏi về chính sách, tài liệu | 0 – 0,3 ← câu này | | Tóm tắt | 0,3 – 0,5 | | Viết nội dung marketing | 0,7 – 0,9 | | Động não ý tưởng | 0,9 – 1,0+ |

Ba cách khác tăng tính nhất quán cho chatbot chính sách: | Cách | Chi tiết | |---|---| | RAG với tài liệu chính sách | câu trả lời dựa trên nguồn cố định, không dựa vào trí nhớ model | | Prompt có cấu trúc chặt | khai rõ định dạng và phạm vi trả lời | | Semantic cache | tái dùng câu trả lời cho câu hỏi tương tự về nghĩa |

Cách đầu quan trọng nhất về mặt chất lượng: với chính sách đổi trả, câu trả lời phải khớp với tài liệu chính thức — và RAG đảm bảo điều đó tốt hơn nhiều so với chỉ hạ temperature. Kết hợp cả hai là mẫu chuẩn:

RAG (đảm bảo NỘI DUNG đúng) + temperature thấp (đảm bảo DIỄN ĐẠT nhất quán)

Và một lưu ý về temperature = 0: nó không đảm bảo tất định tuyệt đối — vẫn có sai khác nhỏ do tính toán dấu phẩy động và cách xử lý song song ở phía dịch vụ. Nó chỉ giảm biến động xuống mức rất thấp, không loại bỏ hoàn toàn.

Đáp án

C — Amazon SageMaker Model Monitor.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai đều là chức năng cốt lõi của Model Monitor: | Yêu cầu | Model Monitor | |---|---| | Theo dõi độ chính xác dự đoán | model quality monitoring | | Theo dõi model drift | data quality + bias + feature attribution drift |

Model Monitor là dịch vụ duy nhất trong bốn phương án giám sát CHẤT LƯỢNG MODEL — ba cái còn lại giám sát hoặc làm những việc khác.

Bốn loại giám sát nó cung cấp: | Loại | Phát hiện | Cần nhãn thật? | |---|---|---| | Data quality | phân bố đầu vào lệch khỏi baseline | ❌ | | Model quality | độ chính xác, precision, recall giảm | ✅ | | Bias drift | chênh lệch giữa các nhóm tăng | ❌ | | Feature attribution drift | đặc trưng chi phối dự đoán thay đổi | ❌ |

DefaultModelMonitor(role=role, instance_count=1, instance_type='ml.m5.xlarge')    .create_monitoring_schedule(
        endpoint_input=endpoint_name,
        statistics=baseline.baseline_statistics(),
        constraints=baseline.suggested_constraints(),
        schedule_cron_expression=CronExpressionGenerator.hourly())

Hai điều kiện bắt buộc trước khi nó hoạt động: | Điều kiện | Hậu quả nếu thiếu | |---|---| | Data capture bật trên endpoint | job chạy nhưng báo cáo TRỐNG | | Baseline đã tính | không có gì để so sánh |

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

• A. Amazon CloudWatch — đây là phương án gần nhất và CloudWatch giám sát endpoint thật, nhưng nó đo chỉ số HẠ TẦNG và VẬN HÀNH: số lời gọi, độ trễ, tỷ lệ lỗi, CPU. Nó không biết gì về độ chính xác của dự đoán hay việc phân bố dữ liệu có thay đổi hay không. (Model Monitor thực ra đẩy kết quả lên CloudWatch — nên hai dịch vụ bổ sung nhau, nhưng cái phát hiện drift là Model Monitor.)
• B. Amazon SageMaker Autopilot — công cụ AutoML: nó 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 giám sát model đang chạy.
• D. AWS Glue — dịch vụ ETL: chuẩn bị và biến đổi dữ liệu. Không liên quan tới giám sát model.

Ghi nhớ

Bốn công cụ giám sát trong hệ thống ML — mỗi cái một tầng: | Công cụ | Giám sát | |---|---| | CloudWatch | hạ tầng: độ trễ, số lời gọi, lỗi, CPU | | Model Monitor | dữ liệu và chất lượng model: drift, độ chính xác | | Clarify | thiên lệch và khả năng giải thích | | CloudTrail | ai đã gọi API nào — kiểm toán |

Cần cả bốn trong một hệ thống production, và mỗi cái bắt một loại vấn đề khác nhau:

Endpoint chết          → CloudWatch
Dữ liệu đầu vào hỏng   → Model Monitor (data quality)
Model dự đoán kém đi   → Model Monitor (model quality)
Model thiên lệch       → Clarify
Ai đó đổi endpoint     → CloudTrail

Một khó khăn thực tế của model quality monitoring:

Nó cần nhãn thật (ground truth), mà nhãn thường đến rất muộn.

Ví dụ: dự đoán tái nhập viện phải chờ 30 ngày mới biết đúng sai. Nên trong thực tế: | Chỉ số | Độ trễ | Vai trò | |---|---|---| | Data quality drift | tức thì | chỉ báo sớm | | Prediction drift | tức thì | chỉ báo sớm | | Model quality | ngày tới tháng | xác nhận |

Prediction drift (phân bố đầu ra thay đổi) là chỉ báo hữu ích nhất mà không cần nhãn: nếu tỷ lệ dự đoán "dương tính" đột nhiên thay đổi mà không có lý do nghiệp vụ, đó là dấu hiệu sớm.

Ba tệp Model Monitor sinh ra: | Tệp | Nội dung | |---|---| | statistics.json | thống kê baseline của từng cột | | constraints.json | ràng buộc suy ra: kiểu, độ đầy đủ, khoảng giá trị | | constraint_violations.json | vi phạm ở lần chạy hiện tại — đọc file này trước khi chẩn đoán |

Và một thực hành nên có: sinh baseline như một bước trong pipeline huấn luyện, ngay sau bước huấn luyện — để baseline luôn khớp với model, thay vì dựa vào việc ai đó nhớ chạy lại nó.

Đáp án

B — Tạo SageMaker Asynchronous Inference endpoint kèm scaling policy; mỗi khi có ảnh được tải lên, kích hoạt Lambda gửi yêu cầu suy luận.

Vì sao đúng

Đề nêu bốn yếu tố, và Asynchronous Inference khớp cả bốn: | Yếu tố | Asynchronous Inference | |---|---| | Ảnh tới 40 MB | hỗ trợ payload lớn (tới 1 GB) | | Hiệu quả về chi phí | co giãn về 0 khi hàng đợi rỗng | | Thích ứng với biến động nhu cầu | hàng đợi nội bộ làm đệm | | Ít công sức vận hành | dịch vụ được quản lý |

Payload 40 MB là yếu tố quyết định, và nó loại ngay hai phương án: | Kiểu triển khai | Giới hạn payload | |---|---| | Real-time endpoint | 6 MB | | Serverless Inference | 4 MB | | Asynchronous Inference | 1 GB ✅ | | Batch transform | 100 MB mỗi bản ghi |

Và cơ chế hàng đợi giải quyết vế biến động nhu cầu:

Ảnh tải lên → S3 event → Lambda gọi InvokeEndpointAsync
                              ↓ (trả về ngay, kèm vị trí output)
                        Hàng đợi nội bộ của SageMaker  ← đệm khi có đỉnh tải
                              ↓
                        Endpoint xử lý theo năng lực
                              ↓
                        Kết quả ghi ra S3 + thông báo SNS

MinCapacity = 0 là điểm tiết kiệm chính: khi không có ảnh nào, endpoint co về 0 và không tốn tiền — trong khi endpoint real-time chạy 24/7.

AsyncInferenceConfig={
    'OutputConfig': {'S3OutputPath': 's3://kho/ket-qua/',
                     'NotificationConfig': {'SuccessTopic': arn_sns}},
    'ClientConfig': {'MaxConcurrentInvocationsPerInstance': 4}}

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

• A. Dùng Batch Transform xử lý ảnh trong S3 theo lô — đây là phương án gần nhất và hoàn toàn hợp lý nếu ảnh được xử lý theo lô định kỳ. Nó thua ở chỗ đề nói ảnh do khách hàng tải lên — tức là đến rải rác và cần xử lý khi tới, không phải gom lại chạy một lần. (Batch transform không có cơ chế phản ứng với từng lần tải lên.)
• C. Tạo Real-Time Inference endpoint, kích hoạt Lambda mỗi khi có ảnh — vượt giới hạn payload 6 MB với ảnh 40 MB. Và endpoint real-time chạy 24/7, trái yêu cầu hiệu quả chi phí cho một workload có biến động.
• D. Tạo Serverless Inference endpoint kèm scaling policy, chạy script gửi yêu cầu cho từng ảnh — vượt giới hạn payload 4 MB, và Serverless Inference không có scaling policy theo nghĩa đó (nó tự co giãn, bạn chỉ khai MaxConcurrency).

Ghi nhớ

Bốn kiểu suy luận của SageMaker — bảng giới hạn payload nên thuộc: | Kiểu | Payload tối đa | Timeout | Co về 0 | |---|---|---|---| | Real-time | 6 MB | 60 giây | ❌ | | Serverless | 4 MB | 60 giây | ✅ | | Asynchronous | 1 GB | 60 phút | ✅ | | Batch transform | 100 MB/bản ghi | theo job | ✅ |

Payload lớn là dấu hiệu nhận biết rõ ràng nhất trong đề thi: thấy ảnh vài chục MB, video, hoặc tài liệu lớn → Asynchronous hoặc Batch transform.

Cách chọn giữa hai kiểu cuối: | Tình huống | Chọn | |---|---| | Dữ liệu đến RẢI RÁC, cần xử lý khi tới | Asynchronous ← câu này | | Có sẵn cả tệp, xử lý một lần | Batch transform | | Cần thông báo khi xong từng item | Asynchronous (SNS) |

Ba tham số cần đặt cho async endpoint: | Tham số | Việc | |---|---| | MaxConcurrentInvocationsPerInstance | số request song song mỗi instance | | MinCapacity: 0 | cho phép co về 0 — điểm tiết kiệm chính | | ApproximateBacklogSizePerInstance | metric auto scaling — theo ĐỘ SÂU HÀNG ĐỢI |

Dòng cuối đáng nhớ: co giãn theo độ sâu hàng đợi chính xác hơn nhiều so với theo CPU — nó phản ánh trực tiếp lượng việc còn tồn.

Và một chi tiết về việc kích hoạt: thay vì S3 event → Lambda → InvokeEndpointAsync, có thể dùng S3 event → EventBridge → Lambda để lọc linh hoạt hơn theo prefix và suffix, và thêm consumer sau này mà không đụng cấu hình bucket.