تیم Foundry مایکروسافت قابلیت ردیابی (tracing) مبتنی بر OpenTelemetry را به چارچوب عامل (agent framework) خود اضافه کرده است که به توسعهدهندگان راهی برای مشاهده اجرای سرتاسری (end-to-end) در میان عاملهای ناهمگون مبتنی بر LLM میدهد.
چرا سیستمهای چندعاملی به چیزی فراتر از فایلهای لاگ نیاز دارند
یک تمرین معمول پاسخ به حادثه مبتنی بر هوش مصنوعی، از یک عامل فرمانده (commander agent) استفاده میکند که چندین عامل متخصص را هماهنگ میکند: یکی لاگها را تجزیه میکند، دیگری ناهنجاریهای متریک را شناسایی میکند، سومی علائم را با دستورالعملهای اجرایی (runbooks) تطبیق میدهد و یک مسیریاب (router)، بهترین مدل زبانی را برای هر زیر-وظیفه انتخاب میکند. هر متخصص ممکن است مدل متفاوتی را فراخوانی کند — مثلاً نسخهای از “gpt-5-mini” — و ابزارهای خود را به کار بگیرد. وقتی مشکلی پیش میآید، مهندسان به لاگهای پراکنده خیره میشوند که نشان میدهند هر جزء چه کاری انجام داده است، اما هیچ دید کلی از نحوه اتصال این قطعات به یکدیگر ندارند.
بدون یک trace یکپارچه، علت اصلی در فرآیند تحویل وظایف بین عاملها پنهان میماند. ممکن است فرمانده درخواستی را ارسال کند که خواننده لاگ آن را به درستی مدیریت کند، اما متخصص متریک دادهها را اشتباه تفسیر کرده و دستورالعمل اجرایی نادرستی را پیشنهاد دهد. عیبیابی دستی این زنجیره زمانبر است و احتمال خطا را افزایش میدهد.
چگونه OpenTelemetry جریان کاری را به هم متصل میکند
OpenTelemetry دو مفهوم اصلی را تعریف میکند: traces و spans. یک trace یک شناسه منحصربهفرد است که یک درخواست را از لحظه ورود تا پاسخ نهایی دنبال میکند. یک span یک عملیات واحد — مانند فراخوانی یک مدل زبانی یا اجرای یک ابزار — را در آن trace ثبت میکند.
وقتی یک عامل درخواستی را دریافت میکند، Trace ID ورودی را از متادیتای درخواست استخراج کرده و یک child span ایجاد میکند که همان شناسه را به ارث میبرد. این child span زمان شروع، مدت زمان، ویژگیها (مانند نام مدل، ابزار استفاده شده) و هرگونه خطا را ثبت میکند. این فرآیند برای هر عامل پاییندستی تکرار میشود و درختی ایجاد میکند که بازتابدهنده جریان منطقی کل وظیفه است.
OpenTelemetry همچنین از Baggage پشتیبانی میکند که یک حامل سبک برای جفتهای کلید-مقدار سفارشی است. با پیوست کردن یک “drill-id” یا سایر زمینههای تجاری به baggage در ابتدای trace، هر span پاییندستی بهطور خودکار آن شناسه را به ارث میبرد. سپس یک span processor، این baggage را به ویژگیهای (attributes) معمولی ارتقا میدهد و پرسوجو (query) برای تمام spanهای مربوط به یک تمرین حادثه خاص را آسان میکند.
ظاهر سطح جدید ردیابی چگونه است
با پیادهسازی ابزارگذاری (instrumentation)، Azure Monitor (یا هر بکانند سازگار با OpenTelemetry) یک سلسلهمراتب بصری را نمایش میدهد:
- Agent name / ID – نشان میدهد کدام جزء عملیات را انجام داده است.
- Tool usage – ثبت میکند که کدام سرویس یا تابع خارجی فراخوانی شده است.
- Model version – دقیقاً LLM استفاده شده را ثبت میکند که برای ردیابی افت عملکرد (regressions) پس از ارتقای مدل مفید است.
- Token consumption – تعداد توکنهای ارسالی به مدل و دریافتی از آن را ثبت میکند که به تیمها در مدیریت هزینهها کمک میکند.
- Latency / duration – گلوگاهها را مشخص میکند، خواه در استنتاج مدل (model inference) باشد یا در ورودی/خروجی (I/O) ابزار.
در مثال تمرین حادثه، root span فرمانده، child spanهایی برای هر متخصص ایجاد میکند و هر متخصص نیز childهایی را برای فراخوانیهای مدل خود ایجاد میکند. با کلیک بر روی هر گره (node)، مجموعه کامل ویژگیها نمایش داده میشود تا مهندس بتواند بلافاصله جزئیات هر عملیات را مشاهده کند.
اهمیت موضوع برای عملیاتهای متمرکز بر هوش مصنوعی
- سرعت تحلیل علت اصلی – تیمها شکست را تا دقیقترین span که خطا داده است ردیابی میکنند و این کار میانگین زمان رفع مشکل (MTTR) را کاهش میدهد.
- شفافیت هزینهها – تعداد توکنها در کنار تأخیر (latency) قرار میگیرند و به بخش مالی اجازه میدهند تا قبل از افزایش چشمگیر صورتحسابهای ابری، مصرفهای بیرویه را شناسایی کنند.
- تنظیم عملکرد – spanهای با تأخیر بالا در میان عاملها، نقاطی را نشان میدهند که در آنها استفاده از کش (caching)، انتخاب مدل یا بازطراحی ابزار میتواند نرخ پردازش (throughput) را بهبود بخشد.
آنچه باید در آینده دنبال کرد
پروژههای ساخته شده بر پایه LangChain، OpenAI SDK یا سایر لایههای هماهنگساز (orchestration) میتوانند همان قراردادهای معنایی (semantic conventions) را برای GenAI اتخاذ کنند و راه را برای ردیابیهایی هموار کنند که در میان ارائهدهندگان ابری و استقرارهای محلی (on-premise) جریان دارند.
سازمانها بهسادگی OpenTelemetry SDK را در عاملهای خود فعال کرده و دادهها را به Azure Monitor یا یک collector متنباز ارسال میکنند.
جمعبندی
OpenTelemetry همان پیوند مفقودی را به سیستمهای هوش مصنوعی چندعاملی میدهد که پراکندگی لاگها را به یک روایت منسجم تبدیل میکند. با انتشار یک Trace ID واحد در میان LLMهای ناهمگون، مسیریابها و فراخوانیهای ابزار، توسعهدهندگان میتوانند خطاها را مکانیابی کنند، هزینهها را نظارت کنند و عملکرد را بدون نیاز به بازطراحی زیرساخت ردیابی، بهینه سازند.