ஆதாயங்கள்:
- யோசனையிலிருந்து உற்பத்திக்கு எல்எல்எம் அம்சத்தை எடுக்கும் எண்ட்-டு-எண்ட் கட்டமைப்பை வடிவமைக்க முடியும்
- சரிபார்ப்பு அமலாக்கம், மனித ஒப்புதல் மற்றும் கண்காணிப்பு (பதிவு/அளவீடுகள்) ஆகியவற்றின் அடுக்குகளை நிறுவுகிறது
- எல்லைகள் நெறிமுறைகள் மற்றும் தனியுரிமைக் கொள்கைகளை உற்பத்தி முடிவுகளாக மொழிபெயர்க்கின்றன
முந்தைய பத்து அலகுகளில், கோரிக்கை அமைப்பு, டோக்கன் பொருளாதாரம், ஓட்டம், கணினி வரியில், மாதிரி தேர்வு, கேச், தொகுதி, பிழை மேலாண்மை, பாதுகாப்பான விசை மற்றும் ஆட்டோமேஷன் ஆகிய பகுதிகளை ஒவ்வொன்றாகக் கற்றுக்கொண்டோம். இந்த கடைசி யூனிட்டில், நாங்கள் பாகங்களை இணைத்து, யோசனையிலிருந்து உற்பத்தி வரை LLM அம்சத்தைக் கொண்டு செல்லும் முழுமையான கட்டமைப்பை நிறுவுகிறோம். உற்பத்தியானது "வொர்க்கிங் டெமோ" என்பதிலிருந்து வேறுபட்டது: சரிபார்ப்பு கட்டாயம், வெளியீடு கண்காணிக்கப்பட வேண்டும், எல்லைகள் மற்றும் நெறிமுறைக் கோட்பாடுகள் முடிவுகளில் உட்பொதிக்கப்பட வேண்டும். இந்த அலகு தொகுதியின் கேரியர் நெடுவரிசை; முந்தியவை எல்லாம் இங்கே ஒன்று சேரும்.
உற்பத்தி கட்டிடக்கலை அடுக்குகள்
ஒரு திடமான LLM தகுதியானது தோராயமாக ஐந்து அடுக்குகளைக் கொண்டுள்ளது:
- உள்ளீட்டு அடுக்கு: தரவைச் சேகரிக்கவும், அதை சுத்தம் செய்யவும், உணர்திறன் பகுதிகளை மறைக்கவும், தேவையானதை மட்டும் அனுப்பவும்.
- மாதிரி அடுக்கு: சரியான மாதிரியைத் தேர்ந்தெடுக்கவும் (அலகு 5), கணினி வரியில் மற்றும் அளவுருக்களை அமைக்கவும் (அலகு 4), கேச் (அலகு 6).
- சரிபார்ப்பு அடுக்கு: ஸ்கீமா/விதி, ஆதாரம் மற்றும் தேவைப்பட்டால் மனித ஒப்புதலுக்கு எதிரான வெளியீட்டைச் சரிபார்க்கவும்.
- செயல் அடுக்கு: சரிபார்க்கப்பட்ட வெளியீட்டுடன் செயலைச் செய்யவும்; அதிக தாக்கத்தை ஏற்படுத்தக்கூடிய செயல்களைப் படமெடுக்கவும்.
- கண்காணிப்பு அடுக்கு: ஒவ்வொரு அழைப்பு, செலவு, பிழை மற்றும் தரம் ஆகியவற்றை பதிவு செய்து அளவிடவும்.
இந்த அடுக்குகள் ஒரு குழாய்; ஒவ்வொன்றும் முந்தைய வெளியீட்டின் வெளியீட்டை சரிபார்க்கிறது.
சரிபார்ப்பு ஏன் தேவைப்படுகிறது?
LLMகள் சரளமான ஆனால் சில நேரங்களில் துல்லியமற்ற வெளியீட்டை உருவாக்க முடியும். இது மாயத்தோற்றம் என்று அழைக்கப்படுகிறது: மாதிரியானது உண்மையாகத் தோன்றும் ஆனால் உண்மையாக இல்லாத தகவலை உருவாக்கலாம். அரட்டை விளையாட்டில் இது பொறுத்துக்கொள்ளக்கூடியது; ஒரு உற்பத்தி அமைப்பில் (விலைப்பட்டியல், சுகாதாரம், சட்ட, நிதி) பொறுத்துக்கொள்ள முடியாது. எனவே அது கண்மூடித்தனமாக நம்பமுடியாததாக மாறியது; உறுதி செய்யப்படுகிறது.
சரிபார்ப்பு அடுக்குகள் (தாக்கத்தால் அதிகரிக்கும்):
- வடிவமைப்பு/திட்ட சரிபார்ப்பு: வெளியீடு எதிர்பார்க்கப்படும் JSON திட்டத்துடன் ஒத்துப்போகிறதா? (கட்டமைக்கப்பட்ட வெளியீடு பெரும்பாலும் இதற்கு உத்தரவாதம் அளிக்கிறது.)
- விதி/தர்க்க சரிபார்ப்பு: மதிப்புகள் நியாயமானதா? (தொகை எதிர்மறையாக உள்ளதா, எதிர்கால தேதியா, வகை செல்லுபடியாகுமா?)
- ஆதார சரிபார்ப்பு: வழங்கப்பட்ட ஆவணங்களின் அடிப்படையில் உரிமைகோரல் உள்ளதா? ஆவணத்தில் இல்லாத ஒன்றை மாதிரி சொல்கிறாரா?
- மனித ஒப்புதல்: உயர் தாக்கம் அல்லது தெளிவற்ற முடிவுகளை நிபுணர் மதிப்பாய்வு செய்கிறார்.
எச்சரிக்கை: "மாடல் மிகவும் நன்றாக உள்ளது, மேலும் சரிபார்ப்பு தேவையில்லை" என்பது மிகவும் ஆபத்தான உற்பத்தி தவறு. எவ்வளவு சிறந்த மாதிரியாக இருந்தாலும் சரிபார்ப்பு அடுக்கு என்பது அதிக தாக்கத்தை ஏற்படுத்தும் முடிவுகளில் ஒரு பாதுகாப்பு வலையாகும். ஒரு தவறான தானியங்கி முடிவு கூட சேமிக்கப்பட்ட நேரத்தை எடுத்துக் கொள்ளலாம்.
மனித-இன்-தி-லூப்
ஒவ்வொரு முடிவும் முற்றிலும் தானாக இருக்க வேண்டியதில்லை. ஹ்யூமன்-இன்-தி-லூப் அணுகுமுறையில், மாதிரி வேலையை விரைவுபடுத்துகிறது மற்றும் மனிதர் அதை அங்கீகரிக்கிறார். சரியான சமநிலை முடிவின் தாக்கம் மற்றும் அந்த பணியின் மாதிரியின் நம்பகத்தன்மையைப் பொறுத்தது.
முடிவின் தாக்கம்
அணுகுமுறை
குறைந்த (லேபிள் பரிந்துரை, வரைவு)
முழு ஆட்டோமேஷன்; பிழை மலிவானது மற்றும் மீளக்கூடியது
நடுத்தர (ரூட்டிங், முன்னுரிமை)
ஆட்டோமேஷன் + மாதிரி கட்டுப்பாடு
அதிக (பணம், ஒப்பந்தம், ஆரோக்கியம், நீக்குதல்)
மனித சம்மதம் கட்டாயம்; மாதிரி மட்டுமே பரிந்துரைக்கிறது
கண்காணிப்பு: நீங்கள் பார்க்காததை உங்களால் நிர்வகிக்க முடியாது
தயாரிப்பில், நீங்கள் ஒவ்வொரு அழைப்பையும் கண்காணிக்க வேண்டும். கண்காணிப்பு இல்லாமல், நீங்கள் விலை, தரத்தை மேம்படுத்தவோ அல்லது சிக்கலை முன்கூட்டியே கண்டுபிடிக்கவோ முடியாது. பதிவு செய்வதற்கான முக்கிய அளவீடுகள்:
- பயன்பாடு/செலவு: ஒரு கோரிக்கை மற்றும் மொத்த டோக்கன்கள், மாதிரி விநியோகம், தினசரி செலவு.
- தாமதம்: சராசரி மற்றும் மோசமான பதில் நேரம்.
- பிழை விகிதம்: 429/500 விகிதங்கள், மறு முயற்சிகள், கைவிடுதல்கள்.
- தரம்: சரிபார்ப்பு அடுக்கில் நிராகரிக்கப்பட்ட வெளியீட்டு விகிதம், மனித ஒப்புதலில் திருத்த விகிதம், பயனர் கருத்து.
உதவிக்குறிப்பு: பதிவுகளை கண்காணிக்க முக்கியமான தரவை (தனிப்பட்ட தகவல், விசைகள்) எழுத வேண்டாம். ரகசியத்தன்மையின் எல்லைக்குள் பதிவுகளை கருத்தில் கொள்ளுங்கள்; தேவைப்பட்டால் மறைத்தல் மூலம் பதிவு செய்யவும் (அலகு 9).
நெறிமுறைகள் மற்றும் எல்லைகள்
நெறிமுறைப் பொறுப்பு என்பது தொழில்நுட்பத் துல்லியத்தைப் போலவே உற்பத்தி முடிவின் ஒரு பகுதியாகும்:
- வெளிப்படைத்தன்மை: ஒரு செயற்கை நுண்ணறிவு அல்லது மனிதனிடம் பேசுகிறார்களா என்பதை பயனர் அறிந்திருக்க வேண்டும்.
- நேர்மை மற்றும் சார்பு: மாதிரியானது அது பயிற்றுவிக்கப்பட்ட தரவுகளிலிருந்து சார்புகளைக் கொண்டிருக்கலாம்; அதிக தாக்கத்தை ஏற்படுத்தும் முடிவுகளில் (பணியமர்த்தல், கடன்) பாரபட்சமான விளைவுகளைக் கண்காணிக்கவும்.
- பொறுப்பு: ஒரு தானியங்கி முடிவு தீங்கு விளைவித்தால், நீங்கள் பொறுப்பு; "மாதிரி சொன்னது" என்பது ஒரு தற்காப்பு அல்ல.
- வரம்புகளை ஏற்றுக்கொள்வது: மாதிரி சில பணிகளை நம்பகத்தன்மையுடன் செய்ய முடியாது; அவற்றை தானியக்கமாக்காமல் இருப்பதும் ஒரு வடிவமைப்பு முடிவாகும்.
நகலெடுக்கக்கூடிய வார்ப்புருக்கள்
# சரிபார்ப்பு சரிபார்ப்பு பட்டியல் (வெளியீட்டு உருவாக்கத்திற்குப் பிறகு) 1) திட்டம் செல்லுபடியாகுமா? (கட்டமைக்கப்பட்ட வெளியீடு சரிபார்ப்பு)2) மதிப்புகள் அர்த்தமுள்ளதா? (விதி சரிபார்ப்பு: வரம்பு, தேதி, enum)3) உரிமைகோரல் ஆதாரத்தின் அடிப்படையில் உள்ளதா? (ஆவணத்தில் இல்லை என்றால் நிராகரிக்கவும்)4) பாதிப்பு அதிகமாக உள்ளதா? → மனித ஒப்புதலுக்கு அனுப்பவும்5) அனைத்தும் நிறைவேற்றப்பட்டால் → செயலை அனுமதித்தால், சேமிக்கவும்
# வழங்கப்பட்ட ஆவணத்தில் உள்ள தகவலை மட்டுமே ஆதாரத்தை நம்பியிருக்க வேண்டும் என்று கணினி அறிவுறுத்தல். ஆவணத்தில் இல்லாத எதையும் சேர்க்க வேண்டாம். ஆவணத்தில் தகவல் இல்லை என்றால், "ஆவணத்தில் காணப்படவில்லை" என்று எழுதவும். விஷயங்களை ஒருபோதும் யூகிக்கவோ அல்லது உருவாக்கவோ வேண்டாம்.
# மனித ஒப்புதல் வரம்பு (முடிவு விதி)IF முடிவு_வகை [பணம், ஒப்பந்தம், நீக்குதல், ஆரோக்கியம்] → மனித ஒப்புதல் கட்டாயம்IF மாதிரி_நம்பிக்கை < வாசல் அல்லது சரிபார்ப்பு "நிச்சயமற்றது" → மனித ஒப்புதலுக்குச் சமர்ப்பிக்கவும்
# ட்ரேஸ் லாக் டெம்ப்ளேட் (உணர்வுத் தரவை எழுதுதல்){ "நேரம்":"...", "மாடல்":"...", "உள்ளீடு_டோக்கன்":..., "அவுட்புட்_டோக்கன்":..., "தாமத_ம்":..., "நிறுத்த_காரணம்":"...", "அங்கீகாரம்":" கடந்து|நிராகரிக்கப்பட்டது|மனிதன்" மற்றும் ":co...} விசை ஒருபோதும் எழுதப்படவில்லை
பலவீனமான ப்ராம்ட் / வலுவான ப்ராம்ட் (உற்பத்தி நம்பகத்தன்மை)
# பலவீனமானது (சரிபார்ப்பு இல்லை, ஆதாரம் இல்லை, தானாகவே பொருந்தும்) இந்தக் கோரிக்கையை மதிப்பிட்டு, பணத்தைத் திரும்பப்பெற முடிவு செய்து விண்ணப்பிக்கவும்.
# STRONG (மூல அடிப்படையிலானது, பரிந்துரையை உருவாக்குகிறது, மனித ஒப்புதலுக்கு செல்கிறது) திரும்பப்பெறும் கொள்கை ஆவணத்தின் அடிப்படையில் மட்டுமே இந்த ரிட்டர்ன் கோரிக்கையை மதிப்பிடவும். நியாயமான முடிவைப் பரிந்துரைக்கவும் ஆனால் செயல்படுத்த வேண்டாம்: {"பரிந்துரை":"அனுமதி|நிராகரி","காரணம்":"...","கொள்கை_பிரிவு":"..."}.கொள்கை ஆவணத்தில் தெளிவான அடிப்படை இல்லை என்றால், "தெளிவில்லாதது" என்று கொடுங்கள். ஒரு பிரதிநிதி இறுதி முடிவை அங்கீகரிப்பார்.
சக்திவாய்ந்த பதிப்பு; இது முடிவை மூலத்திற்குக் காரணம் கூறுகிறது, மாதிரியை "செயல்பவர்" என்பதற்குப் பதிலாக "பரிந்துரையாளர்" என்று நிலைநிறுத்துகிறது மற்றும் மனித ஒப்புதலுக்குப் பின்னால் அதிக தாக்கத்தை ஏற்படுத்துகிறது. இது உற்பத்தி நம்பகத்தன்மையின் சாராம்சம்.
மூன்று சிறிய வழக்குகள்
வழக்கு 1 - சரிபார்ப்பு அடுக்கு சேமிக்கப்பட்ட நாள். ஒரு ஃபின்டெக் மாதிரி பரிவர்த்தனை விளக்கங்களை வகைப்படுத்தி தானியங்கி கணக்கியல் பதிவுகளை உருவாக்குகிறது. அவர்கள் விதி சரிபார்ப்பைச் சேர்த்தனர்: மாதிரியானது தவறாகத் தொகையை வெளியிட்டவுடன் (ஆவணத்தில் 1,250க்கு பதிலாக 12,500), "ஆவணத்துடன் தொகை பொருந்தவில்லை" விதி வெளியீட்டை நிராகரித்தது மற்றும் பதிவு மனிதனிடம் விழுந்தது. சரிபார்ப்பு இல்லை என்றால், தவறான பதிவு அமைதியாக கணினியில் நுழையும்.
வழக்கு 2 - தப்பியோடிய நபர் கண்காணிப்பால் பிடிபட்டார். ஒரு SaaS குழு ஒரு கண்காணிப்பு குழுவை அமைத்தது; ஒரு நாள் காலையில் தினசரி செலவு மூன்று மடங்கு. ஒரு கிளையன்ட் ஒரு லூப்பில் நுழைந்து அதே கோரிக்கையை ஆயிரக்கணக்கான முறை அனுப்பியது பதிவுகளில் இருந்து பார்க்கப்பட்டது. அவர்கள் ஒதுக்கீட்டையும் துப்பறிதலையும் சேர்த்தனர்; சில மணி நேரங்களில் பிரச்னைக்கு தீர்வு காணப்பட்டது. கண்காணிப்பு இல்லாமல், மாத இறுதியில் பில் ஆச்சரியமாக இருக்கும்.
வழக்கு 3 - வரம்பை ஏற்றுக்கொள்வது. ஒரு ஹெல்த்கேர் ஸ்டார்ட்அப் நோயறிதலுக்கான பரிந்துரையை முழுமையாக தானாகவே செய்து அதை நோயாளிக்குக் காட்ட திட்டமிட்டுள்ளது. நெறிமுறைகள் மற்றும் பொறுப்பு மதிப்பாய்வில், இது வரம்பற்றது என்று அவர்கள் முடிவு செய்தனர்: மாதிரியானது சுருக்கத்தையும் சாத்தியமான புள்ளிகளையும் மருத்துவருக்கு மட்டுமே வழங்குகிறது, மருத்துவர் நோயறிதலைச் செய்கிறார். வேலையை தானியக்கமாக்காமல் இருப்பதும் ஒரு முதிர்ந்த வடிவமைப்பு முடிவாகும்.
பொதுவான தவறுகள்
- சரிபார்ப்பைத் தவிர்ப்பது: "மாடல் நன்றாக உள்ளது" என்று கூறி, கண்மூடித்தனமாக வெளியீட்டைப் பயன்படுத்துதல்.
- உயர் தாக்க முடிவை தானியக்கமாக்குதல்: பணம்/உடல்நலம்/சட்டத்தில் மனித ஒப்புதல் அவசியம்.
- கண்காணிப்பு இல்லை: செலவு மற்றும் தர சிக்கல்கள் தாமதமாக கண்டறியப்படுகின்றன.
- பதிவுகளில் முக்கியமான தரவை எழுதுதல்: தனியுரிமை மீறல்; அதை மறைப்பதன் மூலம் சேமிக்கவும்.
- மூலத்தை நம்பியிருக்க முயற்சிக்கவில்லை: ஆவணத்தில் இல்லாததை மாதிரி உருவாக்கலாம்.
- வரம்புகளை புறக்கணித்தல்: சில பணிகளை தானியக்கமாக்காமல் இருப்பது சரியான முடிவு; வெளிப்படைத்தன்மை மற்றும் பொறுப்பு உங்களுடையது.
ஆழமானது: வெளியீட்டு மேலாண்மை, திரும்பப் பெறுதல் மற்றும் அதிகரிக்கும் வரிசைப்படுத்தல்
ஒரு LLM அம்சத்தை தயாரிப்பில் எடுத்துக்கொள்வது, அதை அமைத்து அதை மறந்துவிடுவது அல்ல; காலப்போக்கில் ஒரு நேரடி அமைப்பைப் பாதுகாப்பாக மாற்றியமைப்பதாகும். இதற்கு மூன்று தூண்கள் உள்ளன.
பதிப்பு. உங்கள் சிஸ்டம் ப்ராம்ட், மாடல் தேர்வு மற்றும் சரிபார்ப்பு விதிகள் காலப்போக்கில் மாறும். ஒவ்வொரு குறிப்பிடத்தக்க மாற்றத்தையும் பதிப்பு செய்து, எந்தப் பதிப்பு நேரலையில் உள்ளது என்பதைப் பதிவுசெய்யவும். ஒரு நாள் தரம் குறைந்தால், "என்ன மாறினோம்?" சில நிமிடங்களில் நீங்கள் கேள்விக்கு பதிலளிக்க முடியும். பதிப்பு இல்லாத அமைப்பில், பின்னடைவுக்கான மூல காரணத்தைக் கண்டறிய பல நாட்கள் ஆகும்.
திரும்ப திரும்ப. ஒரு புதிய ப்ராம்ட் அல்லது மாடல் நேரலையில் எதிர்பார்த்ததை விட மோசமாக செயல்பட்டால், நீங்கள் விரைவாக முந்தைய, நன்கு அறியப்பட்ட பதிப்பிற்கு திரும்ப முடியும். திரும்பப்பெறும் திட்டம் இல்லாத மாற்றம் என்பது நேரடி ஆபத்தை கண்மூடித்தனமாக ஏற்றுக்கொள்வது. "நான் எதையாவது மாற்றினேன், அது மோசமாகிவிட்டது, என்னால் திரும்பிச் செல்ல முடியாது" என்பது மிகவும் விலையுயர்ந்த தயாரிப்பு காட்சி.
படிப்படியான வெளியீடு. எல்லா ட்ராஃபிக்கிலும் ஒரே நேரத்தில் மாற்றத்தைப் பயன்படுத்துவதற்குப் பதிலாக, முதலில் அதை ஒரு சிறிய சதவீதத்திற்கு (எ.கா. 5%) மாற்றி, அளவீடுகளை (தரம், செலவு, பிழைகள்) கண்காணிக்கவும். அது நன்றாக இருந்தால், நீங்கள் சதவீதத்தை அதிகரிக்கிறீர்கள்; அது மோசமாக இருந்தால், ஒரு சிறிய பகுதி மட்டுமே பாதிக்கப்பட்ட நிலையில் அதைத் திரும்பப் பெறுவீர்கள். இது ஆபத்தை பெரிதும் கட்டுப்படுத்துகிறது.
இந்த மூன்று நடைமுறைகளும் முந்தைய எல்லா அலகுகளிலிருந்தும் நுட்பங்களை ஒருங்கிணைக்கிறது: eval (அலகு 5) நடவடிக்கைகளை முன்கூட்டியே மாற்றுகிறது, கண்காணிப்பு (இந்த அலகு) பரவலின் போது முன்கூட்டியே எச்சரிக்கையை அளிக்கிறது, சரிபார்ப்பு அடுக்கு தவறான வெளியீடுகளை செயல்படுவதற்கு முன்பு பிடிக்கிறது. உற்பத்தி என்பது ஒரு சரியான அமைப்பு அல்ல; இது ஒரு தொடர்ச்சியான ஒழுக்கம் ஆகும், அது அளவிடுகிறது, கண்காணிக்கிறது மற்றும் நம்பிக்கையுடன் மாற்ற முடியும். முழு தொகுதியும் நீங்கள் இந்த ஒழுக்கத்தை நிலைநாட்ட வேண்டும்.
சுருக்கமாக
வேலை செய்யும் டெமோவை விட உற்பத்தி அதிகம்: இது உள்ளீடு, மாதிரி, சரிபார்ப்பு, செயல் மற்றும் கண்காணிப்பு அடுக்குகளின் குழாய். சரிபார்ப்பு இல்லாமல் வெளியீடு நம்பகத்தன்மையற்றது; உயர் தாக்க முடிவுகள் மனித ஒப்புதலுடன் பிணைக்கப்பட்டுள்ளன; ஒவ்வொரு அழைப்பும் செலவு, பிழைகள் மற்றும் தரத்திற்காக கண்காணிக்கப்படுகிறது. நெறிமுறைகள், வெளிப்படைத்தன்மை, சார்பு கட்டுப்பாடு, பொறுப்புக்கூறல் மற்றும் வரம்புகளை ஏற்றுக்கொள்வது ஆகியவை தொழில்நுட்ப முடிவுகளில் ஒருங்கிணைந்தவை. இந்த தொகுதியில் கற்றுக்கொண்ட ஒவ்வொரு பகுதியும் இந்த முழுமையான வடிவமைப்பில் ஒன்றாக வருகிறது.
விண்ணப்ப பணி
எல்எல்எம் அம்சத்தை இறுதி முதல் இறுதி வரை வடிவமைக்கவும். (1) உங்கள் குறிப்பிட்ட பணிக்கான ஐந்து அடுக்குகளை (உள்ளீடு, மாதிரி, சரிபார்ப்பு, செயல், கண்காணிப்பு) நிரப்பவும். (2) எந்தெந்த முடிவுகளுக்கு மனித அங்கீகாரம் தேவைப்படும் என்பதை தாக்கத்தால் குறிக்கவும். (3) குறைந்தது மூன்று சரிபார்ப்பு காசோலைகளை எழுதவும் (திட்டம், விதி, மூல). (4) நீங்கள் கண்காணிக்கும் முக்கிய அளவீடுகள் மற்றும் நீங்கள் பதிவு செய்யாதவற்றைத் தீர்மானிக்கவும். (5) இந்த அம்சத்தில் நீங்கள் ஏற்றுக்கொள்ளும் வரம்பு மற்றும் நெறிமுறைக் கொள்கையை எழுதுங்கள்.
சரிபார்ப்பு பட்டியல்
- உற்பத்திக் குழாயின் ஐந்து அடுக்குகளை என்னால் வடிவமைக்க முடியும்.
- [ ] ஸ்கீமா, விதி மற்றும் மூலத்திற்கு எதிரான வெளியீட்டை என்னால் சரிபார்க்க முடியும்.
- [ ] முடிவின் தாக்கத்தின் அடிப்படையில் நான் மனித ஒப்புதல் வரம்பை அமைக்க முடியும்.
- [ ] நான் செலவு, பிழை மற்றும் தரத்தை கண்காணித்து, பதிவுகளில் முக்கியமான தரவை எழுதாமல் இருக்க பயிற்சி செய்கிறேன்.
- [ ] நான் நெறிமுறைகள், பொறுப்பு மற்றும் எல்லைகளை உற்பத்தி முடிவுகளாக மாற்ற முடியும்.
தொகுதி தேர்வு
1. LLM அரட்டை API இல் 'சிஸ்டம்' பங்கு என்ன செய்கிறது?
- A) முழு உரையாடல் முழுவதும் பொருந்தும் மாதிரி நிரந்தர வழிமுறைகள் மற்றும் நடத்தை விதிகளை வழங்குகிறது ✔
- B) பயனர் எழுதிய கடைசி கேள்வியை வைத்திருக்கிறது
- சி) மாதிரியால் உருவாக்கப்பட்ட பதிலைச் சேமிக்கிறது
- D) API விசையை குறியாக்குகிறது
விளக்கம்: கணினிப் பாத்திரமானது, முழு உரையாடலுக்கும் பொருந்தக்கூடிய நிலையான வழிமுறைகள், ஆளுமை மற்றும் விதிகளை மாதிரிக்கு வழங்குகிறது; இது பயனர் செய்திகளிலிருந்து தனித்தனியான உயர்நிலை வழிமாற்று.
2. API கோரிக்கையில் ஒவ்வொரு முறையும் உரையாடல் வரலாறு (முந்தைய செய்திகள்) ஏன் மீண்டும் அனுப்பப்படுகிறது?
- A) சேவையகம் வரலாற்றை நீக்குவதால் காப்புப்பிரதி எடுக்க வேண்டியது அவசியம்
- B) API அழைப்புகள் நிலையற்றவை; ✔ மாடல் வரலாறு நினைவில் இல்லாததால் ஒவ்வொரு கோரிக்கையிலும் சூழல் மீண்டும் அனுப்பப்படுகிறது
- C) விலைப்பட்டியலுக்கு மட்டுமே தேவை, மாதிரியில் எந்த விளைவையும் ஏற்படுத்தாது
- D) பதிலைத் தாமதப்படுத்துவதைத் தவிர்க்க வரலாற்றை அனுப்புவது கட்டாயமாகும்
விளக்கம்: LLM API அழைப்புகள் நிலையற்றவை; மாடல் முந்தைய சுற்றுகளை நினைவில் கொள்ளவில்லை, எனவே சூழலைப் பாதுகாப்பதற்கான ஒவ்வொரு கோரிக்கையிலும் தொடர்புடைய அனைத்து வரலாறுகளும் அனுப்பப்படும்.
3. LLM விலையில் 'டோக்கன்' என்றால் என்ன?
- A) API இல் உள்நுழைய பயன்படுத்தப்படும் ஒரு முறை கடவுச்சொல்
- B) ஒவ்வொரு கோரிக்கைக்கும் ஒரு நிலையான கட்டணம் செலுத்தப்படுகிறது
- சி) மாதிரி உரையை செயலாக்கும் மிகச்சிறிய அலகு; பொதுவாக வார்த்தை பகுதி ✔ உடன் ஒத்துள்ளது
- D) வெளியீட்டின் நீளத்தை மட்டுமே அளவிடும் அலகு
விளக்கம்: டோக்கன் என்பது மாதிரியானது உரையைச் செயலாக்கும் சிறிய அலகு ஆகும்; இது வழக்கமாக ஒரு வார்த்தையின் ஒரு பகுதிக்கு ஒத்திருக்கும், மேலும் உள்ளீடு மற்றும் வெளியீடு இரண்டும் டோக்கன்களின் எண்ணிக்கையின் அடிப்படையில் வசூலிக்கப்படும்.
4. பெரும்பாலான LLM வழங்குநர்களில் உள்ளீட்டு டோக்கன்களை விட வெளியீட்டு டோக்கன்கள் ஏன் விலை அதிகம்?
- A) வெளியீட்டு டோக்கன்கள் எப்போதும் உள்ளீட்டை விட நீளமாக இருக்கும்
- B) உள்ளீட்டு டோக்கன்கள் இலவசம்
- C) வெளியீடு டோக்கன்கள் இணையத்தில் இரண்டு முறை அனுப்பப்படும்
- D) ஒவ்வொரு டோக்கனுக்கும் கூடுதல் கணக்கீடுகள் தேவைப்படுவதால், யூனிட் விலை அதிகமாக உள்ளது
விளக்கம்: ஒவ்வொரு வெளியீட்டு டோக்கன்களுக்கும் படி-படி-படி உருவாக்கம் (கணக்கீடு) செய்ய மாதிரி தேவைப்படுகிறது; இந்த உற்பத்தி செலவு உள்ளீட்டை ஒரே நேரத்தில் செயலாக்குவதை விட அதிகமாக உள்ளது, எனவே வெளியீட்டு அலகு விலை பொதுவாக அதிகமாக இருக்கும்.
5. எந்த சூழ்நிலையில் ஸ்ட்ரீமிங்கைப் பயன்படுத்துவது மிகவும் நன்மை பயக்கும்?
- A) நீண்ட பதில்களில்; உணரப்பட்ட தாமதத்தை குறைக்கிறது மற்றும் நேரம் முடிவதை தடுக்கிறது ✔
- B) மிகக் குறுகிய, ஒரு வார்த்தை பதில்களில் மட்டுமே
- C) செலவை பூஜ்ஜியமாகக் குறைக்க
- D) API விசையை மறைக்க
விளக்கம்: நீண்ட பதில்களில், ஸ்ட்ரீமிங் முதல் வார்த்தைகளை உடனடியாகத் தோன்றச் செய்வதன் மூலம் உணரப்பட்ட தாமதத்தைக் குறைக்கிறது மற்றும் பெரிய max_tokens மதிப்புகளில் HTTP காலக்கெடுவைத் தடுக்கிறது.
6. நவீன மாடல்களில் 'முயற்சி' அளவுருவை அதிகரிப்பது பொதுவாக என்ன பாதிக்கிறது?
- அ) பதிலை எப்போதும் சுருக்கவும்
- B) API விசையை தானாகவே சுழற்றுகிறது
- C) இது உள்ளீட்டு டோக்கன் விலையை மட்டுமே குறைக்கிறது
- D) சிந்தனை ஆழம் மற்றும் டோக்கன் செலவு அதிகரிக்கிறது; இது தரத்தை மேம்படுத்தலாம், ஆனால் இது தாமதம் மற்றும் செலவை அதிகரிக்கிறது ✔
விளக்கம்: முயற்சி அளவுரு மாதிரியானது ஒரு பணியைப் பற்றி எவ்வளவு ஆழமாகச் சிந்திக்கும் மற்றும் எத்தனை டோக்கன்களைச் செலவழிக்கும் என்பதைச் சரிசெய்கிறது; மேம்படுத்துதல் தரத்தை மேம்படுத்தலாம், ஆனால் இது தாமதத்தையும் செலவையும் அதிகரிக்கிறது. எளிமையான பணிகளுக்கு, குறைந்த முயற்சி போதுமானது.
7. ஒரு எளிய, அதிக அளவு வகைப்பாடு பணிக்கு பொதுவாக மிகவும் செலவு குறைந்த அணுகுமுறை என்ன?
- A) எப்போதும் மிகவும் விலையுயர்ந்த மற்றும் சக்திவாய்ந்த மாதிரியைப் பயன்படுத்தவும்
- B) ஒவ்வொரு கோரிக்கைக்கும் ஒரே நேரத்தில் அனைத்து மாடல்களையும் அழைக்கிறது
- C) ஒரு சிறிய eval மூலம் சரிபார்ப்பதன் மூலம் பணியை நிறைவேற்றும் இலகுவான/மலிவான மாதிரியைத் தேர்ந்தெடுப்பது ✔
- D) max_tokens மதிப்பை தேவையில்லாமல் மிக அதிகமாக வைத்திருப்பது
விளக்கம்: பணி சிக்கலானதாக இல்லாவிட்டால், மிகவும் விலையுயர்ந்த மற்றும் சக்திவாய்ந்த மாதிரியைப் பயன்படுத்துவதற்குப் பதிலாக, பணியை எளிதாக நிறைவேற்றும் வேகமான மற்றும் மலிவான மாதிரியைத் தேர்ந்தெடுப்பது (எ.கா. ஹைக்கூ வகுப்பு) செலவைக் கணிசமாகக் குறைக்கும்.
8. எந்தச் சூழ்நிலையில் ப்ராம்ட் கேச்சிங் செலவைக் குறைக்கிறது?
- A) ஒரு பெரிய மற்றும் நிலையான சூழல் பல கோரிக்கைகளில் மீண்டும் மீண்டும் பயன்படுத்தப்படும் போது ✔
- B) ஒவ்வொரு கோரிக்கையிலும் முற்றிலும் மாறுபட்ட உரை அனுப்பப்படும் போது
- C) ஒரே ஒரு வேண்டுகோள் விடுக்கப்படும் போது
- D) வெளியீடு டோக்கன்களை குறைக்க
விளக்கம்: கேச்சிங் என்பது முன்னொட்டு பொருத்தம்; ஒரு பெரிய, மாறாத சூழல் (சிஸ்டம் ப்ராம்ட், ஆவணங்கள்) பல கோரிக்கைகளில் மீண்டும் பயன்படுத்தப்படும் சந்தர்ப்பங்களில், தற்காலிக சேமிப்பிலிருந்து படிப்பது முழு விலையில் ஒரு சிறிய பகுதி (~0.1x) ஆகும்.
9. ப்ராம்ட் கேச் ஹிட் ஆக, ப்ராம்ட்டை நான் எப்படி திருத்த வேண்டும்?
- A) தொடக்கத்தில் மாறி உள்ளடக்கத்தையும் முடிவில் நிலையான உள்ளடக்கத்தையும் வைப்பது
- B) ஒவ்வொரு கோரிக்கைக்கும் கணினி வரியில் தற்போதைய தேதி மற்றும் நேரத்தை உட்பொதிக்கவும்
- C) தொடக்கத்தில் நிலையான உள்ளடக்கம் (கணினி வரியில், ஆவணங்கள்) மற்றும் இறுதியில் மாறி உள்ளடக்கம் ✔
- D) ஒவ்வொரு கோரிக்கையிலும் கருவி பட்டியலின் வரிசையை மாற்றுதல்
விளக்கம்: கேச் ஒரு முன்னொட்டு பொருத்தமாக இருப்பதால், நிலையான/மாறாத உள்ளடக்கம் (கணினி வரியில், ஆவணங்கள்) துவக்கப்பட்டது; மாறி உள்ளடக்கம் (தேதி, பயனர் கேள்வி, கோரிக்கை ஐடி) இறுதியில் வைக்கப்படும். தொடக்கத்தில் மாற்றப்பட்ட ஒரு பைட் கூட தற்காலிக சேமிப்பை செல்லாததாக்கும்.
10. எந்த வகையான பணிச்சுமைக்கு தொகுதி செயலாக்கம் மிகவும் பொருத்தமானது?
- A) திரையில் உடனடி பதிலை பயனர் எதிர்பார்க்கும் நேரடி அரட்டை
- B) ஒரே ஒரு சிறிய கேள்வி
- C) API விசையை உருவாக்குதல்
- D) தாமதத்தைத் தாங்கும், அதிக அளவு மற்றும் உடனடி முடிவுகள் தேவைப்படாத வேலைகள் ✔
விளக்கம்: உடனடி பதில் தேவைப்படாத மற்றும் தாமதத்தை பொறுத்துக்கொள்ளக்கூடிய பெரிய அளவிலான வேலைகளுக்கு தொகுதி செயலாக்கம் பொருத்தமானது; முடிவுகள் சிறிது நேரம் கழித்து வழங்கப்படும், ஆனால் அலகு செலவு பொதுவாக குறைவாக இருக்கும்.
11. எந்தக் கோரிக்கையின் முடிவுகள் ஒரு தொகுப்பில் உள்ளன என்பதை நம்பிக்கையுடன் பொருத்துவதற்கு எது பயன்படுத்தப்படுகிறது?
- A) கோரிக்கைகளின் உத்தரவு (நிலை) அனுப்புதல்
- B) பதில்களின் நீளம்
- C) API விசையின் கடைசி 4 இலக்கங்கள்
- D) ஒவ்வொரு கோரிக்கைக்கும் கொடுக்கப்பட்ட தனிப்பட்ட தனிப்பயன்_ஐடி ✔
குறிப்பு: சமர்ப்பிப்பு வரிசையை விட வேறு வரிசையில் மொத்த முடிவுகள் வழங்கப்படலாம்; எனவே ஒவ்வொரு கோரிக்கைக்கும் கொடுக்கப்பட்ட தனித்துவமான custom_id மூலம், இருப்பிடம் அல்ல, ஐடி மூலம் முடிவுகளைப் பொருத்துவது அவசியம்.
12. API இலிருந்து 429 (விகித வரம்பு) பிழையைப் பெறும்போது பரிந்துரைக்கப்படும் நடத்தை என்ன?
- A) ஒரே நேரத்தில் பல கோரிக்கைகளை அனுப்புவதன் மூலம் கட்டாயப்படுத்துதல்
- B) மறுமுயற்சிக்குப் பின் தலைப்பு ✔ஐத் தொடர்ந்து, அதிவேக பின்னடைவுடன் மீண்டும் முயற்சிக்கவும்
- C) கோரிக்கையை முழுவதுமாக ரத்துசெய்து, பிழையை செயலிழப்பாகப் பயனருக்குக் காட்டவும்
- D) API விசையை மாற்றுதல்
விளக்கம்: 429 மீண்டும் முயற்சிக்கக்கூடிய பிழை; மறுமுயற்சிக்குப் பின் தலைப்புக்கு மதிப்பளித்து, அதிவேக பின்னடைவுடன் மீண்டும் முயற்சிப்பதே சரியான அணுகுமுறை. பெரும்பாலான அதிகாரப்பூர்வ SDKகள் இதை தானாகவே செய்கின்றன.
13. பின்வரும் HTTP பிழைக் குறியீடுகளில் எது பொதுவாக மீண்டும் முயற்சி செய்யக்கூடியதாகக் கருதப்படுகிறது?
- A) 400 (தவறான கோரிக்கை)
- B) 401 (அங்கீகாரப் பிழை)
- C) 529 (சர்வர் ஓவர்லோட்) ✔
- D) 404 (காணப்படவில்லை)
விளக்கம்: 429 (வேக வரம்பு), 500 (சர்வர் பிழை) மற்றும் 529 (ஓவர்லோட்) தற்காலிக பிழைகள் மற்றும் பின்வாங்குவதன் மூலம் மீண்டும் முயற்சி செய்யலாம். 400 மற்றும் 401 போன்ற பிழைகள் கோரிக்கை/அடையாளச் சிக்கல்கள்; மீண்டும் முயற்சி செய்தும் தீர்வு கிடைக்காது.
14. API விசைகளை நிர்வகிக்க பின்வரும் பாதுகாப்பான வழி எது?
- A) சூழல் மாறி/மறைக்கப்பட்ட மேலாளரில் சேமித்தல், குறியீட்டில் உட்பொதிக்காமல் தொடர்ந்து சுழலும் ✔
- B) விசையை நேரடியாக மூலக் குறியீட்டில் எழுதி களஞ்சியத்திற்கு அனுப்பவும்
- C) கிளையன்ட் பக்கத்தில் (உலாவி) ஜாவாஸ்கிரிப்ட்டில் விசையை வைப்பது
- ஈ) மின்னஞ்சல் வழியாக முழு குழுவுடன் ஒரு விசையைப் பகிர்தல்
விளக்கம்: விசைகள் ஒருபோதும் மூலக் குறியீடு அல்லது களஞ்சியத்தில் எழுதப்படுவதில்லை; இது சூழல் மாறி அல்லது மறைக்கப்பட்ட மேலாண்மைக் கருவியில் சேமிக்கப்பட்டு, குறைந்தபட்ச சலுகைகளுடன் வழங்கப்பட்டு, தொடர்ந்து சுழலும்.
15. தனியுரிமை அடிப்படையில் ஆட்டோமேஷன் கருவியுடன் (n8n, Zapier, Make) LLM ஒருங்கிணைப்புக்கான சிறந்த அணுகுமுறை என்ன?
- A) தேவை இல்லாவிட்டாலும், அனைத்து மூலத் தரவையும் மாதிரிக்கு அனுப்புதல்
- B) ஃப்ளோ ஸ்டெப் உள்ளே எளிய உரையில் API விசையை எழுதுதல்
- C) முக்கியத் தரவைக் குறைத்தல் மற்றும் மறைத்தல் மற்றும் விசையை ரகசியச் சான்றுகளாகச் சேமித்தல் ✔
- D) ஓட்ட வரலாற்றில் தனிப்பட்ட தரவை நிரந்தரமாக வைத்திருத்தல்
விளக்கம்: மூன்றாம் தரப்பு அமைப்புகள் மற்றும் மாடல் வழியாக தானியங்கு முறையில் நுழையும் தரவு செல்லும்போது, உணர்திறன்/தனிப்பட்ட தரவு குறைக்கப்பட வேண்டும், முகமூடி மற்றும் தேவையான புலங்கள் மட்டுமே அனுப்பப்பட வேண்டும்; API விசையானது கருவிக்குள் ரகசிய சான்றுகளாகவும் சேமிக்கப்படுகிறது.
16. எல்எல்எம் அடிப்படையிலான தயாரிப்பு அம்சத்தில் வெளியீட்டின் சரிபார்ப்பு ஏன் கட்டாயமாக உள்ளது?
- A) வடிவமைப்பு மட்டுமே தேவைப்படுகிறது, ஏனெனில் மாதிரி ஒருபோதும் தவறு செய்யாது
- B) ஏனெனில் மாதிரி திரவமாக ஆனால் சில நேரங்களில் தவறாக உருவாக்க முடியும்; திட்டம்/விதி ஆதாரம் மற்றும் மனித ஒப்புதலுடன் தணிக்கை செய்யப்பட வேண்டும் ✔
- C) சரிபார்ப்பு தவிர்க்கப்பட வேண்டும், ஏனெனில் அது செலவை மட்டுமே அதிகரிக்கிறது
- D) சரிபார்ப்பு என்பது டோக்கன்களின் எண்ணிக்கையைக் குறைப்பதற்காக மட்டுமே
விளக்கம்: LLMகள் சரளமாக ஆனால் சில நேரங்களில் துல்லியமற்ற (மாயத்தோற்றம்) வெளியீட்டை உருவாக்கலாம்; அதனால் அது உயர் தாக்க முடிவுகளில் வெளிவந்தது; இது ஸ்கீமா/விதிகளைச் சரிபார்த்தல், மூலச் சரிபார்ப்பு மற்றும் தேவைப்படும்போது மனித அங்கீகாரம் மூலம் தணிக்கை செய்யப்பட வேண்டும்.