लाभ:
- बता सकते हैं कि स्ट्रीमिंग क्या है, इवेंट के प्रकार और इसकी आवश्यकता क्यों है।
- max_tokens टाइमआउट और 128K लंबे आउटपुट संबंध को समझता है
- कार्यभार के अनुसार स्ट्रीमिंग और गैर-स्ट्रीमिंग अनुरोधों के बीच सही विकल्प चुन सकते हैं
आपने देखा होगा कि चैट इंटरफ़ेस में, प्रतिक्रिया शब्द दर शब्द "टाइप" की जाती है। यह कोई दृश्य उत्कर्ष नहीं है; यह स्ट्रीमिंग नामक तकनीक का परिणाम है और अक्सर उत्पादन-गुणवत्ता एलएलएम एकीकरण के लिए अनिवार्य है। इस इकाई में, आप सीखेंगे कि प्रवाह क्या है, इसमें कौन सी घटनाएँ शामिल हैं, लंबे आउटपुट और टाइमआउट के साथ इसका संबंध है, और प्रवाह का उपयोग कब करना है और कब नहीं। हम एक पेशेवर के वास्तविक कार्यों - लाइव असिस्टेंट, लंबी रिपोर्ट तैयार करना, बैच प्रोसेसिंग - के माध्यम से विषय को कवर करेंगे।
प्रवाह क्या है?
एक गैर-स्ट्रीमिंग (सिंक्रोनस) अनुरोध के साथ, आप तब तक प्रतीक्षा करते हैं जब तक कि मॉडल संपूर्ण प्रतिक्रिया उत्पन्न न कर दे; जब उत्तर तैयार हो जाता है, तो वह एक टुकड़े में आ जाता है। स्ट्रीमिंग अनुरोध में, जैसे ही मॉडल उत्पन्न होता है, सर्वर प्रतिक्रिया को टुकड़े-टुकड़े करके भेजता है। तकनीकी रूप से, यह सर्वर-भेजे गए ईवेंट (एसएसई - सर्वर-सेंटेड ईवेंट, एक विधि जिसमें सर्वर एक खुले कनेक्शन पर उत्तराधिकार में छोटी ईवेंट भेजता है) के साथ किया जाता है।
उपयोगकर्ता अनुभव में अंतर स्पष्ट हो जाता है: 8 सेकंड लगने वाली प्रतिक्रिया पर, गैर-स्ट्रीम उपयोगकर्ता 8 सेकंड के लिए रिक्त स्क्रीन को देखता रहता है; स्ट्रीमिंग उपयोगकर्ता ~0.5 सेकंड में पहला शब्द देखता है और पाठ प्रवाहित होना शुरू हो जाता है। अनुमानित विलंबता - उपयोगकर्ता द्वारा महसूस किया जाने वाला इंतजार - बहुत कम हो गया है, जबकि कुल समय अपरिवर्तित रहता है।
प्रवाह के घटना प्रकार
प्रवाह घटनाओं का एक क्रम है। वैचारिक रूप से, एक सामान्य प्रवाह इस प्रकार होता है:
घटना
मतलब
संदेश_प्रारंभ
प्रतिक्रिया शुरू हुई; मॉडल और आईडी जैसी हेडर जानकारी आ गई है.
content_block_start
सामग्री का एक ब्लॉक (जैसे पाठ) प्रारंभ हुआ
content_block_delta
पाठ का एक छोटा टुकड़ा (डेल्टा) आया; आप इन्हें एकत्र करें
सामग्री_ब्लॉक_स्टॉप
ब्लॉक पूरा हुआ
संदेश_डेल्टा
अंतिम जानकारी जैसे stop_reason और उपयोग को अद्यतन किया गया
संदेश_स्टॉप
उत्तर दें
आपका कोड क्रमिक रूप से content_block_delta ईवेंट में पाठ के टुकड़ों को जोड़ता है; अंत में आपको गैर-स्ट्रीम प्रतिक्रिया के समान सटीक पाठ मिलता है। उपयोग (टोकन नंबर) आमतौर पर प्रवाह के अंत में स्पष्ट होते हैं - प्रवाह समाप्त होने के बाद आप लागतों पर नज़र रखते हैं।
टिप: अधिकांश आधिकारिक एसडीके (सॉफ्टवेयर डेवलपमेंट किट - प्रदाता की तैयार लाइब्रेरी) एक सहायक प्रदान करते हैं जो आपके लिए स्ट्रीम एकत्र करता है (उदाहरण के लिए स्ट्रीम.गेट_फाइनल_मेसेज())। आपको सभी ट्रैक मैन्युअल रूप से प्रबंधित करने की आवश्यकता नहीं है; यदि आप पूर्ण पाठ चाहते हैं, व्यक्तिगत घटनाओं को संसाधित करना चाहते हैं, लेकिन लाइव प्रिंटिंग के लिए इस सहायक का उपयोग करें।
लंबी प्रतिक्रियाएँ, max_tokens और टाइमआउट
स्ट्रीमिंग का दूसरा और अधिक तकनीकी कारण टाइमआउट है। यदि HTTP अनुरोध एक निश्चित अवधि के भीतर पूरा नहीं होता है, तो क्लाइंट कनेक्शन बंद कर देता है। जब आप मॉडल से बड़े आउटपुट का अनुरोध करते हैं (उदाहरण के लिए 40,000 टोकन की रिपोर्ट), तो गैर-प्रवाह कॉल इस सीमा और समय सीमा से अधिक हो सकती है - अनुरोध विफल हो जाएगा, और आपको उत्पन्न टोकन के लिए भुगतान करना होगा।
आधुनिक मॉडल एक अनुरोध में 128,000 टोकन तक आउटपुट कर सकते हैं। लेकिन सामान्य नियम स्पष्ट है: यदि `max_tokens` मान अधिक है (लगभग 16,000 से ऊपर) तो स्ट्रीम का उपयोग करें। स्ट्रीमिंग कनेक्शन को जीवित रखती है और टाइमआउट को रोकती है; आपको तुरंत प्रगति भी दिखाई देगी.
- `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 के साथ काटी गई प्रतिक्रिया को पूर्ण माना जाता है।
- गलत तरीके से डेल्टा का विलय: एसडीके सहायक के साथ मैन्युअल योग अनुक्रम/अनुपलब्ध भागों की त्रुटि उत्पन्न करता है।
- 'उपयोग' को मध्य-धारा में पढ़ने का प्रयास: टोकन संख्याएँ आमतौर पर अंत में स्पष्ट हो जाती हैं; अंत में लागतों का हिसाब रखें.
- लागत में कटौती के लिए स्ट्रीमिंग को गलत समझना: स्ट्रीमिंग से अनुभव और सहनशक्ति में सुधार होता है; यह टोकन मूल्य नहीं बदलता है.
गहरा: प्रवाह टूटता है और लचीलापन
स्ट्रीमिंग एक लाइव कनेक्शन है; यह इसकी ताकत और कमजोरी दोनों है। यदि कनेक्शन बीच में ही बंद हो जाता है (नेटवर्क में उतार-चढ़ाव, क्लाइंट टाइमआउट), तो आप अब तक जमा किए गए टेक्स्ट को बरकरार रखेंगे, लेकिन प्रतिक्रिया अधूरी होगी। एक उत्पादन-गुणवत्ता वाले स्ट्रीमिंग क्लाइंट को इसके लिए तैयार रहना चाहिए: इसे आंशिक पाठ को "पूर्ण प्रतिक्रिया" के रूप में नहीं मानना चाहिए, न ही इसे तब तक प्रतिक्रिया को समाप्त नहीं मानना चाहिए जब तक कि यह message_stop ईवेंट नहीं देख लेता।
दूसरी सूक्ष्मता यह है कि प्रवाह से लागत में परिवर्तन नहीं होता है। चाहे आपको स्ट्रीमिंग के साथ या उसके बिना प्रतिक्रिया प्राप्त हो, टोकन मूल्य पर कोई प्रभाव नहीं पड़ता है; प्रवाह केवल अनुभव और सहनशक्ति में सुधार करता है। तो "अगर हम स्ट्रीमिंग करते हैं, तो क्या वे सस्ते होंगे?" प्रश्न का उत्तर नहीं है - लागत के लिए, 5वीं और 6वीं इकाई (मॉडल चयन, कैश) देखें।
तीसरा बिंदु व्यावहारिक संतुलन बनाना है: लाइव सहायकों के साथ, पहले शब्द का तेजी से आगमन (कथित देरी) को अत्यधिक महत्व दिया जाता है; इसलिए, मॉडल को सीधे उत्तर दर्ज करने और पहले एक संक्षिप्त परिणाम देने के लिए कहना (चौथी इकाई में सिस्टम प्रॉम्प्ट के माध्यम से) प्रवाह के लाभ को कई गुना बढ़ा देता है। यदि उपयोगकर्ता को पहले सेकंड में कुछ सार्थक दिखाई देता है, तो वे आगे आने वाले विवरण के लिए धैर्यपूर्वक प्रतीक्षा करते हैं। दूसरी ओर, पृष्ठभूमि में चलने वाली नौकरियों में प्रवाह का कोई योगदान नहीं होता है, जिसका आउटपुट अगले स्वचालन चरण पर जाता है; वहां एकमात्र मानदंड यह है कि कार्य सही ढंग से और पूरी तरह से पूरा हो गया है।
संक्षेप में
स्ट्रीमिंग प्रतिक्रिया को टुकड़े-टुकड़े करके पुनः प्राप्त करती है, कथित विलंबता को कम करती है और बड़े थ्रूपुट पर टाइमआउट को रोकती है। लाइव सहायक और लंबे दस्तावेज़ उत्पादन के लिए लगभग अनिवार्य; लघु/पृष्ठभूमि कार्य के लिए यह अनावश्यक है। लंबी प्रस्तुतियों में, संरचना और लंबाई को सामने से एक संकेत के साथ लगाने से गुणवत्ता और पता लगाने की क्षमता दोनों बढ़ जाती है; जब प्रवाह समाप्त हो जाता है, तो stop_reason और उपयोग की निश्चित रूप से जाँच की जाती है।
आवेदन कार्य
दो परिदृश्य चुनें: एक लाइव/लंबा (उदाहरण के लिए ग्राहक को रिपोर्ट करना), एक छोटा/पृष्ठभूमि (उदाहरण के लिए टैग करना)। (1) निर्णय लें और बताएं कि क्या आप प्रत्येक के लिए प्रवाह का उपयोग करेंगे। (2) एक संकेत लिखें जो लंबी स्क्रिप्ट (शीर्षक + लक्ष्य लंबाई) के लिए संरचना लागू करता है। (3) max_tokens मान निर्धारित करें। (4) सूचीबद्ध करें कि प्रवाह के अंत में आप stop_reason और उपयोग के साथ क्या जाँच करेंगे।
चेकलिस्ट
- [ ] मैं समझा सकता हूं कि स्ट्रीमिंग क्या है और यह कथित विलंबता को कैसे कम करती है।
- [ ] मैंने स्ट्रीम और डेल्टा जुड़ाव के मूल घटना प्रकारों को समझा।
- [ ] मैं बड़े max_tokens के साथ स्ट्रीम करने की आवश्यकता और टाइमआउट संबंध के बारे में जानता हूं।
- [ ] मैं तय कर सकता हूं कि किस कार्यभार में मैं स्ट्रीमिंग का उपयोग करूंगा और किसमें नहीं।
- [ ] मैं स्ट्रीम के अंत में stop_reason और उपयोग की जांच कर सकता हूं।