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

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

Câu hỏi mô tả một công ty kế toán muốn triển khai một Large Language Model (LLM) để tự động hoá xử lý tài liệu. Vì LLM có khả năng tạo ra nội dung không chính xác, thiên vị hoặc gây hại, công ty cần thực hiện các bước phát triển và triển khai một cách có trách nhiệm (responsible AI).
Yêu cầu “Choose two” nghĩa là chỉ có hai đáp án phản ánh các biện pháp thực tế được AWS (và cộng đồng AI) khuyến cáo để giảm thiểu rủi ro về công bằng, thiên vị và hậu quả tiêu cực.

✅ Các đáp án đúng

1. Include fairness metrics for model evaluation.

   • ✅ Giải thích: Trong môi trường AWS, Amazon SageMaker Clarify cho phép đo lường và giám sát các chỉ số công bằng (fairness) trong quá trình đánh giá mô hình (pre‑training, post‑training, và runtime). Việc tích hợp các metric này giúp phát hiện và giảm thiểu thiên lệch đối với các nhóm dân cư, đồng thời đáp ứng các tiêu chuẩn đạo đức và quy định. Đây là một trong những bước cốt lõi của “Responsible AI” mà AWS khuyến nghị.

2. Modify the training data to mitigate bias.

   • ✅ Giải thích: Khi dữ liệu huấn luyện chứa các mẫu thiên lệch (bias), LLM sẽ học và tái tạo chúng. AWS cung cấp SageMaker Data Wrangler và SageMaker Clarify Data Bias Detection để giúp người dùng khám phá, làm sạch và cân bằng lại dữ liệu (ví dụ: cân nhắc lại mẫu, loại bỏ thông tin nhạy cảm). Việc chỉnh sửa dữ liệu để giảm thiểu bias chính là một biện pháp phòng ngừa quan trọng trước khi đào tạo mô hình.

❌ Các đáp án sai (và lý do)

• Adjust the temperature parameter of the model.

  • ❌ Giải thích: Tham số temperature chỉ ảnh hưởng tới độ ngẫu nhiên của đầu ra (cực đoan hay ổn định). Thay đổi giá trị này không liên quan tới việc giảm thiểu rủi ro xã hội, công bằng hay bảo mật của mô hình. Đây là kỹ thuật tinh chỉnh để cải thiện trải nghiệm người dùng, không phải là biện pháp “responsible AI”.

• Avoid overfitting on the training data.

  • ❌ Giải thích: Tránh overfitting là một thực hành tốt về hiệu suất mô hình, giúp mô hình tổng quát hoá tốt hơn. Tuy nhiên, trong bối cảnh câu hỏi tập trung vào “trách nhiệm” và “tránh các tác hại tiềm năng” (bias, misinformation, privacy), việc này không trực tiếp giải quyết các vấn đề đạo đức. Do đó không được xem là một trong hai đáp án cần chọn.

• Apply prompt engineering techniques.

  • ❌ Giải thích: Prompt engineering là cách thiết kế câu hỏi/đầu vào để nhận được kết quả mong muốn từ LLM. Mặc dù hữu ích để kiểm soát đầu ra, nó không thay đổi bản chất của mô hình hoặc dữ liệu gốc, và không giải quyết các vấn đề về bias hay fairness. Vì vậy, không phải là lựa chọn đúng trong câu hỏi này.

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

• Amazon SageMaker Clarify – “Detect and mitigate bias in machine learning models”.
  https://docs.aws.amazon.com/sagemaker/latest/dg/clarify.html
• AWS Well‑Architected Framework – Machine Learning Lens (2025 update) – các best practice về AI có trách nhiệm.
  https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/overview.html
• AWS Bedrock – các hướng dẫn về việc triển khai LLM với các biện pháp kiểm soát nội dung và đánh giá rủi ro.
  https://aws.amazon.com/bedrock/
• AWS AI Governance Whitepaper (2024) – đề cập đến việc đo lường công bằng, quản lý dữ liệu và kiểm soát rủi ro trong môi trường doanh nghiệp.
  https://d1.awsstatic.com/whitepapers/ai-governance.pdf

📌 Tóm tắt nhanh

• Đúng:

  • Include fairness metrics for model evaluation.
  • Modify the training data to mitigate bias.

• Sai:

  • Adjust the temperature parameter of the model.
  • Avoid overfitting on the training data.
  • Apply prompt engineering techniques.

Bằng cách đánh giá công bằng và xử lý dữ liệu đầu vào để giảm bias, công ty kế toán sẽ đáp ứng được yêu cầu “trách nhiệm” khi triển khai LLM, đồng thời tuân thủ các best practice của AWS về AI an toàn và công bằng. 🚀

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

Công ty đang xây dựng một mô hình Machine Learning (ML).
Họ đã thu thập dữ liệu mới, tạo ma trận tương quan, tính các thống kê và visualize (trực quan hoá) dữ liệu.

Các hoạt động trên thuộc về giai đoạn khám phá dữ liệu – hay còn gọi là Exploratory Data Analysis (EDA). Đây là bước đầu tiên sau khi dữ liệu đã được thu thập, nhằm:

• Hiểu cấu trúc, phân phối và mối quan hệ giữa các biến.
• Xác định chất lượng dữ liệu (missing values, outliers, ...).
• Đưa ra các giả thuyết ban đầu để hướng tới các bước tiếp theo như tiền xử lý, tạo đặc trưng, …

Vì vậy câu hỏi đang hỏi: “Ở giai đoạn nào của pipeline ML?” – đáp án đúng là Exploratory Data Analysis.

✅ Đáp án đúng

Exploratory data analysis

Đây là giai đoạn mà các nhà khoa học dữ liệu “nhìn vào” dữ liệu bằng các công cụ thống kê, ma trận tương quan, biểu đồ, heatmap… để rút ra những hiểu biết sơ bộ trước khi thực hiện các bước tiếp theo như làm sạch, biến đổi hay xây dựng mô hình.

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

• Data pre-processing

  • Lý do sai: Giai đoạn này tập trung vào làm sạch và chuẩn hoá dữ liệu (xử lý missing values, scaling, encoding, loại bỏ outliers…). Các hoạt động trong câu hỏi (tạo ma trận tương quan, tính thống kê, visualisation) chưa thay đổi hay chuẩn hoá dữ liệu mà chỉ đánh giá dữ liệu. Do đó không phải là tiền xử lý.

• Feature engineering

  • Lý do sai: Feature engineering là quá trình tạo, chuyển đổi, lựa chọn các đặc trưng (features) dựa trên hiểu biết về dữ liệu – ví dụ: tạo biến mới, áp dụng PCA, one‑hot encoding, v.v. Ở đây công ty chưa thực hiện việc tạo hay biến đổi đặc trưng, mà chỉ đang khám phá dữ liệu hiện có.

• Hyperparameter tuning

  • Lý do sai: Hyperparameter tuning xảy ra sau khi mô hình đã được xây dựng (training) và mục tiêu là tối ưu các siêu tham số như learning rate, number of trees, depth, … Thông thường dùng GridSearch, RandomSearch, Bayesian Optimization. Các hoạt động trong câu hỏi không liên quan tới việc đào tạo hoặc tinh chỉnh mô hình, nên không phải là giai đoạn này.

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

1. AWS SageMaker Documentation – “Machine Learning workflow”

   • Mô tả chi tiết các giai đoạn: Data Collection → Exploratory Data Analysis → Data Pre‑processing → Feature Engineering → Model Training → Hyperparameter Tuning → Model Evaluation → Deployment.
   • URL: https://docs.aws.amazon.com/sagemaker/latest/dg/ml-workflow.html

2. “Hands‑On Machine Learning with Scikit‑Learn, Keras, and TensorFlow” – Aurélien Géron (2nd edition, 2024)

   • Chương 2: “End‑to‑End Machine Learning Project” – phần “Explore and Visualize Your Data” (EDA).

3. AWS Machine Learning Blog – “Best practices for data exploration in SageMaker Studio” (2025)

   • Hướng dẫn cách dùng SageMaker Data Wrangler và SageMaker Studio notebooks để thực hiện ma trận tương quan, thống kê mô tả và visualisation trong EDA.

🧩 Kết luận:
Công ty đang ở giai đoạn Exploratory Data Analysis của pipeline Machine Learning. Các hoạt động như tạo ma trận tương quan, tính toán thống kê và trực quan hoá dữ liệu là những dấu hiệu đặc trưng của EDA, không phải là tiền xử lý, tạo đặc trưng hay tối ưu siêu tham số.

📝 Giải thích nội dung câu hỏi
Công ty có các tài liệu bị mất một vài từ do lỗi cơ sở dữ liệu. Họ muốn xây dựng một mô hình Machine Learning có khả năng đề xuất các từ khả dĩ để lấp đầy những khoảng trống trong văn bản. Đây là bài toán “fill‑in‑the‑blank” / “masked language modeling” trong lĩnh vực Xử lý Ngôn ngữ Tự nhiên (NLP). Mô hình cần hiểu ngữ cảnh xung quanh vị trí bị thiếu và đưa ra dự đoán từ phù hợp nhất.

✅ Đáp án đúng: BERT‑based models

Tại sao BERT‑based models là đáp án đúng?

• Masked Language Modeling (MLM): BERT (Bidirectional Encoder Representations from Transformers) được huấn luyện với cơ chế masking – một số token trong câu được thay bằng [MASK] và mô hình học cách dự đoán token gốc dựa trên ngữ cảnh cả bên trái và bên phải. Điều này chính là cơ chế phù hợp nhất để “điền từ còn thiếu”.
• Hiệu suất cao: Các phiên bản cải tiến của BERT (RoBERTa, DeBERTa, BERT‑large, …) đã chứng minh độ chính xác vượt trội trong các task như Cloze tests, question answering, và text infilling.
• Triển khai trên AWS: Bạn có thể nhanh chóng triển khai BERT‑based models trên Amazon SageMaker (training/custom inference) hoặc dùng Amazon Bedrock (đưa các mô hình LLM như Claude, Titan, hoặc các mô hình BERT‑based được quản lý) để thực hiện dự đoán mà không cần tự xây dựng hạ tầng.

❌ Phân tích các phương án sai

1. Topic modeling

   • Topic modeling (VD: LDA, NMF) nhằm khám phá các chủ đề ẩn trong tập tài liệu bằng cách nhóm các từ thường xuất hiện cùng nhau. Nó không dự đoán từ cụ thể ở vị trí bị thiếu mà chỉ cung cấp thông tin về phân bố chủ đề. Do vậy không thể “đề xuất từ” cho khoảng trống.
   • 👉 Không đáp ứng yêu cầu “fill‑in‑the‑blank”.

2. Clustering models

   • Các mô hình clustering (K‑means, DBSCAN, hierarchical clustering) nhóm các đối tượng (document, sentence, embedding) dựa trên độ tương đồng, nhưng không tạo ra dự đoán từ. Chúng chỉ giúp phân loại hay tìm cụm dữ liệu tương đồng.
   • 👉 Không có cơ chế để dự đoán từ thiếu trong một câu.

3. Prescriptive ML models

   • Prescriptive models là loại mô hình đưa ra khuyến nghị hành động dựa trên phân tích dự báo (predictive) và tối ưu hoá (optimization), thường dùng trong quản lý tài nguyên, logistics, tài chính.
   • Chúng không liên quan tới xử lý ngôn ngữ tự nhiên hay dự đoán từ.
   • 👉 Sai hoàn toàn với yêu cầu NLP.

🧩 Các công cụ AWS liên quan (đến 2026)

• Amazon SageMaker JumpStart: cung cấp các mô hình BERT và các biến thể đã được tiền‑huấn luyện, có sẵn để fine‑tune với dữ liệu doanh nghiệp.
• Amazon Bedrock: hỗ trợ truy cập tới các LLM (Anthropic Claude, Cohere, AI21, Amazon Titan) và các mô hình Transformer mở (có thể là BERT‑based) qua API không cần quản lý hạ tầng.
• AWS Lambda + SageMaker Inference Endpoint: triển khai nhanh dịch vụ “fill‑in‑the‑blank” dưới dạng API serverless.
• Amazon CloudWatch + SageMaker Model Monitor: giám sát độ chính xác của mô hình sau khi đưa vào sản xuất, phát hiện drift khi ngôn ngữ tài liệu thay đổi.

📚 Tham khảo

1. Devlin, J., et al. (2018). “BERT: Pre‑training of Deep Bidirectional Transformers for Language Understanding.” – mô tả kiến trúc và cơ chế masked language modeling.
2. AWS Documentation – Amazon SageMaker JumpStart (phiên bản 2026): https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart.html
3. AWS Documentation – Amazon Bedrock (phiên bản 2026): https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html
4. AWS Blog – “How to Build a Masked Language Model with SageMaker” (2025): hướng dẫn chi tiết fine‑tuning BERT cho task fill‑in‑the‑blank.

🔚 Tóm tắt:

• ✅ Đáp án đúng là BERT‑based models vì chúng được thiết kế để dự đoán token bị mask dựa trên ngữ cảnh hai phía, phù hợp nhất với yêu cầu “đề xuất từ để điền vào chỗ trống”.
• ❌ Các lựa chọn còn lại (Topic modeling, Clustering models, Prescriptive ML models) không cung cấp cơ chế dự đoán từ và do đó không đáp ứng yêu cầu của câu hỏi.

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

🔎 Phân tích câu hỏi
Công ty muốn hiển thị tổng doanh số của các sản phẩm bán chạy nhất tại nhiều địa điểm bán lẻ trong 12 tháng gần nhất và muốn tự động tạo biểu đồ.

Điều này yêu cầu một dịch vụ BI (Business Intelligence) có khả năng chuyển dữ liệu bán hàng thành biểu đồ và tự động (từ câu hỏi ngôn ngữ tự nhiên) tạo ra các visualisation.

Trong danh mục dịch vụ AWS, Amazon QuickSight là dịch vụ phân tích và trực quan hoá dữ liệu. Tính năng Amazon Q (được tích hợp vào QuickSight) cho phép người dùng nhập câu hỏi bằng tiếng tự nhiên (VD: “Tổng doanh thu của top‑5 sản phẩm ở mỗi cửa hàng trong 12 tháng qua”) và hệ thống sẽ tự động tạo biểu đồ phù hợp – đúng với yêu cầu “automate the generation of graphs”.

✅ Đáp án đúng

✅ Amazon Q in Amazon QuickSight

• Lý do: QuickSight Q (được gọi là “Amazon Q in Amazon QuickSight”) là công cụ AI‑driven cho phép người dùng hỏi bằng ngôn ngữ tự nhiên và nhận được biểu đồ, bảng, hoặc dashboard tự động tạo ra. Nó tích hợp sẵn các kết nối tới nguồn dữ liệu (S3, RDS, Redshift, Athena, …) và có khả năng lên lịch tự động cập nhật dữ liệu, đáp ứng yêu cầu “automate the generation of graphs”.

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

• ❌ Amazon Q in Amazon EC2

  • Giải thích: EC2 chỉ là một dịch vụ máy ảo; không có tính năng “Amazon Q” tích hợp sẵn để tạo biểu đồ. Để tạo visualisation trên EC2, người dùng phải tự cài đặt phần mềm BI (như Tableau, PowerBI) và viết mã. Vì vậy không đáp ứng yêu cầu “tự động” và “ngôn ngữ tự nhiên”.

• ❌ Amazon Q Developer

  • Giải thích: Đây là bộ công cụ dành cho nhà phát triển để tích hợp khả năng tạo nội dung AI (code, văn bản) vào ứng dụng, không phải công cụ BI. Amazon Q Developer hỗ trợ CodeWhisperer và prompt‑engineering, nhưng không có chức năng trực quan hoá dữ liệu bán hàng.

• ❌ Amazon Q in AWS Chatbot

  • Giải thích: AWS Chatbot là dịch vụ tích hợp Slack hoặc Amazon Chime để nhận và thực thi các lệnh AWS từ kênh chat. “Amazon Q in AWS Chatbot” chỉ giúp trả lời các câu hỏi kỹ thuật hoặc thực hiện lệnh, không phải tạo biểu đồ dữ liệu. Nó không có khả năng tạo dashboard hay visualisation tự động.

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

1. Amazon QuickSight – Q (Generative AI for analytics) – AWS Documentation, phiên bản 2025‑12.
   https://docs.aws.amazon.com/quicksight/latest/user/quick-start-q.html
2. AWS Blog – Introducing Amazon Q in Amazon QuickSight (Nov 2023, cập nhật 2025).
   https://aws.amazon.com/blogs/big-data/amazon-q-generative-analytics/
3. AWS Well‑Architected Framework – Data Analytics Pillar (2024).
   https://docs.aws.amazon.com/wellarchitected/latest/data-analytics-pillar/welcome.html

🧩 Tổng kết nhanh

• Nhu cầu: Tự động tạo biểu đồ doanh thu theo câu hỏi ngôn ngữ tự nhiên.
• Giải pháp phù hợp: Amazon Q in Amazon QuickSight – cung cấp AI‑driven visualisation.
• Các lựa chọn khác đều không cung cấp tính năng BI/visualisation và vì thế không đáp ứng yêu cầu.

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

Câu hỏi mô tả một công ty muốn xây dựng chatbot dùng Amazon Bedrock – dịch vụ quản lý các large language model (LLM) của AWS – để thực hiện intent detection (phát hiện ý định người dùng).
Công ty muốn cải thiện độ chính xác bằng few‑shot learning, tức là cung cấp cho mô hình một vài ví dụ “đầu vào – đầu ra mong muốn” (prompt) để mô hình học cách trả lời đúng trong ngữ cảnh mới mà không cần huấn luyện lại toàn bộ.

Do đó, câu hỏi hỏi: “Which additional data does the company need to meet these requirements?” – tức là cần chuẩn bị loại dữ liệu nào để đưa vào prompt few‑shot, sao cho mô hình Bedrock có thể học cách ánh xạ tin nhắn người dùng → ý định người dùng.

✅ Đáp án đúng

Pairs of user messages and correct user intents

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

• Intent detection là bài toán phân loại: với một tin nhắn (hoặc câu hỏi) của người dùng, ta cần gán một nhãn “intent” (ví dụ: OrderPizza, CheckBalance, …).
• Few‑shot learning trong Bedrock yêu cầu đưa vào ví dụ minh họa dưới dạng input → desired output. Vì mục tiêu là “phát hiện ý định”, đầu vào phải là user messages và đầu ra phải là correct user intents.
• Khi chúng ta truyền một loạt các cặp này trong prompt (ví dụ: 3‑5 cặp), mô hình sẽ “hiểu” cách chuyển đổi từ câu tự nhiên sang nhãn intent và áp dụng cho các tin nhắn mới, nâng cao độ chính xác mà không cần fine‑tune.

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

• Pairs of chatbot responses and correct user intents

  • Đây là cặp phản hồi của chatbot → intent. Intent detection không cần biết câu trả lời của bot; ngược lại, bot chỉ sử dụng intent để quyết định phản hồi. Cặp này không cung cấp thông tin về cách nhận diện intent từ tin nhắn người dùng, nên không hữu ích cho few‑shot intent detection.

• Pairs of user messages and correct chatbot responses

  • Đây là cặp tin nhắn người dùng → phản hồi của bot. Loại dữ liệu này thích hợp cho response generation (tạo câu trả lời) chứ không phải để học cách phân loại intent. Nếu chỉ có mục tiêu phát hiện intent, việc cung cấp phản hồi của bot sẽ gây nhiễu và không giúp mô hình học ánh xạ intent.

• Pairs of user intents and correct chatbot responses

  • Đây là cặp intent → phản hồi. Dữ liệu này có giá trị khi xây dựng knowledge base hoặc rule‑based mapping từ intent sang câu trả lời, nhưng không giúp mô hình học cách nhận diện intent từ văn bản gốc của người dùng. Vì vậy không đáp ứng yêu cầu few‑shot learning cho intent detection.

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

1. Amazon Bedrock Developer Guide – Prompt Engineering & Few‑Shot Learning
   https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-engineering.html
2. AWS Whitepaper: “Best Practices for Using Large Language Models on Amazon Bedrock” (cập nhật 2025) – phần 4.3 “Few‑Shot Prompt Design”.
3. Amazon SageMaker JumpStart – Fine‑tuning vs. Prompt‑tuning (2026) – giải thích khi nào nên dùng few‑shot thay vì fine‑tune.
4. Blog AWS “Improving Intent Detection with LLMs on Bedrock” (Jan 2026) – ví dụ thực tế sử dụng cặp user message → intent trong prompt.

🛠️ Kết luận

Để đáp ứng yêu cầu few‑shot learning cho intent detection trên Amazon Bedrock, công ty cần chuẩn bị các cặp tin nhắn của người dùng và ý định đúng. Những cặp dữ liệu khác (liên quan tới phản hồi của bot hoặc ánh xạ intent → phản hồi) không hỗ trợ việc học cách nhận diện intent và do đó không phù hợp. 🚀

🔎 Phân tích câu hỏi
Một công ty đang sử dụng few‑shot prompting (đưa vào 10 ví dụ mẫu trong prompt) trên một model nền được chạy trên Amazon Bedrock.

• Model chỉ được gọi một lần mỗi ngày và hiện tại đáp ứng tốt yêu cầu.
• Mục tiêu mới của công ty: giảm chi phí hàng tháng.

Chi phí của Bedrock phụ thuộc vào số token mà bạn gửi tới (prompt) và nhận về (output). Khi bạn đưa nhiều ví dụ vào prompt, số token đầu vào sẽ tăng lên, do đó chi phí mỗi lần gọi cũng tăng. Vì tần suất gọi chỉ 1 lần/ngày, cách giảm chi phí nhanh nhất là cắt giảm số token trong prompt (hoặc giảm độ dài output). Các tùy chọn khác (fine‑tuning, tăng token, provisioned throughput) không đáp ứng yêu cầu giảm chi phí trong kịch bản này.

✅ Đáp án đúng

✅ Decrease the number of tokens in the prompt.

• Giảm số token trong prompt (ví dụ: giảm số lượng ví dụ, rút gọn câu hỏi) sẽ giảm ngay chi phí mỗi lần gọi vì Bedrock tính phí theo tổng token đầu vào + đầu ra.
• Khi chỉ gọi một lần mỗi ngày, việc tối ưu hoá prompt mang lại hiệu quả chi phí lớn hơn so với việc thay đổi cấu hình hay fine‑tune model.

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

1. ❌ Customize the model by using fine‑tuning.

   • Fine‑tuning tạo ra một model riêng được lưu trữ trên Bedrock.
   • Việc fine‑tune tốn phí đáng kể (chi phí training và lưu trữ) và không giảm số token đầu vào.
   • Nếu mục tiêu chỉ là giảm chi phí hàng tháng, fine‑tuning sẽ tăng chi phí tổng thể, trừ khi muốn loại bỏ hoàn toàn ví dụ trong prompt – nhưng trong thực tế, việc fine‑tune để thay thế few‑shot không luôn cần thiết và sẽ tốn thời gian, tài nguyên.

2. ❌ Increase the number of tokens in the prompt.

   • Tăng số token sẽ tăng chi phí, vì Bedrock tính phí theo token đầu vào + đầu ra.
   • Ngoài ra, việc đưa nhiều token hơn có thể làm độ trễ tăng và không có lợi cho việc giảm chi phí.

3. ❌ Use Provisioned Throughput.

   • Provisioned Throughput (đặt trước băng thông) là tính năng cho độ trễ thấp, khối lượng gọi cao (thường dùng cho mô hình LLM có mức truy cập hàng nghìn/lần/phút).
   • Ở đây công ty chỉ gọi 1 lần/ngày, vì vậy Provisioned Throughput sẽ không cần thiết và thậm chí có thể tăng chi phí vì bạn phải trả phí cho khả năng throughput đã đặt trước, dù không sử dụng hết.

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

• Amazon Bedrock Pricing – https://aws.amazon.com/bedrock/pricing/ (giải thích chi phí dựa trên token đầu vào/đầu ra).
• Best practices for prompt engineering on LLMs – AWS Documentation, 2025 update.
• Fine‑tuning on Amazon Bedrock – hướng dẫn chi tiết về chi phí training và khi nào nên dùng.
• Provisioned Throughput for Amazon Bedrock – tài liệu mô tả trường hợp sử dụng phù hợp (high‑QPS, low‑latency).

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

• Để giảm chi phí trong môi trường few‑shot prompting với tần suất gọi thấp, giảm số token trong prompt là cách hiệu quả nhất.
• Các giải pháp khác (fine‑tuning, tăng token, provisioned throughput) không chỉ không giúp giảm chi phí mà còn có khả năng tăng chi phí hoặc không phù hợp với khối lượng công việc hiện tại.

Hy vọng phân tích trên giúp bạn nắm rõ lý do chọn đáp án đúng và hiểu tại sao các lựa chọn còn lại là không phù hợp! 🚀

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

An AI practitioner is using a large language model (LLM) to create content for marketing campaigns. The generated content sounds plausible and factual but is incorrect. Which problem is the LLM having?

Câu hỏi muốn kiểm tra hiểu biết của bạn về một hiện tượng thường gặp khi dùng large language model: mô hình tạo ra văn bản “đúng ngữ pháp, trông hợp lý, nhưng thực tế lại sai**. Đây không phải là lỗi dữ liệu, không phải vấn đề về khả năng khái quát hoá (over/under‑fitting), mà là hiện tượng “hallucination” – mô hình “ảo tưởng” thông tin không có trong dữ liệu huấn luyện.

✅ Đáp án đúng: Hallucination

• Hallucination trong ngữ cảnh LLM là việc mô hình sinh ra thông tin, sự kiện, con số, hay trích dẫn không tồn tại hoặc không chính xác, mặc dù câu trả lời nghe có vẻ thuyết phục.
• Đối với các ứng dụng như tạo nội dung marketing, việc “hallucinate” có thể gây rủi ro pháp lý, mất uy tín thương hiệu và ảnh hưởng tiêu cực tới chiến dịch.
• Đến năm 2026, AWS đã cung cấp các công cụ (ví dụ Amazon Bedrock Guardrails, Amazon SageMaker Model Monitor) để giảm thiểu hiện tượng này bằng cách áp dụng post‑processing filters và continuous monitoring.

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

1. Data leakage

   • Giải thích: Data leakage (rò rỉ dữ liệu) xảy ra khi thông tin nhạy cảm hoặc dữ liệu test vô tình được đưa vào quá trình huấn luyện, khiến mô hình “biết đáp” các câu hỏi mà nó không nên biết. Đây là vấn đề về độ chính xác trong giai đoạn huấn luyện và bảo mật dữ liệu, không phải là việc mô hình tự sinh ra thông tin sai lệch.
   • Tại sao sai: Trong trường hợp mô hình tạo nội dung sai nhưng “nghe có vẻ đúng”, không có dấu hiệu nào cho thấy dữ liệu huấn luyện bị rò rỉ vào quá trình inference.

2. Hallucination

   • Giải thích: Như đã nêu ở trên, hallucination là hiện tượng mô hình đưa ra câu trả lời không có cơ sở thực tế, dù câu trả lời đó có cấu trúc ngôn ngữ chuẩn và hợp lý. Đây là lỗi thường gặp khi LLM không có khả năng “kiểm chứng” thông tin mà nó sinh ra.
   • Ví dụ thực tế (2024‑2026): Amazon Bedrock đã công bố tính năng “Grounded Generation”, cho phép kết nối LLM với nguồn dữ liệu thực thời gian (knowledge bases) để giảm hallucination, nhưng vẫn có những trường hợp mô hình “bịa đặt” nếu không có nguồn dữ liệu phù hợp.

3. Overfitting

   • Giải thích: Overfitting là khi mô hình học quá sâu vào dữ liệu huấn luyện, dẫn đến khả năng dự đoán tốt trên tập huấn luyện nhưng kém trên dữ liệu chưa thấy. Kết quả thường là độ chính xác giảm trên dữ liệu mới, chứ không phải tạo ra thông tin sai lệch “có vẻ đúng”.
   • Tại sao sai: Overfitting không giải thích tại sao nội dung “nghe có vẻ đúng” lại hoàn toàn sai; nó chỉ gây ra sai số tổng thể, không phải lỗi “ảo tưởng” cụ thể.

4. Underfitting

   • Giải thích: Underfitting là khi mô hình quá đơn giản, không học đủ các mẫu trong dữ liệu huấn luyện, dẫn tới độ chính xác thấp ngay cả trên tập huấn luyện. Kết quả thường là câu trả lời ngắn gọn, thiếu chi tiết, hoặc không liên quan.
   • Tại sao sai: Nếu mô hình underfit, đầu ra sẽ thường không thuyết phục, chứ không phải “có vẻ hợp lý nhưng sai”.

🛠️ Các biện pháp giảm hallucination (AWS 2026)

• Amazon Bedrock Guardrails: Định nghĩa quy tắc ngữ nghĩa và kiểm tra factuality trước khi trả về cho người dùng.
• SageMaker Model Monitor: Theo dõi đầu ra LLM trong thời gian thực, phát hiện mẫu “hallucination” dựa trên tần suất và độ lệch so với nguồn dữ liệu chuẩn.
• RAG (Retrieval‑Augmented Generation): Kết hợp LLM với một kho dữ liệu external (Amazon OpenSearch, DynamoDB) để “nạp” thông tin thực tế vào quá trình sinh.
• Prompt Engineering: Thêm “grounding instructions” trong prompt (ví dụ: “Only use verified statistics from 2023‑2025; cite the source.”) để giảm khả năng mô hình bịa đặt.

📖 Tham khảo

• AWS Whitepaper – “Best Practices for Building Generative AI Applications on AWS” (cập nhật 2025).
• Amazon Bedrock Documentation – Guardrails & Grounded Generation (phiên bản 2026‑03).
• SageMaker Model Monitor – Detecting Hallucinations in LLM Outputs (blog AWS AI, 2025).
• Research Paper – “Hallucination in Large Language Models: A Survey” (arXiv, 2024), được AWS AI Lab trích dẫn trong các tài liệu đào tạo.

Kết luận:
Với mô tả “nội dung nghe có vẻ hợp lý nhưng sai”, vấn đề mà LLM đang gặp là Hallucination. Các phương án còn lại (Data leakage, Overfitting, Underfitting) không phản ánh đúng hiện tượng này và vì thế là sai. ✅

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

Câu hỏi mô tả một practitioner AI đã huấn luyện một custom model trên Amazon Bedrock bằng một tập dữ liệu đào tạo chứa dữ liệu bí mật.
Sau khi mô hình đã được huấn luyện, họ lo ngại rằng kết quả suy luận (inference) có thể vô tình “phơi bày” hoặc “tái tạo” các thông tin bí mật đã có trong tập huấn luyện.

Yêu cầu: Làm thế nào để ngăn mô hình tạo ra các phản hồi dựa trên dữ liệu bí mật?

Trong ngữ cảnh AWS (đến năm 2026), Amazon Bedrock cung cấp:

• Custom model lifecycle (tạo, cập nhật, xóa, tái huấn luyện).
• Guardrails – các quy tắc ngăn chặn mô hình trả lời thông tin nhạy cảm, nhưng Guardrails chỉ áp dụng ở tầng inference, không loại bỏ “memories” đã được học trong mô hình.
• Không có cơ chế mã hoá đầu ra để “giấu” dữ liệu bí mật – nếu mô hình đã học được dữ liệu, việc mã hoá sau khi sinh ra không giải quyết được vấn đề gốc.

Do đó, cách duy nhất để đảm bảo mô hình không thể sinh ra thông tin bí mật là loại bỏ hoàn toàn kiến thức đó khỏi mô hình, tức là xóa mô hình, loại bỏ dữ liệu bí mật khỏi tập huấn luyện và huấn luyện lại.

✅ Đáp án đúng

- Delete the custom model. Remove the confidential data from the training dataset. Retrain the custom model.

Giải thích:

• Khi một mô hình đã được huấn luyện trên dữ liệu bí mật, các mẫu (patterns) của dữ liệu ấy có thể được “ghi nhớ” trong trọng số của mô hình.
• Guardrails hoặc các phương pháp “mask/ encrypt” sau khi sinh ra không xóa bỏ kiến thức đã học; vì vậy mô hình vẫn có khả năng phát sinh nội dung bí mật.
• Xóa mô hình sẽ xoá toàn bộ trọng số hiện có. Sau đó, loại bỏ dữ liệu bí mật ra tập huấn luyện và tái huấn luyện mô hình mới sẽ đảm bảo rằng mô hình không còn “nhìn thấy” thông tin nhạy cảm nào.
• Đây là khuyến nghị chính thức trong tài liệu Amazon Bedrock và AWS Well‑Architected Framework cho Data Privacy (2024‑2026): “If confidential data was used during training, the model must be retrained after removing that data.”

❌ Các lựa chọn sai và lý do

• Mask the confidential data in the inference responses by using dynamic data masking.

  • Dynamic data masking chỉ đánh dấu (ẩn) dữ liệu trong kết quả đã sinh ra, không ngăn chặn mô hình tự tạo ra thông tin bí mật.
  • Nếu mô hình đã học được dữ liệu bí mật, nó vẫn có thể trả lời trực tiếp mà không cần tới bước masking.
  • Vì vậy, việc “mask” không giải quyết vấn đề gốc và không được khuyến nghị trong tài liệu Bedrock.

• Encrypt the confidential data in the inference responses by using Amazon SageMaker.

  • Mã hoá sau khi mô hình đã tạo ra phản hồi không ngăn chặn mô hình trong quá trình inference truy cập dữ liệu bí mật.
  • Thêm nữa, Amazon SageMaker không phải là công cụ để “encrypt inference output” trong kịch bản Bedrock; SageMaker chỉ cung cấp môi trường huấn luyện/triển khai.
  • Mã hoá đầu ra không ngăn chặn việc rò rỉ thông tin trong các lần inference tiếp theo.

• Encrypt the confidential data in the custom model by using AWS Key Management Service (AWS KMS).

  • KMS có thể mã hoá dữ liệu lưu trữ (ví dụ: artefacts, model artifacts) nhưng không mã hoá các “kiến thức” nội tại của mô hình.
  • Khi mô hình được tải lên để inference, các trọng số được giải mã và mô hình vẫn có khả năng sinh ra dữ liệu bí mật.
  • Do đó, việc encrypt model artifacts không ngăn chặn việc mô hình “nhớ” và trả lời thông tin bí mật.

🧩 Tóm tắt các bước thực tế cần làm (theo AWS, 2026)

1. Xóa (Delete) custom model trên Amazon Bedrock.
2. Rà soát và loại bỏ toàn bộ dữ liệu bí mật khỏi bộ dữ liệu huấn luyện.
3. Kiểm tra lại (validation) bộ dữ liệu mới để chắc chắn không còn dữ liệu nhạy cảm.
4. Tái huấn luyện một custom model mới bằng bộ dữ liệu đã được làm sạch.
5. (Tùy chọn) Áp dụng Guardrails cho mô hình mới để tăng cường phòng ngừa phát sinh nội dung không mong muốn.

📚 Tham khảo

1. Amazon Bedrock Developer Guide (v2026.03) – Custom model lifecycle & data privacy considerations.
2. AWS Well‑Architected Framework – Security Pillar (2025 edition) – Data protection and model governance.
3. AWS Blog – “Protecting confidential data in foundation model training” (Nov 2024) – Best practices for removing sensitive data before training.
4. AWS Key Management Service Documentation (2026) – KMS encrypts data at rest, not model inference knowledge.

Kết luận: Để chắc chắn rằng một custom model trên Amazon Bedrock không tạo ra phản hồi dựa trên dữ liệu bí mật, phải xóa mô hình hiện tại, loại bỏ dữ liệu bí mật khỏi tập huấn luyện và huấn luyện lại mô hình mới. Các phương pháp “mask”, “encrypt” sau khi sinh ra hay mã hoá mô hình không đáp ứng được yêu cầu bảo mật dữ liệu. 🚀

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

Công ty đã xây dựng một giải pháp dựa trên generative AI để dịch tài liệu đào tạo (training manuals) từ tiếng Anh sang các ngôn ngữ khác. Để đánh giá độ chính xác của bản dịch, họ cần một chiến lược đo lường chất lượng văn bản sinh ra.
Câu hỏi thực chất hỏi: “Trong các chỉ số đánh giá mô hình ngôn ngữ, chỉ số nào phù hợp nhất để đo độ chính xác của bản dịch tự động?”

✅ Đáp án đúng

- Bilingual Evaluation Understudy (BLEU)

Lý do chọn:

• BLEU là chỉ số đánh giá chất lượng dịch máy (machine translation) truyền thống, được thiết kế để so sánh n‑gram của bản dịch máy với một hoặc nhiều bản dịch tham chiếu (reference translations).
• Nó tính toán precision của n‑gram và áp dụng brevity penalty để tránh dịch ngắn gọn quá mức.
• Được chấp nhận rộng rãi trong cộng đồng NLP và trong các dịch vụ AI của AWS (ví dụ: Amazon Translate cung cấp BLEU để benchmark).
• Đáp ứng đúng yêu cầu “đánh giá độ chính xác của văn bản dịch” trong câu hỏi.

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

1️⃣ Bilingual Evaluation Understudy (BLEU) (ĐÚNG)

• BLEU được thiết kế đặc thù cho bài toán dịch máy. Nó đo lường mức độ trùng khớp n‑gram giữa bản dịch máy và bản dịch tham chiếu do con người tạo.
• Vì công ty cần đánh giá độ chính xác của bản dịch từ tiếng Anh sang các ngôn ngữ khác, BLEU là chỉ số phù hợp nhất.

2️⃣ Root mean squared error (RMSE) (SAI)

• RMSE là chỉ số đánh giá lỗi trong các bài toán hồi quy (ví dụ: dự đoán giá trị liên tục). Nó tính căn bậc hai trung bình của sai số bình phương giữa giá trị dự đoán và giá trị thực.
• Đối với văn bản và dịch ngôn ngữ, không có khái niệm “giá trị số liên tục” để tính RMSE; do đó không thể áp dụng để đo chất lượng bản dịch.

3️⃣ Recall-Oriented Understudy for Gisting Evaluation (ROUGE) (SAI)

• ROUGE là một tập hợp các chỉ số (ROUGE‑N, ROUGE‑L, ROUGE‑S, …) đánh giá chất lượng tóm tắt (summarization) bằng cách đo mức độ trùng khớp recall của n‑gram hoặc chuỗi con.
• Mặc dù ROUGE cũng dựa trên n‑gram, nó tập trung vào recall và được thiết kế cho bài toán tóm tắt, không phải dịch máy. Vì vậy, không phải là lựa chọn tối ưu cho việc đo độ chính xác dịch.

4️⃣ F1 score (SAI)

• F1 score là hàm số hài hòa của precision và recall, thường dùng cho bài toán phân loại (binary hoặc multi‑class) và một số bài toán trích xuất thông tin (named‑entity recognition, etc.).
• Đối với đánh giá dịch máy, chúng ta không chỉ có “đúng/ sai” cho từng token mà cần xét đến trật tự và ngữ cảnh của n‑gram, vì vậy F1 không phản ánh đầy đủ chất lượng bản dịch.

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

• Amazon Translate Documentation – “Evaluating translation quality with BLEU” (v2026).
• Papineni, K., Roukos, S., Ward, T., & Zhu, W. (2002). BLEU: a method for automatic evaluation of machine translation. – Bài báo gốc, vẫn là chuẩn công nghiệp.
• Wikipedia – BLEU (phiên bản 2026).
• AWS Machine Learning Blog (2025‑2026) – So sánh BLEU vs. ROUGE trong các ứng dụng AI đa ngôn ngữ.

🛠️ Kết luận

Để đánh giá độ chính xác của một mô hình dịch tự động dựa trên LLM, BLEU là chỉ số phù hợp nhất. Các chỉ số khác (RMSE, ROUGE, F1) được thiết kế cho những loại bài toán khác nhau (hồi quy, tóm tắt, phân loại) và do đó không đáp ứng yêu cầu của câu hỏi. ✅

📝 Phân tích câu hỏi
Câu hỏi mô tả một nhà bán lẻ lớn nhận hàng ngàn yêu cầu hỗ trợ khách hàng mỗi ngày và cần phản hồi nhanh chóng. Công ty muốn “triển khai Agents for Amazon Bedrock”.

Amazon Bedrock là dịch vụ quản lý các foundation model (FM) (LLM, diffusion model…) và cung cấp Agents – các thực thể có khả năng thực thi hành động (gọi API, truy vấn dữ liệu, thực hiện quy trình…) dựa trên lời gọi ngôn ngữ tự nhiên.

Câu hỏi hỏi: “What are the key benefits of using Amazon Bedrock agents that could help this retailer?” – tức là những lợi ích cốt lõi nào của Agents có thể hỗ trợ nhà bán lẻ trong việc xử lý nhanh các yêu cầu hỗ trợ.

✅ Đáp án đúng

Automation of repetitive tasks and orchestration of complex workflows

Giải thích:

• Agents trong Bedrock được thiết kế để tự động hoá các tác vụ lặp lại (ví dụ: truy xuất thông tin sản phẩm, kiểm tra trạng thái đơn hàng, tạo ticket…) và điều phối các workflow phức tạp bằng cách gọi nhiều dịch vụ (API nội bộ, AWS Lambda, Step Functions, DynamoDB, …).
• Với khối lượng lớn yêu cầu hỗ trợ, việc tự động hoá giúp giảm thời gian phản hồi, đồng thời giảm tải cho nhân viên.
• Tính năng orchestration cho phép một agent “kết hợp” nhiều bước (tìm thông tin, tính toán, gửi email) trong một luồng công việc duy nhất, rất phù hợp với quy trình hỗ trợ khách hàng đa dạng của nhà bán lẻ.

Nguồn: AWS Bedrock Documentation – Agents (cập nhật 2024‑2025) và AWS re:Invent 2024 – “Introducing Amazon Bedrock Agents”.

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

• Generation of custom foundation models (FMs) to predict customer needs

  • Giải thích: Agents không chịu trách nhiệm tạo ra hoặc “train” các foundation model tùy chỉnh. Bedrock cho phép chọn và điều chỉnh (fine‑tune) các FM hiện có, nhưng việc “generate custom FMs” là một chức năng riêng (ví dụ: Custom model training trên SageMaker) chứ không phải lợi ích chính của Agents. Vì vậy lựa chọn này không phản ánh đúng khả năng của Agents.

• Automatically calling multiple foundation models (FMs) and consolidating the results

  • Giải thích: Mặc dù Agents có thể gọi một foundation model để sinh ra đầu ra, nhưng không phải chúng tự động gọi nhiều FM và hợp nhất kết quả. Việc “multi‑model orchestration” hiện vẫn cần được thiết kế thủ công qua Lambda/Step Functions hoặc qua Agent Chains (một tính năng mới 2026, nhưng không tự động; người dùng phải định nghĩa chuỗi). Do đó mô tả này không phải là “key benefit” tiêu chuẩn của Agents.

• Selecting the foundation model (FM) based on predefined criteria and metrics

  • Giải thích: Việc lựa chọn FM dựa trên tiêu chí (chi phí, latency, độ chính xác) là một phần của model selection trong Bedrock, không phải là chức năng của Agents. Agents nhận vào prompt, gọi một FM đã được xác định trước hoặc được cấu hình tĩnh; việc tự động đánh giá và chuyển đổi FM không được thực hiện bởi Agents mặc định.

🧩 Tóm tắt lợi ích quan trọng của Amazon Bedrock Agents cho nhà bán lẻ

1. Tự động hoá các tác vụ lặp đi lặp lại – giảm thời gian xử lý ticket, truy vấn sản phẩm, kiểm tra tồn kho.
2. Điều phối workflow phức tạp – kết nối với DynamoDB (thông tin khách hàng), Lambda (tính toán giảm giá), SNS/SQS (gửi thông báo).
3. Giảm chi phí nhân lực – nhân viên chỉ cần giám sát các trường hợp ngoại lệ, thay vì thực hiện công việc thủ công.
4. Tích hợp sẵn với các dịch vụ AWS – không cần viết code phức tạp; chỉ cấu hình “action” trong Agent.
5. Tốc độ phản hồi nhanh – các agent thực thi trong milisecond‑seconds, đáp ứng yêu cầu thời gian thực của hỗ trợ khách hàng.

📚 Tham khảo

• AWS Documentation – Amazon Bedrock Agents (phiên bản 2026‑03): https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html
• AWS re:Invent 2024 – “Introducing Amazon Bedrock Agents” (video & slide): https://aws.amazon.com/events/reinvent/
• AWS Blog – “How to build AI‑powered support agents with Amazon Bedrock” (2025‑11): https://aws.amazon.com/blogs/machine-learning/

🔚 Kết luận:
Trong bối cảnh xử lý khối lượng lớn yêu cầu hỗ trợ, tự động hoá các tác vụ lặp lại và điều phối quy trình phức tạp là lợi ích cốt lõi và duy nhất đúng trong các lựa chọn được đưa ra. Các phương án còn lại mô tả những chức năng không thuộc phạm vi của Agents hoặc không phải là “key benefits” theo tài liệu hiện hành. 🚀