Microsoft ನ Foundry ತಂಡವು ತನ್ನ ಏಜೆಂಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗೆ OpenTelemetry ಆಧಾರಿತ ಟ್ರೇಸಿಂಗ್ ಅನ್ನು ಸೇರಿಸಿದೆ, ಇದು ವಿವಿಧ ರೀತಿಯ LLM-ಚಾಲಿತ ಏಜೆಂಟ್‌ಗಳಾದ ಇಡೀ ಕಾರ್ಯವಿಧಾನವನ್ನು (end-to-end execution) ನೋಡಲು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಒಂದು ಮಾರ್ಗವನ್ನು ನೀಡುತ್ತದೆ.

ಮಲ್ಟಿ-ಏಜೆಂಟ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಕೇವಲ ಲಾಗ್ ಫೈಲ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನದೇಕೆ ಬೇಕು?

ಒಂದು ಸಾಮಾನ್ಯ AI-ಚಾಲಿತ ಇನ್ಸಿಡೆಂಟ್-ರಿಸ್ಪಾನ್ಸ್ ಡ್ರಿಲ್ (incident-response drill) ಒಂದು ಕಮಾಂಡರ್ ಏಜೆಂಟ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಇದು ಹಲವಾರು ಸ್ಪೆಷಲಿಸ್ಟ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ಸಂಘಟಿಸುತ್ತದೆ: ಒಂದು ಲಾಗ್ಸ್‌ಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡುತ್ತದೆ, ಇನ್ನೊಂದು ಮೆಟ್ರಿಕ್ ಅನಾಮಧೇಯತೆಗಳನ್ನು (metric anomalies) ಪತ್ತೆಹಚ್ಚುತ್ತದೆ, ಮೂರನೆಯದು ಲಕ್ಷಣಗಳನ್ನು ರನ್‌ಬುಕ್‌ಗಳಿಗೆ ಹೊಂದಿಸುತ್ತದೆ ಮತ್ತು ರೌಟರ್ ಪ್ರತಿ ಉಪ-ಕಾರ್ಯಕ್ಕಾಗಿ (sub-task) ಅತ್ಯುತ್ತಮ ಭಾಷಾ ಮಾದರಿಯನ್ನು (language model) ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಸ್ಪೆಷಲಿಸ್ಟ್ ವಿಭಿನ್ನ ಮಾದರಿಯನ್ನು—ಉದಾಹರಣೆಗೆ, “gpt-5-mini” ವೇರಿಯಂಟ್—ಕರೆ ಮಾಡಬಹುದು ಮತ್ತು ತನ್ನದೇ ಆದ ಪರಿಕರಗಳನ್ನು (tools) ಬಳಸಬಹುದು. ಏನಾದರೂ ತಪ್ಪಾದಾಗ, ಎಂಜಿನಿಯರ್‌ಗಳು ಪ್ರತಿಯೊಂದು ಘಟಕವು ಏನು ಮಾಡಿತು ಎಂಬುದನ್ನು ತೋರಿಸುವ ಪ್ರತ್ಯೇಕ ಲಾಗ್ಸ್‌ಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತಾರೆ, ಆದರೆ ಆ ಭಾಗಗಳು ಹೇಗೆ ಒಂದಕ್ಕೊಂದು ಹೊಂದಾಣಿಕೆಯಾಗಿವೆ ಎಂಬ ದೃಷ್ಟಿಕೋನ ಅವರಿಗೆ ಸಿಗುವುದಿಲ್ಲ.

ಏಕೀಕೃತ ಟ್ರೇಸ್ (unified trace) ಇಲ್ಲದಿದ್ದರೆ, ಮೂಲ ಕಾರಣವು ಏಜೆಂಟ್‌ಗಳ ನಡುವಿನ ಹಸ್ತಾಂತರದಲ್ಲಿ (hand-off) ಅಡಗಿರುತ್ತದೆ. ಕಮಾಂಡರ್ ಕಳುಹಿಸಿದ ವಿನಂತಿಯನ್ನು ಲಾಗ್-ರೀಡರ್ ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸಬಹುದು, ಆದರೆ ಮೆಟ್ರಿಕ್ ಸ್ಪೆಷಲಿಸ್ಟ್ ಡೇಟಾವನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಬಹುದು ಮತ್ತು ತಪ್ಪು ರನ್‌ಬುಕ್ ಅನ್ನು ಸೂಚಿಸಬಹುದು. ಅಂತಹ ಸರಪಳಿಯನ್ನು ಕೈಯಿಂದ ಡಿಬಗ್ ಮಾಡುವುದು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ತಪ್ಪುಗಳಿಗೆ ದಾರಿಯಾಗುತ್ತದೆ.

OpenTelemetry ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಹೇಗೆ ಒಟ್ಟಿಗೆ ಸೇರಿಸುತ್ತದೆ

OpenTelemetry ಎರಡು ಪ್ರಮುಖ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ: traces ಮತ್ತು spans. ಟ್ರೇಸ್ ಎಂಬುದು ವಿನಂತಿಯು ಪ್ರವೇಶದಿಂದ ಅಂತಿಮ ಪ್ರತಿಕ್ರಿಯೆಯವರೆಗೆ ಅನುಸರಿಸುವ ಒಂದು ವಿಶಿಷ್ಟ ಗುರುತಾಗಿದೆ (unique identifier). ಸ್ಪಾನ್ (span) ಎಂಬುದು ಆ ಟ್ರೇಸ್‌ನೊಳಗಿನ ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಾಚರಣೆಯನ್ನು—ಉದಾಹರಣೆಗೆ, ಭಾಷಾ ಮಾದರಿಗೆ ಮಾಡುವ ಕರೆ ಅಥವಾ ಪರಿಕರದ ಬಳಕೆಯನ್ನು—ದಾಖಲಿಸುತ್ತದೆ.

ಒಂದು ಏಜೆಂಟ್ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ಅದು ವಿನಂತಿಯ ಮೆಟಾಡೇಟಾದಿಂದ (metadata) ಬರುವ Trace ID ಅನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದೇ ID ಅನ್ನು ವಾರಸುವಾಗಿ ಪಡೆಯುವ (inherits) ಚೈಲ್ಡ್ ಸ್ಪಾನ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಚೈಲ್ಡ್ ಸ್ಪಾನ್ ತನ್ನ ಪ್ರಾರಂಭದ ಸಮಯ, ಅವಧಿ, ಗುಣಲಕ್ಷಣಗಳು (ಮಾದರಿ ಹೆಸರು, ಬಳಸಿದ ಪರಿಕರ) ಮತ್ತು ಯಾವುದೇ ದೋಷಗಳನ್ನು ಲಾಗ್ ಮಾಡುತ್ತದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯು ಪ್ರತಿಯೊಂದು ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಏಜೆಂಟ್‌ಗೂ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ, ಇದು ಒಟ್ಟಾರೆ ಕಾರ್ಯದ ತಾರ್ಕಿಕ ಹರಿವನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವ ಒಂದು ಮರವನ್ನು (tree) ನಿರ್ಮಿಸುತ್ತದೆ.

OpenTelemetry Baggage ಅನ್ನು ಸಹ ಬೆಂಬಲಿಸುತ್ತದೆ, ಇದು ಕಸ್ಟಮ್ ಕೀ-ವ್ಯಾಲ್ಯೂ ಜೋಡಿಗಳಿಗಾಗಿ (key-value pairs) ಬಳಸುವ ಒಂದು ಲಘು ವಾಹಕವಾಗಿದೆ. ಟ್ರೇಸ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಬ್ಯಾಗೇಜ್‌ಗೆ “drill-id” ಅಥವಾ ಇತರ ವ್ಯವಹಾರ ಸಂದರ್ಭವನ್ನು (business context) ಜೋಡಿಸುವ ಮೂಲಕ, ಪ್ರತಿಯೊಂದು ಡೌನ್‌ಸ್ಟ್ರೀಮ್ ಸ್ಪಾನ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಆ ಗುರುತನ್ನು ಪಡೆಯುತ್ತದೆ. ನಂತರ ಸ್ಪಾನ್ ಪ್ರೊಸೆಸರ್ ಬ್ಯಾಗೇಜ್ ಅನ್ನು ಸಾಮಾನ್ಯ ಗುಣಲಕ್ಷಣಗಳಾಗಿ (attributes) ಪರಿವರ್ತಿಸುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಇನ್ಸಿಡೆಂಟ್ ಡ್ರಿಲ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲಾ ಸ್ಪಾನ್‌ಗಳನ್ನು ಸುಲಭವಾಗಿ ಹುಡುಕಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಹೊಸ ಟ್ರೇಸಿಂಗ್ ಸರ್ಫೇಸ್ ಹೇಗಿರುತ್ತದೆ

ಇನ್‌ಸ್ಟ್ರುಮೆಂಟೇಶನ್ (instrumentation) ಸಿದ್ಧವಿರುವಾಗ, Azure Monitor (ಅಥವಾ ಯಾವುದೇ OpenTelemetry-ಅನುಸರಣೆಯ ಬ್ಯಾಕೆಂಡ್) ಒಂದು ದೃಶ್ಯ ಶ್ರೇಣಿಯನ್ನು (visual hierarchy) ಪ್ರದರ್ಶಿಸುತ್ತದೆ:

  • Agent name / ID – ಯಾವ ಘಟಕವು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
  • Tool usage – ಯಾವ ಬಾಹ್ಯ ಸೇವೆ ಅಥವಾ ಫಂಕ್ಷನ್ ಅನ್ನು ಕರೆಯಲಾಗಿದೆ ಎಂಬುದನ್ನು ದಾಖಲಿಸುತ್ತದೆ.
  • Model version – ಬಳಸಲಾದ ನಿಖರವಾದ LLM ಅನ್ನು ಲಾಗ್ ಮಾಡುತ್ತದೆ, ಇದು ಮಾದರಿ ಅಪ್‌ಗ್ರೇಡ್ ನಂತರದ ಬದಲಾವಣೆಗಳನ್ನು (regressions) ಪತ್ತೆಹಚ್ಚಲು ಉಪಯುಕ್ತವಾಗಿದೆ.
  • Token consumption – ಮಾದರಿಗೆ ಎಷ್ಟು ಟೋಕನ್‌ಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ ಮತ್ತು ಮಾದರಿಯಿಂದ ಎಷ್ಟು ಟೋಕನ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಸೆರೆಹಿಡಿಯುತ್ತದೆ, ಇದು ತಂಡಗಳಿಗೆ ವೆಚ್ಚವನ್ನು ನಿರ್ವಹಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
  • Latency / duration – ಮಾದರಿ ಇನ್ಫರೆನ್ಸ್ (model inference) ಅಥವಾ ಟೂಲ್ I/O ನಲ್ಲಿ ಎಲ್ಲಿ ಅಡಚಣೆಗಳು (bottlenecks) ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದನ್ನು ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ.

ಇನ್ಸಿಡೆಂಟ್-ಡ್ರಿಲ್ ಉದಾಹರಣೆಯಲ್ಲಿ, ಕಮಾಂಡರ್‌ನ ರೂಟ್ ಸ್ಪಾನ್ ಪ್ರತಿಯೊಬ್ಬ ಸ್ಪೆಷಲಿಸ್ಟ್‌ಗಾಗಿ ಚೈಲ್ಡ್ ಸ್ಪಾನ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬ ಸ್ಪೆಷಲಿಸ್ಟ್ ತನ್ನ ಮಾದರಿ ಕರೆಗಳಿಗಾಗಿ ಮತ್ತಷ್ಟು ಚೈಲ್ಡ್ ಸ್ಪಾನ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಯಾವುದೇ ನೋಡ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡುವುದರಿಂದ ಸಂಪೂರ್ಣ ಗುಣಲಕ್ಷಣಗಳ ಸೆಟ್ (attribute set) ಬಯಲಾಗುತ್ತದೆ, ಇದರಿಂದ ಎಂಜಿನಿಯರ್ ತಕ್ಷಣವೇ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಾಚರಣೆಯ ವಿವರಗಳನ್ನು ನೋಡಬಹುದು.

AI-ಕೇಂದ್ರಿತ ಕಾರ್ಯಾಚರಣೆಗಳ ಮಹತ್ವ

  • ಮೂಲ-ಕಾರಣ ವಿಶ್ಲೇಷಣೆಯ ವೇಗ (Speed of root-cause analysis) – ತಂಡಗಳು ದೋಷವನ್ನು ಉಂಟುಮಾಡಿದ ನಿಖರವಾದ ಸ್ಪಾನ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಮೂಲಕ, ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸರಾಸರಿ ಸಮಯವನ್ನು (mean time to resolution) ಕಡಿಮೆ ಮಾಡಬಹುದು.
  • ವೆಚ್ಚದ ದೃಶ್ಯತೆ (Cost visibility) – ಟೋಕನ್ ಸಂಖ್ಯೆಗಳು ಲೇಟೆನ್ಸಿಯ ಪಕ್ಕದಲ್ಲಿ ಇರುವುದರಿಂದ, ಕ್ಲೌಡ್ ಬಿಲ್‌ಗಳು ಹೆಚ್ಚಾಗುವ ಮೊದಲು ಹಣಕಾಸು ವಿಭಾಗವು ಅತಿಯಾದ ಬಳಕೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
  • ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಟ್ಯೂನಿಂಗ್ (Performance tuning) – ಏಜೆಂಟ್‌ಗಳ ನಡುವಿನ ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿ ಹೊಂದಿರುವ ಸ್ಪಾನ್‌ಗಳು, ಕ್ಯಾಷಿಂಗ್ (caching), ಮಾದರಿ ಆಯ್ಕೆ ಅಥವಾ ಪರಿಕರಗಳ ಮರು ವಿನ್ಯಾಸವು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು (throughput) ಹೇಗೆ ಹೆಚ್ಚಿಸಬಹುದು ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತವೆ.

ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು

LangChain, OpenAI SDK ಅಥವಾ ಇತರ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಲೇಯರ್‌ಗಳ ಮೇಲೆ ನಿರ್ಮಿಸಲಾದ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು GenAI ಗಾಗಿ ಇದೇ ರೀತಿಯ ಸೆಮ್ಯಾಂಟಿಕ್ ಕನ್ವೆನ್ಷನ್‌ಗಳನ್ನು (semantic conventions) ಅಳವಡಿಸಿಕೊಳ್ಳಬಹುದು, ಇದು ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್‌ಗಳು ಮತ್ತು ಆನ್-ಪ್ರೆಮಿಸ್ ಡಿಪ್ಲಾಯ್‌ಮೆಂಟ್‌ಗಳ ನಡುವೆ ಹರಿಯುವ ಟ್ರೇಸ್‌ಗಳಿಗೆ ದಾರಿ ಮಾಡಿಕೊಡುತ್ತದೆ.

ಸಂಸ್ಥೆಗಳು ಕೇವಲ ತಮ್ಮ ಏಜೆಂಟ್‌ಗಳಲ್ಲಿ OpenTelemetry SDK ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ, ಡೇಟಾವನ್ನು Azure Monitor ಅಥವಾ ಓಪನ್-ಸೋರ್ಸ್ ಕಲೆಕ್ಟರ್‌ಗೆ ಕಳುಹಿಸಬಹುದು.

ಸಾರಾಂಶ

OpenTelemetry ಮಲ್ಟಿ-ಏಜೆಂಟ್ AI ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಚದುರಿಹೋಗಿರುವ ಲಾಗ್ಸ್‌ಗಳನ್ನು ಒಂದು ಸುಸಂಬದ್ಧ ಕಥೆಯನ್ನಾಗಿ (coherent narrative) ಪರಿವರ್ತಿಸುವ ಅಗತ್ಯವಾದ ಕೊಂಡಿಯನ್ನು ನೀಡುತ್ತದೆ. ವಿವಿಧ ರೀತಿಯ LLMಗಳು, ರೌಟರ್‌ಗಳು ಮತ್ತು ಟೂಲ್ ಕರೆಗಳಾದ್ಯಂತ ಒಂದೇ Trace ID ಅನ್ನು ಪ್ರಸಾರ ಮಾಡುವ ಮೂಲಕ, ಡೆವಲಪರ್‌ಗಳು ಟ್ರೇಸಿಂಗ್ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಅನ್ನು ಮರುಸೃಷ್ಟಿಸುವ ಅಗತ್ಯವಿಲ್ಲದೆ ವೈಫಲ್ಯಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು, ವೆಚ್ಚವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸಬಹುದು.