Mở đầu — vì sao bài này quan trọng
Trong hai năm trở lại đây, "AI" trở thành từ khóa mà gần như mọi cuộc họp sản phẩm đều nhắc tới. Nhà đầu tư hỏi "sản phẩm của bạn dùng AI ở đâu?", CEO gửi email lúc nửa đêm với dòng chữ "chúng ta cần có AI", và đội ngũ thì lao vào tích hợp một con chatbot vào góc màn hình mà chẳng ai thực sự dùng. Đây chính là cái bẫy lớn nhất khi xây dựng sản phẩm AI: nhầm lẫn giữa việc dùng AI và việc giải quyết được vấn đề của người dùng.
Bài học đầu tiên của cả khóa — và cũng là bài quan trọng nhất — không dạy bạn cách gọi API hay chọn mô hình. Nó dạy bạn một kỹ năng đắt giá hơn nhiều: biết khi nào nên dùng AI, và quan trọng hơn, khi nào KHÔNG nên. Đây là kỹ năng phân biệt giữa một product builder giỏi và một người chạy theo trend. Vì mỗi lần bạn đặt AI vào chỗ không phù hợp, bạn đang đánh đổi độ tin cậy, chi phí, thời gian phát triển và niềm tin của người dùng — những thứ rất khó lấy lại.
Hãy nghĩ về AI như một loại nguyên liệu đắt tiền và mạnh mẽ, giống như ớt trong món ăn: đúng chỗ thì tuyệt vời, sai chỗ thì hỏng cả bữa. Mục tiêu của bài này là giúp bạn có được "khẩu vị" để quyết định.
Khái niệm cốt lõi
Trước khi bàn về "khi nào", ta cần thống nhất một định nghĩa thực dụng. Trong khóa này, khi nói "AI" ta chủ yếu ám chỉ hai nhóm: (1) các mô hình machine learning học từ dữ liệu lịch sử để dự đoán/phân loại, và (2) các mô hình ngôn ngữ lớn (LLM) như GPT, Claude, Gemini có khả năng hiểu và tạo ra ngôn ngữ tự nhiên. Điểm chung của cả hai là chúng đưa ra kết quả mang tính xác suất (probabilistic), không phải tất định (deterministic). Đây là đặc điểm nền tảng quyết định mọi thứ.
AI phù hợp với bài toán nào?
Có năm dạng bài toán mà AI thực sự tỏa sáng, và bạn nên ghi nhớ như một checklist:
1. Nhận diện mẫu ở quy mô lớn (pattern recognition at scale). Khi bạn có hàng triệu điểm dữ liệu và cần tìm ra quy luật mà con người không thể xử lý thủ công — ví dụ phát hiện giao dịch gian lận trong hàng triệu giao dịch thẻ mỗi ngày. Con người không thể ngồi kiểm tra từng cái, nhưng mô hình học được "dấu vân tay" của gian lận.
2. Cá nhân hóa (personalization). Khi mỗi người dùng cần một trải nghiệm khác nhau và bạn không thể viết tay quy tắc cho từng người. Gợi ý sản phẩm trên Shopee, gợi ý bài hát trên Spotify — không lập trình viên nào ngồi viết "nếu người này thích A thì gợi ý B" cho 50 triệu người.
3. Hiểu ngôn ngữ tự nhiên (natural language understanding). Khi đầu vào là ngôn ngữ lộn xộn của con người — email khiếu nại, tin nhắn chat, bình luận — và bạn cần trích xuất ý định, phân loại cảm xúc, hay tóm tắt. Đây là địa hạt của LLM.
4. Dự đoán từ dữ liệu lịch sử (prediction). Khi quá khứ có khả năng cho biết tương lai: dự báo nhu cầu tồn kho, dự đoán khách hàng nào sắp rời bỏ (churn), ước tính thời gian giao hàng.
5. Tự động hóa các tác vụ mờ, không có quy tắc rõ ràng. Những việc mà "ai làm cũng ra kết quả hơi khác nhau" — như viết bản nháp email, phân loại tài liệu, kiểm duyệt nội dung sơ bộ.
Khi nào KHÔNG nên dùng AI?
Đây là phần mà đa số tài liệu bỏ qua, nhưng lại là phần tạo ra giá trị lớn nhất cho bạn với tư cách người xây sản phẩm. Hãy tránh AI khi:
Bài toán có quy tắc rõ ràng và cố định. Nếu bạn có thể viết ra được "nếu X thì Y" một cách trọn vẹn, hãy dùng câu lệnh if-else, đừng dùng AI. Tính thuế VAT 10%, kiểm tra mật khẩu đủ 8 ký tự, tính tổng đơn hàng — đây là toán và logic, không phải AI. Dùng AI cho những việc này là lãng phí, chậm, đắt và kém tin cậy hơn.
Bạn cần kết quả chính xác 100% và có thể kiểm chứng. AI mang tính xác suất, nên nó có thể sai. Nếu một lỗi nhỏ gây hậu quả nghiêm trọng và bạn không có lớp kiểm soát — ví dụ tính lãi suất khoản vay, chuyển tiền, kê đơn thuốc mà không có bác sĩ duyệt — thì AI không nên là người ra quyết định cuối cùng.
Không đủ hoặc không có dữ liệu. Mô hình ML cần dữ liệu lịch sử để học. Nếu bạn là startup mới với vài trăm người dùng, mô hình gợi ý "xịn" của bạn sẽ chẳng có gì để học. (Điểm này ta sẽ đào sâu ở Bài 2 về Data Strategy — ở đây chỉ cần nhớ nguyên tắc.)
Chi phí sai lầm cao hơn giá trị mang lại. Luôn hỏi: "Nếu AI đoán sai, chuyện gì xảy ra?" Nếu câu trả lời là "khách mất niềm tin và không bao giờ quay lại" trong khi giá trị chỉ là "tiết kiệm 3 giây", thì phép tính này không hợp lý.
Một câu thần chú tôi muốn bạn nhớ: "AI để làm việc con người không làm được ở quy mô đó, không phải để thay việc mà một dòng code làm tốt hơn."
Tình huống thực tế
Ví dụ 1 — Tiki và bài toán gợi ý sản phẩm (AI đúng chỗ)
Một sàn thương mại điện tử như Tiki xử lý hàng triệu lượt truy cập mỗi ngày với hàng trăm nghìn SKU sản phẩm. Giả sử đội sản phẩm muốn tăng tỷ lệ chuyển đổi ở trang chủ. Có hai lựa chọn: viết tay các quy tắc ("ai mua sách thì gợi ý bút") hoặc dùng mô hình gợi ý học từ hành vi.
Đây là ca AI đúng chỗ: dữ liệu khổng lồ (đủ để học), mỗi người dùng cần trải nghiệm riêng (personalization), và quan trọng — chi phí của một gợi ý sai rất thấp. Nếu hệ thống gợi ý sai một sản phẩm, người dùng chỉ đơn giản lướt qua, không có thiệt hại. Nhưng nếu gợi ý đúng, giá trị cộng dồn trên hàng triệu lượt là rất lớn. Giả định một con số: nếu mô hình nâng tỷ lệ click-through từ 2% lên 2,6%, trên nền doanh thu lớn thì đó là hàng chục tỷ đồng mỗi năm.
Bài học rút ra: AI tỏa sáng khi quy mô lớn, cá nhân hóa cao, và chi phí sai lầm thấp — vì bạn có thể chấp nhận sai một chút để đổi lấy giá trị trung bình cao hơn nhiều.
Ví dụ 2 — Fintech VN tính lãi suất bằng LLM (AI sai chỗ)
Tôi từng chứng kiến một startup fintech Việt Nam, trong cơn hào hứng với LLM, quyết định để một chatbot AI "tư vấn và tính toán khoản trả góp" cho khách. Người dùng nhập số tiền vay và kỳ hạn, chatbot trả lời số tiền phải trả hàng tháng bằng ngôn ngữ tự nhiên.
Vấn đề nghiêm trọng nảy sinh: LLM đôi khi tính sai số học. Có lần nó báo mức trả hàng tháng lệch vài trăm nghìn đồng so với con số đúng. Với một sản phẩm tài chính, đây không phải "lỗi nhỏ dễ thương" — đó là rủi ro pháp lý, mất niềm tin, và có thể vi phạm quy định. Bài toán tính lãi suất có công thức toán học chính xác 100%, hoàn toàn không cần AI.
Cách làm đúng là: dùng công thức tính toán tất định (một hàm code) để ra con số chính xác, rồi nếu muốn mới dùng LLM để diễn giải con số đó thành lời văn thân thiện. Tức là AI đóng vai "người dẫn chuyện", còn phần tính toán then chốt phải do logic tất định đảm nhiệm.
Bài học rút ra: Đừng dùng AI cho việc có công thức rõ ràng và đòi hỏi độ chính xác tuyệt đối. Hãy tách bạch "phần tính toán" (dùng code) và "phần diễn đạt" (có thể dùng AI).
Ví dụ 3 — Trung tâm chăm sóc khách hàng phân loại ticket (ranh giới hỗn hợp)
Một doanh nghiệp SaaS ở Đông Nam Á nhận khoảng 5.000 email hỗ trợ mỗi ngày bằng nhiều thứ tiếng (Việt, Anh, Thái). Họ muốn tự động phân loại email vào đúng phòng ban và ưu tiên các ca khẩn.
Đây là ca ranh giới thú vị. Phân loại ý định từ ngôn ngữ tự nhiên lộn xộn — đúng là việc của AI (natural language understanding). Nhưng đội ngũ thông minh không giao toàn quyền cho AI. Họ thiết kế theo mức độ tin cậy: khi mô hình tự tin trên 90%, tự động định tuyến; khi dưới ngưỡng đó, chuyển cho nhân viên xem. Kết quả giả định: 70% email được tự động phân loại đúng, giảm tải đáng kể, trong khi 30% khó vẫn có con người xử lý.
Bài học rút ra: Nhiều bài toán không phải "có/không dùng AI" mà là "dùng AI đến đâu". Thiết kế cơ chế human-in-the-loop (con người trong vòng lặp) cho phép bạn tận dụng AI mà vẫn kiểm soát được rủi ro ở phần đuôi khó nhằn.
Hướng dẫn từng bước
Khi đứng trước một tính năng và phân vân "có nên dùng AI không?", hãy chạy qua khung 6 bước sau. Đây là quy trình bạn có thể áp dụng ngay trong buổi họp sản phẩm tiếp theo:
Bước 1 — Phát biểu vấn đề trước, công nghệ sau. Viết ra một câu: "Người dùng đang gặp khó khăn gì?" mà không nhắc đến từ "AI". Nếu bạn không viết nổi câu này, bạn chưa sẵn sàng để quyết định gì cả.
Bước 2 — Hỏi: bài toán này có quy tắc rõ ràng không? Nếu bạn (hoặc một chuyên gia) có thể viết ra toàn bộ logic dưới dạng if-else trong vòng một buổi, thì hãy dùng code thường. Bỏ qua AI.
Bước 3 — Kiểm tra "chữ ký" của AI. Bài toán có ít nhất một trong năm đặc điểm sau không: quy mô lớn, cần cá nhân hóa, xử lý ngôn ngữ tự nhiên, dự đoán từ lịch sử, hoặc tác vụ mờ không có quy tắc cứng? Nếu không có cái nào, khả năng cao bạn không cần AI.
Bước 4 — Đánh giá chi phí của sai lầm. Vẽ một ma trận 2x2: trục dọc là "AI sai thường xuyên đến đâu", trục ngang là "mỗi lần sai gây hại đến đâu". Chỉ những ô "sai ít + hại nhẹ" hoặc "hại nhẹ dù sai nhiều" mới là vùng an toàn để AI tự chủ. Ô "hại nặng" bắt buộc phải có con người hoặc lớp kiểm soát tất định.
Bước 5 — Kiểm tra dữ liệu và giải pháp thay thế. Bạn có đủ dữ liệu chưa? Có giải pháp không-AI nào rẻ hơn, nhanh hơn không? Nhiều khi một bảng tra cứu (lookup table) hoặc một quy tắc heuristic đơn giản đã đủ tốt cho phiên bản đầu.
Bước 6 — Thiết kế mức độ tự chủ. Nếu quyết định dùng AI, đừng mặc định giao toàn quyền. Chọn một trong ba mức: (a) AI gợi ý, con người quyết; (b) AI tự làm nhưng có ngưỡng tin cậy để chuyển cho người; (c) AI tự chủ hoàn toàn — chỉ dành cho ô "hại nhẹ".
Chạy đủ 6 bước, bạn sẽ có một quyết định có lập luận, thay vì quyết định theo cảm xúc hay áp lực trend.
Lỗi thường gặp & mẹo
Lỗi 1 — "Giải pháp đi tìm vấn đề". Đây là lỗi phổ biến nhất: có sẵn LLM rồi mới đi tìm chỗ nhét vào. Dấu hiệu nhận biết: tính năng bắt đầu bằng "chúng ta hãy thêm AI vào..." thay vì "người dùng đang khổ vì...". Mẹo: luôn viết vấn đề trước, cấm nhắc chữ AI trong câu đầu tiên.
Lỗi 2 — Dùng LLM cho việc tính toán/logic thuần. Như ví dụ fintech ở trên. Mẹo: nếu có công thức, dùng code; chỉ để AI làm phần ngôn ngữ, phần mờ.
Lỗi 3 — Quên tính tổng chi phí sở hữu. Người mới thường chỉ nhìn "AI làm được không" mà quên chi phí ẩn: tiền gọi API mỗi request, độ trễ (latency) làm chậm trải nghiệm, công sức bảo trì khi mô hình "trôi" theo thời gian. Một tính năng AI đẹp trên demo có thể lỗ nặng khi lên quy mô thật. Mẹo: ước tính chi phí trên 1.000 người dùng ngay từ đầu.
Lỗi 4 — Bỏ qua phương án đơn giản. Đôi khi một quy tắc heuristic (ví dụ "sắp xếp theo mức độ phổ biến") đạt 80% hiệu quả của mô hình phức tạp với 5% công sức. Mẹo: luôn xây một "baseline không-AI" để so sánh. Nếu AI không thắng baseline rõ rệt, đừng dùng AI.
Lỗi 5 — Giao toàn quyền cho AI ở nơi rủi ro cao. Mẹo: mặc định thiết kế human-in-the-loop, chỉ nới lỏng khi đã đo được độ tin cậy thực tế.
Mẹo tổng quát: Hãy coi AI là một thành phần trong hệ thống, không phải toàn bộ hệ thống. Sản phẩm AI tốt nhất thường là 20% AI và 80% kỹ thuật phần mềm truyền thống bao quanh nó — làm nhiệm vụ kiểm tra, dự phòng, và đảm bảo an toàn.
Bài tập thực hành
Hãy dành 30–45 phút làm bài tập sau. Nó sẽ rèn đúng cái "khẩu vị" mà bài này muốn xây dựng.
Phần A — Phân loại nhanh. Với mỗi tính năng dưới đây, hãy quyết định: Dùng AI, Không dùng AI, hay Hỗn hợp (human-in-the-loop), và viết một câu lý do:
- Tính tổng tiền giỏ hàng có mã giảm giá.
- Tự động viết bản nháp trả lời email khiếu nại của khách.
- Phát hiện tài khoản đăng nhập bất thường (có thể bị hack).
- Kiểm tra một email có đúng định dạng hợp lệ không.
- Gợi ý khóa học tiếp theo cho học viên trên nền tảng.
- Duyệt hồ sơ vay và quyết định giải ngân tự động.
Phần C — Tìm lỗi. Nhớ lại một sản phẩm bạn từng dùng có tính năng AI khiến bạn khó chịu hoặc thấy vô nghĩa. Nó rơi vào lỗi nào trong 5 lỗi ở trên? Nếu là bạn, bạn sẽ thiết kế lại thế nào?
Gợi ý đáp án Phần A để bạn tự đối chiếu: (1) Không AI — thuần toán học; (2) Dùng AI — ngôn ngữ tự nhiên, nhưng nên có người duyệt trước khi gửi; (3) Hỗn hợp — AI phát hiện mẫu bất thường nhưng cảnh báo/xác minh nên có bước xác nhận; (4) Không AI — có quy tắc regex rõ ràng; (5) Dùng AI — cá nhân hóa từ hành vi, chi phí sai thấp; (6) Hỗn hợp bắt buộc — AI có thể chấm điểm rủi ro nhưng quyết định giải ngân phải có kiểm soát vì hại nặng.
Tóm tắt
Bài học đầu tiên và nền tảng nhất khi xây sản phẩm AI không phải là kỹ thuật, mà là phán đoán. Hãy khắc ghi những điểm sau:
- AI đưa ra kết quả mang tính xác suất, nên nó phù hợp với năm loại bài toán: nhận diện mẫu ở quy mô lớn, cá nhân hóa, hiểu ngôn ngữ tự nhiên, dự đoán từ lịch sử, và tự động hóa tác vụ mờ.
- Đừng dùng AI khi bài toán có quy tắc rõ ràng, đòi hỏi chính xác tuyệt đối, thiếu dữ liệu, hoặc khi chi phí sai lầm cao hơn giá trị mang lại.
- Câu hỏi vàng luôn là: "Nếu AI đoán sai thì chuyện gì xảy ra?" Câu trả lời quyết định bạn có được phép dùng AI, và dùng đến mức tự chủ nào.
- Nhiều bài toán không phải "có/không" mà là "đến đâu" — hãy thiết kế human-in-the-loop với ngưỡng tin cậy.
- Sản phẩm AI xuất sắc thường là một lõi AI nhỏ được bao quanh bởi kỹ thuật phần mềm vững chắc lo phần an toàn và dự phòng.