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

Đáp án

D — Giải pháp PHÁT HIỆN khuôn mặt chỉ tìm và định vị mặt trong ảnh, còn giải pháp PHÂN TÍCH khuôn mặt cung cấp thêm các thuộc tính như tuổi, giới tính…

Vì sao đúng

⚠ Hai tầng khác nhau, tầng sau dựa trên tầng trước:

⚠ Ảnh vào
        ↓ ⚠ DETECTION
⚠ "Có 3 khuôn mặt, tại toạ độ..."
        ↓ ⚠ ANALYSIS
⚠ Thuộc tính của từng mặt
   ⚠ đeo kính, che mặt, hướng đầu, độ mờ

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

• B — ⚠ đảo ngược hai khái niệm, ⚠ đây là bẫy đối xứng cổ điển: ⚠ đọc lướt rất dễ chọn nhầm.

• C (hai thứ giống nhau, dùng thay nhau được) — ⚠ SAI: ⚠ chúng là hai tầng khác nhau.

• A (detection phức tạp và chính xác hơn analysis) — ⚠ vô nghĩa: ⚠ analysis ⚠ xây trên detection.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ khoá D nêu thuộc tính ⚠ tuổi, giới tính — ⚠ những thứ đã bị gỡ.

⚠ Ba tầng khuôn mặt — bảng phải thuộc: | Tầng | Câu hỏi | Hạn chế | |---|---|---| | ⚠ Detection | ⚠ có mặt không, ở đâu | ⚠ dùng tự do | | ⚠ Analysis | ⚠ mặt đó có đặc điểm gì | ⚠ danh sách đã bị thu hẹp | | ⚠ Recognition | ⚠ đây là ai | ⚠ LIMITED ACCESS, phải đăng ký |

Từ khoá nhận diện:

"có bao nhiêu người trong khung hình" → ⚠ detection "người này có đeo kính không" → ⚠ analysis "đây có phải nhân viên A không" → ⚠ verification / identification "đoán tuổi, giới tính, cảm xúc" → ⚠ ĐÃ GỠ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần biết CÓ MẶT hay biết LÀ AI | ⚠ khác nhau về pháp lý | | Thuộc tính cần dùng còn tồn tại không | | | Đã có cơ sở pháp lý cho dữ liệu sinh trắc chưa | |

Và cách thiết kế hệ thống camera tránh được gần hết rắc rối pháp lý về dữ liệu sinh trắc: chỉ dùng tới tầng phát hiện, đừng chạm tới nhận diện danh tính trừ khi nghiệp vụ thật sự đòi hỏi.

Đáp án

D — Đối xử với cá nhân và các nhóm một cách BÌNH ĐẲNG, không thiên vị hay phân biệt đối xử.

Vì sao đúng

⚠ Fairness (công bằng) là nguyên tắc đầu tiên trong sáu nguyên tắc:

⚠ Mô hình duyệt vay
        ↓
⚠ Cùng hồ sơ tài chính
   ⚠ nhưng khác giới / khác vùng
        ↓
⚠ Kết quả KHÁC NHAU?
        ↓
⚠ Vi phạm fairness

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

• A (giải thích đầy đủ cho các bên liên quan) — ⚠ thuộc TRANSPARENCY.

• C (thuật toán cho kết quả chính xác nhất có thể) — ⚠ thuộc RELIABILITY; ⚠ và ⚠ chính xác tổng thể cao vẫn có thể rất bất công.

• B (giảm tỉ lệ lỗi, BẤT KỂ dữ liệu nhân khẩu) — ⚠ bẫy tinh vi nhất: ⚠ "bất kể nhân khẩu" nghe như trung lập, ⚠ nhưng công bằng đòi ⚠ phải NHÌN VÀO từng nhóm mới biết có chênh lệch hay không.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chủ đề với #17978 ở đợt trước — ⚠ #17978 hỏi nguyên nhân thiên lệch (dữ liệu huấn luyện), ⚠ câu này hỏi định nghĩa; ⚠ không mâu thuẫn.

⚠ Vì sao "mù nhân khẩu" KHÔNG bằng công bằng: | Điểm | Nội dung | |---|---| | ⚠ Bỏ cột giới tính KHÔNG xoá được thiên lệch | | | ⚠ Mô hình học lại qua đặc trưng thay thế | ⚠ nghề nghiệp, nơi ở, tên | | ⚠ Không đo theo nhóm thì không phát hiện được | | | ⚠ Cách đúng | ⚠ ĐO hiệu năng theo từng nhóm rồi so sánh | | ⚠ Công cụ | ⚠ Fairlearn tích hợp trong Azure ML |

Từ khoá nhận diện:

"đối xử bình đẳng, không phân biệt" → ⚠ Fairness "nhóm nào bị dự đoán tệ hơn" → ⚠ Fairness "mọi người tiếp cận được" → ⚠ Inclusiveness "bỏ qua dữ liệu nhân khẩu" → ⚠ phương án bẫy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã đo chỉ số theo từng nhóm chưa | | | Có đặc trưng nào thay thế cho thuộc tính nhạy cảm không | | | Dữ liệu huấn luyện có đại diện đủ các nhóm không | |

Và điều phản trực giác nhất về công bằng thuật toán, khiến nhiều nỗ lực thiện chí phản tác dụng: xoá thuộc tính nhạy cảm khỏi dữ liệu thường làm vấn đề khó thấy hơn chứ không làm nó biến mất. Không đo được thì không sửa được.

Đáp án

C — Phát hiện và phân tích CẢM XÚC và giọng điệu của khuôn mặt.

Vì sao đúng

⚠ Đây là câu PHỦ ĐỊNH — tìm năng lực KHÔNG được hỗ trợ.

⚠ "Sentiment và tone" là khái niệm của phân tích VĂN BẢN, ⚠ không phải của Face API. ⚠ Thêm nữa, ⚠ thuộc tính cảm xúc đã bị gỡ khỏi dịch vụ.

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

• A và D — ⚠ là năng lực thật của Face API, nên không phải đáp án.

• B — ⚠ xem mục chất lượng câu hỏi.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này có ⚠ HAI phương án đều không còn được hỗ trợ.

⚠ Face API hiện tại — CÓ và KHÔNG: | CÓ | KHÔNG | |---|---| | ⚠ Detect: vị trí mặt, mốc khuôn mặt | ⚠ cảm xúc | | ⚠ Thuộc tính: kính, che mặt, hướng đầu, mờ, nhiễu | ⚠ tuổi | | ⚠ Verify: hai mặt có cùng người không | ⚠ giới tính | | ⚠ Identify: tìm trong nhóm đã đăng ký | ⚠ nụ cười, trang điểm, râu tóc | | ⚠ Find similar, Group | ⚠ giọng điệu — vốn thuộc văn bản | | ⚠ Liveness | |

Từ khoá nhận diện:

"cảm xúc, giọng điệu, thái độ" → ⚠ phân tích VĂN BẢN, không phải khuôn mặt "hai ảnh này cùng một người không" → ⚠ Verify "đeo kính, che mặt" → ⚠ thuộc tính CÒN được hỗ trợ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề có chữ NOT không | | | Tính năng này còn tồn tại ở bản hiện tại không | | | Có cần đăng ký Limited Access không | |

Và điều cần cảnh giác khi ôn thi bằng ngân hàng câu hỏi cũ, riêng với phần khuôn mặt: một phần đáng kể nội dung đã lỗi thời từ giữa năm 2022. Nắm cả bản cũ lẫn bản hiện tại là cách an toàn nhất.

Đáp án

D — Phiên âm thời gian thực (Real-time Transcription).

Vì sao đúng

⚠ Speech recognition = speech-to-text = chuyển LỜI NÓI thành VĂN BẢN:

⚠ Âm thanh vào
        ↓ ⚠ Speech recognition
⚠ Văn bản ra, ngay khi đang nói
        ↓
⚠ Phụ đề trực tiếp, ghi biên bản họp

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

• A (Text-to-Speech) — ⚠ NGƯỢC CHIỀU: ⚠ văn bản thành giọng nói, ⚠ là speech ⚠ synthesis chứ không phải recognition.

• B (Sentiment Analysis) — ⚠ thuộc AI Language, xử lý văn bản.

• C (Language Translation) — ⚠ thuộc Translator; ⚠ dịch nói cần ghép thêm bước, không phải bản thân nhận dạng giọng nói.

Ghi nhớ

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

⚠ Azure AI Speech — bốn năng lực, phân biệt bằng CHIỀU: | Năng lực | Chiều | |---|---| | ⚠ Speech to text | ⚠ âm thanh → văn bản | | ⚠ Text to speech | ⚠ văn bản → âm thanh | | ⚠ Speech translation | ⚠ âm thanh → âm thanh khác ngôn ngữ | | ⚠ Speaker recognition | ⚠ âm thanh → AI ĐANG NÓI |

Từ khoá nhận diện:

"phiên âm, phụ đề, ghi lại lời nói" → ⚠ speech to text "đọc thành tiếng, giọng đọc" → ⚠ text to speech "ai đang nói" → ⚠ speaker recognition "nói tiếng này ra tiếng kia" → ⚠ speech translation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần kết quả ngay hay xử lý sau | ⚠ real-time hay batch | | Có thuật ngữ riêng hay tên riêng không | | | Môi trường thu âm ồn tới mức nào | |

Và cách cải thiện độ chính xác phiên âm rẻ và hiệu quả hơn mọi tinh chỉnh mô hình: thu âm sạch hơn. Một chiếc micro tốt đặt đúng chỗ thường thắng mọi nỗ lực tuỳ chỉnh phía sau.

Đáp án

C — Chúng cung cấp bộ tính năng TOÀN DIỆN để xây chatbot cấp doanh nghiệp.

Vì sao đúng

⚠ Bot Framework SDK là bộ công cụ đầy đủ cho bot nghiêm túc: | Thành phần | Nội dung | |---|---| | ⚠ Quản lý hội thoại nhiều bước | ⚠ dialog, waterfall | | ⚠ Quản lý trạng thái | ⚠ nhớ ngữ cảnh giữa các lượt | | ⚠ Nối nhiều kênh | ⚠ Teams, web, SMS, Facebook | | ⚠ Tích hợp CLU và question answering | | | ⚠ Xác thực người dùng | | | ⚠ Kiểm thử và gỡ lỗi bằng Bot Emulator | | | ⚠ Telemetry gắn Application Insights | |

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

• A (không cần kinh nghiệm lập trình) — ⚠ SAI: ⚠ SDK ⚠ dành cho lập trình viên; ⚠ không cần code là Copilot Studio.

• D (Azure lo trọn việc triển khai và bảo trì) — ⚠ SAI: ⚠ đội phát triển vẫn phải triển khai, giám sát và cập nhật.

• B (toàn quyền kiểm soát NLP và quản lý hội thoại) — ⚠ 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 B ⚠ cũng là một mô tả đúng về SDK.

⚠ Chọn công cụ theo nhu cầu: | Nhu cầu | Chọn | |---|---| | ⚠ Ra nhanh, người nghiệp vụ tự làm | ⚠ Copilot Studio | | ⚠ Tích hợp sâu, logic phức tạp | ⚠ Bot Framework SDK | | ⚠ Hiểu ý định | ⚠ CLU | | ⚠ FAQ từ tài liệu | ⚠ Custom question answering |

Từ khoá nhận diện:

"cấp doanh nghiệp, đầy đủ tính năng" → ⚠ Bot Framework SDK "không cần lập trình" → ⚠ Copilot Studio "Azure lo hết mọi thứ" → ⚠ thường là phương án SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai bảo trì bot sau khi ra mắt | | | Bot có cần nhớ ngữ cảnh nhiều lượt không | | | Sẽ chạy trên những kênh nào | ⚠ kiểm thử trên từng kênh |

Và phần khó nhất của một chatbot doanh nghiệp, khó hơn cả việc hiểu câu người dùng: giữ được mạch hội thoại khi người ta đổi ý giữa chừng. Đó cũng là lý do bot nghiêm túc thường phải viết bằng SDK.

Đáp án

C — Chuyển giọng nói thành văn bản (Speech-to-text conversion).

Vì sao đúng

⚠ NLP là xử lý NGÔN NGỮ — nói hoặc viết: | Workload NLP | Nội dung | |---|---| | ⚠ Speech to text | ⚠ đề này | | ⚠ Text to speech | | | ⚠ Phân tích cảm xúc | | | ⚠ Trích thực thể, cụm từ khoá | | | ⚠ Dịch thuật | | | ⚠ Hiểu ý định hội thoại | | | ⚠ Tóm tắt | |

⚠ Ngôn ngữ (nói hoặc viết)
        ↓
⚠ NLP

⚠ Ảnh, video
        ↓
⚠ Computer Vision

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

• A (OCR) — ⚠ bẫy hay nhất trong câu này: ⚠ OCR ⚠ cho ra văn bản, nhưng ⚠ đầu vào là ẢNH ⚠ nên nó thuộc ⚠ thị giác máy tính.

• B (nhận dạng ảnh) và D (phát hiện đối tượng) — ⚠ đều thuộc computer vision.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #18028 trong cùng đợt — ⚠ #18028 hỏi kịch bản của nhận dạng giọng nói, ⚠ câu này hỏi workload NLP; ⚠ cùng dẫn tới speech-to-text, không mâu thuẫn.

⚠ Phân loại workload theo ĐẦU VÀO — quy tắc vàng: | Đầu vào | Lĩnh vực | |---|---| | ⚠ Ảnh, video | ⚠ Computer Vision | | ⚠ Văn bản | ⚠ NLP | | ⚠ Âm thanh lời nói | ⚠ NLP (nhánh Speech) | | ⚠ Số liệu bảng | ⚠ học máy truyền thống |

⚠ OCR là ngoại lệ đáng nhớ: ⚠ ảnh vào → chữ ra, ⚠ nên xếp vào ⚠ thị giác.

Từ khoá nhận diện:

"lời nói, phiên âm" → ⚠ NLP / Speech "chữ TRONG ẢNH" → ⚠ Computer Vision (OCR) "phân tích văn bản có sẵn" → ⚠ NLP "vật thể trong ảnh" → ⚠ Computer Vision

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đầu vào thật sự là gì | ⚠ quyết định lĩnh vực | | Có cần ghép nhiều dịch vụ không | | | OCR hay STT là bước đầu tiên | |

Và cái bẫy phân loại hay gặp nhất ở đề Fundamentals, đủ để mất điểm một câu dễ: OCR cho ra chữ nhưng thuộc thị giác máy tính. Phân loại theo dữ liệu ĐI VÀO, không phải theo kết quả đi ra.

Đáp án

A — Nhận diện và ĐỌC CHỮ trong ảnh.

Vì sao đúng

⚠ OCR chuyển chữ trong ảnh thành văn bản máy đọc được:

⚠ Ảnh chụp biển hiệu / hoá đơn / sách quét
        ↓ ⚠ OCR
⚠ "Cà Phê & Code — 25.000đ"
        ↓
⚠ Chuỗi văn bản + toạ độ + độ tin cậy

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

• B (phân loại đối tượng trong ảnh) — ⚠ image classification hoặc object detection.

• C (phân tích cảm xúc trong ảnh) — ⚠ không phải việc của OCR; ⚠ cảm xúc là khái niệm văn bản.

• D (nhận ra khuôn mặt quen) — ⚠ facial recognition.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #17977 ở đợt trước — ⚠ #17977 hỏi API nào đọc chữ trong ảnh (Read API), ⚠ câu này hỏi chức năng chính của OCR; ⚠ cùng nội dung, không mâu thuẫn.

⚠ OCR trong Azure — hai lựa chọn: | Lựa chọn | Dùng khi | |---|---| | ⚠ AI Vision Read | ⚠ đọc chữ THUẦN TUÝ, ảnh và PDF | | ⚠ Document Intelligence | ⚠ cần TRƯỜNG DỮ LIỆU có cấu trúc |

Từ khoá nhận diện:

"đọc chữ trong ảnh" → ⚠ OCR / Read "trích số hoá đơn, ngày, tổng tiền thành trường" → ⚠ Document Intelligence "chữ viết tay" → ⚠ Read có hỗ trợ, độ chính xác thấp hơn "chữ trong video" → ⚠ Video Indexer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần chuỗi chữ hay cần trường dữ liệu | ⚠ Read hay Document Intelligence | | Chữ in hay chữ viết tay | | | Có kiểm điểm tin cậy trước khi nhập vào hệ thống không | |

Và ranh giới giúp chọn đúng giữa hai dịch vụ đọc chữ của Azure: Read cho bạn CHỮ, Document Intelligence cho bạn TRƯỜNG DỮ LIỆU. Cần biết "tổng tiền là bao nhiêu" chứ không chỉ "trên ảnh viết gì" thì đó là Document Intelligence.

Đáp án

A — Một phương pháp GOM các điểm dữ liệu GIỐNG NHAU thành nhóm.

Vì sao đúng

⚠ Clustering là học KHÔNG giám sát — không có nhãn cho trước:

⚠ Dữ liệu KHÔNG có nhãn
        ↓
⚠ Thuật toán tự tìm cấu trúc
        ↓
⚠ Nhóm 1, Nhóm 2, Nhóm 3
        ↓
⚠ CON NGƯỜI đặt tên và diễn giải các nhóm

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

• B (tìm MỘT giá trị đầu ra từ các đặc trưng đầu vào) — ⚠ mô tả hồi quy hoặc phân loại, ⚠ đều là học có giám sát.

• C (dự đoán giá trị tương lai từ giá trị quá khứ) — ⚠ forecasting.

• D (xác định dữ liệu có tương quan không) — ⚠ phân tích tương quan trong thống kê, không phải gom cụm.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #17987 ở đợt trước — ⚠ cùng khoá gom cụm, ⚠ #17987 hỏi qua tình huống phân khúc khách hàng còn câu này hỏi định nghĩa.

⚠ Có giám sát và không giám sát — bảng phân biệt: | Loại | Có nhãn | Bài toán | |---|---|---| | ⚠ Có giám sát | ⚠ CÓ | ⚠ classification, regression | | ⚠ Không giám sát | ⚠ KHÔNG | ⚠ clustering, giảm chiều |

Từ khoá nhận diện:

"tự tìm nhóm, chưa biết trước có nhóm nào" → ⚠ clustering "phân vào các loại ĐÃ BIẾT" → ⚠ classification "dữ liệu chưa gán nhãn" → ⚠ học không giám sát "phân khúc khách hàng" → ⚠ clustering

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu đã có nhãn chưa | ⚠ quyết định có giám sát hay không | | Số cụm có ý nghĩa nghiệp vụ không | | | Mỗi cụm sẽ được đối xử khác nhau thế nào | |

Và câu hỏi quyết định một kết quả gom cụm có giá trị hay chỉ là bức tranh đẹp: đội kinh doanh sẽ làm gì KHÁC ĐI với từng nhóm? Không trả lời được thì số cụm bao nhiêu cũng vậy.

Đáp án

B — Bảo đảm giải pháp AI có ĐẠO ĐỨC (ethical).

Vì sao đúng

⚠ Responsible AI là khung ĐẠO ĐỨC, không phải khung kỹ thuật:

⚠ Câu hỏi kỹ thuật
   ⚠ "Có chạy được không?"
   ⚠ "Có nhanh không?"
   ⚠ "Có chính xác không?"

⚠ Câu hỏi đạo đức
   ⚠ "CÓ NÊN làm không?"
   ⚠ "Ai bị ảnh hưởng?"
   ⚠ "Có công bằng không?"

⚠ Sáu nguyên tắc của Microsoft đều phục vụ mục tiêu này: ⚠ công bằng, tin cậy và an toàn, riêng tư và bảo mật, bao trùm, minh bạch, trách nhiệm giải trình.

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

• D (bảo đảm chính xác) — ⚠ bẫy mạnh nhất: ⚠ chính xác là ⚠ một phần của reliability, ⚠ nhưng một hệ thống rất chính xác vẫn có thể ⚠ bất công, xâm phạm riêng tư, không giải trình được.

• A (nhanh) và C (dễ dùng) — ⚠ thuộc chất lượng sản phẩm, ⚠ không phải mục tiêu của AI có trách nhiệm.

Ghi nhớ

⚠ Sáu nguyên tắc — nhớ bằng câu hỏi: | Nguyên tắc | Câu hỏi | |---|---| | ⚠ Fairness | ⚠ có ai bị thiệt không | | ⚠ Reliability & Safety | ⚠ có chạy đúng và an toàn không | | ⚠ Privacy & Security | ⚠ dữ liệu có được bảo vệ không | | ⚠ Inclusiveness | ⚠ ai cũng dùng được không | | ⚠ Transparency | ⚠ người ta có hiểu không | | ⚠ Accountability | ⚠ ai chịu trách nhiệm |

Từ khoá nhận diện:

"đạo đức, có trách nhiệm" → ⚠ Responsible AI "nhanh, dễ dùng, rẻ" → ⚠ chất lượng sản phẩm, không phải responsible AI "chính xác" → ⚠ chỉ là MỘT phần của reliability

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có thể bị hệ thống này gây hại | | | Đã đo theo từng nhóm chưa | | | Có người chịu trách nhiệm cụ thể chưa | |

Và câu hỏi mà toàn bộ khung AI có trách nhiệm rút gọn lại được, quan trọng hơn mọi câu hỏi kỹ thuật: "chúng ta CÓ NÊN xây thứ này không?" — hỏi trước khi hỏi có xây được hay không.

Đáp án

A — Dự đoán một email có phải thư rác hay không.

Vì sao đúng

⚠ Đầu ra là NHÃN rời rạc, chỉ hai khả năng — phân loại nhị phân:

⚠ Email vào
   ⚠ từ khoá, người gửi, liên kết
        ↓ ⚠ mô hình phân loại
⚠ SPAM hoặc KHÔNG SPAM
        ↓
⚠ Nhãn, không phải con số

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

• B (ước lượng TUỔI từ ảnh) — ⚠ đầu ra là SỐ → hồi quy (⚠ trên dữ liệu ảnh).

• C (dự báo giá cổ phiếu tháng tới) — ⚠ hồi quy / forecasting.

• D (dự đoán doanh số quý tới) — ⚠ hồi quy / forecasting.

⚠ Ba phương án sai đều cho ra CON SỐ — ⚠ đó là dấu hiệu nhận ra ngay.

Ghi nhớ

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

⚠ Nhận dạng nhanh trong phòng thi: | Đầu ra | Bài toán | |---|---| | ⚠ Có / Không, Loại A / B / C | ⚠ classification | | ⚠ Một con số bất kỳ | ⚠ regression | | ⚠ Nhóm chưa biết trước | ⚠ clustering | | ⚠ Lạ hay bình thường | ⚠ anomaly detection |

Từ khoá nhận diện:

"có phải... không" → ⚠ phân loại nhị phân "ước lượng, dự báo con số" → ⚠ hồi quy "tháng tới, quý tới" → ⚠ forecasting "phân nhóm khách hàng" → ⚠ clustering

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đầu ra là nhãn hay con số | | | Loại lỗi nào tốn kém hơn | ⚠ quyết định ngưỡng | | Bài toán có đối thủ chủ động không | ⚠ quyết định tần suất huấn luyện lại |

Và điều làm lọc thư rác khác hẳn phần lớn bài toán học máy khác, dù nhìn qua rất giống: có người ở phía bên kia đang chủ động tìm cách vượt qua mô hình của bạn. Đó là lý do nó phải được huấn luyện lại liên tục.