Model Context Protocol (MCP) ಅನ್ನು ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಗಳನ್ನು (LLMs) ಅಳೆಯಬಹುದಾದ ಮತ್ತು ಸುರಕ್ಷಿತವಾದ ಲೂಪ್ನಲ್ಲಿ ಬಾಹ್ಯ ಪರಿಕರಗಳನ್ನು (external tools) ಬಳಸಬಹುದಾದ ಏಜೆಂಟ್ಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸಲು ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಾನದಂಡವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಲಾಗಿದೆ. ಯಾವುದೇ MCP-ಅರಿವಿರುವ ಹೋಸ್ಟ್ (MCP-aware host) ಮತ್ತು ಯಾವುದೇ MCP ಸರ್ವರ್ ನಡುವೆ ಹಂಚಿಕೆಯ "ಪ್ಲಗ್" ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಮೂಲಕ, ಈ ಪ್ರೊಟೊಕಾಲ್ ಅಭಿವರ್ಧಕರು ಅಡ್-ಹಾಕ್ ಕೋಡ್ಗಳ ಬದಲಿಗೆ ಮುನ್ಸೂಚಿಸಬಹುದಾದ ಮತ್ತು ಲೆಕ್ಕಪರಿಶೋಧಿಸಬಹುದಾದ (auditable) ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
LLMಗಳಿಗೆ ಪ್ರೊಟೊಕಾಲ್ ಏಕೆ ಬೇಕು?
LLM ತನ್ನ ತರಬೇತಿ ಡೇಟಾದಿಂದ ಮುಂದಿನ ಪಠ್ಯದ ಟೋಕನ್ ಅನ್ನು ಮಾತ್ರ ಮುನ್ಸೂಚಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ತರ್ಕವಿಲ್ಲದೆ (extra logic), ಅದು ಹೊಸ ಸತ್ಯಗಳನ್ನು ಪಡೆಯಲು, ಡೇಟಾಬೇಸ್ಗೆ ಬರೆಯಲು ಅಥವಾ ಬಾಹ್ಯ API ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಭಿವರ್ಧಕರು ಮಾದರಿಯನ್ನು ಒಂದು ಲೂಪ್ನಲ್ಲಿ ಸುತ್ತುವರಿಯುವ "ಏಜೆಂಟ್ಗಳನ್ನು" ನಿರ್ಮಿಸಿದ್ದಾರೆ: ಮಾದರಿಯು ಪರಿಕರವನ್ನು ಕೇಳುತ್ತದೆ, ಪರಿಕರವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಫಲಿತಾಂಶವನ್ನು ಮರಳಿ ನೀಡಲಾಗುತ್ತದೆ ಮತ್ತು ಮಾದರಿಯು ಮುಂದುವರಿಯಬೇಕೆ ಅಥವಾ ಬಳಕೆದಾರರಿಗೆ ಉತ್ತರಿಸಬೇಕೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಆ ಲೂಪ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಸಾಮಾನ್ಯ ನಿಯಮಗಳ ಸೆಟ್ ಇಲ್ಲದಿದ್ದರೆ, ನಿಯಂತ್ರಣ ಮೀರಿಹೋದ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ರಚಿಸುವುದು ಅಥವಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಅನಿರೀಕ್ಷಿತ ಕರೆಗಳಿಗೆ ಒಡ್ಡಿಕೊಳ್ಳುವುದು ಸುಲಭವಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಹೊಸ ಪರಿಕರವು ಕಸ್ಟಮ್ ಇಂಟಿಗ್ರೇಷನ್ ಅನ್ನು ಬಯಸುತ್ತಿತ್ತು, ಇದು ಪ್ರಾಜೆಕ್ಟ್ಗಳಾದ್ಯಂತ ಟೋಕನ್ ಬಳಕೆ, ಬಜೆಟ್ ಮಿತಿಗಳು ಅಥವಾ ಭದ್ರತಾ ನೀತಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದನ್ನು ಕಷ್ಟಕರವಾಗಿಸುತ್ತಿತ್ತು.
MCP ಆ ಲೂಪ್ನ ರಚನೆ ಮತ್ತು ಅದರ ಮೂಲಕ ಚಲಿಸಬೇಕಾದ ಡೇಟಾವನ್ನು ಸಂಹಿತೀಕರಿಸುವ ಮೂಲಕ ಆ ಕೊರತೆಗಳನ್ನು ತುಂಬುತ್ತದೆ.
MCP ಏಜೆಂಟ್ನ ಎರಡು ಭಾಗಗಳ ರಚನೆ
MCP ಏಜೆಂಟ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನ (definition) – ಏಜೆಂಟ್ ಏನು ಮಾಡಬಲ್ಲದು ಎಂಬುದನ್ನು ವಿವರಿಸುವ ಟೆಂಪ್ಲೇಟ್ – ಮತ್ತು ಇನ್ಸ್ಟೆನ್ಸ್ (instance) – ಬಳಕೆದಾರರ ವಿನಂತಿಯ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ – ಎಂದು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ.
ಏಜೆಂಟ್ ವ್ಯಾಖ್ಯಾನ (ಟೆಂಪ್ಲೇಟ್)
- Host loop – ಕೇಳು-ಪರಿಕರ-ಓದು-ನಿರ್ಧರಿಸು (ask-tool-read-decide) ಚಕ್ರವನ್ನು ನಡೆಸುವ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್.
- System context – ಮಾದರಿಯ ನಡವಳಿಕೆಯನ್ನು ರೂಪಿಸುವ ವ್ಯಕ್ತಿತ್ವ (persona) ಮತ್ತು ಉನ್ನತ ಮಟ್ಟದ ಸೂಚನೆಗಳು.
- MCP server set – ಹೋಸ್ಟ್ ಕರೆಯಬಹುದಾದ ಲಭ್ಯವಿರುವ ಪರಿಕರ ಮೂಲಗಳ ಪಟ್ಟಿ.
- Tool policy – ನಿರ್ದಿಷ್ಟ ಏಜೆಂಟ್ಗೆ ಯಾವ ಪರಿಕರಗಳು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂಬ ಸ್ಪಷ್ಟ ಪಟ್ಟಿ.
- LLM selection – ಪಠ್ಯದ ತರ್ಕವನ್ನು ರಚಿಸುವ ನಿರ್ದಿಷ್ಟ ಮಾದರಿ.
- Termination limits – ಅಂತ್ಯವಿಲ್ಲದ ಲೂಪ್ಗಳನ್ನು ತಡೆಯಲು ಗರಿಷ್ಠ ಪುನರಾವರ್ತನೆಗಳು ಮತ್ತು ಟೋಕನ್ ಬಜೆಟ್.
- Task contract – ಏಜೆಂಟ್ ಯಾವ ಇನ್ಪುಟ್ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಯಾವ ಔಟ್ಪುಟ್ ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂಬ ಔಪಚಾರಿಕ ವಿವರಣೆ.
- Context strategy – ಟೋಕನ್ ಮಿತಿಗಳ ಒಳಗೆ ಇರಲು ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸವನ್ನು ಹೇಗೆ ಕತ್ತರಿಸಬೇಕು ಅಥವಾ ಸಾರಾಂಶಗೊಳಿಸಬೇಕು ಎಂಬ ನಿಯಮಗಳು.
ಏಜೆಂಟ್ ಇನ್ಸ್ಟೆನ್ಸ್ (ಚಾಲನೆಯಲ್ಲಿರುವ ಕಾರ್ಯ)
- Goal – ಲೂಪ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಬಳಕೆದಾರರ ವಿನಂತಿ.
- Working context – ಹಿಂದಿನ ಪರಿಕರ ಫಲಿತಾಂಶಗಳು ಸೇರಿದಂತೆ ಸಂಗ್ರಹಿಸಿದ ಇತಿಹಾಸ.
- Credentials – ಆಯ್ಕರಿಸಿದ ಪರಿಕರಗಳನ್ನು ಬಳಸಲು ಅಗತ್ಯವಿರುವ ಟೋಕನ್ಗಳು ಅಥವಾ ಅನುಮತಿ ಸೆಟ್ಗಳು.
- Consumed budget – ಇದುವರೆಗೆ ಬಳಸಿದ ಟೋಕನ್ಗಳು ಮತ್ತು ತೆಗೆದುಕೊಂಡ ಹಂತಗಳ ಲೆಕ್ಕಾಚಾರ.
ಈ ಅಂಶಗಳು ಏಜೆಂಟ್ಗೆ ಏನು ಮಾಡಲು ಅನುಮತಿಸಲಾಗಿದೆ ಮತ್ತು ಅದು ಪ್ರಸ್ತುತ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ.
MCP ಅಭಿವೃದ್ಧಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸುತ್ತದೆ
MCP ಗಿಂತ ಮೊದಲು, ಒಬ್ಬ ಅಭಿವರ್ಧಕನು LLM ಅನ್ನು ಹವಾಮಾನ API ಅನ್ನು ಪ್ರಶ್ನಿಸಲು, ಡೇಟಾಬೇಸ್ನಿಂದ ಒಂದು ಸಾಲನ್ನು (row) ಪಡೆಯಲು ಮತ್ತು ನಂತರ ವರದಿಯನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಬಯಸಿದರೆ, ಪ್ರತಿ ಎಂಡ್ಪಾಯಿಂಟ್ಗಾಗಿ ಪ್ರತ್ಯೇಕವಾದ ಗ್ಲೂ ಕೋಡ್ (glue code) ಬರೆಯಬೇಕಾಗಿತ್ತು. ಆ ಕೋಡ್ ಹೆಚ್ಚಾಗಿ ಮಾದರಿಯ ಪ್ರಾಂಪ್ಟ್ನೊಳಗೆ ಪರಿಕರ ಕರೆಗಳನ್ನು (tool calls) ಮರೆಮಾಚುತ್ತಿತ್ತು, ಇದರಿಂದ ಯಾವ ವಿನಂತಿಯು ಯಾವ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪ್ರಚೋದಿಸಿತು ಎಂಬುದನ್ನು ನೋಡುವುದು ಅಸಾಧ್ಯವಾಗಿತ್ತು.
MCP ನೊಂದಿಗೆ, ಹೋಸ್ಟ್ ಸಂಭಾಷಣೆಯನ್ನು ಮಾದರಿಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಮಾದರಿಯು ರಚಿಸುವ ಯಾವುದೇ ಪರಿಕರ ವಿನಂತಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಪರಿಕರವನ್ನು ತಾನೇ ನಿಯೋಜಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಫಲಿತಾಂಶವನ್ನು ಮರಳಿ ನೀಡುತ್ತದೆ. ಹೆಚ್ಚುವರಿ ಕೋಡ್ ಕನಿಷ್ಠವಾಗಿರುತ್ತದೆ, ಆದರೆ ದೃಶ್ಯತೆ (visibility) ಸಂಪೂರ್ಣವಾಗಿರುತ್ತದೆ: ಪ್ರತಿ ರೌಂಡ್-ಟ್ರಿಪ್ ಮತ್ತು ಪ್ರತಿ ಟೋಕನ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಲಾಗುತ್ತದೆ.
ಆ ದೃಶ್ಯತೆಯು ಎರಡು ಪ್ರಾಯೋಗಿಕ ಪ್ರಯೋಜನಗಳನ್ನು ತರುತ್ತದೆ:
- Cost measurement – ಅಭಿವರ್ಧಕರು ಒಂದೇ ಕಾರ್ಯಕ್ಕಾಗಿ ಅಗ್ಗದ ಮಾದರಿಯನ್ನು ದೊಡ್ಡ ಮಾದರಿಯೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು, ಪ್ರತಿ ಪುನರಾವರ್ತನೆಯು ಎಷ್ಟು ಟೋಕನ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ನೋಡಬಹುದು.
- Security auditing – ಪರಿಕರ ನೀತಿ (tool policy) ಮತ್ತು ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಪರಿಶೀಲನೆಗಳು ಮಾದರಿಯ ಹೊರಗೆ ನಡೆಯುತ್ತವೆ, ಇದು ಮಾದರಿಯು ಅನಧಿಕೃತ ಸೇವೆಗಳನ್ನು ಮೌನವಾಗಿ ಬಳಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
ಇನ್ನೂ ವ್ಯಾಖ್ಯಾನಿಸದ ವಿಷಯಗಳು
MCP ಸಂಭಾಷಣೆಯ ರೂಪ ಮತ್ತು ಅದರೊಂದಿಗೆ ಚಲಿಸುವ ಮೆಟಾಡೇಟಾವನ್ನು (metadata) ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ, ಆದರೆ ಪರಿಕರವನ್ನು ಆಂತರಿಕವಾಗಿ ಹೇಗೆ ಅನುಷ್ಠಾನಗೊಳಿಸಬೇಕು ಎಂಬುದನ್ನು ಇದು ನಿರ್ದೇಶಿಸುವುದಿಲ್ಲ.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
- Metric suites – ಸರಣಿಯ ಮುಂದಿನ ಲೇಖನವು ಅಭಿವರ್ಧಕರು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕಾದ ಅಂಕಿಅಂಶಗಳ (ಟೋಕನ್ ವೆಚ್ಚ, ಪುನರಾವರ್ತನೆ ಸಂಖ್ಯೆ, ಪ್ರತಿ ಪರಿಕರದ ವಿಳಂಬತೆ/latency) ಪರಿಶೀಲನಾ ಪಟ್ಟಿಯನ್ನು ಭರವಸೆ ನೀಡುತ್ತದೆ. ಆ ಮೆಟ್ರಿಕ್ಗಳು ಯಾವುದೇ MCP-ಆಧಾರಿತ ಏಜೆಂಟ್ಗಳಿಗಾಗಿ ಡಿ-ಫ್ಯಾಕ್ಟೊ ಹೆಲ್ತ್ ಚೆಕ್ಗಳಾಗಲಿವೆ.
ಅಂತಿಮವಾಗಿ
Model Context Protocol એ LLM ಏಜೆಂಟ್ಗಳಿಗೆ ಏಜೆಂಟ್ ಏನು ಮಾಡಬಲ್ಲದು ಎಂಬುದನ್ನು ಅದು ಯಾವುದೇ ಕ್ಷಣದಲ್ಲಿ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದರಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ಹಂಚಿಕೆಯ, ಲೆಕ್ಕಪರಿಶೋಧಿಸಬಹುದಾದ ರಚನೆಯನ್ನು ನೀಡುತ್ತದೆ. ಅಸ್ಪಷ್ಟವಾದ ಪರಿಕರ-ಕರೆಗಳನ್ನು (tool-calling) ಪಾರದರ್ಶಕ ಲೂಪ್ ಆಗಿ ಪರಿವರ್ತಿಸುವ ಮೂಲಕ, MCP ಅಂತಹ ಅಳತೆಗಳನ್ನು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.