Mở đầu — vì sao bài này quan trọng
Nếu Bài 33–38 đã giúp bạn hiểu nền tảng Machine Learning, cách đánh giá model, vòng đời MLOps, feature engineering, recommendation và search ranking, thì Bài 39 này kéo bạn xuống mặt đất: hai họ ứng dụng AI mà bạn — một Technical PM tại Việt Nam — gần như chắc chắn sẽ chạm tới trong sự nghiệp. Đó là Computer Vision (CV) — máy tính "nhìn" và Natural Language Processing (NLP) — máy tính "đọc và hiểu" ngôn ngữ.
Vì sao quan trọng? Vì đây là hai mảng AI có use case rõ ràng nhất, ROI dễ đo nhất, và dễ bị over-sell nhất. Một startup fintech ở TP.HCM muốn "AI tự động đọc CMND để mở tài khoản". Một sàn TMĐT muốn "AI tự nhận diện sản phẩm trong ảnh người bán đăng". Một ngân hàng muốn "chatbot hiểu tiếng Việt trả lời khách hàng". Tất cả đều là CV hoặc NLP. Và trong tất cả những dự án đó, người quyết định phạm vi nào khả thi, đâu là cạm bẫy, model nào "đủ tốt" — chính là PM.
Bài này không dạy bạn train model. Nó dạy bạn nói chuyện đúng ngôn ngữ với team ML, định nghĩa use case sao cho làm được, và tránh những lời hứa khiến dự án sa lầy. Khi học xong, bạn sẽ phân biệt được "use case CV/NLP nào là vài tuần, use case nào là vài quý", và biết câu hỏi nào phải hỏi trước khi gật đầu.
Khái niệm cốt lõi
Computer Vision — máy tính nhìn thấy gì
Computer Vision là tập hợp kỹ thuật giúp máy tính trích xuất thông tin có ý nghĩa từ hình ảnh và video. Là PM, bạn cần nắm vài dạng bài toán CV vì mỗi dạng có độ khó, dữ liệu và metric rất khác nhau:
- Image Classification (phân loại ảnh): trả lời "ảnh này là cái gì?" — một nhãn cho cả ảnh. Ví dụ: ảnh này là chó hay mèo; món ăn này là phở hay bún bò. Đây là bài toán dễ nhất, dữ liệu dễ gắn nhãn.
- Object Detection (phát hiện vật thể): không chỉ nói "có xe máy" mà còn vẽ bounding box — khung chữ nhật quanh từng vật và nói vị trí của chúng. Ví dụ: đếm số xe trên đường, khoanh vùng từng sản phẩm trên kệ siêu thị. Khó hơn classification vì phải gắn nhãn tọa độ.
- OCR (Optical Character Recognition): đọc chữ trong ảnh thành text. Đây là use case "ăn tiền" nhất ở Việt Nam: đọc CMND/CCCD, hóa đơn, biển số xe, hợp đồng scan. OCR tiếng Việt có dấu là một thử thách riêng — dấu sắc/huyền/hỏi/ngã dễ bị nhầm.
- Image Segmentation (phân vùng): tinh vi hơn detection — gắn nhãn từng pixel, ví dụ tách chính xác viền của một khối u trong ảnh y tế, hay tách nền khỏi người để xóa phông. Đắt nhất về gắn nhãn dữ liệu.
- Face Recognition / Liveness: nhận diện khuôn mặt và kiểm tra "người thật hay ảnh chụp lại" — cốt lõi của eKYC (định danh điện tử) trong fintech.
NLP — máy tính đọc và hiểu ngôn ngữ
NLP giúp máy xử lý văn bản và giọng nói. Các dạng bài toán PM cần biết:
- Text Classification: gắn nhãn cho đoạn text. Ví dụ: phân loại ticket CSKH thành khiếu nại / hỏi đáp / khen ngợi; sentiment analysis (phân tích cảm xúc) review sản phẩm tích cực hay tiêu cực.
- Named Entity Recognition (NER): trích xuất thực thể — tên người, địa chỉ, số tiền, ngày tháng từ văn bản. Ví dụ: bóc tách thông tin từ đơn hàng viết tay, hợp đồng.
- Information Extraction / Document Understanding: kết hợp OCR + NLP để hiểu cấu trúc tài liệu — đây chính là cách đọc hóa đơn để lấy ra "tổng tiền", "mã số thuế", "ngày xuất".
- Machine Translation: dịch máy, ví dụ Việt–Anh.
- Question Answering / Chatbot / RAG: trả lời câu hỏi dựa trên kho tri thức. Đây là vùng mà các Large Language Model (LLM như GPT, Gemini) đã thay đổi cuộc chơi: thay vì train model riêng, ta có thể dùng LLM qua API.
- Summarization: tóm tắt văn bản dài.
Một điểm quan trọng năm 2026: ranh giới đang mờ dần
Trước đây mỗi use case cần một model riêng được train từ đầu. Ngày nay, foundation model và multimodal model (vừa nhìn ảnh vừa đọc text như GPT-4o, Gemini) cho phép giải nhiều bài toán bằng cách gọi API và viết prompt tốt thay vì train. Điều này dịch chuyển vai trò PM: câu hỏi không còn chỉ là "train model nào" mà là "build hay buy" — tự train model chuyên dụng hay dùng API có sẵn của Google/AWS/OpenAI? (Đây là chủ đề bạn sẽ gặp lại sâu hơn ở Bài 53.)
Quy tắc ngón tay cái cho PM: nếu use case phổ biến (OCR CCCD, dịch, chatbot chung), buy/dùng API trước để ra mắt nhanh; chỉ tự train khi domain đặc thù (ví dụ phân loại ảnh lỗi sản phẩm trong nhà máy của riêng bạn) hoặc khi chi phí API ở quy mô lớn vượt chi phí tự host.
Tình huống thực tế
Tình huống 1 — eKYC tại một ví điện tử Việt Nam (CV: OCR + Liveness)
Một ví điện tử (giả định tên PayViet, khoảng 5 triệu user) muốn rút ngắn quy trình mở tài khoản: user chụp CCCD và selfie, hệ thống tự động đọc thông tin và xác minh khuôn mặt thay vì nhân viên duyệt tay mất 2–4 giờ.
Bài toán CV gồm ba phần: (1) OCR đọc số CCCD, họ tên, ngày sinh từ ảnh; (2) Face matching so khuôn mặt trên CCCD với selfie; (3) Liveness detection chống gian lận bằng ảnh chụp lại màn hình.
PM đặt mục tiêu: tự động hóa 80% hồ sơ, 20% còn lại (ảnh mờ, CCCD cũ) chuyển nhân viên review. Kết quả sau 3 tháng: thời gian onboarding trung bình giảm từ 3 giờ xuống 90 giây, tỷ lệ bỏ giữa chừng (drop-off) giảm 22%. Nhưng có một bài học đắt giá: ở phiên bản đầu, OCR đọc nhầm dấu tiếng Việt khiến tên "Nguyễn" thành "Nguyên" trong 4% hồ sơ, gây sai lệch khi đối chiếu với cơ sở dữ liệu quốc gia.
Bài học rút ra: PM đã định nghĩa metric sai. Họ đo "độ chính xác trên từng ký tự" (character accuracy ~98%, nghe rất đẹp), nhưng cái quan trọng là độ chính xác trên cả trường thông tin (field-level — toàn bộ họ tên phải đúng 100% ký tự mới dùng được). 98% ký tự nghĩa là một cái tên 20 ký tự có xác suất sai khá cao. Bài học: với PM, chọn metric phải khớp với hậu quả nghiệp vụ, không phải con số nào nghe oai nhất.
Tình huống 2 — Kiểm duyệt và gắn tag ảnh sản phẩm trên sàn TMĐT (CV: Classification + Detection)
Một sàn TMĐT khu vực Đông Nam Á (giả định ShopSEA) có hàng trăm nghìn người bán đăng ảnh sản phẩm mỗi ngày. Hai vấn đề: ảnh vi phạm (hàng cấm, ảnh phản cảm) lọt lưới, và người bán đăng sai danh mục khiến tìm kiếm kém.
PM chia thành hai use case: Image classification để kiểm duyệt (ảnh có vi phạm chính sách không) và detection để gợi ý danh mục (trong ảnh có gì: giày, túi, điện thoại). Họ chọn dùng API CV có sẵn của một cloud provider cho bản v1 thay vì tự train, ra mắt trong 6 tuần.
Kết quả: 70% ảnh vi phạm bị model chặn tự động trước khi cần người duyệt, đội kiểm duyệt thủ công giảm tải 60%. Nhưng model API generic không nhận diện tốt vài mặt hàng đặc thù địa phương (ví dụ một số loại thực phẩm, đặc sản vùng miền), nên độ chính xác danh mục chỉ ~75%.
Bài học rút ra: PM xử lý đúng — họ không để model tự quyết 100%. Với kiểm duyệt, model chỉ gắn cờ và sắp thứ tự ưu tiên, con người ra quyết định cuối cho ca nhạy cảm (human-in-the-loop). Với danh mục, model chỉ gợi ý, người bán xác nhận. Đây là pattern vàng cho mọi use case CV/NLP rủi ro cao: AI hỗ trợ, không thay thế hoàn toàn con người ở những quyết định có hậu quả lớn.
Tình huống 3 — Tự động phân loại và trả lời ticket CSKH (NLP: Classification + RAG)
Một công ty SaaS B2B ở Hà Nội nhận ~3.000 ticket hỗ trợ mỗi tháng, phần lớn lặp lại ("làm sao xuất hóa đơn?", "đổi mật khẩu thế nào?"). PM muốn dùng NLP để (1) tự phân loại ticket vào đúng đội, (2) gợi ý câu trả lời từ tài liệu nội bộ.
Phần phân loại dùng text classification train trên 6 tháng lịch sử ticket đã gắn nhãn — đạt độ chính xác 88%, đủ để định tuyến tự động. Phần trả lời dùng RAG (Retrieval-Augmented Generation): gọi LLM nhưng "nhồi" tài liệu nội bộ vào prompt để model trả lời dựa trên kiến thức công ty, tránh bịa.
Kết quả: thời gian phản hồi đầu tiên giảm 40%, 35% ticket đơn giản được giải quyết tự động. Nhưng giai đoạn đầu, chatbot bịa ra tính năng không tồn tại (hiện tượng hallucination — model "ảo giác" tự bịa thông tin) khi gặp câu hỏi ngoài tài liệu.
Bài học rút ra: PM thêm hai biện pháp: model phải trích dẫn nguồn (link tới đoạn tài liệu) và nếu độ tự tin thấp thì trả lời "tôi chuyển bạn cho nhân viên" thay vì cố đoán. Với NLP sinh văn bản, PM phải thiết kế hành vi khi model không chắc chắn — đây là phần quan trọng hơn cả độ chính xác trung bình.
Hướng dẫn từng bước
Khi một use case CV hoặc NLP xuất hiện trong roadmap, đây là quy trình PM nên đi:
- Phân loại bài toán cho đúng dạng. Nó là classification, detection, OCR, NER, hay generation? Việc gọi đúng tên giúp bạn ước lượng độ khó và nói chuyện chính xác với team ML. "Đọc hóa đơn" = OCR + information extraction, không phải "classification".
- Định nghĩa đầu vào/đầu ra cực kỳ cụ thể. Đầu vào là ảnh chụp điện thoại hay scan? Có giới hạn định dạng không? Đầu ra là một nhãn, một danh sách bounding box, hay một đoạn JSON? Càng mơ hồ, dự án càng dễ trượt.
- Quyết định build hay buy. Use case phổ biến → thử API có sẵn (Google Vision, AWS Textract/Rekognition, các API OCR tiếng Việt nội địa, LLM API) để ra v1 nhanh. Domain đặc thù hoặc quy mô lớn → cân nhắc tự train. Luôn làm prototype bằng API trước khi cam kết tự build.
- Chọn metric khớp hậu quả nghiệp vụ. Phân biệt precision (trong những cái model báo "có", bao nhiêu đúng) và recall (trong tất cả cái thực sự "có", model bắt được bao nhiêu). Kiểm duyệt nội dung độc hại → ưu tiên recall (đừng để lọt). Tự động duyệt hồ sơ vay → ưu tiên precision (đừng duyệt nhầm). Với OCR, đo field-level chứ đừng chỉ character-level. (Chi tiết về metric đã học ở Bài 34.)
- Thiết kế ngưỡng tự tin (confidence threshold) và human-in-the-loop. Định nghĩa: trên ngưỡng X thì tự động, dưới thì chuyển người. Đây là đòn bẩy quan trọng nhất để ra mắt an toàn — bạn có thể bắt đầu với ngưỡng cao (ít tự động, an toàn) rồi nới dần khi đo được chất lượng.
- Lên kế hoạch dữ liệu và gắn nhãn. CV/NLP sống nhờ dữ liệu. Hỏi: có bao nhiêu dữ liệu đã gắn nhãn? Ai gắn? Có dữ liệu đặc thù Việt Nam (tiếng Việt có dấu, CCCD mẫu mới, ảnh điều kiện ánh sáng thực tế) không? Đây thường là nút thắt thật sự, không phải model.
- Thiết kế vòng phản hồi (feedback loop). Khi con người sửa kết quả model, dữ liệu sửa đó phải quay lại cải thiện model. Đây là cầu nối tới MLOps ở Bài 35.
Lỗi thường gặp & mẹo
- Lỗi: hứa "AI chính xác 100%". Không model CV/NLP nào đạt 100%. Hãy hứa theo kiểu "tự động hóa X% trường hợp, phần còn lại human review" — vừa đúng kỹ thuật vừa dễ bán cho sếp.
- Lỗi: đánh giá model trên dữ liệu "sạch" của phòng lab. Demo chạy đẹp với ảnh CCCD chụp thẳng, đủ sáng. Thực tế user chụp nghiêng, mờ, ngược sáng, dán băng keo. Mẹo: luôn yêu cầu test trên dữ liệu thực tế "bẩn", thu thập ngay từ pilot nhỏ.
- Lỗi: bỏ qua đặc thù tiếng Việt. Model NLP/OCR train chủ yếu trên tiếng Anh thường yếu với dấu tiếng Việt, từ ghép, và văn phong địa phương. Mẹo: khi chọn API/model, bắt buộc benchmark riêng trên tập tiếng Việt của chính bạn.
- Lỗi: quên chi phí vận hành ở quy mô lớn. API tính theo số lần gọi. 10.000 lần/ngày thì rẻ; 10 triệu lần/ngày có thể đắt hơn tự host. Mẹo: ước tính chi phí ở quy mô mục tiêu, không phải quy mô pilot.
- Lỗi: coi nhẹ rủi ro thiên lệch và quyền riêng tư. Face recognition có thể kém chính xác với một số nhóm; dữ liệu CCCD, khuôn mặt là dữ liệu cá nhân nhạy cảm. Mẹo: phối hợp sớm với pháp lý — đây là điểm giao với Nghị định 13 ở Bài 32.
- Mẹo vàng: với mọi use case sinh văn bản (chatbot, summarization), luôn thiết kế sẵn hành vi khi model không chắc (trả lời "không biết", chuyển người, trích nguồn). Chất lượng cảm nhận của user phụ thuộc vào lúc model sai nhiều hơn lúc model đúng.
Bài tập thực hành
- Phân loại use case. Cho 5 yêu cầu sau, gọi tên đúng dạng bài toán CV/NLP: (a) đếm số khách trong cửa hàng từ camera; (b) đọc số tiền trên hóa đơn giấy; (c) phân loại bình luận Facebook là khen/chê; (d) tách nền khỏi ảnh chân dung; (e) chatbot trả lời chính sách bảo hành. Ghi rõ build-hay-buy cho từng cái và lý do.
- Chọn metric. Bạn làm PM cho tính năng tự động chặn ảnh vi phạm trên một sàn TMĐT. Bạn ưu tiên precision hay recall? Viết 3 câu giải thích hậu quả của việc chọn sai, và đề xuất ngưỡng tự tin + cơ chế human-in-the-loop.
- Viết tiêu chí "đủ tốt để ra mắt". Cho use case OCR đọc CCCD, viết 4 tiêu chí chấp nhận (acceptance criteria) cụ thể, đo được — gợi ý: dùng field-level accuracy, tỷ lệ tự động hóa, hành vi khi ảnh mờ, và benchmark trên tập tiếng Việt thực tế. (Kết nối với Bài 18 về Acceptance Criteria.)
Tóm tắt
Computer Vision giúp máy "nhìn" (classification, detection, OCR, segmentation, face/liveness) và NLP giúp máy "đọc hiểu" (classification, NER, extraction, dịch, QA/chatbot, summarization). Là Technical PM, giá trị của bạn không nằm ở việc train model mà ở việc gọi đúng tên bài toán, định nghĩa input/output rõ ràng, quyết định build-hay-buy, chọn metric khớp hậu quả nghiệp vụ, và thiết kế human-in-the-loop cùng hành vi khi model không chắc chắn.
Ba bài học cốt lõi từ thực tế: (1) chọn metric theo hậu quả nghiệp vụ chứ không theo con số nghe oai (field-level vs character-level); (2) AI hỗ trợ chứ không thay thế hoàn toàn con người ở quyết định rủi ro cao; (3) đặc thù tiếng Việt và dữ liệu thực tế "bẩn" phải được kiểm chứng từ sớm. Nắm vững những điều này, bạn sẽ biến những lời hứa AI mơ hồ thành dự án ra mắt được, đo được, và cải thiện được.