Ngân hàng đề — Microsoft Azure AI Fundamentals
Tìm thấy 316 câu.
- A Manually adjust all rural application scores upward by 30% to match the urban approval rate before final decisions are made.
- B Deploy the model as planned since it is working as designed and achieving high overall accuracy rates across all applications.
- C Analyze the training data and model features to identify and remove bias, then retrain and retest the model to ensure equitable outcomes across different demographic groups.
- D Continue using the model but add a disclaimer informing users that results may vary based on geographic location.
Xem giải thích
Đáp án
C — Phân tích dữ liệu huấn luyện và các đặc trưng của mô hình để nhận diện và loại bỏ thiên lệch, rồi huấn luyện và kiểm thử lại để bảo đảm kết quả công bằng giữa các nhóm.
Vì sao đúng
⚠ Đây là cách xử lý ĐÚNG GỐC vấn đề công bằng:
⚠ Chênh lệch 75% và 45%
⚠ với ứng viên ĐỦ ĐIỀU KIỆN NHƯ NHAU
↓
⚠ Đây là THIÊN LỆCH, không phải kết quả hợp lý
↓
⚠ Tìm NGUYÊN NHÂN
⚠ dữ liệu lịch sử có thiên lệch sẵn?
⚠ đặc trưng nào là "proxy" cho vùng miền?
↓
⚠ Sửa dữ liệu và đặc trưng → ⚠ huấn luyện lại → ⚠ đo lại
Vì sao các phương án khác sai
-
A (cộng thêm 30% điểm cho hồ sơ nông thôn) — ⚠ vá triệu chứng, không chữa gốc: ⚠ con số 30% tuỳ tiện; ⚠ có thể vi phạm quy định tín dụng; ⚠ và ⚠ mô hình vẫn thiên lệch bên trong.
-
B (triển khai như kế hoạch vì độ chính xác TỔNG THỂ cao) — ⚠ chính là sai lầm mà đề cảnh báo: ⚠ độ chính xác tổng ⚠ che giấu chênh lệch giữa các nhóm.
-
D (thêm dòng lưu ý kết quả có thể khác theo vùng) — ⚠ thông báo không sửa được thiên lệch: ⚠ và ⚠ về pháp lý, biết mà vẫn dùng còn nặng hơn.
Ghi nhớ
⚠ Nguồn gốc thiên lệch trong mô hình — bảng phải thuộc: | Nguồn | Nội dung | |---|---| | ⚠ Dữ liệu lịch sử | ⚠ phản ánh phân biệt đối xử trong quá khứ | | ⚠ Lấy mẫu không đại diện | ⚠ ít dữ liệu về nhóm thiểu số | | ⚠ Đặc trưng proxy | ⚠ mã bưu chính thay cho chủng tộc, vùng miền | | ⚠ Nhãn thiên lệch | ⚠ người gán nhãn có định kiến | | ⚠ Nguy hiểm nhất | ⚠ proxy — bỏ cột "vùng" vẫn còn "mã bưu chính" |
Từ khoá nhận diện:
"kết quả khác nhau giữa các nhóm" → ⚠ Fairness "độ chính xác tổng thể cao" → ⚠ cảnh báo — phải phân tách theo nhóm "cộng bù điểm cho một nhóm" → ⚠ thường là phương án SAI
| ⚠ Đặc trưng proxy — vì sao khó xử lý | Lý do |
|---|---|
| ⚠ Bỏ cột nhạy cảm KHÔNG đủ | |
| ⚠ Mã bưu chính, trường học, nghề nghiệp đều là proxy | |
| ⚠ Mô hình học lại thiên lệch qua đường vòng | |
| ⚠ Cách phát hiện | ⚠ đo hiệu năng theo nhóm, dù nhóm đó không phải đặc trưng đầu vào |
| ⚠ Công cụ đánh giá công bằng | Công cụ |
|---|---|
| ⚠ Fairlearn | ⚠ thư viện mã nguồn mở của Microsoft |
| ⚠ Responsible AI dashboard trong Azure ML | |
| ⚠ Phân tách chỉ số theo nhóm | ⚠ việc cơ bản nhất, phải làm |
| ⚠ Chỉ số công bằng | ⚠ demographic parity, equalized odds |
| ⚠ Trong lĩnh vực tín dụng — lưu ý pháp lý | Lưu ý |
|---|---|
| ⚠ Nhiều nước cấm phân biệt đối xử trong cho vay | |
| ⚠ Phải giải thích được lý do từ chối | |
| ⚠ Chênh lệch tỉ lệ chấp thuận là rủi ro pháp lý thật | |
| ⚠ Vì vậy | ⚠ mô hình tín dụng thường phải giải thích được, không dùng hộp đen |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ số có được phân tách theo nhóm không | | | Có đặc trưng nào là proxy không | | | Có ai ngoài đội kỹ thuật rà soát vấn đề công bằng không | |
Và lý do việc bỏ cột nhạy cảm ra khỏi dữ liệu không giải quyết được thiên lệch: mô hình học lại chính thông tin đó qua các cột khác. Cách duy nhất để biết là đo kết quả theo từng nhóm — kể cả nhóm mà bạn không đưa vào mô hình.
- A Face detection to identify the presence and location of human faces in the video frames
- B Face analysis to detect facial attributes such as age, emotion, and head pose
- C Face recognition to identify specific customers returning to the store
- D Computer Vision OCR to read text from product labels in the video footage
Xem giải thích
Đáp án
B — Face analysis để phát hiện các thuộc tính khuôn mặt như tuổi, cảm xúc và tư thế đầu.
Ghi nhớ về chất lượng câu hỏi
⚠ Microsoft đã GỠ BỎ các thuộc tính suy đoán này khỏi Azure AI Face.
| Thuộc tính | Trạng thái |
|---|---|
| ⚠ Tuổi, giới tính, cảm xúc, tóc, trang điểm | ⚠ ĐÃ GỠ (từ 2022) vì lo ngại đạo đức |
| ⚠ Còn lại | ⚠ vị trí khuôn mặt, landmark, head pose, blur, occlusion |
| ⚠ Lý do gỡ | ⚠ suy đoán cảm xúc từ khuôn mặt thiếu cơ sở khoa học; ước lượng tuổi và giới tính có thiên lệch |
⚠ KHÔNG sửa khoá — ⚠ vào thời điểm đề được soạn, ⚠ đây là câu trả lời đúng.
⚠ Trong thực tế hôm nay: ⚠ ca dùng này ⚠ không còn triển khai được như mô tả.
Vì sao đúng (theo bối cảnh đề)
⚠ Phân biệt ba năng lực của Face: | Năng lực | Việc | |---|---| | ⚠ Detection | ⚠ CÓ khuôn mặt không, ở đâu | | ⚠ Analysis (attributes) | ⚠ thuộc tính: tuổi, cảm xúc — đề này | | ⚠ Recognition | ⚠ người này LÀ AI |
⚠ Đề cần ⚠ khoảng tuổi và trạng thái cảm xúc → ⚠ thuộc về phân tích thuộc tính.
Vì sao các phương án khác sai
-
A (face detection để xác định sự hiện diện và vị trí) — ⚠ chỉ tìm ra khuôn mặt: ⚠ không cho thuộc tính.
-
C (face recognition để nhận ra khách quay lại) — ⚠ định danh cá nhân: ⚠ đề không yêu cầu.
-
D (OCR đọc chữ trên nhãn sản phẩm) — ⚠ hoàn toàn khác mục đích.
Ghi nhớ
⚠ Bài học đạo đức từ việc Microsoft gỡ tính năng: | Bài học | Nội dung | |---|---| | ⚠ Suy đoán cảm xúc từ khuôn mặt KHÔNG đáng tin | ⚠ biểu cảm khác nhau theo văn hoá và cá nhân | | ⚠ Ước lượng tuổi có thiên lệch theo chủng tộc | | | ⚠ Nguy cơ dùng để phân biệt đối xử | | | ⚠ Nguyên tắc | ⚠ làm được về kỹ thuật không có nghĩa là NÊN làm |
Từ khoá nhận diện:
"thuộc tính khuôn mặt: tuổi, cảm xúc" → ⚠ face analysis — nhưng đã bị gỡ "có khuôn mặt không, ở đâu" → ⚠ face detection — vẫn dùng được "người này là ai" → ⚠ face recognition — cần đăng ký quyền dùng
| ⚠ Thay thế cho ca dùng phân tích khách hàng | Thay thế |
|---|---|
| ⚠ Đếm người bằng object detection | ⚠ không cần khuôn mặt |
| ⚠ Phân tích luồng di chuyển | ⚠ heatmap khu vực |
| ⚠ Khảo sát trực tiếp khách hàng | ⚠ dữ liệu đáng tin hơn nhiều |
| ⚠ Với mục tiêu marketing | ⚠ các cách này vừa hợp pháp hơn vừa chính xác hơn |
| ⚠ Azure AI Face — quyền truy cập hạn chế | Quyền |
|---|---|
| ⚠ Nhận diện và xác minh khuôn mặt cần ĐĂNG KÝ | |
| ⚠ Phải mô tả ca dùng và được Microsoft duyệt | |
| ⚠ Một số ca dùng bị TỪ CHỐI hẳn | |
| ⚠ Đây là | ⚠ một trong ít trường hợp nhà cung cấp tự giới hạn sản phẩm của mình |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tính năng cần dùng còn tồn tại không | ⚠ kiểm tra tài liệu hiện hành | | Có cách đạt mục tiêu mà không cần khuôn mặt không | | | Đã kiểm tra quy định pháp lý địa phương chưa | |
Và điều đáng chú ý trong câu hỏi này, vượt ra ngoài phạm vi kỳ thi: một nhà cung cấp lớn đã chủ động gỡ bỏ tính năng của chính mình vì lý do đạo đức. Đó là tín hiệu rõ ràng rằng ca dùng này cần được cân nhắc lại từ đầu.
- A The ability to classify existing product descriptions into predefined categories
- B The ability to translate product descriptions from one language to another
- C The ability to create new content based on patterns learned from training data
- D The ability to detect sentiment in customer reviews about products
Xem giải thích
Đáp án
C — Khả năng TẠO RA nội dung mới dựa trên các quy luật học được từ dữ liệu huấn luyện.
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này dùng CÙNG kịch bản với #17928 nhưng hỏi khía cạnh khác.
| Câu | Hỏi gì | Khoá |
|---|---|---|
| ⚠ #17928 | ⚠ LOẠI workload nào | ⚠ Generative AI |
| ⚠ #17937 (câu này) | ⚠ ĐẶC ĐIỂM nào của mô hình sinh ngữ giúp làm được | ⚠ tạo nội dung mới từ quy luật đã học |
| ⚠ Bổ sung nhau | ⚠ một câu hỏi tên, một câu hỏi cơ chế |
Vì sao đúng
⚠ Cơ chế của mô hình sinh ngữ:
⚠ Huấn luyện trên khối lượng văn bản khổng lồ
↓
⚠ Học QUY LUẬT: ngữ pháp, phong cách,
cách diễn đạt, quan hệ khái niệm
↓
⚠ Khi sinh: dự đoán từ tiếp theo
dựa trên quy luật đã học
↓
⚠ Kết quả là văn bản MỚI
⚠ chưa từng tồn tại trong dữ liệu huấn luyện
⚠ Điểm mấu chốt: ⚠ mô hình không sao chép, ⚠ nó tổng hợp lại theo quy luật.
Vì sao các phương án khác sai
-
A (phân loại mô tả có sẵn vào danh mục) — ⚠ là CLASSIFICATION, không phải sinh.
-
B (dịch mô tả sang ngôn ngữ khác) — ⚠ là DỊCH: ⚠ có nội dung nguồn để chuyển đổi, không tạo mới.
-
D (phát hiện cảm xúc trong đánh giá) — ⚠ là SENTIMENT ANALYSIS.
Ghi nhớ
⚠ Mô hình sinh ngữ — cách hoạt động: | Khái niệm | Nội dung | |---|---| | ⚠ Huấn luyện trước (pre-training) | ⚠ học quy luật ngôn ngữ từ dữ liệu khổng lồ | | ⚠ Dự đoán token tiếp theo | ⚠ cơ chế sinh cơ bản | | ⚠ Temperature | ⚠ cao = sáng tạo, thấp = ổn định | | ⚠ Top-p (nucleus sampling) | ⚠ giới hạn tập token được chọn | | ⚠ Prompt | ⚠ hướng dẫn mô hình sinh gì |
Từ khoá nhận diện:
"tạo nội dung mới từ quy luật đã học" → ⚠ Generative AI "phân vào danh mục có sẵn" → ⚠ classification "chuyển từ ngôn ngữ này sang ngôn ngữ khác" → ⚠ translation "đánh giá thái độ" → ⚠ sentiment analysis
| ⚠ Temperature — tham số quan trọng nhất | Ảnh hưởng |
|---|---|
| ⚠ 0 | ⚠ gần như luôn cho cùng kết quả — ổn định |
| ⚠ 0.7 | ⚠ cân bằng — mặc định phổ biến |
| ⚠ 1.0+ | ⚠ rất sáng tạo, dễ lan man và bịa |
| ⚠ Với mô tả sản phẩm | ⚠ 0.5-0.8 để có đa dạng mà vẫn bám thông số |
| ⚠ Với trích xuất dữ liệu | ⚠ 0 để nhất quán |
| ⚠ "Sáng tạo" của mô hình thực chất là gì | Thực chất |
|---|---|
| ⚠ Kết hợp lại các quy luật đã học theo cách mới | |
| ⚠ KHÔNG có hiểu biết hay ý định | |
| ⚠ KHÔNG kiểm tra tính đúng của thứ nó sinh ra | |
| ⚠ Hệ quả | ⚠ sinh ra thứ nghe hợp lý nhưng có thể hoàn toàn sai |
| ⚠ Vấn đề bản quyền | Vấn đề |
|---|---|
| ⚠ Mô hình có thể sinh ra đoạn gần giống dữ liệu huấn luyện | |
| ⚠ Azure OpenAI có Protected Material Detection | |
| ⚠ Microsoft có cam kết bảo vệ pháp lý cho khách hàng | ⚠ Customer Copyright Commitment |
| ⚠ Với nội dung thương mại | ⚠ nên bật tính năng phát hiện này |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Temperature đặt bao nhiêu | | | Nội dung sinh ra có trùng lặp giữa các sản phẩm không | | | Có bật phát hiện nội dung có bản quyền không | |
Và điều cần nói rõ khi giới thiệu AI sinh ngữ với đội kinh doanh: nó tổng hợp rất giỏi, nhưng không hề biết mình đang nói gì. Sự trôi chảy của câu chữ không phản ánh độ chính xác của nội dung.
- A Sentiment analysis to determine the emotional tone of each review
- B Language detection to identify which language customers are using
- C Key phrase extraction to identify the main topics in reviews
- D Entity recognition to extract product names from the reviews
Xem giải thích
Đáp án
A — Sentiment analysis để xác định sắc thái cảm xúc của từng đánh giá.
Ghi nhớ về chất lượng câu hỏi
⚠ Đây là câu THỨ HAI về sentiment analysis trong lô này, và còn một câu nữa (#17940).
| Câu | Bối cảnh |
|---|---|
| ⚠ #17923 | ⚠ phân loại đánh giá tích cực/tiêu cực/trung tính |
| ⚠ #17938 (câu này) | ⚠ phân loại đánh giá và tìm sản phẩm bị phản hồi xấu |
| ⚠ #17940 | ⚠ phân tích email hỗ trợ đa ngôn ngữ |
| ⚠ Cùng khoá | ⚠ sentiment analysis |
Vì sao đúng
⚠ Đề đưa hai ví dụ rất rõ: | Ví dụ | Nhãn | |---|---| | ⚠ "This product exceeded my expectations!" | ⚠ tích cực | | ⚠ "Very disappointed with the quality." | ⚠ tiêu cực |
⚠ Cộng thêm yêu cầu ⚠ tìm ra sản phẩm nào bị phản hồi tiêu cực → ⚠ cần điểm cảm xúc cho từng đánh giá.
Vì sao các phương án khác sai
-
C (key phrase extraction) — ⚠ tìm CHỦ ĐỀ được nhắc tới: ⚠ hữu ích để biết khách nói VỀ CÁI GÌ, ⚠ nhưng ⚠ không biết họ hài lòng hay không.
-
D (entity recognition) — ⚠ trích tên sản phẩm: ⚠ là bước bổ trợ, ⚠ không đánh giá thái độ.
-
B (language detection) — ⚠ chỉ nhận diện ngôn ngữ.
Ghi nhớ
⚠ Kết hợp nhiều tính năng cho phân tích phản hồi: | Tính năng | Đóng góp | |---|---| | ⚠ Sentiment analysis | ⚠ hài lòng hay không — câu này | | ⚠ Opinion mining | ⚠ hài lòng về KHÍA CẠNH nào | | ⚠ Key phrase extraction | ⚠ chủ đề được nhắc tới | | ⚠ Entity recognition | ⚠ tên sản phẩm cụ thể | | ⚠ Kết hợp cả bốn | ⚠ "sản phẩm X bị chê về ĐÓNG GÓI" — thông tin hành động được |
Từ khoá nhận diện:
"hài lòng hay không hài lòng" → ⚠ sentiment analysis "khách nói về chủ đề gì" → ⚠ key phrase extraction "trích tên sản phẩm, người, địa điểm" → ⚠ entity recognition "khen cái gì, chê cái gì" → ⚠ opinion mining
| ⚠ Opinion mining — vì sao đáng dùng | Lý do |
|---|---|
| ⚠ "Đồ ăn ngon nhưng phục vụ chậm" | |
| ⚠ Sentiment tổng: TRUNG TÍNH | ⚠ thông tin bị mất |
| ⚠ Opinion mining: đồ ăn = tích cực, phục vụ = tiêu cực | |
| ⚠ Với doanh nghiệp | ⚠ biết CÁI GÌ cần sửa mới hành động được |
| ⚠ Quy trình phân tích phản hồi hoàn chỉnh | Quy trình |
|---|---|
| ⚠ 1. Thu thập đánh giá | |
| ⚠ 2. Nhận diện ngôn ngữ nếu đa quốc gia | |
| ⚠ 3. Sentiment + opinion mining | |
| ⚠ 4. Trích tên sản phẩm (entity) | |
| ⚠ 5. Tổng hợp theo sản phẩm và khía cạnh | |
| ⚠ 6. Cảnh báo khi tỉ lệ tiêu cực tăng đột biến |
| ⚠ Hạn chế cần biết | Hạn chế |
|---|---|
| ⚠ Mỉa mai rất khó nhận | |
| ⚠ Đánh giá ngắn thiếu ngữ cảnh | |
| ⚠ Tiếng lóng và viết tắt | |
| ⚠ Nên | ⚠ lấy mẫu kiểm tra tay định kỳ để biết độ chính xác thật |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dùng opinion mining không | ⚠ giá trị hơn sentiment đơn thuần nhiều | | Độ chính xác trên dữ liệu thật là bao nhiêu | | | Có cảnh báo khi tỉ lệ tiêu cực tăng không | |
Và khác biệt giữa một hệ thống phân tích phản hồi cho ra báo cáo đẹp và một hệ thống thật sự có ích: cái thứ hai nói cho bạn biết cần SỬA CÁI GÌ. Biết 30% khách không hài lòng là thông tin; biết họ không hài lòng về khâu đóng gói mới là hành động.
- A Regression
- B Clustering
- C Classification
- D Anomaly detection
Xem giải thích
Đáp án
A — Regression (hồi quy).
Vì sao đúng
⚠ Cụm quyết định: "đầu ra là một GIÁ TRỊ TIỀN CỤ THỂ". | Đầu ra | Loại mô hình | |---|---| | ⚠ Một con số liên tục | ⚠ HỒI QUY — đề này | | ⚠ Một nhãn | ⚠ phân loại | | ⚠ Một nhóm | ⚠ phân cụm |
⚠ Đầu vào: diện tích, vị trí, số phòng ngủ,
tuổi nhà, gần trường học
↓ ⚠ Hồi quy
⚠ Đầu ra: 2.850.000.000 đồng
⚠ Dự đoán giá nhà là ví dụ kinh điển nhất của hồi quy trong mọi giáo trình học máy.
Vì sao các phương án khác sai
-
C (classification) — ⚠ cho ra NHÃN: ⚠ ví dụ "nhà đắt / trung bình / rẻ"; ⚠ đề cần con số cụ thể.
-
B (clustering) — ⚠ nhóm các bất động sản giống nhau: ⚠ không dự đoán giá.
-
D (anomaly detection) — ⚠ tìm bất động sản có giá bất thường: ⚠ là bài toán khác.
Ghi nhớ
⚠ Chọn loại mô hình theo ĐẦU RA — bảng phải thuộc: | Đầu ra | Loại | Ví dụ | |---|---|---| | ⚠ Số liên tục | ⚠ Regression | ⚠ giá nhà, doanh thu, nhiệt độ | | ⚠ Hai nhãn | ⚠ Binary classification | ⚠ duyệt/từ chối | | ⚠ Nhiều nhãn | ⚠ Multi-class classification | ⚠ loại sản phẩm | | ⚠ Nhóm không có nhãn sẵn | ⚠ Clustering | ⚠ phân khúc khách | | ⚠ Bình thường/bất thường | ⚠ Anomaly detection | ⚠ gian lận |
Từ khoá nhận diện:
"giá trị cụ thể, số tiền, số lượng" → ⚠ regression "thuộc loại nào" → ⚠ classification "nhóm lại" → ⚠ clustering "khác thường" → ⚠ anomaly detection
| ⚠ Chỉ số đánh giá mô hình hồi quy | Chỉ số |
|---|---|
| ⚠ MAE | ⚠ sai số tuyệt đối trung bình — dễ hiểu nhất |
| ⚠ RMSE | ⚠ phạt nặng sai số lớn |
| ⚠ R² | ⚠ mô hình giải thích được bao nhiêu phần biến thiên |
| ⚠ MAPE | ⚠ sai số phần trăm — so sánh được giữa các thang giá |
| ⚠ Với giá nhà | ⚠ MAPE dễ diễn giải: "sai trung bình 8%" |
| ⚠ Thuật toán hồi quy phổ biến | Thuật toán |
|---|---|
| ⚠ Linear regression | ⚠ đơn giản, GIẢI THÍCH ĐƯỢC |
| ⚠ Decision tree / Random forest | ⚠ nắm quan hệ phi tuyến |
| ⚠ Gradient boosting (XGBoost, LightGBM) | ⚠ thường tốt nhất với dữ liệu BẢNG |
| ⚠ Neural network | ⚠ cần nhiều dữ liệu, khó giải thích |
| ⚠ Với dữ liệu bảng như đề này | ⚠ gradient boosting thường thắng deep learning |
| ⚠ Đặc trưng quan trọng cho giá bất động sản | Đặc trưng |
|---|---|
| ⚠ Vị trí | ⚠ thường là yếu tố MẠNH NHẤT |
| ⚠ Diện tích | |
| ⚠ Thời điểm bán | ⚠ giá thay đổi theo thời gian — cần đưa vào |
| ⚠ Tiện ích xung quanh | |
| ⚠ Lưu ý | ⚠ mô hình huấn luyện trên dữ liệu cũ sẽ lệch khi thị trường đổi |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sai số trung bình bao nhiêu phần trăm | ⚠ MAPE dễ trình bày với người kinh doanh | | Mô hình có tính tới thời điểm không | ⚠ giá bất động sản trôi theo thời gian | | Có giải thích được dự đoán không | ⚠ khách hàng sẽ hỏi vì sao |
Và yêu cầu thực tế mà mọi mô hình định giá bất động sản đều gặp: người dùng muốn biết VÌ SAO ra con số đó. Một mô hình chính xác hơn 2% nhưng không giải thích được thường thua một mô hình đơn giản mà nhân viên môi giới tin tưởng.
- A Named entity recognition
- B Key phrase extraction
- C Language detection
- D Sentiment analysis
Xem giải thích
Đáp án
D — Sentiment analysis.
Ghi nhớ về chất lượng câu hỏi
⚠ Đây là câu THỨ BA về sentiment analysis trong cùng lô.
| Câu | Điểm nhấn riêng |
|---|---|
| ⚠ #17923 | ⚠ loại workload nào |
| ⚠ #17938 | ⚠ dịch vụ nào cho đánh giá sản phẩm |
| ⚠ #17940 (câu này) | ⚠ thêm yêu cầu ĐA NGÔN NGỮ không cần huấn luyện riêng |
| ⚠ Cùng khoá | ⚠ sentiment analysis |
Vì sao đúng
⚠ Đề có hai yêu cầu: | Yêu cầu | Sentiment analysis | |---|---| | ⚠ Xác định khách hài lòng hay không | ⚠ đúng mục đích | | ⚠ Nhiều ngôn ngữ, KHÔNG huấn luyện riêng từng ngôn ngữ | ⚠ mô hình dựng sẵn hỗ trợ đa ngôn ngữ NGAY |
⚠ Email tiếng Anh → ⚠ negative 0.9
⚠ Email tiếng Pháp → ⚠ positive 0.85
⚠ Email tiếng Việt → ⚠ neutral 0.6
↓
⚠ CÙNG một API, KHÔNG cấu hình gì thêm
⚠ Đây là ưu điểm lớn của mô hình dựng sẵn so với tự huấn luyện.
Vì sao các phương án khác sai
-
C (language detection) — ⚠ chỉ nhận ra ngôn ngữ nào: ⚠ là bước bổ trợ, ⚠ không đánh giá thái độ.
-
B (key phrase extraction) — ⚠ tìm chủ đề: ⚠ không biết hài lòng hay không.
-
A (named entity recognition) — ⚠ trích tên riêng: ⚠ không liên quan.
Ghi nhớ
⚠ Đa ngôn ngữ trong Azure AI Language: | Tính năng | Đa ngôn ngữ | |---|---| | ⚠ Sentiment analysis | ⚠ hỗ trợ nhiều ngôn ngữ sẵn | | ⚠ Key phrase extraction | ⚠ nhiều ngôn ngữ | | ⚠ NER | ⚠ nhiều ngôn ngữ | | ⚠ Language detection | ⚠ hơn 100 ngôn ngữ | | ⚠ Chất lượng | ⚠ KHÔNG đồng đều — tiếng Anh tốt nhất |
Từ khoá nhận diện:
"nhiều ngôn ngữ, không huấn luyện riêng" → ⚠ mô hình dựng sẵn "cần độ chính xác cao cho lĩnh vực đặc thù" → ⚠ custom model — nhưng phải huấn luyện từng ngôn ngữ "biết email viết bằng tiếng gì" → ⚠ language detection
| ⚠ Dựng sẵn so với tuỳ chỉnh | So sánh |
|---|---|
| ⚠ Dựng sẵn: dùng ngay, đa ngôn ngữ, miễn phí công sức | |
| ⚠ Dựng sẵn: không hiểu thuật ngữ đặc thù ngành | |
| ⚠ Tuỳ chỉnh: chính xác hơn cho lĩnh vực của bạn | |
| ⚠ Tuỳ chỉnh: cần dữ liệu có nhãn CHO TỪNG ngôn ngữ | |
| ⚠ Với yêu cầu đa ngôn ngữ | ⚠ dựng sẵn thắng rõ ràng |
| ⚠ Cần chỉ định ngôn ngữ không | Chỉ định |
|---|---|
⚠ API có tham số language |
|
| ⚠ Không chỉ định thì mặc định tiếng Anh | ⚠ có thể cho kết quả sai |
| ⚠ Cách tốt: chạy language detection trước | |
| ⚠ Hoặc | ⚠ truyền ngôn ngữ nếu đã biết từ hồ sơ khách hàng |
| ⚠ Lưu ý chất lượng theo ngôn ngữ | Lưu ý |
|---|---|
| ⚠ Tiếng Anh: chất lượng cao nhất | |
| ⚠ Ngôn ngữ ít phổ biến: kém hơn đáng kể | |
| ⚠ Nên đo riêng cho từng ngôn ngữ quan trọng | |
| ⚠ Đừng | ⚠ giả định độ chính xác đồng đều giữa các ngôn ngữ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có truyền tham số ngôn ngữ không | ⚠ thiếu thì mặc định tiếng Anh | | Độ chính xác với tiếng Việt là bao nhiêu | ⚠ đo riêng | | Có cần custom model cho thuật ngữ ngành không | |
Và giả định nguy hiểm khi triển khai phân tích cảm xúc đa ngôn ngữ: cho rằng chất lượng đồng đều giữa mọi ngôn ngữ. Một hệ thống đạt 90% với tiếng Anh có thể chỉ đạt 70% với ngôn ngữ ít dữ liệu hơn, và không có gì cảnh báo bạn điều đó.
- A Object detection to identify and locate multiple animals within each image
- B Optical character recognition (OCR) to read text from the images
- C Image classification to assign each image to a single category
- D Face detection to identify individual animals across multiple photos
Xem giải thích
Đáp án
C — Image classification để gán mỗi ảnh vào MỘT danh mục.
Ghi nhớ về chất lượng câu hỏi
⚠ Câu này ĐỐI LẬP với #17930 trong cùng lô — hai bài toán thị giác khác nhau.
| Câu | Yêu cầu | Khoá |
|---|---|---|
| ⚠ #17930 | ⚠ ĐẾM xe đẩy, biết VỊ TRÍ người | ⚠ object detection |
| ⚠ #17941 (câu này) | ⚠ gán MỘT nhãn cho cả ảnh | ⚠ image classification |
| ⚠ Phân biệt | ⚠ cần vị trí và số lượng → detection; chỉ cần một nhãn → classification |
Vì sao đúng
⚠ Đề nêu rõ: mỗi ảnh được gán MỘT trong năm nhãn.
⚠ "bear", "deer", "wolf", "empty", "other wildlife"
↓
⚠ Mỗi ảnh → ⚠ MỘT nhãn
↓
⚠ Không cần biết con vật ở ĐÂU trong ảnh
⚠ Không cần ĐẾM số con
↓
⚠ Image classification là đủ
⚠ Đây là multi-class classification — ⚠ nhiều lớp, mỗi ảnh một lớp.
Vì sao các phương án khác sai
-
A (object detection để tìm và định vị nhiều con vật) — ⚠ làm được nhưng THỪA: ⚠ đề không cần vị trí hay số lượng; ⚠ object detection ⚠ đòi gán nhãn bounding box khi huấn luyện — tốn công hơn nhiều.
-
D (face detection để nhận diện từng con vật) — ⚠ face detection dành cho KHUÔN MẶT NGƯỜI.
-
B (OCR) — ⚠ đọc chữ: ⚠ không liên quan.
Ghi nhớ
⚠ Classification so với detection — chi phí gán nhãn: | Loại | Gán nhãn thế nào | Công sức | |---|---|---| | ⚠ Classification | ⚠ chọn MỘT nhãn cho cả ảnh | ⚠ nhanh | | ⚠ Object detection | ⚠ VẼ HỘP quanh từng đối tượng | ⚠ chậm hơn nhiều lần | | ⚠ Nguyên tắc | ⚠ chọn loại ĐƠN GIẢN NHẤT đáp ứng được yêu cầu |
Từ khoá nhận diện:
"gán một nhãn cho ảnh" → ⚠ image classification "đếm, vị trí, nhiều đối tượng" → ⚠ object detection "vùng chính xác từng pixel" → ⚠ segmentation "một ảnh nhiều nhãn cùng lúc" → ⚠ multi-label classification
| ⚠ Ba biến thể của classification | Biến thể |
|---|---|
| ⚠ Binary | ⚠ hai lớp: có/không |
| ⚠ Multi-class | ⚠ nhiều lớp, chọn MỘT — đề này |
| ⚠ Multi-label | ⚠ nhiều lớp, chọn NHIỀU |
| ⚠ Custom Vision | ⚠ chọn multiclass hay multilabel khi tạo project |
| ⚠ Bẫy dữ liệu với camera bẫy động vật | Bẫy |
|---|---|
| ⚠ Rất nhiều ảnh "empty" | ⚠ dữ liệu MẤT CÂN BẰNG nặng |
| ⚠ Ảnh ban đêm, hồng ngoại, mờ | |
| ⚠ Động vật chỉ hiện một phần | |
| ⚠ Lớp "other wildlife" rất đa dạng | ⚠ khó học |
| ⚠ Xử lý | ⚠ cân bằng lại dữ liệu, hoặc gán trọng số lớp |
| ⚠ Custom Vision cho ca dùng này | Chi tiết |
|---|---|
| ⚠ Tối thiểu 15 ảnh mỗi nhãn, nên có 50+ | |
| ⚠ Ảnh huấn luyện phải giống điều kiện thực tế | ⚠ cùng loại camera, cùng ánh sáng |
| ⚠ Domain compact nếu muốn chạy tại chỗ | ⚠ camera trong rừng thường không có mạng |
| ⚠ Rất quan trọng | ⚠ chạy ở biên giúp không phải truyền hàng nghìn ảnh về |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần vị trí hay số lượng không | ⚠ nếu không thì classification là đủ | | Dữ liệu có mất cân bằng không | ⚠ ảnh "empty" thường chiếm đa số | | Có cần chạy ở biên không | ⚠ camera trong rừng thường không có mạng |
Và nguyên tắc tiết kiệm rất nhiều công sức trong các dự án thị giác máy tính: chọn bài toán đơn giản nhất đáp ứng được yêu cầu. Gán nhãn cho phân loại nhanh hơn vẽ hộp cho phát hiện đối tượng nhiều lần, và với nhiều ca dùng thì phân loại đã đủ.
- A Clustering
- B Classification
- C Anomaly detection
- D Regression
Xem giải thích
Đáp án
B — Classification (phân loại).
Vì sao đúng
⚠ Đầu ra là MỘT TRONG HAI nhãn: duyệt hoặc từ chối.
⚠ Đầu vào: điểm tín dụng, thu nhập,
lịch sử việc làm, tỉ lệ nợ trên thu nhập
↓ ⚠ Binary classification
⚠ Đầu ra: DUYỆT hoặc TỪ CHỐI
⚠ Đây là phân loại NHỊ PHÂN — ⚠ trường hợp phổ biến nhất của classification.
Vì sao các phương án khác sai
-
D (regression) — ⚠ cho ra CON SỐ: ⚠ nếu đề hỏi "dự đoán SỐ TIỀN được vay" thì mới là hồi quy; ⚠ đây là quyết định có/không.
-
A (clustering) — ⚠ nhóm khách hàng giống nhau: ⚠ không quyết định duyệt hay không.
-
C (anomaly detection) — ⚠ tìm hồ sơ bất thường: ⚠ hữu ích để phát hiện gian lận, ⚠ không phải quyết định tín dụng.
Ghi nhớ
⚠ Cùng dữ liệu, khác câu hỏi, khác loại mô hình: | Câu hỏi | Loại | |---|---| | ⚠ "Duyệt hay từ chối?" | ⚠ Binary classification — đề này | | ⚠ "Được vay bao nhiêu tiền?" | ⚠ Regression | | ⚠ "Xác suất vỡ nợ là bao nhiêu?" | ⚠ Classification có trả xác suất | | ⚠ "Hồ sơ này có bất thường không?" | ⚠ Anomaly detection | | ⚠ Bài học | ⚠ loại mô hình do CÂU HỎI quyết định, không do dữ liệu |
Từ khoá nhận diện:
"duyệt/từ chối, có/không" → ⚠ binary classification "bao nhiêu tiền" → ⚠ regression "thuộc nhóm nào trong nhiều nhóm" → ⚠ multi-class "bất thường" → ⚠ anomaly detection
| ⚠ Với mô hình tín dụng — yêu cầu đặc thù | Yêu cầu |
|---|---|
| ⚠ Phải GIẢI THÍCH ĐƯỢC | ⚠ luật nhiều nước bắt phải nêu lý do từ chối |
| ⚠ Phải CÔNG BẰNG giữa các nhóm | ⚠ xem #17935 cùng lô |
| ⚠ Phải kiểm toán được | |
| ⚠ Vì vậy | ⚠ thường dùng mô hình giải thích được, tránh hộp đen |
| ⚠ Ngưỡng quyết định — quan trọng hơn mô hình | Ngưỡng |
|---|---|
| ⚠ Mô hình trả về XÁC SUẤT, không phải quyết định | |
| ⚠ Ngưỡng 0.5 là mặc định, KHÔNG phải luôn đúng | |
| ⚠ Ngưỡng cao → ít duyệt hơn, an toàn hơn, mất khách | |
| ⚠ Ngưỡng thấp → duyệt nhiều, rủi ro nợ xấu cao | |
| ⚠ Quyết định ngưỡng | ⚠ là quyết định KINH DOANH, không phải kỹ thuật |
| ⚠ Chỉ số phù hợp cho bài toán này | Chỉ số |
|---|---|
| ⚠ Precision | ⚠ trong số duyệt, bao nhiêu trả được nợ |
| ⚠ Recall | ⚠ trong số khách tốt, bắt được bao nhiêu |
| ⚠ AUC-ROC | ⚠ khả năng phân biệt tổng thể |
| ⚠ Phân tách theo NHÓM | ⚠ kiểm tra công bằng |
| ⚠ KHÔNG dùng | ⚠ accuracy đơn thuần khi dữ liệu mất cân bằng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngưỡng quyết định do ai chọn | ⚠ phải là quyết định kinh doanh có ghi chép | | Mô hình có giải thích được lý do từ chối không | | | Chỉ số có được phân tách theo nhóm không | |
Và điều mà rất nhiều dự án học máy bỏ qua: chọn ngưỡng quyết định quan trọng không kém chọn mô hình. Cùng một mô hình, hai ngưỡng khác nhau cho ra hai chính sách kinh doanh hoàn toàn khác nhau.
- A Azure OpenAI Service with GPT models
- B Azure AI Speech with speech-to-text translation
- C Azure AI Language with sentiment analysis
- D Azure AI Translator with custom glossaries
Xem giải thích
Đáp án
D — Azure AI Translator với custom glossary (từ điển tuỳ chỉnh).
Vì sao đúng
⚠ Đề nêu hai yêu cầu: | Yêu cầu | Translator + glossary | |---|---| | ⚠ Dịch sang nhiều ngôn ngữ | ⚠ Translator hỗ trợ hơn 100 ngôn ngữ | | ⚠ Giữ NHẤT QUÁN tên sản phẩm và thuật ngữ thương hiệu | ⚠ glossary ép dịch đúng theo quy định |
⚠ Không có glossary
⚠ "SmartHome Hub" → mỗi lần dịch một kiểu
⚠ có khi bị dịch nghĩa đen
⚠ Có glossary
⚠ "SmartHome Hub" → GIỮ NGUYÊN
⚠ "Premium Care" → "Chăm sóc Cao cấp" (cố định)
↓
⚠ Nhất quán trên MỌI ngôn ngữ và MỌI lần dịch
Vì sao các phương án khác sai
-
A (Azure OpenAI với GPT) — ⚠ dịch được nhưng KHÔNG đảm bảo nhất quán: ⚠ mỗi lần gọi có thể ra kết quả khác; ⚠ và ⚠ đắt hơn Translator nhiều cho khối lượng lớn.
-
B (Speech với dịch giọng nói) — ⚠ cho ÂM THANH: ⚠ đề là văn bản.
-
C (AI Language với sentiment analysis) — ⚠ phân tích cảm xúc: ⚠ không dịch.
Ghi nhớ
⚠ Hai cách tuỳ chỉnh dịch thuật — bảng phải thuộc: | Cách | Nội dung | |---|---| | ⚠ Custom glossary (dictionary) | ⚠ danh sách từ và bản dịch cố định — ĐƠN GIẢN, dùng ngay | | ⚠ Custom Translator | ⚠ HUẤN LUYỆN mô hình riêng bằng cặp câu song ngữ | | ⚠ Glossary hợp khi | ⚠ chỉ cần cố định một số thuật ngữ — đề này | | ⚠ Custom Translator hợp khi | ⚠ cả VĂN PHONG của ngành cần khác biệt |
Từ khoá nhận diện:
"giữ nhất quán tên riêng, thuật ngữ" → ⚠ glossary "văn phong chuyên ngành y tế, pháp lý" → ⚠ Custom Translator "dịch giọng nói" → ⚠ Speech translation "dịch có sáng tạo, viết lại" → ⚠ mô hình sinh ngữ — nhưng mất nhất quán
| ⚠ Vì sao nhất quán thuật ngữ quan trọng | Lý do |
|---|---|
| ⚠ Tên sản phẩm bị dịch nghĩa đen là thảm hoạ thương hiệu | |
| ⚠ Khách hàng tìm kiếm theo tên sản phẩm | ⚠ dịch khác nhau là không tìm ra |
| ⚠ Tài liệu kỹ thuật cần thuật ngữ chuẩn | |
| ⚠ Yêu cầu pháp lý với một số ngành |
| ⚠ Cách dùng glossary với Translator | Cách |
|---|---|
| ⚠ Tạo file glossary (TSV, CSV, XLIFF) | |
| ⚠ Mỗi dòng: từ nguồn + bản dịch đích | |
| ⚠ Truyền qua tham số khi gọi API | |
⚠ Hoặc dùng <mstrans:dictionary> inline trong văn bản |
|
| ⚠ Lưu ý | ⚠ glossary có giới hạn kích thước — dùng cho thuật ngữ QUAN TRỌNG |
| ⚠ Translator so với mô hình sinh ngữ cho dịch thuật | So sánh |
|---|---|
| ⚠ Translator: nhất quán, rẻ, nhanh, có glossary | |
| ⚠ Mô hình sinh ngữ: linh hoạt hơn, hiểu ngữ cảnh tốt hơn | |
| ⚠ Mô hình sinh ngữ: đắt hơn nhiều, kém nhất quán | |
| ⚠ Với hàng nghìn mô tả sản phẩm | ⚠ Translator thắng rõ ràng |
| ⚠ Với nội dung marketing cần "bay bổng" | ⚠ mô hình sinh ngữ có thể phù hợp hơn |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Glossary có đủ mọi tên sản phẩm và thuật ngữ chưa | | | Có ai rà soát bản dịch mẫu không | ⚠ nhất là ngôn ngữ không ai trong đội biết | | Chi phí ở quy mô thật là bao nhiêu | |
Và sự cố thương hiệu kinh điển với dịch thuật tự động: tên sản phẩm bị dịch nghĩa đen. Một glossary năm phút để lập ngăn được điều đó trên tất cả các ngôn ngữ cùng lúc.
- A Sentiment Analysis
- B Language Detection
- C Key Phrase Extraction
- D Named Entity Recognition
Xem giải thích
Đáp án
C — Key Phrase Extraction (trích xuất cụm từ khoá).
Vì sao đúng
⚠ Đề cần biết khách hàng ĐANG NÓI VỀ CÁI GÌ, không phải họ cảm thấy thế nào.
⚠ "Giao hàng nhanh nhưng hộp bị móp,
sản phẩm vẫn dùng tốt"
↓ ⚠ Key phrase extraction
⚠ ["giao hàng", "hộp", "sản phẩm"]
↓
⚠ Tổng hợp hàng nghìn đánh giá
↓
⚠ Biết chủ đề nào được nhắc nhiều nhất
| Trả lời câu hỏi | Tính năng |
|---|---|
| ⚠ "Khách nói VỀ CÁI GÌ" | ⚠ Key phrase extraction — đề này |
| ⚠ "Khách cảm thấy THẾ NÀO" | ⚠ Sentiment analysis |
Vì sao các phương án khác sai
-
A (Sentiment Analysis) — ⚠ cho biết THÁI ĐỘ, không cho biết CHỦ ĐỀ: ⚠ đề nói rõ muốn biết chủ đề chính.
-
D (Named Entity Recognition) — ⚠ trích TÊN RIÊNG có phân loại: ⚠ người, tổ chức, địa điểm, ngày tháng; ⚠ hẹp hơn "chủ đề chung".
-
B (Language Detection) — ⚠ chỉ nhận diện ngôn ngữ.
Ghi nhớ
⚠ Bốn tính năng cơ bản của AI Language — phân biệt: | Tính năng | Trả lời | |---|---| | ⚠ Key phrase extraction | ⚠ VĂN BẢN NÓI VỀ GÌ | | ⚠ Sentiment analysis | ⚠ THÁI ĐỘ tích cực hay tiêu cực | | ⚠ NER | ⚠ có TÊN RIÊNG nào: người, nơi, tổ chức | | ⚠ Language detection | ⚠ viết bằng NGÔN NGỮ nào |
Từ khoá nhận diện:
"chủ đề chính, khách nói về gì" → ⚠ key phrase extraction "hài lòng hay không" → ⚠ sentiment analysis "tên sản phẩm, tên người" → ⚠ NER "tiếng gì" → ⚠ language detection
| ⚠ Key phrase so với NER | Phân biệt |
|---|---|
| ⚠ Key phrase: cụm từ QUAN TRỌNG bất kỳ | ⚠ "giao hàng chậm", "chất lượng tốt" |
| ⚠ NER: thực thể CÓ PHÂN LOẠI | ⚠ "Hà Nội" = địa điểm, "01/05" = ngày |
| ⚠ Key phrase | ⚠ rộng hơn, không phân loại |
| ⚠ NER | ⚠ hẹp hơn, có nhãn loại |
| ⚠ Kết hợp để có thông tin hành động được | Kết hợp |
|---|---|
| ⚠ Key phrase: chủ đề được nhắc | |
| ⚠ Sentiment: thái độ với chủ đề đó | |
| ⚠ Opinion mining: gắn hai cái lại | ⚠ "giao hàng" = tiêu cực |
| ⚠ Kết quả | ⚠ "30% đánh giá nhắc tới ĐÓNG GÓI, trong đó 80% tiêu cực" |
| ⚠ Đó mới là | ⚠ thông tin hành động được |
| ⚠ Hạn chế của key phrase extraction | Hạn chế |
|---|---|
| ⚠ Trả về cụm từ, KHÔNG gom nhóm đồng nghĩa | ⚠ "giao hàng", "vận chuyển", "ship" là ba cụm riêng |
| ⚠ Cần bước hậu xử lý để gom nhóm | |
| ⚠ Cụm quá chung chung đôi khi vô nghĩa | |
| ⚠ Cách xử lý | ⚠ dùng embedding để gom cụm đồng nghĩa, hoặc dùng mô hình phân loại chủ đề |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bước gom nhóm cụm đồng nghĩa không | | | Có kết hợp với sentiment không | ⚠ giá trị hơn nhiều | | Kết quả có dẫn tới hành động cụ thể không | |
Và giới hạn khiến key phrase extraction thô không đủ dùng ngay: nó không biết "giao hàng", "vận chuyển" và "ship" là cùng một chủ đề. Cần thêm một bước gom nhóm thì báo cáo mới đọc được.