ದೊಡ್ಡ ಭಾಷಾ ಮಾದರಿಯನ್ನು (large language model) ಲೈವ್ ಹೊರಗಿನ ಡೇಟಾಕ್ಕೆ ಸಂಪರ್ಕಿಸುವುದು ಹೆಚ್ಚಿನ ಡೆಮೊ ವೀಡಿಯೊಗಳು ಸೂಚಿಸುವതിಗಿಂತ ಕಷ್ಟಕರವಾಗಿದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ತಂಡಗಳು ಪ್ರತಿಯೊಂದು ಮಾದರಿ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಡೇಟಾ ಮೂಲಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ಕನೆಕ್ಟರ್ ಅನ್ನು ಬರೆಯಬೇಕಾಗುತ್ತದೆ. Claude ಗಾಗಿ ಒಂದು ಅಡಾಪ್ಟರ್, GPT-4 ಗಾಗಿ ಇನ್ನೊಂದು, ಆಂತರಿಕ Postgres ಕ್ಲಸ್ಟರ್ಗಾಗಿ ಮೂರನೆಯದು ಮತ್ತು ಹಳೆಯ SOAP API ಗಾಗಿ ಮತ್ತೊಂದು. ಅರ್ಧ ಡಜನ್ ಮಾದರಿಗಳು ಮತ್ತು ಮೂರು ಅಥವಾ ನಾಲ್ಕು ಬ್ಯಾಕೆಂಡ್ಗಳ ಮೇಲೆ ಇದನ್ನು ಗುಣಾಕಾರ ಮಾಡಿದರೆ, ನೀವು ಒಂದು ದುರ್ಬಲವಾದ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದುತ್ತೀರಿ, ಇದು ಪ್ರತಿ ಬಾರಿ ವೆಂಡರ್ ಎಂಡ್ಪಾಯಿಂಟ್ ಅಥವಾ ಸ್ಕೀಮಾವನ್ನು ಬದಲಾಯಿಸಿದಾಗಲೂ ಮುರಿದುಬೀಳುತ್ತದೆ. ಈ ಚಕ್ರವನ್ನು ಕೊನೆಗೊಳಿಸಲು Anthropic ಸಂಸ್ಥೆಯು Model Context Protocol ಅನ್ನು ಪರಿಚಯಿಸಿದೆ. MCP ಯಾವುದೇ AI ವ್ಯವಸ್ಥೆಯು ಫೈಲ್ಗಳನ್ನು ಓದಲು, ಫಂಕ್ಷನ್ಗಳನ್ನು ಕರೆಯಲು ಮತ್ತು ಸಂದರ್ಭವನ್ನು (context) ವಿನಂತಿಸಲು ಬಳಸಬಹುದಾದ ಏಕೈಕ, ಪ್ರಮಾಣಿತ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನೀಡುತ್ತದೆ. OpenAI ಮತ್ತು Google DeepMind ಎರಡೂ ಇದನ್ನು ಈಗಾಗಲೇ ಅಳವಡಿಸಿಕೊಂಡಿರುವುದರಿಂದ, ನೀವು ಒಮ್ಮೆ ನಿರ್ಮಿಸಿದ ಕನೆಕ್ಟರ್ ಅನ್ನು ಅಡಿಯಲ್ಲಿರುವ ವ್ಯವಸ್ಥೆಯನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಅಗತ್ಯವಿಲ್ಲದೆ ಅನೇಕ ಮಾದರಿಗಳಿಗೆ ಬಳಸಬಹುದು.
ಮೂರು ಮೂಲಭೂತ ಅಂಶಗಳು (The Three Primitives)
MCP ಸಂಯೋಜನಾ ಸಮಸ್ಯೆಯನ್ನು (integration problem) ಮೂರು ಪ್ರಮುಖ ಕಾರ್ಯಾಚರಣೆಗಳಾಗಿ ಕುಗ್ಗಿಸುತ್ತದೆ.
ಫೈಲ್ ಓದುವುದು (File reading) ಇದು AWS S3, Google Cloud Storage ಅಥವಾ ಸ್ಥಳೀಯ ಫೈಲ್ಸಿಸ್ಟಮ್ನಿಂದ ದಾಖಲೆಗಳನ್ನು ಪಡೆಯಲು ಮಾದರಿಗೆ ಒಂದು ಪ್ರಮಾಣಿತ ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಮಾದರಿಗೆ ನಿಮ್ಮ blob store ಅಥವಾ ಡೇಟಾಬೇಸ್ ಎಕ್ಸ್ಪೋರ್ಟ್ ಅನ್ನು ಹೇಗೆ ಪಾರ್ಸ್ ಮಾಡಬೇಕೆಂದು ಕಲಿಸುವ ಬದಲು, ನೀವು ಒಮ್ಮೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಕಲಿಸಿದರೆ ಸಾಕು. ಮಾದರಿಯು ಕೇಳುತ್ತದೆ, ಸರ್ವರ್ ಅದನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಡೇಟಾ ಮೂಲತಃ ಎಲ್ಲಿಯಿದ್ದರೂ ಅದು ಒಂದೇ ಪೈಪ್ ಮೂಲಕ context window ಗೆ ಪ್ರವೇಶಿಸುತ್ತದೆ.
ಫಂಕ್ಷನ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ (Function execution) ಇದು ಮಾದರಿಗಳು ಬಾಹ್ಯ ಕ್ರಿಯೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ನೀವು ನಿಮ್ಮ CRM API, ನಿಮ್ಮ ಮಾನಿಟರಿಂಗ್ webhook ಅಥವಾ ನಿಮ್ಮ ಟಿಕೆಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಒಮ್ಮೆ ಎನ್ಕ್ಯಾಪ್ಸುಲ್ ಮಾಡಿದರೆ, ಯಾವುದೇ MCP-ಅನುಸರಣೆಯ ಏಜೆಂಟ್ ಅದನ್ನು ಬಳಸಬಹುದು. ಬಳಕೆದಾರರು, “ಟಿಕೆಟ್ 402 ರ ಸ್ಥಿತಿ ಏನು?” ಎಂದು ಕೇಳುತ್ತಾರೆ. ಮಾದರಿಯು ನಿಮ್ಮ wrapper ಅನ್ನು ಕರೆಯುತ್ತದೆ, wrapper CRM ಅನ್ನು ವಿಚಾರಿಸುತ್ತದೆ ಮತ್ತು ಉತ್ತರವು ರಚನಾತ್ಮಕ ಸಂದರ್ಭವಾಗಿ (structured context) ಮರಳುತ್ತದೆ.
ಸಂದರ್ಭೋಚಿತ ಪ್ರಾಂಪ್ಟ್ಗಳು (Contextual prompts) ಇವು context window ಅನ್ನು ತುಂಬಿಸದೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ನಿಖರವಾಗಿಡುತ್ತವೆ. ಪ್ರತಿ ವಿನಂತಿಗೆ ಐವತ್ತು ಪುಟಗಳ ಮ್ಯಾನುಯಲ್ ಅನ್ನು ಹಾಕುವ ಬದಲು, ಮಾದರಿಯು ಅದಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಭಾಗಗಳನ್ನು ಮಾತ್ರ, ಅಗತ್ಯವಿರುವ ಸಮಯದಲ್ಲಿ ವಿನಂತಿಸುತ್ತದೆ. ಇದು ಟೋಕನ್ ವೆಚ್ಚ ಮತ್ತು ವಿಳಂಬವನ್ನು (latency) ನಿಯಂತ್ರಣದಲ್ಲಿಡುತ್ತಾ, ಉತ್ತರಗಳನ್ನು ಪ್ರಸ್ತುತ ಮಾಹಿತಿಯ ಮೇಲೆ ಆಧಾರಿತಗೊಳಿಸುತ್ತದೆ.
ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನದ ಮಾರ್ಗಸೂಚಿ (A Practical Implementation Roadmap)
ನೀವು ಏಕಕಾಲಿಕ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಲು ಸಿದ್ಧರಿದ್ದರೆ, ಇಲ್ಲಿದೆಂದೇ ಪ್ರಾರಂಭಿಸಿ.
ವಿಶೇಷಣವನ್ನು (specification) ಅಧ್ಯಯನ ಮಾಡಿ. ಅಧಿಕೃತ ಉಲ್ಲೇಖವು modelcontextprotocol.io ನಲ್ಲಿ ಲಭ್ಯವಿದೆ. ಯಾವುದೇ ಪ್ರೊಡಕ್ಷನ್ ಕೋಡ್ ಬರೆಯುವ ಮೊದಲು ಅದನ್ನು ಓದಿ. ಸರ್ವರ್ಗಳು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೇಗೆ ಪ್ರಕಟಿಸುತ್ತವೆ, ಕ್ಲೈಂಟ್ಗಳು ಸೆಷನ್ಗಳನ್ನು ಹೇಗೆ ಸಂಧಾನ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು context lifecycles ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಕಡೆಗೆ ಗಮನ ಕೊಡಿ. ಹ್ಯಾಂಡ್ಶೇಕ್ ಲಾಜಿಕ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕಳೆಯುವ ಒಂದು ಗಂಟೆಯು ನಂತರದ ದಿನಗಳ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅನ್ನು ಉಳಿಸುತ್ತದೆ.
ಅಧಿಕೃತ SDK ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ. Anthropic ಸಂಸ್ಥೆಯು Python, TypeScript, Java ಮತ್ತು Go ಗಾಗಿ SDK ಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ. ಇವು wire formats, serialization ಮತ್ತು error framing ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ನೀವು ಮಾಡಬೇಕಾಗಿಲ್ಲ. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಈಗಾಗಲೇ Python-ಅಧಾರಿತವಾಗಿದ್ದರೆ, Python SDK ಅನ್ನು FastAPI services ಅಥವಾ Celery workers ಗೆ ಸುಲಭವಾಗಿ ಬಳಸಬಹುದು. TypeScript ತಂಡಗಳು MCP ಕ್ಲೈಂಟ್ ಅನ್ನು ನೇರವಾಗಿ Next.js API route ಒಳಗೆ ಅಳವಡಿಸಬಹುದು. ನಿಮ್ಮ ಸ್ಟ್ಯಾಕ್ಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಭಾಷೆಯನ್ನು ಆರಿಸಿ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಬಾಯ್ಲರ್ ಪ್ಲೇಟ್ (boilerplate) ಅನ್ನು ಲೈಬ್ರರಿ ನಿರ್ವಹಿಸಲು ಬಿಡಿ.
ಅಧಿಕಾರಪತ್ರಗಳನ್ನು (credentials) ಸುರಕ್ಷಿತಗೊಳಿಸಿ. API ಕೀಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್ ಪಾಸ್ವರ್ಡ್ಗಳನ್ನು environment variables ಅಥವಾ ಮೀಸಲಾದ secrets manager ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. ಸೋರ್ಸ್ ಫೈಲ್ಗಳಲ್ಲಿ ಎಂದಿಗೂ credentials ಅನ್ನು ಹಾರ್ಡ್ಕೋಡ್ ಮಾಡಬೇಡಿ. ಪ್ರೊಟೊಟೈಪ್ ಮಾಡುವ ಅವಸರದಲ್ಲಿ, ಟೋಕನ್ ಅನ್ನು ನೇರವಾಗಿ config dictionary ಗೆ ಪೇಸ್ಟ್ ಮಾಡುವುದು ಆಕರ್ಷಕವಾಗಿ ಕಾಣಬಹುದು, ಆದರೆ ಆ ಅಭ್ಯಾಸವು GitHub ಇತಿಹಾಸದಲ್ಲಿ ಕೀಗಳು ಸೋರಿಕೆಯಾಗಲು ಕಾರಣವಾಗುತ್ತದೆ. ಸ್ಥಳೀಯ ಕೆಲಸಕ್ಕಾಗಿ .env ಫೈಲ್ಗಳನ್ನು ಬಳಸಿ ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ನಿಮ್ಮ orchestration layer ಮೂಲಕ ವೇರಿಯೇಬಲ್ಗಳನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡಿ. ಕೀಗಳನ್ನು ನಿಗದಿತ ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ಬದಲಾಯಿಸಿ (rotate) ಮತ್ತು ಪ್ರತಿಯೊಂದು ಕೀ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ.
ಲಾಜಿಕ್ ಬರೆಯುವ ಮೊದಲು ನಿಮ್ಮ ಪರಿಸರವನ್ನು (terrain) ನಕ್ಷೆ ಮಾಡಿ. ಮಾದರಿಯು ಸ್ಪರ್ಶಿಸುವ ಪ್ರತಿಯೊಂದು ಬಾಹ್ಯ ಎಂಡ್ಪಾಯಿಂಟ್, ಪ್ರತಿ ಡೇಟಾ ಪ್ರಕಾರದ ಸ್ಕೀಮಾ ಮತ್ತು ನೀವು ಗೌರವಿಸಬೇಕಾದ ರೇಟ್ ಲಿಮಿಟ್ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ಒಂದು ಸರಳ ಡೇಟಾ-ಫ್ಲೋ ಡೈಗ್ರಾಮ್ ಅನ್ನು ಬಿಡಿಸಿ. ನಿಮ್ಮ inventory API ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ 100 ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸಿದರೆ, ಆ ನಿರ್ಬಂಧವು ನಿಮ್ಮ ಕನೆಕ್ಟರ್ ವಿಫಲವಾದ ಕರೆಗಳನ್ನು ಎಷ್ಟು ತೀವ್ರವಾಗಿ ಮರುಪ್ರಯತ್ನಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬೇಕು. ನಿಮ್ಮ ಡೇಟಾದ ಸ್ವರೂಪ ಮತ್ತು ನಿಮ್ಮ ಅವಲಂಬನೆಗಳ (dependencies) ಸವಾಲುಗಳನ್ನು ಮೊದಲೇ ತಿಳಿದಿರುವುದು ಅನಿರೀಕ್ಷಿತ ವ್ಯತ್ಯಯಗಳನ್ನು ತಡೆಯುತ್ತದೆ.
ಯಶಸ್ಸನ್ನು ನಿರ್ಧರಿಸುವ ವಿನ್ಯಾಸದ ಆಯ್ಕೆಗಳು (Design Choices That Determine Success)
ಒಮ್ಮೆ ಸ್ಕ್ಯಾಫೋಲ್ಡಿಂಗ್ (scaffolding) ಸಿದ್ಧವಾದ ನಂತರ, ವ್ಯವಸ್ಥೆಯು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆಯೇ ಅಥವಾ ದುರ್ಬಲವಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ವಿವರಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ.
ಪ್ರಾಂಪ್ಟ್ ವಿನ್ಯಾಸ (Prompt design). ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ಗಳು ಮಾದರಿಯು ಯಾವಾಗ ಡೇಟಾವನ್ನು ಪಡೆಯಬೇಕು ಮತ್ತು ಯಾವ ಟೂಲ್ ಅನ್ನು ಬಳಸಬೇಕು ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತಿಳಿಸಬೇಕು. “check the database” ಎಂಬ ಅಸ್ಪ𝙙 ಸೂಚನೆಯು ಮಾದರಿಯನ್ನು ಊಹಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. “Before answering pricing questions, call the get_latest_pricing function and include the effective_date field,” ಎಂಬ ನಿಖರವಾದ ಸೂಚನೆಯು ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಹೋಗಲಾಡಿಸುತ್ತದೆ. ಮಾದರಿಯು ಟೂಲ್ ಆಯ್ಕೆಯಲ್ಲಿ ಕಷ್ಟಪಡುತ್ತಿದ್ದರೆ, ನಿಖರವಾದ ಫಂಕ್ಷನ್ ಕಾಲ್ ಸಿಂಟ್ಯಾಕ್ಸ್ ಮತ್ತು ನಿರೀಕ್ಷಿತ ಆರ್ಗ್ಯುಮೆಂಟ್ಗಳನ್ನು ತೋರಿಸುವ ಒಂದು ಅಥವಾ ಎರಡು ಉದಾಹರಣೆಗಳನ್ನು ಪ್ರಾಂಪ್ಟ್ ಒಳಗೆ ಸೇರಿಸಿ.
ಫೈಲ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ (File handling). ಪ್ರತಿ ಸ್ಟೋರೇಜ್ ಬ್ಯಾಕ್ಎಂಡ್ಗಾಗಿ (storage backend) ಲಘು ಅನುವಾದಕ ಹ್ಯಾಂಡ್ಲರ್ಗಳನ್ನು (translation handlers) ನಿರ್ಮಿಸಿ. ಮಾಡೆಲ್ ದೊಡ್ಡ PDF ಅಥವಾ ಲಾಗ್ ಫೈಲ್ ಅನ್ನು ವಿನಂತಿಸಿದಾಗ, ಇಡೀ ರೊ (raw) ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋಗೆ (context window) ಸ್ಟ್ರೀಮ್ ಮಾಡಬೇಡಿ. ದೊಡ್ಡ ಫೈಲ್ಗಳನ್ನು ಸಣ್ಣ ತುಣುಕುಗಳಾಗಿ ವಿಂಗಡಿಸಿ—ಬಹುಶಃ ಪುಟ, ಸೆಕ್ಷನ್ ಹೆಡರ್ ಅಥವಾ ಸಮಯದ ವಿಂಡೋ ಆಧಾರದ ಮೇಲೆ—ಮತ್ತು ಕೇವಲ ಸಂಬಂಧಿತ ಭಾಗಗಳನ್ನು ಮಾತ್ರ ಹಿಂತಿರುಗಿಸಿ. ಇದರಿಂದ ನೀವು ಟೋಕನ್ ವೆಚ್ಚವನ್ನು (token costs) ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯ ವಿಳಂಬವನ್ನು (response latency) ಸ್ವೀಕಾರಾರ್ಹ ಮಿತಿಯಲ್ಲಿಡಬಹುದು.
ಫಂಕ್ಷನ್ ವ್ರ್ಯಾಪರ್ಗಳು (Function wrappers). ನೆಟ್ವರ್ಕಿಂಗ್ ಸಮಸ್ಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ವ್ರ್ಯಾಪರ್ನ (wrapper) ಹಿಂದೆ ಪ್ರತಿಯೊಂದು ಎಕ್ಸ್ಟರ್ನಲ್ API ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ಒಂದು ವೇಳೆ ಡೌನ್ಸ್ಟ್ರೀಮ್ ಸೇವೆ (downstream service) ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳ ನಂತರ ಟೈಮ್ಔಟ್ ಆದರೆ, ನಿಮ್ಮ ವ್ರ್ಯಾಪರ್ ಆ ಎಕ್ಸೆಪ್ಶನ್ ಅನ್ನು ಹಿಡಿದು (catch), ಘಟನೆಯನ್ನು ಲಾಗ್ ಮಾಡಬೇಕು ಮತ್ತು ಮಾಡೆಲ್ ಪಾರ್ಸ್ ಮಾಡಬಹುದಾದ ರಚನಾತ್ಮಕ JSON ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು. ರೊ ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ಗಳು (Raw stack traces) LLMಗಳನ್ನು ಗೊಂದಲಕ್ಕೀಡುಮಾಡುತ್ತವೆ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಭ್ರಮಿತ ಪರಿಹಾರಗಳನ್ನು (hallucinated workarounds) ಪ್ರಚೋದಿಸುತ್ತವೆ. status, retry_after, ಮತ್ತು message ನಂತಹ ಫೀಲ್ಡ್ಗಳಿರುವ ಸ್ವಚ್ಛವಾದ ಪ್ರತಿಕ್ರಿಯೆಯು, ಮಾಡೆಲ್ ಮರುಪ್ರಯತ್ನಿಸಬೇಕೆ ಅಥವಾ ಬಳಕೆದಾರರಿಂದ ಸ್ಪಷ್ಟೀಕರಣ ಕೇಳಬೇಕೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಭದ್ರತೆಯು ಕೇವಲ ನಂತರದ ಆಲೋಚನೆಯಲ್ಲ (Security Is Not an Afterthought)
AI ಗೆ ಲೈವ್ ಡೇಟಾವನ್ನು ಒಡ್ಡಲು ಶಿಸ್ತು ಅಗತ್ಯವಿದೆ.
ಕನಿಷ್ಠ-ಅಧಿಕಾರ ಪ್ರವೇಶವನ್ನು (least-privilege access) ಅಳವಡಿಸಿಕೊಳ್ಳಿ. AI ಲೇಯರ್ಗಾಗಿ ಮೀಸಲಾದ ಸರ್ವಿಸ್ ಅಕೌಂಟ್ಗಳನ್ನು ರಚಿಸಿ. ಮಾಡೆಲ್ಗೆ ಕೇವಲ ಪ್ರಾಡಕ್ಟ್ ಕ್ಯಾಟಲಾಗ್ ಓದುವ ಅಗತ್ಯವಿದ್ದರೆ, ಅದಕ್ಕೆ ರೈಟ್ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಸ್ (write credentials) ನೀಡಬೇಡಿ. ನೆಟ್ವರ್ಕ್ ಪಾಲಿಸಿಗಳನ್ನು ಎಷ್ಟು ಮಿತಿಗೊಳಿಸಬೇಕೆಂದರೆ, ಕನೆಕ್ಟರ್ ತನ್ನ ಅಧಿಕಾರ ವ್ಯಾಪ್ತಿಯ ಹೊರಗಿರುವ ಇಂಟರ್ನಲ್ ಅಡ್ಮಿನ್ ಪ್ಯಾನಲ್ಗಳು ಅಥವಾ ಬಿಲ್ಲಿಂಗ್ ಸಿಸ್ಟಮ್ಗಳನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಾಗಬಾರದು.
ಪ್ರತಿಯೊಂದು ಕ್ರಮವನ್ನು ಲಾಗ್ ಮಾಡಿ. ಪ್ರತಿಯೊಂದು ಡೇಟಾ ಪ್ರವೇಶ ಮತ್ತು ಫಂಕ್ಷನ್ ಕಾಲ್ಗಾಗಿ ಆಡಿಟ್ ಟ್ರೈಲ್ (audit trail) ನಿರ್ಮಿಸಿ. ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್, ಸೆಷನ್ ಅಥವಾ ಬಳಕೆದಾರರ ಐಡೆಂಟಿಫೈಯರ್, ಬಳಸಲಾದ ಟೂಲ್ ಮತ್ತು ಪರಿಣಾಮಕ್ಕೊಳಗಾದ ರೆಕಾರ್ಡ್ಗಳ ವ್ಯಾಪ್ತಿಯನ್ನು ದಾಖಲಿಸಿ. ಬಳಕೆದಾರರು ನಂತರ ಮಾಡೆಲ್ ಏಕೆ ಹಳೆಯ ಬೆಲೆಯನ್ನು ಉಲ್ಲೇಖಿಸಿತು ಅಥವಾ ಅಳಿಸಿಹಾಕಲಾದ ರೆಕಾರ್ಡ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಿತು ಎಂದು ಕೇಳಿದಾಗ, ಯಾವ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಬಳಸಲಾಗಿತ್ತು ಮತ್ತು ಅದು ಏನನ್ನು ಹಿಂತಿರುಗಿಸಿತು ಎಂಬುದನ್ನು ನಿಮ್ಮ ಲಾಗ್ಗಳು ನಿಖರವಾಗಿ ಬಹಿರಂಗಪಡಿಸಬೇಕು.
ಕಳುಹಿಸುವ ಮೊದಲು ಸ್ಯಾನಿಟೈಸ್ (Sanitize) ಮಾಡಿ. ಡೇಟಾ ಮಾಡೆಲ್ಗೆ ತಲುಪುವ ಮೊದಲೇ ಕನೆಕ್ಟರ್ ಲೇಯರ್ನ ಒಳಗೇ ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಅನಾಮಧೇಯಗೊಳಿಸಿ (Anonymize) ಅಥವಾ ಟೋಕನೈಸ್ (tokenize) ಮಾಡಿ. ಕೆಲಸಕ್ಕೆ ಕಡ್ಡಾಯವಾಗಿ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ ಹೆಸರುಗಳು, ಇಮೇಲ್ ವಿಳಾಸಗಳು, ಫೋನ್ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಅಕೌಂಟ್ ಐಡೆಂಟಿಫೈಯರ್ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ. ಹೆಲ್ತ್ಕೇರ್, ಫೈನಾನ್ಸ್ ಅಥವಾ ಕಾನೂನು ಸಂಬಂಧಿತ ಕೆಲಸಗಳನ್ನು ನಿರ್ವಹಿಸುವಾಗ ಈ ಹಂತವು ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಾಗುತ್ತದೆ. ಸ್ಕ್ರಬ್ಬಿಂಗ್ ಅನ್ನು ಕನೆಕ್ಟರ್ನ ಒಳಗೇ ಮಾಡಿ, ಪ್ರಾಂಪ್ಟ್ ಟೆಂಪ್ಲೇಟ್ನ ಒಳಗಲ್ಲ; ಏಕೆಂದರೆ ಅಲ್ಲಿ ಅಜಾಗರೂಕ ಡೆವಲಪರ್ ಅದನ್ನು ಅಚಾನಕ್ಕಾಗಿ ಬಿಟ್ಟುಬಿಡಬಹುದು.
ಪರೀಕ್ಷೆ ಮತ್ತು ರೋಲ್ಔಟ್ (Testing and Rollout)
ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಕನೆಕ್ಟರ್ ಪ್ರೊಡಕ್ಷನ್ ಲೋಡ್ (production load) ಅಡಿಯಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು.
ಎರಡು ಹಂತಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ. ಮಾಕ್ಡ್ ಎಂಡ್ಪಾಯಿಂಟ್ಗಳನ್ನು (mocked endpoints) ಬಳಸಿ ಪ್ರತಿ ಕನೆಕ್ಟರ್ಗಾಗಿ ಯೂನಿಟ್ ಟೆಸ್ಟ್ಗಳನ್ನು ಬರೆಯಿರಿ. ನೈಜ API ಕೋಟಾಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡದೆ ಸ್ಕೀಮಾ ವ್ಯಾಲಿಡೇಶನ್, ಟೈಮ್ಔಟ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಮತ್ತು ರಿಟ್ರೈ ಲಾಜಿಕ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ. ನಂತರ ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್ಗಳನ್ನು ನಡೆಸಿರಿ, ಇದು ಪೂರ್ಣ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ: ನ್ಯಾಚುರಲ್-ಲ್ಯಾಂಗ್ವೇಜ್ ಕ್ವೆರಿ, ಮಾಡೆಲ್ ರೀಸನಿಂಗ್, ಟೂಲ್ ಸೆಲೆಕ್ಷನ್, ಎಕ್ಸ್ಟರ್ನಲ್ ಕಾಲ್ ಮತ್ತು ಅಂತಿಮ ಪ್ರತಿಕ್ರಿಯೆ. ಇವುಗಳನ್ನು ಪ್ರೊಡಕ್ಷನ್ ರೇಟ್ ಲಿಮಿಟ್ಗಳು ಮತ್ತು ವಿಳಂಬವನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ ಸ್ಟೇಜಿಂಗ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ನಲ್ಲಿ (staging environment) ರನ್ ಮಾಡಿ.
ಹಂತ ಹಂತವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಿ. ಪರೀಕ್ಷೆಗಳು ಪಾಸಾದ ನಂತರವೂ, ನಿಮ್ಮ ಮೊದಲ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಅನ್ನು ಕೇವಲ ಸಣ್ಣ ಗುಂಪಿನ ಆಂತರಿಕ ಬಳಕೆದಾರರಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ಕೆಲವು ದಿನಗಳ ಕಾಲ ವಿಳಂಬ (latency), ದೋಷದ ದರ (error rates) ಮತ್ತು ಟೋಕನ್ ಬಳಕೆಯನ್ನು ಗಮನಿಸಿ. ನೈಜ ಟ್ರಾಫಿಕ್ ಪ್ಯಾಟರ್ನ್ಗಳೊಂದಿಗೆ ಮಾತ್ರ ಕಂಡುಬರುವ ಎಡ್ಜ್ ಕೇಸ್ಗಳನ್ನು (edge cases) ಸರಿಪಡಿಸಿ. ಮೆಟ್ರಿಕ್ಗಳು ಸ್ಥಿರವಾಗಿ ಕಂಡ ನಂತರ, ಹೆಚ್ಚಿನ ಬಳಕೆದಾರರಿಗೆ ಪ್ರವೇಶವನ್ನು ವಿಸ್ತರಿಸಿ.
ನಿಜವಾದ ಪ್ರಯೋಜನ (The Real Payoff)
MCP ಎಲ್ಲಾ ಇಂಟಿಗ್ರೇಷನ್ ಸವಾಲುಗಳನ್ನು ಹೋಗಲಾಡಿಸುವುದಿಲ್ಲ, ಆದರೆ ಮಾಡೆಲ್ಗಳನ್ನು ಎಕ್ಸ್ಟರ್ನಲ್ ಸಿಸ್ಟಮ್ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುವ ಗೊಂದಲಮಯ ಕೆಲಸವನ್ನು ಒಂದೇ, ಸ್ಥಿರವಾದ ಲೇಯರ್ಗೆ ತರುತ್ತದೆ. ಪ್ರತಿ ಹೊಸ ಮಾಡೆಲ್ ಬಿಡುಗಡೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ದುರ್ಬಲ ಅಡಾಪ್ಟರ್ಗಳನ್ನು ಮರುನಿರ್ಮಿಸುವುದನ್ನು ನೀವು ನಿಲ್ಲಿಸುತ್ತೀರಿ. ನಿಮ್ಮ ಇಂಜಿನಿಯರಿಂಗ್ ತಂಡವು ಕಸ್ಟಮ್ ಗ್ಲೂ ಕೋಡ್ (custom glue code) ಡಿಬಗ್ ಮಾಡಲು ಕಡಿಮೆ ಸಮಯವನ್ನು ಮತ್ತು ನಿಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ವಿಭಿನ್ನಗೊಳಿಸುವ ಫೀಚರ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಹೆಚ್ಚು ಸಮಯವನ್ನು ವ್ಯಯಿಸುತ್ತದೆ. ಎಂಟರ್ಪ್ರೈಸ್ AI ಗೆ ನಿಜವಾಗಿಯೂ ಬೇಕಾದ ಅಡಿಪಾಯ ಇದಾಗಿದೆ.