ஸ்ட்ரீமிங் மற்றும் நீண்ட பதில்கள்

ஆதாயங்கள்:

• ஸ்ட்ரீமிங் என்றால் என்ன, நிகழ்வு வகைகள் மற்றும் அது ஏன் தேவை என்பதை விளக்க முடியும்.
• max_tokens நேரம் முடிவடைவதையும் 128K நீண்ட வெளியீட்டு உறவையும் புரிந்துகொள்கிறது
• பணிச்சுமைக்கு ஏற்ப ஸ்ட்ரீமிங் மற்றும் ஸ்ட்ரீமிங் அல்லாத கோரிக்கைகளுக்கு இடையே சரியான தேர்வு செய்யலாம்

அரட்டை இடைமுகத்தில், பதில் வார்த்தைக்கு வார்த்தை "டைப்" செய்யப்படுவதை நீங்கள் கவனித்திருக்கலாம். இது ஒரு காட்சி மலர்ச்சி அல்ல; இது ஸ்ட்ரீமிங் எனப்படும் ஒரு நுட்பத்தின் விளைவாகும் மற்றும் உற்பத்தி-தரமான LLM ஒருங்கிணைப்புக்கு பெரும்பாலும் கட்டாயமாகும். இந்த யூனிட்டில், ஓட்டம் என்றால் என்ன, அது என்ன நிகழ்வுகளைக் கொண்டுள்ளது, நீண்ட வெளியீடு மற்றும் காலக்கெடுவுடன் அதன் உறவு, எப்போது ஓட்டத்தைப் பயன்படுத்த வேண்டும், எப்போது கூடாது என்பதை நீங்கள் அறிந்து கொள்வீர்கள். ஒரு நிபுணரின் உண்மையான பணிகளின் மூலம் தலைப்பை நாங்கள் உள்ளடக்குவோம் — நேரடி உதவியாளர், நீண்ட அறிக்கை உருவாக்கம், தொகுதி செயலாக்கம்.

ஓட்டம் என்றால் என்ன?

ஸ்ட்ரீமிங் அல்லாத (ஒத்திசைவு) கோரிக்கையுடன், மாடல் முழு பதிலை உருவாக்கும் வரை நீங்கள் காத்திருக்கிறீர்கள்; பதில் தயாரானதும், அது ஒரு துண்டாக வரும். ஸ்ட்ரீமிங் கோரிக்கையில், மாதிரியை உருவாக்கும் போது, ​​சேவையகம் பதிலைத் துண்டுகளாக அனுப்புகிறது. தொழில்நுட்ப ரீதியாக, இது சர்வர்-அனுப்பப்பட்ட நிகழ்வுகள் மூலம் செய்யப்படுகிறது (SSE — Server-Sent Events, சர்வர் ஒரு திறந்த இணைப்பில் தொடர்ச்சியாக சிறிய நிகழ்வுகளை அனுப்பும் முறை).

பயனர் அனுபவத்தில் வித்தியாசம் தெளிவாகிறது: 8 வினாடிகள் எடுக்கும் பதிலில், ஸ்ட்ரீம் அல்லாத பயனர் 8 வினாடிகள் வெற்றுத் திரையை வெறித்துப் பார்க்கிறார்; ஸ்ட்ரீமிங் பயனர் முதல் வார்த்தைகளை ~0.5 வினாடிகளில் பார்க்கிறார் மற்றும் உரை ஓடத் தொடங்குகிறது. உணரப்பட்ட தாமதம்-பயனர் உணரும் காத்திருப்பு-பெரிய அளவில் குறைக்கப்படுகிறது, மொத்த நேரம் மாறாமல் இருக்கும்.

நிகழ்வுகளின் ஓட்ட வகைகள்

ஓட்டம் என்பது நிகழ்வுகளின் வரிசை. கருத்தியல் ரீதியாக, ஒரு பொதுவான ஓட்டம் பின்வருமாறு:

சம்பவம்

பொருள்

செய்தி_தொடக்கம்

பதில் தொடங்கியது; மாடல், ஐடி போன்ற தலைப்பு தகவல்கள் வந்துள்ளன.

content_block_start

உள்ளடக்கத்தின் தொகுதி (எ.கா. உரை) தொடங்கப்பட்டது

content_block_delta

ஒரு சிறு துண்டு உரை (டெல்டா) வந்தது; நீங்கள் இவற்றை சேகரிக்கிறீர்கள்

content_block_stop

தொகுதி முடிந்தது

செய்தி_டெல்டா

நிறுத்த_காரணம் மற்றும் பயன்பாடு போன்ற முடிவுத் தகவல் புதுப்பிக்கப்பட்டது

செய்தி_நிறுத்து

பதில் சொல்லுங்கள்

உள்ளடக்க_பிளாக்_டெல்டா நிகழ்வுகளில் உங்கள் குறியீடு தொடர்ச்சியாக உரையின் துண்டுகளை ஒருங்கிணைக்கிறது; ஸ்ட்ரீம் செய்யப்படாத பதிலின் அதே துல்லியமான உரையுடன் நீங்கள் முடிவடையும். பயன்பாடு (டோக்கன் எண்கள்) வழக்கமாக ஓட்டத்தின் முடிவில் தெளிவாக இருக்கும் - ஓட்டம் முடிந்தவுடன் செலவுகளைக் கண்காணிக்கலாம்.

உதவிக்குறிப்பு: பெரும்பாலான அதிகாரப்பூர்வ SDKகள் (மென்பொருள் டெவலப்மெண்ட் கிட் — வழங்குநரின் ஆயத்த நூலகம்) உங்களுக்காக ஸ்ட்ரீமை சேகரிக்க உதவும் ஒரு உதவியாளரை வழங்குகிறது (எ.கா. stream.get_final_message()). நீங்கள் எல்லா தடங்களையும் கைமுறையாக நிர்வகிக்க வேண்டியதில்லை; நீங்கள் முழு உரை, தனிப்பட்ட நிகழ்வுகளை செயலாக்க விரும்பினால் இந்த உதவியாளரைப் பயன்படுத்தவும் ஆனால் நேரலை அச்சிடவும்.

நீண்ட மறுமொழிகள், அதிகபட்ச_டோக்கன்கள் மற்றும் நேரம் முடிந்தது

ஸ்ட்ரீமிங்கிற்கான இரண்டாவது மற்றும் அதிக தொழில்நுட்பக் காரணம் காலாவதியாகும். ஒரு குறிப்பிட்ட காலத்திற்குள் HTTP கோரிக்கையை முடிக்கவில்லை என்றால், கிளையன்ட் இணைப்பை கைவிடுகிறது. மாடலில் இருந்து ஒரு பெரிய வெளியீட்டைக் கோரும்போது (எ.கா. 40,000 டோக்கன்களின் அறிக்கை), ஃப்ளோ அல்லாத அழைப்பு இந்த வரம்பை மீறலாம் மற்றும் நேரம் முடிந்தது - கோரிக்கை தோல்வியடையும், மேலும் உருவாக்கப்பட்ட டோக்கன்களுக்கு நீங்கள் பணம் செலுத்த வேண்டும்.

நவீன மாடல்கள் ஒரு கோரிக்கையில் 128,000 டோக்கன்களை வெளியிடலாம். ஆனால் கட்டைவிரல் விதி தெளிவாக உள்ளது: `max_tokens` மதிப்பு அதிகமாக இருந்தால் (தோராயமாக 16,000க்கு மேல்) ஸ்ட்ரீம்களைப் பயன்படுத்தவும். ஸ்ட்ரீமிங் இணைப்பை உயிர்ப்புடன் வைத்திருக்கிறது மற்றும் காலக்கெடுவைத் தடுக்கிறது; நீங்கள் உடனடியாக முன்னேற்றத்தையும் காண்பீர்கள்.

• `max_tokens`: மாடல் உருவாக்கக்கூடிய அதிகபட்ச வெளியீட்டு டோக்கன்கள்; ஒரு கடினமான கூரை. குறுக்கீடு ஏற்பட்டால், stop_reason max_tokens வழங்கப்படும்.
• சூழல் சாளரம்: உள்ளீடு + வெளியீட்டின் கூட்டுத்தொகை பொருந்த வேண்டிய சாளரம். max_tokens என்பது வெளியீட்டின் உச்சவரம்பு; இரண்டையும் கலக்காதீர்கள்.

எச்சரிக்கை: பெரிய max_tokens மூலம் ஓட்டமில்லாத கோரிக்கைகளை எறிவது தயாரிப்பில் ஒரு சிறந்த தவறு. பதில் இல்லாமல், இணைப்பு குறைகிறது, பயனர் பிழையைப் பார்க்கிறார், மேலும் டோக்கன் செலவு வீணாகிறது. நீண்ட வெளியீடு = ஸ்ட்ரீம்.

எப்போது பாய வேண்டும், எப்போது இல்லை?

நிலை

விருப்பம்

ஏன்

நேரடி அரட்டை / உதவியாளர்

ஓட்டம்

உணரப்பட்ட தாமதம் குறைகிறது, பயனர் முன்னேற்றத்தைக் காண்கிறார்

நீண்ட அறிக்கை / ஆவண தயாரிப்பு

ஓட்டம்

காலாவதியைத் தடுக்கிறது, பெரிய வெளியீட்டை பாதுகாப்பாக எடுத்துச் செல்கிறது

குறுகிய வகைப்பாடு (எ.கா. ஒற்றை வார்த்தை குறிச்சொல்)

ஓட்டம் இல்லை

வெளியீடு ஏற்கனவே சிறியது; கூடுதல் சிக்கலானது தேவையற்றது

தொகுதி செயலாக்கம்

ஓட்டமில்லாத/தொகுதி

முடிவுகள் உடனடியாகக் காட்டப்படாது; அலகு 7 ஐப் பார்க்கவும்

ஆட்டோமேஷன் படி (பின்னணியில்)

பொதுவாக ஓட்டம் இல்லை

நீங்கள் முடிவை அடுத்த படிக்கு அனுப்புகிறீர்கள், நேரடி காட்சி இல்லை

நகலெடுக்கக்கூடிய ப்ராம்ட்/டெம்ப்ளேட்கள்

ஸ்ட்ரீம் ஒரு ப்ராம்ட் அல்ல, ஆனால் ஸ்ட்ரீம் மூலம் உற்பத்தி செய்யப்படும் வெளியீட்டை நிர்வகிப்பதற்கு தூண்டுதல்கள் முக்கியமானவை. நீண்ட மற்றும் பாயும் தயாரிப்புகளில், முன்பக்கத்தில் இருந்து கட்டமைப்பை சுமத்துவது தரம் மற்றும் கண்டறியும் தன்மை ஆகிய இரண்டையும் அதிகரிக்கிறது.

# நீண்ட அறிக்கையை பிரிவுகளாகப் பிரிக்கவும் (இதன் மூலம் முன்னேற்றம் ஓட்டத்தில் தெரியும்) பின்வரும் தலைப்புகளுடன் இந்த சரியான வரிசையில் அறிக்கையை எழுதவும். ஒவ்வொரு தலைப்பையும் '##' என்று தொடங்கவும்:## சுருக்கம்## கண்டுபிடிப்புகள்## பரிந்துரைகள்## அடுத்த படிகள்

# நீண்ட உற்பத்தியில் துண்டிக்கப்படுவதைத் தவிர்க்க இலக்கு நீளத்தைக் கொடுங்கள். மொத்த உரை தோராயமாக 800 வார்த்தைகள் இருக்கும். பகுதிகளை சமநிலையில் வைத்திருங்கள்; பாதி வாக்கியத்தை கடைசியில் விடாதீர்கள்.

# ஸ்ட்ரீமிங் உதவியாளருக்கு முதல் வாக்கியத்தை உடனடியாகக் கொடுங்கள். முதலில் ஒரு வாக்கியத்தில் நேரடியான பதிலைக் கொடுங்கள், பின்னர் விரிவாகச் செல்லவும். எனவே பயனர் காத்திருக்கும்போது உடனடி முடிவைப் பார்க்கிறார்.

# நீண்ட வெளியீட்டை கட்டமைக்கப்பட்டதாக வைத்திருங்கள் (எனவே இது பின்னர் பாகுபடுத்தப்படலாம்) இந்த பிரிவுகளில் வெளியீட்டை வெளியிடவும் மற்றும் ஒவ்வொரு பகுதியையும் தனித்தனி '###' தலைப்புடன் குறிக்கவும், அதனால் நான் அதை நிரல் ரீதியாக அலச முடியும்: ### அறிமுகம் ### உடல் ### ஆதாரங்கள்

பலவீனமான ப்ராம்ட் / வலுவான ப்ராம்ட் (நீண்ட உற்பத்தி)

# பலவீனமான இந்த தலைப்பில் ஒரு நீண்ட மற்றும் விரிவான அறிக்கையை எழுதவும்.

# 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) ஒவ்வொன்றிற்கும் ஓட்டத்தைப் பயன்படுத்துவீர்களா என்பதை முடிவு செய்து நியாயப்படுத்தவும். (2) நீண்ட ஸ்கிரிப்ட் (தலைப்புகள் + இலக்கு நீளம்) கட்டமைப்பை விதிக்கும் ஒரு வரியில் எழுதவும். (3) max_tokens மதிப்புகளைத் தீர்மானிக்கவும். (4) ஓட்டத்தின் முடிவில் நிறுத்த_காரணம் மற்றும் பயன்பாட்டுடன் நீங்கள் என்ன சோதனைகளைச் செய்வீர்கள் என்று பட்டியலிடுங்கள்.

சரிபார்ப்பு பட்டியல்

• [ ] ஸ்ட்ரீமிங் என்றால் என்ன மற்றும் அது எப்படி உணரப்பட்ட தாமதத்தை குறைக்கிறது என்பதை என்னால் விளக்க முடியும்.
• [ ] ஸ்ட்ரீம் மற்றும் டெல்டா இணைப்பின் அடிப்படை நிகழ்வு வகைகளைப் புரிந்துகொண்டேன்.
• [ ] பெரிய மேக்ஸ்_டோக்கன்களுடன் ஸ்ட்ரீம் செய்ய வேண்டியதன் அவசியத்தையும் காலாவதியான உறவையும் நான் அறிவேன்.
• [ ] எந்த பணிச்சுமையில் நான் ஸ்ட்ரீமிங்கைப் பயன்படுத்துவேன், எதில் பயன்படுத்த மாட்டேன் என்பதை என்னால் தீர்மானிக்க முடியும்.
• [ ] ஸ்ட்ரீமின் முடிவில் நிறுத்த_காரணம் மற்றும் பயன்பாட்டை என்னால் சரிபார்க்க முடியும்.