અમે 96% ટોકન બચતનો અસ્વીકાર કેમ કર્યો

અમને એક એવું MCP સર્વર મળ્યું જે ટોકન્સમાં 96% બચત કરે છે. તે એક જ ટૂલનો ઉપયોગ કરે છે: execute_code. ચોક્કસ ફંક્શન્સને કોલ કરવાને બદલે, એજન્ટ ડેટા મેળવવા માટે JavaScript લખે છે.

કાગળ પર, તે જીતી જાય છે. જટિલ કાર્યો માટે, કાર્યક્ષમતાની દ્રષ્ટિએ કોડ એક્ઝિક્યુશન (code execution) ટૂલ-કોલિંગ કરતા વધુ સારું છે.

પરંતુ અમે તેને અપનાવ્યું નથી. તેના બદલે અમે અમારા અલગ, નામવાળા ટૂલ્સ જ રાખ્યા.

અહીં કારણ છે કે સ્પષ્ટ દેખાતો વિકલ્પ અમારા એજન્ટ માટે ખોટો નિર્ણય હતો.

લક્ષ્ય ડિઝાઇન નક્કી કરે છે

મોટાભાગના લોકો ચેટ વિન્ડોમાં ફ્રન્ટિયર મોડલ્સ (frontier models) માટે બિલ્ડ કરે છે. તે મોડલ્સ પાસે વિશાળ ટોકન બજેટ હોય છે. તેમના માટે, કોડ એક્ઝિક્યુશન સર્વોપરી છે.

અમે બોટ (હોડી) પર એક નાના લોકલ મોડલ (Hermes 3 8B) પર વોઈસ-ફર્સ્ટ એજન્ટ માટે બનાવીએ છીએ.

નાના મોડલ માટે, મર્યાદા ટોકન્સની નથી. મર્યાદા વિશ્વસનીયતાની (reliability) છે.

જો એક નાનું મોડલ સાદું ટૂલ કોલ કરવામાં સંઘર્ષ કરતું હોય, તો તેને સાચું JavaScript લખવા કહેવું એ ઘણું અઘરું કામ છે. execute_code ટોકન્સ માટે વિશ્વસનીયતા સાથે સમજૂતી કરે છે. અમે તે સમજૂતી કરી શકતા નથી.

લાસ્ટ-માઈલ સમસ્યા (The Last-Mile Problem)

કોડ એક્ઝિક્યુશન કામનો "લાસ્ટ માઈલ" (છેલ્લો તબક્કો) એજન્ટ પર નાખી દે છે. એજન્ટને આ કરવું પડે છે:

  • ડેટા ફિલ્ટર કરવો
  • પરિણામોને સોર્ટ કરવા
  • આઉટપુટને ફોર્મેટ કરવું

અમારા ટૂલ્સ સર્વરની અંદર આ કામ કરે છે. ઉદાહરણ તરીકે, જ્યારે બેટરી સ્ટેટ વિશે પૂછવામાં આવે છે, ત્યારે અમારું ટૂલ ટેક્સ્ટ-ટુ-સ્પીચ (text-to-speech) માટે તૈયાર સ્ટ્રિંગ રિટર્ન કરે છે. તે કાચા આંકડાઓને બદલે "68 percent, 12.8 volts" કહે છે.

જો અમે execute_code નો ઉપયોગ કરીએ, તો એજન્ટને તે સ્પીચને ફોર્મેટ કરવા માટે લોજિક લખવું પડશે. નાના મોડલ્સ આમાં સતત નિષ્ફળ જાય છે.

ગેરહાજરીનો નિયમ (The Absence Rule)

બોટ પર, સેન્સર્સ ઓફલાઇન થઈ જાય છે. અમારી સિસ્ટમમાં, ખૂટતું સેન્સર એક ક્લીન null રિટર્ન કરે છે. આ એક સફળ કોલ છે.

કોડ એક્ઝિક્યુશન મોડલમાં, ખૂટતું સેન્સર ઘણીવાર એરર (error) આપે છે. જો નાનું મોડલ થોડા ખોટા રસ્તાઓ અનુમાનિત કરે, તો તે એરર લિમિટને ટ્રિગર કરે છે અને એજન્ટને બગાડે છે. નામવાળા ટૂલ્સ અમને ગેરહાજરીને ભૂલ નહીં, પણ સફળતા તરીકે ગણવાની મંજૂરી આપે છે.

અપનાવો-અથવા-બનાવો ચેકલિસ્ટ (Adopt-vs-Build Checklist)

તમે MCP સર્વર અપનાવતા અથવા બનાવતા પહેલા, આ પ્રશ્નો પૂછો:

• લક્ષ્ય એજન્ટ કોણ છે? (ફ્રન્ટિયર મોડલ વિરુદ્ધ નાનું લોકલ મોડલ) • મુખ્ય મર્યાદા શું છે? (ટોકન્સ વિરુદ્ધ વિશ્વસનીયતા) • લાસ્ટ માઈલ કોણ કરે છે? (શું ટૂલ ડેટા ફોર્મેટ કરે છે કે એજન્ટ?) • તે ગેરહાજરીને કેવી રીતે હેન્ડલ કરે છે? (શું ખૂટતી કિંમત એ એરર છે કે નલ (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