Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa ship một tính năng AI mới: trợ lý gợi ý sản phẩm bằng ngôn ngữ tự nhiên trên app thương mại điện tử. Mọi thứ chạy mượt trong demo. Nhưng đến 9 giờ tối thứ Sáu — cao điểm mua sắm — nhà cung cấp model (OpenAI) gặp sự cố toàn cầu, API trả về lỗi 503 suốt 40 phút. Trong 40 phút đó, mỗi lần người dùng bấm vào ô chat, họ nhận về một màn hình trắng kèm dòng "Đã có lỗi xảy ra". Conversion rớt thẳng đứng. Bộ phận chăm sóc khách hàng nhận hàng trăm ticket. Và sếp của bạn hỏi một câu rất đơn giản nhưng khiến bạn lạnh sống lưng: "Sao mình không có phương án dự phòng?"
Đây chính là lý do tồn tại của bài học này. Tính năng AI khác phần mềm truyền thống ở một điểm cốt tử: nó phụ thuộc vào một thành phần mà bạn không kiểm soát được và có thể fail bất cứ lúc nào — model bên thứ ba, latency biến động, output không xác định. Một spec AI tốt không chỉ mô tả "khi mọi thứ chạy đúng thì sao", mà phải mô tả tỉ mỉ "khi mọi thứ hỏng thì hệ thống xuống cấp như thế nào để người dùng vẫn còn dùng được". Phần đó gọi là Fallback & Degraded Experience — chiến lược dự phòng và trải nghiệm xuống cấp có kiểm soát.
Trong bài này, với vai trò người viết spec, bạn sẽ học cách định nghĩa rõ ràng các tầng xuống cấp, cách viết chúng vào PRD/Spec để engineer biết chính xác phải build gì, và cách đảm bảo rằng "lỗi" trong thế giới AI không bao giờ trở thành "tắc nghẽn hoàn toàn" cho người dùng.
Khái niệm cốt lõi
Degraded experience là gì?
"Degraded experience" — trải nghiệm xuống cấp — là một nguyên tắc thiết kế cũ trong kỹ thuật phần mềm gọi là graceful degradation: khi một phần hệ thống hỏng, phần còn lại vẫn hoạt động ở mức thấp hơn thay vì sụp đổ hoàn toàn. Với tính năng AI, nguyên tắc này càng quan trọng vì xác suất "thành phần AI hỏng" cao hơn nhiều so với phần backend truyền thống.
Điều mấu chốt cần hiểu: fallback không phải là một switch on/off, mà là một cái thang nhiều bậc. Mỗi bậc tương ứng với một mức chất lượng trải nghiệm thấp dần, nhưng tất cả đều tốt hơn màn hình lỗi trắng xóa.
Các tầng xuống cấp (levels of degradation)
Đây là bộ khung tôi khuyên bạn dùng khi viết spec. Hãy hình dung như một chiếc thang đi xuống:
Tầng 0 — Trải nghiệm đầy đủ (Primary): Model chính chạy bình thường, trả về kết quả chất lượng cao đúng kỳ vọng. Ví dụ: GPT-4o tạo ra gợi ý sản phẩm cá nhân hóa.
Tầng 1 — Backup model: Model chính fail (timeout, lỗi 5xx, rate limit). Hệ thống tự động chuyển sang model dự phòng. Ví dụ: GPT-4o lỗi → chuyển sang Claude, hoặc chuyển sang một model rẻ/nhanh hơn như GPT-4o-mini, Gemini Flash. Trải nghiệm gần như không đổi với người dùng, có thể chất lượng nhỉnh thấp hơn một chút.
Tầng 2 — Deterministic / rule-based fallback: Cả model chính lẫn backup đều fail. Lúc này AI hoàn toàn không khả dụng, nhưng bạn vẫn phải trả về một cái gì đó hữu ích. Đây là phần được tạo bằng logic tất định (deterministic) — không cần AI. Ví dụ: thay vì gợi ý cá nhân hóa, hệ thống hiển thị "Top 10 sản phẩm bán chạy tuần này" được tính sẵn từ database, hoặc kết quả tìm kiếm bằng từ khóa thuần (keyword search) thay cho tìm kiếm ngữ nghĩa.
Tầng 3 — Graceful empty state: Khi ngay cả fallback tất định cũng không áp dụng được (ví dụ tính năng vốn dĩ chỉ có AI mới làm được), bạn hiển thị một empty state được thiết kế tử tế: giải thích ngắn gọn, đề xuất hành động thay thế, và không bao giờ để người dùng mắc kẹt. Ví dụ: "Trợ lý đang bận, bạn thử tìm kiếm thủ công nhé" kèm nút dẫn về tìm kiếm thường.
Phân biệt 3 loại "fail" mà bạn phải spec riêng
Một sai lầm phổ biến là gộp tất cả lỗi vào một rọ. Thực tế có ba kiểu fail rất khác nhau, và mỗi kiểu cần một fallback khác:
- Hard failure (lỗi cứng): API trả lỗi rõ ràng — 500, 503, timeout, rate limit 429. Dễ phát hiện nhất. Fallback: chuyển model hoặc xuống tầng tất định.
- Soft failure (lỗi mềm / suy giảm chất lượng): API trả về kết quả, nhưng kết quả tệ — rỗng, lạc đề, hoặc vi phạm format. Khó phát hiện hơn vì về mặt kỹ thuật "không có lỗi". Cần một lớp validation output để bắt được.
- Latency failure (lỗi do chậm): Model trả lời đúng nhưng quá chậm — 12 giây trong khi người dùng chỉ chịu đợi 3 giây. Về mặt kỹ thuật là "thành công" nhưng về trải nghiệm là "thất bại". Cần một latency budget (sẽ là chủ đề riêng ở bài khác) và quyết định: cắt sớm và fallback, hay tiếp tục đợi?
Tình huống thực tế
Ví dụ 1 — Trợ lý chăm sóc khách hàng của một ví điện tử Việt Nam
Một ví điện tử lớn tại Việt Nam (giả định gọi là "PayVi") triển khai chatbot AI trả lời câu hỏi về giao dịch, hoàn tiền, hạn mức. Lưu lượng cao điểm: ~8.000 tin nhắn/giờ vào tối cuối tuần. Họ dùng một LLM qua API làm engine chính.
Trong tuần đầu, đội product chỉ spec "nếu lỗi thì hiện thông báo xin lỗi". Đến ngày thứ 9, nhà cung cấp model gặp sự cố vùng châu Á trong 25 phút. Kết quả: hơn 3.000 người dùng nhận thông báo lỗi, 600 người chuyển sang gọi tổng đài, làm nghẽn cả call center.
Đội product viết lại spec theo mô hình thang xuống cấp:
- Tầng 1: Model chính lỗi → chuyển sang model backup của nhà cung cấp khác trong 2 giây.
- Tầng 2: Cả hai lỗi → chuyển sang bộ FAQ tất định: phân loại câu hỏi bằng keyword matching (đơn giản, chạy local) rồi trả về câu trả lời soạn sẵn cho 50 câu hỏi phổ biến nhất (vốn chiếm 70% lưu lượng).
- Tầng 3: Câu hỏi không khớp FAQ nào → hiển thị: "Mình chưa trả lời được câu này ngay lúc này. Bạn để lại câu hỏi, đội ngũ sẽ phản hồi trong 30 phút" + nút tạo ticket.
Ví dụ 2 — Tính năng tóm tắt review sản phẩm trên sàn TMĐT
Một sàn thương mại điện tử Đông Nam Á (kiểu Tiki/Shopee) làm tính năng "Tóm tắt AI" cho phần đánh giá sản phẩm: gom 200 review thành 3 dòng ưu/nhược điểm. Đây là tính năng không quan trọng sống còn — nice-to-have.
Vì không quan trọng sống còn, đội product quyết định một chiến lược fallback rất khác ví dụ 1: không cần model backup, không cần logic tất định phức tạp. Spec ghi rõ:
- Nếu model lỗi hoặc trả lời > 4 giây → ẩn hoàn toàn block tóm tắt AI, người dùng thấy danh sách review như bình thường (giao diện cũ vẫn còn nguyên).
- Tuyệt đối không hiện thông báo lỗi đỏ, không spinner xoay mãi.
Ví dụ 3 — Soft failure suýt làm hỏng tính năng tạo mô tả sản phẩm
Một startup SaaS giúp người bán hàng tự tạo mô tả sản phẩm bằng AI. Spec ban đầu chỉ xử lý hard failure (API lỗi). Nhưng vấn đề thật lại là soft failure: thỉnh thoảng model trả về mô tả bị cắt giữa chừng, hoặc trả về tiếng Anh trong khi người dùng đang nhập tiếng Việt, hoặc trả về JSON sai format khiến UI vỡ.
Vì spec không định nghĩa "thế nào là output hợp lệ", engineer cứ thế hiển thị bất cứ thứ gì model trả ra. Tỉ lệ mô tả lỗi format lên tới 6% — đủ để người bán mất niềm tin.
Đội fix bằng cách thêm vào spec một lớp validation output ngay trước fallback tất định:
- Output phải parse được thành JSON đúng schema.
- Độ dài 50–300 từ.
- Ngôn ngữ output phải khớp ngôn ngữ input (phát hiện bằng thư viện detect ngôn ngữ).
- Nếu vi phạm bất kỳ điều kiện nào → retry 1 lần với prompt nhắc lại format → nếu vẫn fail → fallback sang template mô tả điền chỗ trống (tên + danh mục + thuộc tính).
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn theo khi viết phần Fallback trong spec một tính năng AI.
Bước 1 — Xác định mức độ quan trọng của tính năng (criticality). Hỏi: nếu phần AI biến mất hoàn toàn trong 30 phút, hậu quả là gì? Mất tiền? Mất niềm tin? Hay chỉ là thiếu một tiện ích nhỏ? Câu trả lời quyết định bạn cần thang 2 tầng hay 4 tầng. Viết một câu rõ ràng vào spec: "Đây là tính năng [critical / important / nice-to-have]."
Bước 2 — Liệt kê các chế độ fail (failure modes). Lập bảng ba cột: loại fail (hard / soft / latency), cách phát hiện, ngưỡng kích hoạt. Ví dụ: "Latency fail → kích hoạt khi không có token đầu tiên sau 3 giây."
Bước 3 — Định nghĩa từng bậc thang fallback. Với mỗi bậc, ghi rõ ba điều: (a) điều kiện chuyển xuống bậc này, (b) hệ thống làm gì ở bậc này, (c) người dùng nhìn thấy gì. Đừng để engineer phải tự đoán phần (c) — đó là phần dễ bị bỏ quên nhất.
Bước 4 — Định nghĩa tiêu chí "output hợp lệ". Viết checklist: format, độ dài, ngôn ngữ, từ cấm, có chứa thông tin bịa đặt không. Quy định output không hợp lệ được xử lý như một failure (retry rồi fallback).
Bước 5 — Quyết định cách hiển thị cho người dùng ở mỗi bậc. Có nên cho người dùng biết họ đang ở chế độ xuống cấp không? Tùy ngữ cảnh. Với chatbot tài chính, sự minh bạch ("Mình đang dùng chế độ trả lời nhanh") tạo niềm tin. Với tính năng phụ trợ, im lặng là vàng.
Bước 6 — Spec phần logging & alerting. Mỗi lần hệ thống tụt xuống một bậc fallback phải được ghi log và (nếu là tính năng critical) bắn cảnh báo. Nếu không, bạn sẽ "âm thầm chạy ở tầng 2" suốt nhiều ngày mà không ai biết.
Bước 7 — Viết acceptance criteria có thể test được. Ví dụ: "Khi model chính trả lỗi 503, hệ thống chuyển sang backup trong < 2s và người dùng không thấy bất kỳ thông báo lỗi nào." Phần này phải kiểm thử được, không phải mô tả mơ hồ.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ spec "happy path". Đây là lỗi phổ biến nhất. Spec mô tả rất kỹ khi AI chạy đúng, nhưng phần fail chỉ gói gọn trong một dòng "hiện thông báo lỗi". Mẹo: bắt buộc bản thân viết một mục riêng tên "Khi AI không khả dụng" trong mọi spec AI.
Lỗi 2 — Bỏ quên soft failure. Như ví dụ 3, nhiều người chỉ nghĩ tới lúc API chết. Nhưng output rác còn nguy hiểm hơn lỗi rõ ràng vì nó âm thầm. Mẹo: luôn có một lớp validation output, và coi output xấu là một failure mode chính thức.
Lỗi 3 — Over-engineer fallback cho tính năng phụ. Dồn công sức xây thang 4 tầng cho một tính năng mà người dùng chẳng quan tâm. Mẹo: để criticality dẫn dắt mức đầu tư.
Lỗi 4 — Fallback im lặng cho tính năng critical. Ngược lại của lỗi 3: hệ thống tụt xuống tầng tất định nhưng không log, không alert. Đội product tưởng AI vẫn chạy ngon trong khi thực tế nó đã chết 3 ngày. Mẹo: mọi lần tụt bậc đều phải để lại dấu vết quan sát được.
Lỗi 5 — Cho retry không giới hạn. Khi model chậm, một số spec để hệ thống retry liên tục, khiến latency dồn lại càng tệ và chi phí đội lên. Mẹo: luôn đặt số lần retry tối đa (thường là 1) và một deadline tổng (ví dụ toàn bộ vòng đời request không quá 6 giây dù retry hay fallback).
Mẹo vàng: Với mỗi tính năng AI, hãy luôn chuẩn bị sẵn một câu trả lời cho câu hỏi: "Nếu mai AI đột ngột biến mất, người dùng có còn dùng được sản phẩm này không?" Nếu câu trả lời là "không", bạn đang xây một sản phẩm mong manh. Fallback tất định chính là cái lưới an toàn biến câu trả lời đó thành "có, ở mức cơ bản".
Bài tập thực hành
Hãy chọn một trong hai tình huống dưới đây và viết phần "Fallback & Degraded Experience" cho spec (khoảng 1 trang):
Đề A: Một app giao đồ ăn thêm tính năng "Đề xuất món AI" — gợi ý món ăn dựa trên lịch sử đặt hàng và thời tiết. Đây là tính năng quan trọng nhưng không sống còn. Hãy thiết kế thang fallback đầy đủ, định nghĩa failure modes, tiêu chí output hợp lệ, và mô tả người dùng thấy gì ở từng bậc.
Đề B: Một ngân hàng số làm trợ lý AI giải thích các khoản phí trong sao kê. Đây là tính năng critical (sai thông tin có thể gây hậu quả pháp lý). Hãy spec fallback với yêu cầu cao về độ an toàn — đặc biệt: khi không chắc chắn, hệ thống nên làm gì? (Gợi ý: với tính năng tài chính, "im lặng + chuyển sang người thật" thường an toàn hơn "đoán bừa".)
Khi viết, hãy tự kiểm tra bằng checklist: (1) đã nêu criticality chưa? (2) đã liệt kê đủ 3 loại failure chưa? (3) mỗi bậc thang có đủ điều kiện + hành động + những gì người dùng thấy chưa? (4) đã có tiêu chí output hợp lệ chưa? (5) đã spec logging/alerting chưa? (6) acceptance criteria có test được không?
Tóm tắt
Tính năng AI mong manh hơn phần mềm truyền thống vì nó dựa vào một thành phần bạn không kiểm soát và có thể fail nhiều cách khác nhau. Một spec AI chất lượng phải mô tả không chỉ "khi chạy đúng" mà cả "khi hỏng thì xuống cấp ra sao".
Hãy ghi nhớ bốn ý cốt lõi. Thứ nhất, fallback là một cái thang nhiều bậc — primary, backup model, deterministic fallback, graceful empty state — chứ không phải một công tắc on/off. Thứ hai, có ba loại failure cần spec riêng: hard (lỗi cứng), soft (output rác) và latency (chậm quá), và soft failure là loại hay bị bỏ quên nhất. Thứ ba, mức đầu tư vào fallback phải tỉ lệ với độ quan trọng của tính năng — với tính năng phụ, biến mất lặng lẽ đôi khi là fallback tốt nhất. Thứ tư, mọi lần tụt bậc phải để lại dấu vết quan sát được, và với tính năng critical, "chuyển sang người thật" thường an toàn hơn "đoán bừa".
Khi bạn viết câu hỏi "nếu AI biến mất ngày mai, người dùng có còn dùng được không?" vào đầu mỗi spec, bạn đã đi được nửa đường tới một sản phẩm AI bền vững.