आम्ही ९६% टोकन बचत का नाकारली

आम्हाला एक MCP server सापडला जो ९६% टोकन वाचवतो. तो एकच tool वापरतो: execute_code. विशिष्ट functions कॉल करण्याऐवजी, agent डेटा मिळवण्यासाठी JavaScript लिहितो.

कागदावर हे फायदेशीर वाटते. जटिल कामांसाठी, कार्यक्षमतेच्या बाबतीत code execution हे tool-calling पेक्षा सरस ठरते.

पण आम्ही ते स्वीकारले नाही. त्याऐवजी आम्ही आमचे स्वतंत्र, नावांकित (named) tools तसेच ठेवले.

आमच्या agent साठी तो स्पष्ट वाटणारा पर्याय चुकीचा का ठरला, याची ही कारणे आहेत.

लक्ष्य डिझाइन ठरवते

बहुतेक लोक चॅट विंडोमधील frontier models साठी सिस्टीम बनवतात. त्या models कडे टोकनचा मोठा कोटा असतो. त्यांच्यासाठी, code execution हे सर्वोत्तम असते.

आम्ही एका बोटीवर असलेल्या लहान local model (Hermes 3 8B) वर आधारित voice-first agent साठी काम करत आहोत.

लहान model साठी मर्यादा टोकन्सची नाही, तर विश्वासार्हतेची (reliability) आहे.

जर एखादे लहान model साधे tool कॉल करण्यातही अडखळत असेल, तर त्याला अचूक JavaScript लिहिण्यास सांगणे हे खूप कठीण काम आहे. execute_code विश्वासार्हतेच्या बदल्यात टोकन्स वाचवते. आम्ही अशी तडजोड करू शकत नाही.

'लास्ट-माइल' समस्या (The Last-Mile Problem)

Code execution कामाचा "last mile" भाग agent वर ढकलते. Agent ला खालील गोष्टी कराव्या लागतात:

• डेटा फिल्टर करणे
• निकाल सॉर्ट करणे
• आउटपुट फॉरमॅट करणे

आमचे tools हे काम server च्या आतच करतात. उदाहरणार्थ, बॅटरीच्या स्थितीबद्दल विचारल्यावर, आमचे tool text-to-speech साठी तयार असलेली string परत करते. ते कच्च्या आकड्यांऐवजी "६८ टक्के, १२.८ व्होल्ट्स" असे बोलते.

जर आम्ही execute_code वापरले, तर त्या संवादाला फॉरमॅट करण्यासाठी लागणारे logic agent ला लिहावे लागेल. लहान models यामध्ये वारंवार अपयशी ठरतात.

'अॅब्सन्स' नियम (The Absence Rule)

बोटीवर असताना, sensors ऑफलाइन जाऊ शकतात. आमच्या सिस्टीममध्ये, एखादा sensor उपलब्ध नसेल तर तो 'null' व्हॅल्यू परत करतो. हे एक यशस्वी कॉल मानले जाते.

Code execution मॉडेलमध्ये, एखादा sensor उपलब्ध नसल्यास अनेकदा error येतो. जर लहान model ने काही चुकीचे मार्ग निवडले, तर त्यामुळे error limits ओलांडल्या जातात आणि agent काम करणे थांबवतो. Named tools मुळे आम्हाला 'अभावी' (absence) ही गोष्ट दोष न मानता यश म्हणून हाताळता येते.

Adopt-vs-Build चेकलिस्ट

तुम्ही एखादा MCP server स्वीकारण्यापूर्वी किंवा तयार करण्यापूर्वी, हे प्रश्न स्वतःला विचारा:

• लक्ष्यित agent कोण आहे? (Frontier model विरुद्ध Small local model) • मुख्य मर्यादा काय आहे? (Tokens विरुद्ध Reliability) • 'last mile' चे काम कोण करते? (Tool डेटा फॉरमॅट करते की agent?) • ते 'absence' कशी हाताळते? (मिसिंग व्हॅल्यू म्हणजे error आहे की null?) • देखभालीचा खर्च (maintenance cost) किती आहे? (तुम्ही एखादा निष्क्रिय codebase स्वीकारत आहात का?)

आम्ही त्या दुसऱ्या प्रोजेक्टकडे दुर्लक्ष केले नाही. आम्ही त्यातून कल्पना घेतल्या. आम्ही त्यांचे alarm handling आणि path discovery logic घेतले आणि ते आमच्या roadmap मध्ये समाविष्ट केले.

कार्यक्षमता (Efficiency) चांगली आहे, पण जेव्हा तुम्ही पाण्यावर (बोटीवर) असता, तेव्हा विश्वासार्हता (reliability) आवश्यक असते.

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

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