ਲੋਕਲ ਲਾਰਜ-ਲੈਂਗੂਏਜ ਮਾਡਲ (LLMs) ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਇੱਕ ਸਿੰਗਲ ਮਲਟੀ-ਚੈਨਲ-ਪ੍ਰੋਟੋਕੋਲ (MCP) ਸਰਵਰ ਯੂਜ਼ਰ ਦੁਆਰਾ ਪ੍ਰੋਂਪਟ ਟਾਈਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪੂਰੇ ਕੰਟੈਕਸਟ ਵਿੰਡੋ (context window) ਨੂੰ ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਜਾਂ ਤਾਂ ਕਮਜ਼ੋਰ ਟੂਲ ਵਰਣਨ (tool descriptions) ਚੁਣਨਾ ਪੈਂਦਾ ਹੈ ਜਾਂ ਫਿਰ ਟੁੱਟੇ ਹੋਏ ਗੱਲਬਾਤ ਦੇ ਪ੍ਰਵਾਹ (conversation flow) ਨਾਲ ਸਮਝੌਤਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਲੋਕਲ LLMs ਲਈ ਟੋਕਨ ਬਲੋਟ (token bloat) ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

MCP ਇੱਕ LLM ਨੂੰ ਬਾਹਰੀ ਟੂਲ—APIs, ਸਕ੍ਰਿਪਟਾਂ, ਜਾਂ ਫਾਈਲ-ਸਿਸਟਮ ਯੂਟੀਲਿਟੀਜ਼—ਕਾਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਮਾਡਲ ਨੂੰ ਹਰੇਕ ਟੂਲ ਦਾ ਵਰਣਨ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। 128k-ਟੋਕਨ ਵਿੰਡੋ ਵਾਲੇ ਕਲਾਉਡ-ਹੋਸਟਡ ਮਾਡਲ ਕਈ ਟੂਲ ਡੈਫੀਨੇਸ਼ਨਾਂ ਨੂੰ ਸੋਖ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਯੂਜ਼ਰ ਡਾਇਲਾਗ ਲਈ ਜਗ੍ਹਾ ਬਚਾ ਸਕਦੇ ਹਨ। 8k-ਟੋਕਨ ਵਿੰਡੋ ਦੇ ਨਾਲ ਲੋਕਲ ਚੱਲ ਰਿਹਾ 7-ਬਿਲੀਅਨ-ਪੈਰਾਮੀਟਰ ਵਾਲਾ ਮਾਡਲ ਸਿਰਫ਼ ਕੁਝ ਟੂਲ ਲੋਡ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ ਸਪੇਸ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਮਝੌਤਾ ਬਹੁਤ ਸਪੱਸ਼ਟ ਹੈ: ਛੋਟੇ, ਸਸਤੇ ਵਰਣਨ ਕਾਲਾਂ ਨੂੰ ਗਲਤ ਰਸਤੇ 'ਤੇ ਭੇਜਦੇ ਹਨ; ਲੰਬੇ, ਵਿਸਤ੍ਰਿਤ ਵਰਣਨ ਚੈਟ ਲਈ ਲੋੜੀਂਦੇ ਬਜਟ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹਨ।

ਉਹ ਘਟਨਾਵਾਂ ਜਿਨ੍ਹਾਂ ਕਾਰਨ ਅਜਿਹਾ ਹੋਇਆ

MCP ਨੂੰ ਕਸਟਮ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਕੋਡ ਦੀ ਜਗ੍ਹਾ ਕਈ ਡੇਟਾ ਸਰੋਤਾਂ ਲਈ ਇੱਕ ਸਿੰਗਲ, ਮਾਡਲ-ਡ੍ਰਿਵਨ ਇੰਟਰਫੇਸ ਵਜੋਂ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਜ਼ਿਆਦਾਤਰ MCP ਸਰਵਰ REST ਐਂਡਪੁਆਇੰਟਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੱਕ ਪਤਲੇ ਵੈਪਰ (thin wrappers) ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹਨ ਜੋ ਮਸ਼ੀਨਾਂ ਦੀ ਬਜਾਏ ਮਨੁੱਖੀ ਆਪਰੇਟਰਾਂ ਲਈ ਬਣਾਏ ਗਏ ਹਨ। ਜਦੋਂ ਉਹ ਵੈਪਰ ਇੱਕ ਲੋਕਲ LLM ਸੈਸ਼ਨ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਮਾਡਲ ਨੂੰ ਇਹ ਫੈਸਲਾ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕਿਹੜੇ ਟੂਲ ਨੂੰ ਕਾਲ ਕਰਨਾ ਹੈ, ਹਰੇਕ ਟੂਲ ਦਾ ਨਾਮ, ਪੈਰਾਮੀਟਰ ਅਤੇ ਵਰਤੋਂ ਦੇ ਨੋਟ ਪੜ੍ਹਨੇ ਪੈਂਦੇ ਹਨ। ਛੋਟੀਆਂ ਕੰਟੈਕਸਟ ਵਿੰਡੋਜ਼ ਇਸ "ਡਿਸਕ੍ਰਿਪਸ਼ਨ ਓਵਰਹੈੱਡ" ਨੂੰ ਇੱਕ ਸੰਰਚਨਾਤਮਕ ਰੁਕਾਵਟ (structural bottleneck) ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।

ਕੌਣ ਜਿੱਤਦਾ ਹੈ, ਕੌਣ ਹਾਰਦਾ ਹੈ

  • ਆਪਣੇ ਡਿਵਾਈਸ 'ਤੇ ਅਸਿਸਟੈਂਟ ਬਣਾਉਣ ਵਾਲੇ ਡਿਵੈਲਪਰ ਲਚਕਤਾ ਗੁਆ ਲੈਂਦੇ ਹਨ। ਉਹ ਜਾਂ ਤਾਂ ਟੂਲ ਕੈਟਾਲਾਗ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਵਾਰ-ਵਾਰ ਅਸਫਲਤਾ ਦਾ ਖਤਰਾ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਫਿਰ ਇੱਕ ਭਾਰੀ ਪ੍ਰੋਂਪਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ ਜੋ ਯੂਜ਼ਰ ਦੇ ਇਨਪੁਟ ਨੂੰ ਕੱਟ ਦਿੰਦਾ ਹੈ।
  • ਅੰਤਮ ਯੂਜ਼ਰ (End users) ਉਦੋਂ ਅਸਥਿਰ ਵਿਵਹਾਰ ਦੇਖਦੇ ਹਨ ਜਦੋਂ ਅਸਿਸਟੈਂਟ ਗਲਤ ਟੂਲ ਚੁਣਦਾ ਹੈ ਜਾਂ ਕੰਟੈਕਸਟ ਭਰ ਜਾਣ ਕਾਰਨ ਕੰਮ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੰਦਾ ਹੈ।
  • ਟੂਲ ਪ੍ਰੋਵਾਈਡਰਾਂ ਨੂੰ ਇੱਕ ਸਮਾਨ ਐਂਟਰੀ ਪੁਆਇੰਟ ਮਿਲਦਾ ਹੈ।

ਇਸਦੀ ਕੀਮਤ ਸਿਰਫ਼ ਇੱਕ ਮਾੜਾ ਅਨੁਭਵ ਹੀ ਨਹੀਂ ਹੈ; ਇਹ ਸੁਰੱਖਿਆ ਚਿੰਤਾਵਾਂ ਵੀ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ MCP ਏਜੰਟ ਕਿਸੇ ਵੀ ਲੋਕਲ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਤਾਂ ਪਰਮਿਸ਼ਨ ਮਾਡਲ "ਸਭ ਕੁਝ ਜਾਂ ਕੁਝ ਵੀ ਨਹੀਂ" (all-or-nothing) ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ। ਸੈਂਡਬਾਕਸ (sandbox) ਤੋਂ ਬਿਨਾਂ, ਇੱਕ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕੰਫਿਗਰ ਕੀਤਾ ਗਿਆ ਟੂਲ ਪੂਰੇ ਫਾਈਲ-ਸਿਸਟਮ ਨੂੰ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ।

ਡਿਵੈਲਪਰ ਇਸ ਬਾਰੇ ਕੀ ਕਰ ਰਹੇ ਹਨ

ਕਮਿਊਨਿਟੀ ਵਿੱਚ ਤਿੰਨ ਤਰੀਕੇ ਪ੍ਰਚਲਿਤ ਹਨ:

  • ਡਿਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਛੋਟਾ ਕਰਨਾ (Trim descriptions) – ਟੂਲ ਮੈਟਾਡਾਟਾ ਨੂੰ ਬਿਲਕੁਲ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰ ਦਿਓ। ਇਹ ਟੋਕਨਾਂ ਨੂੰ ਖਾਲੀ ਕਰਦਾ ਹੈ ਪਰ ਮਾਡਲ ਦੁਆਰਾ ਗਲਤ ਐਂਡਪੁਆਇੰਟ ਚੁਣਨ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਫੜਨਾ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।
  • ਡਾਇਨਾਮਿਕ ਲੋਡਿੰਗ (Dynamic loading) – ਸਿਰਫ਼ ਮੌਜੂਦਾ ਗੱਲਬਾਤ ਨਾਲ ਸਬੰਧਤ ਟੂਲ ਦੇ ਹਿੱਸੇ ਨੂੰ ਹੀ ਲੋਡ ਕਰੋ। ਇੱਕ ਹਲਕਾ ਡਿਸਪੈਚਰ, ਯੂਜ਼ਰ ਦੇ ਇਰਾਦੇ (intent) ਦੇ ਅਧਾਰ 'ਤੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਟੂਲ ਸੈੱਟ ਨੂੰ ਇੰਜੈਕਟ ਕਰਨਾ ਹੈ। ਇਹ ਫਾਲਤੂ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਪਰ ਲੇਟੈਂਸੀ (latency) ਅਤੇ ਕੋਡ ਦੀ ਗੁੰਝਲਤਾ ਵਧਾਉਂਦਾ ਹੈ।
  • ਐਕਟਿਵ ਸਰਵਰਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨਾ (Limit active servers) – ਪ੍ਰਤੀ ਸੈਸ਼ਨ MCP ਸਰਵਰਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਤ ਕਰੋ, ਜਿਸ ਨਾਲ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਪਹਿਲ ਦੇਣ ਲਈ ਮਜਬੂਰ ਹੋਣਾ ਪੈਂਦਾ ਹੈ। ਇਹ ਪ੍ਰੋਂਪਟ ਦੇ ਆਕਾਰ ਨੂੰ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਪਰ ਸਮਰੱਥਾ ਦੀ ਵਿਸ਼ਾਲਤਾ ਨਾਲ ਸਮਝੌਤਾ ਕਰਦਾ ਹੈ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਹੱਲ ਜਾਦੂਈ (silver bullet) ਨਹੀਂ ਹੈ। ਡਿਸਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਹਟਾਉਣਾ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ; ਡਾਇਨਾਮਿਕ ਲੋਡਿੰਗ ਇੱਕ ਫੈਸਲਾ ਲੈਣ ਵਾਲੀ ਪਰਤ ਜੋੜਦਾ ਹੈ ਜੋ ਜਵਾਬਾਂ ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੰਦੀ ਹੈ; ਸਰਵਰਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਕਿਹੜੇ ਡੇਟਾ ਸਰੋਤਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨਾ ਹੈ ਇਸ ਬਾਰੇ ਮੁਸ਼ਕਲ ਚੋਣਾਂ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

ਟੋਕਨ ਦੀ ਸਮੱਸਿਆ ਨਾਲ ਜੁੜੇ ਸੁਰੱਖਿਆ ਜੋਖਮ

ਲੋਕਲ ਏਜੰਟ ਅਕਸਰ ਬਿਨਾਂ ਕਿਸੇ ਰੋਕ-ਟੋਕ ਦੇ ਫਾਈਲ-ਸਿਸਟਮ ਐਕਸੈਸ ਨਾਲ ਚੱਲਦੇ ਹਨ। MCP ਪ੍ਰੋਟੋਕੋਲ "ਇਸ ਫੋਲਡਰ ਨੂੰ ਪੜ੍ਹੋ" ਅਤੇ "ਸਭ ਕੁਝ ਪੜ੍ਹੋ" ਦੇ ਵਿਚਕਾਰ ਕੋਈ ਵਿਤਕਰੇ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ (granularity) ਨਹੀਂ ਦਿੰਦਾ। ਕੁਝ ਟੀਮਾਂ ਨੇ ਫੁੱਲ-ਐਕਸੈਸ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਸੁਧਾਰਨ ਲਈ ਗੇਟਵੇ ਲੇਅਰਾਂ ਬਣਾਈਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਗੁੰਝਲਤਾ ਹੋਰ ਵਧ ਗਈ ਹੈ। ਉਹ ਗੇਟਵੇ "ਫੁੱਲ-ਕੰਟਰੋਲ" ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ ਪਰ ਕੋਡ ਬੇਸ ਨੂੰ ਵੀ ਵਧਾਉਂਦੇ ਹਨ।

ਛੋਟੇ ਮਾਡਲਾਂ ਲਈ ਟੂਲ ਡਿਜ਼ਾਈਨ ਕਰਨਾ

ਵੱਡੇ ਕਲਾ

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ on-device ਸਹਾਇਕ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ MCP ਟੂਲ ਵੇਰਵਿਆਂ ਨੂੰ ਇੱਕ ਸੀਮਤ ਸਰੋਤ ਵਜੋਂ ਮੰਨੋ। ਅਸਲ ਗੱਲਬਾਤ ਲਈ context window ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣ ਲਈ ਇਨ੍ਹਾਂ ਨੂੰ ਛੋਟਾ ਕਰੋ, ਡਾਇਨਾਮਿਕ ਤੌਰ 'ਤੇ ਲੋਡ ਕਰੋ, ਅਤੇ ਤੰਗ ਰੂਪ ਵਿੱਚ ਸਕੋਪ ਕੀਤੇ (narrowly scoped) ਟੂਲ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਇੱਕ permission layer ਜੋੜ ਕੇ ਅਸਪਸ਼ਟ “full-access” ਸੁਰੱਖਿਆ ਮਾਡਲ ਤੋਂ ਬਚੋ, ਭਾਵੇਂ ਇਸ ਲਈ ਕੁਝ ਵਾਧੂ tokens ਦੀ ਕੀਮਤ ਕਿਉਂ ਨਾ ਚੁਕਾਉਣੀ ਪਵੇ। ਤੁਹਾਡੇ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਸੰਤੁਲਨ ਹੀ ਇਹ ਤੈਅ ਕਰੇਗਾ ਕਿ ਤੁਹਾਡਾ local LLM ਇੱਕ ਮਦਦਗਾਰ ਸਾਥੀ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜਾਂ ਇੱਕ ਖਰਾਬ chatbot ਵਾਂਗ।