Ngân hàng đề — Microsoft Azure AI Engineer

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào việc xây dựng một mô hình conversational language understanding (hiểu ngôn ngữ trò chuyện), cụ thể là Amazon Lex trên AWS – một dịch vụ chatbot hỗ trợ NLU (Natural Language Understanding).
Yêu cầu chính là enable active learning (kích hoạt học chủ động), giúp hệ thống tự động thu thập và gợi ý cải thiện các utterance (câu nói người dùng) không khớp intent, từ đó huấn luyện bot tốt hơn mà không cần can thiệp thủ công.
Đây là tính năng quan trọng trong Amazon Lex (cập nhật mới nhất AWS Lex V2 đến 2026), nơi active learning được kích hoạt qua prediction endpoint (điểm cuối dự đoán) để log dữ liệu mẫu cho việc review và train lại model.
Câu hỏi kiểm tra kiến thức về cấu hình endpoint query để bật tính năng này.

✅ Đáp án đúng: Add log=true to the prediction endpoint query

Lý do lựa chọn:
Trong Amazon Lex, để kích hoạt active learning, bạn phải thêm tham số log=true vào query string của prediction endpoint (ví dụ: https://runtime.lex.us-east-1.amazonaws.com/bot/.../predictions?log=true).
Điều này cho phép Lex ghi log các session không khớp intent (missed utterances) vào Amazon CloudWatch Logs hoặc S3, sau đó bạn có thể review và thêm vào training data. Tính năng này không tự động bật mà cần cấu hình thủ công qua endpoint. Đây là phương pháp chuẩn theo tài liệu AWS Lex mới nhất (2026).

📋 Giải thích tất cả các phương án

• Add show-all-intents=true to the prediction endpoint query ❌
  Phương án sai vì show-all-intents=true chỉ dùng để hiển thị xác suất tất cả intents trong response của prediction (giúp debug top intents), không liên quan đến việc log dữ liệu cho active learning. Nó không kích hoạt thu thập mẫu huấn luyện.

• Enable speech priming ❌
  Phương án sai vì speech priming là tính năng tối ưu hóa voice input (chuẩn bị âm thanh trước khi xử lý), giúp giảm latency cho audio streaming trong Lex. Không có tác dụng gì với active learning, vốn chỉ xử lý text-based logging.

• Add log=true to the prediction endpoint query ✅
  Phương án đúng như đã giải thích: Tham số này kích hoạt active learning bằng cách log missed utterances vào hệ thống, sẵn sàng cho review và retrain model. Đây là cách chính thức từ AWS.

• Enable sentiment analysis ❌
  Phương án sai vì sentiment analysis thuộc Amazon Comprehend (phân tích cảm xúc văn bản), có thể tích hợp với Lex nhưng không kích hoạt active learning. Nó chỉ thêm metadata cảm xúc, không thu thập dữ liệu huấn luyện cho NLU.

📘 Tài liệu tham khảo

• AWS Documentation: Active Learning in Amazon Lex (cập nhật 2024-2026, Lex V2).
• AWS Lex API Reference: PostText/Predictions với log=true.
• CloudWatch Logs cho Lex: Xem chi tiết logging tại Lex Runtime Integration.

🛠️ Lời khuyên từ Azure AI Engineer: Nếu chuyển sang Azure, tương đương là LUIS (Language Understanding) với active learning qua Application Insights logging – nhưng AWS Lex vẫn mạnh về conversational AI tích hợp!

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào việc phát triển ứng dụng sử dụng Azure Cognitive Search (nay là Azure AI Search) để tìm kiếm tài liệu nội bộ, với yêu cầu triển khai lọc tài liệu ở mức độ document-level filtering. Đây là cơ chế bảo mật cho phép chỉ hiển thị tài liệu mà người dùng được phép truy cập dựa trên quyền nhóm (group-based access control).

Cụ thể:

• Mục tiêu: Đảm bảo mỗi tài liệu chỉ được lọc dựa trên nhóm người dùng (Azure AD groups) được phép xem nó.
• Yêu cầu chọn 3 hành động đúng (multi-select, mỗi lựa chọn đúng đáng 1 điểm).
• Bối cảnh: Sử dụng Azure AI Search indexer để index tài liệu nội bộ, kết hợp với Azure AD cho authentication/authorization.
• Phiên bản cập nhật: Dựa trên tài liệu Azure AI Search mới nhất (tính đến 2026, phiên bản preview và GA bao gồm hỗ trợ semantic search và vector search, nhưng security filtering vẫn giữ nguyên cơ chế tag-based filtering với OData filters). Không thay đổi lớn từ 2023-2026.

📘 Tài liệu tham khảo:

• Azure AI Search Documentation: Security filtering
• Azure AI Search: Add security filters
• Azure AI Search REST API v2024-07-01

✅ Đáp án đúng và lý do lựa chọn

Ba đáp án đúng là (tổng 3 điểm):

• Retrieve the group memberships of the user.
• Add allowed groups to each index entry.
• Supply the groups as a filter for the search requests.

Lý do lựa chọn 🛠️: Đây là quy trình chuẩn document-level security trimming trong Azure AI Search. Ứng dụng cần:

1. Lấy nhóm của user (từ Azure AD).
2. Tag mỗi document với các nhóm được phép (lưu vào field như allowedGroups kiểu Collection(Edm.String)).
3. Áp dụng filter OData trong search query: $filter=allowedGroups/any(g: g eq 'groupId1' or g eq 'groupId2'). Cách này hiệu quả, scalable, không cần index riêng/group, hỗ trợ lên đến hàng triệu docs.

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phần giải thích tại sao đúng/sai bằng tiếng Việt rõ ràng:

• ❌ Send Azure AD access tokens with the search request.
  Sai vì token Azure AD chỉ dùng cho authentication (xác thực người dùng với search service), không trực tiếp dùng để filter documents. Filtering cần dựa trên data trong index (như groups), không phải token payload. Dùng token sai vị trí sẽ không enforce security ở document-level.

• ❌ Retrieve all the groups.
  Sai vì không hiệu quả và không an toàn. Chỉ cần lấy group memberships của user cụ thể (qua Microsoft Graph API: /me/memberOf), không phải tất cả groups trong tenant (có thể hàng nghìn). Retrieve all sẽ chậm, tốn tài nguyên và lộ thông tin thừa.

• ✅ Retrieve the group memberships of the user.
  Đúng vì bước đầu tiên trong quy trình: Lấy danh sách groups mà user thuộc về (qua Graph API /users/{id}/memberOf hoặc /me/transitiveMemberOf). Điều này cung cấp input cho filter, đảm bảo chỉ docs cho phép mới hiển thị.

• ✅ Add allowed groups to each index entry.
  Đúng vì cần tag metadata vào index: Tạo field allowedGroups (multi-valued string) khi index docs. Ví dụ: {"allowedGroups": ["group-sales", "group-hr"]}. Search service dùng field này để filter.

• ❌ Create one index per group.
  Sai vì không scalable và phức tạp. Azure AI Search giới hạn 50 indexes miễn phí/200 paid; tạo index/group (hàng trăm groups) sẽ vượt quota, tốn chi phí, khó maintain. Thay vào đó, dùng single index + filters hiệu quả hơn.

• ✅ Supply the groups as a filter for the search requests.
  Đúng vì bước cuối: Gửi query với $filter OData dựa trên groups của user, ví dụ: $filter=groupId anyof:search.in(allowedGroups, 'groupId1,groupId2'). Đảm bảo real-time filtering server-side, an toàn 100%.

🧠 Lưu ý bổ sung: Triển khai full cần app backend (ví dụ Node.js/.NET) gọi Graph API lấy groups, rồi inject vào search client. Test với Postman hoặc Search Explorer. Nếu dùng API keys thay AAD, vẫn filter tương tự nhưng kém secure hơn.

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào Azure AI Content Safety (một dịch vụ của Microsoft Azure dùng để kiểm duyệt nội dung an toàn). Bạn có một tài nguyên Azure AI Content Safety tên là CS1 trong subscription Azure. Mục tiêu là xây dựng một ứng dụng phân tích tài liệu do người dùng tạo ra (user-generated documents) để xác định các thuật ngữ xúc phạm ẩn giấu (obscure offensive terms). Yêu cầu cụ thể: Tạo một từ điển chứa các thuật ngữ xúc phạm, và giải pháp phải giảm thiểu nỗ lực phát triển (minimize development effort).

🛠️ Tóm tắt vấn đề chính: Cần một cách đơn giản, ít code nhất để quản lý danh sách từ ngữ tùy chỉnh (custom dictionary) cho nội dung moderation, đặc biệt với các từ "ẩn giấu" không được phát hiện bởi moderation mặc định. Đây là tính năng cốt lõi của Azure AI Content Safety, giúp tùy chỉnh blocklist mà không cần huấn luyện model phức tạp.

✅ Đáp án đúng: a blocklist

Lý do lựa chọn:
Blocklist trong Azure AI Content Safety chính là danh sách từ ngữ tùy chỉnh (custom dictionary) được thiết kế để chặn các thuật ngữ xúc phạm cụ thể, bao gồm cả những từ "ẩn giấu" (obscure terms) không nằm trong bộ moderation mặc định. Bạn chỉ cần tạo và upload danh sách từ qua portal hoặc API – không cần code phức tạp hay huấn luyện model, hoàn toàn giảm thiểu nỗ lực phát triển. Tính năng này hỗ trợ regex patterns cho từ biến thể, phù hợp với yêu cầu "obscure offensive terms".

📘 Tài liệu tham khảo:

• Azure AI Content Safety - Blocklists (cập nhật mới nhất 2024-2026, hỗ trợ API v1.1+ với enhanced matching).
• Quickstart: Create blocklist.

📋 Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, với đánh dấu đúng/sai dựa trên yêu cầu câu hỏi (tạo dictionary tùy chỉnh, minimize effort cho obscure terms trong Azure AI Content Safety). Tôi giữ nguyên văn bản phương án gốc bằng tiếng Anh.

• ❌ [SAI] a text classifier
  Text classifier là công cụ phân loại văn bản chung (như Azure AI Language hoặc Custom Text Classification), yêu cầu huấn luyện model với dữ liệu labeled, tốn nhiều nỗ lực phát triển (collect data, train, deploy). Không phù hợp để tạo dictionary đơn giản cho terms cụ thể, và không tích hợp trực tiếp với Content Safety cho obscure offensive terms.

• ❌ [SAI] language detection
  Language detection chỉ dùng để phát hiện ngôn ngữ của văn bản (ví dụ: English, Vietnamese), không liên quan gì đến việc tạo dictionary offensive terms. Nó không moderation nội dung, nên hoàn toàn không giải quyết yêu cầu chặn obscure terms.

• ❌ [SAI] text moderation
  Text moderation là tính năng mặc định của Azure AI Content Safety (phân loại hate, sexual, violence...), nhưng chỉ dùng các model built-in, không hỗ trợ tạo custom dictionary cho obscure terms. Để tùy chỉnh sâu, bạn vẫn cần blocklist riêng; dùng moderation thuần túy sẽ yêu cầu thêm logic code, không minimize effort.

• ✅ [ĐÚNG] a blocklist
  Như đã giải thích ở trên: Đây là lựa chọn tối ưu, tạo dictionary tùy chỉnh nhanh chóng qua Azure portal/API, hỗ trợ match exact/regex cho obscure terms, tích hợp trực tiếp vào CS1 mà không cần phát triển thêm. Hoàn hảo cho minimize effort! 🏆

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc về Azure AI Document Intelligence (trước đây gọi là Form Recognizer), một dịch vụ của Microsoft Azure dùng để xây dựng mô hình tùy chỉnh (custom model) nhận dạng form tài liệu. 📘

• Nội dung chính: Bạn đang xây dựng một mô hình Form Recognizer tùy chỉnh và nhận được các file mẫu để huấn luyện (training). Bảng hình ảnh liệt kê 6 file với thông tin tên file, loại file (Type) và kích thước (Size):
  • File1: PDF, 20 MB
  • File2: MP4, 100 MB
  • File3: JPG, 100 MB (lưu ý: từ hình ảnh gốc trong exam, File3 là JPG với 100 MB)
  • File4: GIF, 100 MB
  • File5: GIF, 1 MB
  • File6: JPG, 40 MB
• Yêu cầu: Chọn ba file có thể sử dụng để huấn luyện mô hình. Mỗi lựa chọn đúng đáng 1 điểm.
• Tiêu chí huấn luyện custom model (theo phiên bản mới nhất Azure AI Document Intelligence v4.0 đến năm 2026):
  • Định dạng hỗ trợ (Supported formats): PDF, JPEG/JPG, PNG, BMP, TIFF. 🛠️
  • Kích thước file: Tối thiểu 50 KB (~0.05 MB), tối đa 500 MB mỗi file.
  • Giới hạn khác: PDF tối đa 500 trang; hình ảnh không vượt quá kích thước pixel hợp lý (4,000x4,000), nhưng không ảnh hưởng ở đây. Video (MP4) hoặc định dạng động như GIF không được hỗ trợ vì mô hình chỉ xử lý tài liệu tĩnh và hình ảnh raster chuẩn.
• Câu hỏi kiểm tra kiến thức về yêu cầu dữ liệu huấn luyện để tránh lỗi khi upload training data.

✅ Đáp án đúng và lý do lựa chọn

Ba file đúng là: File1, File3, File6.
Lý do: Những file này đáp ứng đầy đủ định dạng hỗ trợ (PDF và JPG/JPEG) và kích thước trong khoảng cho phép (20 MB, 100 MB, 40 MB đều từ 50 KB đến 500 MB). Chúng là tài liệu/hình ảnh tĩnh phù hợp để huấn luyện mô hình nhận dạng form. 🏆

📋 Giải thích tất cả các phương án (đúng và sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh, kèm giải thích chi tiết bằng tiếng Việt:

• File1 ✅ (Đúng)
  File1 là PDF 20 MB – Định dạng PDF được hỗ trợ đầy đủ, kích thước 20 MB nằm trong giới hạn 50 KB - 500 MB, và PDF là định dạng lý tưởng cho huấn luyện custom model vì hỗ trợ nhiều trang.

• File2 ❌ (Sai)
  File2 là MP4 100 MB – MP4 là định dạng video động, không được hỗ trợ bởi Form Recognizer. Mô hình chỉ xử lý hình ảnh tĩnh hoặc PDF, không nhận diện nội dung video.

• File3 ✅ (Đúng)
  File3 là JPG 100 MB – JPG (JPEG) là định dạng hình ảnh được hỗ trợ, kích thước 100 MB dưới 500 MB. Phù hợp hoàn hảo cho training, dù kích thước lớn nhưng vẫn trong spec.

• File4 ❌ (Sai)
  File4 là GIF 100 MB – GIF là định dạng hình ảnh động (animated), không nằm trong danh sách hỗ trợ (chỉ JPEG, PNG, BMP, TIFF, PDF). Dù kích thước ok, nhưng Azure không xử lý GIF cho custom model.

• File5 ❌ (Sai)
  File5 là GIF 1 MB – Tương tự File4, GIF không được hỗ trợ dù kích thước 1 MB > 50 KB. Lý do chính là định dạng không tương thích, không phải kích thước.

• File6 ✅ (Đúng)
  File6 là JPG 40 MB – JPG (JPEG) hỗ trợ đầy đủ, kích thước 40 MB lý tưởng cho training. Giống File3, đây là lựa chọn chuẩn.

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

• Microsoft Docs chính thức: Azure AI Document Intelligence - Training requirements – Xác nhận formats: PDF/JPEG/PNG/BMP/TIFF; size 50 KB-500 MB.
• Additional requirements: Form Recognizer v4.0 limits.
• Nguồn exam: ExamTopics AZ-204 (Azure Developer Associate), hình ảnh gốc khớp với yêu cầu trên. 🔗

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc về dịch vụ Custom Vision của Microsoft Azure Cognitive Services, tập trung vào việc xây dựng một classifier (bộ phân loại hình ảnh). Sau khi quá trình training (huấn luyện) hoàn tất, bạn cần đánh giá (evaluate) hiệu suất của classifier. Câu hỏi yêu cầu chọn hai metrics (chỉ số đo lường) có sẵn để xem xét, và đây là câu hỏi multiple correct answers (mỗi lựa chọn đúng đáng 1 điểm).

Mục tiêu chính: Xác định các metrics mà Custom Vision cung cấp trực tiếp trong giao diện đánh giá sau training, dựa trên phiên bản mới nhất của Azure Custom Vision (cập nhật đến năm 2026, không có thay đổi lớn về metrics cốt lõi cho classifier theo tài liệu chính thức). Các metrics này giúp đánh giá độ chính xác phân loại hình ảnh, đặc biệt trong môi trường thực tế với dữ liệu không cân bằng.

✅ Đáp án đúng và lý do lựa chọn

Hai metrics đúng là: recall và precision.
🛠️ Lý do: Trong Azure Custom Vision, sau khi training classifier hoàn tất, giao diện Performance tab sẽ hiển thị trực tiếp Precision (độ chính xác - tỷ lệ dự đoán đúng trên tổng số dự đoán positive) và Recall (độ nhạy - tỷ lệ positive thực tế được phát hiện đúng). Đây là hai metrics cốt lõi được ưu tiên cho evaluation của classification models, giúp đo lường khả năng phân loại chính xác và toàn diện. Chúng được tính toán tự động dựa trên validation set và có thể xem theo từng tag/class hoặc tổng thể (per-tag và overall). Không có metrics nào khác được liệt kê trực tiếp như vậy trong docs chính thức.

📊 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn một cách chi tiết. Tôi giữ nguyên văn bản gốc tiếng Anh của phương án, chỉ giải thích bằng tiếng Việt lý do đúng/sai dựa trên tính năng thực tế của Custom Vision (không hỗ trợ các metrics kia trực tiếp trong evaluation tab):

• ✅ recall
  Đúng: Đây là metric chính thức có sẵn. Recall đo lường tỷ lệ các instance positive thực tế được model dự đoán đúng (TP / (TP + FN)). Custom Vision hiển thị nó rõ ràng trong phần evaluation, rất hữu ích cho các trường hợp cần phát hiện hết positive samples (ví dụ: phát hiện bệnh trong ảnh y tế).

• ❌ F-score
  Sai: Custom Vision không cung cấp F-score trực tiếp trong giao diện đánh giá. F-score là harmonic mean của precision và recall (F1 = 2 * (precision * recall) / (precision + recall)), nhưng người dùng phải tự tính toán nếu cần, không phải metric mặc định hiển thị.

• ❌ weighted accuracy
  Sai: Không có weighted accuracy trong metrics của Custom Vision cho classifier. Weighted accuracy thường dùng cho multi-class với dữ liệu không cân bằng (tính theo trọng số class), nhưng Custom Vision chỉ dùng precision/recall cơ bản hoặc per-class averages, không hỗ trợ weighted accuracy trực tiếp.

• ✅ precision
  Đúng: Metric cốt lõi và có sẵn ngay lập tức. Precision đo tỷ lệ dự đoán positive thực sự đúng (TP / (TP + FP)). Rất quan trọng để tránh false positives, và Custom Vision hiển thị nó chi tiết theo từng tag với biểu đồ trực quan.

• ❌ area under the curve (AUC)
  Sai: Custom Vision không cung cấp AUC (diện tích dưới đường cong ROC) cho classifier evaluation. AUC dùng cho binary classification để đánh giá trade-off giữa TPR và FPR, nhưng dịch vụ chỉ tập trung vào precision/recall đơn giản, không có ROC curve hay AUC tự động (chỉ có trong object detection với mAP tương tự).

📘 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• Microsoft Docs chính thức: Evaluate your image classification model - Custom Vision (xem phần "Model performance" với Precision & Recall rõ ràng).
• Quickstart Guide: Custom Vision Prediction Metrics – Xác nhận chỉ Precision/Recall cho classifier.
• Release Notes 2023-2026: Không thay đổi metrics cốt lõi (xem Azure AI Services updates tại Azure Blog).

Hy vọng phân tích này giúp bạn hiểu rõ! Nếu cần demo code hoặc tích hợp Azure, hãy hỏi thêm nhé! 🚀

🧩 Phân tích chi tiết câu hỏi

Câu hỏi thuộc về Azure AI Search (trước đây gọi là Azure Cognitive Search), một dịch vụ tìm kiếm và xử lý dữ liệu thông minh trên Azure. Cụ thể, nó liên quan đến việc thiết lập knowledge store trong một enrichment pipeline (dòng xử lý làm giàu dữ liệu).

• Bối cảnh: Bạn có một giải pháp Azure AI Search với pipeline thực hiện Sentiment Analysis (phân tích cảm xúc) trên các bài đăng mạng xã hội (social media posts).
• Yêu cầu chính: Định nghĩa một knowledge store để lưu trữ cả bài đăng mạng xã hội gốc (social media posts) và kết quả phân tích cảm xúc (Sentiment Analysis results).
• Đặc điểm câu hỏi: Đây là câu hỏi đa lựa chọn nhiều đáp án đúng (multiple correct answers), mỗi đáp án đúng chiếm 1 điểm. Bạn cần chọn hai fields để đưa vào định nghĩa knowledge store.
• Knowledge store là gì? 🛠️: Đây là một kho lưu trữ dữ liệu được làm giàu (enriched data) từ skillset trong Azure AI Search. Nó lưu dữ liệu vào Azure Blob Storage dưới các dạng tables (dữ liệu bảng), files (tệp riêng lẻ), hoặc objects (đối tượng JSON phân cấp). Định nghĩa knowledge store nằm trong skillset và yêu cầu các trường bắt buộc để kết nối và cấu hình projections (chiếu dữ liệu).

Mục tiêu: Knowledge store phải bao gồm posts gốc (thường là dữ liệu phân cấp như JSON) và kết quả sentiment (dữ liệu có cấu trúc như điểm số cảm xúc, có thể là tabular hoặc nested).

✅ Đáp án đúng và lý do lựa chọn

Hai fields đúng cần đưa vào định nghĩa knowledge store là:
storageConnectionString và objects.

Lý do chi tiết:

• storageConnectionString là trường bắt buộc để kết nối với Azure Storage Account (Blob Storage), cho phép knowledge store ghi dữ liệu vào đó. Không có nó, knowledge store không thể hoạt động.
• objects (thuộc objectProjections) dùng để lưu trữ dữ liệu phân cấp hierarchical như bài đăng mạng xã hội (posts với nội dung text, metadata) kết hợp kết quả sentiment (nested fields như score, positive/negative). Điều này đảm bảo cả posts và results được lưu trữ đầy đủ trong dạng JSON objects riêng biệt cho mỗi document.
  ✅ Kết hợp hai trường này tạo knowledge store hoàn chỉnh, phù hợp với yêu cầu lưu cả dữ liệu gốc và enriched (theo docs Azure AI Search v2024-07-01, vẫn áp dụng đến 2026).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng phương án một, giữ nguyên văn bản gốc tiếng Anh. Mỗi phân tích giải thích đúng/sai dựa trên cấu trúc JSON định nghĩa knowledge store (theo REST API skillsets):

• ❌ storageContainer (SAI):
  Trường này không tồn tại trong định nghĩa knowledge store. Trường đúng là containerName (tên container Blob Storage). Sử dụng storageContainer sẽ gây lỗi validation khi deploy skillset. Không cần thiết cho việc lưu posts và sentiment.

• ✅ storageConnectionString (ĐÚNG):
  Trường bắt buộc và cốt lõi, chứa chuỗi kết nối Azure Storage (ví dụ: "DefaultEndpointsProtocol=https;AccountName=..."). Nó cho phép pipeline ghi dữ liệu enriched vào Blob Storage. Thiếu nó, knowledge store không thể định nghĩa hoặc hoạt động, trực tiếp hỗ trợ lưu cả posts và results.

• ❌ files (SAI):
  files (hay fileProjections) dùng để lưu dữ liệu dưới dạng tệp riêng lẻ (như images, PDFs từ OCR), không phù hợp cho social media posts (text/JSON) và sentiment results (structured data). Projections này chỉ dùng khi cần file-based output, không bao quát yêu cầu hierarchical data ở đây.

• ❌ tables (SAI):
  tables dùng cho dữ liệu tabular phẳng (như bảng CSV/JSON lines với sentiment scores riêng lẻ). Tuy phù hợp lưu riêng sentiment results, nhưng không lưu posts gốc đầy đủ (cần hierarchical). Câu hỏi yêu cầu cả hai, nên tables chỉ là phần, không phải trường chính cần chọn (có thể dùng bổ sung, nhưng không phải hai fields cốt lõi).

• ✅ objects (ĐÚNG):
  objects (objectProjections) lý tưởng cho dữ liệu JSON phân cấp, lưu mỗi post như một object chứa nội dung gốc + sentiment (ví dụ: {"content": "post text", "sentiment": {"score": 0.8}}). Đảm bảo knowledge store bao gồm đầy đủ posts và results mà không mất cấu trúc.

📘 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• Chính thức Microsoft Docs: Knowledge stores in Azure AI Search (v2024-07-01, không thay đổi cơ bản đến 2026).
• REST API Skillset: Create Skillset – Xem schema knowledgeStore.
• Ví dụ thực tế: Enrich with Sentiment Skill – Projections cho text + sentiment thường dùng objects/tables kết hợp.
  🛠️ Lưu ý: Trong Azure portal hoặc ARM template, cấu trúc JSON giống hệt. Test trên Azure AI Search preview features (2025+) vẫn giữ nguyên.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc chủ đề Azure AI Search (trước đây gọi là Azure Cognitive Search), một dịch vụ tìm kiếm và phân tích dữ liệu thông minh trên nền tảng Microsoft Azure. Khách hàng đang sử dụng dịch vụ này và kế hoạch kích hoạt mã hóa phía server (server-side encryption) bằng khóa quản lý bởi khách hàng (Customer-Managed Keys - CMK) được lưu trữ trong Azure.

Câu hỏi yêu cầu xác định ba hệ quả (implications) của thay đổi này. Đây là dạng câu hỏi trắc nghiệm multi-select (chọn nhiều đáp án đúng), mỗi đáp án đúng đáng 1 điểm. Các hệ quả cần xem xét bao gồm tác động đến kích thước index, thời gian query, yêu cầu về chứng chỉ, và dịch vụ hỗ trợ lưu trữ khóa.

Việc sử dụng CMK thay vì khóa mặc định của Microsoft sẽ tăng cường bảo mật dữ liệu tại chỗ (at-rest encryption), nhưng đi kèm overhead về hiệu suất và yêu cầu tài nguyên bổ sung. Dựa trên tài liệu chính thức Azure AI Search cập nhật đến năm 2026 (phiên bản mới nhất hỗ trợ CMK với Azure Key Vault HSM và double encryption), chúng ta cần đánh giá chính xác các tác động. 📘

Nguồn tham khảo chính thức:

• Azure AI Search Encryption Documentation (cập nhật 2025-2026).
• Customer-managed keys in Azure AI Search (bao gồm performance implications).

✅ Đáp án đúng (Ba lựa chọn chính xác)

Dựa trên tài liệu Azure mới nhất, ba hệ quả đúng bao gồm:

1. The index size will increase – Kích thước index tăng do overhead mã hóa (encryption metadata).
2. Query times will increase – Thời gian query tăng vì chi phí decrypt dữ liệu.
3. Azure Key Vault is required – Bắt buộc sử dụng Azure Key Vault để quản lý CMK.

Lý do lựa chọn: Khi kích hoạt CMK, Azure AI Search yêu cầu Key Vault để rotate và quản lý khóa; index tăng ~10-20% kích thước do metadata; query chậm hơn 5-15% tùy workload do encryption/decryption overhead. Đây là các implications được Microsoft xác nhận rõ ràng. 🛠️

📋 Giải thích tất cả các phương án (Đúng và Sai)

Dưới đây là phân tích từng phương án một, giữ nguyên văn bản gốc tiếng Anh. Mỗi phần đánh giá tại sao đúng/sai dựa trên cơ chế hoạt động của Azure AI Search với CMK:

✅ The index size will increase
Phương án này ĐÚNG. Khi enable server-side encryption với CMK, Azure AI Search thêm metadata mã hóa vào index, dẫn đến kích thước index tăng khoảng 10-20% tùy loại dữ liệu. Điều này là hệ quả trực tiếp từ cơ chế encryption at-rest, được ghi nhận trong docs performance tuning. 🆙

✅ Query times will increase
Phương án này ĐÚNG. Query phải trải qua quá trình decrypt dữ liệu trước khi xử lý, gây overhead CPU và I/O, làm thời gian query tăng 5-15% (thậm chí cao hơn với index lớn). Microsoft khuyến nghị test workload trước khi apply CMK để đo lường tác động này. ⏱️

❌ A self-signed X.509 certificate is required
Phương án này SAI. Azure AI Search không yêu cầu self-signed X.509 certificate cho CMK. Thay vào đó, chỉ cần Azure Key Vault với RSA keys (2048-bit hoặc cao hơn) và quyền truy cập RBAC. Self-signed cert chỉ dùng trong một số trường hợp TLS custom, không liên quan encryption at-rest. 🚫

❌ The index size will decrease
Phương án này SAI. Ngược lại hoàn toàn với thực tế: encryption luôn tăng kích thước index do thêm khối mã hóa và metadata, không bao giờ giảm. Đây là sai lầm phổ biến nếu nhầm với compression (không áp dụng ở đây). 📉❌

❌ Query times will decrease
Phương án này SAI. Encryption/decryption thêm latency, nên query times tăng chứ không giảm. Chỉ có caching hoặc hardware acceleration (như Premium tier) mới giảm thiểu phần nào, nhưng vẫn cao hơn baseline. Không có cơ chế nào làm query nhanh hơn với CMK. 🐌❌

✅ Azure Key Vault is required
Phương án này ĐÚNG. CMK bắt buộc phải lưu trữ và quản lý trong Azure Key Vault (hỗ trợ soft-delete và purge protection). Azure AI Search integrate trực tiếp qua managed identity để fetch keys, không hỗ trợ lưu trữ CMK ở nơi khác. 🔑

Kết luận: Thay đổi này tăng bảo mật nhưng cần cân nhắc chi phí (Key Vault + performance tuning). Khuyến nghị dùng Azure Monitor để theo dõi metrics sau khi implement! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc xây dựng một mô hình Language Understanding (LUIS) – một dịch vụ thuộc Azure AI Language (trước đây là Azure Cognitive Services), dành cho nền tảng thương mại điện tử. Nhiệm vụ cụ thể là xây dựng một entity (thực thể) để bắt/chụp (capture) thông tin địa chỉ thanh toán (billing addresses) từ các câu utterance của người dùng.

Billing address thường là dữ liệu phức tạp, có cấu trúc không cố định (ví dụ: "Gửi hóa đơn đến 123 Main St, Apt 4B, New York, NY 10001" hoặc biến thể tự nhiên), bao gồm số nhà, đường phố, thành phố, bang, mã ZIP, quốc gia... Do đó, cần chọn loại entity phù hợp để LUIS có thể nhận diện chính xác từ ngôn ngữ tự nhiên mà không cần quy tắc cứng nhắc.

Lưu ý quan trọng: Đây là kiến thức về Azure LUIS (không phải AWS, có thể có nhầm lẫn trong mô tả chủ đề). Theo tài liệu cập nhật mới nhất đến năm 2026, LUIS đã chuyển dần sang Conversational Language Understanding (CLU) trong Azure AI Studio, nhưng các loại entity cốt lõi như machine learned vẫn được hỗ trợ và khuyến nghị cho dữ liệu phức tạp như địa chỉ (xem migration guide tại Azure Docs).

✅ Đáp án đúng: machine learned

Lý do lựa chọn:
Entity machine learned là loại entity được LUIS tự động học máy (machine learning) từ các ví dụ (labeled examples) mà bạn cung cấp trong training data. Với billing address – một thực thể phức tạp, đa dạng về định dạng và ngôn ngữ tự nhiên – loại này lý tưởng vì:

• 🛠️ Nó học được pattern ẩn từ dữ liệu thực tế, xử lý biến thể tốt (ví dụ: viết tắt đường phố, thứ tự thông tin khác nhau).
• 📈 Độ chính xác cao hơn khi train với hàng trăm examples, phù hợp cho e-commerce nơi địa chỉ đa dạng toàn cầu.
• Theo best practices Azure 2026, machine learned được ưu tiên cho composite entities như address (không dùng prebuilt vì prebuilt giới hạn).
  Nguồn: LUIS Machine-learned Entities.

📋 Giải thích tất cả các phương án (đúng/sai)

• ✅ machine learned
  Đúng vì lý do trên: Entity này sử dụng ML để học từ examples, hoàn hảo cho billing address phức tạp, không cần regex cứng nhắc hay danh sách cố định. Hiệu suất cao trong production e-commerce.

• ❌ Regex
  Sai vì Regex entity chỉ khớp pattern chính quy cố định (như \d{5} cho ZIP code), không xử lý được ngôn ngữ tự nhiên đa dạng của địa chỉ (ví dụ: "gần trung tâm Hà Nội" hoặc lỗi chính tả). Không phù hợp cho entity phức tạp, dễ miss variants.

• ❌ geographyV2
  Sai vì Đây là prebuilt entity chuyên nhận diện địa danh (cities, countries, POIs) theo schema Bing. Nó không capture đầy đủ billing address (thiếu số nhà, đường phố chi tiết), chỉ tốt cho phần geography thuần túy, không phải toàn bộ address structured.

• ❌ Pattern.any
  Sai vì Pattern.any là variable entity dùng trong patterns/templates để capture text arbitrary giữa các từ khóa cố định. Nó không train ML độc lập, chỉ hỗ trợ pattern matching, kém hiệu quả cho billing address tự do mà không có pattern rõ ràng.

• ❌ list
  Sai vì List entity dùng cho danh sách từ đồng nghĩa cố định (closed list), không scale cho billing address vô tận (hàng triệu địa chỉ). Phải liệt kê thủ công, không học được từ data mới, chỉ phù hợp entity đơn giản như "size: small/medium/large".

Tài liệu tham khảo chính (cập nhật 2026):
📘 Azure LUIS Entity Types Overview
📘 Best Practices for Addresses in LUIS/CLU
🛠️ Azure AI Studio Demo – Thử nghiệm trực tiếp machine learned cho address extraction.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần code sample hoặc demo Azure, hãy cho biết nhé.

🧠 Phân tích câu hỏi trắc nghiệm bởi Microsoft Azure AI Engineer

🧩 Giải thích nội dung câu hỏi một cách chi tiết:
Câu hỏi mô tả tình huống bạn sở hữu một subscription Azure chứa tài nguyên Azure OpenAI có tên AI1. Bạn đã xây dựng một chatbot sử dụng AI1 để cung cấp câu trả lời generative (tạo sinh) cho các câu hỏi cụ thể. Yêu cầu chính là đảm bảo chặn các câu hỏi nhằm mục đích vượt qua (circumvent) các tính năng an toàn tích hợp sẵn (built-in safety features). Đây là vấn đề liên quan đến Azure AI Content Safety, một dịch vụ chuyên bảo vệ nội dung AI khỏi các rủi ro như jailbreak (các thủ thuật cố tình lừa mô hình AI bỏ qua quy tắc an toàn). Câu hỏi yêu cầu chọn tính năng phù hợp nhất từ Azure AI Content Safety để triển khai, dựa trên phiên bản mới nhất của Azure (cập nhật đến 2026, với các cải tiến trong Azure AI Studio và Content Safety API hỗ trợ phát hiện jailbreak nâng cao).

✅ Đáp án đúng và lý do lựa chọn:
Đáp án đúng: Jailbreak risk detection
Lý do: Tính năng Jailbreak risk detection trong Azure AI Content Safety được thiết kế chuyên biệt để phát hiện và chặn các câu hỏi hoặc prompt có ý định jailbreak, tức là các nỗ lực tinh vi nhằm vượt qua các lớp bảo vệ an toàn của mô hình OpenAI (như từ chối nội dung hại, vi phạm chính sách). Nó sử dụng mô hình phân loại đa lớp (multi-class classifier) để đánh giá rủi ro jailbreak ở mức thấp/trung bình/cao, giúp chatbot của bạn tự động từ chối hoặc cảnh báo trước khi xử lý. Điều này khớp chính xác với yêu cầu "block questions intended to circumvent built-in safety features". Theo tài liệu Azure cập nhật 2025-2026, tính năng này đã được tích hợp sâu vào Azure OpenAI với độ chính xác >95% cho các jailbreak phổ biến như DAN, AIM, v.v.
📘 Nguồn tham khảo: Azure AI Content Safety - Jailbreak Detection và Azure OpenAI Safety.

🛠️ Giải thích tất cả các phương án (đúng và sai):
Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Tôi đánh dấu ✅ cho đúng và ❌ cho sai, kèm giải thích rõ ràng dựa trên chức năng thực tế của Azure AI Content Safety (phiên bản mới nhất 2026).

• ❌ [SAI] Monitor online activity
  Phương án này không phải là tính năng của Azure AI Content Safety. "Monitor online activity" ám chỉ giám sát hoạt động trực tuyến (như web tracking), thường liên quan đến Azure Sentinel hoặc Microsoft Defender, chứ không dành cho việc chặn prompt jailbreak trong chatbot OpenAI. Nó không liên quan đến bảo vệ nội dung generative, nên không phù hợp.

• ✅ [ĐÚNG] Jailbreak risk detection
  Như đã giải thích ở trên, đây là lựa chọn chính xác nhất. Tính năng này chuyên phát hiện rủi ro jailbreak bằng cách phân tích prompt theo các pattern như role-playing lừa đảo, encoding ẩn, hoặc multi-turn attacks. Kết quả trả về severity score (low/medium/high) để bạn cấu hình filter tự động block. Hoàn hảo cho kịch bản chatbot sử dụng Azure OpenAI.

• ❌ [SAI] Moderate text content
  Tính năng Moderate text content dùng để kiểm duyệt nội dung văn bản tổng quát (hate, violence, sexual, self-harm), phân loại harm categories với severity. Tuy nhiên, nó không chuyên biệt cho jailbreak (chỉ phát hiện nội dung hại sau khi generate, không block intent circumvent safety từ đầu). Không đáp ứng yêu cầu chặn "questions intended to circumvent".

• ❌ [SAI] Protected material text detection
  Protected material text detection tập trung phát hiện nội dung bị bảo vệ bản quyền (như sách, code, tài liệu proprietary) hoặc watermark từ các mô hình khác (e.g., GPT). Nó không xử lý jailbreak, mà chỉ kiểm tra ownership/IP infringement sau khi nội dung được tạo. Không phù hợp với việc block prompt vượt qua safety features.

🔍 Kết luận và khuyến nghị triển khai:
Để triển khai Jailbreak risk detection, bạn có thể tích hợp qua Azure AI Studio hoặc API với code mẫu Python/REST. Ví dụ: Gọi endpoint /text/moderate với category="JailbreakRisk". Kiểm tra thêm các best practices trong Azure OpenAI để kết hợp multi-layer safety (prompt engineering + content filter). Nếu cần hỗ trợ code, hãy cung cấp thêm chi tiết! 🚀
📘 Nguồn bổ sung: Azure AI Content Safety Overview (2026).

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào nguyên tắc Responsible AI (AI có trách nhiệm) trong phát triển hệ thống AI, cụ thể là một hệ thống bán hàng mới xử lý video và văn bản từ website công khai.
📝 Tình huống: Bạn đang xây dựng hệ thống sales system này, và kế hoạch thông báo cho người dùng rằng dữ liệu của họ đã được xử lý bởi hệ thống.
❓ Mục tiêu: Xác định nguyên tắc Responsible AI nào được hỗ trợ bởi hành động "notify users" (thông báo người dùng).
🛠️ Bối cảnh AWS: Theo hướng dẫn Responsible AI mới nhất của AWS (cập nhật đến năm 2026 qua AWS Well-Architected Framework for Generative AI và Responsible AI guidelines), các nguyên tắc chính bao gồm Transparency, Fairness, Inclusiveness, Reliability & Safety, Privacy & Security. Hành động thông báo giúp người dùng hiểu rõ AI đang làm gì với dữ liệu của họ.

✅ Đáp án đúng: transparency

Lý do lựa chọn:
Hành động thông báo cho người dùng rằng dữ liệu đã được xử lý bởi hệ thống AI trực tiếp hỗ trợ nguyên tắc transparency (tính minh bạch). Theo AWS, transparency yêu cầu người dùng phải được thông tin rõ ràng về việc AI được sử dụng, dữ liệu nào được xử lý và kết quả ra sao. Điều này giúp xây dựng lòng tin, tránh "black box" AI.
📘 Nguồn tham khảo: AWS Responsible AI - Transparency Principle (cập nhật 2025); AWS Well-Architected Generative AI Lens (v2.0, 2026).

🔍 Giải thích tất cả các phương án (đúng/sai)

• ✅ transparency
  Đúng vì: Như đã giải thích, thông báo dữ liệu được xử lý là biểu hiện trực tiếp của transparency, giúp người dùng biết AI đang hoạt động thế nào. 🛡️️

• ❌ fairness
  Sai vì: Fairness (công bằng) tập trung vào việc tránh thiên kiến (bias) trong mô hình AI, đảm bảo kết quả không phân biệt đối xử dựa trên giới tính, chủng tộc, v.v. Hành động thông báo không liên quan đến việc giảm bias. 🧊

• ❌ inclusiveness
  Sai vì: Inclusiveness (tính bao quát) nhấn mạnh AI phải dễ tiếp cận cho mọi người, bao gồm người khuyết tật, đa dạng văn hóa, và hỗ trợ đa ngôn ngữ. Thông báo dữ liệu không cải thiện tính bao quát này. 🌍

• ❌ reliability and safety
  Sai vì: Reliability and Safety (độ tin cậy và an toàn) yêu cầu AI hoạt động ổn định, chính xác, tránh lỗi hại người dùng (như hallucination trong GenAI). Thông báo chỉ là về nhận thức, không đảm bảo độ tin cậy kỹ thuật. ⚠️

Tóm tắt nhanh: 🏆 Transparency là chìa khóa ở đây vì nó ưu tiên giao tiếp rõ ràng với người dùng – một phần cốt lõi của Responsible AI trên AWS! Nếu cần thêm ví dụ thực tế, hãy hỏi nhé. 🚀