به گزارش از وبسایت cncf 🤖 Traditional APM نمی‌تواند به شما توضیح دهد که چرا نماینده‌تان برای پرسیدن یک سؤال سه‌بار، به‌طور غیرعادی هزینه کرده است. ما چندین ماه است که عوامل مبتنی بر هوش مصنوعی را تولید و به‌کار می‌گیریم؛ سخت‌ترین بخش، ساختن آن‌ها نیست، بلکه فهمیدن این است که وقتی اشتباه می‌کنند چه اتفاقی می‌افتد.
این عوامل با ردیابیِ پشته به‌صورت معمولی خراب نمی‌شوند؛ آن‌ها در حلقه می‌افتند، دچار hallucination می‌شوند، توکن‌ها را مصرف می‌کنند و خروجی‌هایی با ظاهر قابل قبول تولید می‌کنند که به‌طور نامحسوسی نادرست است. 🔍 در ادامه آنچه آموخته‌ایم را مرور می‌کنیم.
چرا مانیتورینگِ سنتی ناکافی است؟ نظارت بر یک برنامهٔ معمولی به پرسش‌های پایه‌ای مثل: «آیا سرویس بالا است؟»، «زمان پاسخ چقدر است؟» و «آیا خطایی وجود دارد؟» پاسخ می‌دهد. اما نظارت بر عامل باید به سؤالات دیگری پاسخ بدهد: چرا این جلسه به‌طوردست‌کم بیشتری هزینه کرده؟ چرا نماینده مرتباً با همان ابزار تماس گرفته؟ آیا نماینده واقعاً همان کاری را که ادعا می‌کرد انجام داده؟ کدام مدل برای این کار مناسب‌تر است؟ آیا عامل الگوهای خطا را تکرار می‌کند یا یاد می‌گیرد؟ این‌ها سوالاتی متفاوت هستند و شمارنده‌های Prometheus و داشبوردهای Grafana به‌تنهایی کافی نیستند.
سه ستون برای نظارت بر نمایندگان وجود دارد:
1. ردیابی‌ها – جدول‌زمانی جلسه 🧾 هر جلسهٔ نماینده باید یک ردیابی اختصاصی تولید کند — نه یک ردیابی عمومی APM، بلکه یک عامل-trace که تاریخچهٔ کامل تصمیم‌گیری را ضبط می‌کند: هر فراخوانی مدل (LLM)، هر فراخوانی ابزار، هر تفویض نمایندگی فرعی، همراه با زمان و هزینهٔ مربوط. ما از Langfuse به‌عنوان backend ردیابی استفاده می‌کنیم. هر فراخوانی LLM، اجرای ابزار و تفویض نمایندگی فرعی یک بازه (span) دارد و این بازه‌ها تو در تو (traces nest) هستند؛ کار نمایندهٔ فرعی به‌عنوان فرزند ردیابی والد ظاهر می‌شود تا بتوان بدون از دست دادن رشتهٔ تصمیم‌گیری، جریان را دنبال کرد.
تحویل ردیابی باید غیر‌مسدود باشد: اجرای ابزار هرگز نباید در یک HTTP POST منتظر ارسال ردیابی بماند. از یک خط لولهٔ صادرکنندهٔ دسته‌ای استفاده کنید تا داده‌ها در حافظه بافر شوند و به‌صورت دوره‌ای flush شوند؛ هنگام خاموش‌شدن، بافر‌ها را تخلیه کنید. اگر backend ردیابی موقتا در دسترس نباشد، تله‌متری را از دست می‌دهید — نه دسترسی سرویس را.
2. هزینه‌ها – اقتصاد واحد عامل 💸 هزینهٔ توکن و اقتصاد واحد عامل‌ها مهم است. شما به دید در دو سطح نیاز دارید: در سطح هر جلسه — هزینهٔ کل، تفکیک توکن، و ردیابی اینکه کدام مدل در هر لحظه چه کاری انجام داده — و در سطح کلی — نرخ نوشت روزانه، تعداد جلسات، و روند هزینه. چرا این مهم است؟ عاملی که در حلقه می‌افتد ابزار مشابه را مکرراً فراخوانی می‌کند و توکن‌ها را به‌شکل نمایی می‌سوزاند. بدون نظارت روی هزینه، مشکل را وقتی فاکتور می‌رسد کشف می‌کنید، نه هنگام شروع حلقه.
نرده‌های محافظ پیشگیرانه ضروری‌اند: هشدارهای واکنشی به‌تنهایی کافی نیستند — یک حلقهٔ محکم در یک عامل موازی می‌تواند در عرض چند ثانیه بودجه را تماما مصرف کند. محدودیت‌های سخت برای تکرارها، بودجهٔ تماس هر ابزار و تشخیص حلقه که تماس‌های متوالی یکسان را مسدود می‌کند، همگی به‌عنوان قطع‌کننده‌های مدار عمل می‌کنند. هشدارها خط دوم دفاع هستند، نه خط اول. یک هشدار مناسب زمانی فعال می‌شود که یک جلسهٔ منفرد چند برابر میانگین هزینهٔ آن نماینده شود تا ناهنجاری‌های آهسته‌تر مثل مارپیچ‌های توهم یا انباشت حافظه تشخیص داده شوند.
3. حسابرسی – رکورد غیرقابل‌تغییر 🛡️ هر فراخوانی ابزار، هر تصمیم حاکمیتی و هر عملیات حافظه باید به‌صورت append-only، ساختاریافته، دارای مهرزمان و قابل جستجو ثبت شود. خروجی‌های ابزار که ممکن است داده‌های حساس داشته باشند باید پیش از وارد شدن به رکورد پاک‌سازی شوند. شما باید بتوانید آنچه رخ داده را بازسازی کنید بدون آنکه اعتبارنامه‌ها افشا شوند.
فرمان تشخیصی ما شبیه یک معاینهٔ پزشکی است: در یک نما سلامت عامل را بررسی می‌کند — اتصال مدل‌ها، دسترسی به vector store، تائیدیه‌های منتظر، تعداد آیتم‌های حافظه، وضعیت ردیابی backend و سلامت یکپارچه‌سازی‌ها. یک دستور به‌سرعت نشان می‌دهد که آیا وابستگی‌ها سالم‌اند یا خیر، بدون اینکه لازم باشد چندین داشبورد را بررسی کنید.
بازبینی خودکار ردیابی‌های تکمیل‌شده برای اشکال‌زدایی مفید است؛ اما وقتی روزانه صدها نماینده صدها جلسه اجرا می‌کنند، بازبینی دستی همهٔ جلسات عملی نیست. ما تجزیه و تحلیل خودکار را روی ردیابی‌ها اجرا می‌کنیم: مدت، هزینه، تعداد ابزارها، تشخیص حلقه و پرچم‌های بازدهٔ توکن. جلسات غیرعادی — حلقه‌ها، هزینهٔ بالا، خطاهای ابزار — برای بررسی انسانی علامت‌گذاری می‌شوند. انسان‌ها پرچم‌ها را بررسی می‌کنند، نه هر جلسه را.
معیارها در برابر ردیابی‌ها: برای داشبوردهای بلادرنگ و هشدارها، معیارهای خلاصه‌شده را به Prometheus (یا مشابه) صادر کنید: نرخ موفقیت/شکست ابزار بر اساس نام ابزار، هزینهٔ جلسه در هر نماینده، هیستوگرام تاخیر تأیید، و شمارش طبقه‌بندی‌ها. این معیارها ردپاهای ردیابی را تکمیل می‌کنند، نه جایگزینشان. هشدار مهم دربارهٔ کاردینالیته: برچسب‌های Prometheus را کم‌کاردینال نگه دارید — نام ابزار و نام نماینده امن‌اند، اما هرگز شناسه‌های یکتا مانند session_id را به‌عنوان label قرار ندهید؛ انفجار کاردینالیته می‌تواند سرور متریک را از کار بیندازد. جزئیات جلسه را به لاگ‌های ردیابی یا ساختار یافته بسپارید.
چه باید تماشا کرد — سیگنال‌ها و اهمیت آن‌ها 🔎 هزینهٔ جلسه در مقابل میانگین، تشخیص حلقه و نرخ رشد از اوایل موضوع را نشان می‌دهند. افزایش ناگهانی هزینه تقریباً همیشه نشانهٔ یک باگ است — حلقه‌ها، خطاهای مسیریابی مدل یا انباشت بافت نامحدود. هشدار دربارهٔ هزینه باید اولین گام باشد و اشکال‌زدایی دومین. ردیابی‌ها برای اشکال‌زدایی هستند و معیارها برای هشدار؛ تلاش برای هشدار بر اساس ردیابی‌های بسیار دقیق یا اشکال‌زدایی با معیارهای بیش از حد تجمیع‌شده اشتباه است — از هر دو به‌درستی استفاده کنید.
ویرایش PII غیرقابل‌مذاکره است. دنبالهٔ حسابرسی در بازبینیِ حادثه مورد بازخواست قرار می‌گیرد؛ اگر حاوی اعتبارنامه یا اطلاعات شناسایی فردی باشد، ابزار مشاهده‌پذیری شما به یک مسئولیت تبدیل می‌شود. یک فرمان تشخیصی بسازید که همهٔ وابستگی‌ها را چک کند و پاک‌سازی را با پاسخ موفق/ناموفق گزارش دهد — این در زمان صرفه‌جویی بیشتری از مرور چندین داشبورد خواهد کرد.
تجزیه و تحلیل ردیابی خودکار لازم است: نمی‌توانید صدها جلسه را روزانه به‌صورت دستی مرور کنید. اجازه دهید تحلیلگر ناهنجاری‌ها را علامت‌گذاری کند؛ انسان‌ها سپس پرچم‌ها را مرور می‌کنند و نه تمام جلسات را. ✅
