ನೂತನ ಮಾಡೆಲ್ ಬೆಂಚ್ಮಾರ್ಕ್ಗಳನ್ನು ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಏಜೆಂಟ್ ಒಂದು ಚಂದಾದಾರಿಕೆಯನ್ನು (subscription) ರದ್ದುಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ಗಮನಿಸಲು ಪ್ರಾರಂಭಿಸಿ. ಈ ಎರಡು ಚಟುವಟಿಕೆಗಳ ನಡುವಿನ ಅಂತರವೇ ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್ಗಳು ವಿಫಲವಾಗುವ ಜಾಗ. ಒಂದು ಸಿಂಗಲ್-ಟರ್ನ್ ಟೆಸ್ಟ್ (single-turn test) ನಿಮ್ಮ ಪ್ರತಿಕ್ರಿಯೆ ಕೇಳಲು ಆಹ್ಲಾದಕರವಾಗಿದೆಯೇ ಎಂದು ಹೇಳಬಹುದು. ಆದರೆ ಏಜೆಂಟ್ ತಪ್ಪು ಗ್ರಾಹಕನಿಗೆ ಹಣವನ್ನು ಮರುಪಾವತಿ ಮಾಡಿತೇ, ಕ್ಯಾಲೆಂಡರ್ API ವಿರುದ್ಧ ಹದಿನಾಲ್ಕು ಬಾರಿ ಲೂಪ್ ಆಗಿತೇ ಅಥವಾ ಫ್ರಾಡ್ ಚೆಕ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಡಲು ನಿರ್ಧರಿಸಿತೇ ಎಂದು ಅದು ಹೇಳಲಾರದು. ಏಜೆಂಟ್ ಉತ್ಪಾದಿಸುವ ಪಠ್ಯವು ಅತ್ಯಂತ ಕಡಿಮೆ ಅಪಾಯಕಾರಿ ವಿಷಯವಾಗಿದೆ. ನಿಜವಾದ ಅಪಾಯಗಳು ಅದು ಬಳಸುವ ಟೂಲ್ಗಳು, ಅದು ಬದಲಾಯಿಸುವ ಡೇಟಾ ಮತ್ತು ಸಹಾಯ ಕೇಳಬೇಕಾದ ಸಂದರ್ಭದಲ್ಲಿ ಸಹಾಯ ಕೇಳದೆ ಮುಂದುವರಿಯುವ ಕ್ಷಣಗಳಲ್ಲಿ ಅಡಗಿವೆ.
ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಪಠ್ಯ ಬೆಂಚ್ಮಾರ್ಕ್ಗಳು ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ
ಪ್ರಮಾಣಿತ ಬೆಂಚ್ಮಾರ್ಕ್ಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಅಂಕಗಳು ತಪ್ಪಾದ ಭರವಸೆಯನ್ನು ನೀಡುವ ರೂಪವಾಗಿ ಮಾರ್ಪಟ್ಟಿವೆ. ಅತ್ಯಂತ ಸುಂದರವಾದ ಗದ್ಯವನ್ನು ಬರೆಯುವ ಏಜೆಂಟ್ ಕೂಡ ಕಾರ್ಯಾಚರಣೆಯ ಅಪಾಯಕಾರಿಯಾಗಬಹುದು (operational hazard). ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅಪಾಯಿಂಟ್ಮೆಂಟ್ಗಳನ್ನು ಬುಕ್ ಮಾಡಿದಾಗ, ಡೇಟಾಬೇಸ್ ರೆಕಾರ್ಡ್ಗಳನ್ನು ಎಡಿಟ್ ಮಾಡಿದಾಗ ಅಥವಾ ಸಪೋರ್ಟ್ ಟಿಕೆಟ್ಗಳನ್ನು ಸಲ್ಲಿಸಿದಾಗ, ಜನರೇಟ್ ಆದ ಪಠ್ಯವು ವರ್ಕ್ಫ್ಲೋದ ಕೇವಲ ಮೇಲ್ಮೈಯಷ್ಟೇ ಆಗಿರುತ್ತದೆ. ಅದರ ಅಡಿಯಲ್ಲಿ, ಏಜೆಂಟ್ ಯಾವ ಎಂಡ್ಪಾಯಿಂಟ್ ಅನ್ನು ಬಳಸಬೇಕು, ಯಾವ ಪೇಲೋಡ್ ಅನ್ನು ಕಳುಹಿಸಬೇಕು ಮತ್ತು ಯಾವಾಗ ನಿಲ್ಲಿಸಬೇಕು ಎಂಬುದರ ಬಗ್ಗೆ ನಿರ್ದಿಷ್ಟ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿರುತ್ತದೆ. ಅದು ರೀಡಿಂಗ್-ಕಂಪ್ರಿಹೆನ್ಷನ್ (reading-comprehension) ಲೀಡರ್ಬೋರ್ಡ್ನಲ್ಲಿ ಅಗ್ರಸ್ಥಾನ ಪಡೆಯಬಹುದು, ಆದರೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಡಬಲ್-ಬುಕ್ ಮಾಡುವ ಮೂಲಕ, ತಪ್ಪು ಸಾಲನ್ನು (row) ಬದಲಾಯಿಸುವ ಮೂಲಕ ಅಥವಾ ಲಾಗ್ ಫೈಲ್ಗೆ ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯನ್ನು ಸೋರಿಕೆ ಮಾಡುವ ಮೂಲಕ ನಿಮಗೆ ಹಣದ ನಷ್ಟವನ್ನು ಉಂಟುಮಾಡಬಹುದು. ನೀವು ಕೇವಲ ಔಟ್ಪುಟ್ನ ಮೆರುಗು ಮಾತ್ರವಲ್ಲದೆ, ಕೆಲಸದ ಕಾರ್ಯವಿಧಾನವನ್ನು (mechanics) ಪರಿಶೀಲಿಸಬೇಕಾಗುತ್ತದೆ. ಒಂದು ಏಜೆಂಟ್ ಆಫ್ಲೈನ್ QA ಟೆಸ್ಟ್ನಲ್ಲಿ ಉತ್ತಮ ಅಂಕಗಳನ್ನು ಪಡೆಯಬಹುದು ಮತ್ತು ಆದರೂ ಲೂಪ್ ಆಗುವ ಮೂಲಕ ಅಥವಾ ಟೂಲ್ ಅನ್ನು ತಪ್ಪಾಗಿ ಬಳಸುವ ಮೂಲಕ ನಿಮ್ಮ ವರ್ಕ್ಫ್ಲೋ ಅನ್ನು ವಿಫಲಗೊಳಿಸಬಹುದು ಎಂದಾದರೆ, ನಿಮ್ಮ ಮೌಲ್ಯಮಾಪನವು ತಪ್ಪು ಸಂಕೇತಗಳನ್ನು ನೋಡುತ್ತಿದೆ ಎಂದರ್ಥ.
ಐದು ಅವಲಂಬನೆಗಳನ್ನು (Dependencies) ಗುರುತಿಸುವುದು
Van Data Team ತಂಡವು ಪ್ರತಿಯೊಂದು ಮೌಲ್ಯಮಾಪನವನ್ನು ಐದು ನಿರ್ದಿಷ್ಟ ನಿಯಂತ್ರಣ ಬಿಂದುಗಳನ್ನು (control points) ಗುರುತಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಇದು ಪ್ರಶ್ನೆಯನ್ನೇ ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ. ಒಂದು ಮಾಡೆಲ್ ಇನ್ನೊಂದಕ್ಕಿಂತ ಸ್ಮಾರ್ಟ್ ಆಗಿದೆಯೇ ಎಂದು ಕೇಳುವ ಬದಲು, ನಿಮ್ಮ ನೈಜ ನಿರ್ಬಂಧಗಳ ಅಡಿಯಲ್ಲಿ ಏಜೆಂಟ್ ವಾಸ್ತವವಾಗಿ ಪ್ರೊಡಕ್ಷನ್ ಕಾರ್ಯವನ್ನು ಪೂರ್ಣಗೊಳಿಸಬಲ್ಲದೇ ಎಂದು ನೀವು ಕೇಳಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.
ವ್ಯಾಪಾರ ಫಲಿತಾಂಶಗಳು (Business outcomes). ಡಾಲರ್ಗಳಲ್ಲಿ ಮತ್ತು ಗ್ರಾಹಕರ ಮೇಲಿನ ಪರಿಣಾಮದಲ್ಲಿ "ಪೂರ್ಣಗೊಂಡಿತು" ಎಂದರೆ ಏನು ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ. ಏಜೆಂಟ್ ಕೇವಲ ಒಂದು ಸಾರಾಂಶವನ್ನು ನೀಡಿದ ಕಾರಣ ಕೆಲಸ ಪೂರ್ಣಗೊಂಡಿತು ಎಂದರ್ಥವಲ್ಲ. ಇನ್ವೆಂಟರಿ ರೆಕಾರ್ಡ್ ನಿಖರವಾಗಿರಲಿ, ಅಪಾಯಿಂಟ್ಮೆಂಟ್ ಖಚಿತವಾಗಲಿ ಮತ್ತು ಗ್ರಾಹಕರಿಗೆ ಮಾನ್ಯವಾದ ಟ್ರ್ಯಾಕಿಂಗ್ ಸಂಖ್ಯೆ ತಲುಪಿದಾಗ ಮಾತ್ರ ಅದು ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
ಬದಲಾಯಿಸಬಹುದಾದ ಸ್ಥಿತಿ (Mutable state). ಏಜೆಂಟ್ಗೆ ಏನನ್ನು ಬದಲಾಯಿಸಲು ಅನುಮತಿ ಇದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ತಿಳಿಯಿರಿ. ಯಾವ ಟೇಬಲ್ಗಳು, ಯಾವ ಸ್ಟೇಟಸ್ಗಳು, ಯಾವ ಅಕೌಂಟ್ ಫ್ಲಾಗ್ಗಳು? ಏಜೆಂಟ್ ಮರುಪಾವತಿಗಳನ್ನು (refunds) ನೀಡಲು, ಕೆಲಸಗಳನ್ನು ಮರುನಿಗದಿಗೊಳಿಸಲು ಅಥವಾ ಬಿಲ್ಲಿಂಗ್ ವಿಳಾಸಗಳನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಲು ಸಾಧ್ಯವಿದ್ದರೆ, ಅದು ಸ್ಪರ್ಶಿಸುವ ಪ್ರತಿಯೊಂದು ಫೀಲ್ಡ್ ಅನ್ನು ನೀವು ಪಟ್ಟಿ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ಟೂಲ್ ಅನುಮತಿಗಳು (Tool permissions). ಯಾವ API ಎಂಡ್ಪಾಯಿಂಟ್ಗಳು ಮತ್ತು ಫಂಕ್ಷನ್ಗಳು ವ್ಯಾಪ್ತಿಯಲ್ಲಿವೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತಿಳಿಸಿ. ಸರ್ಚ್ ಟೂಲ್, ರೈಟ್ ಟೂಲ್ ಮತ್ತು ನೋಟಿಫಿಕೇಶನ್ ಟೂಲ್ ಅನ್ನು ಹೊಂದಿರುವ ಏಜೆಂಟ್, ಗಡಿಗಳು ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ ಅವುಗಳನ್ನು ಗೊಂದಲಕ್ಕೀಡು ಮಾಡಿಕೊಳ್ಳಬಹುದು. ಪ್ರತಿಯೊಂದು ಅನುಮತಿಯನ್ನು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಾಚರಣೆಯ ಅಗತ್ಯಕ್ಕೆ ಹೊಂದಿಸಿ.
ವೈಫಲ್ಯದ ಚೇತರಿಕೆ (Failure recovery). ಕ್ಯಾಲೆಂಡರ್ API ಟೈಮ್ ಔಟ್ ಆದಾಗ, 500 ಎರರ್ ನೀಡಿದಾಗ ಅಥವಾ ತಪ್ಪಾದ (malformed) JSON ಅನ್ನು ನೀಡಿದಾಗ ಏನಾಗಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ. ಏಜೆಂಟ್ ಗಾಬರಿಯಾಗಬಾರದು, ಯಶಸ್ಸಿನ ಸಂದೇಶವನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಬಾರದು (hallucinate) ಅಥವಾ ಸತತವಾಗಿ ಪ್ರಯತ್ನಿಸುತ್ತಿರಬಾರದು. ಅದಕ್ಕೆ ಸ್ಪಷ್ಟವಾದ ಫಾಲ್ಬ್ಯಾಕ್ ಪಥ (fallback path) ಅಗತ್ಯವಿದೆ.
ಮಾನವ ವಿಮರ್ಶೆ ಹಂತಗಳು (Human review gates). ಏಜೆಂಟ್ ಮುಂದುವರಿಯುವ ಮೊದಲು ಒಬ್ಬ ವ್ಯಕ್ತಿಯ ಅನುಮತಿ ಬೇಕಾದ ಕ್ಷಣಗಳನ್ನು ಗುರುತಿಸಿ. ಇದು ಆಟೊಮೇಷನ್ನ ದೌರ್ಬಲ್ಯದ ಸಂಕೇತವಲ್ಲ. ಇದು ಹೆಚ್ಚಿನ ಪರಿಣಾಮ ಬೀರುವ ಬದಲಾವಣೆಗಳಿಗೆ ಸುರಕ್ಷತಾ ವಾಲ್ವ್ ಆಗಿ ಮತ್ತು ನಿಮ್ಮ ರೂಬ್ರಿಕ್ಗಳಿಗಾಗಿ (rubrics) ಸತ್ಯಾಸತ್ಯತೆಯನ್ನು ತಿಳಿಸುವ ಮೂಲವಾಗಿದೆ.
ನೈಜ ಮೌಲ್ಯಮಾಪನ ಯೋಜನೆ ಹೇಗಿರುತ್ತದೆ
ಅವಲಂಬನೆಗಳನ್ನು ಗುರುತಿಸಿದ ನಂತರ, ಪ್ರೊಡಕ್ಷನ್ನ ಸಂಕೀರ್ಣತೆಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಮೌಲ್ಯಮಾಪನ ಯೋಜನೆ ನಿಮಗೆ ಬೇಕಾಗುತ್ತದೆ. ಸ್ಲೈಡ್-ಡೆಕ್ ಮೆಟ್ರಿಕ್ಸ್ಗಳು ಇಲ್ಲಿ ನಿಮಗೆ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.
ಸಿಂಥೆಟಿಕ್ ಪ್ರಶ್ನೆ ಬ್ಯಾಂಕ್ಗಳಿಂದಲ್ಲದೆ, ನೈಜ ಪ್ರೊಡಕ್ಷನ್ ವೈಫಲ್ಯಗಳಿಂದ ಟೆಸ್ಟ್ ಸೆಟ್ಗಳನ್ನು (test sets) ನಿರ್ಮಿಸಿ. ನಿಮ್ಮ ಏಜೆಂಟ್ ಕಳೆದ ಮಂಗಳವಾರ ಎರಡು ಒಂದೇ ರೀತಿಯ SKUಗಳನ್ನು ಗೊಂದಲಕ್ಕೀಡು ಮಾಡಿಕೊಳ್ಳುವ ಮೂಲಕ ವಿಫಲವಾಗಿದ್ದರೆ, ಅದೇ ಗೊಂದಲವು ಶಾಶ್ವತ ಟೆಸ್ಟ್ ಕೇಸ್ ಆಗಿರಬೇಕು. ಪ್ರತಿ ಬಾರಿ ಒಂದು ಘಟನೆಯು ನಿಮಗೆ ಹೊಸತನ್ನು ಕಲಿಸಿದಾಗ ನಿಮ್ಮ ಮೌಲ್ಯಮಾಪನ ಸೂಟ್ ಬೆಳೆಯುತ್ತಿರಬೇಕು.
ಕಾರ್ಯಾಚರಣೆಯ ಪದಗಳಲ್ಲಿ ಯಶಸ್ವಿ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ರೂಬ್ರಿಕ್ಗಳನ್ನು (rubrics) ಬರೆಯಿರಿ. "ಸಹಾಯಕಾರಿ" ಅಥವಾ "ನಿಖರ" ಎಂಬಂತಹ ಅಸ್ಪಷ್ಟ ಮಾನದಂಡಗಳು ಪ್ರಯೋಜನಕಾರಿಯಲ್ಲ. ಒಂದು ಉಪಯುಕ್ತ ರೂಬ್ರಿಕ್ ಹೀಗೆ ಹೇಳುತ್ತದೆ: ಮರುಪಾವತಿ ಕಾರ್ಯವು ಯಶಸ್ವಿಯಾಗಬೇಕಾದರೆ ಮೂಲ ಪೇಮೆಂಟ್ ಐಡಿ ಉಲ್ಲೇಖಿಸಲ್ಪಟ್ಟಿರಬೇಕು, ಮೊತ್ತವು ವಿನಂತಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು, ಖಚಿತಪಡಿಸುವ ಇಮೇಲ್ ಕ್ಯೂನಲ್ಲಿರಬೇಕು ಮತ್ತು ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಐಡಿ ಲಾಗ್ ಆಗಿರಬೇಕು.
ಟೂಲ್ ಕಾಲ್ ಮತ್ತು ರಿಟ್ರೈಗಳಿಗಾಗಿ ಟ್ರೇಸ್ ಸ್ಪೆಕ್ಸ್ಗಳನ್ನು (trace specs) ವ್ಯಾಖ್ಯಾನಿಸಿ. ಏಜೆಂಟ್ ಏನನ್ನು ಯೋಜಿಸಿತು, ಅದು ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಕರೆ ಮಾಡಿತು, ಎಷ್ಟು ಬಾರಿ ರಿಟ್ರೈ ಮಾಡಿತು ಮತ್ತು ರಿಟ್ರೈ ತಂತ್ರವು ಸೂಕ್ತವಾಗಿದೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ ನಿಮಗೆ ವೀಕ್ಷಣೆ (observability) ಅಗತ್ಯವಿದೆ. ಟೂಲ್-ಮಟ್ಟದ ವಿವರಣೆಯಿಲ್ಲದ ಟ್ರೇಸ್ ಕೇವಲ ಒಂದು ಸುಂದರ ಕಥೆಯಷ್ಟೇ.
ಯಾವಾಗ ಮನುಷ್ಯನಿಗೆ ಎಚ್ಚರಿಕೆ ನೀಡಬೇಕು ಎಂಬುದಕ್ಕೆ ನೀತಿಗಳನ್ನು (policies) ನಿಗದಿಪಡಿಸಿ. ಏಜೆಂಟ್ ತನ್ನದೇ ಆದ ಮಿತಿಗಳನ್ನು ತಿಳಿದುಕೊಳ್ಳಬೇಕು. ಒಂದು ವಿನಂತಿಯು ಹಣದ ಮಿತಿಯನ್ನು ಮೀರಿದರೆ, VIP ಅಕೌಂಟ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಿದರೆ ಅಥವಾ ಹಿಂದೆ ಎಂದೂ ನೋಡದ ಸ್ಥಿತಿಯನ್ನು ಎದುರಿಸಿದರೆ, ಅದು ಊಹಿಸುವ ಬದಲು ವಿಷಯವನ್ನು ಮೇಲಧಿಕಾರಿಗಳಿಗೆ ಅಥವಾ ಮನುಷ್ಯರಿಗೆ ವರ್ಗಾಯಿಸಬೇಕು (escalate).
ಕೆಟ್ಟ ಮಾಡೆಲ್ ಅಪ್ಗ್ರೇಡ್ಗಳನ್ನು ತಡೆಯಲು release gates ಅನ್ನು ಅಳವಡಿಸಿ. ಒಂದು ಹೊಸ ಮಾಡೆಲ್ ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಫಲಿತಾಂಶಗಳನ್ನು ಸುಧಾರಿಸಿದರೆ ಮಾತ್ರ ಅದು ಅಪ್ಗ್ರೇಡ್ ಎಂದು ಪರಿಗಣಿಸಲ್ಪಡುತ್ತದೆ. ಅದು tool arguments ಗಳನ್ನು ಪದೇ ಪದೇ ತಪ್ಪಾಗಿ ನೀಡಿದರೆ (hallucinate), latency ಹೆಚ್ಚಿಸಿದರೆ ಅಥವಾ ಹೊಸ ಸುರಕ್ಷತಾ ಅಪಾಯಗಳನ್ನು ತಂದರೆ, ಅದನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬಾರದು. ಬೇಸ್ ಮಾಡೆಲ್ ವೆಂಡರ್ ಹೊಸ ವರ್ಷನ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದಾಗಲೂ, ಈ ಗೇಟ್ ಪ್ರೊಡಕ್ಷನ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿಡುತ್ತದೆ.
Runtime Grading: ಏಜೆಂಟ್ ಕೆಲಸ ಮಾಡುವುದನ್ನು ಗಮನಿಸುವುದು
ಆಫ್ಲೈನ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಮೀರಿ runtime grading ಕಡೆಗೆ ಸಾಗಲು Anthropic ಉದ್ಯಮವನ್ನು ಪ್ರೇರೇಪಿಸುತ್ತಿದೆ. ಒಂದು ಕೆಲಸ ಮುಗಿದ ನಂತರ ಅದರ ಟ್ರಾನ್ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ವಿಮರ್ಶಿಸುವ ಬದಲು, runtime grading ವ್ಯವಸ್ಥೆಯು ಕೆಲಸ ನಡೆಯುತ್ತಿರುವಾಗಲೇ ಏಜೆಂಟ್ನ ಕೆಲಸವನ್ನು ನಿರ್ಣಯಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದು ತಪ್ಪುಗಳು ದೊಡ್ಡ ಸಮಸ್ಯೆಗಳಾಗುವ ಮೊದಲೇ ಅವುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ.
Grader ಅನ್ನು ಸೇರಿಸುವುದು ಟೋಕನ್ಗಳು ಮತ್ತು latency ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ನೀವು ಪ್ರತಿಯೊಂದು ಸಣ್ಣ ಹಂತವನ್ನೂ ಗ್ರೇಡ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಗ್ರೇಡರ್ನ ಸ್ಥಾನವನ್ನು ನಿರ್ಧರಿಸುವುದು ಒಂದು ವಿನ್ಯಾಸದ ನಿರ್ಧಾರವಾಗಿದೆ (design decision). ತಪ್ಪುಗಳು ಸಂಭವಿಸಿದರೆ ಹೆಚ್ಚು ನಷ್ಟವಾಗುವ ಸ್ಥಳಗಳಲ್ಲಿ ಅವುಗಳನ್ನು ಇರಿಸಿ. ಡೇಟಾಬೇಸ್ಗೆ state change ಅನ್ನು ಕಮಿಟ್ ಮಾಡುವ ಮೊದಲು, ಪಾವತಿಯನ್ನು (payment) ಪಡೆಯುವ ಮೊದಲು ಮತ್ತು ಗ್ರಾಹಕರಿಗೆ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು ಇರಿಸುವ ಚೆಕ್ಪಾಯಿಂಟ್ಗಳು ಅತ್ಯಂತ ಮೌಲ್ಯಯುತವಾಗಿವೆ. ಇವು ತಪ್ಪು ನಿರ್ಧಾರವು ಬದಲಾಯಿಸಲಾಗದ ಕ್ರಿಯೆಯಾಗಿ ಪರಿಣಮಿಸುವ ಕ್ಷಣಗಳು.
ಒಂದು ನಿರ್ದಿಷ್ಟ ಅಂಧಬಿಂದುವನ್ನು (blind spot) ಗಮನದಲ್ಲಿಡಿ. ಅದೇ ಮಾಡೆಲ್ ಕೆಲಸವನ್ನು ಮಾಡಿದ್ದಲ್ಲಿ ಮತ್ತು ಅದೇ ಮಾಡೆಲ್ ಕೆಲಸವನ್ನು ಗ್ರೇಡ್ ಮಾಡಿದ್ದಲ್ಲಿ, ಅದು ಅದೇ ತಪ್ಪುಗಳನ್ನು ಗಮನಿಸದೆ ಬಿಡಬಹುದು. ತಪ್ಪು ಉಂಟುಮಾಡಿದ ತರ್ಕವು (reasoning), ವಿಮರ್ಶೆಯ ಸಮಯದಲ್ಲಿ ಆ ತಪ್ಪನ್ನು ಸುಲಭವಾಗಿ ಸಮರ್ಥಿಸಿಕೊಳ್ಳಬಹುದು. ಹೆಚ್ಚಿನ ಪರಿಣಾಮ ಬೀರುವ ಕೆಲಸಗಳಿಗಾಗಿ, ಮಾನವ ವಿಮರ್ಶೆಯನ್ನು (human review) ಒಳಗೊಳ್ಳಿ. ಹಣ ಅಥವಾ ಗ್ರಾಹಕರ ನಂಬಿಕೆಯ ವಿಷಯವಿರುವಾಗ, ಗ್ರೇಡರ್ನ ತೀರ್ಮಾನವನ್ನು ಮನುಷ್ಯರು ಪರಿಶೀಲಿಸಲು ಅವಕಾಶ ನೀಡಿ.
ಇಲ್ಲಿನ ಗುರಿ ಕಾರ್ಯಾಚರಣೆಯ ನಿಯಂತ್ರಣ (operational control). ನಿಮ್ಮ ಇನ್ಸಿಡೆಂಟ್ ಡೇಟಾ, ಟಾಸ್ಕ್ ರೂಬ್ರಿಕ್ಸ್ ಮತ್ತು runtime traces ಗಳನ್ನು ಒಂದೇ ಫೀಡ್ಬ್ಯಾಕ್ ಸೈಕಲ್ಗೆ ಜೋಡಿಸಿ. ಸಂಪೂರ್ಣ ಹಾದಿಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ: ಯೋಜನೆ, ಟೂಲ್ ಬಳಕೆ, ರಿಕವರಿ ವರ್ತನೆ ಮತ್ತು ಅಂತಿಮ ಫಲಿತಾಂಶ. ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು ತಿಳಿದಿರುವ ಮತ್ತು ಪುನರಾವರ್ತಿತ ತಪ್ಪುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಆಫ್ಲೈನ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಬಳಸಿ. ನೀವು ನಿರೀಕ್ಷಿಸದ ಹೊಸ ವೈಫಲ್ಯಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು runtime traces ಬಳಸಿ. ನಿಮ್ಮ ರೂಬ್ರಿಕ್ಗಳು ಎಲ್ಲಿ ಅಸ್ಪಷ್ಟವಾಗಿವೆ ಮತ್ತು ಎಲ್ಲಿ ಅವುಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿಸಬೇಕೆಂದು ತಿಳಿಯಲು ಮಾನವ ವಿಮರ್ಶೆಯನ್ನು ಬಳಸಿ.
ಆದ್ದರಿಂದ ನಿಮ್ಮನ್ನು ನೀವೇ ಕೇಳಿಕೊಳ್ಳಿ: ನಿಮ್ಮ ವರ್ಕ್ಫ್ಲೋದಲ್ಲಿ runtime grader ಅನ್ನು ಎಲ್ಲಿ ಇರಿಸುತ್ತೀರಿ? ಟೂಲ್ ಕಾಲ್ ಮಾಡುವ ಮೊದಲು, ಟೂಲ್ ಕಾಲ್ ಮಾಡಿದ ನಂತರ ಅಥವಾ ಕೇವಲ ಅಪಾಯಕಾರಿ ಬದಲಾವಣೆಯ ಮೊದಲು? ಹೆಚ್ಚಿನ ತಂಡಗಳು ಎಲ್ಲವನ್ನೂ ಗ್ರೇಡ್ ಮಾಡುವ ಮೂಲಕ ಅತಿ ವಿಶಾಲವಾಗಿ ಪ್ರಾರಂಭಿಸುತ್ತವೆ ಮತ್ತು ನಂತರ ವೆಚ್ಚದ ಕಾರಣದಿಂದಾಗಿ ಕೆಲಸ ನಿಧಾನವಾಗುತ್ತದೆ. ಸಂಕುಚಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಿ. ಒಂದು ವೇಳೆ ತಪ್ಪಾದರೆ ಅತಿ ಹೆಚ್ಚು ನಷ್ಟ ಉಂಟುಮಾಡುವ ಒಂದು ಕ್ರಿಯೆಯನ್ನು ಆರಿಸಿ. ಮೊದಲು ಅಲ್ಲಿ ಗ್ರೇಡರ್ ಅನ್ನು ಇರಿಸಿ.
ಒಂದು ದುಬಾರಿ ತಪ್ಪಿನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ
ಕಾರ್ಯಾಚರಣೆಯ ಮೌಲ್ಯಮಾಪನವು ಕೇವಲ ಸಂಶೋಧನಾ ಅಭ್ಯಾಸವಲ್ಲ. ಏಜೆಂಟ್ ಲೈವ್ ಆದ ನಂತರ ನೆಮ್ಮದಿಯಿಂದ ನಿದ್ರೆ ಮಾಡಲು ಇದು ಒಂದು ಮಾರ್ಗವಾಗಿದೆ. ಮೊದಲ ದಿನವೇ ನಿಮಗೆ ಪರಿಪೂರ್ಣ ಚೌಕಟ್ಟು (framework) ಬೇಕಿಲ್ಲ. ನಿಮಗೆ ಕೇವಲ ಒಂದು ಸುಸ್ಪಷ್ಟ ವರ್ಕ್ಫ್ಲೋ, ಸರಳ ವ್ಯವಹಾರಿಕ ಪದಗಳಲ್ಲಿ ಬರೆದ ರೂಬ್ರಿಕ್ ಮತ್ತು ತಪ್ಪುವು ದುಬಾರಿಯಾಗುವ ನಿಖರ ಕ್ಷಣದಲ್ಲಿ ಇರಿಸಲಾದ ಗ್ರೇಡರ್ ಬೇಕು. ಅದನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿಕೊಂಡರೆ, ನೀವು ನಂಬಬಹುದಾದ ಬಲವಾದ ಅಡಿಪಾಯವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದರ್ಥ.
ನೀವು ಪರಿಣತರ ಸಮುದಾಯದೊಂದಿಗೆ ಏಜೆಂಟ್ ಮೌಲ್ಯಮಾಪನ ಮತ್ತು runtime grading ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಮಾಹಿತಿ ಪಡೆಯಲು ಬಯಸಿದರೆ, GyaanSetu ಕಲಿಕಾ ಸಮುದಾಯವನ್ನು https://t.me/GyaanSetuAi ನಲ್ಲಿ ಕಾಣಬಹುದು.