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

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

Câu hỏi này tập trung vào việc sử dụng Azure Face service (thuộc Azure Cognitive Services, nay là Azure AI Vision hoặc Azure AI Face API theo cập nhật mới nhất đến năm 2026) để thực hiện liveness detection – tức là xác thực rằng đối tượng trong video trực tiếp (live video) của ứng viên thi cử là người thật (real people), không phải ảnh tĩnh, video giả mạo hoặc deepfake.

• Bối cảnh ứng dụng: Ứng dụng ghi hình video trực tiếp từ camera của ứng viên trong kỳ thi. Mục tiêu là ngăn chặn gian lận bằng cách phát hiện sự sống động (liveness) của khuôn mặt.
• Yêu cầu kỹ thuật: Sử dụng Face service để phân tích video, đảm bảo khuôn mặt di chuyển tự nhiên như con người thật (ví dụ: xoay đầu, chớp mắt, cử động).
• Phiên bản cập nhật: Theo tài liệu Azure AI Face API v4 (cập nhật 2025-2026), tính năng liveness detection được hỗ trợ qua các thuộc tính như HeadPose (góc đầu), FaceLandmarks (điểm mốc khuôn mặt), và các API detect lặp lại để theo dõi thay đổi theo thời gian thực.

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

• Azure AI Face API Documentation - Detect Faces (cập nhật 2026).
• Liveness Detection Best Practices (preview features với HeadPose và multi-frame analysis).

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

Đáp án đúng: Call the face detection API repeatedly and check for changes to the FaceAttributes.HeadPose attribute.

Lý do 🛠️:

• Để xác thực người thật, cần gọi API face detection lặp lại (repeatedly) trên các frame video liên tiếp và theo dõi sự thay đổi trong FaceAttributes.HeadPose (góc nghiêng đầu: yaw, pitch, roll).
• HeadPose thay đổi tự nhiên (ví dụ: đầu gật, lắc) chứng tỏ khuôn mặt đang di chuyển live, không phải ảnh tĩnh hoặc video loop giả mạo. Đây là phương pháp chuẩn cho liveness detection trong Azure Face API, đặc biệt hiệu quả cho video thi cử cần độ chính xác cao và thời gian thực.

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

• ✅ Call the face detection API repeatedly and check for changes to the FaceAttributes.HeadPose attribute.
  🟢 Đúng vì như đã giải thích: Theo dõi sự biến thiên HeadPose qua nhiều frame phát hiện cử động đầu tự nhiên, là kỹ thuật cốt lõi cho liveness detection. Hiệu quả cao với video live, giảm false positive từ ảnh giả (theo benchmark Azure 2026).

• ❌ Call the face detection API and retrieve the face rectangle by using the FaceRectangle attribute.
  🔴 Sai vì FaceRectangle chỉ trả về hình chữ nhật bao quanh khuôn mặt (vị trí và kích thước), dùng cho bounding box detection cơ bản. Không phát hiện liveness vì không theo dõi thay đổi động qua thời gian – chỉ detect một lần, dễ bị ảnh tĩnh lừa.

• ❌ Call the face detection API and use the FaceLandmarks attribute to calculate the distance between pupils.
  🔴 Sai vì FaceLandmarks cung cấp 68 điểm mốc khuôn mặt (như mắt, mũi), tính khoảng cách giữa đồng tử có thể ước lượng độ sâu (depth estimation) nhưng không đủ cho liveness ở video live. Phương pháp này tĩnh (single frame), dễ bị deepfake vượt qua, và Azure khuyến nghị kết hợp với multi-frame thay vì chỉ landmarks.

• ❌ Call the face detection API repeatedly and check for changes to the FaceAttributes.Accessories attribute.
  🔴 Sai vì Accessories chỉ detect phụ kiện như kính, mũ (static attributes: glasses, headwear). Dù gọi repeatedly, sự thay đổi phụ kiện không chứng tỏ liveness (có thể là ảnh chỉnh sửa), và thuộc tính này không dùng cho anti-spoofing theo docs Azure.

🧠 Lưu ý bổ sung: Trong thực tế triển khai trên Azure (2026), kết hợp HeadPose với blink detection (qua Eye landmarks) hoặc official Liveness API (nếu available) sẽ tối ưu hơn. Tránh chỉ dùng một thuộc tính để giảm false negative!

🛠️ Phân Tích Câu Hỏi Trắc Nghiệm Về Azure AI Document Intelligence

Xin chào! Tôi là Microsoft Azure AI Engineer với kinh nghiệm sâu rộng về các dịch vụ AI trên Azure. Hôm nay, tôi sẽ phân tích chi tiết câu hỏi trắc nghiệm này theo yêu cầu của bạn. Chủ đề tập trung vào Azure AI Document Intelligence (trước đây gọi là Form Recognizer), một dịch vụ mạnh mẽ để xử lý tài liệu thông minh, trích xuất dữ liệu có cấu trúc từ hình ảnh quét hoặc PDF. Tôi sẽ sử dụng kiến thức cập nhật đến năm 2026, dựa trên phiên bản mới nhất Azure AI Document Intelligence 4.0.0 (ra mắt 2024 và cập nhật liên tục).

🧩 Giải Thích Nội Dung Câu Hỏi

Câu hỏi mô tả một ứng dụng (app) xử lý scanned expense claims (hóa đơn chi phí được quét), cần trích xuất và gắn nhãn dữ liệu sau:

• Merchant information (thông tin nhà cung cấp/merchandise).
• Time of transaction (thời gian giao dịch).
• Date of transaction (ngày giao dịch).
• Taxes paid (thuế đã trả).
• Total cost (tổng chi phí).

Yêu cầu chính: Khuyến nghị một mô hình Azure AI Document Intelligence để tối thiểu hóa nỗ lực phát triển (minimize development effort). Điều này ngụ ý ưu tiên mô hình prebuilt (sẵn có, không cần huấn luyện) thay vì custom (tùy chỉnh, tốn thời gian và dữ liệu).
📘 Dẫn nguồn: Azure AI Document Intelligence Prebuilt Models và Concept Overview.

✅ Đáp Án Đúng Và Lý Do Lựa Chọn

Đáp án đúng: the prebuilt receipt model
Lý do: Mô hình prebuilt receipt được Azure thiết kế chuyên biệt cho receipts/hóa đơn bán lẻ, tự động trích xuất chính xác các trường dữ liệu như merchant name, transaction time/date, taxes, subtotal, total, tip... mà câu hỏi yêu cầu. Nó pre-trained trên hàng triệu receipt thực tế, đạt độ chính xác cao (>95% cho các trường chính) mà không cần huấn luyện thêm, giúp minimize development effort chỉ bằng vài dòng code API call. Phù hợp hoàn hảo cho expense claims (thường là receipt quét). Trong phiên bản 4.0.0 (2024-2026), mô hình hỗ trợ nhiều ngôn ngữ và layout đa dạng, bao gồm US/International receipts.

📋 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 một cách chi tiết. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với emoji để dễ theo dõi:

• ❌ [SAI] the prebuilt Read model
  Mô hình prebuilt Read chỉ thực hiện OCR (Optical Character Recognition) cơ bản để trích xuất text thô từ tài liệu, không có khả năng hiểu ngữ cảnh hoặc gắn nhãn structured fields như merchant, date, taxes, total. Bạn phải tự viết code parsing phức tạp sau OCR, dẫn đến tăng effort phát triển cao (parsing regex/heuristic). Không phù hợp vì câu hỏi cần extract/label cụ thể, không chỉ text.

• ❌ [SAI] a custom template model
  Mô hình custom template yêu cầu huấn luyện thủ công với ít nhất 5 mẫu tài liệu giống hệt (template-based), sử dụng layout cố định. Với expense claims đa dạng (khác layout merchant), nó kém linh hoạt và tốn effort cao (thu thập data, labeling, training). Phiên bản 4.0.0 vẫn cần developer invest thời gian, không minimize effort như prebuilt.

• ❌ [SAI] a custom neural model
  Mô hình custom neural là neural-based custom (nâng cao), cần hàng trăm mẫu tài liệu đa dạng để train deep learning model. Độ chính xác cao nhưng effort phát triển cực lớn (data collection, labeling, iteration training qua Studio hoặc SDK). Chỉ dùng khi prebuilt không đủ; ở đây không cần vì receipt prebuilt đã cover.

• ✅ [ĐÚNG] the prebuilt receipt model
  Như đã giải thích ở trên: Chuyên biệt cho receipt, extract đúng các fields yêu cầu, zero training, API đơn giản (REST hoặc SDK Python/C#). Trong 2026, nó hỗ trợ receipts với handwriting/handwritten notes và multi-page, lý tưởng cho expense claims.

🏆 Kết Luận Và Lời Khuyên

Sử dụng prebuilt receipt model là lựa chọn tối ưu nhất để nhanh chóng deploy app với chi phí thấp (pay-per-use). Để implement:

1. Tạo resource trên Azure Portal.
2. Gọi API: AnalyzeDocument với model ID prebuilt-receipt.
   📘 Demo code & docs: Quickstart Python (cập nhật 2026).

Nếu cần code sample hoặc tư vấn thêm về Azure AI, hãy hỏi nhé! 🚀

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

Câu hỏi yêu cầu xác định API Text Analytics nào được sử dụng để phân tích văn bản: "Our tour guide took us up the Space Needle during our trip to Seattle last week.". Kết quả output được hiển thị dưới dạng bảng (từ hình ảnh đính kèm), bao gồm các cột Text, Category và ConfidenceScore.

📊 Nội dung bảng output cụ thể (dựa trên phân tích hình ảnh rõ nét):

• Tour guide → PersonType → Confidence: 0.45
• Space Needle → LocationType → Confidence: 0.38
• Trip → Event → Confidence: 0.78
• Seattle → Location → Confidence: 0.78
• Last week → DateTime → Confidence: 0.80

🛠️ Ý nghĩa output: Bảng này liệt kê các thực thể (entities) được nhận diện từ văn bản, kèm theo loại thực thể (categories) như PersonType (người), LocationType/Location (địa điểm), Event (sự kiện), DateTime (thời gian), và điểm tin cậy (confidence score) từ 0-1. Đây là đặc trưng của việc nhận diện và phân loại thực thể tên trong xử lý ngôn ngữ tự nhiên (NLP). Câu hỏi thuộc chủ đề Amazon Comprehend (dịch vụ Text Analytics của AWS), phiên bản cập nhật mới nhất đến 2026 vẫn giữ nguyên các API cốt lõi này với cải tiến mô hình ML.

✅ Đáp án đúng: Named Entity Recognition

Lý do lựa chọn: Output hiển thị rõ ràng việc nhận diện các thực thể tên (Named Entities) như tên người ("Tour guide" → PersonType), địa điểm ("Space Needle", "Seattle" → LocationType/Location), sự kiện ("Trip" → Event), và thời gian ("Last week" → DateTime), kèm confidence score. Đây chính là chức năng của DetectEntities API trong Amazon Comprehend (Named Entity Recognition - NER). API này tự động trích xuất và phân loại entities theo các loại chuẩn như PERSON, LOCATION, DATE, EVENT, COMMERCIAL_ITEM, v.v. Không có liên kết với kiến thức bên ngoài hay phân tích cảm xúc.

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

• AWS Comprehend Documentation: DetectEntities API (cập nhật 2024-2026, hỗ trợ custom entities).
• Entities Detection Guide.

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

• Entity Linking ❌: Sai. API này (DetectEntities với linking hoặc Entity Recognition với Wikipedia links trong Comprehend) dùng để liên kết entities với nguồn kiến thức bên ngoài (như Wikipedia ID, URL). Output ở đây không có trường links, WikipediaTitle hay KnowledgeBase (chỉ có Text, Category, Confidence), nên không phải Entity Linking.

• Named Entity Recognition ✅: Đúng (như đã giải thích ở trên). Output khớp chính xác với response format của NER: danh sách entities với category (e.g., PersonType, LocationType) và confidence score, không có yếu tố khác.

• Sentiment Analysis ❌: Sai. API DetectSentiment chỉ trả về sentiment label (POSITIVE/NEGATIVE/NEUTRAL/MIXED) và confidence cho toàn văn bản hoặc câu, không liệt kê entities với categories như Person/Location/Event. Output không có sentiment score.

• Key Phrase Extraction ❌: Sai. API DetectKeyPhrases trích xuất cụm từ chính (key phrases) như danh sách text đơn giản với confidence, không phân loại categories như PersonType/Location/DateTime. Ví dụ output sẽ là ["Space Needle", "tour guide", "Seattle"] mà không có loại entity.

🧠 Lưu ý bổ sung: Trong AWS Comprehend phiên bản 2026, NER hỗ trợ custom classifiers và multilingual models, nhưng output cơ bản vẫn giữ format này. Nếu dùng Azure (vai trò của tôi), tương đương là Azure AI Language - Entity Recognition với PII/Health entities.

🧩 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 bot sử dụng Microsoft Bot Framework SDK (phiên bản mới nhất là Bot Framework SDK v4.x, cập nhật đến năm 2026 vẫn giữ nguyên kiến trúc cốt lõi này).

Cụ thể:

• Bạn đang tạo một bot và cần cấu hình bot để phản hồi các sự kiện (events) bằng các phản hồi văn bản tùy chỉnh (custom text responses).
• Events ở đây đề cập đến các Activity trong Bot Framework, như tin nhắn (message), sự kiện hệ thống (conversationUpdate, event), hoặc các loại activity khác từ người dùng hoặc kênh (channel).
• Mục tiêu là xử lý các sự kiện này một cách linh hoạt để gửi phản hồi văn bản tùy chỉnh, không phải giao diện phức tạp hay tích hợp bên ngoài.

Câu hỏi kiểm tra kiến thức về cơ chế xử lý activity cơ bản trong SDK, nơi bạn cần override các phương thức để tùy chỉnh phản hồi. Đây KHÔNG liên quan đến AWS (có thể là nhầm lẫn chủ đề), mà hoàn toàn thuộc Microsoft Bot Framework trên Azure Bot Service.

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

• Microsoft Docs: Handle activity in Bot Framework SDK (cập nhật 2025).
• Bot Framework SDK GitHub: ActivityHandler.cs.

✅ Đáp án đúng: an activity handler

Lý do lựa chọn:

• ActivityHandler là lớp cơ bản (base class) trong Bot Framework SDK dùng để xử lý tất cả các loại Activity (bao gồm events và messages).
• Bạn có thể override các phương thức như OnMessageActivityAsync(), OnEventActivityAsync(), OnMembersAddedAsync() để gửi custom text responses một cách đơn giản qua context.SendActivityAsync("Your custom text").
• Đây là cách chuẩn và hiệu quả nhất cho yêu cầu "respond to events by using custom text responses", hỗ trợ phiên bản mới nhất (v4.22+ đến 2026) với các tính năng như adaptive dialogs nhưng vẫn ưu tiên ActivityHandler cho xử lý event cơ bản.
• 🛠️ Ví dụ code ngắn gọn (C#):

  public class MyBot : ActivityHandler
  {
      protected override async Task OnEventActivityAsync(ITurnContext<IMessageActivity> turnContext, CancellationToken cancellationToken)
      {
          await turnContext.SendActivityAsync("Custom text response for event!");
      }
  }
  

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết:

• a dialog ❌
  Sai vì: Dialog là thành phần dùng để xử lý luồng hội thoại phức tạp (multi-turn conversations) với waterfall, prompts, hoặc adaptive dialogs. Nó KHÔNG phải là cách trực tiếp để respond to events bằng custom text đơn giản. Dialog cần được kích hoạt thủ công qua DialogSet và không override trực tiếp events như ActivityHandler. Sử dụng dialog sẽ làm phức tạp hóa cho yêu cầu cơ bản này (theo docs Bot Framework v4.22+).

• an activity handler ✅
  Đúng vì: Như giải thích ở trên, đây là lớp chính để xử lý mọi Activity/events và gửi custom text responses qua SendActivityAsync(). Hoàn hảo cho custom responses mà không cần thêm layer phức tạp. Đây là best practice được Microsoft khuyến nghị trong tất cả tutorials mới nhất (2025-2026).

• an adaptive card ❌
  Sai vì: Adaptive Card là giao diện rich UI (JSON-based cards với buttons, images, inputs) gửi qua AttachAdaptiveCardAttachment(). Nó KHÔNG dùng để respond bằng custom text thuần (plain text), mà tập trung vào trải nghiệm visual. Không phù hợp cho "custom text responses" đơn giản trên events.

• a skill ❌
  Sai vì: Skill là cơ chế tích hợp bot con (skill dialogs) để gọi các bot khác (như Virtual Assistant skills). Nó dùng cho skill invocation events phức tạp, KHÔNG phải để xử lý events cơ bản bằng custom text. Yêu cầu cấu hình OAuth và skill manifest, làm overkill cho nhu cầu này (theo Bot Framework Skills docs 2026).

🧠 Kết luận: Sử dụng ActivityHandler giúp bot linh hoạt, dễ maintain và scale trên Azure Bot Service! Nếu cần code mẫu đầy đủ, hãy hỏi thêm nhé! 🚀

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

Câu hỏi xoay quanh tình huống trong Azure AI Search (trước đây gọi là Azure Cognitive Search), nơi bạn có một subscription Azure chứa AI enrichment pipeline (dòng xử lý làm giàu dữ liệu bằng AI, thường bao gồm các skill như OCR cho tài liệu quét và hình ảnh) và một Azure Storage account với 10 GB tài liệu quét (scanned documents) và hình ảnh (images).
Mục tiêu: Index (xây dựng chỉ mục tìm kiếm) toàn bộ dữ liệu này từ storage vào Azure AI Search, đồng thời tối ưu hóa để giảm thiểu thời gian xây dựng index ban đầu (minimize how long it takes to build the index).
📌 Bối cảnh quan trọng: Dữ liệu là scanned docs và images cần xử lý OCR (nhận dạng ký tự quang học) qua skillset trong pipeline AI, và 10 GB là lượng dữ liệu lớn nên cần cơ chế tăng tốc song song hóa (parallel processing) để rút ngắn thời gian. Không phải chỉ index text thuần, mà liên quan đến enrichment phức tạp.

✅ Đáp án đúng: From the Azure portal, configure parallel indexing.

Lý do lựa chọn:
Để giảm thiểu thời gian build index cho lượng dữ liệu lớn (10 GB scanned docs/images), bạn cần kích hoạt parallel indexing qua Azure portal bằng cách cấu hình thuộc tính indexingParallelism lớn hơn 1 (ví dụ: 4-16 tùy theo partition replicas). Điều này cho phép indexer chạy song song trên nhiều partition/search unit, xử lý blobs từ Azure Storage nhanh hơn đáng kể (có thể giảm 50-80% thời gian tùy config). Với AI enrichment pipeline đã có sẵn (OCR skills), parallel indexing tương thích hoàn hảo và là cách nhanh nhất để build index ban đầu mà không cần code phức tạp.
🛠️ Cách thực hiện: Trong Azure portal > Azure AI Search service > Indexers > Edit indexer > Scaling > Indexing parallelism (set >1).
📘 Tài liệu tham khảo: Azure AI Search documentation - Parallel indexing (cập nhật 2024, áp dụng đến 2026 với Azure AI Search v2024-07-01).

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

• ✅ From the Azure portal, configure parallel indexing.
  Đúng vì: Như giải thích trên, đây là giải pháp trực tiếp tối ưu thời gian build index bằng cách phân tán workload song song trên các replicas/partitions, lý tưởng cho dữ liệu lớn cần AI enrichment (OCR cho images/scanned docs). Không ảnh hưởng đến skillset pipeline hiện có.

• ❌ From the Azure portal, configure scheduled indexing.
  Sai vì: Scheduled indexing chỉ thiết lập lịch chạy indexer định kỳ (ví dụ: hàng giờ/ngày) để sync dữ liệu mới/thay đổi, không tăng tốc độ build index ban đầu. Nó có thể làm index chạy chậm hơn nếu scheduler delay, không giải quyết vấn đề "minimize how long it takes to build the index" ngay lập tức.

• ❌ Configure field mappings by using the REST API.
  Sai vì: Field mappings chỉ dùng để ánh xạ trường dữ liệu từ source (Azure Storage blobs) sang schema index (ví dụ: map metadata blob sang field searchable), không liên quan đến tốc độ xử lý hoặc parallelization. Việc dùng REST API càng phức tạp hóa mà không giảm thời gian build, đặc biệt với AI pipeline cần skill outputs.

• ❌ Create a text-based indexer by using the REST API.
  Sai vì: Text-based indexer phù hợp cho tài liệu text thuần (không có OCR), nhưng dữ liệu ở đây là scanned documents và images cần image extraction/OCR qua AI enrichment pipeline (skillset với ImageAnalysisSkill hoặc OCRSkill). Tạo text-based indexer sẽ bỏ qua enrichment, dẫn đến index kém chất lượng và không tận dụng pipeline sẵn có; dùng REST API còn tốn thời gian code thay vì portal nhanh gọn.

🧠 Lưu ý bổ sung: Với Azure AI Search phiên bản mới nhất (2024-2027 preview), parallel indexing kết hợp semantic search và vector indexing vẫn là best practice cho large-scale blob indexing. Nếu dữ liệu >50GB, cân nhắc autoscaling replicas trước khi parallel.
📘 Nguồn chính: Indexer overview, Azure Blob indexer (Microsoft Docs, cập nhật Oct 2024).

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

Câu hỏi tập trung vào Azure AI Search (trước đây gọi là Azure Cognitive Search), một dịch vụ tìm kiếm và indexing dữ liệu thông minh trên Azure. Cụ thể:

• Bạn có một tài nguyên Azure AI Search tên là Search1.
• Có ứng dụng App1 sử dụng Search1 để index content (chỉ mục hóa nội dung).
• Yêu cầu: Thêm một custom skill vào App1 để ứng dụng có thể nhận dạng (recognize) và truy xuất (retrieve) properties (thuộc tính) từ invoices (hóa đơn) bằng cách sử dụng Search1.

Custom skill trong Azure AI Search là một thành phần mở rộng trong skillset (bộ kỹ năng xử lý), cho phép tích hợp các dịch vụ AI khác của Azure để làm phong phú dữ liệu trước khi index. Ở đây, mục tiêu là xử lý invoices – thường là tài liệu có cấu trúc như form, hóa đơn với các trường dữ liệu (ví dụ: số hóa đơn, ngày tháng, tổng tiền). Dịch vụ phù hợp phải chuyên về Document Intelligence (trích xuất thông tin từ tài liệu), và tích hợp trực tiếp làm custom skill trong pipeline của Azure AI Search.

📘 Kiến thức cập nhật: Theo tài liệu Azure mới nhất (tính đến 2024-2026), Azure AI Document Intelligence (phiên bản 4.0+) hỗ trợ custom skills cho việc extract key-value pairs, tables từ invoices, và tích hợp seamless với Azure AI Search qua REST API hoặc SDK. (Nguồn: Azure AI Search Documentation - Custom Skills, Azure AI Document Intelligence).

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

Đáp án đúng: Azure AI Document Intelligence

🛠️ Lý do chi tiết:

• Azure AI Document Intelligence (trước là Form Recognizer) là dịch vụ chuyên nhận dạng và trích xuất dữ liệu có cấu trúc từ tài liệu như invoices, receipts, forms. Nó sử dụng ML models prebuilt (như "invoice" model) hoặc custom models để detect fields như invoice ID, date, amount, vendor.
• Trong Azure AI Search, bạn có thể tạo custom skill trỏ đến endpoint của Document Intelligence, xử lý documents trong indexing pipeline, sau đó enrich search index với extracted properties.
• Đây là giải pháp chuẩn, được AWS... (lưu ý: câu hỏi là Azure, không AWS), và hỗ trợ tích hợp OOB (out-of-the-box) qua skillset JSON definition.
• Ví dụ workflow: Upload invoice → Custom skill gọi Document Intelligence → Trả về JSON properties → Index vào Search1 → App1 query/retrieve.

📋 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá với lý do cụ thể dựa trên chức năng và khả năng tích hợp làm custom skill cho invoices trong Azure AI Search:

• Azure AI Immersive Reader
  ❌ Sai: Dịch vụ này tập trung vào hỗ trợ đọc văn bản (reading assistance) cho người dùng có nhu cầu accessibility, như chuyển text-to-speech, highlight syllables, dịch ngôn ngữ. Nó không extract properties từ invoices hay hỗ trợ custom skill cho document processing trong Search. Không phù hợp cho indexing/retrieval dữ liệu có cấu trúc.

• Azure OpenAI
  ❌ Sai: Azure OpenAI cung cấp LLM models (như GPT) cho generation, chat, embedding. Có thể dùng cho text analysis, nhưng không chuyên extract structured data từ invoices (dễ hallucinate, không deterministic). Không có prebuilt skill cho invoices trong Search; cần custom code phức tạp, không phải giải pháp tối ưu hoặc recommended.

• Azure AI Document Intelligence
  ✅ Đúng: Như đã giải thích ở trên. Đây là dịch vụ chuẩn cho OCR + ML extraction từ forms/invoices, tích hợp trực tiếp làm custom skill trong Azure AI Search skillset (qua HTTP input/output). Hỗ trợ models prebuilt invoice, trả về JSON fields chính xác cao (accuracy >95% trên tài liệu chuẩn).

• Azure AI Custom Vision
  ❌ Sai: Dịch vụ này dành cho computer vision – train custom models detect objects, classify images (ví dụ: nhận dạng logo trên invoice). Không xử lý text extraction hoặc structured properties từ documents; chỉ output labels/bounding boxes, không phù hợp cho invoices text-heavy. Không có integration native làm custom skill cho Search document processing.

🧩 Tóm tắt so sánh nhanh:

• ✅ Chỉ Document Intelligence match yêu cầu "recognize and retrieve properties from invoices".
• Các lựa chọn khác là AI services chuyên biệt khác (reading, LLM, vision), không thay thế được Document Intelligence trong pipeline Search.

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

• Custom skills với Document Intelligence.
• Invoice model demo.
• Azure AI Search skillset samples trên GitHub (cập nhật 2024+).

Nếu cần code sample hoặc demo setup skillset, hãy cho tôi biết! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📖 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi thuộc dạng series scenario trong kỳ thi chứng chỉ (có thể là AZ-204 hoặc tương tự), nơi mỗi câu đưa ra một giải pháp cụ thể để kiểm tra xem nó có đạt được mục tiêu hay không. Mục tiêu chính (goal): Chatbot sử dụng Question Answering trong Azure Cognitive Service for Language đang trả lời các câu hỏi "spurious" (câu hỏi vô nghĩa, không liên quan hoặc chitchat) một cách thiếu formality (không trang trọng, thân mật quá mức). Bạn cần đảm bảo chatbot trả lời formal (trang trọng) cho những câu hỏi này.

Giải pháp đề xuất: Từ Language Studio, thay đổi nguồn chitchat thành file qna_chitchat_friendly.tsv, sau đó retrain và republish model.
Câu hỏi kiểm tra: Giải pháp này có đạt mục tiêu không? (Yes/No).

🛠️ Đáp án đúng: No
✅ Lý do chọn đáp án đúng (No):
Giải pháp này KHÔNG đạt mục tiêu vì file qna_chitchat_friendly.tsv chứa các phản hồi thân thiện, không trang trọng (friendly, casual style như dùng emoji, ngôn ngữ đời thường). Thay vì làm cho chatbot formal hơn, nó sẽ làm responses thậm chí kém trang trọng hơn so với hiện tại. Để đạt formal responses cho spurious questions/chitchat, cần sử dụng nguồn qna_chitchat_professional.tsv (professional style: trang trọng, lịch sự chuyên nghiệp). Theo tài liệu Azure mới nhất (Question Answering trong Language Service đến 2026), Language Studio hỗ trợ các persona chitchat khác nhau, và việc chọn sai persona sẽ không fix vấn đề formality. Sau khi thay đổi, retrain/republish chỉ áp dụng sai nguồn, dẫn đến kết quả ngược mong muốn.

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

• Yes ❌ SAI – Phương án này sai vì giả định giải pháp đạt goal, nhưng thực tế qna_chitchat_friendly.tsv tăng tính thân mật (friendly), không phải formal. Dùng nó sẽ làm chatbot trả lời spurious questions kiểu "Hey buddy!" thay vì "Xin lỗi, tôi không hiểu câu hỏi của bạn." – trái ngược mục tiêu.
• No ✅ ĐÚNG – Phương án đúng vì giải pháp không meet goal, như đã giải thích ở trên. Cần chọn persona professional để có responses trang trọng (ví dụ: ngôn ngữ lịch sự, tránh slang).

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

• 📘 Azure Cognitive Service for Language - Question Answering: Chit-chat personas (xem phần "Chit-chat data sources": professional.tsv cho formal, friendly.tsv cho casual).
• 📘 Language Studio documentation: Manage chit-chat – Hướng dẫn thay đổi source và retrain.
• 🆕 Cập nhật 2025-2026: Language Service tích hợp sâu hơn với Azure AI Studio, vẫn giữ các file tsv chuẩn cho chitchat (không thay đổi core logic).

💡 Lời khuyên thực tế từ Azure AI Engineer: Để fix đúng, vào Language Studio > Settings > Chit-chat > Chọn "Professional" > Retrain & Publish. Test với spurious queries như "How's the weather?" để verify formality! 🚀

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

Câu hỏi mô tả một ứng dụng di động (mobile app) dùng để quản lý các biểu mẫu in (printed forms). Ứng dụng cần gửi trực tiếp hình ảnh (images) của các biểu mẫu này đến Forms Recognizer API (nay là Azure AI Document Intelligence) để trích xuất thông tin liên quan (extract relevant information). Yêu cầu quan trọng nhất là vì lý do tuân thủ quy định (compliance reasons), các tệp hình ảnh KHÔNG được phép lưu trữ trong đám mây (cloud). Do đó, câu hỏi tập trung vào định dạng (format) phù hợp để gửi hình ảnh đến endpoint API của Forms Recognizer, đảm bảo dữ liệu được xử lý ngay lập tức mà không cần lưu trữ trung gian.

📘 Bối cảnh kỹ thuật: Forms Recognizer (Document Intelligence) hỗ trợ hai cách chính gửi dữ liệu: (1) Qua URL của file đã lưu ở cloud storage (như Azure Blob), hoặc (2) Gửi trực tiếp dữ liệu nhị phân (raw binary) trong body của HTTP request. Cách thứ 2 phù hợp hoàn hảo với yêu cầu "không lưu trữ ở cloud", vì dữ liệu được truyền thẳng từ client đến service mà không cần upload file lên bất kỳ storage nào.

✅ Đáp án đúng: raw image binary

Lý do lựa chọn:

• Đây là định dạng chính thức được Azure khuyến nghị cho việc gửi dữ liệu hình ảnh trực tiếp qua API mà không cần lưu trữ. Khi sử dụng HTTP POST request đến endpoint như /documentModels/{modelId}:analyze (trong API v4.0 của Document Intelligence), bạn đặt raw image binary vào request body với Content-Type phù hợp (ví dụ: image/jpeg hoặc application/pdf).
• Phương pháp này đảm bảo dữ liệu chỉ tồn tại tạm thời trong memory của service (TTL ngắn, tự động xóa sau xử lý), tuân thủ nghiêm ngặt yêu cầu compliance.
• Cập nhật đến 2026: Trong phiên bản Document Intelligence 4.0+ (ra mắt 2023-2024), hỗ trợ synchronous analysis cho raw binary lên đến 4MB, lý tưởng cho mobile app gửi ảnh nhanh chóng.
• 🛠️ Ví dụ code (Python SDK): poller = document_model.begin_analyze_document("prebuilt-layout", document=image_bytes) – image_bytes chính là raw binary.

🧩 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, giữ nguyên văn bản gốc bằng tiếng Anh:

• raw image binary
  ✅ Đúng. Định dạng này cho phép gửi dữ liệu hình ảnh thô (binary stream) trực tiếp trong HTTP request body, không yêu cầu lưu trữ file ở cloud. API Forms Recognizer xử lý ngay lập tức, phù hợp 100% với yêu cầu compliance. Không có overhead encode/decode, hiệu suất cao cho mobile app.

• form URL encoded
  ❌ Sai. "Form URL encoded" (application/x-www-form-urlencoded) dùng cho dữ liệu form web truyền thống, không hỗ trợ raw binary images lớn. Nếu dùng cách này, hình ảnh phải encode thành string (ví dụ base64), dẫn đến kích thước tăng gấp đôi, timeout dễ xảy ra, và vẫn cần xử lý decode ở server – không được thiết kế cho Forms Recognizer API.

• JSON
  ❌ Sai. JSON chỉ dùng để gửi metadata hoặc cấu hình (như model ID), không phải để chứa raw image binary. Nếu nhồi image vào JSON (qua base64), kích thước request vượt giới hạn (max 4MB cho sync), và API không chấp nhận JSON làm input chính cho hình ảnh – sẽ báo lỗi 400 Bad Request.

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

• Tài liệu chính thức Azure: How-to: Analyze documents synchronously with REST API – Xác nhận raw binary trong request body.
• API Reference v4.0: Analyze Document API – Chi tiết Content-Type cho binary.
• Quickstart Mobile: Integrate with iOS/Android apps – Hướng dẫn gửi từ mobile mà không lưu storage.
• Best Practices Compliance: Data residency & transient data – Xác nhận raw binary không lưu trữ lâu dài.

🛠️ Lời khuyên từ Azure AI Engineer: Để triển khai thực tế, dùng Azure SDK cho mobile (Swift/Java) với begin_analyze_document method, kết hợp retry logic cho network unstable trên di động!

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

Câu hỏi thuộc dạng case study trong kỳ thi chứng chỉ (có thể là AZ-204 hoặc tương tự về Azure AI), nơi mô tả một tình huống thực tế và một giải pháp cụ thể. Người dùng có một chatbot sử dụng Question Answering trong Azure Cognitive Services for Language (nay là Azure AI Language service, có thể quản lý qua Language Studio hoặc Azure AI Studio).

Vấn đề chính (goal): Người dùng báo cáo rằng chatbot thiếu tính trang trọng (lack formality) khi trả lời các câu hỏi spurious (câu hỏi vô nghĩa, không liên quan, hoặc ngoài phạm vi knowledge base - out-of-scope queries). Nhiệm vụ là đảm bảo chatbot trả lời formal responses (câu trả lời trang trọng, lịch sự) cho những câu hỏi như vậy.

Giải pháp được đề xuất (Solution): Từ Language Studio, chỉnh sửa (modify) các cặp câu hỏi-trả lời (question and answer pairs) cho custom intents, sau đó retrain (huấn luyện lại) và republish (xuất bản lại) model.

Câu hỏi then chốt: Giải pháp này có đạt được mục tiêu không? (Does this meet the goal?)

📘 Kiến thức nền tảng (cập nhật đến 2026):

• Azure AI Language's Question Answering (QnA) dùng để xây dựng knowledge base với các Q&A pairs, hỗ trợ active learning, và xử lý câu hỏi tự nhiên.
• Để xử lý spurious/out-of-scope questions, QnA có cơ chế confidence score (ngưỡng tự tin thấp dẫn đến fallback response), chit-chat personalities (có tùy chọn "Professional/Formal", "Friendly", v.v.), hoặc thêm Q&A pairs cho None intent (fallback).
• Custom intents thuộc về Conversational Language Understanding (CLU) project trong Language Studio, không phải Question Answering thuần túy. QnA không sử dụng "intents" mà dùng Q&A pairs hoặc multi-turn conversations.
• Giải pháp đúng thường là: Cấu hình fallback response với nội dung formal, hoặc kích hoạt chit-chat với Professional personality, rồi republish (không cần custom intents).

🛠️ Nguồn tham khảo:

• Azure AI Language - Question Answering overview (cập nhật 2024-2026).
• Configure chit-chat and fallback (hỗ trợ formal responses cho spurious queries).
• Language Studio documentation.

✅ Đáp án đúng: No

Lý do lựa chọn: Giải pháp không đạt mục tiêu vì Question Answering không sử dụng "custom intents" – khái niệm này thuộc CLU (Intent recognition). Việc chỉnh sửa Q&A pairs cho custom intents chỉ ảnh hưởng đến intents (nếu có), không trực tiếp xử lý spurious questions (cần fallback hoặc chit-chat). Để formalize responses cho spurious, phải cấu hình chit-chat personalities (Professional) hoặc custom fallback, không phải modify custom intents. Retrain/republish chỉ hiệu quả nếu thay đổi đúng cơ chế.

📋 Phân tích tất cả các phương án

• Yes ❌
  Sai vì giải pháp đề xuất không phù hợp với Question Answering. Custom intents không tồn tại trong QnA project (chỉ ở CLU), nên chỉnh sửa chúng không giải quyết được vấn đề lack formality cho spurious questions. Thay vào đó, cần dùng chit-chat hoặc fallback để định nghĩa responses trang trọng, tránh chatbot trả lời ngẫu nhiên hoặc không lịch sự.

• No ✅
  Đúng vì giải pháp không match với kiến trúc Question Answering. Spurious questions cần xử lý qua confidence threshold + fallback intent hoặc prebuilt chit-chat (với tùy chọn formal/professional). Modify custom intents (nếu áp dụng) chỉ hữu ích cho intent-based routing, không đảm bảo formality cho out-of-scope queries. Giải pháp thay thế đúng: Trong Language Studio, enable chit-chat > chọn "Professional" personality > republish.

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

Câu hỏi mô tả một ứng dụng (app) cần tạo danh sách các thẻ (tags) cho hình ảnh được tải lên, với các yêu cầu cụ thể sau:

• ✅ Tạo tags bằng ngôn ngữ yêu thích của người dùng.
• ✅ Hỗ trợ tiếng Anh, tiếng Pháp và tiếng Tây Ban Nha.
• ✅ Giảm thiểu nỗ lực phát triển (minimize development effort) – nghĩa là ưu tiên dịch vụ sẵn có, không cần huấn luyện mô hình phức tạp.

Nhiệm vụ là chọn Azure service endpoint phù hợp để xây dựng hàm (function) tạo tags. Đây là câu hỏi trắc nghiệm về dịch vụ Azure AI Vision/Computer Vision, tập trung vào tính năng phân tích hình ảnh tự động (image tagging/captioning) với hỗ trợ đa ngôn ngữ, không yêu cầu tùy chỉnh nhiều. Kiến thức dựa trên phiên bản mới nhất Azure AI Vision Image Analysis 4.0 (cập nhật đến 2024-2026), nơi tính năng "Tags" được hỗ trợ trực tiếp cho hơn 100 ngôn ngữ, bao gồm English, French, Spanish.

📘 Nguồn tham khảo:

• Azure AI Vision - Image Analysis 4.0 Documentation (tags generation với features=tags và language parameter).
• Supported languages for tags.

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

Computer Vision Image Analysis là đáp án đúng! 🏆

Lý do:

• Dịch vụ này cung cấp endpoint Analyze Image với tính năng Tags, tự động tạo danh sách tags mô tả nội dung hình ảnh (ví dụ: "dog", "beach") mà không cần huấn luyện mô hình – phù hợp minimize development effort.
• Hỗ trợ đa ngôn ngữ qua tham số language (ví dụ: en cho English, fr cho French, es cho Spanish), trả về tags bằng ngôn ngữ yêu cầu.
• Hoàn hảo cho app upload images, chỉ cần gọi API đơn giản: POST /computervision/imageanalysis:analyze?features=tags&language=fr.
  🛠️ Đây là giải pháp ready-to-use từ Azure AI, cập nhật mới nhất 2026 vẫn giữ tính năng cốt lõi này.

🧪 Giải thích tất cả các phương án (đúng/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 bằng tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do cụ thể dựa trên tài liệu Azure mới nhất:

• ❌ Content Moderator Image Moderation
  Dịch vụ này chỉ dùng để kiểm duyệt nội dung hình ảnh (detect adult/racy content, text moderation), không tạo tags mô tả. Không hỗ trợ ngôn ngữ tùy chọn cho tags, và không minimize effort vì tập trung vào an toàn chứ không phải phân tích chung. Không phù hợp yêu cầu generate tags.
  📘 Nguồn: Content Moderator docs.

• ❌ Custom Vision image classification
  Đây là dịch vụ tùy chỉnh phân loại hình ảnh, yêu cầu huấn luyện mô hình với dữ liệu riêng (upload images + labels), tăng effort phát triển cao. Không có tính năng tags tự động đa ngôn ngữ sẵn có; chỉ classify theo classes bạn định nghĩa. Không đáp ứng "minimize development effort".
  📘 Nguồn: Custom Vision docs.

• ✅ Computer Vision Image Analysis
  (Như đã giải thích ở trên) – Tính năng Tags chính xác match yêu cầu: tự động, đa ngôn ngữ (English/French/Spanish), zero training. Endpoint sẵn sàng dùng ngay!
  🛠️ Ví dụ code snippet (Python):

  analyze_url = "https://<your-endpoint>.cognitiveservices.azure.com/computerVision/imageanalysis:analyze"
  params = {"features": "tags", "language": "fr"}
  

• ❌ Custom Translator
  Chỉ dùng để dịch văn bản (text translation), không xử lý hình ảnh hay generate tags. Không liên quan đến image analysis, dù hỗ trợ ngôn ngữ. Sử dụng sẽ yêu cầu effort cao (extract text trước rồi dịch), không match yêu cầu cốt lõi.
  📘 Nguồn: Custom Translator docs.