ಪ್ರೊಡಕ್ಷನ್ ಹಂತಕ್ಕೆ ಹೋಗುವ ಮೊದಲು AI ಏಜೆಂಟ್ ಪ್ಲೇಗ್ರೌಂಡ್ ಅನ್ನು ನಿರ್ಮಿಸುವುದು
ಒಂದು ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಒಮ್ಮೆ ಸ್ಟೇಜಿಂಗ್ ಡೇಟಾಬೇಸ್ ಎಂದು ಭಾವಿಸಿದ್ದ ಡೇಟಾಬೇಸ್ ಮೇಲೆ ಕ್ಲೀನಪ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಚಲಾಯಿಸಿತು. ಆದರೆ ಅದು ವಾಸ್ತವವಾಗಿ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್ ಆಗಿತ್ತು. ತಪ್ಪು ಕ್ರೆಡೆನ್ಶಿಯಲ್ಗಳೊಂದಿಗೆ (credentials) ಅದಕ್ಕೆ ಹೇಳಿದಂತೆಯೇ ಮಾಡಿದ್ದರಿಂದ, ಆ ಏಜೆಂಟ್ ನಾಲ್ಕು ತಿಂಗಳ ಗ್ರಾಹಕರ ಆರ್ಡರ್ಗಳನ್ನು ಅಳಿಸಿಹಾಕಿತು.
ಈ ವೈಫಲ್ಯವು ಏಜೆಂಟ್ಗಳನ್ನು ಬಳಸಬಾರದು ಎನ್ನುವುದಕ್ಕೆ ಕಾರಣವಲ್ಲ. ಬದಲಾಗಿ, ಒಂದು ಪ್ಲೇಗ್ರೌಂಡ್ ಅನ್ನು ನಿರ್ಮಿಸಬೇಕೆಂಬುದಕ್ಕೆ ಇದು ಒಂದು ಕಾರಣ.
ನೀವು ಹೊಸ ಇಂಜಿನಿಯರ್ಗೆ ಅವರ ಮೊದಲ ದಿನವೇ ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್ ಪ್ರವೇಶವನ್ನು ನೀಡುವುದಿಲ್ಲ. ಬದಲಾಗಿ ನೀವು ಅವರಿಗೆ ಸ್ಟೇಜಿಂಗ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್, ಕೇವಲ ಓದಲು ಮಾತ್ರ ಅವಕಾಶವಿರುವ (read-only) ಪ್ರವೇಶ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿರುವ ಕಾರ್ಯಗಳನ್ನು ನೀಡುತ್ತೀರಿ. ಏಜೆಂಟ್ಗಳಿಗೂ ಇದೇ ರೀತಿಯ ಓನ್ಬೋರ್ಡಿಂಗ್ ಅಗತ್ಯವಿದೆ. ಅವು ಪ್ರತಿ ನಿಮಿಷಕ್ಕೆ ಸಾವಿರಾರು ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಲ್ಲವು, ಆದ್ದರಿಂದ ಪ್ಲೇಗ್ರೌಂಡ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟರೆ ಅದರ ಬೆಲೆ ಸಾವಿರ ಪಟ್ಟು ಹೆಚ್ಚಾಗಿರುತ್ತದೆ.
ಒಂದು ನೈಜ ಪ್ಲೇಗ್ರೌಂಡ್ ಮೂರು ಕೆಲಸಗಳನ್ನು ಮಾಡಲೇಬೇಕು:
- ಏಜೆಂಟ್ ತನ್ನ ಸಂಪೂರ್ಣ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು (decision loop) ನಡೆಸಲು ಬಿಡಬೇಕು.
- ಯಾವುದೇ ಅಡ್ಡಪರಿಣಾಮಗಳು (side effects) ನೈಜ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ತಲುಪದಂತೆ ತಡೆಯಬೇಕು.
- ಪರಿಶೀಲನೆಗಾಗಿ ಎಲ್ಲವನ್ನೂ ದಾಖಲಿಸಬೇಕು.
ಕೇವಲ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸಬೇಡಿ. ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಎಂದರೆ ಒಂದು ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುವುದು ಮತ್ತು ಉತ್ತರವನ್ನು ಓದುವುದು ಅಷ್ಟೆ. ಏಜೆಂಟ್ನ ನಡವಳಿಕೆಯು ಟೂಲ್ ಕರೆಗಳ (tool calls) ಸರಣಿಯಾಗಿದೆ. ಒಂದು ಟೂಲ್ ಅನಿರೀಕ್ಷಿತ ಡೇಟಾವನ್ನು ನೀಡಿದಾಗ, ಲೂಪ್ನ ಮಧ್ಯದಲ್ಲಿ ನಿಜವಾದ ವೈಫಲ್ಯಗಳು ಸಂಭವಿಸುತ್ತವೆ.
ನೀವು ಮಾಡೆಲ್ ಅನ್ನು ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ (sandbox) ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ನೀವು ಎಕ್ಸಿಕ್ಯೂಟರ್ ಅನ್ನು (executor) ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ಟೂಲ್ ಕರೆಗಳು ಕ್ರಮಗಳಾಗಿ (actions) ಬದಲಾಗುವಲ್ಲಿ ಒಂದು ವಿಭಜನಾ ಬಿಂದುವನ್ನು (seam) ಸೃಷ್ಟಿಸಿ. ಲೈವ್ ಎಕ್ಸಿಕ್ಯೂಟರ್ ಬದಲಿಗೆ ಮಾಕ್ಗಳನ್ನು (mocks) ಬಳಸುವ ಪ್ಲೇಗ್ರೌಂಡ್ ಎಕ್ಸಿಕ್ಯೂಟರ್ ಅನ್ನು ಬಳಸಿ. ಏಜೆಂಟ್ ಲೂಪ್ಗೆ ಈ ವ್ಯತ್ಯಾಸ ತಿಳಿಯಬಾರದು. ನಿಮ್ಮ ಏಜೆಂಟ್ ನೇರವಾಗಿ ಡೇಟಾಬೇಸ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಕರೆಯುತ್ತಿದ್ದರೆ, ನಿಮ್ಮಲ್ಲಿ ಯಾವುದೇ ವಿಭಜನಾ ಬಿಂದು ಅಥವಾ ಸುರಕ್ಷತೆ ಇರುವುದಿಲ್ಲ.
ಈ ಮೂರು ನಿರ್ದಿಷ್ಟ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ:
- ನಡವಳಿಕೆ (Behavior): ಏಜೆಂಟ್ ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಸರಿಯಾದ ಟೂಲ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆಯೇ?
- ಟೂಲ್ ಕರೆಗಳು (Tool calls): ಆರ್ಗ್ಯುಮೆಂಟ್ಗಳು ಸರಿಯಾಗಿವೆ ಮತ್ತು ಸುರಕ್ಷಿತ ಮಿತಿಯಲ್ಲಿವೆಯೇ?
- ವೈಫಲ್ಯದ ವಿಧಾನಗಳು (Failure modes): ಒಂದು API ಟೈಮ್ ಔಟ್ ಆದಾಗ ಅಥವಾ ಕಸದಂತಹ (garbage) ಡೇಟಾವನ್ನು ನೀಡಿದಾಗ ಏನಾಗುತ್ತದೆ?
ಯಾವಾಗಲೂ ಯಶಸ್ವಿಯಾಗುವ ಮಾಕ್ (mock) ಏಜೆಂಟ್ಗೆ ಏನನ್ನೂ ಕಲಿಸುವುದಿಲ್ಲ. ನೆಟ್ವರ್ಕ್ ಟೈಮ್ ಔಟ್ಗಳು ಅಥವಾ ತಪ್ಪಾದ ಡೇಟಾದಂತಹ ವೈಫಲ್ಯಗಳನ್ನು ನಿಮ್ಮ ಪ್ಲೇಗ್ರೌಂಡ್ನಲ್ಲಿ ಸೇರಿಸಲು (inject) ನೀವು ಸಾಧ್ಯವಾಗಬೇಕು. ಆಗ ಮಾತ್ರ ಏಜೆಂಟ್ ಸಮರ್ಥವಾಗಿ ಮರುಪ್ರಯತ್ನಿಸುತ್ತದೆಯೇ ಅಥವಾ ಭ್ರಮಿಸುತ್ತದೆಯೇ (hallucinating) ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು.
ನಿಮ್ಮ ಏಜೆಂಟ್ ಕೋಡ್ ಅನ್ನು ರನ್ ಮಾಡುವುದಾದರೆ, ನಿಮಗೆ ಬಲವಾದ ಐಸೊಲೇಶನ್ (isolation) ಅಗತ್ಯವಿದೆ. ನಂಬಲಾಗದ ಕೋಡ್ಗಾಗಿ microVM ಗಳನ್ನು ಬಳಸಿ. ಕೇವಲ ಸುಲಭವಾಗಿದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಸರಳ ಕಂಟೇನರ್ಗಳಿಂದ (containers) ಪ್ರಾರಂಭಿಸಬೇಡಿ. ಸುಲಭವಾದ ಸೆಟಪ್ ದೊಡ್ಡ ಮಟ್ಟದ ಭದ್ರತಾ ಘಟನೆಗೆ ಕಾರಣವಾಗಬಹುದು.
ಏಜೆಂಟ್ಗಳು ನಾನ್-ಡೆಟರ್ಮಿನಿಸ್ಟಿಕ್ (non-deterministic) ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ಒಂದು ಬಾರಿ ಪಾಸಾದ ಪರೀಕ್ಷೆಯು ಏಜೆಂಟ್ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ ಎಂದರ್ಥವಲ್ಲ. ನೀವು ಒಂದೇ ಕಾರ್ಯವನ್ನು ಹಲವು ಬಾರಿ ನಡೆಸಬೇಕು. ಒಂದು ಏಜೆಂಟ್ 10 ರಲ್ಲಿ 7 ಬಾರಿ ಪಾಸಾದರೆ, ಅದು ನಿಮ್ಮ ನೈಜ ಬಳಕೆದಾರರಲ್ಲಿ ಸುಮಾರು 30% ರಷ್ಟು ಜನರಿಗೆ ವೈಫಲ್ಯವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಸ್ಥಿರತೆಯೇ (Consistency) ನಿಮ್ಮ ಅತ್ಯಂತ ಪ್ರಮುಖ ಮಾನದಂಡವಾಗಿದೆ.
ಕೊನೆಯದಾಗಿ, ಪ್ರತಿಕೂಲ ಟೂಲ್ ಔಟ್ಪುಟ್ಗಳಿಂದ (adversarial tool outputs) ರಕ್ಷಿಸಿಕೊಳ್ಳಿ. ಏಜೆಂಟ್ ಟೂಲ್ ಡೇಟಾವನ್ನು ಸೂಚನೆಗಳೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ. ದುರುದ್ದೇಶಪೂರಿತ ಬಳಕೆದಾರರು ಏಜೆಂಟ್ ಅನ್ನು ತಪ್ಪಾದ ದಾರಿಗೆ ತಿರುಗಿಸಲು ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ (prompt injection) ಮೂಲಕ ಡೇಟಾಬೇಸ್ಗೆ ಡೇಟಾವನ್ನು ಸೇರಿಸಬಹುದು. ಪ್ಲೇಗ್ರೌಂಡ್ನಲ್ಲಿ ಪ್ರತಿಕೂಲ ಪೇಲೋಡ್ಗಳನ್ನು (hostile payloads) ನೀಡಿ ನಿಮ್ಮ ಏಜೆಂಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ.
ಲಾಂಚ್ ಬಟನ್ ಅನ್ನು ನಿರ್ಮಿಸಬೇಡಿ, ಬದಲಾಗಿ ಪದಕೇರಿಕೆ ಹಾದಿಯನ್ನು (graduation path) ನಿರ್ಮಿಸಿ:
- ಮಾಕ್ಗಳು ಮತ್ತು ಸಂಪೂರ್ಣ ಸ್ಯಾಂಡ್ಬಾಕ್ಸಿಂಗ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ.
- ಅನೇಕ ರನ್ಗಳ ಮೂಲಕ ಸ್ಥಿರತೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ.
- ಪ್ರತಿಕೂಲ ಇನ್ಪುಟ್ಗಳ ವಿರುದ್ಧ ಪರೀಕ್ಷಿಸಿ.
- ಪ್ರೊಡಕ್ಷನ್ ಮಾದರಿಯ ಡೇಟಾ ಬಳಸಿ ಡ್ರೈ-ರನ್ (dry-run) ಮೋಡ್ಗೆ ಹೋಗಿ.
- ನಂತರವಷ್ಟೇ ಮಿತಿಗೊಳಿಸಿದ (scoped), ನಿಯಂತ್ರಿತ (gated) ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾದ ಪ್ರವೇಶವನ್ನು ನೀಡಿ.
ನಿಮ್ಮ ಏಜೆಂಟ್ ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ ತಪ್ಪು ಮಾಡಲು ಒಂದು ಜಾಗವನ್ನು ನೀಡಿ. ಆಗ ಅದು ಮುಖ್ಯವಾದ ಸಂದರ್ಭಗಳಲ್ಲಿ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
Source: https://dev.to/nazar_boyko/building-an-ai-agent-playground-before-giving-it-production-access-4glh
Optional learning community: https://t.me/GyaanSetuAi