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

Đáp án

A và E.

• A — Ghi metric từ Lambda function lên CloudWatch
• E — Đặt CloudWatch alarm gửi email thông báo

Vì sao đúng

Đề mô tả một luồng ba bước, và hai đáp án là hai bước cần thiết:

① Lambda tính điểm tin cậy của model
    ↓ A: put_metric_data → CloudWatch custom metric
② CloudWatch alarm so với ngưỡng 80%
    ↓ E: alarm vượt ngưỡng → SNS → email
③ Đội nhận thông báo

A — ghi custom metric:

cloudwatch.put_metric_data(
    Namespace='PhatHienGianLan/ChatLuong',
    MetricData=[{
        'MetricName': 'DiemTinCay',
        'Value': diem_tin_cay,
        'Unit': 'Percent',
        'Dimensions': [{'Name': 'ModelVersion', 'Value': 'v3'}]}])

E — alarm gửi email:

cloudwatch.put_metric_alarm(
    AlarmName='canh-bao-tin-cay-thap',
    MetricName='DiemTinCay', Namespace='PhatHienGianLan/ChatLuong',
    Statistic='Average', Period=300, Threshold=80,
    ComparisonOperator='LessThanThreshold',
    EvaluationPeriods=2,
    AlarmActions=[arn_sns_topic])       # SNS topic có email subscription

Vì sao cần custom metric: điểm tin cậy của model không phải metric có sẵn — SageMaker không biết ngưỡng nghiệp vụ của bạn. Bạn phải tự tính và tự đẩy lên.

Và EvaluationPeriods=2 tránh báo động giả do một dự đoán đơn lẻ có điểm thấp.

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

• **D. Ghi metric từ Lambda lên AWS CloudTrail — đây là phương án gần nhất về mặt "một dịch vụ log của AWS", nhưng CloudTrail ghi lời gọi API, không nhận metric tuỳ chỉnh: bạn không "ghi metric vào CloudTrail" được. Nó là nhật ký kiểm toán, không phải kho metric.
• **B. Ghi metric từ Lambda lên AWS CloudFormation — CloudFormation là dịch vụ hạ tầng là mã: nó tạo và quản lý tài nguyên. Nó không lưu metric.
• C. Đặt CloudFormation change set để gửi email — change set là bản xem trước thay đổi hạ tầng trước khi áp dụng. Nó không gửi thông báo cho ai.

Ghi nhớ

Bốn dịch vụ AWS hay bị lẫn — nhớ đúng vai: | Dịch vụ | Việc | |---|---| | CloudWatch | METRIC, LOG, ALARM | | CloudTrail | ghi lời gọi API — kiểm toán | | CloudFormation | hạ tầng là mã | | CloudFront | CDN |

Bốn tên bắt đầu bằng "Cloud" nhưng làm bốn việc hoàn toàn khác nhau — đây là nhóm bẫy phổ biến trong đề thi.

Ba bước để có cảnh báo dựa trên chỉ số tuỳ chỉnh: | Bước | Cơ chế | |---|---| | ① Tính chỉ số | Lambda hoặc ứng dụng | | ② Đẩy lên CloudWatch | put_metric_data | | ③ Alarm + SNS | ngưỡng → thông báo |

Ba tham số quan trọng của put_metric_data: | Tham số | Việc | |---|---| | Namespace | nhóm metric — nên đặt theo ứng dụng | | Dimensions | tách theo chiều: model version, môi trường, loại giao dịch | | Unit | Percent, Count, Milliseconds... |

Dimensions quan trọng nhất về mặt phân tích: không có nó, mọi model và mọi môi trường trộn vào một con số — và bạn không tách ra được sau này.

Ba thống kê của alarm và khi nào dùng: | Thống kê | Dùng cho | |---|---| | Average | xu hướng chung của điểm tin cậy | | Minimum | bắt trường hợp tệ nhất | | Sum | đếm số lần vi phạm |

Với điểm tin cậy, cân nhắc dùng Minimum hoặc một percentile thấp thay vì Average: trung bình 90% nghe tốt, nhưng nếu 5% dự đoán có tin cậy dưới 50% thì đó là những giao dịch đáng lo nhất.

Và ba mẹo giảm báo động giả: | Mẹo | Chi tiết | |---|---| | EvaluationPeriods > 1 | phải vi phạm nhiều chu kỳ liên tiếp | | DatapointsToAlarm | ví dụ 3 trong 5 chu kỳ | | TreatMissingData | quyết định hành vi khi không có dữ liệu |

Đáp án

B — Dùng SageMaker Script Mode để đưa các script PyTorch hiện có và tập dữ liệu độc quyền vào SageMaker cho huấn luyện và suy luận mà không cần sửa đổi đáng kể.

Vì sao đúng

Đề nêu hai ràng buộc, và Script Mode là lựa chọn duy nhất thoả cả hai: | Ràng buộc | Script Mode | |---|---| | Công sức di trú ít nhất | dùng container PyTorch dựng sẵn | | Thay đổi tối thiểu với script PyTorch hiện có | script chạy gần như nguyên vẹn |

Script Mode là mức tuỳ biến ở giữa: bạn viết mã, AWS lo container:

from sagemaker.pytorch import PyTorch

estimator = PyTorch(
    entry_point='train.py',           # ← script HIỆN CÓ của bạn
    source_dir='./ma-nguon',          # ← cả thư mục, gồm requirements.txt
    role=role,
    instance_type='ml.p3.2xlarge',
    framework_version='2.1',
    py_version='py310')

estimator.fit({'training': 's3://kho/du-lieu-y-te/'})

Ba thay đổi nhỏ cần làm trong script hiện có:

# ① Đọc đường dẫn dữ liệu từ biến môi trường
parser.add_argument('--train', default=os.environ['SM_CHANNEL_TRAINING'])

# ② Ghi model ra thư mục SageMaker quy định
parser.add_argument('--model-dir', default=os.environ['SM_MODEL_DIR'])

# ③ Nhận siêu tham số qua tham số dòng lệnh
parser.add_argument('--learning-rate', type=float, default=0.001)

Ba dòng — đó là toàn bộ "significant modifications" cần thiết.

Và requirements.txt trong source_dir được cài tự động — nên thư viện y tế chuyên ngành cũng dùng được mà không cần dựng container riêng.

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

• D. Dựng container PyTorch tuỳ chỉnh với script và dữ liệu hiện có, rồi triển khai lên SageMaker cho huấn luyện phân tán và suy luận — đây là phương án gần nhất và hoạt động được, nhưng nó tốn công hơn nhiều: phải viết Dockerfile, dựng image, đẩy lên ECR, và tự bảo trì (cập nhật phiên bản, vá bảo mật). (BYOC chỉ đáng làm khi framework hoặc phiên bản không được container dựng sẵn hỗ trợ — không phải trường hợp này.)
• C. Refactor script PyTorch để tích hợp với thuật toán DỰNG SẴN của SageMaker và tải dữ liệu lên S3 — vi phạm thẳng ràng buộc "minimal changes": dùng thuật toán dựng sẵn nghĩa là vứt bỏ model tuỳ chỉnh mà đề nói cần kiến thức chuyên ngành để xây.
• **A. Di trú dữ liệu sang S3 và dùng EMR tiền xử lý rồi triển khai model PyTorch lên EC2 instance — bỏ hoàn toàn dịch vụ được quản lý: bạn tự quản lý EC2, tự lo auto scaling, tự dựng máy chủ suy luận. Trái mục tiêu "leverage scalable and managed infrastructure".

Ghi nhớ

Bốn mức tuỳ biến trên SageMaker, theo công sức tăng dần: | Mức | Cách làm | Dùng khi | |---|---|---| | Thuật toán dựng sẵn | chỉ cấu hình siêu tham số | XGBoost, Linear Learner | | Script Mode | container AWS + script của bạn | framework chuẩn, mã riêng ← câu này | | Mở rộng container AWS | FROM image AWS rồi cài thêm | cần thư viện hệ thống đặc biệt | | BYOC | container hoàn toàn của bạn | framework không được hỗ trợ |

Nguyên tắc: leo thang từ trên xuống — mức càng thấp càng ít thứ phải bảo trì.

Ba biến môi trường quan trọng của Script Mode: | Biến | Trỏ tới | |---|---| | SM_CHANNEL_<TÊN> | thư mục dữ liệu của channel đó | | SM_MODEL_DIR | /opt/ml/model — SageMaker tự đóng gói lên S3 | | SM_OUTPUT_DATA_DIR | artifact phụ (biểu đồ, báo cáo) |

Cấu trúc thư mục trong container:

/opt/ml/
  ├── input/data/training/   ← dữ liệu từ S3
  ├── model/                 ← ghi model ra đây
  ├── output/                ← artifact phụ
  └── code/                  ← script của bạn

Ba framework có container dựng sẵn: | Framework | Class Estimator | |---|---| | PyTorch | sagemaker.pytorch.PyTorch | | TensorFlow | sagemaker.tensorflow.TensorFlow | | Hugging Face | sagemaker.huggingface.HuggingFace | | Scikit-learn, XGBoost | SKLearn, XGBoost |

Và ba lưu ý riêng cho dữ liệu y tế trong đề: | Lưu ý | Chi tiết | |---|---| | Training job trong VPC riêng | khai subnets và security_group_ids | | Mã hoá volume và inter-container traffic | volume_kms_key, encrypt_inter_container_traffic=True | | Không ghi dữ liệu bệnh nhân vào log | log CloudWatch được giữ lâu |

Cả ba đều là cấu hình đơn giản trên Estimator — và cần thiết cho dữ liệu chịu quản lý.

Đáp án

D — Dùng Amazon Kendra index các bài báo lưu trữ trong S3 bucket và bật tìm kiếm ngữ nghĩa với truy vấn ngôn ngữ tự nhiên.

Vì sao đúng

Đề nêu ba yêu cầu, và Kendra khớp cả ba: | Yêu cầu | Kendra | |---|---| | Tìm kiếm ngữ nghĩa | hiểu ý nghĩa, không chỉ khớp từ khoá | | Truy vấn ngôn ngữ tự nhiên | thiết kế riêng cho việc này | | Hiệu quả nhất | dịch vụ được quản lý — index S3 bằng connector dựng sẵn |

Kendra là dịch vụ tìm kiếm doanh nghiệp có sẵn hiểu biết ngữ nghĩa:

Truy vấn: "bài báo nào nói về tác động của lãi suất tới thị trường nhà đất?"

Tìm kiếm từ khoá:  chỉ khớp bài có đúng các từ đó
Kendra:            hiểu Ý ĐỊNH, trả về cả bài viết
                   "chính sách tiền tệ ảnh hưởng bất động sản"

Ba lợi ích so với tự dựng: | Lợi ích | Chi tiết | |---|---| | Connector S3 dựng sẵn | trỏ vào bucket, Kendra tự index | | Không quản lý vector store | không cần chọn embedding model, không cần OpenSearch | | Có sẵn tính năng doanh nghiệp | kiểm soát truy cập theo người dùng, đồng nghĩa, tăng độ liên quan |

Và Kendra trả về ba loại kết quả, hữu ích cho nhà báo: | Loại | Nội dung | |---|---| | Answer | trích đoạn trả lời trực tiếp câu hỏi | | Document | tài liệu liên quan | | FAQ | câu hỏi thường gặp đã khai |

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

• B. Triển khai SageMaker endpoint với model ngôn ngữ đã fine-tune xử lý truy vấn và tự tích hợp với S3 để lấy bài báo — đây là phương án gần nhất về mặt năng lực (nó thật sự dựng được tìm kiếm ngữ nghĩa), nhưng nó tốn công nhất: fine-tune model, quản lý endpoint, tự dựng vector store, tự viết logic truy xuất. Trái tiêu chí "most efficiently".
• A. Dùng Comprehend trích xuất cụm từ khoá và thực thể rồi xây công cụ tìm kiếm tuỳ chỉnh — Comprehend không tìm kiếm: nó phân tích văn bản. Và "build a custom search engine" là tự dựng lại thứ Kendra làm sẵn.
• C. Dùng Glue tiền xử lý và tạo metadata catalog, rồi Athena thực hiện truy vấn NGỮ NGHĨA trên catalog — Athena chạy SQL, không có tìm kiếm ngữ nghĩa: nó khớp chuỗi và điều kiện, không hiểu ý nghĩa. Không có cách nào diễn đạt "bài nào nói về chủ đề tương tự" bằng SQL.

Ghi nhớ

Ba cách dựng tìm kiếm ngữ nghĩa trên AWS — theo công sức tăng dần: | Cách | Công sức | Kiểm soát | |---|---|---| | Amazon Kendra | thấp nhất — dịch vụ được quản lý | thấp | | Bedrock Knowledge Bases | thấp — RAG được quản lý | vừa | | OpenSearch + embedding tự chọn | cao — tự dựng mọi thứ | cao nhất |

Phân biệt Kendra với Bedrock Knowledge Bases — hai dịch vụ hay bị so sánh: | | Kendra | Knowledge Bases | |---|---|---| | Mục đích | TÌM KIẾM và trả về tài liệu | RAG — sinh câu trả lời từ tài liệu | | Đầu ra | danh sách tài liệu + trích đoạn | câu trả lời tổng hợp + citation | | Kiểm soát truy cập | ✅ mạnh, theo người dùng | qua IAM | | Dùng khi | người dùng muốn ĐỌC tài liệu gốc | muốn CÂU TRẢ LỜI |

Với nhà báo tìm bài báo để đọc và trích dẫn, Kendra phù hợp hơn — họ cần tài liệu gốc, không phải bản tóm tắt do AI viết.

Các nguồn Kendra index được: | Nguồn | Ghi chú | |---|---| | Amazon S3 | connector dựng sẵn ← câu này | | SharePoint, Confluence | tài liệu nội bộ | | Salesforce, ServiceNow | hệ thống nghiệp vụ | | RDS, database qua JDBC | dữ liệu có cấu trúc | | Web crawler | trang web |

Ba tính năng của Kendra hữu ích cho toà soạn: | Tính năng | Chi tiết | |---|---| | Relevance tuning | tăng trọng số cho bài mới, hoặc theo chuyên mục | | Custom synonyms | khai từ đồng nghĩa của ngành | | Access control | nhà báo chỉ thấy bài họ có quyền |

Dòng đầu đáng dùng cho tin tức: bài mới thường liên quan hơn bài cũ cùng chủ đề, và Kendra cho phép boost theo trường ngày tháng.

Và một cân nhắc về chi phí: Kendra tính tiền theo edition và số tài liệu index — nó không rẻ với kho rất lớn. Với ngân sách hạn chế, Bedrock Knowledge Bases với OpenSearch Serverless thường rẻ hơn cho cùng quy mô, đổi lại ít tính năng doanh nghiệp hơn.

Đáp án

D — Dùng AWS Lake Formation định nghĩa quyền dựa trên Lake Formation tag (LF-Tags); gán tag theo danh mục nội dung cho dữ liệu và liên kết chúng với IAM role của các chuyên viên phân tích.

Vì sao đúng

Đề nêu ba yêu cầu, và LF-Tags đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Mỗi chuyên viên chỉ truy cập danh mục của mình | tag theo danh mục + cấp quyền theo tag | | Kiểm soát chi tiết (fine-grained) | Lake Formation: bảng, cột, dòng, ô | | Giảm độ phức tạp vận hành | một chính sách theo tag thay cho hàng chục policy riêng |

Vì sao tag-based access control (TBAC) giảm độ phức tạp:

Không dùng tag — cấp quyền từng bảng:
  10 chuyên viên × 20 bảng = tối đa 200 lần cấp quyền
  Thêm một bảng mới → phải cấp quyền lại cho mọi người liên quan

Dùng LF-Tags:
  Gắn tag:   danh_muc = "the-thao"  cho các bảng thể thao
  Cấp quyền: role PhanTichTheThao được đọc danh_muc = "the-thao"
  → Thêm bảng mới, chỉ cần GẮN TAG — quyền tự áp dụng

# ① Tạo tag
aws lakeformation create-lf-tag --tag-key danh_muc   --tag-values the-thao phim-anh phim-tai-lieu

# ② Gắn tag cho bảng
aws lakeformation add-lf-tags-to-resource   --resource '{"Table": {"DatabaseName":"data_lake","Name":"log_the_thao"}}'   --lf-tags '[{"TagKey":"danh_muc","TagValues":["the-thao"]}]'

# ③ Cấp quyền theo tag
aws lakeformation grant-permissions   --principal DataLakePrincipalIdentifier=arn:aws:iam::...:role/PhanTichTheThao   --resource '{"LFTagPolicy": {"ResourceType":"TABLE",
               "Expression":[{"TagKey":"danh_muc","TagValues":["the-thao"]}]}}'   --permissions SELECT

Và Athena tôn trọng quyền Lake Formation tự động — chuyên viên chạy SELECT * FROM ... và engine tự lọc, không cần ứng dụng nhớ thêm điều kiện.

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

• C. Dùng Glue workflow gắn tag cho dữ liệu và quản lý quyền bằng IAM policy condition dựa trên tag đó — đây là phương án gần nhất và về nguyên tắc là ABAC hợp lệ, nhưng nó hoạt động ở tầng IAM và S3 object tag, không ở tầng catalog. Hệ quả: nó không cho kiểm soát mức cột và dòng, và Athena phải đọc qua quyền S3 thay vì qua Lake Formation.
• B. Tạo bucket S3 riêng cho từng danh mục và cấp quyền ở mức bucket — cứng nhắc và không mở rộng được: thêm một danh mục là thêm một bucket, và không kiểm soát được ở mức cột (một bảng có thể chứa cả cột nhạy cảm lẫn không nhạy cảm).
• A. Dùng bucket policy hạn chế truy cập thư mục theo danh mục và Athena workgroup cho kiểm soát mức truy vấn — Athena workgroup kiểm soát chi phí và cấu hình truy vấn, không kiểm soát dữ liệu nào truy cập được. Và bucket policy làm việc ở mức object, không ở mức cột hay dòng.

Ghi nhớ

Bốn mức kiểm soát của Lake Formation: | Mức | Giới hạn | |---|---| | Table | thấy hay không thấy cả bảng | | Column | ẩn một số cột | | Row | chỉ thấy dòng thoả điều kiện | | Cell | giao của hai mức trên |

Hai mô hình cấp quyền của Lake Formation: | Mô hình | Cách làm | Mở rộng | |---|---|---| | Named resource | cấp quyền cho từng bảng cụ thể | kém khi nhiều bảng | | LF-Tag (TBAC) | gắn tag, cấp quyền theo tag | tốt — bảng mới tự thừa hưởng |

LF-Tags thắng rõ khi số lượng bảng lớn hoặc thay đổi thường xuyên — đúng tình huống của một data lake nội dung streaming.

Các engine tự động tôn trọng quyền Lake Formation: | Engine | Hỗ trợ | |---|---| | Amazon Athena | ✅ | | Redshift Spectrum | ✅ | | AWS Glue ETL | ✅ | | Amazon EMR | ✅ (với runtime role) | | Amazon QuickSight | ✅ |

Ba bước bắt buộc khi triển khai Lake Formation: | Bước | Chi tiết | |---|---| | Chuyển sang mô hình quyền Lake Formation | tắt IAM-only access cho catalog | | Đăng ký vị trí S3 với Lake Formation | để nó quản lý quyền truy cập | | Ứng dụng chạy bằng role được cấp quyền qua LF | không phải quyền S3 trực tiếp |

Bước đầu hay bị bỏ sót: nếu vẫn để chế độ IAM-only, quyền Lake Formation không có hiệu lực và mọi người vẫn truy cập được qua quyền S3.

Và một mẹo thiết kế tag: dùng nhiều chiều tag thay vì một:

danh_muc     = the-thao | phim-anh | phim-tai-lieu
do_nhay_cam  = cong-khai | noi-bo | han-che

Cách này cho phép diễn đạt "chuyên viên thể thao xem được dữ liệu thể thao ở mức nội bộ trở xuống" — một câu lệnh cấp quyền thay cho nhiều.

Đáp án

A — Feature engineering cho dữ liệu có cấu trúc thường gồm các việc như chuẩn hoá và xử lý giá trị thiếu, trong khi với dữ liệu phi cấu trúc thì gồm tokenization và vectorization.

Vì sao đúng

Khác biệt bắt nguồn từ điểm xuất phát của dữ liệu: | | Có cấu trúc | Phi cấu trúc | |---|---|---| | Dạng ban đầu | bảng: hàng và cột có kiểu rõ ràng | văn bản, ảnh, âm thanh, video | | Vấn đề chính | chất lượng và thang đo | chuyển thành SỐ | | Việc điển hình | chuẩn hoá, điền thiếu, mã hoá phân loại | tokenization, embedding, trích xuất đặc trưng |

Với dữ liệu có cấu trúc, dữ liệu đã là số hoặc gần số — công việc là làm cho nó phù hợp với thuật toán:

tuoi = 34, thu_nhap = 50.000.000, thanh_pho = "Hà Nội"
    ↓
Chuẩn hoá:      thang đo lệch nhau ⇒ đưa về cùng khoảng
Điền thiếu:     ô trống ⇒ trung bình, trung vị
Mã hoá:         "Hà Nội" ⇒ one-hot
Tạo đặc trưng:  ty_le_no_thu_nhap = tong_no / thu_nhap

Với dữ liệu phi cấu trúc, việc đầu tiên là BIẾN NÓ THÀNH SỐ:

Văn bản: "Sản phẩm này rất tốt"
    ↓ tokenization
["Sản", "phẩm", "này", "rất", "tốt"]
    ↓ vectorization (TF-IDF hoặc embedding)
[0.23, -0.81, 0.45, ...]

Ảnh: ma trận điểm ảnh
    ↓ trích xuất đặc trưng (CNN, hoặc thủ công: cạnh, kết cấu)
vector đặc trưng

Nhưng cả hai loại đều CẦN feature engineering — đó là điểm phân biệt với phương án D.

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

• D. Feature engineering cho dữ liệu có cấu trúc KHÔNG cần thiết vì dữ liệu đã ở dạng dùng được, còn phi cấu trúc thì LUÔN cần tiền xử lý rộng — đây là phương án gần nhất và nửa sau đúng nhưng nửa đầu sai: dữ liệu bảng vẫn cần chuẩn hoá, xử lý thiếu, mã hoá và tạo đặc trưng. Nói nó "đã ở dạng dùng được" là bỏ qua phần lớn công việc thực tế.
• B. Feature engineering cho có cấu trúc tập trung vào nhận diện ảnh, còn phi cấu trúc tập trung vào phân tích dữ liệu số — đảo ngược hoàn toàn: ảnh là dữ liệu phi cấu trúc, số là có cấu trúc.
• C. Các việc feature engineering cho hai loại hoàn toàn giống nhau — sai: tokenization không áp dụng cho bảng số, và chuẩn hoá thang đo không áp dụng cho văn bản thô.

Ghi nhớ

Bảng kỹ thuật feature engineering theo loại dữ liệu: | Loại dữ liệu | Kỹ thuật điển hình | |---|---| | Số (có cấu trúc) | chuẩn hoá, log transform, binning, tạo tỷ số | | Phân loại (có cấu trúc) | one-hot, ordinal, target encoding | | Văn bản | tokenization, TF-IDF, word/sentence embedding | | Ảnh | resize, augmentation, trích xuất bằng CNN | | Âm thanh | spectrogram, MFCC | | Chuỗi thời gian | đặc trưng trễ (lag), cửa sổ trượt, phân rã mùa vụ |

Ba việc chung cho MỌI loại dữ liệu: | Việc | Chi tiết | |---|---| | Xử lý giá trị thiếu | có ở cả bảng lẫn văn bản (tài liệu rỗng) | | Xử lý ngoại lai | ảnh hỏng cũng là ngoại lai | | Chia tập đúng cách | phân tầng, theo thời gian, theo nhóm |

Ba công cụ AWS theo loại dữ liệu: | Loại | Công cụ | |---|---| | Bảng | Data Wrangler, Glue DataBrew | | Văn bản | Comprehend, BlazingText, Bedrock embedding | | Ảnh | Rekognition, Data Wrangler (transform ảnh) |

Và một xu hướng đáng biết: với dữ liệu phi cấu trúc, deep learning ngày càng thay thế feature engineering thủ công — CNN tự học đặc trưng ảnh, transformer tự học biểu diễn văn bản. Nhưng với dữ liệu bảng, feature engineering thủ công vẫn quan trọng bậc nhất — và đó là lý do XGBoost cộng đặc trưng tốt vẫn thường thắng deep learning trên loại dữ liệu này.

Đáp án

D — Triển khai model bằng SageMaker real-time inference với auto-scaling endpoint để xử lý đỉnh tải và đảm bảo tính sẵn sàng cao.

Vì sao đúng

Đề liệt kê năm yêu cầu, và real-time endpoint với auto-scaling đáp ứng cả năm: | Yêu cầu | Cơ chế | |---|---| | Tính sẵn sàng cao, không gián đoạn | endpoint thường trực, nhiều instance, nhiều AZ | | Độ trễ thấp cho dự đoán thời gian thực | model nạp sẵn trong bộ nhớ | | Payload 1 KB – 5 MB | vừa giới hạn 6 MB của real-time | | Đỉnh tải khó đoán trong giờ cao điểm | auto-scaling phản ứng theo tải thật | | Co giãn động suốt ngày | target tracking policy |

Ba yêu cầu đầu cùng nhau loại các phương án khác:

Payload tới 5 MB      → loại Serverless (trần 4 MB)
Độ trễ thấp           → loại Batch transform và Asynchronous
Không gián đoạn       → cần endpoint thường trực với MinCapacity ≥ 2

autoscaling.put_scaling_policy(
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 1000.0,
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance'},
        'ScaleOutCooldown': 60,      # lên nhanh khi có đỉnh
        'ScaleInCooldown': 300})     # xuống chậm, tránh dao động

Và MinCapacity ≥ 2 là điều kiện cho vế "high availability": nếu một AZ gặp sự cố, instance ở AZ còn lại vẫn phục vụ.

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

• C. Dùng Serverless Inference tự co giãn theo nhu cầu, loại bỏ việc quản lý endpoint — đây là phương án gần nhất và hấp dẫn về mặt vận hành, nhưng nó vướng hai giới hạn cứng: payload tối đa 4 MB trong khi đề nói tới 5 MB, và cold start mâu thuẫn với yêu cầu "provide predictions without interruptions" cùng độ trễ thấp cho dự báo giao thông thời gian thực.
• B. Dùng Asynchronous inference để xử lý đỉnh tải và đáp ứng yêu cầu độ trễ thấp nghiêm ngặt — tự mâu thuẫn: async xếp hàng và trả kết quả qua S3, độ trễ tính bằng giây tới phút. Nó xử lý đỉnh tải tốt nhưng không thể đáp ứng "strict low-latency".
• A. Dùng Batch transform xử lý dự đoán theo lô trong giờ cao điểm — không phải suy luận thời gian thực: batch transform chạy theo job trên tệp có sẵn, không phục vụ request đến bất kỳ lúc nào.

Ghi nhớ

Bốn kiểu suy luận và giới hạn — bảng quyết định: | Kiểu | Payload | Độ trễ | Co về 0 | |---|---|---|---| | Real-time | 6 MB | mili giây | ❌ | | Serverless | 4 MB | có cold start | ✅ | | Asynchronous | 1 GB | giây tới phút | ✅ | | Batch transform | 100 MB/bản ghi | theo job | ✅ |

Payload là tiêu chí lọc nhanh nhất trong đề thi: 5 MB loại ngay Serverless, còn trên 6 MB thì loại luôn cả Real-time.

Ba yếu tố của tính sẵn sàng cao cho endpoint: | Yếu tố | Cấu hình | |---|---| | Nhiều instance | MinCapacity ≥ 2 | | Nhiều AZ | SageMaker tự phân bổ khi có ≥ 2 instance | | Auto-scaling | thêm năng lực khi tải tăng |

Bốn loại chính sách auto-scaling: | Loại | Dùng khi | |---|---| | Target tracking | mặc định — đơn giản và hiệu quả nhất | | Step scaling | cần kiểm soát chi tiết mức điều chỉnh | | Scheduled | đỉnh tải BIẾT TRƯỚC — dùng kèm target tracking | | Manual | môi trường dev |

Với "unpredictable surges" như đề mô tả, target tracking là lựa chọn đúng — scheduled scaling chỉ xử lý được đỉnh tải dự đoán được.

Và một giới hạn cần biết: auto-scaling mất vài phút để instance mới sẵn sàng. Ba cách giảm ảnh hưởng: | Cách | Chi tiết | |---|---| | Đặt MinCapacity đủ cao | chịu được đỉnh tải nền mà không cần chờ | | ScaleOutCooldown ngắn | phản ứng nhanh hơn | | Kết hợp scheduled scaling | nâng sàn trước giờ cao điểm đã biết (giờ tan tầm) |

Với dự báo thời gian giao hàng, giờ cao điểm giao thông là khá dự đoán được — nên kết hợp cả hai là mẫu tốt nhất.

Đáp án

C — Bias–variance trade-off là bài toán cân bằng giữa sai số do ĐỘ PHỨC TẠP của model (variance) và sai số do GIẢ ĐỊNH SAI trong model (bias), trong đó bias cao gây UNDERFITTING và variance cao gây OVERFITTING.

Vì sao đúng

Đáp án này định nghĩa đúng cả hai thành phần và ghép đúng hệ quả của từng cái: | Thành phần | Nguyên nhân | Hệ quả | |---|---|---| | Bias cao | model quá đơn giản, giả định sai | UNDERFITTING | | Variance cao | model quá phức tạp, nhạy với dữ liệu huấn luyện | OVERFITTING |

Trực giác về hai loại sai số:

BIAS cao (underfitting):
  Model tuyến tính cố khớp quan hệ cong
  → sai ổn định ở mọi tập dữ liệu
  → train loss CAO, validation loss CAO

VARIANCE cao (overfitting):
  Model rất phức tạp học thuộc cả nhiễu
  → kết quả biến động mạnh khi đổi tập huấn luyện
  → train loss THẤP, validation loss CAO

Và "trade-off" nằm ở chỗ chúng đối nghịch nhau:

Độ phức tạp model tăng →  bias GIẢM,  variance TĂNG
Độ phức tạp model giảm →  bias TĂNG,  variance GIẢM

Tổng sai số
     │╲                    ╱
     │ ╲                  ╱
     │  ╲___         ___╱      ← điểm tối ưu
     │      ╲___╱
     │  bias↘     ↗variance
     └────────────────────── độ phức tạp model

Mục tiêu không phải triệt tiêu một trong hai, mà là tìm điểm tổng sai số nhỏ nhất.

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

• D. Trade-off là cân bằng giữa underfitting và overfitting, trong đó bias cao gây OVERFITTING và variance cao gây UNDERFITTING — đây là phương án gần nhất và ghép ngược hệ quả: bias cao gây underfitting, variance cao gây overfitting. Nửa đầu của phát biểu đúng, nửa sau đảo chiều.
• B. Trade-off là chọn giữa model phức tạp cao có thể học cả nhiễu (bias cao) và model đơn giản hơn có thể tổng quát tốt hơn nhưng bỏ sót mẫu quan trọng (variance cao) — gán nhãn ngược cho cả hai: model phức tạp học nhiễu là variance cao, model đơn giản bỏ sót mẫu là bias cao.
• A. Trade-off là kỹ thuật cải thiện hiệu năng bằng cách TĂNG CẢ bias LẪN variance cùng lúc — vô nghĩa: cả hai đều là sai số, mục tiêu là giảm chúng, không phải tăng.

Ghi nhớ

Phân rã sai số của model:

Tổng sai số = Bias² + Variance + Sai số không giảm được

Chẩn đoán qua đường cong loss: | Train loss | Validation loss | Chẩn đoán | Cách chữa | |---|---|---|---| | Cao | Cao | bias cao (underfitting) | model phức tạp hơn, thêm đặc trưng, huấn luyện lâu hơn | | Thấp | Cao | variance cao (overfitting) | regularization, dropout, thêm DỮ LIỆU, early stopping | | Thấp | Thấp | tốt | |

Điểm mấu chốt về cách chữa: hai vấn đề cần hai hướng ngược nhau — nên chẩn đoán sai dẫn tới làm tình hình tệ hơn.

Ba cách giảm variance mà không tăng bias: | Cách | Chi tiết | |---|---| | Thêm dữ liệu huấn luyện | cách tốt nhất — giảm variance mà không đụng bias | | Bagging / ensemble | trung bình nhiều model giảm phương sai | | Data augmentation | tăng dữ liệu một cách nhân tạo |

Dòng đầu là lý do "thêm dữ liệu" gần như luôn là câu trả lời tốt khi có overfitting — nó không phải đánh đổi gì cả.

Và một liên hệ với thực hành: model cây đơn lẻ có variance cao, nên random forest (bagging) và XGBoost (boosting) tồn tại để xử lý điều đó — random forest giảm variance, boosting giảm bias.

Đáp án

D — PCA cho giảm chiều, K-Means cho phân tích cụm, và Random Cut Forest (RCF) cho phát hiện bất thường.

Vì sao đúng

Đề nêu ba nhiệm vụ, và mỗi thuật toán khớp đúng một nhiệm vụ: | Nhiệm vụ | Thuật toán | Loại học | |---|---|---| | Giảm chiều để cải thiện hiệu năng và trực quan hoá | PCA | không giám sát | | Phân tích cụm nhận diện nhóm khách hàng | K-Means | không giám sát | | Phát hiện giao dịch bất thường | Random Cut Forest | không giám sát |

Cả ba đều là học không giám sát — phù hợp với đề, vốn không nhắc tới nhãn nào.

PCA — giảm chiều bằng cách tìm hướng biến thiên nhiều nhất:

Dữ liệu 50 chiều (số tiền, tần suất, vị trí, thời gian...)
    ↓ PCA giữ 95% phương sai
Dữ liệu 8 chiều
    → huấn luyện nhanh hơn, và vẽ được lên 2D để nhìn

K-Means — nhóm khách hàng có hành vi tương tự:

Chọn K = 5
    ↓ tìm 5 tâm cụm, gán mỗi khách về tâm gần nhất
5 phân khúc khách hàng cho chiến dịch marketing

RCF — phát hiện giao dịch lệch khỏi mẫu bình thường: | Đặc điểm | Vì sao phù hợp | |---|---| | Không cần nhãn "gian lận" | gian lận hiếm và khó gán nhãn đầy đủ | | Đa chiều | xét số tiền + tần suất + vị trí CÙNG LÚC | | Cho điểm bất thường liên tục | đặt ngưỡng cảnh báo theo mức chấp nhận |

Và PCA trước K-Means là thứ tự hợp lý: giảm chiều trước giúp phân cụm chính xác hơn — vì khoảng cách trong không gian nhiều chiều trở nên kém phân biệt (hiện tượng "lời nguyền chiều cao").

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

• C. PCA cho giảm chiều, K-Means cho phân cụm, và Neural Networks cho phát hiện bất thường — đây là phương án gần nhất và hai lựa chọn đầu đúng, nhưng "Neural Networks" không phải thuật toán DỰNG SẴN của SageMaker cho phát hiện bất thường. Đề nói rõ phải dùng built-in algorithms, và thuật toán dựng sẵn cho việc này là Random Cut Forest.
• A. XGBoost cho giảm chiều, K-Means cho phân cụm, RCF cho phát hiện bất thường — XGBoost không giảm chiều: nó là thuật toán phân loại và hồi quy có giám sát. Nó cho feature importance (giúp chọn lọc đặc trưng), nhưng đó là việc khác với giảm chiều.
• B. Linear Learner cho giảm chiều, DBSCAN cho phân cụm, RCF cho bất thường — hai lỗi: Linear Learner là thuật toán có giám sát, không giảm chiều; và DBSCAN KHÔNG phải thuật toán dựng sẵn của SageMaker.

Ghi nhớ

Thuật toán dựng sẵn của SageMaker — phân theo nhiệm vụ: | Nhiệm vụ | Thuật toán | |---|---| | Giảm chiều | PCA | | Phân cụm | K-Means | | Phát hiện bất thường | Random Cut Forest, IP Insights | | Phân loại / hồi quy (bảng) | XGBoost, Linear Learner | | Hệ gợi ý | Factorization Machines, Object2Vec | | Văn bản | BlazingText, LDA, Neural Topic Model | | Chuỗi thời gian | DeepAR |

Ba thuật toán trong đáp án đều thuộc nhóm không giám sát — và đó là dấu hiệu nhận biết: đề không nhắc tới nhãn nào cả.

Ba thuật toán giảm chiều và khác biệt: | Thuật toán | Đặc điểm | |---|---| | PCA | tuyến tính, nhanh, giữ phương sai lớn nhất | | t-SNE | phi tuyến, chỉ để trực quan hoá, không dùng làm tiền xử lý | | UMAP | phi tuyến, nhanh hơn t-SNE |

PCA là lựa chọn đúng khi cần cả giảm chiều LẪN trực quan hoá như đề nêu — t-SNE đẹp hơn để nhìn nhưng không dùng được làm bước tiền xử lý cho model.

Ba đánh đổi của PCA cần biết: | Đánh đổi | Chi tiết | |---|---| | Mất khả năng diễn giải | PC1 không có ý nghĩa nghiệp vụ nào | | Bắt buộc chuẩn hoá trước | PCA nhạy với thang đo | | Chỉ nắm quan hệ tuyến tính | quan hệ cong thì kém hiệu quả |

Dòng giữa quan trọng và hay bị bỏ sót: nếu không chuẩn hoá, cột "số tiền giao dịch" (hàng triệu) sẽ chi phối hoàn toàn thành phần chính đầu tiên, và PCA chỉ đang đo lại chính cột đó.

Và một lưu ý về K trong K-Means: chọn K bằng elbow method (vẽ tổng bình phương khoảng cách theo K, tìm chỗ gãy) hoặc silhouette score. Với phân khúc khách hàng, K cũng nên phù hợp với số chiến dịch marketing mà đội có thể vận hành — một ràng buộc nghiệp vụ quan trọng không kém tiêu chí thống kê.

Đáp án

A, B và D:

• A — Amazon SageMaker JumpStart
• B — Amazon SageMaker Canvas
• D — Amazon SageMaker Autopilot

Vì sao đúng

Đề yêu cầu giải pháp low-code/no-code (LCNC) để đơn giản hoá việc fine-tune, và ba dịch vụ này là nhóm LCNC của SageMaker: | Dịch vụ | Mức mã | |---|---| | JumpStart | vài dòng — model và script fine-tune dựng sẵn | | Canvas | không cần mã — hoàn toàn trực quan | | Autopilot | không cần mã — AutoML tự động |

JumpStart cho fine-tuning với rất ít mã:

from sagemaker.jumpstart.estimator import JumpStartEstimator
estimator = JumpStartEstimator(model_id='huggingface-llm-falcon-7b-bf16')
estimator.fit({'training': 's3://kho/ho-so-benh-an-an-danh/'})

Ba dòng — không script huấn luyện, không container tuỳ chỉnh.

Canvas cho giao diện hoàn toàn trực quan, bao gồm cả việc tuỳ biến foundation model — phù hợp với người dùng nghiệp vụ không viết mã.

Và ba dịch vụ này bổ sung nhau trong một luồng:

Canvas    → giao diện cho người không viết mã
JumpStart → kho model và script fine-tune
Autopilot → AutoML tự chọn cấu hình

Ghi chú về chất lượng câu hỏi

Cần nói rõ một điểm về phương án D. SageMaker Autopilot là công cụ AutoML cho DỮ LIỆU BẢNG — nó tự động chọn thuật toán, tạo đặc trưng và tinh chỉnh siêu tham số cho bài toán phân loại và hồi quy. Nó không phải công cụ fine-tune LLM.

Với việc tóm tắt tài liệu y tế bằng LLM, hai lựa chọn LCNC thật sự là: | Lựa chọn | Chi tiết | |---|---| | JumpStart | fine-tune LLM dựng sẵn | | Canvas | tuỳ biến foundation model qua giao diện |

Phương án E (Data Wrangler) cũng đáng bàn: nó là công cụ chuẩn bị dữ liệu ít mã, và fine-tuning cần dữ liệu đã chuẩn bị — nên nó có vai trò trong luồng, dù không trực tiếp fine-tune.

Nhìn theo cách người ra đề có lẽ muốn — "những dịch vụ SageMaker nào thuộc nhóm LCNC" — thì A, B, D là ba cái tên đúng. Nhưng nếu hiểu chặt là "dịch vụ nào fine-tune được LLM", thì Autopilot không thuộc nhóm đó.

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

• **E. SageMaker Data Wrangler — chuẩn bị dữ liệu, không fine-tune model. Nó là bước trước trong luồng, và như đã nêu, có thể lập luận nó thuộc nhóm LCNC — nhưng nó không thực hiện việc fine-tune.
• **C. SageMaker Clarify — phân tích thiên lệch và khả năng giải thích. Không liên quan tới fine-tuning.
• **F. SageMaker Model Monitor — giám sát model đã triển khai. Cũng không liên quan.

Ghi nhớ

Ba nhóm công cụ của SageMaker theo mức mã: | Nhóm | Công cụ | Đối tượng | |---|---|---| | Không cần mã | Canvas, Autopilot | người dùng nghiệp vụ | | Ít mã | JumpStart, Data Wrangler | nhà khoa học dữ liệu | | Viết mã đầy đủ | Studio notebook, Script Mode, BYOC | kỹ sư ML |

Bậc thang tuỳ biến LLM — chọn theo nhu cầu: | Mức | Kỹ thuật | Chi phí | |---|---|---| | 1 | Prompt engineering | rất thấp | | 2 | RAG | thấp | | 3 | Fine-tuning (LoRA) | vừa | | 4 | Full fine-tuning | cao |

Nguyên tắc: luôn thử mức 1 và 2 trước. Với tóm tắt tài liệu y tế, một prompt tốt cộng RAG trên hướng dẫn lâm sàng thường cho kết quả tốt mà không cần fine-tune — và tránh được rủi ro dữ liệu bệnh nhân đi vào trọng số model.

Ba cách fine-tune LLM trên AWS: | Cách | Đặc điểm | |---|---| | SageMaker JumpStart | script dựng sẵn, ít mã nhất | | Bedrock Custom Model | fine-tune foundation model, serverless | | SageMaker training job tự viết | kiểm soát hoàn toàn |

Và ba lưu ý riêng cho dữ liệu y tế: | Lưu ý | Chi tiết | |---|---| | Dữ liệu đã ẩn danh vẫn có rủi ro tái định danh | quasi-identifier: ngày sinh, mã bưu chính | | Fine-tuning ghi thông tin vào TRỌNG SỐ | không gỡ ra được — khác với RAG | | Chạy trong VPC riêng, mã hoá volume | yêu cầu tuân thủ |

Dòng giữa là lý do cân nhắc RAG trước fine-tuning với dữ liệu nhạy cảm: nếu một tài liệu phải gỡ bỏ vì lý do pháp lý, RAG gỡ được ngay; fine-tuning thì phải huấn luyện lại từ đầu.

Đáp án

A — Giảm tham số max_depth trong thuật toán XGBoost để ngăn model overfitting vào tập huấn luyện.

Vì sao đúng

Đề mô tả triệu chứng rõ ràng: model rất tốt trên tập huấn luyện nhưng phân loại sai bệnh nhân mới — đó là định nghĩa của overfitting.

Và max_depth là tham số kiểm soát overfitting quan trọng nhất của XGBoost:

max_depth = 12:  mỗi cây rất sâu
                 → chia dữ liệu thành rất nhiều nhánh nhỏ
                 → mỗi lá chỉ chứa vài mẫu
                 → model HỌC THUỘC nhiễu

max_depth = 4:   cây nông
                 → mỗi lá chứa nhiều mẫu
                 → chỉ học được mẫu tổng quát

Vì sao độ sâu liên quan trực tiếp tới nhiễu: một cây sâu có thể tạo ra nhánh riêng cho một bệnh nhân duy nhất — và nhánh đó chỉ mô tả nhiễu, không mô tả quy luật.

xgb.set_hyperparameters(
    max_depth=4,              # ← giảm từ mặc định 6
    min_child_weight=5,       # yêu cầu tối thiểu mẫu mỗi lá
    subsample=0.8,            # mỗi cây dùng 80% dữ liệu
    colsample_bytree=0.8,     # mỗi cây dùng 80% đặc trưng
    reg_lambda=1.0)           # L2 regularization

Năm tham số trên cùng kiểm soát overfitting, và max_depth thường có tác động lớn nhất.

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

• D. Loại bỏ đặc trưng không liên quan khỏi tập huấn luyện để giảm nhiễu và cải thiện tổng quát hoá — đây là phương án gần nhất và hữu ích trong thực tế, nhưng nó kém trực tiếp hơn: XGBoost vốn đã bỏ qua đặc trưng không hữu ích (nó chỉ chia theo đặc trưng làm giảm loss). Và "irrelevant features" đòi bạn xác định được cái nào không liên quan — trong khi giảm max_depth là một thay đổi tham số đơn giản và hiệu quả ngay.
• C. Tăng learning_rate để model hội tụ nhanh hơn và làm tốt hơn trên dữ liệu chưa thấy — không liên quan tới overfitting: learning rate ảnh hưởng tốc độ hội tụ, và tăng nó thường làm overfitting TỆ HƠN với boosting (mỗi cây đóng góp nhiều hơn, model nhanh chóng khớp chặt dữ liệu huấn luyện).
• B. Tăng kích thước tập huấn luyện bằng cách NHÂN BẢN các ví dụ giao dịch gian lận để cải thiện recall — hai vấn đề: nhân bản không thêm thông tin và làm overfitting tệ hơn; và cụm "fraudulent transactions" là lỗi sao chép từ một câu hỏi khác — đề này nói về phân loại bệnh nhân nguy cơ cao/thấp, không có giao dịch nào.

(Lỗi ở phương án B là dấu hiệu của việc bộ đề tái sử dụng khung câu hỏi giữa các chủ đề mà quên sửa chi tiết — nó không ảnh hưởng tới việc chọn đáp án, nhưng đáng ghi nhận.)

Ghi nhớ

Các tham số chống overfitting của XGBoost — theo mức tác động: | Tham số | Việc | Hướng chống overfit | |---|---|---| | max_depth | độ sâu tối đa mỗi cây | GIẢM (4–6) | | min_child_weight | trọng số tối thiểu mỗi lá | TĂNG | | subsample | tỷ lệ mẫu mỗi cây | GIẢM (0,7–0,9) | | colsample_bytree | tỷ lệ đặc trưng mỗi cây | GIẢM (0,7–0,9) | | reg_alpha / reg_lambda | L1 / L2 regularization | TĂNG | | eta (learning_rate) | tốc độ học | GIẢM (kèm tăng số cây) | | num_round | số cây | GIẢM, hoặc dùng early stopping |

Hai dòng cuối đi cùng nhau: giảm eta và tăng num_round cho model ổn định hơn — nhưng phải có early stopping để không chạy quá số cây cần thiết:

xgb.fit(..., eval_set=[(X_val, y_val)], early_stopping_rounds=20)

Chẩn đoán qua đường cong loss: | Train | Validation | Chẩn đoán | Chữa bằng | |---|---|---|---| | Thấp | Cao | overfitting | giảm max_depth, tăng regularization, thêm dữ liệu | | Cao | Cao | underfitting | tăng max_depth, thêm đặc trưng |

Ba cách khác chống overfitting không đụng tới siêu tham số: | Cách | Chi tiết | |---|---| | Thêm dữ liệu thật | cách tốt nhất — giảm variance không tăng bias | | Cross-validation | phát hiện sớm và chọn cấu hình ổn định | | Early stopping | dừng đúng lúc validation loss chạm đáy |

Và với dữ liệu y tế nói riêng: kiểm tra rò rỉ dữ liệu trước khi kết luận overfitting. Một cột như "kết quả xét nghiệm chẩn đoán" chỉ tồn tại sau khi bệnh được xác nhận — dùng nó để huấn luyện cho điểm số rất cao rồi thất bại hoàn toàn trên bệnh nhân mới, và triệu chứng trông giống hệt overfitting.