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

Đáp án

B — Model parameter (tham số model) là các giá trị định nghĩa model và hành vi của nó trong việc diễn giải đầu vào và sinh phản hồi. Hyperparameter (siêu tham số) là các giá trị điều chỉnh được để tuỳ biến model, kiểm soát quá trình huấn luyện.

Vì sao đúng

Đây là một phân biệt nền tảng, và cách nhớ đơn giản nhất là hỏi ai quyết định giá trị: | | Model parameter | Hyperparameter | |---|---|---| | Ai quyết định | MODEL học được trong quá trình huấn luyện | CON NGƯỜI đặt trước khi huấn luyện | | Ví dụ | trọng số, bias | learning rate, batch size, số epoch, số tầng | | Số lượng | hàng triệu tới hàng tỷ | thường vài tới vài chục | | Thay đổi khi nào | liên tục trong lúc huấn luyện | cố định trong một lần huấn luyện |

Với foundation model, sự phân biệt này rất trực quan:

"Model 70 tỷ tham số"  → 70 tỷ MODEL PARAMETER (trọng số đã học)
                          → định nghĩa model biết gì và cư xử thế nào

Learning rate = 0,0001  → HYPERPARAMETER
Batch size = 32         → HYPERPARAMETER
                          → kiểm soát CÁCH model học

Và với GenAI có thêm một tầng dễ nhầm: các tham số lúc suy luận (temperature, top-p, max tokens) đôi khi cũng được gọi là hyperparameter — nhưng chúng không tham gia huấn luyện, chúng chỉ điều chỉnh cách lấy mẫu từ model đã cố định.

Nên bảng đầy đủ cho GenAI là ba tầng: | Tầng | Ví dụ | Thay đổi được sau khi huấn luyện? | |---|---|---| | Model parameter | trọng số | chỉ bằng fine-tuning | | Training hyperparameter | learning rate, epoch | không (phải huấn luyện lại) | | Inference parameter | temperature, top-p | ✅ đổi ở mỗi lời gọi |

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

• A. Hyperparameter định nghĩa model và hành vi, model parameter là giá trị điều chỉnh được để tuỳ biến — đảo ngược hoàn toàn hai định nghĩa.
• C. Cả hai đều là giá trị điều chỉnh được để kiểm soát quá trình huấn luyện — sai với model parameter: bạn không đặt trọng số bằng tay; model học chúng.
• D. Cả hai đều là giá trị định nghĩa model và hành vi — sai với hyperparameter: nó kiểm soát cách học, không phải là bản thân kiến thức của model.

Ghi nhớ

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

"Giá trị này do ai đặt?" Model tự học → parameter Con người đặt trước → hyperparameter

Các hyperparameter huấn luyện quan trọng nhất: | Hyperparameter | Ảnh hưởng | |---|---| | Learning rate | quan trọng nhất — quá lớn thì dao động, quá nhỏ thì chậm | | Batch size | tốc độ và độ ổn định của gradient | | Số epoch | quá ít thì underfit, quá nhiều thì overfit | | Kiến trúc (số tầng, số neuron) | năng lực model | | Regularization (L1, L2, dropout) | chống overfitting |

Các inference parameter của GenAI: | Tham số | Điều khiển | |---|---| | Temperature | độ ngẫu nhiên — thấp thì tất định, cao thì sáng tạo | | Top-P (nucleus) | chỉ lấy token có tổng xác suất tích luỹ ≤ P | | Top-K | chỉ lấy K token xác suất cao nhất | | Max tokens | độ dài tối đa của phản hồi |

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

Và một liên hệ với các kỹ thuật tuỳ biến model: | Kỹ thuật | Đụng tới gì | |---|---| | Prompt engineering | không đụng gì — chỉ đổi đầu vào | | RAG | không đụng trọng số — thêm ngữ cảnh | | Fine-tuning / LoRA | THAY ĐỔI model parameter | | Đổi inference parameter | không đụng trọng số |

Chỉ dòng thứ ba thay đổi bản thân model — và đó cũng là nội dung của #6571 trong cùng lô này.

Đáp án

A — Accuracy (độ chính xác).

Vì sao đúng

Điểm quyết định nằm ở cách diễn đạt của đề: "maximize correct predictions for BOTH patients at risk (positive labels) AND patients not at risk (negative labels)".

Cụm "cả hai lớp, đối xử như nhau" chính là định nghĩa của accuracy:

Accuracy = (TP + TN) / (TP + TN + FP + FN)
             ↑    ↑
        dự đoán đúng ở CẢ HAI lớp

So sánh với các chỉ số khác — mỗi cái chỉ nhìn một phần: | Chỉ số | Công thức | Nhìn vào | |---|---|---| | Accuracy | (TP + TN) / tổng | CẢ HAI lớp | | Precision | TP / (TP + FP) | chỉ dự đoán dương | | Recall | TP / (TP + FN) | chỉ ca dương thật | | Specificity | TN / (TN + FP) | chỉ ca âm thật |

Precision và recall hoàn toàn bỏ qua true negative — nên chúng không đo được "dự đoán đúng cho bệnh nhân không có nguy cơ".

Ghi chú quan trọng về điều kiện áp dụng

Accuracy chỉ là chỉ số phù hợp khi hai lớp tương đối CÂN BẰNG. Đề không nói gì về phân bố lớp, và đó là một thiếu sót đáng lưu ý:

Nếu chỉ 2% bệnh nhân có nguy cơ:
  Model đoán "không ai có nguy cơ" → accuracy 98%
  → con số đẹp, model hoàn toàn vô dụng

Với dữ liệu y tế, tỷ lệ mắc bệnh thường thấp, nên trong thực tế nên kiểm tra phân bố trước khi chọn accuracy. Nếu mất cân bằng, chỉ số đúng cho cùng mục tiêu ("đúng ở cả hai lớp") là balanced accuracy — trung bình của recall trên từng lớp:

Balanced accuracy = (Recall_dương + Recall_âm) / 2

Nó không nằm trong bốn phương án, nhưng đáng biết vì nó là phiên bản chịu được mất cân bằng của cùng ý tưởng.

Trong phạm vi câu hỏi — bốn lựa chọn đã cho và cách diễn đạt "cả hai lớp" — A là đáp án đúng.

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

• C. Precision — chỉ đo chất lượng của dự đoán DƯƠNG: trong số bệnh nhân bị gắn cờ "có nguy cơ", bao nhiêu đúng. Nó không nói gì về bệnh nhân được xếp "không có nguy cơ".
• D. Recall — chỉ đo khả năng bắt được ca DƯƠNG thật: trong số bệnh nhân thật sự có nguy cơ, bắt được bao nhiêu. Cũng bỏ qua lớp âm. (Đây là phương án gần nhất về mức phổ biến trong y tế — recall thường được ưu tiên vì bỏ sót bệnh nguy hiểm hơn báo nhầm. Nhưng đề nói rõ muốn tối đa hoá cả hai.)
• B. RMSE — chỉ số HỒI QUY: đo sai số giữa giá trị dự đoán và thực tế liên tục. Đây là bài toán phân loại nhị phân, không có sai số liên tục nào.

Ghi nhớ

Bốn ô của confusion matrix và chỉ số nào dùng ô nào:

                Dự đoán DƯƠNG    Dự đoán ÂM
Thực tế DƯƠNG        TP              FN
Thực tế ÂM           FP              TN

Chọn chỉ số theo mục tiêu nghiệp vụ: | Mục tiêu | Chỉ số | |---|---| | Đúng ở cả hai lớp, dữ liệu cân bằng | Accuracy | | Đúng ở cả hai lớp, dữ liệu MẤT CÂN BẰNG | Balanced accuracy, F1 | | Không bỏ sót ca dương | Recall | | Không báo nhầm | Precision | | So sánh model qua nhiều ngưỡng | AUC-ROC hoặc PR-AUC |

Và nguyên tắc quan trọng nhất khi chọn chỉ số:

Chỉ số phải phản ánh CHI PHÍ NGHIỆP VỤ của từng loại lỗi.

Với sàng lọc bệnh, bỏ sót một bệnh nhân (FN) thường tốn kém hơn nhiều so với gọi thêm một người đi xét nghiệm (FP) — nên trong thực tế, recall hoặc F-beta với β > 1 thường phù hợp hơn accuracy, dù đề này diễn đạt theo hướng khác.

Đáp án

C — Giảm buffer interval của Kinesis Data Firehose về 0 giây bằng cách dùng "buffering hints", cho phép giao dữ liệu tới OpenSearch Service ngay lập tức.

Vì sao đúng

Đề nêu tình trạng hiện tại và mục tiêu: | Hiện tại | Mục tiêu | |---|---| | Firehose với buffer interval 60 giây | độ trễ dưới một giây |

Nguyên nhân độ trễ nằm đúng ở tham số đó, và AWS đã cho phép hạ nó xuống 0:

Buffer interval 60 giây:
  Firehose GOM dữ liệu 60 giây rồi mới gửi một lô
  → cảnh báo về sự kiện sức khoẻ có thể chậm tới 60 giây

Buffer interval 0 giây (zero buffering):
  Firehose gửi ngay khi nhận
  → độ trễ giảm xuống mức dưới giây

Buffering hints là cấu hình của Firehose gồm hai tham số, và cái nào đạt trước thì gửi:

{
  "BufferingHints": {
    "IntervalInSeconds": 0,     // gửi ngay, không chờ
    "SizeInMBs": 1
  }
}

Đây là giải pháp ít thay đổi nhất — chỉ sửa một tham số cấu hình, không đổi kiến trúc, không viết mã mới. Với một pipeline đang chạy phục vụ giám sát bệnh nhân, đó là lợi thế thật.

(Ghi chú lịch sử: buffer interval tối thiểu của Firehose trước đây là 60 giây. AWS bổ sung tuỳ chọn zero buffering cho các đích như OpenSearch sau này. Nếu bạn đọc tài liệu cũ, con số 60 giây vẫn xuất hiện như mức tối thiểu — nên đáp án này chỉ đúng với phiên bản dịch vụ hiện tại.)

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

• D. Thay Firehose bằng Kinesis Data Streams và dùng Lambda ghi dữ liệu vào OpenSearch với độ trễ thấp hơn — đây là phương án gần nhất và hoàn toàn khả thi về mặt kỹ thuật: Data Streams cho độ trễ dưới giây và Lambda xử lý ngay. Nó thua ở công sức: phải viết và bảo trì hàm Lambda, xử lý lỗi, thử lại, và quản lý shard. Khi một thay đổi cấu hình đạt được cùng kết quả, đổi cả kiến trúc là quá mức cần thiết.
• A. Chuyển từ Firehose sang Apache Spark Streaming tiền xử lý rồi nạp vào OpenSearch — tốn công nhất: phải dựng và quản lý cụm Spark (EMR hoặc Managed Flink), viết mã xử lý. Và Spark Streaming hoạt động theo micro-batch, nên bản thân nó cũng có độ trễ.
• B. Bật caching trên dashboard OpenSearch để giảm độ trễ bằng cách phục vụ dữ liệu đã nạp trước đó — giải quyết sai vấn đề: cache làm dashboard hiển thị dữ liệu CŨ nhanh hơn, trong khi vấn đề là dữ liệu mới chưa tới. Với cảnh báo y tế, phục vụ dữ liệu cũ là điều tệ nhất có thể làm.

Ghi nhớ

Bốn dịch vụ streaming của AWS: | Dịch vụ | Việc | Độ trễ | |---|---|---| | Kinesis Data Streams | thu nhận và lưu tạm luồng | dưới giây | | Kinesis Data Firehose | giao luồng tới đích, có buffer | 0 giây tới 15 phút (cấu hình được) | | Managed Service for Apache Flink | xử lý và tổng hợp luồng | dưới giây | | Amazon MSK | Kafka được quản lý | dưới giây |

Phân biệt hai cái đầu: | | Data Streams | Firehose | |---|---|---| | Nhiều consumer | ✅ | ❌ một đích | | Lưu lại và replay | ✅ (24h–365 ngày) | ❌ | | Quản lý shard | phải tự lo (hoặc on-demand) | không cần | | Biến đổi dữ liệu | tự viết consumer | Lambda transform tích hợp |

Hai tham số buffering hints của Firehose: | Tham số | Khoảng | Ý nghĩa | |---|---|---| | IntervalInSeconds | 0–900 | chờ tối đa bao lâu | | SizeInMBs | 1–128 | gom tối đa bao nhiêu dữ liệu |

Cái nào đạt trước thì gửi — nên đặt interval = 0 nghĩa là gửi ngay không chờ gom.

Và một đánh đổi cần biết khi hạ buffer về 0: | Đánh đổi | Chi tiết | |---|---| | Nhiều lời gọi nhỏ tới đích | tăng tải lên OpenSearch | | Nhiều tệp nhỏ nếu đích là S3 | gây vấn đề hiệu năng cho Athena về sau |

Với đích là OpenSearch và yêu cầu cảnh báo tức thì như trong đề, đánh đổi này chấp nhận được. Với đích là S3 cho phân tích theo lô, buffer lớn hơn lại tốt hơn — đây là ví dụ điển hình cho việc cùng một tham số có giá trị tối ưu ngược nhau tuỳ mục đích.

Đáp án

B — So sánh đường cong loss của tập huấn luyện và tập kiểm chứng theo thời gian; nếu validation loss cao hơn nhiều so với training loss thì model nhiều khả năng đang overfitting.

Vì sao đúng

Đề nêu hai nghi ngờ: model hoạt động rất tốt trên dữ liệu huấn luyện nhưng kém trên dữ liệu mới, và có dấu hiệu chưa nắm được hết độ phức tạp.

Đường cong loss là công cụ chẩn đoán mạnh nhất vì nó phân biệt được cả hai vấn đề cùng lúc:

OVERFITTING:
loss │╲
     │ ╲___         validation ← tách xa dần
     │     ╲___╱──
     │╲
     │ ╲____        training  ← tiếp tục giảm
     └──────────────

UNDERFITTING:
loss │╲___
     │    ╲______   validation ┐
     │╲___          training   ┘ ← CẢ HAI đều cao và phẳng
     │    ╲______
     └──────────────

Bảng chẩn đoán: | Training loss | Validation loss | Kết luận | |---|---|---| | Thấp | Cao | Overfitting | | Cao | Cao | Underfitting | | Thấp | Thấp | tốt | | Cao | Thấp | thường là lỗi dữ liệu (tập validation quá dễ) |

Và đường cong còn cho biết thời điểm bắt đầu overfit — điểm mà validation loss chạm đáy rồi quay đầu — chính là chỗ nên đặt early stopping.

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

• D. Phân tích hiệu năng trên tập kiểm thử riêng; nếu model tốt trên cả tập huấn luyện lẫn tập kiểm thử thì nó không overfit cũng không underfit — đây là phương án gần nhất và kết luận thì đúng, nhưng nó chỉ xác nhận khi model đã tốt. Đề đang hỏi cách chẩn đoán vấn đề đang có — và phương án này không cho biết vấn đề là gì khi model không tốt. (Ngoài ra, dùng tập kiểm thử để chẩn đoán và điều chỉnh là sai quy trình — nó phải giữ nguyên cho lần đánh giá cuối.)
• A. Cross-validation với các tập con khác nhau; nếu hiệu năng biến động nhiều giữa các fold thì model đang UNDERFITTING — kết luận sai chiều: biến động lớn giữa các fold là dấu hiệu PHƯƠNG SAI CAO, tức là overfitting, không phải underfitting. Underfitting cho hiệu năng kém một cách ổn định ở mọi fold.
• C. Giảm số đặc trưng; nếu hiệu năng cải thiện thì trước đó model đang overfitting — đây là thử nghiệm can thiệp, không phải chẩn đoán: bạn thay đổi model rồi suy ngược. Nó tốn thời gian, và kết quả mơ hồ (hiệu năng có thể cải thiện vì lý do khác).

Ghi nhớ

Bảng chẩn đoán qua đường cong loss — bảng nên thuộc: | Triệu chứng | Vấn đề | Cách chữa | |---|---|---| | Train thấp, val cao và tăng | overfitting | regularization, dropout, thêm dữ liệu, early stopping | | Cả hai cao, phẳng lì | underfitting | model phức tạp hơn, thêm đặc trưng, huấn luyện lâu hơn | | Cả hai cao, dao động | learning rate quá lớn | giảm learning rate | | Loss thành NaN | gradient bùng nổ | gradient clipping | | Val thấp hơn train | tập validation quá dễ, hoặc rò rỉ | kiểm tra cách chia dữ liệu |

Phân biệt bias và variance — hai khái niệm nền dưới overfitting/underfitting: | | High bias (underfitting) | High variance (overfitting) | |---|---|---| | Nguyên nhân | model quá đơn giản | model quá phức tạp so với dữ liệu | | Biểu hiện | sai ổn định ở mọi tập | biến động lớn giữa các tập | | Chữa bằng | tăng năng lực model | regularization, thêm dữ liệu |

Cross-validation vẫn hữu ích — chỉ là phương án A diễn giải sai kết quả của nó: độ lệch chuẩn lớn giữa các fold = variance cao = overfitting.

Và một trường hợp đặc biệt đáng biết cho dữ liệu chuỗi thời gian như cảm biến trong đề: không được chia ngẫu nhiên. Phải dùng time-based split — huấn luyện trên quá khứ, kiểm chứng trên tương lai. Chia ngẫu nhiên dữ liệu chuỗi thời gian là một dạng rò rỉ dữ liệu: model được nhìn thấy tương lai, cho điểm số rất đẹp rồi thất bại hoàn toàn trên production.

Đề nói dữ liệu là "sensor data collected over time" — nên đây là chi tiết cần kiểm tra trước cả việc chẩn đoán overfitting.

Đáp án

A — Bật auto-scaling cho SageMaker endpoint để tự động điều chỉnh số instance theo tải request, và đặt budget alert trong AWS Budgets để theo dõi chi phí tăng khi co giãn.

Vì sao đúng

Đề nêu bốn yếu tố, và đáp án A xử lý cả bốn: | Yếu tố | Cơ chế | |---|---| | Đỉnh tải gây độ trễ cao và timeout | auto-scaling thêm instance khi cần | | Cần độ trễ thấp | giữ endpoint real-time | | Ngân sách hạn hẹp | giảm instance khi tải thấp | | Theo dõi chi phí | AWS Budgets cảnh báo |

Auto-scaling giải quyết đúng nguyên nhân: timeout xảy ra vì request xếp hàng khi số instance không đủ. Thêm instance giải quyết trực tiếp:

autoscaling.put_scaling_policy(
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 1000.0,
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'SageMakerVariantInvocationsPerInstance'},
        'ScaleOutCooldown': 60,      # lên nhanh
        'ScaleInCooldown': 300})     # xuống chậm

Và vế thứ hai — budget alert — là chi tiết quan trọng cho một startup ngân sách hạn hẹp:

Auto-scaling giải quyết vấn đề hiệu năng nhưng tạo ra một rủi ro mới: chi phí không kiểm soát.

Một đợt tăng tải bất thường (hoặc một bug gây gọi lặp) có thể đẩy số instance lên trần và tạo hoá đơn bất ngờ. MaxCapacity là trần cứng, còn AWS Budgets là hệ thống cảnh báo cho bạn biết trước khi tháng kết thúc.

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

• D. Tăng kích thước instance để xử lý nhiều request hơn mỗi instance, và theo dõi THỦ CÔNG hiệu năng và chi phí bằng CloudWatch — đây là phương án gần nhất và có giúp một phần, nhưng nó giải quyết bằng cách cấp thừa cố định: instance lớn hơn chạy 24/7 nghĩa là trả nhiều tiền hơn kể cả lúc thấp điểm — trái yêu cầu tiết kiệm. Và "manually monitor" không phải giải pháp vận hành.
• C. Xin tăng service quota để có nhiều instance hơn lúc cao điểm, và đặt CloudWatch Alarm khi vượt 80% quota — quota không phải nút thắt: nâng trần cho phép có thể dùng nhiều instance hơn, nhưng nếu không bật auto-scaling thì số instance vẫn không tự tăng. Đây là điều kiện cần chứ không phải giải pháp.
• B. Dùng AWS Lambda với Provisioned Concurrency xử lý request, giới hạn concurrency tối đa để kiểm soát chi phí — thay đổi kiến trúc lớn không cần thiết, và có hai vấn đề: model chẩn đoán y tế có thể vượt giới hạn kích thước của Lambda, và Provisioned Concurrency là trả tiền giữ sẵn — mâu thuẫn với mục tiêu tiết kiệm.

Ghi nhớ

Ba nguyên nhân độ trễ và timeout của SageMaker endpoint: | Nguyên nhân | Cách nhận biết | Cách chữa | |---|---|---| | Không đủ instance | InvocationsPerInstance cao, độ trễ tăng theo tải | auto-scaling | | Instance quá nhỏ cho model | ModelLatency cao kể cả khi tải thấp | instance lớn hơn hoặc GPU | | Payload quá lớn | OverheadLatency cao | giảm kích thước payload |

Dòng đầu và dòng hai cần phân biệt vì cách chữa khác nhau: độ trễ tăng theo tải là vấn đề số lượng; độ trễ cao kể cả khi rảnh là vấn đề kích thước.

Bốn tham số auto-scaling cần đặt đúng: | Tham số | Ảnh hưởng | |---|---| | MinCapacity | sàn — đặt ≥ 2 để chịu được mất một AZ | | MaxCapacity | trần chi phí — quan trọng với ngân sách hạn hẹp | | TargetValue | quá cao thì chậm phản ứng, quá thấp thì cấp thừa | | Cooldown lên < xuống | mở rộng nhanh, thu hẹp chậm |

Ba công cụ quản lý chi phí AWS: | Công cụ | Việc | |---|---| | AWS Budgets | đặt ngưỡng và CẢNH BÁO khi vượt | | Cost Explorer | phân tích xu hướng, dự báo, lọc theo tag | | Cost Anomaly Detection | tự phát hiện chi tiêu bất thường |

Dòng cuối đáng bật cho startup: nó dùng máy học để nhận ra chi tiêu lệch khỏi mẫu bình thường — bắt được những sự cố mà ngưỡng cố định bỏ sót.

Và một giới hạn cần biết: auto-scaling của SageMaker mất vài phút để instance mới sẵn sàng. Với đỉnh tải dựng đứng, kết hợp thêm scheduled scaling cho những khung giờ đã biết trước — nâng MinCapacity từ trước thay vì để hệ thống phản ứng sau.

Đáp án

D — Huấn luyện một model Linear Learner cơ bản trên SageMaker, tập trung vào các đặc trưng chính như tuổi khách hàng, tần suất mua hàng và giá trị đơn hàng trung bình, để thiết lập đường cơ sở cho việc dự đoán CLV.

Vì sao đúng

Đề nêu mục đích rất rõ: thiết lập đường cơ sở hiệu năng TRƯỚC KHI triển khai model phức tạp, để có điểm tham chiếu đánh giá các model nâng cao sau này.

Ba tính chất của một đường cơ sở tốt, và Linear Learner có cả ba: | Tính chất | Linear Learner | |---|---| | Đơn giản, dễ cài đặt | thuật toán dựng sẵn, vài dòng mã | | Nhanh và rẻ | huấn luyện trong phút, chạy trên CPU | | Cùng loại bài toán | hồi quy — đúng với CLV là giá trị liên tục |

Vì sao cần đường cơ sở — đây là nguyên tắc thực hành quan trọng:

Không có đường cơ sở:
  "Model deep learning đạt RMSE 450"  → tốt hay không? Không biết.

Có đường cơ sở:
  Linear Learner:  RMSE 520
  Deep learning:   RMSE 450   → cải thiện 13%
  → giờ mới đánh giá được liệu công sức có xứng đáng

Và không hiếm khi kết quả là: model phức tạp không hơn đường cơ sở bao nhiêu — một thông tin rất giá trị, vì nó tiết kiệm công sức và chi phí vận hành cho phần đời còn lại của hệ thống.

Ba đặc trưng đề nêu (tuổi, tần suất mua, giá trị đơn trung bình) cũng đúng tinh thần đường cơ sở: chúng là những biến hiển nhiên nhất — nếu model phức tạp không vượt được một model tuyến tính trên ba biến này, có vấn đề ở đâu đó.

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

• C. Dùng SageMaker Autopilot tự động khám phá nhiều model và chọn cái tốt nhất làm đường cơ sở, bỏ qua việc chọn model thủ công — đây là phương án gần nhất và rất hữu ích trong thực tế, nhưng nó mâu thuẫn với mục đích của đường cơ sở: Autopilot cho ra model tốt nhất nó tìm được, không phải một điểm tham chiếu đơn giản. Nếu đường cơ sở đã là kết quả tối ưu hoá tự động, bạn mất khả năng trả lời "model phức tạp có đáng công không". (Autopilot đúng là công cụ tốt để tạo một baseline MẠNH — nhưng đường cơ sở trong ngữ cảnh này là "mức tối thiểu để so", và cần đơn giản.)
• B. Dùng JumpStart triển khai model đã huấn luyện sẵn cho PHÂN KHÚC khách hàng làm đường cơ sở cho model dự đoán CLV — sai loại bài toán: phân khúc khách hàng là phân cụm không giám sát, CLV là hồi quy có giám sát. Hai đầu ra không so sánh được với nhau.
• A. Triển khai BlazingText tạo word embedding từ đánh giá của khách hàng làm đường cơ sở — sai hoàn toàn: BlazingText xử lý văn bản, và embedding không phải dự đoán CLV. Không có gì để so.

Ghi nhớ

Nguyên tắc đường cơ sở (baseline):

Luôn dựng một model đơn giản trước. Nó cho biết bài toán khó tới đâu và model phức tạp đáng giá bao nhiêu.

Ba mức đường cơ sở, từ đơn giản nhất: | Mức | Ví dụ | |---|---| | Baseline tầm thường | đoán giá trị trung bình cho mọi khách hàng | | Baseline đơn giản | hồi quy tuyến tính trên vài đặc trưng hiển nhiên ← câu này | | Baseline mạnh | XGBoost với siêu tham số mặc định, hoặc Autopilot |

Nên có ít nhất mức 1 và mức 2: mức 1 cho biết sàn tuyệt đối, mức 2 cho biết một model hợp lý đạt được gì.

Thuật toán dựng sẵn của SageMaker cho hồi quy: | Thuật toán | Đặc điểm | |---|---| | Linear Learner | đơn giản, nhanh, diễn giải được — tốt cho baseline | | XGBoost | mạnh nhất cho dữ liệu bảng | | Factorization Machines | dữ liệu thưa, tương tác đặc trưng | | DeepAR | chuỗi thời gian |

Ba lợi ích thực tế của việc có đường cơ sở: | Lợi ích | Chi tiết | |---|---| | Đo được tiến bộ | biết cải thiện bao nhiêu phần trăm | | Phát hiện lỗi sớm | model phức tạp TỆ HƠN baseline là dấu hiệu có bug | | Quyết định dừng đúng lúc | nếu chênh lệch nhỏ, chọn model đơn giản để vận hành |

Dòng giữa đáng nhớ: một model deep learning cho kết quả kém hơn hồi quy tuyến tính gần như luôn là dấu hiệu của lỗi kỹ thuật (chuẩn hoá sai, learning rate sai, rò rỉ trong baseline) chứ không phải giới hạn của thuật toán.

Và một lợi ích ít được nhắc: model đơn giản dễ vận hành hơn nhiều. Nếu nó chỉ kém 3%, nó thường là lựa chọn đúng cho production — rẻ hơn, nhanh hơn, dễ giải thích hơn, và ít thứ hỏng hơn.

Đáp án

A — Token là một chuỗi ký tự mà model có thể diễn giải hoặc dự đoán như một đơn vị nghĩa duy nhất; embedding là một vector giá trị số biểu diễn thông tin đã được cô đọng bằng cách biến đổi đầu vào thành vector đó.

Vì sao đúng

Hai khái niệm này ở hai giai đoạn khác nhau trong đường đi của dữ liệu qua model:

Văn bản thô:  "Học máy rất thú vị"
    ↓ ① TOKENIZATION
Token:        ["Học", "máy", "rất", "thú", "vị"]      ← vẫn là ký tự
    ↓ ② EMBEDDING
Vector:       [[0.23, -0.81, ...], [0.45, 0.12, ...], ...]   ← số
    ↓
Model xử lý

Token — đơn vị rời rạc: | Đặc điểm | Chi tiết | |---|---| | Bản chất | chuỗi ký tự | | Có thể là | từ, từ con (subword), hoặc ký tự | | Vì sao quan trọng | tính tiền và giới hạn ngữ cảnh đều đo bằng TOKEN |

Ví dụ về từ con: "tokenization" → ["token", "ization"]. Cách chia này cho phép model xử lý được từ chưa từng thấy bằng cách ghép các mảnh đã biết.

Embedding — biểu diễn liên tục: | Đặc điểm | Chi tiết | |---|---| | Bản chất | vector số nhiều chiều (thường 384–3.072 chiều) | | Tính chất | gần nhau trong không gian = gần nhau về Ý NGHĨA | | Vì sao quan trọng | nền tảng của tìm kiếm ngữ nghĩa và RAG |

Tính chất thứ hai là điều làm embedding hữu ích:

"con mèo"  và  "chú mèo"   → hai vector RẤT GẦN
"con mèo"  và  "máy bay"   → hai vector xa nhau

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

• D. Embedding là chuỗi ký tự, token là vector số — đảo ngược hoàn toàn hai định nghĩa.
• B. Cả hai đều là vector số — sai với token: token vẫn là ký tự, chưa được chuyển thành số.
• C. Cả hai đều là chuỗi ký tự — sai với embedding: embedding là số, đó là toàn bộ điểm của nó.

Ghi nhớ

Ba khái niệm liên quan, theo thứ tự xử lý: | Khái niệm | Bản chất | Giai đoạn | |---|---|---| | Token | chuỗi ký tự | sau tokenization | | Token ID | số nguyên (chỉ số trong từ điển) | ánh xạ token → id | | Embedding | vector số nhiều chiều | tra bảng embedding |

Ba điều cần biết về token trong thực tế: | Điều | Chi tiết | |---|---| | Quy tắc thô | 1 token ≈ 4 ký tự tiếng Anh | | Ngôn ngữ có dấu tốn nhiều token hơn | tiếng Việt thường gấp 1,5–2 lần tiếng Anh cùng nghĩa | | Tính tiền theo token | cả đầu vào lẫn đầu ra |

Dòng giữa có ý nghĩa thực tế: một prompt tiếng Việt tốn nhiều token hơn bản dịch tiếng Anh của nó — nên với ứng dụng khối lượng lớn, đây là yếu tố chi phí thật.

Ba đặc điểm của embedding cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Số chiều cố định | mỗi model có số chiều riêng (Titan v2: 1.024, có thể chọn 256/512) | | KHÔNG so sánh được giữa các model | vector từ hai model khác nhau là vô nghĩa với nhau | | Đo bằng cosine similarity | phổ biến nhất cho embedding văn bản |

Dòng giữa là quy tắc quan trọng nhất khi vận hành hệ thống RAG:

Đổi embedding model = bắt buộc dựng lại TOÀN BỘ index.

Không có cách vá cục bộ nào, và trộn vector từ hai model cho ra kết quả xếp hạng sai một cách âm thầm — hệ thống không báo lỗi, nó chỉ trả về kết quả kém hơn.

Và một loại embedding khác đáng biết: embedding đa phương thức (multimodal) — ánh xạ cả văn bản lẫn ảnh vào CÙNG một không gian vector, cho phép tìm ảnh bằng câu mô tả. Amazon Titan Multimodal Embeddings làm việc này.

Đáp án

B — Triển khai SageMaker Model Monitor theo dõi phân bố đặc trưng đầu vào và dự đoán của model theo thời gian, cảnh báo khi có sai lệch so với mẫu kỳ vọng.

Vì sao đúng

Đề mô tả triệu chứng: một số giao dịch bị phân loại nhầm là không gian lận, và nghi ngờ có bất thường hoặc lỗi ở khâu xử lý dữ liệu hoặc suy luận.

Model Monitor giám sát đúng hai chỗ mà đề nghi ngờ: | Khâu nghi ngờ | Model Monitor phát hiện | |---|---| | Xử lý dữ liệu | data quality — phân bố đặc trưng đầu vào lệch khỏi baseline | | Suy luận model | prediction drift — phân bố đầu ra thay đổi bất thường |

Vì sao giám sát phân bố phát hiện được lỗi pipeline:

Baseline (lúc huấn luyện):  so_tien có giá trị trung bình 2,3 triệu
Hiện tại:                    so_tien có giá trị trung bình 2.300

→ Có ai đó đổi đơn vị từ đồng sang nghìn đồng ở khâu tiền xử lý
→ Model nhận đầu vào sai thang đo ⇒ dự đoán sai một cách hệ thống

Đây là loại lỗi im lặng nguy hiểm nhất: không có exception, không có mã lỗi 500, pipeline chạy "thành công" — chỉ là kết quả sai.

Và prediction drift là chỉ báo bổ sung quan trọng cho phát hiện gian lận:

Nếu tỷ lệ giao dịch bị gắn cờ đột nhiên giảm mạnh mà không có lý do nghiệp vụ, đó là dấu hiệu sớm nhất — vì nhãn thật (khách khiếu nại) đến rất muộn.

DefaultModelMonitor(...).create_monitoring_schedule(
    endpoint_input=endpoint,
    statistics=baseline.baseline_statistics(),
    constraints=baseline.suggested_constraints(),
    schedule_cron_expression=CronExpressionGenerator.hourly())

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

• A. Dùng Lambda ghi log và kiểm toán mọi giao dịch, lưu log chi tiết trên S3 để phân tích THỦ CÔNG khi nghi có bất thường — đây là phương án gần nhất và ghi log là việc nên làm, nhưng nó thụ động: log chỉ hữu ích khi bạn đã biết có vấn đề và biết tìm gì. Model Monitor chủ động phát hiện và cảnh báo.
• D. Đặt CloudWatch alarm giám sát CPU và bộ nhớ trên các tài nguyên tính toán của pipeline — giám sát sai tầng: CPU và bộ nhớ cho biết hạ tầng có khoẻ không, không cho biết dữ liệu có đúng không. Một pipeline dùng CPU hoàn toàn bình thường vẫn có thể đang xử lý dữ liệu sai.
• C. Xem xét thủ công định kỳ một mẫu ngẫu nhiên các giao dịch đã xử lý — quá chậm và không đủ độ phủ: với khối lượng lớn và gần thời gian thực, mẫu ngẫu nhiên rất khó bắt được vấn đề, và "định kỳ" nghĩa là phát hiện muộn.

Ghi nhớ

Ba tầng giám sát cho pipeline ML — mỗi tầng bắt một loại vấn đề: | Tầng | Công cụ | Bắt gì | |---|---|---| | Hạ tầng | CloudWatch (CPU, bộ nhớ, lỗi) | dịch vụ chết, hết tài nguyên | | Dữ liệu | Model Monitor (data quality) | dữ liệu sai định dạng, sai thang đo, thiếu | | Model | Model Monitor (quality, drift) | model kém đi, phân bố dự đoán lạ |

Cả ba đều cần — và tầng giữa là tầng hay bị bỏ sót nhất, dù nó bắt được loại lỗi im lặng nhất.

Bốn loại giám sát của Model Monitor: | Loại | Phát hiện | Cần nhãn thật? | |---|---|---| | Data quality | thiếu giá trị, sai kiểu, phân bố lệch | ❌ | | Model quality | độ chính xác giảm | ✅ | | Bias drift | chênh lệch giữa các nhóm | ❌ | | Feature attribution drift | đặc trưng chi phối đổi | ❌ |

Với phát hiện gian lận, cột cuối rất quan trọng: nhãn thật đến sau hàng tuần, nên ba loại không cần nhãn là chỉ báo khả dụng duy nhất theo thời gian thực.

Hai điều kiện bắt buộc trước khi giám sát: | Điều kiện | Chi tiết | |---|---| | Data capture bật trên endpoint | không bật thì job chạy với báo cáo trống | | Baseline đã tính | suggest_baseline() từ dữ liệu huấn luyện |

Ba ràng buộc mà baseline sinh ra tự động:

{"name": "so_tien",
 "inferred_type": "Fractional",
 "completeness": 1.0,
 "num_constraints": {"is_non_negative": true}}

Ba ràng buộc này bắt được phần lớn lỗi pipeline im lặng — và chúng được sinh tự động, không phải khai bằng tay.

Đáp án

C — Dùng Amazon Transcribe chuyển video và âm thanh thành văn bản tiếng Đức, Amazon Translate dịch tiếng Đức sang tiếng Anh, và Amazon Comprehend phân tích cảm xúc cùng tóm tắt phản hồi bằng tiếng Anh.

Vì sao đúng

Đề nêu ba yêu cầu, và chuỗi ba dịch vụ xử lý đúng ba bước:

Video/âm thanh tiếng Đức
    ↓ ① Amazon Transcribe (speech-to-text)
Văn bản tiếng Đức
    ↓ ② Amazon Translate (dịch)
Văn bản tiếng Anh
    ↓ ③ Amazon Comprehend (cảm xúc, phân tích)
Kết quả bằng tiếng Anh

Mỗi dịch vụ làm đúng một việc nó được thiết kế cho, và cả ba đều là dịch vụ được quản lý — đáp ứng yêu cầu "least operational effort": | Bước | Dịch vụ | Vì sao | |---|---|---| | Âm thanh → văn bản | Transcribe | hỗ trợ nhiều ngôn ngữ, xử lý được video | | Dịch | Translate | dịch máy chất lượng cao | | Phân tích | Comprehend | cảm xúc, thực thể, cụm từ khoá |

transcribe.start_transcription_job(
    Media={'MediaFileUri': 's3://kho/phan-hoi/'},
    LanguageCode='de-DE',                    # tiếng Đức
    OutputBucketName='kho-van-ban')

translate.translate_text(Text=van_ban_duc,
    SourceLanguageCode='de', TargetLanguageCode='en')

comprehend.detect_sentiment(Text=van_ban_anh, LanguageCode='en')

(Một lưu ý: Comprehend hỗ trợ trực tiếp tiếng Đức cho phân tích cảm xúc, nên về mặt kỹ thuật có thể bỏ bước dịch nếu chỉ cần cảm xúc. Nhưng đề yêu cầu kết quả tóm tắt bằng tiếng Anh, nên bước dịch vẫn cần — chỉ là có thể đặt ở cuối thay vì ở giữa.)

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

• D. Dùng Transcribe TÓM TẮT TRỰC TIẾP âm thanh và video từ tiếng Đức thành văn bản tiếng Anh, rồi Comprehend phân tích cảm xúc — đây là phương án gần nhất và gán cho Transcribe hai khả năng nó không có: nó không tóm tắt, và nó không dịch (nó chép lại đúng ngôn ngữ gốc). Đây là mô tả một tính năng không tồn tại.
• B. Dùng Amazon Rekognition trích xuất metadata từ video và âm thanh, kết hợp với bản chép âm thanh để tóm tắt bằng Comprehend — Rekognition là dịch vụ THỊ GIÁC: nó nhận diện vật thể, khuôn mặt, cảnh trong video — không xử lý âm thanh và không trích xuất được nội dung lời nói.
• A. Tiền xử lý THỦ CÔNG mọi định dạng thành văn bản thuần và dùng model SageMaker tự huấn luyện để tóm tắt bằng tiếng Anh — tốn công nhất: "manually preprocess" với khối lượng lớn là không khả thi, và tự huấn luyện model tóm tắt là dự án riêng.

Ghi nhớ

Chuỗi dịch vụ AI của AWS cho các bài toán đa phương thức: | Bài toán | Chuỗi | |---|---| | Cảm xúc từ âm thanh cùng ngôn ngữ | Transcribe → Comprehend | | Cảm xúc từ âm thanh đa ngôn ngữ | Transcribe → Translate → Comprehend ← câu này | | Phân tích tài liệu scan | Textract → Comprehend | | Phụ đề đa ngôn ngữ | Transcribe → Translate → Polly | | Kiểm duyệt video | Rekognition (hình) + Transcribe (tiếng) |

Bảng phân vai — nhớ đúng dịch vụ nào làm gì: | Dịch vụ | Đầu vào | Đầu ra | |---|---|---| | Transcribe | âm thanh, video | văn bản CÙNG ngôn ngữ | | Translate | văn bản | văn bản ngôn ngữ KHÁC | | Comprehend | văn bản | cảm xúc, thực thể, cụm từ khoá | | Rekognition | ảnh, video (HÌNH) | vật thể, khuôn mặt, văn bản trong ảnh | | Polly | văn bản | âm thanh |

Ba tính năng của Transcribe hữu ích cho phân tích phản hồi khách hàng: | Tính năng | Việc | |---|---| | Speaker diarization | tách lời khách hàng khỏi lời nhân viên | | Custom vocabulary | nhận diện đúng tên sản phẩm, thuật ngữ riêng | | Automatic language identification | tự nhận ngôn ngữ khi có nhiều thứ tiếng |

Dòng cuối đáng dùng cho đề này: công ty thu thập phản hồi nhiều ngôn ngữ, nên bật IdentifyLanguage=True để không phải khai thủ công từng tệp.

Và một lựa chọn hiện đại hơn đáng cân nhắc cho vế tóm tắt: Amazon Bedrock. Comprehend cho cảm xúc và thực thể, nhưng nó không tóm tắt văn bản. Nếu đề thật sự cần bản tóm tắt tự do, chuỗi đúng sẽ là Transcribe → Bedrock (dịch + tóm tắt trong một lời gọi) — vừa gọn hơn vừa cho kết quả tốt hơn. Trong bốn phương án đã cho thì C vẫn là lựa chọn hợp lý nhất.

Đáp án

C và E.

• C — Ưu tiên recall để giảm false negative, đảm bảo bắt được nhiều bệnh nhân mắc bệnh nhất có thể
• E — Dùng F1 score để cân bằng đánh đổi giữa precision và recall, đảm bảo cả hai loại lỗi đều được xét

Vì sao đúng

Đề mô tả hai loại lỗi với hai hậu quả khác nhau, và yêu cầu giảm cả hai: | Loại lỗi | Hậu quả | |---|---| | False positive | xét nghiệm theo dõi không cần thiết và tốn kém | | False negative | không cung cấp được điều trị quan trọng |

E — F1 là chỉ số duy nhất trong năm phương án xét CẢ HAI:

F1 = 2 × (Precision × Recall) / (Precision + Recall)
       ↑ giảm FP              ↑ giảm FN

F1 là trung bình điều hoà, nghĩa là nó bị kéo xuống bởi giá trị thấp hơn — một model có precision 0,95 và recall 0,20 cho F1 chỉ 0,33. Đó là điều mong muốn: nó không cho phép "giỏi một mặt, bỏ mặt kia".

C — recall được ưu tiên riêng vì hậu quả không đối xứng:

Trong y tế, bỏ sót một ca bệnh (FN) thường nghiêm trọng hơn nhiều so với một lần xét nghiệm thừa (FP).

Xét nghiệm thừa tốn tiền và gây lo lắng; bỏ sót bệnh có thể mất mạng. Nên dù cân bằng cả hai (F1), vẫn nghiêng về recall.

Hai đáp án này bổ sung nhau: F1 là chỉ số tổng hợp để so sánh model, recall là ràng buộc tối thiểu phải đạt.

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

• B. Dùng AUC để hiểu hiệu năng qua các ngưỡng phân loại khác nhau — đây là phương án gần nhất và AUC hữu ích thật (đặc biệt để so sánh model trước khi chọn ngưỡng), nhưng nó không trực tiếp đo đánh đổi giữa hai loại lỗi tại điểm vận hành. Và với dữ liệu y tế thường mất cân bằng, ROC-AUC có thể cho con số đẹp giả tạo — PR-AUC phù hợp hơn.
• D. Tập trung vào precision để giảm false positive, tránh xét nghiệm không cần thiết — chỉ nhìn một nửa vấn đề: tối ưu precision đơn thuần sẽ khiến model thận trọng quá mức và bỏ sót bệnh nhân — đúng loại lỗi nghiêm trọng hơn.
• A. Ưu tiên accuracy vì nó cho cảm nhận tổng quát về hiệu năng model — chỉ số gây hiểu lầm với dữ liệu y tế: tỷ lệ mắc bệnh thường thấp, nên model đoán "không ai mắc bệnh" vẫn đạt accuracy rất cao mà hoàn toàn vô dụng.

Ghi nhớ

Bốn chỉ số cho phân loại nhị phân — dùng ô nào của confusion matrix: | Chỉ số | Công thức | Giảm loại lỗi nào | |---|---|---| | Precision | TP / (TP + FP) | false positive | | Recall | TP / (TP + FN) | false negative | | F1 | 2PR / (P + R) | CẢ HAI | | Accuracy | (TP+TN)/tổng | gây hiểu lầm khi mất cân bằng |

F-beta — biến thể khi hai loại lỗi không cân bằng về chi phí: | Biến thể | Ưu tiên | Dùng khi | |---|---|---| | F2 (β = 2) | recall gấp đôi | bỏ sót tốn kém — sàng lọc bệnh | | F1 (β = 1) | cân bằng | mặc định | | F0.5 (β = 0,5) | precision gấp đôi | báo nhầm tốn kém |

Với bài toán y tế trong đề, F2 thường phù hợp hơn F1 — nhưng nó không nằm trong năm phương án.

Ba bước để chọn chỉ số đúng:

① Xác định hai loại lỗi và HẬU QUẢ của từng loại
② Ước lượng CHI PHÍ tương đối của chúng
③ Chọn chỉ số (và ngưỡng) phản ánh tỷ lệ chi phí đó

Và một điểm quan trọng về ngưỡng phân loại, thường bị bỏ qua:

Model trả về XÁC SUẤT; ngưỡng biến xác suất thành quyết định — và ngưỡng là quyết định NGHIỆP VỤ, không phải kỹ thuật.

Ngưỡng 0,5 (mặc định):  precision 0,80, recall 0,65
Ngưỡng 0,3:              precision 0,62, recall 0,88   ← ít bỏ sót hơn

Với sàng lọc bệnh, hạ ngưỡng để tăng recall thường là lựa chọn đúng — và điều đó không cần huấn luyện lại model, chỉ cần đổi một con số. Nên luôn triển khai model trả về xác suất, không phải nhãn cứng.