Microsoft-এর Foundry টিম তাদের এজেন্ট ফ্রেমওয়ার্কে OpenTelemetry-ভিত্তিক ট্রেসিং (tracing) যুক্ত করেছে, যা ডেভেলপারদের বিভিন্ন ধরণের LLM-চালিত এজেন্টগুলোর মধ্যে এন্ড-টু-এন্ড (end-to-end) কার্যপ্রক্রিয়া দেখার সুযোগ করে দিচ্ছে।

কেন মাল্টি-এজেন্ট সিস্টেমের জন্য শুধু লগ ফাইল যথেষ্ট নয়

একটি সাধারণ AI-চালিত ইনসিডেন্ট-রেসপন্স ড্রিল (incident-response drill) একটি কমান্ডার এজেন্ট ব্যবহার করে যা বেশ কিছু স্পেশালিস্ট এজেন্টকে পরিচালনা করে: একটি লগ পার্স (parse) করে, অন্যটি মেট্রিক অ্যানোমালি (metric anomalies) শনাক্ত করে, তৃতীয়টি লক্ষণগুলোকে রানবুকের (runbook) সাথে মেলায় এবং একটি রাউটার প্রতিটি সাব-টাস্কের জন্য সেরা ল্যাঙ্গুয়েজ মডেল বেছে নেয়। প্রতিটি স্পেশালিস্ট ভিন্ন ভিন্ন মডেল ব্যবহার করতে পারে—যেমন, একটি “gpt-5-mini” ভেরিয়েন্ট—এবং তাদের নিজস্ব টুলস ব্যবহার করতে পারে। যখন কোনো সমস্যা হয়, ইঞ্জিনিয়াররা বিচ্ছিন্ন লগগুলোর দিকে তাকিয়ে থাকেন যা প্রতিটি কম্পোনেন্ট কী করেছে তা দেখায়, কিন্তু পুরো প্রক্রিয়াটি কীভাবে কাজ করছে তার কোনো সামগ্রিক চিত্র দেখায় না।

একটি ইউনিফাইড ট্রেস (unified trace) ছাড়া, এজেন্টদের মধ্যে ডেটা হস্তান্তরের সময় মূল কারণটি (root cause) লুকিয়ে থাকে। কমান্ডার এমন একটি রিকোয়েস্ট পাঠাতে পারে যা লগ-রিডার সঠিকভাবে হ্যান্ডেল করে, কিন্তু মেট্রিক স্পেশালিস্ট ডেটা ভুলভাবে ব্যাখ্যা করতে পারে এবং ভুল রানবুক সাজেস্ট করতে পারে। এই চেইনটি ম্যানুয়ালি ডিবাগ করা অনেক সময়সাপেক্ষ এবং এতে ভুলের সম্ভাবনা থাকে।

কীভাবে OpenTelemetry ওয়ার্কফ্লোকে একত্রে যুক্ত করে

OpenTelemetry দুটি মূল ধারণা সংজ্ঞায়িত করে: traces এবং spans। একটি trace হলো একটি অনন্য আইডেন্টিফায়ার যা একটি রিকোয়েস্টের শুরু থেকে শেষ পর্যন্ত অনুসরণ করে। একটি span সেই trace-এর মধ্যে একটি একক অপারেশন রেকর্ড করে—যেমন ল্যাঙ্গুয়েজ মডেল কল করা বা কোনো টুল ইনভোকেশন (tool invocation)।

যখন একটি এজেন্ট একটি রিকোয়েস্ট পায়, তখন এটি রিকোয়েস্টের মেটাডেটা থেকে ইনকামিং Trace ID সংগ্রহ করে এবং একটি চাইল্ড স্প্যান (child span) তৈরি করে যা একই ID উত্তরাধিকারসূত্রে পায়। চাইল্ড স্প্যানটি তার শুরুর সময়, সময়কাল, অ্যাট্রিবিউটস (মডেলের নাম, ব্যবহৃত টুল) এবং যেকোনো ত্রুটি লগ করে। এই প্রক্রিয়াটি প্রতিটি ডাউনস্ট্রিম এজেন্টের জন্য পুনরাবৃত্তি হয়, যা একটি ট্রি (tree) তৈরি করে যা সামগ্রিক টাস্কের লজিক্যাল ফ্লো বা যৌক্তিক প্রবাহকে প্রতিফলিত করে।

OpenTelemetry Baggage-কেও সাপোর্ট করে, যা কাস্টম কী-ভ্যালু পেয়ারের (key-value pairs) জন্য একটি লাইটওয়েট ক্যারিয়ার। ট্রেসের শুরুতে ব্যাগেজে (baggage) একটি “drill-id” বা অন্যান্য বিজনেস কনটেক্সট যুক্ত করার মাধ্যমে, প্রতিটি ডাউনস্ট্রিম স্প্যান স্বয়ংক্রিয়ভাবে সেই আইডেন্টিফায়ারটি পেয়ে যায়। এরপর একটি স্প্যান প্রসেসর সেই ব্যাগেজকে সাধারণ অ্যাট্রিবিউটে রূপান্তরিত করে, ফলে একটি নির্দিষ্ট ইনসিডেন্ট ড্রিলের সাথে সম্পর্কিত সমস্ত স্প্যান কুয়েরি করা সহজ হয়।

নতুন ট্রেসিং সারফেসটি দেখতে কেমন

ইন্সট্রুমেন্টেশন (instrumentation) সম্পন্ন হলে, Azure Monitor (বা যেকোনো OpenTelemetry-সামঞ্জস্যপূর্ণ ব্যাকএন্ড) একটি ভিজ্যুয়াল হায়ারার্কি বা দৃশ্যমান শ্রেণিবিন্যাস প্রদর্শন করে:

  • Agent name / ID – কোন কম্পোনেন্ট অপারেশনটি সম্পন্ন করেছে তা দেখায়।
  • Tool usage – কোন এক্সটার্নাল সার্ভিস বা ফাংশন কল করা হয়েছে তা রেকর্ড করে।
  • Model version – কোন নির্দিষ্ট LLM ব্যবহার করা হয়েছে তা লগ করে, যা মডেল আপগ্রেডের পর রিগ্রেশন (regression) ট্র্যাক করতে সহায়ক।
  • Token consumption – মডেলে কতগুলো টোকেন পাঠানো হয়েছে এবং কতগুলো টোকেন গ্রহণ করা হয়েছে তা ক্যাপচার করে, যা টিমগুলোকে খরচ নিয়ন্ত্রণে রাখতে সাহায্য করে।
  • Latency / duration – কোথায় বাটলনেক (bottleneck) বা বাধা সৃষ্টি হচ্ছে তা চিহ্নিত করে, তা মডেল ইনফারেন্স (inference) বা টুল I/O যাই হোক না কেন।

ইনসিডেন্ট-ড্রিল উদাহরণটিতে, কমান্ডারের রুট স্প্যান (root span) প্রতিটি স্পেশালিস্টের জন্য চাইল্ড স্প্যান তৈরি করে এবং প্রতিটি স্পেশালিস্ট তার মডেল কলের জন্য আরও চাইল্ড স্প্যান তৈরি করে। যেকোনো নোডে ক্লিক করলে সম্পূর্ণ অ্যাট্রিবিউট সেট দেখা যায়, ফলে একজন ইঞ্জিনিয়ার তাৎক্ষণিকভাবে প্রতিটি অপারেশনের বিস্তারিত দেখতে পান।

AI-কেন্দ্রিক অপারেশনের গুরুত্ব

  • রুট-কজ অ্যানালাইসিসের গতি (Speed of root-cause analysis) – টিমগুলো একটি ব্যর্থতাকে ঠিক সেই স্প্যানে ট্র্যাক করতে পারে যেখানে ত্রুটি দেখা দিয়েছিল, যা সমস্যার সমাধানের গড় সময় (mean time to resolution) কমিয়ে দেয়।
  • খরচের স্বচ্ছতা (Cost visibility) – ল্যাটেন্সির পাশাপাশি টোকেন সংখ্যা দেখা যায়, যা ফিন্যান্স টিমকে ক্লাউড বিল বাড়ার আগেই অতিরিক্ত ব্যবহারের বিষয়টি শনাক্ত করতে সাহায্য করে।
  • পারফরম্যান্স টিউনিং (Performance tuning) – এজেন্টগুলোর মধ্যে হাই-ল্যাটেন্সি স্প্যানগুলো নির্দেশ করে যে কোথায় ক্যাশিং (caching), মডেল সিলেকশন বা টুল রিডিজাইন করার মাধ্যমে থ্রুপুট (throughput) বাড়ানো সম্ভব।

পরবর্তীতে যা লক্ষ্য রাখতে হবে

LangChain, OpenAI SDK বা অন্যান্য অর্কেস্ট্রেশন লেয়ারের ওপর ভিত্তি করে তৈরি প্রজেক্টগুলো GenAI-এর জন্য একই সিম্যান্টিক কনভেনশন (semantic conventions) গ্রহণ করতে পারে, যা ক্লাউড প্রোভাইডার এবং অন-প্রিমিস (on-premise) ডেপ্লয়মেন্টের মধ্যে প্রবাহিত ট্রেসিংয়ের পথ প্রশস্ত করবে।

সংস্থাগুলো কেবল তাদের এজেন্টগুলোতে OpenTelemetry SDK সক্রিয় করবে এবং Azure Monitor বা কোনো ওপেন-সোর্স কালেক্টরে ডেটা পাঠাবে।

সারসংক্ষেপ

OpenTelemetry মাল্টি-এজেন্ট AI সিস্টেমগুলোকে সেই প্রয়োজনীয় সংযোগ প্রদান করে যা বিচ্ছিন্ন লগগুলোকে একটি সুসংগত বর্ণনায় রূপান্তরিত করে। বিভিন্ন ধরণের LLM, রাউটার এবং টুল কলের মাধ্যমে একটি একক Trace ID ছড়িয়ে দেওয়ার মাধ্যমে, ডেভেলপাররা ট্রেসিং ইনফ্রাস্ট্রাকচার নতুন করে তৈরি না করেই ত্রুটি শনাক্ত করতে পারেন, খরচ পর্যবেক্ষণ করতে পারেন এবং পারফরম্যান্স অপ্টিমাইজ করতে পারেন।