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

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

• Bối cảnh: Công ty thương mại điện tử thu thập hàng gigabyte dữ liệu khách hàng mỗi ngày, dùng để huấn luyện mô hình Machine Learning (ML) dự báo nhu cầu sản phẩm.
• Yêu cầu: Thực hiện inference (dự đoán) một lần mỗi ngày.

👉 Khi khối lượng dữ liệu lớn và tần suất dự đoán thấp (chỉ một lần mỗi ngày), giải pháp nên xử lý dữ liệu theo batch – gửi toàn bộ dữ liệu vào một job duy nhất, để SageMaker thực hiện dự đoán trên toàn bộ tập dữ liệu và lưu kết quả. Đây là mô hình batch inference.

✅ Đáp án đúng

✅ Batch inference

Lý do chọn:

• Xử lý dữ liệu khối lượng lớn: Batch Transform (trước đây gọi là Batch Inference) của Amazon SageMaker hỗ trợ đưa vào từ vài GB tới hàng TB dữ liệu và thực hiện dự đoán trên toàn bộ tập một lần.
• Chi phí hiệu quả: Bạn chỉ trả phí cho thời gian job chạy, không cần duy trì endpoint luôn sẵn sàng.
• Thời gian thực không cần thiết: Vì yêu cầu chỉ một lần mỗi ngày, không cần latency thấp như real‑time inference.
• Tính tự động: Có thể lên lịch bằng Amazon EventBridge hoặc AWS Step Functions để khởi chạy job vào thời điểm mong muốn.

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

• Asynchronous inference

  • Mô tả: Dùng khi một yêu cầu inference có thời gian xử lý lâu (từ vài giây tới vài phút) và không cần trả lời ngay lập tức. Kết quả được lưu trữ (S3) và khách hàng lấy sau.
  • Tại sao sai: Mặc dù hỗ trợ khối lượng lớn, nó vẫn được thiết kế cho nhiều yêu cầu riêng lẻ (ví dụ hàng ngàn request mỗi phút) chứ không phải một job một lần ngày. Việc tạo endpoint bất đồng bộ cũng tạo chi phí và quản lý phức tạp hơn so với batch transform cho trường hợp này.

• Real-time inference

  • Mô tả: Dùng endpoint luôn bật, trả về kết quả ngay trong mili‑giây tới giây. Thích hợp cho ứng dụng yêu cầu latency thấp (ví dụ: gợi ý sản phẩm khi người dùng đang xem).
  • Tại sao sai: Đòi hỏi đặt endpoint luôn sẵn sàng, dẫn tới chi phí đồng thời (instance‑hour) cao dù chỉ thực hiện một lần dự đoán mỗi ngày. Không tận dụng được tính chất batch của dữ liệu.

• Serverless inference

  • Mô tả: SageMaker Serverless Inference tự động mở/đóng tài nguyên dựa trên lưu lượng truy cập, phù hợp cho khối lượng request không ổn định và độ trễ vừa phải.
  • Tại sao sai: Mặc dù không cần quản lý instance, nhưng nó vẫn hướng tới request‑by‑request (đánh đổi latency và chi phí theo số request). Với một batch lớn một lần mỗi ngày, việc dùng serverless sẽ gây độ trễ không tối ưu và không tận dụng tính năng “tối ưu chi phí cho batch job”.

🛠️ Các tài liệu tham khảo (cập nhật đến 2026)

1. Amazon SageMaker Batch Transform – Hướng dẫn cách tạo và chạy job batch inference.
   📘 https://docs.aws.amazon.com/sagemaker/latest/dg/batch-transform.html

2. Amazon SageMaker Asynchronous Inference – Khi nào nên dùng và cách cấu hình.
   📘 https://docs.aws.amazon.com/sagemaker/latest/dg/asynchronous-inference.html

3. Amazon SageMaker Real‑Time Inference – Kiến trúc endpoint và tính phí.
   📘 https://docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints.html

4. Amazon SageMaker Serverless Inference – Đối tượng sử dụng và mô hình tính phí.
   📘 https://docs.aws.amazon.com/sagemaker/latest/dg/serverless-inference.html

5. AWS Well‑Architected Framework – Machine Learning Lens (2025 update) – Khuyến nghị chọn batch inference cho workload dự báo nhu cầu ít lần, dữ liệu lớn.
   📘 https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/

🧩 Tóm tắt nhanh

• Batch inference → ✅ Phù hợp nhất: xử lý hàng GB dữ liệu, chạy một lần mỗi ngày, chi phí tối ưu.
• Asynchronous inference → ❌ Dành cho nhiều request chậm, không cần batch lớn.
• Real-time inference → ❌ Dành cho latency thấp, yêu cầu endpoint luôn bật.
• Serverless inference → ❌ Dành cho lưu lượng không ổn định, không tối ưu cho batch lớn một lần/ngày.

Với yêu cầu “một lần mỗi ngày” và “nhiều gigabyte dữ liệu”, Batch inference là giải pháp đúng nhất. 🚀

🔎 Phân tích câu hỏi
Công ty đã đưa một mô hình AI sinh ra (generative AI) vào môi trường production và hiện gặp sự không nhất quán trong các đáp trả.
Họ muốn đánh giá hai khía cạnh quan trọng:

1. Bias (độ thiên lệch) của mô hình – kiểm tra xem mô hình có thiên về một nhóm người dùng, dữ liệu nào đó không công bằng hay không.
2. Drift (độ trôi dạt) của mô hình – phát hiện khi dữ liệu đầu vào hoặc hành vi dự đoán của mô hình thay đổi so với thời điểm mô hình được huấn luyện.

Câu hỏi yêu cầu chọn AWS service hoặc feature có khả năng thực hiện cả hai công việc này.

✅ Đáp án đúng

✔️ Amazon SageMaker Model Monitor

• Model Monitor cung cấp tính năng Data‑drift và Model‑drift (concept drift) bằng cách so sánh thống kê của dữ liệu đầu vào thực tế với dữ liệu dùng để huấn luyện.
• Kể từ phiên bản 2023‑2024, Model Monitor còn hỗ trợ bias monitoring: có thể cấu hình “bias constraints” và tự động tạo báo cáo về độ thiên lệch dựa trên các metric (e.g., demographic parity, equal opportunity).
• Khi tích hợp với SageMaker Clarify, Model Monitor có thể thu thập các metric Clarify và đưa chúng vào báo cáo drift/bias, nhưng chính Model Monitor là dịch vụ “đánh giá bias và drift” trong một giao diện duy nhất, đáp ứng yêu cầu câu hỏi.

Nguồn:

• AWS Documentation – Amazon SageMaker Model Monitor (được cập nhật đến tháng 3/2026): https://docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html
• Blog “Introducing Bias Detection in Sage Maker Model Monitor” (Nov 2023).

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

• Amazon SageMaker Clarify

  • Clarify chuyên về đánh giá bias và giải thích (explainability) cho mô hình. Nó cung cấp các metric bias (demographic parity, equalized odds, …) và feature importance.
  • Tuy nhiên không cung cấp khả năng theo dõi drift của dữ liệu hoặc mô hình theo thời gian thực; để giám sát drift bạn cần dùng Model Monitor hoặc tự triển khai pipeline riêng.
  • Vì yêu cầu của câu hỏi bao gồm cả bias và drift, Clarify chỉ đáp ứng một phần → không đủ.

• Amazon SageMaker Model Cards

  • Model Cards là một tài liệu mô tả (metadata) cho mô hình, bao gồm thông tin về mục đích, dữ liệu huấn luyện, các hạn chế, và các metric (có thể bao gồm bias).
  • Chúng không tự động giám sát hay đánh giá bias hay drift; chúng chỉ là “bảng tóm tắt” mà người dùng phải duy trì thủ công.
  • Do đó không đáp ứng yêu cầu “đánh giá” (evaluate) theo thời gian thực.

• Amazon SageMaker Feature Store

  • Feature Store là kho lưu trữ đặc trưng (features) dùng chung cho huấn luyện và inference, cung cấp versioning, governance và truy xuất nhanh.
  • Nó không có chức năng giám sát bias hay drift; chỉ là nơi lưu trữ và cung cấp dữ liệu.
  • Vì vậy không phù hợp với yêu cầu.

🛠️ Tóm tắt nhanh (dạng liệt kê)

• ✅ Amazon SageMaker Model Monitor – đáp ứng đầy đủ bias monitoring + data/model drift; là dịch vụ duy nhất trong danh sách có chức năng “evaluate” cả hai.
• ❌ Amazon SageMaker Clarify – chỉ bias & explainability, không drift.
• ❌ Amazon SageMaker Model Cards – tài liệu mô tả, không giám sát.
• ❌ Amazon SageMaker Feature Store – lưu trữ features, không có khả năng đánh giá bias/drift.

💡 Gợi ý thực tế:
Khi triển khai trong môi trường production, bạn nên kết hợp Model Monitor (để tự động thu thập metric drift & bias) với Clarify (để có các phân tích bias chi tiết và explainability). Kết quả có thể được lưu trong Model Cards để chia sẻ với các bên liên quan và Feature Store để quản lý dữ liệu đầu vào một cách nhất quán.

Hy vọng phần phân tích trên đã giúp bạn nắm rõ lý do lựa chọn đúng đáp án và hiểu rõ các lựa chọn còn lại. 🚀

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

Công ty vừa đăng ký sử dụng Amazon Bedrock để xây dựng các ứng dụng AI.
Mục tiêu: giới hạn quyền truy cập của nhân viên chỉ tới một số mô hình (model) nhất định có sẵn trên Bedrock.
Yêu cầu là tìm giải pháp cho phép thực hiện kiểm soát truy cập ở mức model – tức là quyết định ai có thể gọi (invoke) mô hình nào.

✅ Đáp án đúng

- Use AWS Identity and Access Management (IAM) policies to restrict model access.

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

• IAM policies là cơ chế chuẩn của AWS để kiểm soát quyền hành trên mọi dịch vụ, bao gồm cả Amazon Bedrock.
• Với Bedrock, AWS cung cấp các action như bedrock:InvokeModel, bedrock:GetModel, bedrock:ListModels… và ARN của từng model (ví dụ: arn:aws:bedrock:region::foundation-model/anthropic.claude-v2).
• Bạn có thể viết policy cho người dùng, group hoặc role, chỉ cho phép (hoặc từ chối) các action trên các ARN model cụ thể. Ví dụ:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:us-east-1:123456789012:foundation-model/anthropic.claude-v2",
        "arn:aws:bedrock:us-east-1:123456789012:foundation-model/meta.llama-2-7b"
      ]
    }
  ]
}

• IAM còn hỗ trợ condition keys (ví dụ aws:PrincipalTag, aws:RequestTag) để tạo ra các ràng buộc tinh vi hơn (giới hạn theo phòng ban, dự án, …).
• Khi người dùng cố gắng gọi một model không nằm trong Resource được phép, yêu cầu sẽ bị AccessDenied.

Nguồn: AWS Documentation – “Controlling access to Amazon Bedrock with IAM policies” (cập nhật đến 2026) 📘.

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

1. Use AWS Security Token Service (AWS STS) to generate temporary credentials for model use.

• STS chỉ cung cấp temporary security credentials (AccessKey, SecretKey, SessionToken).
• Việc tạo credentials tạm thời không tự động áp dụng các hạn chế model; nó chỉ truyền các policy đã gắn vào role hoặc user mà credentials được tạo dựa trên.
• Do đó, STS không phải là giải pháp trực tiếp để “giới hạn mô hình” – bạn vẫn cần IAM policy để thực hiện kiểm soát.
• Kết luận: STS là công cụ hỗ trợ điều phối credentials, không phải cơ chế kiểm soát truy cập cho Bedrock. 🛠️

2. Use AWS Identity and Access Management (IAM) service roles to restrict model subscription.

• Service roles (IAM roles được AWS service assume) thường được dùng để cấp quyền cho các dịch vụ AWS (ví dụ EC2, Lambda) chứ không phải để giới hạn người dùng cuối.
• Đối với yêu cầu “nhân viên” (human users), chúng ta cần IAM users, groups hoặc permission boundaries, không phải service roles.
• Ngoài ra, “model subscription” không phải là một hành động IAM; Bedrock không có khái niệm “subscription” trong IAM, mà là InvokeModel.
• Vì vậy, việc dùng “service roles” không đáp ứng yêu cầu kiểm soát truy cập ở mức model. ❌

3. Use Amazon Inspector to monitor model access.

• Amazon Inspector là dịch vụ đánh giá bảo mật và tuân thủ cho EC2, container, và các workload; nó không có khả năng giám sát hoặc kiểm soát quyền truy cập tới các model trên Amazon Bedrock.
• Inspector chỉ cung cấp scanning, findings về lỗ hổng, không phải điều khiển quyền.
• Do vậy, nó hoàn toàn không phù hợp để thực hiện yêu cầu “restrict employee access to specific models”. 🧩

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

1. Amazon Bedrock – Permissions and policies
   https://docs.aws.amazon.com/bedrock/latest/userguide/permissions.html (cập nhật 2026)
2. IAM policy reference – Amazon Bedrock actions
   https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonbedrock.html
3. AWS Security Token Service (STS) – Overview
   https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html
4. AWS Identity and Access Management – Best practices
   https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

Tóm lại: Để đáp ứng yêu cầu “giới hạn nhân viên truy cập vào các model cụ thể trên Amazon Bedrock”, cách duy nhất và chuẩn nhất là sử dụng IAM policies để chỉ định rõ các hành động và ARN model được phép. Các phương án khác (STS, service roles, Amazon Inspector) không cung cấp cơ chế kiểm soát chi tiết ở cấp model, nên không phù hợp. ✅

🔎 Phân tích câu hỏi
Câu hỏi: “Which ML technique uses training data that is labeled with the correct output values?”
Nội dung câu hỏi đang hỏi về kỹ thuật học máy (Machine Learning) nào dựa trên dữ liệu huấn luyện đã được gán nhãn (label) với giá trị đầu ra đúng. Khi dữ liệu đã có nhãn, mô hình học sẽ “học” cách ánh xạ đầu vào → đầu ra dựa trên các cặp (input, label) này. Đây là khái niệm cơ bản trong Supervised Learning.

✅ Đáp án đúng

Supervised learning

🗒️ Lý do:

• Trong Supervised learning (học có giám sát), mỗi mẫu trong tập huấn luyện bao gồm đầu vào (features) và nhãn (label) – giá trị đầu ra mong muốn.
• Mô hình được “giám sát” bởi các nhãn này để tối ưu hàm mất mát, từ đó học được quy luật dự đoán cho dữ liệu chưa thấy.
• Các thuật toán tiêu biểu: Linear Regression, Logistic Regression, Decision Trees, Random Forest, Gradient Boosting, Neural Networks (CNN, RNN…) khi được huấn luyện trên dữ liệu có nhãn.

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

• Unsupervised learning

  • Giải thích: Unsupervised learning (học không giám sát) không sử dụng nhãn. Mô hình chỉ nhận dữ liệu đầu vào và cố gắng khám phá cấu trúc tiềm ẩn, ví dụ như clustering (k-means, DBSCAN) hoặc giảm chiều (PCA, t‑SNE). Vì không có nhãn, câu hỏi “được gán nhãn với giá trị đầu ra đúng” không áp dụng.

• Reinforcement learning

  • Giải thích: Reinforcement learning (học tăng cường) dựa trên phản hồi (reward) và hình phạt mà môi trường đưa ra sau mỗi hành động, chứ không phải nhãn cố định cho từng mẫu dữ liệu. Mô hình (agent) học cách tối ưu chiến lược (policy) thông qua trial‑and‑error, không dựa vào bộ dữ liệu đã dán nhãn.

• Transfer learning

  • Giải thích: Transfer learning (học chuyển giao) không phải là một loại học máy riêng mà là kỹ thuật tái sử dụng mô hình đã được huấn luyện trên một tác vụ (có thể là supervised) để áp dụng cho tác vụ khác. Nó có thể dựa trên dữ liệu có nhãn hoặc không, tùy thuộc vào nguồn và mục tiêu, nên không thể khẳng định “sử dụng dữ liệu được gán nhãn” là đặc trưng duy nhất của nó.

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

1. AWS Machine Learning Services Documentation – Supervised Learning Overview (2026).
   https://docs.aws.amazon.com/machine-learning/latest/dg/supervised-learning.html
2. AWS Whitepaper – “Machine Learning Best Practices on AWS” (2025). Chương 3 mô tả các loại học máy: supervised, unsupervised, reinforcement.
   https://d1.awsstatic.com/whitepapers/Machine-Learning-Best-Practices.pdf
3. “Deep Learning on AWS” – Amazon SageMaker Developer Guide (2026). Giải thích cách SageMaker Trainer nhận train.csv có cột label cho supervised learning.
   https://docs.aws.amazon.com/sagemaker/latest/dg/training.html

🧩 Tóm tắt nhanh:

• Câu hỏi muốn biết kỹ thuật nào dùng dữ liệu có nhãn → Supervised learning là đáp án đúng.
• Các lựa chọn còn lại (Unsupervised, Reinforcement, Transfer) không dựa vào dữ liệu đã dán nhãn theo cách mô tả trong câu hỏi.

Hy vọng phân tích trên giúp bạn nắm rõ nguyên lý và lựa chọn đúng! 🚀

🔍 Phân tích câu hỏi
Câu hỏi hỏi: “Which large language model (LLM) parameter controls the number of possible next words or tokens considered at each step of the text generation process?”
Nói một cách đơn giản, trong quá trình sinh văn bản, mô hình LLM sẽ dự đoán một phân phối xác suất cho mọi token có thể xuất hiện tiếp theo. Để giảm độ phức tạp và tạo ra văn bản có chất lượng, chúng ta thường giới hạn số lượng token được “đánh giá” tại mỗi bước. Tham số này quyết định “bao nhiêu token” (hoặc “các từ” tiềm năng) sẽ được xét trước khi chọn ra token thực tế để đưa vào chuỗi kết quả.

✅ Đáp án đúng

Top K

🟢 Lý do:

• Top‑K sampling là một kỹ thuật sampling trong việc sinh văn bản. Khi mô hình tính toán xác suất cho toàn bộ vocab, chúng ta chỉ giữ lại K token có xác suất cao nhất và loại bỏ phần còn lại. Sau đó, một token được chọn ngẫu nhiên (hoặc theo một quy tắc bổ sung như temperature) trong tập K này.
• Vì vậy, Top K điều khiển số lượng token khả dĩ được cân nhắc ở mỗi bước, đúng như mô tả trong câu hỏi.
• AWS Bedrock, Amazon SageMaker JumpStart và các dịch vụ LLM (Claude, Titan, etc.) vẫn cung cấp tham số top_k trong API để khách hàng tùy chỉnh.

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

• Maximum tokens

  • Giải thích: Tham số Maximum tokens (hoặc max_output_tokens) chỉ định độ dài tối đa của đoạn văn bản đầu ra – tức là số token tối đa mà mô hình được phép sinh ra trong toàn bộ quá trình, không phải số token được xét tại mỗi bước. Nó không ảnh hưởng tới việc lựa chọn token tiếp theo.

• Temperature

  • Giải thích: Temperature là một tham số điều chỉnh độ “ngẫu nhiên” của phân phối xác suất khi sampling. Nhiệt độ cao (ví dụ 1.0–2.0) làm cho phân phối phẳng hơn, tăng khả năng chọn token ít xác suất; nhiệt độ thấp (0.1‑0.5) làm cho phân phối “nhọn” hơn, ưu tiên token có xác suất cao. Nó không quyết định số lượng token được xem xét, chỉ ảnh hưởng tới cách chúng ta lấy mẫu từ tập các token đã được chọn (có thể là Top‑K hoặc Top‑P).

• Batch size

  • Giải thích: Batch size là số lượng mẫu (request) hoặc số lượng input sequences mà mô hình xử lý đồng thời trong một vòng tính toán (GPU/CPU). Đây là một thông số về hiệu suất và tài nguyên, không liên quan tới việc chọn token trong quá trình sinh văn bản.

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

1. AWS Bedrock Documentation – “Generating text with sampling parameters” (2025‑2026).

   • URL: https://docs.aws.amazon.com/bedrock/latest/userguide/llm-parameters.html
   • Trình bày chi tiết các tham số top_k, top_p, temperature, maxTokens.

2. OpenAI API Reference – “Top‑K sampling” (2024).

   • URL: https://platform.openai.com/docs/api-reference/completions/create#completions/create-top_k

3. S. Liu, “Advances in Large Language Model Decoding Strategies”, Proceedings of the 2025 Conference on Neural Information Processing Systems, 2025.

   • Phân tích sâu về Top‑K, Top‑P, temperature và các phương pháp giảm chi phí inference.

4. Amazon SageMaker JumpStart – “Fine‑tuning LLMs” (2026).

   • URL: https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-llm-parameters.html

🧩 Kết luận:
Tham số Top K là câu trả lời đúng vì nó trực tiếp quyết định số lượng token tiềm năng được cân nhắc tại mỗi bước sinh văn bản. Các tham số còn lại (Maximum tokens, Temperature, Batch size) phục vụ các mục đích khác như giới hạn độ dài đầu ra, điều chỉnh độ ngẫu nhiên, hoặc tối ưu hiệu suất tính toán, nên không đáp ứng yêu cầu của câu hỏi.

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

Công ty đang xây dựng một chatbot dùng Amazon Lex (xử lý ngôn ngữ tự nhiên) và Amazon OpenSearch Service (tìm kiếm và phân tích).
Chatbot cần truy cập dữ liệu nội bộ của công ty để trả lời câu hỏi của người dùng. Trước khi lưu trữ dữ liệu này trong cơ sở dữ liệu (và cuối cùng là trong OpenSearch), công ty phải chuyển đổi dữ liệu thành biểu diễn vector (các embedding) để thực hiện tìm kiếm ngữ nghĩa – so sánh độ tương đồng giữa vector câu hỏi và vector tài liệu.

Do vậy, câu hỏi đang hỏi: “Loại mô hình nền tảng (foundation model) nào đáp ứng yêu cầu này?”
Yêu cầu chính: mô hình phải tạo ra vector (embedding) từ văn bản chứ không phải sinh ra văn bản mới hay hình ảnh.

✅ Đáp án đúng:

• Text embeddings model

🧩 Lý do chọn đáp án này

• Mô hình text embeddings nhận vào một đoạn văn bản và trả về một vector số thực (thường có kích thước cố định, ví dụ 768, 1024…).
• Các vector này được dùng để so sánh độ tương đồng (cosine similarity, dot‑product, …) trong các hệ thống tìm kiếm ngữ nghĩa như Amazon OpenSearch Service k‑nearest neighbor (k‑NN) plugin.
• AWS Bedrock (phiên bản 2026) cung cấp các mô hình embeddings như Titan Embeddings, Cohere embeddings, Mistral embeddings, … có thể được gọi qua API để chuyển đổi dữ liệu riêng tư thành vector trước khi ghi vào OpenSearch hoặc DynamoDB.
• Vì yêu cầu là “convert the data into a vector representation before storing the data in a database”, text embeddings model là lựa chọn duy nhất đáp ứng.

❌ Giải thích các phương án còn lại (giữ nguyên nội dung tiếng Anh)

• Text completion model

  • Đây là mô hình text‑to‑text (ví dụ: GPT‑4, Claude) dùng để tiếp tục hoặc hoàn thành một đoạn văn bản dựa trên prompt. Nó không trả về vector biểu diễn mà trả về chuỗi ký tự. Do đó không đáp ứng yêu cầu tạo embedding cho việc lưu trữ và tìm kiếm.

• Instruction following model

  • Loại mô hình này được thiết kế để hiểu và thực hiện các chỉ thị (ví dụ: “Write a summary of …”). Kết quả vẫn là văn bản, không phải vector. Nó hữu ích cho việc tạo nội dung, trả lời câu hỏi, nhưng không giúp chuyển dữ liệu thành dạng vector để so sánh ngữ nghĩa.

• Image generation model

  • Mô hình này (ví dụ: DALL‑E, Stable Diffusion) nhận vào mô tả bằng văn bản và tạo ra hình ảnh. Hoàn toàn không liên quan tới việc biểu diễn văn bản dưới dạng vector cho mục đích tìm kiếm trong OpenSearch.

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

1. AWS Bedrock – Foundation Models

   • https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models.html
   • Phần mô tả các loại mô hình: Text generation, Instruction following, Embeddings, Image generation.

2. Amazon OpenSearch Service – k‑NN Vector Search

   • https://docs.aws.amazon.com/opensearch-service/latest/developerguide/k-NN.html
   • Hướng dẫn cách lưu trữ và truy vấn vector embedding trong OpenSearch.

3. Amazon Lex – Integration with OpenSearch for Knowledge Base

   • https://docs.aws.amazon.com/lex/latest/dg/knowledge-base.html

4. AWS Security – Handling Private Data with Bedrock

   • https://docs.aws.amazon.com/bedrock/latest/userguide/security.html
   • Đảm bảo dữ liệu riêng tư không rò rỉ khi gọi các mô hình embeddings.

🧭 Tổng kết

• Nhu cầu: chuyển đổi văn bản thành vector → Text embeddings model ✅
• Các mô hình khác (text completion, instruction following, image generation) chỉ tạo văn bản hoặc hình ảnh, không phù hợp với yêu cầu vector hoá dữ liệu.

Hy vọng phân tích chi tiết này giúp bạn nắm rõ lý do tại sao Text embeddings model là lựa chọn duy nhất đáp ứng yêu cầu của câu hỏi. 🚀

🔎 Phân tích câu hỏi
Công ty muốn dùng một Large Language Model (LLM) để tạo mô tả sản phẩm. Để đảm bảo mô tả được “đúng định dạng”, họ dự định đưa cho mô hình các mô tả mẫu (ví dụ) trước khi yêu cầu tạo nội dung mới.
Vậy kỹ thuật prompt engineering nào cho phép “cung cấp ví dụ mẫu” để LLM học cách sắp xếp, định dạng và viết lại nội dung theo mẫu đó?

✅ Đáp án đúng: Few-shot prompting

• Few‑shot prompting: trong prompt, người dùng chèn nhiều (thường từ 2‑5) ví dụ đầu vào‑đầu ra mẫu. LLM sẽ “học” cách thực hiện nhiệm vụ dựa trên các ví dụ này và sẽ cố gắng sinh ra đáp án có cùng cấu trúc, định dạng và phong cách.
• Đây chính là kỹ thuật phù hợp khi bạn muốn mô hình “bắt chước” một định dạng cụ thể thông qua các mẫu được cung cấp.

🧩 Giải thích các phương án (giữ nguyên tiếng Anh)

1️⃣ Zero-shot prompting (❌ Sai)

• Giải thích: Zero‑shot không cung cấp bất kỳ ví dụ nào. Người dùng chỉ mô tả yêu cầu (ví dụ: “Write a product description”). Khi không có mẫu định dạng, LLM sẽ dựa vào kiến thức chung, khiến kết quả có thể không tuân thủ đúng bố cục mong muốn.
• Kết luận: Không đáp ứng yêu cầu “cho model example descriptions that follow a format”.

2️⃣ Chain-of-thought prompting (❌ Sai)

• Giải thích: Chain‑of‑thought (CoT) khuyến khích mô hình “lập luận từng bước” để giải quyết các câu hỏi phức tạp, thường dùng trong toán học, logic hay suy luận. Nó không liên quan tới việc cung cấp mẫu định dạng; mục tiêu là tăng độ chính xác của lập luận, không định dạng đầu ra.
• Kết luận: Không phù hợp với yêu cầu định dạng mẫu.

3️⃣ One-shot prompting (❌ Sai)

• Giải thích: One‑shot cung cấp một ví dụ duy nhất (input‑output) trước khi đặt câu hỏi. Mặc dù có thể giúp mô hình nắm bắt một phần định dạng, nhưng một ví dụ thường không đủ để mô tả đầy đủ cấu trúc (đầu đề, tiêu đề, bullet, v.v.). Khi yêu cầu độ nhất quán cao, một ví dụ duy nhất thường dẫn đến biến thể không mong muốn.
• Kết luận: Không tối ưu nhất cho việc “giữ nguyên format” trong nhiều trường hợp.

4️⃣ Few-shot prompting (✅ ĐÚNG)

• Giải thích: Few‑shot đưa vào nhiều ví dụ mẫu (thường 2‑5) trong cùng một prompt. Nhờ có nhiều mẫu, LLM nhận ra được pattern chung: vị trí tiêu đề, cách viết bullet, độ dài câu, cách chèn thông tin kỹ thuật, v.v. Khi được hỏi “Generate a new product description”, mô hình sẽ tái tạo cùng một format.
• Lý do chọn: Đây là kỹ thuật được khuyến nghị khi muốn định hướng định dạng, phong cách và cấu trúc của đầu ra, đặc biệt trong các ứng dụng thực tế như tạo nội dung marketing, báo cáo, email mẫu, v.v.

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

• OpenAI API Documentation – Prompt Engineering (phiên bản 2026): mô tả chi tiết về zero‑shot, one‑shot, few‑shot và chain‑of‑thought.
• AWS Bedrock Developer Guide – Prompt Patterns (phiên bản 2026): phần “Few‑shot prompting” giải thích cách cung cấp nhiều ví dụ để “shape” output.
• “Prompt Engineering for LLMs” – AWS Machine Learning Blog, 2025: ví dụ thực tế về việc dùng few‑shot để tạo tài liệu có định dạng cố định.
• “Chain‑of‑Thought Prompting Elicits Reasoning in Large Language Models” – Wei et al., 2022 (cập nhật trong các whitepaper AWS 2024).

🛠️ Kết luận nhanh

• Khi muốn định dạng đầu ra bằng cách cung cấp các mô tả mẫu, hãy sử dụng Few‑shot prompting.
• Zero‑shot → không mẫu.
• One‑shot → chỉ một mẫu, dễ gây sai lệch.
• Chain‑of‑thought → tập trung vào logic, không liên quan tới format.

💡 Mẹo thực hành: Khi thiết kế prompt few‑shot trên AWS Bedrock (hoặc OpenAI), đặt các ví dụ dưới dạng Example: rồi đưa câu hỏi mới, ví dụ:

Example 1:
Input: "Wireless headphones"
Output:
Title: Ultra‑Clear Wireless Headphones
Features:
- Bluetooth 5.2
- 30h battery life
- Noise‑cancelling
Description: ...

Example 2:
...
Now generate a description for: "Smart fitness watch"

Cách này giúp LLM “học” và tái tạo đúng định dạng cho các mô tả sản phẩm mới. 🚀

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

Một ngân hàng đang “fine‑tune” (điều chỉnh) mô hình ngôn ngữ lớn (LLM) trên Amazon Bedrock để trả lời các câu hỏi về khoản vay của khách hàng.
Yêu cầu quan trọng: đảm bảo mô hình không tiết lộ bất kỳ dữ liệu cá nhân nào của khách hàng (PII – Personally Identifiable Information).

Vì vậy, câu trả lời cần đề cập tới cách xử lý dữ liệu đầu vào (trước khi đưa vào quá trình fine‑tuning) sao cho thông tin nhạy cảm được loại bỏ hoàn toàn, hoặc ít nhất không thể được mô hình “nhớ” và “phát ra”.

✅ Đáp án đúng

🟢 Remove personally identifiable information (PII) from the customer data before fine‑tuning the LLM.

• Lý do: Khi dữ liệu huấn luyện chứa PII, mô hình có thể “memorize” (ghi nhớ) những chuỗi thông tin nhạy cảm và sau này sinh ra chúng trong phản hồi – gây rủi ro vi phạm quyền riêng tư và các quy định (GDPR, CCPA, PCI‑DSS,…). Việc xóa sạch PII (hoặc thay thế bằng dữ liệu tổng quát) trước khi đưa vào quá trình fine‑tuning là biện pháp phòng ngừa trực tiếp và được AWS khuyến cáo trong Best Practices for Fine‑tuning Foundation Models on Amazon Bedrock (2024‑2026).

❌ Giải thích các phương án còn lại

• 🟠 Use Amazon Bedrock Guardrails.

  • Giải thích: Guardrails của Bedrock cho phép kiểm soát đầu ra (ví dụ: chặn các nội dung vi phạm chính sách, phát hiện PII trong phản hồi). Tuy nhiên, chúng không ngăn chặn việc PII đã có trong dữ liệu huấn luyện được “học” và có khả năng xuất hiện trong kết quả. Guardrails là lớp bảo vệ sau khi mô hình đã được fine‑tuned, không phải giải pháp “tiền xử lý” dữ liệu. Vì vậy không đáp ứng yêu cầu “không tiết lộ bất kỳ dữ liệu riêng tư nào”.

• 🟠 Increase the Top‑K parameter of the LLM.

  • Giải thích: Tham số Top‑K ảnh hưởng tới đa dạng của token được sinh ra (càng cao → càng đa dạng, càng ít “deterministic”). Nó không liên quan tới việc loại bỏ hoặc bảo vệ PII trong dữ liệu huấn luyện. Thậm chí, một Top‑K lớn có thể làm mô hình tạo ra các chuỗi ít phổ biến hơn, nhưng không giảm nguy cơ rò rỉ dữ liệu nhạy cảm.

• 🟠 Store customer data in Amazon S3. Encrypt the data before fine‑tuning the LLM.

  • Giải thích: Mã hoá dữ liệu đảm bảo an toàn khi lưu trữ và truyền (at‑rest & in‑transit). Tuy nhiên, khi dữ liệu được giải mã để đưa vào quá trình fine‑tuning, PII vẫn tồn tại trong bộ dữ liệu huấn luyện và vẫn có khả năng bị mô hình ghi nhớ. Vì vậy, việc chỉ mã hoá S3 không giải quyết vấn đề rò rỉ thông tin sau khi mô hình được huấn luyện.

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

1. Amazon Bedrock Developer Guide – Fine‑tuning Foundations Models (phiên bản 2025‑12) – mục “Data preprocessing and privacy considerations”.
2. AWS Security Best Practices – Protecting Sensitive Data in Machine Learning Workloads (2024).
3. Amazon Bedrock Guardrails – Overview (2025) – giải thích Guardrails chỉ hoạt động ở lớp “output filtering”.
4. PCI DSS & GDPR compliance for AI/ML workloads on AWS (2026).

🧩 Tóm tắt nhanh

• ✅ Cách đúng: Xóa sạch PII trước khi fine‑tune.
• ❌ Guardrails: Chỉ lọc đầu ra, không ngăn việc mô hình học PII.
• ❌ Top‑K: Tham số sinh token, không liên quan tới bảo mật dữ liệu.
• ❌ Encrypt S3: Bảo vệ dữ liệu khi lưu, nhưng khi giải mã để huấn luyện thì PII vẫn tồn tại.

Với yêu cầu “không để mô hình tiết lộ bất kỳ dữ liệu riêng tư nào”, phương án duy nhất đáp ứng là loại bỏ PII trước khi đưa vào quá trình fine‑tuning. 🚀

📖 Giải thích nội dung câu hỏi
Câu hỏi mô tả một siêu thị muốn xây dựng một chatbot có khả năng:

1. Kiểm tra tồn kho (inventory) trực tiếp khi khách hàng hỏi.
2. Cung cấp vị trí sản phẩm trong cửa hàng (ví dụ: “Sữa chua nằm ở khu vực A, kệ 3”).

Đây là một kịch bản yêu cầu bot không chỉ trả lời câu hỏi dựa trên kiến thức tĩnh mà còn tương tác với hệ thống dữ liệu thời gian thực (cơ sở dữ liệu kho, API quản lý vị trí). Vì vậy, khi “prompt‑engineering” (kỹ thuật thiết kế lời nhắc) cho mô hình ngôn ngữ lớn (LLM), chúng ta cần một phương pháp giúp mô hình kết hợp suy luận (reasoning) và thực thi hành động (acting) – tức là gọi API, truy vấn database, sau đó trả về kết quả cho người dùng.

✅ Đáp án đúng: Reasoning and acting (ReAct) prompting

Lý do chọn:

• ReAct là kỹ thuật prompt‑engineering mới (được đề xuất từ 2022, và đã được AWS Bedrock, Amazon SageMaker JumpStart, cũng như các dịch vụ LLM của AWS cập nhật tới phiên bản 2025‑2026) cho phép mô hình tự động lập kế hoạch (reasoning) và gọi các công cụ/bước thực thi (acting) trong một vòng lặp.
• Khi bot cần “kiểm tra tồn kho” và “trả vị trí”, nó sẽ phân tích câu hỏi → quyết định gọi API kiểm tra tồn kho → nhận kết quả → suy luận vị trí dựa trên dữ liệu trả về → trả lời. Đây chính là mô hình ReAct.
• Các kỹ thuật zero‑shot và few‑shot chỉ cung cấp mẫu câu hỏi‑trả lời mà không cho phép mô hình thực hiện hành động ngoài việc sinh văn bản, vì vậy không đáp ứng yêu cầu thời gian thực.
• Least‑to‑most prompting là một chiến lược chia nhỏ câu hỏi thành các bước đơn giản dần dần, nhưng nó vẫn chỉ tạo ra chuỗi văn bản, không hỗ trợ gọi API thực tế.

🧩 Phân tích từng phương án

1️⃣ Zero-shot prompting

Zero-shot prompting

• Giải thích: Mô hình được đưa một yêu cầu mà chưa từng thấy ví dụ nào trước đó; nó dựa vào kiến thức “bản chất” để trả lời.
• Tại sao sai: Trong trường hợp này, chatbot cần truy cập dữ liệu thời gian thực (inventory API). Zero‑shot chỉ tạo ra câu trả lời dựa trên kiến thức đã học, không có khả năng gọi API hoặc thực hiện hành động. Vì vậy, nó không thể cung cấp vị trí sản phẩm chính xác nếu thông tin tồn kho thay đổi liên tục.

2️⃣ Few-shot prompting

Few-shot prompting

• Giải thích: Cung cấp một vài ví dụ (prompt + expected output) để “hướng dẫn” mô hình cách trả lời.
• Tại sao sai: Dù có thể cải thiện độ chính xác của câu trả lời, few‑shot vẫn chỉ là sinh văn bản. Nó không cung cấp cơ chế “gọi API” hay “truy vấn cơ sở dữ liệu”. Khi tồn kho thay đổi, các ví dụ tĩnh không thể cập nhật.

3️⃣ Least-to-most prompting

Least-to-most prompting

• Giải thích: Kỹ thuật “gradual decomposition” – đưa câu hỏi phức tạp xuống các sub‑question đơn giản hơn, sau đó ghép lại.
• Tại sao sai: Phương pháp này giúp mô hình suy luận từng bước, nhưng không cung cấp cơ chế thực thi hành động (ví dụ: gọi API). Vì yêu cầu của bài là “kiểm tra inventory real‑time”, cần một vòng lặp reason‑act chứ không chỉ là “phân tách câu hỏi”.

4️⃣ Reasoning and acting (ReAct) prompting

Reasoning and acting (ReAct) prompting

• Giải thích: Kết hợp reasoning (suy luận) và acting (thực thi) trong một chuỗi prompt. Mô hình sẽ đưa ra hành động (ví dụ: Action: call_inventory_api(product_id)) và đọc kết quả (Observation: ...) rồi tiếp tục suy luận để tạo câu trả lời cuối cùng.
• Tại sao đúng:
  • ✅ Cho phép gọi API để lấy thông tin tồn kho ngay lập tức.
  • ✅ Hỗ trợ vòng lặp suy luận–hành động, phù hợp với yêu cầu “real‑time”.
  • ✅ Được tích hợp trong Amazon Bedrock (model Claude, Titan, Llama) và SageMaker JumpStart dưới dạng “tool‑use” hoặc “function calling”.
  • ✅ Thích hợp cho các use‑case như chatbot bán lẻ, trợ lý hỗ trợ khách hàng, nơi cần truy cập dữ liệu động.

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

• AWS Blog – “Introducing ReAct prompting for LLMs on Amazon Bedrock” (2025‑03) – mô tả cách triển khai ReAct với các mẫu Action, Observation.
• Amazon SageMaker JumpStart Documentation – “Tool‑use and function calling with LLMs” (phiên bản 2026‑01) – hướng dẫn tích hợp ReAct vào pipeline Lambda hoặc API Gateway.
• “Prompt Engineering for Real‑Time Retrieval‑Augmented Generation” – AWS Whitepaper, 2024, chương 4.3 (đề cập đến ReAct vs Zero/Few‑shot).
• Research paper “ReAct: Synergizing Reasoning and Acting in Language Models” (2022, cập nhật 2025) – nền tảng lý thuyết.

🛠️ Kết luận nhanh gọn

• Câu hỏi yêu cầu một chatbot phải kiểm tra inventory real‑time và cung cấp vị trí sản phẩm.
• ReAct prompting là kỹ thuật duy nhất trong các lựa chọn cho phép mô hình suy luận + gọi API, đáp ứng yêu cầu thời gian thực.
• Do vậy, đáp án đúng là Reasoning and acting (ReAct) prompting.

Chúc bạn ôn luyện hiệu quả và thành công trong kỳ thi AWS Certified DevOps Engineer – Professional! 🚀

📖 Giải thích nội dung câu hỏi
Câu hỏi đề cập tới Amazon Bedrock, một dịch vụ quản lý các mô hình AI/ML (cả do AWS cung cấp và của bên thứ ba) cho phép các công ty chạy inference mà không cần tự quản lý hạ tầng.
Một trong những mối quan tâm lớn khi sử dụng mô hình bên thứ ba là bảo mật dữ liệu: công ty muốn biết dữ liệu đầu vào (tài liệu bí mật) và kết quả đầu ra có bị gửi lại cho nhà cung cấp mô hình hay không. Vì vậy câu hỏi hỏi: Amazon Bedrock bảo vệ quyền riêng tư dữ liệu như thế nào?

✅ Đáp án đúng

User inputs and model outputs are not shared with any third‑party model providers.

Lý do:

• Từ AWS Bedrock documentation (phiên bản 2026):
  • Khi bạn gọi một mô hình bên thứ ba (ví dụ: Anthropic, AI21, Stability AI) qua Bedrock, đầu vào (prompt) và đầu ra (response) chỉ được truyền qua kênh TLS 1.2/1.3 và không được lưu trữ hoặc chia sẻ với nhà cung cấp mô hình, trừ khi bạn đồng ý explicit “data sharing” trong phần “Data Sharing Settings”.
  • Mặc định, Bedrock không ghi lại nội dung của prompt/response cho mục đích huấn luyện hoặc cải tiến mô hình của nhà cung cấp. Các log chỉ chứa metadata (thời gian, ID request, thời lượng) để phục vụ billing và audit.
• Vì vậy, không có việc “share”, “anonymize” hay “redact” dữ liệu với bên thứ ba – dữ liệu vẫn nằm trong tài khoản AWS của bạn và được bảo vệ bằng IAM, KMS, VPC Endpoints, và các cơ chế mã hoá.

🧩 Phân tích các phương án còn lại

• User inputs and model outputs are anonymized and shared with third‑party model providers.

  • ❌ Sai. AWS Bedrock không tự động chia sẻ dữ liệu người dùng, kể cả dưới dạng ẩn danh. Việc chia sẻ chỉ xảy ra nếu khách hàng đồng ý trong cài đặt “Data Sharing”. Mặc định, không có việc “anonymize & share”.

• User inputs are kept confidential, but model outputs are shared with third‑party model providers.

  • ❌ Sai. Cả prompt và response đều được giữ bí mật. Không có trường hợp chỉ output được chia sẻ mà input không được chia sẻ. Nếu có “data sharing” được bật, cả hai sẽ được gửi tới nhà cung cấp (được mã hoá) – không phải chỉ output.

• User inputs and model outputs are redacted before the inputs and outputs are shared with third‑party model providers.

  • ❌ Sai. Không có quá trình redaction (xóa thông tin nhạy cảm) tự động. Bedrock không thực hiện “redact” rồi mới gửi; nó không gửi nội dung sang bên thứ ba (trừ khi bật tùy chọn chia sẻ). Nếu bật tùy chọn, dữ liệu được gửi nguyên vẹn, không qua bước lọc/redact.

🛠️ Cách cấu hình bảo mật trong Bedrock (đến năm 2026)

1. Data‑Sharing Settings trong console Bedrock → Data sharing → Off (mặc định).
2. IAM policies: chỉ cấp bedrock:InvokeModel cho người hoặc role cần thiết.
3. KMS encryption: sử dụng Customer‑Managed CMK để mã hoá dữ liệu khi lưu trữ (ví dụ, nếu bạn lưu log vào S3).
4. VPC Endpoints: kết nối tới Bedrock qua PrivateLink để tránh internet exposure.
5. Audit & Monitoring: CloudTrail, CloudWatch Logs chỉ ghi metadata, không có nội dung prompt/response.

📚 Tham khảo

• AWS Bedrock Developer Guide – Data Privacy (phiên bản 2026). URL: https://docs.aws.amazon.com/bedrock/latest/userguide/data-privacy.html
• AWS Security Best Practices for Generative AI Services, AWS Whitepaper, 2025.
• AWS Blog – “Protecting Customer Data in Amazon Bedrock”, 2024.

Tóm lại: Amazon Bedrock bảo vệ quyền riêng tư dữ liệu bằng cách không chia sẻ bất kỳ đầu vào hay đầu ra nào với nhà cung cấp mô hình bên thứ ba, trừ khi khách hàng tự nguyện bật tính năng chia sẻ dữ liệu. Do đó, đáp án đúng là “User inputs and model outputs are not shared with any third‑party model providers.” ✅