Khi Non-Determinism Chạm Vào Giao Diện Sản Phẩm

Khi Non-Determinism Chạm Vào Giao Diện Sản Phẩm

AI Literacy Lesson 1 đã cho bạn khung chọn công nghệ: bài toán phi cấu trúc, Cost of Failure chấp nhận được → Model-based. Model-based đồng nghĩa non-deterministic - cùng input, output có thể khác nhau giữa các lần chạy. Nhưng đó là quyết định kiến trúc. Câu hỏi module này đặt ra tiếp: một khi đã chọn Model, non-determinism đó đâm thẳng vào giao diện bạn vẽ ra theo cách cụ thể nào?

Ví dụ xuyên suốt bài: ReplyGenie - công cụ AI soạn sẵn email trả lời khách hàng cho một startup SaaS.

1. Ba trục mà UI truyền thống mặc định cố định, nhưng Model làm vỡ

UI truyền thống dựng trên một "hợp đồng" ngầm: field luôn trả về độ dài X, action luôn xong trong khoảng Y, kết quả luôn đúng N mục. Khi bộ não phía sau là model xác suất, hợp đồng đó vỡ trên 3 trục:

• Hình dạng/độ dài output - cùng một yêu cầu, có lần trả lời 1 câu, có lần trả cả đoạn kèm điều kiện.
• Thời gian phản hồi - không còn nằm trong một khoảng hẹp, dễ đoán như hệ rule-based (ví dụ 200-300ms), mà giãn rộng theo độ phức tạp của input, có thể chênh nhau gấp chục lần giữa hai lượt gọi.
• Độ tin cậy - model không bao giờ từ chối trả lời (AI Literacy Lesson 1), nên UI phải có chỗ chứa sự không chắc chắn, không thể coi "model sai" là edge case hiếm gặp.

Lưu ý ở trục thứ hai: hệ rule-based không phải lúc nào cũng "cố định tuyệt đối" - nó vẫn dao động nhẹ theo tải hệ thống, nhưng dao động đó nằm trong một khoảng hẹp, đủ hẹp để set một loading indicator tĩnh mà không sai lệch nhiều. Với model, khoảng dao động đó nới rộng ra nhiều lần và phụ thuộc mạnh vào input - đó mới là điểm vỡ thật sự, không phải việc rule-based "luôn đúng một con số".

2. Ví dụ: ReplyGenie thiết kế như thể output vẫn cố định

UI ban đầu của ReplyGenie được thiết kế như một form auto-complete truyền thống: ô text cố định 4 dòng, progress bar luôn chạy đúng 1 giây, không có chỗ hiển thị "tôi không chắc khách này đang hỏi về gói Basic hay Pro". Kết quả: câu trả lời dài bị cắt cụt trong ô 4 dòng (vỡ trục hình dạng), những câu hỏi phức tạp mất 6-7 giây khiến progress bar 1 giây trông như app treo (vỡ trục thời gian), và khi model đoán nhầm gói dịch vụ, nhân viên CSKH gửi luôn email sai mà không có tín hiệu cảnh báo nào (vỡ trục độ tin cậy).

3. Bảng đối chiếu giả định cũ và thực tế mới

Ba trục này là khung cho toàn bộ phần còn lại của module: Lesson 30 xử lý trục latency, Lesson 29 và 31 xử lý trục độ tin cậy, Lesson 28 và 33 xử lý việc input/output không còn cố định hình dạng.

4. Ẩn dụ: tổng đài đọc kịch bản và chuyên gia tư vấn trực tiếp

Sự khác biệt giống gọi tổng đài đọc kịch bản có sẵn (mỗi câu hỏi ra đúng một câu trả lời, đúng một nhịp điệu) và hỏi trực tiếp một chuyên gia tư vấn - người trả lời ngắn gọn nếu câu hỏi dễ, dài dòng kèm điều kiện nếu câu hỏi khó, và đôi khi nói thẳng "để tôi kiểm tra lại, tôi chưa chắc phần này". UI cho sản phẩm AI-native phải được thiết kế cho kiểu phản hồi thứ hai.

Bài tập 27.1: TripBrief - app tự động lên lịch trình du lịch. User gõ "3 ngày ở Đà Lạt" → app hiển thị một thẻ kết quả có 2 đặc điểm: (1) chiều cao cố định, luôn hiển thị đúng 3 hoạt động/ngày dù model gợi ý bao nhiêu; (2) progress bar luôn chạy đúng 1.5 giây rồi hiện kết quả, không có cách nào báo nếu model không chắc một địa điểm còn mở cửa hay không.

Chỉ ra 2 chỗ cụ thể trong thiết kế trên sẽ vỡ khi engine phía sau là model xác suất, và với mỗi chỗ, nêu rõ nó thuộc trục nào trong 3 trục vừa học.