Mga nadagdag:
- Maaaring ipaliwanag kung ano ang streaming, mga uri ng kaganapan at kung bakit ito kinakailangan.
- Ang max_tokens ay nakakakuha ng timeout at 128K na mahabang relasyon sa output
- Makakagawa ng tamang pagpili sa pagitan ng streaming at non-streaming na mga kahilingan ayon sa workload
Maaaring napansin mo na sa isang chat interface, ang tugon ay "na-type" na salita sa bawat salita. Ito ay hindi isang visual na pag-unlad; Ito ay resulta ng isang pamamaraan na tinatawag na streaming at kadalasang ipinag-uutos para sa kalidad ng produksyon na pagsasama ng LLM. Sa unit na ito, malalaman mo kung ano ang daloy, kung anong mga kaganapan ang binubuo nito, ang kaugnayan nito sa mahabang output at timeout, at kung kailan gagamitin ang daloy at kung kailan hindi. Tatalakayin namin ang paksa sa pamamagitan ng mga tunay na gawain ng isang propesyonal — live na katulong, pagbuo ng mahabang ulat, pagproseso ng batch.
Ano ang Flow?
Sa isang kahilingang hindi nag-stream (kasabay), maghihintay ka hanggang sa magawa ng modelo ang buong tugon; Kapag handa na ang sagot, darating ito sa isang piraso. Sa isang kahilingan sa streaming, ipinapadala ng server ang bawat piraso ng tugon habang bumubuo ang modelo. Sa teknikal, ginagawa ito sa mga kaganapang ipinadala ng server (SSE — Mga Kaganapang Ipinadala ng Server, isang paraan kung saan nagpapadala ang server ng mga maliliit na kaganapan nang magkakasunod sa isang bukas na koneksyon).
Ang pagkakaiba ay nagiging maliwanag sa karanasan ng user: sa isang tugon na tumatagal ng 8 segundo, ang non-stream na user ay tumitig sa isang blangkong screen sa loob ng 8 segundo; Nakikita ng streaming user ang mga unang salita sa loob ng ~0.5 segundo at nagsimulang dumaloy ang text. Ang pinaghihinalaang latency—ang paghihintay na nararamdaman ng user—ay lubos na nababawasan, habang ang kabuuang oras ay nananatiling hindi nagbabago.
Mga Uri ng Daloy ng Kaganapan
Ang daloy ay isang pagkakasunod-sunod ng mga pangyayari. Sa konsepto, ang isang karaniwang daloy ay ganito:
pangyayari
Ibig sabihin
message_start
Nagsimula ang tugon; Dumating na ang impormasyon ng header gaya ng modelo at ID.
content_block_start
Nagsimula ang isang bloke ng nilalaman (hal. text).
content_block_delta
Isang maliit na piraso ng teksto (delta) ang dumating; kolektahin mo ang mga ito
content_block_stop
natapos ang block
message_delta
Na-update na pangwakas na impormasyon tulad ng stop_reason at paggamit
message_stop
Reply over
Ang iyong code ay sunud-sunod na pinagsasama ang mga piraso ng teksto sa content_block_delta na mga kaganapan; napupunta ka sa parehong eksaktong teksto tulad ng hindi naka-stream na tugon. ang paggamit (mga numero ng token) ay karaniwang malinaw sa dulo ng daloy — sinusubaybayan mo ang mga gastos kapag natapos na ang daloy.
Tip: Karamihan sa mga opisyal na SDK (Software Development Kit — ang handa na library ng provider) ay nagbibigay ng isang katulong na kumukuha ng stream para sa iyo (hal. stream.get_final_message()). Hindi mo kailangang manu-manong pamahalaan ang lahat ng mga track; Gamitin ang helper na ito kung gusto mo ang buong text, iproseso ang mga indibidwal na kaganapan ngunit para sa live na pag-print.
Mahabang Tugon, max_tokens at Timeout
Ang pangalawa at mas teknikal na dahilan ng streaming ay timeout. Kung ang isang kahilingan sa HTTP ay hindi nakumpleto sa loob ng isang tiyak na tagal ng panahon, ibinabagsak ng kliyente ang koneksyon. Kapag humiling ka ng malaking output mula sa modelo (hal. ulat ng 40,000 token), maaaring lumampas sa limitasyong ito at time out ang hindi dumaloy na tawag — mabibigo ang kahilingan, at kailangan mong bayaran ang mga token na nabuo.
Makakapaglabas ang mga modernong modelo ng hanggang 128,000 token sa isang kahilingan. Ngunit malinaw ang panuntunan ng thumb: gumamit ng mga stream kung mataas ang value ng `max_tokens` (halos lampas sa 16,000). Pinapanatili ng streaming na buhay ang koneksyon at pinipigilan ang mga timeout; Makikita mo rin agad ang pag-unlad.
- `max_tokens`: Pinakamataas na output token na maaaring gawin ng modelo; isang matigas na kisame. Kung magkaroon ng interrupt, ibabalik ang stop_reason max_tokens.
- Context window: Ang window kung saan dapat magkasya ang kabuuan ng input + output. ang max_tokens ay ang kisame ng output; Huwag ihalo ang dalawa.
Babala: Ang paghahagis ng mga hindi dumadaloy na kahilingan na may malalaking max_tokens ay isang klasikong pagkakamali sa produksyon. Kung walang tugon, bumababa ang koneksyon, nakakakita ng error ang user, at nasasayang ang halaga ng token. Mahabang output = stream.
Kailan Daloy at Kailan Hindi?
Katayuan
kagustuhan
Bakit
Live chat / katulong
daloy
Naramdamang bumababa ang latency, nakikita ng user ang pag-unlad
Mahabang ulat / paggawa ng dokumento
daloy
Pinipigilan ang timeout, nagdadala ng malaking output nang ligtas
Maikling pag-uuri (hal. iisang salita na tag)
walang daloy
Maliit na ang output; karagdagang kumplikado na hindi kailangan
Batch processing
walang daloy/batch
Ang mga resulta ay hindi ipinapakita kaagad; Tingnan ang unit 7
Hakbang sa automation (sa background)
Kadalasan walang daloy
Ipapasa mo ang resulta sa susunod na hakbang, walang live na display
Nakokopyang Prompt/Template
Ang stream mismo ay hindi isang prompt, ngunit ang mga prompt ay kritikal para sa pamamahala ng output na ginawa ng stream. Sa mahaba at tuluy-tuloy na mga produksyon, ang pagpapataw ng istraktura mula sa harap ay nagpapataas ng parehong kalidad at traceability.
# Hatiin ang mahabang ulat sa mga seksyon (upang ang pag-usad ay nakikita sa daloy) Isulat ang ulat na may mga sumusunod na heading, sa eksaktong pagkakasunud-sunod na ito. Simulan ang bawat heading gamit ang '## ':## Summary## Findings## Recommendations## Susunod na hakbang
# Bigyan ang target na haba upang maiwasan ang pagputol sa mahabang produksyon. Ang kabuuang teksto ay magiging humigit-kumulang 800 salita. Panatilihing balanse ang mga bahagi; Huwag mag-iwan ng kalahating pangungusap sa dulo.
# Ibigay kaagad ang unang pangungusap para sa streaming assistant. Magbigay muna ng direktang isang pangungusap na sagot, pagkatapos ay isa-isahin. Kaya nakikita ng user ang isang agarang resulta habang naghihintay.
# Panatilihing nakabalangkas ang mahabang output (para ma-parse ito sa ibang pagkakataon) I-output ang output sa mga seksyong ito at markahan ang bawat seksyon ng hiwalay na '#### ' header para ma-parse ko ito sa programmatically: ### INTRODUCTION ### BODY ### SOURCES
Mahinang prompt / Malakas na prompt (mahabang produksyon)
# WEAKWsumulat ng mahaba at detalyadong ulat sa paksang ito.
# STRONGSumulat ng ulat ng humigit-kumulang 900 salita sa paksang ito. Mga Heading: ## Buod, ## Pagsusuri, ## Mga Panganib, ## Mga Rekomendasyon. Ang bawat heading ay dapat na hindi hihigit sa 3 talata. Huwag mag-iwan ng kalahating pangungusap sa dulo.
Napakahusay na bersyon; Tinutukoy nito ang haba, istraktura at kalidad ng pagtatapos nang maaga. Habang dumarating ang mga seksyon, malinaw na nakikita ng user ang pag-usad at pinamamahalaan niya ang haba ng kanyang sarili laban sa panganib ng pagkaantala ng modelo.
Tatlong Mini Case
Kaso 1 — Blangkong screen na reklamo. Ang client assistant ng isang consulting team ay tumutugon nang walang daloy; ang average na tugon ay tumatagal ng 7 segundo, ang mga user ay nagtatanong ng "nagpe-freeze ba ito?" reklamo niya. Sa sandaling pumasok ako sa daloy, ang unang salita ay dumating sa ~0.6 segundo; Ang kabuuang oras ay nanatiling pareho, ngunit ang mga "mabagal" na reklamo ay halos nawala.
Kaso 2 — Hindi napapanahong ulat. Nagkakaroon ng 30-pahinang quarter report ang isang finance team; Sa max_tokens: 30000, ang kahilingan na walang daloy ay maalis sa isang 60 segundong pag-timeout ng kliyente, mabibigo ang kahilingan — at ang mga nabuong token ay isusulat sa invoice. Sumabay sila sa agos; nanatiling live ang koneksyon, naihatid nang buo ang ulat, at inalis ang mga nasayang na gastos.
Kaso 3 — Hindi kinakailangang daloy. Nilagyan ng label ng operations team ang mga papasok na email bilang "urgent/regular"; Ang output ay isang salita, ngunit karaniwan nilang ginagamit ang daloy. Ang daloy ay hindi nagbigay ng pakinabang sa isang salita na tugon, na ginagawang hindi kinakailangang kumplikado ang code. Nang lumipat ako sa flowless, pinasimple ang code at nanatiling pareho ang pag-uugali. Aralin: mahalaga ang streaming sa mahaba/live na output, hindi sa lahat ng dako.
Mga karaniwang pagkakamali
- Hindi gumagamit ng mga stream sa mahabang output: Timeout at nasayang na halaga ng token.
- Paggamit ng streaming sa maikling output: Hindi kinakailangang kumplikado, walang benepisyo.
- Hindi nilagyan ng check ang `stop_reason` sa dulo ng stream: ang pinutol na tugon na may max_tokens ay itinuturing na kumpleto.
- Maling pagsasama ng mga delta: Ang manu-manong pagsusuma sa SDK helper ay gumagawa ng sequence/missing parts error.
- Sinusubukang basahin ang `paggamit` sa kalagitnaan ng stream: Karaniwang nagiging malinaw ang mga numero ng token sa dulo; Subaybayan ang mga gastos sa dulo.
- Napagkamalan ang streaming para sa cost-cutting: Ang streaming ay nagpapabuti sa karanasan at tibay; Hindi nito binabago ang presyo ng token.
Mas malalim: Flow Break at Resilience
Ang streaming ay isang live na koneksyon; Ito ang parehong lakas at kahinaan nito. Kung bumaba ang koneksyon sa gitna (pagbabago-bago ng network, timeout ng kliyente), pananatilihin mo ang text na naipon mo sa ngayon, ngunit hindi kumpleto ang tugon. Ang isang streaming client na may kalidad ng produksyon ay dapat maging handa para dito: hindi nito dapat ituring ang bahagyang text bilang isang "nakumpletong tugon", at hindi rin nito dapat isaalang-alang na tapos na ang tugon hanggang sa makita nito ang kaganapang message_stop.
Ang pangalawang subtlety ay ang daloy ay hindi nagbabago sa gastos. Kung nakatanggap ka ng tugon na mayroon o walang streaming ay hindi makakaapekto sa presyo ng token; ang daloy ay nagpapabuti lamang sa karanasan at pagtitiis. Kaya "kung mag-stream kami, mas mura ba sila?" Ang sagot sa tanong ay hindi — para sa gastos, tingnan ang ika-5 at ika-6 na yunit (pagpili ng modelo, cache).
Ang pangatlong punto ay ang magkaroon ng praktikal na balanse: sa mga live na katulong, ang mabilis na pagdating ng unang salita (pinaniniwalaang pagkaantala) ay lubos na pinahahalagahan; Samakatuwid, ang pagtatanong sa modelo na direktang ilagay ang sagot at magbigay muna ng maikling resulta (sa pamamagitan ng system prompt sa ika-4 na yunit) ay nagpaparami ng benepisyo ng daloy. Kung may nakikitang makabuluhan ang user sa unang segundo, matiyagang naghihintay sila sa susunod na detalye. Sa kabilang banda, ang daloy ay walang kontribusyon sa mga trabahong tumatakbo sa background, ang output nito ay napupunta sa susunod na hakbang sa automation; Ang tanging criterion doon ay ang trabaho ay nakumpleto nang tama at ganap.
Sa buod
Kinukuha ng streaming ang bawat piraso ng tugon, binabawasan ang nakikitang latency at pinipigilan ang mga timeout sa malalaking throughput. Halos sapilitan para sa live na katulong at mahabang paggawa ng dokumento; Ito ay hindi kailangan para sa maikli/background na gawain. Sa mahabang produksyon, ang pagpapataw ng istraktura at haba mula sa harap na may isang prompt ay nagdaragdag ng parehong kalidad at traceability; Kapag natapos na ang daloy, tiyak na susuriin ang stop_reason at paggamit.
Gawain ng aplikasyon
Pumili ng dalawang senaryo: isang live/long (hal. ulat sa customer), isang maikli/background (hal. pag-tag). (1) Magpasya at bigyang-katwiran kung gagamit ka ng daloy para sa bawat isa. (2) Sumulat ng prompt na nagpapataw ng istraktura para sa mahabang script (heading + target na haba). (3) Tukuyin ang mga halaga ng max_tokens. (4) Ilista kung anong mga pagsusuri ang gagawin mo nang may stop_reason at paggamit sa dulo ng daloy.
checklist
- [ ] Maaari kong ipaliwanag kung ano ang streaming at kung paano nito binabawasan ang pinaghihinalaang latency.
- [ ] Naunawaan ko ang mga pangunahing uri ng kaganapan ng pagsali sa stream at delta.
- [ ] Alam ko ang tungkol sa pangangailangang mag-stream gamit ang malalaking max_tokens at ang timeout na relasyon.
- [ ] Maaari akong magpasya kung aling workload ang gagamitin ko sa streaming at kung saan ako ay hindi.
- [ ] Maaari kong suriin ang stop_reason at paggamit sa dulo ng stream.