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

Đáp án

D — Features (đặc trưng) là các giá trị ĐẦU VÀO của mô hình học máy.

Vì sao đúng

⚠ Định nghĩa nền tảng của học máy có giám sát:

⚠ FEATURES (x)  →  ⚠ MÔ HÌNH  →  ⚠ LABEL (y)
   ⚠ đầu vào                        ⚠ đầu ra
   ⚠ diện tích                      ⚠ giá nhà
   ⚠ số phòng
   ⚠ vị trí

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

• A (Labels là giá trị đầu vào) — ⚠ NGƯỢC: ⚠ label là đầu ra.

• B (Features là giá trị đầu ra) — ⚠ NGƯỢC: ⚠ feature là đầu vào.

• C (Labels là giá trị ĐẦU RA) — ⚠ xem mục chất lượng câu hỏi bên dưới.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này có ⚠ HAI phương án đúng nhưng khoá chỉ đánh dấu một.

⚠ Đây là lỗi soạn đề, không phải chỗ bạn hiểu sai — ⚠ nắm chắc định nghĩa hai chiều là đủ.

⚠ Từ vựng nền tảng phải thuộc: | Từ | Nghĩa | |---|---| | ⚠ Feature | ⚠ biến đầu vào, cột dữ liệu | | ⚠ Label / Target | ⚠ biến đầu ra, thứ cần dự đoán | | ⚠ Observation / Row | ⚠ một mẫu dữ liệu | | ⚠ Feature engineering | ⚠ tạo đặc trưng mới từ dữ liệu thô | | ⚠ Feature selection | ⚠ chọn đặc trưng có ích, bỏ nhiễu |

Từ khoá nhận diện:

"đầu vào, thông tin ta có" → ⚠ feature "đầu ra, thứ cần dự đoán" → ⚠ label "dữ liệu KHÔNG có nhãn" → ⚠ học không giám sát, gom cụm "cột nào là kết quả" → ⚠ label column trong AutoML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột nào là label, cột nào là feature | | | Có cột nào chứa sẵn đáp án không | ⚠ rò rỉ dữ liệu | | Đặc trưng nào thực sự có ích | ⚠ xem feature importance |

Và cái bẫy tinh vi nhất khi chọn đặc trưng, làm mô hình đạt độ chính xác gần như hoàn hảo trên giấy: một cột vô tình chứa sẵn câu trả lời, ví dụ đưa "ngày huỷ hợp đồng" vào để dự đoán khách có huỷ hay không.

Đáp án

B — Chúng phân tích và diễn giải nội dung của ảnh.

Vì sao đúng

⚠ Phân loại ảnh nhận vào một ảnh và trả về LỚP mà ảnh đó thuộc về:

⚠ Ảnh vào
        ↓ ⚠ trích đặc trưng
⚠ Phân tích nội dung
        ↓
⚠ "Đây là ảnh MÈO — xác suất 0,94"

⚠ Điểm cốt lõi: ⚠ mô hình ⚠ hiểu nội dung ảnh nói về cái gì, ⚠ chứ không chỉ xử lý ảnh về mặt kỹ thuật.

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

• A (theo dõi chuyển động của vật thể) — ⚠ thuộc video tracking, ⚠ cần chuỗi khung hình, không phải một ảnh tĩnh.

• D (đổi kích thước hoặc định dạng ảnh) — ⚠ xử lý ảnh thuần tuý, ⚠ không có AI nào ở đây.

• C (gắn thẻ mô tả cho ảnh) — ⚠ xem mục chất lượng câu hỏi.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án C ⚠ gần đúng và dễ gây tranh cãi.

⚠ Bốn bài toán thị giác — phân biệt bằng ĐẦU RA: | Bài toán | Đầu ra | |---|---| | ⚠ Image classification | ⚠ MỘT nhãn cho CẢ ảnh | | ⚠ Object detection | ⚠ nhiều nhãn + BOUNDING BOX | | ⚠ Semantic segmentation | ⚠ nhãn cho TỪNG PIXEL | | ⚠ Image tagging | ⚠ danh sách thẻ mô tả | | ⚠ OCR | ⚠ chữ trong ảnh |

Từ khoá nhận diện:

"ảnh này là cái gì" → ⚠ phân loại ảnh "có bao nhiêu, ở ĐÂU trong ảnh" → ⚠ phát hiện đối tượng "theo dõi chuyển động" → ⚠ video, không phải phân loại ảnh "đổi cỡ, đổi định dạng" → ⚠ xử lý ảnh, không phải AI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần một nhãn hay nhiều nhãn | ⚠ multiclass hay multilabel | | Có cần biết vị trí trong ảnh không | ⚠ nếu có thì là object detection | | Ngưỡng tin cậy đặt bao nhiêu | |

Và câu hỏi tách bạch phân loại ảnh với phát hiện đối tượng chỉ trong một nhịp: bạn có cần biết vật đó nằm Ở ĐÂU trong ảnh không? Cần vị trí thì phải là phát hiện đối tượng, dù chỉ có một vật.

Đáp án

C — Phát hiện bất thường tìm ra các mẫu trong dữ liệu được coi là KHÁC THƯỜNG.

Vì sao đúng

⚠ Anomaly detection học "bình thường trông thế nào" rồi báo động khi có sai khác:

⚠ Dữ liệu lịch sử
        ↓
⚠ Mô hình học ngưỡng bình thường
        ↓ ⚠ điểm mới đi vào
⚠ Nằm ngoài vùng bình thường?
        ↓ CÓ
⚠ Cảnh báo bất thường

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

• B (dự đoán giá trị TƯƠNG LAI) — ⚠ đó là DỰ BÁO (forecasting), ⚠ một bài toán khác; ⚠ phát hiện bất thường xét ⚠ điểm hiện tại có lạ không.

• D (nhận dạng đối tượng trong ảnh) — ⚠ thuộc computer vision.

• A (không cần dữ liệu bên ngoài) — ⚠ vô nghĩa: ⚠ mọi mô hình đều cần dữ liệu lịch sử để biết thế nào là bình thường.

Ghi nhớ

⚠ Phân biệt ba bài toán dễ lẫn: | Bài toán | Câu hỏi | |---|---| | ⚠ Anomaly detection | ⚠ điểm này có LẠ không | | ⚠ Forecasting | ⚠ giá trị TƯƠNG LAI là bao nhiêu | | ⚠ Classification | ⚠ thuộc LOẠI nào trong các loại đã biết |

Từ khoá nhận diện:

"bất thường, lạ, ngoài dự kiến" → ⚠ anomaly detection "tháng sau bán được bao nhiêu" → ⚠ forecasting / regression "thư này có phải spam không" → ⚠ classification

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần phát hiện lạ hay dự báo tương lai | | | Tỉ lệ báo động giả bao nhiêu là chấp nhận được | | | Có đủ dữ liệu "bình thường" để học không | |

Và lý do phổ biến nhất khiến một hệ thống phát hiện bất thường bị bỏ xó dù mô hình vẫn chạy đúng: báo động giả quá nhiều, đến mức người trực ngừng nhìn cảnh báo. Sau đó cảnh báo thật cũng trôi qua không ai xử lý.

Đáp án

B — AI Search (Azure AI Search).

Vì sao đúng

⚠ Đề liệt kê đúng ba việc Azure AI Search làm trong một quy trình: | Việc đề nêu | AI Search làm bằng | |---|---| | ⚠ Đánh chỉ mục toàn văn | ⚠ index + indexer | | ⚠ Trích cụm từ nâng cao | ⚠ key phrase extraction skill | | ⚠ Phân tích cảm xúc | ⚠ sentiment skill |

⚠ Tài liệu thô
        ↓ ⚠ indexer
⚠ Skillset làm giàu
   ⚠ OCR + key phrase + sentiment + entity
        ↓
⚠ Chỉ mục tìm kiếm được

⚠ Điểm mấu chốt: ⚠ AI Search ⚠ gọi các dịch vụ AI khác thay bạn — ⚠ không cần tự nối từng API.

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

• A (Azure Machine Learning) — ⚠ để huấn luyện mô hình, ⚠ không phải nền tảng tìm kiếm; ⚠ có thể làm ⚠ custom skill trong skillset nhưng không thay thế được AI Search.

• C (Azure Synapse Analytics) — ⚠ phân tích dữ liệu lớn, không phải knowledge mining.

• D (Azure Stream Analytics) — ⚠ xử lý dòng dữ liệu thời gian thực, không đánh chỉ mục tài liệu.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #17999 ở đợt trước.

⚠ Bốn dịch vụ dữ liệu Azure hay bị đưa ra làm nhiễu: | Dịch vụ | Việc thật | |---|---| | ⚠ Azure AI Search | ⚠ đánh chỉ mục, tìm kiếm, làm giàu bằng AI | | ⚠ Azure Machine Learning | ⚠ huấn luyện và triển khai mô hình | | ⚠ Azure Synapse Analytics | ⚠ kho dữ liệu, phân tích quy mô lớn | | ⚠ Azure Stream Analytics | ⚠ xử lý dòng sự kiện thời gian thực |

Từ khoá nhận diện:

"chỉ mục toàn văn, tìm kiếm tài liệu" → ⚠ AI Search "dòng dữ liệu IoT theo thời gian thực" → ⚠ Stream Analytics "kho dữ liệu phân tích" → ⚠ Synapse "huấn luyện mô hình riêng" → ⚠ Azure ML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Skillset có chạy lại khi tài liệu đổi không | | | Chỉ mục có bật semantic ranker không | | | Chi phí gọi các skill AI là bao nhiêu | ⚠ tính theo lượt xử lý |

Và điều dễ bỏ qua khi thiết kế knowledge mining: chi phí không nằm ở tầng tìm kiếm mà ở tầng làm giàu. Mỗi lần chạy lại skillset trên toàn bộ kho tài liệu là một lần trả tiền cho toàn bộ lượt gọi AI.

Đáp án

D — Azure Bot Service đòi hỏi VIẾT MÃ, còn Power Virtual Agents dựng được bằng giao diện KHÔNG CẦN MÃ.

Vì sao đúng

⚠ Khác biệt căn bản là ĐỐI TƯỢNG NGƯỜI DÙNG: | Công cụ | Dành cho | Cách làm | |---|---|---| | ⚠ Power Virtual Agents | ⚠ người làm nghiệp vụ | ⚠ kéo-thả luồng hội thoại | | ⚠ Azure Bot Service | ⚠ lập trình viên | ⚠ Bot Framework SDK, C#/JavaScript/Python |

⚠ Power Virtual Agents
   ⚠ Chọn chủ đề → thêm câu kích hoạt
   ⚠ → vẽ nhánh hội thoại → xuất bản
        ⚠ KHÔNG viết mã

⚠ Azure Bot Service
   ⚠ Viết dialog, state, middleware
   ⚠ → triển khai → nối kênh
        ⚠ TOÀN QUYỀN kiểm soát

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

• C (PVA chỉ làm hội thoại theo luật đơn giản) — ⚠ SAI: ⚠ PVA có ⚠ generative answers đọc tài liệu và trả lời bằng AI sinh ngữ.

• B (PVA chỉ tích hợp được với Teams) — ⚠ SAI: ⚠ PVA xuất bản được lên web, Teams, Facebook và nhiều kênh khác.

• A (Bot Service có phân tích sẵn, PVA phải cấu hình thêm) — ⚠ NGƯỢC: ⚠ PVA có bảng phân tích tích hợp ngay trong cổng.

Ghi nhớ

⚠ Chọn công cụ chatbot: | Tình huống | Chọn | |---|---| | ⚠ Người nghiệp vụ tự dựng, ra nhanh | ⚠ Power Virtual Agents / Copilot Studio | | ⚠ Logic phức tạp, tích hợp hệ thống sâu | ⚠ Azure Bot Service + SDK | | ⚠ Hiểu ý định và trích thực thể | ⚠ CLU (dùng được ở cả hai) | | ⚠ Trả lời FAQ từ tài liệu | ⚠ Custom question answering | | ⚠ Điều phối nhiều mô hình | ⚠ Orchestration workflow |

Từ khoá nhận diện:

"không cần lập trình, người nghiệp vụ tự làm" → ⚠ Power Virtual Agents "toàn quyền, tích hợp sâu, viết mã" → ⚠ Bot Service "hiểu ý định người dùng" → ⚠ CLU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai sẽ bảo trì bot sau này | ⚠ quyết định chọn công cụ | | Có cần gọi hệ thống nội bộ phức tạp không | | | Bot có biết nói "tôi không hiểu" không | |

Và cách phối hợp thực tế nhất của hai công cụ này, thay vì chọn một: Copilot Studio lo phần lớn hội thoại thường gặp, và chuyển tiếp sang bot lập trình khi đụng nghiệp vụ phức tạp.

Đáp án

D — Bảo đảm giải pháp AI có thể GIẢI THÍCH được các quyết định của nó.

Vì sao đúng

⚠ Accountability (trách nhiệm giải trình) nghĩa là có người CHỊU TRÁCH NHIỆM và giải thích được:

⚠ AI ra quyết định
        ↓
⚠ Người bị ảnh hưởng hỏi "vì sao?"
        ↓
⚠ Phải có câu trả lời
        ↓ ⚠ nếu không
⚠ Không ai chịu trách nhiệm được

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

• A (nhiều lớp bảo mật) — ⚠ thuộc PRIVACY & SECURITY.

• C (bảo đảm kết quả chính xác) — ⚠ thuộc RELIABILITY & SAFETY.

• B (dùng AI để tối đa lợi nhuận) — ⚠ mục tiêu kinh doanh, không phải nguyên tắc AI có trách nhiệm.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #17972 và #17917 ở các đợt trước.

⚠ Sáu nguyên tắc AI có trách nhiệm — bảng phân biệt: | Nguyên tắc | Từ khoá quyết định | |---|---| | ⚠ Fairness | ⚠ thiên vị nhóm người | | ⚠ Reliability & Safety | ⚠ hoạt động ổn định, kiểm thử, giám sát | | ⚠ Privacy & Security | ⚠ bảo vệ dữ liệu | | ⚠ Inclusiveness | ⚠ mọi người dùng được, kể cả khuyết tật | | ⚠ Transparency | ⚠ NGƯỜI DÙNG HIỂU hệ thống làm gì | | ⚠ Accountability | ⚠ AI CHỊU TRÁCH NHIỆM, giải trình được |

Từ khoá nhận diện:

"ai chịu trách nhiệm, giải trình, kiểm toán" → ⚠ Accountability "người dùng hiểu, biết đang nói với AI" → ⚠ Transparency "nhóm người bị đối xử khác" → ⚠ Fairness

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai là chủ sở hữu hệ thống AI này | | | Quyết định có được ghi log để truy lại không | | | Người bị ảnh hưởng khiếu nại ở đâu | |

Và câu hỏi phân biệt một hệ thống AI có trách nhiệm giải trình với một hệ thống chỉ nói rằng mình có: khi nó ra quyết định sai gây thiệt hại, có tên một người cụ thể để trả lời không?

Đáp án

B — Nó trích được cụm từ khoá từ văn bản ở NHIỀU NGÔN NGỮ.

Vì sao đúng

⚠ Key phrase extraction là tính năng dựng sẵn của Azure AI Language: | Đặc điểm | Nội dung | |---|---| | ⚠ Đa ngôn ngữ | ⚠ hàng chục ngôn ngữ, có tiếng Việt | | ⚠ KHÔNG cần huấn luyện | ⚠ gọi API là dùng ngay | | ⚠ KHÔNG cần dữ liệu gán nhãn | | | ⚠ Tự nhận diện ý chính | ⚠ không dựa vào danh sách định sẵn |

⚠ "Dịch vụ giao hàng nhanh nhưng
   đóng gói sơ sài, hàng bị móp"
        ↓
⚠ Cụm từ khoá:
   ⚠ "dịch vụ giao hàng"
   ⚠ "đóng gói"
   ⚠ "hàng bị móp"

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

• C (chỉ nhận cụm từ ĐỊNH SẴN) — ⚠ SAI: ⚠ mô hình tự tìm ý chính, ⚠ không tra danh sách.

• A (chỉ hữu ích để nhận người và địa điểm) — ⚠ nhầm sang NER; ⚠ key phrase trích ⚠ cụm từ chủ đề, không phải thực thể.

• D (không tuỳ chỉnh được) — ⚠ đúng một phần nhưng không phải "tính năng chính"; ⚠ đề hỏi ⚠ tính năng then chốt, ⚠ và nêu một hạn chế không trả lời được câu hỏi đó.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #17981 và #17989.

⚠ Bốn tính năng phân tích văn bản dựng sẵn — phân biệt bằng ĐẦU RA: | Tính năng | Đầu ra | |---|---| | ⚠ Key phrase extraction | ⚠ danh sách CỤM TỪ chủ đề | | ⚠ NER | ⚠ thực thể có LOẠI: người, nơi, ngày | | ⚠ Sentiment analysis | ⚠ tích cực / tiêu cực / trung tính + điểm | | ⚠ Language detection | ⚠ mã ngôn ngữ + độ tin cậy |

Từ khoá nhận diện:

"ý chính, chủ đề chính của văn bản" → ⚠ key phrase "tên người, địa điểm, tổ chức" → ⚠ NER "khách hàng khen hay chê" → ⚠ sentiment "văn bản này tiếng gì" → ⚠ language detection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngôn ngữ cần dùng có được hỗ trợ không | | | Cần cụm chủ đề hay cần thực thể có loại | | | Có kết hợp với cảm xúc để tìm điểm đau không | |

Và cách khai thác key phrase extraction cho ra giá trị thật, thay vì chỉ có một đống từ khoá: ghép nó với phân tích cảm xúc để biết chủ đề nào đang bị phàn nàn nhiều nhất.

Đáp án

B — Tự động gán nhãn dữ liệu (Automatic data labeling).

Vì sao đúng

⚠ Đây là câu PHỦ ĐỊNH — tìm cái KHÔNG phải tính năng điển hình.

⚠ Giải pháp phân loại ảnh cần dữ liệu ĐÃ ĐƯỢC GÁN NHÃN từ trước — ⚠ đó là ⚠ đầu vào bạn phải chuẩn bị, ⚠ không phải thứ dịch vụ tự làm cho bạn.

⚠ Bạn: thu thập ảnh + GÁN NHÃN
        ↓
⚠ Dịch vụ: huấn luyện mô hình
        ↓
⚠ Mô hình: phân loại ảnh mới

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

• A, C, D — ⚠ đều tồn tại, nên không phải đáp án của câu phủ định.

Ghi nhớ

⚠ Gán nhãn dữ liệu — sự thật phải nhớ: | Sự thật | Nội dung | |---|---| | ⚠ Là việc TỐN CÔNG NHẤT của một dự án ML | | | ⚠ Phải do CON NGƯỜI làm | ⚠ hoặc ít nhất kiểm duyệt | | ⚠ Azure ML có công cụ HỖ TRỢ gán nhãn | ⚠ data labeling project | | ⚠ Có ML-assisted labeling | ⚠ gợi ý nhãn nhưng người vẫn duyệt | | ⚠ Không có | ⚠ cỗ máy tự gán nhãn hoàn toàn đúng |

Từ khoá nhận diện:

"tự động gán nhãn hoàn toàn" → ⚠ không tồn tại, thường là bẫy "mô hình dựng sẵn dùng ngay" → ⚠ AI Vision "huấn luyện nhãn riêng" → ⚠ Custom Vision, cần ảnh gán nhãn "dữ liệu KHÔNG có nhãn" → ⚠ học không giám sát, gom cụm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Câu hỏi có chữ NOT hay KHÔNG không | | | Ai sẽ gán nhãn và mất bao lâu | ⚠ thường là nút thắt của dự án | | Nhãn có nhất quán giữa người gán không | |

Và khoản chi phí bị đánh giá thấp nhất trong mọi dự án học máy, thường lớn hơn cả chi phí tính toán: công sức gán nhãn dữ liệu. Không dịch vụ nào làm thay bạn hoàn toàn phần đó.

Đáp án

D — Học máy tự động có thể dùng để CHỌN mô hình và siêu tham số tốt nhất cho một bài toán.

Vì sao đúng

⚠ AutoML thử nhiều tổ hợp rồi xếp hạng:

⚠ Nạp dữ liệu + chỉ ra cột LABEL
        ↓
⚠ AutoML tự động:
   ⚠ tiền xử lý và chuẩn hoá
   ⚠ thử nhiều THUẬT TOÁN
   ⚠ dò SIÊU THAM SỐ
   ⚠ đánh giá chéo
        ↓
⚠ Bảng xếp hạng, mô hình tốt nhất ở đầu

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

• B (chỉ dùng cho học CÓ GIÁM SÁT) — ⚠ nghe hợp lý nhưng vẫn không phải điều đề hỏi; ⚠ và AutoML còn làm ⚠ dự báo chuỗi thời gian, thị giác, NLP — ⚠ rộng hơn cách nói ở phương án này.

• A (không cần đầu vào hay chỉ dẫn nào từ nhà khoa học dữ liệu) — ⚠ SAI: ⚠ vẫn phải chọn dữ liệu, chỉ cột label, chọn chỉ số tối ưu và ⚠ diễn giải kết quả.

• C (chỉ chạy được nếu dữ liệu hoàn toàn sạch) — ⚠ SAI: ⚠ AutoML có bước ⚠ featurization tự động xử lý thiếu dữ liệu và mã hoá.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #17991.

⚠ AutoML — điều PHẢI làm và điều KHÔNG tự làm: | AutoML tự làm | Bạn vẫn phải làm | |---|---| | ⚠ Thử nhiều thuật toán | ⚠ chuẩn bị và hiểu dữ liệu | | ⚠ Dò siêu tham số | ⚠ chỉ đúng cột label | | ⚠ Featurization cơ bản | ⚠ chọn chỉ số tối ưu phù hợp | | ⚠ Đánh giá chéo | ⚠ kiểm tra rò rỉ dữ liệu | | ⚠ Xếp hạng kết quả | ⚠ quyết định có triển khai không |

Từ khoá nhận diện:

"tự thử nhiều thuật toán, chọn tốt nhất" → ⚠ AutoML "kéo thả không cần code" → ⚠ Designer "không cần con người can thiệp gì" → ⚠ luôn là phương án SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số tối ưu đã chọn có đúng mục tiêu nghiệp vụ không | | | Có cột nào rò rỉ đáp án không | | | Mô hình đứng đầu có giải thích được không | |

Và cách một dự án AutoML thất bại dù bảng xếp hạng rất đẹp: chọn nhầm chỉ số tối ưu. AutoML sẽ tận tuỵ tìm mô hình tốt nhất cho đúng chỉ số bạn đã chỉ, kể cả khi chỉ số đó không phản ánh điều bạn thật sự cần.

Đáp án

A — Chúng có khả năng phân tích cảm xúc trên khuôn mặt và nhận diện từng cá nhân với độ chính xác cao.

Vì sao đúng

⚠ Theo khoá của bộ đề, đây là phương án mô tả đầy đủ nhất hai nhóm năng lực: | Nhóm | Nội dung | |---|---| | ⚠ Facial DETECTION | ⚠ tìm khuôn mặt và vị trí trong ảnh | | ⚠ Facial ANALYSIS | ⚠ phân tích thuộc tính khuôn mặt | | ⚠ Facial RECOGNITION | ⚠ so khớp danh tính |

⚠ Ba phương án còn lại đều nêu một GIỚI HẠN không đúng, ⚠ nên bộ đề chọn A.

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

• B (chỉ phát hiện được mặt nhìn thẳng vào máy ảnh) — ⚠ SAI: ⚠ phát hiện được ở ⚠ nhiều góc nghiêng.

• C (nhận diện chính xác nhưng KHÔNG phân biệt được cảm xúc) — ⚠ theo mô tả cũ của dịch vụ là sai.

• D (phát hiện nhiều góc nhưng KHÔNG nhận diện được cá nhân) — ⚠ SAI: ⚠ Face API ⚠ có nhận diện danh tính (Identify) khi đã đăng ký PersonGroup.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ khoá A ⚠ không còn đúng với dịch vụ hiện tại.

⚠ Face API sau 2022 — CÒN và ĐÃ GỠ: | CÒN | ĐÃ GỠ | |---|---| | ⚠ Phát hiện mặt + bounding box | ⚠ cảm xúc | | ⚠ Mốc khuôn mặt (landmark) | ⚠ tuổi | | ⚠ Kính, che mặt, mờ, nhiễu | ⚠ giới tính | | ⚠ Head pose | ⚠ nụ cười, trang điểm, tóc | | ⚠ Liveness (chống ảnh giả) | | | ⚠ Verify / Identify | ⚠ cần được DUYỆT mới dùng |

Từ khoá nhận diện:

"đếm số người, che mặt để bảo mật" → ⚠ Face detection, dùng tự do "nhận ra ĐÂY LÀ AI" → ⚠ Face recognition, Limited Access "đoán tuổi, giới tính, cảm xúc" → ⚠ ĐÃ GỠ — cảnh giác trong đề cũ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tính năng đề nhắc có còn tồn tại không | ⚠ đề cũ hay lỗi thời | | Có cần đăng ký Limited Access không | | | Có cơ sở pháp lý để xử lý dữ liệu sinh trắc không | |

Và điều bộ đề này chưa cập nhật, đáng nhớ hơn cả bản thân câu hỏi: Microsoft đã tự gỡ một tính năng đang bán được vì lý do đạo đức. Đó là minh hoạ cụ thể nhất cho sáu nguyên tắc AI có trách nhiệm mà kỳ thi bắt bạn học thuộc.