Bài 2: Điều Gì Khiến Sản Phẩm AI Khác Biệt Hoàn Toàn Với Sản Phẩm Truyền Thống?

Khi bước chân vào lĩnh vực phát triển sản phẩm AI, tôi nhanh chóng nhận ra rằng: những nguyên lý làm sản phẩm truyền thống không còn áp dụng nguyên vẹn được nữa. Dưới đây là 6 khác biệt cốt lõi bạn cần hiểu để tránh “mang mindset cũ vào sân chơi mới”.

1. Sản phẩm AI: Một hành vi, nhiều kết quả, và lý do vì sao bạn không thể test theo cách cũ

Trong phần mềm truyền thống, mọi thứ hoạt động theo logic cố định: nếu A thì B. Tức là cùng một input, bạn luôn mong đợi một output giống nhau. Điều này giúp dễ test, dễ debug, dễ dự đoán.

Trong sản phẩm truyền thống, tính nhất quán (determinism) là yếu tố quan trọng: người dùng mong đợi hành vi giống nhau cho cùng một thao tác. Nhưng AI, đặc biệt là mô hình tạo sinh (Generative AI), lại có tính non-deterministic – nghĩa là kết quả có thể khác nhau dù input giống nhau.

Tuy nhiên, với sản phẩm AI, một input có thể cho ra nhiều output khác nhau, tuỳ thuộc vào:

• Bộ dữ liệu huấn luyện
• Phiên bản mô hình
• Tham số ngữ cảnh
• Ngẫu nhiên có chủ đích trong inference (temperature sampling...)

Điều này có thể là lợi thế (đa dạng hoá kết quả, tăng cá nhân hoá, tránh nhàm chán), nhưng cũng mang rủi ro (khó test, khó kiểm soát trải nghiệm người dùng, gây mất niềm tin nếu AI "nói một đằng, lúc khác lại nói khác").

Ví dụ thực tế:

• Một khách hàng truy cập trang chủ Shopee lúc 10h sáng có thể thấy đề xuất sản phẩm khác với lúc 10h tối, vì hệ thống gợi ý theo mô hình thay đổi theo trend, thời gian, cohort, lịch sử duyệt web.
• Trên Canva, cùng một prompt “generate a modern logo with gradient” có thể ra 5 mẫu hoàn toàn khác nhau ở 5 lần bấm.

Hãy chuyển từ mindset “kiểm soát logic” sang “thiết kế xác suất + giới hạn” (guardrails), ví dụ như top-K result, sampling temperature, hoặc lựa chọn từ danh sách đã được filter trước.

2. Mỗi người dùng có một trải nghiệm khác nhau

AI mở ra khả năng cá nhân hoá ở cấp độ từng user, điều mà các sản phẩm truyền thống rất khó làm ở quy mô lớn.

Mỗi người dùng có thể thấy UI, content, gợi ý, hoặc hành vi sản phẩm khác nhau dựa trên:

• Lịch sử sử dụng
• Dữ liệu thiết bị (device, location, language)
• Dự đoán hành vi sắp tới (predictive UX)

Ví dụ thực tế:

• Spotify Daily Mix không giống nhau giữa hai tài khoản, thậm chí khi cùng nghe một thể loại nhạc. Mỗi người sẽ được “định tuyến” qua các hành trình nghe khác nhau tùy theo embedding vector của hành vi âm nhạc.
• Trong Duolingo, khi bạn chọn phần "Past Tense", hệ thống sẽ tự động tăng cường bài luyện dạng đó. Không còn bài học chung cố định như truyền thống.

Mini case study (có thể ứng dụng cho edtech/ecommerce):
Một app học ngôn ngữ triển khai AI để gợi ý từ vựng “yếu” của từng học viên dựa trên các lỗi hay gặp trong quá trình học tập. Sau 2 tuần A/B testing, nhóm dùng AI có tỷ lệ hoàn thành bài tập tăng/giảm X% và retention tăng/giảm Y% so với nhóm control.

3. Dữ liệu là động cơ chính, không phải logic code

Trong sản phẩm truyền thống, code là “trái tim” của sản phẩm. Trong sản phẩm AI, dữ liệu chính là trái tim.

• Mô hình tốt hay không phụ thuộc vào: độ đầy đủ, độ sạch, độ đúng của dữ liệu.
• Bạn không “viết logic” nữa, mà phải giao tiếp với mô hình để tự hình thành logic.
• PM phải bắt đầu quan tâm đến:
  • Data pipeline (luồng dữ liệu đầu vào)
  • Data labeling (gán nhãn đúng)
  • Bias & fairness (tránh thiên lệch)
  • Drift (dữ liệu thay đổi theo thời gian)

Ví dụ thực tế:

• Một hệ thống phân loại review sản phẩm (tốt/xấu) hoạt động kém vì training set chứa quá nhiều từ “đùa cợt” như “tệ vãi, dùng mãi không hỏng” (nhưng bị dán nhãn là negative).

Khái niệm mới: làm sản phẩm AI nghĩa là bạn phải nghĩ về vòng đời dữ liệu: từ lúc user tạo ra → được lưu → làm sạch → đưa vào huấn luyện → tạo ra behavior mới.

4. Đo lường hiệu quả không thể chỉ dùng “conversion rate”

Một tính năng AI không luôn có "đáp án đúng" duy nhất, nên bạn không thể đo lường bằng các chỉ số truyền thống như conversion rate hay click rate.

Cần thêm các chỉ số chuyên biệt:

• Precision / Recall: mức độ chính xác / bao phủ
• Latency: thời gian phản hồi
• Confidence Score: mô hình chắc chắn bao nhiêu %
• User Satisfaction: cảm nhận chủ quan

Ví dụ thực tế: Với một AI chatbot chăm sóc khách hàng:

• Nếu chỉ đo số lượng câu trả lời, bạn sẽ bỏ sót chất lượng.
• Cần đo:
  • Tỷ lệ phải chuyển sang agent người thật (escalation rate)
  • Tỷ lệ trả lời đúng trong 3 câu đầu tiên
  • Satisfaction rating sau khi kết thúc phiên

5. Mô hình cần được cập nhật và bảo trì liên tục

Phần mềm truyền thống có thể chạy 6 tháng–1 năm không cần đụng đến logic code. Nhưng AI model có thể mất hiệu quả chỉ sau vài tuần, nếu:

• Dữ liệu hành vi người dùng thay đổi
• Nội dung sản phẩm cập nhật
• Bản thân mô hình cũng thay đổi

Drift là không thể tránh khỏi. Giống như cây xanh , bạn không thể “trồng cây vào đất” là xong, mà phải chăm sóc liên tục.

Ví dụ thực tế:

• Một hệ thống phát hiện gian lận giao dịch online hiệu quả trong quý 1, nhưng đến quý 2 bị “qua mặt” vì các chiêu trò gian lận mới chưa có trong dữ liệu training.

6. Bạn không thể kiểm soát toàn bộ trải nghiệm , nhưng phải chịu trách nhiệm kiểm soát nó

Đây là nghịch lý lớn nhất của sản phẩm AI:

• Bạn không viết toàn bộ logic
• Nhưng người dùng vẫn đòi hỏi trải nghiệm đáng tin cậy, an toàn, dễ hiểu

Vì vậy, bạn cần:

• Thiết kế fallback (ví dụ: nếu AI không chắc, chuyển sang rule-based)
• Tạo explainability layer: giúp người dùng hiểu vì sao AI ra kết quả đó
• Truyền thông rõ ràng: “AI có thể sai, nhưng chúng tôi học liên tục từ bạn để cải thiện.”

Ví dụ thực tế:

• ChatGPT thường nhấn mạnh: “Tôi có thể không chính xác, hãy kiểm tra lại thông tin” , đây là một cách để thiết lập kỳ vọng đúng.