ಸಪೋರ್ಟ್ ಏಜೆಂಟ್ ಬಳಕೆದಾರರ ಟೂ-ಫ್ಯಾಕ್ಟರ್ ಅಥೆಂಟಿಕೇಶನ್ (two-factor authentication) ರಿಸೆಟ್ ಮಾಡುವ ವಿನಂತಿಗೆ ಅಸ್ತಿತ್ವದಲ್ಲೇ ಇಲ್ಲದ ಹಂತಗಳೊಂದಿಗೆ ಉತ್ತರಿಸಿದನು. ಆ ಪ್ರತಿಕ್ರಿಯೆ ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಕೂಡಿದಂತೆ ಕಾಣುತ್ತಿತ್ತು, HTTP ವಿನಂತಿಯು 200 OK ಅನ್ನು ನೀಡಿತು, ವಿಳಂಬ (latency) ಸಾಮಾನ್ಯ ಮಟ್ಟದಲ್ಲಿತ್ತು ಮತ್ತು ಎಲ್ಲಾ ಮಾನಿಟರಿಂಗ್ ಚಾರ್ಟ್ಗಳು ಹಸಿರಾಗಿಯೇ ಇದ್ದವು.
ತಪ್ಪುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬೇಕಿದ್ದ ಆಂತರಿಕ ತಪಾಸಣೆಗಳು ಎಂದಿಗೂ ನಡೆಯದ ಕಾರಣ, AI ಚಾಲಿತ ಸಪೋರ್ಟ್ ಏಜೆಂಟ್ ತಪ್ಪು ಮಾಹಿತಿಯನ್ನು (hallucinated) ನೀಡಿತು. ಎಂಜಿನಿಯರ್ಗಳು ಅವಲಂಬಿಸಿರುವ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳು ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ನಡೆಯುತ್ತಿವೆ ಎಂದು ವರದಿ ಮಾಡಿದವು, ಆದರೆ ಏಜೆಂಟ್ ಮೌನವಾಗಿ ಒಂದು ಸುಳ್ಳು ಪರಿಹಾರವನ್ನು ಸೃಷ್ಟಿಸಿತು.
ಸಾಂಪ್ರದಾಯಿಕ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳು AI ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್ಗಳನ್ನು (hallucinations) ಏಕೆ ಪತ್ತೆಹಚ್ಚಲಾರವು
ಹೆಚ್ಚಿನ ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ ಸ್ಟ್ಯಾಕ್ಗಳು (observability stacks) AI ಏಜೆಂಟ್ ಅನ್ನು ಇತರ ಮೈಕ್ರೋಸರ್ವಿಸ್ಗಳಂತೆ ಪರಿಗಣಿಸುತ್ತವೆ: ಒಂದು ಇನ್ಬೌಂಡ್ ವಿನಂತಿ ಮತ್ತು ಒಂದು ಔಟ್ಬೌಂಡ್ ಪ್ರತಿಕ್ರಿಯೆ. ಅವು HTTP ಸ್ಟೇಟಸ್, ರೆಸ್ಪಾನ್ಸ್ ಟೈಮ್ ಮತ್ತು ಎರರ್ ಕೌಂಟ್ ಅನ್ನು ಲಾಗ್ ಮಾಡುತ್ತವೆ. ಆದರೆ ಅವು ವಿನಂತಿಯ ಒಳಗಿರುವ ಗುಪ್ತ ಹಂತಗಳನ್ನು ಲಾಗ್ ಮಾಡುವುದಿಲ್ಲ – ಅಂದರೆ ಬಾಹ್ಯ ದಾಖಲೆಗಳ ಹುಡುಕಾಟ (retrieval), ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ಗಳಿಗೆ ಮಾಡುವ ಕರೆಗಳು, ಪೂರಕ ಪರಿಕರಗಳ (auxiliary tools) ಬಳಕೆ ಮತ್ತು ಔಟ್ಪುಟ್ ಅನ್ನು ದೃಢೀಕರಿಸುವ ಯಾವುದೇ ಗಾರ್ಡ್-ರೈಲ್ ಲಾಜಿಕ್ (guard-rail logic).
ರಿಟ್ರಿವಲ್ ಹಂತವು ಖಾಲಿ ಫಲಿತಾಂಶವನ್ನು ನೀಡಿದಾಗ, ಮಾಡೆಲ್ ಹೆಚ್ಚಾಗಿ ನಂಬಲರ್ಹವಾಗಿ ಕೇಳಿಸುವ ಪಠ್ಯದೊಂದಿಗೆ ಆ "ಬಿಟ್ಟ ಸ್ಥಳವನ್ನು ತುಂಬುತ್ತದೆ". ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ನ ದೃಷ್ಟಿಕೋನದಲ್ಲಿ, ಕರೆ ಯಶಸ್ವಿಯಾಗಿದೆ, ಏಕೆಂದರೆ ಯಾವುದೂ ಕ್ರ್ಯಾಶ್ ಆಗಲಿಲ್ಲ ಮತ್ತು ಸ್ಟೇಟಸ್ ಕೋಡ್ 200 ಆಗಿಯೇ ಉಳಿಯಿತು. ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್ ಅದೃಶ್ಯವಾಗಿ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ತಪ್ಪು ಉತ್ತರ ತಲುಪುವುದೇ ಇದರ ಏಕೈಕ ಲಕ್ಷಣವಾಗುತ್ತದೆ.
ಬ್ಲಾಕ್ ಬಾಕ್ಸ್ ಅನ್ನು ಓದಬಲ್ಲ ಟ್ರೀ (tree) ಆಗಿ ಪರಿವರ್ತಿಸುವುದು
ವಿಶ್ವಾಸಾರ್ಹ ಡಿಬಗ್ಗೆ (debugging) ಮೊದಲ ಹೆಜ್ಜೆ ಎಂದರೆ ಏಜೆಂಟ್ ಅನ್ನು ಒಂದು ಏಕರೂಪದ (monolithic) ಕರೆಯಂತೆ ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವುದು ಮತ್ತು ಪ್ರತಿಯೊಂದು ಆಂತರಿಕ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಟ್ರೇಸ್ ಟೇಬಲ್ನಲ್ಲಿ (trace table) ತನ್ನದೇ ಆದ ಸಾಲಾಗಿ ದೃಶ್ಯೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸುವುದು. ಒಂದು ಸಾಮಾನ್ಯ ಪ್ರಕ್ರಿಯೆಯು ಈ ಕೆಳಗಿನವುಗಳಾಗಿ ವಿಂಗಡಿಸಲ್ಪಡುತ್ತದೆ:
- ಏಜೆಂಟ್ನ ಮೇಲ್ಮಟ್ಟದ ಕರೆ (invocation)
- ಸಂಬಂಧಿತ ದಾಖಲೆಗಳನ್ನು ಪಡೆಯುವ ರಿಟ್ರಿವಲ್ ಹಂತ
- ಪಡೆಯಲಾದ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಪ್ರತಿಯೊಂದು ಲ್ಯಾಂಗ್ವೇಜ್-ಮಾಡಲ್ ಇನ್ಫರೆನ್ಸ್ (inference)
- ಪ್ರತಿಯೊಂದು ಟೂಲ್ ಕರೆ (ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್ ಲುಕಪ್, API ವಿನಂತಿ)
- ಸತ್ಯಾಸತ್ಯತೆಯನ್ನು ಅಥವಾ ನೀತಿ ಅನುಸರಣೆಯನ್ನು ಖಚಿತಪಡಿಸುವ ಗಾರ್ಡ್-ರೈಲ್ ತಪಾಸಣೆಗಳು
ಪ್ರತಿ ಸಾಲು ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್, ಯಶಸ್ಸಿನ ಫ್ಲಾಗ್ ಮತ್ತು ಆ ಹಂತದ ಮೂಲಕ ಚಲಿಸಿದ ಪೇಲೋಡ್ ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಈ ರಚನೆಯೊಂದಿಗೆ, ಅಂತಿಮ ಔಟ್ಪುಟ್ನಿಂದ ಊಹಿಸುವ ಬದಲು, ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಸಾಲು ಸಾಲಾಗಿ ಪರಿಶೀಲಿಸಬಹುದಾದ ಟ್ರೀ ಆಗಿ ಪರಿವರ್ತಿಸಬಹುದು.
ತಪ್ಪಿಹೋದ ಬಗ್ (bug)
ದೋಷಪೂರಿತ ಸಪೋರ್ಟ್ ಸಂವಹನದಲ್ಲಿ ಟ್ರೇಸ್ ಈ ರೀತಿ ಇತ್ತು:
- ರಿಟ್ರಿವಲ್ ನಡೆಯಿತು ಆದರೆ ಯಾವುದೇ ದಾಖಲೆಗಳನ್ನು ನೀಡಲಿಲ್ಲ.
- ಮುಂದಿನ ಹಂತವು ಹೇಗಿದ್ದರೂ ಮುಂದುವರಿಯಿತು, ಮಾಡೆಲ್ಗೆ ಖಾಲಿ ಕಾನ್ಟೆಕ್ಸ್ ಅನ್ನು ವರ್ಗಾಯಿಸಿತು.
- ಮಾಡೆಲ್ ಕಲ್ಪಿತ ಹಂತಗಳೊಂದಿಗೆ ಬಿಟ್ಟುಹೋದ ಮಾಹಿತಿಯನ್ನು ತುಂಬುವ ಉತ್ತರವನ್ನು ಸೃಷ್ಟಿಸಿತು.
- ಪೈಪ್ಲೈನ್ನಲ್ಲಿ ಯಾವುದೇ ಎಕ್ಸೆಪ್ಶನ್ (exception) ಎದುರಾಗದ ಕಾರಣ ಸಿಸ್ಟಮ್ 200 ಅನ್ನು ನೀಡಿತು.
ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್ ಎಂಬುದು ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ನ ದೋಷವಾಗಿರಲಿಲ್ಲ; ಅದು ರಿಟ್ರಿವಲ್ ಮತ್ತು ಜನರೇಷನ್ ಹಂತಗಳ ನಡುವೆ ಇರಬೇಕಿದ್ದ ಗಾರ್ಡ್-ರೈಲ್ ಇಲ್ಲದಿರುವುದು. ತನ್ನ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಆಧರಿಸಲು ಯಾವುದೇ ಮಾಹಿತಿ ಇಲ್ಲದಿದ್ದರೂ ಏಜೆಂಟ್ ಉತ್ತರಿಸಿತು.
ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್ಗಳನ್ನು ತಡೆಯುವ ಸರಳ ಗಾರ್ಡ್-ರೈಲ್ಗಳು
ಎರಡು ನಿರ್ದಿಷ್ಟ ಬದಲಾವಣೆಗಳು ಸಮಸ್ಯೆಯನ್ನು ನಿವಾರಿಸಿದವು:
- ಖಾಲಿ ರಿಟ್ರಿವಲ್ ಆದಾಗ ಸ್ಥಗಿತಗೊಳಿಸಿ (Abort on empty retrieval) – ಡಾಕ್ಯುಮೆಂಟ್ ಸ್ಟೋರ್ ಏನನ್ನೂ ನೀಡದಿದ್ದರೆ, ಏಜೆಂಟ್ ಜನರೇಷನ್ಗೆ ಹೋಗುವ ಬದಲು "ನಿಮಗೆ ಬೇಕಾದ ಮಾಹಿತಿಯನ್ನು ನಾನು ಹುಡುಕಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ" ಎಂದು ಉತ್ತರಿಸಬೇಕು.
- ಗ್ರೌಂಡಿಂಗ್ ಚೆಕ್ (Grounding check) – ಮಾಡೆಲ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡಿದ ನಂತರ, ಪ್ರತಿಯೊಂದು ಸತ್ಯಾಂಶದ ಹೇಳಿಕೆಯು ಪಡೆಯಲಾದ ವಿಷಯದಲ್ಲಿ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ತಪಾಸಣೆಯಲ್ಲಿ ವಿಫಲವಾದರೆ, ಉತ್ತರವನ್ನು ತಿರಸ್ಕರಿಸಿ ಮತ್ತು "ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ" ಎಂಬ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡಿ.
ವೇಗವಾದ ಡಿಬಗ್ಗಾಗಿ ಒಂದು ಪ್ರಾಯೋಗಿಕ ವರ್ಕ್ಫ್ಲೋ (workflow)
- ಪ್ರತಿಯೊಂದು ಆಂತರಿಕ ಕರೆಯನ್ನು ಟ್ರೇಸ್ ಮಾಡಿ – ಪ್ರತಿಯೊಂದು ರಿಟ್ರಿವಲ್, ಮಾಡೆಲ್ ಇನ್ಫರೆನ್ಸ್ ಮತ್ತು ಟೂಲ್ ಬಳಕೆ ಒಂದು ಪರ್ಸಿಸ್ಟೆಂಟ್ ಲಾಗ್ನಲ್ಲಿ (persistent log) ಸಾಲನ್ನು ಬರೆಯುವಂತೆ ಏಜೆಂಟ್ ಅನ್ನು ಇನ್ಸ್ಟ್ರುಮೆಂಟ್ ಮಾಡಿ.
- ವಿಫಲವಾದ ರನ್ಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ – ಬಳಕೆದಾರರು ತಪ್ಪು ಎಂದು ವರದಿ ಮಾಡುವ ಯಾವುದೇ ಸಂವಹನದ ಸಂಪೂರ್ಣ ಟ್ರೇಸ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿ. ಸ್ಟೋರೇಜ್ ಉಳಿಸಲು ಅವುಗಳನ್ನು ಡಿಲೀಟ್ ಮಾಡುವುದು ರಿಗ್ರೆಷನ್ಗಳನ್ನು (regressions) ಪತ್ತೆಹಚ್ಚಲು ಬೇಕಾದ ಡೇಟಾವನ್ನು ಮರೆಮಾಚುತ್ತದೆ.
- ವರ್ಷನ್ ಮಾಹಿತಿಯೊಂದಿಗೆ ರನ್ಗಳನ್ನು ಟ್ಯಾಗ್ ಮಾಡಿ – ಪ್ರತಿ ಟ್ರೇಸ್ ಸಾಲಿನಲ್ಲಿ ರಿಲೀಸ್ ಐಡೆಂಟಿಫೈಯರ್ ಮತ್ತು ಯಾವುದೇ ಫೀಚರ್-ಫ್ಲಾಗ್ ಸ್ಥಿತಿಯನ್ನು ಸೇರಿಸಿ. ಇದು ಹೊಸ ಬಗ್ ಅನ್ನು ಇತ್ತೀಚಿನ ಕೋಡ್ ಬದಲಾವಣೆಯೊಂದಿಗೆ ಸಂಬಂಧಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
- ಕೇವಲ ವೇಗವನ್ನಲ್ಲ, ಗುಣಮಟ್ಟವನ್ನು ಅಳೆಯಿರಿ – ಉತ್ತರವು ಸೂಚನೆಯನ್ನು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಅನುಸರಿಸುತ್ತದೆ ಮತ್ತು ಪಡೆಯಲಾದ ವಿಷಯದಲ್ಲಿ ಎಷ್ಟು ನಿಖರವಾಗಿದೆ ಎಂಬುದನ್ನು ಅಳೆಯುವ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಸೇರಿಸಿ. ಉತ್ತರಗಳು ತಪ್ಪಾಗಿದ್ದರೆ ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ (throughput) ಪ್ರಯೋಜನಕಾರಿಯಲ್ಲ.
- ದಿನನಿತ್ಯ ವಿಫಲತೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ – ಸಂಗ್ರಹಿಸಲಾದ ವಿಫಲತೆಗಳ ಸಂಕ್ಷಿಪ್ತ ಮತ್ತು ನಿಯಮಿತ ಪರಿಶೀಲನೆಯು ಅನೇಕ ಬಳಕೆದಾರರನ್ನು ಬಾಧಿಸುವ ಮೊದಲೇ ಮಾದರಿಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, ಒಂದು ನಿರ್ದಿಷ್ಟ ರೀತಿಯ ಕ್ವೆರಿ ನಿರಂತರವಾಗಿ ಖಾಲಿ ರಿಟ್ರಿವಲ್ಗಳನ್ನು ನೀಡುತ್ತದೆ) ಪತ್ತೆಹಚ್ಚಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
"ಹಸಿರು" (green) ಅನ್ನು "ದೃಢೀಕರಿಸಲಾಗಿದೆ" (verified) ಎಂದು ಪರಿವರ್ತಿಸುವ ಮೂಲಕ, ತಂಡಗಳು ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್ಗಳನ್ನು ಮೊದಲೇ ಪತ್ತೆಹಚ್ಚಬಹುದು ಮತ್ತು ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿಡಬಹುದು.
ಆಂತರಿಕ ವೈಫಲ್ಯಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದರ ವೆಚ್ಚ
ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳು ಕೇವಲ HTTP ಲೇಯರ್ನಲ್ಲಿ ಯಶಸ್ಸನ್ನು ವರದಿ ಮಾಡಿದಾಗ, ಸಂಸ್ಥೆಗಳು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಾಣುವ ಆದರೆ ನಿಯಮಿತವಾಗಿ ತಪ್ಪು ಮಾರ್ಗದರ್ಶನ ನೀಡುವ ಏಜೆಂಟ್ಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತವೆ.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
ಅವು ಸಾಮಾನ್ಯವಾಗುವವರೆಗೆ, ಪ್ರತಿಯೊಂದು ಆಂತರಿಕ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಗಮನಿಸಬಹುದಾದದ್ದು (observable) ಎಂದು ಪರಿಗಣಿಸುವುದು ಮತ್ತು ಸಾಕ್ಷ್ಯಗಳು ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ತಕ್ಷಣವೇ ವಿಫಲಗೊಳ್ಳುವುದು (fail fast) ಅತ್ಯಂತ ಸುರಕ್ಷಿತ ವಿಧಾನವಾಗಿದೆ.
ಮುಖ್ಯ ಅಂಶ: ಹಸಿರು ಡ್ಯಾಶ್ಬೋರ್ಡ್ ವ್ಯವಸ್ಥೆಯು ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ತಿಳಿಸುತ್ತದೆ; ಆದರೆ ಉತ್ತರ ಸರಿಯಾಗಿದೆ ಎಂದು ಅದು ಖಾತರಿ ನೀಡುವುದಿಲ್ಲ. ಪ್ರತಿ ಮಾಹಿತಿ ಪಡೆಯುವಿಕೆ (retrieval), ಮಾಡೆಲ್ ಕರೆ (model call) ಮತ್ತು ಗಾರ್ಡ್-ರೈಲ್ ಪರಿಶೀಲನೆಯನ್ನು (guard-rail check) ಪತ್ತೆಹಚ್ಚುವ ಮೂಲಕ, ನೀವು ಅಡಗಿರುವ ಭ್ರಮೆಗಳನ್ನು (hallucinations) ಬಳಕೆದಾರರನ್ನು ತಲುಪುವ ಮೊದಲೇ ಸರಿಪಡಿಸಬಹುದಾದ ಕಣ್ಣಿಗೆ ಕಾಣುವ ವಿಫಲತೆಗಳನ್ನಾಗಿ ಬದಲಾಯಿಸಬಹುದು.