Quản Lý Độ Trễ Và Cảm Nhận Hiệu Năng Qua Streaming
So sánh 3 kỹ thuật che/giảm latency - static loading, skeleton state, streaming - và chọn đúng kỹ thuật theo dạng output, không mặc định vì là AI feature.
Quản Lý Độ Trễ Và Cảm Nhận Hiệu Năng Qua Streaming
Lesson 27 đã nêu: trục thứ hai bị vỡ khi model đứng sau feature là thời gian phản hồi. Cần nói chính xác hơn: hệ rule-based không có latency "cố định tuyệt đối" - nó vẫn dao động theo tải hệ thống, network, kích thước dữ liệu, nhưng dao động đó nằm trong một khoảng hẹp, dễ đoán (ví dụ 200-300ms), đủ hẹp để một loading indicator tĩnh vẫn đúng gần như mọi lần. Model - đặc biệt LLM sinh văn bản - không có khoảng hẹp đó: câu hỏi đơn giản trả lời trong 0.5s, câu hỏi phức tạp có thể mất 8-10s. Vấn đề không phải "chậm hơn", mà là độ lệch quá lớn giữa các lần gọi khiến bất kỳ loading pattern cố định nào cũng sai với ít nhất một nửa số trường hợp.
Ví dụ xuyên suốt bài: LegalDraft - công cụ AI soạn thảo điều khoản hợp đồng theo yêu cầu luật sư.
1. Ba kỹ thuật xử lý, từ yếu tới mạnh
- Loading indicator tĩnh - spinner/progress bar không đổi theo thực tế xử lý. Vẫn dùng được cho tác vụ nhanh, ổn định (dưới 1-2s, khoảng dao động hẹp kiểu rule-based), nhưng với AI feature có độ trễ biến thiên lớn, spinner đứng yên 8 giây khiến user nghĩ app bị treo.
- Skeleton state - hiện trước "khung xương" của kết quả trước khi có data thật. Giảm cảm giác chờ vì user thấy cấu trúc trước khi thấy nội dung - nhưng vẫn là chờ, không giải quyết được việc AI trả lời dài 30 giây.
- Streaming response - hiển thị output ngay khi model sinh từng phần (chính bài trả lời của AI Literacy Lesson 2 - Streaming UI - cũng dùng cơ chế này). Biến "thời gian chờ" thành "thời gian đọc", và quan trọng hơn: user có thể ngắt/hủy giữa chừng nếu thấy câu trả lời đi sai hướng.
3 Kỹ Thuật Che/Giảm Latency, Từ Yếu Tới Mạnh
LegalDraft chuyển từ spinner tĩnh sang streaming - cùng thời gian xử lý, cảm giác chờ khác hẳn.
Biến chờ thành đọc; cho phép ngắt sớm nếu output sai hướng.
Cần backend/API hỗ trợ trả theo chunk; không phải model nào cũng có.
2. Ví dụ: LegalDraft đổi spinner tĩnh sang streaming, số request trùng giảm hẳn
Bản đầu: bấm "Tạo điều khoản" → spinner tĩnh → sau 6-12 giây (tùy độ phức tạp) hiện nguyên đoạn văn bản dài. Luật sư phản hồi: cảm giác app "đứng hình", nhiều người bấm lại nút vì tưởng chưa gửi được request - tạo request trùng, tốn API cost.
Đổi sang streaming: chữ hiện dần từng câu ngay khi model sinh ra. Cùng thời gian xử lý 6-12 giây thực tế, nhưng cảm giác chờ biến mất vì luật sư đã bắt đầu đọc từ giây thứ 1. Thêm tác dụng phụ tốt: 2 luật sư báo họ bấm nút dừng giữa chừng khi thấy model đi lạc đề, tiết kiệm cả thời gian đọc lẫn cost - điều không thể làm được với response không stream.
3. Chọn kỹ thuật theo dạng output, không mặc định vì là AI feature
| Kỹ thuật | Giải quyết được gì | Không giải quyết được gì |
|---|---|---|
| Spinner tĩnh | Tác vụ nhanh, ổn định (dưới 1-2s) | Độ trễ biến thiên lớn - trông như app treo |
| Skeleton state | Giảm cảm giác "trống rỗng" trong lúc chờ | Không rút ngắn cảm giác chờ với tác vụ thật sự dài |
| Streaming | Biến chờ thành đọc; cho phép ngắt sớm nếu output sai hướng | Cần backend/API hỗ trợ trả về theo chunk; không phải model nào cũng có sẵn |
Lưu ý: streaming không miễn phí. Với dữ liệu có cấu trúc chặt (JSON, bảng số liệu), streaming từng phần có thể khiến giao diện "nhảy" liên tục hoặc hiện dữ liệu chưa hoàn chỉnh gây hiểu lầm. Chọn stream hay không phụ thuộc dạng output, không phải cứ AI feature là mặc định phải stream.
4. Ẩn dụ: bếp đóng kín và bếp mở
Spinner tĩnh giống đứng trước cửa bếp nhà hàng đóng kín, không biết món đang nấu tới đâu - 10 phút và 2 phút cảm giác chờ y hệt nhau, chỉ có nỗi sốt ruột tăng dần. Streaming giống nhà hàng có bếp mở: bạn thấy đầu bếp đang cắt, đang xào, món ăn được bày dần lên đĩa - cùng 10 phút chờ, nhưng cảm giác hoàn toàn khác vì bạn thấy được tiến trình.
Bài tập 30.1: FinCheck - app AI phân tích báo cáo tài chính công ty, trả về nhận định dài kèm bảng số liệu trích xuất (không chỉ text). Thời gian xử lý dao động 3-15 giây tùy độ dài báo cáo. Chọn 1 trong 3 kỹ thuật trên (hoặc kết hợp) cho phần nhận định dạng text và cho phần bảng số liệu, giải thích vì sao 2 phần này có thể cần cách xử lý khác nhau.