Fitimet:
- Mund të shpjegojë se çfarë është transmetimi, llojet e ngjarjeve dhe pse nevojitet.
- max_tokens kap afatin kohor dhe lidhjen e prodhimit të gjatë 128K
- Mund të bëjë zgjedhjen e duhur midis kërkesave për transmetim dhe jo-transmetim sipas ngarkesës së punës
Ju mund të keni vënë re se në një ndërfaqe chat, përgjigja "shtypet" fjalë për fjalë. Ky nuk është një lulëzim vizual; Është rezultat i një teknike të quajtur transmetim dhe shpesh është i detyrueshëm për integrimin e LLM me cilësi të prodhimit. Në këtë njësi, do të mësoni se çfarë është fluksi, nga cilat ngjarje përbëhet, marrëdhëniet e tij me daljen e gjatë dhe kohën e ndërprerjes, dhe kur të përdorni rrjedhën dhe kur jo. Ne do ta mbulojmë temën përmes detyrave reale të një profesionisti - asistenti i drejtpërdrejtë, gjenerimi i raporteve të gjata, përpunimi i grupeve.
Çfarë është Flow?
Me një kërkesë jo-transmetuese (sinkrone), ju prisni derisa modeli të prodhojë të gjithë përgjigjen; Kur përgjigja është gati, ajo arrin në një pjesë. Në një kërkesë transmetimi, serveri dërgon përgjigjen pjesë-pjesë ndërsa modeli gjeneron. Teknikisht, kjo bëhet me ngjarje të dërguara nga serveri (SSE — Ngjarje të dërguara nga serveri, një metodë në të cilën serveri dërgon ngjarje të vogla me radhë mbi një lidhje të hapur).
Dallimi bëhet i dukshëm në përvojën e përdoruesit: në një përgjigje që zgjat 8 sekonda, përdoruesi që nuk është në transmetim shikon një ekran bosh për 8 sekonda; Përdoruesi i transmetimit shikon fjalët e para në ~0,5 sekonda dhe teksti fillon të rrjedhë. Vonesa e perceptuar - pritja që ndjen përdoruesi - zvogëlohet shumë, ndërsa koha totale mbetet e pandryshuar.
Llojet e rrjedhës së ngjarjeve
Rrjedha është një sekuencë ngjarjesh. Konceptualisht, një rrjedhë tipike shkon kështu:
incidenti
Kuptimi
mesazh_fillimi
Filloi përgjigja; Informacioni i kokës si modeli dhe ID-ja ka mbërritur.
përmbajtje_blloku_fillimi
Filloi një bllok përmbajtjeje (p.sh. teksti).
delta_blloku i përmbajtjes
Një pjesë e vogël e tekstit (delta) mbërriti; ti mbledh keto
përmbajtje_blloku_stop
blloku i përfunduar
mesazh_delta
Informacionet e përditësuara të përfundimit të tilla si stop_arsyeja dhe përdorimi
mesazh_ndal
Përgjigjuni
Kodi juaj kombinon në mënyrë sekuenciale pjesë të tekstit në ngjarjet content_block_delta; përfundoni me të njëjtin tekst të saktë si përgjigja e patransmetuar. përdorimi (numrat e shenjave) zakonisht janë të qarta në fund të rrjedhës - ju mbani gjurmët e kostove pasi të përfundojë rrjedha.
Këshillë: Shumica e SDK-ve zyrtare (Paketa e Zhvillimit të Softuerit - biblioteka e gatshme e ofruesit) ofrojnë një ndihmës që mbledh transmetimin për ju (p.sh. stream.get_final_message()). Nuk është e nevojshme të menaxhoni manualisht të gjitha gjurmët; Përdoreni këtë ndihmës nëse dëshironi tekstin e plotë, përpunoni ngjarje individuale, por për printim të drejtpërdrejtë.
Përgjigje të gjata, max_tokens dhe Kohëzgjatje
Shkaku i dytë dhe më teknik i transmetimit është koha e kaluar. Nëse një kërkesë HTTP nuk plotësohet brenda një periudhe të caktuar kohore, klienti heq lidhjen. Kur kërkoni një dalje të madhe nga modeli (p.sh. një raport prej 40,000 tokenash), thirrja pa rrjedhë mund të kalojë këtë kufi dhe të përfundojë - kërkesa do të dështojë dhe ju do të duhet të paguani për argumentet e krijuara.
Modelet moderne mund të nxjerrin deri në 128,000 argumente në një kërkesë të vetme. Por rregulli i përgjithshëm është i qartë: përdorni transmetimet nëse vlera "max_tokens" është e lartë (afërsisht mbi 16,000). Transmetimi e mban lidhjen gjallë dhe parandalon ndërprerjet kohore; Ju gjithashtu do të shihni përparimin në çast.
- `max_tokens`: Shenjat maksimale të daljes që modeli mund të prodhojë; një tavan i fortë. Nëse ndodh një ndërprerje, stop_reason max_tokens kthehet.
- Dritarja e kontekstit: Dritarja në të cilën duhet të përshtatet shuma e hyrjes + daljes. max_tokens është tavani i prodhimit; Mos i ngatërroni të dyja.
Kujdes: Hedhja e kërkesave që nuk rrjedhin me max_tokens të mëdhenj është një gabim klasik në prodhim. Pa një përgjigje, lidhja bie, përdoruesi sheh një gabim dhe kostoja e shenjës harxhohet. Prodhim i gjatë = rrymë.
Kur të rrjedhë dhe kur jo?
Statusi
preferencë
Pse
Bisedë / asistent i drejtpërdrejtë
rrjedhin
Vonesa e perceptuar bie, përdoruesi sheh përparim
Prodhimi i raportit/dokumentit të gjatë
rrjedhin
Parandalon kohëzgjatjen, kryen rezultate të mëdha në mënyrë të sigurt
Klasifikimi i shkurtër (p.sh. etiketa me një fjalë)
nuk ka rrjedhje
Prodhimi është tashmë i vogël; kompleksiteti shtesë i panevojshëm
Përpunimi në grup
pa rrjedhje/batch
Rezultatet nuk shfaqen menjëherë; Shih njësinë 7
Hapi i automatizimit (në sfond)
Zakonisht nuk ka rrjedhje
Ju e kaloni rezultatin në hapin tjetër, pa shfaqje të drejtpërdrejtë
Prompt/shabllone të kopjueshme
Vetë transmetimi nuk është një kërkesë, por kërkesat janë kritike për menaxhimin e prodhimit të prodhuar nga transmetimi. Në prodhimet e gjata dhe të rrjedhshme, imponimi i strukturës nga përpara rrit cilësinë dhe gjurmueshmërinë.
# Ndani raportin e gjatë në seksione (në mënyrë që përparimi të jetë i dukshëm në rrjedhë) Shkruani raportin me titujt e mëposhtëm, në këtë rend të saktë. Filloni çdo titull me '## ':## Përmbledhje## Gjetje## Rekomandime## Hapat e mëtejshëm
# Jepni gjatësinë e synuar për të shmangur shkurtimin në prodhim të gjatë. Teksti i përgjithshëm do të jetë afërsisht 800 fjalë. Mbani të balancuara porcionet; Mos lini gjysmë fjali në fund.
# Jepni fjalinë e parë menjëherë për asistentin e transmetimit. Jepni fillimisht një përgjigje të drejtpërdrejtë me një fjali, pastaj shkoni në detaje. Kështu që përdoruesi sheh një rezultat të menjëhershëm gjatë pritjes.
# Mbajeni të strukturuar daljen e gjatë (që të mund të analizohet më vonë) Nxjerni daljen në këto seksione dhe shënoni secilin seksion me një titull të veçantë '###' në mënyrë që të mund ta analizoj atë në mënyrë programore: ### HYRJE ### TRUPI ### BURIMET
Prompt i dobët / Prompt i fortë (prodhim i gjatë)
# I DOBËT Shkruani një raport të gjatë dhe të detajuar për këtë temë.
# STRONG Shkruani një raport me rreth 900 fjalë për këtë temë. Titujt: ## Përmbledhje, ## Analiza, ## Rreziqet, ## Rekomandime. Çdo titull duhet të jetë maksimumi 3 paragrafë. Mos lini gjysmë fjali në fund.
Version i fuqishëm; Ai përcakton gjatësinë, strukturën dhe cilësinë e përfundimit paraprakisht. Ndërsa seksionet vijnë në rrjedhë, përdoruesi e sheh qartë progresin dhe e menaxhon vetë gjatësinë kundrejt rrezikut të ndërprerjes së modelit.
Tre Mini Rastet
Rasti 1 - Ankesa në ekran bosh. Asistenti i klientit të një ekipi konsulent po përgjigjej pa rrjedhë; Përgjigja mesatare zgjat 7 sekonda, përdoruesit pyesin "a ngrin?" u ankua ai. Sapo hyra në rrjedhë, fjala e parë erdhi në ~0,6 sekonda; Koha totale mbeti e njëjtë, por ankesat "të ngadalta" pothuajse u zhdukën.
Rasti 2 - Raport i vjetëruar. Një ekip financash po prodhonte një raport tremujor prej 30 faqesh; Me max_tokens: 30000, kërkesa pa rrjedhë do të ngecë në një afat kohor prej 60 sekondash të klientit, kërkesa do të dështonte - dhe argumentet e krijuara do të shkruheshin në faturë. Ata shkuan me rrjedhën; lidhja mbeti e drejtpërdrejtë, raporti u dorëzua i plotë dhe kostot e shpenzuara u eliminuan.
Rasti 3 — Rrjedha e panevojshme. Një ekip operativ po etiketonte emailet hyrëse si “urgjente/të rregullta”; Prodhimi ishte një fjalë, por ata zakonisht përdornin rrjedhën. Rrjedha nuk dha asnjë përfitim në përgjigjen me një fjalë, duke e bërë kodin të panevojshëm kompleks. Kur kalova në flowless, kodi u thjeshtua dhe sjellja mbeti e njëjtë. Mësimi: transmetimi është i vlefshëm në prodhimin e gjatë/të drejtpërdrejtë, jo kudo.
Gabimet e zakonshme
- Mospërdorimi i transmetimeve në prodhim të gjatë: Koha e skaduar dhe kostoja e harxhuar e tokenit.
- Përdorimi i transmetimit në prodhim të shkurtër: Kompleksitet i panevojshëm, përfitim zero.
- Mos kontrollimi i 'stop_reason' në fund të transmetimit: përgjigja e cunguar me max_tokens konsiderohet e plotë.
- Shkrirja e gabuar e deltave: Përmbledhja manuale me ndihmësin e SDK prodhon gabim në sekuencë/pjesë që mungojnë.
- Përpjekja për të lexuar 'përdorimin' në mes të transmetimit: Numrat e shenjave zakonisht bëhen të qarta në fund; Mbani gjurmët e kostove në fund.
- Gabimi i transmetimit për uljen e kostos: Transmetimi përmirëson përvojën dhe qëndrueshmërinë; Nuk e ndryshon çmimin simbol.
Më të thella: Ndërprerjet e rrjedhës dhe elasticiteti
Transmetimi është një lidhje e drejtpërdrejtë; Kjo është edhe forca dhe dobësia e saj. Nëse lidhja bie në mes (luhatja e rrjetit, afati i klientit), do të ruani tekstin që keni grumbulluar deri më tani, por përgjigja do të jetë e paplotë. Një klient transmetimi me cilësi prodhimi duhet të përgatitet për këtë: ai nuk duhet ta trajtojë tekstin e pjesshëm si një "përgjigje të përfunduar", as nuk duhet ta konsiderojë përgjigjen të përfunduar derisa të shohë ngjarjen message_stop.
Hollësia e dytë është se rrjedha nuk e ndryshon koston. Nëse merrni një përgjigje me ose pa transmetim, nuk ndikon në çmimin e tokenit; rrjedha vetëm përmirëson përvojën dhe qëndrueshmërinë. Pra, "nëse shkojmë në transmetim, a do të jenë më të lirë?" Përgjigja e pyetjes është jo - për koston, shikoni njësinë e 5-të dhe të 6-të (zgjedhja e modelit, cache).
Pika e tretë është të arrihet një ekuilibër praktik: me asistentët e drejtpërdrejtë, mbërritja e shpejtë e fjalës së parë (vonesa e perceptuar) vlerësohet shumë; Prandaj, kërkimi i modelit që të fusë drejtpërdrejt përgjigjen dhe të japë fillimisht një rezultat të shkurtër (nëpërmjet promptit të sistemit në njësinë e 4-të) shumëfishon përfitimin e rrjedhës. Nëse përdoruesi sheh diçka kuptimplote në sekondën e parë, ai pret me durim për detajet që vijojnë. Nga ana tjetër, fluksi nuk ka asnjë kontribut për punët që funksionojnë në sfond, prodhimi i të cilave shkon në hapin tjetër të automatizimit; I vetmi kriter atje është që puna të kryhet në mënyrë korrekte dhe të plotë.
Në përmbledhje
Transmetimi rikthen përgjigjen pjesë-pjesë, duke reduktuar vonesën e perceptuar dhe duke parandaluar afatet kohore në xhiro të mëdha. Pothuajse e detyrueshme për asistentin e drejtpërdrejtë dhe prodhimin e dokumenteve të gjata; Është e panevojshme për punë të shkurtra/në sfond. Në prodhimet e gjata, imponimi i strukturës dhe gjatësisë nga përpara me një prompt rrit cilësinë dhe gjurmueshmërinë; Kur rrjedha të përfundojë, stop_arsyeja dhe përdorimi kontrollohen patjetër.
Detyra e aplikimit
Zgjidhni dy skenarë: një të drejtpërdrejtë/gjatë (p.sh. raportimi te klienti), një të shkurtër/në sfond (p.sh. etiketimi). (1) Vendosni dhe arsyetoni nëse do të përdorni rrjedhën për secilën. (2) Shkruani një kërkesë që imponon strukturën për shkrimin e gjatë (titujt + gjatësia e objektivit). (3) Përcaktoni vlerat max_tokens. (4) Rendisni se çfarë kontrollesh do të kryeni me stop_reason dhe përdorim në fund të rrjedhës.
listë kontrolli
- [ ] Unë mund të shpjegoj se çfarë është transmetimi dhe si redukton vonesën e perceptuar.
- [ ] Kuptova llojet bazë të ngjarjeve të bashkimit të rrjedhës dhe deltës.
- [ ] Unë e di për nevojën për të transmetuar me max_tokens të mëdhenj dhe marrëdhënien e afatit.
- [ ] Unë mund të vendos se në cilën ngarkesë pune do të përdor transmetimin dhe në cilën jo.
- [ ] Mund të kontrolloj stop_arsye dhe përdorim në fund të transmetimit.