નફો:
- સ્ટ્રીમિંગ શું છે, ઇવેન્ટના પ્રકારો અને શા માટે તેની જરૂર છે તે સમજાવી શકે છે.
- max_tokens સમયસમાપ્તિ અને 128K લાંબા આઉટપુટ સંબંધને સમજે છે
- વર્કલોડ અનુસાર સ્ટ્રીમિંગ અને નોન-સ્ટ્રીમિંગ વિનંતીઓ વચ્ચે યોગ્ય પસંદગી કરી શકે છે
તમે કદાચ નોંધ્યું હશે કે ચેટ ઈન્ટરફેસમાં, પ્રતિભાવ શબ્દ દ્વારા "ટાઈપ" થાય છે. આ દ્રશ્ય ખીલવું નથી; તે સ્ટ્રીમિંગ નામની ટેકનિકનું પરિણામ છે અને ઉત્પાદન-ગુણવત્તાવાળા એલએલએમ એકીકરણ માટે ઘણીવાર ફરજિયાત છે. આ એકમમાં, તમે શીખી શકશો કે પ્રવાહ શું છે, તે કઈ ઘટનાઓ ધરાવે છે, લાંબા આઉટપુટ અને સમયસમાપ્તિ સાથે તેનો સંબંધ અને ક્યારે પ્રવાહનો ઉપયોગ કરવો અને ક્યારે નહીં. અમે એક વ્યાવસાયિકના વાસ્તવિક કાર્યો દ્વારા વિષયને આવરી લઈશું — લાઈવ આસિસ્ટન્ટ, લાંબો રિપોર્ટ જનરેશન, બેચ પ્રોસેસિંગ.
ફ્લો શું છે?
બિન-સ્ટ્રીમિંગ (સિંક્રનસ) વિનંતી સાથે, તમે મોડલ સંપૂર્ણ પ્રતિસાદ ઉત્પન્ન કરે ત્યાં સુધી રાહ જુઓ; જ્યારે જવાબ તૈયાર થાય છે, ત્યારે તે એક ભાગમાં આવે છે. સ્ટ્રીમિંગ વિનંતિમાં, સર્વર મોડલ જનરેટ થાય તે રીતે પ્રતિભાવ ટુકડો ટુકડો મોકલે છે. તકનીકી રીતે, આ સર્વર દ્વારા મોકલવામાં આવેલી ઇવેન્ટ્સ સાથે કરવામાં આવે છે (SSE — સર્વર-સેંટ ઇવેન્ટ્સ, એક પદ્ધતિ જેમાં સર્વર ખુલ્લા કનેક્શન પર અનુગામી નાની ઇવેન્ટ્સ મોકલે છે).
વપરાશકર્તાના અનુભવમાં તફાવત સ્પષ્ટ થાય છે: 8 સેકન્ડ લેતી પ્રતિક્રિયા પર, નોન-સ્ટ્રીમ વપરાશકર્તા 8 સેકન્ડ માટે ખાલી સ્ક્રીન તરફ જુએ છે; સ્ટ્રીમિંગ વપરાશકર્તા ~0.5 સેકન્ડમાં પ્રથમ શબ્દો જુએ છે અને ટેક્સ્ટ વહેવા લાગે છે. અનુમાનિત વિલંબતા-વપરાશકર્તા જે પ્રતીક્ષા અનુભવે છે તે ખૂબ જ ઘટી જાય છે, જ્યારે કુલ સમય યથાવત રહે છે.
પ્રવાહના ઇવેન્ટ પ્રકારો
પ્રવાહ એ ઘટનાઓનો ક્રમ છે. વૈચારિક રીતે, એક લાક્ષણિક પ્રવાહ આના જેવો જાય છે:
ઘટના
અર્થ
સંદેશ_પ્રારંભ
પ્રતિભાવ શરૂ થયો; મોડેલ અને ID જેવી હેડરની માહિતી આવી ગઈ છે.
content_block_start
સામગ્રીનો બ્લોક (દા.ત. ટેક્સ્ટ) શરૂ થયો
સામગ્રી_બ્લોક_ડેલ્ટા
ટેક્સ્ટનો એક નાનો ટુકડો (ડેલ્ટા) આવ્યો; તમે આ એકત્રિત કરો
content_block_stop
બ્લોક પૂર્ણ
સંદેશ_ડેલ્ટા
અપડેટ કરેલ અંતની માહિતી જેમ કે stop_reason અને ઉપયોગ
મેસેજ_સ્ટોપ
ઉપર જવાબ આપો
તમારો કોડ અનુક્રમે content_block_delta ઇવેન્ટ્સમાં ટેક્સ્ટના ટુકડાઓને જોડે છે; તમે નોન-સ્ટ્રીમ કરેલ પ્રતિસાદ જેવા જ ચોક્કસ ટેક્સ્ટ સાથે અંત કરો છો. વપરાશ (ટોકન નંબરો) સામાન્ય રીતે પ્રવાહના અંતે સ્પષ્ટ હોય છે — એકવાર પ્રવાહ સમાપ્ત થઈ જાય પછી તમે ખર્ચનો ટ્રૅક રાખો છો.
ટીપ: મોટાભાગના અધિકૃત SDK (સોફ્ટવેર ડેવલપમેન્ટ કિટ — પ્રદાતાની તૈયાર લાઇબ્રેરી) એક સહાયક પ્રદાન કરે છે જે તમારા માટે સ્ટ્રીમ એકત્રિત કરે છે (દા.ત. stream.get_final_message()). તમારે બધા ટ્રેક મેન્યુઅલી મેનેજ કરવાની જરૂર નથી; જો તમને સંપૂર્ણ લખાણ જોઈતું હોય તો આ સહાયકનો ઉપયોગ કરો, વ્યક્તિગત ઇવેન્ટ્સની પ્રક્રિયા કરો પરંતુ લાઈવ પ્રિન્ટિંગ માટે.
લાંબા પ્રતિભાવો, મહત્તમ_ટોકન્સ અને સમયસમાપ્તિ
સ્ટ્રીમિંગનું બીજું અને વધુ તકનીકી કારણ સમય સમાપ્તિ છે. જો HTTP વિનંતી ચોક્કસ સમયગાળામાં પૂર્ણ ન થાય, તો ક્લાયંટ કનેક્શન છોડી દે છે. જ્યારે તમે મોડેલમાંથી મોટા આઉટપુટની વિનંતી કરો છો (દા.ત. 40,000 ટોકન્સનો અહેવાલ), ત્યારે નોન-ફ્લો કૉલ આ મર્યાદાને ઓળંગી શકે છે અને સમય સમાપ્ત થઈ શકે છે — વિનંતી નિષ્ફળ જશે, અને તમારે જનરેટ થયેલા ટોકન્સ માટે ચૂકવણી કરવી પડશે.
આધુનિક મોડલ એક વિનંતીમાં 128,000 ટોકન્સ સુધીનું આઉટપુટ કરી શકે છે. પરંતુ અંગૂઠાનો નિયમ સ્પષ્ટ છે: જો `મેક્સ_ટોકન્સ` મૂલ્ય ઊંચું હોય તો સ્ટ્રીમ્સનો ઉપયોગ કરો (આશરે 16,000થી ઉપર). સ્ટ્રીમિંગ કનેક્શનને જીવંત રાખે છે અને સમયસમાપ્તિને અટકાવે છે; તમે તરત જ પ્રગતિ પણ જોશો.
- `max_tokens`: મહત્તમ આઉટપુટ ટોકન્સ મોડેલ ઉત્પન્ન કરી શકે છે; સખત છત. જો કોઈ વિક્ષેપ આવે, તો stop_reason max_tokens પરત કરવામાં આવે છે.
- સંદર્ભ વિન્ડો: વિન્ડો જેમાં ઇનપુટ + આઉટપુટનો સરવાળો ફિટ હોવો જોઈએ. max_tokens એ આઉટપુટની ટોચમર્યાદા છે; બંનેને મિક્સ કરશો નહીં.
સાવધાન: મોટા max_tokens સાથે નોન-ફ્લો વિનંતીઓ ફેંકવી એ ઉત્પાદનમાં ઉત્તમ ભૂલ છે. પ્રતિસાદ વિના, કનેક્શન ઘટી જાય છે, વપરાશકર્તા ભૂલ જુએ છે, અને ટોકન ખર્ચ વેડફાઈ જાય છે. લાંબી આઉટપુટ = પ્રવાહ.
ક્યારે વહેવું અને ક્યારે નહીં?
સ્થિતિ
પસંદગી
શા માટે
લાઇવ ચેટ / સહાયક
પ્રવાહ
વિલંબિતતામાં ઘટાડો થયો, વપરાશકર્તા પ્રગતિ જુએ છે
લાંબા અહેવાલ / દસ્તાવેજ ઉત્પાદન
પ્રવાહ
સમયસમાપ્તિને અટકાવે છે, મોટા આઉટપુટને સુરક્ષિત રીતે વહન કરે છે
ટૂંકું વર્ગીકરણ (દા.ત. એક શબ્દ ટેગ)
કોઈ પ્રવાહ નથી
આઉટપુટ પહેલેથી જ નાનું છે; વધારાની જટિલતા બિનજરૂરી
બેચ પ્રક્રિયા
પ્રવાહહીન/બેચ
પરિણામો તરત દેખાતા નથી; એકમ 7 જુઓ
ઓટોમેશન સ્ટેપ (બેકગ્રાઉન્ડમાં)
સામાન્ય રીતે કોઈ પ્રવાહ નથી
તમે પરિણામને આગલા પગલામાં પસાર કરશો, કોઈ લાઇવ ડિસ્પ્લે નહીં
નકલ કરી શકાય તેવા પ્રોમ્પ્ટ/ટેમ્પ્લેટ્સ
સ્ટ્રીમ પોતે પ્રોમ્પ્ટ નથી, પરંતુ સ્ટ્રીમ દ્વારા ઉત્પાદિત આઉટપુટનું સંચાલન કરવા માટે પ્રોમ્પ્ટ મહત્વપૂર્ણ છે. લાંબા અને ફ્લોય પ્રોડક્શન્સમાં, આગળથી સ્ટ્રક્ચર લાદવાથી ગુણવત્તા અને ટ્રેસિબિલિટી બંને વધે છે.
# લાંબા અહેવાલને વિભાગોમાં વિભાજીત કરો (જેથી પ્રગતિ પ્રવાહમાં દેખાય) આ ચોક્કસ ક્રમમાં નીચેના મથાળાઓ સાથે અહેવાલ લખો. દરેક મથાળાને '##' સાથે શરૂ કરો:## સારાંશ## તારણો## ભલામણો## આગલા પગલાં
# લાંબા ઉત્પાદનમાં કાપ ટાળવા માટે લક્ષ્ય લંબાઈ આપો. કુલ લખાણ અંદાજે 800 શબ્દોનું હશે. ભાગોને સંતુલિત રાખો; અંતમાં અડધું વાક્ય છોડશો નહીં.
# સ્ટ્રીમિંગ સહાયક માટે તરત જ પ્રથમ વાક્ય આપો. પ્રથમ એક વાક્યનો સીધો જવાબ આપો, પછી વિગતવાર જાઓ. તેથી વપરાશકર્તા રાહ જોતી વખતે તાત્કાલિક પરિણામ જુએ છે.
# લાંબા આઉટપુટને સંરચિત રાખો (જેથી તે પછીથી વિશ્લેષિત થઈ શકે છે) આ વિભાગોમાં આઉટપુટ આઉટપુટ કરો અને દરેક વિભાગને અલગ '###' હેડર વડે ચિહ્નિત કરો જેથી હું તેને પ્રોગ્રામેટિકલી પાર્સ કરી શકું: ### પરિચય ### BODY ### સ્ત્રોતો
નબળા પ્રોમ્પ્ટ / મજબૂત પ્રોમ્પ્ટ (લાંબા ઉત્પાદન)
# WEAK આ વિષય પર એક લાંબો અને વિગતવાર અહેવાલ લખો.
# STRONGઆ વિષય પર આશરે 900 શબ્દોનો અહેવાલ લખો. શીર્ષકો: ## સારાંશ, ## વિશ્લેષણ, ## જોખમો, ## ભલામણો. દરેક મથાળું વધુમાં વધુ 3 ફકરાનું હોવું જોઈએ. અંતમાં અડધું વાક્ય છોડશો નહીં.
શક્તિશાળી સંસ્કરણ; તે અગાઉથી લંબાઈ, માળખું અને સમાપ્ત ગુણવત્તા નક્કી કરે છે. જેમ જેમ વિભાગો પ્રવાહમાં આવે છે, તેમ વપરાશકર્તા પ્રગતિને સ્પષ્ટપણે જુએ છે અને મોડલ વિક્ષેપના જોખમ સામે લંબાઈને જાતે જ મેનેજ કરે છે.
ત્રણ મિની કેસ
કેસ 1 - ખાલી સ્ક્રીનની ફરિયાદ. કન્સલ્ટિંગ ટીમનો ક્લાયન્ટ આસિસ્ટન્ટ પ્રવાહ વિના જવાબ આપી રહ્યો હતો; સરેરાશ પ્રતિસાદ 7 સેકન્ડ લે છે, વપરાશકર્તાઓ પૂછે છે "શું તે સ્થિર થાય છે?" તેણે ફરિયાદ કરી. એકવાર હું પ્રવાહમાં આવી ગયો, પ્રથમ શબ્દ ~0.6 સેકન્ડમાં આવ્યો; કુલ સમય સમાન રહ્યો, પરંતુ "ધીમી" ફરિયાદો લગભગ અદૃશ્ય થઈ ગઈ.
કેસ 2 - જૂનો રિપોર્ટ. એક ફાઇનાન્સ ટીમે 30 પાનાનો ત્રિમાસિક અહેવાલ તૈયાર કર્યો હતો; max_tokens: 30000 સાથે, નો-ફ્લો વિનંતી 60-સેકન્ડના ક્લાયન્ટ સમયસમાપ્તિમાં અટકી જશે, વિનંતી નિષ્ફળ જશે — અને જનરેટ કરેલ ટોકન્સ ઇન્વૉઇસમાં લખવામાં આવશે. તેઓ પ્રવાહ સાથે ગયા; કનેક્શન જીવંત રહ્યું, રિપોર્ટ સંપૂર્ણ રીતે વિતરિત કરવામાં આવ્યો, અને નકામા ખર્ચ દૂર કરવામાં આવ્યો.
કેસ 3 - બિનજરૂરી પ્રવાહ. એક ઓપરેશન ટીમ ઇનકમિંગ ઈમેઈલને "તાકીદ/નિયમિત" તરીકે લેબલ કરી રહી હતી; આઉટપુટ એક શબ્દ હતો, પરંતુ તેઓ આદત રીતે પ્રવાહનો ઉપયોગ કરતા હતા. પ્રવાહે એક-શબ્દના પ્રતિભાવમાં કોઈ લાભ આપ્યો નથી, જે કોડને બિનજરૂરી રીતે જટિલ બનાવે છે. જ્યારે મેં ફ્લોલેસ પર સ્વિચ કર્યું, ત્યારે કોડ સરળ બન્યો અને વર્તન સમાન રહ્યું. પાઠ: સ્ટ્રીમિંગ લાંબા/જીવંત આઉટપુટમાં મૂલ્યવાન છે, દરેક જગ્યાએ નહીં.
સામાન્ય ભૂલો
- લાંબા આઉટપુટમાં સ્ટ્રીમ્સનો ઉપયોગ ન કરવો: સમયસમાપ્તિ અને વ્યર્થ ટોકન ખર્ચ.
- ટૂંકા આઉટપુટમાં સ્ટ્રીમિંગનો ઉપયોગ કરવો: બિનજરૂરી જટિલતા, શૂન્ય લાભ.
- સ્ટ્રીમના અંતે `સ્ટોપ_કારણ` તપાસી રહ્યાં નથી: મહત્તમ_ટોકન્સ સાથેનો કપાયેલ પ્રતિસાદ પૂર્ણ માનવામાં આવે છે.
- ડેલ્ટાને ખોટી રીતે મર્જ કરવું: SDK હેલ્પર સાથે મેન્યુઅલ સમેશન ક્રમ/ગુમ થયેલા ભાગોની ભૂલ પેદા કરે છે.
- `ઉપયોગ` મધ્ય-પ્રવાહ વાંચવાનો પ્રયાસ કરી રહ્યા છીએ: ટોકન નંબરો સામાન્ય રીતે અંતમાં સ્પષ્ટ થઈ જાય છે; અંતે ખર્ચ પર નજર રાખો.
- ખર્ચ ઘટાડવા માટે સ્ટ્રીમિંગની ભૂલ કરવી: સ્ટ્રીમિંગ અનુભવ અને સહનશક્તિ સુધારે છે; તે ટોકન કિંમતમાં ફેરફાર કરતું નથી.
વધુ ઊંડો: પ્રવાહ વિરામ અને સ્થિતિસ્થાપકતા
સ્ટ્રીમિંગ એ જીવંત જોડાણ છે; આ તેની શક્તિ અને નબળાઈ બંને છે. જો કનેક્શન મધ્યમાં ઘટી જાય છે (નેટવર્કની વધઘટ, ક્લાયંટ સમયસમાપ્તિ), તો તમે અત્યાર સુધી સંચિત કરેલ ટેક્સ્ટને જાળવી રાખશો, પરંતુ પ્રતિસાદ અધૂરો રહેશે. ઉત્પાદન-ગુણવત્તા સ્ટ્રીમિંગ ક્લાયંટ આ માટે તૈયાર હોવું જોઈએ: તેણે આંશિક ટેક્સ્ટને "સંપૂર્ણ પ્રતિસાદ" તરીકે ગણવો જોઈએ નહીં, અને જ્યાં સુધી તે સંદેશ_સ્ટોપ ઇવેન્ટ ન જુએ ત્યાં સુધી પ્રતિસાદને સમાપ્ત કરવાનો વિચાર કરવો જોઈએ નહીં.
બીજી સૂક્ષ્મતા એ છે કે પ્રવાહ ખર્ચમાં ફેરફાર કરતું નથી. તમને સ્ટ્રીમિંગ સાથે કે વગર પ્રતિસાદ મળે તે ટોકન કિંમતને અસર કરતું નથી; પ્રવાહ માત્ર અનુભવ અને સહનશક્તિ સુધારે છે. તેથી "જો આપણે સ્ટ્રીમિંગ પર જઈએ, તો શું તે સસ્તું હશે?" પ્રશ્નનો જવાબ ના છે — કિંમત માટે, 5મું અને 6ઠ્ઠું એકમ (મોડલ પસંદગી, કેશ) જુઓ.
ત્રીજો મુદ્દો વ્યવહારુ સંતુલન જાળવવાનો છે: જીવંત સહાયકો સાથે, પ્રથમ શબ્દનું ઝડપી આગમન (વિલંબ માનવામાં આવે છે) ખૂબ મૂલ્યવાન છે; તેથી, મોડલને સીધો જવાબ દાખલ કરવા અને પ્રથમ ટૂંકું પરિણામ આપવાનું કહેવું (4થા એકમમાં સિસ્ટમ પ્રોમ્પ્ટ દ્વારા) પ્રવાહના લાભને ગુણાકાર કરે છે. જો વપરાશકર્તા પ્રથમ સેકન્ડમાં કંઈક અર્થપૂર્ણ જુએ છે, તો તેઓ નીચેની વિગતો માટે ધીરજપૂર્વક રાહ જુએ છે. બીજી બાજુ, પૃષ્ઠભૂમિમાં ચાલતી નોકરીઓમાં પ્રવાહનું કોઈ યોગદાન નથી, જેનું આઉટપુટ આગામી ઓટોમેશન સ્ટેપ પર જાય છે; ત્યાં એકમાત્ર માપદંડ એ છે કે કાર્ય યોગ્ય રીતે અને સંપૂર્ણ રીતે પૂર્ણ થયું છે.
સારાંશમાં
સ્ટ્રીમિંગ પ્રતિસાદના ભાગને ભાગરૂપે પુનઃપ્રાપ્ત કરે છે, માનવામાં આવતી વિલંબતા ઘટાડે છે અને મોટા થ્રુપુટ પર સમય સમાપ્ત થતા અટકાવે છે. જીવંત સહાયક અને લાંબા દસ્તાવેજ ઉત્પાદન માટે લગભગ ફરજિયાત; ટૂંકા/બેકગ્રાઉન્ડ કામ માટે તે બિનજરૂરી છે. લાંબા પ્રોડક્શન્સમાં, પ્રોમ્પ્ટ સાથે આગળની બાજુથી માળખું અને લંબાઈ લાદવાથી ગુણવત્તા અને ટ્રેસેબિલિટી બંને વધે છે; જ્યારે પ્રવાહ સમાપ્ત થાય છે, ત્યારે stop_reason અને ઉપયોગ ચોક્કસપણે તપાસવામાં આવે છે.
એપ્લિકેશન કાર્ય
બે દૃશ્યો પસંદ કરો: એક જીવંત/લાંબી (દા.ત. ગ્રાહકને જાણ કરો), એક ટૂંકી/બેકગ્રાઉન્ડ (દા.ત. ટેગિંગ). (1) તમે દરેક માટે પ્રવાહનો ઉપયોગ કરશો કે કેમ તે નક્કી કરો અને વાજબી ઠેરવો. (2) એક પ્રોમ્પ્ટ લખો જે લાંબી સ્ક્રિપ્ટ (હેડિંગ્સ + લક્ષ્ય લંબાઈ) માટે માળખું લાદશે. (3) મહત્તમ_ટોકન્સ મૂલ્યો નક્કી કરો. (4) પ્રવાહના અંતે તમે stop_reason અને ઉપયોગ સાથે કયા ચેકો કરશો તેની યાદી બનાવો.
ચેકલિસ્ટ
- [ ] હું સમજાવી શકું છું કે સ્ટ્રીમિંગ શું છે અને તે કથિત વિલંબને કેવી રીતે ઘટાડે છે.
- [ ] હું સ્ટ્રીમ અને ડેલ્ટા જોડવાના મૂળભૂત ઘટના પ્રકારોને સમજી શક્યો.
- [ ] હું મોટા max_tokens સાથે સ્ટ્રીમ કરવાની જરૂરિયાત અને સમય સમાપ્તિ સંબંધ વિશે જાણું છું.
- [ ] હું નક્કી કરી શકું છું કે કયા વર્કલોડમાં હું સ્ટ્રીમિંગનો ઉપયોગ કરીશ અને કયામાં નહીં.
- [ ] હું સ્ટ્રીમના અંતે stop_reason અને વપરાશ તપાસી શકું છું.