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

Tìm thấy 316 câu.

Câu 11
Your company is developing a chatbot that needs to understand customer queries in multiple languages and generate appropriate responses. The development team is evaluating different neural network architectures and suggests using a Transformer-based model. Which feature of the Transformer architecture makes it particularly suitable for this natural language processing task?
  1. A The use of convolutional layers that extract features from fixed-size text segments to identify patterns.
  2. B The ability to process all words in a sentence simultaneously rather than sequentially, allowing the model to understand context more efficiently.
  3. C The reliance on labeled training data to create decision trees for classification of customer intents.
  4. D The requirement to process text one word at a time in a specific order, which ensures grammatical accuracy in the responses.
Xem giải thích

Đáp án

B — Khả năng xử lý ĐỒNG THỜI mọi từ trong câu thay vì tuần tự, giúp mô hình hiểu ngữ cảnh hiệu quả hơn.

Vì sao đúng

⚠ Đột phá của Transformer nằm ở cơ chế ATTENTION:

⚠ Mô hình CŨ (RNN, LSTM)
   ⚠ đọc từ 1 → từ 2 → từ 3 → ...
   ⚠ TUẦN TỰ, không song song được
   ⚠ từ xa nhau khó liên hệ

⚠ TRANSFORMER
   ⚠ nhìn TOÀN BỘ câu cùng lúc
   ⚠ mỗi từ "chú ý" tới mọi từ khác
        ↓
⚠ Huấn luyện SONG SONG trên GPU
⚠ Nắm được quan hệ giữa các từ XA NHAU
Lợi ích Nội dung
⚠ Song song hoá ⚠ huấn luyện nhanh hơn nhiều lần
⚠ Ngữ cảnh dài ⚠ liên hệ được từ đầu câu với cuối câu
⚠ Đa ngôn ngữ ⚠ học được biểu diễn chung cho nhiều ngôn ngữ

Vì sao các phương án khác sai

  • D (xử lý từng từ theo thứ tự) — ⚠ mô tả RNN/LSTM, tức là mô hình TRƯỚC Transformer: ⚠ đúng thứ Transformer thay thế.

  • A (dùng lớp tích chập trên đoạn văn bản cố định) — ⚠ mô tả CNN: ⚠ dùng cho ảnh, ⚠ và cho văn bản ở một số kiến trúc cũ.

  • C (dựa vào dữ liệu có nhãn để tạo cây quyết định) — ⚠ mô tả cây quyết định: ⚠ hoàn toàn không phải Transformer.

Ghi nhớ

⚠ Transformer — khái niệm phải thuộc: | Khái niệm | Nội dung | |---|---| | ⚠ Self-attention | ⚠ mỗi từ tính mức liên quan với mọi từ khác | | ⚠ Positional encoding | ⚠ thêm thông tin VỊ TRÍ vì không xử lý tuần tự | | ⚠ Multi-head attention | ⚠ nhiều "góc nhìn" quan hệ song song | | ⚠ Encoder / Decoder | ⚠ encoder hiểu, decoder sinh | | ⚠ Bài báo gốc | ⚠ "Attention Is All You Need" (2017) |

Từ khoá nhận diện:

"xử lý song song, attention" → ⚠ Transformer "xử lý tuần tự từng từ" → ⚠ RNN, LSTM "lớp tích chập" → ⚠ CNN — chủ yếu cho ảnh "GPT, BERT, Llama" → ⚠ đều dựa trên Transformer

⚠ Ba kiểu kiến trúc Transformer Kiểu
⚠ Encoder-only ⚠ BERT — hiểu văn bản: phân loại, trích thực thể
⚠ Decoder-only ⚠ GPT — SINH văn bản
⚠ Encoder-decoder ⚠ T5, BART — dịch, tóm tắt
⚠ Chatbot sinh ngữ ⚠ thường là decoder-only
⚠ Vì sao positional encoding cần thiết Lý do
⚠ Attention nhìn mọi từ cùng lúc ⚠ không biết từ nào trước, từ nào sau
⚠ "chó cắn người" và "người cắn chó" khác nghĩa
⚠ Positional encoding thêm thông tin thứ tự vào
⚠ Nếu thiếu ⚠ mô hình coi câu như một túi từ không thứ tự
⚠ Hạn chế của Transformer Hạn chế
⚠ Chi phí attention tăng theo BÌNH PHƯƠNG độ dài ⚠ câu dài rất tốn
⚠ Cần rất nhiều dữ liệu và tính toán
⚠ Cửa sổ ngữ cảnh có giới hạn
⚠ Nghiên cứu hiện nay ⚠ tập trung vào attention hiệu quả hơn cho ngữ cảnh dài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cửa sổ ngữ cảnh của mô hình là bao nhiêu | | | Kiến trúc phù hợp là encoder hay decoder | | | Chi phí theo token đã tính chưa | ⚠ văn bản dài tốn theo cấp số |

Và điều làm Transformer thay đổi hẳn ngành xử lý ngôn ngữ: nó biến việc huấn luyện thành bài toán song song hoá được. Nhờ đó mô hình có thể lớn lên hàng nghìn lần trong vài năm, điều mà kiến trúc tuần tự không bao giờ cho phép.

Câu 12
A healthcare company is developing a generative AI chatbot to provide general health information to patients. During testing, the chatbot occasionally provides medical advice that contradicts established medical guidelines and sometimes generates information about specific medications that doesn't exist. Which responsible AI principle should be the PRIMARY focus to address these issues?
  1. A Reliability and safety
  2. B Fairness and inclusiveness
  3. C Transparency
  4. D Privacy and security
Xem giải thích

Đáp án

A — Reliability and safety (Độ tin cậy và An toàn).

Vì sao đúng

⚠ Hai triệu chứng trong đề đều thuộc về độ tin cậy: | Triệu chứng | Vấn đề | |---|---| | ⚠ Lời khuyên y tế TRÁI với hướng dẫn chuẩn | ⚠ thông tin SAI — không đáng tin | | ⚠ Bịa ra thuốc KHÔNG TỒN TẠI | ⚠ hallucination — ảo giác của mô hình |

⚠ Mô hình sinh ngữ
   ⚠ dự đoán từ tiếp theo có xác suất cao
   ⚠ KHÔNG kiểm tra tính ĐÚNG
        ↓
⚠ Sinh ra thứ nghe rất thuyết phục
   ⚠ nhưng hoàn toàn bịa
        ↓
⚠ Trong Y TẾ = ⚠ nguy hiểm thật sự

⚠ Trong y tế, thông tin sai không chỉ là bất tiện — nó gây hại.

Vì sao các phương án khác sai

  • C (Transparency) — ⚠ liên quan nhưng không phải trọng tâm: ⚠ minh bạch là cho người dùng biết đang nói chuyện với AI; ⚠ vấn đề ở đây là ⚠ nội dung SAI.

  • B (Fairness and inclusiveness) — ⚠ về đối xử công bằng giữa các nhóm: ⚠ đề không nêu vấn đề thiên lệch.

  • D (Privacy and security) — ⚠ về bảo vệ dữ liệu: ⚠ đề không nêu vấn đề rò rỉ.

Ghi nhớ

⚠ Sáu nguyên tắc Responsible AI — ánh xạ với triệu chứng: | Triệu chứng | Nguyên tắc | |---|---| | ⚠ Thông tin SAI, bịa đặt, kết quả không ổn định | ⚠ Reliability & Safety | | ⚠ Kết quả kém với một nhóm người | ⚠ Fairness | | ⚠ Người dùng không biết đang nói với AI | ⚠ Transparency | | ⚠ Rò rỉ dữ liệu cá nhân | ⚠ Privacy & Security | | ⚠ Không ai chịu trách nhiệm, không truy vết được | ⚠ Accountability | | ⚠ Người khuyết tật không dùng được | ⚠ Inclusiveness |

Từ khoá nhận diện:

"bịa thông tin, hallucination" → ⚠ Reliability & Safety "không biết đang nói với máy" → ⚠ Transparency "kém với nhóm thiểu số" → ⚠ Fairness "ai chịu trách nhiệm" → ⚠ Accountability

⚠ Cách giảm hallucination Cách
⚠ RAG — neo câu trả lời vào tài liệu thật ⚠ hiệu quả nhất
⚠ System message giới hạn phạm vi trả lời
⚠ Bắt mô hình TRÍCH DẪN nguồn
⚠ Giảm temperature ⚠ bớt sáng tạo, bám dữ liệu hơn
⚠ Groundedness detection của Content Safety ⚠ phát hiện câu trả lời không có căn cứ
⚠ Con người rà soát với nội dung rủi ro cao
⚠ Vì sao mô hình bịa đặt Lý do
⚠ Nó dự đoán TỪ TIẾP THEO có xác suất cao
⚠ Không có cơ chế kiểm tra sự thật
⚠ Được huấn luyện để trả lời, không phải để nói "tôi không biết"
⚠ Hệ quả ⚠ câu bịa nghe TRÔI CHẢY y như câu đúng
⚠ Ứng dụng AI trong y tế — nguyên tắc Nguyên tắc
⚠ Không đưa lời khuyên y tế trực tiếp ⚠ chỉ cung cấp thông tin chung
⚠ Luôn khuyến nghị gặp bác sĩ
⚠ Neo mọi câu trả lời vào nguồn được duyệt
⚠ Ghi log để rà soát
⚠ Có đường chuyển sang người thật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Câu trả lời có neo vào nguồn thật không | ⚠ RAG | | Có kiểm thử với câu hỏi gài bẫy không | | | Có cảnh báo rõ đây không phải lời khuyên y tế không | |

Và điều nguy hiểm nhất ở hiện tượng bịa đặt của mô hình ngôn ngữ: câu bịa nghe y hệt câu đúng. Không có dấu hiệu ngữ pháp hay giọng điệu nào để người đọc phân biệt — đó chính là lý do phải neo câu trả lời vào tài liệu thật.

Câu 13
A healthcare organization is developing an AI-powered chatbot that will help patients schedule appointments and answer general health questions. The chatbot will process patient names, contact information, and medical symptoms during conversations. Which action should the organization prioritize to ensure compliance with privacy regulations?
  1. A Store all conversation logs in a public cloud storage account to ensure backup redundancy and easy access for the development team.
  2. B Implement data encryption at rest and in transit, ensure proper authentication mechanisms, and establish role-based access controls for accessing patient conversation data.
  3. C Allow the AI model to retain all patient conversation history indefinitely to improve the accuracy of future responses through continuous learning.
  4. D Share anonymized conversation data with third-party vendors without patient consent to help improve the AI model's performance.
Xem giải thích

Đáp án

B — Triển khai mã hoá dữ liệu khi lưu và khi truyền, bảo đảm cơ chế xác thực đúng đắn, và thiết lập kiểm soát truy cập theo vai trò cho dữ liệu hội thoại bệnh nhân.

Vì sao đúng

⚠ Ba lớp bảo vệ cơ bản, đúng chuẩn cho dữ liệu y tế: | Lớp | Nội dung | |---|---| | ⚠ Mã hoá khi LƯU (at rest) | ⚠ ai lấy được ổ đĩa cũng không đọc được | | ⚠ Mã hoá khi TRUYỀN (in transit) | ⚠ TLS — chống nghe lén | | ⚠ Xác thực đúng đắn | ⚠ chỉ người hợp lệ mới vào được | | ⚠ RBAC | ⚠ mỗi vai trò chỉ thấy phần cần thiết |

⚠ Dữ liệu trong đề gồm tên, liên hệ và TRIỆU CHỨNG Y TẾ — ⚠ thuộc loại nhạy cảm nhất theo mọi khung pháp lý.

Vì sao các phương án khác sai

  • A (lưu log hội thoại vào tài khoản lưu trữ CÔNG KHAI) — ⚠ vi phạm nghiêm trọng: ⚠ "công khai" nghĩa là ⚠ ai trên Internet cũng đọc được.

  • C (giữ vô thời hạn toàn bộ lịch sử hội thoại để cải thiện mô hình) — ⚠ vi phạm nguyên tắc GIỚI HẠN LƯU TRỮ: ⚠ GDPR và HIPAA đều đòi ⚠ chỉ giữ dữ liệu trong thời gian cần thiết.

  • D (chia sẻ dữ liệu ẩn danh cho bên thứ ba mà KHÔNG có sự đồng ý) — ⚠ hai vấn đề: ⚠ thiếu đồng thuận; ⚠ và ⚠ "ẩn danh" thường không thật sự ẩn danh — dữ liệu y tế rất dễ tái định danh.

Ghi nhớ

⚠ Bảo vệ dữ liệu y tế — các lớp bắt buộc: | Lớp | Công nghệ | |---|---| | ⚠ Mã hoá khi lưu | ⚠ TDE, Storage encryption, CMEK | | ⚠ Mã hoá khi truyền | ⚠ TLS 1.2+ | | ⚠ Xác thực | ⚠ Entra ID, MFA | | ⚠ Phân quyền | ⚠ RBAC, quyền tối thiểu | | ⚠ Ghi nhật ký | ⚠ audit log ai truy cập gì | | ⚠ Giới hạn lưu trữ | ⚠ chính sách xoá theo thời hạn | | ⚠ Che/ẩn danh khi phân tích | ⚠ PII Detection |

Từ khoá nhận diện:

"bảo vệ dữ liệu cá nhân" → ⚠ Privacy & Security "công khai, giữ vô thời hạn, chia sẻ không đồng thuận" → ⚠ luôn là phương án SAI "quyền tối thiểu" → ⚠ RBAC

⚠ Nguyên tắc giới hạn dữ liệu Nguyên tắc
⚠ Chỉ thu thập dữ liệu THẬT SỰ cần ⚠ data minimisation
⚠ Chỉ giữ trong thời gian cần thiết ⚠ storage limitation
⚠ Chỉ dùng cho mục đích đã thông báo ⚠ purpose limitation
⚠ Vi phạm phổ biến ⚠ "cứ giữ hết, biết đâu sau này cần"
⚠ Ẩn danh hoá — vì sao khó hơn ta tưởng Lý do
⚠ Xoá tên KHÔNG đủ
⚠ Ngày sinh + mã bưu chính + giới tính = định danh được
⚠ Dữ liệu y tế hiếm gặp tự nó là định danh
⚠ Cần ⚠ phân tích rủi ro tái định danh (k-anonymity)
⚠ Và ⚠ sự đồng thuận vẫn cần dù đã ẩn danh, tuỳ quy định
⚠ Với chatbot y tế — lưu ý riêng Lưu ý
⚠ Nội dung hội thoại có thể chứa PII không lường trước
⚠ Log của mô hình cũng phải được bảo vệ
⚠ Cân nhắc tắt logging phía nhà cung cấp ⚠ Azure OpenAI có tuỳ chọn này
⚠ Ký BAA nếu chịu HIPAA

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log hội thoại được lưu ở đâu, ai đọc được | | | Có chính sách xoá sau N ngày không | | | Nhà cung cấp mô hình có lưu dữ liệu của bạn không | |

Và câu hỏi hay bị bỏ qua khi tích hợp mô hình ngôn ngữ của bên thứ ba: dữ liệu gửi lên có được nhà cung cấp lưu lại không?. Với dữ liệu y tế, câu trả lời phải là không, và phải có văn bản xác nhận điều đó.

Câu 14
A marketing team wants to use AI to create unique product descriptions for their e-commerce website. They need the AI system to generate original content based on product specifications they provide. Which type of AI workload would be most appropriate for this scenario?
  1. A Anomaly detection
  2. B Computer vision
  3. C Generative AI
  4. D Classification
Xem giải thích

Đáp án

C — Generative AI (AI sinh nội dung).

Vì sao đúng

⚠ Đề nêu rõ: TẠO RA nội dung MỚI, ĐỘC ĐÁO từ thông số sản phẩm.

⚠ Đầu vào: thông số sản phẩm
   ⚠ "áo thun cotton, màu xanh,
      size M, có túi"
        ↓ ⚠ Generative AI
⚠ Đầu ra: mô tả bán hàng MỚI
   ⚠ "Chiếc áo thun cotton mềm mại
      với sắc xanh dịu mắt..."
Phân biệt cốt lõi Nội dung
⚠ AI phân tích ⚠ PHÂN LOẠI, dự đoán, phát hiện thứ ĐÃ CÓ
⚠ AI SINH NGỮ ⚠ TẠO RA nội dung chưa từng tồn tại

Vì sao các phương án khác sai

  • D (classification) — ⚠ gán NHÃN cho thứ đã có: ⚠ không tạo ra nội dung mới.

  • B (computer vision) — ⚠ phân tích ẢNH: ⚠ đề tạo VĂN BẢN.

  • A (anomaly detection) — ⚠ phát hiện bất thường trong số liệu.

Ghi nhớ

⚠ Phân biệt AI phân tích và AI sinh ngữ — bảng phải thuộc: | Loại | Đầu ra | Ví dụ | |---|---|---| | ⚠ Phân loại | ⚠ NHÃN có sẵn | ⚠ thư này là spam hay không | | ⚠ Hồi quy | ⚠ CON SỐ | ⚠ doanh thu tháng tới | | ⚠ Phân cụm | ⚠ NHÓM | ⚠ phân khúc khách hàng | | ⚠ Phát hiện bất thường | ⚠ bình thường / bất thường | | | ⚠ Sinh ngữ (Generative) | ⚠ NỘI DUNG MỚI | ⚠ văn bản, ảnh, mã, âm thanh |

Từ khoá nhận diện:

"tạo ra, viết ra, sinh ra nội dung mới" → ⚠ Generative AI "phân loại, gán nhãn" → ⚠ classification "dự đoán con số" → ⚠ regression "tìm điểm bất thường" → ⚠ anomaly detection

⚠ Dịch vụ Generative AI trên Azure Dịch vụ
⚠ Azure OpenAI Service ⚠ GPT cho văn bản, DALL·E cho ảnh
⚠ Azure AI Foundry ⚠ catalog nhiều mô hình, công cụ xây ứng dụng
⚠ Azure AI Content Safety ⚠ lọc nội dung đầu vào và đầu ra
⚠ Với sinh mô tả sản phẩm ⚠ mô hình ngôn ngữ + prompt có cấu trúc
⚠ Thiết kế prompt cho sinh nội dung hàng loạt Thiết kế
⚠ System message định GIỌNG ĐIỆU thương hiệu
⚠ Đưa VÍ DỤ mẫu (few-shot) ⚠ giúp giữ nhất quán
⚠ Truyền thông số sản phẩm dạng có cấu trúc
⚠ Giới hạn độ dài đầu ra
⚠ Đặt temperature vừa phải ⚠ quá cao thì lan man, quá thấp thì đơn điệu
⚠ Rủi ro khi sinh nội dung thương mại Rủi ro
⚠ Bịa thông số không có thật ⚠ nguy hiểm về pháp lý với mô tả sản phẩm
⚠ Nội dung trùng lặp giữa các sản phẩm
⚠ Giọng điệu không nhất quán với thương hiệu
⚠ Bắt buộc ⚠ có người rà soát trước khi đăng, ít nhất ở giai đoạn đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nội dung sinh ra có bịa thông số không | ⚠ kiểm tra ngẫu nhiên | | Giọng điệu có nhất quán không | | | Có quy trình rà soát trước khi đăng không | |

Và rủi ro cụ thể khi dùng AI viết mô tả sản phẩm thương mại: mô hình có thể bịa ra tính năng sản phẩm không có. Một câu quảng cáo sai sự thật do máy viết vẫn là trách nhiệm pháp lý của doanh nghiệp.

Câu 15
A retail company wants to implement a customer analytics solution that can detect when customers enter their store and estimate their age range to provide targeted advertising on digital displays. The solution should not identify specific individuals. Which capability of Azure AI Face service should they use?
  1. A Face verification with similarity scores
  2. B Face detection with age attribute analysis
  3. C Face recognition with custom model training
  4. D Face identification with a person group
Xem giải thích

Đáp án

B — Face detection kèm phân tích thuộc tính tuổi.

Vì sao đúng

⚠ Đề nêu ràng buộc quyết định: "KHÔNG được định danh cá nhân cụ thể". | Năng lực | Có định danh không | |---|---| | ⚠ Face DETECTION | ⚠ KHÔNG — chỉ phát hiện "có khuôn mặt", kèm thuộc tính | | ⚠ Face VERIFICATION | ⚠ so hai khuôn mặt — có phải một người không | | ⚠ Face IDENTIFICATION | ⚠ CÓ — tìm ra người đó là ai trong Person Group |

⚠ Face detection
   ⚠ trả về: vị trí khuôn mặt
   ⚠ thuộc tính: khoảng tuổi ước lượng
        ↓
⚠ KHÔNG lưu, KHÔNG so khớp danh tính
        ↓
⚠ Đủ để hiển thị quảng cáo theo nhóm tuổi

Vì sao các phương án khác sai

  • D (face identification với person group) — ⚠ CHÍNH LÀ định danh cá nhân: ⚠ vi phạm ràng buộc của đề.

  • A (face verification với điểm tương đồng) — ⚠ cũng so khớp danh tính: ⚠ xác nhận hai ảnh có cùng một người.

  • C (face recognition với mô hình tuỳ chỉnh) — ⚠ nhận diện danh tính: ⚠ vi phạm ràng buộc.

Ghi nhớ

⚠ Azure AI Face — các năng lực: | Năng lực | Việc | |---|---| | ⚠ Detection | ⚠ tìm khuôn mặt, trả thuộc tính | | ⚠ Verification | ⚠ hai ảnh có cùng một người không (1:1) | | ⚠ Identification | ⚠ người này là ai trong nhóm (1:N) | | ⚠ Similarity | ⚠ tìm khuôn mặt giống nhất | | ⚠ Grouping | ⚠ gom khuôn mặt giống nhau thành nhóm |

Từ khoá nhận diện:

"không định danh cụ thể, chỉ thống kê" → ⚠ face detection "xác thực đăng nhập bằng khuôn mặt" → ⚠ verification "tìm ra người này là ai" → ⚠ identification

⚠ LƯU Ý PHÁP LÝ QUAN TRỌNG Lưu ý
⚠ Microsoft HẠN CHẾ quyền dùng nhận diện khuôn mặt ⚠ phải đăng ký và được duyệt
⚠ Một số thuộc tính đã bị GỠ BỎ ⚠ giới tính, cảm xúc, tuổi — vì lo ngại đạo đức
⚠ Nhiều nơi có luật riêng về sinh trắc học
⚠ Trước khi triển khai ⚠ kiểm tra cả điều khoản Microsoft LẪN luật địa phương
⚠ Vì sao Microsoft hạn chế các thuộc tính này Lý do
⚠ Ước lượng tuổi và giới tính có thiên lệch theo chủng tộc
⚠ Suy đoán cảm xúc từ khuôn mặt thiếu cơ sở khoa học
⚠ Nguy cơ dùng để phân biệt đối xử
⚠ Bài học chung ⚠ năng lực kỹ thuật làm được không có nghĩa là NÊN làm
⚠ Thiết kế tôn trọng quyền riêng tư cho ca dùng này Thiết kế
⚠ Xử lý tại chỗ, KHÔNG gửi ảnh lên đám mây
⚠ KHÔNG lưu ảnh khuôn mặt
⚠ Chỉ giữ số liệu tổng hợp ⚠ "15 người nhóm 20-30 tuổi"
⚠ Có biển thông báo cho khách hàng
⚠ Cân nhắc dùng object detection người thay vì face ⚠ ít xâm phạm hơn nhiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần khuôn mặt không | ⚠ đếm người có thể dùng object detection | | Ảnh có được lưu không | ⚠ không nên | | Đã kiểm tra quy định pháp lý địa phương chưa | |

Và câu hỏi nên đặt trước mọi dự án dùng nhận diện khuôn mặt: có cách nào đạt mục tiêu mà không cần tới khuôn mặt không?. Rất thường xuyên câu trả lời là có, và giải pháp đó vừa đơn giản hơn vừa ít rủi ro pháp lý hơn.

Câu 16
A retail company wants to develop an AI solution that can analyze security camera footage from their stores. The solution needs to identify when customers are present in restricted areas and count how many shopping carts are currently in use. Which type of computer vision solution should they implement?
  1. A Image classification
  2. B Optical character recognition (OCR)
  3. C Object detection
  4. D Facial recognition
Xem giải thích

Đáp án

C — Object detection (phát hiện đối tượng).

Vì sao đúng

⚠ Đề cần hai việc, cả hai đều là object detection: | Việc | Vì sao cần object detection | |---|---| | ⚠ Phát hiện khách trong khu vực HẠN CHẾ | ⚠ cần biết VỊ TRÍ, không chỉ có/không | | ⚠ ĐẾM số xe đẩy đang dùng | ⚠ cần đếm từng đối tượng riêng biệt |

⚠ Image classification
   ⚠ "ảnh này CÓ người" — một nhãn cho cả ảnh
        ↓ ⚠ KHÔNG đủ

⚠ Object detection
   ⚠ "có 3 người tại (x1,y1), (x2,y2), (x3,y3)"
   ⚠ "có 5 xe đẩy tại..."
        ↓
⚠ Biết VỊ TRÍ → ⚠ so với khu vực hạn chế
⚠ Biết SỐ LƯỢNG → ⚠ đếm được

Vì sao các phương án khác sai

  • A (image classification) — ⚠ chỉ gán MỘT nhãn cho CẢ ảnh: ⚠ không cho vị trí, ⚠ không đếm được.

  • D (facial recognition) — ⚠ định danh CÁ NHÂN: ⚠ đề chỉ cần biết có người, không cần biết là ai; ⚠ và dùng nhận diện khuôn mặt ở đây là xâm phạm không cần thiết.

  • B (OCR) — ⚠ đọc CHỮ trong ảnh: ⚠ không liên quan.

Ghi nhớ

⚠ Các tác vụ computer vision — bảng phải thuộc: | Tác vụ | Đầu ra | |---|---| | ⚠ Image classification | ⚠ MỘT nhãn cho cả ảnh | | ⚠ Object detection | ⚠ NHIỀU đối tượng + bounding box + nhãn | | ⚠ Semantic segmentation | ⚠ nhãn cho TỪNG PIXEL | | ⚠ Instance segmentation | ⚠ tách từng đối tượng ở mức pixel | | ⚠ OCR | ⚠ chữ trong ảnh | | ⚠ Face detection/recognition | ⚠ khuôn mặt |

Từ khoá nhận diện:

"ĐẾM, VỊ TRÍ, nhiều đối tượng" → ⚠ object detection "ảnh này thuộc loại nào" → ⚠ classification "vùng chính xác tới từng pixel" → ⚠ segmentation "đọc chữ" → ⚠ OCR

⚠ Dịch vụ Azure cho object detection Dịch vụ
⚠ Azure AI Vision — Image Analysis ⚠ đối tượng thông dụng, dựng sẵn
⚠ Azure AI Custom Vision ⚠ đối tượng RIÊNG — như xe đẩy của cửa hàng
⚠ Azure AI Video Indexer ⚠ phân tích video
⚠ Với "xe đẩy siêu thị" ⚠ có thể cần Custom Vision nếu mô hình chung không nhận ra
⚠ Xử lý video an ninh — kiến trúc Kiến trúc
⚠ Camera → trích frame theo chu kỳ ⚠ không cần xử lý mọi frame
⚠ Chạy object detection ở BIÊN ⚠ giảm băng thông và độ trễ
⚠ Chỉ gửi sự kiện lên đám mây ⚠ không gửi cả video
⚠ Lưu số liệu tổng hợp
⚠ Vì sao xử lý ở biên ⚠ video liên tục quá tốn băng thông và tiền
⚠ Cân nhắc quyền riêng tư cho camera cửa hàng Cân nhắc
⚠ Đếm người KHÔNG cần nhận diện khuôn mặt
⚠ Không lưu hình ảnh cá nhân
⚠ Có biển thông báo có camera
⚠ Chỉ giữ số liệu tổng hợp
⚠ Nguyên tắc ⚠ thu thập ít nhất mức đủ để đạt mục tiêu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình chung có nhận ra xe đẩy không | ⚠ thử trước, nếu không thì cần Custom Vision | | Xử lý ở biên hay trên đám mây | ⚠ ảnh hưởng lớn tới chi phí | | Có lưu hình ảnh cá nhân không | ⚠ không nên |

Và quyết định kiến trúc quan trọng nhất khi phân tích video an ninh: xử lý ở đâu. Gửi luồng video liên tục lên đám mây tốn băng thông và chi phí gấp nhiều lần so với xử lý tại chỗ và chỉ gửi kết quả.

Câu 17
A marketing team wants to create personalized email content for thousands of customers based on their purchase history and preferences. The team needs the content to be unique for each customer while maintaining the company's brand voice. Which type of AI workload would be most appropriate for this scenario?
  1. A Generative AI
  2. B Classification
  3. C Computer vision
  4. D Anomaly detection
Xem giải thích

Đáp án

A — Generative AI.

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này GẦN TRÙNG với #17928 trong cùng lô.

Câu Bối cảnh Khoá
⚠ #17928 ⚠ tạo mô tả sản phẩm từ thông số ⚠ Generative AI
⚠ #17931 (câu này) ⚠ tạo email cá nhân hoá từ lịch sử mua hàng ⚠ Generative AI
⚠ Cùng mẫu câu hỏi ⚠ "tạo nội dung MỚI" ⇒ luôn là Generative AI

Vì sao đúng

⚠ Ba dấu hiệu trong đề: | Dấu hiệu | Kết luận | |---|---| | ⚠ "tạo nội dung email" | ⚠ SINH ra văn bản mới | | ⚠ "độc đáo cho từng khách hàng" | ⚠ mỗi lần sinh một kết quả khác | | ⚠ "giữ giọng điệu thương hiệu" | ⚠ điều khiển bằng system message và ví dụ mẫu |

⚠ Lịch sử mua hàng + sở thích
        ↓ ⚠ đưa vào prompt
⚠ Mô hình sinh ngữ
        ↓
⚠ Email riêng cho từng người
   ⚠ giữ giọng điệu chung của thương hiệu

Vì sao các phương án khác sai

  • B (classification) — ⚠ gán nhãn cho thứ có sẵn: ⚠ ví dụ phân khách vào nhóm; ⚠ đó có thể là bước chuẩn bị, không phải việc sinh nội dung.

  • C (computer vision) — ⚠ xử lý ảnh.

  • D (anomaly detection) — ⚠ phát hiện bất thường.

Ghi nhớ

⚠ Nhận diện loại workload — quy tắc chung: | Đề nói | Loại | |---|---| | ⚠ "tạo ra, viết, sinh, soạn" | ⚠ Generative AI | | ⚠ "phân loại, gán nhãn, xác định thuộc loại nào" | ⚠ Classification | | ⚠ "dự đoán con số, ước lượng giá trị" | ⚠ Regression | | ⚠ "nhóm lại, phân khúc" | ⚠ Clustering | | ⚠ "phát hiện bất thường" | ⚠ Anomaly detection | | ⚠ "nhận diện trong ảnh" | ⚠ Computer vision |

Từ khoá nhận diện:

"cá nhân hoá nội dung cho từng người" → ⚠ Generative AI "phân khách thành nhóm" → ⚠ clustering hoặc classification "gợi ý sản phẩm" → ⚠ hệ gợi ý — không phải sinh ngữ

⚠ Kiến trúc cá nhân hoá email thực tế Kiến trúc
⚠ 1. Phân khúc khách hàng ⚠ clustering hoặc luật nghiệp vụ
⚠ 2. Lấy dữ liệu liên quan cho từng người
⚠ 3. Đưa vào prompt cùng system message
⚠ 4. Sinh nội dung
⚠ 5. Kiểm duyệt và rà soát
⚠ Kết hợp nhiều loại AI ⚠ thực tế hiếm khi chỉ dùng một
⚠ Giữ giọng điệu thương hiệu — cách làm Cách
⚠ System message mô tả giọng điệu rõ ràng
⚠ Đưa 3-5 ví dụ email mẫu ⚠ few-shot prompting — hiệu quả nhất
⚠ Đặt temperature vừa phải
⚠ Có checklist rà soát trước khi gửi
⚠ Với quy mô lớn ⚠ cân nhắc fine-tune mô hình trên email cũ của công ty
⚠ Rủi ro khi gửi email do AI sinh hàng loạt Rủi ro
⚠ Bịa thông tin về đơn hàng hoặc khuyến mãi
⚠ Xưng hô sai
⚠ Giọng điệu lệch với thương hiệu
⚠ Một lỗi nhân lên hàng nghìn lần
⚠ Bắt buộc ⚠ kiểm tra mẫu ngẫu nhiên trước mỗi chiến dịch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã kiểm tra mẫu ngẫu nhiên chưa | | | Có bịa thông tin khuyến mãi không | | | Giọng điệu có nhất quán không | |

Và điều làm rủi ro của AI sinh ngữ khác hẳn AI phân tích: sai sót được nhân lên theo quy mô. Một mô hình phân loại sai một khách hàng là một lỗi nhỏ; một prompt sai gửi đi năm mươi nghìn email là một sự cố thương hiệu.

Câu 18
A retail company wants to digitize thousands of historical paper invoices stored in their archives. They need to extract invoice numbers, dates, vendor names, and total amounts from these documents to populate a searchable database. Which Azure AI service feature would be most appropriate for this scenario?
  1. A Azure AI Vision's Face API to identify and verify persons in the documents
  2. B Azure AI Document Intelligence (Form Recognizer) with prebuilt invoice models
  3. C Azure AI Custom Vision to classify invoices into different categories
  4. D Azure AI Vision's Image Analysis API to detect objects and generate image captions
Xem giải thích

Đáp án

B — Azure AI Document Intelligence (Form Recognizer) với mô hình hoá đơn dựng sẵn.

Vì sao đúng

⚠ Document Intelligence có sẵn mô hình cho HOÁ ĐƠN: | Trường trích được | Có sẵn | |---|---| | ⚠ InvoiceId | ⚠ số hoá đơn | | ⚠ InvoiceDate | ⚠ ngày | | ⚠ VendorName | ⚠ tên nhà cung cấp | | ⚠ InvoiceTotal | ⚠ tổng tiền | | ⚠ Items | ⚠ từng dòng hàng |

⚠ Đề cần đúng bốn trường
   ⚠ số hoá đơn, ngày, nhà cung cấp, tổng tiền
        ↓
⚠ Mô hình prebuilt-invoice
   ⚠ trích SẴN cả bốn
        ↓
⚠ KHÔNG cần huấn luyện gì

⚠ Tên cũ là Form Recognizer — ⚠ đề ghi cả hai tên.

Vì sao các phương án khác sai

  • D (Image Analysis API phát hiện đối tượng và sinh chú thích) — ⚠ mô tả ảnh nói chung: ⚠ không trích trường có cấu trúc.

  • C (Custom Vision phân loại hoá đơn thành các danh mục) — ⚠ chỉ PHÂN LOẠI ảnh: ⚠ không trích dữ liệu ra.

  • A (Face API để nhận diện người trong tài liệu) — ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Mô hình dựng sẵn của Document Intelligence: | Mô hình | Tài liệu | |---|---| | ⚠ prebuilt-invoice | ⚠ hoá đơn — đề này | | ⚠ prebuilt-receipt | ⚠ biên lai | | ⚠ prebuilt-idDocument | ⚠ CMND, hộ chiếu, bằng lái | | ⚠ prebuilt-businessCard | ⚠ danh thiếp | | ⚠ prebuilt-tax.us.w2 | ⚠ biểu mẫu thuế Mỹ | | ⚠ prebuilt-contract | ⚠ hợp đồng | | ⚠ prebuilt-healthInsuranceCard.us | | | ⚠ prebuilt-layout | ⚠ cấu trúc chung: bảng, đoạn | | ⚠ prebuilt-read | ⚠ OCR thuần |

Từ khoá nhận diện:

"hoá đơn, biên lai, CMND" → ⚠ prebuilt model tương ứng "biểu mẫu riêng của công ty" → ⚠ custom model "chỉ cần lấy chữ" → ⚠ Read OCR "chỉ cần bảng và cấu trúc" → ⚠ Layout model

⚠ Vì sao dùng prebuilt thay vì custom Lý do
⚠ KHÔNG cần dữ liệu huấn luyện
⚠ Dùng được NGAY
⚠ Hoạt động với nhiều mẫu hoá đơn khác nhau ⚠ quan trọng với hồ sơ lịch sử từ nhiều nhà cung cấp
⚠ Được Microsoft cập nhật liên tục
⚠ Chỉ cần custom khi ⚠ biểu mẫu rất đặc thù mà prebuilt không nhận
⚠ Số hoá tài liệu lịch sử — thách thức Thách thức
⚠ Chất lượng quét kém ⚠ giấy cũ, mờ, nghiêng
⚠ Nhiều mẫu hoá đơn khác nhau qua các năm
⚠ Chữ viết tay bổ sung trên hoá đơn
⚠ Khối lượng rất lớn
⚠ Vì vậy ⚠ prebuilt model linh hoạt hơn custom cho ca dùng này
⚠ Quy trình xử lý hàng loạt Quy trình
⚠ Quét vào Blob Storage
⚠ Xử lý theo lô, không từng file một
⚠ Kiểm tra confidence từng trường
⚠ Thấp → hàng chờ người xác nhận
⚠ Ghi cả bản gốc lẫn dữ liệu trích ra ⚠ để đối chiếu về sau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Prebuilt model có nhận đúng mẫu hoá đơn cũ không | ⚠ thử với mẫu thật trước | | Ngưỡng confidence đặt bao nhiêu | | | Có giữ bản quét gốc không | ⚠ cần cho đối chiếu và kiểm toán |

Và việc luôn nên làm trước một dự án số hoá tài liệu quy mô lớn: thử mô hình dựng sẵn với vài chục mẫu thật trước khi cam kết. Nếu prebuilt đã đủ tốt, bạn tiết kiệm được toàn bộ công sức huấn luyện mô hình riêng.

Câu 19
A company wants to develop a customer support chatbot that can answer product-related questions using information from their existing documentation. The chatbot should provide responses based on the company's specific product manuals rather than general internet knowledge. Which Azure OpenAI feature would be most appropriate for this scenario?
  1. A Use GPT-4 with system messages to instruct the model to only answer product questions.
  2. B Use DALL-E to generate visual responses from the product documentation.
  3. C Use the Whisper model to convert the documentation into audio format.
  4. D Use Azure OpenAI with Retrieval Augmented Generation (RAG) to ground responses in the company's documentation.
Xem giải thích

Đáp án

D — Dùng Azure OpenAI với Retrieval Augmented Generation (RAG) để neo câu trả lời vào tài liệu của công ty.

Vì sao đúng

⚠ RAG giải đúng bài toán đề nêu: trả lời DỰA TRÊN tài liệu riêng, không phải kiến thức Internet chung.

⚠ Người dùng hỏi
        ↓
⚠ TÌM KIẾM trong tài liệu công ty
   ⚠ (Azure AI Search)
        ↓
⚠ Lấy đoạn liên quan nhất
        ↓
⚠ Đưa vào prompt CÙNG câu hỏi
        ↓
⚠ Mô hình trả lời DỰA TRÊN đoạn đó
        ↓
⚠ Trích dẫn được nguồn
Lợi ích của RAG Nội dung
⚠ Câu trả lời neo vào tài liệu THẬT ⚠ giảm mạnh hallucination
⚠ Cập nhật tài liệu là cập nhật câu trả lời ⚠ không cần huấn luyện lại
⚠ Trích dẫn được nguồn
⚠ Rẻ hơn fine-tune rất nhiều

Vì sao các phương án khác sai

  • A (dùng GPT-4 với system message yêu cầu chỉ trả lời về sản phẩm) — ⚠ bẫy gần nhất: ⚠ system message ⚠ giới hạn PHẠM VI nhưng ⚠ không cung cấp NỘI DUNG; ⚠ mô hình vẫn trả lời từ kiến thức chung và ⚠ vẫn bịa.

  • B (dùng DALL·E sinh phản hồi hình ảnh) — ⚠ DALL·E sinh ẢNH: ⚠ không liên quan.

  • C (dùng Whisper chuyển tài liệu thành âm thanh) — ⚠ Whisper là speech-to-text: ⚠ chuyển ÂM THANH thành CHỮ, không phải ngược lại; ⚠ và hoàn toàn lạc đề.

Ghi nhớ

⚠ Ba cách đưa kiến thức riêng vào mô hình — bảng phải thuộc: | Cách | Chi phí | Khi nào | |---|---|---| | ⚠ Prompt engineering | ⚠ rẻ nhất | ⚠ ít thông tin, đưa thẳng vào prompt | | ⚠ RAG | ⚠ trung bình | ⚠ nhiều tài liệu, cập nhật thường xuyên — ĐỀ NÀY | | ⚠ Fine-tuning | ⚠ đắt nhất | ⚠ dạy PHONG CÁCH hoặc định dạng, không phải kiến thức |

Từ khoá nhận diện:

"trả lời dựa trên tài liệu riêng" → ⚠ RAG "dạy mô hình phong cách trả lời" → ⚠ fine-tuning "giới hạn phạm vi" → ⚠ system message — nhưng KHÔNG đủ "tài liệu thay đổi thường xuyên" → ⚠ RAG, vì không cần huấn luyện lại

⚠ Kiến trúc RAG trên Azure Thành phần
⚠ Tài liệu → Blob Storage
⚠ Chia nhỏ (chunking) và tạo embedding
⚠ Azure AI Search làm kho vector
⚠ Azure OpenAI sinh câu trả lời
⚠ Azure AI Foundry để dựng và đánh giá
⚠ Có tính năng ⚠ "Azure OpenAI On Your Data" — dựng RAG nhanh
⚠ Yếu tố quyết định chất lượng RAG Yếu tố
⚠ CHIA NHỎ tài liệu thế nào ⚠ quan trọng nhất — đoạn quá dài hay quá ngắn đều tệ
⚠ Chất lượng tìm kiếm ⚠ kết hợp vector và từ khoá (hybrid)
⚠ Số đoạn đưa vào prompt
⚠ Prompt yêu cầu chỉ dùng thông tin được cung cấp
⚠ Sai lầm phổ biến ⚠ đổ lỗi cho mô hình trong khi vấn đề nằm ở khâu TÌM KIẾM
⚠ Vì sao fine-tuning KHÔNG hợp cho kiến thức Lý do
⚠ Fine-tune dạy PHONG CÁCH, không nhồi được sự thật
⚠ Tài liệu đổi là phải huấn luyện lại ⚠ rất tốn
⚠ Không trích dẫn được nguồn
⚠ Vẫn có thể bịa
⚠ Fine-tune hợp khi ⚠ cần định dạng đầu ra nhất quán hoặc giọng điệu đặc thù

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khâu tìm kiếm có trả về đúng đoạn không | ⚠ kiểm tra riêng phần này | | Câu trả lời có trích dẫn nguồn không | | | Mô hình có nói "không tìm thấy" khi tài liệu không có không | |

Và nơi phần lớn hệ thống RAG thất bại, trái với những gì người ta nghĩ: không phải ở mô hình sinh ngữ mà ở khâu tìm kiếm. Nếu đoạn tài liệu lấy ra sai, mô hình dù giỏi tới đâu cũng chỉ có thể trả lời sai một cách trôi chảy.

Câu 20
Your data science team has trained multiple versions of a customer churn prediction model in Azure Machine Learning. The team needs to track which version performs best in production and be able to quickly switch between model versions if issues arise. Which Azure Machine Learning capability should you recommend?
  1. A Use Azure DevOps to version control only the training scripts, then retrain the model from scratch whenever a change is needed in production.
  2. B Store each model file in Azure Blob Storage and manually copy the best performing model to the production application server when needed.
  3. C Use Azure Machine Learning model registry to register each model version, then deploy the selected version to an endpoint with the ability to update the deployment to different versions.
  4. D Create separate Azure Machine Learning workspaces for each model version to isolate them completely.
Xem giải thích

Đáp án

C — Dùng model registry của Azure Machine Learning để đăng ký từng phiên bản mô hình, rồi triển khai phiên bản được chọn lên endpoint với khả năng cập nhật.

Vì sao đúng

⚠ Đề nêu hai nhu cầu, model registry đáp ứng cả hai: | Nhu cầu | Model registry | |---|---| | ⚠ Theo dõi phiên bản nào chạy tốt nhất | ⚠ lưu metadata, chỉ số, nguồn gốc từng phiên bản | | ⚠ ĐỔI NHANH giữa các phiên bản khi có sự cố | ⚠ cập nhật deployment trỏ sang phiên bản khác |

⚠ Model registry
   ├── ⚠ churn-model:1 — accuracy 0.82
   ├── ⚠ churn-model:2 — accuracy 0.85
   └── ⚠ churn-model:3 — accuracy 0.87 ← đang chạy
        ↓ ⚠ phiên bản 3 gặp vấn đề
⚠ Cập nhật endpoint trỏ về :2
        ↓
⚠ Quay lui trong VÀI PHÚT

⚠ Managed endpoint còn hỗ trợ triển khai xanh-lam (blue-green): ⚠ chia lưu lượng giữa hai phiên bản.

Vì sao các phương án khác sai

  • B (lưu file mô hình vào Blob Storage rồi chép tay lên máy chủ) — ⚠ hoàn toàn thủ công: ⚠ dễ sai, ⚠ không có metadata, ⚠ không truy vết được.

  • A (chỉ quản phiên bản SCRIPT, huấn luyện lại mỗi khi cần đổi) — ⚠ huấn luyện lại mất hàng giờ: ⚠ không đáp ứng "đổi NHANH khi có sự cố"; ⚠ và ⚠ không đảm bảo ra đúng mô hình cũ.

  • D (tạo workspace riêng cho từng phiên bản) — ⚠ cực kỳ cồng kềnh: ⚠ mất hết khả năng so sánh, ⚠ chi phí quản trị lớn.

Ghi nhớ

⚠ Model registry lưu gì — bảng phải thuộc: | Thông tin | Nội dung | |---|---| | ⚠ File mô hình | ⚠ artifact | | ⚠ Số phiên bản | ⚠ tự tăng | | ⚠ Chỉ số hiệu năng | ⚠ accuracy, F1, AUC | | ⚠ Nguồn gốc (lineage) | ⚠ dữ liệu nào, mã nào, thí nghiệm nào tạo ra | | ⚠ Môi trường | ⚠ thư viện và phiên bản cần để chạy | | ⚠ Thẻ và mô tả | |

Từ khoá nhận diện:

"quản phiên bản mô hình, quay lui nhanh" → ⚠ model registry + endpoint "chép file thủ công" → ⚠ luôn là phương án sai "huấn luyện lại để quay lui" → ⚠ quá chậm "chia lưu lượng giữa hai phiên bản" → ⚠ blue-green / canary deployment

⚠ Triển khai an toàn với managed endpoint Cách
⚠ Một endpoint, NHIỀU deployment
⚠ Chia lưu lượng theo phần trăm ⚠ 90% bản cũ, 10% bản mới
⚠ Theo dõi chỉ số của bản mới
⚠ Tốt thì tăng dần lên 100%
⚠ Xấu thì trả về 0% ngay
⚠ Đây là ⚠ canary deployment — giảm rủi ro rất nhiều
⚠ Vì sao lineage quan trọng Lý do
⚠ Sáu tháng sau: "mô hình này huấn luyện bằng dữ liệu nào?"
⚠ Kiểm toán đòi chứng minh nguồn gốc
⚠ Dựng lại được kết quả
⚠ Điều tra khi mô hình hoạt động sai
⚠ Không có lineage ⚠ mô hình trở thành hộp đen không ai dám sửa
⚠ Theo dõi mô hình sau khi triển khai Theo dõi
⚠ Data drift ⚠ dữ liệu đầu vào đổi so với lúc huấn luyện
⚠ Prediction drift ⚠ phân bố dự đoán thay đổi
⚠ Chỉ số nghiệp vụ ⚠ quan trọng nhất — mô hình có tạo giá trị không
⚠ Azure ML có ⚠ Model Monitoring làm sẵn hai cái đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quay lui một phiên bản mất bao lâu | ⚠ nên tính bằng phút | | Có biết mô hình đang chạy huấn luyện từ dữ liệu nào không | | | Có theo dõi trôi dữ liệu không | |

Và câu hỏi kiểm tra mức trưởng thành MLOps của một tổ chức: quay lui về phiên bản mô hình trước mất bao lâu?. Nếu câu trả lời là "phải huấn luyện lại", thì quy trình đó chưa sẵn sàng cho sản xuất.