Mở đầu — vì sao bài này quan trọng
Khi bạn viết spec cho một nút bấm, một form đăng ký, hay một màn hình thanh toán, output của hệ thống là xác định (deterministic): cùng một input luôn cho ra cùng một kết quả. Nhưng khi bạn spec cho một feature dùng AI — đặc biệt là các mô hình ngôn ngữ lớn (LLM — Large Language Model, như GPT, Gemini, hay các model nội bộ) — bạn bước vào một thế giới khác hẳn: output là xác suất (probabilistic). Cùng một câu hỏi, model có thể trả lời khác nhau giữa hai lần gọi. Đôi khi nó trả lời sai một cách rất tự tin. Đôi khi nó "treo" 8 giây. Đôi khi nhà cung cấp model bị sập và API trả về lỗi 503.
Đây chính là lý do spec cho AI feature là một kỹ năng riêng, không thể viết theo lối mòn của một feature CRUD thông thường. Nếu bạn bê nguyên template PRD cũ vào, bạn sẽ bỏ sót những phần sống còn: điều gì xảy ra khi model trả về rác? Bao lâu thì coi là "quá chậm"? Làm sao đo được câu trả lời là "đủ tốt"? Và quan trọng nhất với người dùng Việt Nam: làm sao chặn được những câu bịa đặt (hallucination) khi feature của bạn tư vấn về tài chính, sức khỏe hay pháp lý?
Một PM viết spec AI tốt không cần biết train model. Nhưng bạn bắt buộc phải định nghĩa được năm thứ: hợp đồng input/output, phương án dự phòng khi model lỗi, ngân sách độ trễ, tiêu chí đánh giá chất lượng, và rào chắn chống bịa đặt. Bài này sẽ dạy bạn cả năm.
Khái niệm cốt lõi
Một AI feature, dưới góc nhìn của PM, không phải là "phép màu". Nó là một hộp đen có xác suất nằm giữa input của người dùng và output hiển thị. Nhiệm vụ của spec là bao quanh hộp đen đó bằng những ràng buộc rõ ràng để kỹ sư và designer biết phải xử lý mọi trường hợp.
1. Input/Output Contract (Hợp đồng đầu vào — đầu ra)
Đây là phần nền móng. Bạn phải định nghĩa chính xác:
- Input là gì: text người dùng nhập, dữ liệu ngữ cảnh kèm theo (context — ví dụ lịch sử chat, hồ sơ người dùng, sản phẩm đang xem), và những ràng buộc về độ dài, ngôn ngữ, định dạng.
- Output trông như thế nào: là đoạn văn tự do, hay JSON có cấu trúc, hay một danh sách gợi ý có giới hạn? Output có schema cố định không (ví dụ luôn trả về
{intent, confidence, suggested_reply})? - Ràng buộc trên output: độ dài tối đa, tông giọng (lịch sự, không dùng từ lóng), và những thứ tuyệt đối không được xuất hiện (số điện thoại bịa, link ngoài, lời khuyên y tế cụ thể).
2. Fallback khi model fail (Phương án dự phòng)
Model AI sẽ lỗi — đây không phải câu hỏi "nếu" mà là "khi nào". Có ba loại lỗi cần spec riêng:
- Lỗi hạ tầng: API timeout, trả lỗi 429 (quá tải / rate limit), 500/503. Spec phải nói rõ: thử lại (retry) mấy lần, sau bao lâu, rồi degrade (hạ cấp trải nghiệm) ra sao.
- Lỗi nội dung: model trả về rỗng, trả về sai schema, hoặc trả về nội dung vi phạm policy.
- Lỗi chất lượng thấp: model trả về nhưng confidence (độ tự tin) thấp dưới ngưỡng.
3. Latency Budget (Ngân sách độ trễ)
LLM chậm hơn API thông thường rất nhiều — có thể từ 800ms đến vài giây. Spec phải đặt ra một ngân sách thời gian: ví dụ p95 (95% các lượt) phải xong dưới 3 giây. Và phải spec hành vi UI trong lúc chờ: hiển thị streaming (chữ chạy dần như đang gõ), skeleton loading, hay spinner? Khi vượt ngân sách thì cắt (timeout) ở giây thứ mấy và làm gì tiếp.
4. Eval Criteria (Tiêu chí đánh giá chất lượng)
Bạn không thể nói "AI trả lời hay là được". Bạn cần định nghĩa chất lượng có thể đo được: một bộ ví dụ thử (test set) với input và output mong đợi, các chiều đánh giá (đúng/sai, hữu ích, đúng tông giọng, an toàn), và ngưỡng pass tối thiểu (ví dụ ≥ 85% lượt đạt). Đây là thứ phân biệt một feature AI "demo cho vui" với một feature dám đưa ra production.
5. Hallucination Guard (Rào chắn chống bịa đặt)
Hallucination là khi model bịa ra thông tin nghe rất thật nhưng sai. Đây là rủi ro số một của LLM. Spec cần định nghĩa: model được phép nói về cái gì, không được nói về cái gì, có bắt buộc trích nguồn (grounding) không, và cơ chế kiểm tra trước khi hiển thị (ví dụ: nếu model trả về một mã sản phẩm, hệ thống phải đối chiếu mã đó có thật trong database không).
Tình huống thực tế
Ví dụ 1 — Tiki: chatbot tư vấn sản phẩm bịa ra chính sách đổi trả
Hãy hình dung đội PM của một sàn thương mại điện tử lớn như Tiki triển khai chatbot AI trả lời câu hỏi "Sản phẩm này có được đổi trả không?". Bản spec đầu tiên chỉ có một dòng: "Dùng LLM trả lời câu hỏi của khách dựa trên mô tả sản phẩm."
Kết quả khi chạy thử nội bộ với 200 câu: chatbot trả lời trôi chảy, nhưng có 18 lượt nó tự bịa ra chính sách "đổi trả trong 30 ngày miễn phí" cho cả những sản phẩm thuộc nhóm hàng không được đổi trả (đồ lót, thực phẩm). Nếu lên production, đây là rủi ro pháp lý và khiếu nại thật.
Đội PM viết lại spec theo hướng grounding + guard: model chỉ được trả lời chính sách đổi trả bằng cách trích đúng trường return_policy trong database của sản phẩm đó; nếu trường này rỗng, output bắt buộc là câu cố định "Mình chưa có thông tin chính sách đổi trả cho sản phẩm này, bạn nhấn vào đây để xem chi tiết." Họ thêm một bước kiểm tra: nếu output chứa cụm "ngày" hoặc "miễn phí" mà không khớp với dữ liệu gốc, lượt đó bị chặn và rơi vào fallback.
Bài học: AI tư vấn về chính sách, giá, tồn kho — những thứ có "sự thật" trong database — thì spec phải buộc model dựa vào dữ liệu thật, không được tự sinh. Hallucination guard không phải tính năng phụ, nó là điều kiện để được lên production.
Ví dụ 2 — Một ngân hàng số tại TP.HCM: latency budget cứu trải nghiệm
Một ngân hàng số giả định triển khai tính năng "tóm tắt chi tiêu tháng" bằng LLM: người dùng mở app, AI viết một đoạn 3 câu tóm tắt thói quen chi tiêu. Bản demo chạy đẹp trên máy PM. Nhưng khi đo thực tế trên mạng 4G của người dùng, p95 latency lên tới 6,4 giây — và trong suốt thời gian đó màn hình chỉ có một spinner xoay tròn. Tỷ lệ người dùng thoát màn hình (drop-off) ở bước này là 41%.
Đội PM bổ sung vào spec một mục Latency Budget rõ ràng: ngân sách p95 = 3 giây; nếu vượt 3 giây thì hiển thị ngay phần tóm tắt "tĩnh" tính bằng công thức (không cần AI) như "Tháng này bạn chi 12,3 triệu, nhiều hơn tháng trước 8%", đồng thời stream phần "nhận xét" của AI vào sau khi nó sẵn sàng. Họ cũng chuyển từ spinner sang streaming text để người dùng thấy chữ chạy dần thay vì chờ trong vô vọng. Drop-off giảm xuống còn 12%.
Bài học: với LLM, "chậm" không chỉ là vấn đề kỹ thuật mà là vấn đề trải nghiệm. Spec phải đặt con số ngân sách cụ thể, định nghĩa hành vi UI khi chờ, và luôn có một phần kết quả không-AI hiển thị trước để người dùng không nhìn vào màn hình trống.
Ví dụ 3 — Startup edtech: eval set biến tranh cãi cảm tính thành quyết định bằng số
Một startup edtech tại Việt Nam làm tính năng "AI chấm và góp ý bài luận tiếng Anh" của học viên. Vấn đề: mỗi lần đội kiểm thử, người thì khen "AI góp ý hay", người thì chê "AI quá khắt khe". Không ai quyết định được có nên ship hay không vì tất cả đều dựa trên cảm tính.
PM xây một eval set gồm 120 bài luận mẫu, mỗi bài có nhãn do giáo viên thật chấm (band điểm + 3 lỗi chính). Họ định nghĩa bốn chiều đo: (1) band điểm AI lệch không quá 0,5 so với giáo viên, (2) bắt đúng ít nhất 2/3 lỗi ngữ pháp chính, (3) tông giọng động viên chứ không phán xét, (4) không bịa ra lỗi không tồn tại. Ngưỡng pass: ≥ 80% bài đạt cả bốn chiều. Lần chạy đầu chỉ đạt 64% — chủ yếu rớt ở chiều (4) vì AI hay bịa lỗi. Sau khi chỉnh prompt và thêm guard, đạt 86% và họ tự tin ship.
Bài học: eval set biến cuộc tranh luận cảm tính thành một con số chung mọi người đồng thuận. Không có eval set, bạn sẽ ship dựa trên ý kiến của người to tiếng nhất, không phải dựa trên chất lượng thật.
Hướng dẫn từng bước
Khi cần spec một AI feature, hãy đi theo trình tự sau:
Bước 1 — Mô tả Input/Output Contract. Viết ra chính xác model nhận gì và phải trả ra gì. Nếu output cần parse, định nghĩa schema (ví dụ JSON với các trường bắt buộc). Liệt kê ràng buộc: độ dài, ngôn ngữ, tông giọng, và danh sách "tuyệt đối không xuất hiện".
Bước 2 — Định nghĩa Latency Budget. Đặt ngân sách p50 và p95 (ví dụ p95 ≤ 3s). Spec hành vi UI khi chờ (streaming / skeleton), thời điểm timeout, và phần kết quả không-AI hiển thị trước.
Bước 3 — Liệt kê các nhánh Fallback. Lập một bảng: với mỗi loại lỗi (timeout, rate limit, output rỗng, sai schema, confidence thấp, vi phạm policy) → hệ thống làm gì (retry mấy lần → degrade ra sao → đường lui không-AII). Nguyên tắc: feature không bao giờ được để màn hình trắng hoặc văng lỗi kỹ thuật ra cho người dùng.
Bước 4 — Xây Eval Criteria & test set. Tạo bộ ví dụ thử (20–200 mẫu tùy độ rủi ro) có input và output mong đợi. Định nghĩa các chiều đo và ngưỡng pass. Đây là "định nghĩa của xong" (definition of done) về chất lượng.
Bước 5 — Thiết kế Hallucination Guard. Trả lời: model được nói về gì, không được nói về gì? Có bắt buộc grounding vào dữ liệu thật không? Có bước kiểm tra/đối chiếu output trước khi hiển thị không? Với feature rủi ro cao (tài chính, y tế, pháp lý), thêm câu disclaimer và chặn các loại nội dung nhạy cảm.
Bước 6 — Spec phần giám sát sau khi ship. Ghi rõ sẽ log gì (input, output, latency, lượt rơi vào fallback), và cơ chế để người dùng báo cáo câu trả lời tệ (nút "câu trả lời này không đúng").
Lỗi thường gặp & mẹo
Lỗi 1 — Spec AI như spec feature deterministic. Viết "AI trả lời câu hỏi của user" rồi coi như xong. Mẹo: luôn tự hỏi "nếu model trả về rác / quá chậm / bịa đặt thì sao?". Nếu spec không trả lời được, nó chưa hoàn chỉnh.
Lỗi 2 — Quên non-AI fallback. Nhiều spec coi AI là con đường duy nhất. Khi nhà cung cấp model sập (chuyện xảy ra thường xuyên), cả feature chết. Mẹo: mọi AI feature phải có một đường lui không cần AI, dù chỉ là kết quả mặc định đơn giản.
Lỗi 3 — Không đo chất lượng, chỉ "nhìn thấy ổn". Demo vài câu thấy hay rồi ship. Mẹo: bắt buộc có eval set trước khi ship. Số mẫu có thể nhỏ, nhưng phải có.
Lỗi 4 — Bỏ qua latency vì test trên máy nhanh. Mẹo: luôn đo latency trên điều kiện mạng thật của người dùng (4G, vùng xa), không chỉ wifi văn phòng.
Lỗi 5 — Tin tưởng output mù quáng với feature rủi ro cao. Mẹo: với tài chính/y tế/pháp lý, mặc định coi mọi output là "chưa đáng tin cho đến khi được grounding và kiểm tra".
Mẹo tổng quát: viết một bảng "input bất thường → hành vi mong đợi" ngay trong spec. Input rỗng, input quá dài, input bằng ngôn ngữ khác, input cố tình phá (prompt injection) — mỗi cái cần một dòng hành vi rõ ràng.
Bài tập thực hành
Chọn một AI feature (gợi ý: "AI gợi ý câu trả lời cho nhân viên CSKH" của một sàn TMĐT, hoặc "AI tóm tắt review sản phẩm"). Viết một spec ngắn gồm đúng năm phần:
- Input/Output Contract: model nhận gì, trả ra gì (kèm schema nếu có), ràng buộc gì.
- Latency Budget: con số p95 cụ thể, hành vi UI khi chờ, hành vi khi timeout.
- Bảng Fallback: ít nhất 4 loại lỗi và hành vi tương ứng, trong đó có 1 đường lui không-AI.
- Eval Criteria: 3 chiều đo, ngưỡng pass, và mô tả test set (bao nhiêu mẫu, lấy từ đâu).
- Hallucination Guard: model được/không được nói về gì, có grounding không, có bước kiểm tra output không.
Tóm tắt
Spec cho AI feature khác spec thông thường vì bạn đang bao quanh một hộp đen xác suất, không phải một hàm xác định. Năm trụ cột bắt buộc là: Input/Output Contract (định nghĩa rõ vào — ra và schema), Latency Budget (đặt con số và hành vi chờ), Fallback (mọi loại lỗi đều có đường lui, luôn có nhánh không-AI), Eval Criteria (đo chất lượng bằng test set và ngưỡng pass thay vì cảm tính), và Hallucination Guard (chống bịa đặt bằng grounding và kiểm tra output, đặc biệt với feature rủi ro cao).
Ba ví dụ — Tiki bịa chính sách đổi trả, ngân hàng số tối ưu latency, startup edtech dùng eval set — đều cho thấy cùng một nguyên lý: một AI feature chỉ sẵn sàng cho production khi spec đã trả lời được câu hỏi "model sẽ thất bại như thế nào, và khi đó người dùng thấy gì?". Viết được câu trả lời đó cho mọi trường hợp, bạn đã đi trước phần lớn PM trên thị trường.