ನಿಮ್ಮ ಮೊದಲ ಏಜೆಂಟ್ ವರ್ಕ್ಫ್ಲೋ ಒಂದು ಪ್ರಾಂಪ್ಟ್ ಮತ್ತು ಕೆಲವು ಟೂಲ್ಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಇದು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಇದು ಆರ್ಡರ್ ಸ್ಥಿತಿಯನ್ನು (order status) ಹುಡುಕುತ್ತದೆ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತೀರಿ.
ನಂತರ ಉತ್ಪನ್ನ ಬೆಳೆಯುತ್ತದೆ. ಸೇಲ್ಸ್ ತಂಡವು ಮೀಟಿಂಗ್ ನೋಟ್ಸ್ಗಳನ್ನು ಸಿಂಕ್ ಮಾಡುವ CRM ಅಪ್ಡೇಟರ್ ಅನ್ನು ಕೇಳುತ್ತದೆ. ಸಪೋರ್ಟ್ ತಂಡಕ್ಕೆ ಮೂರು ಆಂತರಿಕ ವ್ಯವಸ್ಥೆಗಳನ್ನು (internal systems) ಬಳಸುವ ರಿಫಂಡ್ ವರ್ಕ್ಫ್ಲೋ ಬೇಕಾಗುತ್ತದೆ. ಇಂಜಿನಿಯರಿಂಗ್ ತಂಡವು ವೆಂಡರ್ ಫಾರ್ಮ್ಗಳನ್ನು ತುಂಬಲು ಬ್ರೌಸರ್ ಆಕ್ಷನ್ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯು ಚಿಕ್ಕದಾಗಿ ಕಾಣಿಸಬಹುದು. ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಆದ ಪ್ರಾಂಪ್ಟ್ ಫೈಲ್, ತನ್ನದೇ ಆದ Slack ಥ್ರೆಡ್ ಮತ್ತು ತನ್ನದೇ ಆದ "ಕ್ವಿಕ್ ಫಿಕ್ಸ್" ಇರುತ್ತದೆ. ಆರು ತಿಂಗಳ ನಂತರ, ನಿಮ್ಮ ಏಜೆಂಟ್ ಒಂದೇ ವ್ಯವಸ್ಥೆಯಾಗಿ ಉಳಿಯುವುದಿಲ್ಲ. ಅದು ಕಾಪಿ ಮಾಡಿದ ಪ್ರಾಂಪ್ಟ್ಗಳು, ಅಡಗಿರುವ ಬಿಸಿನೆಸ್ ರೂಲ್ಸ್ಗಳು ಮತ್ತು ಯಾರೂ ಹುಡುಕಲಾಗದ ಹಳೆಯ ಚಾಟ್ ಥ್ರೆಡ್ಗಳಲ್ಲಿ ತೆಗೆದುಕೊಂಡ ನಿರ್ಧಾರಗಳ ಒಂದು ಚದುರಿದ ರಾಶಿಯಾಗುತ್ತದೆ. ಇದನ್ನೇ 'ಪ್ರಾಂಪ್ಟ್ ಸ್ಪ್ರಾಲ್' (prompt sprawl) ಎನ್ನಲಾಗುತ್ತದೆ. ಇದು ನಿಮ್ಮ AI ಉತ್ಪನ್ನವನ್ನು ಪರೀಕ್ಷಿಸಲು ಕಷ್ಟವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ, ಪರಿಶೀಲಿಸಲು ಕಷ್ಟವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಹಿಂದಕ್ಕೆ ಪಡೆಯಲು (roll back) ಅಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.
ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ AI ಏಜೆಂಟ್ ಸ್ಕಿಲ್ ರಿಜಿಸ್ಟ್ರಿ (skill registry).
ಸ್ಕಿಲ್ ಎಂದರೆ ವಾಸ್ತವವಾಗಿ ಏನು
ಸ್ಕಿಲ್ ಎಂದರೆ ಕೇವಲ ಫೋಲ್ಡರ್ಗೆ ಉಳಿಸಿದ ಪ್ರಾಂಪ್ಟ್ ಅಲ್ಲ. ಇದು ಏಜೆಂಟ್ ಏನು ಮಾಡುತ್ತದೆ, ಯಾವ ಟೂಲ್ಗಳನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಏನು ಎಂದಿಗೂ ಮಾಡಬಾರದು ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಒಂದು ವರ್ಷನ್ ಮಾಡಲಾದ (versioned), ಪರೀಕ್ಷಿಸಬಹುದಾದ ಪ್ಯಾಕೇಜ್ ಆಗಿದೆ. ಇದನ್ನು ನಿಮ್ಮ ತಂಡ ಮತ್ತು ಯಂತ್ರದ ನಡುವಿನ ಒಪ್ಪಂದ ಎಂದು ಭಾವಿಸಿ. ಏಜೆಂಟ್ ಒಂದು ಸ್ಕಿಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಿದಾಗ, ಅದರ ಮಿತಿಗಳು ಎಲ್ಲಿವೆ ಮತ್ತು ಯಶಸ್ಸು ಎಂದರೆ ಏನು ಎಂಬುದು ಅದಕ್ಕೆ ನಿಖರವಾಗಿ ತಿಳಿದಿರಬೇಕು.
ಈ ರಚನೆಯಿಲ್ಲದೆ, ಪ್ರತಿಯೊಂದು ಪ್ರಾಂಪ್ಟ್ ಕೂಡ ಒಂದು ಸಣ್ಣ, ಘೋಷಿಸದ ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್ ಆಗಿ ಬದಲಾಗುತ್ತದೆ. ಇದು ಯಾರೂ ಗಮನಿಸದ ಗುಪ್ತ ಅನುಮತಿಗಳು (permissions), ಅಂತರ್ಗತ ಬಿಸಿನೆಸ್ ರೂಲ್ಸ್ಗಳು ಮತ್ತು ವೆಚ್ಚದ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಉತ್ಪನ್ನದ ರೋಡ್ಮ್ಯಾಪ್ ಮುಂದೆ ಸಾಗಿದರೂ ಪ್ರಾಂಪ್ಟ್ ಅಲ್ಲೇ ಉಳಿದಿರುವುದರಿಂದ, ಇದು ನಿಜವಾದ ಉತ್ಪನ್ನದಿಂದ ದೂರ ಸರಿಯುತ್ತದೆ. ಎಲ್ಲಕ್ಕಿಂತ ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ, ಇದನ್ನು ಕಾಪಿ ಮಾಡಲಾಗುತ್ತದೆ. ಯಾರೋ ಒಬ್ಬರು ಇದನ್ನು ಡೆಮೋಕ್ಕಾಗಿ ಬಳಸಬಹುದು ಅಥವಾ ಹೊಸ ಮೈಕ್ರೋಸರ್ವಿಸ್ಗೆ ಪೇಸ್ಟ್ ಮಾಡಬಹುದು, ಆಗ ಈಗ ನಿಮ್ಮ ಬಳಿ ಕತ್ತಲೆಯಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ಚಲಿಸುತ್ತಿರುವ ಎರಡು ಸತ್ಯದ ಮೂಲಗಳು (sources of truth) ಇರುತ್ತವೆ.
ಪ್ರಾಂಪ್ಟ್ಗಳು ಮಾತ್ರ ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ
ಪ್ರಾಂಪ್ಟ್ಗಳು ಪಠ್ಯದಂತೆ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ ತಂಡಗಳು ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರೇಶನ್ನಂತೆ ಪರಿಗಣಿಸುತ್ತವೆ. ವಾಸ್ತವದಲ್ಲಿ, ಅವು ಯಾರೂ ಒಪ್ಪಿಕೊಳ್ಳುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕೋಡ್ಗೆ (code) ಹತ್ತಿರವಾಗಿವೆ. ಪ್ರೊಡಕ್ಷನ್ ಪ್ರಾಂಪ್ಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಸೀಕ್ವೆನ್ಸಿಂಗ್, ಫಾರ್ಮ್ಯಾಟಿಂಗ್, ಎರ್ರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಮತ್ತು ಅಕ್ಸೆಸ್ ಕಂಟ್ರೋಲ್ ಬಗ್ಗೆ ತರ್ಕವನ್ನು (logic) ಒಳಗೊಂಡಿರುತ್ತದೆ. ಆ ತರ್ಕವು ಕೇವಲ ನೈಸರ್ಗಿಕ ಭಾಷೆಯಲ್ಲಿ ಇದ್ದಾಗ, ಗೊಂದಲ ಉಂಟಾಗುತ್ತದೆ. ಏಜೆಂಟ್ಗೆ CRM ಅನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಲು ಅನುಮತಿ ಇದೆಯೇ ಅಥವಾ ಪ್ರಾಂಪ್ಟ್ ಕೇವಲ ಸೂಚನೆ ನೀಡಿದೆಯೇ? ಬಿಲ್ಲಿಂಗ್ API ಸ್ಥಗಿತಗೊಂಡರೆ, ಪ್ರಾಂಪ್ಟ್ ಸುರಕ್ಷಿತವಾಗಿ ಹೇಗೆ ವಿಫಲವಾಗಬೇಕು ಎಂದು ತಿಳಿದಿದೆಯೇ ಅಥವಾ ಅದು ಯಶಸ್ಸಿನ ಸಂದೇಶವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆಯೇ (hallucinate)?
ವೆಚ್ಚವು ಮತ್ತೊಂದು ಮೌನ ಕೊಲೆಗಡುಕ. ಏಜೆಂಟ್ಗೆ "ಹಂತ ಹಂತವಾಗಿ ಯೋಚಿಸಿ ಮತ್ತು ವ್ಯಾಪಕವಾಗಿ ಹುಡುಕಿ" ಎಂದು ಕೇಳುವ ಪ್ರಾಂಪ್ಟ್ ಪ್ರತಿ ಬಾರಿ ಚಲಿಸುವಾಗ ಟೋಕನ್ಗಳನ್ನು (tokens) ಖಾಲಿ ಮಾಡಬಹುದು. ಆ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಇರುವ ಸಪೋರ್ಟ್ ಫ್ಲೋಗೆ ಕಾಪಿ ಮಾಡಿದಾಗ, ನಿಮ್ಮ ಮಾಸಿಕ ಇನ್ಫರೆನ್ಸ್ ಬಿಲ್ (inference bill) ದ್ವಿಗುಣಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಏಕೆ ಎಂದು ಯಾರಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ.
ವ್ಯವಹಾರವು ಬದಲಾದಾಗ ಆದರೆ ಪಠ್ಯವು ಬದಲಾಗದಿದ್ದಾಗ 'ಡ್ರಿಫ್ಟ್' (drift) ಸಂಭವಿಸುತ್ತದೆ. ನಿಮ್ಮ ರಿಫಂಡ್ ನೀತಿಯು ಈಗ ನಿರ್ದಿಷ್ಟ ಮಿತಿಗಿಂತ ಹೆಚ್ಚಿನ ಮೊತ್ತಕ್ಕೆ ಮ್ಯಾನೇಜರ್ ಅನುಮತಿಯನ್ನು ಬಯಸುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ. ಆ ನಿಯಮವು ಪಾಲಿಸಿ ಲೇಯರ್ ಬದಲಿಗೆ ಪ್ರಾಂಪ್ಟ್ನ ಒಳಗಿದ್ದರೆ, ಅಪ್ಡೇಟ್ ಮಾಡಬೇಕಾದ ಕಾಪಿಗಳನ್ನು ಹುಡುಕಲು ನೀವು ಪ್ರತಿಯೊಂದು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಅನ್ನು ಹುಡುಕಬೇಕಾಗುತ್ತದೆ. ಒಂದನ್ನು ಮರೆತರೂ ಸಹ, ಏಜೆಂಟ್ಗಳು ನೀಡಬಾರದ ಹಣವನ್ನು ನೀಡುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ.
ಪ್ರೊಡಕ್ಷನ್ ಸ್ಕಿಲ್ನ ರಚನೆ (Anatomy)
ನೀವು ಈ ಗೊಂದಲದಿಂದ ತಪ್ಪಿಸಿಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ಪ್ರತಿಯೊಂದು ಸ್ಕಿಲ್ ಅನ್ನು ಸಾಫ್ಟ್ವೇರ್ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ (software artifact) ರೀತಿ ಪರಿಗಣಿಸಿ. ಉಪಯುಕ್ತ ಪ್ರೊಡಕ್ಷನ್ ಸ್ಕಿಲ್ ಕೇವಲ ಪಠ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಒಳಗೊಂಡಿರಬೇಕು. ಅದಕ್ಕೆ ಇವು ಬೇಕು:
- ಹೆಸರು ಮತ್ತು ಉದ್ದೇಶ. "prompt_v3_final" ಎಂದಲ್ಲ, ಬದಲಿಗೆ ವ್ಯವಹಾರದ ಗುರಿಯ ಸ್ಪಷ್ಟ ವಿವರಣೆಯೊಂದಿಗೆ "process_standard_refund" ಎಂದಿರಲಿ.
- ಇನ್ಪುಟ್ ಸ್ಕೀಮಾ ಮತ್ತು ಅಗತ್ಯ ಸಂದರ್ಭ (context). ಸ್ಕಿಲ್ ನಿರೀಕ್ಷಿಸುವ ನಿಖರವಾದ ಫೀಲ್ಡ್ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ. ಅದಕ್ಕೆ ಬಳಕೆದಾರರ ಐಡಿ (user ID), ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸ (conversation history), ಅಥವಾ ಟೆನೆಂಟ್ ಐಡೆಂಟಿಫೈಯರ್ ಬೇಕೇ? ಇಲ್ಲಿನ ಸ್ಟ್ರಾಂಗ್ ಟೈಪಿಂಗ್ (strong typing) ಏಜೆಂಟ್ ತಪ್ಪು ಕಲ್ಪನೆಗಳನ್ನು ಮಾಡಿಕೊಳ್ಳದಂತೆ ತಡೆಯುತ್ತದೆ.
- ಟೂಲ್ ಅನುಮತಿಗಳು ಮತ್ತು ಸುರಕ್ಷತಾ ಮಿತಿಗಳು. ಸ್ಕಿಲ್ ಯಾವ ಟೂಲ್ಗಳನ್ನು ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪಟ್ಟಿ ಮಾಡಿ. ರಿಟ್ರೈಗಳು (retries), ವೆಚ್ಚದ ಮಿತಿಗಳು ಮತ್ತು ರೇಟ್ ಕ್ಯಾಪ್ಗಳ ಮೇಲೆ ಗಾರ್ಡ್ರೈಲ್ಸ್ಗಳನ್ನು (guardrails) ಹೊಂದಿಸಿ. ಸ್ಕಿಲ್ ಬಳಕೆದಾರರ ಡಿಲೀಷನ್ API ಅನ್ನು ಬಳಸಬಾರದು ಎಂದಿದ್ದರೆ, ಅದನ್ನು ಕೇವಲ ಪಠ್ಯದಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಕೋಡ್ನಲ್ಲಿಯೂ ತಿಳಿಸಿ.
- ಯಶಸ್ಸಿನ ಮಾನದಂಡಗಳು ಮತ್ತು ಟೆಸ್ಟ್ ಕೇಸ್ಗಳು. ಸ್ಕಿಲ್ ಚಲಿಸುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಅದು "ಕೆಲಸ ಮಾಡುತ್ತದೆ" ಎಂದರ್ಥವಲ್ಲ. ಔಟ್ಪುಟ್ನಲ್ಲಿ ಏನಿರಬೇಕು ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ. ರಿಫಂಡ್ ಸ್ಕಿಲ್ ಆಗಿದ್ದರೆ, ಯಶಸ್ಸು ಎಂದರೆ ವ್ಯಾಲಿಡೇಟ್ ಮಾಡಲಾದ ಟ್ರಾನ್ಸಾಕ್ಷನ್ ರೆಕಾರ್ಡ್, ಕಳುಹಿಸಲಾದ ಇಮೇಲ್ ಕನ್ಫರ್ಮೇಶನ್ ಮತ್ತು ರಚಿಸಲಾದ ಆಡಿಟ್ ಲಾಗ್ ಎಂಟ್ರಿ ಎಂದರ್ಥವಾಗಬಹುದು.
- ವರ್ಷನ್ ಇತಿಹಾಸ ಮತ್ತು ಮಾಲೀಕತ್ವದ ಸ್ಥಿತಿ. ಯಾರಾದರೂ ಇದರ ಜವಾಬ್ದಾರಿ ತೆಗೆದುಕೊಳ್ಳಬೇಕು. v2.3 ಏಕೆ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು v2.2 ರಲ್ಲಿ ಏನಾಯಿತು ಎಂಬುದನ್ನು ಚೇಂಜ್ಲಾಗ್ (changelog) ವಿವರಿಸಬೇಕು.
ನಿಮ್ಮ ಲೇಯರ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ
ತಂಡಗಳು ಮಾಡುವ ದೊಡ್ಡ ತಪ್ಪು ಎಂದರೆ ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿ ತುಂಬುವುದು. ಅವರು ಸ್ನೇಹಪರ ಮಾರ್ಗದರ್ಶನ, ಟೂಲ್ ಡಾಕ್ಯುಮೆಂಟೇಶನ್, ಸೆಕ್ಯೂರಿಟಿ ಪಾಲಿಸಿ ಮತ್ತು ಎರ್ರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಎಲ್ಲವನ್ನೂ ಪಠ್ಯದ ರಾಶಿಯಲ್ಲಿ ಬೆರೆಸುತ್ತಾರೆ. ಇದು ನಿರ್ವಹಿಸಲು ಅಸಾಧ್ಯ (unmaintainable).
ಅದನ್ನು ವಿಭಜಿಸಿ:
- Instructions ಎಂಬುದು ಏಜೆಂಟ್ಗೆ ನೀಡುವ ಮಾರ್ಗದರ್ಶನವಾಗಿದೆ. ಅವು ಧಾಟಿ (tone), ಫಾರ್ಮ್ಯಾಟ್ ಮತ್ತು ಸಾಮಾನ್ಯ ವಿಧಾನವನ್ನು ವಿವರಿಸುತ್ತವೆ.
- Tool Rules ಎಂಬುದು ಏಜೆಂಟ್ಗೆ ಯಾವ ಟೂಲ್ಗಳು ಲಭ್ಯವಿವೆ ಮತ್ತು ಅವು ಏನು ಮಾಡುತ್ತವೆ ಎಂದು ತಿಳಿಸುತ್ತವೆ. ಇದು ಕೇವಲ ಅನ್ವೇಷಣೆಯಾಗಿದೆಯೇ ಹೊರತು ಅನುಮತಿಯಲ್ಲ.
- Policy ಎಂಬುದು ಕೇವಲ ನಂಬಿಕೆಯ ಮೇಲೆ ಅಲ್ಲದೆ, ಕೋಡ್ ಮೂಲಕ ಜಾರಿಗೆ ತರಲ್ಪಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, $500 ಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಮರುಪಾವತಿಗೆ (refund) ಎರಡನೇ ಕಣ್ಣಿನ ಪರಿಶೀಲನೆ ಬೇಕಿದ್ದರೆ, ಆ ಪರಿಶೀಲನೆಯು ಟೂಲ್ ಅನ್ನು ಕರೆಯುವ ಮೊದಲೇ ನಡೆಯುವ ವ್ಯಾಲಿಡೇಶನ್ ಫಂಕ್ಷನ್ನಲ್ಲಿ ಇರುತ್ತದೆ.
- Evals ಎಂಬುದು ಯಾವುದೇ ಬದಲಾವಣೆಯ ನಂತರ ಕೌಶಲ್ಯವು ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವ ಪರೀಕ್ಷೆಗಳಾಗಿವೆ.
ಉದಾಹರಣೆಗೆ, "ದಯವಿಟ್ಟು ಗ್ರಾಹಕರ ಪೂರ್ಣ ಕ್ರೆಡಿಟ್ ಕಾರ್ಡ್ ಸಂಖ್ಯೆಯನ್ನು ಎಂದಿಗೂ ಬಹಿರಂಗಪಡಿಸಬೇಡಿ" ಎಂದು ಬರೆಯಬೇಡಿ. ಬದಲಾಗಿ, ಏಜೆಂಟ್ ನೋಡುವ ಮೊದಲೇ PAN ಸಂಖ್ಯೆಗಳನ್ನು ಮರೆಮಾಚುವ (redact) ಡೇಟಾ ಫಾರ್ಮ್ಯಾಟರ್ ಅನ್ನು ನಿರ್ಮಿಸಿ. ಚತುರ ಬಳಕೆದಾರರ ಇನ್ಪುಟ್ನಿಂದ ನೀತಿಯನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದ ಕಾರಣ, ನೀತಿಯು ಕೋಡ್ನಲ್ಲಿ ಇರಬೇಕು.
ಪ್ರೊಡಕ್ಷನ್ ಅನ್ನು "Latest" ಗೆ ಪಾಯಿಂಟ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ
ಮೌನವಾದ ಪ್ರಾಂಪ್ಟ್ ಅಪ್ಡೇಟ್ನಿಂದ ಶುಕ್ರವಾರದ ಸಂಜೆ ಹಾಳಾಗುವುದನ್ನು ಯಾವುದೂ ತಡೆಯಲಾರದು. ನಿಮ್ಮ ಪ್ರೊಡಕ್ಷನ್ ಏಜೆಂಟ್ ಯಾವಾಗಲೂ ಕೌಶಲ್ಯದ "latest" ಆವೃತ್ತಿಯನ್ನು ಪಡೆಯುತ್ತಿದ್ದರೆ, ಪ್ರತಿ 'main' ಮರ್ಜ್ ಕೂಡ ಒಂದು ಸಂಭವನೀಯ ಲೈವ್ ಘಟನೆಯಾಗುತ್ತದೆ. ನಿಮಗೆ dev, staging, ಮತ್ತು prod ನಂತಹ ಏಲಿಯಾಸ್ಗಳು (aliases) ಬೇಕು. ಪರೀಕ್ಷಿಸಲಾದ ಸುಸ್ಥಿತಿಯಲ್ಲಿರುವ ಆವೃತ್ತಿಯನ್ನು ಈ ಹಂತಗಳ ಮೂಲಕ ಪ್ರಮೋಟ್ ಮಾಡಿ. prod v2.1.4 ಕ್ಕೆ ಪಾಯಿಂಟ್ ಮಾಡಿದಾಗ, ನೀವು ಅದನ್ನು ರನ್ ಮಾಡುವುದನ್ನು ಗಮನಿಸಬಹುದು, ಅದರ ನಡವಳಿಕೆಯನ್ನು ಅಳೆಯಬಹುದು ಮತ್ತು ನೆಮ್ಮದಿಯಿಂದ ಮಲಗಬಹುದು. ಏನಾದರೂ ತಪ್ಪಾದರೆ, ನೀವು ಏಲಿಯಾಸ್ ಅನ್ನು ಹಿಂದಕ್ಕೆ ಸರಿಸಬಹುದು. ಒತ್ತಡದ ನಡುವೆ ಮಧ್ಯರಾತ್ರಿಯಲ್ಲಿ ನೀವು ನ್ಯಾಚುರಲ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡುವುದಿಲ್ಲ.
ಈ ಶಿಸ್ತು ನಿಮ್ಮ ತಂಡವು ಬ್ಯಾಕ್ವರ್ಡ್ಸ್ ಕಾಂಪ್ಯಾಟಿಬಿಲಿಟಿ (backwards compatibility) ಬಗ್ಗೆ ಯೋಚಿಸಲು ಒತ್ತಾಯಿಸುತ್ತದೆ. v2.2 ಆವೃತ್ತಿಯು v2.1 ನಂತೆಯೇ ಇನ್ಪುಟ್ ರೂಪವನ್ನು ನಿರ್ವಹಿಸಬಲ್ಲದೇ? ಇಲ್ಲದಿದ್ದರೆ, ಪ್ರಮೋಷನ್ ಸ್ಟೇಜಿಂಗ್ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ಗ್ರಾಹಕರಿಗಿಂತ ಮುಂಚೆಯೇ ನೀವು ಅದನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು.
ಭದ್ರತೆಯು ಪ್ಯಾಕೇಜ್ನ ಒಳಗಿನಿಂದಲೇ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ
ಪರಿಶೀಲಿಸದ ಪ್ರಾಂಪ್ಟ್ಗಳಿಂದ ತುಂಬಿದ ರಿಜಿಸ್ಟ್ರಿಯು ಒಂದು ಅಪಾಯಕಾರಿ ಅಂಶವಾಗಿದೆ. ನೀವು ಕೋಡ್ನಲ್ಲಿ ಮಾಡುವಂತೆಯೇ ನಿಮ್ಮ ಕೌಶಲ್ಯಗಳನ್ನು (skills) ರಿಸ್ಕ್ಗಳಿಗಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ಪ್ರಾಂಪ್ಟ್ ಟೆಂಪ್ಲೇಟ್ಗಳಲ್ಲಿ ಅಡಗಿರುವ ಹಾರ್ಡ್ಕೋಡೆಡ್ ಸೀಕ್ರೆಟ್ಗಳು ಅಥವಾ API ಕೀಗಳನ್ನು ಹುಡುಕಿ. ಡೇಟಾವನ್ನು ಹೊರಹಾಕುವ (exfiltrate) ಬಾಹ್ಯ ವೆಬ್ಹುಕ್ಗಳು ಅಥವಾ ಶೆಲ್ ಕಮಾಂಡ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಸಿಸ್ಟಮ್ ನೀತಿಯನ್ನು ಅತಿಕ್ರಮಿಸಲು ಮಾಡುವ ಪ್ರಯತ್ನಗಳನ್ನು ಗಮನಿಸಿ, ಉದಾಹರಣೆಗೆ "ignore previous instructions" ಎಂಬ ಪ್ರಾಂಪ್ಟ್ಗಳು ಅಥವಾ ಏಜೆಂಟ್ಗೆ ತನ್ನದೇ ಆದ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಹಿರಂಗಪಡಿಸಲು ಕೇಳುವ ಪ್ರಾಂಪ್ಟ್ಗಳು. ಇವು ಕೇವಲ ಸೈದ್ಧಾಂತಿಕವಲ್ಲ. ಇವು ಪ್ರಾಂಪ್ಟ್-ಇಂಜೆಕ್ಷನ್ ದಾಳಿಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ಮಾದರಿಗಳಾಗಿದ್ದು, ಯಾರೂ ಪರಿಶೀಲಿಸದ ಕಾಪಿ ಮಾಡಿದ ಪಠ್ಯದೊಂದಿಗೆ ಇವು ಬರುವため ಅಪಾಯಕಾರಿಯಾಗಿವೆ.
ನಿಮ್ಮ ಸ್ಕಿಲ್ ಪ್ಯಾಕೇಜ್ಗಳನ್ನು ಸ್ಟ್ಯಾಟಿಕ್ ಅನಾಲಿಸಿಸ್ (static analysis) ಮೂಲಕ ರನ್ ಮಾಡಿ. ಒಂದು ಸ್ಕಿಲ್ ಫೈಲ್ನಲ್ಲಿ ಅಲೋಲಿಸ್ಟ್ (allowlist) ನಲ್ಲಿ ಇಲ್ಲದ URL ಇದ್ದರೆ, ಬಿಲ್ಡ್ ಅನ್ನು ವಿಫಲಗೊಳಿಸಿ. ಅದು ಅನುಮೋದಿತ ಮ್ಯಾನಿಫೆಸ್ಟ್ನಲ್ಲಿ ಇಲ್ಲದ ಟೂಲ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಿದರೆ, ಅದನ್ನು ತಿರಸ್ಕರಿಸಿ.
ನೀವು ಅದನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ನಂಬಲು ಸಾಧ್ಯವಿಲ್ಲ
ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ಗಳಿಲ್ಲದ ರಿಜಿಸ್ಟ್ರಿಯು ಕೇವಲ ಪ್ರಾಂಪ್ಟ್ಗಳ ಫೋಲ್ಡರ್ ಇದ್ದಂತೆ. ಪ್ರತಿ ಕೌಶಲ್ಯಕ್ಕೆ ಹ್ಯಾಪಿ ಪಾತ್ (happy path), ಎಡ್ಜ್ ಕೇಸ್ಗಳು (edge cases) ಮತ್ತು ಫೈಲ್ಯೂರ್ ಮೋಡ್ಗಳನ್ನು (failure modes) ಪರೀಕ್ಷಿಸುವ ಟೆಸ್ಟ್ ಸೆಟ್ ಅಗತ್ಯವಿದೆ. ಹೆಚ್ಚಿನ ಅಪಾಯವಿರುವ ಕೌಶಲ್ಯಗಳಿಗೆ, ಕೇವಲ ಫಂಕ್ಷನಲ್ ಟೆಸ್ಟ್ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನದಿನ ಅಗತ್ಯವಿದೆ. ಏಜೆಂಟ್ ಇನ್ನೊಬ್ಬ ಬಳಕೆದಾರರ ಡೇಟಾವನ್ನು ನೋಡದಂತೆ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನೀವು ಪರ್ಮಿಷನ್ ಬೌಂಡರಿಗಳನ್ನು (permission boundaries) ಪರೀಕ್ಷಿಸಬೇಕಾಗುತ್ತದೆ. ನೀತಿಯು ಕ್ರಿಯೆಯನ್ನು ತಡೆದಾಗ ಅದು 'ಇಲ್ಲ' ಎಂದು ಹೇಳುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನೀವು ರಿಫ್ಯೂಸಲ್ ಬಿಹೇವಿಯರ್ (refusal behavior) ಚೆಕ್ಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್-ಮಟ್ಟದ ರಕ್ಷಣೆಗಳನ್ನು ಅಡ್ವರ್ಸರಿಯಲ್ ಇನ್ಪುಟ್ಗಳು ಬೈಪಾಸ್ ಮಾಡದಂತೆ ನೋಡಿಕೊಳ್ಳಲು ನೀವು ಪ್ರಾಂಪ್ಟ್-ಇಂಜೆಕ್ಷನ್ ರೆಸಿಸ್ಟೆನ್ಸ್ ಟೆಸ್ಟ್ಗಳನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ನಿಮ್ಮ ಪರೀಕ್ಷೆಗಳಿಗೆ ಸ್ಪಷ್ಟವಾದ ಹೆಸರನ್ನು ನೀಡಿ. "refund_skill_rejects_negative_amount" ಎಂದು ಹೆಸರಿಸಲ್ಪಟ್ಟ ಪರೀಕ್ಷೆಯು ಮುಂದಿನ ಎಂಜಿನಿಯರ್ಗೆ ಯಾವ ನಡವಳಿಕೆಯನ್ನು ರಕ್ಷಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ತಿಳಿಸುತ್ತದೆ. ಆವೃತ್ತಿ ಪ್ರಮೋಷನ್ ಸಮಯದಲ್ಲಿ ಪರೀಕ್ಷೆಯು ವಿಫಲವಾದರೆ, ಅಭ್ಯರ್ಥಿ ಬಿಲ್ಡ್ ಅಸುರಕ್ಷಿತವಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ನಿಮ್ಮ ಬಳಿ ಕಠಿಣ ಪುರಾವೆ ಇರುತ್ತದೆ.
ನಿಜವಾದ ಗುರಿ ನಿಯಂತ್ರಣ (Control)
ಮರುಬಳಕೆ (Reuse) ಒಳ್ಳೆಯದು, ಆದರೆ ನಿಯಂತ್ರಣವೇ ನಿಮ್ಮನ್ನು ಉದ್ಯೋಗದಲ್ಲಿ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಸ್ಕಿಲ್ ರಿಜಿಸ್ಟ್ರಿಯು ನಿಮ್ಮ ತಂಡಕ್ಕೆ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಖಚಿತವಾಗಿ ಹೇಳಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ: ಇದು ಅನುಮೋದಿತ ವರ್ಕ್ಫ್ಲೋ (workflow). ಇದು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ರನ್ ಆಗುತ್ತಿರುವ ಆವೃತ್ತಿ. ಇವು ಅದು ಬಳಸಬಹುದಾದ ಟೂಲ್ಗಳು. ಇದನ್ನು ನಾವು ಸರಿಯಾಗಿ ಹೇಗೆ ರೋಲ್ಬ್ಯಾಕ್ (roll back) ಮಾಡಬಹುದು.
ಆ ಸ್ಪಷ್ಟತೆಯು ನಿಮ್ಮನ್ನು ಕೇವಲ ಚತುರ ಡೆಮೋಗಳನ್ನು (demos) ತಯಾರಿಸುವುದರಿಂದ ವಿಶ್ವಾಸಾರ್ಹ ಸಾಫ್ಟ್ವೇರ್ ನಿರ್ವಹಿಸುವತ್ತ ಕೊಂಡೊಯ್ಯುತ್ತದೆ. ಡೆಮೋಗಳು ಸ್ಟೇಕ್ಹೋಲ್ಡರ್ಗಳನ್ನು ಹತ್ತು ನಿಮಿಷಗಳ ಕಾಲ ಪ್ರಭಾವಿತಗೊಳಿಸಬಹುದು. ಆದರೆ ವಿಶ್ವಾಸಾರ್ಹ ಸಾಫ್ಟ್ವೇರ್ ಮುಂಜಾನೆ ಮೂರು ಗಂಟೆಯ에도 ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಅನಿರೀಕ್ಷಿತ ಸಂದರ್ಭಗಳನ್ನು (exceptions) ಸುಗಮವಾಗಿ ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಯಾರಾದರೂ ಮಂಗಳವಾರ ಮಧ್ಯಾಹ್ನ ಒಂದು ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ (pull request) ಮರ್ಜ್ ಮಾಡಿದ್ದಕ್ಕಾಗಿ ತನ್ನ ನಡವಳಿಕೆಯನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.
ನಿಮ್ಮ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ನಿರ್ಮಿಸಿ. ನಿಮ್ಮ ಕೌಶಲ್ಯಗಳಿಗೆ ಆವೃತ್ತಿಗಳನ್ನು ನೀಡಿ (Version). ನಿಮ್ಮ ನೀತಿಗಳನ್ನು ಕೋಡ್ನಲ್ಲಿ ಜಾರಿಗೆ ತರండి. ನಿಮ್ಮ ನಿದ್ರೆಯ ವೇಳಾಪಟ್ಟಿಯೇ ಇದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ ಎಂದು ಭಾವಿಸಿ ಪರೀಕ್ಷಿಸಿ. ನಿಮ್ಮ ಭವಿಷ್ಯದ ನೀವು ನಿಮಗೆ ಧನ್ಯವಾದ ಅರ್ಪಿಸುತ್ತಾರೆ.