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

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

Công ty mạng xã hội muốn ngăn người dùng đăng nội dung mang tính phân biệt đối xử.
Họ quyết định dùng Amazon Bedrock – dịch vụ nền tảng AI/ML của AWS, trong đó có tính năng Guardrails (các rào chắn nội dung) cho phép:

• Xác định các chủ đề/đầu vào không được chấp nhận (ví dụ: “hate speech”, “discrimination”, “harassment”).
• Chặn hoặc đánh dấu các tương tác chứa các chủ đề này trước khi chúng được trả về cho người dùng.

Vì vậy, câu trả lời đúng phải mô tả cách chặn (block) các tương tác liên quan tới các chủ đề đã định sẵn.

✅ Đáp án đúng

- Block interactions related to predefined topics.

Giải thích:

• Amazon Bedrock cung cấp Guardrails cho phép bạn định nghĩa pre‑defined topics (ví dụ: “racial slurs”, “gender discrimination”).
• Khi người dùng gửi yêu cầu, Bedrock sẽ kiểm tra nội dung và chặn (block) bất kỳ tương tác nào có chứa các chủ đề bị cấm, trả về thông báo lỗi hoặc phản hồi “content not allowed”.
• Đây chính là cơ chế đáp ứng yêu cầu “ngăn người dùng đăng nội dung phân biệt đối xử”.

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

• - Give users the ability to interact based on user preferences.

  • Giải thích: Tùy chọn này cho phép người dùng tự lựa chọn cách tương tác (ví dụ: tone, style). Nó không cung cấp cơ chế kiểm soát nội dung hay chặn những nội dung gây phân biệt. Vì vậy không đáp ứng yêu cầu ngăn chặn nội dung không mong muốn.

• - Restrict user conversations to predefined topics.

  • Giải thích: Câu này gợi ý rằng người dùng chỉ được đối thoại trong những chủ đề đã định. Guardrails của Bedrock không giới hạn toàn bộ cuộc trò chuyện vào một danh sách chủ đề, mà chặn các chủ đề bị cấm. Việc “giới hạn” toàn bộ nội dung sẽ làm giảm đáng kể tính năng của ứng dụng và không phải là cách Bedrock hoạt động.

• - Provide a variety of responses to select from for user engagement.

  • Giải thích: Cung cấp đa dạng câu trả lời là tính năng generation của mô hình AI (ví dụ: Claude, Titan). Nó không liên quan tới kiểm duyệt hay chặn nội dung phân biệt. Do đó không đáp ứng mục tiêu ngăn chặn nội dung tiêu cực.

🛠️ Cách triển khai thực tế (tóm tắt)

1. Tạo Guardrail trong Amazon Bedrock console hoặc qua API:

   • Định nghĩa “Disallowed topics” (e.g., hate speech, sexism).
   • Chọn action = BLOCK để trả về lỗi khi phát hiện.

2. Kết nối ứng dụng với Bedrock endpoint:

   import boto3
   client = boto3.client('bedrock-runtime')
   response = client.invoke_model(
       modelId='amazon.titan-text-v1',
       body={'prompt': user_input},
       guardrailId='guardrail-1234'   # ID của guardrail vừa tạo
   )
   

3. Xử lý phản hồi: nếu response['guardrailResult'] báo “BLOCKED”, hiển thị thông báo “Nội dung không được phép” cho người dùng.

📚 Tham khảo (cập nhật đến 2026)

• Amazon Bedrock Developer Guide – Guardrails
  https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
• AWS Blog – Using Guardrails for content moderation with Bedrock (2025)
  https://aws.amazon.com/blogs/aws/guardrails-content-moderation-bedrock/
• AWS Well‑Architected Framework – Security Pillar (2024‑2026 updates)
  https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html

Tóm lại:
🟢 Cách duy nhất đáp ứng yêu cầu ngăn người dùng đăng nội dung phân biệt là “Block interactions related to predefined topics” nhờ tính năng Guardrails của Amazon Bedrock. Các phương án còn lại either không liên quan tới việc kiểm soát nội dung hoặc mô tả sai cách hoạt động của Bedrock.

🧩 Câu hỏi phân tích

Một công ty giáo dục muốn xây dựng một ứng dụng cho phép người dùng nhập văn bản hoặc cung cấp ảnh của một câu hỏi. Ứng dụng sẽ trả lời bằng văn bản kèm giải thích chi tiết cho câu trả lời.

Yêu cầu: chọn loại mô hình nào đáp ứng được cả việc nhận đầu vào đa dạng (text + image) và đầu ra là văn bản có giải thích.

✅ Đáp án đúng

✅ Large multi‑modal language model

👉 Lý do lựa chọn

• Multi‑modal → mô hình có khả năng “hiểu” và xử lý đồng thời văn bản và hình ảnh (ví dụ: Amazon Titan Multimodal, Anthropic Claude‑3.5 Multimodal trên Amazon Bedrock, hay các mô hình Llama‑2‑Vision trên SageMaker).
• Large language model → được huấn luyện trên khối lượng dữ liệu khổng lồ, có khả năng tạo ra câu trả lời bằng văn bản và giải thích chi tiết, phù hợp với yêu cầu “written answer + explanation”.
• AWS cung cấp các service như Amazon Bedrock và Amazon SageMaker JumpStart cho phép triển khai nhanh các mô hình đa phương tiện này, đồng thời hỗ trợ inference ở mức độ low‑latency cho các ứng dụng thời gian thực trong giáo dục.

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

1. Computer vision model

   • Chỉ tập trung vào phân tích hình ảnh (phân loại, phát hiện đối tượng, trích xuất đặc trưng).
   • Không có khả năng tạo nội dung văn bản hoặc giải thích câu trả lời, nên không đáp ứng được phần “written answer”.
   • Ví dụ AWS: Amazon Rekognition hoặc các mô hình Vision‑only trên SageMaker (ResNet, EfficientNet) → chỉ trả về nhãn/độ tin cậy, không sinh ra văn bản mô tả chi tiết.

2. Diffusion model

   • Mô hình tạo ra hình ảnh (ví dụ: Stable Diffusion) bằng cách mô phỏng quá trình nhiễu và khử nhiễu.
   • Chúng không được thiết kế để hiểu nội dung câu hỏi hoặc viết câu trả lời bằng văn bản.
   • Trên AWS, diffusion model được cung cấp qua SageMaker JumpStart để sinh ảnh, không phù hợp với yêu cầu câu hỏi‑trả lời.

3. Text‑to‑speech model

   • Chức năng chính là chuyển đổi văn bản thành âm thanh (speech synthesis).
   • Không hỗ trợ đầu vào hình ảnh và không thực hiện phân tích câu hỏi; chỉ nhận văn bản đã có sẵn và xuất ra audio.
   • AWS cung cấp Amazon Polly hoặc các mô hình TTS trên Bedrock, nhưng chúng không đáp ứng yêu cầu “câu hỏi đa dạng + trả lời bằng văn bản + giải thích”.

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

• Amazon Bedrock – Model Catalog (2024‑2026): mô tả các mô hình đa phương tiện như Titan Multimodal và Claude‑3.5 Multimodal → https://docs.aws.amazon.com/bedrock/latest/userguide/model-catalog.html
• Amazon SageMaker JumpStart – Multimodal LLMs (phiên bản 2.0, 2025): cung cấp các mẫu triển khai nhanh cho LLM + Vision → https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-multimodal.html
• AWS Well‑Architected Framework – Machine Learning Pillar (2025): khuyến nghị chọn mô hình đáp ứng cả input type và output format cho ứng dụng AI đa dạng → https://aws.amazon.com/architecture/well-architected/machine-learning/

🔧 Kết luận nhanh

• Large multi‑modal language model ✅ là lựa chọn duy nhất đáp ứng đầu vào text + image và đầu ra văn bản có giải thích.
• Các mô hình còn lại (Computer vision, Diffusion, Text‑to‑speech) chỉ tập trung vào một khía cạnh duy nhất (hình ảnh, sinh ảnh, hoặc chuyển đổi văn bản sang giọng nói) và không thể thực hiện nhiệm vụ toàn diện của ứng dụng giáo dục này.

💡 Khi triển khai trên AWS, bạn có thể dùng Amazon Bedrock để gọi API của Titan Multimodal hoặc Claude‑3.5 Multimodal, hoặc tự huấn luyện một mô hình tương tự trên SageMaker nếu muốn tùy chỉnh sâu hơn.

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

In which stage of the generative AI model lifecycle are tests performed to examine the model's accuracy?

Câu hỏi yêu cầu xác định giai đoạn nào trong vòng đời một mô hình AI sinh ra (generative AI) mà chúng ta thực hiện các bài kiểm tra (tests) để đánh giá độ chính xác của mô hình. “Lifecycle” ở đây đề cập tới chuỗi các bước chuẩn bị, huấn luyện và vận hành mô hình – một khái niệm được AWS mô tả chi tiết trong tài liệu Amazon SageMaker Model Building Pipelines và Amazon Bedrock (cập nhật đến năm 2026).

Các giai đoạn thường gặp:

1. Data selection / Collection – thu thập và lựa chọn dữ liệu nguồn.
2. Data preprocessing / Feature engineering – làm sạch, chuẩn hoá dữ liệu.
3. Training – huấn luyện mô hình ban đầu.
4. Fine‑tuning – tinh chỉnh mô hình trên tập dữ liệu chuyên biệt.
5. Evaluation – kiểm tra, đo lường các chỉ số (accuracy, precision, recall, F1, …) bằng cách chạy các test trên tập validation / test.
6. Deployment – triển khai mô hình vào môi trường production (endpoint, inference).
7. Monitoring & Continuous Improvement – giám sát hiệu suất và thực hiện retraining nếu cần.

🧩 Điểm then chốt: Kiểm tra độ chính xác (accuracy) là hoạt động đánh giá (evaluation). Trong giai đoạn này, chúng ta chạy các test set (các mẫu chưa từng thấy) và tính toán các metric để quyết định mô hình có đủ tiêu chuẩn để đưa vào production hay không.

✅ Đáp án đúng

🔹 Evaluation

• Lý do: Ở giai đoạn Evaluation, các bài kiểm tra (tests) được thực hiện trên validation set và test set để đo lường độ chính xác và các chỉ số chất lượng khác của mô hình. AWS khuyến nghị sử dụng SageMaker Clarify, SageMaker Model Monitor, và SageMaker Pipelines để tự động hoá quá trình đánh giá. Đây là bước quyết định mô hình có đủ chuẩn để chuyển sang Deployment hay cần quay lại Fine‑tuning.

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

• Deployment

  • Giải thích: Deployment là giai đoạn triển khai mô hình đã được đánh giá thành công lên môi trường production (SageMaker Endpoint, AWS Lambda, hoặc Amazon Bedrock). Ở đây chúng ta không thực hiện các test đo độ chính xác; thay vào đó, chúng ta thường thực hiện monitoring (giám sát) để phát hiện drift, chứ không phải đánh giá ban đầu.

• Data selection

  • Giải thích: Data selection (hoặc data collection) là giai đoạn chọn lựa và thu thập dữ liệu dùng để huấn luyện. Mặc dù việc chọn dữ liệu ảnh hưởng tới độ chính xác cuối cùng, nhưng không phải là giai đoạn thực hiện các test để đo độ chính xác của mô hình. Các test ở đây thường là data quality checks, không phải model accuracy tests.

• Fine‑tuning

  • Giải thích: Fine‑tuning là tinh chỉnh mô hình đã được pre‑trained trên một tập dữ liệu chuyên biệt. Trong quá trình fine‑tuning, có thể thực hiện một số validation checks, nhưng đánh giá độ chính xác cuối cùng vẫn được thực hiện ở giai đoạn Evaluation. Fine‑tuning chủ yếu tập trung vào việc cập nhật trọng số, không phải đo lường chính xác tổng thể.

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

1. Amazon SageMaker Documentation – Model Building Pipelines
   https://docs.aws.amazon.com/sagemaker/latest/dg/pipelines.html
2. Amazon SageMaker Clarify – Evaluating Model Bias & Accuracy
   https://docs.aws.amazon.com/sagemaker/latest/dg/clarify.html
3. AWS Blog – Best practices for evaluating generative AI models on Amazon Bedrock (2025)
   https://aws.amazon.com/blogs/machine-learning/evaluating-generative-ai-models/
4. AWS Well‑Architected Framework – Machine Learning Pillar (cập nhật 2026)
   https://aws.amazon.com/architecture/well-architected/machine-learning/

🛠️ Kết luận:
Trong vòng đời mô hình AI sinh ra, giai đoạn Evaluation là thời điểm thực hiện các bài kiểm tra để đánh giá độ chính xác của mô hình. Các giai đoạn khác như Deployment, Data selection và Fine‑tuning không phải là nơi thực hiện các test đánh giá độ chính xác cuối cùng. ✅

📝 Phân tích câu hỏi
Câu hỏi: “Which statement correctly describes embeddings in generative AI?”
Yêu cầu: chọn câu mô tả đúng về embeddings – một khái niệm cốt lõi trong các mô hình ngôn ngữ lớn (LLM), tìm kiếm vector và các ứng dụng AI sinh tạo.

🔍 Nội dung cần nắm:

• Embeddings là cách chuyển đổi dữ liệu (văn bản, ảnh, âm thanh, …) thành vector đa chiều (thường có hàng trăm hoặc hàng nghìn chiều).
• Các vector này được học sao cho các đối tượng có ý nghĩa ngữ nghĩa hoặc ngữ cảnh tương tự sẽ có khoảng cách Euclid / cosine gần nhau trong không gian vector.
• Nhờ vậy, embeddings cho phép so sánh, tìm kiếm, gộp nhóm, hoặc làm đầu vào cho các mô hình sinh tạo (GPT, Stable Diffusion, …).

✅ Đáp án đúng

- Embeddings represent data as high-dimensional vectors that capture semantic relationships.

🎯 Lý do chọn

• High‑dimensional vectors: Các embeddings thường có 128‑4096 chiều (hoặc hơn) tùy mô hình.
• Capture semantic relationships: Khi huấn luyện, mô hình tối ưu hoá sao cho các token, câu, hay hình ảnh có ý nghĩa gần nhau sẽ tạo ra các vector có cosine similarity cao. Điều này chính là “semantic similarity” – nền tảng của tìm kiếm vector, clustering, và đầu vào cho các mô hình sinh tạo.
• Đây là định nghĩa chuẩn được dùng trong tài liệu AWS (ví dụ Amazon SageMaker JumpStart, Amazon Bedrock, và Amazon Kendra) và trong tài liệu học máy hiện đại (paper Word2Vec, BERT, CLIP,...).

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

• Embeddings is a technique that searches data to find the most helpful information to answer natural language questions.

  • Giải thích: Embeddings không phải là kỹ thuật tìm kiếm; chúng chỉ là đại diện vector của dữ liệu. Việc “tìm kiếm” dựa trên embeddings (ví dụ vector similarity search) là một bước sau khi đã tạo embeddings, chứ không phải bản chất của embeddings. Vì vậy mô tả này nhầm lẫn giữa representation và retrieval.

• Embeddings reduce the hardware requirements of a model by using a less precise data type for the weights and activations.

  • Giải thích: Đây là mô tả của quantization (giảm độ chính xác của trọng số/activations) chứ không phải embeddings. Embeddings thường được lưu dưới dạng float32 hoặc float16 (hoặc bfloat16) và không tự động giảm yêu cầu phần cứng. Thực tế, nếu số lượng embeddings lớn (ví dụ hàng tỷ token), chúng có thể tăng yêu cầu bộ nhớ lưu trữ.

• Embeddings provide the ability to store and retrieve data for generative AI applications.

  • Giải thích: Lại nhầm lẫn giữa representation và storage/retrieval. Embeddings chỉ là cách biểu diễn dữ liệu; việc “lưu trữ và truy xuất” phụ thuộc vào hệ thống vector database (Amazon OpenSearch with k‑NN, Amazon DynamoDB + Milvus, hoặc Amazon RDS). Do đó câu này mô tả chức năng phụ trợ, không phải bản chất của embeddings.

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

1. AWS Documentation – Amazon SageMaker JumpStart: “Embedding models transform raw data into high‑dimensional vectors that capture semantic meaning.”
2. AWS Documentation – Amazon Bedrock: “You can generate embeddings with foundation models (e.g., Titan Embeddings) to power semantic search and recommendation.”
3. Amazon Kendra Developer Guide: “Kendra indexes documents using embeddings to understand context and relevance.”
4. Research papers: Mikolov et al., Word2Vec (2013); Devlin et al., BERT (2018); Radford et al., CLIP (2021) – all describe embeddings as high‑dimensional semantic vectors.
5. AWS re:Invent 2023‑2025 Sessions – “Scaling Vector Search on AWS with OpenSearch k‑NN and Amazon Aurora Serverless” – clarifies the separation between embeddings and vector search.

🧩 Tổng kết

• Câu đúng: Embeddings represent data as high-dimensional vectors that capture semantic relationships.
• Các đáp án còn lại đều nhầm lẫn giữa embeddings (đại diện dữ liệu) và các kỹ thuật/đặc tính khác như tìm kiếm, quantization, hoặc lưu trữ.

Hi vọng giải thích chi tiết trên giúp bạn nắm vững khái niệm embeddings trong AI sinh tạo và phân biệt chúng với các công nghệ liên quan! 🚀

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

A company wants to add generative AI functionality to its application by integrating a large language model (LLM). The responses from the LLM must be as deterministic and as stable as possible. Which solution meets these requirements?

Câu hỏi yêu cầu đảm bảo tính xác định (deterministic) – tức là cùng một prompt, cùng một cấu hình, mô hình luôn trả về kết quả giống nhau. Trong các LLM (ví dụ Amazon Bedrock’s Claude, Titan, hoặc các mô hình OpenAI), tính xác định được điều khiển chủ yếu bằng tham số temperature và một số tham số phụ khác (top‑p, top‑k). Khi temperature = 0 (hoặc gần 0), mô hình sẽ luôn chọn token có xác suất cao nhất, do đó giảm thiểu sự ngẫu nhiên và cho ra kết quả ổn định. Các kỹ thuật “đặt câu lệnh trong prompt” (prompt engineering) không thay thế được việc điều chỉnh các siêu‑tham số mô hình.

✅ Đáp án đúng

🟢 Configure the application to automatically set the temperature parameter to 0 when submitting the prompt to the LLM.

Giải thích:

• Tham số temperature quyết định mức độ ngẫu nhiên của quá trình sinh token.
• Khi temperature = 0, mô hình luôn chọn token có xác suất lớn nhất, vì vậy đầu ra trở nên deterministic và stable.
• Đây là cách chuẩn được khuyến nghị trong tài liệu AWS Bedrock và các nhà cung cấp LLM khác để đạt tính nhất quán.
• AWS Bedrock cho phép thiết lập temperature khi gọi InvokeModel hoặc thông qua SDK; giá trị 0.0 sẽ “turn off randomness”.

Tham khảo:

• Amazon Bedrock Developer Guide – “Controlling model output with temperature, top‑p, and top‑k” (phiên bản 2026).
• OpenAI API Documentation – “temperature” parameter (được cập nhật tới 2026).

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

• 🟠 Configure the application to automatically add "make your response deterministic" at the end of the prompt before submitting the prompt to the LLM.

  • Việc thêm câu lệnh vào prompt không thay đổi cách mô hình lựa chọn token; LLM không có “hiểu” rằng câu lệnh này sẽ tắt tính ngẫu nhiên.
  • Prompt engineering có thể ảnh hưởng tới nội dung, nhưng không kiểm soát được randomness; do đó không bảo đảm tính deterministic.

• 🟠 Configure the application to automatically add "make your response deterministic" at the beginning of the prompt before submitting the prompt to the LLM.

  • Tương tự như trên, vị trí của câu lệnh (đầu hay cuối) không làm thay đổi cơ chế nội bộ của mô hình.
  • Các mô hình hiện tại (Claude, Titan, GPT‑4, v.v.) không có token đặc biệt để kích hoạt “deterministic mode” thông qua prompt.

• 🟠 Configure the application to automatically set the temperature parameter to 1 when submitting the prompt to the LLM.

  • temperature = 1 là giá trị cao nhất (hoặc gần cao nhất) mà mô hình sẽ sinh ra các token có xác suất thấp hơn, tạo ra độ ngẫu nhiên lớn.
  • Kết quả sẽ không deterministic và có thể thay đổi đáng kể giữa các lần gọi, trái ngược hoàn toàn với yêu cầu.

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

1. Sử dụng Amazon Bedrock

   • Khi gọi InvokeModel qua SDK (Python boto3, Java, v.v.), truyền tham số:

     {
       "prompt": "...",
       "temperature": 0.0,
       "maxTokens": 512,
       "topP": 1.0,
       "topK": 0
     }
     

   • Đảm bảo rằng các giá trị top‑p/top‑k không gây ra randomness bổ sung (giá trị mặc định topP=1.0 và topK=0 là an toàn).

2. Kiểm tra tính deterministic

   • Thực hiện multiple invocations với cùng prompt và cùng cấu hình; các phản hồi phải giống hệt nhau.
   • Nếu phát hiện khác biệt, kiểm tra lại phiên bản mô hình (một số phiên bản mới có cập nhật trọng số gây ra thay đổi nhẹ) và đảm bảo không có biến môi trường hoặc header gây randomness.

3. Quản lý phiên bản mô hình

   • Khi sử dụng Bedrock, bạn có thể đặt modelId cụ thể (ví dụ anthropic.claude-v2:0) để tránh việc mô hình tự động cập nhật lên phiên bản mới có thể thay đổi hành vi.

4. Giám sát & Logging

   • Ghi lại temperature và prompt vào CloudWatch Logs để dễ dàng audit và debug khi có vấn đề về tính ổn định.

📚 Tài liệu tham khảo

• Amazon Bedrock Developer Guide (2026 edition) – Chapter “Model Parameters”.
• AWS re:Invent 2025 – Session “Best Practices for Using Generative AI on AWS” – Slides & video.
• OpenAI API Documentation (2026) – Section “temperature”.
• Anthropic Claude Documentation (2026) – “Controlling Output Variability”.

💡 Kết luận: Để đạt được tính deterministic và ổn định cao nhất khi tích hợp LLM, cần đặt temperature về 0 (hoặc gần 0) trong yêu cầu API. Các phương án dựa vào prompt engineering không đảm bảo tính ổn định và do đó là sai.

🔎 Phân tích câu hỏi
Công ty muốn chọn một mô hình AI sinh tạo (generative AI) để xây dựng một ứng dụng trả lời người dùng theo thời gian thực (real‑time). Vì vậy, yếu tố quan trọng nhất là độ nhanh của quá trình suy luận (inference) – thời gian cần để mô hình nhận một yêu cầu (prompt) và trả về kết quả. Khi độ trễ (latency) thấp, người dùng sẽ cảm nhận được phản hồi “ngay lập tức”.

✅ Đáp án đúng: Inference speed

Lý do lựa chọn:

• Inference speed đo lường latency của mô hình khi xử lý một yêu cầu. Đối với các ứng dụng thời gian thực (chatbot, trợ lý ảo, dịch vụ trả lời câu hỏi...), latency thường phải dưới 100‑200 ms để cảm giác “ngay lập tức”.
• Trên AWS, bạn có thể tối ưu inference speed bằng:
  • Amazon SageMaker Serverless Inference hoặc SageMaker Multi‑Model Endpoints để giảm thời gian khởi động (cold start).
  • Elastic Inference, AWS Inferentia hoặc GPU‑tuned instances (p4d, g6) để tăng tốc độ xử lý.
  • Amazon Bedrock cung cấp các “model endpoints” được tối ưu sẵn latency < 100 ms cho một số mô hình LLM.
• Khi latency đáp ứng được yêu cầu thời gian thực, trải nghiệm người dùng sẽ tốt hơn và chi phí có thể được kiểm soát (bạn không cần triển khai mô hình quá lớn chỉ để “đảm bảo” tốc độ).

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

• Model complexity

  • Complexity (độ phức tạp) mô tả số lượng tham số, kiến trúc mạng, v.v. Mô hình phức tạp thường tốt hơn về độ chính xác, nhưng lại tăng latency và chi phí inference. Độ phức tạp không phải là tiêu chí quyết định khi mục tiêu là thời gian thực; ngược lại, bạn thường muốn đơn giản hoá mô hình (hoặc dùng kỹ thuật quantization, pruning) để giảm latency.

• Innovation speed

  • Innovation speed ám chỉ tốc độ mà nhà cung cấp hoặc cộng đồng phát triển, cập nhật mô hình mới. Đây là yếu tố quan trọng khi cân nhắc độ mới, tính năng của mô hình, nhưng không ảnh hưởng trực tiếp tới thời gian phản hồi của ứng dụng. Một mô hình mới có thể vẫn chậm nếu không tối ưu inference.

• Training time

  • Training time là thời gian cần để huấn luyện mô hình từ dữ liệu. Đây là chi phí trước khi triển khai và không liên quan tới độ trễ khi phục vụ yêu cầu. Một mô hình có thời gian huấn luyện dài không đồng nghĩa với việc nó sẽ nhanh hơn hay chậm hơn khi inference.

📚 Tham khảo (cập nhật đến 2026)

1. Amazon SageMaker Developer Guide – Inference
   https://docs.aws.amazon.com/sagemaker/latest/dg/inference.html (được cập nhật thường xuyên, bao gồm phần về latency và các tùy chọn tối ưu).

2. Amazon Bedrock Documentation – Model Endpoints
   https://docs.aws.amazon.com/bedrock/latest/userguide/model-endpoints.html (cung cấp thông tin về latency mục tiêu cho các mô hình LLM).

3. AWS Architecture Blog – Reducing Latency for Generative AI (2025)
   https://aws.amazon.com/blogs/architecture/reducing-latency-for-generative-ai/ (chiến lược tối ưu inference trên AWS Inferentia, GPU, và serverless).

4. AWS re:Invent 2025 Session – “Real‑time Generative AI at Scale”
   Video và slide trình bày các best‑practice để đạt latency < 100 ms.

🛠️ Gợi ý thực tiễn cho DevOps Engineer

• Triển khai endpoint với Provisioned Concurrency (SageMaker) hoặc Provisioned Throughput (Bedrock) để tránh cold‑start latency.
• Sử dụng Elastic Inference hoặc AWS Inferentia2 cho mô hình LLM lớn, giảm thời gian inference mà vẫn giữ chi phí hợp lý.
• Áp dụng quantization (INT8, FP16) và model compilation (AWS Neuron) để rút ngắn latency.
• Giám sát latency bằng Amazon CloudWatch Latency Metrics và thiết lập alarm khi vượt ngưỡng SLA (ví dụ: > 150 ms).

Tóm lại: Để đáp ứng yêu cầu “phản hồi thời gian thực”, công ty cần chú trọng vào Inference speed của mô hình, vì đây là yếu tố quyết định latency khi phục vụ người dùng. Các yếu tố khác như model complexity, innovation speed hay training time không liên quan trực tiếp tới thời gian phản hồi và do đó không phải là tiêu chí ưu tiên trong trường hợp này. 🚀

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

Which term refers to the instructions given to foundation models (FMs) so that the FMs provide a more accurate response to a question?

Câu hỏi đang hỏi về thuật ngữ dùng để chỉ “các chỉ dẫn / lời nhắc” mà chúng ta truyền cho foundation model (một mô hình ngôn ngữ lớn như Claude, Gemini, hoặc Amazon Titan) nhằm khiến mô hình trả lời một câu hỏi một cách chính xác, chi tiết hơn.

Trong lĩnh vực AI hiện đại (đặc biệt là Generative AI), thuật ngữ này được dùng rộng rãi trong tài liệu kỹ thuật, tutorial, và trong các dịch vụ AI của AWS (Amazon Bedrock, Amazon SageMaker JumpStart, …).

✅ Đáp án đúng

Prompt

• Lý do: “Prompt” là thuật ngữ chuẩn để mô tả chuỗi văn bản (hoặc cấu trúc) mà người dùng gửi tới mô hình nền tảng để yêu cầu nó thực hiện một tác vụ nào đó – ví dụ: trả lời câu hỏi, tạo nội dung, dịch thuật, … Khi prompt được thiết kế tốt (có hướng dẫn, ràng buộc, ngữ cảnh), mô hình sẽ tạo ra kết quả chính xác hơn.

• Cập nhật 2026: AWS đã cập nhật tài liệu Bedrock và SageMaker để nhấn mạnh “prompt engineering” là một kỹ năng quan trọng, với các công cụ như Prompt Builder, Prompt Tuning, và Prompt Templates.

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

1. Direction

   • Direction không phải là thuật ngữ chuyên ngành trong ngữ cảnh tương tác với mô hình ngôn ngữ. Nó có thể ám chỉ “hướng dẫn” chung, nhưng trong tài liệu AI của AWS và cộng đồng AI toàn cầu, không có định nghĩa nào gọi “direction” là phần đầu vào cho mô hình.
   • Khi nói “direction” trong AI, thường là một cụm từ phụ trong prompt (ví dụ: “Give directions on how to …”), chứ không phải là tên gọi của phần đầu vào.

2. Dialog

   • Dialog (đối thoại) đề cập tới chuỗi các lượt trò chuyện giữa người dùng và mô hình, tức là một phiên giao tiếp liên tiếp. Tuy nhiên, dialog không phải là “lời nhắc” duy nhất mà chúng ta đưa vào mô hình; nó là cấu trúc của một conversation.
   • AWS Bedrock cung cấp tính năng “Conversation Mode” cho các mô hình, nhưng thuật ngữ “dialog” không dùng để mô tả các chỉ dẫn ban đầu.

3. Translation

   • Translation là công việc dịch ngôn ngữ (ví dụ: từ tiếng Anh sang tiếng Việt). Đây là một tác vụ mà mô hình có thể thực hiện, nhưng không phải là “các chỉ dẫn” được cung cấp cho mô hình.
   • Khi bạn muốn mô hình thực hiện dịch, bạn sẽ đưa vào một prompt như “Translate the following text…”. Do vậy “translation” không phải là đáp án đúng.

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

• AWS Documentation – Amazon Bedrock Prompt Engineering
  https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-engineering.html
• Amazon SageMaker JumpStart – Prompt Tuning
  https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-prompt-tuning.html
• “Foundations of Prompt Engineering” – AWS AI Blog, 2025
  https://aws.amazon.com/blogs/ai/foundations-of-prompt-engineering/

🧩 Tổng kết

• Prompt là thuật ngữ chuẩn để chỉ “các chỉ dẫn” được đưa cho foundation models nhằm nhận được câu trả lời chính xác hơn.
• Các lựa chọn khác (Direction, Dialog, Translation) không mô tả đúng khái niệm này trong bối cảnh AI/ML hiện đại và tài liệu AWS.

👉 Khi chuẩn bị cho kỳ thi AWS Certified DevOps Engineer – Professional hay bất kỳ chứng chỉ AI nào, hãy nhớ rằng Prompt Engineering là kỹ năng cốt lõi, và “Prompt” luôn là đáp án đúng cho câu hỏi này.

🔍 Phân tích câu hỏi
Công ty bán lẻ muốn xây dựng một mô hình Machine Learning (ML) dùng để gợi ý sản phẩm cho khách hàng. Họ đặc biệt quan tâm tới “responsible ML practices” – nghĩa là phải giảm thiểu các nguồn gây ra bias (thiên lệch) trong mô hình.
Trong giai đoạn thu thập dữ liệu, việc lựa chọn nguồn dữ liệu, cách lấy mẫu và độ đa dạng của dữ liệu là những yếu tố then chốt để tránh việc mô hình học một cách thiên vị đối với một nhóm khách hàng nào đó.

✅ Đáp án đúng

🟢 Ensure that the data is balanced and collected from a diverse group.

Giải thích:

• Balanced data → Đảm bảo mỗi lớp (ví dụ: các nhóm tuổi, giới tính, khu vực địa lý, mức thu nhập…) có số lượng mẫu tương đương, tránh việc một lớp chiếm ưu thế và “đè” lên các lớp khác.
• Diverse group → Thu thập dữ liệu từ nhiều phân khúc khách hàng khác nhau (địa lý, ngôn ngữ, hành vi mua sắm, thiết bị truy cập…) giúp mô hình học được các mẫu đa dạng, giảm nguy cơ “phân biệt” khi dự đoán.
• Đây là nguyên tắc nền tảng trong AWS Well‑Architected Framework – Machine Learning Lens (2025) và các hướng dẫn của Amazon SageMaker Clarify (phiên bản 2026) về phát hiện & giảm bias. Khi dữ liệu cân bằng và đa dạng, các thuật toán ML sẽ ít có xu hướng học các quan hệ sai lệch dựa trên đặc tính không liên quan.

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

• ❌ Use data from only customers who match the demographics of the company's overall customer base.

  • Lý do sai: Việc chỉ lấy dữ liệu từ “đối tượng khớp với dân số tổng thể” không đảm bảo tính đa dạng thực tế. “Overall customer base” thường đã bị thiên lệch (ví dụ: tập trung ở một khu vực, một độ tuổi). Khi chỉ dùng nhóm này, mô hình sẽ không học được những hành vi của các nhóm khách hàng ngoại biên, dẫn tới bias khi dự đoán cho những khách hàng không thuộc nhóm mẫu.

• ❌ Collect data from customers who have a past purchase history.

  • Lý do sai: Dữ liệu chỉ từ khách hàng có lịch sử mua hàng bị giới hạn ở những người đã từng giao dịch, bỏ qua những khách hàng mới, tiềm năng hoặc những người không mua thường xuyên. Điều này tạo ra selection bias – mô hình sẽ ưu tiên đề xuất những mặt hàng phù hợp với khách hàng “cũ”, giảm khả năng khám phá sản phẩm mới cho người chưa mua.

• ❌ Ensure that the data is from a publicly available dataset.

  • Lý do sai: Dữ liệu công khai không nhất thiết đáp ứng yêu cầu độ cân bằng và đa dạng cho trường hợp cụ thể của công ty. Nhiều bộ dữ liệu mở (như Kaggle, UCI) có thể chứa bias sẵn có hoặc không phản ánh đúng đặc thù hành vi mua sắm của khách hàng công ty. Thay vào đó, công ty nên tự thu thập hoặc hợp tác để xây dựng bộ dữ liệu nội bộ cân bằng, đa dạng và tuân thủ quy định bảo mật dữ liệu (GDPR, CCPA, ...).

🧩 Áp dụng thực tế trên AWS (2026)

1. Amazon SageMaker Data Wrangler – giúp khai thác, làm sạch và cân bằng dữ liệu ngay trong pipeline.
2. SageMaker Clarify – tự động phát hiện bias trong tập train/validation và cung cấp metric (e.g., demographic parity, equalized odds).
3. SageMaker Feature Store – lưu trữ các đặc trưng đã được chuẩn hoá, đồng thời ghi lại metadata về nguồn gốc dữ liệu (độ đa dạng, thời gian thu thập).
4. AWS Glue DataBrew – công cụ không-code để thực hiện sampling cân bằng (stratified sampling) dựa trên các thuộc tính dân số học.
5. AWS Identity & Access Management (IAM) + AWS Lake Formation – bảo vệ dữ liệu nhạy cảm khi thu thập từ nhiều nhóm khách hàng, đồng thời tuân thủ principle of least privilege.

📚 Tham khảo

• AWS Well‑Architected Framework – Machine Learning Lens (v2, 2025) – phần “Data Quality & Bias Mitigation”.
• Amazon SageMaker Clarify Documentation (2026 Update) – các ví dụ về cách đo và giảm bias trong dữ liệu.
• AWS Machine Learning Blog – “Building Fair and Responsible ML Systems” (Mar 2026).
• AWS re:Invent 2025 Session “Responsible AI on AWS” – thực tiễn cân bằng dữ liệu và đa dạng hoá mẫu.

Tóm lại: Để giảm bias khi thu thập dữ liệu cho mô hình gợi ý sản phẩm, công ty cần đảm bảo dữ liệu cân bằng và lấy từ một nhóm đa dạng – đây là lựa chọn đúng. Các phương án còn lại đều không đáp ứng yêu cầu về giảm bias và có thể dẫn tới các vấn đề về công bằng và hiệu suất mô hình. 🚀

🔍 Phân tích câu hỏi
Câu hỏi đưa ra một tình huống thực tế: “Một công ty đang phát triển mô hình Machine Learning để dự đoán churn (rời bỏ) của khách hàng. Câu hỏi: Metric (đánh giá) nào sẽ đo lường hiệu năng của mô hình trong một bài toán binary classification như dự đoán churn?”

• “Binary classification” nghĩa là mô hình chỉ đưa ra hai nhãn: churn (có) hoặc không churn (không).
• Đánh giá mô hình trong trường hợp này cần một chỉ số phản ánh độ cân bằng giữa độ chính xác (precision) và độ thu hồi (recall), hoặc phản ánh khả năng phân biệt giữa hai lớp.
• Các metric phổ biến cho binary classification: Accuracy, Precision, Recall, F1‑score, ROC‑AUC, PR‑AUC, …

Câu hỏi yêu cầu chọn một metric phù hợp nhất, và trong các lựa chọn chỉ có F1 score là metric dành riêng cho bài toán phân loại nhị phân.

✅ Đáp án đúng: F1 score

Lý do chọn:

• F1 score là harmonic mean của Precision và Recall:
  [
  \text{F1} = 2 \times \frac{\text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}} ]
• Khi dữ liệu không cân bằng (ví dụ churn chỉ chiếm 5‑10 % tổng khách hàng), Accuracy có thể gây hiểu lầm, trong khi F1 cân bằng cả hai khía cạnh giảm false positives và giảm false negatives.
• Trong AWS SageMaker, khi cấu hình BinaryClassificationMetrics hoặc EvaluationMetric, F1 là một metric hợp lệ và thường được sử dụng để chọn mô hình tốt nhất.

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

1. F1 score

   • ✅ Là metric thiết kế riêng cho binary (và multi‑class) classification.
   • ✅ Đánh giá cân bằng giữa Precision và Recall, phù hợp khi lớp dương tính (churn) hiếm hơn.
   • ✅ Được hỗ trợ trực tiếp trong SageMaker‑built‑in algorithms (ví dụ XGBoost, Linear Learner) và trong sagemaker.estimator.Estimator thông qua metric_definitions.

2. Mean squared error (MSE)

   • ❌ MSE là metric cho regression, đo trung bình bình phương sai lệch giữa giá trị dự đoán và giá trị thực.
   • ❌ Không phản ánh đúng khả năng phân loại (có/không) vì nó không phân biệt giữa các ngưỡng quyết định.
   • ❌ Trong SageMaker, MSE chỉ được dùng khi bạn triển khai mô hình regression (ví dụ dự đoán giá trị bán hàng).

3. R-squared

   • ❌ R‑squared (Coefficient of Determination) cũng là metric cho regression, đo phần variance của dữ liệu được mô hình giải thích.
   • ❌ Không áp dụng cho bài toán binary classification; giá trị R‑squared luôn gần 0 hoặc âm khi dùng với nhãn 0/1.
   • ❌ SageMaker không cung cấp R‑squared trong BinaryClassificationMetrics.

4. Time used to train the model

   • ❌ Thời gian huấn luyện là độ đo hiệu suất (performance) của quá trình training, không phải đánh giá chất lượng dự đoán.
   • ❌ Một mô hình nhanh nhưng kém chính xác vẫn sẽ bị đánh giá thấp khi xét về độ chính xác dự đoán.
   • ❌ AWS SageMaker cung cấp TrainingJobSummary để theo dõi thời gian, nhưng đây không phải metric đánh giá mô hình.

📚 Tham khảo (tới 2026)

• AWS SageMaker Documentation – Built‑in Algorithms – Binary Classification Metrics (phiên bản 2026).
  https://docs.aws.amazon.com/sagemaker/latest/dg/built-in-algorithms-binary-classification.html
• Machine Learning Crash Course – Classification Metrics – Google (có phần giải thích chi tiết F1 vs. Accuracy).
  https://developers.google.com/machine-learning/crash-course/classification/metrics
• Hands‑On Machine Learning with Scikit‑Learn, Keras & TensorFlow, 3rd Edition (2024) – Chương về evaluation metrics.

🛠️ Gợi ý thực tiễn trên AWS

• Khi tạo training job trong SageMaker, thêm metric_definitions để tự động ghi nhận F1 score vào CloudWatch:

metric_definitions = [
    {"Name": "train:f1", "Regex": "f1 = ([0-9\\.]+)"}
]
estimator = sagemaker.estimator.Estimator(
    image_uri=container,
    role=role,
    instance_count=1,
    instance_type='ml.m5.xlarge',
    metric_definitions=metric_definitions,
    hyperparameters=hyperparameters
)

• Đối với model evaluation, dùng sklearn.metrics.f1_score trong notebook SageMaker Studio để tính F1 trên tập validation và truyền lại giá trị này cho ModelBias hoặc ModelExplainability để báo cáo.

Tóm lại:
Trong bối cảnh dự đoán churn (binary classification), F1 score là metric phù hợp nhất để đánh giá hiệu năng mô hình, còn các metric khác (MSE, R‑squared, thời gian huấn luyện) không phản ánh đúng chất lượng dự đoán. 🚀

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

Câu hỏi mô tả một tình huống trong Amazon SageMaker – một nhà thực hành AI (AI practitioner) cần chọn metric (chỉ số) để đo hiệu suất của mô hình phân loại.
Yêu cầu của metric là:

“Tỷ lệ của số mục được phân loại đúng so với tổng số mục được phân loại đúng + sai.”

Nói cách khác:

[ \text{Metric} = \frac{\text{Số dự đoán đúng (True Positives + True Negatives)}}{\text{Tổng số dự đoán (True Positives + True Negatives + False Positives + False Negatives)}} ]

Đây chính là định nghĩa của Accuracy trong thống kê và học máy.

✅ Đáp án đúng: Accuracy

• Lý do: Accuracy tính tỷ lệ phần trăm các mẫu mà mô hình dự đoán đúng (cả 2 lớp) trên toàn bộ mẫu kiểm tra. Công thức:

[ \text{Accuracy} = \frac{TP + TN}{TP + TN + FP + FN} ]

• Áp dụng trong SageMaker: Khi bạn chạy một training job hoặc batch transform và tạo một Evaluation trong SageMaker Model Monitor hoặc SageMaker Experiments, bạn có thể chỉ định accuracy như một metric để thu thập và hiển thị trên console. Đây là metric mặc định cho các bài toán phân loại nhị phân và đa lớp, và phù hợp với yêu cầu câu hỏi.

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

1. Precision

• Định nghĩa: Precision = TP / (TP + FP)
• Giải thích: Precision đo tỷ lệ các dự đoán dương tính đúng so với tổng số dự đoán dương tính (đúng + sai). Nó không tính tới các mẫu âm tính đúng (TN), vì vậy không phản ánh “tổng số mục được phân loại đúng + sai” mà câu hỏi yêu cầu.
• Kết luận: Không đáp ứng yêu cầu của câu hỏi.

2. F1 score

• Định nghĩa: F1 = 2 * (Precision * Recall) / (Precision + Recall)
• Giải thích: F1 là trung bình hài hòa giữa Precision và Recall, dùng để cân bằng khi dữ liệu mất cân đối. Công thức không đơn giản là “đúng / (đúng + sai)”, mà là một hàm phức tạp dựa trên cả Precision và Recall.
• Kết luận: Không phải là metric mà câu hỏi mô tả.

3. Recall

• Định nghĩa: Recall = TP / (TP + FN)
• Giải thích: Recall đo khả năng mô hình “phát hiện” tất cả các mẫu dương tính thực tế (có bao gồm FN). Nó bỏ qua các dự đoán âm tính đúng (TN) và các dự đoán dương tính sai (FP). Do đó, không đáp ứng tiêu chí “tổng số mục được phân loại đúng + sai”.
• Kết luận: Sai.

📚 Tham khảo & nguồn tài liệu (tính đến 2026)

1. AWS Documentation – Amazon SageMaker Model Monitoring

   • https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html
   • Mô tả cách cấu hình và thu thập các metric như accuracy, precision, recall, f1 trong các job.

2. AWS Certified DevOps Engineer – Professional Exam Guide (2026 Edition)

   • Chương “Machine Learning Ops” đề cập tới việc lựa chọn metric phù hợp cho mô hình dựa trên yêu cầu nghiệp vụ.

3. Scikit‑learn User Guide – Classification Metrics (phiên bản 1.5, 2026)

   • https://scikit-learn.org/stable/modules/model_evaluation.html#classification-metrics
   • Định nghĩa chuẩn của Accuracy, Precision, Recall, F1.

🧩 Tổng kết

• Câu hỏi yêu cầu một metric đo đúng / (đúng + sai) → Accuracy ✅
• Các metric còn lại (Precision, Recall, F1) đều tập trung vào các khía cạnh riêng (dương tính, âm tính, cân bằng) và không khớp với mô tả yêu cầu.

Hy vọng phân tích trên giúp bạn nắm rõ lý do lựa chọn Accuracy và hiểu được sự khác nhau giữa các metric trong bối cảnh đánh giá mô hình trên Amazon SageMaker. 🚀