உள்ளூர் பெரிய மொழி மாதிரிகளை (LLMs) பயன்படுத்தும் டெவலப்பர்கள், ஒரு பயனர் ஒரு தூண்டுதலை (prompt) தட்டச்சு செய்வதற்கு முன்பே, ஒரு ஒற்றை Multi-Channel-Protocol (MCP) சர்வர் முழு சூழல் சாளரத்தையும் (context window) ஆக்கிரமித்துவிடுவதைக் கண்டறிந்துள்ளனர். அவர்கள் குறைவான கருவி விளக்கங்களைத் தேர்ந்தெடுக்க வேண்டும் அல்லது சிதைந்த உரையாடல் ஓட்டத்தை ஏற்க வேண்டும் என்ற இக்கட்டான நிலையில் உள்ளனர்.

உள்ளூர் LLM-களுக்கு டோக்கன் வீக்கம் (token bloat) ஏன் முக்கியமானது

MCP ஒரு LLM-ஐ வெளிப்புறக் கருவிகளை—APIs, ஸ்கிரிப்ட்கள் அல்லது கோப்பு முறைமை பயன்பாடுகளை—அழைக்க அனுமதிக்கிறது; இதற்காக ஒவ்வொரு கருவியின் விளக்கத்தையும் மாடலுக்கு வழங்குகிறது. 128k-டோக்கன் சாளரம் கொண்ட கிளவுட் சார்ந்த மாதிரிகள் பல கருவி வரையறைகளை உள்வாங்கிக் கொள்ள முடியும், அதே நேரத்தில் பயனர் உரையாடலுக்கும் இடமிருக்கும். ஆனால் 8k-டோக்கன் சாளரத்துடன் உள்ளூர் முறையில் இயங்கும் 7-பில்லியன் அளவுரு (parameter) கொண்ட மாதிரி, சில கருவிகளை ஏற்றிய உடனேயே இடப்பற்றாக்குறையைச் சந்திக்கிறது. இதில் உள்ள சவால்கள் மிகத் தெளிவானவை: குறுகிய, மலிவான விளக்கங்கள் அழைப்புகளைத் தவறாக வழிநடத்தும்; நீண்ட, விரிவான விளக்கங்கள் உரையாடலுக்குத் தேவையான டோக்கன் வரம்பை நுகர்ந்துவிடும்.

இதற்குக் காரணமான நிகழ்வுகளின் சங்கிலித் தொடர்

பல தரவு ஆதாரங்களுக்கு ஒரு ஒற்றை, மாதிரி சார்ந்த இடைமுகத்தை (model-driven interface) வழங்குவதற்காகவும், தனிப்பயன் ஒருங்கிணைப்பு குறியீடுகளுக்கு (custom integration code) மாற்றாகவும் MCP உருவாக்கப்பட்டது. பெரும்பாலான MCP சர்வர்கள் மனித இயக்குபவர்களுக்காக உருவாக்கப்பட்ட REST endpoints-களின் மெல்லிய உறைகலங்களாகவே (thin wrappers) செயல்படுகின்றன, இயந்திரங்களுக்காக அல்ல. அந்த உறைகலங்கள் ஒரு உள்ளூர் LLM அமர்வுக்குள் வரும்போது, மாடல் எந்தக் கருவியைப் பயன்படுத்த வேண்டும் என்று முடிவு செய்வதற்கு முன், ஒவ்வொரு கருவியின் பெயர், அளவுருக்கள் (parameters) மற்றும் பயன்பாட்டு குறிப்புகளைப் படிக்க வேண்டியுள்ளது. சிறிய சூழல் சாளரங்கள் இந்த "விளக்கச் சுமையை" (description overhead) ஒரு கட்டமைப்புத் தடையாக மாற்றுகின்றன.

யார் வெற்றி பெறுகிறார்கள், யார் பாதிக்கப்படுகிறார்கள்

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

இதன் விலை வெறும் மோசமான அனுபவம் மட்டுமல்ல; இது பாதுகாப்பு கவலைகளையும் எழுப்புகிறது. ஒரு MCP ஏஜென்ட் எந்தவொரு உள்ளூர் கோப்பையும் படிக்க முடியும் போது, அனுமதி மாதிரி (permission model) "முழுமையாக அல்லது எதுவுமே இல்லை" என்ற நிலைக்குத் தள்ளப்படுகிறது. ஒரு சாண்ட்பாக்ஸ் (sandbox) இல்லையெனில், தவறாக உள்ளமைக்கப்பட்ட ஒரு கருவி முழு கோப்பு முறைமையையும் வெளிப்படுத்தக்கூடும்.

இதற்காக டெவலப்பர்கள் என்ன செய்கிறார்கள்

சமூகத்தில் மூன்று தீர்வுகள் ஆதிக்கம் செலுத்துகின்றன:

  • விளக்கங்களைக் குறைத்தல் (Trim descriptions) – கருவி மெட்டாடேட்டாவை மிகக் குறைந்த அளவிற்குக் குறைக்கின்றனர். இது டோக்கன்களை விடுவிக்கிறது, ஆனால் மாடல் தவறான கருவியைத் தேர்ந்தெடுக்கும் வாய்ப்பை அதிகரிக்கிறது, இது டெவலப்பர்கள் கண்டறிந்து மீண்டும் முயற்சிக்க வேண்டிய பிழைகளுக்கு வழிவகுக்கிறது.
  • டைனமிக் லோடிங் (Dynamic loading) – தற்போதைய உரையாடலுக்குத் தொடர்புடைய கருவிகளின் ஒரு பகுதியை மட்டும் ஏற்றுகின்றனர். பயனரின் நோக்கத்தின் அடிப்படையில், எந்தத் தொகுப்பைப் புகுத்த வேண்டும் என்பதை ஒரு இலகுரக டிஸ்பாட்சர் (dispatcher) தீர்மானிக்கிறது. இது தேவையற்ற டோக்கன் பயன்பாட்டைக் குறைக்கிறது, ஆனால் தாமதத்தையும் (latency) குறியீட்டு சிக்கலையும் சேர்க்கிறது.
  • செயலில் உள்ள சர்வர்களின் எண்ணிக்கையைக் கட்டுப்படுத்துதல் (Limit active servers) – ஒரு அமர்வுக்கு ஒரு குறிப்பிட்ட எண்ணிக்கையிலான MCP சர்வர்களை மட்டுமே அனுமதிக்கின்றனர், இது டெவலப்பர்கள் மிக முக்கியமான ஒருங்கிணைப்புகளுக்கு முன்னுரிமை அளிக்கக் கட்டாயப்படுத்துகிறது. இது தூண்டுதல் அளவை நிர்வகிக்கக்கூடியதாக வைத்திருக்கிறது, ஆனால் திறன்களின் பரப்பளவைச் சமரசம் செய்கிறது.

இந்தத் தீர்வுகளில் எதுவுமே ஒரு மந்திரக்கோல் (silver bullet) அல்ல. விளக்கங்களைக் குறைப்பது நம்பகத்தன்மையைப் பாதிக்கிறது; டைனமிக் லோடிங் பதில்களைத் தாமதப்படுத்தும் ஒரு முடிவெடுக்கும் அடுக்கைச் சேர்க்கிறது; சர்வர்களைக் கட்டுப்படுத்துவது எந்தத் தரவு ஆதாரங்களை ஆதரிப்பது என்பது குறித்த கடினமான முடிவுகளை எடுக்கத் தூண்டுகிறது.

டோக்கன் சிக்கலுடன் தொடர்புடைய பாதுகாப்பு அபாயங்கள்

உள்ளூர் ஏஜெண்டுகள் பெரும்பாலும் கட்டுப்பாடற்ற கோப்பு முறைமை அணுகலுடன் இயங்குகின்றன. "இந்த ஃபோல்டரைப் படி" மற்றும் "அனைத்தையும் படி" ஆகியவற்றிற்கு இடையே MCP நெறிமுறை எந்தத் தெளிவான பிரிவினையும் (granularity) வழங்கவில்லை. சில குழுக்கள் இந்த முழு-அணுகல் சிக்கலைச் சரிசெய்ய கேட்வே அடுக்குகளை (gateway layers) உருவாக்கியுள்ளனர், இது கூடுதல் சிக்கலைச் சேர்க்கிறது. அந்த கேட்வேகள் "முழுக்கட்டுப்பாட்டு" சிக்கலைக் குறைத்தாலும், குறியீட்டுத் தளத்தையும் (code base) அதிகரிக்கின்றன.

சிறிய மாதிரிகளுக்கான கருவிகளை வடிவமைத்தல்

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

  • குறுகிய செயல்பாட்டுத் திறன் (Narrow functionality) – ஒவ்வொரு கருவியும் ஒரு வேலையை மட்டுமே செய்ய வேண்டும். ஒரு "தேடல்" (search) கருவி கோப்புகளை எழுதவும் முயன்றால், ஒன்றுடன் ஒன்று மேலோங்கும் பொறுப்புகளைக் கையாள முடியாத மாடல் குழப்பமடையும்.
  • தெளிவற்ற பெயரிடல் (Unambiguous naming) – "process" அல்லது "handle" போன்ற பொதுவான பெயர்களைத் தவிர்க்கவும். பெயர்கள் துல்லியமான செயல்பாட்டைத் தெரிவிக்க வேண்டும், இது மாடலின் பணிச்சுமையைக் குறைக்கும்.
  • தெளிவான, சுருக்கமான விளக்கங்கள் (Clear, concise descriptions) – மாடல் முடிவெடுக்க உண்மையிலேயே தேவைப்படும் அளவுருக்களை மட்டுமே சேர்க்கவும். மாடல் வடிவங்களை விரைவாக அடையாளம் காணும் வகையில் ஒரு நிலையான வடிவமைப்பைப் பயன்படுத்தவும்.

முரண்பட்ட கருத்து: இந்த நெறிமுறை இன்னும் மதிப்புமிக்கது

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

முக்கியக் கருத்து

நீங்கள் ஒரு on-device assistant-ஐ உருவாக்குகிறீர்கள் என்றால், MCP tool விளக்கங்களை ஒரு வரையறுக்கப்பட்ட வளமாக (scarce resource) கருதுங்கள். உண்மையான உரையாடலுக்கான context window-வைச் செயல்பாட்டில் வைத்திருக்க, அவற்றைச் சுருக்கவும், தேவைக்கேற்ப ஏற்றவும் (load dynamically), மற்றும் குறுகிய எல்லை கொண்ட கருவிகளை (narrowly scoped tools) வடிவமைக்கவும். அதே நேரத்தில், சில கூடுதல் tokens செலவானாலும், ஒரு அனுமதி அடுக்கை (permission layer) இணைப்பதன் மூலம், மறைமுகமான "முழு அணுகல்" (full-access) பாதுகாப்பு மாதிரியிலிருந்து பாதுகாக்கவும். நீங்கள் பேணும் இந்தச் சமநிலையே, உங்கள் local LLM ஒரு பயனுள்ள துணையாக இருக்குமா அல்லது ஒரு பழுதான chatbot-ஆக இருக்குமா என்பதைத் தீர்மானிக்கும்.