Mở đầu — vì sao bài này quan trọng
Trong vài năm gần đây, gần như mọi sản phẩm số tại Việt Nam đều muốn gắn thêm chữ "AI" vào tính năng của mình: chatbot tư vấn của ngân hàng, gợi ý món ăn trên ứng dụng giao đồ, tóm tắt văn bản trong app ghi chú, hay trợ lý viết content cho dân marketing. Là một PM, sớm muộn gì bạn cũng sẽ phải viết spec (tài liệu mô tả yêu cầu) cho một tính năng dùng AI — đặc biệt là các tính năng dựa trên mô hình ngôn ngữ lớn (LLM — Large Language Model, như GPT, Gemini, hay các mô hình của Anthropic).
Vấn đề là: viết spec cho tính năng AI rất khác với viết spec cho một tính năng phần mềm thông thường. Nếu bạn áp dụng nguyên si cách viết yêu cầu cũ — kiểu "khi người dùng bấm nút A thì hệ thống hiển thị B" — bạn sẽ vấp ngay. Bởi vì AI không phải là một hàm toán học cho ra kết quả cố định. Cùng một câu hỏi, hai lần hỏi có thể cho ra hai câu trả lời khác nhau. Đôi khi nó trả lời sai một cách rất tự tin. Đôi khi nó mất 8 giây mới phản hồi. Và đôi khi nó nói những điều mà bạn không hề mong muốn.
Bài này sẽ dạy bạn cách tư duy và viết spec cho tính năng AI sao cho đội kỹ thuật hiểu đúng, đội thiết kế lường trước được các trạng thái lỗi, và sản phẩm cuối cùng không khiến người dùng thất vọng. Đây là một kỹ năng rất "hot" mà nhiều PM Việt Nam còn lúng túng — nắm vững nó sẽ giúp bạn nổi bật.
Khái niệm cốt lõi
1. Tính phi xác định (Non-deterministic)
Đây là điểm khác biệt lớn nhất. Phần mềm truyền thống mang tính xác định (deterministic): cùng một đầu vào luôn cho ra cùng một đầu ra. 2 + 2 luôn bằng 4. Nhưng LLM mang tính phi xác định: cùng một câu hỏi, mô hình có thể trả lời theo nhiều cách khác nhau ở mỗi lần gọi.
Hệ quả với cách viết spec: bạn không thể viết "đầu ra phải đúng bằng chuỗi X". Thay vào đó, bạn phải mô tả phạm vi chấp nhận được của đầu ra — giọng điệu, độ dài, định dạng, những gì được phép và không được phép nói. Bạn chuyển từ "spec chính xác từng ký tự" sang "spec mô tả ranh giới và tiêu chí chất lượng".
2. Độ trễ (Latency)
Một lệnh gọi LLM thường mất từ 1 đến 10 giây, đôi khi lâu hơn nếu câu trả lời dài. So với một API thông thường trả về trong vài chục mili-giây, đây là cả một khoảng cách lớn. Người dùng nhìn màn hình trống 8 giây sẽ tưởng app bị treo.
Vì vậy spec của bạn bắt buộc phải mô tả trải nghiệm chờ đợi: có hiển thị hiệu ứng "đang gõ" (typing indicator) không? Có dùng streaming — tức là chữ hiện dần từng phần như ChatGPT — để người dùng cảm thấy nhanh hơn không? Có thời gian chờ tối đa (timeout) bao nhiêu giây trước khi báo lỗi?
3. Ảo giác (Hallucination)
LLM có thể "bịa" thông tin — đưa ra câu trả lời nghe rất thuyết phục nhưng hoàn toàn sai sự thật. Ví dụ chatbot ngân hàng có thể bịa ra một mức lãi suất không tồn tại. Đây là rủi ro nghiêm trọng, đặc biệt trong các lĩnh vực nhạy cảm như tài chính, y tế, pháp lý.
Spec của bạn cần nêu rõ: tính năng này có được phép "tự do sáng tạo" hay phải bám chặt vào nguồn dữ liệu cho trước (thường gọi là RAG — Retrieval-Augmented Generation, tức là cho mô hình đọc tài liệu nội bộ rồi mới trả lời)? Có cần hiển thị nguồn trích dẫn không? Khi nào thì hệ thống nên trả lời "Tôi không biết" thay vì cố đoán?
4. Chi phí theo token (Cost)
Khác với phần mềm thường (chạy bao nhiêu lần cũng gần như miễn phí), mỗi lệnh gọi LLM đều tốn tiền, tính theo token (đơn vị xấp xỉ một từ hoặc một phần của từ). Một tính năng dùng nhiều có thể đốt hàng chục triệu đồng mỗi tháng. PM phải đưa yếu tố chi phí vào spec: ước lượng số lượt gọi, độ dài trung bình, có cache (lưu lại câu trả lời cũ) cho các câu hỏi lặp lại không.
5. Đánh giá chất lượng (Evals)
Vì đầu ra không cố định, bạn không thể kiểm thử kiểu "đúng/sai" như thông thường. Bạn cần evals — một bộ ví dụ mẫu (golden set) gồm các đầu vào tiêu biểu kèm tiêu chí "thế nào là câu trả lời tốt". Đội kỹ thuật sẽ chạy bộ này mỗi khi đổi prompt hay đổi mô hình để xem chất lượng tăng hay giảm. PM nên là người chủ trì xây dựng bộ tiêu chí này.
Tình huống thực tế
Ví dụ 1 — Chatbot CSKH của một sàn TMĐT (giả định: "ChợViệt")
Một PM tại sàn thương mại điện tử ChợViệt được giao làm chatbot trả lời câu hỏi về đơn hàng. Bản spec đầu tiên chỉ viết: "Người dùng hỏi, AI trả lời chính xác trạng thái đơn hàng." Khi triển khai, đội gặp hàng loạt vấn đề: chatbot bịa ra ngày giao hàng không có thật (hallucination), trả lời chậm 9 giây khiến người dùng bỏ đi, và khi được hỏi "shop này lừa đảo phải không" thì nó trả lời lung tung gây khủng hoảng truyền thông.
PM phải viết lại spec với các ràng buộc rõ ràng: chatbot chỉ được lấy thông tin từ API đơn hàng nội bộ (RAG), không tự suy diễn; nếu không tìm thấy dữ liệu thì trả lời "Mình chưa tìm thấy thông tin này, bạn vui lòng cung cấp mã đơn hàng nhé" thay vì đoán; có hiển thị "..." trong khi chờ và stream câu trả lời; với các câu nhạy cảm (khiếu nại, tố cáo) thì tự động chuyển sang nhân viên thật. Sau khi áp dụng, tỷ lệ hài lòng tăng từ 58% lên 81%.
Bài học: Spec AI phải định nghĩa rõ "vùng được phép trả lời" và "đường thoát hiểm" (fallback) khi AI không chắc chắn.
Ví dụ 2 — Tính năng tóm tắt cuộc họp trong một app năng suất Đông Nam Á
Một startup ở Singapore làm app ghi chú muốn thêm tính năng "tóm tắt cuộc họp tự động" cho thị trường Việt Nam, Indonesia, Thái Lan. PM ban đầu chỉ spec: "Nhập transcript, AI tóm tắt thành các gạch đầu dòng." Khi test với dữ liệu thật, tóm tắt tiếng Việt bị lủng củng, lẫn lộn tên người, và độ dài lúc thì 2 dòng lúc thì 2 trang.
PM bổ sung spec với các tiêu chí đầu ra cụ thể: tóm tắt tối đa 5 gạch đầu dòng cho mỗi chủ đề; luôn tách riêng phần "việc cần làm" và "người phụ trách"; giữ nguyên tên riêng tiếng Việt; nếu transcript dài quá 30 phút thì chia nhỏ xử lý. Quan trọng nhất, PM xây một bộ evals gồm 30 cuộc họp mẫu với bản tóm tắt "chuẩn" do con người viết, để đo chất lượng mỗi khi tinh chỉnh prompt.
Bài học: Với AI sinh nội dung, hãy spec theo tiêu chí chất lượng có thể đo được (độ dài, cấu trúc, ngôn ngữ), và đầu tư xây bộ ví dụ mẫu để kiểm thử.
Ví dụ 3 — Trợ lý viết caption cho creator (giả định: app "ContentVN")
Một PM làm tính năng gợi ý caption mạng xã hội cho người sáng tạo nội dung. Vì mỗi lượt gọi LLM tốn tiền và lượng người dùng lớn (dự kiến 50.000 lượt/ngày), nếu không tính toán thì chi phí có thể lên tới hơn 100 triệu đồng/tháng. PM đưa vào spec: cache lại các kết quả cho cùng một chủ đề phổ biến, giới hạn mỗi người dùng miễn phí 10 lượt/ngày, và dùng mô hình nhỏ rẻ hơn cho bản nháp, chỉ dùng mô hình mạnh khi người dùng bấm "viết lại hay hơn". Nhờ vậy chi phí giảm khoảng 65% mà chất lượng cảm nhận gần như không đổi.
Bài học: Chi phí token là yếu tố sản phẩm, không phải chuyện riêng của kỹ thuật. PM phải spec rõ giới hạn sử dụng, chiến lược cache và lựa chọn mô hình.
Hướng dẫn từng bước
Khi viết spec cho một tính năng AI, hãy đi qua các bước sau:
Bước 1 — Xác định "việc cần làm" của AI một cách hẹp. Đừng viết "AI giúp người dùng làm mọi thứ". Hãy thu hẹp: "AI tóm tắt email thành 3 gạch đầu dòng". Tính năng AI càng hẹp càng dễ kiểm soát chất lượng.
Bước 2 — Mô tả đầu vào và đầu ra mong muốn. Đầu vào là gì (văn bản, ảnh, lịch sử hội thoại)? Đầu ra cần có định dạng nào (JSON, gạch đầu dòng, đoạn văn)? Độ dài tối đa? Giọng điệu (thân thiện, trang trọng)?
Bước 3 — Định nghĩa ranh giới và quy tắc. AI được phép nói gì, không được nói gì? Có chủ đề cấm không (chính trị, y tế, lời khuyên tài chính)? Khi không chắc chắn thì xử lý ra sao? Đây chính là phần "guardrails" — hàng rào bảo vệ.
Bước 4 — Thiết kế trải nghiệm độ trễ và lỗi. Spec rõ: trạng thái đang chờ (loading/typing), có streaming không, timeout bao nhiêu giây, thông báo khi AI lỗi hoặc quá tải, và nút "thử lại".
Bước 5 — Định nghĩa cách đo chất lượng (evals). Cùng đội chuẩn bị 20–50 ví dụ đầu vào tiêu biểu kèm tiêu chí "câu trả lời tốt trông thế nào". Đây là cơ sở để kiểm thử và cải tiến.
Bước 6 — Tính toán chi phí và quy mô. Ước lượng số lượt gọi, độ dài trung bình, chọn mô hình, chiến lược cache và giới hạn sử dụng.
Bước 7 — Thiết kế vòng phản hồi. Thêm nút "thích / không thích" (thumbs up/down) hoặc "báo cáo câu trả lời sai" để thu thập dữ liệu cải tiến sau khi ra mắt.
Lỗi thường gặp & mẹo
Lỗi 1: Spec AI như spec phần mềm thường. Viết "đầu ra phải bằng X" là sai ngay từ gốc. Mẹo: chuyển sang mô tả ranh giới và tiêu chí chất lượng, không phải kết quả cố định.
Lỗi 2: Quên các trạng thái lỗi và độ trễ. Nhiều PM chỉ vẽ kịch bản "mọi thứ chạy hoàn hảo". Thực tế AI sẽ chậm, sẽ lỗi, sẽ quá tải. Mẹo: với mỗi tính năng AI, hãy liệt kê ít nhất 4 trạng thái — đang chờ, thành công, không tìm thấy/không chắc chắn, lỗi hệ thống.
Lỗi 3: Bỏ qua hallucination ở lĩnh vực nhạy cảm. Đừng để AI tự do "sáng tạo" về số liệu tài chính, sức khỏe, pháp lý. Mẹo: bắt buộc bám nguồn (RAG), hiển thị trích dẫn, và cho phép trả lời "Tôi không biết".
Lỗi 4: Không lường trước chi phí. Một tính năng "free" có thể khiến công ty lỗ nặng. Mẹo: luôn ước lượng chi phí token ngay trong spec, kèm cache và giới hạn.
Lỗi 5: Không có cách đo chất lượng. Nếu không có evals, bạn không biết bản cập nhật prompt mới tốt hơn hay tệ hơn. Mẹo: coi bộ ví dụ mẫu là một phần bắt buộc của spec, do PM chủ trì.
Mẹo vàng: Hãy tự mình "chơi" với mô hình (qua ChatGPT, Gemini hay playground) trước khi viết spec. Bạn sẽ cảm nhận được nó mạnh ở đâu, dở ở đâu, và viết yêu cầu thực tế hơn nhiều so với việc chỉ ngồi tưởng tượng.
Bài tập thực hành
Hãy chọn một trong hai đề sau và viết một bản spec dài khoảng 1–2 trang:
Đề A: Bạn là PM của một ứng dụng học tiếng Anh tại Việt Nam. Hãy spec tính năng "AI chấm và sửa lỗi ngữ pháp cho đoạn văn người học viết". Yêu cầu nêu rõ: đầu vào/đầu ra, định dạng phản hồi, ranh giới (AI có được viết lại toàn bộ giúp người học không, hay chỉ gợi ý?), trạng thái chờ và lỗi, ít nhất 5 ví dụ trong bộ evals, và ước lượng chi phí thô.
Đề B: Bạn là PM của một app fintech. Hãy spec tính năng "trợ lý AI giải thích các khoản chi tiêu trong tháng". Đặc biệt nhấn mạnh: làm sao chống hallucination về số liệu, khi nào AI phải từ chối trả lời, hiển thị nguồn dữ liệu, và 4 trạng thái UX (chờ/thành công/không chắc chắn/lỗi).
Sau khi viết xong, hãy tự đối chiếu với 7 bước trong phần "Hướng dẫn từng bước" xem mình đã bao quát đủ chưa.
Tóm tắt
Viết spec cho tính năng AI khác về bản chất so với phần mềm thường vì AI mang tính phi xác định (cùng đầu vào, khác đầu ra), chậm (độ trễ 1–10 giây), có thể bịa thông tin (hallucination), tốn chi phí theo token, và khó kiểm thử theo kiểu đúng/sai. Vì vậy PM phải chuyển từ tư duy "mô tả kết quả chính xác" sang tư duy "mô tả ranh giới, tiêu chí chất lượng, trạng thái lỗi và cách đo lường". Một bản spec AI tốt cần có: phạm vi việc-cần-làm hẹp, mô tả đầu vào/đầu ra, các guardrails, thiết kế trải nghiệm độ trễ và lỗi, bộ evals để đo chất lượng, ước lượng chi phí, và vòng phản hồi sau ra mắt. Nắm vững những nguyên tắc này, bạn sẽ tự tin dẫn dắt những tính năng AI thực sự hữu ích thay vì chỉ gắn nhãn "AI" cho đẹp.