ಹೆಚ್ಚಿನ ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು ಇಂದಿಗೂ AI ಏಜೆಂಟ್‌ಗಳನ್ನು ಗಣಿತದ ಮನೆಗೆಲಸವನ್ನು ಅಂಕ ನೀಡುವಂತೆಯೇ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತವೆ. ಅವು ಕೇವಲ ಅಂತಿಮ ಫಲಿತಾಂಶವನ್ನು ಮಾತ್ರ ನೋಡುತ್ತವೆ. ಉತ್ತರ ಸರಿಯಾಗಿದ್ದರೆ, ಅವು ಬಿಡುಗಡೆಗೆ ಅನುಮೋದನೆ ನೀಡಿ ಮುಂದೆ ಸಾಗುತ್ತವೆ. ಇದು ಒಂದು ಅಪಾಯಕಾರಿ ಅಡ್ಡಹಾದಿ. ಸರಿಯಾದ ಉತ್ತರವು ಒಳಗಿನ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಟ್ಟುಹೋದ ವ್ಯವಸ್ಥೆಯನ್ನು ಮರೆಮಾಚಬಹುದು.

ನಿಜವಾದ ಕಥೆಯು ಏಜೆಂಟ್ ಅಲ್ಲಿಗೆ ತಲುಪಲು ಅನುಸರಿಸಿದ ಹಾದಿಯಲ್ಲಿದೆ. ಆ ಹಾದಿಯನ್ನು ಏಜೆಂಟ್ ಟ್ರ್ಯಾಜೆಕ್ಟರಿ (agent trajectory) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಪ್ರತಿಯೊಂದು tool call, ಪ್ರತಿಯೊಂದು routing decision ಮತ್ತು ಏಜೆಂಟ್ ಮರುಪರಿಶೀಲನೆಗಾಗಿ ನಿಲ್ಲುವ ಪ್ರತಿಯೊಂದು ವಿರಾಮವನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಇದನ್ನು ಏಜೆಂಟ್ ಬಿಡಿಸಿದ ಬ್ರೆಡ್‌ಕ್ರಂಬ್ಸ್ (trail of breadcrumbs) ಹಾದಿಯೆಂದು ನೀವು ಭಾವಿಸಬಹುದು. ನೀವು ಕೇವಲ ಗುರಿಯನ್ನು ಮಾತ್ರ ಪರಿಶೀಲಿಸಿದರೆ, ದಾರಿಯುದ್ದಕ್ಕೂ ಹರಡಿರುವ ಎಲ್ಲಾ ಎಚ್ಚರಿಕೆ ಸಂಕೇತಗಳನ್ನು ನೀವು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ.

ಅಸ್ತವ್ಯಸ್ತವಾದ ಹಾದಿಗಳ ಸಮಸ್ಯೆ

ಒಂದು ಏಜೆಂಟ್ ಕುಡಿದ ಚಾಲಕನಂತೆ ವರ್ತಿಸುತ್ತಿದ್ದರೂ ಸರಿಯಾದ ಉತ್ತರವನ್ನು ನೀಡಬಹುದು. ಅದು ತಪ್ಪು tools ಮೂಲಕ ಅಡ್ಡಾಡುತ್ತದೆ, router ಗೆ ಮರಳಿ ಬರುತ್ತದೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ ಸರಿಯಾದ ಉತ್ತರವನ್ನು ಕಂಡುಹಿಡಿಯುವ ಮೊದಲು ಅನಗತ್ಯ ತರ್ಕದ (redundant reasoning) ಚಕ್ರದಲ್ಲಿ ಸುತ್ತಾಡುತ್ತದೆ. ಬಳಕೆದಾರರಿಗೆ ಮಾತ್ರ ಸ್ವಚ್ಛವಾದ ಫಲಿತಾಂಶ ಕಾಣಿಸುತ್ತದೆ. ಆದರೆ ತೆರೆಯ ಮರೆಯಲ್ಲಿ, ವ್ಯವಸ್ಥೆಯು ಸಂಪನ್ಮೂಲಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತಿರುತ್ತದೆ ಮತ್ತು ಅಪಾಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತಿರುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಈ ಅಸ್ತವ್ಯಸ್ತತೆ ಹೇಗಿರುತ್ತದೆ?

ಮೊದಲನೆಯದಾಗಿ, ಅನಗತ್ಯ tool call. ಏಜೆಂಟ್ ನಿಮ್ಮ customer database ಅನ್ನು ವಿಚಾರಿಸುತ್ತದೆ, ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುತ್ತದೆ, ಐದು ಸೆಕೆಂಡುಗಳ ನಂತರ ಅದನ್ನು ಮರೆತುಬಿಡುತ್ತದೆ ಮತ್ತು ಅದೇ parameters ಗಳೊಂದಿಗೆ ಮತ್ತೆ ಅದೇ ದಾಖಲೆಯನ್ನು ವಿಚಾರಿಸುತ್ತದೆ. ಇದು ಡೇಟಾ ಸಮಸ್ಯೆಯಲ್ಲ, ಇದು trajectory ಸಮಸ್ಯೆ. ಏಜೆಂಟ್ ತನ್ನ state ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ವಿಫಲವಾಯಿತು, ಆದ್ದರಿಂದ ಅದು ಕೆಲಸವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ.

ನಂತರ 'wrong-tool-first' ಮಾದರಿಯಿದೆ. ಒಂದು coding agent ಈಗಾಗಲೇ ಸ್ಥಳೀಯ repository ಯಲ್ಲಿ ಇರುವ function definition ಗಾಗಿ ವೆಬ್‌ನಲ್ಲಿ ಹುಡುಕಲು ಪ್ರಯತ್ನಿಸಬಹುದು. ಅಥವಾ ಒಂದು support agent ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗೆ ಖಚಿತವಾಗಿ account settings tool ಅಗತ್ಯವಿದ್ದಾಗ billing API ಅನ್ನು ಬಳಸಬಹುದು. ಪ್ರತಿಯೊಂದು ತಪ್ಪು ಆಯ್ಕೆಯು tokens ಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ, latency ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ನಿಜವಾದ ಕೆಲಸ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ context limits ಮುಗಿದುಹೋಗುವ ಸಾಧ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

Router loops ಮತ್ತೊಂದು ಎಚ್ಚರಿಕೆಯ ಸಂಕೇತ. ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ node ಒಂದು ನಿರ್ಧಾರಕ್ಕೆ ಬರಲಾರದು. ಅದು ಕಾರ್ಯವನ್ನು branch A ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ನಂತರ ತನ್ನ ನಿರ್ಧಾರವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ, ಅದನ್ನು ಹಿಂಪಡೆಯುತ್ತದೆ, branch B ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ನಂತರ ಯಾವುದೇ ಕಾರಣವಿಲ್ಲದೆ ಅದನ್ನು ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ fallback node ಮೂಲಕ route ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು loop ಒಂದು network hop ಅನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಅಂತಿಮ debug log ನಲ್ಲಿ ಗೊಂದಲವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಕೊನೆಯದಾಗಿ, ಪುನರಾವರ್ತಿತ ವಿಶ್ಲೇಷಣೆ (repeated analysis). ಏಜೆಂಟ್ ಒಂದು ತೀರ್ಮಾನವನ್ನು ಸ್ಥಿರ ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು, ಪ್ರತಿ ಹಂತದಲ್ಲೂ ಅದೇ ತೀರ್ಮಾನವನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಪಡೆಯುತ್ತಾ ಇರುತ್ತದೆ. ಇದು ಪ್ರತಿಯೊಂದು ಕತ್ತರಿಸುವ ಮೊದಲು ಮರದ ಹಲಗೆಯನ್ನು ಹತ್ತು ಬಾರಿ ಅಳೆಯುವ ಬಡಗಿ ಇದ್ದಂತೆ. ಮೊದಲ ಅಳತೆ ಸರಿಯಾಗಿತ್ತು, ಆದರೆ ಮುಂದಿನ ಒಂಬತ್ತು ಅಳತೆಗಳು ವ್ಯರ್ಥ ಪ್ರಯತ್ನಗಳಾಗಿವೆ.

ಈ ಹೆಚ್ಚುವರಿ ಹಂತಗಳು ನಿಜವಾದ ಪರಿಣಾಮಗಳನ್ನು ಬೀರುತ್ತವೆ. Latency ಹೆಚ್ಚಾಗುತ್ತದೆ. ಒಂದು synchronous chat interface ನಲ್ಲಿ, ಹೆಚ್ಚುವರಿ ಮೂರು ಸೆಕೆಂಡುಗಳು ಒಂದು ಯುಗದಂತೆ ಭಾಸವಾಗುತ್ತವೆ. ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ (at scale), ಆ ಸೆಕೆಂಡುಗಳು ಸಾವಿರಾರು ಡಾಲರ್ಗಳ compute ವೆಚ್ಚಕ್ಕೆ ಕಾರಣವಾಗುತ್ತವೆ. ವೈಫಲ್ಯದ ಅಪಾಯವೂ ಹೆಚ್ಚುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಅನಗತ್ಯ ಹಂತವು ಬಾಹ್ಯ API time out ಆಗಲು, context window overflow ಆಗಲು ಅಥವಾ race condition ಉಂಟಾಗಲು ಮತ್ತೊಂದು ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ. ಮತ್ತು ಏನಾದರೂ ಮುರಿದುಹೋದಾಗ, spaghetti ತರಹ ಕಾಣುವ trace ಅನ್ನು debug ಮಾಡುವುದು ಬಹಳ ಕಷ್ಟ. ಏಜೆಂಟ್ ಏತಕ್ಕಾಗಿ ಏಳನೇ ಹಂತವನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಎಂದು ಪುನರ್ನಿರ್ಮಿಸಲು ನೀವು ಗಂಟೆಗಟ್ಟಲೆ ಸಮಯ ವ್ಯಯಿಸುತ್ತೀರಿ, ಆದರೆ ಕೊನೆಗೆ ಏಳನೇ ಹಂತವೇ ಇರಬೇಕಾಗಿರಲಿಲ್ಲ ಎಂಬುದು ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ.

ಕನ್ವರ್ಜೆನ್ಸ್ (Convergence) ಎಂದರೆ ನಿಜವಾಗಿ ಏನು?

Trajectory ಎನ್ನುವುದು ಹಾದಿಯಾಗಿದ್ದರೆ, convergence ಎನ್ನುವುದು ಅದರ ದಕ್ಷತೆಯ ಅಳತೆಯಾಗಿದೆ. ಬಳಕೆದಾರರ ವಿನಂತಿ ಮತ್ತು ಸರಿಯಾದ ಪರಿಹಾರದ ನಡುವಿನ ಅತ್ಯಂತ ಚಿಕ್ಕ ಮತ್ತು ಕಾರ್ಯಸಾಧ್ಯವಾದ ಮಾರ್ಗವನ್ನು ಏಜೆಂಟ್ ಎಷ್ಟು ನಿಖರವಾಗಿ ಅನುಸರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು convergence ತಿಳಿಸುತ್ತದೆ.

ಇದು accuracy ಗಿಂತ ಭಿನ್ನವಾಗಿದೆ. Accuracy ಎಂಬುದು ಕೇವಲ ಅಂತಿಮ ಸ್ಥಿತಿ ಸರಿಯಾಗಿದೆಯೇ ಎಂದು ಕೇಳುವ ಒಂದು ಸಾಧನ. ಆದರೆ convergence ಆ ಪ್ರಯಾಣವು ತರ್ಕಬದ್ಧವಾಗಿದೆಯೇ ಎಂದು ಕೇಳುತ್ತದೆ. ಹೆಚ್ಚಿನ accuracy ಮತ್ತು ಕಡಿಮೆ convergence ಹೊಂದಿರುವ ಏಜೆಂಟ್ ಯಶಸ್ಸಿನ ವೇಷ ಧರಿಸಿದ ಹೊರೆ ಇದ್ದಂತೆ. ಹೆಚ್ಚಿನ convergence ಮತ್ತು ಸಾಧಾರಣ accuracy ಹೊಂದಿರುವ ಏಜೆಂಟ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಸುಲಭ, ಏಕೆಂದರೆ ಅದರ ತರ್ಕವು ಸ್ವಚ್ಛವಾಗಿರುತ್ತದೆ ಮತ್ತು ಅದರ ತಪ್ಪುಗಳು ನಿರ್ದಿಷ್ಟ ಸ್ಥಳೀಯವಾಗಿರುತ್ತವೆ.

ಏಜೆಂಟ್ ವಾಸ್ತವವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವ ಹಂತಗಳನ್ನು ಆ ಕಾರ್ಯ ವರ್ಗಕ್ಕಾಗಿ ನೀವು ವ್ಯಾಖ್ಯಾನಿಸಿದ ಅತ್ಯಂತ ಚಿಕ್ಕ ಹಾದಿಯೊಂದಿಗೆ ಹೋಲಿಸುವ ಮೂಲಕ ನೀವು ಅಂದಾಜು convergence score ಅನ್ನು ಲೆಕ್ಕಹಾಕಬಹುದು. ಒಂದು ಸಾಮಾನ್ಯ refund query ಗೆ ನಿಖರವಾಗಿ ಮೂರು tool calls ಬೇಕಾಗಬೇಕೆಂದಿದ್ದರೆ ಮತ್ತು ಏಜೆಂಟ್ ಒಂಬತ್ತು ಬಳಸಿದರೆ, ನಿಮ್ಮ convergence ratio ಕುಸಿಯುತ್ತಿದೆ ಎಂದರ್ಥ. ವಿವಿಧ ರೀತಿಯ ವ್ಯರ್ಥಗಳನ್ನು weighting ಮಾಡುವ ಮೂಲಕ ನೀವು ಇದನ್ನು ಸುಧಾರಿಸಬಹುದು. ಒಂದು tool ನ latency ಮತ್ತು ಬೆಲೆಯನ್ನು ಅವಲಂಬಿಸಿ, ಒಂದು ತಪ್ಪು tool call ಒಂದು ಅನಗತ್ಯ call ಗಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗಬಹುದು. ಯಾವುದೇ ಮೌಲ್ಯವನ್ನು ಸೇರಿಸದ router loop ಎಲ್ಲಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ದಂಡವನ್ನು (penalty) ಹೊಂದಿರಬಹುದು, ಏಕೆಂದರೆ ಅದು architectural