Ieguvumi:
- Var izskaidrot, kas ir straumēšana, notikumu veidus un kāpēc tā ir nepieciešama.
- max_tokens uztver taimautu un 128 K garu izvades attiecību
- Var izdarīt pareizo izvēli starp straumēšanas un nestraumēšanas pieprasījumiem atbilstoši darba slodzei
Iespējams, esat pamanījis, ka tērzēšanas saskarnē atbilde tiek "rakstīta" vārds pa vārdam. Tas nav vizuāls uzplaukums; Tas ir tehnikas, ko sauc par straumēšanu, rezultāts un bieži vien ir obligāts ražošanas kvalitātes LLM integrācijai. Šajā nodaļā jūs uzzināsit, kas ir plūsma, no kādiem notikumiem tā sastāv, tās saistību ar ilgu izvadi un taimautu un kad izmantot plūsmu un kad ne. Tēmu aplūkosim caur reālajiem profesionāļa uzdevumiem — tiešraides asistentu, garu atskaišu ģenerēšanu, pakešu apstrādi.
Kas ir plūsma?
Ar nestraumēšanas (sinhronu) pieprasījumu jūs gaidāt, līdz modelis ģenerē visu atbildi; Kad atbilde ir gatava, tā nonāk vienā gabalā. Straumēšanas pieprasījumā serveris nosūta atbildi pa daļām, modelim ģenerējot. Tehniski tas tiek darīts ar servera nosūtītiem notikumiem (SSE — Server-Sent Events — metode, kurā serveris sūta mazus notikumus pēc kārtas, izmantojot atvērtu savienojumu).
Atšķirība kļūst acīmredzama lietotāja pieredzē: atbildot, kas ilgst 8 sekundes, lietotājs, kas nav straumes lietotājs, skatās uz tukšu ekrānu 8 sekundes; Straumēšanas lietotājs pirmos vārdus redz ~0,5 sekundēs un teksts sāk plūst. Uztvertais latentums — lietotāja jūtams gaidīšanas laiks — ir ievērojami samazināts, bet kopējais laiks paliek nemainīgs.
Notikumu plūsmas veidi
Plūsma ir notikumu secība. Konceptuāli tipiska plūsma ir šāda:
incidents
Nozīme
message_start
Sākās atbilde; Ir saņemta galvenes informācija, piemēram, modelis un ID.
content_block_start
Sākts satura (piem., teksta) bloks
content_block_delta
Sanāca neliels teksta fragments (delta); jūs tos savācat
content_block_stop
bloks pabeigts
message_delta
Atjaunināta beigu informācija, piemēram, stop_reason un lietojums
message_stop
Atbildiet tālāk
Jūsu kods secīgi apvieno teksta daļas notikumos content_block_delta; jūs saņemat tādu pašu tekstu kā nestraumētā atbilde. lietojums (marķieru skaitļi) parasti ir skaidrs plūsmas beigās — jūs sekojat līdzi izmaksām, kad plūsma ir beigusies.
Padoms. Lielākā daļa oficiālo SDK (Software Development Kit — nodrošinātāja gatava bibliotēka) nodrošina palīgu, kas apkopo straumi jūsu vietā (piemēram, stream.get_final_message()). Jums nav manuāli jāpārvalda visi ieraksti; Izmantojiet šo palīgu, ja vēlaties pilnu tekstu, apstrādāt atsevišķus notikumus, bet tiešraidē.
Garas atbildes, max_tokens un taimauts
Otrs un tehniskāks straumēšanas iemesls ir taimauts. Ja HTTP pieprasījums netiek pabeigts noteiktā laika periodā, klients pārtrauc savienojumu. Pieprasot lielu modeļa izvadi (piemēram, atskaiti par 40 000 marķieriem), neplūsmas izsaukums var pārsniegt šo ierobežojumu un beigties taimauts — pieprasījums neizdosies, un jums būs jāmaksā par ģenerētajiem marķieriem.
Mūsdienu modeļi var izvadīt līdz 128 000 marķieru vienā pieprasījumā. Taču īkšķis ir skaidrs: izmantojiet straumes, ja vērtība “max_tokens” ir augsta (aptuveni virs 16 000). Straumēšana uztur savienojumu un novērš taimautu; Jūs arī uzreiz redzēsit progresu.
- "max_tokens": maksimālais izvades marķieri, ko modelis var radīt; cieti griesti. Ja notiek pārtraukums, tiek atgriezts stop_reason max_tokens.
- Konteksta logs: logs, kurā jāiekļaujas ievades un izvades summai. max_tokens ir izvades griesti; Nejauciet abus.
Uzmanību! Neplūsmas pieprasījumu izvirzīšana ar lieliem max_tokens ir klasiska kļūda ražošanā. Ja netiek sniegta atbilde, savienojums tiek pārtraukts, lietotājs redz kļūdu, un marķiera izmaksas tiek iztērētas. Gara izvade = straume.
Kad plūst un kad ne?
Statuss
priekšroka
Kāpēc
Tiešraides tērzēšana / palīgs
plūsma
Uztvertais latentums samazinās, lietotājs redz progresu
Gara atskaite/dokumentu izgatavošana
plūsma
Novērš taimautu, droši pārnēsā lielu izvadi
Īsa klasifikācija (piemēram, viena vārda atzīme)
nav plūsmas
Izlaide jau tā ir maza; papildu sarežģītība nav nepieciešama
Partijas apstrāde
bezplūsmas/partija
Rezultāti netiek parādīti uzreiz; Skatīt 7. vienību
Automatizācijas solis (fonā)
Parasti nav plūsmas
Jūs nododat rezultātu nākamajai darbībai, bez tiešraides
Kopējamas uzvednes/veidnes
Pati straume nav uzvedne, taču uzvednes ir būtiskas, lai pārvaldītu straumes radīto izvadi. Garās un plūstošās izrādēs struktūras uzspiešana no priekšpuses uzlabo gan kvalitāti, gan izsekojamību.
# Sadaliet garo pārskatu sadaļās (lai plūsmā būtu redzams progress) Uzrakstiet atskaiti ar šādiem virsrakstiem, tieši šādā secībā. Sāciet katru virsrakstu ar '##':## Kopsavilkums## Secinājumi## Ieteikumi## Nākamās darbības
# Norādiet mērķa garumu, lai izvairītos no saīsināšanas ilgstošas ražošanas laikā. Kopējais teksta apjoms būs aptuveni 800 vārdu. Saglabājiet porcijas līdzsvarotu; Neatstājiet pusi teikuma beigās.
# Nekavējoties sniedziet pirmo teikumu straumēšanas palīgam. Vispirms sniedziet tiešu viena teikuma atbildi, pēc tam iedziļinieties detaļās. Tātad lietotājs gaidīšanas laikā redz tūlītēju rezultātu.
# Saglabājiet garo izvadi strukturētu (lai to varētu parsēt vēlāk) Izvadiet izvadi šajās sadaļās un atzīmējiet katru sadaļu ar atsevišķu galveni ###, lai es varētu to parsēt programmatiski: ### IEVADS ### BODY ### AVOTI
Vāja uzvedne/Spēcīga uzvedne (ilgi ražošana)
# WEAKUzrakstiet garu un detalizētu ziņojumu par šo tēmu.
# STRONGUzrakstiet aptuveni 900 vārdu garu ziņojumu par šo tēmu. Virsraksti: ## Kopsavilkums, ## Analīze, ## Riski, ## Ieteikumi. Katrā virsrakstā jābūt ne vairāk kā 3 rindkopām. Neatstājiet pusi teikuma beigās.
Jaudīga versija; Tas jau iepriekš nosaka garumu, struktūru un apdares kvalitāti. Plūsmā nākot sadaļām, lietotājs skaidri redz progresu un pats pārvalda garumu, lai novērstu modeļa pārtraukšanas risku.
Trīs mini futrāļi
1. gadījums — sūdzība par tukšu ekrānu. Konsultāciju komandas klientu palīgs atbildēja bez plūsmas; vidēji atbilde aizņem 7 sekundes, lietotāji jautā "vai tas sasalst?" viņš sūdzējās. Kad iekļuvu plūsmā, pirmais vārds nāca ~0,6 sekundēs; Kopējais laiks palika nemainīgs, bet "lēnās" sūdzības gandrīz pazuda.
2. gadījums — novecojis ziņojums. Finanšu komanda sagatavoja 30 lappušu garu ceturkšņa pārskatu; Izmantojot max_tokens: 30000, bezplūsmas pieprasījums iestrēgst 60 sekunžu klienta taimautā, pieprasījums neizdosies — un ģenerētie marķieri tiktu ierakstīti rēķinā. Viņi gāja straumei līdzi; savienojums palika dzīvs, ziņojums tika piegādāts pilnā apjomā un tika novērstas izšķērdētās izmaksas.
3. gadījums — nevajadzīga plūsma. Operāciju komanda ienākošos e-pastus atzīmēja kā “steidzami/parasti”; Izvade bija viens vārds, bet viņi parasti izmantoja plūsmu. Plūsma nesniedza nekādu labumu viena vārda atbildē, padarot kodu nevajadzīgi sarežģītu. Kad pārgāju uz bezplūsmas režīmu, kods tika vienkāršots un darbība palika tāda pati. Nodarbība: straumēšana ir vērtīga ilgā/tiešraidē, ne visur.
Biežas kļūdas
- Strauju neizmantošana garā izvadē: noildze un izšķērdēta marķiera izmaksas.
- Straumēšanas izmantošana īsā izvadē: nevajadzīga sarežģītība, nulles ieguvums.
- Netiek pārbaudīts `stop_reason` straumes beigās: saīsinātā atbilde ar max_tokens tiek uzskatīta par pabeigtu.
- Nepareizi sapludinātas deltas: manuāla summēšana ar SDK palīgu rada secības/trūkstošu daļu kļūdu.
- Mēģinājums nolasīt lietojumu straumes vidū: marķiera numuri parasti kļūst skaidri beigās; Beigās sekojiet līdzi izmaksām.
- Straumēšanas kļūdaina izmantošana izmaksu samazināšanai: straumēšana uzlabo pieredzi un izturību; Tas nemaina žetonu cenu.
Deeper: plūsmas pārtraukumi un noturība
Straumēšana ir tiešraides savienojums; Tas ir gan tā spēks, gan neaizsargātība. Ja savienojums samazinās vidū (tīkla svārstības, klienta taimauts), jūs saglabāsiet līdz šim uzkrāto tekstu, bet atbilde būs nepilnīga. Produkcijas kvalitātes straumēšanas klientam tam jābūt gatavam: tam nevajadzētu uzskatīt daļēju tekstu kā "pabeigtu atbildi", kā arī nevajadzētu uzskatīt, ka atbilde ir pabeigta, līdz tiek parādīts notikums message_stop.
Otrs smalkums ir tāds, ka plūsma nemaina izmaksas. Tas, vai saņemat atbildi ar straumēšanu vai bez tās, neietekmē marķiera cenu; plūsma tikai uzlabo pieredzi un izturību. Tātad, "ja mēs sāksim straumēt, vai tie būs lētāki?" Atbilde uz jautājumu ir nē — par izmaksām skatiet 5. un 6. vienību (modeļa izvēle, kešatmiņa).
Trešais punkts ir panākt praktisku līdzsvaru: ar dzīvajiem asistentiem ļoti tiek novērtēta pirmā vārda ātra atnākšana (novērtētā kavēšanās); Tāpēc, aicinot modeli tieši ievadīt atbildi un vispirms sniegt īsu rezultātu (izmantojot sistēmas uzvedni 4. vienībā), plūsmas ieguvums tiek palielināts. Ja lietotājs pirmajā sekundē redz kaut ko jēgpilnu, viņš pacietīgi gaida turpmāko detaļu. No otras puses, plūsmai nav nekādas ietekmes uz darbiem, kas darbojas fonā un kuru izvade tiek novirzīta uz nākamo automatizācijas soli; Vienīgais kritērijs ir tas, ka darbs ir pabeigts pareizi un pilnībā.
Rezumējot
Straumējot atbilde tiek izgūta pa daļām, samazinot uztverto latentumu un novēršot taimautus lielai caurlaidspējai. Gandrīz obligāta dzīvā asistenta un garo dokumentu izgatavošanai; Tas nav nepieciešams īsiem/fona darbiem. Garajos iestudējumos struktūras un garuma uzspiešana no priekšpuses ar uzvedni palielina gan kvalitāti, gan izsekojamību; Kad plūsma ir pabeigta, noteikti tiek pārbaudīts stop_reason un lietojums.
Lietojumprogrammas uzdevums
Izvēlieties divus scenārijus: vienu tiešraidi/ilgu (piemēram, ziņot klientam), vienu īsu/fona (piemēram, marķēšanu). (1) Izlemiet un pamatojiet, vai izmantosit plūsmu katram. (2) Uzrakstiet uzvedni, kas nosaka garā skripta struktūru (virsraksti + mērķa garums). (3) Nosakiet max_tokens vērtības. (4) Uzskaitiet, kādas pārbaudes veiksiet ar stop_reason un izmantošanu plūsmas beigās.
kontrolsaraksts
- [ ] Es varu izskaidrot, kas ir straumēšana un kā tā samazina uztverto latentumu.
- [ ] Es sapratu straumes un delta pievienošanās galveno notikumu veidus.
- [ ] Es zinu par nepieciešamību straumēt ar lieliem max_tokens un taimauta attiecību.
- [ ] Varu izlemt, kurā slodzē izmantošu straumēšanu un kurā nē.
- [ ] Straumes beigās varu pārbaudīt stop_reason un lietojumu.