ಒಂದು AI ಏಜೆಂಟ್ ತನ್ನದೇ ಆದ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳನ್ನು (credentials) ಹೊತ್ತುಕೊಂಡು ನೇರವಾಗಿ ಬಾಹ್ಯ ಸೇವೆಗಳಿಗೆ ಸಂಪರ್ಕಿಸಿದಾಗ, ಅದು ಉದ್ಯೋಗಿ ಸಾಫ್ಟ್ವೇರ್ನಂತೆ ವರ್ತಿಸದೆ, ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಕರಿಲ್ಲದ ಮತ್ತು ಕಾರ್ಪೊರೇಟ್ ಕಾರ್ಡ್ ಹೊಂದಿರುವ ಒಬ್ಬ ಗುತ್ತಿಗೆದಾರನಂತೆ ವರ್ತಿಸುತ್ತದೆ. ಅದು ಏನನ್ನು ಬಳಸಿದೆ, ಯಾರು ಪ್ರವೇಶವನ್ನು ಅನುಮೋದಿಸಿದರು ಅಥವಾ ಒಂದು ಸಂಭಾಷಣೆಯು ಇನ್ನೊಂದಕ್ಕಿಂತ ಹತ್ತು ಪಟ್ಟು ಹೆಚ್ಚು ವೆಚ್ಚ ಏಕೆ ಉಂಟುಮಾಡಿತು ಎಂಬುದನ್ನು ನೀವು ನೋಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಲಾಗ್ಗಳು (logs) ಡಜನ್ ಗಟ್ಟಲೆ ಸೇವೆಗಳಲ್ಲಿ ಚದುರಿಹೋಗುತ್ತವೆ. ಪ್ರಶ್ನೆಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ.
ಏಜೆಂಟ್ ವಾಸ್ತವವಾಗಿ ಯಾವ ಟೂಲ್ ಅನ್ನು ಬಳಸಿತು? ಆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸಲು ಅದಕ್ಕೆ ಯಾರು ಅನುಮತಿ ನೀಡಿದರು? ಸೋಮವಾರದ ಬಳಕೆ ಐದು ಟೋಕನ್ಗಳಾಗಿದ್ದರೆ, ಮಂಗಳವಾರದ ಬಳಕೆ ಏಕೆ ನಲವತ್ತು ಸಾವಿರ ಟೋಕನ್ಗಳನ್ನು ಬಳಸಿತು? ನಾವು ನಿಜವಾಗಿಯೂ ಎಷ್ಟು ಖರ್ಚು ಮಾಡಿದ್ದೇವೆ?
ಬಳಕೆದಾರರು, ಮಾಡೆಲ್ಗಳು ಮತ್ತು ಸೇವೆಗಳ ನಡುವೆ ಒಂದು ಕೇಂದ್ರ ನಿಯಂತ್ರಣ ಪದರ (central control layer) ಇಲ್ಲದಿದ್ದರೆ, ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರ ಸಿಗುವುದಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಸಂಪರ್ಕವನ್ನು ಒಮ್ಮೆಲೇ ನೋಂದಾಯಿಸುವ, ಏಜೆಂಟ್ಗೆ ನಿಜವಾಗಿಯೂ ಬೇಕಾದ ಸೀಮಿತ ಕಾರ್ಯಗಳನ್ನು (functions) ಮಾತ್ರ ಒದಗಿಸುವ ಮತ್ತು ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಪೂರ್ಣವಾಗಿ ದಾಖಲಿಸುವ ಒಂದು ಏಕೈಕ ಪ್ಲೇನ್ (single plane) ನಿಮಗೆ ಬೇಕಾಗುತ್ತದೆ. ಈ ಲೇಖನವು deco Studio ಅನ್ನು ಆ ಸ್ಥಳೀಯ ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ಆಗಿ ಬಳಸುವ ಸುಧಾರಿತ ಲ್ಯಾಬ್ ಅನ್ನು ವಿವರಿಸುತ್ತದೆ. ನೀವು ಅದನ್ನು ಸೆಟಪ್ ಮಾಡುತ್ತೀರಿ, ಸುರಕ್ಷಿತ Model Context Protocol ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುತ್ತೀರಿ, ಕೇವಲ ಒಂದು ಅನುಮತಿಸಲಾದ ಫಂಕ್ಷನ್ ಅನ್ನು ಮಾತ್ರ ಪ್ರದರ್ಶಿಸುತ್ತೀರಿ ಮತ್ತು ಏಜೆಂಟ್ ತನ್ನ ಮಿತಿಯನ್ನು ಮೀರಿ ಹೋಗಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸುತ್ತೀರಿ.
ಚದುರಿಹೋಗಿರುವ ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳ ಸಮಸ್ಯೆ
ಒಂದು ಸಾಮಾನ್ಯ ತಂಡದ ವ್ಯವಸ್ಥೆಯನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಒಬ್ಬ ಡೆವಲಪರ್ ವೈಯಕ್ತಿಕ ಕೀ (personal key) ಬಳಸಿ ಏಜೆಂಟ್ ಅನ್ನು ಸರ್ಚ್ API ಗೆ ಸಂಪರ್ಕಿಸುತ್ತಾನೆ. ಇನ್ನೊಬ್ಬರು ಡೆಮೊವು ಹಾನಿಕಾರಕವಾಗಿ ಕಾಣಿಸದ ಕಾರಣ ಅದೇ ಏಜೆಂಟ್ ಅನ್ನು ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್ಗೆ ಜೋಡಿಸುತ್ತಾರೆ. ಮೂರನೆಯವರು ಏಜೆಂಟ್ "ಇನ್ವಾಯ್ಸ್ಗಳಿಗೆ ಸಹಾಯ ಮಾಡಲು" ಬಿಲ್ಲಿಂಗ್ ಲುಕ್ಅಪ್ ಟೂಲ್ ಅನ್ನು ಸೇರಿಸುತ್ತಾರೆ. ಪ್ರತಿಯೊಂದು ಸಂಪರ್ಕವು ಇತರರಿಗೆ ಅತೀಂದ್ರಿಯವಾಗಿರುತ್ತದೆ. ಈಗ ಏಜೆಂಟ್ಗೆ ಸರ್ಚ್, ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾ ಮತ್ತು ಹಣಕಾಸಿನ ದಾಖಲೆಗಳಿಗೆ ನೇರ ಪ್ರವೇಶವಿದೆ, ಆದರೆ ತಂಡದ ಬಳಿ ಯಾವುದು ಲೈವ್ ಇದೆ ಎಂಬ ಏಕೀಕೃತ ಪಟ್ಟಿಯಿಲ್ಲ.
ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳು ಏಜೆಂಟ್ನ ಒಳಗೇ ಇದ್ದಾಗ, ಆಡಳಿತ (governance) ಕುಸಿಯುತ್ತದೆ. ಕೀ ಏಜೆಂಟ್ನ ಮೆಮೊರಿ ಅಥವಾ ಅದರ ಲೋಕಲ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ ಫೈಲ್ನಲ್ಲಿ ಇರುವುದರಿಂದ ನೀವು ಪ್ರವೇಶವನ್ನು ಕೇಂದ್ರವಾಗಿ ಹಿಂಪಡೆಯಲು (revoke) ಸಾಧ್ಯವಿಲ್ಲ. ಬಾಹ್ಯ ಸೇವೆಯು ಕೇವಲ ಅನಾಮಧೇಯ ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೈಂಟ್ನಿಂದ ಬಂದ API ಕಾಲ್ ಅನ್ನು ಮಾತ್ರ ನೋಡುವುದರಿಂದ ನೀವು ಬಳಕೆಯನ್ನು ಆಡಿಟ್ (audit) ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ವೆಚ್ಚದ ಅನಿರೀಕ್ಷಿತ ಏರಿಕೆಗಳು ದಿನಗಳ ನಂತರ ಕ್ಲೌಡ್ ಬಿಲ್ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಅಷ್ಟರ ಹೊತ್ತಿಗೆ ಯಾವ ಪ್ರಾಂಪ್ಟ್ (prompt) ಈ ಏರಿಕೆಗೆ ಕಾರಣವಾಯಿತು ಎಂಬುದು ಯಾರಿಗೂ ನೆನಪಿರುವುದಿಲ್ಲ.
deco Studio ನಲ್ಲಿ ನಿಮ್ಮ ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು
deco Studio ಒಂದು ಲೋಕಲ್ ಹಬ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೂಲಕ ಇದನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. ನೀವು ಇದನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಯಂತ್ರದಲ್ಲಿ ರನ್ ಮಾಡಬಹುದು ಮತ್ತು ಇದು ಕಾನ್ಫಿಗರೇಶನ್ಗಳು ಇರುವ ಏಕೈಕ ಸ್ಥಳವಾಗುತ್ತದೆ. ಏಜೆಂಟ್ಗಳಾದ್ಯಂತ API ಕೀಗಳು ಮತ್ತು ಟೂಲ್ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು (tool definitions) ಚದುರಿಸುವ ಬದಲು, ನೀವು ಸ್ಟುಡಿಯೋದಲ್ಲಿ ಒಮ್ಮೆ ಸಂಪರ್ಕವನ್ನು ನೋಂದಾಯಿಸುತ್ತೀರಿ. ನಂತರ ಪ್ರತಿ ಏಜೆಂಟ್ ಯಾವ ಫಂಕ್ಷನ್ಗಳನ್ನು ನೋಡಬಹುದು ಎಂಬುದನ್ನು ನೀವು ನಿಖರವಾಗಿ ನಿರ್ಧರಿಸುತ್ತೀರಿ.
ಇದನ್ನು ಒಂದು ಸ್ವಿಚ್ಬೋರ್ಡ್ ಅನ್ನು ಇನ್ಸ್ಟಾಲ್ ಮಾಡುವುದಕ್ಕೆ ಹೋಲಿಸಬಹುದು. ಎಲ್ಲಾ ವೈರ್ಗಳು ಒಂದೇ ಕೋಣೆಗೆ ಬರುತ್ತವೆ. ಯಾವ ಲೈನ್ಗಳು ಯಾವ ಇಲಾಖೆಗಳಿಗೆ ಸಂಪರ್ಕ ಹೊಂದಿರಬೇಕು ಎಂಬುದನ್ನು ನೀವು ಆಯ್ಕೆ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಪ್ರತಿ ಕಾಲ್ನ ದಾಖಲೆಯನ್ನು ನೀವು ಇಟ್ಟುಕೊಳ್ಳುತ್ತೀರಿ.
ಮೊದಲು deco Studio ಅನ್ನು ಲೋಕಲ್ ಆಗಿ ರನ್ ಮಾಡುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. ಅದು ಸಿದ್ಧವಾದ ನಂತರ, ನೀವು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕೇಂದ್ರೀಕರಿಸುತ್ತೀರಿ. ಟೂಲ್ ಬಳಸಲು ಬಯಸುವ ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಈಗ ನೇರವಾಗಿ ಬಾಹ್ಯ ಸೇವೆಯನ್ನು ಕೇಳುವ ಬದಲು ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ಅನ್ನು ಕೇಳಬೇಕು. ಇದು ತಕ್ಷಣವೇ ನೀವು ಗಮನಿಸಲು (observe), ಫಿಲ್ಟರ್ ಮಾಡಲು ಮತ್ತು ಲಾಗ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವ ಒಂದು ಚೋಕ್ಪಾಯಿಂಟ್ (chokepoint) ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಸುರಕ್ಷಿತ MCP ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುವುದು
ಈ ಲ್ಯಾಬ್ನಲ್ಲಿ, ನೀವು Model Context Protocol ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುತ್ತೀರಿ. ಮಾಡೆಲ್ಗಳು ಬಾಹ್ಯ ಟೂಲ್ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು MCP ಒಂದು ಓಪನ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಆಗಿದೆ, ಆದರೆ ಸ್ಟ್ಯಾಂಡರ್ಡ್ಗಳು ಸುರಕ್ಷತೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಇಲ್ಲಿನ ನಿರ್ಣಾಯಕ ಹಂತವೆಂದರೆ ಆಯ್ಕೆ ಮಾಡುವಿಕೆ (selectivity). ಸರ್ವರ್ ನೀಡುವ ಪ್ರತಿಯೊಂದು ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು (endpoint) ನೀವು ಕುರುಡಾಗಿ ಪ್ರದರ್ಶಿಸುವುದಿಲ್ಲ. ನೀವು ಸರ್ವರ್ ಅನ್ನು deco Studio ನಲ್ಲಿ ನೋಂದಾಯಿಸುತ್ತೀರಿ, ನಂತರ ನಿಮ್ಮ ಟೆಸ್ಟ್ ಏಜೆಂಟ್ಗೆ ಕೇವಲ ಒಂದು ಅನುಮತಿಸಲಾದ ಫಂಕ್ಷನ್ ಅನ್ನು ಮಾತ್ರ ಪ್ರದರ್ಶಿಸುತ್ತೀರಿ.
ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ MCP ಸರ್ವರ್ ಹತ್ತು ಫಂಕ್ಷನ್ಗಳನ್ನು ನೀಡಬಹುದು: ಫೈಲ್ ಓದುವುದು (file read), ಫೈಲ್ ಬರೆಯುವುದು (file write), ಡೇಟಾಬೇಸ್ ಕ್ವೆರಿ (database query), ನೆಟ್ವರ್ಕ್ ಫೆಚ್ (network fetch) ಮತ್ತು ಇತರವುಗಳು. ನೀವು ಒಂದು ಹಾನಿಕಾರಕವಲ್ಲದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೀರಿ, ಬಹುಶಃ ಒಂದು ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ಡ್ ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಅಥವಾ ಸಿಂಥೆಟಿಕ್ ಡೇಟಾ ವಿರುದ್ಧದ ರೀಡ್-ಓನ್ಲಿ ಲುಕ್ಅಪ್ ಅನ್ನು ನೀವು ಮಾತ್ರ ಪ್ರದರ್ಶಿಸುತ್ತೀರಿ. ಉಳಿದ ಒಂಬತ್ತು ಏಜೆಂಟ್ಗೆ ಅತೀಂದ್ರಿಯವಾಗಿರುತ್ತವೆ. ಏಜೆಂಟ್ ಅವುಗಳಿಗಾಗಿ ಕೇಳಿದರೆ, ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ಕಠಿಣ ನಿರಾಕರಣೆಯನ್ನು (hard refusal) ನೀಡುತ್ತದೆ.
ಇದು 'principle of least privilege' ಅನ್ನು ಯಾಂತ್ರಿಕಗೊಳಿಸುವುದಾಗಿದೆ. ಏಜೆಂಟ್ ಸಾಮರ್ಥ್ಯವನ್ನು (capability) ವಿನಯಪೂರ್ವಕ ಸೂಚನೆಯ ಮೂಲಕವಲ್ಲದೆ, ಸಾಫ್ಟ್ವೇರ್ ಮಿತಿಯ (software boundary) ಮೂಲಕ ಪಡೆಯುತ್ತದೆ.
ಮಿತಿಯನ್ನು ಪರೀಕ್ಷಿಸುವುದು
ಒಂದು ಟೆಸ್ಟ್ ಏಜೆಂಟ್ ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಅದನ್ನು ನಿಮ್ಮ deco Studio ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ಗೆ ಕಳುಹಿಸಿ. ಅನುಮತಿಸಲಾದ ಏಕೈಕ ಫಂಕ್ಷನ್ ಅಗತ್ಯವಿರುವ ಕೆಲಸವನ್ನು ಅದಕ್ಕೆ ನೀಡಿ. ಅದು ಯಶಸ್ವಿಯಾಗುವುದನ್ನು ಗಮನಿಸಿ. ಸ್ಟುಡಿಯೋ ಒಳಗಿನ ಲಾಗ್ಗಳು ಮಾಡೆಲ್ ವಿನಂತಿ (model request), ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ಮೂಲಕ ಟೂಲ್ ಕಾಲ್ ರೂಟಿಂಗ್, ಫಂಕ್ಷನ್ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ ಮತ್ತು ಮಾಡೆಲ್ಗೆ ಹಿಂತಿರುಗುವ ಫಲಿತಾಂಶವನ್ನು ತೋರಿಸುತ್ತವೆ. ನೀವು ಇಡೀ ಹಾದಿಯನ್ನು ಒಂದೇ ಸತತ ಟ್ರೇಸ್ನಲ್ಲಿ (continuous trace) ಓದಬಹುದು.
ಈಗ ಏಜೆಂಟ್ಗೆ ನೀವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹೊರಗಿಟ್ಟಿರುವ ಫಂಕ್ಷನ್ ಅಗತ್ಯವಿರುವ ಎರಡನೇ ಕಾರ್ಯವನ್ನು ನೀಡಿ. ಏಜೆಂಟ್ ಆ ಮಿತಿಯನ್ನು ಮೀರಿச் செயல்பಡಲು ಪ್ರಯತ್ನಿಸಬಹುದು ಅಥವಾ ಆ ಟೂಲ್ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ಭ್ರಮಿಸಬಹುದು (hallucinate). ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲೂ, ಕರಲ್ (call) ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ಗೆ ತಲುಪುತ್ತದೆ, ಅಲೋಲಿಸ್ಟ್ (allowlist) ಅದನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ ಮತ್ತು ಕಾರ್ಯವು ವಿಫಲವಾಗುತ್ತದೆ. ಈ ವಿಫಲತೆಯೇ ನಿಮ್ಮ ಮಿತಿ ಸಾಫ್ಟ್ವೇರ್ ಮೂಲಕ ಜಾರಿಗೆ ತರಲಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಾಗಿದೆ, ಇದು ಕೇವಲ ಸೈದ್ಧಾಂತಿಕವಲ್ಲ.
ಇದನ್ನು ಮೊದಲು ಸಿಂಥೆಟಿಕ್ (synthetic) ಕಾರ್ಯಗಳೊಂದಿಗೆ ಮಾಡಿ. ಜನರೇಟ್ ಮಾಡಿದ ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್ಗಳಿಂದ ಕೂಡಿದ ಒಂದು ನಕಲಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಏಜೆಂಟ್ಗೆ ಅದನ್ನು ಕ್ವೇರಿ ಮಾಡಲು ಬಿಡಿ. ಅಲೋಲಿಸ್ಟ್ ಮತ್ತು ತಿರಸ್ಕಾರಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಮಿತಿಯನ್ನು ನೀವು ನಂಬಿದ ನಂತರವಷ್ಟೇ ಏಜೆಂಟ್ ಅನ್ನು ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್ಗಳಿಗೆ ಬಳಸಲು ಪರಿಗಣಿಸಿ. ಗೋಡೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಮೊದಲೇ ನೈಜ ಡೇಟಾ ಬಳಕೆಗೆ ಧಾವಿಸುವುದು ರಹಸ್ಯಗಳು ಸೋರಿಕೆಯಾಗಲು ಕಾರಣವಾಗುತ್ತದೆ.
ಒಂದು ರನ್ನ ಸಂಪೂರ್ಣ ಹಾದಿಯನ್ನು ಓದುವುದು
deco Studio ಒಂದು ಕಾರ್ಯದ (execution) ಪ್ರತಿಯೊಂದು ಪದರವನ್ನು ಪರೀಕ್ಷಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ. ನೀವು ರೊ (raw) ಮಾಡೆಲ್ ವಿನಂತಿಯನ್ನು ನೋಡಬಹುದು: ಪ್ರಾಂಪ್ಟ್, ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ, ಫಾರ್ಮ್ಯಾಟಿಂಗ್. ಮಾಡೆಲ್ ನಿರ್ಧರಿಸಿದ ಟೂಲ್ ಕಾಲ್ ಅನ್ನು ನೀವು ನೋಡಬಹುದು. ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಆ ಕಾಲ್ ಅನ್ನು ಹೇಗೆ ರೂಟ್ ಮಾಡುತ್ತದೆ, ಫಂಕ್ಷನ್ ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಪೇಲೋಡ್ ಹೇಗೆ ಮರಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು. ಅಂತಿಮವಾಗಿ, ಮಾಡೆಲ್ ತನ್ನ ಉತ್ತರವನ್ನು ರೂಪಿಸಲು ಆ ಫಲಿತಾಂಶವನ್ನು ಹೇಗೆ ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು.
ಈ ದೃಶ್ಯೀಕರಣವು (visibility) ಮೂಲಭೂತ ಆಡಿಟ್ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರ ನೀಡುತ್ತದೆ. ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಅದನ್ನು ಲಾಗ್ ಮಾಡಿದ್ದರಿಂದ ಯಾವ ಟೂಲ್ ಕಾರ್ಯಗತಗೊಂಡಿತು ಎಂಬುದು ನಿಮಗೆ ತಿಳಿದಿರುತ್ತದೆ. ಕಾನ್ಫಿಗರೇಶನ್ ದಾಖಲೆಗಳು ಒಂದು ಸ್ಥಳೀಯ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿರುವುದರಿಂದ ಯಾರು ಪ್ರವೇಶವನ್ನು ನೀಡಿದ್ದಾರೆ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿದಿರುತ್ತದೆ. ನೀವು ಟೋಕನ್ಗಳನ್ನು ಎಣಿಸಬಹುದಾದ ಕಾರಣ ರನ್ ಏಕೆ ದುಬಾರಿಯಾಯಿತು ಎಂಬುದು ನಿಮಗೆ ತಿಳಿದಿರುತ್ತದೆ.
ಮುಖ್ಯವಾದವುಗಳನ್ನು ಎಣಿಸುವುದು
ಪ್ರತಿ ರನ್ಗಾಗಿ, ನಾಲ್ಕು ನಿರ್ದಿಷ್ಟ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ಮೊದಲನೆಯದಾಗಿ, ಇನ್ಪುಟ್ ಮತ್ತು ಔಟ್ಪುಟ್ ಟೋಕನ್ಗಳು. ಇವು ಮಾಡೆಲ್ ವೆಚ್ಚಗಳ ಬಹುಪಾಲು ಭಾಗವನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ ಮತ್ತು ನಿಮಗೆ ಅಂದಾಜು ಸಂಖ್ಯೆಗಳಲ್ಲದೆ ನಿಖರವಾದ ಸಂಖ್ಯೆಗಳ ಅಗತ್ಯವಿದೆ. ಎರಡನೆಯದಾಗಿ, ಮಾಡೆಲ್ ಲೇಟೆನ್ಸಿಯನ್ನು (latency) ಟೂಲ್ ಲೇಟೆನ್ಸಿಯಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ. ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ ಮತ್ತು ಮಾಡೆಲ್ನ ಪ್ರತಿಕ್ರಿಯೆಯ ನಡುವಿನ ಸಮಯವು, ಟೂಲ್ ಕಾಲ್ಗೆ ಉತ್ತರಿಸಲು ಬಾಹ್ಯ ಸೇವೆ ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಇವೆರಡನ್ನೂ ಗೊಂದಲ ಮಾಡಿಕೊಳ್ಳುವುದು ತಪ್ಪು ನಿರ್ diagnoses (misdiagnosed slowdowns) ಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಮೂರನೆಯದಾಗಿ, ದೃಢೀಕರಿಸಿದ ಪ್ರೊವೈಡರ್ ದರಗಳ ಆಧಾರದ ಮೇಲೆ ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಹಾಕಿ. ಊಹಿಸಬೇಡಿ. ನಿಮ್ಮ ಪ್ರೊವೈಡರ್ನ ಬೆಲೆ ಪಟ್ಟಿಯನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಅಳತೆ ಮಾಡಿದ ಟೋಕನ್ಗಳೊಂದಿಗೆ ಅದನ್ನು ಹೊಂದಿಸಿ. ನಾಲ್ಕನೆಯದಾಗಿ, ಯಶಸ್ವಿ ಕಾಲ್ಗಳನ್ನು ತಿರಸ್ಕರಿಸಲ್ಪಟ್ಟ ಅನಧಿಕೃತ ಕಾಲ್ಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. ಹೆಚ್ಚಿನ ತಿರಸ್ಕಾರದ ಸಂಖ್ಯೆಯು ನಿಮ್ಮ ಏಜೆಂಟ್ ಮಿತಿಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿದೆ ಅಥವಾ ನಿಮ್ಮ ಅಲೋಲಿಸ್ಟ್ ಕಾನೂನುಬದ್ಧ ಅಗತ್ಯಗಳೊಂದಿಗೆ ಹೊಂದಾಣಿಕೆಯಾಗುತ್ತಿಲ್ಲ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಈ ಅಂಕಿಅಂಶಗಳು ಏಜೆಂಟ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬ್ಲಾಕ್-ಬಾಕ್ಸ್ ಚಂದಾದಾರಿಕೆಯಿಂದ (black-box subscription) ಗಮನಿಸಬಹುದಾದ ವ್ಯವಸ್ಥೆಯಾಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ. ನೀವು ಬಜೆಟ್ ಮಾಡಬಹುದು, ಉತ್ತಮಗೊಳಿಸಬಹುದು ಮತ್ತು ವಿವರಿಸಬಹುದು.
ಲೋಕಲ್ ಕಂಟ್ರೋಲ್ ಮತ್ತು ಲೋಕಲ್ ಎಕ್ಸಿಕ್ಯೂಷನ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸ
ಇದು ಎಚ್ಚರಿಕೆಯ ನಿರ್ಮಾತೃಗಳನ್ನು ಸಹ ಗೊಂದಲಕ್ಕೀಡುಮಾಡುವ ಪಾಠವಾಗಿದೆ. ನಿಮ್ಮ ಯಂತ್ರದಲ್ಲಿ deco Studio ಅನ್ನು ಚಲಾಯಿಸುವುದು ನಿಮಗೆ ಕಾನ್ಫಿಗರೇಶನ್ ಮೇಲೆ ಲೋಕಲ್ ಕಂಟ್ರೋಲ್ ನೀಡುತ್ತದೆ, ಆದರೆ ಅದು ಮಾಡೆಲ್ನ ಸ್ಥಳೀಯ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು (local execution) ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ನೀವು ಏಜೆಂಟ್ ಅನ್ನು OpenAI, Anthropic ಅಥವಾ ಯಾವುದೇ ಹೋಸ್ಟ್ ಮಾಡಿದ API ನಂತಹ ಬಾಹ್ಯ ಪ್ರೊವೈಡರ್ ಅನ್ನು ಕರೆಯಲು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದರೆ, ನಿಮ್ಮ ಪ್ರಾಂಪ್ಟ್ಗಳು ನಿಮ್ಮ ಯಂತ್ರದಿಂದ ಹೊರಬರುತ್ತವೆ. Studio ಗೇಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಡೇಟಾ ಇನ್ನೂ ನೆಟ್ವರ್ಕ್ ಮೂಲಕ ಚಲಿಸುತ್ತದೆ.
ಯಾವಾಗಲೂ ಈ ಮಿತಿಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ಪೈಪ್ಲೈನ್ನ ಯಾವ ಭಾಗಗಳು ಲೋಕಲ್ಹೋಸ್ಟ್ನಲ್ಲಿ (localhost) ಇರುತ್ತವೆ ಮತ್ತು ಯಾವ ಭಾಗಗಳು ಬೇರೆಯವರ ಸರ್ವರ್ಗೆ ಪ್ರಯಾಣಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ. ನಿಮ್ಮ ಡೇಟಾ ಸೂಕ್ಷ್ಮವಾಗಿದ್ದರೆ, ಟೂಲ್ ಲೇಯರ್ನ ಲೋಕಲ್ ಕಂಟ್ರೋಲ್ ಸಾಕಾಗುವುದಿಲ್ಲ. ಮಾಡೆಲ್ ಇನ್ಫರೆನ್ಸ್ (inference) ಎಲ್ಲಿ ನಡೆಯುತ್ತದೆ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿದಿರಬೇಕು. ಲೋಕಲ್ ಡ್ಯಾಶ್ಬೋರ್ಡ್ನ ಸೌಕರ್ಯವನ್ನು ರಿಮೋಟ್ ಮಾಡೆಲ್ನ ವಾಸ್ತವದೊಂದಿಗೆ ಗೊಂದಲ ಮಾಡಿಕೊಳ್ಳಬೇಡಿ.
ಸೂಚನೆಗಳು ಅಧಿಕಾರವಲ್ಲ (Instructions Are Not Authorization)
ಪ್ರಾಂಪ್ಟಿಂಗ್ ಮೂಲಕ ಏಜೆಂಟ್ ಅನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವುದು ಒಂದು ಅಪಾಯಕಾರಿ ಶಾರ್ಟ್ಕಟ್ ಆಗಿದೆ. ಮಾಡೆಲ್ಗೆ, "ಎಂದಿಗೂ ಡಿಲೀಟ್ ಫಂಕ್ಷನ್ ಅನ್ನು ಕರೆಯಬೇಡ" ಎಂದು ಹೇಳುವುದು ಭದ್ರತಾ ನಿಯಂತ್ರಣವಲ್ಲ. ಅದು ಕೇವಲ ಒಂದು ಸಲಹೆ. ಮಾಡೆಲ್ಗಳು ಸೂಚನೆಗಳನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಬಹುದು, ಜೈಲ್ಬ್ರೇಕ್ ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ಮಾಡಬಹುದು ಅಥವಾ ಕೇವಲ ತಾರ್ಕಿಕ ತಪ್ಪುಗಳನ್ನು ಮಾಡಬಹುದು. ನೈಜ ಭದ್ರತೆಯು ಸಾಫ್ಟ್ವೇರ್ ಮಿತಿಯಲ್ಲಿರುತ್ತದೆ.
ಯಾವ ಫಂಕ್ಷನ್ಗಳನ್ನು ಕರೆಯಬಹುದು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲು deco Studio ಒಳಗೆ ಅಲೋಲಿಸ್ಟ್ಗಳನ್ನು ಬಳಸಿ. ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಒಳಗೆ ಸರ್ವರ್-ಸೈಡ್ ಚೆಕ್ಗಳೊಂದಿಗೆ ಆ ಮಿತಿಗಳನ್ನು ಜಾರಿಗೆ ತರండి. ಬಳಕೆದಾರರು ಫೈಲ್ ಅನುಮತಿಗಳನ್ನು (file permissions) ಹೇಗೆ ಕಂಡುಕೊಳ್ಳುತ್ತಾರೋ ಹಾಗೆಯೇ ಏಜೆಂಟ್ ತನ್ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಕಂಡುಕೊಳ್ಳಬೇಕು: ಕಠಿಣ ಮಿತಿಯನ್ನು ತಲುಪುವ ಮೂಲಕವೇ ಹೊರತು ಸ್ನೇಹಪರ ಟಿಪ್ಪಣಿಯನ್ನು ಓದುವುದರಿಂದಲ್ಲ. ಭದ್ರತೆಯು ಆರ್ಕಿಟೆಕ್ಚರ್ನಲ್ಲಿರಬೇಕೇ ಹೊರತು ನ್ಯಾಚುರಲ್ ಲ್ಯಾಂಗ್ವೇಜ್ನಲ್ಲಿಲ್ಲ.
ಸಣ್ಣದಾಗಿ ಪ್ರಾರಂಭಿಸಿ, ಸಂಶಯದಿಂದಿರಿ
ನಿಮ್ಮ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಅನ್ನು ಒಂದೊಂದೇ ಹಂತವಾಗಿ ನಿರ್ಮಿಸಿ. ಒಂದು MCP ಸರ್ವರ್. ಒಂದು ಎಕ್ಸ್ಪೋಸ್ಡ್ ಫಂಕ್ಷನ್. ಒಂದು ಸಿಂಥೆಟಿಕ್ ಟಾಸ್ಕ್. ಏಜೆಂಟ್ ಎಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಬೇಕೋ ಅಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುತ್ತಿದೆ ಮತ್ತು ಎಲ್ಲಿ ವಿಫಲವಾಗಬೇಕೋ ಅಲ್ಲಿ ವಿಫಲವಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಟ್ರೇಸ್ (trace) ಅನ್ನು ಓದಿ. ಟೋಕನ್ ಸಂಖ್ಯೆಗಳನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ನಂತರ ಮುಂದಿನ ಟೂಲ್ ಅನ್ನು ಸೇರಿಸಿ.
ನಿಯಂತ್ರಣ ಎಂಬುದು ನೀವು ತಿರುಗಿಸುವ ಸ್ವಿಚ್ ಅಲ್ಲ. ಅದು ಮಿತಿಗಳನ್ನು ನಂಬುವ ಮೊದಲು ಅವುಗಳನ್ನು ಸಾಬೀತುಪಡಿಸುವ ಅಭ್ಯಾಸವಾಗಿದೆ. deco Studio ಆ ಅಭ್ಯಾಸವನ್ನು ಅಭ್ಯಾಸ ಮಾಡಲು ನಿಮಗೆ ಲೋಕಲ್ ಪ್ಲೇನ್ ನೀಡುತ್ತದೆ. ಸ್ವಾಯತ್ತ ಏಜೆಂಟ್ಗಳ ಸಮೂಹವನ್ನು (swarm of autonomous agents) ನಿರ್ವಹಿಸಬಹುದಾದ, ಗಮನಿಸಬಹುದಾದ ಮತ್ತು ಮಿತಿಯೊಳಗಿನ ವ್ಯವಸ್ಥೆಯಾಗಿ ಪರಿವರ್ತಿಸಲು ಅದನ್ನು ಬಳಸಿ.
Source: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: Telegram ನಲ್ಲಿ GyaanSetu AI