नफा:
- स्ट्रीमिंग म्हणजे काय, इव्हेंटचे प्रकार आणि ते का आवश्यक आहे हे स्पष्ट करू शकते.
- max_tokens ग्रास्प्स टाइमआउट आणि 128K लांब आउटपुट संबंध
- वर्कलोडनुसार स्ट्रीमिंग आणि नॉन-स्ट्रीमिंग विनंत्या दरम्यान योग्य निवड करू शकते
तुमच्या लक्षात आले असेल की चॅट इंटरफेसमध्ये प्रतिसाद हा शब्दानुसार "टाइप" केला जातो. हे दृश्य उत्कर्ष नाही; हे स्ट्रीमिंग नावाच्या तंत्राचा परिणाम आहे आणि उत्पादन-गुणवत्तेच्या LLM एकत्रीकरणासाठी अनेकदा अनिवार्य आहे. या युनिटमध्ये, तुम्ही फ्लो म्हणजे काय, त्यात कोणत्या घटनांचा समावेश आहे, त्याचा दीर्घ आउटपुट आणि कालबाह्यता यांच्याशी संबंध, आणि प्रवाह कधी वापरायचा आणि कधी नाही हे शिकाल. आम्ही एका व्यावसायिकाच्या वास्तविक कार्यांद्वारे विषय कव्हर करू - थेट सहाय्यक, दीर्घ अहवाल निर्मिती, बॅच प्रक्रिया.
प्रवाह म्हणजे काय?
नॉन-स्ट्रीमिंग (सिंक्रोनस) विनंतीसह, मॉडेल संपूर्ण प्रतिसाद तयार करेपर्यंत तुम्ही प्रतीक्षा करता; उत्तर तयार झाल्यावर ते एका तुकड्यात येते. स्ट्रीमिंग विनंतीमध्ये, मॉडेल व्युत्पन्न केल्याप्रमाणे सर्व्हर तुकड्या-तुकड्याने प्रतिसाद पाठवतो. तांत्रिकदृष्ट्या, हे सर्व्हर-पाठवलेल्या इव्हेंटसह केले जाते (SSE — सर्व्हर-पाठवलेले इव्हेंट, एक पद्धत ज्यामध्ये सर्व्हर एका ओपन कनेक्शनवर लहान इव्हेंट पाठवतो).
वापरकर्त्याच्या अनुभवामध्ये फरक स्पष्ट होतो: 8 सेकंद लागणाऱ्या प्रतिसादावर, प्रवाह नसलेला वापरकर्ता 8 सेकंदांसाठी रिकाम्या स्क्रीनकडे पाहतो; स्ट्रीमिंग वापरकर्त्याला पहिले शब्द ~0.5 सेकंदात दिसतात आणि मजकूर वाहू लागतो. समजलेली विलंबता—वापरकर्त्याला वाटणारी प्रतीक्षा—मोठ्या प्रमाणात कमी झाली आहे, तर एकूण वेळ अपरिवर्तित आहे.
प्रवाहाचे इव्हेंट प्रकार
प्रवाह हा घटनांचा क्रम आहे. वैचारिकदृष्ट्या, एक सामान्य प्रवाह याप्रमाणे जातो:
घटना
अर्थ
संदेश_प्रारंभ
प्रतिसाद सुरू झाला; मॉडेल आणि आयडी सारखी शीर्षलेख माहिती आली आहे.
content_block_start
सामग्रीचा ब्लॉक (उदा. मजकूर) सुरू झाला
सामग्री_ब्लॉक_डेल्टा
मजकूराचा एक छोटा तुकडा (डेल्टा) आला; तुम्ही हे गोळा करा
content_block_stop
ब्लॉक पूर्ण
संदेश_डेल्टा
अद्ययावत समाप्ती माहिती जसे की stop_reason आणि वापर
संदेश_थांबवा
उत्तर द्या
तुमचा कोड अनुक्रमे सामग्री_ब्लॉक_डेल्टा इव्हेंटमधील मजकूराचे तुकडे एकत्र करतो; तुमचा शेवट नॉन-स्ट्रीम केलेल्या प्रतिसादासारखाच अचूक मजकूर आहे. वापर (टोकन क्रमांक) सामान्यतः प्रवाहाच्या शेवटी स्पष्ट असतात — प्रवाह संपल्यानंतर तुम्ही खर्चाचा मागोवा ठेवता.
टीप: बहुतेक अधिकृत SDKs (सॉफ्टवेअर डेव्हलपमेंट किट — प्रदात्याची तयार लायब्ररी) एक मदतनीस प्रदान करतात जो तुमच्यासाठी प्रवाह गोळा करतो (उदा. stream.get_final_message()). तुम्हाला सर्व ट्रॅक मॅन्युअली व्यवस्थापित करण्याची गरज नाही; तुम्हाला संपूर्ण मजकूर हवा असल्यास हा मदतनीस वापरा, वैयक्तिक कार्यक्रमांवर प्रक्रिया करा परंतु थेट मुद्रणासाठी.
दीर्घ प्रतिसाद, कमाल_टोकन्स आणि कालबाह्य
प्रवाहाचे दुसरे आणि अधिक तांत्रिक कारण म्हणजे कालबाह्य. HTTP विनंती ठराविक कालावधीत पूर्ण न झाल्यास, क्लायंट कनेक्शन सोडतो. जेव्हा तुम्ही मॉडेलमधून मोठ्या आउटपुटची विनंती करता (उदा. 40,000 टोकनचा अहवाल), तेव्हा नॉन-फ्लो कॉल ही मर्यादा ओलांडू शकतो आणि वेळ संपू शकतो — विनंती अयशस्वी होईल आणि तुम्हाला व्युत्पन्न केलेल्या टोकनसाठी पैसे द्यावे लागतील.
आधुनिक मॉडेल्स एका विनंतीमध्ये 128,000 टोकन आउटपुट करू शकतात. परंतु अंगठ्याचा नियम स्पष्ट आहे: जर `max_tokens` मूल्य जास्त असेल (अंदाजे १६,००० पेक्षा जास्त) तर प्रवाह वापरा. प्रवाह कनेक्शन जिवंत ठेवते आणि कालबाह्य होण्यास प्रतिबंध करते; तुम्हाला प्रगती देखील झटपट दिसेल.
- `max_tokens`: मॉडेल तयार करू शकणारे कमाल आउटपुट टोकन; एक कठोर कमाल मर्यादा. व्यत्यय आल्यास, stop_reason max_tokens परत केले जातात.
- संदर्भ विंडो: ज्या विंडोमध्ये इनपुट + आउटपुटची बेरीज फिट असणे आवश्यक आहे. max_tokens ही आउटपुटची कमाल मर्यादा आहे; दोन्ही मिसळू नका.
खबरदारी: मोठ्या max_tokens सह नॉन-फ्लो विनंत्या फेकणे ही उत्पादनातील एक उत्कृष्ट चूक आहे. प्रतिसादाशिवाय, कनेक्शन कमी होते, वापरकर्त्याला त्रुटी दिसते आणि टोकनची किंमत वाया जाते. लांब आउटपुट = प्रवाह.
कधी वाहायचे आणि कधी नाही?
स्थिती
प्राधान्य
का
थेट गप्पा / सहाय्यक
प्रवाह
लेटन्सी कमी झाली, वापरकर्ता प्रगती पाहतो
लांब अहवाल / दस्तऐवज उत्पादन
प्रवाह
कालबाह्य होण्यास प्रतिबंध करते, सुरक्षितपणे मोठे आउटपुट घेऊन जाते
लहान वर्गीकरण (उदा. एकच शब्द टॅग)
प्रवाह नाही
आउटपुट आधीच लहान आहे; अतिरिक्त जटिलता अनावश्यक
बॅच प्रक्रिया
प्रवाहहीन/बॅच
परिणाम त्वरित दर्शविले जात नाहीत; युनिट 7 पहा
ऑटोमेशन पायरी (पार्श्वभूमीत)
सहसा प्रवाह नसतो
तुम्ही निकाल पुढील चरणात पास कराल, थेट प्रदर्शन नाही
कॉपी करण्यायोग्य प्रॉम्प्ट/टेम्प्लेट्स
प्रवाह स्वतः एक प्रॉम्प्ट नाही, परंतु प्रवाहाद्वारे उत्पादित आउटपुट व्यवस्थापित करण्यासाठी प्रॉम्प्ट महत्त्वपूर्ण आहेत. लांब आणि प्रवाही उत्पादनांमध्ये, समोरून रचना लादणे गुणवत्ता आणि शोधण्यायोग्यता दोन्ही वाढवते.
# दीर्घ अहवालाची विभागांमध्ये विभागणी करा (जेणेकरुन प्रगती प्रवाहात दिसून येईल) या अचूक क्रमाने अहवाल खालील शीर्षकांसह लिहा. प्रत्येक मथळा '##' सह सुरू करा:## सारांश## निष्कर्ष## शिफारसी## पुढील चरण
# लांब उत्पादनात ट्रंकेशन टाळण्यासाठी लक्ष्य लांबी द्या. एकूण मजकूर अंदाजे 800 शब्दांचा असेल. भाग संतुलित ठेवा; शेवटी अर्धे वाक्य सोडू नका.
# स्ट्रीमिंग सहाय्यकासाठी ताबडतोब पहिले वाक्य द्या. प्रथम थेट एका वाक्याचे उत्तर द्या, नंतर तपशीलात जा. त्यामुळे प्रतीक्षा करताना वापरकर्त्याला त्वरित परिणाम दिसतो.
# लांब आउटपुट संरचित ठेवा (जेणेकरुन ते नंतर विश्लेषित केले जाऊ शकते) या विभागांमधील आउटपुट आउटपुट करा आणि प्रत्येक विभागाला स्वतंत्र '###' शीर्षलेखाने चिन्हांकित करा जेणेकरून मी त्याचे प्रोग्रामॅटिक पद्धतीने विश्लेषण करू शकेन: ### परिचय ### मुख्य भाग ### स्रोत
कमकुवत प्रॉम्प्ट / मजबूत प्रॉम्प्ट (दीर्घ उत्पादन)
# WEAK या विषयावर एक लांब आणि तपशीलवार अहवाल लिहा.
# STRONGया विषयावर अंदाजे 900 शब्दांचा अहवाल लिहा. मथळे: ## सारांश, ## विश्लेषण, ## जोखीम, ## शिफारसी. प्रत्येक मथळा जास्तीत जास्त 3 परिच्छेदांचा असावा. शेवटी अर्धे वाक्य सोडू नका.
शक्तिशाली आवृत्ती; ते अगोदरच लांबी, रचना आणि फिनिश गुणवत्ता ठरवते. जसजसे विभाग प्रवाहात येतात, वापरकर्ता प्रगती स्पष्टपणे पाहतो आणि मॉडेल व्यत्यय येण्याच्या जोखमीपासून स्वतः लांबी व्यवस्थापित करतो.
तीन मिनी केसेस
केस 1 - रिक्त स्क्रीन तक्रार. सल्लागार संघाचा ग्राहक सहाय्यक प्रवाहाशिवाय प्रतिसाद देत होता; सरासरी प्रतिसादास 7 सेकंद लागतात, वापरकर्ते विचारतात "ते गोठते का?" त्याने तक्रार केली. एकदा मी प्रवाहात आलो की, पहिला शब्द ~0.6 सेकंदात आला; एकूण वेळ समान राहिला, परंतु "धीमे" तक्रारी जवळजवळ गायब झाल्या.
केस 2 - जुना अहवाल. वित्त संघाने 30 पृष्ठांचा तिमाही अहवाल तयार केला होता; max_tokens: 30000 सह, नो-फ्लो विनंती 60-सेकंद क्लायंट टाइमआउटमध्ये अडकेल, विनंती अयशस्वी होईल — आणि व्युत्पन्न टोकन इनव्हॉइसमध्ये लिहिले जातील. ते प्रवाहाबरोबर गेले; कनेक्शन थेट राहिले, अहवाल पूर्ण वितरित केला गेला आणि वाया गेलेले खर्च काढून टाकले गेले.
केस 3 - अनावश्यक प्रवाह. एक ऑपरेशन टीम इनकमिंग इमेल्सना “तातडीचे/नियमित” असे लेबल करत होती; आउटपुट हा एक शब्द होता, परंतु त्यांनी नेहमीच प्रवाह वापरला. प्रवाहाने एक-शब्द प्रतिसादात कोणताही फायदा दिला नाही, ज्यामुळे कोड अनावश्यकपणे जटिल झाला. जेव्हा मी फ्लोलेसवर स्विच केले तेव्हा कोड सरलीकृत झाला आणि वर्तन समान राहिले. धडा: स्ट्रीमिंग दीर्घ/लाइव्ह आउटपुटमध्ये मौल्यवान आहे, सर्वत्र नाही.
सामान्य चुका
- दीर्घ आउटपुटमध्ये प्रवाह वापरत नाही: कालबाह्य आणि वाया गेलेली टोकन किंमत.
- शॉर्ट आउटपुटमध्ये प्रवाह वापरणे: अनावश्यक जटिलता, शून्य फायदा.
- प्रवाहाच्या शेवटी `stop_reason` तपासत नाही: max_tokens सह कापलेला प्रतिसाद पूर्ण मानला जातो.
- डेल्टास चुकीच्या पद्धतीने विलीन करणे: SDK मदतनीससह मॅन्युअल समीकरण अनुक्रम/गहाळ भाग त्रुटी निर्माण करते.
- `वापर` मध्य-प्रवाह वाचण्याचा प्रयत्न करत आहे: टोकन क्रमांक सहसा शेवटी स्पष्ट होतात; शेवटी खर्चाचा मागोवा ठेवा.
- खर्चात कपात करण्यासाठी चुकीचे स्ट्रीमिंग: स्ट्रीमिंग अनुभव आणि सहनशक्ती सुधारते; हे टोकन किंमत बदलत नाही.
सखोल: प्रवाह खंडित आणि लवचिकता
प्रवाह एक थेट कनेक्शन आहे; हे तिची ताकद आणि असुरक्षा दोन्ही आहे. जर कनेक्शन मध्यभागी घसरले (नेटवर्क चढ-उतार, क्लायंट कालबाह्य), आपण आतापर्यंत जमा केलेला मजकूर राखून ठेवाल, परंतु प्रतिसाद अपूर्ण असेल. उत्पादन-गुणवत्तेचा प्रवाह क्लायंट यासाठी तयार असावा: तो आंशिक मजकूर "पूर्ण प्रतिसाद" म्हणून मानू नये, किंवा तो संदेश_स्टॉप इव्हेंट पाहत नाही तोपर्यंत प्रतिसाद संपेल असा विचार करू नये.
दुसरी सूक्ष्मता म्हणजे प्रवाह खर्च बदलत नाही. तुम्हाला स्ट्रीमिंगसह किंवा त्याशिवाय प्रतिसाद मिळाला तरी टोकन किंमतीवर परिणाम होत नाही; प्रवाह केवळ अनुभव आणि सहनशक्ती सुधारतो. तर "आम्ही प्रवाहात गेलो तर ते स्वस्त होतील का?" प्रश्नाचे उत्तर नाही आहे — खर्चासाठी, 5 व्या आणि 6 व्या युनिटकडे पहा (मॉडेल निवड, कॅशे).
तिसरा मुद्दा म्हणजे व्यावहारिक समतोल राखणे: थेट सहाय्यकांसह, पहिल्या शब्दाचे जलद आगमन (समजलेला विलंब) अत्यंत मूल्यवान आहे; म्हणून, मॉडेलला थेट उत्तर एंटर करण्यास सांगणे आणि प्रथम (4थ्या युनिटमधील सिस्टम प्रॉम्प्टद्वारे) एक लहान परिणाम देण्यास सांगणे प्रवाहाचा फायदा वाढवते. जर वापरकर्त्याला पहिल्या सेकंदात काहीतरी अर्थपूर्ण दिसले, तर ते पुढील तपशीलासाठी संयमाने प्रतीक्षा करतात. दुसरीकडे, पार्श्वभूमीत चालणाऱ्या नोकऱ्यांमध्ये प्रवाहाचे कोणतेही योगदान नाही, ज्याचे आउटपुट पुढील ऑटोमेशन चरणावर जाते; काम योग्य आणि पूर्णपणे पूर्ण झाले आहे हा एकमेव निकष आहे.
सारांशात
प्रवाह तुकड्याने प्रतिसाद मिळवते, समजलेली विलंबता कमी करते आणि मोठ्या थ्रूपुटवर कालबाह्य होण्यास प्रतिबंध करते. थेट सहाय्यक आणि दीर्घ दस्तऐवज निर्मितीसाठी जवळजवळ अनिवार्य; लहान/पार्श्वभूमीच्या कामासाठी हे अनावश्यक आहे. लांब प्रॉडक्शनमध्ये, प्रॉम्प्टसह समोरून रचना आणि लांबी लादणे गुणवत्ता आणि शोधण्यायोग्यता दोन्ही वाढवते; प्रवाह पूर्ण झाल्यावर, stop_reason आणि वापर निश्चितपणे तपासले जातात.
अर्ज कार्य
दोन परिस्थिती निवडा: एक थेट/दीर्घ (उदा. ग्राहकाला अहवाल), एक लहान/पार्श्वभूमी (उदा. टॅगिंग). (1) तुम्ही प्रत्येकासाठी प्रवाह वापरणार की नाही हे ठरवा आणि त्याचे समर्थन करा. (२) दीर्घ स्क्रिप्टसाठी (शीर्षलेख + लक्ष्य लांबी) रचना लागू करणारा प्रॉम्प्ट लिहा. (३) कमाल_टोकन्स मूल्ये निश्चित करा. (4) तुम्ही स्टॉप_रिझन आणि प्रवाहाच्या शेवटी कोणत्या तपासण्या कराल याची यादी करा.
चेकलिस्ट
- स्ट्रीमिंग म्हणजे काय आणि ते समजलेली विलंबता कशी कमी करते हे मी स्पष्ट करू शकतो.
- [ ] मला प्रवाह आणि डेल्टा सामील होण्याचे मूलभूत प्रकार समजले.
- [ ] मला मोठ्या max_tokens सह प्रवाहित करण्याची आवश्यकता आणि कालबाह्य संबंधांबद्दल माहिती आहे.
- मी कोणत्या वर्कलोडमध्ये स्ट्रीमिंग वापरेन आणि कोणत्यामध्ये नाही हे मी ठरवू शकतो.
- [ ] मी प्रवाहाच्या शेवटी stop_reason आणि वापर तपासू शकतो.