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 tập trung vào việc đo lường nhận thức công chúng (public perception) về thương hiệu trên mạng xã hội bằng cách sử dụng xử lý ngôn ngữ tự nhiên (Natural Language Processing - NLP).
📌 Yêu cầu chính: Phân tích văn bản từ mạng xã hội (như tweet, comment, post) để đánh giá cảm xúc, ý kiến tích cực/tiêu cực về thương hiệu. Đây là nhiệm vụ điển hình của phân tích cảm xúc (Sentiment Analysis), khai thác ý kiến (Opinion Mining) và các tính năng NLP khác.
🛠️ Bối cảnh Azure: Trong hệ sinh thái Azure AI (cập nhật đến năm 2026, theo phiên bản Azure AI Language mới nhất), dịch vụ cần hỗ trợ xử lý văn bản tự nhiên để trích xuất insights từ dữ liệu không cấu trúc như nội dung social media.

✅ Đáp án đúng: Language service

Lý do lựa chọn:
Azure AI Language service (trước đây gọi là Text Analytics) là dịch vụ chuyên biệt cho NLP, hỗ trợ Sentiment Analysis (phân tích cảm xúc), Opinion Mining (khai thác khía cạnh cụ thể như "giá cả" hay "chất lượng" của thương hiệu), và Key Phrase Extraction. Những tính năng này lý tưởng để đo lường perception trên social media bằng cách phân tích hàng loạt văn bản, trả về điểm số tích cực/trung lập/tiêu cực.
🎯 Ưu điểm nổi bật (2026): Hỗ trợ đa ngôn ngữ, tích hợp dễ dàng với Azure Synapse hoặc Power BI để visualize dữ liệu social media thời gian thực. Không dịch vụ nào khác phù hợp hơn cho pure NLP text-based perception.

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

• ✅ Language service
  🟢 Đúng vì: Như đã giải thích, đây là dịch vụ cốt lõi cho NLP trên văn bản, trực tiếp đo lường sentiment và opinion từ social media. Hoàn hảo cho brand perception monitoring.

• ❌ Content Moderator
  🔴 Sai vì: Dịch vụ này tập trung vào moderation nội dung (phát hiện nội dung độc hại, khiêu dâm, spam), không phải phân tích sentiment hay perception. Nó chỉ lọc nội dung xấu, không đo lường ý kiến công chúng về thương hiệu.

• ❌ Computer Vision
  🔴 Sai vì: Chuyên xử lý hình ảnh/video (như nhận diện đối tượng, OCR, phân tích cảm xúc khuôn mặt), không hỗ trợ NLP trên văn bản social media. Không liên quan đến text-based perception.

• ❌ Form Recognizer (nay là Document Analysis trong Azure AI)**
  🔴 Sai vì: Dành cho trích xuất dữ liệu từ form tài liệu có cấu trúc (hóa đơn, hợp đồng), không xử lý văn bản không cấu trúc từ social media hay sentiment analysis.

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

• Azure AI Language - Sentiment Analysis (Microsoft Docs).
• Azure AI Services Comparison – Xác nhận Language là lựa chọn cho NLP perception.
• Quickstart: Brand Sentiment Analysis – Ví dụ thực tế với social media data.

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

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

📘 Nội dung câu hỏi:
Câu hỏi xoay quanh việc huấn luyện một custom extraction model (mô hình trích xuất tùy chỉnh) bằng tài nguyên Azure AI Document Intelligence (trước đây gọi là Form Recognizer) có tên AIdoc1 ở tier S0 trong một subscription Azure. Bạn có các file được liệt kê trong bảng sau (dựa trên hình ảnh đính kèm):

Nhiệm vụ là xác định file nào có thể upload vào Document Intelligence Studio để huấn luyện mô hình. Các yêu cầu chính từ Azure AI Document Intelligence (phiên bản mới nhất v4.0+ đến 2026):

• Định dạng hỗ trợ: PDF, JPEG/JPG, PNG, BMP, TIFF (không hỗ trợ XLSX hoặc các định dạng khác cho training custom model).
• Kích thước file: Tối đa 500 MB/file ở tier S0 (áp dụng cho cả PDF và hình ảnh khi training).
• Bảo mật: Không được password-protected (file PDF có mật khẩu không hỗ trợ).
• Số lượng: Ít nhất 5 file sạch cho custom extraction model, nhưng câu hỏi chỉ hỏi về file có thể upload (không yêu cầu đủ số lượng).
  Hình ảnh bảng rõ ràng hiển thị các thuộc tính, giúp loại trừ dựa trên định dạng, kích thước và mật khẩu.

✅ Đáp án đúng: File1 and File2 only

Lý do lựa chọn (🛠️ Phân tích chi tiết):

• File1 (JPG, 400 MB, N/A): Định dạng hình ảnh hỗ trợ (JPEG), kích thước < 500 MB, không có vấn đề mật khẩu → Có thể upload.
• File2 (PDF, 250 MB, No): Định dạng PDF hỗ trợ, không mật khẩu, kích thước < 500 MB → Có thể upload.
  Các file khác bị loại do vi phạm quy tắc (xem giải thích dưới). Điều này phù hợp với docs Azure mới nhất (2026), nơi tier S0 giới hạn 500 MB/file cho custom training và chỉ chấp nhận PDF/images không khóa.

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

• Azure AI Document Intelligence - Custom model training requirements (cập nhật 2026: limits S0 tier, supported formats, no password).
• Pricing tiers and limits (500 MB max per doc ở S0).

❌ 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 giữ nguyên văn bản gốc bằng tiếng Anh, kèm lý do đúng/sai bằng tiếng Việt (dựa trên quy tắc Azure AI Document Intelligence Studio):

• File1, File2, and File4 only ❌
  Sai vì: File4 (XLSX, 900 MB) không được hỗ trợ định dạng (chỉ PDF/images), và kích thước vượt 500 MB. File1 & File2 OK, nhưng File4 loại trừ toàn bộ lựa chọn.

• File2, and File5 only ❌
  Sai vì: File5 (PDF, Yes password) bị khóa mật khẩu → Không hỗ trợ upload/training (Azure yêu cầu PDF "unprotected"). File2 OK, nhưng File5 loại.

• File2, File4, and File5 only ❌
  Sai vì: File4 (XLSX) không hỗ trợ định dạng; File5 có mật khẩu; chỉ File2 OK → Toàn bộ sai.

• File1, File2, File3, File4, and File5 ❌
  Sai vì: File3 (PNG, 600 MB) vượt kích thước 500 MB; File4 không hỗ trợ XLSX; File5 có mật khẩu → Chỉ File1 & File2 hợp lệ.

• File1 and File2 only ✅
  Đúng vì: Cả hai file thỏa mãn đầy đủ: định dạng hỗ trợ (JPG/PDF), <500 MB, không mật khẩu → Hoàn hảo cho upload vào Studio để train custom extraction model.

🧩 Kết luận: Chỉ File1 và File2 là lựa chọn an toàn, giúp tránh lỗi upload thất bại trong Document Intelligence Studio! 🚀

🧩 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 of questions" trong kỳ thi chứng chỉ (như AZ-204 hoặc tương tự), nơi mỗi câu đưa ra một giải pháp cụ thể cho tình huống đã mô tả trước đó. Tình huống: Bạn có một chatbot sử dụng tính năng Question Answering trong Azure Cognitive Service for Language (nay là Azure AI Language). Người dùng phàn nàn rằng phản hồi của chatbot thiếu tính trang trọng (lack formality) khi trả lời các câu hỏi không liên quan hoặc chit-chat (spurious questions), ví dụ như "Hello" hoặc "How are you?".
Mục tiêu (goal): Đảm bảo chatbot trả lời các câu hỏi spurious một cách chính thức, trang trọng (formal).
Giải pháp đề xuất (Solution): Từ Language Studio, thay đổi nguồn dữ liệu chit-chat sang file qna_chitchat_professional.tsv, sau đó retrain (huấn luyện lại) và republish (xuất bản lại) mô hình.
Câu hỏi: Giải pháp này có đạt được mục tiêu không? (Yes/No).

✅ Đáp án đúng: Yes
Lý do lựa chọn: Giải pháp này hoàn toàn phù hợp với mục tiêu vì Azure AI Language hỗ trợ các chit-chat personalities (cá tính chit-chat) qua các file TSV sẵn có. File qna_chitchat_professional.tsv chứa các phản hồi trang trọng, chuyên nghiệp dành riêng cho spurious questions (câu hỏi chit-chat). Việc thay đổi nguồn, retrain và republish sẽ cập nhật mô hình để sử dụng ngay các phản hồi formal này, giải quyết chính xác vấn đề "lack formality". Đây là cách chính thức được Microsoft khuyến nghị (cập nhật đến 2026, không thay đổi cơ bản trong Language Studio).

🛠️ Giải thích tất cả các phương án trả lời

• Yes ✅
  Đúng vì: Như đã giải thích, file qna_chitchat_professional.tsv là một trong các nguồn chit-chat chính thức của Azure (cùng với normal, friendly, caring, etc.). Nó cung cấp phản hồi formal/professional cho spurious questions, ví dụ: Thay vì "Hi there!" thân mật, nó sẽ dùng "Hello, how may I assist you today?". Sau khi thay đổi trong Language Studio > Knowledge base > Chit-chat tab, retrain và republish sẽ kích hoạt ngay. Điều này trực tiếp "meet the goal" mà không cần code thêm.

• No ❌
  Sai vì: Giải pháp được mô tả chính xác là cách chuẩn để xử lý chit-chat formality trong Azure AI Language. Chọn "No" sẽ nhầm lẫn, vì không có vấn đề kỹ thuật nào (như deprecated feature) ở phiên bản mới nhất (2026). Các giải pháp khác (như custom Q&A pairs hoặc fallback) không trực tiếp và hiệu quả bằng việc switch personality file.

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

• Azure AI Language - Add chit-chat to your QnA 🖥️ (Hướng dẫn chính thức về personalities, file TSV như professional.tsv).
• Language Studio Documentation 🧑‍💻 (Giao diện thực tế để thay đổi chit-chat source).
• Release notes Azure AI Services 2025-2026: Không thay đổi core chit-chat functionality, chỉ cải thiện accuracy với GPT integration nhưng TSV vẫn hỗ trợ đầy đủ.

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

📘 Nội dung câu hỏi:
Câu hỏi xoay quanh dịch vụ Azure AI Document Intelligence (trước đây gọi là Form Recognizer), một tài nguyên trong Azure subscription sử dụng Standard S0 pricing tier với tên DI1. Bạn có ba file sau (dựa trên bảng mô tả trong hình ảnh đính kèm):

• File1.pdf: Dung lượng 800 MB, chứa các hình ảnh quét (scanned images).
• File2.jpg: Dung lượng 1 KB, là hình ảnh có kích thước 25 x 25 pixels.
• File3.tiff: Dung lượng 5 MB, là hình ảnh có kích thước 5000 x 5000 pixels.

Câu hỏi yêu cầu xác định file nào có thể được phân tích (analyze) bằng DI1.
🛠️ Các giới hạn chính của Azure AI Document Intelligence (phiên bản mới nhất 4.0.0 đến 2026):

• Định dạng hỗ trợ: PDF, JPEG/JPG, PNG, BMP, TIFF.
• Giới hạn kích thước file: Tối đa 500 MB cho PDF và TIFF (áp dụng cho toàn bộ file, không chỉ per page).
• Giới hạn độ phân giải hình ảnh: Phải từ 50 x 50 pixels đến 10.000 x 10.000 pixels (inclusive).
• Tier S0: Không ảnh hưởng đến giới hạn kích thước/file format, chỉ liên quan đến giá và throughput (pay-per-use).
  Những file vượt giới hạn sẽ bị từ chối khi gọi API Analyze Document hoặc Layout/Read model.

✅ Đáp án đúng: File3.tiff only
Lý do lựa chọn:
File3.tiff thỏa mãn tất cả yêu cầu: định dạng TIFF được hỗ trợ, dung lượng 5 MB < 500 MB, độ phân giải 5000 x 5000 pixels nằm trong khoảng 50-10.000 pixels. Các file khác vi phạm giới hạn (chi tiết ở phần giải thích phương án).

🔍 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 giữ nguyên nội dung gốc bằng tiếng Anh, kèm giải thích sai/đúng bằng tiếng Việt:

• ❌ File1.pdf only
  Sai vì: File1.pdf có dung lượng 800 MB vượt quá giới hạn 500 MB cho PDF. Dù chứa scanned images và PDF được hỗ trợ, nhưng kích thước quá lớn nên không thể analyze toàn bộ file.

• ❌ File2.jpg only
  Sai vì: File2.jpg có độ phân giải 25 x 25 pixels nhỏ hơn giới hạn tối thiểu 50 x 50 pixels. Định dạng JPG hỗ trợ, dung lượng 1 KB OK, nhưng kích thước pixel không đạt yêu cầu.

• ✅ File3.tiff only
  Đúng vì: File3.tiff đầy đủ điều kiện: TIFF hỗ trợ, 5 MB < 500 MB, 5000 x 5000 pixels trong khoảng cho phép (50-10.000). Đây là lựa chọn chính xác duy nhất.

• ❌ File2.jpg and File3.tiff only
  Sai vì: File3.tiff OK, nhưng File2.jpg bị loại do độ phân giải quá nhỏ (25 x 25 < 50 x 50). Không thể analyze cả hai cùng lúc.

• ❌ File1.pdf, File2.jpg, and File3.tiff
  Sai vì: Chỉ File3.tiff OK; File1.pdf vượt dung lượng, File2.jpg vượt giới hạn pixel. Không thể analyze cả ba.

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

• Service limits: Azure AI Document Intelligence limits – Xác nhận 500 MB max cho PDF/TIFF, 50x50 đến 10k x 10k pixels.
• Supported formats & concepts: Overview Azure AI Document Intelligence.
• Pricing tiers: Pricing page – S0 tier không thay đổi limits.

💡 Lưu ý: Nếu file TIFF đa trang, mỗi trang vẫn phải tuân thủ limits pixel. Trong case này, mô tả là "an image" nên coi như single-page. Là Azure AI Engineer, tôi khuyên test qua Document Intelligence Studio trước khi integrate API! 🚀

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

Câu hỏi thuộc lĩnh vực Microsoft Bot Framework Composer (một công cụ low-code để xây dựng bots thông minh trên nền tảng Azure Bot Service). Nội dung yêu cầu: Bạn đã tạo 5 bots riêng biệt bằng Composer. Bây giờ, cần kết hợp chúng thành một bot duy nhất (single bot) để người dùng tiếp cận, đồng thời hỗ trợ dynamic routing – tức là tự động chuyển hướng (route) đến bot phù hợp dựa trên input từ người dùng (ví dụ: dựa trên intent nhận diện từ câu hỏi của user).

🔍 Yêu cầu cụ thể của giải pháp:

• Phải thực hiện 3 hành động (multi-select question, mỗi lựa chọn đúng đáng 1 điểm).
• Giải pháp phải hỗ trợ dynamic routing: Nghĩa là bot chính sẽ phân tích input, nhận diện intent từ nhiều bots con, rồi route đến bot đúng mà không cần hard-code.
• Phiên bản cập nhật mới nhất (tính đến 2026): Bot Framework Composer phiên bản mới nhất (tích hợp Composer v2.x và Bot Framework SDK v4.19+), sử dụng Orchestrator làm NLU engine chính cho multi-turn/multi-bot orchestration và dispatch intents.

🛠️ Ngữ cảnh kỹ thuật: Composer sử dụng Recognizer để xử lý ngôn ngữ tự nhiên (NLU). Để kết hợp nhiều bots, cần Dispatch model với Orchestrator – một thư viện ML-based từ Microsoft Research, hỗ trợ hierarchical intents và dynamic routing hiệu quả hơn LUIS hoặc regex-based dispatch.

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

Các đáp án đúng (3 lựa chọn):

• Change the Recognizer/Dispatch type.
• Create an Orchestrator model.
• Install the Orchestrator package.

Lý do lựa chọn 📘: Để tạo bot tổng hợp với dynamic routing, quy trình chuẩn trong Composer là:

1. Install Orchestrator package 🧩: Cài đặt package cần thiết để kích hoạt Orchestrator engine.
2. Create Orchestrator model 🔄: Huấn luyện model từ intents của 5 bots con, tạo file .model để dispatch intents dynamically.
3. Change the Recognizer/Dispatch type ⚙️: Chuyển Recognizer sang loại "Orchestrator" hoặc "Dispatch with Orchestrator" để bot chính sử dụng model này route input đến bot đúng. Kết hợp 3 bước này tạo ra Orchestrator-based Dispatch, hỗ trợ routing dựa trên ML prediction (hiệu suất cao, ít lỗi hơn so với regex). Đây là best practice từ docs Microsoft (không cần extension hay WebSockets).

📋 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, giữ nguyên văn bản gốc tiếng Anh. Mỗi phần đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do chi tiết bằng tiếng Việt:

• Create a composer extension.
  ❌ Sai: Composer extensions dùng để mở rộng UI hoặc custom components (như adaptive cards), không liên quan đến routing bots. Không hỗ trợ dynamic dispatch giữa nhiều bots.

• Change the Recognizer/Dispatch type.
  ✅ Đúng: Trong Composer, bạn phải chuyển Recognizer sang loại "Dispatch" hoặc "Orchestrator" (qua Properties panel). Điều này kích hoạt routing logic, phân tích input và chuyển đến bot con phù hợp dựa trên trained model. Bước bắt buộc sau khi tạo model.

• Create an Orchestrator model.
  ✅ Đúng: Tạo model Orchestrator bằng cách import intents từ 5 bots (qua "Train Orchestrator" wizard). Model này học hierarchical intents (ví dụ: "BookFlight" từ Bot1), hỗ trợ dynamic routing với độ chính xác cao (>95% theo benchmarks 2025).

• Enable WebSockets.
  ❌ Sai: WebSockets dùng cho real-time streaming channels (như Direct Line), không liên quan đến bot orchestration. Chỉ cần cho adaptive dialogs, không giải quyết vấn đề routing nhiều bots.

• Create a custom recognizer JSON file.
  ❌ Sai: File JSON custom dùng cho regex-based recognizers đơn giản, không scale cho 5 bots và thiếu dynamic ML routing. Orchestrator vượt trội hơn vì dùng pretrained embeddings (BERT-like).

• Install the Orchestrator package.
  ✅ Đúng: Cài package "Microsoft.Bot.Builder.Orchestrator" qua NuGet hoặc Composer marketplace (Settings > Extensions). Bước đầu tiên để unlock Orchestrator features, bao gồm CLI tools như orchestrator-cli train.

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

• Microsoft Docs chính thức: Dispatch to multiple bots or models with Orchestrator (Bot Framework Composer docs, v2.1.2+).
• GitHub Repo: BotBuilder-Composer/Orchestrator – Hướng dẫn install và train model.
• Azure Bot Service Guide: Multi-bot orchestration patterns (cập nhật Q1/2026).
• Release Notes: Orchestrator v0.9+ hỗ trợ multi-language và edge deployment (Azure AI Studio integration).

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

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

Câu hỏi tập trung vào việc tích hợp các nguồn dữ liệu khác nhau để có thể tìm kiếm thống nhất qua Azure Cognitive Search REST API (nay được gọi là Azure AI Search theo cập nhật mới nhất từ Microsoft đến năm 2026).

Các nguồn dữ liệu bao gồm:

• Finance: Cơ sở dữ liệu Microsoft SQL Server on-premises (tại chỗ, không phải cloud).
• Sales: Azure Cosmos DB sử dụng Core (SQL) API.
• Logs: Azure Table storage.
• HR: Azure SQL database.

Mục tiêu: Đảm bảo tất cả dữ liệu từ 4 nguồn này có thể được index và tìm kiếm qua REST API của Azure AI Search.

🛠️ Vấn đề cốt lõi: Azure AI Search hỗ trợ indexers (công cụ tự động crawl và index dữ liệu) cho nhiều nguồn cloud như Azure SQL, Cosmos DB (SQL API), Table Storage. Tuy nhiên, on-premises SQL Server không được hỗ trợ trực tiếp bởi indexer. Do đó, cần chuyển đổi dữ liệu từ nguồn on-premises sang một định dạng/store mà Azure AI Search hỗ trợ (như Azure Blob Storage, Azure Data Lake Storage Gen2 - ADLS Gen2).

Các nguồn khác (Sales, Logs, HR) đã sẵn sàng vì chúng thuộc Azure và được hỗ trợ indexer ngay lập tức (xem tài liệu indexer sources).

✅ Đáp án đúng: Export the data in Finance to Azure Data Lake Storage

Lý do lựa chọn:

• Finance là nguồn duy nhất on-premises SQL Server, không thể index trực tiếp. Việc export dữ liệu sang Azure Data Lake Storage (ADLS Gen2) giải quyết vấn đề vì:
  • ADLS Gen2 được hỗ trợ đầy đủ bởi Azure AI Search indexer (hỗ trợ hierarchical JSON, CSV, Parquet, v.v., cập nhật mới nhất 2026).
  • Sau export, tất cả 4 nguồn đều có thể được index: HR/Azure SQL ✅, Sales/Cosmos DB ✅, Logs/Table Storage ✅, Finance/ADLS ✅.
  • Sử dụng REST API để push/pull index từ các data source này một cách thống nhất.
• Đây là giải pháp tối ưu, ít xâm lấn nhất (không cần migrate toàn bộ, chỉ export), phù hợp best practice của Microsoft cho hybrid scenarios.

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

• Azure AI Search Indexers Overview (cập nhật 2025-2026).
• Supported Data Sources (xác nhận ADLS Gen2 hỗ trợ indexer).

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

• ❌ SAI: Migrate the data in HR to Azure Blob storage.
  Phương án này không cần thiết và sai lầm vì HR (Azure SQL database) đã được hỗ trợ trực tiếp bởi Azure AI Search indexer (SQL indexer với connection string). Việc migrate sang Blob Storage chỉ làm phức tạp hóa (Blob hỗ trợ nhưng không phải ưu tiên), không giải quyết vấn đề Finance on-premises – nguồn thực sự cần fix.

• ❌ SAI: Migrate the data in HR to the on-premises SQL server.
  Hoàn toàn sai vì sẽ làm HR từ nguồn cloud tốt (Azure SQL ✅ indexer) thành on-premises SQL (không hỗ trợ indexer). Kết quả: 2 nguồn không index được (HR + Finance), vi phạm mục tiêu "search all the data".

• ✅ ĐÚNG: Export the data in Finance to Azure Data Lake Storage.
  Như đã giải thích ở trên: Chỉ fix đúng nguồn vấn đề (Finance), ADLS Gen2 hỗ trợ indexer mạnh mẽ (hierarchical data, skillsets, vectors cho AI Search 2026), cho phép search thống nhất qua REST API.

• ❌ SAI: Ingest the data in Logs into Azure Sentinel.
  Không liên quan vì Logs (Azure Table Storage) đã hỗ trợ indexer trực tiếp (Table indexer). Azure Sentinel là công cụ SIEM/SOAR cho security logs, không phải data source cho AI Search. Việc ingest vào Sentinel chỉ dùng cho threat detection, không giúp index/search dữ liệu chung.

🛠️ Lưu ý bổ sung: Giải pháp đúng có thể kết hợp với Push model qua REST API nếu export định kỳ, hoặc Pull model qua indexer scheduler. Kiểm tra quyền IAM cho ADLS (Storage Blob Data Reader).

🧩 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-400 hoặc AZ-204 liên quan đến Azure AI), nơi bạn đang xây dựng một chatbot sử dụng Question Answering (QA) trong Azure Cognitive Service for Language (nay là Azure AI Language).
📄 Tình huống cụ thể:

• Bạn có file PDF tên Doc1.pdf chứa danh mục sản phẩm và bảng giá.
• Sau khi upload file và train model, chatbot trả lời đúng cho câu hỏi: "What is the price of ?" (giá của sản phẩm X).
• Nhưng thất bại với câu hỏi tương tự: "How much does cost?" (sản phẩm X giá bao nhiêu?).
• Mục tiêu: Đảm bảo chatbot trả lời đúng cả hai câu hỏi.
• Giải pháp đề xuất: Từ Language Studio, thêm alternative phrasing (các cách diễn đạt thay thế) vào cặp question-answer pair, sau đó retrain và republish model.
  ❓ Câu hỏi chính: Giải pháp này có đạt được mục tiêu không? (Yes/No).

🛠️ Bối cảnh kỹ thuật (cập nhật đến 2026): Azure AI Language hỗ trợ Custom Question Answering qua Language Studio, nơi model được train từ dữ liệu không cấu trúc như PDF. Model sử dụng NLP để match câu hỏi người dùng với các Q&A pairs được extract tự động hoặc chỉnh sửa thủ công. Vấn đề ở đây là semantic similarity – hai câu hỏi có ý nghĩa giống nhau nhưng phrasing khác, nên cần thêm alternate questions để cải thiện recall và precision.

✅ Đáp án đúng: Yes

Lý do lựa chọn:
Giải pháp này hoàn toàn phù hợp và đạt mục tiêu! Trong Language Studio, bạn có thể chỉnh sửa Q&A pairs bằng cách thêm alternative phrasing (các câu hỏi thay thế) cho cùng một answer. Ví dụ: Thêm "How much does cost?" vào pair chứa "What is the price of ?". Sau đó, retrain (chỉ mất vài phút) và republish để deploy. Model sẽ sử dụng embedding vectors và ranking models (dựa trên BERT-like models cập nhật 2025-2026) để nhận diện các biến thể ngôn ngữ tự nhiên, đảm bảo trả lời đúng cả hai câu. Đây là best practice chính thức từ Microsoft để handle paraphrasing.
🎯 Kết quả: Chatbot sẽ match semantic intent, không cần tạo knowledge base mới hay dùng Active Learning phức tạp.

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

• Yes ✅
  Đúng: Như đã phân tích, đây là cách chuẩn và hiệu quả nhất trong Language Studio. Thêm alternative phrasing giúp model mở rộng coverage cho các câu hỏi đồng nghĩa mà không thay đổi dữ liệu nguồn (PDF). Retrain nhanh chóng (dùng generative hoặc extractive mode mới nhất 2026) và republish đảm bảo zero-downtime. Không có side-effect tiêu cực, phù hợp với scenario multi-turn QA.

• No ❌
  Sai: Không chọn "No" vì giải pháp đúng chuẩn protocol của Azure AI Language. Nếu chọn No, có thể nghĩ nhầm rằng cần dùng Azure Bot Framework Composer hoặc chỉnh PDF nguồn, nhưng thực tế Language Studio hỗ trợ trực tiếp feature này. "No" chỉ đúng nếu giải pháp vi phạm (ví dụ: không retrain), nhưng ở đây đầy đủ quy trình.

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

• Azure AI Language - Question Answering: Add alternate questions 🛡️ (Hướng dẫn chính thức thêm phrasing).
• Language Studio Overview 📖 (Quy trình train/retrain/republish).
• Custom QA Best Practices 🔍 (Xử lý paraphrasing và PDF ingestion).

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

🧩 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à xử lý dữ liệu thông minh trên Azure. Tình huống cụ thể:

• Bạn có một indexer đang index hóa các purchase orders (đơn đặt hàng mua) bằng cách sử dụng Form Recognizer (nay là Azure AI Document Intelligence) để trích xuất thông tin từ tài liệu.
• Yêu cầu: Phân tích thông tin đã trích xuất bằng Microsoft Power BI (công cụ BI trực quan hóa dữ liệu), đồng thời tối thiểu hóa nỗ lực phát triển (minimize development effort).
• Câu hỏi yêu cầu: Nên thêm gì vào indexer để đạt được mục tiêu này?

Mục tiêu chính là tạo ra định dạng dữ liệu dễ dàng kết nối trực tiếp với Power BI mà không cần code phức tạp, tận dụng tính năng projections (chiếu dữ liệu) trong indexer của Azure AI Search. Projections giúp biến dữ liệu thô từ skillset (như Form Recognizer) thành các định dạng output sẵn sàng sử dụng (table, file, object). Với Power BI, định dạng table là lý tưởng nhất vì Power BI hỗ trợ import trực tiếp từ Azure AI Search indexer output dưới dạng bảng.

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

Đáp án đúng: a table projection
🛠️ Lý do:

• Table projection cho phép indexer tự động tạo ra các bảng dữ liệu (tables) từ thông tin trích xuất bởi Form Recognizer (như fields: invoice number, date, total amount từ purchase orders).
• Output là CSV hoặc Parquet files lưu trên Azure Blob Storage, Power BI có thể kết nối trực tiếp qua connector "Azure Blob Storage" hoặc "Azure AI Search", không cần viết code thêm.
• Điều này tối thiểu hóa dev effort vì toàn bộ quá trình (extract → project → store) được cấu hình declarative trong indexer definition, không yêu cầu custom skills hay ETL phức tạp.
• Tính năng này được hỗ trợ từ phiên bản Azure AI Search 2021-04-30 trở lên, và vẫn là best practice đến năm 2026 (Azure AI Search preview features như vector search không ảnh hưởng).

📋 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, giữ nguyên nội dung gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên tài liệu Azure AI Search mới nhất (2024-2026), tập trung vào khả năng tích hợp Power BI và minimize dev effort:

• ❌ [SAI] a projection group
  Phương án này không tồn tại trong Azure AI Search. Không có khái niệm "projection group" trong indexer hoặc skillset. Đây là lựa chọn đánh lừa, có thể nhầm lẫn với "output field mappings" hoặc groups trong projections khác, nhưng không hỗ trợ output table cho Power BI.

• ✅ [ĐÚNG] a table projection
  Như đã giải thích ở trên: Tạo bảng dữ liệu trực tiếp từ extracted fields của Form Recognizer, lưu dưới dạng file dễ import vào Power BI. Cấu hình đơn giản qua JSON schema trong indexer (ví dụ: {"tableProjections": [{"tableName": "purchase_orders", "source": "/document/tables/*"}]}). Hoàn hảo cho minimize dev effort.

• ❌ [SAI] a file projection
  File projection dùng để xuất toàn bộ document thành file gốc (như PDF, image) sau khi enrich, lưu trên Blob Storage. Không tạo table structured data, nên Power BI khó phân tích trực tiếp (phải extract lại), tăng dev effort. Phù hợp cho lưu trữ raw files hơn.

• ❌ [SAI] an object projection
  Object projection xuất dữ liệu dưới dạng JSON objects (hierarchical), hữu ích cho apps cần nested data. Tuy nhiên, Power BI không hỗ trợ native import JSON phức tạp từ indexer mà không cần Power Query transformations (tăng dev effort). Không tối ưu cho BI analysis như table.

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

• Chính thức Microsoft Docs: Indexer projections in Azure AI Search – Chi tiết table/file/object projections.
• Form Recognizer integration: Cognitive skill for Document Analysis – Ví dụ với purchase orders.
• Power BI connector: Connect to Azure AI Search from Power BI – Hỗ trợ table projections trực tiếp.
• Release notes 2024: Azure AI Search REST API version 2024-07-01 xác nhận projections ổn định, thêm hỗ trợ semantic search nhưng không thay đổi core projections.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần ví dụ code indexer JSON, hãy cho biết thêm.

🧩 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ự), mô tả tình huống xây dựng chatbot sử dụng Question Answering trong Azure Cognitive Service for Language (nay là Azure AI Language - Question Answering).

• Bối cảnh: Bạn upload file PDF Doc1.pdf chứa catalogue sản phẩm và danh sách giá, sau đó train model.
  • Chatbot thành công trả lời câu hỏi: "What is the price of ?" (giá của sản phẩm X).
  • Chatbot thất bại với câu hỏi tương tự: "How much does cost?" (sản phẩm X giá bao nhiêu?).
• Mục tiêu: Đảm bảo chatbot trả lời đúng cả hai câu hỏi (cần xử lý các biến thể ngôn ngữ của cùng một intent - hỏi giá sản phẩm).
• Giải pháp đề xuất: Từ Language Studio, bật tính năng chit-chat, sau đó retrain và republish model.
• Câu hỏi chính: Giải pháp này có đạt mục tiêu không? (Does this meet the goal?).

Vấn đề cốt lõi là model chưa nhận diện được các biến thể câu hỏi (question variations) từ dữ liệu tùy chỉnh trong PDF, dù chúng cùng hỏi về giá sản phẩm. Đây là hạn chế phổ biến của Question Answering nếu không cấu hình thêm synonyms hoặc alternate questions.

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

Đáp án đúng: No
📌 Lý do: Tính năng chit-chat chỉ thêm các phản hồi trò chuyện chung (small talk) như chào hỏi, cảm ơn, hoặc câu hỏi vui vẻ (ví dụ: "How are you?"), không liên quan đến việc xử lý các câu hỏi cụ thể từ dữ liệu tùy chỉnh như giá sản phẩm trong PDF. Bật chit-chat sẽ không giúp model nhận diện biến thể "How much does cost?", vì đây là câu hỏi knowledge base-based chứ không phải chit-chat. Giải pháp đúng phải là thêm alternate questions, synonyms cho phrases hỏi giá, hoặc kích hoạt active learning để model tự học từ feedback. (Dựa trên tài liệu Azure AI Language mới nhất 2024-2026).

🛠️ Giải thích tất cả các phương án trả lời

• Yes ❌
  Phương án sai. Lý do: Enabling chit-chat chỉ bổ sung các mẫu câu trò chuyện chung (pre-defined chit-chat dataset), không cải thiện khả năng matching các biến thể câu hỏi từ nguồn dữ liệu tùy chỉnh (custom question answering project). Chit-chat không train trên nội dung PDF, nên không giải quyết vấn đề nhận diện "How much does cost?" so với "What is the price of ?". Kết quả: Model vẫn fail, không đạt goal.

• No ✅
  Phương án đúng. Lý do: Như đã phân tích, chit-chat không phải công cụ để xử lý question variations trong custom Q&A. Thay vào đó, cần:

  • Thêm alternate questions hoặc short answer với phrases như "how much", "cost", "giá" vào Language Studio.
  • Sử dụng boosting/lowering phrases hoặc active learning để model học từ test cases.
  • Retrain sau khi chỉnh sửa.
    Điều này đảm bảo model hiểu semantic similarity giữa hai câu hỏi.

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

• Azure AI Language - Question Answering Overview: learn.microsoft.com/en-us/azure/ai-services/language-service/question-swering/overview – Giải thích chit-chat chỉ cho small talk, không custom Q&A.
• Chit-chat trong Language Studio: learn.microsoft.com/en-us/azure/ai-services/language-service/question-answering/how-to/chit-chat – Xác nhận chỉ thêm conversational responses, không ảnh hưởng knowledge base.
• Question Variations & Synonyms: learn.microsoft.com/en-us/azure/ai-services/language-service/question-answering/concepts/best-practices – Hướng dẫn fix variations như trường hợp này.
• Phiên bản mới nhất: Azure AI Language v2024-10-01 (tương thích đến 2026, không thay đổi core chit-chat behavior).

Hy vọng phân tích giúp bạn ôn thi hiệu quả! 🚀 Nếu cần ví dụ code deploy, hỏi thêm nhé!

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

Xin chào! Tôi là một Microsoft Azure AI Engineer với kinh nghiệm sâu rộng về các dịch vụ Azure AI, bao gồm Azure AI Search (trước đây là Azure Cognitive Search).
Hôm nay, tôi sẽ phân tích chi tiết câu hỏi trắc nghiệm này theo đúng yêu cầu của bạn. Câu hỏi thuộc dạng "case study" trong các kỳ thi chứng chỉ Azure (như AZ-400 hoặc AZ-204), nơi mỗi giải pháp được đánh giá riêng lẻ xem có đạt mục tiêu hay không. Chủ đề tập trung vào scaling Azure AI Search để xử lý throttling (giới hạn tốc độ yêu cầu). Tôi sử dụng kiến thức cập nhật đến phiên bản Azure AI Search mới nhất năm 2026, với các tính năng scaling linh hoạt qua replicas và partitions.

🧩 1. Giải thích nội dung câu hỏi một cách chi tiết và rõ ràng

• Bối cảnh (Scenario): Bạn đang quản lý một dịch vụ Azure Cognitive Search (nay gọi là Azure AI Search). Trong 12 tháng qua, lượng query tìm kiếm (query volume) tăng dần đều.
• Vấn đề (Problem): Một số yêu cầu query tìm kiếm bị throttled (giới hạn tốc độ, dẫn đến lỗi 429 Too Many Requests hoặc độ trễ cao). Throttling xảy ra khi dịch vụ vượt quá giới hạn tài nguyên hiện tại.
• Mục tiêu (Goal): Giảm khả năng query bị throttled (reduce the likelihood that search query requests are throttled).
• Giải pháp đề xuất (Solution): Thêm replicas (add replicas).
• Câu hỏi chính: Giải pháp này có đạt mục tiêu không? (Does this meet the goal?).
• Lưu ý đặc biệt: Đây là câu hỏi "one-way" (không quay lại được), và có thể có nhiều giải pháp đúng/sai trong series.

🛠️ Nguyên lý hoạt động của Azure AI Search scaling (cập nhật 2026):
Azure AI Search scale theo search units (SU) = replicas × partitions.

• Replicas: Scale read operations (queries, lookups) – tăng khả năng xử lý đồng thời nhiều query đọc dữ liệu. Mỗi replica xử lý độc lập queries, giảm tải và throttling cho search requests.
• Partitions: Scale write operations (indexing, document ingestion) và storage.
  Vấn đề ở đây là query throttling (read-heavy), nên replicas là giải pháp trực tiếp!

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

Đáp án đúng: Yes ✅

Lý do chi tiết:
Thêm replicas trực tiếp tăng throughput cho search queries (lên đến hàng nghìn queries/giây tùy tier). Theo tài liệu Azure 2026:

• Mỗi replica xử lý queries song song, phân tải traffic.
• Throttling query giảm đáng kể vì replicas scale horizontal read capacity.
• Ví dụ: Tier Basic (1 replica mặc định) dễ throttle khi volume tăng; scale lên 2-12 replicas (tùy tier) giải quyết ngay.
  Giải pháp đúng 100% đạt mục tiêu, không ảnh hưởng indexing (nếu cần, kết hợp partitions sau).

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

Tôi giữ nguyên văn bản gốc phương án bằng tiếng Anh, chỉ phân tích/giải thích bằng tiếng Việt hoàn toàn. Sử dụng ✅ cho đúng, ❌ cho sai.

• Yes ✅
  Giải thích đúng: Phương án này hoàn toàn phù hợp vì replicas chuyên scale search query performance. Khi query volume tăng, thêm replicas (qua portal/CLI/API) ngay lập tức tăng query limits (ví dụ: Standard tier từ 3 QPS/replica lên cao hơn). Throttling query giảm mạnh, đạt mục tiêu "reduce likelihood". Đây là best practice chính thức từ Microsoft cho read-heavy workloads.

• No ❌
  Giải thích sai: Phương án này không chính xác vì bỏ qua cơ chế scaling cốt lõi của Azure AI Search. Thêm replicas KHÔNG phải giải pháp sai – ngược lại, nó là khuyến nghị hàng đầu cho query throttling. Chọn "No" sẽ nhầm lẫn với trường hợp write-heavy (cần partitions). Trong case study này, query-focused → "No" thất bại mục tiêu.

📘 4. Tài liệu tham khảo (References) – Cập nhật mới nhất 2026

• Chính thức Microsoft: Azure AI Search Limits & Scaling – Xác nhận replicas cho query throttling.
• Service Limits: Azure AI Search Performance Guidelines – Replicas scale QPS lên 200-2250+/replica.
• CLI/API Scale: az search service update --replica-count 2 (Azure CLI v2.65+).
• Case Study tương tự: Microsoft Docs "High Availability & Throttling" (2026 update hỗ trợ autoscaling preview).

💡 Lời khuyên từ Azure Engineer: Để tối ưu, monitor qua Metrics (Query Throttling Rate) trong Azure Portal, kết hợp autoscaling nếu volume biến động. Nếu cần tư vấn thêm case study khác, hãy hỏi nhé! 🚀