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

Tìm thấy 195 câu.

Câu 121 Data Preparation for Machine Learning (ML)

A financial services company is using Amazon SageMaker Canvas to build machine learning models for predicting stock price trends. The company stores its data in Amazon S3, and the dataset includes large volumes of transactional records with a complex structure, including nested fields and multiple data types. The data scientist needs to choose a file format that will optimize data processing performance and minimize loading time into SageMaker Canvas.

Which file format will meet these requirements?

  1. A

    CSV
  2. B

    XML
  3. C

    JSON
  4. D

    Apache Parquet
Xem giải thích

Đáp án

D — Apache Parquet.

Vì sao đúng

Đề nêu ba yếu tố, và Parquet đáp ứng cả ba: | Yếu tố | Parquet | |---|---| | Khối lượng bản ghi giao dịch lớn | nén rất tốt, giảm dung lượng nhiều lần | | Cấu trúc phức tạp, trường lồng nhau | hỗ trợ kiểu lồng nhau tự nhiên | | Tối ưu hiệu năng, giảm thời gian nạp | định dạng CỘT — chỉ đọc cột cần dùng |

Vì sao định dạng cột nhanh hơn cho phân tích:

CSV (theo DÒNG):     đọc mọi cột của mọi dòng, dù chỉ cần 3 cột
Parquet (theo CỘT):  chỉ đọc đúng 3 cột đó
                     → giảm dữ liệu phải đọc nhiều lần

Với dữ liệu giao dịch có hàng chục cột mà model chỉ dùng vài cột, khác biệt rất lớn.

Ba ưu điểm cụ thể của Parquet: | Ưu điểm | Chi tiết | |---|---| | Nén hiệu quả | thường nhỏ hơn CSV 5–10 lần | | Schema nhúng sẵn | kiểu dữ liệu được lưu — không phải suy đoán | | Predicate pushdown | bỏ qua cả khối dữ liệu không thoả điều kiện lọc |

Dòng giữa quan trọng cho dữ liệu giá cổ phiếu: với CSV, một cột số có thể bị đọc nhầm thành chuỗi, và ngày tháng thì luôn phải phân tích lại. Parquet lưu kiểu dữ liệu cùng dữ liệu.

Và vế "nested fields" là điểm phân biệt rõ nhất: CSV hoàn toàn phẳng — không có cách nào biểu diễn cấu trúc lồng nhau ngoài việc làm phẳng thủ công.

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

  • C. JSON — đây là phương án gần nhất và hỗ trợ trường lồng nhau tốt, nhưng nó kém về hiệu năng: JSON là văn bản, không nén theo cột, và phải phân tích cú pháp toàn bộ mỗi lần đọc. Với khối lượng lớn, thời gian nạp cao hơn Parquet nhiều lần.
  • A. CSV — không hỗ trợ trường lồng nhau, không lưu kiểu dữ liệu, nén kém, và là định dạng theo dòng nên phải đọc mọi cột. Nó đơn giản và phổ biến, nhưng sai với cả ba yêu cầu của đề.
  • B. XML — tệ nhất về hiệu năng: rất dài dòng (mỗi giá trị kèm thẻ mở và đóng), phân tích cú pháp chậm, và không có tối ưu theo cột nào.

Ghi nhớ

So sánh các định dạng dữ liệu: | Định dạng | Kiểu | Lồng nhau | Nén | Hiệu năng phân tích | |---|---|---|---|---| | CSV | dòng, văn bản | ❌ | kém | thấp | | JSON | dòng, văn bản | ✅ | kém | thấp | | Parquet | CỘT, nhị phân | ✅ | rất tốt | cao nhất | | ORC | CỘT, nhị phân | ✅ | rất tốt | cao | | Avro | dòng, nhị phân | ✅ | tốt | tốt cho GHI, kém cho đọc phân tích |

Parquet và ORC gần tương đương; Parquet phổ biến hơn trong hệ sinh thái AWS và Spark.

Dòng Avro đáng nhớ: nó là định dạng theo dòng, nên tốt cho việc ghi và streaming nhưng kém cho truy vấn phân tích. Mẫu thường dùng: ghi bằng Avro, chuyển sang Parquet cho phân tích.

Ba trường hợp vẫn nên dùng CSV: | Trường hợp | Lý do | |---|---| | Dữ liệu rất nhỏ | overhead của Parquet không đáng | | Trao đổi với hệ thống chỉ đọc được CSV | tương thích | | Một số thuật toán dựng sẵn của SageMaker | yêu cầu CSV hoặc RecordIO |

Dòng cuối là chi tiết thực tế: nhiều thuật toán dựng sẵn của SageMaker (XGBoost, Linear Learner) nhận CSV hoặc RecordIO-protobuf, không nhận Parquet trực tiếp — nên thường có một bước chuyển đổi ở cuối pipeline chuẩn bị dữ liệu.

Ba tối ưu đi kèm Parquet trên S3: | Tối ưu | Lợi ích | |---|---| | Phân vùng theo cột hay lọc | chỉ đọc thư mục liên quan | | Kích thước tệp 128 MB – 1 GB | tránh vấn đề nhiều tệp nhỏ | | Nén Snappy | cân bằng tốt giữa tỷ lệ nén và tốc độ giải nén |

Và một lưu ý về SageMaker Canvas cụ thể: nó hỗ trợ Parquet trực tiếp, nên không cần chuyển đổi. Với dữ liệu giao dịch chứng khoán khối lượng lớn, đây là lựa chọn giảm thời gian nạp rõ rệt so với CSV.

Câu 122 Chọn nhiều đáp án ML Solution Monitoring, Maintenance, and Security

You are a Cloud Financial Manager at a SaaS company that uses various AWS services to run its applications and machine learning workloads. Your management team has asked you to reduce overall AWS spending while ensuring that critical applications remain highly available and performant. To achieve this, you need to use AWS cost analysis tools to monitor spending, identify cost-saving opportunities, and optimize resource utilization across the organization.

Which of the following actions can you perform using the appropriate AWS cost analysis tools to achieve your goal of reducing costs and optimizing AWS resource utilization? (Select two)

  1. A

    Leverage AWS Trusted Advisor to directly modify and reconfigure resources based on cost optimization recommendations without manual intervention
  2. B

    Use AWS Cost Explorer to set custom budgets for cost and usage to govern costs across your organization and receive alerts when costs exceed your defined thresholds
  3. C

    Use AWS Cost Explorer to automatically delete unused resources across your AWS environment, ensuring that no unnecessary costs are incurred
  4. D

    Use AWS Cost Explorer to analyze historical spending patterns, identify cost trends, and forecast future costs to help with budgeting and planning
  5. E

    Leverage AWS Trusted Advisor to receive recommendations for cost optimization, such as identifying underutilized or idle resources, and reserved instance purchasing opportunities
Xem giải thích

Đáp án

D và E.

  • D — Dùng AWS Cost Explorer phân tích mẫu chi tiêu lịch sử, xác định xu hướng chi phí và dự báo chi phí tương lai phục vụ lập ngân sách
  • E — Dùng AWS Trusted Advisor nhận khuyến nghị tối ưu chi phí như xác định tài nguyên chưa dùng hết hoặc nhàn rỗi, và cơ hội mua reserved instance

Vì sao đúng

Hai đáp án mô tả đúng khả năng thật của hai công cụ: | Công cụ | Việc | |---|---| | Cost Explorer | PHÂN TÍCH: xem lịch sử, lọc, nhóm, dự báo | | Trusted Advisor | KHUYẾN NGHỊ: quét môi trường và gợi ý cải thiện |

D — Cost Explorer là công cụ phân tích:

Xem lịch sử:  chi phí 12 tháng qua theo dịch vụ, theo tag, theo tài khoản
Lọc và nhóm:  "chi phí SageMaker theo dự án, chỉ môi trường prod"
Dự báo:       ước lượng chi phí 3–12 tháng tới dựa trên xu hướng

Vế dự báo đặc biệt hữu ích cho lập ngân sách: nó dùng mẫu chi tiêu lịch sử để ước lượng tương lai, kèm khoảng tin cậy.

E — Trusted Advisor quét và khuyến nghị: | Loại khuyến nghị | Ví dụ | |---|---| | Tài nguyên nhàn rỗi | EC2 instance CPU dưới 10%, load balancer không có target | | Chưa dùng hết | EBS volume không gắn vào đâu, Elastic IP không dùng | | Cơ hội mua Reserved/Savings Plans | dựa trên mẫu sử dụng ổn định |

Với môi trường ML, hai loại đầu bắt được những khoản lãng phí phổ biến nhất: notebook instance quên tắt và endpoint không còn ai gọi.

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

  • B. Dùng Cost Explorer đặt ngân sách tuỳ chỉnh cho chi phí và mức dùng, nhận cảnh báo khi vượt ngưỡng — đây là phương án gần nhất và mô tả đúng chức năng nhưng SAI DỊCH VỤ: đặt ngân sách và cảnh báo là việc của AWS Budgets, không phải Cost Explorer. Cost Explorer chỉ phân tích và hiển thị.
  • C. Dùng Cost Explorer TỰ ĐỘNG XOÁ tài nguyên không dùng — Cost Explorer không thực hiện hành động nào: nó là công cụ chỉ đọc, dùng để phân tích. Nó không tạo, sửa hay xoá tài nguyên.
  • A. Dùng Trusted Advisor TRỰC TIẾP sửa đổi và cấu hình lại tài nguyên theo khuyến nghị không cần can thiệp thủ công — Trusted Advisor chỉ khuyến nghị: nó quét và báo cáo, còn việc thực hiện là của bạn. (Có thể tự động hoá bằng cách bắt sự kiện Trusted Advisor qua EventBridge rồi chạy Lambda — nhưng đó là bạn tự dựng, không phải Trusted Advisor tự làm.)

Ghi nhớ

Bốn công cụ chi phí của AWS — nhớ đúng vai: | Công cụ | Việc | Có hành động không? | |---|---|---| | Cost Explorer | PHÂN TÍCH: lọc, nhóm, xu hướng, dự báo | ❌ chỉ đọc | | AWS Budgets | ĐẶT NGƯỠNG và CẢNH BÁO | ❌ (chỉ báo) | | Trusted Advisor | KHUYẾN NGHỊ tối ưu | ❌ chỉ gợi ý | | Cost and Usage Report | dữ liệu thô chi tiết nhất | ❌ | | Cost Anomaly Detection | phát hiện bất thường bằng ML | ❌ (chỉ báo) |

Không công cụ nào trong nhóm này TỰ THỰC HIỆN hành động — đó là điểm chung mà hai phương án sai (A và C) đều vi phạm.

Năm hạng mục của Trusted Advisor: | Hạng mục | Nội dung | |---|---| | Cost Optimization | tài nguyên nhàn rỗi, cơ hội RI/SP | | Performance | cấu hình chưa tối ưu | | Security | port mở, MFA, key công khai | | Fault Tolerance | backup, multi-AZ | | Service Limits | sắp chạm quota |

(Lưu ý: đầy đủ các kiểm tra cần Business hoặc Enterprise Support plan; gói cơ bản chỉ có một số kiểm tra giới hạn.)

Ba khoản lãng phí phổ biến nhất trong môi trường ML: | Khoản | Cách phát hiện | |---|---| | Notebook instance quên tắt | Trusted Advisor: EC2 nhàn rỗi | | SageMaker endpoint không còn ai gọi | CloudWatch: Invocations = 0 nhiều ngày | | Dữ liệu cũ trên S3 lớp Standard | Cost Explorer theo dịch vụ + S3 Storage Lens |

Dòng giữa không được Trusted Advisor bắt tự động — bạn phải tự đặt alarm trên Invocations, và đó là một trong những kiểm tra đáng thiết lập nhất cho đội ML.

Và ba việc nên làm để kiểm soát chi phí ML liên tục: | Việc | Công cụ | |---|---| | Gắn thẻ mọi tài nguyên và bật cost allocation tag | nền tảng cho mọi phân tích | | Đặt budget theo tag cho từng dự án | AWS Budgets | | Tự động tắt notebook ngoài giờ | EventBridge schedule + Lambda |

Câu 123 Data Preparation for Machine Learning (ML)

A financial services company is building a fraud detection model using Amazon SageMaker. The ML engineer receives a 40 MB Apache Parquet file as input data. The file contains several correlated columns that are not needed for the model. The engineer needs to drop these unnecessary columns with the least effort while ensuring the data remains compatible with SageMaker for further preprocessing and model training.

What should the ML engineer do?

  1. A

    Convert the Parquet file to CSV, manually edit the file to remove the columns, and re-upload the file to SageMaker
  2. B

    Use SageMaker Data Wrangler to import the Parquet file, drop the unnecessary columns, and save the transformed data
  3. C

    Use AWS Glue to transform the Parquet file and drop the unnecessary columns before importing it into SageMaker
  4. D

    Write a custom Python script using pandas to load the Parquet file, drop the unnecessary columns, and save it back as a Parquet file
Xem giải thích

Đáp án

B — Dùng SageMaker Data Wrangler nhập tệp Parquet, bỏ các cột không cần thiết, và lưu dữ liệu đã biến đổi.

Vì sao đúng

Đề nêu ba yếu tố, và cụm quyết định là "with the least effort": | Yếu tố | Data Wrangler | |---|---| | Tệp Parquet 40 MB | hỗ trợ Parquet trực tiếp | | Bỏ cột không cần | thao tác chọn trong giao diện, không viết mã | | Giữ tương thích với SageMaker | xuất thẳng sang S3, Feature Store, hoặc pipeline |

Quy trình trong Data Wrangler:

Import tệp Parquet từ S3
    ↓ chọn transform "Manage columns" → "Drop column"
    ↓ chọn các cột tương quan cần bỏ
    ↓ Export → S3 (vẫn ở định dạng Parquet)

Không viết mã, không dựng hạ tầng, không chuyển đổi định dạng.

Và Data Wrangler còn cho một thứ hữu ích cho chính bài toán này: đề nói các cột "correlated" — Data Wrangler có sẵn công cụ đo tương quan: | Công cụ | Việc | |---|---| | Data Quality and Insights Report | hiển thị ma trận tương quan giữa các cột | | Feature correlation | chỉ ra cặp cột trùng thông tin | | Target leakage detection | phát hiện cột rò rỉ nhãn |

Nên bạn vừa xác định được cột nào nên bỏ vừa bỏ chúng trong cùng một công cụ — thay vì phải phân tích ở nơi khác rồi mới xử lý.

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

  • D. Viết script Python với pandas nạp tệp Parquet, bỏ cột, lưu lại thành Parquet — đây là phương án gần nhất và hoàn toàn hợp lý về mặt kỹ thuật (40 MB nằm gọn trong bộ nhớ). Nó thua ở tiêu chí "least effort": phải viết mã, chạy ở đâu đó, và không tái sử dụng được như một bước trong pipeline. (Trong thực tế, với một tệp 40 MB và một thao tác đơn giản, pandas là lựa chọn rất thực dụng — chỉ là đề hỏi cách ít công nhất trong bối cảnh SageMaker.)
  • C. Dùng AWS Glue biến đổi tệp Parquet và bỏ cột trước khi nhập vào SageMaker — quá nặng cho 40 MB: Glue là công cụ ETL cho quy mô terabyte, và một job Glue có thời gian khởi động vài phút cho một thao tác mất vài giây.
  • A. Chuyển Parquet sang CSV, sửa tệp thủ công để xoá cột, rồi tải lại lên — tệ nhất về mọi mặt: mất kiểu dữ liệu và cấu trúc lồng nhau khi chuyển sang CSV, sửa thủ công không tái lập được, và tệp phình lên đáng kể.

Ghi nhớ

Chọn công cụ chuẩn bị dữ liệu theo quy mô: | Quy mô | Công cụ | |---|---| | MB tới vài GB, thao tác đơn giản | Data Wrangler, hoặc pandas | | GB tới TB | Glue, EMR Spark | | Rất lớn, lặp lại | Glue job trong pipeline |

Bốn khả năng của Data Wrangler: | Khả năng | Chi tiết | |---|---| | Kết nối nhiều nguồn | S3, Athena, Redshift, Snowflake, JDBC | | 300+ transform dựng sẵn | không viết mã | | Data Quality and Insights Report | tương quan, rò rỉ mục tiêu, ngoại lai, mất cân bằng | | Xuất thành pipeline | biến các bước trực quan thành ProcessingStep |

Khả năng cuối là điểm mạnh cho việc chuyển từ thăm dò sang sản xuất: bạn làm bằng giao diện, rồi xuất thành mã chạy lại được — không phải viết lại bằng tay.

Ba lý do nên bỏ cột tương quan cao: | Lý do | Chi tiết | |---|---| | Đa cộng tuyến | làm hệ số của model tuyến tính không ổn định và khó diễn giải | | Tốn tài nguyên | nhiều cột hơn = huấn luyện chậm hơn | | Nguy cơ overfitting | nhiều chiều hơn với cùng lượng dữ liệu |

(Lưu ý: model cây (XGBoost, random forest) chịu được đa cộng tuyến khá tốt — chúng chỉ chọn một trong các cột tương quan. Nên việc bỏ cột quan trọng hơn với model tuyến tính.)

Ba cách phát hiện cột nên bỏ: | Cách | Phát hiện | |---|---| | Ma trận tương quan | cặp cột trùng thông tin (|r| > 0,9) | | Phương sai gần 0 | cột gần như không đổi — không mang thông tin | | Target leakage check | cột chứa thông tin về nhãn — nguy hiểm nhất |

Dòng cuối đáng cảnh giác nhất với model phát hiện gian lận: một cột như "trạng thái khiếu nại" có thể chỉ tồn tại SAU KHI gian lận được phát hiện — dùng nó để huấn luyện cho điểm số rất đẹp rồi thất bại hoàn toàn trên production.

Câu 124 ML Model Development

You are a machine learning engineer at a company building a recommendation system using deep learning. The system is based on a neural network architecture implemented in TensorFlow. Your team wants to train the model on a large dataset stored in Amazon S3 and leverage the scalability of Amazon SageMaker. You plan to use SageMaker script mode to customize the training process while taking advantage of SageMaker’s managed services.

Which of the following actions is the MOST LIKELY to help you successfully train the model using SageMaker script mode with TensorFlow?

  1. A

    Use SageMaker script mode to automatically convert your Python script into a SageMaker Estimator object without specifying the TensorFlow framework version
  2. B

    Package your TensorFlow model as a .tar.gz file, upload it to Amazon S3, and use SageMaker script mode to directly deploy the model for training
  3. C

    Create a custom Docker container with TensorFlow installed and push it to Amazon ECR, then use SageMaker script mode to launch the training job
  4. D

    Write a training script in Python that adheres to TensorFlow's Estimator API, upload it to an S3 bucket, and use SageMaker script mode with the built-in TensorFlow container to execute the script
Xem giải thích

Đáp án

D — Viết script huấn luyện bằng Python theo quy ước của TensorFlow, tải lên S3, và dùng SageMaker script mode với container TensorFlow dựng sẵn để chạy script đó.

Vì sao đúng

Đề nêu ba yếu tố: | Yếu tố | Script mode | |---|---| | Model TensorFlow tự viết | script của bạn, framework chuẩn | | Dữ liệu lớn trên S3 | SageMaker lo việc đưa dữ liệu vào | | Tận dụng dịch vụ được quản lý | container dựng sẵn — không tự đóng gói |

Script mode là mức tuỳ biến ở giữa — bạn viết mã huấn luyện nhưng dùng container do AWS bảo trì:

from sagemaker.tensorflow import TensorFlow

estimator = TensorFlow(
    entry_point='train.py',              # ← script của bạn
    source_dir='./ma-nguon',
    role=role,
    instance_type='ml.p3.2xlarge',
    instance_count=1,
    framework_version='2.14',            # ← khai phiên bản TensorFlow
    py_version='py310')

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

Ba quy ước mà script phải tuân theo: | Quy ước | Chi tiết | |---|---| | Đọc dữ liệu từ biến môi trường | SM_CHANNEL_TRAINING trỏ tới /opt/ml/input/data/training | | Ghi model ra SM_MODEL_DIR | /opt/ml/model — SageMaker tự đóng gói lên S3 | | Nhận siêu tham số qua tham số dòng lệnh | argparse |

parser.add_argument('--train', type=str, default=os.environ['SM_CHANNEL_TRAINING'])
parser.add_argument('--model-dir', type=str, default=os.environ['SM_MODEL_DIR'])

Và framework_version là bắt buộc — nó quyết định container nào được dùng. Đây chính là điểm mà phương án A bỏ sót.

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

  • A. Dùng script mode tự động chuyển script Python thành Estimator object mà KHÔNG khai phiên bản TensorFlow — đây là phương án gần nhất và sai ở đúng chỗ: framework_version là tham số bắt buộc để SageMaker biết chọn container nào. Không có nó thì không xác định được môi trường chạy. Và "tự động chuyển script thành Estimator" mô tả sai cơ chế — bạn tạo Estimator và trỏ nó tới script.
  • C. Tạo container Docker tuỳ chỉnh với TensorFlow, đẩy lên ECR, rồi dùng script mode chạy job — lẫn lộn hai cách tiếp cận: nếu tự dựng container thì đó là BYOC, không phải script mode. Và với TensorFlow tiêu chuẩn, tự dựng container là công sức thừa — container dựng sẵn đã có.
  • B. Đóng gói model TensorFlow thành tệp .tar.gz, tải lên S3, dùng script mode triển khai trực tiếp model để huấn luyện — lẫn lộn huấn luyện với triển khai: model.tar.gz là kết quả của huấn luyện, không phải đầu vào. Và "deploy the model for training" là mô tả tự mâu thuẫn.

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 vài thư viện thêm | | 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 trong script mode: | Biến | Trỏ tới | |---|---| | SM_CHANNEL_<TÊN> | thư mục chứa dữ liệu của channel đó | | SM_MODEL_DIR | nơi ghi model — SageMaker tự đóng gói lên S3 | | SM_OUTPUT_DATA_DIR | nơi ghi artifact phụ (biểu đồ, báo cáo) | | SM_HOSTS, SM_CURRENT_HOST | dùng cho huấn luyện phân tán |

Cấu trúc thư mục bên 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 | |---|---| | TensorFlow | sagemaker.tensorflow.TensorFlow | | PyTorch | sagemaker.pytorch.PyTorch | | Hugging Face | sagemaker.huggingface.HuggingFace | | Scikit-learn, XGBoost | SKLearn, XGBoost |

Và một chi tiết hữu ích: requirements.txt trong source_dir được cài tự động — nên bạn thêm được thư viện phụ mà không cần dựng container riêng. Đây thường là cách giải quyết đúng khi thiếu vài package, thay vì nhảy thẳng sang BYOC.

Câu 125 ML Solution Monitoring, Maintenance, and Security

You are a data scientist at a healthcare company that has deployed a machine learning model to predict patient readmission rates. The model plays a crucial role in optimizing patient care and managing hospital resources. After several months in production, the medical team has noticed that the model’s predictions seem less accurate than before, leading to concerns about data quality and model performance. To ensure that the model continues to deliver reliable predictions, you need to implement techniques to monitor both data quality and model performance continuously.

Which of the following approaches is the MOST EFFECTIVE for monitoring data quality and model performance in this scenario?

  1. A

    Schedule periodic retraining of the model on the latest data to ensure it remains accurate, without additional monitoring of data quality or performance metrics
  2. B

    Set up a dashboard that tracks model performance metrics, such as precision, recall, and AUC, and use version control to monitor changes in the model's code and training data over time
  3. C

    Perform manual checks on a sample of the input data each week to ensure data quality and manually track model performance metrics in a spreadsheet for analysis
  4. D

    Implement data validation rules to check for missing values, outliers, and distribution changes in the input data before feeding it to the model, and use model performance metrics such as accuracy and F1 score to monitor the model's output
Xem giải thích

Đáp án

D — Triển khai luật kiểm tra dữ liệu để phát hiện giá trị thiếu, ngoại lai và thay đổi phân bố trong dữ liệu đầu vào trước khi đưa vào model, và dùng các chỉ số hiệu năng như accuracy và F1 để giám sát đầu ra của model.

Vì sao đúng

Đề yêu cầu giám sát hai thứ liên tục: chất lượng dữ liệu và hiệu năng model. Đáp án D là phương án duy nhất làm cả hai: | Yêu cầu | Cơ chế | |---|---| | Giám sát chất lượng dữ liệu | luật kiểm tra: thiếu, ngoại lai, phân bố | | Giám sát hiệu năng model | accuracy, F1 trên đầu ra |

Vế kiểm tra dữ liệu là thứ bắt được nguyên nhân gốc:

Model kém đi có thể do:
  ① Dữ liệu đầu vào hỏng      → kiểm tra dữ liệu bắt được
  ② Phân bố đã dịch chuyển     → kiểm tra phân bố bắt được
  ③ Quan hệ đầu vào–nhãn đổi   → chỉ số hiệu năng bắt được

Chỉ giám sát hiệu năng thì bạn biết có vấn đề nhưng không biết vì sao. Ba loại kiểm tra dữ liệu trong đáp án tương ứng với ba nguyên nhân phổ biến nhất: | Kiểm tra | Bắt được | |---|---| | Giá trị thiếu | cột đột nhiên rỗng — thường là lỗi pipeline | | Ngoại lai | giá trị bất thường — sai đơn vị đo, lỗi nhập liệu | | Thay đổi phân bố | data drift — nhóm bệnh nhân đã khác |

Và SageMaker Model Monitor tự động hoá chính xác những kiểm tra này — baseline sinh ra constraints.json chứa đúng ba loại ràng buộc đó.

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

  • B. Dựng dashboard theo dõi chỉ số hiệu năng (precision, recall, AUC) và dùng version control theo dõi thay đổi mã và dữ liệu huấn luyện — đây là phương án gần nhất và cả hai đều là thực hành tốt, nhưng nó thiếu vế kiểm tra chất lượng dữ liệu ĐẦU VÀO. Version control theo dõi những gì bạn thay đổi; nó không phát hiện được dữ liệu production đang thay đổi.
  • A. Huấn luyện lại định kỳ trên dữ liệu mới nhất, không giám sát thêm chất lượng dữ liệu hay chỉ số hiệu năng — huấn luyện lại mù: bạn không biết có cần không, không biết có hiệu quả không, và nếu dữ liệu mới bị hỏng thì bạn huấn luyện model trên dữ liệu hỏng.
  • C. Kiểm tra THỦ CÔNG một mẫu dữ liệu mỗi tuần và theo dõi chỉ số trong bảng tính — quá chậm, không đủ độ phủ, và không nhất quán. Với hệ thống y tế chạy liên tục, một tuần là quá dài.

Ghi nhớ

Hai tầng giám sát cho model production — cần cả hai: | Tầng | Giám sát gì | Phát hiện | |---|---|---| | Đầu vào (data quality) | giá trị thiếu, kiểu, phân bố | nguyên nhân | | Đầu ra (model quality) | accuracy, F1, phân bố dự đoán | hậu quả |

Tầng đầu vào phát hiện sớm hơn — thường trước khi chất lượng model giảm đủ để nhận ra.

Ba loại ràng buộc mà Model Monitor sinh tự động:

{"name": "so_ngay_nam_vien",
 "inferred_type": "Integral",
 "completeness": 1.0,
 "num_constraints": {"is_non_negative": true}}
Ràng buộc Bắt được
completeness cột đột nhiên có null
inferred_type kiểu đổi (số thành chuỗi)
Thống kê phân bố thang đo hoặc trung bình lệch

Một khó khăn riêng của model quality monitoring trong y tế:

Nhãn thật đến rất muộn. Biết bệnh nhân có tái nhập viện hay không phải chờ 30 ngày.

Nên trong thực tế: | Chỉ số | Độ trễ | Vai trò | |---|---|---| | Data quality | tức thì | chỉ báo sớm | | Prediction drift | tức thì | chỉ báo sớm | | Model quality (accuracy, F1) | 30+ ngày | xác nhận |

Prediction drift đáng theo dõi riêng: nếu tỷ lệ bệnh nhân được dự đoán "nguy cơ cao" đột nhiên thay đổi mà không có lý do lâm sàng, đó là dấu hiệu sớm nhất.

Và ba việc nên tự động hoá: | Việc | Công cụ | |---|---| | Kiểm tra dữ liệu trước khi vào model | Model Monitor hoặc validation trong pipeline | | Cảnh báo khi vi phạm | EventBridge → SNS | | Ghi vết mọi vi phạm | constraint_violations.json trên S3 |

Với hệ thống y tế, việc thứ ba còn có giá trị tuân thủ: nó là bằng chứng rằng bạn đang giám sát chủ động, không phải chờ ai đó phàn nàn.

Câu 126 Data Preparation for Machine Learning (ML)

You are tasked with preparing a dataset for a machine learning model using SageMaker Data Wrangler. You need to perform a transformation that removes outliers from your dataset.

Which of the following actions in SageMaker Data Wrangler would you use to accomplish this task?

  1. A

    Format string
  2. B

    Filter
  3. C

    Impute
  4. D

    One-hot Encode
Xem giải thích

Đáp án

B — Filter (lọc).

Vì sao đúng

Loại bỏ ngoại lai về bản chất là giữ lại những dòng thoả điều kiện và bỏ đi những dòng không thoả — và đó chính là định nghĩa của thao tác lọc.

Trong Data Wrangler, thao tác này thực hiện bằng cách khai điều kiện:

Filter:  so_tien >= 0 AND so_tien <= 100000000
Filter:  tuoi > 0 AND tuoi < 120

Hoặc dùng transform chuyên cho ngoại lai với các phương pháp thống kê: | Phương pháp | Cách xác định ngoại lai | |---|---| | Standard deviation | ngoài khoảng ±k lần độ lệch chuẩn | | Quantile (IQR) | ngoài khoảng Q1 − 1,5·IQR đến Q3 + 1,5·IQR | | Min-max | ngoài khoảng bạn khai | | Robust Z-score | dùng trung vị — ít bị chính ngoại lai ảnh hưởng |

Phương pháp cuối đáng biết: Z-score thông thường dùng trung bình và độ lệch chuẩn, mà cả hai đều bị ngoại lai kéo lệch — nên với dữ liệu có nhiều ngoại lai, robust Z-score đáng tin hơn.

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

  • C. Impute (điền giá trị) — đây là phương án gần nhất về mặt "cùng nhóm xử lý dữ liệu bẩn", nhưng nó xử lý giá trị THIẾU, không xử lý ngoại lai: nó điền vào ô trống bằng trung bình, trung vị hoặc giá trị cố định. (Có một biến thể hợp lệ trong thực tế: thay ngoại lai bằng giá trị biên — gọi là winsorizing — nhưng đó không phải thao tác "Impute" trong Data Wrangler.)
  • A. Format string (định dạng chuỗi) — xử lý dữ liệu văn bản: viết hoa, cắt khoảng trắng, thay thế ký tự. Không liên quan tới ngoại lai số.
  • D. One-hot Encode — mã hoá biến phân loại thành cột nhị phân. Cũng không liên quan.

Ghi nhớ

Bốn nhóm transform của Data Wrangler cho dữ liệu bẩn: | Nhóm | Xử lý | |---|---| | Filter / Handle outliers | ngoại lai | | Handle missing | giá trị thiếu — impute hoặc drop | | Handle duplicates | dòng trùng lặp | | Format string | văn bản không nhất quán |

Ba cách xử lý ngoại lai — chọn theo bối cảnh: | Cách | Khi nào | |---|---| | Loại bỏ (filter) | ngoại lai là LỖI dữ liệu | | Giới hạn về biên (winsorize) | ngoại lai là giá trị thật nhưng cực đoan | | Giữ nguyên | ngoại lai chính là thứ cần phát hiện |

Dòng cuối rất quan trọng và hay bị bỏ qua: với bài toán phát hiện gian lận hoặc phát hiện bất thường, ngoại lai chính là tín hiệu — loại bỏ chúng là vứt bỏ đúng thứ model cần học.

Nguyên tắc: trước khi xoá một ngoại lai, hỏi nó là lỗi hay là hiện tượng thật.

Giá nhà 500 tỷ trong tập dữ liệu nhà phổ thông
    → có thể là lỗi nhập liệu (thừa số 0)
    → hoặc là một biệt thự thật

Giao dịch 2 tỷ lúc 3h sáng ở nước ngoài
    → có thể là gian lận — ĐỪNG XOÁ

Ba cách phát hiện ngoại lai: | Cách | Đặc điểm | |---|---| | Thống kê (IQR, Z-score) | đơn giản, một chiều | | Trực quan hoá (box plot, scatter) | thấy được mẫu | | Model (Isolation Forest, RCF) | đa chiều — bắt được tổ hợp bất thường |

Cách thứ ba mạnh nhất: một điểm dữ liệu có thể bình thường ở mọi chiều riêng lẻ nhưng bất thường ở tổ hợp — chỉ model đa chiều thấy được.

Và một lưu ý về thứ tự xử lý: loại ngoại lai TRƯỚC khi chuẩn hoá. Nếu chuẩn hoá trước, một ngoại lai cực đoan sẽ nén toàn bộ dữ liệu còn lại vào một khoảng rất hẹp — làm hỏng thang đo của mọi mẫu khác.

Câu 127 ML Model Development

A publishing company wants to automatically identify and extract meaningful, unique keywords from a large collection of documents using AWS services.

What solution should the ML engineer implement to achieve this goal with minimal operational overhead?

  1. A

    Leverage Amazon Rekognition to search and extract insights about the entities and Key phrases present in the documents
  2. B

    Leverage Amazon Textract to gather insights about the entities and Key phrases present in the documents
  3. C

    Leverage Amazon Kendra to search and extract meaningful, unique keywords present in the documents
  4. D

    Leverage Amazon Comprehend custom entity recognition and key phrase extraction to identify and extract relevant keywords
Xem giải thích

Đáp án

D — Dùng Amazon Comprehend custom entity recognition và key phrase extraction để nhận diện và trích xuất các từ khoá liên quan.

Vì sao đúng

Đề nêu hai yêu cầu, và Comprehend đáp ứng cả hai: | Yêu cầu | Comprehend | |---|---| | Tự động nhận diện và trích xuất từ khoá có ý nghĩa | key phrase extraction | | Ít công sức vận hành nhất | dịch vụ được quản lý, API sẵn sàng |

Hai khả năng trong đáp án bổ sung nhau: | Khả năng | Việc | |---|---| | Key phrase extraction | tự động tìm cụm danh từ quan trọng — KHÔNG cần huấn luyện | | Custom entity recognition | nhận diện loại thực thể RIÊNG của bạn — cần dữ liệu gán nhãn |

comprehend.detect_key_phrases(Text=noi_dung, LanguageCode='vi')
# → [{'Text': 'trí tuệ nhân tạo', 'Score': 0.99, 'BeginOffset': 12, ...}]

comprehend.detect_entities(
    Text=noi_dung, LanguageCode='vi',
    EndpointArn=arn_model_tuy_chinh)   # với custom entity

Vì sao cần cả hai cho một nhà xuất bản:

Key phrase extraction:  bắt cụm từ quan trọng CHUNG
                        → "biến đổi khí hậu", "chính sách tiền tệ"

Custom entity:          bắt loại thực thể RIÊNG của ngành xuất bản
                        → tên tác giả, tên tác phẩm, thể loại, nhà xuất bản

Và key phrase extraction không cần huấn luyện gì — gọi API là có kết quả ngay, đáp ứng yêu cầu "minimal operational overhead".

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

  • C. Dùng Amazon Kendra tìm kiếm và trích xuất từ khoá có ý nghĩa trong tài liệu — đây là phương án gần nhất và Kendra là dịch vụ NLP mạnh, nhưng nó là công cụ TÌM KIẾM doanh nghiệp: nó trả lời câu hỏi từ tài liệu, không trích xuất danh sách từ khoá. Và nó tốn kém hơn nhiều cho một tác vụ trích xuất đơn giản.
  • B. Dùng Amazon Textract thu thập thông tin về thực thể và cụm từ khoá — sai giai đoạn xử lý: Textract trích xuất VĂN BẢN từ tài liệu quét và ảnh (OCR, bảng, form). Nó cho bạn văn bản; phân tích ngữ nghĩa văn bản đó là việc của Comprehend. (Textract + Comprehend là chuỗi hợp lệ khi tài liệu là bản scan — nhưng Textract một mình không làm được việc đề hỏi.)
  • A. Dùng Amazon Rekognition tìm kiếm và trích xuất thông tin về thực thể và cụm từ khoá trong tài liệu — sai loại dữ liệu hoàn toàn: Rekognition là dịch vụ thị giác máy tính cho ảnh và video. Nó đọc được văn bản trong ảnh (DetectText), nhưng không phân tích ngữ nghĩa văn bản.

Ghi nhớ

Bảng phân vai các dịch vụ AI của AWS — nhóm hay nhầm: | Dịch vụ | Đầu vào | Việc | |---|---|---| | Comprehend | văn bản | NLP: thực thể, cụm từ khoá, cảm xúc, PII, phân loại | | Textract | tài liệu scan, ảnh | OCR: trích xuất văn bản, bảng, form | | Rekognition | ảnh, video | thị giác: vật thể, khuôn mặt, cảnh | | Kendra | tài liệu | TÌM KIẾM ngữ nghĩa, trả lời câu hỏi | | Translate | văn bản | dịch |

Chuỗi thường dùng: | Bài toán | Chuỗi | |---|---| | Tài liệu SỐ (PDF text, HTML) | Comprehend trực tiếp ← câu này | | Tài liệu SCAN | Textract → Comprehend | | Video có lời nói | Transcribe → Comprehend |

Sáu khả năng của Comprehend: | Khả năng | Cần huấn luyện? | |---|---| | Key phrase extraction | ❌ dùng ngay | | Entity recognition (dựng sẵn) | ❌ — người, địa điểm, tổ chức, ngày | | Sentiment | ❌ | | PII detection | ❌ | | Custom entity recognition | ✅ cần dữ liệu gán nhãn | | Custom classification | ✅ |

Bốn khả năng đầu dùng được ngay không cần chuẩn bị gì — đó là lý do Comprehend thắng ở tiêu chí "minimal operational overhead".

Ba lưu ý khi dùng custom entity recognition: | Lưu ý | Chi tiết | |---|---| | Cần tối thiểu 25 tài liệu mỗi loại thực thể | thực tế nên vài trăm | | Endpoint tính tiền theo THỜI GIAN chạy | hợp với lưu lượng liên tục, không hợp dùng thưa | | Có chế độ phân tích theo lô | rẻ hơn nhiều cho xử lý một lần |

Dòng cuối quan trọng với bài toán trong đề: nhà xuất bản xử lý một bộ sưu tập tài liệu lớn — đây là công việc theo lô, nên dùng StartEntitiesDetectionJob thay vì tạo endpoint thường trực.

Câu 128 Data Preparation for Machine Learning (ML)

A fashion retailer wants to develop a machine learning model to predict the popularity of clothing designs. The dataset includes categorical data about the primary fabric type of each design, such as "Cotton," "Polyester," and "Silk." An ML engineer is preparing the data for a neural network model and needs to preprocess the fabric type information appropriately.

Which technique should the ML engineer use for feature engineering?

  1. A

    Perform min-max normalization on the categorical fabric type data to scale the values between 0 and 1 for compatibility with the model
  2. B

    Apply one-hot encoding to convert the categorical fabric type data into binary vectors that the neural network can process
  3. C

    Use PCA (Principal Component Analysis) to reduce the dimensionality of the categorical fabric type data before feeding it into the neural network
  4. D

    Use label encoding to assign unique integer values to each fabric type and input these integers directly into the neural network
Xem giải thích

Đáp án

B — Áp dụng one-hot encoding chuyển dữ liệu loại vải phân loại thành vector nhị phân mà mạng nơ-ron xử lý được.

Vì sao đúng

Đề nêu hai yếu tố quyết định: | Yếu tố | Hệ quả | |---|---| | Dữ liệu PHÂN LOẠI: "Cotton", "Polyester", "Silk" | cần chuyển thành số | | Model là MẠNG NƠ-RON | nhạy với giá trị số và quan hệ giữa chúng |

One-hot encoding chuyển mỗi giá trị thành một cột nhị phân:

loai_vai      →   vai_Cotton  vai_Polyester  vai_Silk
"Cotton"              1             0            0
"Polyester"           0             1            0
"Silk"                0             0            1

Vì sao KHÔNG dùng label encoding (gán 1, 2, 3) — đây là điểm mấu chốt phân biệt với phương án D:

Label encoding:  Cotton=1, Polyester=2, Silk=3

Mạng nơ-ron sẽ HIỂU rằng:
  Silk > Polyester > Cotton         ← thứ tự KHÔNG TỒN TẠI
  Silk − Cotton = 2                 ← phép trừ VÔ NGHĨA
  Polyester là "trung bình" của Cotton và Silk   ← sai hoàn toàn

Loại vải không có thứ tự tự nhiên — lụa không "lớn hơn" cotton theo bất kỳ nghĩa nào. Áp một thứ tự giả lên nó là đưa thông tin sai vào model.

Và mạng nơ-ron đặc biệt nhạy với điều này vì nó thực hiện phép nhân và cộng trên đầu vào — nên quan hệ số học giả sẽ ảnh hưởng trực tiếp tới trọng số học được.

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

  • D. Dùng label encoding gán số nguyên duy nhất cho mỗi loại vải và đưa thẳng vào mạng nơ-ron — đây là phương án gần nhất và là bẫy chính của câu hỏi: nó tạo ra thứ tự giả như phân tích trên. (Label encoding hợp lệ với model cây — chúng chia theo ngưỡng nên không giả định quan hệ số học. Nhưng với mạng nơ-ron thì không.)
  • A. Min-max normalization trên dữ liệu loại vải phân loại để đưa giá trị về khoảng 0–1 — không áp dụng được cho dữ liệu phân loại: chuẩn hoá làm việc với giá trị số liên tục. "Cotton" không có giá trị số để chuẩn hoá.
  • C. Dùng PCA giảm chiều dữ liệu loại vải phân loại trước khi đưa vào mạng — sai thứ tự và sai công cụ: PCA làm việc với dữ liệu số, nên bạn vẫn phải mã hoá trước. Và với chỉ ba loại vải, không có gì để giảm chiều.

Ghi nhớ

Bốn cách mã hoá biến phân loại — chọn theo bản chất dữ liệu và loại model: | Cách | Dùng khi | Model phù hợp | |---|---|---| | One-hot | KHÔNG có thứ tự, ít giá trị | mọi model, đặc biệt mạng nơ-ron | | Ordinal | CÓ thứ tự tự nhiên | mọi model | | Label encoding | không thứ tự | CHỈ model cây | | Target encoding | rất nhiều giá trị | model cây, cẩn thận rò rỉ | | Embedding | rất nhiều giá trị, mạng nơ-ron | mạng nơ-ron |

Ordinal encoding hợp lệ khi có thứ tự thật:

kich_co:  "S"=1, "M"=2, "L"=3, "XL"=4    ← thứ tự CÓ NGHĨA

Với cột như vậy, ordinal tốt hơn one-hot vì nó giữ được thông tin thứ tự.

Bẫy lớn nhất của one-hot: bùng nổ số chiều. Một cột "mã sản phẩm" với 10 nghìn giá trị thành 10 nghìn cột. Ba cách xử lý: | Cách | Chi tiết | |---|---| | Gộp giá trị hiếm thành "Khác" | giảm số cột đáng kể | | Target encoding | thay bằng giá trị trung bình của nhãn | | Embedding layer | mạng nơ-ron học vector dày cho mỗi giá trị |

Embedding layer là cách chuẩn cho mạng nơ-ron với biến phân loại nhiều giá trị — nó học biểu diễn có ý nghĩa thay vì vector thưa khổng lồ.

Và một chi tiết kỹ thuật: drop one column (bỏ một cột trong one-hot) tránh được đa cộng tuyến hoàn hảo — quan trọng với hồi quy tuyến tính, không quan trọng với mạng nơ-ron hay model cây. Với ba loại vải, hai cột là đủ để biểu diễn cả ba trạng thái.

Câu 129 Chọn nhiều đáp án Data Preparation for Machine Learning (ML)

Which of the following is correct regarding the training set, validation set, and test set used in the context of machine learning? (Select two)

  1. A

    Test sets are optional
  2. B

    Validation set is used to determine how well the model generalizes
  3. C

    Test set is used to determine how well the model generalizes
  4. D

    Validation sets are optional
  5. E

    Test set is used for hyperparameter tuning
Xem giải thích

Đáp án

C và D.

  • C — Test set dùng để đánh giá model tổng quát hoá tốt tới đâu
  • D — Validation set là tuỳ chọn

Vì sao đúng

C — test set là thước đo tổng quát hoá:

Training set:   model HỌC từ đây          → không đo được tổng quát hoá
Validation set: model được TINH CHỈNH theo → đã bị "nhiễm", không khách quan
Test set:       model CHƯA BAO GIỜ thấy   → ước lượng KHÁCH QUAN

Điểm mấu chốt: mỗi lần bạn nhìn vào một tập để ra quyết định, tập đó mất tính khách quan. Vì bạn chọn siêu tham số dựa trên validation set, hiệu năng trên nó lạc quan hơn thực tế. Chỉ test set — dùng đúng một lần ở cuối — cho ước lượng đúng.

D — validation set là tuỳ chọn, và có ba lý do: | Lý do | Chi tiết | |---|---| | Không tinh chỉnh gì thì không cần | dùng siêu tham số mặc định | | Cross-validation thay thế được | chia training set thành k phần luân phiên | | Dữ liệu quá ít | dành hết cho training và test |

Cross-validation là lý do phổ biến nhất:

Không có validation set riêng:
  Training set → chia 5 fold
  Mỗi vòng: 4 fold huấn luyện, 1 fold kiểm chứng
  → tận dụng được toàn bộ dữ liệu huấn luyện
  → Test set vẫn giữ riêng, không đụng tới

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

  • B. Validation set dùng để đánh giá model tổng quát hoá tốt tới đâu — đây là phương án gần nhất và gần đúng nhưng không chính xác: validation set được dùng để CHỌN model và siêu tham số, nên hiệu năng trên nó thiên lệch lạc quan. Nó là công cụ so sánh giữa các lựa chọn, không phải thước đo tổng quát hoá cuối cùng.
  • **A. Test set là tuỳ chọn — ngược lại: test set là tập không nên bỏ. Không có nó, bạn không có ước lượng khách quan nào về hiệu năng thật.
  • **E. Test set dùng để tinh chỉnh siêu tham số — sai nghiêm trọng và là lỗi phổ biến trong thực tế: dùng test set để tinh chỉnh nghĩa là model gián tiếp học từ nó, và con số cuối cùng không còn ý nghĩa.

Ghi nhớ

Vai trò ba tập — bảng nền tảng: | Tập | Việc | Nhìn bao nhiêu lần | |---|---|---| | Training | học tham số | mọi epoch | | Validation | chọn siêu tham số, early stopping, so sánh model | nhiều lần | | Test | báo cáo hiệu năng cuối | ĐÚNG MỘT LẦN |

Nguyên tắc vàng:

Mỗi lần bạn dùng một tập để ra quyết định, tập đó không còn "chưa thấy" nữa.

Điều này giải thích tại sao:

  • Validation set thiên lệch lạc quan sau khi bạn chọn model tốt nhất trên nó
  • Test set phải giữ nguyên cho tới lần đánh giá cuối
  • Nếu bạn xem test set rồi quay lại chỉnh model, test set đã trở thành validation set

Ba tình huống và cách chia phù hợp: | Tình huống | Cách chia | |---|---| | Dữ liệu nhiều (hàng triệu) | 98/1/1 — 1% vẫn là hàng chục nghìn mẫu | | Dữ liệu vừa | 70/15/15 hoặc 80/10/10 | | Dữ liệu ít | cross-validation + test set riêng |

Ba nguyên tắc chia dữ liệu, theo mức quan trọng: | Nguyên tắc | Chi tiết | |---|---| | Phân tầng khi mất cân bằng | giữ tỷ lệ lớp ở mọi tập | | Theo THỜI GIAN với chuỗi thời gian | không bao giờ chia ngẫu nhiên | | Theo NHÓM khi dữ liệu liên quan | mọi bản ghi của cùng một thực thể phải cùng một tập |

Và một biến thể đáng biết cho môi trường production: holdout set thứ hai — một tập nữa không ai được xem cho tới khi model chuẩn bị phát hành. Với nhiều vòng lặp phát triển, test set ban đầu dần bị nhiễm (vì bạn đã xem nó nhiều lần qua các phiên bản), và tập thứ hai này cho ước lượng trung thực cuối cùng.

Câu 130 ML Solution Monitoring, Maintenance, and Security

Which of the following is correct regarding the techniques used to improve the performance of a Foundation Model (FM)?

  1. A

    Both Fine-tuning and Retrieval-augmented generation (RAG) change the weights of the FM
  2. B

    Neither Fine-tuning nor Retrieval-augmented generation (RAG) changes the weights of the FM
  3. C

    Fine-tuning does not change the weights of the FM whereas Retrieval-augmented generation (RAG) changes the weights of the FM
  4. D

    Fine-tuning changes the weights of the FM whereas Retrieval-augmented generation (RAG) does not change the weights of the FM
Xem giải thích

Đáp án

D — Fine-tuning THAY ĐỔI trọng số của Foundation Model, trong khi RAG KHÔNG thay đổi trọng số.

Vì sao đúng

Đây là phân biệt nền tảng giữa hai kỹ thuật tuỳ biến model, và chúng hoạt động ở hai tầng hoàn toàn khác nhau: | | Fine-tuning | RAG | |---|---|---| | Thay đổi trọng số | ✅ CÓ | ❌ KHÔNG | | Cách hoạt động | huấn luyện tiếp trên dữ liệu của bạn | thêm ngữ cảnh vào prompt | | Giải quyết | học HÀNH VI, định dạng, giọng điệu | cung cấp KIẾN THỨC |

Fine-tuning — model học và trọng số đổi:

Model gốc (trọng số W)
    ↓ huấn luyện tiếp trên dữ liệu của bạn
Model mới (trọng số W')  ← ĐÃ KHÁC

RAG — model không đổi, chỉ prompt đổi:

Câu hỏi
    ↓ tìm tài liệu liên quan trong vector store
Prompt = [tài liệu tìm được] + [câu hỏi]
    ↓ gửi vào model — TRỌNG SỐ KHÔNG ĐỔI
Câu trả lời có căn cứ

Hệ quả thực tế của khác biệt này rất lớn: | Khía cạnh | Fine-tuning | RAG | |---|---|---| | Cập nhật kiến thức | phải huấn luyện lại | cập nhật index — vài phút | | Chi phí | cao (GPU, thời gian) | thấp | | Truy vết nguồn | ❌ không biết thông tin từ đâu | ✅ có citation | | Gỡ bỏ thông tin | rất khó — phải huấn luyện lại | xoá khỏi index là xong |

Dòng cuối đáng chú ý về mặt tuân thủ: nếu một tài liệu phải gỡ bỏ (yêu cầu pháp lý, thông tin sai), RAG gỡ được ngay, còn fine-tuning thì thông tin đã nằm trong trọng số.

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

  • **A. Cả hai đều thay đổi trọng số — sai với RAG: nó chỉ thêm ngữ cảnh vào prompt, model hoàn toàn không đổi.
  • **B. Không cái nào thay đổi trọng số — sai với fine-tuning: đó chính là định nghĩa của nó.
  • **C. Fine-tuning KHÔNG đổi trọng số, RAG CÓ — đảo ngược hoàn toàn hai định nghĩa.

Ghi nhớ

Bậc thang tuỳ biến model — chọn theo bản chất vấn đề: | Mức | Kỹ thuật | Đổi trọng số? | Chi phí | Giải quyết | |---|---|---|---|---| | 1 | Prompt engineering | ❌ | rất thấp | hướng dẫn cách trả lời | | 2 | RAG | ❌ | thấp | thiếu KIẾN THỨC riêng | | 3 | Fine-tuning (LoRA) | ✅ | vừa | cần học HÀNH VI, định dạng | | 4 | Full fine-tuning | ✅ | cao | thay đổi sâu hơn | | 5 | Continued pre-training | ✅ | rất cao | ngôn ngữ chuyên ngành khác biệt |

Nguyên tắc: luôn leo thang từ mức 1. Rất nhiều vấn đề tưởng cần fine-tune thực ra giải được bằng prompt tốt hơn hoặc RAG.

Cách phân biệt mức 2 và mức 3 — câu hỏi quyết định: | Triệu chứng | Giải pháp | |---|---| | "Model không biết thông tin của công ty tôi" | RAG | | "Model biết nhưng trả lời sai định dạng, sai giọng điệu" | fine-tuning | | Cả hai | kết hợp: fine-tune cho hành vi, RAG cho kiến thức |

Dòng cuối là mẫu phổ biến trong hệ thống thật — hai kỹ thuật không loại trừ nhau.

LoRA (Low-Rank Adaptation) đáng biết như biến thể hiệu quả của fine-tuning: | Đặc điểm | Chi tiết | |---|---| | Chỉ huấn luyện ~0,1–1% tham số | adapter nhỏ, không đụng trọng số gốc | | Artifact vài chục MB | thay vì vài GB | | Nhiều adapter dùng chung một base model | tiết kiệm hạ tầng |

Về mặt kỹ thuật, LoRA cũng thay đổi hành vi model bằng cách cộng adapter vào trọng số gốc — nên nó vẫn thuộc nhóm "thay đổi trọng số" trong câu hỏi này.

Và ba lợi ích của RAG mà fine-tuning không có: | Lợi ích | Chi tiết | |---|---| | Truy vết nguồn | người đọc kiểm chứng được | | Cập nhật tức thì | thêm tài liệu là có ngay | | Kiểm soát truy cập | lọc theo quyền của người dùng lúc truy xuất |

Dòng cuối quan trọng cho ứng dụng doanh nghiệp: với RAG, người dùng khác nhau thấy tài liệu khác nhau; với fine-tuning, kiến thức nằm trong trọng số và mọi người đều truy cập được như nhau.