લોકલ લાર્જ લેંગ્વેજ મોડલ્સ (LLMs) નો ઉપયોગ કરતા ડેવલપર્સને જાણવા મળે છે કે એક સિંગલ Multi-Channel-Protocol (MCP) સર્વર યુઝર પ્રોમ્પ્ટ ટાઈપ કરે તે પહેલાં જ આખી કોન્ટેક્સ્ટ વિન્ડો (context window) ખાઈ શકે છે. તેમણે કાં તો નબળા ટૂલ વર્ણનો (tool descriptions) અથવા બગડેલા વાતચીતના પ્રવાહ વચ્ચે પસંદગી કરવી પડે છે.

લોકલ LLMs માટે ટોકન બ્લોટ (token bloat) શા માટે મહત્વનું છે

MCP એક LLM ને દરેક ટૂલનું વર્ણન આપીને એક્સટર્નલ ટૂલ્સ—APIs, સ્ક્રિપ્ટ્સ અથવા ફાઇલ-સિસ્ટમ યુટિલિટીઝ—ને કોલ કરવાની મંજૂરી આપે છે. 128k-ટોકન વિન્ડો ધરાવતા ક્લાઉડ-હોસ્ટેડ મોડલ્સ ઘણા બધા ટૂલ ડેફિનેશન્સ સમાવી શકે છે અને તેમ છતાં યુઝર ડાયલોગ માટે જગ્યા છોડી શકે છે. 8k-ટોકન વિન્ડો સાથે લોકલ રીતે ચાલતું 7-બિલિયન પેરામીટર ધરાવતું મોડલ માત્ર થોડા ટૂલ્સ લોડ કર્યા પછી જ જગ્યા પૂરી કરી દે છે. આ વિરોધાભાસ સ્પષ્ટ છે: ટૂંકા, સસ્તા વર્ણનો કોલ્સને ખોટી રીતે રુટ કરે છે; લાંબા, વિગતવાર વર્ણનો ચેટ માટે જરૂરી બજેટનો વપરાશ કરે છે.

આ પરિસ્થિતિ તરફ દોરી જતી ઘટનાઓની સાંકળ

MCP ને કસ્ટમ ઇન્ટિગ્રેશન કોડને બદલે ઘણા ડેટા સોર્સ માટે સિંગલ, મોડલ-ડ્રિવન ઇન્ટરફેસ તરીકે બનાવવા માટે બનાવવામાં આવ્યું હતું. મોટાભાગના MCP સર્વર્સ માનવ ઓપરેટર્સ માટે બનાવેલા REST એન્ડપોઇન્ટ્સના પાતળા વરાppers (wrappers) તરીકે કામ કરે છે, મશીનો માટે નહીં. જ્યારે તે વરાppers લોકલ LLM સેશનમાં આવે છે, ત્યારે મોડલે કયું ટૂલ ઇનવોક કરવું તે નક્કી કરતા પહેલા દરેક ટૂલનું નામ, પેરામીટર્સ અને વપરાશની નોંધો વાંચવી પડે છે. નાની કોન્ટેક્સ્ટ વિન્ડો આ "વર્ણન ઓવરહેડ" (description overhead) ને એક સ્ટ્રક્ચરલ બોટલનેક (bottleneck) માં ફેરવી દે છે.

કોણ જીતે છે, કોણ હારે છે

  • ઓન-ડિવાઇસ આસિસ્ટન્ટ્સ બનાવતા ડેવલપર્સ લવચીકતા (flexibility) ગુમાવે છે. તેઓ કાં તો ટૂલ કેટલોગને ઘટાડે છે, જેનાથી વારંવાર નિષ્ફળતાનું જોખમ રહે છે, અથવા યુઝર ઇનપુટને ટૂંકું કરી દે તેવા બ્લોટેડ પ્રોમ્પ્ટનો સ્વીકાર કરે છે.
  • એન્ડ યુઝર્સ ત્યારે અસ્થિર વર્તન જુએ છે જ્યારે આસિસ્ટન્ટ ખોટું ટૂલ પસંદ કરે છે અથવા કોન્ટેક્સ્ટ ભરાઈ જવાથી કામ કરવાનો ઇનકાર કરે છે.
  • ટૂલ પ્રોવાઇડર્સ ને એક યુનિફોર્મ એન્ટ્રી પોઈન્ટ મળે છે.

આનો ખર્ચ માત્ર નબળો અનુભવ નથી; તે સુરક્ષાની ચિંતાઓ પણ વધારે છે. જ્યારે એક MCP એજન્ટ કોઈપણ લોકલ ફાઇલ વાંચી શકે છે, ત્યારે પરમિશન મોડલ "ઓલ-ઓર-નથિંગ" (all-or-nothing) માં તब्दीલ થઈ જાય છે. સેન્ડબોક્સ વગર, ખોટી રીતે કોન્ફિગર કરેલું ટૂલ આખી ફાઇલ સિસ્ટમને ખુલ્લી પાડી શકે છે.

ડેવલપર્સ આ બાબતે શું કરી રહ્યા છે

સમુદાયમાં ત્રણ ઉપાયો પ્રભુત્વ ધરાવે છે:

  • વર્ણનોને ટ્રીમ કરવા (Trim descriptions) – ટૂલ મેટાડેટાને ન્યૂનતમ સ્તરે લાવો. આનાથી ટોકન્સ મુક્ત થાય છે પરંતુ મોડલ ખોટું એન્ડપોઇન્ટ પસંદ કરવાની શક્યતા વધે છે, જેનાથી એવી ભૂલો થાય છે જે ડેવલપર્સે પકડવી અને ફરીથી પ્રયાસ કરવો પડે છે.
  • ડાયનેમિક લોડિંગ (Dynamic loading) – વર્તમાન વાતચીત માટે સુસંગત હોય તેવા ટૂલ્સના સબસેટને જ લોડ કરો. એક લાઇટવેઇટ ડિસ્પેચર, યુઝરના ઇન્ટેન્ટના આધારે નક્કી કરે છે કે કયા ટૂલ સેટને ઇન્જેક્ટ કરવો. આનાથી બિનજરૂરી ટોકન વપરાશ ઘટે છે પરંતુ લેટન્સી (latency) અને કોડની જટિલતા વધે છે.
  • સક્રિય સર્વર્સ મર્યાદિત કરવા (Limit active servers) – દરેક સેશનમાં MCP સર્વર્સની સંખ્યા મર્યાદિત કરો, જેનાથી ડેવલપર્સને સૌથી આવશ્યક ઇન્ટિગ્રેશનને પ્રાથમિકતા આપવા માટે મજબૂર કરવામાં આવે છે. આનાથી પ્રોમ્પ્ટ સાઈઝ મેનેજેબલ રહે છે પરંતુ ક્ષમતાની વ્યાપકતાનો બલિદાન આપવો પડે છે.

આમાંથી એક પણ ઉકેલ સંપૂર્ણ (silver bullet) નથી. વર્ણનો ઘટાડવાથી વિશ્વસનીયતાને નુકસાન થાય છે; ડાયનેમિક લોડિંગ પ્રતિસાદને ધીમો બનાવતું એક નિર્ણય લેવાનો લેયર ઉમેરે છે; સર્વર્સ મર્યાદિત કરવાથી કયા ડેટા સોર્સને સપોર્ટ કરવા તે અંગે કઠિન નિર્ણયો લેવા પડે છે.

ટોકન સમસ્યા સાથે જોડાયેલા સુરક્ષા જોખમો

લોકલ એજન્ટ્સ ઘણીવાર અનરિસ્ટ્રિક્ટેડ ફાઇલ-સિસ્ટમ એક્સેસ સાથે ચાલે છે. MCP પ્રોટોકોલ "આ ફોલ્ડર વાંચો" અને "બધું જ વાંચો" વચ્ચે કોઈ તફાવત (granularity) આપતો નથી. કેટલીક ટીમો ફૂલ-એક્સેસ સમસ્યાને સુધારવા માટે ગેટવે લેયર્સ બનાવવામાં આવ્યા છે, જે વધુ જટિલતા ઉમેરે છે. તે ગેટવેઝ "ફુલ-કંટ્રોલ" સમસ્યાને ઘટાડે છે પરંતુ કોડ બેઝ પણ વધારે છે.

નાના મોડલ્સ માટે ટૂલ્સ ડિઝાઇન કરવા

મોટા ક્લાઉડ મોડલ્સ ખરાબ વર્ણનોમાંથી સુધરી શકે છે, તેથી ડેવલપર્સ ક્યારેક સચોટ ટૂલ ડેફિનેશન્સની જરૂરિયાતને અવગણે છે. લોકલ મોડલ્સ માટે, આ સિદ્ધાંતોનું પાલન કરો:

  • મર્યાદિત કાર્યક્ષમતા (Narrow functionality) – દરેક ટૂલે એક જ કામ કરવું જોઈએ. એક "સર્ચ" ટૂલ જે ફાઇલો પણ લખે છે, તે એવા મોડલને મૂંઝવણમાં મૂકી દેશે જે ઓવરલેપિંગ જવાબદારીઓને ટ્રેક કરી શકતું નથી.
  • ચોક્કસ નામકરણ (Unambiguous naming) – "process" અથવા "handle" જેવા સામાન્ય નામો ટાળો. નામોએ ચોક્કસ ઓપરેશન દર્શાવવું જોઈએ, જેથી મોડલનો માનસિક ભાર (mental load) ઘટે.
  • સ્પષ્ટ, સંક્ષિપ્ત વર્ણનો (Clear, concise descriptions) – માત્ર તે જ પેરામીટર્સ શામેલ કરો જે મોડલને નિર્ણય લેવા માટે ખરેખર જરૂરી હોય. એક સુસંગત ફોર્મેટનો ઉપયોગ કરો જેથી મોડલ ઝડપથી પેટર્ન ઓળખી શકે.

વિરોધ પક્ષ: પ્રોટોકોલનું મૂલ્ય હજુ પણ છે

ઘર્ષણ હોવા છતાં, MCP આકર્ષક રહે છે કારણ કે તે બોઈલરપ્લેટ કોડને સરળ બનાવે છે. એક સિંગલ, મોડલ-ડ્રિવન ઇન્ટરફેસ દરેક માટે કસ્ટમ એડેપ્ટર્સ લખ્યા વિના ડઝનબંધ સેવાઓ સાથે જોડાઈ શકે છે. જે ટીમો ક્લાઉડ-સ્કેલ મોડલ્સનો ખર્ચ ઉઠાવી શકે છે તેઓ ટોકન બ્લોટને બિન-મુદ્દા તરીકે જુએ છે, અને તેની સુવિધા તેના ઓવરહેડ કરતા વધુ છે. પડકાર એ સુવિધાને ઓન-ડિવાઇસ LLMs ની મર્યાદિત દુનિયામાં રૂપાંતરિત કરવાનો છે.

મુખ્ય વાત (Takeaway)

જો તમે ઓન-ડિવાઇસ આસિસ્ટન્ટ બનાવી રહ્યા હોવ, તો MCP ટૂલ ડિસ્ક્રિપ્શનને એક મર્યાદિત સંસાધન તરીકે ગણો. વાસ્તવિક વાતચીત માટે context window કાર્યરત રાખવા માટે તેને ટ્રીમ કરો, ડાયનેમિકલી લોડ કરો અને સાંકડા સ્કોપ ધરાવતા ટૂલ્સ ડિઝાઇન કરો. સાથે જ, ભલે થોડા વધારાના ટોકન્સનો ખર્ચ થાય, પણ એક પરમિશન લેયર ઉમેરીને પરોક્ષ "ફુલ-એક્સેસ" સિક્યુરિટી મોડલ સામે રક્ષણ આપો. તમે જે સંતુલન જાળવશો તેના પરથી નક્કી થશે કે તમારું લોકલ LLM એક મદદરૂપ સાથી જેવું લાગે છે કે પછી એક ખામીયુક્ત ચેટબોટ જેવું.