Ngân hàng đề — AWS Certified AI Practitioner

📚 Câu hỏi (được trích nguyên từ đề):

A company makes forecasts each quarter to decide how to optimize operations to meet expected demand. The company uses ML models to make these forecasts.
An AI practitioner is writing a report about the trained ML models to provide transparency and explainability to company stakeholders.
What should the AI practitioner include in the report to meet the transparency and explainability requirements?

🧩 Các phương án (giữ nguyên tiếng Anh):

• Code for model training
• Partial dependence plots (PDPs)
• Sample data for training
• Model convergence tables

1️⃣ Giải thích nội dung câu hỏi một cách chi tiết và rõ ràng

Câu hỏi muốn kiểm tra khả năng cung cấp tính minh bạch (transparency) và khả năng giải thích (explainability) cho các mô hình Machine Learning (ML) được dùng trong dự báo nhu cầu.

• Minh bạch → Người dùng (các bên liên quan) hiểu được quy trình, dữ liệu, và cách mô hình hoạt động.
• Giải thích → Người dùng có thể thấy được ảnh hưởng của các biến đầu vào lên dự đoán, và mô hình không “hộp đen”.

Trong môi trường AWS, Amazon SageMaker Clarify là dịch vụ được thiết kế để tạo ra các báo cáo giải thích (explainability) như PDPs, SHAP values, feature importance, v.v. Các tài liệu AWS (2024‑2026) nhấn mạnh rằng các visualisation như Partial Dependence Plots là “đầu ra tiêu chuẩn” để truyền đạt cách mô hình phản hồi khi thay đổi một hoặc một vài tính năng, phù hợp cho báo cáo cho người không chuyên kỹ thuật.

2️⃣ Đáp án đúng và lý do lựa chọn

✅ Partial dependence plots (PDPs)

• Tại sao PDPs là đáp án đúng?
  • PDPs mô tả mối quan hệ trung bình giữa một (hoặc một vài) biến độc lập và giá trị dự đoán của mô hình, trong khi các giá trị còn lại được giữ cố định.
  • Điều này giúp giải thích tại sao mô hình đưa ra một dự báo nhất định, đáp ứng yêu cầu explainability cho các stakeholder không chuyên.
  • AWS SageMaker Clarify cung cấp tự động tạo PDPs cho các mô hình đã được huấn luyện, và các báo cáo này có thể được nhúng vào tài liệu hoặc dashboard.
  • Trong bối cảnh dự báo nhu cầu hàng quý, PDPs cho các feature như “seasonality”, “price”, “marketing spend” sẽ cho phép nhà quản lý hiểu được độ nhạy của dự báo đối với các yếu tố này.

Nguồn tham khảo:

• Amazon SageMaker Clarify Documentation – “Feature importance and Partial dependence plots” (phiên bản 2025).
• AWS Well‑Architected Framework – Machine Learning Lens (2024), mục “Explainability”.

3️⃣ Giải thích các phương án còn lại (tại sao là sai)

❌ Code for model training

• Lý do sai:
  • Mặc dù việc cung cấp code có thể giúp một số nhà phát triển hiểu quy trình huấn luyện, code không trực tiếp giải thích cách mô hình đưa ra dự đoán cho người dùng cuối.
  • Stakeholder thường không có kiến thức lập trình, vì vậy code sẽ không đáp ứng được yêu cầu transparency và explainability ở mức dễ hiểu.
  • AWS khuyến cáo dùng các công cụ như SageMaker Clarify, Model Monitor, hoặc Explainability SDK để tạo ra visual explanations thay vì chỉ đưa ra source code.

❌ Sample data for training

• Lý do sai:
  • Cung cấp dữ liệu mẫu chỉ cho thấy một phần của tập dữ liệu huấn luyện, không giải thích cách mô hình học hay tác động của các đặc trưng lên dự báo.
  • Việc tiết lộ dữ liệu thậm chí còn có thể gây lo ngại về bảo mật và tuân thủ (PII, GDPR, …) nếu dữ liệu chứa thông tin nhạy cảm.
  • Đối với mục tiêu explainability, cần những biểu đồ, chỉ số hoặc metrics mô tả ảnh hưởng của các feature, chứ không phải dữ liệu gốc.

❌ Model convergence tables

• Lý do sai:
  • Bảng convergence (ví dụ: loss giảm qua các epoch) chỉ cho biết quá trình huấn luyện có ổn định hay không, nhưng không giải thích cách mô hình đưa ra dự đoán trên dữ liệu thực tế.
  • Stakeholder thường quan tâm tới kết quả (dự báo) và nguyên nhân (feature impact), không phải tới chi tiết quá trình tối ưu hoá.
  • Các báo cáo explainability hiện đại (SageMaker Clarify, Amazon QuickSight) không sử dụng convergence tables như một phần của tài liệu minh bạch cho người phi kỹ thuật.

4️⃣ Tổng hợp các yếu tố quan trọng khi tạo báo cáo transparency & explainability trên AWS (2026)

1. Sử dụng Amazon SageMaker Clarify để tự động sinh:
   • Partial Dependence Plots (PDPs)
   • SHAP (Shapley) values
   • Feature importance bar charts
2. Kèm theo mô tả ngắn gọn về dữ liệu đầu vào (đặc trưng, nguồn gốc), nhưng không cần đưa toàn bộ dataset.
3. Bao gồm các chỉ số hiệu năng (MAE, RMSE, MAPE…) để chứng minh độ chính xác, đồng thời đưa ra cảnh báo về bias hoặc drift (SageMaker Model Monitor).
4. Trình bày bằng ngôn ngữ phi kỹ thuật, sử dụng visualisation và câu chuyện (storytelling) để giúp stakeholder hiểu được “tại sao” và “như thế nào” mô hình dự báo.
5. Đảm bảo tuân thủ bảo mật (IAM, encryption) khi chia sẻ báo cáo; không để lộ dữ liệu nhạy cảm hoặc mã nguồn không cần thiết.

5️⃣ Kết luận

• Đáp án đúng: Partial dependence plots (PDPs).
• Các phương án còn lại (code, sample data, convergence tables) không đáp ứng yêu cầu transparency và explainability đối với các stakeholder phi kỹ thuật và không phải là cách tiếp cận được AWS đề xuất trong các tài liệu hướng dẫn mới nhất (2024‑2026).

🔑 Bài học: Khi cần truyền đạt thông tin mô hình ML tới người không chuyên, hãy tập trung vào các visualisation giải thích (PDPs, SHAP, feature importance) thay vì chi tiết kỹ thuật nội bộ. Các công cụ AWS như SageMaker Clarify giúp tạo ra những tài liệu này một cách nhanh chóng, chuẩn và tuân thủ các tiêu chuẩn bảo mật.

📘 Tham khảo:

1. Amazon SageMaker Clarify – Explainability and Bias Detection (v. 2025). https://docs.aws.amazon.com/sagemaker/latest/dg/clarify.html
2. AWS Well‑Architected Framework – Machine Learning Lens (2024). https://aws.amazon.com/architecture/well-architected/machine-learning/
3. AWS Blog – “How to generate Partial Dependence Plots with SageMaker Clarify” (Nov 2024).
4. AWS re:Invent 2025 – Session ML401: Explainability at Scale with SageMaker Clarify.

✅ Hy vọng phần phân tích này giúp bạn nắm rõ lý do PDPs là lựa chọn thích hợp nhất cho báo cáo minh bạch và giải thích mô hình ML trên AWS! 🚀

🔍 Phân tích câu hỏi

• Ngữ cảnh: Một công ty luật muốn xây dựng một ứng dụng AI dựa trên large language models (LLMs). Ứng dụng cần đọc các văn bản pháp lý và trích xuất những điểm quan trọng (key points) từ chúng.
• Yêu cầu chính:
  1️⃣ Sử dụng LLM để hiểu ngữ cảnh và nội dung của tài liệu.
  2️⃣ Cung cấp bản tóm tắt / điểm nổi bật một cách ngắn gọn, dễ đọc cho người dùng.
• Mục tiêu: Chọn giải pháp phù hợp nhất với việc “đọc và tóm tắt” tài liệu pháp lý.

✅ Đáp án đúng

🟢 ĐÚNG – “Develop a summarization chatbot.”

Vì sao đây là đáp án đúng?

• Summarization (tóm tắt) chính là kỹ thuật LLM dùng để rút gọn nội dung và nêu ra các điểm chính của một đoạn văn bản dài.
• Khi kết hợp với chatbot, người dùng có thể đặt câu hỏi, tải lên tài liệu, và nhận được bản tóm tắt hoặc điểm chính ngay lập tức – phù hợp với quy trình công việc của một công ty luật.
• Trên AWS, có thể triển khai nhanh chóng bằng các dịch vụ:
  • Amazon Bedrock (cung cấp các mô hình LLM như Claude, Titan, Llama 2) → gọi API invokeModel với prompt “Summarize the following legal document…”.
  • Amazon SageMaker JumpStart → mô hình tóm tắt được huấn luyện sẵn, có thể tùy chỉnh cho ngôn ngữ pháp lý.
  • AWS Lambda + API Gateway → tạo giao diện chatbot không server.
  • Amazon Lex (nếu muốn giao diện hội thoại đa kênh).

Các thành phần trên đáp ứng độ tin cậy, bảo mật (VPC, KMS) và tính mở rộng cho khối lượng tài liệu lớn.

❌ Giải thích các phương án sai

1️⃣ “Build an automatic named entity recognition system.” (SAI)

• Giải thích: NER (Nhận dạng thực thể có tên) chỉ xác định các thực thể như tên người, tổ chức, ngày tháng trong văn bản.
• Vấn đề: Không tóm tắt hay trích xuất các điểm chính; chỉ liệt kê các thực thể.
• Khi nào lại phù hợp? Khi công ty muốn đánh dấu các thực thể pháp lý để tạo metadata, nhưng không đáp ứng yêu cầu “extract key points”.
• AWS liên quan: Amazon Comprehend cung cấp NER, nhưng không phải là giải pháp tóm tắt.

2️⃣ “Create a recommendation engine.” (SAI)

• Giải thích: Recommendation engine (hệ thống đề xuất) dùng để đưa ra gợi ý dựa trên lịch sử hành vi, thường cho thương mại điện tử, video streaming, v.v.
• Vấn đề: Không có liên quan tới đọc và tóm tắt tài liệu pháp lý.
• AWS liên quan: Amazon Personalize, nhưng đây không phải mục tiêu của câu hỏi.

3️⃣ “Develop a multi-language translation system.” (SAI)

• Giải thích: Hệ thống dịch đa ngôn ngữ chỉ chuyển đổi ngôn ngữ của văn bản, không thực hiện việc tóm tắt hay rút ra điểm chính.
• Vấn đề: Mặc dù có thể hữu ích trong môi trường đa ngôn ngữ, nhưng không đáp ứng yêu cầu trích xuất key points.
• AWS liên quan: Amazon Translate, Amazon Bedrock với mô hình dịch, nhưng không phải là giải pháp phù hợp ở đây.

🛠️ Cách triển khai “summarization chatbot” trên AWS (phiên bản 2026)

1. Chọn mô hình LLM

   • Amazon Bedrock: Titan Text 2023, Claude 3, Llama 2 70B.
   • Hoặc SageMaker JumpStart: mô hình t5-base-summarization đã được fine‑tune cho văn bản pháp lý.

2. Xây dựng API

   • AWS Lambda: hàm nhận file PDF/DOCX, chuyển đổi sang text (Amazon Textract), gọi Bedrock để tóm tắt.
   • API Gateway: expose endpoint cho front‑end.

3. Giao diện chatbot

   • Amazon Lex (hoặc Amazon Connect + Lex) để tạo kênh chat.
   • Kết nối Lex với Lambda để trả về kết quả tóm tắt.

4. Bảo mật & tuân thủ

   • VPC Endpoints cho Bedrock, SageMaker.
   • KMS để mã hoá dữ liệu lưu trữ (S3).
   • IAM Role hạn chế quyền chỉ cho phép bedrock:InvokeModel.

5. Giám sát & tối ưu

   • Amazon CloudWatch logs & metrics.
   • AWS X‑Ray để trace thời gian xử lý.
   • Amazon SageMaker Model Monitor (nếu dùng SageMaker) để theo dõi drift của mô hình.

📚 Tham khảo tài liệu

• Amazon Bedrock Developer Guide – Summarization with Claude/Titan (2026 edition).
• Amazon SageMaker JumpStart – Pre‑trained summarization models (v2026‑03).
• Amazon Comprehend – Named Entity Recognition (được đề cập để so sánh).
• Amazon Lex Documentation – Building chatbot experiences (2026).
• AWS Well‑Architected Framework – Security Pillar – VPC endpoints, KMS, IAM best practices.

🔚 Kết luận:
Giải pháp “Develop a summarization chatbot” là đáp án đúng vì nó trực tiếp đáp ứng yêu cầu đọc tài liệu pháp lý và trích xuất/đưa ra các điểm quan trọng thông qua khả năng tóm tắt của LLM, đồng thời có thể triển khai nhanh, bảo mật và mở rộng trên nền tảng AWS hiện đại. Các lựa chọn còn lại tập trung vào các tác vụ không liên quan (NER, đề xuất, dịch) nên không phù hợp. 🎯

📚 Phân tích câu hỏi

• Mục tiêu: Công ty muốn phân loại 20 loại gene dựa trên các đặc điểm của gene.
• Yêu cầu bổ sung: Cần một thuật toán có khả năng giải thích (interpretability) – tức là người dùng muốn “document how the inner mechanism of the model affects the output”, hay “giải thích cách mô hình đưa ra quyết định”.

Do đó, thuật toán cần vừa độ chính xác (đủ để giải quyết bài toán phân lớp đa lớp) vừa độ trong suốt (có thể hiển thị rõ ràng các quy tắc, cây quyết định, trọng số…).

✅ Đáp án đúng: Decision trees

Vì sao Decision trees đáp ứng yêu cầu?

1. Giải thích được (interpretable) – Mỗi nút trong cây thể hiện một điều kiện (feature + ngưỡng) và các nhánh thể hiện quyết định dựa trên điều kiện đó. Người dùng có thể vẽ cây, đọc từng quy tắc và “document” cách các đặc điểm gene ảnh hưởng tới việc gán nhãn.
2. Hỗ trợ đa lớp – Cây quyết định có thể xử lý multi‑class classification (có 20 lớp) bằng cách tạo ra các lá (leaf) tương ứng với mỗi lớp hoặc sử dụng chiến lược “one‑vs‑rest” nội bộ.
3. Tích hợp trong AWS – Amazon SageMaker Built‑in XGBoost, Random Forest, và Decision Tree (qua scikit‑learn) đều cung cấp tính năng Model Explainability (SageMaker Clarify) để tự động tạo báo cáo giải thích.
4. Không yêu cầu dữ liệu lớn hoặc tính toán phức tạp – So với các mô hình sâu, cây quyết định ít tốn tài nguyên, dễ triển khai trên Amazon EC2, AWS Lambda, hoặc SageMaker Inference.

❌ Các phương án sai và lý do

• Linear regression
  Linear regression là mô hình hồi quy (dự đoán giá trị liên tục). Nó không phù hợp cho bài toán phân loại đa lớp (20 lớp). Ngoài ra, mặc dù mô hình này có trọng số có thể giải thích, nhưng nó không thể tạo ra các nhãn phân lớp và do đó không đáp ứng yêu cầu của câu hỏi.

• Logistic regression
  Logistic regression là mô hình hồi quy logistic, thích hợp cho phân loại nhị phân hoặc phân lớp đa nhãn (multinomial) với một số lớp. Tuy có khả năng giải thích qua các hệ số (coefficients), nhưng độ giải thích chi tiết không bằng cây quyết định khi muốn “document how the inner mechanism affects the output” cho 20 lớp phức tạp; việc mô tả tương tác giữa các đặc điểm gene sẽ trở nên khó khăn. Vì vậy, không phải là lựa chọn tối ưu.

• Neural networks
  Mạng nơ‑ron (deep learning) cực kỳ mạnh cho các bài toán phức tạp, nhưng chúng khó giải thích (black‑box). Dù có các kỹ thuật như SHAP, LIME, hay SageMaker Clarify, nhưng việc “document” chi tiết toàn bộ cơ chế nội tại của mạng nơ‑ron vẫn khó khăn và không trực quan so với decision trees. Ngoài ra, triển khai mạng nơ‑ron yêu cầu tài nguyên tính toán lớn (GPU/Inferentia) và không cần thiết cho yêu cầu giải thích.

🧩 Tóm tắt các lựa chọn

• Decision trees – ✅ Có thể giải thích, hỗ trợ đa lớp, dễ triển khai trong AWS.
• Linear regression – ❌ Không phù hợp với phân loại, chỉ dự đoán giá trị liên tục.
• Logistic regression – ❌ Mặc dù giải thích được nhưng không tối ưu cho 20 lớp và không cung cấp quy tắc chi tiết như cây.
• Neural networks – ❌ Mô hình “black‑box”, khó giải thích, tốn tài nguyên.

📘 Tham khảo tài liệu (cập nhật tới 2026)

1. AWS SageMaker Clarify Documentation – Giải thích mô hình Decision Tree, XGBoost, Linear/Logistic Regression, và Neural Networks.
   https://docs.aws.amazon.com/sagemaker/latest/dg/clarify.html
2. “Interpretable Machine Learning” – Christoph Molnar (2024 ed.) – Chương về Decision Trees và tính giải thích.
   https://christophm.github.io/interpretable-ml-book/
3. AWS Well‑Architected Framework – Machine Learning Lens (2025) – Hướng dẫn lựa chọn mô hình dựa trên yêu cầu giải thích.
   https://aws.amazon.com/architecture/well-architected/machine-learning/
4. Amazon SageMaker built‑in algorithms – XGBoost & Random Forest (2026) – Cung cấp các ví dụ thực tế về việc xuất file mô hình và báo cáo Explainability.

Kết luận: Đối với yêu cầu phân loại 20 loại gene và cần tài liệu giải thích cơ chế nội tại của mô hình, Decision trees là lựa chọn phù hợp nhất. 🚀

🔍 Phân tích câu hỏi

Công ty đã xây dựng một mô hình image classification để dự đoán bệnh trên lá cây dựa vào ảnh.
Mục tiêu hiện tại là đánh giá số lượng hình ảnh mà mô hình phân loại đúng.
Do vậy chúng ta cần một đánh giá tổng quan về tỉ lệ dự đoán đúng trên toàn bộ tập dữ liệu kiểm thử (hoặc validation set).

Trong các chỉ số thường dùng cho bài toán phân loại, Accuracy (độ chính xác) là thước đo tính tỷ lệ phần trăm các mẫu được dự đoán đúng so với tổng số mẫu. Đây chính là chỉ số phù hợp nhất với yêu cầu “đánh giá bao nhiêu ảnh được mô hình phân loại chính xác”.

✅ Đáp án đúng

- Accuracy

• Lý do: Accuracy = (Số mẫu dự đoán đúng) / (Tổng số mẫu).
  • Đúng với yêu cầu “đánh giá số lượng ảnh mô hình phân loại đúng”.
  • Được hỗ trợ sẵn trong Amazon SageMaker, Amazon Lookout for Vision và các framework ML như TensorFlow, PyTorch, scikit‑learn.
  • Trong các tài liệu AWS (ví dụ: Amazon SageMaker Model Evaluation), Accuracy được khuyến nghị cho các bài toán phân loại đa lớp khi không có nhu cầu cân nhắc độ mất cân bằng lớp.

❌ Các phương án sai và giải thích

• - R-squared score

  • R‑squared (R²) đo mức độ giải thích variance của bài toán hồi quy (giá trị liên tục).
  • Không áp dụng cho classification vì nó không phản ánh số lượng dự đoán đúng/ sai.
  • Trên SageMaker, R² chỉ xuất hiện trong các notebook cho hồi quy (ví dụ: XGBoost regression).

• - Root mean squared error (RMSE)

  • RMSE cũng là chỉ số dành cho hồi quy, tính căn bậc hai trung bình của sai số bình phương giữa giá trị dự đoán và giá trị thực.
  • Đối với phân loại, RMSE không có nghĩa vì đầu ra không phải là giá trị số liên tục.
  • Trong AWS, RMSE thường được dùng để đánh giá mô hình dự báo thời gian, giá trị sensor, v.v.

• - Learning rate

  • Learning rate (tốc độ học) là siêu tham số của thuật toán tối ưu (gradient descent) quyết định mức độ cập nhật trọng số ở mỗi vòng lặp.
  • Nó không phải là metric đánh giá hiệu suất mô hình, mà là tham số cấu hình trong quá trình huấn luyện.
  • Trong SageMaker Training Jobs, learning rate được đặt trong hyperparameters, không phải trong metrics.

📚 Tham khảo (cập nhật tới 2026)

1. AWS Documentation – Amazon SageMaker Model Evaluation
   https://docs.aws.amazon.com/sagemaker/latest/dg/model-evaluation.html
2. AWS Blog – Best Practices for Model Metrics in SageMaker (2024)
   https://aws.amazon.com/blogs/machine-learning/best-practices-model-metrics-sagemaker/
3. scikit‑learn – Classification Metrics (phiên bản 1.5, 2025)
   https://scikit-learn.org/stable/modules/model_evaluation.html#classification-metrics

🧩 Tổng kết:

• Để đo “có bao nhiêu ảnh được mô hình phân loại đúng”, Accuracy là chỉ số phù hợp nhất.
• Các chỉ số R‑squared, RMSE và Learning rate không liên quan tới việc đo lường độ chính xác trong bài toán phân loại ảnh.

✅ Bạn có thể cấu hình SageMaker để tự động ghi lại metric Accuracy trong quá trình training và evaluation, giúp dễ dàng theo dõi và so sánh các phiên bản mô hình.

📚 Phân tích câu hỏi

• Bối cảnh: Công ty đã có một mô hình ngôn ngữ lớn (LLM) đã được huấn luyện sẵn và đang dùng nó để tạo chatbot đề xuất sản phẩm.
• Yêu cầu: Kết quả (output) của LLM phải ngắn gọn và được viết bằng một ngôn ngữ cụ thể (ví dụ: tiếng Việt, tiếng Nhật …).
• Mục tiêu: Tìm cách “điều chỉnh chất lượng phản hồi” sao cho đáp ứng đúng yêu cầu mà không cần thay đổi mô hình, không cần tái huấn luyện lại.

Trong môi trường AWS, khách hàng thường dùng Amazon Bedrock hoặc SageMaker JumpStart để truy cập các LLM (Claude, Llama 2, Titan …). Các tham số như temperature, Top‑K, model size ảnh hưởng đến độ đa dạng và độ “độ ngẫu nhiên” của đáp án, nhưng không trực tiếp kiểm soát độ dài hay ngôn ngữ đầu ra.

✅ Giải pháp thực tiễn nhất: Adjust the prompt – tức là thay đổi cách viết lời nhắc (prompt) để chỉ định rõ ràng độ dài và ngôn ngữ mong muốn. Prompt engineering là kỹ thuật chuẩn trong việc “tùy chỉnh” hành vi của LLM mà không cần thay đổi mô hình.

✅ Đáp án đúng

- Adjust the prompt.

Vì sao?

1. Prompt engineering cho phép chúng ta đưa các chỉ dẫn cụ thể như:
   • “Viết câu trả lời trong tối đa 2 câu.”
   • “Sử dụng tiếng Việt cho mọi phản hồi.”
2. Trong Amazon Bedrock, chúng ta có thể truyền system prompt (được gọi là “instruction”) để định hướng toàn bộ cuộc hội thoại.
3. Khi chúng ta chỉ định độ dài và ngôn ngữ trong prompt, mô hình sẽ cố gắng tuân thủ các yêu cầu đó mà không cần thay đổi bất kỳ siêu tham số nào.
4. Đây là cách nhanh nhất, chi phí thấp nhất và không cần tái huấn luyện hay chuyển đổi model.

❌ Giải thích các phương án sai

1. Choose an LLM of a different size.

• Giải thích: Thay đổi kích thước (size) của mô hình (ví dụ: từ 7B → 13B) ảnh hưởng tới khả năng hiểu ngữ cảnh và độ chính xác, nhưng không bảo đảm rằng kết quả sẽ ngắn hơn hay bằng một ngôn ngữ cụ thể.
• Thực tế AWS: Amazon Bedrock cho phép lựa chọn model size, nhưng việc chọn model “nhỏ hơn” chỉ giảm chi phí tính phí token, không kiểm soát độ dài đầu ra.

2. Increase the temperature.

• Giải thích: Temperature điều chỉnh độ ngẫu nhiên của mô hình:
  • Giá trị cao (≥0.8) → kết quả đa dạng, ít lặp, nhưng không làm cho câu trả lời ngắn hơn.
  • Giá trị thấp (≤0.2) → phản hồi đồng nhất, nhưng vẫn có thể dài.
• Mối quan hệ với yêu cầu: Nhiệt độ không quyết định ngôn ngữ hay độ dài, vì vậy tăng temperature không đáp ứng mục tiêu.

3. Increase the Top K value.

• Giải thích: Top‑K (và Top‑P) kiểm soát các token được xem xét trong quá trình sinh. Giá trị cao hơn cho phép mô hình chọn từ một tập lớn hơn các token, làm tăng độ sáng tạo, nhưng không ép buộc mô hình tạo câu ngắn hoặc trong một ngôn ngữ nhất định.
• Trong AWS: Các API của Bedrock cho phép truyền topK/topP trong request, nhưng chúng chỉ ảnh hưởng tới độ phong phú của văn bản, không phải độ dài hay ngôn ngữ.

🛠️ Cách thực hiện “Adjust the prompt” trên AWS (2026)

1. Sử dụng Amazon Bedrock – InvokeModel API

   {
     "prompt": "Bạn là trợ lý bán hàng. Hãy đề xuất một sản phẩm phù hợp cho khách hàng, trả lời **trong tối đa 2 câu** và viết **bằng tiếng Việt**.",
     "temperature": 0.3,
     "maxTokens": 150,
     "topP": 0.9
   }
   

2. Kết hợp system và user prompt (định dạng chat) để luôn giữ “ngôn ngữ + độ dài” trong system prompt.
3. Kiểm thử A/B: Gửi cùng một query với prompt khác nhau, đo average token length và language detection (có thể dùng Amazon Comprehend để xác minh).
4. Tối ưu hoá: Nếu vẫn có trường hợp trả lời dài hơn, có thể bổ sung chỉ dẫn “Nếu câu trả lời dài hơn 2 câu, rút gọn ngay lập tức”.

📖 Tham khảo nguồn tài liệu

• Amazon Bedrock Developer Guide (v2026.02) – phần Prompt Engineering và Control Parameters.
• AWS Whitepaper “Best Practices for Using Large Language Models” (2025) – chương 3: “Guiding model behavior with prompts”.
• OpenAI API Documentation (2026) – mặc dù không phải AWS, nhưng nguyên tắc temperature và top‑K được giải thích chi tiết, hỗ trợ so sánh.
• Amazon Comprehend – Language Detection API – dùng để kiểm chứng rằng output thực sự ở ngôn ngữ mong muốn.

📌 Kết luận ngắn gọn

• Để rút ngắn và định hướng ngôn ngữ cho output của LLM, điều chỉnh prompt là phương pháp chuẩn, nhanh, không tốn chi phí và phù hợp với mọi mô hình trên AWS.
• Các lựa chọn khác (thay đổi kích thước model, tăng temperature, tăng Top‑K) không trực tiếp giải quyết yêu cầu về độ dài và ngôn ngữ, vì vậy chúng là sai.

💡 Tip: Khi triển khai thực tế, luôn ghi lại phiên bản prompt và các siêu tham số trong AWS CloudFormation hoặc Terraform để duy trì tính nhất quán và có thể rollback nếu cần.

Chúc bạn thành công trong việc tối ưu chatbot! 🚀

🧩 Câu hỏi:
Một công ty chạy pipeline Machine Learning trên Amazon SageMaker trong môi trường production. Dữ liệu đầu vào rất lớn (tối đa 1 GB) và thời gian xử lý có thể kéo dài tới 1 giờ. Công ty yêu cầu độ trễ gần‑real‑time.
❓ Yêu cầu: chọn SageMaker inference option đáp ứng được các tiêu chí trên.

1️⃣ Giải thích nội dung câu hỏi

• Kích thước payload: 1 GB → quá lớn so với giới hạn “few MB” của các endpoint real‑time hoặc serverless.
• Thời gian xử lý: lên tới 1 giờ → không phù hợp với các endpoint được thiết kế để trả lời trong mili‑giây hoặc vài giây.
• Độ trễ “gần‑real‑time”: công ty muốn nhận kết quả trong thời gian ngắn (đúng trong vài phút‑hàng chục phút), chứ không chờ hàng giờ hay ngày như batch truyền thống.

Vì vậy chúng ta cần một kiểu inference cho phép:

1. Payload lớn (có thể truyền dữ liệu qua S3 hoặc chunk).
2. Thời gian xử lý dài (từ vài phút tới hàng giờ).
3. Kết quả có thể truy xuất nhanh (không phải batch offline).

Trong các tùy chọn của SageMaker, Asynchronous inference chính là dịch vụ đáp ứng ba yêu cầu này.

2️⃣ Đáp án đúng

✅ Asynchronous inference

• Hỗ trợ payload lớn: yêu cầu có thể đưa dữ liệu vào S3 và tham chiếu bằng URL; không bị giới hạn 6 MB như real‑time.
• Xử lý lâu: thiết kế cho các mô hình có thời gian inference lên tới several hours (hiện tại tài liệu AWS cho phép tới 48 giờ).
• Gần‑real‑time: khi yêu cầu được gửi, SageMaker trả về một Inference Job ID; kết quả sẽ được lưu vào S3 và có thể được poll hoặc thông báo qua SNS/Lambda trong vòng vài giây‑phút. Độ trễ thường nằm trong khoảng từ vài giây đến vài phút, phù hợp với “near real‑time”.

Nguồn tham khảo:

• 📘 Amazon SageMaker Asynchronous Inference – AWS Documentation (phiên bản 2026)
• 📘 Choosing the right inference option – AWS Whitepaper “Amazon SageMaker Best Practices”.

3️⃣ Phân tích các phương án khác

❌ Real-time inference

• Giới hạn payload: tối đa 6 MB (đối với JSON/CSV) hoặc 10 MB (binary). Không thể nhận 1 GB.
• Thời gian xử lý: endpoint được thiết kế để trả lời trong mili‑giây tới vài giây; nếu một yêu cầu kéo dài hơn 1 giây, endpoint sẽ bị timeout và gây lỗi 504.
• Không phù hợp với nhu cầu “long‑running” và “large payload”.

❌ Serverless inference

• Giới hạn payload tương tự Real‑time (khoảng 6‑10 MB).
• Thời gian xử lý: tối đa 30 giây (đối với một invocation) theo tài liệu mới nhất; nếu quá lâu, Lambda‑based backend sẽ timeout.
• Không đáp ứng yêu cầu xử lý tới 1 giờ và dữ liệu 1 GB.

❌ Batch transform

• Mô hình batch: dùng cho offline processing lớn, không có yêu cầu latency. Kết quả chỉ được ghi lại sau khi toàn bộ job hoàn thành (có thể mất giờ‑ngày).
• Không “near real‑time”: không thể trả về kết quả ngay sau một request đơn lẻ.
• Mặc dù hỗ trợ payload lớn, nhưng không phù hợp với yêu cầu thời gian đáp ứng nhanh.

4️⃣ Tổng kết

• Đáp án đúng: Asynchronous inference ✅
• Các tùy chọn còn lại (Real‑time, Serverless, Batch transform) đều không đáp ứng ít nhất một trong ba tiêu chí quan trọng: kích thước dữ liệu, thời gian xử lý dài, và độ trễ gần‑real‑time.

5️⃣ Lời khuyên thực tiễn (đối với DevOps Engineer)

• Khi triển khai Asynchronous inference, cấu hình S3 bucket cho input/output, IAM role cho phép SageMaker truy cập, và SNS/Lambda để nhận thông báo khi job hoàn thành.
• Giám sát qua CloudWatch Metrics: Invocations, InvocationLatency, ModelLatency, và SageMaker Asynchronous Inference Job Metrics để tối ưu chi phí và thời gian.
• Đối với mô hình có tốc độ inference > 30 seconds, cân nhắc model partitioning hoặc multi‑instance để giảm thời gian, nhưng vẫn giữ chế độ asynchronous.

📚 Tham khảo:

1. Amazon SageMaker Asynchronous Inference – https://docs.aws.amazon.com/sagemaker/latest/dg/asynchronous-inference.html (phiên bản 2026).
2. Real‑time Inference – https://docs.aws.amazon.com/sagemaker/latest/dg/real-time-inference.html.
3. Serverless Inference – https://docs.aws.amazon.com/sagemaker/latest/dg/serverless-inference.html.
4. Batch Transform – https://docs.aws.amazon.com/sagemaker/latest/dg/batch-transform.html.

Chúc bạn ôn tập hiệu quả và đạt điểm cao trong kỳ thi AWS Certified DevOps Engineer – Professional! 🚀

🧩 Phân tích câu hỏi

Công ty đã có sẵn domain‑specific models (các mô hình được huấn luyện cho một lĩnh vực cụ thể).
Thay vì xây dựng mô hình mới từ đầu, họ muốn tận dụng các mô hình đã được huấn luyện trước (pre‑trained) và “điều chỉnh” (fine‑tune) chúng để thực hiện các nhiệm vụ mới nhưng liên quan đến nhau.

Yêu cầu này mô tả chiến lược học máy mà cho phép:

• Sử dụng kiến thức đã học được từ một tập dữ liệu lớn (hoặc từ một domain) → giảm thời gian và chi phí huấn luyện.
• Chỉ cần “điều chỉnh” một phần của mô hình (thường là các lớp cuối) cho nhiệm vụ mới.

Trong AWS, cách thực hiện phổ biến nhất là Transfer Learning – được hỗ trợ qua Amazon SageMaker (JumpStart, SageMaker Studio, SageMaker Training jobs với --transfer-learning flag, v.v.).

✅ Đáp án đúng

✅ Use transfer learning.

Lý do: Transfer learning chính là việc chuyển kiến thức từ một mô hình đã học (pre‑trained) sang một nhiệm vụ mới, thường bằng cách đóng băng một số lớp và huấn luyện lại (fine‑tune) các lớp cuối trên dữ liệu mới. Điều này đáp ứng đúng yêu cầu “adapt pre‑trained models to create models for new, related tasks” mà câu hỏi đưa ra.

AWS cập nhật đến năm 2026 cung cấp:

• SageMaker JumpStart: bộ sưu tập các mô hình pre‑trained (ResNet, BERT, etc.) có thể được fine‑tune ngay trong Studio.
• SageMaker Pipelines: tích hợp transfer learning trong workflow CI/CD cho ML.
• SageMaker Training với --transfer-learning cho phép chỉ định source_model_arn và target_dataset.

❌ Giải thích các phương án sai

1. ❌ Increase the number of epochs.

   • Giải thích: Tăng số epoch chỉ làm cho mô hình tiếp tục học lâu hơn trên cùng một tập dữ liệu và kiến trúc hiện tại. Nó không thay đổi việc sử dụng mô hình đã được huấn luyện trước, cũng không giúp “adapt” mô hình cho một nhiệm vụ mới. Thậm chí, nếu dữ liệu mới ít, việc tăng epoch có thể dẫn tới over‑fitting.

2. ❌ Decrease the number of epochs.

   • Giải thích: Giảm số epoch làm cho quá trình huấn luyện ngắn hơn, nhưng tương tự như trên, nó không tạo ra khả năng tái sử dụng mô hình đã có cho nhiệm vụ mới. Việc giảm epoch chỉ làm giảm độ hội tụ, có thể gây under‑fitting.

3. ❌ Use unsupervised learning.

   • Giải thích: Học không giám sát (unsupervised) tập trung vào việc khám phá cấu trúc tiềm ẩn của dữ liệu mà không có nhãn. Trong trường hợp công ty muốn điều chỉnh một mô hình đã được huấn luyện cho một task mới có nhãn (ví dụ: phân loại, dự đoán), phương pháp này không đáp ứng yêu cầu. Transfer learning thường dựa vào học có giám sát (supervised fine‑tuning) hoặc semi‑supervised khi nhãn hạn chế, chứ không phải unsupervised.

📚 Tham khảo tài liệu AWS (cập nhật 2026)

• Amazon SageMaker JumpStart – Transfer Learning: https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-transfer-learning.html
• SageMaker Training Job – Transfer Learning Parameters: https://docs.aws.amazon.com/sagemaker/latest/dg/training-job.html#training-job-transfer-learning
• Best Practices for Transfer Learning on SageMaker (AWS Blog, 2025): https://aws.amazon.com/blogs/machine-learning/transfer-learning-sagemaker-best-practices/
• AWS Well‑Architected Framework for Machine Learning (2024 edition): phần Cost Optimization nhấn mạnh việc sử dụng pre‑trained models để giảm chi phí và thời gian triển khai.

🔚 Tóm tắt:
Chiến lược phù hợp với yêu cầu “adapt pre‑trained models to create models for new, related tasks” là Transfer Learning. Các phương án “increase/decrease epochs” và “unsupervised learning” không đáp ứng mục tiêu tái sử dụng mô hình đã được huấn luyện, vì vậy chúng là sai. ✅🧠

🔎 Phân tích câu hỏi
Công ty muốn xây dựng một giải pháp tạo ảnh cho kính bảo hộ và yêu cầu:

1. Độ chính xác cao – các nhãn (annotation) phải phản ánh đúng nội dung hình ảnh.
2. Giảm thiểu rủi ro “annotation sai” – cần có cơ chế kiểm tra, xác nhận lại kết quả tự động.

Vì vậy, câu hỏi đang hỏi “giải pháp nào có thể kết hợp tự động hoá và kiểm định con người (human‑in‑the‑loop) để đạt độ chính xác tối đa khi gán nhãn ảnh?”

✅ Đáp án đúng

Human‑in‑the‑loop validation by using Amazon SageMaker Ground Truth Plus

Tại sao đây là đáp án đúng?

• SageMaker Ground Truth Plus (được ra mắt 2023 và liên tục được cải tiến đến 2026) cung cấp một workflow human‑in‑the‑loop tích hợp sẵn:
  • Tự động tạo nhãn bằng machine‑learning assisted labeling (model‑in‑the‑loop).
  • Kết quả được gửi tới người kiểm duyệt (human reviewers) để xác nhận, sửa lỗi hoặc bổ sung.
  • Hệ thống tính độ tin cậy (label quality score) cho mỗi nhãn và tự động lặp lại vòng kiểm tra cho các mẫu có điểm thấp.
• Nhờ có các reviewer chuyên môn và cơ chế quality control (quy tắc “majority vote”, “reviewer qualification”, “audit sampling”), nguy cơ nhãn sai giảm mạnh, đáp ứng yêu cầu “high accuracy” và “minimize risk of incorrect annotations”.
• Tích hợp liền mạch với Amazon SageMaker để tạo dataset, train model và triển khai, phù hợp với kiến trúc DevOps/ML‑Ops.

❌ Giải thích các phương án sai

1️⃣ Data augmentation by using an Amazon Bedrock knowledge base

• Bedrock là dịch vụ generative AI (LLM, diffusion models) cung cấp knowledge base để truy vấn kiến thức, không phải công cụ gán nhãn hình ảnh.
• Data augmentation chỉ tạo ra các biến thể (rotate, flip, noise…) của ảnh hiện có để tăng kích thước dataset, không giúp cải thiện độ chính xác của nhãn và không có cơ chế kiểm định con người.
• Vì vậy, nó không đáp ứng yêu cầu “minimize the risk of incorrect annotations”.

2️⃣ Image recognition by using Amazon Rekognition

• Amazon Rekognition là dịch vụ nhận dạng, phân tích ảnh/video (face detection, object/scene detection, text detection…).
• Rekognition có thể tự động gán nhãn dựa trên mô hình đã được huấn luyện sẵn, nhưng không cung cấp cơ chế human‑in‑the‑loop để xác nhận lại nhãn.
• Độ chính xác phụ thuộc vào mô hình mặc định của AWS, không thể bảo đảm “high accuracy” cho miền chuyên biệt như protective eyewear mà không có bước kiểm duyệt.

3️⃣ Data summarization by using Amazon QuickSight Q

• QuickSight Q là công cụ tự động trả lời câu hỏi bằng ngôn ngữ tự nhiên dựa trên dữ liệu đã có trong QuickSight.
• Nó không liên quan tới việc gán nhãn ảnh, cũng không thực hiện bất kỳ xử lý hình ảnh nào.
• Do đó, không đáp ứng bất kỳ yêu cầu nào của câu hỏi.

🛠️ Khi nào nên dùng các dịch vụ còn lại?

• Amazon Bedrock: Khi muốn tạo nội dung sáng tạo (hình ảnh, văn bản) hoặc truy vấn kiến thức từ LLM; không phải cho việc gán nhãn dữ liệu.
• Amazon Rekognition: Khi cần phân tích nhanh (detect objects, facial analysis) trên quy mô lớn và không yêu cầu kiểm định nhãn chi tiết.
• Amazon QuickSight Q: Khi cần truy vấn, trực quan hoá dữ liệu kinh doanh, tạo báo cáo nhanh.

📚 Tham khảo (tính tới 2026)

• Amazon SageMaker Ground Truth Plus – Documentation (AWS, 2026).
  https://docs.aws.amazon.com/sagemaker/latest/dg/ground-truth-plus.html
• Human‑in‑the‑Loop labeling best practices – AWS Machine Learning Blog, 2024.
  https://aws.amazon.com/blogs/machine-learning/human-in-the-loop-labeling-best-practices/
• Amazon Bedrock – Generative AI service (AWS, 2025).
  https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html
• Amazon Rekognition – Image and video analysis (AWS, 2025).
  https://docs.aws.amazon.com/rekognition/latest/dg/what-is.html
• Amazon QuickSight Q – Natural language query (AWS, 2025).
  https://docs.aws.amazon.com/quicksight/latest/user/quickSight-Q.html

Tóm lại: Đối với yêu cầu “độ chính xác cao” và “giảm thiểu rủi ro annotation sai” trong việc gán nhãn ảnh kính bảo hộ, SageMaker Ground Truth Plus với quy trình human‑in‑the‑loop là giải pháp duy nhất đáp ứng đầy đủ, còn các lựa chọn còn lại không phù hợp vì không cung cấp cơ chế kiểm định con người và/hoặc không liên quan tới việc gán nhãn ảnh. 🚀

🔎 Phân tích câu hỏi

Công ty muốn xây dựng một chatbot chạy trên Amazon Bedrock và sử dụng một foundation model (FM).
FM cần truy cập vào dữ liệu được lưu trong Amazon S3; dữ liệu này được mã hoá bằng SSE‑S3 (Amazon S3‑managed encryption keys).

Khi FM cố gắng đọc dữ liệu trong bucket, quá trình fail – có nghĩa là mô hình không có đủ quyền truy cập / giải mã.
Câu hỏi yêu cầu chọn giải pháp đáp ứng được:

1. Bedrock (và model) có thể đọc và giải mã dữ liệu trong bucket.
2. Không làm lộ dữ liệu ra bên ngoài hay phá vỡ nguyên tắc bảo mật.

✅ Đáp án đúng

- Ensure that the role that Amazon Bedrock assumes has permission to decrypt data with the correct encryption key.

Vì sao đáp án này là đúng?

• Khi một Amazon Bedrock model cần truy cập tài nguyên AWS (ví dụ: S3), Bedrock sẽ “assume” một IAM role mà bạn chỉ định trong model access configuration.
• Đối với SSE‑S3, khóa mã hoá được quản lý hoàn toàn bởi S3. Người dùng không cần quản lý KMS key, nhưng để S3 tự động giải mã khi trả về dữ liệu, IAM role phải có quyền s3:GetObject (và/hoặc s3:ListBucket nếu cần duyệt).
• Nếu role không có quyền này, S3 sẽ trả về AccessDenied – chính là lỗi “failure when attempting to access the S3 bucket data”.
• Do đó, đảm bảo role có quyền đọc và do đó “giải mã” dữ liệu là cách duy nhất đáp ứng yêu cầu.
• Từ AWS 2025‑2026, tài liệu Bedrock vẫn khuyến nghị: “Configure a service‑linked role or a customer‑managed IAM role with the necessary S3 permissions (e.g., s3:GetObject) for the model to retrieve encrypted content.” (source: Amazon Bedrock Developer Guide, “Providing model access to Amazon S3 data”).

❌ Giải thích các phương án sai

• Set the access permissions for the S3 buckets to allow public access to enable access over the internet.

  • Việc mở công khai bucket (public read) không giải quyết vấn đề giải mã; SSE‑S3 vẫn yêu cầu IAM permission.
  • Thêm vào đó, đây là vi phạm nguyên tắc bảo mật (principle of least privilege) và có thể khiến dữ liệu nhạy cảm bị rò rỉ.
  • Bedrock không cần truy cập qua Internet công cộng; nó có thể truy cập nội bộ thông qua IAM role.

• Use prompt engineering techniques to tell the model to look for information in Amazon S3.

  • Prompt engineering chỉ ảnh hưởng tới cách mô hình suy luận; nó không cung cấp các quyền IAM hoặc các cơ chế truy cập.
  • Mô hình không tự động có khả năng “đọc” một bucket chỉ dựa vào prompt; cần một IAM role và API call (s3:GetObject).
  • Vì vậy, cách này không khắc phục lỗi “AccessDenied”.

• Ensure that the S3 data does not contain sensitive information.

  • Việc loại bỏ dữ liệu nhạy cảm không giải quyết vấn đề permission.
  • Ngay cả khi dữ liệu không nhạy cảm, nếu role không có s3:GetObject, việc truy cập vẫn sẽ thất bại.
  • Đây không phải là “giải pháp kỹ thuật” mà là một biện pháp giảm rủi ro phụ trợ, không đáp ứng yêu cầu truy cập.

🛠️ Các bước thực hiện đề xuất (theo AWS 2026)

1. Tạo hoặc chỉnh sửa IAM role mà Bedrock sẽ “assume”.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": ["s3:GetObject", "s3:ListBucket"],
         "Resource": [
           "arn:aws:s3:::my-bucket",
           "arn:aws:s3:::my-bucket/*"
         ]
       }
     ]
   }
   

2. Liên kết role này trong Amazon Bedrock Model Access Configuration (Console > Bedrock > Models > Manage access).
3. Kiểm tra Bucket Policy (nếu có) để chắc chắn không có Deny nào cản s3:GetObject cho role.
4. Kiểm thử bằng Invoke Model trong console hoặc qua AWS SDK để xác nhận model có thể đọc dữ liệu và trả về kết quả.

📚 Tham khảo

• Amazon Bedrock Developer Guide – “Providing model access to Amazon S3 data” (phiên bản cập nhật 2026).
• Amazon S3 Documentation – “Amazon S3 Server‑Side Encryption (SSE‑S3)” (2025‑2026).
• IAM Best Practices – “Least‑privilege principle for service‑linked roles” (AWS Security Blog, 2025).

Tóm lại: Để mô hình Foundation Model trên Amazon Bedrock truy cập dữ liệu SSE‑S3, cần cấp cho IAM role mà Bedrock sử dụng quyền s3:GetObject (và nếu cần s3:ListBucket), qua đó S3 sẽ tự động giải mã dữ liệu. Các lựa chọn khác either vi phạm bảo mật hoặc không giải quyết vấn đề quyền truy cập. ✅

📝 Phân tích câu hỏi

Một công ty muốn triển khai language model (mô hình ngôn ngữ) để thực hiện inference (suy diễn) trực tiếp trên thiết bị edge (các thiết bị nằm gần người dùng, ví dụ: camera, máy IoT, thiết bị di động…). Yêu cầu quan trọng nhất là độ trễ (latency) phải thấp nhất có thể. Vì vậy chúng ta cần một kiến trúc cho phép mô hình được chạy cực nhanh mà không phải phụ thuộc vào kết nối mạng tới trung tâm.

✅ Đáp án đúng

🔹 Deploy optimized small language models (SLMs) on edge devices.

• Các small language model (SLM) được tối ưu hoá (quantization, pruning, knowledge‑distillation…) để có kích thước chỉ vài MB‑tới‑tens MB, phù hợp với tài nguyên CPU/GPU/ASIC hạn chế trên thiết bị edge.
• Khi mô hình được đặt trực tiếp trên thiết bị, inference không cần truyền dữ liệu qua mạng, do đó latency gần như bằng 0 (chỉ phụ thuộc vào tốc độ xử lý nội bộ).
• AWS cung cấp các công cụ hỗ trợ triển khai SLM trên edge: Amazon SageMaker Edge Manager, AWS IoT Greengrass, AWS Snowball Edge, và AWS Trainium/Inferentia cho các thiết bị mạnh hơn.
• Từ phiên bản 2025‑2026, SageMaker Edge Manager đã hỗ trợ model compiler (trong SageMaker Neo) giúp chuyển đổi SLM sang định dạng tối ưu cho CPU, GPU, hoặc các chip AI tùy chỉnh (Ví dụ: AWS‑Designed Arm Neoverse).

Vì vậy đây là giải pháp đáp ứng yêu cầu “latency thấp nhất”.

❌ Giải thích các lựa chọn sai

1. Deploy optimized large language models (LLMs) on edge devices.

• LLM (ví dụ: GPT‑4, Claude, Llama‑2 70B) thường có hàng trăm gigabyte tham số, yêu cầu bộ nhớ và tính toán rất lớn.
• Mặc dù có các công nghệ model compression (quantization 4‑bit, LoRA, etc.), nhưng ngay cả sau khi nén, kích thước và yêu cầu tính toán vẫn vượt quá khả năng hầu hết các thiết bị edge hiện nay.
• Việc cố gắng chạy LLM trên edge sẽ gây tăng latency do swap memory, throttling CPU/GPU, hoặc thậm chí không thể khởi chạy.
• AWS không cung cấp dịch vụ SageMaker Edge cho LLM ở kích thước này; thay vào đó họ khuyến nghị SageMaker JumpStart hoặc SageMaker Inference Endpoints trên cloud.

✅ Kết luận: Không thể đáp ứng yêu cầu “độ trễ thấp nhất”.

2. Incorporate a centralized small language model (SLM) API for asynchronous communication with edge devices.

• Mô hình được lưu trữ ở trung tâm và các thiết bị edge gọi API asynchronously.
• Mặc dù SLM có kích thước nhỏ, nhưng mỗi lần inference vẫn phải truyền dữ liệu qua mạng (Internet hoặc mạng nội bộ).
• Độ trễ mạng (từ vài ms tới vài trăm ms) luôn lớn hơn so với việc chạy trực tiếp trên thiết bị.
• Ngoài ra, độ tin cậy phụ thuộc vào kết nối, không phù hợp với các môi trường edge có băng thông hạn chế hoặc không ổn định.

✅ Kết luận: Không đáp ứng tiêu chí “latency thấp nhất”.

3. Incorporate a centralized large language model (LLM) API for asynchronous communication with edge devices.

• Kết hợp các nhược điểm của LLM (kích thước, tài nguyên) và kết nối mạng.
• Thậm chí còn tăng đáng kể latency và chi phí (vì mỗi request phải tính phí cho compute lớn ở cloud).
• Đối với các trường hợp yêu cầu phản hồi nhanh (real‑time inference), cách tiếp cận này là không thực tế.

✅ Kết luận: Sai hoàn toàn so với yêu cầu.

📚 Tham khảo tài liệu (cập nhật đến năm 2026)

1. Amazon SageMaker Edge Manager – “Deploy machine learning models to edge devices with low latency” (AWS Documentation, phiên bản 2026).
2. AWS IoT Greengrass – “Run Lambda functions and ML inference locally on edge devices” (2025‑2026).
3. SageMaker Neo – “Compile models for optimal performance on a variety of hardware, including edge CPUs and accelerators” (AWS Blog, 2025).
4. AWS Snowball Edge – “Compute‑optimized edge device for running large workloads offline” (AWS Whitepaper, 2024).
5. AWS re:Invent 2025 – Session “Running Small Language Models at the Edge” – mô tả thực tiễn triển khai SLM trên thiết bị IoT.

📌 Tổng kết

• Đáp án đúng: Deploy optimized small language models (SLMs) on edge devices.
• Lý do: SLM được tối ưu hoá vừa đủ khả năng ngôn ngữ, vừa nhẹ để chạy trực tiếp trên thiết bị, loại bỏ toàn bộ độ trễ mạng và đáp ứng yêu cầu “latency thấp nhất”.
• Các lựa chọn còn lại đều gặp vấn đề về kích thước mô hình, tài nguyên thiết bị, hoặc độ trễ mạng, nên không phù hợp.

👍 Hy vọng phân tích trên giúp bạn nắm rõ cách lựa chọn giải pháp phù hợp cho inference trên edge với độ trễ tối thiểu! 🚀