Thực hànhTrung cấp

Streaming: hiển thị sớm nhưng phải kết thúc đúng

Thiết kế trạng thái cho câu trả lời đang truyền, phân biệt thời gian có chữ đầu tiên với thời gian có kết quả dùng được.

Trong bài viết này

Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.

Câu trả lời đã hiện nửa màn hình rồi mạng ngắt. Người dùng bấm sao chép và gửi phần thiếu cho đồng nghiệp vì giao diện trông giống một kết quả hoàn chỉnh. Streaming đã giúp họ thấy chữ sớm, nhưng trạng thái cuối không được truyền đạt rõ.

Một luồng văn bản tốt cần thiết kế cả lúc chưa có dữ liệu, lúc đang nhận, lúc hoàn tất và lúc chỉ có kết quả một phần.

Đo hai mốc thời gian khác nhau

Thời gian đến nội dung đầu tiên phản ánh lúc người dùng bắt đầu nhận phản hồi. Thời gian đến kết quả dùng được phản ánh lúc nhiệm vụ có thể tiếp tục. Hai mốc này phục vụ hai câu hỏi khác nhau.

Trong ví dụ giả định, câu đầu xuất hiện nhanh nhưng phần kết luận phải chờ công cụ tra cứu. Không nên báo tác vụ xong khi chỉ có lời mở đầu. Nếu kết quả là dữ liệu có cấu trúc, JSON nhận được giữa chừng thường chưa đủ để xác nhận biểu mẫu.

Theo hướng dẫn Server-Sent Events của MDN, SSE truyền sự kiện theo một chiều từ máy chủ tới trình duyệt. Đây là một cách vận chuyển luồng, còn ý nghĩa của từng sự kiện và trạng thái công việc vẫn do ứng dụng thiết kế.

Mô hình hóa trạng thái rõ ràng

Một quy trình minh họa có thể dùng các trạng thái:

đang gửi → đang chờ → đang nhận → hoàn tất
                         ↘ bị ngắt
                         ↘ người dùng dừng

Khi đang nhận, hiển thị nhãn ngắn và nút dừng. Khi bị ngắt, giữ phần văn bản đã nhận nhưng gắn trạng thái chưa hoàn tất và cung cấp đường thử lại. “Người dùng dừng” cũng khác “lỗi mạng”: cách diễn đạt và hành vi tiếp theo nên phản ánh nguyên nhân.

Đừng dùng việc đóng kết nối làm dấu hiệu hoàn tất duy nhất. Giao thức ứng dụng cần sự kiện kết thúc rõ, kèm mã yêu cầu và trạng thái. Nếu kết nối đóng mà chưa có sự kiện ấy, xử lý như kết quả chưa xác định hoặc chưa hoàn chỉnh.

Nhìn để hiểuAPI hay tự vận hành: nhìn cả hệ thống

API chuyển phần vận hành mô hình cho nhà cung cấp; tự vận hành đưa thêm trách nhiệm về phía đội ngũ của bạn. Cả hai lựa chọn đều cần kiểm tra quyền sử dụng, dữ liệu và chất lượng trên công việc cụ thể.

Hai cách vận hành, cùng trách nhiệm kiểm tra chất lượngỨng dụng có thể gọi API của một nhà cung cấp hoặc tự vận hành mô hình. API giao phần vận hành mô hình cho nhà cung cấp nhưng vẫn cần kiểm tra tích hợp, điều khoản và dữ liệu. Tự vận hành đòi hỏi hạ tầng, cập nhật và giám sát. Cả hai cách đều phải được đánh giá trên nhu cầu thật.Ứng dụngGọi APITự vận hànhNhà cung cấp vận hànhBạn kiểm tra tích hợp, dữ liệuBạn vận hành mô hìnhHạ tầng · cập nhật · giám sátCùng kiểm tra chất lượng tiếng Việt

↔ Vuốt ngang để xem toàn bộ sơ đồ.

  1. 01 / Dùng API

    Ứng dụng gửi yêu cầu tới dịch vụ vận hành mô hình. Cần kiểm tra điều khoản và chính sách xử lý dữ liệu.

  2. 02 / Tự vận hành

    Mô hình chạy trên hạ tầng do bạn quản lý, nếu giấy phép và phần mềm cho phép.

  3. 03 / Rõ trách nhiệm

    Với tự vận hành, đội ngũ lo tài nguyên, cập nhật và giám sát. Cả hai cách vẫn cần kiểm soát luồng dữ liệu của ứng dụng.

  4. 04 / Thử đúng công việc

    Đo chất lượng tiếng Việt, thời gian, tổng chi phí và công sức sửa lỗi trên cùng nhiệm vụ trước khi chọn.

Đây là khung so sánh, không phải kết luận về một nhà cung cấp hay cấu hình cụ thể. Tải được trọng số không tự động đồng nghĩa với mã nguồn mở.

Ghép luồng mà không nhân đôi nội dung

Các mảnh mạng không nhất thiết trùng ranh giới ký tự hoặc câu. Bộ giải mã cần giữ trạng thái cho chuỗi byte chưa hoàn chỉnh. Phần giao diện cũng không nên giả định mỗi mảnh là một đoạn Markdown đầy đủ.

Nếu hỗ trợ kết nối lại, thiết kế số thứ tự sự kiện hoặc điểm tiếp tục theo hợp đồng phía máy chủ. Khi nhận lại sự kiện cũ, khách hàng phải nhận diện được để tránh nối lặp câu. Không có cơ chế tiếp tục thì thử lại nên tạo một lần sinh mới có nhãn rõ ràng.

Với tác vụ gọi công cụ, văn bản đang hiện không chứng minh hành động đã hoàn thành. Kết quả đặt lịch phải được xác nhận từ dịch vụ đặt lịch; một câu “mình đang đặt” chỉ là thông báo tiến trình.

Đánh đổi giữa tốc độ và độ ổn định giao diện

Cập nhật mỗi mảnh rất nhỏ có thể làm giao diện nhấp nháy và tăng công việc kết xuất. Gom các mảnh trong một khoảng ngắn giúp đọc dễ hơn nhưng tăng chút độ trễ hiển thị. Chọn cách gom bằng thử nghiệm trên thiết bị thực, không chỉ máy phát triển.

Tránh kéo cuộn xuống liên tục khi người dùng đã cuộn lên đọc. Một dấu báo “có nội dung mới” giữ quyền điều khiển tốt hơn. Với trình đọc màn hình, thông báo từng token tạo nhiễu; ưu tiên trạng thái và đơn vị nội dung có nghĩa.

Lỗi thường gặp là đo streaming bằng ảnh chụp sau khi hoàn tất. Ảnh ấy không thể hiện gián đoạn, nút dừng, cuộn trang hay trạng thái mất kết nối. Cần kiểm tra toàn bộ diễn biến.

Bài tập: ngắt mạng giữa câu

Tạo luồng giả định trả một hướng dẫn nhiều bước, rồi chủ động ngắt sau khi bước đầu xuất hiện. Kiểm tra lại với hành động dừng của người dùng và với hai sự kiện có cùng mã thứ tự.

Tiêu chí đạt: phần trả lời thiếu không được gắn “hoàn tất”, nút dừng có tác dụng quan sát được, sự kiện lặp không nhân đôi chữ và người dùng có thể tiếp tục đọc ở vị trí đã chọn. Ghi riêng hai mốc thời gian ở đầu bài để đánh giá lợi ích thực tế của streaming.

Bạn muốn hiểu điều gì?

Khám phá tất cả bài viết esc để đóng