96% டோக்கன் சேமிப்பை நாங்கள் ஏன் நிராகரித்தோம்

96% டோக்கன்களைச் சேமிக்கும் ஒரு MCP சர்வரை நாங்கள் கண்டறிந்தோம். இது execute_code என்ற ஒரு கருவியைப் பயன்படுத்துகிறது. குறிப்பிட்ட செயல்பாடுகளை (functions) அழைப்பதற்குப் பதிலாக, தரவைப் பெற ஏஜென்ட் (agent) JavaScript-ஐ எழுதுகிறது.

காகித அளவில் பார்த்தால், இதுவே சிறந்தது. சிக்கலான பணிகளுக்கு, செயல்திறன் விஷயத்தில் கருவி அழைப்பை (tool-calling) விட குறியீடு இயக்கம் (code execution) மேலானது.

ஆனால் நாங்கள் அதை ஏற்றுக்கொள்ளவில்லை. அதற்குப் பதிலாக எங்களது தனித்துவமான, பெயரிடப்பட்ட கருவிகளையே (named tools) தொடர்ந்து பயன்படுத்தினோம்.

எங்களது ஏஜென்ட்டிற்கு அந்தத் தெளிவானத் தெரிவு ஏன் தவறான முடிவாக இருந்தது என்பதற்கான காரணங்கள் இதோ.

இலக்குதான் வடிவமைப்பைத் தீர்மானிக்கிறது

பெரும்பாலான மக்கள் சாட் விண்டோவில் (chat window) இயங்கும் frontier மாடல்களுக்காக உருவாக்குகிறார்கள். அந்த மாடல்களுக்குப் மிகப்பெரிய டோக்கன் வரம்புகள் (token budgets) உள்ளன. அவர்களுக்கு, குறியீடு இயக்கம் (code execution) தான் முதன்மையானது.

நாங்கள் ஒரு படகில் இயங்கும் சிறிய உள்ளூர் மாடலுக்கான (Hermes 3 8B) குரல் சார்ந்த ஏஜென்ட்டிற்காக (voice-first agent) உருவாக்குகிறோம்.

ஒரு சிறிய மாடலுக்கு, டோக்கன்கள் தடையல்ல. நம்பகத்தன்மை (reliability) தான் முக்கியத் தடை.

ஒரு சிறிய மாடல் ஒரு எளிய கருவியைக் கூட அழைப்பதில் சிரமப்பட்டால், அதற்குச் சரியான JavaScript-ஐ எழுதச் சொல்வது மிகவும் கடினமான காரியம். execute_code நம்பகத்தன்மையைக் குறைத்து டோக்கன்களைச் சேமிக்கிறது. அந்தத் தியாகத்தை எங்களால் செய்ய முடியாது.

கடைசி மைல் சிக்கல் (The Last-Mile Problem)

குறியீடு இயக்கம் வேலையின் "கடைசி மைல்" (last mile) பகுதியை ஏஜென்ட்டின் மீதே சுமத்துகிறது. ஏஜென்ட் செய்ய வேண்டியவை:

• தரவை வடிகட்ட வேண்டும் (Filter the data)
• முடிவுகளை வரிசைப்படுத்த வேண்டும் (Sort the results)
• வெளியீட்டை வடிவமைக்க வேண்டும் (Format the output)

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

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

தகவல் இல்லாமை விதி (The Absence Rule)

ஒரு படகில், சென்சார்கள் (sensors) ஆஃப்லைனில் செல்லக்கூடும். எங்களது அமைப்பில், ஒரு சென்சார் இல்லையென்றால் அது ஒரு தெளிவான null மதிப்பைக் கொடுக்கும். இது ஒரு வெற்றிகரமான அழைப்பாகக் கருதப்படுகிறது.

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

ஏற்றுக்கொள்வதா அல்லது உருவாக்குவதா? - சரிபார்ப்புப் பட்டியல் (Adopt-vs-Build Checklist)

நீங்கள் ஒரு MCP சர்வரை ஏற்றுக்கொள்வதற்கு அல்லது உருவாக்குவதற்கு முன், இந்தக் கேள்விகளைக் கேளுங்கள்:

• இலக்கு ஏஜென்ட் யார்? (Frontier மாடல் vs. சிறிய உள்ளூர் மாடல்) • முக்கியத் தடை எது? (டோக்கன்கள் vs. நம்பகத்தன்மை) • கடைசி மைல் வேலையை யார் செய்கிறார்கள்? (கருவி தரவை வடிவமைக்கிறதா அல்லது ஏஜென்ட் செய்கிறதா?) • தகவல் இல்லாமையை அது எப்படி கையாள்கிறது? (விடுபட்ட மதிப்பு ஒரு பிழையா அல்லது null-ஆ?) • பராமரிப்புச் செலவு என்ன? (நீங்கள் பயன்படாத ஒரு குறியீட்டுத் தொகுப்பை (codebase) பொறுப்பேற்கிறீர்களா?)

நாங்கள் அந்தத் திட்டத்தைப் புறக்கணிக்கவில்லை. அதன் யோசனைகளை நாங்கள் பயன்படுத்திக் கொண்டோம். அவர்களின் அலாரம் கையாளுதல் (alarm handling) மற்றும் பாதை கண்டறிதல் தர்க்கத்தை (path discovery logic) எடுத்து எங்களது திட்டப்பணியில் (roadmap) சேர்த்துக் கொண்டோம்.

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

Source: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

Optional learning community: https://t.me/GyaanSetuAi