AI ಏಜೆಂಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿರುವ ಡೆವಲಪರ್‌ಗಳು ಒಂದೇ ಮೂರು ವಿಷಯಗಳನ್ನು ಪದೇ ಪದೇ ಪರಿಶೀಲಿಸುತ್ತಿರುತ್ತಾರೆ – 200 HTTP ಸ್ಟೇಟಸ್, ಫೈರ್ಡ್ ಕಾಲ್‌ಬ್ಯಾಕ್ ಮತ್ತು ರೆಸ್ಪಾನ್ಸ್‌ನಲ್ಲಿರುವ ಕೆಲವು ಪಠ್ಯ – ಮತ್ತು ಕೆಲಸ ಮುಗಿದಿದೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಮೂರು-ಪದರದ ಸಿಗ್ನಲ್ ಮಾಡೆಲ್ (three-layer signal model) ತೋರಿಸುವಂತೆ, ಈ ಮೇಲ್ಮಟ್ಟದ ನೋಟವು ಮೌನ ವೈಫಲ್ಯಗಳನ್ನು (silent failures) ಮರೆಮಾಚುತ್ತದೆ.

ಮೇಲ್ಮಟ್ಟದ ಪರಿಶೀಲನೆ ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ

ಹೆಚ್ಚಿನ ಮಾನಿಟರಿಂಗ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು ಫ್ರೇಮ್‌ವರ್ಕ್ ಯಶಸ್ಸನ್ನು ವರದಿ ಮಾಡಿದ ತಕ್ಷಣ ಹಸಿರು ಬಣ್ಣಕ್ಕೆ ತಿರುಗುತ್ತವೆ. ಆ ಯಶಸ್ಸು ಕೇವಲ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಮೊದಲ ಪದರವಾಗಿದೆ. ಒಂದು ವೇಳೆ ಮಾಡೆಲ್ ಖಾಲಿ ಪೇಲೋಡ್ (empty payload) ಅನ್ನು ನೀಡಿದರೆ, ಡಜನ್‌ಗಟ್ಟಲೆ ಅನಗತ್ಯ ಟೂಲ್ ಕರೆಗಳನ್ನು (tool calls) ಮಾಡಿದರೆ, ಅಥವಾ ಏಜೆಂಟ್‌ಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಂಡರೆ, ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಇನ್ನೂ "ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ" ಎಂದು ತೋರಿಸುತ್ತದೆ. ಈ ಗುಪ್ತ ಸಮಸ್ಯೆಗಳು ನಂತರವೇ ಹೊರಬರುತ್ತವೆ, ಹೆಚ್ಚಾಗಿ ಗ್ರಾಹಕರು ಮಾಹಿತಿಯ ಕೊರತೆಯನ್ನು ವರದಿ ಮಾಡಿದಾಗ ಅಥವಾ ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸೇವೆ ವಿಫಲವಾದಾಗ ಇವು ಗೋಚರಿಸುತ್ತವೆ.

ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಯಶಸ್ಸಿನ ಮೂರು ಪದರಗಳು

ಪದರ 1 – ಫ್ರೇಮ್‌ವರ್ಕ್ ಪದರ (The Framework layer)

ಇದು ಗೋಚರಿಸುವ ಅಂಚು: HTTP ರೆಸ್ಪಾನ್ಸ್ ಕೋಡ್, ಫ್ರೇಮ್‌ವರ್ಕ್‌ನ "ಟಾಸ್ಕ್ ಮುಗಿದಿದೆ" (task finished) ಫ್ಲಾಗ್ ಮತ್ತು ಯಾವುದೇ ಔಟ್‌ಪುಟ್ ಪಠ್ಯದ ಉಪಸ್ಥಿತಿ. 200 ಸ್ಟೇಟಸ್ ಎಂದರೆ ವಿನಂತಿ ಸರ್ವರ್ ತಲುಪಿದೆ ಮತ್ತು ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸಿದೆ ಎಂದು ತಿಳಿಸುತ್ತದೆ, ಆದರೆ ಮಾಡೆಲ್ ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಖಾಲಿ ಪ್ರತಿಕ್ರಿಯೆ ಅಥವಾ ಶೂನ್ಯ-ಟೋಕನ್ (zero-token) ಪ್ರತಿಕ್ರಿಯೆಯೂ ಸಹ ಈ ಮಟ್ಟದಲ್ಲಿ ಯಶಸ್ಸಿನಾಗಿ ಎಣಿಸಲ್ಪಡುತ್ತದೆ.

ಪದರ 2 – ಡೇಟಾ ಪದರ (The Data layer)

ಇಲ್ಲಿ ನೀವು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಒಳಗಿನ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನೋಡುತ್ತೀರಿ. ಸಂಬಂಧಿತ ಸಿಗ್ನಲ್‌ಗಳು ಇಂತಿವೆ:

  • ಟೋಕನ್ ಸಂಖ್ಯೆಗಳು (Token counts) – ಮಾಡೆಲ್ ಯಾವುದೇ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳನ್ನು ನೀಡಿದೆಯೇ?
  • ಟೂಲ್-ಕರೆಗಳ ಆವರ್ತನ (Tool-call frequency) – ನಿರೀಕ್ಷೆಗಿಂತ ಹೆಚ್ಚಿನ ಬಾರಿ ಟೂಲ್ ಅನ್ನು ಬಳಸಲಾಗಿದೆಯೇ?
  • ಸ್ಕೀಮಾ ವ್ಯಾಲಿಡೇಶನ್ (Schema validation) – ತಪ್ಪಾದ JSON ಫಾರ್ಮ್ಯಾಟ್ ಸ್ಪಷ್ಟವಾದ ಎರರ್ ತೋರಿಸುವ ಬದಲು ಮೌನವಾಗಿ ಫಾಲ್‌ಬ್ಯಾಕ್ ಆಗಿದೆಯೇ?
  • ವಿಳಂಬ (Latency) – ಒಂದು ಕಾರ್ಯವು 3 ಸೆಕೆಂಡ್‌ಗಳ ಬದಲಿಗೆ 45 ಸೆಕೆಂಡ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆಯೇ?

ಸಾಮಾನ್ಯ ಮಾನಿಟರಿಂಗ್ ಪರಿಕರಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಕೇವಲ ಅಂತಿಮ ಫಲಿತಾಂಶವನ್ನು ಮಾತ್ರ ತೋರಿಸುತ್ತವೆ, ಈ ಪ್ರಕ್ರಿಯೆ-ಗುಣಮಟ್ಟದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು (process-quality metrics) ತೋರಿಸುವುದಿಲ್ಲ. ಇವುಗಳಿಲ್ಲದೆ ಮಾಡೆಲ್ ಉದ್ದೇಶಿತವಾಗಿ ವರ್ತಿಸಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂದು ನೀವು ತಿಳಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಪದರ 3 – ಹ್ಯಾಂಡ್‌ಆಫ್ ಪದರ (The Handoff layer)

ಮಲ್ಟಿ-ಏಜೆಂಟ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಡೇಟಾ ಒಂದು ಘಟಕದಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಚಲಿಸಬೇಕು. ಈ ಪದರವು ಆ ಚಲನೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತದೆ:

  • ವಿತರಣೆ (Delivery) – ಔಟ್‌ಪುಟ್ ನಿಜವಾಗಿಯೂ ಮುಂದಿನ ಹಂತಕ್ಕೆ ತಲುಪಿದೆಯೇ?
  • ನಷ್ಟ (Loss) – ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ಡೇಟಾ ಕಳೆದುಹೋಗಿದೆಯೇ?
  • ದೋಷಪೂರಿತವಾಗುವುದು (Corruption) – ಏಜೆಂಟ್‌ಗಳ ನಡುವೆ ಚಲಿಸುವಾಗ ಪೇಲೋಡ್ ಬದಲಾಗಿದೆಯೇ?

ಒಂದು ಏಜೆಂಟ್ ಪದರ 1 ಮತ್ತು 2 ಅನ್ನು ಪಾಸು ಮಾಡಬಹುದು, ಆದರೆ ತನ್ನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ತಲುಪಿಸುವಲ್ಲಿ ವಿಫಲವಾಗಿ, ಚೈನ್ ಅನ್ನು ಮುರಿದು ಮುಂದಿನ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಅಗತ್ಯವಿರುವ ಇನ್‌ಪುಟ್ ಇಲ್ಲದಂತೆ ಮಾಡಬಹುದು.

ಅಪಾಯದಲ್ಲಿ ಏನಿದೆ

ಮೌನ ವೈಫಲ್ಯಗಳನ್ನು ಡಿಬಗ್ ಮಾಡುವುದು ಕಷ್ಟ. AI ಚಾಲಿತ ಸೇವೆಗಳನ್ನು ಮಾರಾಟ ಮಾಡುವ ಸಂಸ್ಥೆಗಳಿಗೆ, ಈ ಗುಪ್ತ ಬಗ್‌ಗಳು ನೇರವಾಗಿ ಆದಾಯದ ನಷ್ಟ ಮತ್ತು ಮರುಸ್ಥಾಪನೆಯಾಗುವಂತಹ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಹಾನಿಗೆ ಕಾರಣವಾಗಬಹುದು.

ಮರೆಮಾಚಿದ ಸಿಗ್ನಲ್‌ಗಳನ್ನು ಹೇಗೆ ಹೊರತರುವುದು

ಡಿಫಾಲ್ಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್ ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವುದು ಇನ್ನು ಮುಂದೆ ಸಾಕಾಗುವುದಿಲ್ಲ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಇನ್‌ಸ್ಟ್ರುಮೆಂಟೇಶನ್ (instrumentation) ಅನ್ನು ಸೇರಿಸಿ:

ಪದರ 2 ಅನ್ನು ಮಾನಿಟರಿಂಗ್ ಮಾಡುವುದು

  • ಪ್ರತಿ ರನ್‌ಗಾಗಿ ಇನ್‌ಪುಟ್ ಮತ್ತು ಔಟ್‌ಪುಟ್ ಟೋಕನ್ ಸಂಖ್ಯೆಗಳನ್ನು ಲಾಗ್ ಮಾಡಿ.
  • ಟೂಲ್-ಕರೆಗಳ ಆವರ್ತನವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಸಾಮಾನ್ಯ ನಡವಳಿಕೆಯ ಬೇಸ್‌ಲೈನ್‌ಗೆ ಹೋಲಿಸಿ.
  • ಔಟ್‌ಪುಟ್ ಪಾರ್ಸಿಂಗ್ ಯಶಸ್ವಿಯಾಯಿತೇ ಅಥವಾ ವಿಫಲವಾಗಿತೇ ಎಂದು ದಾಖಲಿಸಿ, ತಪ್ಪಾದ JSON ಅನ್ನು ಫ್ಲಾಗ್ ಮಾಡಿ.
  • ಕೇವಲ ಸರಾಸರಿಗಳಿಗಿಂತ ವಿಳಂಬದ ಪರ್ಸೆಂಟೈಲ್‌ಗಳನ್ನು (latency percentiles) ಕ್ಯಾಪ್ಚರ್ ಮಾಡಿ, ಇದರಿಂದ ಅಸಮಾನ್ಯ ವ್ಯತ್ಯಾಸಗಳನ್ನು (outliers) ಪತ್ತೆಹಚ್ಚಬಹುದು.

ಪದರ 3 ಅನ್ನು ಮಾನಿಟರಿಂಗ್ ಮಾಡುವುದು

  • ಆರ್ಕಿಟೆಕ್ಚರ್ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಏಜೆಂಟ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಉತ್ಪಾದಕನಿಂದ (producer) ಗ್ರಾಹಕನವರೆಗೆ (consumer) ಡೇಟಾ ಹರಿವನ್ನು ಟ್ರೇಸ್ ಮಾಡಿ.
  • ಒಂದು ಘಟಕದ ಔಟ್‌ಪುಟ್ ಮುಂದಿನ ಘಟಕದ ನಿರೀಕ್ಷಿತ ಇನ್‌ಪುಟ್ ಸ್ಕೀಮಾಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
  • ಹೊಂದಾಣಿಕೆಯ ಕೊರತೆ, ವಿತರಣೆಯ ಕೊರತೆ ಅಥವಾ ಅನಿರೀಕ್ಷಿತ ಪೇಲೋಡ್ ಗಾತ್ರಗಳ ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆ (alert) ನೀಡಿ.

ಗ್ರಾಹಕರ ದೂರು ಬಂದ ನಂತರವಷ್ಟೇ ಅಲ್ಲದೆ, ಈ ಲಾಗ್‌ಗಳನ್ನು ಮುನ್ನೆಚ್ಚರಿಕೆಯಾಗಿ ಸಂಗ್ರಹಿಸಿ.

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

Source: https://dev.to/babarmaker76/three-signal-layers-where-ai-agent-silent-failures-hide-1k02

Community for deeper discussion: https://t.me/GyaanSetuAi