Lợi nhuận:
- Có thể giải thích phát trực tuyến là gì, loại sự kiện và lý do cần thiết.
- max_tokens nắm bắt thời gian chờ và mối quan hệ đầu ra dài 128K
- Có thể đưa ra lựa chọn đúng đắn giữa yêu cầu phát trực tuyến và không phát trực tuyến tùy theo khối lượng công việc
Bạn có thể nhận thấy rằng trong giao diện trò chuyện, câu trả lời được "gõ" từng chữ một. Đây không phải là một sự khởi sắc về mặt hình ảnh; Nó là kết quả của một kỹ thuật được gọi là phát trực tuyến và thường là bắt buộc để tích hợp LLM chất lượng sản xuất. Trong phần này, bạn sẽ tìm hiểu luồng là gì, nó bao gồm những sự kiện nào, mối quan hệ của nó với đầu ra và thời gian chờ dài, cũng như khi nào nên sử dụng luồng và khi nào không. Chúng tôi sẽ đề cập đến chủ đề này thông qua các nhiệm vụ thực sự của một chuyên gia — trợ lý trực tiếp, tạo báo cáo dài, xử lý hàng loạt.
Dòng chảy là gì?
Với yêu cầu không phát trực tuyến (đồng bộ), bạn đợi cho đến khi mô hình tạo ra toàn bộ phản hồi; Khi câu trả lời đã sẵn sàng, nó sẽ đến nguyên vẹn. Trong yêu cầu phát trực tuyến, máy chủ sẽ gửi từng phần phản hồi khi mô hình tạo ra. Về mặt kỹ thuật, việc này được thực hiện với các sự kiện do máy chủ gửi (SSE — Sự kiện do máy chủ gửi, một phương thức trong đó máy chủ gửi các sự kiện nhỏ liên tiếp qua một kết nối mở).
Sự khác biệt trở nên rõ ràng trong trải nghiệm người dùng: đối với phản hồi mất 8 giây, người dùng không phát trực tiếp sẽ nhìn chằm chằm vào màn hình trống trong 8 giây; Người dùng phát trực tuyến sẽ nhìn thấy các từ đầu tiên sau ~0,5 giây và văn bản bắt đầu trôi chảy. Độ trễ cảm nhận được—sự chờ đợi mà người dùng cảm nhận được—giảm đi đáng kể, trong khi tổng thời gian vẫn không thay đổi.
Các loại sự kiện của luồng
Dòng chảy là một chuỗi các sự kiện. Về mặt khái niệm, một quy trình điển hình sẽ diễn ra như sau:
sự cố
Ý nghĩa
tin nhắn_bắt đầu
Phản hồi bắt đầu; Thông tin tiêu đề như model và ID đã đến.
nội dung_block_start
Một khối nội dung (ví dụ: văn bản) đã bắt đầu
nội dung_block_delta
Một đoạn văn bản nhỏ (delta) đã đến; bạn thu thập những thứ này
nội dung_block_stop
khối hoàn thành
tin nhắn_delta
Thông tin kết thúc được cập nhật như stop_reason và cách sử dụng
tin nhắn_stop
Trả lời lại
Mã của bạn kết hợp tuần tự các đoạn văn bản trong sự kiện content_block_delta; bạn sẽ nhận được văn bản chính xác giống như phản hồi không được phát trực tuyến. mức sử dụng (số mã thông báo) thường rõ ràng ở cuối quy trình — bạn theo dõi chi phí sau khi quy trình kết thúc.
Mẹo: Hầu hết các SDK chính thức (Bộ phát triển phần mềm — thư viện tạo sẵn của nhà cung cấp) đều cung cấp trình trợ giúp thu thập luồng cho bạn (ví dụ: stream.get_final_message()). Bạn không cần phải quản lý tất cả các bản nhạc theo cách thủ công; Sử dụng trình trợ giúp này nếu bạn muốn toàn bộ văn bản, xử lý các sự kiện riêng lẻ nhưng để in trực tiếp.
Phản hồi dài, max_tokens và Hết giờ
Nguyên nhân thứ hai và mang tính kỹ thuật hơn của việc phát trực tuyến là thời gian chờ. Nếu yêu cầu HTTP không được hoàn thành trong một khoảng thời gian nhất định, máy khách sẽ ngắt kết nối. Khi bạn yêu cầu một đầu ra lớn từ mô hình (ví dụ: báo cáo 40.000 mã thông báo), cuộc gọi không theo luồng có thể vượt quá giới hạn này và hết thời gian chờ — yêu cầu sẽ không thành công và bạn sẽ phải trả tiền cho các mã thông báo được tạo.
Các mô hình hiện đại có thể xuất tới 128.000 mã thông báo trong một yêu cầu. Nhưng nguyên tắc chung rất rõ ràng: sử dụng luồng nếu giá trị `max_tokens` cao (khoảng trên 16.000). Truyền phát giúp duy trì kết nối và ngăn chặn thời gian chờ; Bạn cũng sẽ thấy sự tiến bộ ngay lập tức.
- `max_tokens`: Mã thông báo đầu ra tối đa mà mô hình có thể tạo ra; trần cứng. Nếu xảy ra gián đoạn, stop_reason max_tokens sẽ được trả về.
- Cửa sổ ngữ cảnh: Cửa sổ trong đó tổng đầu vào + đầu ra phải vừa. max_tokens là mức trần của sản lượng; Đừng trộn lẫn cả hai.
Thận trọng: Việc ném các yêu cầu không theo luồng có max_tokens lớn là một lỗi kinh điển trong quá trình sản xuất. Nếu không có phản hồi, kết nối sẽ bị ngắt, người dùng sẽ thấy lỗi và chi phí mã thông báo sẽ bị lãng phí. Đầu ra dài = luồng.
Khi nào nên chảy và khi nào không?
Trạng thái
sở thích
tại sao
Trò chuyện trực tiếp/trợ lý
dòng chảy
Độ trễ cảm nhận được giảm xuống, người dùng nhìn thấy tiến trình
Sản xuất báo cáo/tài liệu dài
dòng chảy
Ngăn chặn thời gian chờ, mang đầu ra lớn một cách an toàn
Phân loại ngắn (ví dụ: thẻ từ đơn)
không có dòng chảy
Đầu ra đã nhỏ; sự phức tạp bổ sung không cần thiết
Xử lý hàng loạt
không có dòng chảy/mẻ
Kết quả không được hiển thị ngay lập tức; Xem bài 7
Bước tự động hóa (ở chế độ nền)
Thường không có dòng chảy
Bạn chuyển kết quả sang bước tiếp theo, không hiển thị trực tiếp
Lời nhắc/Mẫu có thể sao chép
Bản thân luồng không phải là lời nhắc nhưng lời nhắc rất quan trọng để quản lý đầu ra do luồng tạo ra. Trong các sản phẩm dài và trôi chảy, việc áp đặt cấu trúc từ phía trước sẽ làm tăng cả chất lượng và khả năng truy xuất nguồn gốc.
# Chia báo cáo dài thành nhiều phần (để có thể nhìn thấy tiến trình trong luồng) Viết báo cáo với các tiêu đề sau, theo thứ tự chính xác này. Bắt đầu mỗi tiêu đề bằng '##':## Tóm tắt## Kết quả## Khuyến nghị## Các bước tiếp theo
# Đưa ra độ dài mục tiêu để tránh bị cắt bớt khi sản xuất dài. Tổng văn bản sẽ có khoảng 800 từ. Giữ các phần cân bằng; Đừng để lại nửa câu ở cuối.
# Đưa ngay câu đầu tiên cho trợ lý phát trực tuyến. Trước tiên hãy đưa ra câu trả lời trực tiếp bằng một câu, sau đó đi vào chi tiết. Vì vậy, người dùng sẽ thấy kết quả ngay lập tức trong khi chờ đợi.
# Giữ cấu trúc đầu ra dài (để có thể phân tích cú pháp sau) Xuất đầu ra trong các phần này và đánh dấu mỗi phần bằng một tiêu đề '### ' riêng biệt để tôi có thể phân tích cú pháp theo chương trình: ### GIỚI THIỆU ### BODY ### NGUỒN
Dấu nhắc yếu / Dấu nhắc mạnh (sản xuất dài)
# YẾUViết một báo cáo dài và chi tiết về chủ đề này.
# MẠNH Viết một báo cáo khoảng 900 từ về chủ đề này. Các tiêu đề: ## Tóm tắt, ## Phân tích, ## Rủi ro, ## Khuyến nghị. Mỗi tiêu đề có tối đa 3 đoạn văn. Đừng để lại nửa câu ở cuối.
Phiên bản mạnh mẽ; Nó xác định trước chiều dài, cấu trúc và chất lượng hoàn thiện. Khi các phần được đưa vào luồng, người dùng sẽ thấy rõ tiến trình và tự quản lý độ dài để tránh nguy cơ gián đoạn mô hình.
Ba hộp nhỏ
Trường hợp 1 - Khiếu nại màn hình trống. Trợ lý khách hàng của nhóm tư vấn đã phản hồi không trôi chảy; phản hồi trung bình mất 7 giây, người dùng hỏi "nó có bị treo không?" anh ấy phàn nàn. Khi tôi bắt đầu mạch, từ đầu tiên sẽ xuất hiện sau ~0,6 giây; Tổng thời gian vẫn giữ nguyên nhưng những lời phàn nàn “chậm” gần như biến mất.
Trường hợp 2 - Báo cáo lỗi thời. Một nhóm tài chính đang chuẩn bị một bản báo cáo quý dài 30 trang; Với max_tokens: 30000, yêu cầu không có luồng sẽ bị kẹt trong thời gian chờ 60 giây của máy khách, yêu cầu sẽ không thành công — và mã thông báo được tạo sẽ được ghi vào hóa đơn. Họ đã đi theo dòng chảy; kết nối vẫn hoạt động, báo cáo được gửi đầy đủ và chi phí lãng phí được loại bỏ.
Trường hợp 3 - Dòng chảy không cần thiết. Nhóm điều hành đã dán nhãn các email đến là “khẩn cấp/thường xuyên”; Đầu ra chỉ là một từ, nhưng họ thường sử dụng dòng chảy. Luồng này không mang lại lợi ích gì trong phản hồi một từ, khiến mã trở nên phức tạp không cần thiết. Khi tôi chuyển sang chế độ không có dòng chảy, mã đã được đơn giản hóa và hoạt động vẫn như cũ. Bài học: phát trực tuyến có giá trị ở đầu ra dài/trực tiếp, không phải ở mọi nơi.
Những lỗi thường gặp
- Không sử dụng luồng ở đầu ra dài: Hết thời gian chờ và lãng phí chi phí mã thông báo.
- Sử dụng tính năng phát trực tuyến ở đầu ra ngắn: Độ phức tạp không cần thiết, không mang lại lợi ích gì.
- Không kiểm tra `stop_reason` ở cuối luồng: phản hồi bị cắt ngắn bằng max_tokens được coi là hoàn tất.
- Việc hợp nhất các delta không chính xác: Tính tổng thủ công bằng trình trợ giúp SDK tạo ra lỗi trình tự/phần bị thiếu.
- Cố gắng đọc `cách sử dụng` giữa dòng: Số mã thông báo thường trở nên rõ ràng ở cuối; Theo dõi chi phí vào cuối.
- Hiểu nhầm việc phát trực tuyến để cắt giảm chi phí: Phát trực tuyến cải thiện trải nghiệm và độ bền; Nó không thay đổi giá token.
Sâu hơn: Sự gián đoạn dòng chảy và khả năng phục hồi
Truyền phát là kết nối trực tiếp; Đây vừa là điểm mạnh vừa là điểm yếu của nó. Nếu kết nối bị rớt giữa chừng (dao động mạng, thời gian chờ của máy khách), bạn sẽ giữ lại văn bản mà bạn đã tích lũy cho đến nay, nhưng phản hồi sẽ không đầy đủ. Ứng dụng khách phát trực tuyến chất lượng sản xuất nên chuẩn bị cho điều này: ứng dụng này không được coi một phần văn bản là "phản hồi đã hoàn thành" và cũng không nên coi phản hồi là đã hoàn tất cho đến khi nhìn thấy sự kiện message_stop.
Điều tinh tế thứ hai là dòng chảy không làm thay đổi chi phí. Việc bạn nhận được phản hồi có hoặc không có phát trực tuyến đều không ảnh hưởng đến giá mã thông báo; dòng chảy chỉ cải thiện kinh nghiệm và sức chịu đựng. Vì vậy, “nếu chúng tôi phát trực tuyến, liệu chúng có rẻ hơn không?” Câu trả lời cho câu hỏi là không - về chi phí, hãy xem đơn vị thứ 5 và thứ 6 (lựa chọn kiểu máy, bộ đệm).
Điểm thứ ba là đạt được sự cân bằng thực tế: với trợ lý trực tiếp, việc xuất hiện nhanh chóng từ đầu tiên (độ trễ nhận thức) được đánh giá cao; Do đó, việc yêu cầu người mẫu nhập câu trả lời trực tiếp và đưa ra kết quả ngắn trước (thông qua lời nhắc hệ thống ở đơn vị thứ 4) sẽ nhân lên lợi ích của quy trình. Nếu người dùng nhìn thấy điều gì đó có ý nghĩa trong giây đầu tiên, họ sẽ kiên nhẫn chờ đợi chi tiết tiếp theo. Mặt khác, luồng không có đóng góp nào cho các công việc chạy ở chế độ nền, đầu ra của chúng sẽ chuyển sang bước tự động hóa tiếp theo; Tiêu chí duy nhất ở đây là công việc được hoàn thành chính xác và đầy đủ.
Tóm lại
Truyền phát truy xuất từng phần phản hồi, giảm độ trễ nhận thấy và ngăn chặn thời gian chờ trên thông lượng lớn. Hầu như bắt buộc đối với trợ lý trực tiếp và sản xuất tài liệu dài; Nó không cần thiết cho công việc ngắn/nền. Trong các sản phẩm dài, việc áp đặt cấu trúc và chiều dài từ phía trước một cách nhanh chóng sẽ làm tăng cả chất lượng và khả năng truy xuất nguồn gốc; Khi luồng kết thúc, stop_reason và mức sử dụng chắc chắn sẽ được kiểm tra.
Nhiệm vụ ứng dụng
Chọn hai kịch bản: một trực tiếp/dài hạn (ví dụ: báo cáo cho khách hàng), một kịch bản ngắn/nền (ví dụ: gắn thẻ). (1) Quyết định và chứng minh xem bạn có sử dụng quy trình cho từng mục hay không. (2) Viết lời nhắc áp đặt cấu trúc cho đoạn chữ dài (tiêu đề + độ dài mục tiêu). (3) Xác định giá trị max_tokens. (4) Liệt kê những bước kiểm tra bạn sẽ thực hiện với stop_reason và mức sử dụng ở cuối quy trình.
danh sách kiểm tra
- [ ] Tôi có thể giải thích tính năng phát trực tuyến là gì và nó làm giảm độ trễ nhận thấy như thế nào.
- [ ] Tôi đã hiểu các loại sự kiện cơ bản của việc nối luồng và nối delta.
- [ ] Tôi biết về nhu cầu phát trực tuyến với max_tokens lớn và mối quan hệ thời gian chờ.
- [ ] Tôi có thể quyết định khối lượng công việc nào tôi sẽ sử dụng tính năng phát trực tuyến và khối lượng công việc nào tôi sẽ không sử dụng.
- [ ] Tôi có thể kiểm tra stop_reason và mức sử dụng ở cuối luồng.