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

Đáp án

C — Azure Machine Learning hỗ trợ TRIỂN KHAI mô hình thành DỊCH VỤ WEB.

Vì sao đúng

⚠ Triển khai là bước biến mô hình thành thứ dùng được:

⚠ Mô hình đã huấn luyện
        ↓ ⚠ đăng ký vào registry
⚠ Tạo endpoint
        ↓
⚠ REST API có URL và khoá
        ↓
⚠ Ứng dụng gọi và nhận dự đoán

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

• A (không quản lý phiên bản mô hình) — ⚠ SAI: ⚠ model registry ⚠ đánh phiên bản tự động.

• B (chỉ triển khai được mô hình huấn luyện TRÊN Azure) — ⚠ SAI: ⚠ đăng ký và triển khai được mô hình huấn luyện ở nơi khác.

• D (phải cấu hình co giãn THỦ CÔNG) — ⚠ SAI: ⚠ managed endpoint có ⚠ tự co giãn.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #17994 ở đợt trước — ⚠ #17994 hỏi nơi lưu mô hình đã huấn luyện (model registry), ⚠ câu này hỏi tính năng triển khai; ⚠ hai bước liên tiếp của cùng quy trình.

⚠ Vòng đời MLOps trong Azure ML: | Bước | Nội dung | |---|---| | ⚠ Chuẩn bị dữ liệu | ⚠ data asset | | ⚠ Huấn luyện | ⚠ job trên compute cluster | | ⚠ Đăng ký mô hình | ⚠ registry, có phiên bản | | ⚠ Triển khai | ⚠ endpoint | | ⚠ Giám sát | ⚠ drift, hiệu năng | | ⚠ Huấn luyện lại | ⚠ pipeline tự động |

Từ khoá nhận diện:

"gọi từ ứng dụng, trả kết quả ngay" → ⚠ online endpoint "chấm điểm hàng triệu bản ghi qua đêm" → ⚠ batch endpoint "quản lý phiên bản mô hình" → ⚠ model registry "chạy trên thiết bị không có mạng" → ⚠ triển khai ra biên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần dự đoán ngay hay theo lô | | | Có kế hoạch quay lui khi mô hình mới tệ hơn không | | | Môi trường triển khai có khớp môi trường huấn luyện không | |

Và nguyên nhân phổ biến nhất khiến một mô hình chạy tốt trong notebook mà hỏng ngay khi triển khai: môi trường thư viện khác nhau. Ghim phiên bản môi trường ngay từ lúc huấn luyện là cách rẻ nhất để tránh cả một buổi chiều gỡ lỗi.

Đáp án

B — Giám sát các chỉ số ĐA CHIỀU và phát hiện bất thường.

Vì sao đúng

⚠ Metrics Advisor sinh ra cho dữ liệu chỉ số có nhiều chiều:

⚠ Doanh thu
   ⚠ chia theo VÙNG × SẢN PHẨM × KÊNH
        ↓
⚠ Hàng nghìn chuỗi số cùng lúc
        ↓ ⚠ Metrics Advisor
⚠ Phát hiện chuỗi nào bất thường
⚠ Gom cảnh báo liên quan lại
⚠ Chỉ ra chiều nào gây ra vấn đề

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

• C (triển khai và quản lý mô hình) — ⚠ Azure Machine Learning.

• D (tìm kiếm dạng dịch vụ) — ⚠ Azure AI Search.

• A (tự dựng chatbot) — ⚠ Bot Service hoặc Copilot Studio.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ dịch vụ trong khoá ⚠ đã thông báo ngừng hoạt động.

⚠ Ba dịch vụ giám sát bất thường của Azure — phân biệt: | Dịch vụ | Phạm vi | |---|---| | ⚠ Anomaly Detector | ⚠ MỘT chuỗi thời gian, API đơn giản | | ⚠ Metrics Advisor | ⚠ NHIỀU chiều, có quản lý cảnh báo | | ⚠ Azure Monitor | ⚠ giám sát hạ tầng và ứng dụng |

Từ khoá nhận diện:

"chỉ số đa chiều, phân tích nguyên nhân gốc" → ⚠ Metrics Advisor "một chuỗi số, phát hiện điểm lạ" → ⚠ Anomaly Detector "CPU, bộ nhớ, log ứng dụng" → ⚠ Azure Monitor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dịch vụ trong đề còn được hỗ trợ không | | | Cần một chuỗi hay nhiều chiều | | | Ai nhận cảnh báo và xử lý thế nào | |

Và điều đáng rút ra khi một dịch vụ đám mây bị khai tử giữa vòng đời sản phẩm: phần khó thay thế không phải lời gọi API mà là quy trình cảnh báo và con người đã quen với nó. Tách hai lớp đó ra từ đầu giúp việc chuyển đổi rẻ hơn nhiều.

Đáp án

D — Endpoint Detection and Response (EDR)

Vì sao đúng

EDR dựng riêng để phát hiện tấn công tinh vi trên chính máy chủ: nó theo dõi liên tục hành vi của tiến trình, lời gọi hệ thống và kết nối mạng, rồi nhận ra chuỗi hành vi đáng ngờ mà từng hành động riêng lẻ trông vẫn bình thường. Đó là loại tấn công mà chữ ký virus truyền thống không bắt được.

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

• B. Threat Prevention — ngăn chặn mối đe doạ đã biết trước khi chúng chạy; không phát hiện được thứ chưa có chữ ký.
• A. Automated Investigation and Response — chạy sau khi đã phát hiện, để điều tra và xử lý.
• C. Secure Score — chấm điểm tư thế bảo mật, mang tính đánh giá chứ không phát hiện tấn công đang diễn ra.

Đáp án

D — Dự đoán doanh số của một cửa hàng bán lẻ trong quý tới.

Vì sao đúng

⚠ Doanh số là con số liên tục — hồi quy:

⚠ Đặc trưng
   ⚠ doanh số các quý trước
   ⚠ mùa vụ, khuyến mãi, số cửa hàng
        ↓
⚠ 4,7 tỷ đồng
        ↓
⚠ CON SỐ → hồi quy

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

• B (email có phải spam không) — ⚠ phân loại nhị phân.

• C (phân loại ảnh mèo và chó) — ⚠ phân loại ảnh.

• A (xác định cảm xúc của một đánh giá) — ⚠ phân loại vào tích cực / tiêu cực / trung tính.

⚠ Cả ba đều cho ra NHÃN, không phải số.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư cùng một khuôn trong đợt này.

⚠ Bảng đầu ra — học một lần dùng cho cả nhóm: | Ví dụ trong bộ đề | Bài toán | |---|---| | ⚠ Doanh số quý tới | ⚠ regression | | ⚠ Giá cổ phiếu | ⚠ regression | | ⚠ Email có phải spam | ⚠ classification | | ⚠ Ảnh mèo hay chó | ⚠ classification | | ⚠ Cảm xúc đánh giá | ⚠ classification | | ⚠ Nhóm khách theo hành vi mua | ⚠ clustering | | ⚠ Giao dịch bất thường | ⚠ anomaly detection |

Từ khoá nhận diện:

"bao nhiêu tiền, bao nhiêu đơn" → ⚠ regression "có phải, thuộc loại nào" → ⚠ classification "tự chia nhóm" → ⚠ clustering "quý tới, tháng tới" → ⚠ forecasting, một dạng hồi quy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đầu ra là số hay nhãn | | | Đã có mốc so sánh đơn giản chưa | | | Đặc trưng mùa vụ đã đưa vào chưa | |

Và bước đầu tiên nên làm trước mọi mô hình dự báo, thường bị bỏ qua vì trông quá đơn giản: dựng một mốc so sánh ngây thơ như lấy số cùng kỳ năm trước. Không thắng được nó thì mô hình phức tạp chỉ tạo thêm việc bảo trì.

Đáp án

D — Object detection xác định VỊ TRÍ của các vật trong ảnh, còn object recognition xác định LOẠI của chúng.

Vì sao đúng

⚠ Theo cách phân chia mà bộ đề dùng: | Thuật ngữ | Trả lời câu hỏi | |---|---| | ⚠ Detection | ⚠ Ở ĐÂU — hộp bao, toạ độ | | ⚠ Recognition | ⚠ LÀ GÌ — nhãn của vật |

⚠ Ảnh vào
        ↓ ⚠ DETECTION
⚠ "Có vật tại (120, 80, 200, 180)"
        ↓ ⚠ RECOGNITION
⚠ "Vật đó là con mèo"

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

• C — ⚠ đảo ngược hai vế; ⚠ bẫy đối xứng, đọc lướt rất dễ chọn.

• B (hai thuật ngữ dùng thay nhau được) — ⚠ SAI: ⚠ chúng trả lời hai câu hỏi khác nhau.

• A (không dùng trong thị giác máy tính) — ⚠ SAI rõ ràng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ ranh giới này ⚠ không thống nhất trong tài liệu ngành.

⚠ Thuật ngữ thị giác — bảng an toàn cho đề thi: | Thuật ngữ | Trong đề này | |---|---| | ⚠ Image classification | ⚠ một nhãn cho cả ảnh | | ⚠ Object detection | ⚠ vị trí, hộp bao | | ⚠ Object recognition | ⚠ loại của vật | | ⚠ Segmentation | ⚠ từng pixel | | ⚠ Facial recognition | ⚠ danh tính người |

Từ khoá nhận diện:

"ở đâu, toạ độ, hộp bao" → ⚠ detection "là gì, loại nào" → ⚠ recognition / classification "đường viền chính xác" → ⚠ segmentation "là AI" → ⚠ facial recognition

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề hỏi vị trí hay loại | | | Phương án có bị đảo vế không | ⚠ đọc kỹ cả hai vế | | Trong thực tế cần cả hai không | |

Và dạng câu hỏi lặp đi lặp lại trong bộ đề này, đáng luyện riêng: "khác biệt chính giữa A và B" luôn kèm một phương án đảo ngược hai vế. Xác định đúng vế trước khi đọc phương án là cách tránh bẫy chắc chắn nhất.

Đáp án

B — Kiểm tra dữ liệu định kỳ để phát hiện và xử lý thiên lệch trong dữ liệu huấn luyện

Vì sao đúng

Thiên lệch của mô hình gần như luôn bắt nguồn từ dữ liệu huấn luyện, nên đó là chỗ phải xử lý. Rà soát định kỳ là cần thiết vì thiên lệch không tĩnh: dữ liệu mới được thêm vào, phân bố người dùng thay đổi, và mô hình được huấn luyện lại — mỗi lần đều có thể sinh ra thiên lệch mới.

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

• A. Bỏ qua thông tin nhân khẩu để đảm bảo không thiên lệch — đây là hiểu nhầm phổ biến và nguy hiểm: bỏ trường "giới tính" không xoá được thiên lệch, vì mô hình vẫn suy ra được nó từ các trường tương quan. Tệ hơn, bỏ trường đi thì bạn mất luôn khả năng đo xem mô hình có đối xử khác nhau giữa các nhóm hay không.
• C. Tối ưu tốc độ và hiệu năng — không liên quan tới công bằng.
• D. Ưu tiên nội dung sáng tạo hơn độ chính xác — đánh đổi sai hướng.

Đáp án

D — Phân tích cảm xúc xác định CẢM XÚC TỔNG THỂ của văn bản, còn trích cụm từ khoá xác định các CỤM TỪ QUAN TRỌNG NHẤT.

Vì sao đúng

⚠ Hai tính năng, hai câu hỏi khác nhau:

⚠ "Giao hàng nhanh nhưng đóng gói tệ,
   hộp móp hết cả"

⚠ SENTIMENT
   ⚠ Tổng thể: tiêu cực (0,72)

⚠ KEY PHRASE
   ⚠ "giao hàng", "đóng gói", "hộp móp"

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

• C — ⚠ đảo ngược hai vế; ⚠ đây là bẫy chính của câu.

• B (hai thuật ngữ như nhau) — ⚠ SAI.

• A (không dùng trong NLP) — ⚠ SAI rõ ràng: ⚠ cả hai đều là tính năng lõi của AI Language.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là ⚠ dạng "đảo vế" thứ ba trong đợt.

⚠ Bốn tính năng AI Language — trả lời bốn câu hỏi: | Tính năng | Câu hỏi | |---|---| | ⚠ Sentiment analysis | ⚠ cảm thấy thế nào | | ⚠ Key phrase extraction | ⚠ nói về cái gì | | ⚠ NER | ⚠ nhắc tới ai, nơi nào | | ⚠ Summarization | ⚠ rút gọn lại là gì |

Từ khoá nhận diện:

"tích cực hay tiêu cực" → ⚠ sentiment "chủ đề, ý chính" → ⚠ key phrase "tên riêng có phân loại" → ⚠ NER "tóm tắt" → ⚠ summarization

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đọc kỹ cả hai vế của phương án không | | | Cần biết thái độ hay biết chủ đề | | | Có ghép nhiều tính năng để ra thông tin hành động được không | |

Và chiến thuật xử lý dạng câu "khác biệt giữa A và B" nhanh và chắc nhất: loại ngay hai phương án nói "giống nhau" và "không liên quan", rồi chỉ cần phân biệt cặp còn lại — trong đó một cái chắc chắn bị đảo vế.

Đáp án

A — Tạo DỮ LIỆU TỔNG HỢP chân thực để huấn luyện mô hình.

Vì sao đúng

⚠ Sinh dữ liệu tổng hợp là ứng dụng thực tế của AI sinh ngữ:

⚠ Dữ liệu thật
   ⚠ hiếm, đắt, hoặc NHẠY CẢM
        ↓ ⚠ mô hình sinh ngữ
⚠ Dữ liệu giả nhưng CÓ CÙNG ĐẶC TÍNH
        ↓
⚠ Dùng để huấn luyện mô hình khác

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

• B (hệ gợi ý dựa trên hành vi người dùng) — ⚠ học máy truyền thống hoặc học tăng cường.

• C (kiểm định giả thuyết thống kê) — ⚠ thống kê cổ điển, không phải AI sinh ngữ.

• D (tối ưu vận hành bằng quy hoạch tuyến tính) — ⚠ tối ưu hoá toán học, một lĩnh vực khác hẳn.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về generative AI trong đợt.

⚠ Ứng dụng generative AI trong doanh nghiệp: | Ứng dụng | Nội dung | |---|---| | ⚠ Trợ lý hỏi đáp trên tài liệu nội bộ | ⚠ RAG | | ⚠ Soạn thảo và viết lại nội dung | | | ⚠ Tóm tắt tài liệu, cuộc họp | | | ⚠ Sinh và giải thích mã nguồn | | | ⚠ Sinh dữ liệu tổng hợp | ⚠ đề này | | ⚠ Trích thông tin từ văn bản tự do | |

Từ khoá nhận diện:

"tạo dữ liệu giả để huấn luyện" → ⚠ generative AI "gợi ý theo hành vi" → ⚠ recommendation "tối ưu lộ trình, phân bổ nguồn lực" → ⚠ tối ưu hoá, không phải AI sinh ngữ "kiểm định giả thuyết" → ⚠ thống kê

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu tổng hợp có giữ được đặc tính của dữ liệu thật không | | | Đã kiểm trên dữ liệu thật chưa | | | Có bản ghi nào bị tái tạo nguyên văn không | |

Và giới hạn của dữ liệu tổng hợp mà người ta hay quên khi nó giải quyết được bài toán thiếu dữ liệu: nó chỉ tạo ra được những gì mô hình sinh đã biết. Chính những ca biên hiếm nhất — thứ bạn cần nhất — lại là thứ nó khó tạo ra nhất.

Đáp án

C — Phát hiện các bất thường trong dữ liệu CHUỖI THỜI GIAN.

Vì sao đúng

⚠ Anomaly Detector là API chuyên cho một chuỗi số theo thời gian:

⚠ Chuỗi số theo thời gian
   ⚠ [100, 102, 98, 101, 350, 99, 103]
        ↓ ⚠ Anomaly Detector
⚠ Điểm thứ 5 là BẤT THƯỜNG
   ⚠ kèm giá trị kỳ vọng và biên trên dưới

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

• A (xây, huấn luyện, triển khai mô hình) — ⚠ Azure Machine Learning.

• B (tăng cường khả năng tìm kiếm) — ⚠ Azure AI Search.

• D (dựng chatbot thông minh) — ⚠ Bot Service, Copilot Studio.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ dịch vụ này ⚠ cũng đã thông báo ngừng.

⚠ Ba câu về phát hiện bất thường trong đợt này: | Câu | Hỏi gì | Khoá | |---|---|---| | ⚠ #18007 | ⚠ anomaly detection làm gì | ⚠ tìm mẫu khác thường | | ⚠ #18056 | ⚠ Metrics Advisor làm gì | ⚠ giám sát chỉ số đa chiều | | ⚠ #18063 (câu này) | ⚠ Anomaly Detector làm gì | ⚠ bất thường trong chuỗi thời gian | | ⚠ Phân biệt | ⚠ Anomaly Detector = MỘT chuỗi; Metrics Advisor = NHIỀU chiều |

Từ khoá nhận diện:

"một chuỗi số theo thời gian" → ⚠ Anomaly Detector "nhiều chiều, phân tích nguyên nhân gốc" → ⚠ Metrics Advisor "giám sát máy chủ, log" → ⚠ Azure Monitor "ảnh sản phẩm lỗi" → ⚠ thị giác máy tính, không phải hai cái trên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dịch vụ trong đề còn được hỗ trợ không | | | Một chuỗi hay nhiều chiều | | | Granularity có khớp tần suất dữ liệu không | |

Và điều đáng chú ý nhất khi đọc lô câu hỏi này bằng con mắt của năm 2026: ba dịch vụ AI chuyên biệt xuất hiện trong cùng một lô đề đều đã bị khai tử. Kiến thức nền về bài toán thì vẫn nguyên giá trị; chỉ tên dịch vụ là thứ thay đổi nhanh.

Đáp án

B — Features là DỮ LIỆU ĐẦU VÀO dùng để dự đoán, còn labels là ĐẦU RA ta muốn dự đoán.

Vì sao đúng

⚠ Định nghĩa nền tảng, nêu đủ cả hai vế:

⚠ FEATURES (x)          ⚠ LABEL (y)
⚠ diện tích              ⚠ giá nhà
⚠ số phòng        →      ⚠ (thứ cần dự đoán)
⚠ vị trí
⚠ năm xây
   ⚠ ĐẦU VÀO                ⚠ ĐẦU RA

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

• A — ⚠ đảo ngược hai vế; ⚠ lại là bẫy đối xứng.

• C (cả hai đều là dữ liệu ĐẦU VÀO) — ⚠ SAI: ⚠ nếu label cũng là đầu vào thì không còn gì để dự đoán.

• D (cả hai đều là ĐẦU RA) — ⚠ SAI: ⚠ vậy mô hình lấy gì làm căn cứ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #18005 ở đợt trước, ⚠ nhưng ⚠ soạn TỐT HƠN.

⚠ Từ vựng nền tảng — bảng phải thuộc: | Từ | Nghĩa | |---|---| | ⚠ Feature | ⚠ cột đầu vào | | ⚠ Label / Target | ⚠ cột cần dự đoán | | ⚠ Observation | ⚠ một dòng dữ liệu | | ⚠ Training data | ⚠ có cả feature và label | | ⚠ Dữ liệu dự đoán | ⚠ CHỈ có feature |

Từ khoá nhận diện:

"đầu vào, thông tin đã biết" → ⚠ feature "đầu ra, thứ cần biết" → ⚠ label "cột nào là kết quả" → ⚠ label column trong AutoML "không có nhãn" → ⚠ học không giám sát

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột nào là label | | | Tại thời điểm dự đoán, mọi feature đã có sẵn chưa | ⚠ câu hỏi chống rò rỉ | | Có đặc trưng nào tạo thêm được từ dữ liệu hiện có không | |

Và câu hỏi duy nhất cần đặt cho từng cột trước khi đưa vào mô hình, đủ để chặn gần hết lỗi rò rỉ dữ liệu: "vào đúng thời điểm cần dự đoán, tôi đã có giá trị của cột này chưa?" Nếu chưa, nó không phải feature.