Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều người làm sản phẩm AI phải học theo cách khó khăn: xây dựng một sản phẩm AI tốt hiếm khi là công việc của một người. Ở các bài trước, bạn đã học về RAG, fine-tuning, evaluations, embeddings — những kỹ thuật cốt lõi. Nhưng khi bước vào một tổ chức thật, bạn sẽ nhận ra rằng phần lớn thất bại của dự án AI không đến từ việc mô hình kém, mà đến từ việc con người phối hợp với nhau kém.
Trong một đội ngũ sản phẩm AI hiện đại, bạn sẽ làm việc cạnh những người có nền tảng rất khác mình: ML engineer (kỹ sư máy học) — người hiểu sâu về mô hình, dữ liệu huấn luyện, độ chính xác thống kê; AI engineer — người ghép các API mô hình lại thành tính năng; và product manager (PM) — người quyết định làm gì và tại sao. Ba nhóm này nói ba "ngôn ngữ" khác nhau. ML engineer nói về F1-score, recall, drift dữ liệu. AI engineer nói về prompt, latency, token cost. PM nói về retention, conversion, tuần lễ ra mắt.
Nếu bạn không hiểu cách những vai trò này khớp với nhau, bạn sẽ rơi vào những tình huống kinh điển: PM hứa với khách một tính năng mà ML engineer bảo "cần 3 tháng thu thập dữ liệu"; AI engineer tự sửa mô hình rồi làm hỏng pipeline mà ML engineer đã dày công tối ưu; hoặc cả đội cãi nhau vì không ai định nghĩa được "tốt" nghĩa là gì. Bài này dạy bạn cách làm việc hiệu quả với ML engineer — nhóm vai trò khó phối hợp nhất nhưng thường quyết định chất lượng lõi của sản phẩm AI.
Khái niệm cốt lõi
Ba vai trò, ba tư duy
Trước khi phối hợp, bạn cần hiểu rõ ranh giới trách nhiệm. Đây là mô hình phổ biến ở các đội sản phẩm AI năm 2026:
Product Manager (PM) — trả lời câu hỏi cái gì, tại sao, khi nào. PM sở hữu bài toán kinh doanh: người dùng cần gì, tính năng nào tạo giá trị, ưu tiên ra sao. PM không cần biết cách huấn luyện mô hình, nhưng cần hiểu đủ để biết đâu là kỳ vọng khả thi.
AI Engineer — xây tính năng bằng API mô hình có sẵn (GPT, Claude, Gemini...). Họ giỏi prompt engineering, RAG, ghép nối hệ thống, tối ưu latency và chi phí token. Họ tư duy như một software engineer: ship nhanh, lặp nhanh, đo bằng metric sản phẩm.
ML Engineer — làm việc ở tầng sâu hơn: huấn luyện hoặc fine-tune mô hình, xây pipeline dữ liệu, thiết kế eval thống kê, xử lý drift, tối ưu inference. Họ tư duy như một nhà khoa học ứng dụng: quan tâm phân phối dữ liệu, độ tin cậy thống kê, khả năng tái lập (reproducibility). Với ML engineer, "nó chạy được trên máy tôi" chưa đủ — họ cần biết nó chạy đúng trên phân phối dữ liệu thực tế.
Điểm mấu chốt: ranh giới giữa AI engineer và ML engineer đang mờ dần, và đây chính là nơi xung đột hay xảy ra. Ai sở hữu prompt? Ai sở hữu eval? Khi mô hình sai, ai chịu trách nhiệm — người viết prompt hay người huấn luyện? Một đội không rõ ranh giới sẽ mất hàng tuần chỉ để tranh cãi "đây là việc của ai".
Vì sao ML engineer khó phối hợp hơn bạn tưởng
ML engineer làm việc với sự bất định (uncertainty) như một phần bản chất công việc. Một software engineer bình thường viết code, chạy test, xanh là xong. Một ML engineer thì phải chấp nhận rằng mô hình có thể đạt 92% chính xác hôm nay, rồi tụt xuống 85% tháng sau khi dữ liệu người dùng thay đổi — mà không có ai "làm gì sai" cả.
Điều này tạo ra ba khác biệt lớn về cách làm việc:
- Thời gian không tuyến tính. Fine-tune một mô hình có thể mất 2 ngày hoặc 2 tuần, tùy dữ liệu bẩn đến đâu. ML engineer ghét bị hỏi "khi nào xong?" vì họ thật sự không biết cho đến khi thử.
- Định nghĩa "xong" mơ hồ. Với tính năng thường, xong là code merge. Với ML, xong là "đạt ngưỡng metric mà PM và ML engineer đã thống nhất" — nếu chưa thống nhất ngưỡng đó từ đầu, dự án sẽ kéo dài vô tận.
- Chi phí thử nghiệm cao. Mỗi lần huấn luyện tốn tiền GPU và thời gian. ML engineer cân nhắc kỹ trước mỗi thử nghiệm, trong khi AI engineer quen với vòng lặp "sửa prompt, chạy lại trong 5 giây".
Ngôn ngữ chung: metric và eval
Cầu nối duy nhất giúp ba vai trò làm việc với nhau là một hệ metric chung mà tất cả đồng ý. Đây là lý do bài Evaluations (Bài 9) quan trọng đến vậy trong bối cảnh phối hợp. Khi PM nói "chatbot phải trả lời tốt hơn", câu đó vô nghĩa với ML engineer. Nhưng khi cả đội đồng ý "tỷ lệ trả lời đúng ý định (intent accuracy) phải đạt ≥ 88% trên bộ 500 câu hỏi vàng, và tỷ lệ ảo giác (hallucination) < 3%", thì mọi người có cùng một mục tiêu đo được.
Nhiệm vụ của bạn — dù bạn là PM hay AI engineer — là biến mọi yêu cầu mơ hồ thành metric cụ thể trước khi ML engineer bắt tay vào việc.
Tình huống thực tế
Tình huống 1 — Tiki và bài toán "ai sở hữu prompt"
Giả sử một đội tại Tiki (sàn thương mại điện tử Việt Nam) xây trợ lý tư vấn sản phẩm bằng LLM. Đội có 1 PM, 2 AI engineer và 1 ML engineer. Ban đầu, AI engineer viết toàn bộ prompt và RAG pipeline, ML engineer chỉ lo fine-tune mô hình phân loại ý định người dùng (mua hàng, khiếu nại, hỏi vận chuyển...).
Vấn đề xảy ra sau 6 tuần: AI engineer liên tục chỉnh prompt để "vá" các câu trả lời sai, trong khi ML engineer phát hiện phần lớn lỗi thực ra đến từ mô hình phân loại ý định gán sai nhãn. Hai bên đổ lỗi cho nhau. AI engineer bảo "mô hình của anh phân loại sai"; ML engineer bảo "prompt của các cậu không dùng đúng ý định tôi trả về". Mỗi lần sửa một bên lại làm hỏng bên kia.
Cách họ giải quyết: đội ngồi lại vẽ một sơ đồ trách nhiệm (ownership map). Họ chia hệ thống thành các tầng rõ ràng — tầng phân loại ý định (ML engineer sở hữu, cam kết ≥ 90% accuracy), tầng truy xuất tài liệu (AI engineer sở hữu), tầng sinh câu trả lời (AI engineer sở hữu prompt, nhưng eval do cả hai cùng duyệt). Quan trọng nhất, họ xây một bộ eval chung với 300 hội thoại thật, và mỗi thay đổi ở bất kỳ tầng nào đều phải chạy qua bộ eval này trước khi merge.
Bài học: xung đột không phải do năng lực, mà do thiếu ranh giới rõ ràng và thiếu một nguồn sự thật chung để phân định đúng sai. Ownership map + shared eval giải quyết 80% mâu thuẫn.
Tình huống 2 — Startup fintech và cú hứa hẹn tai hại
Một startup fintech ở TP.HCM (khoảng 25 người) xây tính năng chấm điểm rủi ro tín dụng bằng ML. PM, dưới áp lực từ một khách hàng ngân hàng lớn, hứa sẽ giao mô hình đạt "độ chính xác 95%" trong 4 tuần. PM không hỏi ý ML engineer trước khi hứa.
Khi ML engineer nhận yêu cầu, cô ấy chỉ ra vấn đề: dữ liệu lịch sử chỉ có 8.000 mẫu, trong đó số ca vỡ nợ (nhãn dương) chỉ chiếm 4% — mất cân bằng nghiêm trọng. Với dữ liệu như vậy, "95% accuracy" là con số vô nghĩa: chỉ cần đoán "không vỡ nợ" cho mọi hồ sơ đã đạt 96% accuracy rồi, nhưng mô hình đó hoàn toàn vô dụng vì bỏ sót toàn bộ ca rủi ro. Metric đúng phải là recall trên nhóm vỡ nợ và AUC, không phải accuracy.
Kết quả: đội mất 2 tuần đầu chỉ để "dịch" lại lời hứa của PM thành metric có ý nghĩa, thương lượng lại với khách hàng, và điều chỉnh kỳ vọng. Suýt mất hợp đồng.
Bài học: PM không được hứa metric AI khi chưa hỏi ML engineer. Với sản phẩm AI, kỳ vọng phải được đồng thiết kế. Một cuộc họp 30 phút trước khi hứa với khách có thể tiết kiệm hàng tuần và cứu cả một thương vụ. Đồng thời, người làm sản phẩm cần hiểu đủ về metric để không bị con số đẹp (accuracy) đánh lừa trong bài toán mất cân bằng dữ liệu.
Tình huống 3 — Đội y tế và vòng lặp phản hồi bị đứt
Một công ty y tế số ở Singapore xây công cụ tóm tắt hồ sơ bệnh án cho bác sĩ. AI engineer dựng nhanh phiên bản dùng API Claude, ship trong 3 tuần, người dùng khen. Nhưng khi ML engineer muốn cải thiện chất lượng bằng fine-tuning, cô phát hiện đội không hề lưu lại phản hồi của bác sĩ (bác sĩ sửa gì trong bản tóm tắt, chấp nhận hay bỏ). Không có dữ liệu phản hồi, không thể huấn luyện cải tiến — data flywheel (bài 28) bị đứt ngay từ đầu.
Nguyên nhân: AI engineer tối ưu cho tốc độ ra mắt, còn ML engineer nghĩ về vòng đời dài hạn của mô hình. Hai tư duy này không được đồng bộ từ ngày đầu.
Cách khắc phục: đội thêm một quy tắc — mọi tính năng AI, ngay từ MVP, phải ghi log input, output, và tín hiệu phản hồi của người dùng (dù ban đầu chưa dùng đến). ML engineer được mời vào từ giai đoạn thiết kế, không phải khi cần "cứu chất lượng".
Bài học: mời ML engineer vào từ đầu, kể cả khi bản đầu tiên chỉ dùng API. Quyết định về logging và dữ liệu phản hồi phải có mặt ML engineer, vì họ là người nhìn xa nhất về nhu cầu dữ liệu tương lai.
Hướng dẫn từng bước
Đây là quy trình phối hợp thực tế bạn có thể áp dụng cho mọi tính năng AI:
Bước 1 — Kick-off ba bên trước khi viết dòng code nào. Ngồi cùng PM, AI engineer, ML engineer. PM trình bày bài toán (cái gì, tại sao). Hai kỹ sư phản biện về tính khả thi. Đừng để PM tự quyết một mình rồi "ném việc qua tường".
Bước 2 — Chuyển yêu cầu thành metric đo được. Cùng nhau định nghĩa: metric chất lượng là gì, ngưỡng chấp nhận là bao nhiêu, bộ dữ liệu vàng (golden set) để đo lấy từ đâu. Viết ra thành văn bản. Đây là hợp đồng chung của cả đội.
Bước 3 — Vẽ ownership map. Chia hệ thống thành các tầng, gán rõ ai sở hữu tầng nào, ai cam kết metric nào cho tầng đó. Điểm giao (như prompt dùng output của mô hình phân loại) phải ghi rõ ai duyệt.
Bước 4 — Thống nhất một shared eval pipeline. Mọi thay đổi ở bất kỳ tầng nào đều chạy qua cùng một bộ eval trước khi merge. Đây là "trọng tài" khách quan khi có tranh cãi.
Bước 5 — Đặt log và data flywheel ngay từ MVP. Kể cả khi bản đầu chỉ dùng API, hãy để ML engineer quyết định cần log gì để phục vụ cải tiến sau này.
Bước 6 — Họp đồng bộ theo nhịp, không micromanage. Với ML engineer, thay vì hỏi "xong chưa", hãy hỏi "kết quả thử nghiệm gần nhất cho metric bao nhiêu, rào cản là gì". Chấp nhận rằng tiến độ ML là dạng thăm dò, không tuyến tính.
Lỗi thường gặp & mẹo
Lỗi 1 — PM hứa metric trước khi hỏi ML engineer. Như tình huống fintech, đây là lỗi phổ biến và tốn kém nhất. Mẹo: đặt quy tắc "không cam kết con số AI ra ngoài khi chưa có chữ ký của ML engineer".
Lỗi 2 — Coi accuracy là metric vạn năng. Trong bài toán mất cân bằng dữ liệu, accuracy đánh lừa. Mẹo: người làm sản phẩm cần biết tối thiểu về recall, precision, F1, AUC để đối thoại có ý nghĩa với ML engineer.
Lỗi 3 — Ném việc qua tường (throw over the wall). PM viết spec rồi biến mất, ML engineer làm xong rồi giao lại, ai cũng làm phần mình trong im lặng. Mẹo: dùng shared eval làm điểm gặp bắt buộc — mọi người thấy cùng một bảng kết quả.
Lỗi 4 — Mời ML engineer vào quá muộn. Gọi họ khi "chất lượng đã tệ rồi" thì thường đã mất cơ hội thu thập dữ liệu đúng. Mẹo: mời từ giai đoạn thiết kế, kể cả với MVP dùng API.
Lỗi 5 — Nhầm lẫn vai trò AI engineer và ML engineer. Bắt ML engineer đi viết prompt vặt, hoặc bắt AI engineer tự fine-tune mà không có nền tảng. Mẹo: tôn trọng chuyên môn — ML engineer giỏi nhất ở tầng mô hình và dữ liệu, đừng lãng phí họ vào việc ghép API.
Mẹo vàng — xây "từ điển chung". Nhiều xung đột chỉ là hiểu nhầm thuật ngữ. Dành 1 buổi để cả đội thống nhất: "chất lượng" nghĩa là gì, "xong" nghĩa là gì, "tốt hơn" đo bằng gì. Một trang tài liệu đơn giản này tiết kiệm hàng chục cuộc cãi vã.
Bài tập thực hành
- Vẽ ownership map cho một tính năng giả định. Lấy ví dụ chatbot chăm sóc khách hàng của một ngân hàng Việt Nam. Chia hệ thống thành các tầng (phân loại ý định, truy xuất, sinh câu trả lời, guardrail), và gán rõ AI engineer hay ML engineer sở hữu tầng nào, cam kết metric gì. Ghi rõ các điểm giao cần duyệt chung.
- Dịch yêu cầu mơ hồ thành metric. Cho câu của PM: "Tôi muốn công cụ tóm tắt tài liệu này thông minh hơn." Hãy viết lại thành 2–3 metric đo được kèm ngưỡng chấp nhận, và mô tả bộ golden set bạn cần để đo.
- Đóng vai xử lý xung đột. Viết một đoạn hội thoại ngắn (khoảng 8–10 lượt) giữa AI engineer và ML engineer đang đổ lỗi cho nhau về một câu trả lời sai. Với vai trò người điều phối, hãy chỉ ra bạn sẽ dùng công cụ gì (shared eval, ownership map) để phân định và hạ nhiệt.
- Thiết kế quy tắc logging cho MVP. Cho một tính năng gợi ý sản phẩm bằng LLM, liệt kê tối thiểu 5 loại dữ liệu bạn sẽ log ngay từ bản đầu để không làm đứt data flywheel sau này.
Tóm tắt
Làm việc với ML engineer là một trong những kỹ năng mềm quan trọng nhất nhưng ít được dạy nhất của người xây sản phẩm AI. Ba điều cần nhớ:
- Hiểu và tôn trọng sự khác biệt. PM lo cái gì/tại sao, AI engineer ghép API và ship nhanh, ML engineer làm việc ở tầng mô hình/dữ liệu với sự bất định. Ba tư duy khác nhau — đừng ép ai làm việc trái chuyên môn.
- Metric chung là ngôn ngữ chung. Biến mọi yêu cầu mơ hồ thành metric đo được và một shared eval pipeline. Đó là trọng tài khách quan cho mọi tranh cãi và là hợp đồng chung của cả đội.
- Phối hợp từ đầu, không ném việc qua tường. Kick-off ba bên, vẽ ownership map, mời ML engineer vào từ giai đoạn thiết kế, và đặt logging từ MVP để giữ vòng lặp dữ liệu.