Keuntungan:
- Boleh menerangkan apa itu penstriman, jenis acara dan sebab ia diperlukan.
- max_tokens memahami tamat masa dan hubungan keluaran sepanjang 128K
- Boleh membuat pilihan yang tepat antara permintaan penstriman dan bukan penstriman mengikut beban kerja
Anda mungkin perasan bahawa dalam antara muka sembang, respons adalah "ditaip" perkataan demi perkataan. Ini bukan perkembangan visual; Ia adalah hasil daripada teknik yang dipanggil penstriman dan selalunya wajib untuk penyepaduan LLM berkualiti pengeluaran. Dalam unit ini, anda akan mempelajari apakah aliran, peristiwa yang terdiri daripadanya, hubungannya dengan keluaran yang panjang dan tamat masa, dan bila hendak menggunakan aliran dan bila tidak. Kami akan membincangkan topik ini melalui tugas sebenar seorang profesional — pembantu langsung, penjanaan laporan panjang, pemprosesan kelompok.
Apakah Aliran?
Dengan permintaan bukan strim (segerak), anda menunggu sehingga model menghasilkan keseluruhan respons; Apabila jawapan sudah siap, ia tiba dalam satu bahagian. Dalam permintaan penstriman, pelayan menghantar respons sekeping demi sekeping semasa model menjana. Secara teknikal, ini dilakukan dengan acara yang dihantar pelayan (SSE — Acara Dihantar Pelayan, kaedah di mana pelayan menghantar acara kecil berturut-turut melalui sambungan terbuka).
Perbezaannya menjadi jelas dalam pengalaman pengguna: pada respons yang mengambil masa 8 saat, pengguna bukan strim merenung skrin kosong selama 8 saat; Pengguna penstriman melihat perkataan pertama dalam ~0.5 saat dan teks mula mengalir. Kependaman yang dirasakan—penantian yang dirasai pengguna—sangat berkurangan, manakala jumlah masa kekal tidak berubah.
Jenis Aliran Acara
Aliran ialah urutan peristiwa. Dari segi konsep, aliran biasa berlaku seperti ini:
kejadian
Maknanya
mesej_mula
Sambutan bermula; Maklumat pengepala seperti model dan ID telah tiba.
content_block_start
Satu blok kandungan (cth. teks) bermula
content_block_delta
Sekeping kecil teks (delta) tiba; anda kumpulkan ini
content_block_stop
blok selesai
mesej_delta
Maklumat penamat yang dikemas kini seperti stop_reason dan penggunaan
message_stop
Balas habis
Kod anda secara berurutan menggabungkan kepingan teks dalam acara content_block_delta; anda akan mendapat teks tepat yang sama seperti respons tidak distrim. penggunaan (nombor token) biasanya jelas pada penghujung aliran — anda menjejaki kos sebaik sahaja aliran tamat.
Petua: Kebanyakan SDK rasmi (Kit Pembangunan Perisian — pustaka sedia untuk pembekal) menyediakan pembantu yang mengumpulkan strim untuk anda (cth. stream.get_final_message()). Anda tidak perlu mengurus semua trek secara manual; Gunakan pembantu ini jika anda mahukan teks penuh, proses acara individu tetapi untuk pencetakan langsung.
Respons Panjang, max_token dan Tamat Masa
Punca penstriman kedua dan lebih teknikal ialah tamat masa. Jika permintaan HTTP tidak diselesaikan dalam tempoh masa tertentu, pelanggan memutuskan sambungan. Apabila anda meminta output yang besar daripada model (cth. laporan 40,000 token), panggilan bukan aliran mungkin melebihi had dan masa tamat ini — permintaan akan gagal dan anda perlu membayar untuk token yang dijana.
Model moden boleh mengeluarkan sehingga 128,000 token dalam satu permintaan. Tetapi peraturan praktikal adalah jelas: gunakan strim jika nilai `maks_tokens` adalah tinggi (kira-kira melebihi 16,000). Penstriman memastikan sambungan hidup dan menghalang tamat masa; Anda juga akan melihat kemajuan serta-merta.
- `max_tokens`: Token output maksimum yang boleh dihasilkan oleh model; siling yang keras. Jika gangguan berlaku, stop_reason max_tokens dikembalikan.
- Tetingkap konteks: Tetingkap di mana jumlah input + output mesti muat. max_tokens ialah siling output; Jangan campur kedua-duanya.
Awas: Melemparkan permintaan bukan aliran dengan max_tokens yang besar ialah kesilapan klasik dalam pengeluaran. Tanpa respons, sambungan terputus, pengguna melihat ralat, dan kos token dibazirkan. Keluaran panjang = aliran.
Bila Untuk Mengalir dan Bila Tidak?
Status
keutamaan
kenapa
Sembang langsung / pembantu
aliran
Kependaman yang dirasakan menurun, pengguna melihat kemajuan
Laporan panjang / pengeluaran dokumen
aliran
Menghalang tamat masa, membawa keluaran besar dengan selamat
Klasifikasi pendek (cth. tag perkataan tunggal)
tiada aliran
Keluaran sudah kecil; kerumitan tambahan yang tidak diperlukan
Pemprosesan kelompok
tidak mengalir/berkelompok
Keputusan tidak ditunjukkan serta-merta; Lihat unit 7
Langkah automasi (di latar belakang)
Selalunya tiada aliran
Anda menghantar keputusan ke langkah seterusnya, tiada paparan langsung
Prompt/Templat Boleh Disalin
Strim itu sendiri bukanlah gesaan, tetapi gesaan adalah penting untuk menguruskan output yang dihasilkan oleh aliran. Dalam pengeluaran yang panjang dan mengalir, mengenakan struktur dari hadapan meningkatkan kualiti dan kebolehkesanan.
# Bahagikan laporan panjang kepada bahagian (supaya kemajuan dapat dilihat dalam aliran) Tulis laporan dengan tajuk berikut, dalam susunan yang tepat ini. Mulakan setiap tajuk dengan '## ':## Ringkasan## Penemuan## Cadangan## Langkah seterusnya
# Berikan panjang sasaran untuk mengelakkan pemotongan dalam pengeluaran panjang. Jumlah teks akan menjadi lebih kurang 800 patah perkataan. Pastikan bahagian seimbang; Jangan tinggalkan separuh ayat di penghujungnya.
# Berikan ayat pertama dengan segera untuk pembantu penstriman. Beri jawapan langsung satu ayat dahulu, kemudian terperinci. Jadi pengguna melihat hasil serta-merta semasa menunggu.
# Pastikan output panjang berstruktur (supaya ia boleh dihuraikan kemudian) Output output dalam bahagian ini dan tandakan setiap bahagian dengan pengepala '### ' yang berasingan supaya saya boleh menghuraikannya secara pemrograman: ### PENGENALAN ### BODY ### SUMBER
Gesaan lemah / Gesaan kuat (pengeluaran lama)
# WEAKWtulis laporan yang panjang dan terperinci tentang topik ini.
# STRONGTulis laporan kira-kira 900 perkataan mengenai topik ini. Tajuk: ## Ringkasan, ## Analisis, ## Risiko, ## Syor. Setiap tajuk hendaklah maksimum 3 perenggan. Jangan tinggalkan separuh ayat di penghujungnya.
Versi berkuasa; Ia menentukan panjang, struktur dan kualiti kemasan terlebih dahulu. Apabila bahagian masuk dalam aliran, pengguna melihat kemajuan dengan jelas dan menguruskan sendiri panjangnya terhadap risiko gangguan model.
Tiga Kes Mini
Kes 1 — Aduan skrin kosong. Pembantu pelanggan pasukan perunding bertindak balas tanpa aliran; tindak balas purata mengambil masa 7 saat, pengguna bertanya "adakah ia membeku?" dia mengeluh. Sebaik sahaja saya masuk ke dalam aliran, perkataan pertama datang dalam ~0.6 saat; Jumlah masa tetap sama, tetapi aduan "lambat" hampir hilang.
Kes 2 — Laporan lapuk. Sebuah pasukan kewangan telah menghasilkan laporan suku tahunan 30 muka surat; Dengan max_tokens: 30000, permintaan tiada aliran akan tersekat dalam tamat masa pelanggan 60 saat, permintaan akan gagal — dan token yang dijana akan ditulis pada invois. Mereka mengikuti arus; sambungan kekal secara langsung, laporan telah dihantar sepenuhnya, dan kos yang terbuang telah dihapuskan.
Kes 3 — Aliran yang tidak perlu. Pasukan operasi telah melabelkan e-mel masuk sebagai "mendesak/biasa"; Keluaran adalah satu perkataan, tetapi mereka lazimnya menggunakan aliran. Aliran ini tidak memberikan faedah dalam tindak balas satu perkataan, menjadikan kod itu tidak perlu rumit. Apabila saya beralih kepada tidak mengalir, kod dipermudahkan dan tingkah laku kekal sama. Pengajaran: penstriman bernilai dalam output jangka panjang/langsung, bukan di mana-mana sahaja.
Kesilapan biasa
- Tidak menggunakan strim dalam output yang panjang: Tamat masa dan kos token terbuang.
- Menggunakan penstriman dalam output pendek: Kerumitan yang tidak perlu, faedah sifar.
- Tidak menandai `stop_reason` di penghujung strim: respons terpotong dengan max_tokens dianggap lengkap.
- Menggabungkan delta tidak betul: Penjumlahan manual dengan pembantu SDK menghasilkan ralat urutan/bahagian yang hilang.
- Cuba membaca `penggunaan` pertengahan strim: Nombor token biasanya menjadi jelas pada penghujungnya; Jejaki kos pada akhir.
- Tersilap penstriman untuk mengurangkan kos: Penstriman meningkatkan pengalaman dan daya tahan; Ia tidak mengubah harga token.
Lebih Dalam: Pecah Aliran dan Ketahanan
Penstriman ialah sambungan langsung; Ini adalah kekuatan dan kelemahannya. Jika sambungan terputus di tengah (turun naik rangkaian, tamat masa pelanggan), anda akan mengekalkan teks yang telah anda kumpulkan setakat ini, tetapi respons tidak akan lengkap. Klien penstriman kualiti pengeluaran harus bersedia untuk ini: ia tidak seharusnya menganggap teks separa sebagai "tindak balas yang lengkap", dan tidak juga menganggap respons itu akan selesai sehingga ia melihat peristiwa message_stop.
Kehalusan kedua ialah aliran tidak mengubah kos. Sama ada anda menerima respons dengan atau tanpa penstriman tidak menjejaskan harga token; aliran hanya meningkatkan pengalaman dan ketahanan. Jadi "jika kita pergi streaming, adakah mereka akan lebih murah?" Jawapan kepada soalan adalah tidak — untuk kos, lihat unit ke-5 dan ke-6 (pemilihan model, cache).
Perkara ketiga adalah untuk mencapai keseimbangan praktikal: dengan pembantu langsung, ketibaan pantas perkataan pertama (dianggap kelewatan) sangat dihargai; Oleh itu, meminta model memasukkan jawapan secara terus dan memberikan hasil pendek terlebih dahulu (melalui gesaan sistem dalam unit ke-4) menggandakan manfaat aliran. Jika pengguna melihat sesuatu yang bermakna dalam detik pertama, mereka menunggu dengan sabar untuk butiran yang berikut. Sebaliknya, aliran tidak mempunyai sumbangan kepada pekerjaan yang dijalankan di latar belakang, outputnya pergi ke langkah automasi seterusnya; Satu-satunya kriteria yang ada ialah kerja itu disiapkan dengan betul dan lengkap.
Secara ringkasnya
Penstriman mendapatkan semula respons sekeping demi sekeping, mengurangkan kependaman yang dirasakan dan menghalang tamat masa pada pemprosesan yang besar. Hampir wajib untuk pembantu langsung dan pengeluaran dokumen panjang; Ia tidak perlu untuk kerja pendek/latar belakang. Dalam pengeluaran yang panjang, mengenakan struktur dan panjang dari hadapan dengan segera meningkatkan kualiti dan kebolehkesanan; Apabila aliran selesai, stop_reason dan penggunaan pasti disemak.
Tugasan permohonan
Pilih dua senario: satu secara langsung/panjang (cth. laporkan kepada pelanggan), satu pendek/latar belakang (cth. penandaan). (1) Tentukan dan wajarkan sama ada anda akan menggunakan aliran untuk setiap satu. (2) Tulis gesaan yang mengenakan struktur untuk skrip panjang (tajuk + panjang sasaran). (3) Tentukan nilai max_tokens. (4) Senaraikan pemeriksaan yang akan anda lakukan dengan stop_reason dan penggunaan pada penghujung aliran.
senarai semak
- [ ] Saya boleh menerangkan apa itu penstriman dan cara ia mengurangkan kependaman yang dilihat.
- [ ] Saya memahami jenis acara asas bagi aliran dan delta yang bergabung.
- [ ] Saya tahu tentang keperluan untuk menstrim dengan max_token yang besar dan hubungan tamat masa.
- [ ] Saya boleh memutuskan beban kerja mana yang akan saya gunakan penstriman dan yang mana saya tidak akan gunakan.
- [ ] Saya boleh menyemak stop_reason dan penggunaan pada penghujung strim.