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