LLM API அடிப்படைகள்: கோரிக்கை, பதில் மற்றும் செய்திப் பாத்திரங்கள்

ஆதாயங்கள்:

• LLM API கோரிக்கையின் அடிப்படை கட்டமைப்பை விவரிக்க முடியும் (இறுதிப்பு, மாதிரி, செய்திகள், max_tokens)
• கணினி, பயனர் மற்றும் உதவியாளர் பாத்திரங்கள் மற்றும் நிலையற்ற உரையாடல் வரலாறு ஆகியவற்றுக்கு இடையேயான வேறுபாட்டைப் புரிந்துகொள்கிறது
• திரும்பிய பதிலின் புலங்களை (உள்ளடக்கத் தொகுதிகள், நிறுத்த_காரணம், பயன்பாடு) படித்து விளக்கலாம்

முந்தைய தொகுதிகளில், அரட்டை சாளரத்தில் இருந்து செயற்கை நுண்ணறிவைப் பயன்படுத்தினோம். ஆனால் உங்கள் சொந்த தயாரிப்பு, ஆட்டோமேஷன் அல்லது பணிப்பாய்வு ஆகியவற்றில் AI ஐ உட்பொதிக்க விரும்பினால், அரட்டை இடைமுகம் அதைக் குறைக்காது; நீங்கள் மாதிரியுடன் நிரல் ரீதியாக இணைக்க வேண்டும், அதாவது குறியீடு அல்லது ஆட்டோமேஷன் கருவி. இந்த பாலத்தின் பெயர் API (Application Programming Interface, இரண்டு மென்பொருட்கள் சில விதிகளுடன் பேச அனுமதிக்கும் ஒப்பந்தம்). இந்த யூனிட்டை நீங்கள் முடிக்கும்போது, ​​எல்எல்எம் (பெரிய மொழி மாதிரி) ஏபிஐ கோரிக்கை என்ன, செய்திப் பாத்திரங்கள் என்ன செய்கின்றன, பதிலை எவ்வாறு படிப்பது என்பதை நீங்கள் அறிவீர்கள். மீதமுள்ள தொகுதி கட்டப்படும் அடித்தளம் இதுதான்.

API எவ்வாறு வேலை செய்கிறது?

API இன் அடிப்படை ஓட்டம் இதுதான்: நீங்கள் ஒரு குறிப்பிட்ட வடிவத்தில் கோரிக்கையை அனுப்புகிறீர்கள்; சேவையகம் ஒரு குறிப்பிட்ட வடிவத்தில் பதிலை வழங்குகிறது. LLMகளில், இது பொதுவாக HTTP அழைப்பு (HTTP: இணையத்தில் கோரிக்கை-பதில்களை எடுத்துச் செல்வதற்கான நிலையான நெறிமுறை) ஒரு முகவரிக்கு (இறுதிப்புள்ளி, உங்கள் கோரிக்கையைக் கையாளும் சர்வரில் உள்ள நிலையான முகவரி). எடுத்துக்காட்டாக, ஒரு செய்தியிடல் API இல், எல்லா கோரிக்கைகளும் ஒரே முகவரிக்குச் சென்று உடலில் JSON (ஜாவாஸ்கிரிப்ட் ஆப்ஜெக்ட் நோட்டேஷன் — மனிதர்கள் மற்றும் இயந்திரங்கள் இருவரும் படிக்கக்கூடிய விசை/மதிப்பு ஜோடிகளைக் கொண்ட உரை வடிவம்) என எடுத்துச் செல்லப்படும்.

கோரிக்கையில், குறைந்தபட்சம் இந்த மூன்று விஷயங்களைக் குறிப்பிடவும்:

• மாடல்: எந்த மாதிரியை நீங்கள் பயன்படுத்துவீர்கள் (எ.கா. வேகமான மற்றும் மலிவான மாடல் அல்லது சக்திவாய்ந்த மாடல்).
• max_tokens: மாடல் உருவாக்கக்கூடிய அதிகபட்ச எண்ணிக்கை டோக்கன்கள் (உரை செயலாக்கப்படும் மிகச்சிறிய அலகு, அடுத்த யூனிட்டில் விரிவாக செயலாக்கப்படும்); அதாவது வெளியீடு வரம்பு.
• செய்திகள்: உரையாடலை உருவாக்கும் செய்திகளின் பட்டியல்.

படிப்படியாக: கோரிக்கையை எவ்வாறு அமைப்பது

1. இறுதிப்புள்ளி மற்றும் சான்றுகளைத் தயாரிக்கவும். தலைப்பில் உள்ள கோரிக்கையில் உங்கள் API விசையை (உங்கள் அடையாளத்தை நிரூபிக்கும் ரகசிய சரம்) சேர்க்கிறீர்கள். குறியீட்டில் நீங்கள் ஒருபோதும் விசையை உட்பொதிக்கவில்லை; யூனிட் 9 இல் பாதுகாப்பான சேமிப்பகத்தை நாங்கள் காப்போம்.
2. மாதிரி மற்றும் வெளியீட்டு வரம்பை தேர்ந்தெடுக்கவும். இலகுரக மாடல் + ஒரு எளிய பணிக்கான சிறிய max_tokens; சக்திவாய்ந்த மாடல் + சிக்கலான பணிக்கான பெரிய வரம்பு.
3. செய்தி பட்டியலை அமைக்கவும். List the system instruction, user message, and past rounds (if any).
4. கோரிக்கையை அனுப்பி பதிலை அலசவும். திரும்பிய JSON இலிருந்து உரை உள்ளடக்கத்தைப் படிக்கவும், காரணத்தை நிறுத்தவும் மற்றும் டோக்கன் பயன்பாடு.

செய்தி பாத்திரங்கள்: கணினி, பயனர், உதவியாளர்

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

பங்கு

யார் எழுதுகிறார்கள்

நோக்கம்

அமைப்பு

டெவலப்பர்/ஆபரேட்டர்

முழு உரையாடல் முழுவதும் பொருந்தும் நிரந்தர அறிவுறுத்தல்கள், ஆளுமை மற்றும் விதிகள்

பயனர்

இறுதி பயனர்

பயனரின் தற்போதைய கேள்வி அல்லது உள்ளீடு

உதவியாளர்

மாதிரி

மாதிரியால் உருவாக்கப்பட்ட பதில் (மற்றும் முந்தைய பதில்கள்)

பெரும்பாலான வழங்குநர்களில் கோரிக்கை அமைப்பில் கணினி பங்கு ஒரு தனி கணினி புலமாக கிடைக்கிறது; பயனர் மற்றும் உதவியாளர் செய்திகள் பட்டியலில் வரிசையாக பட்டியலிடப்பட்டுள்ளனர். Critical point: the system instruction is the high-level instruction, the user message is the request to be answered at that moment.

{ "model": "claude-opus-4-8", "max_tokens": 1024, "system": "நீங்கள் ஒரு கார்ப்பரேட் ஆதரவு உதவியாளர். சுருக்கமான, முறையான மற்றும் சரிபார்க்கப்பட்ட பதிலைக் கொடுங்கள். உங்களுக்கு உறுதியாகத் தெரியாத தகவலை உருவாக்க வேண்டாம்.", "செய்திகள்": [ { "role": "பயனர்": "எனது செயல்முறையைத் தொடங்குவது?" } ]}

பேச்சு நிலையற்றது

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

{ "model": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "Hello, my name is Deniz." }, { "role": "உதவியாளர்", "content": "வணக்கம் டெனிஸ், நான் உங்களுக்கு எப்படி உதவுவது?" }, { "role": "user", "content": "நான் என் பெயரைச் சொன்னேன், உங்களுக்கு நினைவிருக்கிறதா?" } ]}

மூன்றாவது செய்திக்கு சரியாக பதிலளிப்பது முந்தைய இரண்டு செய்திகளையும் நீங்கள் அனுப்புவதைப் பொறுத்தது. அனுப்பாவிட்டால் "கடல்" மாதிரி தெரியாமல் தப்பாக பதில் சொல்லும். இது நேரடியாக செலவை பாதிக்கிறது: நீண்ட உரையாடல், பெரிய பட்டியல், ஒவ்வொரு கோரிக்கையும் அதிக டோக்கன்களை உட்கொள்ளும்.

உதவிக்குறிப்பு: நீண்ட உரையாடல்களில், முழு வரலாற்றையும் அனுப்புவதற்குப் பதிலாக பழைய சுற்றுகளை (சுருக்கம் + கடைசி சில சுற்றுகள்) சுருக்கி நகர்த்துவது செலவைக் குறைக்கிறது மற்றும் சூழல் சாளரத்தைப் பாதுகாக்கிறது. இதை 6 மற்றும் 11 அலகுகளில் ஆழப்படுத்துவோம்.

பதிலைப் படியுங்கள்

மாதிரி ஒரு பதிலை அளிக்கும் போது, நீங்கள் ஒரு கட்டமைக்கப்பட்ட பொருளைப் பெறுவீர்கள், சாதாரண உரை அல்ல. வழக்கமான பகுதிகள்:

{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "assistant", "content": [ { "type": "text", "text": "Return ஐத் தொடங்க, உங்கள் கணக்கில் உள்ள 'My Orders' பக்கத்திற்குச் செல்லவும்..." {{101}} , "stopend_rea:" "input_tokens": 47, "output_tokens": 88 }}

• உள்ளடக்கம்: பதில் தன்னை; இது உள்ளடக்கத் தொகுதிகளின் பட்டியல். உரைத் தொகுதியின் உரை புலம் உண்மையான பதில்.
• நிறுத்த_காரணம்: மாடல் ஏன் நிறுத்தப்பட்டது. முடிவு_திருப்பு = இயற்கை முடிவு; max_tokens = வெளியீட்டு வரம்பில் சிக்கியது (பதில் முழுமையடையாமல் இருக்கலாம்); மறுப்பு = பாதுகாப்பு காரணங்களுக்காக மறுப்பு. உங்கள் குறியீடு எப்போதும் stop_reason ஐ முதலில் பார்க்க வேண்டும்.
• பயன்பாடு: உள்ளீடு மற்றும் வெளியீடு டோக்கன் எண்கள். இது செலவு மற்றும் வரம்பு கண்காணிப்பின் அடிப்படையாகும்.

கவனம்: stop_reason அதிகபட்சம்_டோக்கன்கள் எனில், பதில் முடிக்கப்படவில்லை. இதை "வெற்றிகரமான பதில்" எனக் கருதி, பயனருக்கு பாதி உரையைக் காட்டுவது தயாரிப்பில் மிகவும் பொதுவான தவறுகளில் ஒன்றாகும். max_tokens ஐ அதிகரிக்கவும் அல்லது ஸ்ட்ரீமிங்கைப் பயன்படுத்தவும்.

பலவீனமான வரியில் / வலுவான வரியில்

இரண்டு வெவ்வேறு கணினி அறிவுறுத்தல்களுடன் ஒரே பணி:

# பலவீனமான நீங்கள் ஒரு உதவியாளர். கேள்விகளுக்கு பதிலளிக்கவும்.

# STRONGநீங்கள் கார்ப்பரேட் ஆதரவு உதவியாளர். விதிகள்:- வழங்கப்பட்ட கொள்கை ஆவணத்தில் உள்ள தகவலை மட்டுமே நம்புங்கள்; இது ஆவணத்தில் இல்லை என்றால், "இந்தத் தகவல் என்னிடம் இல்லை, நான் அதை தொடர்புடைய பிரிவுக்கு அனுப்புகிறேன்" என்று சொல்லுங்கள். - பதில்கள் 3 வாக்கியங்களுக்கு மிகாமல் இருக்க வேண்டும், முறையாகவும் தெளிவாகவும் இருக்க வேண்டும். - தனிப்பட்ட தரவை (TC ஐடி எண், கார்டு எண்) கேட்க வேண்டாம் மற்றும் மீண்டும் செய்ய வேண்டாம். - நீங்கள் உறுதியாக தெரியாத போது யூகிக்க வேண்டாம்.

சக்திவாய்ந்த பதிப்பு; இது நோக்கம், வடிவம், பாதுகாப்பு விளிம்பு மற்றும் நிச்சயமற்ற நடத்தை ஆகியவற்றை வரையறுக்கிறது. மாடல் வெளியீட்டின் நிலைத்தன்மை இந்த தெளிவிலிருந்து நேரடியாக வருகிறது.

மூன்று சிறிய வழக்குகள்

வழக்கு 1 - ஆதரவு பாட் (நிலையற்ற பொறி). ஒரு இ-காமர்ஸ் குழு இந்த போட்டை நேரலையில் எடுத்தது; "முந்தைய ஆர்டரை ரத்து செய்" என்று பயனர் கூறியதும், ஆர்டர் எண்ணை போட் "மறந்து விட்டது". காரணம்: அவர்கள் ஒவ்வொரு கோரிக்கையையும் கடைசி செய்தியுடன் மட்டுமே அனுப்புகிறார்கள். தீர்வு: அவர்கள் கடைசி 6 சுற்றுகளை செய்திகள் பட்டியலில் சேர்த்துள்ளனர். முடிவு: சூழல் பாதுகாக்கப்படுகிறது, ஆனால் ஒரு கோரிக்கைக்கான உள்ளீடு 40 டோக்கன்களில் இருந்து ~600 டோக்கன்களாக அதிகரித்துள்ளது - யூனிட் 2 இல் செலவு பாடத்தை நாங்கள் காண்போம்.

வழக்கு 2 - முழுமையற்ற ஒப்பந்தச் சுருக்கம். ஒரு சட்டக் குழு 10 பக்க ஒப்பந்தங்களை கோடிட்டுக் காட்டியது; அதிகபட்சம்_டோக்கன்கள்: 300 குறைவாக இருந்தது, சுருக்கங்கள் வாக்கியத்தின் நடுப்பகுதியை வெட்டுகின்றன. நிறுத்த_காரணம் ஒவ்வொரு முறையும் அதிகபட்ச_டோக்கன்கள் ஆனால் யாரும் பார்க்கவில்லை. அதிகபட்ச_டோக்கன்களை 1500 ஆக உயர்த்தியது மற்றும் நிறுத்த_காரணத்தை சரிபார்த்தது; துண்டிக்கப்பட்ட சுருக்க விகிதம் 18% இலிருந்து 0% ஆக குறைந்தது.

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

பொதுவான தவறுகள்

• கடந்த காலத்தை அனுப்ப மறந்துவிட்டது: மாதிரி "நினைவில் இல்லை" என்று கருதப்படுகிறது; அதேசமயம் அது நிலையற்றது. நீங்கள் சூழலைக் கொண்டு செல்கிறீர்கள்.
• `stop_reason` ஐப் பார்க்கவில்லை: max_tokens உடன் நிறுத்தப்பட்ட பதில் முழுமையானதாகக் கருதப்படுகிறது.
• `பயனர்` இல் அறிவுறுத்தலை உட்பொதித்தல்: அமைப்பில் நிலையான விதிகள்; உடனடி உள்ளீடு பயனருக்கு செல்கிறது. கலவை பாதுகாப்பு குறைபாடுகளை உருவாக்குகிறது.
• `உள்ளடக்கத்தை` ஒரு எளிய சரம் என்று தவறாகப் புரிந்துகொள்வது: பதில் தொகுதிகளின் பட்டியல்; முதல் உரைத் தொகுதியின் உரைப் புலத்தைப் படித்து, குருட்டுக் குறியீட்டுடன் உள்ளடக்கத்தைப்[0] பெறுவதற்கு முன் அதன் வகையைச் சரிபார்க்கவும்.
• குறியீட்டில் விசையை உட்பொதித்தல்: சூழல் மாறியைப் பயன்படுத்தவும் (அலகு 9).

ஆழமானது: உள்ளடக்கத் தொகுதிகள் மற்றும் பல பகுதி பதில்கள்

பதிலில் உள்ள உள்ளடக்கப் புலம் ஏன் பட்டியலானது என்பதைப் புரிந்துகொள்வது, நீங்கள் பின்னர் சந்திக்கும் மேம்பட்ட அம்சங்களுக்கு அடிப்படையாகும். சில நேரங்களில் மாதிரியானது உரையின் ஒரு தொகுதியை அல்ல, ஆனால் பல தொகுதிகளை வழங்குகிறது: சிந்தனையின் ஒரு தொகுதி, அதைத் தொடர்ந்து உரையின் தொகுதி; அல்லது உரையின் தொகுதியைத் தொடர்ந்து ஒரு கருவி பயன்பாட்டுத் தொகுதி. அதனால்தான் கண்மூடித்தனமாக உள்ளடக்கத்தை[0] "பதில்" என்று எண்ணுவது பலவீனமானது. பட்டியலைச் சென்று வகையின்படி வரிசைப்படுத்துவதே சரியான அணுகுமுறை: உரை வகைப் புலம் உள்ள தொகுதிகளின் உரை உள்ளடக்கத்தை நீங்கள் சேகரித்து, மற்ற வகைகளை (சிந்தனை, கருவி) தனித்தனியாகக் கருதுகிறீர்கள்.

நடைமுறையில் இந்த வேறுபாடு என்னவெனில், நீங்கள் மாதிரியின் நியாயத்தை (ஏதேனும் இருந்தால்) பயனருக்கு வெளிப்படுத்தாமல் பதிவு செய்யலாம், கருவி அழைப்புகளை தனித்தனி தர்க்கத்திற்கு திருப்பிவிடலாம் மற்றும் உண்மையான பதிலை திரையில் மட்டுமே அச்சிடலாம். தொகுதி முன்னேறும் போது (குறிப்பாக அலகுகள் 4 மற்றும் 11 இல்) இந்த தொகுதி அமைப்பு வெளியீட்டை சரிபார்ப்பதற்கும் இயக்குவதற்கும் எவ்வளவு பயனுள்ளதாக இருக்கும் என்பதை நீங்கள் காண்பீர்கள்.

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

சுருக்கமாக

ஒரு LLM API கோரிக்கை மாதிரி, வெளியீடு வரம்பு மற்றும் செய்தி பட்டியல் ஆகியவற்றைக் கொண்டுள்ளது; பாத்திரங்கள் (அமைப்பு, பயனர், உதவியாளர்) மாதிரியின் நடத்தையை தீர்மானிக்கிறது. அழைப்புகள் நிலையற்றவை: ஒவ்வொரு கோரிக்கையிலும் நீங்கள் சூழலைக் கொண்டு செல்கிறீர்கள். பதில் ஒரு கட்டமைக்கப்பட்ட பொருள்; உள்ளடக்கத்தைப் படித்தல் மற்றும் விளக்குவது, நிறுத்த_காரணம் மற்றும் பயன்பாட்டுப் புலங்கள் உற்பத்தியில் நீடித்து நிலைத்திருக்கும் அடிப்படையாகும்.

விண்ணப்ப பணி

உங்கள் சொந்த தொழிலில் இருந்து ஒரு பணியைத் தேர்ந்தெடுக்கவும் (எ.கா. உள்வரும் மின்னஞ்சலை வரிசைப்படுத்துதல், சுருக்கமான சுருக்கங்களை உருவாக்குதல்). ஒரு துண்டு காகிதத்தில்: (1) 4-5 விதிகளுடன் கணினி வரியில் எழுதவும், (2) மாதிரி பயனர் செய்தி மற்றும் 2-சுற்று வரலாற்றை அமைக்கவும், (3) max_tokens க்கான நியாயமான மதிப்பைத் தீர்மானித்து நியாயப்படுத்தவும், (4) திரும்பிய பதிலில் நீங்கள் கையாளும் stop_reason மதிப்புகளை பட்டியலிடுங்கள்.

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

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