എന്തുകൊണ്ടാണ് ഞങ്ങൾ 96% ടോക്കൺ ലാഭിക്കുന്ന രീതി നിരസിച്ചത്

96% ടോക്കണുകൾ ലാഭിക്കുന്ന ഒരു MCP സെർവർ ഞങ്ങൾ കണ്ടെത്തി. ഇത് execute_code എന്ന ഒരു ടൂൾ മാത്രമാണ് ഉപയോഗിക്കുന്നത്. പ്രത്യേക ഫംഗ്ഷനുകൾ വിളിക്കുന്നതിന് പകരം, ഡാറ്റ ലഭിക്കുന്നതിനായി ഏജന്റ് ജാവാസ്ക്രിപ്റ്റ് (JavaScript) എഴുതുന്നു.

കാണാൻ ഇത് മികച്ചതായി തോന്നാം. സങ്കീർണ്ണമായ ജോലികൾക്ക്, കാര്യക്ഷമതയുടെ കാര്യത്തിൽ ടൂൾ-കോളിംഗിനേക്കാൾ മികച്ചതാണ് കോഡ് എക്സിക്യൂഷൻ (code execution).

എന്നാൽ ഞങ്ങൾ അത് സ്വീകരിച്ചില്ല. പകരം ഞങ്ങളുടെ പ്രത്യേകമായ, പേരുള്ള ടൂളുകൾ തന്നെ നിലനിർത്തി.

എന്തുകൊണ്ടാണ് എല്ലാവർക്കും തോന്നുന്ന ആ തിരഞ്ഞെടുപ്പ് ഞങ്ങളുടെ ഏജന്റിന് തെറ്റായ ഒന്നായി മാറിയതെന്ന് താഴെ നൽകുന്നു.

ലക്ഷ്യമാണ് ഡിസൈനിനെ തീരുമാനിക്കുന്നത്

ഭൂരിഭാഗം ആളുകളും ചാറ്റ് വിൻഡോകളിലെ അത്യാധുനിക മോഡലുകൾക്കായിട്ടാണ് (frontier models) നിർമ്മിക്കുന്നത്. ആ മോഡലുകൾക്ക് വലിയ ടോക്കൺ ബജറ്റുകൾ ഉണ്ട്. അവയ്ക്ക് കോഡ് എക്സിക്യൂഷൻ ആണ് ഏറ്റവും മികച്ചത്.

എന്നാൽ ഞങ്ങൾ ഒരു ബോട്ടിൽ ഉപയോഗിക്കുന്ന, ചെറിയ ലോക്കൽ മോഡലിൽ (Hermes 3 8B) പ്രവർത്തിക്കുന്ന ഒരു വോയ്‌സ്-ഫസ്റ്റ് ഏജന്റിന് വേണ്ടിയാണ് നിർമ്മിക്കുന്നത്.

ഒരു ചെറിയ മോഡലിനെ സംബന്ധിച്ചിടത്തോളം പരിമിതി ടോക്കണുകളല്ല, മറിച്ച് വിശ്വാസ്യതയാണ് (reliability).

ഒരു ചെറിയ മോഡലിന് ഒരു ലളിതമായ ടൂൾ വിളിക്കാൻ പോലും ബുദ്ധിമുട്ടുണ്ടെങ്കിൽ, ശരിയായ ജാവാസ്ക്രിപ്റ്റ് എഴുതാൻ ആവശ്യപ്പെടുന്നത് അതിലും കഠിനമായ ജോലിയാണ്. execute_code വിശ്വാസ്യത കുറച്ച് ടോക്കണുകൾ ലാഭിക്കുന്നു. ആ വിട്ടുവീഴ്ച ഞങ്ങൾക്ക് ചെയ്യാൻ കഴിയില്ല.

ലാസ്റ്റ്-മൈൽ പ്രശ്നം (The Last-Mile Problem)

കോഡ് എക്സിക്യൂഷൻ ജോലിയുടെ അവസാന ഘട്ടം (last mile) ഏജന്റിലേക്ക് മാറ്റുന്നു. ഏജന്റ് ചെയ്യേണ്ട കാര്യങ്ങൾ ഇവയാണ്:

  • ഡാറ്റ ഫിൽട്ടർ ചെയ്യുക
  • ഫലങ്ങൾ ക്രമീകരിക്കുക (sort)
  • ഔട്ട്പുട്ട് ഫോർമാറ്റ് ചെയ്യുക

ഞങ്ങളുടെ ടൂളുകൾ ഈ ജോലി സെർവറിനുള്ളിൽ തന്നെ ചെയ്യുന്നു. ഉദാഹരണത്തിന്, ബാറ്ററി സ്റ്റേറ്റിനെക്കുറിച്ച് ചോദിക്കുമ്പോൾ, ഞങ്ങളുടെ ടൂൾ ടെക്സ്റ്റ്-ടു-സ്പീച്ചിനായി (text-to-speech) തയ്യാറാക്കിയ ഒരു സ്ട്രിംഗ് ആണ് നൽകുന്നത്. ഇത് വെറും നമ്പറുകൾക്ക് പകരം "68 ശതമാനം, 12.8 വോൾട്ട്" എന്ന് പറയും.

ഞങ്ങൾ execute_code ഉപയോഗിക്കുകയാണെങ്കിൽ, ആ സംസാരം ഫോർമാറ്റ് ചെയ്യാനുള്ള ലോജിക് ഏജന്റ് തന്നെ എഴുതണം. ചെറിയ മോഡലുകൾ ഇതിൽ നിരന്തരം പരാജയപ്പെടുന്നു.

അബ്സെൻസ് റൂൾ (The Absence Rule)

ഒരു ബോട്ടിൽ സെൻസറുകൾ ഓഫ്‌ലൈൻ ആകാൻ സാധ്യതയുണ്ട്. ഞങ്ങളുടെ സിസ്റ്റത്തിൽ, ഒരു സെൻസർ ലഭ്യമല്ലെങ്കിൽ അത് ഒരു 'null' വാല്യൂ നൽകുന്നു. ഇത് ഒരു വിജയകരമായ കോൾ ആയി കണക്കാക്കുന്നു.

ഒരു കോഡ് എക്സിക്യൂഷൻ മോഡലിൽ, സെൻസർ ലഭ്യമല്ലെങ്കിൽ അത് പലപ്പോഴും ഒരു എറർ (error) കാണിക്കും. ഒരു ചെറിയ മോഡൽ തെറ്റായ പാതകൾ തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, അത് എറർ ലിമിറ്റുകൾ കവിഞ്ഞും ഏജന്റ് പ്രവർത്തനരഹിതമായും മാറാൻ കാരണമാകും. പേരുള്ള ടൂളുകൾ ഉപയോഗിക്കുന്നതിലൂടെ, ഒരു ഡാറ്റയുടെ അഭാവത്തെ ഒരു പിഴവായി കാണാതെ ഒരു വിജയമായി കണക്കാക്കാൻ ഞങ്ങൾക്ക് സാധിക്കുന്നു.

അഡോപ്റ്റ്-വിസസ്-ബിൽഡ് ചെക്ക്‌ലിസ്റ്റ് (Adopt-vs-Build Checklist)

നിങ്ങൾ ഒരു MCP സെർവർ സ്വീകരിക്കുന്നതിന് മുൻപോ അല്ലെങ്കിൽ നിർമ്മിക്കുന്നതിന് മുൻപോ ഈ ചോദ്യങ്ങൾ ചോദിക്കുക:

• ആരാണ് ലക്ഷ്യമിടുന്ന ഏജന്റ്? (അത്യാധുനിക മോഡൽ vs. ചെറിയ ലോക്കൽ മോഡൽ) • പ്രധാന പരിമിതി എന്താണ്? (ടോക്കണുകൾ vs. വിശ്വാസ്യത) • അവസാന ഘട്ട ജോലി ആര് ചെയ്യുന്നു? (ടൂൾ ഡാറ്റ ഫോർമാറ്റ് ചെയ്യുന്നുണ്ടോ അതോ ഏജന്റ് ആണോ?) • അഭാവത്തെ (absence) അത് എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു? (ലഭ്യമല്ലാത്ത വാല്യൂ ഒരു എറർ ആണോ അതോ null ആണോ?) • മെയിന്റനൻസ് ചിലവ് എത്രയാണ്? (നിങ്ങൾ ഉപയോഗശൂന്യമായ ഒരു കോഡ്ബേസ് ഏറ്റെടുക്കുകയാണോ?)

ഞങ്ങൾ ആ പ്രോജക്റ്റിനെ അവഗണിച്ചില്ല. പകരം അതിലെ ആശയങ്ങൾ ഞങ്ങൾ ഉൾക്കൊണ്ടു. അവരുടെ അലാറം ഹാൻഡ്‌ലിംഗും പാത്ത് ഡിസ്കവറി ലോജിക്കും ഞങ്ങൾ വാങ്ങി ഞങ്ങളുടെ റോഡ്മാപ്പിൽ ഉൾപ്പെടുത്തി.

കാര്യക്ഷമത നല്ലതാണ്, എന്നാൽ നിങ്ങൾ വെള്ളത്തിലാണെങ്കിൽ (ഒരു ബോട്ടിലാണെങ്കിൽ) വിശ്വാസ്യതയാണ് പ്രധാനം.

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

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