LLM-கள் உங்கள் குறியீட்டிற்குள் (code) நுழையாது – அவை உங்களுக்கு ஒரு கோரிக்கையை (request) வழங்கும், நீங்கள் அந்தச் செயல்பாட்டை (function) இயக்க வேண்டும். "மாடல் தானாகவே எனது Python முறையை (routine) அழைக்கிறது" என்ற தவறான நம்பிக்கையை இந்த எளிய உண்மை மாற்றியமைக்கிறது, மேலும் பிழைத்திருத்தம் (debugging) மற்றும் பாதுகாப்பைப் பற்றி டெவலப்பர்கள் மறுபரிசீலனை செய்யத் தூண்டுகிறது.
டிஸ்பாட்ச் லூப் (dispatch loop), படிப்படியாக
ஒரு மொழி மாதிரி (LLM) ஒரு கருவியைத் தேவைப்படும்போது, அது ஒரு தீர்மானிக்கப்பட்ட வரிசையைப் பின்பற்றுகிறது:
- திட்டமிடுதல் (Planning) – ஒரு செயல் தேவை என்று மாடல் முடிவு செய்கிறது (எ.கா., "பணத்தைத் திரும்பப் பெறுதல்").
- கோரிக்கையை உருவாக்குதல் (Generating a request) – இது கருவியின் (tool) பெயர் மற்றும் வாதங்களை (arguments) வழங்கும் கட்டமைக்கப்பட்ட உரையை—பொதுவாக JSON—வெளியிடுகிறது.
- பகுப்பாய்வு (Parsing) – உங்கள் ஆப் அல்லது ஒரு துணை கட்டமைப்பானது (framework) அந்த உரையைப் படிக்கிறது.
- பொருத்துதல் (Matching) – நீங்கள் வெளிப்படுத்திய உண்மையான செயல்பாடுகளின் பதிவேட்டில் (registry) கட்டமைப்பானது அந்தப் பெயரைத் தேடுகிறது.
- சரிபார்த்தல் (Validating) – வாதங்கள் செயல்பாட்டின் ஸ்கீமாவிற்கு (schema) பொருந்துகின்றனவா என்பதையும், அழைப்பாளர் அங்கீகரிக்கப்பட்டவரா என்பதையும் இது சரிபார்க்கிறது.
- செயல்படுத்துதல் (Executing) – பொருத்தமான செயல்பாடு உங்கள் சூழலில் (environment) இயங்கி, வேலையைச் செய்கிறது.
- திரும்பப் பெறுதல் (Returning) – முடிவு தொகுக்கப்பட்டு, அடுத்தகட்ட சிந்தனைக்காக மாடலுக்குத் திருப்பி அனுப்பப்படுகிறது.
LLM-ஐ ஒரு திட்டமிடுபவராகவும் (planner), கட்டமைப்பை (framework) ஒரு விநியோகிப்பவராகவும் (dispatcher), மற்றும் செயல்பாட்டை (function) தரவு அல்லது பணத்தை உண்மையில் நகர்த்தும் ஒரு தொழிலாளியாகவும் கருதுங்கள்.
ஏன் இந்த "மந்திரம்" பற்றிய தவறான நம்பிக்கை நீடிக்கிறது
பெரும்பாலான டெவலப்பர்கள், ஒரு செயல்பாடு அழைப்பைப் (function call) போலவே தோற்றமளிக்கும் மாடலின் வெளியீட்டைப் பார்த்து, மாடலே அந்தச் செயல்பாட்டைச் செய்துவிட்டது என்று நினைத்துவிடுகிறார்கள். சேவை வழங்குநர்களின் (provider) ஆவணங்களில் உள்ள "tool calling" என்ற சொல், மாடல் நேரடியாகக் குறியீட்டை அழைப்பது போன்ற உணர்வைத் தருகிறது.
உண்மையில், மாடல் ஒரு அழைப்பை விவரிக்கும் உரையை மட்டுமே உருவாக்குகிறது. தேடுதல் (lookup), வகை சரிபார்ப்பு (type checking), அனுமதி அமலாக்கம் (permission enforcement) மற்றும் பிழை கையாளுதல் (error handling) போன்ற கடினமான வேலைகளை உங்கள் செயல்முறைதான் செய்கிறது.
உள் கட்டமைப்புகளை மறைக்கும் கட்டமைப்புகள் (Frameworks)
PydanticAI மற்றும் LangChain போன்ற லைப்ரரிகள் (libraries) இந்த லூப்பைத் தமதாக்குகின்றன (abstract), இதனால் நீங்கள் வணிகத் தர்க்கத்தில் (business logic) கவனம் செலுத்த முடியும். அவை தானாகவே:
- ஒரு ஸ்கீமாவுடன் (எ.கா., ஒரு Pydantic model) வாதங்களைச் சரிபார்க்கின்றன.
- அனுமதிகளை அமலாக்குகின்றன, பயனர் கருவியைத் தூண்ட முடியுமா என்பதை உறுதி செய்கின்றன.
- தோல்வியின் போது மீண்டும் முயற்சிக்கின்றன, ஒரு கருவி பிழையைத் திருப்பியனுப்பும்போது மீண்டும் மாடலுக்குச் செல்கின்றன.
- தொடர்ச்சியான லூப்களைத் தடுக்கின்றன, அடுத்தடுத்த கருவி அழைப்புகளுக்கு வரம்பு விதிக்கின்றன.
- உரையாடல் நிலையைப் பராமரிக்கின்றன, கருவி முடிவுகளை உரையாடலுடன் இணைக்கின்றன.
இந்த உதவியாளர்களுடன் கூட, முறை மாறாது: மாடல் ஒருபோதும் குறியீட்டைச் செயல்படுத்தாது.
சேவை வழங்குநர்களிடமிருந்து கிடைக்கும் நேரடி (Native) tool-calling ஆதரவு
சில சேவை வழங்குநர்கள் கருவி வரையறைகள் மற்றும் கோரிக்கை வடிவங்களைத் தரப்படுத்துகின்ற ஒரு "நேரடி" (native) tool-calling இடைமுகத்தை வழங்குகிறார்கள். இது ஒருங்கிணைப்பை எளிதாக்குகிறது, ஆனால் டிஸ்பாட்ச் (dispatch) படிநிலையை நீக்காது. கோரப்பட்ட செயல்பாட்டை உண்மையில் இயக்கும் குறியீட்டை நீங்கள் இன்னும் எழுத வேண்டும் (அல்லது இறக்குமதி செய்ய வேண்டும்).
சிக்கலுக்குப் பெயர் மாற்றும்போது பிழைத்திருத்தம் (Debugging) எளிதாகிறது
"குழப்பமடைந்த ஏஜென்ட்" (confused agent) என்று குறை கூறுவதற்குப் பதிலாக, "மாடல் பதிலில் எந்தத் கருவி அழைப்புகளும் இல்லை" என்று சொல்லுங்கள். இந்த வேறுபாடு முக்கியமானது:
- கருவி அழைப்பு இல்லை (No tool call) – மாடல் நேரடியாகப் பதிலளித்தது அல்லது சரியாக வடிவமைக்கப்பட்ட கோரிக்கையை உருவாக்கத் தவறிவிட்டது.
- தவறான கோரிக்கை (Malformed request) – JSON இலக்கண ரீதியாகத் தவறாக உள்ளது அல்லது தேவையான புலங்கள் விடுபட்டுள்ளன, எனவே டிஸ்பாட்சர் அதை நிராகரிக்கிறது.
- சரிபார்ப்புத் தோல்வி (Validation failure) – வாதங்கள் ஸ்கீமாவுடன் பொருந்தவில்லை, இது செயல்பாட்டிற்கு முன்பே பிழையைத் தூண்டுகிறது.
தோல்விகளை வகைப்படுத்துவதன் மூலம், லூப்பின் ஒவ்வொரு நிலையையும் பதிவு செய்யவும் (log), எங்கு தவறு நடந்தது என்பதைக் கண்டறியவும் முடியும்.
நம்பகமான பைப்லைனுக்கான (pipeline) நடைமுறை குறிப்புகள்
- மாடல் வெளியீட்டை நம்பகமற்ற உள்ளீடாகக் கருதுங்கள். எந்தவொரு பக்கவிளைவு ஏற்படுத்தும் (side-effecting) குறியீட்டையும் அழைப்பதற்கு முன், ஒவ்வொரு கோரிக்கையையும் தீர்மானிக்கப்பட்ட சரிபார்ப்பு (deterministic validation) மூலம் இயக்கவும்.
- மூலக் கோரிக்கையை (raw request) மற்றும் ஒவ்வொரு சரிபார்ப்புப் படிநிலையின் முடிவையும் பதிவு செய்யவும். இது ஏதேனும் தவறு நடக்கும்போது மீண்டும் சரிபார்க்கக்கூடிய ஒரு தடயத்தை உருவாக்குகிறது.
- அடுத்தடுத்த கருவி அழைப்புகளுக்குத் தெளிவான வரம்புகளை நிர்ணயிக்கவும்; ஒரு கட்டுப்பாடற்ற லூப் வளங்களைச் (resources) செலவழிக்கலாம் அல்லது விகித வரம்புகளை (rate limits) எட்டலாம்.
- ஒவ்வொரு செயல்பாட்டையும் ஒரு try/except பிளாக்கிற்குள் (block) வைக்கவும், இது மாடலால் புரிந்துகொள்ளக்கூடிய கட்டமைக்கப்பட்ட பிழைப் பொருளைத் (error object) திருப்பி அனுப்ப வேண்டும், இது மீண்டும் முயற்சி செய்ய அல்லது மென்மையான மாற்றத்திற்கு (graceful fallback) வழிவகுக்கும்.
- அனுமதிச் சரிபார்ப்புகளை வணிகத் தர்க்கத்திலிருந்து பிரிக்கவும். செயல்பாடு இயங்குவதற்கு முன் அழைப்பாளரின் உரிமைகளைச் சரிபார்க்கவும், குறிப்பாக "பயனரை நீக்குதல்" (delete user) போன்ற சிறப்புச் செயல்பாடுகளுக்கு.
- ஸ்கீமா சார்ந்த வரையறைகளைப் பயன்படுத்தவும் (எ.கா., Pydantic models), இதனால் மாடல் பின்பற்ற வேண்டிய JSON ஸ்கீமாவை கட்டமைப்பால் தானாகவே உருவாக்க முடியும்.
அடுத்து கவனிக்க வேண்டியவை
சேவை வழங்குநர்கள் நேரடி tool-calling API-களை மேம்படுத்தும்போது, கோரிக்கை வடிவங்கள் குறித்த கடுமையான ஒப்பந்தங்கள் மற்றும் விரிவான பிழை குறியீடுகளை எதிர்பார்க்கலாம். அந்த மாற்றங்கள் சரிபார்ப்பை எளிதாக்கும் மற்றும் டெவலப்பர்கள் கடுமையான பாதுகாப்பு வேலிகளை உருவாக்க உதவும். லைப்ரரி புதுப்பிப்புகளைக் கவனித்துக் கொண்டே இருங்கள்—பல லைப்ரரிகள் புதிய சேவை வழங்குநர் அம்சங்களுக்கான உள்ளமைக்கப்பட்ட ஆதரவைச் சேர்த்துக் கொண்டிருக்கின்றன.
முக்கியக் கருத்து (Takeaway)
LLM என்பது ஒரு மேம்பட்ட உரை உருவாக்கி மட்டுமே, அது செயல்களைச் செயல்படுத்தும் கருவி அல்ல. செயல்களைச் செய்யும் முதன்மையான அதிகாரம் உங்கள் குறியீட்டிற்கு மட்டுமே உண்டு; நீங்கள் உருவாக்கும் (அல்லது இறக்குமதி செய்யும்) dispatcher என்பது அந்தச் செயல்களைச் சரிபார்க்கும், அங்கீகரிக்கும் மற்றும் இயக்கும் ஒரு வாயிற்காவலராகச் செயல்படுகிறது. பணிப்பாய்வை (workflow) இவ்வாறு மறுசீரமைப்பது, "மந்திரம்" போன்ற மாயையான நம்பிக்கையை நீக்குகிறது, பிழைத்திருத்தத்தை (debugging) துல்லியமாக்குகிறது, மேலும் ஒவ்வொரு உற்பத்தி அமைப்பிற்கும் (production system) தேவையான பாதுகாப்பு ஒழுக்கத்தை நடைமுறைப்படுத்துகிறது.