Microsoft کی Foundry ٹیم نے اپنے ایجنٹ فریم ورک میں OpenTelemetry پر مبنی ٹریسنگ (tracing) کا اضافہ کر دیا ہے، جس سے ڈویلپرز کو مختلف اقسام کے LLM سے چلنے والے ایجنٹس کے درمیان اینڈ ٹو اینڈ (end-to-end) عمل کو دیکھنے کا طریقہ مل گیا ہے۔

ملٹی ایجنٹ سسٹمز کو لاگ فائلوں سے زیادہ کیوں ضرورت ہے

ایک عام AI سے چلنے والی انسیڈنٹ ریسپانس ڈرل (incident-response drill) میں ایک کمانڈر ایجنٹ استعمال ہوتا ہے جو کئی ماہر ایجنٹس (specialist agents) کی نگرانی کرتا ہے: ایک لاگز کا تجزیہ کرتا ہے، دوسرا میٹرک کی بے قاعدگیوں (anomalies) کا پتہ لگاتا ہے، تیسرا علامات کو رن بکس (runbooks) سے ملاتا ہے، اور ایک روٹر ہر ذیلی کام کے لیے بہترین لینگویج ماڈل کا انتخاب کرتا ہے۔ ہر ماہر ایجنٹ ایک مختلف ماڈل—مثلاً "gpt-5-mini" کا کوئی ورژن—استعمال کر سکتا ہے اور اپنے ٹولز کو کال کر سکتا ہے۔ جب کچھ غلط ہوتا ہے، تو انجینئرز الگ تھلگ لاگز کو دیکھتے ہیں جو یہ تو بتاتے ہیں کہ ہر جز (component) نے کیا کیا، لیکن یہ نہیں دکھاتے کہ تمام حصے آپس میں کیسے جڑے ہوئے ہیں۔

ایک متحد ٹریس (unified trace) کے بغیر، اصل وجہ (root cause) ایجنٹس کے درمیان کام کی منتقلی (hand-off) میں چھپ جاتی ہے۔ ہو سکتا ہے کہ کمانڈر ایک ایسی درخواست بھیجے جسے لاگ ریڈر درست طریقے سے سنبھال لے، لیکن میٹرک اسپیشلسٹ ڈیٹا کی غلط تشریح کرے اور غلط رن بک تجویز کر دے۔ اس زنجیر کی دستی طور پر ڈیبگنگ (debugging) کرنے میں وقت لگتا ہے اور غلطی کا امکان بھی رہتا ہے۔

OpenTelemetry ورک فلو کو کیسے یکجا کرتا ہے

OpenTelemetry دو بنیادی تصورات کی تعریف کرتا ہے: traces اور spans۔ ٹریس (trace) ایک منفرد شناختی نمبر (unique identifier) ہے جو درخواست کے آغاز سے لے کر حتمی جواب تک اس کا پیچھا کرتا ہے۔ اسپین (span) اس ٹریس کے اندر ایک واحد آپریشن—جیسے لینگویج ماڈل کو کال کرنا یا کسی ٹول کا استعمال—کو ریکارڈ کرتا ہے۔

جب کوئی ایجنٹ درخواست وصول کرتا ہے، تو وہ درخواست کے میٹا ڈیٹا (metadata) سے آنے والی Trace ID حاصل کرتا ہے اور ایک چائلڈ اسپین (child span) بناتا ہے جو اسی ID کو وراثت میں لیتا ہے۔ چائلڈ اسپین اپنے شروع ہونے کا وقت، دورانیہ، خصوصیات (ماڈل کا نام، استعمال شدہ ٹول) اور کسی بھی غلطی کو لاگ میں محفوظ کرتا ہے۔ یہ عمل ہر ڈاؤن اسٹریم (downstream) ایجنٹ کے لیے دہرایا جاتا ہے، جس سے ایک ایسا درخت (tree) بنتا ہے جو مجموعی کام کے منطقی بہاؤ کی عکاسی کرتا ہے۔

OpenTelemetry Baggage کو بھی سپورٹ کرتا ہے، جو کسٹم کی-ویلیو (key-value) جوڑوں کے لیے ایک ہلکا پھلکا کیریئر ہے۔ ٹریس کے آغاز پر بیگیج (baggage) کے ساتھ "drill-id" یا دیگر کاروباری سیاق و سباق (business context) منسلک کر کے، ہر ڈاؤن اسٹریم اسپین خود بخود اس شناختی نمبر کو حاصل کر لیتا ہے۔ اس کے بعد ایک اسپین پروسیسر بیگیج کو عام خصوصیات (attributes) میں تبدیل کر دیتا ہے، جس سے کسی خاص انسیڈنٹ ڈرل سے متعلق تمام اسپینز کو تلاش کرنا آسان ہو جاتا ہے۔

نیا ٹریسنگ سر فیس کیسا دکھتا ہے

انسٹرومینٹیشن (instrumentation) کے بعد، Azure Monitor (یا کوئی بھی OpenTelemetry کے ہم آہنگ بیک اینڈ) ایک بصری درجہ بندی (visual hierarchy) پیش کرتا ہے:

  • Agent name / ID – دکھاتا ہے کہ کس جز (component) نے آپریشن انجام دیا۔
  • Tool usage – ریکارڈ کرتا ہے کہ کس بیرونی سروس یا فنکشن کو کال کیا گیا۔
  • Model version – استعمال شدہ درست LLM کو لاگ کرتا ہے، جو ماڈل اپ گریڈ کے بعد ریگریشنز (regressions) کو ٹریک کرنے کے لیے مفید ہے۔
  • Token consumption – یہ ریکارڈ کرتا ہے کہ ماڈل کو کتنے ٹوکنز بھیجے گئے اور کتنے وصول کیے گئے، جس سے ٹیموں کو لاگت کے انتظام میں مدد ملتی ہے۔
  • Latency / duration – ان مقامات کی نشاندہی کرتا ہے جہاں رکاوٹیں (bottlenecks) نظر آتی ہیں، چاہے وہ ماڈل انفرنس (inference) میں ہوں یا ٹول I/O میں۔

انسیڈنٹ ڈرل کی مثال میں، کمانڈر کا روٹ اسپین (root span) ہر ماہر کے لیے چائلڈ اسپینز پیدا کرتا ہے، اور ہر ماہر اپنے ماڈل کالز کے لیے مزید چائلڈ اسپینز پیدا کرتا ہے۔ کسی بھی نوڈ (node) پر کلک کرنے سے مکمل خصوصیات (attributes) کا سیٹ ظاہر ہو جاتا ہے، تاکہ انجینئر فوری طور پر ہر آپریشن کی تفصیلات دیکھ سکے۔

AI پر مبنی آپریشنز کے لیے اہمیت

  • اصل وجہ کے تجزیے کی رفتار (Speed of root-cause analysis) – ٹیمیں کسی ناکامی کو ٹھیک اسی اسپین تک ٹریس کرتی ہیں جس نے ایرر (error) دیا ہو، جس سے مسئلے کے حل کا اوسط وقت (mean time to resolution) کم ہو جاتا ہے۔
  • لاگت کی وضاحت (Cost visibility) – ٹوکن کی تعداد لیٹنسی (latency) کے ساتھ دکھائی دیتی ہے، جس سے فنانس ٹیم کلاؤڈ بلوں کے بڑھنے سے پہلے ہی بے تحاشہ استعمال کو پکڑ سکتی ہے۔
  • کارکردگی کی بہتری (Performance tuning) – ایجنٹس کے درمیان ہائی لیٹنسی اسپینز ان مقامات کی نشاندہی کرتے ہیں جہاں کیشنگ (caching)، ماڈل کا انتخاب یا ٹول کی دوبارہ ڈیزائننگ تھرو پٹ (throughput) کو بڑھا سکتی ہے۔

آگے کیا دیکھنا ہے

LangChain، OpenAI SDK یا دیگر آرکیسٹریشن لیئرز پر مبنی پروجیکٹس GenAI کے لیے انہی سیمنٹک کنونشنز (semantic conventions) کو اپنا سکتے ہیں، جس سے ایسے ٹریسز کی راہ ہموار ہوگی جو کلاؤڈ فراہم کنندگان اور آن پریمیس (on-premise) ڈیپلائمنٹس کے درمیان بہہ سکیں۔

ادارے محض اپنے ایجنٹس میں OpenTelemetry SDK کو فعال کرتے ہیں اور ڈیٹا Azure Monitor یا کسی اوپن سورس کلیکٹر (open-source collector) کو بھیج دیتے ہیں۔

خلاصہ

OpenTelemetry ملٹی ایجنٹ AI سسٹمز کو وہ گمشدہ جوڑ فراہم کرتا ہے جو بکھرے ہوئے لاگز کو ایک مربوط بیانیے (coherent narrative) میں بدل دیتا ہے۔ مختلف اقسام کے LLMs، روٹرز اور ٹول کالز کے درمیان ایک ہی Trace ID کو پھیلا کر، ڈویلپرز ٹریسنگ انفراسٹرکچر کو دوبارہ ایجاد کیے بغیر ناکامیوں کا پتہ لگا سکتے ہیں، لاگت کی نگرانی کر سکتے ہیں اور کارکردگی کو بہتر بنا سکتے ہیں۔