ಸ್ಥಳೀಯ ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗಳನ್ನು (LLMs) ಬಳಸುವ ಡೆವಲಪರ್ಗಳು, ಬಳಕೆದಾರರು ಒಂದು ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಟೈಪ್ ಮಾಡುವ ಮೊದಲೇ ಒಂದು ಸಿಂಗಲ್ Multi-Channel-Protocol (MCP) ಸರ್ವರ್ ಇಡೀ ಸಂದರ್ಭದ ವಿಂಡೋವನ್ನು (context window) ಬಳಸಿಕೊಳ್ಳುವುದನ್ನು ಗಮನಿಸುತ್ತಾರೆ. ಅವರು ಅಲ್ಪ ವಿವರಣೆಗಳನ್ನು ನೀಡಬೇಕೆ ಅಥವಾ ಸಂಭಾಷಣೆಯ ಹರಿವು ಹಾಳಾಗುವುದನ್ನು ಸಹಿಸಿಕೊಳ್ಳಬೇಕೆ ಎಂಬ ಸಂದಿಗ್ಧತೆಯಲ್ಲಿ ಸಿಲುಕುತ್ತಾರೆ.
ಸ್ಥಳೀಯ LLMಗಳಿಗೆ ಟೋಕನ್ ಬ್ಲೋಟ್ (token bloat) ಏಕೆ ಮುಖ್ಯವಾಗುತ್ತದೆ
MCP ಒಂದು LLM ಗೆ ಬಾಹ್ಯ ಪರಿಕರಗಳನ್ನು—APIs, ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಅಥವಾ ಫೈಲ್-ಸಿಸ್ಟಮ್ ಉಪಯುಕ್ತತೆಗಳನ್ನು—ಪ್ರತಿ ಪರಿಕರದ ವಿವರಣೆಯನ್ನು ನೀಡುವುದರ ಮೂಲಕ ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ. 128k-ಟೋಕನ್ ವಿಂಡೋ ಹೊಂದಿರುವ ಕ್ಲೌಡ್-ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಮಾದರಿಗಳು ಅನೇಕ ಪರಿಕರದ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ತಡೆದುಕೊಳ್ಳಬಲ್ಲವು ಮತ್ತು ಬಳಕೆದಾರರ ಸಂಭಾಷಣೆಗಾಗಿ ಸ್ಥಳವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಲ್ಲವು. ಆದರೆ 8k-ಟೋಕನ್ ವಿಂಡೋ ಹೊಂದಿರುವ 7-ಬಿಲಿಯನ್ ಪ್ಯಾರಾಮೀಟರ್ ಸ್ಥಳೀಯ ಮಾದರಿಯು ಕೇವಲ ಕೆಲವು ಪರಿಕರಗಳನ್ನು ಲೋಡ್ ಮಾಡಿದ ನಂತರವೇ ಸ್ಥಳಾವಕಾಶವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಇಲ್ಲಿನ ವಿನಿಮಯವು ಕಠಿಣವಾಗಿದೆ: ಅಲ್ಪ ಮತ್ತು ಅಗ್ಗದ ವಿವರಣೆಗಳು ಕರೆಗಳನ್ನು ತಪ್ಪಾದ ಕಡೆಗೆ ಕಳುಹಿಸಬಹುದು; ದೀರ್ಘ ಮತ್ತು ವಿವರವಾದ ವಿವರಣೆಗಳು ಚಾಟ್ಗಾಗಿ ಬೇಕಾದ ಬಜೆಟ್ ಅನ್ನು ಬಳಸಿಕೊಳ್ಳುತ್ತವೆ.
ಇಲ್ಲಿಗೆ ಕಾರಣವಾದ ಘಟನೆಗಳ ಸರಪಳಿ
ಅನೇಕ ಡೇಟಾ ಮೂಲಗಳಿಗೆ ಏಕೈಕ, ಮಾದರಿ-ಚಾಲಿತ ಇಂಟರ್ಫೇಸ್ ಆಗಿ ಕೆಲಸ ಮಾಡಲು ಮತ್ತು ಕಸ್ಟಮ್ ಇಂಟಿಗ್ರೇಷನ್ ಕೋಡ್ ಅನ್ನು ಬದಲಿಸಲು MCP ಅನ್ನು ನಿರ್ಮಿಸಲಾಯಿತು. ಹೆಚ್ಚಿನ MCP ಸರ್ವರ್ಗಳು ಮನುಷ್ಯರಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ REST endpoints ಗಳ ಸುತ್ತ ಸುತ್ತುವ ತೆಳುವಾದ ವ್ರ್ಯಾಪ್ಪರ್ಗಳಂತೆ (wrappers) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ, ಯಂತ್ರಗಳಿಗಾಗಿ ಅಲ್ಲ. ಆ ವ್ರ್ಯಾಪ್ಪರ್ಗಳು ಸ್ಥಳೀಯ LLM ಸೆಷನ್ಗೆ ಬಂದಾಗ, ಮಾದರಿಯು ಯಾವ ಪರಿಕರವನ್ನು ಬಳಸಬೇಕೆಂದು ನಿರ್ಧರಿಸುವ ಮೊದಲು ಪ್ರತಿಯೊಂದು ಪರಿಕರದ ಹೆಸರು, ಪ್ಯಾರಾಮೀಟರ್ಗಳು ಮತ್ತು ಬಳಕೆಯ ಟಿಪ್ಪಣಿಗಳನ್ನು ಓದಬೇಕಾಗುತ್ತದೆ. ಸಣ್ಣ ಸಂದರ್ಭದ ವಿಂಡೋಗಳು ಈ "ವಿವರಣೆಯ ಹೆಚ್ಚಿನ ಹೊರೆ"ಯನ್ನು (description overhead) ಒಂದು ರಚನಾತ್ಮಕ ಅಡಚಣೆಯನ್ನಾಗಿ (bottleneck) ಪರಿವರ್ತಿಸುತ್ತವೆ.
ಯಾರು ಗೆಲ್ಲುತ್ತಾರೆ, ಯಾರು ಸೋಲುತ್ತಾರೆ
- ಸಾಧನದ ಮೇಲಿನ ಸಹಾಯಕರನ್ನು (on-device assistants) ನಿರ್ಮಿಸುವ ಡೆವಲಪರ್ಗಳು ನಮ್ಯತೆಯನ್ನು (flexibility) ಕಳೆದುಕೊಳ್ಳುತ್ತಾರೆ. ಅವರು ಪರಿಕರಗಳ ಪಟ್ಟಿಯನ್ನು ಕಡಿತಗೊಳಿಸಿ ಪದೇ ಪದೇ ವೈಫಲ್ಯಗಳನ್ನು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ ಅಥವಾ ಬಳಕೆದಾರರ ಇನ್ಪುಟ್ ಅನ್ನು ಕಡಿತಗೊಳಿಸುವ ಅತಿಯಾದ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.
- ಅಂತಿಮ ಬಳಕೆದಾರರು (End users) ಸಹಾಯಕನು ತಪ್ಪು ಪರಿಕರವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದಾಗ ಅಥವಾ ಸಂದರ್ಭವು ಪೂರ್ಣಗೊಂಡ ಕಾರಣ ಕೆಲಸ ಮಾಡಲು ನಿರಾಕರಿಸಿದಾಗ ಅಸ್ಥಿರ ನಡವಳಿಕೆಯನ್ನು ನೋಡುತ್ತಾರೆ.
- ಪರಿಕರ ಪೂರೈಕೆದಾರರು (Tool providers) ಏಕರೂಪದ ಪ್ರವೇಶಿಕೆಯನ್ನು ಪಡೆಯುತ್ತಾರೆ.
ಇದರ ವೆಚ್ಚ ಕೇವಲ ಕಳಪೆ ಅನುಭವ ಮಾತ್ರವಲ್ಲ; ಇದು ಭದ್ರತಾ ಕಾಳಜಿಗಳನ್ನು ಎಬ್ಬಿಸುತ್ತದೆ. ಒಂದು MCP ಏಜೆಂಟ್ ಯಾವುದೇ ಸ್ಥಳೀಯ ಫೈಲ್ ಅನ್ನು ಓದಬಲ್ಲಾಗಿದ್ದಾಗ, ಅನುಮತಿ ಮಾದರಿಯು "ಎಲ್ಲವೂ ಅಥವಾ ಏನೂ ಇಲ್ಲ" (all-or-nothing) ಎಂಬ ಸ್ಥಿತಿಗೆ ತಲುಪುತ್ತದೆ. ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ (sandbox) ಇಲ್ಲದಿದ್ದರೆ, ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಪರಿಕರವು ಇಡೀ ಫೈಲ್ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು.
ಡೆವಲಪರ್ಗಳು ಇದರ ಬಗ್ಗೆ ಏನು ಮಾಡುತ್ತಿದ್ದಾರೆ
ಸಮುದಾಯದಲ್ಲಿ ಮೂರು ಪರಿಹಾರಗಳು ಪ್ರಬಲವಾಗಿವೆ:
- ವಿವರಣೆಗಳನ್ನು ಕಡಿತಗೊಳಿಸುವುದು (Trim descriptions) – ಪರಿಕರದ ಮೆಟಾಡೇಟಾವನ್ನು ಕನಿಷ್ಠ ಮಟ್ಟಕ್ಕೆ ತರುವುದು. ಇದು ಟೋಕನ್ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತದೆ ಆದರೆ ಮಾದರಿಯು ತಪ್ಪಾದ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸಾಧ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಇದು ಡೆವಲಪರ್ಗಳು ಪತ್ತೆಹಚ್ಚಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬೇಕಾದ ದೋಷಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
- ಡೈನಾಮಿಕ್ ಲೋಡಿಂಗ್ (Dynamic loading) – ಪ್ರಸ್ತುತ ಸಂಭಾಷಣೆಗೆ ಸಂಬಂಧಿಸಿದ ಪರಿಕರಗಳ ಉಪಸಮೂಹವನ್ನು ಮಾತ್ರ ಲೋಡ್ ಮಾಡುವುದು. ಬಳಕೆದಾರರ ಉದ್ದೇಶದ ಆಧಾರದ ಮೇಲೆ ಯಾವ ಪರಿಕರಗಳ ಸೆಟ್ ಅನ್ನು ಬಳಸಬೇಕೆಂದು ಒಂದು ಲಘು ಡಿಸ್ಪ್ಯಾಚರ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಇದು ಅನಗತ್ಯ ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಆದರೆ ವಿಳಂಬ (latency) ಮತ್ತು ಕೋಡ್ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
- ಸಕ್ರಿಯ ಸರ್ವರ್ಗಳನ್ನು ಮಿತಿಗೊಳಿಸುವುದು (Limit active servers) – ಪ್ರತಿ ಸೆಷನ್ನಲ್ಲಿ MCP ಸರ್ವರ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುವುದು, ಇದರಿಂದ ಡೆವಲಪರ್ಗಳು ಅತ್ಯಗತ್ಯ ಇಂಟಿಗ್ರೇಷನ್ಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಲು被迫ಪಡುತ್ತಾರೆ. ಇದು ಪ್ರಾಂಪ್ಟ್ ಗಾತ್ರವನ್ನು ನಿರ್ವಹಣಾ ಮಟ್ಟದಲ್ಲಿಡುತ್ತದೆ ಆದರೆ ಸಾಮರ್ಥ್ಯದ ವ್ಯಾಪ್ತಿಯನ್ನು ಬಲಿಕೊಡುತ್ತದೆ.
ಇವುಗಳಲ್ಲಿ ಯಾವುದೇ ಪರಿಹಾರವು ಸಂಪೂರ್ಣ ಪರಿಹಾರವಲ್ಲ (silver bullet). ವಿವರಣೆಗಳನ್ನು ಕಡಿತಗೊಳಿಸುವುದು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಕುಂದಿಸುತ್ತದೆ; ಡೈನಾಮಿಕ್ ಲೋಡಿಂಗ್ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ನಿಧಾನಗೊಳಿಸುವ ನಿರ್ಧಾರದ ಪದರವನ್ನು ಸೇರಿಸುತ್ತದೆ; ಸರ್ವರ್ಗಳನ್ನು ಮಿತಿಗೊಳಿಸುವುದು ಯಾವ ಡೇಟಾ ಮೂಲಗಳನ್ನು ಬೆಂಬಲಿಸಬೇಕು ಎಂಬ ಕಠಿಣ ಆಯ್ಕೆಗಳಿಗೆ ಒತ್ತಾಯಿಸುತ್ತದೆ.
ಟೋಕನ್ ಸಮಸ್ಯೆಯೊಂದಿಗೆ ಬರುವ ಭದ್ರತಾ ಅಪಾಯಗಳು
ಸ್ಥಳೀಯ ಏಜೆಂಟ್ಗಳು ಹೆಚ್ಚಾಗಿ ನಿರ್ಬಂಧವಿಲ್ಲದ ಫೈಲ್-ಸಿಸ್ಟಮ್ ಪ್ರವೇಶದೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. MCP ಪ್ರೊಟೊಕಾಲ್ "ಈ ಫೋಲ್ಡರ್ ಅನ್ನು ಓದಿ" ಮತ್ತು "ಎಲ್ಲವನ್ನೂ ಓದಿ" ಎಂಬ ನಡುವೆ ಯಾವುದೇ ವ್ಯತ್ಯಾಸವನ್ನು ನೀಡುವುದಿಲ್ಲ. ಕೆಲವು ತಂಡಗಳು ಪೂರ್ಣ-ಪ್ರವೇಶದ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಲು ಗೇಟ್ವೇ ಲೇಯರ್ಗಳನ್ನು ನಿರ್ಮಿಸಿವೆ, ಇದು ಹೆಚ್ಚಿನ ಸಂಕೀರ್ಣತೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ. ಆ ಗೇಟ್ವೇಗಳು "ಪೂರ್ಣ ನಿಯಂತ್ರಣ" ಸಮಸ್ಯೆಯನ್ನು ತಗ್ಗಿಸುತ್ತವೆ ಆದರೆ ಕೋಡ್ ಬೇಸ್ ಅನ್ನು ಕೂಡ ಹೆಚ್ಚಿಸುತ್ತವೆ.
ಸಣ್ಣ ಮಾದರಿಗಳಿಗಾಗಿ ಪರಿಕರಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು
ದೊಡ್ಡ ಕ್ಲೌಡ್ ಮಾದರಿಗಳು ಕೆಟ್ಟ ವಿವರಣೆಗಳಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳಬಲ್ಲವು, ಆದ್ದರಿಂದ ಡೆವಲಪರ್ಗಳು ಕೆಲವೊಮ್ಮೆ ನಿಖರವಾದ ಪರಿಕರ ವ್ಯಾಖ್ಯಾನಗಳ ಅಗತ್ಯವನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತಾರೆ. ಸ್ಥಳೀಯ ಮಾದರಿಗಳಿಗಾಗಿ, ಈ ತತ್ವಗಳನ್ನು ಅನುಸರಿಸಿ:
- ಸೀಮಿತ ಕಾರ್ಯಕ್ಷಮತೆ (Narrow functionality) – ಪ್ರತಿ ಪರಿಕರವು ಒಂದೇ ಕೆಲಸ ಮಾಡಬೇಕು. "search" ಪರಿಕರವು ಫೈಲ್ಗಳನ್ನು ಬರೆಯುವ ಕೆಲಸವನ್ನೂ ಮಾಡಿದರೆ, ಅತಿಕ್ರಮಿಸುವ ಜವಾಬ್ದಾರಿಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲಾಗದ ಮಾದರಿಯು ಗೊಂದಲಕ್ಕೀಡಾಗಬಹುದು.
- ಅಸ್ಪಷ್ಟವಲ್ಲದ ಹೆಸರಿಸುವಿಕೆ (Unambiguous naming) – "process" ಅಥವಾ "handle" ನಂತಹ ಸಾಮಾನ್ಯ ಹೆಸರುಗಳನ್ನು ತಪ್ಪಿಸಿ. ಹೆಸರುಗಳು ನಿಖರವಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ತಿಳಿಸಬೇಕು, ಇದು ಮಾದರಿಯ ಮಾನಸಿಕ ಹೊರೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
- ಸ್ಪಷ್ಟ ಮತ್ತು ಸಂಕ್ಷಿಪ್ತ ವಿವರಣೆಗಳು (Clear, concise descriptions) – ಮಾದರಿಯು ನಿರ್ಧರಿಸಲು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿರುವ ಪ್ಯಾರಾಮೀಟರ್ಗಳನ್ನು ಮಾತ್ರ ಸೇರಿಸಿ. ಮಾದರಿಯು ಮಾದರಿಗಳನ್ನು (patterns) ವೇಗವಾಗಿ ಗುರುತಿಸಲು ಸುಸಂಬದ್ಧವಾದ ಫಾರ್ಮ್ಯಾಟ್ ಬಳಸಿ.
ವಿರೋಧಾತ್ಮಕ ಅಂಶ: ಪ್ರೊಟೊಕಾಲ್ ಇನ್ನೂ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿದೆ
ಅಡೆತಡೆಗಳಿದ್ದರೂ, MCP ಆಕರ್ಷಕವಾಗಿ ಉಳಿದಿದೆ ಏಕೆಂದರೆ ಇದು ಬಾಯ್ಲರ್ಪ್ಲೇಟ್ ಕೋಡ್ ಅನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ. ಏಕೈಕ, ಮಾದರಿ-ಚಾಲಿತ ಇಂಟರ್ಫೇಸ್ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಕಸ್ಟಮ್ ಅಡಾಪ್ಟರ್ಗಳನ್ನು ಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲದೆ ಡಜನ್ಗಟ್ಟಲೆ ಸೇವೆಗಳಿಗೆ ಸಂಪರ್ಕಿಸಬಹುದು. ಕ್ಲೌಡ್-ಸ್ಕೇಲ್ ಮಾದರಿಗಳನ್ನು ಹೊಂದಲು ಶಕ್ತಿ ಇರುವ ತಂಡಗಳು ಟೋಕನ್ ಬ್ಲೋಟ್ ಅನ್ನು ಸಮಸ್ಯೆಯಾಗಿ ಪರಿಗಣಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅದರ ಅನುಕೂಲವು ಹೆಚ್ಚಿನ ಹೊರೆಯಗಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಸವಾಲಿನ ಕೆಲಸವೆಂದರೆ ಆ ಅನುಕೂಲವನ್ನು ಸಾಧನದ ಮೇಲಿನ LLMಗಳ ಸೀಮಿತ ಜಗತ್ತಿಗೆ ತರುವುದು.
ಮುಖ್ಯ ಅಂಶಗಳು
ನೀವು ಆನ್-ಡೈವೈಸ್ ಅಸಿಸ್ಟೆಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, MCP ಟೂಲ್ ವಿವರಣೆಗಳನ್ನು ಅಪರೂಪದ ಸಂಪನ್ಮೂಲವೆಂದು ಪರಿಗಣಿಸಿ. ಸಂಭಾಷಣೆಗೆ ಅಗತ್ಯವಿರುವ context window ಅನ್ನು ಸಕ್ರಿಯವಾಗಿಡಲು, ಅವುಗಳನ್ನು ಕತ್ತರಿಸಿ (trim), ಡೈನಾಮಿಕವಾಗಿ ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಕಿರಿದಾದ ವ್ಯಾಪ್ತಿಯ ಟೂಲ್ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಕೆಲವು ಹೆಚ್ಚುವರಿ ಟೋಕನ್ಗಳ ವೆಚ್ಚವಾದರೂ ಸಹ, ಒಂದು ಪರ್ಮಿಷನ್ ಲೇಯರ್ ಅನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಅಪ್ರತ್ಯಕ್ಷವಾದ “full-access” ಭದ್ರತಾ ಮಾದರಿಯಿಂದ ರಕ್ಷಿಸಿಕೊಳ್ಳಿ. ನೀವು ಸಾಧಿಸುವ ಈ ಸಮತೋಲನವು ನಿಮ್ಮ ಲೋಕಲ್ LLM ಒಂದು ಸಹಕಾರಿಯಂತೆ ಕಾಣುತ್ತದೆಯೇ ಅಥವಾ ಕೆಟ್ಟುಹೋದ ಚಾಟ್ಬಾಟ್ನಂತೆ ಕಾಣುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.