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

🔎 Phân tích câu hỏi
Một công ty muốn xây dựng mô hình Machine Learning (ML) bằng Amazon SageMaker. Trong quá trình phát triển, các đội ngũ khác nhau cần chia sẻ và quản lý các biến (features) chung – ví dụ: các đặc trưng đã tiền xử lý, các biến thống kê, hay các biến mô tả dữ liệu đầu vào. Yêu cầu này đòi hỏi một kho lưu trữ trung tâm, có khả năng:

• Lưu trữ, phiên bản hoá và phục vụ các feature cho các môi trường training, inference và cho nhiều nhóm đồng thời.
• Quản lý quyền truy cập (IAM, VPC, encryption) để các team chỉ có thể đọc/ghi theo quy định.
• Cung cấp API (SDK, REST) để các notebook, pipelines, hoặc ứng dụng khác có thể truy xuất feature một cách nhất quán.

Trong SageMaker, tính năng đáp ứng đúng nhu cầu này là Amazon SageMaker Feature Store.

✅ Đáp án đúng: Amazon SageMaker Feature Store

• Tại sao đúng?
  Feature Store là một kho dữ liệu quản lý feature (Feature Repository) được thiết kế riêng cho ML. Nó cung cấp:

  • Feature Group: lưu trữ các feature ở dạng thời gian (time‑series) hoặc không thời gian, có versioning và metadata.
  • Online Store & Offline Store: cho phép truy xuất nhanh (real‑time inference) và truy vấn batch (training).
  • Quản lý quyền qua IAM, VPC, KMS để các team có thể chia sẻ mà vẫn kiểm soát được quyền.
  • SDK & API (SageMaker SDK, Boto3) giúp các pipeline, notebook, và ứng dụng Lambda/Gateway truy cập đồng nhất.

  Từ phiên bản 2024‑2025, Feature Store còn hỗ trợ feature lineage, data quality checks, và integration với SageMaker Pipelines – rất phù hợp với môi trường đa team.

🧩 Giải thích các phương án còn lại (sai)

• Amazon SageMaker Data Wrangler
  Data Wrangler là công cụ trong SageMaker Studio giúp thu thập, làm sạch, biến đổi và chuẩn bị dữ liệu bằng giao diện kéo‑thả hoặc script. Nó không cung cấp kho lưu trữ trung tâm để chia sẻ feature giữa các team; các transform được lưu dưới dạng notebook hoặc pipeline, nhưng không có khả năng quản lý version và phục vụ feature như một kho dữ liệu độc lập. Vì vậy, không đáp ứng yêu cầu “share and manage variables across multiple teams”.

• Amazon SageMaker Clarify
  Clarify là tính năng đánh giá công bằng (fairness), bias và explainability cho mô hình ML. Nó cung cấp các metric, visualizations và công cụ để kiểm tra bias trong dữ liệu và dự đoán, nhưng không phải là nơi lưu trữ hoặc quản lý feature. Do vậy, không phù hợp với nhu cầu chia sẻ biến.

• Amazon SageMaker Model Cards
  Model Cards là tài liệu mô tả mô hình (metadata, intended use, performance, limitations) giúp truyền đạt thông tin mô hình tới các bên liên quan. Chúng không lưu trữ hay quản lý các feature; chỉ là tài liệu mô tả mô hình. Vì thế cũng không đáp ứng yêu cầu.

📚 Tham khảo (tính đến năm 2026)

1. Amazon SageMaker Feature Store – Documentation
   https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html (phiên bản cập nhật 2026)
2. SageMaker Feature Store – What’s new 2024‑2025
   https://aws.amazon.com/blogs/machine-learning/amazon-sagemaker-feature-store-updates-2024/
3. AWS Well‑Architected Framework – Machine Learning Lens – phần “Feature Management”.
4. AWS Blog – Using Feature Store to enable cross‑team collaboration
   https://aws.amazon.com/blogs/machine-learning/collaborative-feature-store/

🛠️ Kết luận: Để chia sẻ và quản lý các biến (features) trong môi trường phát triển ML đa team, Amazon SageMaker Feature Store là giải pháp thích hợp nhất. Các tùy chọn khác (Data Wrangler, Clarify, Model Cards) phục vụ các mục đích riêng biệt như chuẩn bị dữ liệu, đánh giá công bằng, và tài liệu mô hình, nên không đáp ứng yêu cầu của câu hỏi.

📝 Giải thích nội dung câu hỏi
Câu hỏi mô tả một công ty muốn nâng cao năng suất của các nhà phát triển phần mềm bằng cách áp dụng generative AI. Công ty quyết định sử dụng Amazon Q Developer – một dịch vụ AI sinh mã mới (được ra mắt và cập nhật liên tục đến năm 2026) nhằm hỗ trợ lập trình viên trong quá trình viết code, tái sử dụng đoạn mã, quản lý giấy phép và các tài nguyên tham chiếu.
Yêu cầu thực tế: “What can Amazon Q Developer do to help the company meet these requirements?” – tức là cần xác định các khả năng chính của Amazon Q Developer mà đáp ứng nhu cầu “tăng năng suất lập trình và hỗ trợ phát triển phần mềm”.

✅ Đáp án đúng

- Create software snippets, reference tracking, and open source license tracking.

Lý do chọn:

• Create software snippets: Amazon Q Developer có khả năng tạo ra các đoạn mã (code snippets) dựa trên mô tả ngôn ngữ tự nhiên của lập trình viên, giảm thời gian viết tay.
• Reference tracking: Dịch vụ tự động ghi lại các thư viện, API và tài nguyên mà đoạn mã sử dụng, giúp lập trình viên dễ dàng kiểm tra phụ thuộc và cập nhật.
• Open source license tracking: Q Developer tích hợp công cụ phân tích giấy phép nguồn mở (OSS) để xác định các rủi ro pháp lý khi sử dụng mã nguồn mở trong dự án, đáp ứng yêu cầu tuân thủ.

Các tính năng này chính là những điểm mạnh được AWS nhấn mạnh trong tài liệu Amazon Q Developer – Developer productivity with generative AI (cập nhật 2026) và đáp ứng đầy đủ “tăng năng suất” và “hỗ trợ phát triển phần mềm”.

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

1. Run an application without provisioning or managing servers.

   • Giải thích: Đây là mô tả của AWS Lambda hoặc AWS Fargate, chứ không phải chức năng của Amazon Q Developer. Q Developer chỉ cung cấp trợ giúp viết code, không chịu trách nhiệm triển khai hoặc chạy ứng dụng.

2. Enable voice commands for coding and providing natural language search.

   • Giải thích: Mặc dù Amazon Q Developer hỗ trợ natural language prompts để sinh mã, nhưng không có tính năng điều khiển bằng giọng nói (voice commands). Tính năng này thuộc các sản phẩm như Amazon Bedrock + Amazon Polly hoặc Amazon Lex, không phải Q Developer.

3. Convert audio files to text documents by using ML models.

   • Giải thích: Chức năng chuyển đổi audio → text (speech‑to‑text) thuộc Amazon Transcribe. Q Developer không xử lý dữ liệu âm thanh; nó chỉ làm việc với văn bản và mã nguồn.

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

• Amazon Q Developer – Documentation (AWS, phiên bản cập nhật tháng 03/2026).
• AWS re:Invent 2025 – “Boosting developer productivity with Amazon Q” (video và slide).
• AWS Well‑Architected Framework – Developer Productivity Pillar (2025).

Tóm tắt:
✅ Amazon Q Developer giúp công ty đạt mục tiêu bằng cách tạo đoạn mã, theo dõi tham chiếu và quản lý giấy phép nguồn mở. Các lựa chọn còn lại mô tả các dịch vụ AWS khác hoặc tính năng không tồn tại trong Q Developer, vì vậy chúng là sai. 🚀

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

Câu hỏi mô tả một tổ chức tài chính đang phát triển một ứng dụng AI bằng Amazon Bedrock. Ứng dụng này được triển khai trong một VPC và không được phép có bất kỳ lưu lượng internet nào (để đáp ứng yêu cầu tuân thủ quy định).
Yêu cầu: chọn dịch vụ hoặc tính năng AWS cho phép VPC “giao tiếp” với Amazon Bedrock mà không cần đi qua internet công cộng.

2️⃣ Đáp án đúng

✅ AWS PrivateLink

Lý do:

• PrivateLink cung cấp VPC Interface Endpoints cho phép kết nối tới các dịch vụ AWS (như Amazon Bedrock) trong mạng nội bộ của AWS, không cần Internet Gateway, NAT, hay proxy công cộng.
• Khi tạo một Interface VPC Endpoint cho Bedrock, lưu lượng đi qua đường truyền riêng tư của AWS backbone, đáp ứng yêu cầu “không có internet”.
• PrivateLink còn hỗ trợ định danh VPC‑to‑VPC và đối tác SaaS mà vẫn giữ dữ liệu trong môi trường riêng, rất phù hợp với quy định tài chính.

3️⃣ Giải thích tất cả các phương án

• AWS PrivateLink

  • ✅ Đúng
  • Cung cấp kết nối riêng tư tới dịch vụ AWS (Bedrock) thông qua Interface VPC Endpoint. Không cần Internet Gateway hay NAT, vì vậy không có bất kỳ lưu lượng internet công cộng nào. Đây là cách chuẩn để “đưa” các dịch vụ fully‑managed vào VPC một cách an toàn.

• Amazon Macie

  • ❌ Sai
  • Amazon Macie là dịch vụ phát hiện dữ liệu nhạy cảm và bảo mật dữ liệu trong Amazon S3. Nó không cung cấp khả năng truy cập mạng tới các dịch vụ AWS khác và không giải quyết yêu cầu “không có internet”. Nhiệm vụ của Macie là quét, phân loại và cảnh báo, không phải là tạo kênh truyền dữ liệu nội bộ.

• Amazon CloudFront

  • ❌ Sai
  • CloudFront là Content Delivery Network (CDN), luôn hoạt động qua Internet để phân phối nội dung tới các edge location. Để sử dụng CloudFront, VPC vẫn phải có đầu ra internet (thông qua IGW/NAT). Vì vậy nó vi phạm yêu cầu “không được phép truy cập internet”.

• Internet gateway

  • ❌ Sai
  • Internet Gateway (IGW) là cổng ra internet cho VPC, cho phép các subnet công cộng hoặc NAT truyền lưu lượng tới/đến internet công cộng. Sử dụng IGW sẽ tạo ra lưu lượng internet, trái hoàn toàn với điều kiện “không cho phép truy cập internet”.

4️⃣ Kiến thức cập nhật đến năm 2026

• Từ 2024, Amazon Bedrock đã được hỗ trợ Interface VPC Endpoints (PrivateLink) để khách hàng có thể truy cập mô hình AI mà không rời khỏi AWS network.
• 2025: AWS mở rộng danh sách dịch vụ có PrivateLink, bao gồm cả Bedrock, SageMaker, và các dịch vụ AI mới.
• 2026: AWS khuyến cáo trong AWS Well‑Architected Framework – Security Pillar rằng các workloads yêu cầu “no‑internet” nên dùng PrivateLink hoặc AWS Transit Gateway để giữ lưu lượng trong mạng nội bộ.

5️⃣ Tham khảo tài liệu

• 📘 Amazon Bedrock – Using VPC Interface Endpoints (PrivateLink) – AWS Documentation (phiên bản 2026)
• 📘 AWS PrivateLink – Overview – AWS Documentation (phiên bản 2026)
• 📘 AWS Well‑Architected Framework – Security Pillar (cập nhật 2025)

Tóm tắt: Để cho phép VPC truy cập Amazon Bedrock mà không cần internet, chỉ có AWS PrivateLink (qua Interface VPC Endpoint) đáp ứng yêu cầu. Các lựa chọn còn lại đều không cung cấp kết nối nội bộ hoặc thậm chí tạo ra lưu lượng internet, do đó là sai. 🚀

🔎 Phân tích câu hỏi
Công ty muốn xây dựng một educational game (trò chơi giáo dục) trong đó người dùng sẽ trả lời các câu hỏi kiểu “Trong một hũ có 6 viên bi đỏ, 4 viên bi xanh và 3 viên bi vàng. Xác suất rút được viên bi xanh là bao nhiêu?”.
Yêu cầu quan trọng nhất của đề bài: “Which solution meets these requirements with the LEAST operational overhead?” – tức là phải chọn cách triển khai đơn giản nhất và cần ít công sức vận hành nhất.

Trong bối cảnh AWS, “operational overhead” bao gồm việc cài đặt, đào tạo, quản lý, giám sát các mô hình Machine Learning (ML) – từ việc chuẩn bị dữ liệu, tạo môi trường training, lưu trữ mô hình, đến việc triển khai inference. Nếu một giải pháp không cần tới bất kỳ dịch vụ ML nào, chi phí vận hành sẽ giảm tối đa.

✅ Đáp án đúng

✅ Use code that will calculate probability by using simple rules and computations.

Lý do lựa chọn ✅

• Tính toán xác suất trong ví dụ trên là một phép toán cơ bản:
  [
  P(\text{green}) = \frac{\text{số bi xanh}}{\text{tổng số bi}} = \frac{4}{6+4+3}= \frac{4}{13}. ]
  Đây là một công thức tĩnh, không phụ thuộc vào dữ liệu lịch sử hay mô hình dự đoán.
• Không cần dùng ML: Không có lợi thế nào khi áp dụng học máy cho một phép tính xác suất cố định. Việc tạo, huấn luyện, lưu trữ và cập nhật mô hình sẽ chỉ làm tăng độ phức tạp và chi phí.
• Triển khai dễ dàng: Có thể viết một hàm ngắn (Python, Node.js, Java…) và chạy trực tiếp trên AWS Lambda hoặc trong backend của trò chơi (EC2, ECS, App Runner).
  • Lambda: không cần quản lý server, chỉ trả tiền theo thời gian thực thi (độ trễ < 1 s).
  • Chi phí: gần như 0 khi tần suất gọi thấp – hoàn toàn phù hợp cho một trò chơi giáo dục.
• Giảm overhead: Không cần cấu hình SageMaker, không cần pipeline CI/CD cho mô hình, không cần monitoring model drift, không cần lưu trữ artifacts.
  → Least operational overhead được đáp ứng tối đa.

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

1️⃣ Use supervised learning to create a regression model that will predict probability.

• Supervised learning yêu cầu dữ liệu huấn luyện (các trường hợp đầu vào → xác suất thực tế) để xây dựng mô hình hồi quy.
• Đối với một bài toán xác suất đơn giản, việc thu thập dữ liệu, tạo pipeline ETL, huấn luyện trên Amazon SageMaker, lưu trữ mô hình, và triển khai endpoint SageMaker Inference sẽ gây overhead lớn (quản lý notebook, training jobs, model monitoring).
• Kết quả sẽ không chính xác hơn so với công thức toán học thuần túy và sẽ tốn tài nguyên, chi phí, và công sức bảo trì.

2️⃣ Use reinforcement learning to train a model to return the probability.

• Reinforcement Learning (RL) thích hợp cho các bài toán quyết định tuần tự, nơi có state, action, và reward.
• Để dự đoán một xác suất tĩnh, RL không chỉ không cần thiết mà còn khó triển khai: cần môi trường mô phỏng, policy network, thuật toán tối ưu (ví dụ PPO, DQN) và thường chạy trên GPU hoặc SageMaker RL.
• Điều này làm tăng độ phức tạp và chi phí (đào tạo trên EC2 P3/P4, lưu trữ checkpoint).
• Vì mục tiêu chỉ là tính toán một tỉ lệ đơn giản, RL là lựa chọn không hợp lý và tạo overhead tối đa.

3️⃣ Use unsupervised learning to create a model that will estimate probability density.

• Unsupervised learning (clustering, density estimation) nhằm khám phá cấu trúc ẩn trong dữ liệu mà không có nhãn.
• Đối với một bài toán “xác suất rút bi xanh” không có đặc điểm đa chiều cần khám phá, việc dùng Gaussian Mixture Model, K‑Means, hay Kernel Density Estimation là lãng phí.
• Triển khai trên SageMaker hoặc EMR sẽ yêu cầu pipeline tiền xử lý, training jobs, và endpoint để trả về ước lượng – tất cả đều tăng overhead.
• Ngoài ra, ước lượng density không cung cấp kết quả chính xác cho câu hỏi xác suất rút bi xanh, vì nó phụ thuộc vào độ chính xác của mô hình và kích thước mẫu.

🛠️ Gợi ý triển khai thực tiễn trên AWS (ít overhead)

1. AWS Lambda + API Gateway

   • Viết hàm (Python/Node.js) tính: prob_green = green / (red + green + yellow).
   • Đặt hàm dưới dạng REST API để game client gọi.
   • Ưu điểm: không cần quản lý server, tự động scaling, chi phí tính theo số request.

2. AWS CloudFront + Lambda@Edge (nếu muốn tính ngay tại edge)

   • Đưa hàm tính xác suất vào Lambda@Edge để giảm latency cho người chơi toàn cầu.

3. AWS Amplify (frontend)

   • Nếu game được triển khai dưới dạng web/mobile, có thể tích hợp logic tính xác suất trực tiếp trong React/Vue code, không thậm chí cần Lambda. Điều này giảm overhead về backend nữa.

4. Monitoring

   • Dùng Amazon CloudWatch Logs để ghi log request nếu cần. Không cần Model Monitoring vì không có mô hình ML.

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

• AWS Lambda Developer Guide – “Getting Started with Lambda” (https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html)
• Amazon API Gateway – “Creating a REST API” (https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-getting-started-with-rest-apis.html)
• AWS Amplify – “Integrate backend APIs” (https://docs.amplify.aws/lib/restapi/getting-started/q/platform/js)
• AWS Well‑Architected Framework – Operational Excellence Pillar – “Minimize operational overhead” (https://aws.amazon.com/architecture/well-architected/operational-excellence/)

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

• ✅ Giải pháp dùng code tính xác suất là cách đơn giản nhất và có ít operational overhead nhất trong trường hợp này.
• Các lựa chọn dựa trên Machine Learning (supervised, reinforcement, unsupervised) đều quá phức tạp, tốn chi phí, và không cần thiết cho một phép tính xác suất cố định.

🧩 Bài học: Khi yêu cầu chỉ là một phép toán định tính, hãy luôn ưu tiên giải pháp thuần procedural (code) trước khi nghĩ tới các dịch vụ Machine Learning của AWS. Điều này giúp giảm chi phí, giảm rủi ro vận hành và tăng tốc thời gian đưa sản phẩm ra thị trường.

📖 Giải thích câu hỏi
Câu hỏi yêu cầu bạn xác định metric (chỉ số) nào dùng để đo hiệu suất thời gian chạy (runtime efficiency) khi triển khai và vận hành các mô hình AI trong môi trường thực tế (sản xuất). “Runtime efficiency” ở đây không phải là thời gian huấn luyện mà là thời gian phản hồi (latency) của mô hình khi nhận yêu cầu dự đoán. Đây là chỉ số quan trọng để đánh giá mức độ nhanh chóng, đáp ứng yêu cầu của người dùng hoặc hệ thống downstream.

✅ Đáp án đúng

✅ Average response time

Lý do chọn:

• Average response time (thời gian phản hồi trung bình) đo khoảng thời gian từ khi một yêu cầu (inference request) được gửi đến mô hình AI tới khi kết quả được trả về.
• Đây là chỉ số trực tiếp phản ánh runtime efficiency của mô hình khi đang hoạt động (inference) trong môi trường production.
• AWS cung cấp các metric này qua Amazon CloudWatch cho các dịch vụ như Amazon SageMaker Endpoint, AWS Lambda (nếu dùng hàm inference), hoặc Amazon ECS/EKS khi chạy container chứa mô hình.
• Khi average response time thấp, mô hình xử lý nhanh, đáp ứng tốt yêu cầu thời gian thực (real‑time inference). Ngược lại, thời gian phản hồi cao cho thấy có vấn đề về resource provisioning, model optimization, hoặc network latency.

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

• ❌ Customer satisfaction score (CSAT)

  • CSAT đo sự hài lòng của khách hàng dựa trên khảo sát, phản ánh quan điểm người dùng cuối hơn là hiệu suất kỹ thuật.
  • Nó không cung cấp thông tin chi tiết về thời gian thực thi của mô hình AI; có thể khách hàng hài lòng dù latency cao (nếu độ chính xác cao) và ngược lại.
  • Vì vậy CSAT không phải metric đo runtime efficiency.

• ❌ Training time for each epoch

  • Thời gian huấn luyện mỗi epoch chỉ liên quan đến giai đoạn training (huấn luyện) của mô hình, không phải giai đoạn inference (đưa vào vận hành).
  • Metric này giúp tối ưu hoá quá trình huấn luyện (ví dụ: chọn instance, batch size), nhưng không đo thời gian phản hồi khi mô hình đang được sử dụng trong production.

• ❌ Number of training instances

  • Đây là đếm số lượng mẫu dữ liệu được dùng trong quá trình training. Nó liên quan tới độ phức tạp của dữ liệu và khả năng học của mô hình, không phản ánh hiệu suất thời gian chạy khi mô hình được triển khai.
  • Ngoài ra, metric này không liên quan tới latency, throughput hay tài nguyên runtime.

🛠️ Các công cụ/metric AWS liên quan (đến 2026)

• Amazon CloudWatch Metrics for SageMaker Endpoints

  • Invocations (số lượng yêu cầu)
  • InvocationLatency (thời gian phản hồi trung bình) ✅
  • ModelLoadTime (thời gian tải mô hình)

• AWS X-Ray – cho phép trace latency chi tiết từng request, giúp xác định bottleneck.

• Amazon CloudWatch Evidently – có thể theo dõi user‑perceived latency khi chạy A/B testing cho các phiên bản mô hình.

📚 Tham khảo

1. AWS Documentation – Amazon SageMaker Monitoring (phiên bản 2026): https://docs.aws.amazon.com/sagemaker/latest/dg/monitoring.html
2. Amazon CloudWatch Metrics – SageMaker Endpoints: https://docs.aws.amazon.com/cloudwatch/latest/monitoring/sagemaker-metrics.html
3. AWS Well‑Architected Framework – Operational Excellence Pillar (đối với AI/ML workloads): https://d1.awsstatic.com/whitepapers/architecture/AWS-Well-Architected-Framework-Operational-Excellence.pdf

Tóm tắt:

• Metric đo runtime efficiency của mô hình AI là Average response time.
• Các metric khác (CSAT, Training time per epoch, Number of training instances) không phản ánh thời gian thực thi khi mô hình đang phục vụ yêu cầu.

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

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

Một công ty đang xây dựng ứng dụng trung tâm liên lạc (contact‑center) và muốn rút ra thông tin quan trọng từ âm thanh của các cuộc gọi khách hàng.
Yêu cầu thực chất là:

1. Chuyển đổi giọng nói → văn bản (speech‑to‑text).
2. Sau khi có văn bản, có thể thực hiện các phân tích (tìm từ khóa, cảm xúc, thực thể, …).

Do đó giải pháp cần hỗ trợ transcription (ghi âm → text) một cách tự động, chính xác và có thể mở rộng.

✅ Đáp án đúng

✔️ “Transcribe call recordings by using Amazon Transcribe.”

Lý do:

• Amazon Transcribe là dịch vụ speech‑to‑text được quản lý, hỗ trợ đa ngôn ngữ, nhận dạng người nói, và có thể xử lý file audio (MP3, WAV, …) hoặc luồng streaming.
• Nó cho phép lưu kết quả dưới dạng plain text hoặc JSON (với timestamps, speaker labels), rất phù hợp để tiếp tục phân tích bằng các công cụ NLP (Amazon Comprehend, SageMaker, …).
• Được cập nhật liên tục đến năm 2026 với các tính năng như custom vocabularies, automatic language detection, và real‑time streaming transcription, đáp ứng tốt yêu cầu “analyze and extract key information from the audio of the customer calls”.

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

• Build a conversational chatbot by using Amazon Lex.

  • Amazon Lex là dịch vụ định nghĩa và triển khai chatbot (voice & text) dựa trên mô hình NLU/NLP.
  • Nó không cung cấp khả năng chuyển đổi audio cũ thành text; thay vào đó, Lex dùng để tương tác thời gian thực với người dùng.
  • Vì câu hỏi muốn phân tích các cuộc gọi đã ghi âm, Lex không phù hợp.

• Extract information from call recordings by using Amazon SageMaker Model Monitor.

  • SageMaker Model Monitor là công cụ giám sát chất lượng mô hình machine‑learning (phát hiện drift, dữ liệu ngoại lệ) sau khi mô hình đã được triển khai.
  • Nó không thực hiện việc chuyển đổi âm thanh sang văn bản hay trích xuất thông tin trực tiếp từ file audio.
  • Để dùng SageMaker cho mục tiêu này, ta cần đầu tiên có bản transcript (ví dụ từ Transcribe) rồi mới đưa vào mô hình NLP; vì vậy không phải là giải pháp duy nhất cho yêu cầu.

• Create classification labels by using Amazon Comprehend.

  • Amazon Comprehend là dịch vụ phân tích ngôn ngữ tự nhiên (sentiment, entity, key‑phrase, topic modeling) trên văn bản.
  • Nó không thể tiếp nhận file âm thanh; cần có bản transcript trước khi dùng Comprehend.
  • Vì yêu cầu bắt đầu từ audio, việc dùng trực tiếp Comprehend là sai lầm.

📚 Tham khảo tài liệu (đến 2026)

1. Amazon Transcribe – Documentation
   https://docs.aws.amazon.com/transcribe/latest/dg/what-is-transcribe.html
2. AWS Blog – “New Features in Amazon Transcribe (2025‑2026)” – giới thiệu custom vocabularies, real‑time streaming, speaker diarization.
3. Amazon Lex – Developer Guide – https://docs.aws.amazon.com/lex/latest/dg/what-is.html
4. Amazon SageMaker Model Monitor – Documentation – https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html
5. Amazon Comprehend – Documentation – https://docs.aws.amazon.com/comprehend/latest/dg/what-is.html

🧩 Kết luận

• Để “phân tích và trích xuất thông tin chính” từ âm thanh các cuộc gọi, bước đầu tiên là chuyển đổi audio → text → Amazon Transcribe là giải pháp phù hợp nhất.
• Các dịch vụ khác (Lex, SageMaker Model Monitor, Comprehend) có chức năng hữu ích trong bối cảnh khác, nhưng không đáp ứng trực tiếp yêu cầu chuyển đổi và phân tích audio như trong câu hỏi.

🔎 Phân tích câu hỏi
Một công ty có petabytes dữ liệu khách hàng chưa được gán nhãn (unlabeled). Mục tiêu là phân loại khách hàng thành các “tier” (cấp độ) để thực hiện chiến dịch quảng cáo và khuyến mại. Vì dữ liệu chưa có nhãn (không biết trước “tier” nào là đúng), công ty cần một phương pháp tự động khám phá cấu trúc, nhóm các khách hàng lại với nhau mà không dựa vào nhãn đầu vào.

✅ Đáp án đúng

🟢 Unsupervised learning

Vì sao lựa chọn này là đúng?

• Dữ liệu không có nhãn → không thể áp dụng các thuật toán yêu cầu nhãn (supervised) hay các môi trường phản hồi (reinforcement).
• Mục tiêu phân cụm (clustering) – tìm ra các nhóm khách hàng có đặc điểm tương đồng (ví dụ: hành vi mua sắm, mức chi tiêu, độ tuổi…) để xác định các “tier”.
• Unsupervised learning cung cấp các thuật toán clustering (K‑Means, DBSCAN, Gaussian Mixture, Hierarchical Clustering) và dimensionality reduction (PCA, t‑SNE, UMAP) giúp khám phá cấu trúc ẩn trong dữ liệu lớn.
• Trên AWS, Amazon SageMaker hỗ trợ đầy đủ các thuật toán không giám sát (SageMaker Built‑in Algorithms → Clustering, K‑Means, PCA) và SageMaker Canvas cho phép người không chuyên tạo mô hình không giám sát chỉ bằng giao diện kéo‑thả.
• Khi dữ liệu lên petabytes, AWS cung cấp Amazon S3 làm kho lưu trữ, Amazon EMR hoặc SageMaker Processing để tiền xử lý và chạy các job clustering quy mô lớn.

Do đó, Unsupervised learning là cách tiếp cận phù hợp nhất để “phân lớp” khách hàng mà không cần nhãn sẵn có.

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

1. Supervised learning

• Mô tả: Thuật toán học từ cặp dữ liệu (input, label) để dự đoán nhãn cho dữ liệu mới.
• Tại sao sai: Dữ liệu của công ty không có nhãn (không biết trước tier nào là đúng). Để dùng supervised learning, cần gán nhãn cho một bộ dữ liệu huấn luyện – việc này tốn kém, thời gian và không đáp ứng yêu cầu “không có nhãn”.
• AWS liên quan: SageMaker Linear Learner, XGBoost, Deep Learning Containers… đều yêu cầu nhãn.

2. Reinforcement learning

• Mô tả: Mô hình học thông qua phản hồi (reward/punishment) khi tương tác với môi trường, thường dùng cho điều khiển robot, tối ưu tài nguyên, game AI.
• Tại sao sai: Không có định nghĩa môi trường và phần thưởng rõ ràng cho việc “phân lớp khách hàng”. Reinforcement learning không phải là công cụ khám phá cấu trúc dữ liệu tĩnh.
• AWS liên quan: SageMaker RL Frameworks (RL‑Coach, RL‑TensorFlow) được dùng cho các bài toán tối ưu hành động, không phù hợp với clustering.

3. Reinforcement learning from human feedback (RLHF)

• Mô tả: Một biến thể của RL, trong đó phần thưởng được tạo ra từ phản hồi của con người (ví dụ: ChatGPT).
• Tại sao sai: Yêu cầu phản hồi có chất lượng và quy trình “human‑in‑the‑loop”. Đối với việc phân nhóm khách hàng, không có cơ chế “phản hồi” để hướng dẫn mô hình học; việc thu thập phản hồi cho petabytes dữ liệu sẽ vô cùng không thực tế.
• AWS liên quan: SageMaker RLHF chưa được công bố chính thức (tính đến 2026), và không phù hợp cho bài toán clustering không nhãn.

🛠️ Các dịch vụ AWS hỗ trợ Unsupervised learning cho quy mô petabytes

📚 Tham khảo (tính đến 2026)

1. AWS Documentation – Amazon SageMaker Built‑in Algorithms – “Clustering (K‑Means)”
   https://docs.aws.amazon.com/sagemaker/latest/dg/algos-clustering.html
2. AWS Whitepaper – Machine Learning at Scale on AWS (2024 update) – chương “Unsupervised Learning at Petabyte Scale”.
   https://d1.awsstatic.com/whitepapers/MachineLearningAtScale.pdf
3. AWS Blog – Scaling Unsupervised Learning with Amazon EMR and SageMaker (Jan 2025).
   https://aws.amazon.com/blogs/big-data/scaling-unsupervised-learning/
4. SageMaker Canvas – No‑Code Unsupervised Modeling (released 2023, continuously updated).
   https://aws.amazon.com/sagemaker/canvas/

📌 Tóm tắt nhanh

• Câu hỏi: Dữ liệu không có nhãn, cần phân nhóm khách hàng → Unsupervised learning.
• Đáp án đúng: 🟢 Unsupervised learning.
• Các lựa chọn còn lại (Supervised, Reinforcement, RLHF) đều không phù hợp vì yêu cầu nhãn, môi trường phản hồi, hoặc feedback con người, trong khi bài toán yêu cầu khám phá cấu trúc dữ liệu không nhãn.

💡 Mẹo thi: Khi đề bài nhắc “unlabeled data” → luôn nghĩ tới unsupervised (clustering, dimensionality reduction). Nếu đề yêu cầu “các hành động tối ưu qua phản hồi” → nghĩ tới reinforcement. Nếu có “đầu vào + nhãn” → supervised. 🚀

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

An AI practitioner wants to use a foundation model (FM) to design a search application. The search application must handle queries that have text and images. Which type of FM should the AI practitioner use to power the search application?

• Yêu cầu chức năng: Ứng dụng tìm kiếm cần hiểu và so sánh cả văn bản (text) và hình ảnh (image) trong một truy vấn.
• Nhiệm vụ chính của mô hình nền tảng: Chuyển đổi (embed) các đầu vào đa phương tiện (text + image) thành vector đại diện thống nhất để có thể tính độ tương đồng với tài liệu (cũng có thể là text, image hoặc cả hai) trong kho lưu trữ vector.
• Loại mô hình phù hợp: Multi‑modal embedding model – mô hình tạo embedding cho nhiều modality (đa phương tiện) cùng lúc, cho phép so sánh trực tiếp giữa các loại dữ liệu.

✅ Đáp án đúng

- Multi-modal embedding model

Lý do lựa chọn

• Embedding → chuyển đổi dữ liệu thô (text, image) thành vector trong không gian chung, thích hợp cho search/retrieval (so sánh cosine similarity, dot‑product, …).
• Multi‑modal → mô hình được huấn luyện để đồng thời xử lý text + image và tạo ra một vector đại diện cho toàn bộ truy vấn, cho phép truy vấn đa phương tiện.
• Trên AWS, các mô hình này có thể được triển khai qua Amazon Bedrock (ví dụ: Titan Multimodal Embedding, Cohere Multimodal Embedding, hoặc Meta LLaVA‑embedding phiên bản mới 2025) và lưu trữ vector trong Amazon OpenSearch Serverless hoặc Amazon DynamoDB + Amazon Kendra Vector Index để thực hiện tìm kiếm nhanh.

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

1. Text embedding model

   • Mô tả: Chỉ tạo embedding cho văn bản. Khi truy vấn chứa hình ảnh, phần hình ảnh sẽ không được biểu diễn, dẫn tới mất thông tin quan trọng và chất lượng tìm kiếm giảm mạnh.
   • AWS context: Các model như Titan Text Embedding hoặc Cohere Text Embedding chỉ nhận đầu vào chuỗi ký tự; chúng không thể trực tiếp nhận hình ảnh.

2. Multi-modal generation model

   • Mô tả: Loại mô hình này được thiết kế để tạo ra nội dung (ví dụ: tạo ảnh từ mô tả văn bản, hoặc tạo mô tả văn bản cho ảnh). Nó không tập trung vào việc tạo vector đại diện để so sánh, mà tập trung vào output generation.
   • AWS context: Ví dụ Amazon Bedrock “Titan Multimodal Generation” hay Stable Diffusion (được hỗ trợ trên Bedrock) chuyên tạo ảnh, không phù hợp cho nhiệm vụ tìm kiếm.

3. Image generation model

   • Mô tả: Chỉ tạo hình ảnh mới dựa trên prompt (text) hoặc các điều kiện khác. Không thực hiện embedding và không hỗ trợ truy vấn kết hợp text‑image.
   • AWS context: Các model như Stable Diffusion, Midjourney‑style được cung cấp qua Bedrock là ví dụ điển hình. Chúng không giải quyết yêu cầu “search”.

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

• Amazon Bedrock Documentation – “Multimodal Embedding Models” (phiên bản cập nhật 2026).
• AWS Whitepaper: “Building Retrieval‑Augmented Generation (RAG) and Vector Search on AWS” (2025).
• Kendra Developer Guide – Using Vector Indexes (2026).
• Meta LLaVA‑Embedding Model Release Note, 2025 – hỗ trợ text + image embedding.
• Cohere Multimodal Embedding API Reference, cập nhật 2026.

🛠️ Gợi ý triển khai thực tế trên AWS

1. Chọn mô hình: Ví dụ Titan Multimodal Embedding từ Amazon Bedrock.
2. Xây dựng pipeline:
   • Input: Nhận query (text + image).
   • Embedding: Gọi API Bedrock InvokeModel để nhận vector embedding đa phương tiện.
   • Lưu trữ: Đưa vector vào Amazon OpenSearch Serverless với vector fields (kỹ thuật k‑NN).
   • Tìm kiếm: Sử dụng OpenSearch knn query để lấy tài liệu có similarity cao nhất.
3. Mở rộng: Kết hợp với Amazon Kendra để bổ sung khả năng tìm kiếm dựa trên metadata và tính năng RAG.

Tóm lại, để thiết kế một ứng dụng tìm kiếm chấp nhận truy vấn kết hợp text + image, Multi‑modal embedding model là lựa chọn đúng vì nó cung cấp vector biểu diễn thống nhất cho cả hai loại dữ liệu, cho phép thực hiện vector similarity search một cách hiệu quả trên hạ tầng AWS hiện đại. 🚀

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

Công ty đang sử dụng foundation model (FM) trên Amazon Bedrock để xây dựng công cụ tìm kiếm AI. Muốn “fine‑tune” (tinh chỉnh) mô hình sao cho đáp ứng tốt hơn với dữ liệu nội bộ của mình.
Câu hỏi hỏi: “Which strategy will successfully fine‑tune the model?” – tức là chúng ta cần chọn cách chuẩn bị và cung cấp dữ liệu (hoặc cấu hình dịch vụ) sao cho quá trình fine‑tuning trên Bedrock thành công.

📌 Những yếu tố quan trọng về fine‑tuning trên Amazon Bedrock (đến năm 2026)

• Bedrock hỗ trợ tinh chỉnh các foundation model của Amazon (Titan, Claude, Llama 2, …) thông qua API “CreateFineTuneJob”.
• Dữ liệu đầu vào phải ở định dạng JSONL (mỗi dòng là một JSON object) chứa hai trường bắt buộc:
  • prompt – đoạn văn bản đưa vào mô hình (câu hỏi, mô tả, …).
  • completion – kết quả mong muốn (câu trả lời, nhãn, …).
• Các trường này phải được gán nhãn (labeled) để mô hình học “prompt → completion”.
• Không cần tạo file .txt dạng CSV; Bedrock sẽ không chấp nhận định dạng CSV hay plain‑text không có cấu trúc JSONL.
• “Provisioned Throughput” là tính năng đối với inference (tốc độ đáp ứng) chứ không liên quan tới việc đào tạo hay fine‑tune.
• Việc “train the model on journals and textbooks” không phải là chiến lược fine‑tune trong Bedrock; đó là pre‑training quy mô lớn, đòi hỏi hạ tầng và giấy phép khác, không được hỗ trợ trực tiếp qua API Bedrock.

Vì vậy, chiến lược đúng là cung cấp dữ liệu đã gán nhãn, bao gồm trường prompt và completion theo định dạng JSONL.

✅ Đáp án đúng

🔹 Provide labeled data with the prompt field and the completion field.

• Lý do: Đây là định dạng chuẩn yêu cầu bởi API CreateFineTuneJob của Amazon Bedrock. Mỗi bản ghi JSON phải có prompt (đầu vào) và completion (đầu ra mong muốn). Khi dữ liệu được chuẩn bị như vậy, Bedrock sẽ tự động thực hiện quá trình fine‑tuning và tạo ra một model version mới, sẵn sàng cho inference.

❌ Các đáp án sai và giải thích

1. 🔸 Prepare the training dataset by creating a .txt file that contains multiple lines in .csv format.

   • Sai vì: Bedrock không hỗ trợ file .txt hoặc .csv làm đầu vào cho fine‑tuning. Dữ liệu phải ở định dạng JSONL (mỗi dòng một JSON object). Định dạng CSV không chứa thông tin cấu trúc prompt/completion, vì vậy dịch vụ sẽ không nhận dạng được mục tiêu học.

2. 🔸 Purchase Provisioned Throughput for Amazon Bedrock.

   • Sai vì: Provisioned Throughput là tùy chọn tăng tốc độ trả lời (inference) cho các endpoint đã triển khai, không có ảnh hưởng tới quá trình đào tạo hoặc fine‑tuning. Việc mua Provisioned Throughput không giúp mô hình học được dữ liệu mới.

3. 🔸 Train the model on journals and textbooks.

   • Sai vì: Đề cập tới pre‑training trên nguồn dữ liệu quy mô lớn (journals, textbooks). Điều này không phải là fine‑tuning được hỗ trợ qua Bedrock và không đáp ứng yêu cầu “using the company's data”. Thêm vào đó, việc pre‑train trên tài liệu công cộng không được phép nếu không có quyền bản quyền và không được Bedrock cung cấp API cho việc này.

🛠️ Các bước thực hiện fine‑tune đúng (theo tài liệu Bedrock 2026)

1. Chuẩn bị dữ liệu

   • Định dạng JSONL. Ví dụ:

     {"prompt":"Câu hỏi: Tìm kiếm sản phẩm X", "completion":"Kết quả: Sản phẩm X có sẵn tại kho A"}
     {"prompt":"Câu hỏi: Giá của dịch vụ Y", "completion":"Kết quả: 199 USD/tháng"}
     

   • Đảm bảo mỗi bản ghi được gán nhãn (có prompt và completion rõ ràng).

2. Upload dataset lên Amazon S3 (đường dẫn S3 phải có quyền đọc cho Bedrock).

3. Tạo job fine‑tune bằng AWS CLI, SDK hoặc Console:

   aws bedrock create-fine-tune-job \
       --model-identifier "amazon.titan-text-v2:0" \
       --training-data-config "S3Uri=s3://my-bucket/fine-tune-data.jsonl" \
       --output-data-config "S3Uri=s3://my-bucket/output/"
   

4. Giám sát tiến độ qua AWS CloudWatch và AWS Step Functions (nếu cần orchestrate).

5. Khi job hoàn thành, đăng ký endpoint cho model đã fine‑tuned và (nếu muốn) đặt Provisioned Throughput để tối ưu latency.

📚 Tham khảo tài liệu (2026)

• Amazon Bedrock Developer Guide – Fine‑tuning foundation models (phiên bản 2026‑03).
  https://docs.aws.amazon.com/bedrock/latest/devguide/finetuning.html
• AWS CLI Command Reference – create-fine-tune-job (phiên bản 2026).
  https://docs.aws.amazon.com/cli/latest/reference/bedrock/create-fine-tune-job.html
• AWS Blog – “Introducing Fine‑tuning on Amazon Bedrock” (2025‑11).
  https://aws.amazon.com/blogs/aws/introducing-fine-tuning-on-amazon-bedrock/

🧩 Tóm tắt nhanh

• ✅ Cung cấp dữ liệu có nhãn, gồm prompt và completion → Đúng.
• ❌ File .txt CSV → Sai, không đúng định dạng.
• ❌ Mua Provisioned Throughput → Sai, chỉ liên quan tới inference.
• ❌ Train trên journals/textbooks → Sai, không phải fine‑tune và không dùng dữ liệu công ty.

Hy vọng phân tích trên giúp bạn nắm rõ cách “fine‑tune” mô hình trên Amazon Bedrock một cách chuẩn xác! 🚀

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

• Mục tiêu: Công ty muốn dùng trí tuệ nhân tạo (AI) để bảo vệ ứng dụng trước các mối đe dọa.
• Yêu cầu cụ thể: Hệ thống AI cần kiểm tra xem một địa chỉ IP có phải là nguồn đáng ngờ (suspicious source) hay không.
• Ngữ cảnh AWS: Đối với việc phát hiện IP “đáng ngờ”, AWS thường dùng các mô hình phát hiện bất thường (anomaly detection) hoặc các dịch vụ như Amazon GuardDuty, Amazon VPC Traffic Mirroring + SageMaker, nơi mà AI/ML phân tích hành vi mạng và so sánh với các mẫu “bình thường”.

Vì vậy, câu trả lời đúng là phát triển một hệ thống phát hiện bất thường (anomaly detection system), vì đây là cách tiếp cận AI phù hợp nhất để xác định IP có hành vi lạ so với lịch sử bình thường.

✅ Đáp án đúng

✔️ Develop an anomaly detection system.

• Lý do:

  • Anomaly detection (phát hiện bất thường) là kỹ thuật Machine Learning dùng để so sánh hành vi hiện tại (ví dụ: một IP mới, tần suất yêu cầu, vị trí địa lý) với mô hình “bình thường” đã học từ dữ liệu lịch sử.
  • Khi một IP xuất hiện với các đặc điểm bất thường (ví dụ: tần suất cao, vị trí không phù hợp, được liệt kê trong danh sách đen), hệ thống sẽ gán nó là “suspicious”.
  • Trên AWS, bạn có thể triển khai bằng Amazon SageMaker (built‑in algorithms như Random Cut Forest, XGBoost), Amazon Lookout for Metrics, hoặc tận dụng Amazon GuardDuty (được xây dựng trên mô hình anomaly detection để phát hiện IP đáng ngờ).

• Cập nhật đến 2026:

  • Amazon Lookout for Metrics (ra mắt 2023, liên tục cập nhật) cung cấp khả năng tự động phát hiện bất thường trên dữ liệu thời gian thực, bao gồm các chỉ số mạng.
  • Amazon SageMaker JumpStart cung cấp mẫu “Anomaly Detection with Random Cut Forest” đã được tối ưu cho phát hiện IP đáng ngờ.

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

• Build a speech recognition system.

  • Speech recognition (nhận dạng giọng nói) dùng để chuyển đổi âm thanh thành văn bản, không liên quan tới việc phân tích địa chỉ IP hay phát hiện các nguồn nguy hiểm.
  • Trên AWS, dịch vụ này là Amazon Transcribe, nhưng nó không có khả năng xử lý dữ liệu mạng.

• Create a natural language processing (NLP) named entity recognition system.

  • Named Entity Recognition (NER) trong NLP dùng để xác định các thực thể (person, organization, location…) trong văn bản.
  • Mặc dù NER có thể nhận diện “IP address” trong log text, nó không tự động đánh giá IP có đáng ngờ hay không; việc này cần một mô hình phân loại/bất thường, không phải NER.
  • Dịch vụ AWS liên quan: Amazon Comprehend, không phù hợp với yêu cầu bảo mật mạng.

• Create a fraud forecasting system.

  • Hệ thống fraud forecasting tập trung dự báo các hành vi gian lận tài chính (thẻ tín dụng, giao dịch thương mại điện tử).
  • Dù có thể áp dụng kỹ thuật tương tự (phát hiện bất thường), mục tiêu chính là dự đoán gian lận chứ không phải kiểm tra IP có phải nguồn đáng ngờ.
  • Trên AWS, các giải pháp như Amazon Fraud Detector được thiết kế cho kịch bản tài chính, không tối ưu cho kiểm tra IP mạng.

🛠️ Gợi ý triển khai thực tế trên AWS (2026)

1. Sử dụng Amazon GuardDuty

   • Dịch vụ managed threat detection dựa trên machine learning để phát hiện IP đáng ngờ, tài nguyên bị tấn công, và hành vi bất thường.
   • Kết hợp với AWS Security Hub để tập trung cảnh báo.

2. Xây dựng mô hình anomaly detection bằng Amazon SageMaker

   • Thu thập log mạng (VPC Flow Logs, CloudFront logs) vào Amazon S3.
   • Dùng SageMaker JumpStart – Random Cut Forest hoặc XGBoost để huấn luyện mô hình phân loại “suspicious vs normal”.
   • Triển khai mô hình dưới dạng SageMaker Endpoint và tích hợp vào AWS Lambda để kiểm tra IP mỗi khi có request.

3. Amazon Lookout for Metrics (được cập nhật năm 2025)

   • Đặt metric “Số lượng request per IP” → Lookout tự động phát hiện bất thường → Gửi cảnh báo qua Amazon SNS.

📚 Tham khảo tài liệu

• Amazon GuardDuty – How GuardDuty works (AWS Documentation, cập nhật 2026)
  https://docs.aws.amazon.com/guardduty/latest/ug/guardduty-how-it-works.html
• Amazon SageMaker JumpStart – Anomaly Detection with Random Cut Forest (2025)
  https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-anomaly-detection.html
• Amazon Lookout for Metrics – Detect anomalies in your data (2024)
  https://docs.aws.amazon.com/lookoutmetrics/latest/dev/what-is-lookout-for-metrics.html
• Amazon Fraud Detector – Use cases (2023) – để hiểu vì sao không phù hợp với kiểm tra IP.

Tóm lại: Để đáp ứng yêu cầu “kiểm tra IP có phải nguồn đáng ngờ” trong môi trường AWS, phát triển một hệ thống phát hiện bất thường (anomaly detection) là giải pháp phù hợp nhất. Các lựa chọn khác (speech recognition, NLP NER, fraud forecasting) không giải quyết được vấn đề bảo mật mạng. 🎯