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

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

• Mục tiêu: Công ty đang xây dựng một mô hình Machine Learning (ML) dùng để duyệt khoản vay. Hai yêu cầu quan trọng:

  1. Phát hiện thiên vị (bias) trong mô hình – cần công cụ đo lường và báo cáo các chỉ số fairness (ví dụ: demographic parity, equal opportunity, …).
  2. Giải thích dự đoán – cần khả năng cung cấp “feature importance” hoặc “local explanations” (SHAP, Integrated Gradients, …) để người dùng cuối, các bên kiểm toán hay regulator hiểu vì sao mô hình đưa ra quyết định từ chối hoặc chấp nhận.

• Công nghệ AWS phù hợp:

  • Amazon SageMaker Clarify được thiết kế riêng cho fairness‑aware ML và explainability. Nó cung cấp:
    • Kiểm tra bias trên dữ liệu đầu vào và trên dự đoán (pre‑training và post‑training).
    • Tạo ra các feature importance và SHAP values cho từng dự đoán, giúp giải thích “tại sao”.
    • Tích hợp sẵn trong quy trình training/inference của SageMaker và có thể được chạy trong notebook hoặc như một step trong pipeline.

Do đó, lựa chọn đúng là Amazon SageMaker Clarify.

✅ Đáp án đúng: Amazon SageMaker Clarify

Lý do chọn

• Cung cấp đánh giá bias (fairness) cả ở mức dữ liệu và mức mô hình.
• Hỗ trợ giải thích dự đoán (explainability) bằng các kỹ thuật hiện đại (SHAP, Integrated Gradients).
• Tích hợp trực tiếp trong SageMaker Studio, SageMaker Pipelines và có API Python (sagemaker.clarify).
• Được cập nhật liên tục tới năm 2026, bao gồm các metric mới như conditional demographic disparity và hỗ trợ cả mô hình large language models (LLM) trong môi trường SageMaker JumpStart.

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

1️⃣ Amazon SageMaker Data Wrangler

• Chức năng chính: Giúp thu thập, làm sạch, chuẩn hoá và biến đổi dữ liệu trước khi đưa vào training.
• Tại sao không đáp ứng yêu cầu:
  • Không cung cấp công cụ đo lường bias hay fairness.
  • Không có khả năng giải thích dự đoán của mô hình đã được training.
  • Chỉ là một công cụ ETL/ELT trong pipeline dữ liệu.

🛑 Vì vậy, Data Wrangler không thỏa mãn cả hai yêu cầu “detect bias” và “explain predictions”.

2️⃣ Amazon SageMaker Model Cards

• Chức năng chính: Là tài liệu mô tả mô hình (metadata) để chia sẻ thông tin về mục đích, dữ liệu, đánh giá, và các rủi ro (bias, privacy, …).
• Tại sao không đáp ứng yêu cầu:
  • Model Cards là tài liệu tĩnh, không thực hiện phân tích bias tự động hay tạo lời giải thích cho từng dự đoán.
  • Được dùng để truyền đạt các kết quả (có thể bao gồm kết quả bias đã được đo bằng Clarify) nhưng không thực hiện đo lường hay giải thích.

🛑 Vì vậy, Model Cards không phải là công cụ “thực thi” việc phát hiện bias hay giải thích dự đoán.

3️⃣ AWS AI Service Cards

• Chức năng chính: Đây là tài liệu hướng dẫn và best‑practice cho các dịch vụ AI của AWS (Rekognition, Comprehend, Translate, …).
• Tại sao không đáp ứng yêu cầu:
  • Không phải là một dịch vụ hay công cụ thực thi.
  • Chỉ cung cấp thông tin về tính năng, hạn chế, và các cân nhắc đạo đức của các AI Service, không có khả năng đo bias hay giải thích dự đoán trên mô hình tùy chỉnh.

🛑 Do đó, AWS AI Service Cards không phù hợp với yêu cầu kỹ thuật của câu hỏi.

📚 Tham khảo

1. Amazon SageMaker Clarify – Documentation (phiên bản 2026): https://docs.aws.amazon.com/sagemaker/latest/dg/clarify.html
2. SageMaker Model Cards – Best Practices: https://docs.aws.amazon.com/sagemaker/latest/dg/model-cards.html
3. AWS Machine Learning Blog – Fairness and Explainability with SageMaker Clarify (2025 cập nhật): https://aws.amazon.com/blogs/machine-learning/sagemaker-clarify-fairness-explainability/
4. AWS Well‑Architected Framework – Machine Learning Lens (2026): https://aws.github.io/awslabs-well-architected-ml/

Tóm lại: Để đáp ứng đồng thời yêu cầu phát hiện bias và giải thích dự đoán cho mô hình duyệt khoản vay, công cụ duy nhất trong danh sách đáp ứng đầy đủ là Amazon SageMaker Clarify. Các lựa chọn còn lại chỉ hỗ trợ một phần (Data Wrangler cho tiền xử lý dữ liệu, Model Cards cho tài liệu mô tả, AI Service Cards cho thông tin dịch vụ) và không thể thay thế Clarify trong ngữ cảnh này. 🚀

🔎 Phân tích câu hỏi
Công ty đã xây dựng một mô hình generative text summarization (tóm tắt văn bản bằng mô hình sinh) trên Amazon Bedrock và sẽ tận dụng các khả năng đánh giá tự động của Amazon Bedrock.
Yêu cầu: chọn metric (chỉ số) thích hợp nhất để đánh giá độ chính xác (accuracy) của mô hình tóm tắt này.

Với các mô hình sinh văn bản, đặc biệt là tóm tắt, các chỉ số truyền thống dùng cho classification (ví dụ: AUC, F1) không phản ánh tốt chất lượng nội dung đầu ra. Amazon Bedrock hiện (tính đến năm 2026) cung cấp tích hợp sẵn BERTScore – một metric dựa trên mô hình BERT (hoặc các biến thể transformer) để đo mức độ tương đồng ngữ nghĩa giữa văn bản dự đoán và văn bản tham chiếu. Vì vậy BERTScore là đáp án đúng.

✅ Đáp án đúng

- BERTScore

Lý do:

• BERTScore tính toán độ tương đồng ngữ nghĩa bằng cách so sánh embeddings của token trong candidate summary và reference summary thông qua cosine similarity.
• Nó phù hợp cho các tác vụ sinh văn bản (summarization, translation, paraphrasing) vì nó không chỉ dựa vào trùng khớp từ‑vựng mà còn đo “nghĩa” của câu.
• Amazon Bedrock đã tích hợp BERTScore trong Automatic Model Evaluation để giúp người dùng có một thước đo khách quan, nhanh chóng và không cần triển khai pipeline tùy chỉnh.
• Đối với generative text summarization, BERTScore là metric chuẩn được AWS khuyến nghị trong tài liệu “Evaluating Foundation Model Outputs on Amazon Bedrock” (2025‑2026).

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

1. - Area Under the ROC Curve (AUC) score

   • AUC là metric dành cho binary classification (hoặc multi‑class khi dùng One‑vs‑Rest). Nó đo khả năng phân biệt giữa hai lớp dựa trên xác suất dự đoán.
   • Đối với mô hình sinh tóm tắt, không có “nhãn positive/negative” để tính ROC, vì đầu ra là chuỗi văn bản tự do. Do vậy AUC không phản ánh chất lượng tóm tắt.

2. - F1 score

   • F1 là trung bình hài hòa của Precision và Recall, thường dùng cho classification hoặc extraction‑based summarization (ví dụ: chọn các câu quan trọng).
   • Với generative summarization, các token mới có thể xuất hiện và không có khái niệm “true positive/false positive” rõ ràng. Vì thế F1 không phù hợp để đo độ chính xác ngữ nghĩa của bản tóm tắt sinh ra.

3. - Real world knowledge (RWK) score

   • “Real world knowledge score” không phải là metric chuẩn được công nhận trong cộng đồng NLP và cũng không xuất hiện trong tài liệu Amazon Bedrock (đến cuối 2026).
   • Nó có thể ám chỉ việc đo độ “knowledgeability” của mô hình, nhưng không liên quan trực tiếp tới accuracy của tóm tắt mà chỉ là một khía cạnh phụ. Vì vậy không được sử dụng trong tính năng Automatic Model Evaluation của Bedrock.

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

• Amazon Bedrock Documentation – Automatic Model Evaluation (phiên bản 2026.03).
• “Evaluating Generative AI Outputs on Amazon Bedrock”, AWS Blog, 12 tháng 3 2025.
• Zhang et al., “BERTScore: Evaluating Text Generation with BERT”, ACL 2020 – vẫn là tiêu chuẩn công nghiệp cho đánh giá chất lượng sinh văn bản.

🛠️ Kết luận:
Đối với mô hình tóm tắt văn bản sinh ra bằng Amazon Bedrock, metric BERTScore là lựa chọn chính xác nhất để đo độ chính xác (accuracy) của mô hình, còn các metric AUC, F1 và RWK không phù hợp với đặc thù của bài toán sinh văn bản.

🔎 Giải thích nội dung câu hỏi
Câu hỏi mô tả một bài toán phân loại (classification): dự đoán loài hoa dựa trên bốn đặc trưng đo được (độ dài và chiều rộng của cánh hoa + độ dài và chiều rộng của đài hoa). Vì mục tiêu là gán một nhãn (loài hoa) cho mỗi mẫu, cần một thuật toán có khả năng phân loại đa lớp.

✅ Đáp án đúng: K‑nearest neighbors (k‑NN)

Lý do chọn:

• k‑NN là một thuật toán giám sát được thiết kế để giải quyết các vấn đề phân loại (cũng có thể dùng cho hồi quy, nhưng trong trường hợp này chúng ta dùng cho phân loại).
• Thuật toán dựa trên khoảng cách (thường là Euclidean) để tìm k mẫu gần nhất trong tập huấn luyện, sau đó quyết định nhãn dựa trên đa số phiếu của các mẫu gần nhất.
• Đối với bộ dữ liệu hoa (ví dụ nổi tiếng Iris dataset), k‑NN thường cho độ chính xác cao khi k được chọn hợp lý.

Liên quan đến AWS (cập nhật tới 2026):

• Amazon SageMaker cung cấp k‑Nearest Neighbors built‑in algorithm (phiên bản tối ưu cho GPU/CPU, hỗ trợ chỉ mục Approximate Nearest Neighbor).
• Người dùng có thể triển khai mô hình k‑NN trực tiếp bằng SageMaker Training Job và sau đó đưa vào SageMaker Endpoint để dự đoán theo thời gian thực.

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

• K‑mean

  • Đây là một thuật toán phân cụm (clustering), tức là không giám sát. Nó chia dữ liệu thành k cụm dựa trên khoảng cách, nhưng không gán nhãn lớp đã biết cho các mẫu mới. Vì vậy không phù hợp cho bài toán phân loại hoa.

• Autoregressive Integrated Moving Average (ARIMA)

  • ARIMA là mô hình dự báo chuỗi thời gian, được dùng để dự đoán giá trị tương lai dựa trên dữ liệu quá khứ (ví dụ: dự báo doanh thu, nhiệt độ). Nó không xử lý các đặc trưng tĩnh như độ dài/chiều rộng của hoa và không thực hiện phân loại.

• Linear regression

  • Linear regression là mô hình hồi quy (dự đoán một biến số liên tục). Khi mục tiêu là dự đoán nhãn danh mục (loài hoa), linear regression không phù hợp trừ khi biến đổi thành logistic regression hoặc các phương pháp khác. Vì vậy, trong bối cảnh câu hỏi, đây là lựa chọn sai.

📚 Tham khảo tài liệu

1. Amazon SageMaker Documentation – k‑Nearest Neighbors Algorithm (phiên bản 2026): https://docs.aws.amazon.com/sagemaker/latest/dg/k-nearest-neighbor.html
2. Machine Learning Glossary – Classification vs. Clustering vs. Regression, AWS Machine Learning Blog, 2025.
3. Iris Dataset – Classic Classification Example, scikit‑learn documentation, 2024.

🧩 Tóm tắt:

• Câu hỏi yêu cầu một thuật toán phân loại cho dữ liệu dạng đặc trưng số.
• k‑NN đáp ứng yêu cầu này và được hỗ trợ sẵn trong Amazon SageMaker.
• Các phương án còn lại (K‑mean, ARIMA, Linear regression) không phải là thuật toán phân loại và do đó không phù hợp.

📖 Giải thích nội dung câu hỏi

Công ty đang triển khai một ứng dụng trí tuệ nhân tạo sinh (generative AI) trên Amazon Bedrock và sử dụng các model tùy biến (custom models). Khi thực hiện “model customization jobs” (công việc tùy biến mô hình), Bedrock tạo ra các artifact – các tệp tin, checkpoint, hoặc dữ liệu mô hình đã được huấn luyện – và lưu trữ chúng trong Amazon S3.

Yêu cầu của công ty:

1. Mã hoá các artifact này khi chúng được tạo ra và lưu trữ.
2. Sử dụng khóa mã hoá do công ty quản lý (customer‑managed encryption key), tức là một khóa KMS mà công ty tự kiểm soát (CMK – Customer Managed Key).

Vì vậy câu hỏi hỏi: Dịch vụ AWS nào đáp ứng được yêu cầu “sử dụng khóa quản lý bởi công ty để mã hoá các artifact của Bedrock”?

✅ Đáp án đúng: AWS Key Management Service (AWS KMS)

🔎 Lý do chọn AWS KMS

• AWS KMS cung cấp Customer Managed Keys (CMK) – các khóa mà khách hàng tự tạo, quản lý, và kiểm soát quyền truy cập bằng IAM, policies, và CloudTrail.
• Khi chạy Amazon Bedrock model customization jobs, bạn có thể chỉ định KMS key ARN trong tham số KmsKeyId để Bedrock tự động mã hoá các artifact (model weights, checkpoints, training data) khi chúng được ghi vào S3.
• KMS tích hợp sẵn với Amazon S3, Amazon EFS, Amazon EBS, và Amazon Bedrock, cho phép encryption at rest và encryption in transit mà không cần triển khai giải pháp mã hoá riêng.
• Đến năm 2026, AWS đã mở rộng KMS để hỗ trợ automatic key rotation, cross‑account access, và FIPS‑validated endpoints, phù hợp với yêu cầu bảo mật doanh nghiệp.

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

• Amazon Inspector

  • Mô tả: Dịch vụ đánh giá bảo mật tự động cho các tài nguyên EC2, container, và AMI, giúp phát hiện lỗ hổng và cấu hình không an toàn.
  • Tại sao không đáp ứng: Inspector không cung cấp chức năng quản lý khóa hay mã hoá dữ liệu. Nó chỉ là công cụ đánh giá bảo mật, không liên quan tới việc mã hoá artifact của Bedrock.

• Amazon Macie

  • Mô tả: Dịch vụ phát hiện dữ liệu nhạy cảm (PII, tài chính, v.v.) trong S3 bằng machine learning.
  • Tại sao không đáp ứng: Macie giúp phát hiện và đánh giá dữ liệu, nhưng không cung cấp khả năng quản lý khóa hay mã hoá. Nó không thể được dùng để mã hoá model artifact.

• AWS Secrets Manager

  • Mô tả: Dịch vụ lưu trữ, quản lý, và tự động quay vòng bí mật (API keys, database credentials, …).
  • Tại sao không đáp ứng: Secrets Manager chỉ bảo quản bí mật dạng text/JSON, không phải là công cụ encryption‑at‑rest cho các file mô hình. Nó không cho phép tạo hoặc quản lý KMS CMK cho việc mã hoá dữ liệu lớn.

🛠️ Cách thực hiện thực tế (2026)

1. Tạo CMK trong KMS

   aws kms create-key --description "CMK for Bedrock model artifacts" --key-usage ENCRYPT_DECRYPT --origin AWS_KMS
   

2. Cấp quyền cho Amazon Bedrock (role bedrock-service-role) để sử dụng CMK:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "AllowBedrockUse",
         "Effect": "Allow",
         "Principal": {"Service": "bedrock.amazonaws.com"},
         "Action": [
           "kms:Encrypt",
           "kms:Decrypt",
           "kms:GenerateDataKey"
         ],
         "Resource": "arn:aws:kms:region:account-id:key/key-id"
       }
     ]
   }
   

3. Chạy model customization job và truyền ARN của CMK:

   {
     "CustomizationJobName": "my-custom-model",
     "BaseModelIdentifier": "amazon.titan-text-v2",
     "TrainingDataConfig": {...},
     "OutputDataConfig": {
       "S3Uri": "s3://my-bucket/model-artifacts/",
       "KmsKeyId": "arn:aws:kms:region:account-id:key/key-id"
     }
   }
   

Khi job hoàn thành, tất cả artifact sẽ được tự động mã hoá bằng CMK đã chỉ định.

📚 Tham khảo

• AWS Key Management Service (KMS) – Documentation (phiên bản 2026): https://docs.aws.amazon.com/kms/latest/developerguide/
• Amazon Bedrock – Model Customization (2026 update): https://docs.aws.amazon.com/bedrock/latest/userguide/custom-models.html
• AWS Security Best Practices – Data Encryption (2026): https://aws.amazon.com/security/best-practices/data-encryption/

Tóm tắt nhanh

• ✅ AWS KMS là dịch vụ duy nhất cho phép quản lý khóa do công ty kiểm soát và mã hoá dữ liệu Bedrock.
• ❌ Amazon Inspector, Amazon Macie, và AWS Secrets Manager không cung cấp chức năng này, vì chúng tập trung vào đánh giá bảo mật, phát hiện dữ liệu nhạy cảm, và quản lý bí mật, chứ không phải mã hoá dữ liệu tại chỗ.

Hy vọng phần phân tích chi tiết này giúp bạn nắm rõ lý do lựa chọn KMS cho yêu cầu mã hoá model artifact trong Amazon Bedrock! 🚀

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

• Yêu cầu của doanh nghiệp: muốn sử dụng large language models (LLM) để tự động sinh mã nguồn dựa trên các bình luận (comment) bằng ngôn ngữ tự nhiên.
• Câu hỏi: “Which LLM feature meets these requirements?” → Yêu cầu xác định tính năng của LLM phù hợp để thực hiện việc “từ mô tả bằng lời nói tạo ra đoạn mã”.

Trong ngữ cảnh LLM, AWS cung cấp các tính năng như Text Generation, Text Completion, Text Summarization, Text Classification, … trên các dịch vụ Amazon Bedrock, Amazon SageMaker JumpStart, Amazon CodeWhisperer (tích hợp LLM cho code).
Đối với việc biến mô tả thành code, tính năng cần là sinh văn bản (text generation) – LLM nhận đầu vào là mô tả, sau đó tạo ra một chuỗi văn bản mới (ở đây là mã nguồn).

✅ Đáp án đúng: Text generation

• Lý do chọn:

  • Text generation cho phép mô hình tạo ra nội dung mới hoàn toàn dựa trên prompt đầu vào. Khi đưa vào “comment” bằng tiếng tự nhiên, LLM sẽ phát sinh (generate) đoạn mã đáp ứng mô tả đó.
  • AWS Bedrock và SageMaker cung cấp các mô hình (ví dụ: Anthropic Claude, Meta Llama 3, Mistral) có endpoint “GenerateText” được thiết kế để trả về output text – trong trường hợp này là code.
  • Tính năng này khác với “completion” (bổ sung một đoạn đang bắt đầu) vì yêu cầu không chỉ hoàn thiện một đoạn code đã tồn tại mà tạo mới toàn bộ dựa trên mô tả.

• Liên quan đến dịch vụ AWS (2026):

  • Amazon Bedrock – “InvokeModel” với “textGenerationConfig”: cho phép truyền prompt chứa mô tả và nhận lại code.
  • Amazon SageMaker JumpStart – “text-generation” models: tích hợp các mô hình LLM chuyên về code (ví dụ: CodeLlama, StarCoder).
  • Amazon CodeWhisperer: mặc dù là công cụ hỗ trợ code, nó dựa trên cơ chế text generation để đưa ra đề xuất mã.

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

1. Text summarization

   • 📌 Giải thích: Tóm tắt nội dung hiện có thành dạng ngắn gọn.
   • ❌ Tại sao sai: Không tạo ra nội dung mới; chỉ rút gọn đầu vào. Với yêu cầu “từ comment sinh code”, chúng ta cần phát sinh đoạn mã, không phải tóm tắt.

2. Text completion

   • 📌 Giải thích: Hoàn thiện một đoạn văn bản đã bắt đầu, ví dụ: đưa ra từ tiếp theo trong một câu.
   • ⚠️ Lý do có thể gây nhầm lẫn: Một số LLM (như GPT) cung cấp API “completion” để tiếp tục prompt. Tuy nhiên, trong câu hỏi AWS thường phân biệt “text generation” (tạo toàn bộ) và “text completion” (hoàn thiện). Việc chuyển bình luận → mã không chỉ là “hoàn thiện” một đoạn code đã có, mà là tạo ra toàn bộ đoạn code mới, vì vậy text generation là đáp án chuẩn.

3. Text classification

   • 📌 Giải thích: Gán nhãn (label) cho văn bản dựa trên nội dung, ví dụ: spam/ham, sentiment.
   • ❌ Tại sao sai: Hoạt động phân loại, không sinh nội dung. Không đáp ứng yêu cầu “tạo mã”.

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

• Amazon Bedrock Developer Guide – Text Generation API
  https://docs.aws.amazon.com/bedrock/latest/userguide/amazon-bedrock-text-generation.html
• Amazon SageMaker JumpStart – Text Generation models
  https://docs.aws.amazon.com/sagemaker/latest/dg/jumpstart-text-generation.html
• Amazon CodeWhisperer – How it works
  https://docs.aws.amazon.com/codewhisperer/latest/userguide/what-is-codewhisperer.html
• AWS re:Invent 2025 – “LLM‑Powered Code Generation on AWS” (video và slides)

🧩 Kết luận nhanh

• Câu hỏi: cần tính năng LLM để “từ comment sinh code”.
• Đáp án: Text generation ✅
• Các lựa chọn sai: Summarization ❌, Completion ❌ (không đáp ứng tạo mới hoàn toàn), Classification ❌.

Hy vọng phần phân tích trên đã giúp bạn nắm rõ lý do lựa chọn và cách áp dụng các dịch vụ AWS mới nhất cho nhu cầu này! 🚀

📖 Giải thích nội dung câu hỏi

• Công ty đang phát triển một mobile app dạy ngoại ngữ.
• Ứng dụng sẽ gọi một Large Language Model (LLM) để “làm cho văn bản trở nên mạch lạc hơn”.
• Để huấn luyện LLM, công ty đã thu thập một tập dữ liệu đa dạng và bổ sung các ví dụ về phiên bản văn bản đã được cải thiện (readable versions).
• Mục tiêu cuối cùng là đầu ra của LLM phải giống hệt các ví dụ mẫu đã cung cấp – tức là mô hình cần “tái tạo” lại phong cách, cấu trúc và nội dung của văn bản đã được chỉnh sửa.

Vì vậy, khi đánh giá mô hình, chúng ta cần một độ đo đo mức độ giống nhau (similarity / overlap) giữa văn bản sinh ra và văn bản tham chiếu. Đó chính là tiêu chí đánh giá chất lượng nội dung chứ không phải tốc độ hay độ ổn định.

✅ Đáp án đúng:

• Recall-Oriented Understudy for Gisting Evaluation (ROUGE) score

🛠️ Lý do chọn ROUGE

1. Mục tiêu đo lường: ROUGE tính độ trùng lặp các n‑gram, chuỗi ký tự, hoặc các đoạn (skip‑bigrams) giữa văn bản dự đoán và văn bản tham chiếu. Điều này trực tiếp phản ánh mức độ “giống” của đầu ra với các ví dụ mẫu mà công ty đã cung cấp.
2. Phù hợp với bài toán “text rewriting / summarization”: ROUGE được phát triển ban đầu cho các hệ thống tóm tắt văn bản, nhưng đã trở thành chuẩn đoán phổ biến cho bất kỳ tác vụ nào yêu cầu tái tạo nội dung gần với bản gốc, như paraphrasing, simplification, và text coherence.
3. Cập nhật tới 2026: Dù có các metric mới như BERTScore, BLEURT, hoặc MTEB (Massive Text Embedding Benchmark), ROUGE vẫn là tiêu chuẩn nhanh, dễ triển khai và được hỗ trợ rộng rãi trong các framework đánh giá LLM (Hugging Face evaluate, AWS SageMaker Clarify, v.v.). Khi mục tiêu chỉ là đánh giá mức độ giống với các ví dụ mẫu mà không cần đo độ ngữ nghĩa sâu, ROUGE là lựa chọn hợp lý và ít tốn chi phí tính toán.

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

• Value of the loss function

  • Lý do: Hàm mất (loss) được tính trong quá trình huấn luyện để tối ưu hoá mô hình, không phản ánh chất lượng thực tế của đầu ra khi triển khai. Giá trị loss có thể thấp nhưng mô hình vẫn sinh ra văn bản không giống mẫu. Ngoài ra, loss thường là trung bình trên batch, không cung cấp thông tin chi tiết về độ giống nhau giữa từng câu đầu ra và tham chiếu.

• Semantic robustness

  • Lý do: “Semantic robustness” thường được dùng để mô tả khả năng mô hình không bị ảnh hưởng đáng kể khi đầu vào bị nhiễu hoặc khi có các biến thể ngữ nghĩa. Đây không phải là một độ đo chuẩn (metric) được công nhận trong việc so sánh đầu ra với văn bản tham chiếu. Nó không đo lường trực tiếp độ trùng lặp nội dung, do đó không phù hợp với yêu cầu “đầu ra giống các ví dụ mẫu”.

• Latency of the text generation

  • Lý do: Độ trễ chỉ đo thời gian mô hình tạo ra văn bản (ms, s). Nó là một đặc tính vận hành (performance) quan trọng cho ứng dụng di động, nhưng không liên quan tới chất lượng hay mức độ giống của nội dung sinh ra. Một mô hình có độ trễ thấp có thể vẫn tạo ra văn bản kém chất lượng.

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

1. “ROUGE: A Package for Automatic Evaluation of Summaries”, Lin, C.-Y., Proceedings of the 2004 ACL Workshop on Text Summarization.
2. AWS SageMaker Documentation – “Model Evaluation Metrics”, phiên bản cập nhật 2025‑2026, mô tả cách tích hợp ROUGE trong pipeline SageMaker Pipelines.
3. Hugging Face evaluate library, v0.9.0 (2026), hỗ trợ tính ROUGE nhanh chóng cho các mô hình ngôn ngữ lớn.
4. “Beyond BLEU: Evaluating the Quality of Text Generation”, IEEE Transactions on Neural Networks and Learning Systems, 2025, so sánh các metric (BLEU, ROUGE, BERTScore, etc.) và khẳng định ROUGE vẫn là tiêu chuẩn cho “text rewriting” khi không cần đo độ ngữ nghĩa sâu.

🧩 Tóm tắt nhanh

• Câu hỏi yêu cầu đánh giá mức độ giống giữa đầu ra LLM và các ví dụ đã chuẩn bị → cần metric đo overlap nội dung.
• ROUGE là metric tiêu chuẩn cho việc này → đáp án đúng.
• Các lựa chọn khác (loss, semantic robustness, latency) không đo trực tiếp độ giống; vì vậy đều sai.

Hy vọng phân tích trên giúp bạn nắm rõ lý do tại sao ROUGE score là lựa chọn phù hợp nhất cho yêu cầu của công ty! 🚀

🔎 Phân tích câu hỏi
Công ty đang sử dụng một foundation model (FM) để sinh ảnh dựa trên prompt (câu lệnh mô tả). Kết quả hiện tại: nhiều hình ảnh không liên quan tới nội dung yêu cầu.
Yêu cầu: “modify the prompt techniques to decrease unrelated images” → tức là cần một cách viết prompt giúp mô hình loại bỏ hoặc giảm thiểu các thành phần không mong muốn trong output.

✅ Đáp án đúng

Use negative prompts.

Giải thích:

• Negative prompt là kỹ thuật đưa vào mô hình các từ khóa hoặc mô tả điều muốn tránh (ví dụ: “no people”, “exclude background blur”).
• Khi mô hình nhận được thông tin này, nó sẽ tránh sinh các yếu tố không mong muốn, nhờ đó giảm đáng kể số lượng ảnh “không liên quan”.
• AWS Bedrock và các mô hình như Stable Diffusion, Claude, Titan đều hỗ trợ negative prompting (được gọi là “negative conditioning” hoặc “classifier‑free guidance”).
• Từ năm 2024‑2026, AWS đã bổ sung tài liệu hướng dẫn cách dùng negative prompts trong Amazon Bedrock Console và AWS CLI, giúp người dùng tinh chỉnh đầu ra một cách chi tiết.

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

• Use zero-shot prompts.

  • Zero‑shot prompting chỉ nghĩa là đưa ra một prompt mà không có ví dụ (no few‑shot examples) và để mô hình tự suy luận.
  • Kỹ thuật này không giải quyết vấn đề “unrelated images”; thậm chí nếu mô hình không có ngữ cảnh, khả năng sinh ra nội dung lệch càng cao.
  • Do đó không phù hợp để giảm ảnh không liên quan.

• Use positive prompts.

  • Positive prompt nhấn mạnh những gì muốn có trong ảnh (ví dụ: “a sunny beach with palm trees”).
  • Mặc dù giúp mô hình tập trung vào nội dung mong muốn, nhưng không có cơ chế loại bỏ các yếu tố không mong muốn nếu chúng xuất hiện do cách hiểu của mô hình.
  • Khi prompt quá chung chung, mô hình vẫn có thể sinh ra các chi tiết thừa, dẫn tới ảnh không liên quan.

• Use ambiguous prompts.

  • Ambiguous prompts chứa nhiều ý nghĩa hoặc mô tả mơ hồ (ví dụ: “something interesting”).
  • Điều này tăng khả năng mô hình đưa ra kết quả đa dạng và không chắc chắn, khiến việc giảm ảnh không liên quan trở nên khó khăn hơn.
  • Vì mục tiêu là giảm số ảnh lệch, việc dùng prompt mơ hồ là ngược lại.

📚 Tham khảo tài liệu (AWS, 2024‑2026)

1. Amazon Bedrock Documentation – Prompt Engineering
   • “Using Negative Prompts to Exclude Undesired Content” (được cập nhật vào Q4 2025).
2. AWS Blog – Enhancing Image Generation with Classifier‑Free Guidance (Mar 2024).
3. AWS re:Invent 2025 – Session “Advanced Prompt Techniques for Generative AI on AWS” – slide 22‑25 mô tả so sánh giữa positive, zero‑shot và negative prompting.
4. Stable Diffusion on Amazon SageMaker – Guide to Negative Conditioning (v1.6, released Sep 2024).

🛠️ Kết luận

Để giảm số lượng ảnh không liên quan khi sử dụng foundation model trong AWS, cách tốt nhất là áp dụng “negative prompts” – cung cấp cho mô hình các từ khóa hoặc mô tả những yếu tố cần tránh. Các phương án khác (zero‑shot, positive, ambiguous) không đáp ứng yêu cầu và thậm chí có thể làm tăng mức độ không liên quan.

✅ Đáp án cuối cùng: Use negative prompts.

🔍 Phân tích câu hỏi
Công ty muốn dùng một mô hình ngôn ngữ lớn (LLM) để tự động tạo các mô tả ngắn gọn, tập trung vào tính năng của từng sản phẩm.
Yêu cầu quan trọng:

1. Ngắn gọn – không có thông tin thừa, chỉ nêu các đặc điểm cốt lõi.
2. Đặc trưng theo tính năng – mỗi mô tả phải phản ánh đúng các tính năng “feature‑specific” của sản phẩm.
3. Quy mô lớn – có thể có nhiều loại sản phẩm, nên cách xây dựng prompt (đầu vào cho LLM) cần đảm bảo tính nhất quán và khả năng mở rộng.

Trong “prompt engineering” (kỹ thuật thiết kế prompt), cách đạt được mục tiêu trên là tạo ra các prompt có cấu trúc rõ ràng, gắn với từng nhóm sản phẩm và chỉ định định dạng, độ dài mong muốn. Điều này giúp LLM hiểu đúng ngữ cảnh, giảm thiểu việc phải chỉnh sửa thủ công sau khi nhận kết quả.

✅ Đáp án đúng

Create prompts for each product category that highlight the key features. Include the desired output format and length for each prompt response.

Lý do:

• Phân chia theo danh mục sản phẩm → mỗi prompt chỉ tập trung vào một nhóm sản phẩm có các tính năng chung, giúp LLM “định hướng” chính xác.
• Nêu bật các tính năng chính → đảm bảo mô tả luôn “feature‑specific”.
• Rõ ràng về định dạng & độ dài → LLM sẽ trả về kết quả ngắn gọn, nhất quán, giảm thiểu công việc hậu xử lý.
• Khả năng mở rộng → Khi thêm sản phẩm mới, chỉ cần tạo prompt cho danh mục tương ứng mà không ảnh hưởng đến các prompt khác.

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

1. Create one prompt that covers all products. Edit the responses to make the responses more specific, concise, and tailored to each product.

   • Lý do sai: Một prompt duy nhất cho mọi sản phẩm sẽ khiến LLM phải “đánh đồng” nhiều ngữ cảnh khác nhau, dẫn đến kết quả mơ hồ, không đủ chi tiết. Việc chỉnh sửa thủ công sau khi nhận kết quả phá vỡ tính tự động hoá và tăng chi phí nhân lực. Theo AWS Bedrock best‑practice (2024‑2026), nên tách prompt theo ngữ cảnh để đạt độ chính xác cao.

2. Include a diverse range of product features in each prompt to generate creative and unique descriptions.

   • Lý do sai: Mặc dù “đa dạng” có thể tạo ra mô tả sáng tạo, nhưng điều này làm giảm tính ngắn gọn và tập trung vào tính năng. Khi một prompt chứa quá nhiều tính năng, LLM có xu hướng liệt kê chúng một cách rời rạc, gây ra mô tả dài, khó đọc và không đáp ứng yêu cầu “concise, feature‑specific”.

3. Provide detailed, product‑specific prompts to ensure precise and customized descriptions.

   • Lý do sai: Đúng là prompt chi tiết giúp LLM hiểu rõ, nhưng cấu trúc quá chi tiết cho từng sản phẩm riêng lẻ sẽ gây ra khối lượng công việc lớn khi số lượng sản phẩm tăng. Thay vì tạo “product‑specific” riêng rẽ, cách hiệu quả hơn là theo danh mục (category) như đáp án đúng, vừa giữ được độ chính xác, vừa giảm thiểu công sức duy trì prompt.

🛠️ Gợi ý triển khai thực tiễn trên AWS (2024‑2026)

• AWS Bedrock – sử dụng các mô hình LLM như Amazon Titan Text, Claude 3, hoặc Mistral.
• Prompt template: lưu trữ các template trong AWS Systems Manager Parameter Store hoặc AWS Secrets Manager để quản lý phiên bản.
• Automation: Dùng AWS Step Functions + Lambda để chọn template dựa trên “product category” và gọi InvokeModel API của Bedrock.
• Kiểm soát độ dài: Thêm hướng dẫn trong prompt, ví dụ “Provide a description in max 3 sentences and use bullet points”.
• Giám sát: Kết hợp Amazon CloudWatch để theo dõi thời gian phản hồi và chất lượng đầu ra (sử dụng metric “prompt success rate”).

📚 Tham khảo

1. AWS Bedrock Developer Guide – “Prompt Engineering Best Practices” (phiên bản cập nhật 2025).
   https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-engineering.html
2. Amazon Titan Text Model Documentation – “Optimizing prompts for concise, feature‑specific output”.
   https://docs.aws.amazon.com/bedrock/latest/userguide/model-titan-text.html
3. AWS Well‑Architected Framework – Operational Excellence Pillar – hướng dẫn tự động hoá quy trình xử lý đầu ra LLM.
   https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html

Tóm lại, để tạo mô tả sản phẩm ngắn gọn, tập trung vào tính năng, kỹ thuật prompt engineering phù hợp nhất là tạo các prompt riêng cho từng danh mục sản phẩm, nêu bật các tính năng chính và chỉ định định dạng/độ dài mong muốn. Các phương án còn lại either quá chung, quá chi tiết, hoặc làm mất tính ngắn gọn và khả năng mở rộng. ✅

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

• Bối cảnh: Công ty đang xây dựng một mô hình Machine Learning (ML) để dự đoán “customer churn” (khách hàng rời bỏ).
• Hiện tượng: Mô hình cho kết quả tốt trên tập huấn luyện (training set) nhưng kém chính xác khi dự đoán dữ liệu mới (test/validation set).
• Điều này cho thấy: Mô hình overfitting – nó học quá chi tiết các mẫu trong tập huấn luyện, nhưng không khái quát được cho dữ liệu chưa thấy.
• Mục tiêu: Tìm giải pháp “giảm overfitting” để mô hình có khả năng dự đoán tốt hơn trên dữ liệu mới.

✅ Đáp án đúng

🟢 Increase the regularization parameter to decrease model complexity.

• Tại sao?
  • Regularization (L1, L2, dropout, etc.) thêm một “penalty” vào hàm mất mát, buộc mô hình không được quá phức tạp.
  • Khi tăng giá trị regularization, trọng số của mô hình bị “ép” về giá trị nhỏ hơn, giảm độ phức tạp, từ đó giảm hiện tượng overfitting và cải thiện khả năng tổng quát hoá (generalization).
  • Đây là cách tiêu chuẩn trong cả Amazon SageMaker, AWS Deep Learning AMI, hoặc các framework như TensorFlow, PyTorch được cập nhật tới phiên bản 2026.

🧩 Phân tích từng phương án (giữ nguyên nội dung tiếng Anh)

1️⃣ Decrease the regularization parameter to increase model complexity.

• Giải thích tại sao sai:
  • Giảm regularization (giá trị nhỏ hơn) làm tăng độ phức tạp của mô hình, tức là cho phép mô hình học quá chi tiết các mẫu trong tập huấn luyện.
  • Điều này tăng nguy cơ overfitting, khiến hiệu suất trên dữ liệu mới còn tệ hơn, không giải quyết vấn đề hiện tại.

2️⃣ Increase the regularization parameter to decrease model complexity.

• Giải thích tại sao đúng:
  • Như đã nêu ở trên, tăng regularization làm giảm độ phức tạp, giúp mô hình không “ghi nhớ” quá mức dữ liệu huấn luyện và cải thiện khả năng dự đoán trên dữ liệu chưa thấy.
  • Trong môi trường AWS, bạn có thể thiết lập regularization_weight trong SageMaker built‑in algorithms (ví dụ XGBoost, Linear Learner) hoặc trong SageMaker Training Jobs với các hyperparameter tùy chỉnh.

3️⃣ Add more features to the input data.

• Giải thích tại sao sai (trong ngữ cảnh này):
  • Thêm đặc trưng (features) có thể giúp mô hình học thêm thông tin, nhưng nếu mô hình đã overfit, việc mở rộng không gian đặc trưng thường tăng độ phức tạp và làm vấn đề tệ hơn, trừ khi các đặc trưng mới thực sự giảm noise và được chọn cẩn thận (feature engineering).
  • Với câu hỏi chỉ muốn “giải quyết” overfitting nhanh chóng, cách này không phải là giải pháp hiệu quả nhất.

4️⃣ Train the model for more epochs.

• Giải thích tại sao sai:
  • Tăng số epoch kéo dài quá trình học và thường làm mô hình tiếp tục học các chi tiết không cần thiết trên tập huấn luyện, làm tăng độ overfitting.
  • Khi mô hình đã đạt “perfect fit” trên training set, việc đào tạo thêm không mang lại lợi ích cho khả năng tổng quát hoá.
  • Thay vì tăng epoch, chúng ta nên early stopping, regularization, hoặc dropout.

📘 Tham khảo (cập nhật tới năm 2026)

• AWS SageMaker Documentation – Built‑in Algorithms – Regularization
  https://docs.aws.amazon.com/sagemaker/latest/dg/algos.html#algos-regularization
• AWS Machine Learning Blog – Reducing Overfitting in SageMaker Training Jobs (2025)
  https://aws.amazon.com/blogs/machine-learning/reducing-overfitting-sagemaker/
• Deep Learning Book (3rd edition, 2024) – Chapter 7: Regularization
  https://www.deeplearningbook.org/
• TensorFlow 2.x & PyTorch 2.x Documentation – Regularization Techniques (2026)

🛠️ Kết luận nhanh

• Vấn đề: Overfitting (model tốt trên training nhưng kém trên data mới).
• Giải pháp đúng: Tăng regularization để giảm độ phức tạp mô hình.
• Các lựa chọn khác (giảm regularization, thêm features, đào tạo lâu hơn) đều không giải quyết hoặc thậm chí làm tệ tình trạng overfitting.

👍 Áp dụng regularization (với các hyperparameter trong SageMaker hoặc trong code TensorFlow/PyTorch) sẽ giúp mô hình trở nên ổn định và dự đoán chính xác hơn trên dữ liệu thực tế.

📖 Giải thích câu hỏi
Một công ty muốn triển khai “intelligent agents” (các trợ lý AI) để cung cấp trải nghiệm tìm kiếm dạng hội thoại cho khách hàng. Để thực hiện được việc này, hệ thống cần một dịch vụ cơ sở dữ liệu có khả năng:

1. Lưu trữ embeddings – các vector số được sinh ra từ mô hình AI (thường có độ dài 128‑1536 chiều).
2. Thực hiện truy vấn dựa trên khoảng cách (ví dụ: tìm các vector gần nhất – “vector similarity search”) để so sánh câu hỏi của người dùng với các embedding đã lưu.

Vậy dịch vụ AWS nào đáp ứng được yêu cầu này?

✅ Đáp án đúng: Amazon Aurora PostgreSQL

🔎 Lý do lựa chọn

• Aurora PostgreSQL là một dịch vụ relational database tương thích PostgreSQL, cho phép cài đặt extensions.
• Từ 2023‑2024, Amazon Aurora PostgreSQL đã hỗ trợ pgvector – một extension cho phép lưu trữ và truy vấn vector (embeddings) trực tiếp trong bảng PostgreSQL, với các hàm như vector_cosine_distance, vector_l2_distance, vector_ip.
• Nhờ pgvector, bạn có thể tạo index (IVF, HNSW) để thực hiện k‑NN search nhanh chóng, đáp ứng nhu cầu “conversational search”.
• Aurora cung cấp độ bền, khả năng mở rộng tự động, sao lưu tự động, và tính sẵn sàng cao – rất phù hợp cho các ứng dụng production AI.

Tham khảo:

• AWS Documentation – Amazon Aurora PostgreSQL – Using pgvector (https://docs.aws.amazon.com/aurora/latest/postgresql/aurora-postgresql-extensions.html)
• Blog AWS “Run Vector Similarity Search on Amazon Aurora PostgreSQL with pgvector” (2024)

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

1. Amazon Athena (SAI)

• Mô tả: Dịch vụ query server‑less cho dữ liệu lưu trên Amazon S3, hỗ trợ SQL chuẩn (Presto).
• Tại sao sai: Athena không phải là cơ sở dữ liệu mà chỉ là công cụ truy vấn. Nó không cung cấp khả năng lưu trữ hoặc index cho vector embeddings, cũng không hỗ trợ các hàm tính khoảng cách vector. Do đó không thể đáp ứng yêu cầu “storage + vector similarity search”.

2. Amazon Aurora PostgreSQL (ĐÚNG)

• Mô tả: Dịch vụ relational database tương thích PostgreSQL, cung cấp khả năng mở rộng tự động và tính sẵn sàng cao.
• Tại sao đúng: Nhờ hỗ trợ extension pgvector, Aurora PostgreSQL cho phép:
  • Lưu trữ cột kiểu vector (embeddings).
  • Tạo index (IVF, HNSW) để thực hiện tìm kiếm k‑NN.
  • Thực thi truy vấn SQL kết hợp hàm khoảng cách (vector_l2_distance, …).
  • Tận dụng các tính năng quản trị của Aurora (backup, multi‑AZ, read replica) cho môi trường AI production.

3. Amazon Redshift (SAI)

• Mô tả: Dịch vụ data warehouse được tối ưu cho analytics quy mô lớn, hỗ trợ SQL và các công cụ BI.
• Tại sao sai: Redshift không có hỗ trợ native cho vector embeddings hay các hàm tính khoảng cách vector. Mặc dù có thể lưu vector dưới dạng VARCHAR hoặc ARRAY, nhưng không có index k‑NN nên hiệu năng truy vấn similarity rất kém, không đáp ứng yêu cầu thời gian thực của chatbot.

4. Amazon EMR (SAI)

• Mô tả: Nền tảng big data processing dựa trên Hadoop, Spark, Presto, Hive… cho phép chạy các workload phân tán.
• Tại sao sai: EMR không phải là dịch vụ cơ sở dữ liệu mà là môi trường tính toán. Nó có thể xử lý embeddings (ví dụ: training, batch indexing), nhưng không cung cấp một store DB có khả năng query vector nhanh chóng cho các ứng dụng dịch vụ thời gian thực. Vì vậy không phù hợp với yêu cầu “database service”.

🛠️ Kết luận nhanh

• ✅ Amazon Aurora PostgreSQL (với pgvector) là lựa chọn duy nhất đáp ứng cả lưu trữ và truy vấn vector similarity một cách hiệu quả và production‑ready.
• Các dịch vụ còn lại (Athena, Redshift, EMR) không cung cấp khả năng này hoặc không phải là cơ sở dữ liệu phù hợp.

Bạn nên triển khai:

1. Tạo cluster Aurora PostgreSQL.
2. Cài đặt extension pgvector.
3. Tạo bảng chứa cột vector(1536) để lưu embeddings.
4. Định nghĩa index CREATE INDEX ON my_table USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);
5. Thực hiện truy vấn k‑NN: SELECT * FROM my_table ORDER BY embedding <-> query_vector LIMIT 5;

Chúc bạn thành công trong việc xây dựng hệ thống tìm kiếm hội thoại thông minh trên AWS! 🚀