మేము 96% టోకెన్ల ఆదాను ఎందుకు తిరస్కరించాము

టోకెన్ల విషయంలో 96% ఆదా చేసే ఒక MCP సర్వర్‌ను మేము కనుగొన్నాము. ఇది ఒకే ఒక టూల్‌ను ఉపయోగిస్తుంది: execute_code. నిర్దిష్ట ఫంక్షన్‌లను పిలవడానికి బదులుగా, ఏజెంట్ డేటాను పొందడానికి JavaScript రాస్తుంది.

కాగితం మీద చూస్తే, ఇది గెలుస్తుంది. సంక్లిష్టమైన పనుల కోసం, సామర్థ్యం (efficiency) పరంగా కోడ్ ఎగ్జిక్యూషన్, టూల్-కాలింగ్‌ను మించిపోతుంది.

కానీ మేము దానిని స్వీకరించలేదు. దానికి బదులుగా మా ప్రత్యేకమైన, పేరున్న టూల్స్‌నే (named tools) ఉంచుకున్నాము.

మా ఏజెంట్‌కు స్పష్టంగా కనిపించిన ఆ ఎంపిక ఎందుకు తప్పుగా మారిందో ఇక్కడ ఉంది.

లక్ష్యమే డిజైన్‌ను నిర్ణయిస్తుంది

చాలా మంది చాట్ విండోలో ఉండే ఫ్రాంటియర్ మోడల్స్ (frontier models) కోసం నిర్మిస్తారు. ఆ మోడల్స్‌కు భారీ టోకెన్ బడ్జెట్‌లు ఉంటాయి. వాటికి కోడ్ ఎగ్జిక్యూషన్ అనేది అత్యుత్తమమైనది.

మేము ఒక పడవలో ఉండే చిన్న లోకల్ మోడల్ (Hermes 3 8B) పై ఆధారపడిన వాయిస్-ఫస్ట్ ఏజెంట్ కోసం నిర్మిస్తున్నాము.

ఒక చిన్న మోడల్‌కు, పరిమితి టోకెన్లు కాదు. పరిమితి విశ్వసనీయత (reliability).

ఒక చిన్న మోడల్ ఒక సాధారణ టూల్‌ను పిలవడానికి కూడా ఇబ్బంది పడుతుంటే, దానికి సరైన JavaScript రాయమని అడగడం అనేది చాలా కష్టమైన పని. execute_code విశ్వసనీయతను టోకెన్ల కోసం వదులుకుంటుంది. మేము ఆ లాభనష్టాల బేరానికి వెళ్లలేము.

లాస్ట్-మైల్ సమస్య (The Last-Mile Problem)

కోడ్ ఎగ్జిక్యూషన్ పనుల యొక్క "చివరి దశ"ను (last mile) ఏజెంట్‌పైకి నెట్టేస్తుంది. ఏజెంట్ ఈ క్రింది పనులు చేయాలి:

  • డేటాను ఫిల్టర్ చేయడం
  • ఫలితాలను క్రమబద్ధీకరించడం (sort)
  • అవుట్‌పుట్‌ను ఫార్మాట్ చేయడం

మా టూల్స్ ఈ పనిని సర్వర్ లోపలే చేస్తాయి. ఉదాహరణకు, బ్యాటరీ స్థితి గురించి అడిగినప్పుడు, మా టూల్ టెక్స్ట్-టు-స్పీచ్ కోసం సిద్ధంగా ఉన్న స్ట్రింగ్‌ను తిరిగి ఇస్తుంది. ఇది కేవలం నంబర్ల కంటే "68 శాతం, 12.8 వోల్టులు" అని చెబుతుంది.

మేము execute_code ఉపయోగిస్తే, ఆ మాటలను ఫార్మాట్ చేయడానికి ఏజెంట్ లాజిక్‌ను రాయాల్సి ఉంటుంది. చిన్న మోడల్స్ ఈ విషయంలో నిరంతరం విఫలమవుతాయి.

అబ్సెన్స్ రూల్ (The Absence Rule)

పడవలో సెన్సార్లు ఆఫ్‌లైన్‌లోకి వెళ్తుంటాయి. మా సిస్టమ్‌లో, ఒక సెన్సార్ అందుబాటులో లేకపోతే అది క్లీన్ nullను తిరిగి ఇస్తుంది. ఇది ఒక విజయవంతమైన కాల్ (successful call).

కోడ్ ఎగ్జిక్యూషన్ మోడల్‌లో, సెన్సార్ లేకపోతే తరచుగా ఎర్రర్ వస్తుంది. ఒక చిన్న మోడల్ కొన్ని తప్పుడు మార్గాలను ఊహించినట్లయితే, అది ఎర్రర్ పరిమితులను దాటి ఏజెంట్‌ను దెబ్బతీస్తుంది. పేరున్న టూల్స్ (Named tools) ద్వారా మేము లోపాన్ని కాకుండా, సెన్సార్ లేకపోవడాన్ని కూడా ఒక విజయవంతమైన ఫలితంగా చూపించగలుగుతున్నాము.

అడాప్ట్-వర్సెస్-బిల్డ్ చెక్‌లిస్ట్ (Adopt-vs-Build Checklist)

మీరు ఒక MCP సర్వర్‌ను స్వీకరించే ముందు లేదా నిర్మించే ముందు, ఈ ప్రశ్నలను అడగండి:

• లక్ష్య ఏజెంట్ ఎవరు? (Frontier model vs. Small local model) • ప్రధాన పరిమితి ఏమిటి? (Tokens vs. Reliability) • చివరి దశ పనిని ఎవరు చేస్తారు? (టూల్ డేటాను ఫార్మాట్ చేస్తుందా లేదా ఏజెంట్ చేస్తుందా?) • లోపించిన విలువను (absence) అది ఎలా హ్యాండిల్ చేస్తుంది? (అందుబాటులో లేని విలువ ఎర్రరా లేక null ఆ?) • నిర్వహణ ఖర్చు (maintenance cost) ఎంత? (మీరు ఉపయోగించని పాత కోడ్‌బేస్‌ను వాడుతున్నారా?)

మేము ఆ ఇతర ప్రాజెక్ట్‌ను విస్మరించలేదు. దాని నుండి ఆలోచనలను సేకరించాము. వారి అలారం హ్యాండ్లింగ్ మరియు పాత్ డిస్కవరీ లాజిక్‌ను తీసుకుని మా రోడ్‌మ్యాప్‌కు జోడించాము.

సామర్థ్యం (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