ಟೂಲ್ ಕಾಲ್ ಯಶಸ್ವಿಯಾಯಿತು. ಫಲಿತಾಂಶ ವಿಫಲವಾಯಿತು.

ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳು ಹೆಚ್ಚಾಗಿ ತಪ್ಪು ಸಂಕೇತಗಳಿಗಾಗಿ ಹುಡುಕುತ್ತವೆ.

ನೀವು ಕ್ರ್ಯಾಶ್‌ಗಳಿಗಾಗಿ (crashes) ಹುಡುಕುತ್ತೀರಿ. ನೀವು ಎಕ್ಸೆಪ್ಶನ್‌ಗಳಿಗಾಗಿ (exceptions) ಹುಡುಕುತ್ತೀರಿ. ನೀವು ಕೆಂಪು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಿಗಾಗಿ ಹುಡುಕುತ್ತೀರಿ.

ಕೆಲವು ಅತ್ಯಂತ ಕೆಟ್ಟ ವೈಫಲ್ಯಗಳು ವೈಫಲ್ಯಗಳಂತೆ ಕಾಣಿಸುವುದಿಲ್ಲ. ಅವು ಯಶಸ್ಸಿನಂತೆ ಕಾಣುತ್ತವೆ.

AI ಏಜೆಂಟ್‌ಗಳು ಮತ್ತು MCP ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ನಾನು ಈ ಮಾದರಿಯನ್ನು ಕಂಡೆ. ಒಂದು ಏಜೆಂಟ್ ಟೂಲ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ. ಟೂಲ್ ಯಶಸ್ವಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ. ಯಾವುದೇ ದೋಷ (error) ಇರುವುದಿಲ್ಲ. ಯಾವುದೇ ಟೈಮ್‌ಔಟ್ (timeout) ಇರುವುದಿಲ್ಲ. ಸಿಸ್ಟಮ್ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ.

ಆದರೆ ಕಾರ್ಯವು ವಿಫಲವಾಯಿತು. ಆ ಕ್ರಿಯೆಯು ಎಂದಿಗೂ ನಡೆಯಲಿಲ್ಲ. ಬಳಕೆದಾರರಿಗೆ ತಪ್ಪು ಫಲಿತಾಂಶ ಸಿಗುತ್ತದೆ.

ನಿಮ್ಮ ತಂಡಕ್ಕಿಂತ ಮೊದಲು ಗ್ರಾಹಕರು ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತಾರೆ.

ಹೆಚ್ಚಿನ ಸಾಫ್ಟ್‌ವೇರ್‌ಗಳು ಒಂದು ಕಲ್ಪನೆಯ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ: ವಿನಂತಿಯು (request) ಯಶಸ್ವಿಯಾದರೆ, ಫಲಿತಾಂಶವೂ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ.

ನೀವು ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗಳನ್ನು (external systems) ಬಳಸಿದಾಗ ಈ ಕಲ್ಪನೆಯು ವಿಫಲವಾಗುತ್ತದೆ. AI ಏಜೆಂಟ್‌ಗಳು APIs, ಡೇಟಾಬೇಸ್‌ಗಳು ಮತ್ತು SaaS ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿವೆ. ಪ್ರತಿಯೊಂದು ಅವಲಂಬನೆಯು ವಿನಂತಿ ಮತ್ತು ವಾಸ್ತವದ ನಡುವೆ ಅಂತರವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಸಿಸ್ಟಮ್ ಯಶಸ್ಸನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ವಾಸ್ತವದಲ್ಲಿ ಅದು ವೈಫಲ್ಯವಾಗಿದೆ.

ಉದಾಹರಣೆ ಸನ್ನಿವೇಶಗಳು:

• ಟೂಲ್ ಸರಿಯಾದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಫಲಿತಾಂಶವು null ಆಗಿರುತ್ತದೆ. ಏಜೆಂಟ್ ಅಪೂರ್ಣ ಡೇಟಾದೊಂದಿಗೆ ಮುಂದುವರಿಯುತ್ತದೆ. • ಒಂದು ವಿನಂತಿಯು ಮೂರು ಕ್ರಿಯೆಗಳನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ. ಕೇವಲ ಒಂದು ಮಾತ್ರ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ. ಆದರೂ ಟೂಲ್ ಯಶಸ್ಸನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಈಗ ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋ (workflow) ಹಾಳಾಗಿದೆ. • ಪ್ರತಿಕ್ರಿಯೆಯು ಯಶಸ್ವಿಯಾಗಿ ಬರುತ್ತದೆ, ಆದರೆ ಡೇಟಾ ಹಳೆಯದಾಗಿರುತ್ತದೆ. ಏಜೆಂಟ್ ಹಳೆಯ ಮಾಹಿತಿಯ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. • ಒಂದು ಫೀಲ್ಡ್‌ನ ಫಾರ್ಮ್ಯಾಟ್ ಬದಲಾಗುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಇನ್ನೂ ಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತದೆ, ಆದರೆ ಅದರ ಅರ್ಥ ತಪ್ಪಾಗಿರುತ್ತದೆ. ವರ್ಕ್‌ಫ್ಲೋ ಮೌನವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ.

ಕ್ರ್ಯಾಶ್‌ಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಸುಲಭ. ಮೌನ ವೈಫಲ್ಯಗಳನ್ನು (silent failures) ಕಂಡುಹಿಡಿಯುವುದು ಕಷ್ಟ.

ಕ್ರ್ಯಾಶ್ ಒಂದು ಅಲರ್ಟ್ ಅನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ. ಮೌನ ವೈಫಲ್ಯವು ಬಳಕೆದಾರರ ನಂಬಿಕೆಯನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ. ಹಾನಿಯಾದ ನಂತರ ಎಂಜಿನಿಯರ್‌ಗಳು ಡಿಬಗ್ ಮಾಡಲು (debugging) ಗಂಟೆಗಟ್ಟಲೆ ಸಮಯ ವ್ಯಯಿಸುತ್ತಾರೆ.

ಸಾಮಾನ್ಯವಾಗಿ ಗ್ರಾಹಕರು ದೂರು ನೀಡಿದಾಗ ತನಿಖೆಯು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಸಮಸ್ಯೆಯನ್ನು (reliability problem) ಪತ್ತೆಹಚ್ಚಲು ಇದು ಅತ್ಯಂತ ದುಬಾರಿ ಮಾರ್ಗವಾಗಿದೆ.

ಯಶಸ್ವಿ ವಿನಂತಿಗಳನ್ನು ನಂಬುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಯಶಸ್ವಿ ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಲು (validating) ಪ್ರಾರಂಭಿಸಿ.

ರೆಸ್ಪಾನ್ಸ್ ಕೋಡ್ (response code) ಸಂವಹನವು ನಡೆದಿದೆಯೇ ಎಂದು ಮಾತ್ರ ತಿಳಿಸುತ್ತದೆ. ಗುರಿ ತಲುಪಿದೆಯೇ ಎಂದು ಅದು ತಿಳಿಸುವುದಿಲ್ಲ.

ನಿಮ್ಮ ಕೊನೆಯ 10 ಪ್ರೊಡಕ್ಷನ್ ಟೂಲ್ ಕರೆಗಳನ್ನು (production tool calls) ಪರಿಶೀಲಿಸಿ. ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ:

  • ವಿನಂತಿಯು ಯಶಸ್ವಿಯಾಯಿತೇ?
  • ಉದ್ದೇಶಿತ ಫಲಿತಾಂಶವು ಸಂಭವಿಸಿದೆಯೇ?
  • ಅದು ವಿಫಲವಾದರೆ ನಮಗೆ ಹೇಗೆ ತಿಳಿಯುತ್ತದೆ?

ಉತ್ತರಗಳು ಭಿನ್ನವಾಗಿದ್ದರೆ, ನಿಮ್ಮಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಅಂತರವಿದೆ (reliability gap). ನೀವು ಪತ್ತೆಹಚ್ಚದಿದ್ದರೆ, ನಿಮ್ಮ ಬಳಕೆದಾರರು ಅದನ್ನು ಶೀಘ್ರದಲ್ಲೇ ಪತ್ತೆಹಚ್ಚುತ್ತಾರೆ.

ಮೂಲ: https://dev.to/sasi_sundar/the-tool-call-succeeded-the-outcome-failed-3l59

ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi